Akerna/LeafData LCB B2B Sales Data Leakage
The LeafData (aka: Akerna, MJ Platform, MJ Freeway) platform in Washington is leaking B2B sales data. In this scenario a B2B sale from LicenseA to LicenseB has become visible to LicenseC who is completely unrelated to either A or B
We sent a bug report, with necessary details however the response from LeafData was that it was not reproducable. They stated they couldn't test until we could provide full HTTP logs (they could have seen first hand by simply trying a single API request). Fortunately, we work with two of the affected licensees and we have this service called Pipe, which traps all that for us.
Pipe Cannabis API Proxy
The Pipe service we offer is an API proxy specifically designed for interacting with cannabis service APIs. For those who have worked with these systems their issues are legend. So Pipe exists for this exact purpose. We can use this service to log every single request and response from these other API services.
Logs of Leakage
B2B IT227MW is from WAWA1.MMCH to WAWA1.MM5V and it's visible to WAWA1.MMLH -- which not the sender or receiver.
B2B IT2284L is from WAWA1.MMCH to WAWA1.MM5W and it's also visible to WAWA1.MMLH -- which not the sender or receiver.
Analysis
The service provider was unable, or unwilling, to diagnose this simple issue. We provided them with the transaction IDs and the affected license IDs. They could simply executed two API calls -- the ones shown in these logs. It should be trivial for them to either execute these calls or evaluate the data from their own logs.
The process was quite simple.
First, using those identified transfers we just grep some log files.
On our system it took about 10 minutes to find the log files and extract the specific requests.
Second there was a small amount of work to map those "Global IDs" to the license codes the LCB provides. That's only three records to map, and if you are the service provider it should, again, be trivial. It took us less than one minute.
Third one simply looks at the data to determine the cause, which for this one is trivial! In fact, it may have been apparent to those familiar with the data at the first report of this issue.
The transfers that are leaking have a mis-assigned "global_transporting_mme_id".
You'd have to look at those logs, and understand this data to see it, so we'll show you.
There are three different license related attributes on a B2B Sale (aka Transfer). They are "global_from_mme_id", "global_to_mme_id" and "global_transporting_mme_id". Typically, the B2B sale is only visible to the buyer (global_to_mme_id) and seller (global_from_mme_id). What's happening here is that global_transporting_mme_id is also being shown these B2B sales. In this case, the global_transporting_mme_id is not actually a transporter, it's different farm.
Cause
It appears that two things are happening.
One, the LeafData system is not enforcing that only Transporter type license are used in the global_transporting_mme_id field.
Secondly, the LeafData system is then leaking this information to non-trasporters once they are incorrectly assigned.
A simple piece of data validation would have prevented this issue.
Additional Impact
Looking at the data-dumps provded by the LCB we can discover some additional interesting things about this bug. We're using a sample data-set loaded from transactions through January 2020.
- 10.57% of all B2B Sales are using a third party transporter -- (110789 of 1047694)
- 83.43% of the Carrier type deals are using an actual carrier license ("Z") -- (92436 of 110789)
- 16.56% of the Carrier type deals are using a non-carrier type license! -- (18353 of 110789)
- 1.75% of the total B2B sales have incorrect transporter assigned.
Appears this little bug affects thousands of records.