Supermarkt-Lieferdienste sind in der Pandemie sehr beliebt. Neben den Klassikern sind jetzt Dienste neu im Spiel, die in unter einer Stunde liefern. Einer davon ist Gorillas – hier bekam man nicht nur die bestellten Äpfel und Müsliriegel in 10 Minuten, sondern genauso schnell auch die Daten aller Kund*innen.

Wie das passieren konnte? Leider mal wieder viel zu einfach. Hier die ganze Geschichte von vorne:

Gorillas ist zurzeit der größte dieser Dienste in Deutschland und verspricht mit großflächiger Werbung eine Lieferung innerhalb von 10 Minuten. Die Bestellungen werden dann in dezentralen Depots zusammengestellt und auf Fahrrädern ausgeliefert.

Vor einigen Wochen sind wir schon mal über eine Sicherheitslücke bei der Konkurrenz gestolpert. Nun hat Gorillas in den letzten Wochen ein extremes Wachstum hingelegt und auch nochmal absurde 290 Millionen US-Dollar Venture Capital eingesammelt¹ – für uns ein guter Grund, den Dienst mal auszuprobieren.

Es ist schon fast ein Routineschritt: Bei jeder neuen App, die wir installieren, einmal kurz mit einem mitmproxy² in den Datenverkehr zu schauen. Dabei fällt uns direkt auf den ersten Blick auf, dass Gorillas hier Daten aus zwei verschiedenen Google Cloud Storage Buckets lädt: eddress und gorillas-public. Buckets sind einfach nur ein fancy Name für Ordner in Cloud-Speicher-Diensten – und diese werden hier genutzt, um Produktbilder und Werbebanner an die App auszuliefern.

Nicht immer will man, dass eine Liste aller Dateien, die in einem Bucket liegen, öffentlich zugänglich ist, beispielsweise wenn Geschäftsdaten im Spiel sind. Deswegen ist bei den meisten Cloud-Services die öffentliche Auflistung der Dateien standardmäßig deaktiviert. So kann man zwar auf die Dateien zugreifen – aber nur, wenn man den exakten Link kennt.

Nunja, in diesem Fall konnten wir uns eine Liste aller Dateien anzeigen lassen und damit auch die einzelnen Dateien selbst. So hatten wir Zugriff auf viele, viele Fotos von all den Produkten, die Gorillas im Angebot hat. Prinzipiell ist es erst einmal nicht schlimm, wenn wir nun die Links zu allen Produktbildern kennen. Leider blieb es nicht dabei und natürlich kommt jetzt ein großes Aber…

Im Cloud-Bucket von Gorillas haben wir auch Fotos von Dingen gefunden, mit denen wir so nicht gerechnet hatten: Haustüren und Klingelschilder. Sind das etwa auch Produktfotos? Hat der Lieferdienst hier eine weitere Marktlücke entdeckt und ist ins Baumarktbusiness eingestiegen? Wohl eher nicht: Diese Dateien waren definitiv nicht für die Öffentlichkeit bestimmt. Streng genommen eigentlich nicht einmal für Gorillas.

Die abfotografierten Haustüren und Klingelschilder kommen von Fahrer*innen, die anscheinend vereinzelt Fotos machen sollen, nachdem sie eine Bestellung ausgeliefert haben. Davon steht nicht nur nichts in der Datenschutzerklärung³, sondern es ist auch einfach nur creepy⁴.

Als wir im Bucket eddress nun auch noch Sprachmemos, Rechnungen und Datenbank-Backups finden, wird klar, dass dies nicht gewollt sein kann.

Was ist eddress jetzt schon wieder?

Der Name »eddress« taucht nicht nur in dem Bucket-Namen auf, sondern auch im App-Identifier, scheint also relevant zu sein.

Nach kurzer Recherche stellt sich heraus: Eddress ist ein Unternehmen mit Sitz in Pakistan und im Libanon, das White-Label-Kurier-Software anbietet – also gezielt neutral gehaltene Software, welche die einzelnen Lieferdienste dann passend zum eigenen Unternehmen gestalten können. Eddress selbst betreibt auch einen Lieferdienst, ganz ähnlich wie Gorillas, namens noknok im Libanon.

Die Apps von noknok und Gorillas sehen sich zum Verwechseln ähnlich. Das legt den Schluss nahe, dass Gorillas seine Software einfach komplett bei Eddress eingekauft hat. Auch stellt sich raus, dass der CEO von Eddress mittlerweile CTO von Gorillas geworden ist. Die beiden Unternehmen sind also tatsächlich eng miteinander verwoben.

Noch 200g von den API-Keys dazu?

Nachdem wir wussten, dass das Gorillas-System von Eddress gebaut wurde, wollten wir mehr zu dieser Kooperation erfahren. Die Suchmaschine unserer Wahl fand zwar keine Artikel zu dem Thema, brachte uns aber auf ein Admin-Portal von Gorillas/Eddress: portal.gorillas.io.

Hier werden wir von einem Login-Screen begrüßt, zu dem wir keine Zugangsdaten haben. Ein kurzer Blick in die Browsertools zeigt aber: Das JavaScript für das Portal wird auch schon vor dem Login geladen und wir können deswegen einen Blick in den Quellcode werfen.

Dabei fielen uns diese Zeilen auf:

Nachdem wir beim Lieferdienst Flink bereits Erfahrungen mit GraphQL-Schnittstellen gesammelt haben, packen wir auch dieses Mal die auffällige URL in den GraphQL-Client unserer Wahl.

GraphQL ist eine Sprache, um Datenabfragen zu formulieren. Man beschreibt also, welche Informationen man gerne vom Server hätte und in welcher Form. So konnten wir zum Beispiel dem Server bei Flink sagen: »Gib uns die letzten 10 Bestellungen, wer sie getätigt hat und was bestellt wurde.« Der Server auf der anderen Seite sollte dabei eigentlich so eingestellt sein, dass er nicht alle Anfragen gleichermaßen behandelt, sondern bestimmte Informationen nur berechtigten Anfragesteller*innen herausgibt. Bei Flink war das falsch konfiguriert – und bei Gorillas?

Um das herauszufinden, haben wir uns die GraphQL-Möglichkeiten näher angeschaut. So bringt GraphQL beispielsweise eine Funktion mit, um herauszufinden, welche Informationen man wie abrufen kann: Introspection. Die meisten GraphQL-Clients erstellen daraus automatisch eine Dokumentation der API, so auch unserer:

Die beiden Abfragen für die Bestellungen benötigen Zugangsdaten, deswegen bekommen wir nur die folgende Fehlermeldung:

Die tenantConfig allerdings lässt sich ohne jegliche Zugangsbeschränkung abrufen. Und die dort ausgelieferten Informationen sind durchaus brisant: API-Keys und URLs für verschiedene Services, die scheinbar von der Gorillas-Infrastruktur genutzt werden. Darunter API-Keys für Sendgrid und Slack-Webhook-URLs.

Mit den Slack-URLs könnten wir Nachrichten in bestimmte Slack-Kanäle von Gorillas posten: »Heute Hitzefrei!«

Viel relevanter sind jedoch die Sendgrid-API-Keys. Sendgrid ist ein sogenannter transaktioneller E-Mail-Provider. In den letzten Jahren ist es schwieriger geworden, als neuer Anbieter E-Mails selber so zu versenden, dass sie in der Inbox landen und nicht sofort im Spamfilter hängen bleiben. Statt sich also selbst um den Mailversand zu kümmern, bezahlen immer mehr Anbieter Unternehmen wie Sendgrid, Mailjet oder Amazon SES, damit diese die E-Mails für sie versenden.

Mit dem Sendgrid-API-Key könnten wir also E-Mails im Namen von Gorillas versenden: »Hey Investors, Geld is wieder alle«

Dieses Problem betrifft nicht nur Gorillas, sondern auch andere Dienste, welche die Software von Eddress benutzen. Darunter unter anderem:

• oyanow, Nigeria
• noknok, Libanon
• Liban Post (die staatliche Post im Libanon)

Dadurch könnten Angreifer*innen z.B. authentisch aussehende E-Mails im Namen von Gorillas oder anderen Eddress-Kund*innen versenden.

Bei Sendgrid lässt sich sehr feinkörnig einstellen, welcher API-Key welche Rechte hat. Die betroffenen API-Keys haben jedoch extrem viele Berechtigungen: Der API-Key von Gorillas für 100 Funktionen, der von Liban Post sogar für mehr als 200 Funktionen. Neben dem Verschicken von E-Mail befindet sich darunter auch die Berechtigung zum Anlegen neuer API-Keys. Eine Angreifer*in könnte sich so relativ unbemerkt einen neuen API-Key erstellen – und diesen auch dann weiter nutzen, wenn der geleakte API-Key deaktiviert wird.

Dürfen es noch ein paar mehr Daten sein?

Wir waren gerade fertig damit, den Report für die bisher beschriebenen Lücken zu schreiben, da kam uns eine Idee: Um auf die Abfragen nach den Bestellungen zugreifen zu können, benötigt man eine Zugangskennung (JSON Web Token). Wenn man sich in der App einloggt, bekommt man eine Kennung dieser Art. In der Erwartung, dass wir damit maximal unsere eigenen Daten abfragen können, haben wir also unsere Zugangskennung aus dem App-Datenverkehr genommen und in unseren GraphQL-Client eingegeben. Und tätsächlich bekamen wir Daten. Nicht nur unsere, sondern alle.

Insgesamt konnten wir die Daten von über 1.000.000 Bestellungen, den dazuhörigen 200.000 Kund*innen sowie Fahrer*innen abrufen.

Dazu gehören:

• Name, Adresse, E-Mail-Adresse und Telefon-Nummer der Kund*innen
• Bestelldetails (bestelle Produkte, Anzahl, Preis, etc.)
• Bei Kreditkartenzahlung: Ablaufdatum der Kreditkarte
• Referenzen auf Fotos der Haustür/des Klingelschildes, falls vorhanden
• Name und Telefonnummer des “activeWorker”, vermutlich von Fahrer*innen oder Picker*innen

Betroffen sind also nicht nur die Kund*innen, sondern auch die Fahrer*innen – ein weiteres Problem im Umgang von Startup-Lieferdiensten mit ihren Arbeiter*innen. Die Arbeitsbedingungen der Picker*innen und Rider*innen standen schon mehrfach in der Kritik. Für die Kund*innen hat dieses Datenleck aber noch ganz andere Auswirkungen.

Spear-Phishing mit dem Schleppnetz

Diese ganzen Daten bilden zusammen mit dem Sendgrid-Zugriff die Grundlage für ein extrem perfides Angriffsszenario. Bei E-Mails soll man nicht nur darauf achten, ob der Absender plausibel aussieht, sondern auch, ob man beispielsweise mit richtigem Namen angesprochen wird, um sicher zu gehen, dass es sich dabei nicht um Phishing-E-Mails handelt.

Wir haben aber beides in der Hand: Wir kennen die Daten aller Kund*innen samt ihrer Bestellungen und können E-Mails im Namen von Gorillas schreiben.

Jetzt stellen wir uns eine E-Mail an alle Gorillas-Kund*innen mit sinngemäß diesem Inhalt vor:

Hallo Alex Mustermensch, 🦍❤️

Du hast am 01.01.1970 bei uns für 23.42€ an die Adresse “Musterstraße 123, 00000 Musterstadt” bestellt. Dafür hast du deine Kreditkarte mit dem Ablaufdatum 13/37 benutzt. Leider wurde die Zahlung von unserem Zahlungsdienstleister storniert. Deswegen müssen wir dich bitten, deine Rechnung zu begleichen.

Die Zahlung kannst du bequem unter folgendem Link tätigen: ich-stehle-deine-kreditkartendaten‎.de/payment/{Bestellnummer}

Hier findest du noch einmal eine Auflistung aller von dir bestellten Produkte:

Da die Domains gorlllas.io und goriilas.io noch frei sind, würden sich hier sogar vertraut aussehende Domains für die Zahlung nutzen lassen. Allerdings sind es Menschen mittlerweile sowieso gewöhnt, auf verschiedenste Zahlungsanbieter umgeleitet zu werden.

Fest steht: Wir würden drauf reinfallen.

Gorillas’ Reaktion

Während wir die Lücken fanden, haben wir diese auch dokumentiert und danach gesammelt an das CERT-Bund gemeldet. Das CERT-Bund hat sie dann überprüft und an Gorillas übermittelt. Gorillas hat die beschriebenen Lücken, nach eigener Aussage, inzwischen geschlossen, die SendGrid-API-Keys widerrufen und auch die Kund*innen und Fahrer*innen informiert. Wir begrüßen sehr, dass Gorillas dort von sich aus tätig wird, obwohl nicht unbedingt eine Rechtspflicht besteht.

Auch wir haben diese E-Mail bekommen. Leider müssen wir, trotz des guten Willens, kritisieren, dass Gorillas nicht genau benennt, welche Daten abrufbar waren. Denn wer erinnert sich schon einige Monate nach einer Bestellung von völlig normalen Alltagswaren, welche Daten beim Lieferdienst angegeben wurden? Und auch von den Fotos von Haustüren und Klingelschildern ist kein Wort zu lesen. Das finden wir sogar noch schlimmer, weil die Kund*innen von Gorillas nicht einmal wissen, dass diese Bilder überhaupt existieren.

Wann lernt die Branche endlich?!?

Es ist jetzt schon das zweite Mal, dass ein Supermarklieferdienst über eine ungeschützte GraphQL-Schnittstelle stolpert. Wir hatten ja ein wenig die Hoffnung, dass die Lücke bei Flink ein Warnschuss für alle Anbieter war, und sie in ihren eigenen System noch mal genau nachschauen, ob sie ähnliche Probleme haben. Dass selbst bei Investitionen von dreistelligen Millionenbeträgen die IT-Sicherheit nicht ansatzweise geprüft wird⁵, überrascht uns nun ein weiteres Mal. Wir hätten erwartet, dass Investor*innen bei solchen Beträgen doch etwas mehr Sorgfalt bei der Auswahl ihrer Investitionsziele walten lassen. Denn die Konkurrenz soll sicher auch nicht wissen, welche Produkte wo besonders gut laufen.

Dabei hat IT-Sicherheit das Problem vieler Präventionsmaßnahmen: Je besser sie ist, desto weniger sieht man ihren Nutzen. Erst wenn das Kind in den Brunnen, oder die zerforschung in die Datenbank gefallen ist, merkt man, dass da etwas gefehlt hat. Sobald die Brunnen und Datenbanken ausreichend gesichert sind, merkt niemand etwas davon – weil ja alles richtig, reibungslos und leise läuft.

Gleichzeitig lässt sich IT-Sicherheit oft nicht so gut vermarkten wie neue Features⁶ und es fehlen auch etwas die finanziellen Anreize. Die DSGVO erlaubt empfindliche Strafen für solche Datenschutzverletzungen. Jetzt sind die Datenschutzbehörden an der Reihe, diese auch auszusprechen, damit Unternehmen in Zukunft noch einen Grund mehr haben, auf ihre Sicherheit zu achten.

Offenlegung: Gorillas hat uns unangekündigt 15.000€ überwiesen.

Wir haben weder Gorillas noch irgendein anderes Unternehmen, bei dem wir Sicherheitslücken fanden, je um Geld gebeten und werden das auch in Zukunft nicht tun. Trotzdem haben wir uns über diese Zuwendung sehr gefreut und möchten uns dafür bedanken.

Die Überweisung haben wir erst nach dem Erscheinen des Artikels bemerkt und sie hat weder Einfluss auf unsere aktuelle, noch auf eventuelle zukünftige Berichterstattung über Gorillas.