3133 stories
·
6 followers

Gorillas: Special offer – unicorn slices, 150g (2021)

2 Shares
Gorillas Advertising with the slogan 'Just going check gorillas one more time, then I will put the phone away... oh nice, cinnamon buns' but 'cinnamon buns' is replaced with 'data'

We felt more like “Oh fuck, Databreach”

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.

Gorillas is active in over 15 cities in 4 countries (DE, NL, UK, FR) and plans to expand to over 50 cities soon, including the USA. We found out about this through job ads, which are always an interesting research approach.

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:

Screenshot of the XML response listing all the files contained in the bucket.

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.

Doorbell place at the TV-Set of  Lindenstraße

Symbolbild (image: Jedesto, CC BY-SA 4.0, via Wikimedia Commons)

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.

Screenshot of the URL bar of the link to the Gorillas app which contains com.eddress.getgoodys as the app identifier

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.

Screenshots of the apps from gorillas and noknok side by side, differing almost exclusively in colour.

There are 20 differences between these images, can you spot them all?

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.

The logos of eddress and Gorillas, with the handshake emoji in between.

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.

Why is that?

The admin portal of Gorillas is a so-called single-page Application. This means that the page consists of only one HTML file and all content is loaded dynamically. The entire JavaScript code of the application is also delivered right from the start.

This is not a security problem per se, but it sometimes allows exciting insights into the infrastructure and features of a web app that was previously inaccessible due to a lack of login or permissions.

Looking at the code, these lines caught our eye:

Screenshot of a piece of JavaScript code. In it, there's a line hightlighted with a URL that says 'graphql'.

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:

Screenshot of an automatically generated doc for the 'activeOrders', 'ordersData' and 'tenantConfig' endpoints.

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

Screenshot of a GraphQL error message that we are not authorized to call `activeOrders`.

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.

GraphQL API Response, the data shows objects like 'emailConfig' with apiKey, sender email address and 'slackConfig'

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.
Screenshot of the JSON return of the API. Contains the COMPLETE information of an order, including products, amount, payment type, address, contact details, geo-coordinates, order status.

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.

Our delivery times are longer than 10 minutes: As a collective, we need well over a week to create such an article, from finding the issues to writing the reports, to publishing this post. If you like it, feel free to support us.

Adblock test (Why?)

Read the whole story
Sjon
7 days ago
reply
pbouwdewijn
9 days ago
reply
Share this story
Delete

The next big Wi-Fi standard is for sensing, not communication (2021)

1 Share

Article URL: https://staceyoniot.com/the-next-big-wi-fi-standard-is-for-sensing-not-communication/

Comments URL: https://news.ycombinator.com/item?id=29901587

Points: 166

# Comments: 170

Read the whole story
Sjon
11 days ago
reply
Share this story
Delete

Ghost in the ethernet optic

1 Share

Article URL: https://blog.benjojo.co.uk/post/smart-sfp-linux-inside

Comments URL: https://news.ycombinator.com/item?id=29919782

Points: 160

# Comments: 48

Read the whole story
Sjon
14 days ago
reply
Share this story
Delete

Apple moet Nederlandse datingapps eigen betaalsysteem toestaan

1 Share

Aanbieders van datingapps in Apples Nederlandse App Store moeten ook andere betaalsystemen dan Apples betaalsysteem kunnen gebruiken, meldde Tweakers onlangs. Appaanbieders moeten ook de mogelijkheid krijgen om in hun datingapp te kunnen verwijzen naar betaalmogelijkheden buiten de app. Hier krijgt Apple twee maanden de tijd voor. De ACM dreigt met een dwangsom van maximaal 50 miljoen euro als dit niet gebeurt.

De kwestie van Apples verplichte betaalinterface (en het dikke percentage dat Apple vervolgens afroomt) is al lang een hot topic. Vorig jaar liep een conflict tussen Apple en Epic hoog op, maar vooralsnog komt daar weinig uit. De Nederlandse procedure voelt als een bijzaak, zeker omdat het ‘maar’ om datingapps gaat en niet om het wereldwijd beroemde Fortnite. Maar vergis je niet, er wordt nogal wat betaald in datingapps, vrij gebruikelijk is dat mannen per bericht stevig betalen. (En de boze tongen beweren dat de vrouwen dan weer betaald krijgen om de mannen aan het lijntje te houden, maar dat terzijde.)

In ieder geval, ook datingapps moeten de betalingen (de aanschaf van credits waarmee je berichten kunt sturen en dergelijke) via de kassa van Apple laten lopen. En dat vinden zij oneerlijk, vandaar de rechtszaak. Dan krijg je dus altijd meteen de vraag: heeft Apple een machtspositie, en zo ja wat is dan de markt? Als je kijkt naar smartphones dan is het marktaandeel klein, je kunt het dan “high end smartphones” noemen en dan is het hoger, maar dat voelt wat arbitrair.

De ACM ziet het nog scherper, zoals samengevat door de rechtbank:

Volgens de ACM beschikt Apple over een economische machtspositie op de markt voor appstorediensten op het mobiele besturingssysteem iOS ten behoeve van datingappaanbieders. De datingappaanbieders hebben niet in voldoende mate substitutiemogelijkheden voor de appstoredienst van AppleApple kan zich daardoor in hoge mate onafhankelijk gedragen van datingappaanbieders.
Het juridisch meest objectieve argument voor een machtspositie hebben is dat je onafhankelijk van je concurrenten kunt opereren. En dat kan Apple, in ieder geval waar het gaat om app-levering, -onderhoud en -betaling:
Voor een breed bereik van de datingapp moet een appaanbieder in ieder geval in zowel de App Store als de Google Play Store aanwezig zijn (multi-homing). Voor datingappaanbieders is multi-homing essentieel, omdat datingapps sterk afhankelijk zijn van netwerkeffecten: hoe groter de kans op een succesvolle match, hoe aantrekkelijker het wordt om de app te gebruiken.
Anders gezegd, je moet als datingdienstaanbieder wel een app hebben en dat moet wel bij Apple (en Google) zijn, anders kom je er niet tussen als commerciële dienst. Dus Apple (en ja, ook Google) kunnen je dicteren wat ze willen en jij accepteert dat maar, de App Store laten zitten kán gewoon niet. En als jij wel moet winkelen bij Apple, dan heeft Apple een machtspositie en dan mogen ze niet vragen wat ze willen. Ook niet als het moetje door een andere oorzaak komt dan Apples eigen handelen.

Dit verklaart ook meteen waarom het over dating gaat. Bij Tweakers:

Een ACM-woordvoerder zegt daarover tegen Tweakers dat er de afgelopen jaren onderzoek is gedaan naar Apples App Store-beleid en de impact op de markt. Hieruit zou zijn gebleken dat datingappaanbieders de meeste last ervaren van deze voorwaarden.
Dat haakt dus in op bovenstaand argument: je moet een sterke afhankelijkheid hebben van netwerkeffecten om in die afhankelijke positie te komen, en dat zien we met name bij sociale apps. En in Nederland is die categorie grotendeels vertegenwoordigd door de datingapp.

Arnoud

Het bericht Apple moet Nederlandse datingapps eigen betaalsysteem toestaan verscheen eerst op Ius Mentis.

Read the whole story
Sjon
16 days ago
reply
Share this story
Delete

See how DMARC, SPF, and DKIM work interactively

1 Share

Article URL: https://www.learndmarc.com/

Comments URL: https://news.ycombinator.com/item?id=29869266

Points: 352

# Comments: 64

Read the whole story
Sjon
18 days ago
reply
Share this story
Delete

Open source maintainer pulls the plug on NPM packages colors and faker

1 Share

Article URL: https://snyk.io/blog/open-source-maintainer-pulls-the-plug-on-npm-packages-colors-and-faker-now-what/

Comments URL: https://news.ycombinator.com/item?id=29867525

Points: 208

# Comments: 488

Read the whole story
Sjon
18 days ago
reply
Share this story
Delete
Next Page of Stories