Risiko Passwort-Reset, unverschlüsselte URLs und inkrementelle UserIDs

Sicherheit (Pexels, allgemeine Nutzung)[English]Die Funktion zum Zurücksetzen eines Anmeldekennworts ist ja bei Online-Konten (und ggf. auch lokalen Konten) weit verbreitet. Ein betroffener Anwender kann sich dann ein neues Anmeldekennwort über Formulare generieren und zur erneuten Anmeldung verwenden. Zum Problem wird dies, wenn Anwenderkonten über aufsteigende UserIDs intern verwaltet werden. Ein Sicherheitsforscher hat kürzlich in einem Fall gezeigt, wie er das Kennwort des Chefs (CEO) über diese Funktion zurücksetzen und so dessen Konto übernehmen konnte.


Anzeige

Bei Online-Konten muss ja der Fall abgefangen werden, dass der Benutzer sich nicht mehr anmelden kann, weil er das Kennwort zur Anmeldung vergessen hat. Also wird ein Link zum Zurücksetzen des Kennworts auf der Anmeldeseite implementiert. Der Betroffene oder die Betroffene gibt den Benutzernamen in einem Formular ein und bekommt (ggf. nach einer Sicherheitsfrage) ein Einmalkennwort zur Anmeldung per E-Mail geschickt; oder er kann über einen übermittelten Link das Anmeldekennwort neu setzen. Das kann aber schief gehen, wie nachfolgender Tweet, der auf diesen Artikel verlinkt, zeigt.

Sicherheit beim Passwort Reset

Bei einem Pentest einer Webanwendung für einen Kunden fand Cristi Vlad eine interessante Falle, die eine Kontoübernahme ermöglicht. Die Erkenntnisse hat er aufgeschrieben, um diese mit der Infosec-Community zu teilen.

Bei solchen Pentests, die mit Authentifizierung zu tun haben, testet er alle damit verbundenen Funktionen ausgiebig. Als er dann bei der Funktion "Passwort vergessen" ankam, wollte er den gesamten Ablauf beobachten. Nach Anwahl des betreffenden Links erhielt er eine E-Mail mit einem Link zum Zurücksetzen des Passworts. Das sah so aus:

*ttps://email.mail.redactedexample.com/c/verylongENCRYPTEDstring

Beim Kunden gab es also keine Verifizierung, die den Passwort-Reset nochmals absicherte. Ob interne Sicherheitsmechanismen existierten, um das Zurücksetzen von Kennwörtern von unbefugten Dritten außerhalb der Firma zu unterbinden, geht beim Überfliegen des Beitrags nicht hervor. Ich hatte kürzlich im Blog-Beitrag Windows Domain: Vergessene Kennwörter selbst zurücksetzen die Lösung eines Blog-Lesers vorgestellt. Dort gibt es einige Überlegungen zur Absicherung dieses Reset-Prozesses. 

Interessanter für den Pentester war aber der weitere Verlauf des Reset-Vorgangs. Denn bei Anwahl des Links wurde er zu einer URL mit folgendem Muster umgeleitet und fand dort das Passwort-Zurücksetz-Formular:

*ttps://redactedexample.com/someendpoint/confirm.php?u=551234911&t=<132bitUnknownHashType>&x=2913117


Anzeige

Die Fett hervorgehebenen Parameter in der URL deuten darauf hin, dass da eine UserID zur Identifikation des Kontos verwendet wird. Anhand dieser URL wurde dann im Browser ein Reset-Formular mit folgenden Inhalten angeboten.

Your email is <myemail>
Create new password:
********************
Confirm password:
********************
Submit button

Wer also die URL zum Passwort-Reset-Formular kannte, konnte dieses Kennwort zurücksetzen. Als erstes hat der Pentester dann den Parameter hinter dem X in der URL entfernt, um zu sehen, ob das Kennwort-Reset-Formular noch funktioniert – was es tat. Damit war klar, dass der Parameter u irgendwie der UserID-Wert zur Identifikation des Benutzerkontos war. Er hat  dann diese Wert schlicht um 1 erhöht und geschaut, was passiert. Er bekam prompt die Kennwort-Rücksetzseite des nächsten Benutzerkontos angezeigt, weil die UserIDs aufsteigend vergeben wurden.

Mit diesem Schema konnte er sich sofort über das Passwort-Reset-Funktion am nächsten Konto anmelden. Damit lockte natürlich die Option, das Benutzerkonto des Chefs auf diese Weise zu übernehmen. Der Pentester erhöhte die UserID solange, bis die E-Mail-Adresse des CEO im Formular erschien und konnte auch dessen Passwort zurücksetzen, um dann das Benutzerkonto zu übernehmen.

Das Problem war hier, dass die Entwickler die Parameter einmal nicht verschlüsselt hatten. Zudem waren die BenutzerIDs aufsteigend vergeben worden und es gab keine Sicherungsmechanismen, die Unbefugte davon abhielten, die UserIDs mal schnell auszuprobieren. Ein Angreifer hätte mit wenig Aufwand und Kenntnis der Rücksetz-URL die Konten der kompletten Firma auf einen Rutsch übernehmen können.

Ähnliche Artikel:
Windows Domain: Vergessene Kennwörter selbst zurücksetzen
Windows Admin-Kontenkennwort vergessen: Wie kommt man weiter?
Windows Server 2019: Update KB5011551 blockiert Passwortänderung


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

2 Antworten zu Risiko Passwort-Reset, unverschlüsselte URLs und inkrementelle UserIDs

  1. topas sagt:

    Schon sportlich, dass der Hash überhaupt nicht genutzt zu werden scheint.
    Wenn man keinen adäquaten Zugriff auf die DB hat um entsprechende Tokens zu generieren (Abgleich Hash mit Token in DB, ob für die UID und den Token ein Change vorliegt, inkl Verfallsdauer) doch zumindest 2-3 Daten zu der UID (Mailadresse, AD-Kennung, whatever) als Text verschlüsseln und das als Hash mitsenden, um den Abgleich zu fahren. Eine andere UID erfordert einen komplett neuen Hash (wenn dann statt für uid=1 der Text "ad|mueller7" dann für uid=2 der Text "ad|schneider3" gehasht wird), ein Spielen ander UID bringt also nichts. Fügt man noch einen Timestamp in den Text ein kann man sogar zeitlich abgelaufene Passwortänderungen abfangen. Sind aber 10min Brainstorming un dnochmal soviel Implementierungszeit, wird also überbewertet.

    • Ralph D. Kärner sagt:

      Es fängt doch schon an, dass ich immer wieder erlebe, dass in der freien Wildbahn trotz dicken und mehrfachen Hinweisen darauf, welche Dinge nach der Installation anzupassen sind, immer wieder auf Standars-Salts zur Härtung des Hashes oder gar auch Standard-Zugangsdaten in Bezug auf Adminkonten anzutreffen sind. So lange Du aber die Basics nicht in die Köpfe der Verantwortlichen geprüfgelt kriegst, weil Bequemlichkeit einen höheren Stellenwert als Sicher heit hat, so lange kannst Du nicht erwarten, dass dann auch noch advanced developing betrieben wird in dem Bereich.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.