Channel Security

Die in About Security #218, #219 und #220 beschriebenen Schwachstellen erfordern entweder eine weitere Schwachstelle, über die der Angreifer in ein lokales Netz oder einen Server eindringen kann, oder können nur von einem Angreifer ausgenutzt werden, der sich zwischen Webanwendung und Benutzer befindet. Für den Angreifer einfacher auszunutzen sind Schwachstellen, über die er die Zugangsdaten anderer Benutzer direkt abfragen oder ändern kann. Wie zum Beispiel in der Funktion zur Änderung des Passworts.

Funktion zur Passwortänderung überflüssig?

Viele Webanwendungen verzichten auf die Möglichkeit, das Passwort durch den Benutzer ändern zu lassen. Das ist aus zwei Gründen schlecht: Zum einen können die Benutzer ihr Passwort dadurch nicht regelmäßig ändern (was zugegebenermaßen die meisten sowieso nicht machen, obwohl sie es sollten), zum anderen können die Benutzer dadurch ein evtl. kompromittiertes Passwort nicht ändern. Wer einen Zugangsdaten sammelnden Trojaner auf seinem Rechner findet, ist gut beraten, wenn er nach dessen Entfernung alle verwendeten Passwörter ändert. Geht das bei einer Webanwendung nicht, ist das äußerst ungünstig. Und zwar nicht nur für den Benutzer, dessen Account bei der Webanwendung dem Angreifer dadurch offen steht, sondern auch für den Betreiber der Webanwendung, der plötzlich einen Angreifer als Benutzer hat. Logische Schlussfolgerung: Eine Funktion zur Änderung des Passworts durch den Benutzer ist notwendig. Die muss dann aber auch sicher sein.

Unsichere Funktion

Obwohl die Funktion zur Passwortänderung ein wichtiger Teil des Authentifizierungssystems ist, wird sie bei dessen Absicherung oft übersehen. In vielen Webanwendungen ist die Funktion zur Passwortänderung ohne vorherige Authentifizierung zugänglich, oft weil sie gleichzeitig die Funktion zum Zurücksetzen eines vergessenen Passworts enthält. Ist sie ohne Authentifizierung zugänglich, gibt es mehrere mögliche Schwachstellen bzw. Implementierungsfehler:

• Die Fehlermeldung beim Eingeben einer nicht existierenden Benutzername-Passwort-Kombination verrät, ob der Benutzername existiert oder nicht (siehe About Security #215 und #216).
• Während die Vordertür in Form der Authentifizierungsfunktion einen Schutz vor Brute-Force-Angriffen bekommt, fehlt dieser an der Hintertür, der Funktion zur Passwortänderung. Denn darüber kann sich der Angreifer ja nicht anmelden, richtig? Natürlich nicht: Zwar kann er sich darüber nicht anmelden, aber er kann das richtige Passwort über einen Brute-Force-Angriff ermitteln und bei Bedarf danach gleich auf einen ihn passenden Wert ändern und den Benutzer damit aussperren. Daher muss eine ohne Authentifizierung zugängliche Funktion zur Passwortänderung vor Brute-Force-Angriffen geschützt werden.

Schwachstellen finden

Die Funktion (oder die Funktionen, falls es mehrere, z.B. für verschiedene Bereiche der Webanwendung, gibt) zur Passwortänderung wird ähnlich wie die eigentliche Authentifizierungsfunktion geprüft (siehe About Security #214 bis #217): Die Funktion wird ermittelt (evtl. ist sie nicht direkt verlinkt, kann aber über einen URL wie webanwendung/changepass.php o.Ä. direkt aufgerufen werden), für Benutzername und aktuelles Passwort werden verschiedene richtige bzw. falsche Werte eingegeben und die Reaktion der Webanwendung beobachtet. Gibt es unterschiedliche Fehlermeldungen für richtige und falsche Benutzernamen? Ist ein Brute-Force-Angriff möglich?

Passwortänderung nach der Authentifizierung

Ist die Funktion zur Passwortänderung erst nach der Authentifizierung zugänglich, kann sie trotzdem noch eine Schwachstelle enthalten. Da der Benutzername in diesem Fall nicht benötigt wird, wird er meist auch nicht angezeigt. Damit wäre die Funktion für einen Angreifer weitgehend nutzlos: Er erreicht sie erst nach dem erfolgreichen Eindringen in ein Benutzerkonto bzw. nachdem er sich selbst angemeldet hat und kann dann das Passwort für diesen Benutzer ändern.

Allerdings ist es manchmal möglich, doch einen Benutzernamen einzugeben, z.B. in einem versteckten Formularfeld, das den Benutzernamen enthält. Evtl. kann auch ein zusätzlicher Parameter mit dem gleichen Namen wie des Parameters für den Benutzernamen beim Anmelden übergeben werden, um den vorgegebenen Benutzernamen zu überschreiben. Wird das bisherige Passwort nicht abgefragt, kann ein Angreifer dann problemlos das Passwort eines anderen Benutzers ändern, er muss der Webanwendung nur dessen Benutzernamen und das gewünschte Passwort übergeben. Muss auch das bisherige Passwort angegeben werden, können über einen Brute-Force-Angriff die Passwörter anderer Benutzer ermittelt werden, sofern es keinen Schutz vor solchen Angriffen gibt. Was i.d.R. der Fall sein wird – wozu sollte man an dieser Stelle auch einen Brute-Force-Angriff verhindern? Zwar könnte man eine entsprechende Schutzfunktion hinzufügen, einfacher und zielführender (schließlich könnte ein Angreifer zufällig das richtige Passwort treffen, bevor der Brute-Force-Schutz greift) ist es aber, die Änderung des Benutzernamens, für den das Passwort geändert werden soll, zu verhindern.

Zusammenfassung

Ist die Funktion zur Passwortänderung ohne Authentifizierung zugänglich, muss sie vor Brute-Force-Angriffen geschützt werden. Deutlich besser ist es aber, sie erst nach der erfolgreichen Authentifizierung zugänglich zu machen. Dann muss aber darauf geachtet werden, dass wirklich nur das Passwort des authentifizierten Benutzers geändert werden kann. Die Abfrage des bisherigen Passworts bietet zusätzlichen Schutz.

In der nächsten Folge geht es um weitere mögliche Angriffe auf die Authentifizierung, zuerst um die "Vergessenes Passwort"-Funktion.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #214: Schwachstellen-Suche: Authentifizierung - Grundlagen
• About Security #215: Schwachstellen-Suche: Authentifizierung - Brute Force
• About Security #216: Schwachstellen-Suche: Authentifizierung - Namen finden
• About Security #217: Schwachstellen-Suche: Authentifizierung - Ein Angriff
• About Security #218: Schwachstellen-Suche: Authentifizierung - Die Übertragung
• About Security #219: Schwachstellen-Suche: Authentifizierung - Verschlüsselung
• About Security #220: Schwachstellen-Suche: Authentifizierung - Unsichere Kryptographie
• About Security #221: Schwachstellen-Suche: Authentifizierung - Passwort ändern