Skip to content

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

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 auch der Passwort-Reset oder eine unsichere "Recovery"-, "Remember me"- oder "User Impersonation"-Funktion können zur Gefahr werden. Genauso wie eine fehlerhafte Passwortprüfung oder nicht eindeutige Benutzernamen. Die können auch entstehen, wenn es Missverständnisse gibt. Ein weiteres Problem sind

Vorhersagbare Benutzernamen und Passwörter

"Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 14" vollständig lesen

Drucksache: Entwickler Magazin 3.17 - Achtung, privat!?

Im Entwickler Magazin 3.17 ist ein Artikel über einige Vorträge rund um Überwachung auf dem 33c3 erschienen. Eine Leseprobe finden Sie auf entwickler.de!

Jedes Jahr zwischen Weihnachten und Silvester findet der Chaos Communication Congress des CCC statt. 2016 bereits zum 33. Mal, was ihm kurz zum 33c3 machte. Wie üblich gab es jede Menge interessante Vorträge, von denen ich im Artikel eine Auswahl vorgestellt habe.

"Drucksache: Entwickler Magazin 3.17 - Achtung, privat!?" vollständig lesen

Drucksache: Windows Developer 5.17 - Ein Bild? Ein Exploit? Oder beides?

Im windows.developer 5.17 ist ein Artikel über Stegosploit erschienen, eine Methode, um Exploits samt zugehörigen JavaScript-Code in Bildern zu verbergen.

Dass Schwachstellen in Bilder verarbeitenden Code, z.B. im Webbrowser, über entsprechend präparierte Bilder ausgenutzt werden ist Standard. Wie sollte man diesen Code auch sonst erreichen? Nur waren diese Bilder dann auch in irgend einer Form beschädigt, so dass sie i.A. nicht als harmloses Bild dargestellt wurden. Außerdem war der meist zusätzlich benötigte JavaScript-Code zum Vorbereiten des Angriff für Virenscanner und Co. leicht zu erkennen.

"Drucksache: Windows Developer 5.17 - Ein Bild? Ein Exploit? Oder beides?" vollständig lesen