Skip to content

Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 7

Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization".

Die verschiedenen Möglichkeiten zur Authentifizierung habe ich bereits beschrieben. Ebenso erste Angriffe: Default-Zugangsdaten und schlechte (= unsichere) Passwörter sowie Brute-Force- und Wörterbuch-Angriffe, die durch verräterische Fehlermeldungen erleichtert werden können. Ein weiteres Problem sind ungeschützt übertragene Zugangsdaten und die unsichere Verwendung von HTTPS. Aber auch Funktionen rund um die Passwortverwaltung können zu einer Schwachstelle werden, z.B. unsicher gespeicherte Passwörter. Auch nicht ungefährlich ist die

Funktion zur Passwortänderung

Und das gilt, wenn auch in geringeren Maßen, auch für die Weboberflächen des IoT. Wobei das erste Problem bei der Passwortänderung oft darin besteht, dass es für den normalen Benutzer gar keine Möglichkeit gibt, um sein Passwort zu ändern.

Das ist bei Webanwendungen 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, und wie nützlich das ist, darüber lässt sich auch streiten), zum anderen können die Benutzer dadurch ein evtl. oder bekannt kompromittiertes Passwort nicht ändern. Wer einen Zugangsdaten sammelnden Trojaner auf seinen 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.

Bei den Weboberflächen für das IoT ist dies Problem nicht ganz so schlimm, denn da sind die Benutzer ja i.A. auch gleichzeitig Administratoren, und zumindest die werden ja hoffentlich eine Möglichkeit besitzen, ein Passwort zu ändern.

Aber auch wenn es für den Benutzer eine Möglichkeit gibt, sein Passwort zu ändern, ist noch nicht alles eitel Sonnenschein. Denn oft sind diese Funktionen unsicher.

Unsichere Funktion zur Passwortänderung

Denn bei der Absicherung dieses wichtigen Teils des Authentifizierungssystems wird oft geschlampt. Oft ist die Funktion zur Passwortänderung ohne vorherige Authentifizierung zugänglich, weil sie gleichzeitig die Funktion zum Zurücksetzen eines vergessenen Passworts enthält. Auf den ersten Blick scheint das kein Problem zu sein, denn bei der Änderung des Passworts muss ja auch das alte Passwort eingegeben werden, woran ein Angreifer regelmäßig scheitern wird.

Kein Schutz vor Brute-Force-Angriffen

Das gilt aber nur, wenn die Funktion zur Passwortänderung über einen Schutz vor Brute-Force-Angriffen verfügt. Auf den oft verzichtet wird, denn darüber kann sich der Angreifer ja nicht anmelden. Aber er kann das richtige Passwort über einen Brute-Force-Angriff ermitteln und dadurch die Funktion zur Passwortänderung nutzen. Ob er dann das ermittelte Passwort erneut setzt und dadurch seinen erfolgreichen Zugriff auf die Anwendung verbirgt, oder ob er ein neues, eigenen Passwort setzt und dadurch den Benutzer aussperrt liegt allein in seinem Ermessen.

Daher muss eine ohne Authentifizierung zugängliche Funktion zur Passwortänderung vor Brute-Force-Angriffen geschützt werden.

Verräterische Fehlermeldung

Ein weiteres Problem ist oft die Fehlermeldung beim Eingeben einer nicht existierenden Benutzername-Passwort-Kombination, die verrät, ob der Benutzername existiert oder nicht.

Missbrauch der Funktion für andere Benutzerkonten

Ist die Funktion zur Passwortänderung erst nach der Authentifizierung zugänglich, kann sie trotzdem noch eine Schwachstelle enthalten. Da die Funktion in diesem Fall nur vom jeweils authentifizierten Benutzer aufgerufen werden kann, wird der Benutzername nicht als Parameter benötigt. Dadurch ist die Funktion für einen Angreifer nahezu nutzlos: Er erreicht sie erst nach dem erfolgreichen Eindringen in ein Benutzerkonto bzw. nachdem er sich bei einer Anwendung, bei der er sich selbst ein Konto anlegen kann, selbst angemeldet hat. Und er kann dann das Passwort nur 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 der Parameter für den Benutzernamen beim Anmelden übergeben werden, um den vorgegebenen Benutzernamen zu überschreiben.

Und das ist eine gewaltige Schwachstelle. Wird das bisherige Passwort nicht abgefragt, kann ein Angreifer 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. Denn wie schon geschrieben: Eigentlich darf nur das des aktuellen Benutzers geändert werden, nur dafür ist die Funktion vorgesehen.

In der nächsten Folge geht es um weitere mögliche Angriffe auf und über die Authentifizierung.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 8

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 9

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 10

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 11

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 12

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 13

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 14

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 15

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 16

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 17

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 18

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: "Insufficient Authentication/Authorization". Die ve

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #6: Unsichere Cloud-Interfaces

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 6 angekommen: "Insecure Cloud Interface". Oder auf deutsch: Unsichere Cloud-Int

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Toirasi Saduj am :

Hallo

Bin sehr froh ihre Seite gefunden zu haben. Selten auf diesem Gebiet etwas derart eingänglicheres zu lesen bekommen. verwende sie in meinen Schulungen und verlinke sie sooft es Sinn macht.

Ich bin selbst an einem neuen Authentifizierungsverfahren zugange das nach einer Art von Reißverschlussverfahren funktioniert, eine dritte Instanz als Kontrolle mit einbezieht und den Nutzer bei der Authentifizierung gänzlich außen vor lässt. Mich würde ihre Meinung dazu interessieren. Wenn sie denn daran interesse hätten.

So aber zumindest einigen Dank an sie

mfg

r. lienhard

p.s. für den Fall das die Mailadresse wirklich nicht angegeben wurde oder auch sonst nicht zugänglich...
[E-Mail gelöscht]

Carsten Eilers am :

Hallo,

erst mal bitte ich um Entschuldigung für die verspätete Freischaltung des Kommentars und die Antwort. Ich habe im Moment ziemlich viel zu tun, so dass das Blog quasi auf "Autopilot" fährt. Und man kann zwar Artikel automatisch online stellen, aber keine Kommentare moderieren. Das muss daher immer etwas warten, bis ich Zeit dafür habe.

QUOTE:
Bin sehr froh ihre Seite gefunden zu haben. Selten auf diesem Gebiet etwas derart eingänglicheres zu lesen bekommen. verwende sie in meinen Schulungen und verlinke sie sooft es Sinn macht.


Danke.

QUOTE:
Ich bin selbst an einem neuen Authentifizierungsverfahren zugange das nach einer Art von Reißverschlussverfahren funktioniert, eine dritte Instanz als Kontrolle mit einbezieht und den Nutzer bei der Authentifizierung gänzlich außen vor lässt. Mich würde ihre Meinung dazu interessieren. Wenn sie denn daran interesse hätten.


Durchaus. Zur Zeit habe ich kaum Zeit dafür, aber wenn es einige Monate Zeit hat würde ich mir das gerne mal ansehen. Meine Adresse steht unter jedem Artikel.

QUOTE:
p.s. für den Fall das die Mailadresse wirklich nicht angegeben wurde oder auch sonst nicht zugänglich...


s9y selbst speichert die Adresse, zeigt sie aber in Kommentaren nicht an. Im Backend kann man sie aber sehen.

Viele Grüße
Carsten Eilers

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!