Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 5
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. Dazu habe ich noch einen Punkt hinzuzufügen:
Unsichere Verwendung von HTTPS
Eigentlich ist HTTPS bzw. das davon verwendete TLS weitgehend sicher. Ein Problem sind aber die Zertifikate, mit denen der Server bzw. in diesem Fall das IoT-Gerät sich ausweist und über die der Client deren Identität prüfen kann. Dazu habe ich ja schon des öfteren etwas geschrieben: Es gibt viel zu viele diese Zertifikate ausstellenden Zertifizierungsstellen (Certification Authority, CA), die mit ihrer Signatur bestätigen, dass der im Zertifikat präsentierte öffentliche Schlüssel zum angegebenen Server gehört. Und die Browser bzw. Betriebssysteme vertrauen viel zu vielen dieser Zertifizierungsstellen. Manche sind aber nicht besonders vertrauenswürdig, andere wurden bereits gehackt oder haben freiwillig falsche Zertifikate ausgestellt. Zumindest den "schwarzen Schafen" unter den Zertifizierungsstellen sollte man eigentlich nicht vertrauen.
Aber das sind in diesem Fall nicht mal die größten Probleme. Viel gefährlicher sind selbst erstellte Zertifikate, in denen die Server bzw. IoT-Geräte sich quasi selbst bestätigen, dass das ihr Schlüssel ist.
Die Webbrowser prüfen bei jedem Zertifikat, ob es von einer vertrauenswürdigen Zertifizierungsstelle unterzeichnet wurde. Dazu verwenden sie eine Liste mit den sog. Root-Zertifikaten der für vertrauenswürdig erachteten Zertifizierungsstellen. Lässt sich die Signatur unter einem Zertifikat mit einem dieser Root-Zertifikate überprüfen, wird dem Zertifikat vertraut.
Liegt dem Webbrowser das Root-Zertifikat der verwendeten Zertifizierungsstelle nicht vor, fragt er beim Benutzer nach, ob der dem präsentierten Zertifikat vertrauen möchte oder nicht. Der Benutzer kann dann entscheiden, ob er diesem bestimmten Server-Zertifikat vertraut oder nicht und sich ggf. auch das fehlende Root-Zertifikat besorgen und im Webbrowser importieren.
Außer von Zertifizierungsstellen ausgestellten Zertifikaten können wir schon erwähnt auch selbst-signierte Zertifikate (self-signed certificate), die unabhängig von einer Zertifizierungsstelle erstellt wurden, verwendet werden. Diese müssen ebenfalls manuell bestätigt werden. Eine Authentifizierung ist damit nicht möglich, ein solches Zertifikat ist genau so aussagekräftig wie ein selbst ausgestellter Personalausweis, aber die übertragenen Daten können danach mit dem im Zertifikat enthaltenen Schlüssel verschlüsselt werden.
Werden selbst signierte oder von einer dem Webbrowser unbekannten Zertifizierungsstelle ausgestellte Zertifikate verwendet, ist die Gefahr eines MitM-Angriffs besonders hoch. Der Benutzer weiß ja, dass die Zertifikatsprüfung fehl schlägt und er dem Zertifikat manuell das Vertrauen aussprechen muss. Der MitM kann dem Benutzer also relativ problemlos sein eigenes, gefälschtes Zertifikat unterschieben und muss sich keines einer vertrauenswürdigen Zertifizierungsstelle besorgen.
Da der Benutzer weiß, das er das Zertifikat bestätigen muss und das wahrscheinlich auch bereits in der Vergangenheit getan hat, wird er bei der entsprechenden Meldung des Webbrowsers weniger misstrauisch sein. Die prinzipiell sichere Verschlüsselung wird also nicht gebrochen, sondern quasi unterbrochen: Der Angreifer nutzt die unsichere Verwendung von HTTPS, um sich zwischen Client und Server zu drängeln und dort die Daten zu belauschen.
Verschärft wird dieses Problem durch die erweiterten Warnungen in neuen Webbrowsern: Wenn die grossflächig vor einem unsicheren Zertifikat warnen und einen Abbruch der Verbindung empfehlen, ist es kontraproduktiv, dem Benutzer vorher zu sagen, das er diese Warnung in diesem Fall ignorieren soll, da sie selbst verursacht wurde. Ob das wirklich der Fall ist oder ob ein tatsächlich gefälschtes Zertifikat vorgezeigt wurde, kann der normale Benutzer meist nicht beurteilen.
In der nächsten Folge geht es um weitere Schwachstellen in und Angriffe auf die Authentifizierung.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 6
Vorschau anzeigen
www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.www.ceilers-news.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 18
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #6: Unsichere Cloud-Interfaces
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #7: Mobile Cloud-Interfaces
Vorschau anzeigen