During the pandemic, grocery delivery services gained popularity. New players on the market offer delivery in under an hour. One of them is Gorillas, which not only delivers apples and granola bars in 10 minutes, but just as quickly delivered the data of all its customers.

How could this happen? Unfortunately, it was once again much too simple. But let’s start at the beginning:

Gorillas currently is the largest of these services in Germany. On large billbords they promise delivery times of under 10 minutes. Orders are picked in decentralized depots and delivered by riders on bicycles.

A few weeks ago, we already stumbled across a security vulnerability in the software of their competitor ‘flink’. Gorillas has experienced extreme growth in recent weeks and also raised another absurd 290 million US dollars in venture capital¹ - a good reason for us to give their service a try.

For us it’s almost a routine step: with every new app we install we take a quick look at its data traffic with a mitmproxy². At first glance, we notice that Gorillas loads data from two different Google Cloud Storage buckets: eddress and gorillas-public. Buckets is simply a fancy name for folders in cloud storage services - here these are used to store and deliver product images and advertising banners to the app.

You don’t always want a list of all the files that are in a cloud bucket to be publicly available, for example when business data is involved. That’s why most cloud services disable the public listing of files by default. That way you can access the files - but only if you know the exact link.

Well, in this case, we were able to see a list of all the files, and thus access the individual files themselves. We had access to many, many photos of all the products Gorillas offers. Knowing the links to all product images would not necessarily be a problem, but unfortunately, it didn’t stop there:

In the gorillas cloud bucket, we also found photos of things we didn’t expect to see there: front doors and doorbell signs. Are these product images, too? Has the delivery service discovered another market niche and entered the hardware store business? Probably not: these files were definitely not intended for the public. Strictly speaking, not even for Gorillas.

The photographed front doors and doorbell plates come from drivers who seem to sometimes need to take such photos when delivering an order. Not only is this part missing in the privacy policy³, but it’s also just creepy⁴.

As we now find voice memos, invoices and database backups in the bucket eddress, it becomes clear that this cannot be intentional.

What the hell is eddress?

The name “eddress” appears in many places. Not only in the bucket name, but also in the app identifier, so it seems relevant.

After a brief investigation, it turns out: Eddress is a company based in Pakistan and Lebanon that offers white-label courier software - software that is purposefully kept neutral, which individual delivery services can then design to fit their own business. Eddress itself also operates a delivery service, much like Gorillas, called noknok in Lebanon.

The apps from noknok and Gorillas look almost identical. This suggests that Gorillas bought their software entirely from eddress. Also, it turns out that the CEO of eddress has now become the CTO of Gorillas. So the two companies are indeed closely intertwined.

Add another 200g of API keys?

After knowing that the Gorillas system was built by eddress, we wanted to learn more about this collaboration. Our search engine of choice didn’t find any articles on the subject, but it did take us to an admin portal for Gorillas/eddress: portal.gorillas.io.

Here we are greeted by a login screen to which we have no credentials. But a quick look into the browser tools shows: The JavaScript for the portal is loaded before the login. That allows us a look into the source code.

Looking at the code, these lines caught our eye:

Having had previous experience with GraphQL interfaces in the delivery service Flink, we immediately entered the URL into a GraphQL client of our choice.

GraphQL is a language for data queries. That means you can describe what information you would like to have from the server and in what format. For example, at Flink, we could tell the server, “Give us the last 10 orders, who placed them, and what was ordered.” The server on the other side should be configured not to handle all requests equally, but to only give out certain information to authorized users. With Flink, this was configured incorrectly - and with Gorillas?

To find out, we used a really cool function of GraphQL: Introspection. Introspection provides a method to find out what information can be retrieved and how. Most GraphQL clients automatically create documentation of the API from this:

The two queries for orders need credentials, that’s why we only get the following error message:

The tenantConfig however can be accessed without any restrictions. And the information delivered there is quite interesting: API keys and URLs for various services that are apparently used by the Gorillas/eddress infrastructure. Among them we found API keys for Sendgrid and Slack webhook URLs.

With the Slack URLs, we could post messages to specific Gorillas Slack channels: “No work today!”

Much more relevant, however, are the Sendgrid API keys. Sendgrid is a so-called transactional email provider. In recent years it has become increasingly difficult to send emails with your own infrastructure in a way where they end up in the receivers inbox and don’t immediately get caught by spam filters. So instead of taking care of sending e-mails themselves, more and more providers turn to services like Sendgrid, Mailjet or Amazon SES, which send out the e-mails for them.

So with the Sendgrid API key, we could send emails on behalf of Gorillas: “Hey investors, we’ve run out of money again”

This problem doesn’t only affect Gorillas, but also other services that use eddress’ software. Among them are:

• oyanow, Nigeria
• noknok, Lebanon
• LibanPost (the national post office of Lebanon).

This would allow attackers to send authentic-looking emails on behalf of Gorillas or other eddress clients.

Sendgrid allows a very detailed configuration of which API key is allowed to do what. However, the API keys in question have an extremely large number of permissions: The API key of Gorillas for 100 of these so-called “scopes”, the one of Liban Post for more than 200. In addition to sending e-mails, this also includes the authorization to create new API keys. An attacker could thus create a new API key relatively unnoticed - and continue to use it even if the leaked API key is revoked.

Would you like to have some more data?

We had just finished writing the report for the problems described so far when an idea came to us: To access the queries for orders you need an access token. When you log into the app you get a token of this type. So, expecting that it would allow us to query our own data, we took our access identifier from the app and entered it into our GraphQL client. And sure enough, we got data. Not just ours, but all of it.

In total, we were able to retrieve data on over 1,000,000 orders, the associated 200,000 customers, and workers.

This includes:

• Names, addresses, email addresses and phone numbers of customers
• Order details (products ordered, quantity, price, etc.)
• In the case of credit card payment: the expiration date of the credit card
• References to photos of the front door/bell plate, if available
• Name and phone number of “activeWorker”, presumably drivers or pickers.

So it’s not just the customers who are affected, but also the workers - another problem in how startup delivery services treat them. The working conditions of pickers and riders have already been criticized several times.

Spear phishing with a trawl

All this data, together with SendGrid access, forms the basis for an extremely evil attack scenario. To safeguard against phishing e-mails, people are taught to not only check the accuracy of the sender, but also whether for instance one is addressed with the correct name.

But we have both now: We know the data of all customers, including their orders, and can write e-mails in the name of Gorillas.

Now let’s imagine an e-mail to all Gorillas customers that ordered in the last few days with the following content:

Hello Alex Example, 🦍❤️

Yesterday you ordered with us for 23.42€ to the address “Examplestreet 123, 00000 Examplecity”. For this, you used your credit card with an expiration date of 13/37. Unfortunately, the payment was declined by our payment service provider. Therefore we have to ask you to settle your invoice.

You can make the payment comfortably under the following link: i-steal-your-credit-card-data.com/payment/{order-number}

The products you ordered were: […]

Since the domains gorlllas.io and goriilas.io are not registered, even familiar-looking domains could be used. Anyway, people are already used to being redirected to a wide variety of payment providers.

One thing is for certain: We would fall for it.

Gorilla’s reaction

While finding the vulnerabilities, we also documented them and reported them collectively to CERT-Bund, the german federal Computer Emergency Response Team. CERT-Bund then reviewed them and forwarded our reports to Gorillas. Gorillas has, according to its own statement, closed the vulnerabilities described, revoked leaked API keys and also informed the relevant authorities as well as its customers and workers. We very much welcome that Gorillas informed its customers and workers on its own initiative, even though there is not necessarily a legal obligation.

We also received the e-mail Gorillas sent to its customers. Unfortunately, we have to criticize that they do not name exactly which data was retrievable. Who remembers what data they might have entered, months after ordering normal everyday goods? And there is not a word about the photos of front doors and doorbell signs either. We think this is even worse because the customers of Gorillas don’t even know that these pictures exist.

When will the industry finally learn‽

This is the second time that a supermarket delivery service leaked all customer data because of an unprotected GraphQL interface. We hoped that the issue at Flink served as a warning for all providers and that they would take another close look into their own systems to see if they have similar problems. The fact that even with investments of triple-digit millions, IT security does not seem to be seen as important⁵ surprises us once again. We expected that investors would take a little more care when selecting their investment targets for such enormous sums. After all, the competitors are certainly not supposed to know which products are doing particularly well in which parts of the city.

Here IT security has the same problem as other preventative measures: The better it is, the less one sees its benefit. Only when it’s too late and we already found our way into the databases, the companies realise what they did wrong. As long as the system is sufficiently secured, no one notices - because everything is running properly, smoothly and quietly.

At the same time, IT security is harder to advertise than new features⁶ and financial incentives are somewhat lacking. The GDPR allows for severe penalties for such data breaches. Now it’s on the data protection authorities to issue them so that companies will have one more reason to pay attention to their IT security in the future.