Skip to content

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.

Carsten Eilers

Trackbacks

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

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

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
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

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #7: Mobile 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 7 angekommen: "Insecure Mobile Interface". Oder auf deutsch: Unsichere Mobile-I