Kunden der Deutschen Telekom können ihre Daten und Verträge über das online Kundencenter einsehen und verwalten. Das Login erfolgt über https://accounts.login.idm.telekom.com/ mit den bei der Registrierung festgelegten Zugangsdaten.
Nun kann es natürlich passieren, dass man sein Kennwort vergisst. Natürlich hat die Telekom auch hierfür eine Lösung parat. Nämlich eine klassische Passwort-zurücksetzen-Funktion.
Die meisten Webseiten senden zum Zurücksetzen des Kennworts bekanntlich einen Link an die hinterlegte Mail-Adresse. Dieser Link beinhaltet dann einen Schlüssel, welcher beim Zurücksetzen des Kennworts validiert wird.
Die Telekom hat andere Pläne
Statt einem Link erhält man bei der Telekom einen 6-stelligen Bestätigungscode per Mail, welcher im Kundencenter eingegeben werden muss.
Es ist nicht schwer zu erkennen, dass es nicht gerade die sicherste Methode für eine Passwortzurücksetzung ist. Sofern aber eine strikte Eingabebegrenzung (“Bruteforce-Schutz”) vorhanden ist, sollte das aber kein großes Problem darstellen. Oder?
Let’s try it out
Um zu prüfen, ob ein Bruteforce-Schutz vorhanden ist, sollte das mehrfache Eingeben eines falschen Bestätigungscodes genügen. Nach mehreren fehlerhaften Eingaben, sollte der Vorgang abgebrochen werden und somit auch der korrekte Bestätigungscode invalidiert werden.
Gesagt getan. Ich forderte mir einen Bestätigungscode zum Zurücksetzen des Kennworts an und begann falsche Codes einzuhämmern. Zunächst schien es als würde es einen Bruteforce-Schutz geben. Zumindest erhielt ich nach drei fehlgeschlagenen Versuchen die Meldung:
“Zu viele Fehlversuche. Bitte versuchen Sie es später noch einmal.”
Ich soll es also später nochmal versuchen? Mit dem gleichen Code? Hmm
Stattdessen versuchte ich ohne Wartezeit nun den korrekten Bestätigungscode einzugeben. Und Baaaam! Er wurde akzeptiert und ich konnte mein Kennwort ändern.
Nur Zufall?
Um zu erkennen, ob hier wirklich eine Lücke existiert, musste ich wohl schon ein paar mehr Codes ausprobieren. Es kommt gelegentlich vor, dass Unternehmen entsprechende Schutzmaßnahmen auf mehren Ebenen implementieren, wodurch ein weiterer Schutz bspw. ab dem 20. Versuch greifen würde. Was also her musste war ein Skript, welches den Angriff automatisiert. Leider verwendet die Telekom JavaServer Faces, was die Herstellung eines Skripts aufgrund des komplexen Request-Aufbau sowie die Verwendung von Viewstates nicht gerade einfach machte.
Python ist toll
Nach einigen Stunden rumgewusel war ein funktionierendes Python-Skript hergestellt. Und siehe da: Es gab keinerlei weitere Schutzmaßnahmen. Es ließen sich problemlos 10 Codes pro Sekunde ausprobieren.
Die Geschwindigkeit des Angriffs wurde somit einzig und allein von der Performance des Servers bzw. die Dauer der POST-Requests beschränkt. Prinzipiell wäre jedoch auch Multithreading möglich gewesen, um die Geschwindigkeit durch das parallele Absetzen von Requests weiter zu erhöhen.
Schlussendlich hat das Skript dann automatisiert nach einem neuen Kennwort gefragt, was dann auch direkt gesetzt wurde.
War die Lücke effektiv ausnutzbar?
Dazu muss man wohl ein wenig rechnen. Bei einem numerischen 6-stelligen Code gibt es bekanntlich 1 Million mögliche Kombinationen. Wenn wir davon ausgehen, dass pro Sekunde 15 Codes verarbeitet werden können, dann dauert es …
1.000.000 ÷ 15 = 66.667 Sekunden
Quelle: Matheunterricht 🙂
66.667 ÷ 60 = 1.111 Minuten
1.111 ÷ 60 = 18,52 Stunden
Da rein statistisch das Kennwort im Schnitt bei der Hälfte aller möglichen Versuche “erraten” wird, dauert ein Angriff somit im Schnitt etwas über 9 Stunden. Ein Angriff wäre somit nur gezielt gegen einzelne Accounts möglich. Ein massenhaftes Ausnutzen der Lücke würde vermutlich aufgrund der Anfrageflut auffallen.
Das Bug Bounty Programm der Deutschen Telekom
Die Deutsche Telekom bietet ein Bug Bounty Programm für bestimmte Teilbereiche der Dienst-Infrastruktur an. Darunter fallen unter anderem die Domains telekom.de und telekom.com. Der hier beschriebene Bug steckte jedoch hinter der Domain telekom-dienste.de, welche als zentrale “Authentifizierungsstelle” für alle Telekom-Dienste dient. Um so erstaunlicher war für mich die Tatsache, dass diese Domain nicht im Scope des Bug Bounty Programms ist. Natürlich machte es dennoch Sinn, die Schwachstelle im Rahmen des Bug Bounty Programms zu melden, da eine Ausweitung der Scopes nachträglich möglich ist. So entschied ich mich noch folgenden Satz mit auf den Weg zu geben:
Wirklich schade, dass die Domain nicht im Bug Bounty Programm inbegriffen ist, obwohl durch diese banale Lücke, ein Zugriff auf nahezu alle Telekom.de-Dienste möglich ist.
Auszug aus dem Bug-Report
Kontakt mit dem CERT
Das Cyber Emergency Response Team (kurz CERT) ist der Anlaufpunkt für alle Sicherheitsrelevanten Meldungen bei der Telekom. Auch der Bund bietet ein solches CERT an. Nachdem ich meinen Report inklusive dem Proof of Concept an das Telekom-CERT übermittelte, begann das Warten.
Timeline
12.05.2018 – Meldung an das CERT
14.05.2018 – Bestätigung der Lücke seitens dem CERT
16.05.2018 – Ankündigung eines Fix seitens dem Systemmanagers
18.05.2018 – Behebung des Fehlers
Damit war für mich der Fall abgeschlossen. Das Thema Bug Bounty stand nicht mehr im Raum, bis ich am 04.06.2018 eine weitere Mail erhielt.
Fazit
Die Reaktionszeit war gut. Die Programmierung des PoC war aufwendig. Um so mehr freut es mich, dass es nun doch noch ein “Bounty” aka “kleine Anerkennung” gab.