- Auf einer Subdomain des Eicher-Motors-Prämienrechners wurden Microsoft-Unternehmens-Cloud-Zugangsdaten offengelegt, wodurch eine Anmeldung am
noreply-E-Mail-Konto von TTIBI möglich war - Die betroffene E-Mail-Versand-API verschickte Mails ohne Authentifizierung, und die Versandprotokolle in Server-Fehlerantworten legten ein base64-kodiertes Passwort offen
- In dem offengelegten Konto befanden sich 657.000 an Kunden gesendete E-Mails sowie Versicherungs-Police-PDFs im Umfang von rund 25 GB, Kundendaten, Links zum Zurücksetzen von Passwörtern und OTPs
- Für das Konto war keine Zwei-Faktor-Authentifizierung aktiviert, und auch andere Cloud-Ressourcen wie Microsoft-Unternehmensverzeichnis, SharePoint und Teams waren zugänglich
- Die verwundbare API wurde erst mehr als 2 Monate nach der Meldung so geändert, dass sie Authentifizierung verlangt; laut Stand vom 27. Januar 2024 wurde auch das Passwort des E-Mail-Kontos geändert, sodass keine Anmeldung mehr möglich ist
TTIBI-Kompromittierung begann mit Eicher-Prämienrechner
- Bei der Untersuchung von Eicher-Motors-Systemen wurde das Microsoft-E-Mail-Konto
noreplyeicher@ttibi.co.invon Toyota Tsusho Insurance Broker India, kurz TTIBI, offengelegt - TTIBI ist ein indischer Versicherungsmakler unter der japanischen Toyota Tsusho Insurance Management Corporation und wurde 2008 gegründet
- Eicher Motors ist ein indischer Fahrzeughersteller und produziert Motorräder von Royal Enfield Motors sowie Nutzfahrzeuge von VE Commercial Vehicles, einem Joint Venture mit der Volvo Group
- Die beiden Unternehmen hatten eine versicherungsbezogene Partnerschaft, und auf der TTIBI-Website existierte eine dedizierte Eicher-Subdomain
Weg zur Entdeckung der Schwachstelle
- Bei der Analyse der Android-App MY EICHER wurde in einer Java-Klasse für die API-Schnittstelle die URL des Prämienrechners gefunden
- Der Quellcode der Website des Prämienrechners enthielt einen clientseitigen Mechanismus zum E-Mail-Versand
- Im Code gab es Spuren der Verwendung von Bearer Authorization, sodass Authentifizierung erforderlich schien; als jedoch eine direkte API-Anfrage aufgebaut wurde, wurde statt
401 Unauthorizedtatsächlich eine E-Mail versendet - Die Server-Fehlerantwort gab zusammen mit ihr auch Versandprotokolle zurück, in denen ein base64-kodiertes Passwort enthalten war
Im noreply-Konto verbliebene Daten
noreplyeicher@ttibi.co.inwar einnoreply-Konto für den automatischen Mailversand, bei TTIBI handelte es sich jedoch um ein tatsächlich loginfähiges Konto- In diesem Konto blieb der gesamte Verlauf aller an Kunden gesendeten E-Mails erhalten
- insgesamt 657.000 E-Mails
- rund 25 GB Umfang
- Kundendaten
- Versicherungs-Police-PDFs
- Links zum Zurücksetzen von Passwörtern
- OTPs
- Da sogar OTPs und Links zum Zurücksetzen von Passwörtern einsehbar waren, waren darunter Informationen, die zur Übernahme von Kunden-Versicherungskonten missbraucht werden konnten
- Mit demselben Konto war auch der Zugriff auf Microsoft-Cloud-Ressourcen möglich
- Unternehmensverzeichnis
- SharePoint
- Teams
Sicherheitsversagen, das die Schwachstelle verschärfte
-
Clientseitige E-Mail-Versandfunktion
- Eine E-Mail-Versandfunktion, bei der der Client Betreff, Inhalt und Empfänger steuern kann, kann zum Versand bösartiger Mails missbraucht werden
- Da die Mails von einem echten Konto gesendet werden, kann dies zu beschädigter E-Mail-Reputation und Phishing führen
-
Fehlende API-Authentifizierung
- Im Frontend gab es Spuren der Nutzung von Authentifizierungs-Token, aber der Server prüfte die Token tatsächlich nicht
- Hätte der Server die Token überprüft, wäre dieser Angriff möglicherweise verhindert worden
-
Übermäßige API-Fehlerantworten
- Wenn bei der API-Verarbeitung Fehler auftraten, wurden dem Client zu viele Informationen zurückgegeben
- In diesem Fall legte die Fehlerantwort das Passwort direkt offen
-
Fehlende Zwei-Faktor-Authentifizierung
- Bei der Anmeldung am Microsoft-Konto gab es keine Zwei-Faktor-Authentifizierung und keine anderen Verifizierungsabfragen
- Mit Zwei-Faktor-Authentifizierung wäre eine erfolgreiche Anmeldung möglicherweise schwierig gewesen
-
E-Mail-Aufbewahrung
- Alle vom Konto gesendeten und empfangenen E-Mails wurden aufbewahrt, wodurch ein einfacher Zugriff auf große Mengen an Kundendaten möglich war
- Mit einer Aufbewahrungsrichtlinie hätte sich die Auswirkung der Offenlegung von Kundendaten verringern lassen
Reaktion und aktueller Status
- Am 17. Januar 2024 war das Passwort des E-Mail-Kontos noch nicht geändert worden, obwohl TTIBI die Schwachstelle bereits seit mehr als 5 Monaten kannte
- Laut Update vom 27. Januar 2024 wurde das Passwort des E-Mail-Kontos geändert, sodass eine Anmeldung an diesem Konto nicht mehr möglich ist
- Die verwundbare API wurde schließlich so geändert, dass sie Authentifizierung verlangt
- Ob es Warnungen zu ungewöhnlichen Microsoft-Logins gab, ist nicht bekannt; falls es Warnungen gab, wurden sie möglicherweise ignoriert oder nicht überprüft
Zeitachse der Meldung
- Da TTIBI nicht unter Toyotas HackerOne-Programm zur Offenlegung von Schwachstellen fiel, erfolgte die Meldung an India CERT-In
- 7. August 2023: Ausführlicher Bericht zur Schwachstelle an CERT-In gesendet
- 8. August 2023: CERT-In vergab eine Fall-ID und antwortete, TTIBI zu kontaktieren
- 1. September 2023: Um ein Update zum Fortschritt gebeten
- 6. September 2023: CERT-In antwortete, die Schwachstelle an TTIBI weitergeleitet zu haben und weitere Updates zu teilen
- 8. Oktober 2023: Die betroffene Website war offline, aber die verwundbare API bestand weiter; CERT-In wurde informiert
- 11. Oktober 2023: CERT-In antwortete, TTIBI habe die Schwachstelle behoben, bei der Überprüfung bestand sie jedoch weiterhin
- 18. Oktober 2023: Die E-Mail-Versand-API wurde so geändert, dass sie Authentifizierung verlangt, womit die Schwachstelle behoben wurde
- Anschließend folgten Gespräche über eine mögliche Bug-Bounty-Vergütung, doch TTIBI antwortete nicht, und der Fall wurde am 22. Dezember 2023 geschlossen
1 Kommentare
Kommentare auf Hacker News
Ich bin kein Inder, aber aus der Perspektive von jemandem, der bei einem großen IT-Dienstleister vom Tata-Typ arbeitet, fühlt sich das erschreckend realistisch an.
Eine große Rolle spielen hier eine Managementkultur, in der man belohnt wird, wenn man es billig erledigt, und eine Kultur, die Eigeninitiative oder Selbstverwirklichung von Entwicklern unterdrückt.
Hätte ich so etwas in den USA gesehen, wäre ich sofort gegangen, aber diese Leute haben praktisch keine Wahl, weil beim Kündigen 90 Tage Gehalt zurückgefordert werden.
Die meisten Manager haben keinen technischen Hintergrund, hören also nur, was sie hören wollen, und wollen nichts hören, was ihnen widerspricht.
Es kann sogar falsch sein, das als Ergebnis desselben Teams oder derselben Firma zu betrachten: Entwickler werden stark in Silos aufgeteilt, in API-Entwickler, Office-365-Entwickler, Frontend-Entwickler usw., und sie fassen Bereiche nicht an, für die sie nicht „zertifiziert“ sind.
Selbst in Meetings zu 100-Millionen-Dollar-Projekten wird ernsthaft über SendGrid-Kosten gestritten, bis am Ende irgendein Entwickler sagt, man könne es mit Office 365 machen, weil niemand „SendGrid-Erfahrung“ hat.
Das Budget des Sicherheitsteams wird als Erstes gekürzt, weil es ja „schon sicher sein sollte“, und wenn man mit dem Neffen redet, der für Security eingestellt wurde, bekommt man die Haltung: Warum sich die Mühe machen, wenn die Regierung oder sonst jemand ohnehin nicht klagen wird?
Entwickler werden nicht ermutigt, zu entwickeln, sondern lernen, Tickets abzuarbeiten und keine Fragen zu stellen.
Ich arbeite mit klugen Entwicklern in Indien zusammen, aber das ist keine Innovationskultur, sondern Arbeit, die wie ein Callcenter behandelt wird: nicht vom Skript abweichen, in einem engen Problembereich bleiben, und solange man nicht scheitert, gilt man als erfolgreich.
Das kann auch bald bei uns ankommen.
Ein Honda-Autohändler, mit dem ich Mitte bis Ende der 2000er zu tun hatte, speicherte Finanzierungsanträge unter fortlaufenden numerischen IDs.
Ich habe es nicht gemeldet, konnte aber mehrere sensible Informationen von Einwohnern New Jerseys abrufen, etwa SSNs, Geburtsdaten, Namen und Adressen.
Damals gab es praktisch keine Bug Bounties, aber den CFAA gab es, also habe ich es nicht gemeldet.
Ich habe meinen eigenen Antrag löschen lassen, aber die Schwachstelle blieb noch Jahre bestehen, bis auf ein neues System gewechselt wurde, und auch das neue System wirkte verwundbar.
Seitdem habe ich mit diesem Händler keine Geschäfte mehr gemacht und bin auch heute sehr vorsichtig bei Autohändlern und Finanzierungsanträgen. Selbst wenn es etwas teurer ist, nehme ich die Finanzierung normalerweise woanders auf.
https://eaton-works.com/2023/06/06/honda-ecommerce-hack/
Wir arbeiten unter https://cerebrum.com in einem anderen Bereich, der Identitätsprüfung, und dieser Kommentar hat mir viele Ideen gegeben.
Der Sicherheitsfehler selbst ist schrecklich, aber bis zu einem gewissen Grad lässt er sich damit erklären, dass man einem unerfahrenen Entwickler Aufgaben gegeben hat, die weit über sein Verständnis hinausgingen.
Was ich aber überhaupt nicht verstehe: Wie konnte es genehmigt werden, vertrauliche Kundendokumente in einem E-Mail-Konto zu speichern?
Das bedeutet, dass es niemand Verantwortlichen gibt, der weiß, wie dieses Geschäft betrieben werden muss; und wenn es sich um eine Tochtergesellschaft oder einen Outsourcing-Partner handelt, bedeutet es auch, dass nie jemand ein Audit durchgeführt hat.
Das kommt bei den Eigentümern des Unternehmens und bei der Stelle, die diese Arbeit vergeben hat, krimineller Fahrlässigkeit nahe.
Vermutlich gab es einfach eine Funktion des Mailservers, gesendete E-Mails zu speichern, und das Ganze entstand als Nebenprodukt der dummen Entscheidung, für die „noreply“-Adresse ein echtes Konto zu verwenden.
Das diente gewissermaßen als Audit-Log, Debugging-Tool und Datenbank-Backup zugleich.
Geändert wurde es erst, nachdem man merkte, dass Mitarbeiter sämtliche Kundendaten zu ihrem neuen Arbeitgeber mitnahmen.
Wenn „TTIBI die Schwachstelle seit über fünf Monaten kennt und trotzdem das Passwort des E-Mail-Kontos nicht geändert hat“, hoffe ich wenigstens, dass sie das Base64-Passwort aus den Fehlerlogs entfernt haben.
Bestimmt haben sie das. Oder?
Die Auswirkung ist buchstäblich enorm, nämlich Zugriff auf praktisch ganz SharePoint und Outlook, während der Weg dorthin nur darin besteht, clientseitiges JavaScript anzusehen. Das macht die Schwachstelle ziemlich ungewöhnlich.
Ein kleiner Punkt: Bei Screenshots halte ich es für besser, sensible Informationen mit schwarzen Balken zu verdecken statt sie zu verwischen. Vorsicht schadet nicht.
Weil solche Fälle mit einem „Dankesschreiben“ enden, werden die meisten dieser Schwachstellen von White Hats nicht gemeldet oder offengelegt, sondern aktiv von Hackern ausgenutzt.
Es braucht einen Rechtsrahmen, der Unternehmen für ein gewisses Maß an mangelhafter Sicherheitsverwaltung im Zusammenhang mit Kundendaten haftbar macht.
Indien hat größere Probleme als Datenlecks.
Eines davon ist eine stabile Stromversorgung.
Ich warte auf den Tag, an dem Indien genug Strom hat, sodass Hacking zur Hauptsorge wird.
Jeden Monat werden 100.000 km Glasfaser verlegt, und jeden Tag werden 350 5G-Basisstationen errichtet.
Man muss auch sehen, dass der Monitoring-E-Mail-Endpunkt praktisch wie ein Kommunikations-Worker/Agent/Runner entworfen wurde und dann unbeaufsichtigt immer weiter anwuchs.
Das bedeutet, dass die E-Mail-Nutzung nicht überwacht wird und es auch keine ergänzenden Kontrollen gibt, die anomales Verhalten erkennen, etwa: „Warum verursacht dieser E-Mail-Alias ein Vielfaches der Speicherkosten anderer Aliasse?“
Der Kern ist die Aussage: „Das noreply-Konto könnte das wichtigste Konto der Organisation sein, weil es potenziell alle Aufzeichnungen enthält, die an Kunden gesendet wurden.“
Wenn ein „führender Versicherungsmakler in ganz Indien“ kein Geld hat, um kompetente Entwickler einzustellen, sollte er der Person, die mehrere gravierende Probleme gefunden und verantwortungsvoll gemeldet hat, durch die Kunden gefährdet wurden, wenigstens ein paar Münzen zahlen.
Aber das haben sie nicht getan, und ich kann kaum glauben, dass sie sogar das Passwort des kompromittierten E-Mail-Kontos immer noch nicht zurückgesetzt haben.
Wie soll man einem Unternehmen, das sich so verhält, zutrauen, irgendetwas richtig zu machen?
Toyota Tsusho Insurance Broker India wirkt wie ein Unternehmen, das man meiden sollte wie die Pest.
Das ist nicht jemand, der eine wichtige Sicherheitswarnung aktiv ignoriert, sondern jemand, der nicht versteht, wovon die Rede ist.
Er begreift grundsätzlich nicht die Umgebung, die er betreibt, oder die Aufgabe, vor der er steht, und weil die Fachbegriffe, die du benutzt, für ihn oder sein Team keine Bedeutung haben, hofft er einfach, dass du verschwindest.
Die Haltung ist etwa: „Bitte hören Sie auf, verwirrende E-Mails zu schicken. Wir haben Wichtigeres zu tun.“
Um das zu lösen, braucht es auf Organisationsebene einen Austausch der Führungsspitze, und der IT-Verantwortliche samt allem, was er angefasst hat, muss weg.
Ein Teil des Problems besteht darin, dass dieses Postfach faktisch als „kostenloses“ SMTP-Konto genutzt wurde, um nicht für ausgehende E-Mails bezahlen zu müssen.
Hätten sie etwas wie SES verwendet, lägen im Gesendet-/Posteingang dieses Kontos nicht so viele sensible Informationen.
SES ist mit 0,10 Dollar pro 1.000 E-Mails sehr günstig.
Man müsste alle gesendeten E-Mails speichern und eine Oberfläche bauen, über die nichttechnische Sachbearbeiter frühere Nachrichten ansehen und durchsuchen können.
Wenn sie den gesamten Funktionsumfang dieses „kostenlosen“ SMTP-Ansatzes genutzt haben, sind Entwicklung und Wartung ziemlich teuer.