MONTHLY SECURITY SUMMARY Ausgabe Februar 2016

Bildquelle: Wikimedia Commons

FOKUS

DAS INTERNET DER DINGE

Ausgabe 02/2016

Februar 2016: Security is our Business! Das neue Jahr ist hier. Und mit ihm erschaffen wir auch den scip monthly Security Summary neu. Das neue Layout soll erfrischen, neugierig machen, begeistern. Unsere Publikation kommt nun ins Teenager-Alter, denn schliesslich befinden wir uns im 13ten Jahr. Sie halten die 158ste Ausgabe in den Händen! In all diesen Jahren haben wir viel geschrieben. Viel nachgedacht. Und so soll es auch in Zukunft sein. Teenager sind nicht einfach. Und als Eltern mit ihnen umzugehen, ebenso schwer. Unsere Motivation macht es jedoch jeden Monat zu einer wahren Freude, die neueste Ausgabe zusammenzustellen. Falls Sie Möglichkeiten sehen, wie wir unsere Publikation verbessern können— egal ob in Bezug auf Inhalt oder Form—, teilen Sie uns das bitte mit. Der Bereich der Informationssicherheit ist spannend. Und die sich für die Zukunft abzeichnenden Entwicklungen machen das Thema noch viel spannender. Wir bleiben am Ball, denn: Security is our Business! Marc Ruef Head of Research

Bildquelle: https://flic.kr/p/8Nmx6h

scip AG Badenerstrasse 623 8048 Zürich Switzerland +41 44 404 13 13 www.scip.ch

2

Ausgabe 02/2016

NEWS

WAS IST BEI UNS PASSIERT? BEITRAG ZU AUSWEISEN IM DARKNET IN 20 MINUTEN http://www.20min.ch/ Für die Tageszeitung 20 Minuten fasst der Journalist Tobias Bolzern einige der Resultate unserer Analyse zum Darknet zusammen. Darin geht es hauptsächlich um die Verfügbarkeit und Preisstruktur von Schweizer Ausweisdokumenten.

BEITRAG ZU EXPLOIT-HANDEL IN WATSON http://wat.is/-y4mnngCB Unsere jüngste Publikation zum Thema Darknet wurde von verschiedenen Medienvertretern aufgegriffen. Das Online-Magazin watson nimmt sich dem Exploit-Markt an. Im Beitrag stellt er 7 Zahlen und Fakten zum Handel mit Schwachstellen und Angriffstools vor.

GEWINNSPIEL ZUR NEUEN AUSGABE UNSERER BUCHREIHE Auf Facebook und Twitter haben wir ein Gewinnspiel durchgeführt, bei dem es ein Exemplar unseres neuen Buchs zu gewinnen gab. Wir möchten den 10 Gewinnern gratulieren, die in den letzten Tagen das Buch zugeschickt bekommen haben. Viel Spass beim Lesen!

Weitere News zu unserer Firma finden Sie auf unserer Webseite. 3

Ausgabe 02/2016

SCIP BUCHREIHE AUSGABE 7

UNSER AKTUELLES BUCH

Das verflixte siebente Jahr merkt man Labs, der regelmässigen Publikation der scip AG nicht an: Mit der Verlässlichkeit eines Uhrwerkes erscheinen die Artikel der Mitarbeiter aus allen Geschäftsbereichen der scip AG allwöchentlich und erreichen mittlerweile eine Leserschaft, die zu den grössten im deutschsprachigen Bereich gehört. Weniger vorhersehbar sind die Themen, mit denen sich Labs beschäftigt: Der Bereich der Informationssicherheit ist so vielschichtig und schnelllebig, nicht selten finden tagesaktuelle Themen noch binnen Wochenfrist ihren Weg zur Veröffentlichung. Es überrascht daher wenig, dass der dritte Sammelband, Labs 7, eine Selektion mit interessanter Bandbreite zusammenfasst: Von Wearables über Drohnen bis hin zu klassischen Themen wie Datenverschlüsselung oder Compliance . Mit einem Vorwort von Pascal Adam, Chief Information Security Officer der Schweizer Parlamentsdienste und Dozent an der Telematikschule Bern.

Weitere Informationen auf unserer Webseite.

4

SICHERHEIT IST WICHTIG. FÜR UNS ALLE.

Bildquelle: https://flic.kr/p/6BbQvo

Ausgabe 02/2016

STEFAN FRIEDLI

NICHT NUR TERRORISTEN HABEN ETWAS ZU VERSTECKEN

Die Angriffe in Paris im vergangenen November haben ihre Spuren hinterlassen: Nicht nur die Angehörigen der Getöteten und die Überlebenden der tödlichen Angriffe, sondern die ganze westliche Gesellschaft hinterfragt zum wiederholten Mal, wie Extremismus und dem damit verbundenen Terrorismus die Stirn zu bieten ist. Gleichzeitig wird Ursachenforschung betrieben: Wie konnten diese Angriffe geplant und ausgeführt werden? Hätte man sie verhindern können? Und wenn ja, warum wurden die entsprechenden Massnahmen nicht ergriffen?

Nach den Enthüllungen, die Edward Snowdens Dokumente mit sich brachten, beklagte sich der Direktor des amerikanischen CIA, John Brennan jüngst über das Händeringen, das den Auftrag der Geheimdienste in dieser Sache erschwere. ArsTechnica berichtet über einen von der New York Times entfernten Artikel und dessen Annahme, dass Snowdens geleakte Informationen dazu geführt haben, dass Organisationen mit terroristischem Hintergrund ihre eigenen operativen Sicherheitsmassnahmen deutlich erhöht hätten.

Diese Fragen sind wichtig und ihre sorgfältige und sachgemässe Beantwortung umso mehr. Trotzdem dauerte es nur wenige Stunden, bis erste Politiker und andere Interessensvertreter nach mehr Überwachung riefen und verschlüsselte Kommunikationskanäle dafür verantwortlich machten, dass hier einmal mehr sinnlos Blut vergossen wurde. Zahlreiche Experten hatten verschlüsselte Messaging-Systeme bereits als mitschuldig identifiziert, bevor die genutzten Kommunikationskanäle überhaupt ermittelt waren.

Inwiefern dies der Fall ist, lässt sich in Frage stellen. Bereits bei der Jagd auf Osama Bin Laden durch die US-Regierung wurde bekannt, dass dieser vor seinem Tod ausschliesslich auf Kuriere und komplett vom Internet getrennte Computer setzte. Erst die ungefähr 100 USB-Flashdrives, die nach seiner Eliminierung von der amerikanischen Spezialeinheit SEAL Team Six der US Navy gefunden wurden, gaben Einblick in die Kommunikation zwischen Bin Laden und seinen Kontakten, die über den ganzen Erdball verstreut waren.

6

Ausgabe 02/2016

Es mutet daher naiv an, zu glauben, dass andere Organisationen wie auch der Islamische Staat (IS), die sich auch durch ihren routinierten Umgang mit Technologie hervortun, sich vor Snowdens Enthüllungen nicht bewusst gewesen wären, dass Mobiltelefone und unverschlüsselte E-Mails abgehört respektive mitgelesen werden können. Ganz im Gegensatz zu einer breiten Öffentlichkeit, die bis zu eben jenen Enthüllungen nicht wusste, in welcher Breite und Tiefe die Überwachung durch die NSA technisch umgesetzt wurde. Und während kaum einer Einwände gegen die gezielte Überwachung von potenziellen Terroristen hat, so gibt die flächendeckende Überwachung ganzer Bevölkerungen durchaus Anlass zur Diskussion. Sätze wie “Ich habe nichts zu verbergen”, oftmals gekoppelt mit Zusätzen wie “Wenn dafür solche Ereignisse wie Paris verhindert werden können” hört man oft. Und gerade in dieser spezifischen Kombina-

tion ist diese Haltung nachvollziehbar. Doch hinterfragt man den effektiven Nutzen einer flächendeckenden Überwachung und stellt sie den damit verbundenen Risiken eines Missbrauchs gegenüber, wird die Sache kompliziert. In einem Artikel von The Intercept, verfasst von Jenna McLaughlin, wird ein internes, unklassifiziertes Dokument des Department for Homeland Security zitiert, in dem die Verhaftungen von 64 Personen in den USA basierend auf Tatbeständen im Zusammenhang mit dem IS dokumentiert werden. In keinem einzigen Fall existieren Beweise, die darauf hindeuten würden, dass die umfassenden Überwachungsmittel der NSA dazu beigetragen hätten, dass diese Verhaftungen möglich wurden. Vielmehr wurden die entsprechenden Personen durch klassische Kontrollinstanzen, wie Grenzkontrollen oder durch reguläre Verdachtsmomente erhaltene Durchsuchungsbefehle aufgegriffen.

7

Ausgabe 02/2016

„

Nicht die Frage, ob jemand etwas zu verstecken hat, ist relevant – sondern das Recht, etwas nicht der Öffentlichkeit preisgeben zu müssen sollte gewahrt werden.

“

Diese Informationen decken sich in ihrer grundsätzlichen Aussage mit den früheren Daten, die Journalist und Autor Glenn Greenwald in seinem Buch No Place to Hide: Edward Snowden, the NSA, and the U.S. Surveillance State zusammengetragen hat und die ebenfalls darauf hindeuten, dass sämtliche effektiv verhinderten Bedrohungen ausschliesslich durch traditionelle Methoden der Ermittlung eliminiert wurden. Die Bedingung “Wenn dafür solche Ereignisse wie Paris verhindert werden können” ist daher nur sehr bedingt gegeben. Was bleibt, ist das klassische Argument “Ich habe nichts zu verbergen”. Und während diese Aussage im Ermessen des Sprechers korrekt sein mag, ist sie hochgradig kontextabhängig. Kardinal Richelieu, ein französischer Aristokrat, Staatsmann und Kirchenfürst (1585-1642), wird oft wie folgt zitiert:

Gebt mir sechs Zeilen von der Hand des ehrlichsten Mannes, so werde ich etwas finden, um ihn an den Galgen zu bringen. Nicht die Frage, ob jemand etwas zu verstecken hat, ist relevant – sondern das Recht, etwas nicht der Öffentlichkeit preisgeben zu müssen sollte gewahrt werden. Wer fordert, dass niemand ein Recht auf Geheimnisse besitzen darf, öffnet Tür und Tor für die Diskriminierung von Minderheiten und die Verfolgung von unangenehmen politischen oder kulturellen Zeitgenossen. Nicht nur durch den Staat, sondern potentiell auch durch andere Organisationen, die durch Datenleaks, unberechtigte Zugriffe oder korrupte Funktionsträger in den Besitz von kompromittierenden Daten kommen können. Es bleibt die Frage bestehen, welche Wahl eine moderne Gesellschaft in dieser Hinsicht treffen sollte: Sicherheit oder Privatsphäre. Oder wie Kryptograph Bruce Schneier sie umformte: Kontrolle oder Frei-

8

Ausgabe 02/2016

Unser Bedürfnis nach Sicherheit ist durch die jüngsten Angriffe auf unsere Gesellschaft so hoch wie selten zuvor. Doch ist sie das Opfer der Privatsphäre im Hinblick auf die fragwürdige Wirksamkeit der Überwachungsmethoden wert? Diese Diskussion muss noch geführt werden. Aber nicht im Schatten von Angst und Unsicherheit, sondern sachlich und zielorientiert. Denn während die Bedrohung durch Extremisten wie den IS vermutlich schwinden wird, wird diese Entscheidung uns permanent begleiten.

Stefan Friedli [email protected] +41 44 404 13 13

Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. (Benjamin Franklin)

9

Ausgabe 02/2016

VEIT HAILPERIN

VORGEHEN ZUM TESTEN VON IOT DEVICES

Stellen Sie sich ein Sexspielzeug vor, das mit einer Applikation auf Ihrem Smartphone kommuniziert und mechanische Parameter an ein persönliches Profil anpasst. Oder auf Facebook-Likes reagiert. Oder eine Art Playlist von mechanischen Bewegungen abspielt, dazu noch Licht- und Soundeffekte von sich gibt, Aromen versprüht. Oder es könnte gar einen JSON-Stream mit Parametern einer ferngesteuerten Applikation – eines anderen Sexspielzeugs vielleicht? – auf einem anderen Kontinent interpretieren und Sie möchten es testen! Dieses und andere spannende Objekte nennen sich Das Internet der Dinge (engl. Internet of Things, IoT). Die Geräte, welche mit Netzwerken – insbesondere dem Internet – verbunden sind, werden aufgrund ihres Aussehens häufig nicht als Computer betrachtet – aber genau das sind sie. Jüngst ist es Mode geworden, diese Geräte zu testen/hacken, was zur Entdeckung vieler unangenehmer Schwachstellen geführt hat. Wie bereits für Web- und Mobiletests hat das OWASP Projekt auch für IoT Geräte eine Liste der Top Ten Schwachstellen herausgegeben, welche Auditoren bei ihren Analysen helfen sollen. In die-

sem Artikel betrachten wir den Penetration Testing Execution Standard (PTES) im Zusammenhang mit der Untersuchung von IoT-Geräten. Wir geben Anregungen, auf was es zusätzlich zu Achten gilt, wenn man IoT-Geräte testet. Wir werden uns in der Struktur dieses Artikels an der grundlegenden Struktur des PTES orientieren. Normalerweise haben wir ein oder zwei Technologien in einem Test. Dies ist bei IoT-Geräten nicht so. Ganz im Gegenteil, es handelt sich oft um eine ganze Fülle an Technologien und Komponenten, die betrachtet werden müssen. Die meisten Geräte besitzen ein Management Interface, welches durch eine Web Applikation, Mobile Applikation oder sonstiges gesteuert wird. Es verbindet sich zu Netzwerken, manchmal schnurlos und manchmal verkabelt. Schon nur damit haben wir ein breites Themenspektrum, ohne überhaupt die tatsächliche Applikation betrachtet zu haben.

10

Ausgabe 02/2016

„

Im Gegensatz zu manch anderen Projekten handelt es sich bei IoT oft um eine ganze Fülle an Technologien und Komponenten, die betrachtet werden müssen.

“

Testvorbereitung

Informationsbeschaffung

Die Definition der zu prüfenden Bereiche (Scope) ist essentiell, um Zeit effizient einsetzen zu können und Kundenbeziehungen nicht zu ruinieren. Jegliche Einund Ausgabe muss in Betracht gezogen werden. Deswegen muss auch an Folgendes gedacht werden:

Informationssammlung ist die Grundlage eines jeden Tests. Abhängig vom Level der Informationsbeschaffung kann Social Engineering der entwickelnden und produzierenden Firma relevant sein. Fragen, die gestellt werden sollten:



Management Interface



Firmware



Dazugehörige Mobile- und WebApplikationen



Das Gerät (physisch)



Sind alle davon im Scope? Die Aspekte im Scope werden damit ein Grundbestandteil des Gefahrenmodells.



Was für Forschung wurde bereits betrieben, die dieses Gerät betrifft?



Gibt es ähnliche Geräte von dieser Firma?



Gibt es ein Whitepaper zu dem Gerät und/ oder was für Technologien werden verwendet?



Gibt es Informationen auf dem Gerät (z.B. Aufkleber) oder auf den Chips, wenn man es öffnen kann?

11

Ausgabe 02/2016

Gefahrenmodell

Schwachstellenanalyse

Ein Gefahrenmodell ist notwendig. Da so viele Angriffsvektoren existieren, ist es sinnvoll, für jeden sein eigenes Modell zu entwickeln. Je nach Modell wird die Auswirkung eines jeden Findings unterschiedlich bewertet. Vor lauter Freude über Findings sollte trotzdem Folgendes im Hinterkopf behalten werden: Der Vektor “Voraussetzung ist physischer Zugang, dass etwas was auf die Platine gelötet wurde, nachdem man es geöffnet hat, was das Entfernen von besonderen Schrauben und vorsichtiges Erhitzen des Klebers bedarf, damit man Zugriff auf die serielle Schnittstelle erhält” ist in der Realität meist wenig praktikabel.

Für eine vollumfängliche Analyse ist es unter Umständen notwendig, die Firmware zu extrahieren. Die folgenden, zusätzlichen zu den im PTES erwähnten, Eingabemöglichkeiten sollten bedacht werden:

Ein IoT-Toaster sollte nicht als sicher gelten, nur weil sich keine interessanten Daten darauf befinden. Es hat eine CPU, manchmal ist das alles, was ein Angreifer möchte.

1.

Physischer Zugriff (besonders aber nicht limitiert zu Heimautomatisierung):

2.

Ports (USB, Ethernet, ...)

3.

Debugging Schnittstellen (JTag, Serial, ...)

4.

Knöpfe (On-Off, Reset, ...)

5.

Wireless (NFC, Bluetooth, Wi-Fi, ...)

12

Ausgabe 02/2016

Mit der Ausnahme eines Whitebox Tests, bei dem man alle Informationen des Herstellers erhält, sollte auch eine Kommunikationsanalyse durchgeführt werden. 1.

Was für Daten schickt bzw. empfängt das Gerät?

2.

Mit was für Geräten wird kommuniziert?

3.

Wie kann sichergestellt werden, dass keine out-of-band Kommunikation verpasst wird?

4.

Kommuniziert das Gerät direkt oder über einen Pivothost? (Liegt der auch im Scope?)

5.

Wie funktioniert externer Zugriff? (Offener Port, UPnP mit STUN, ...)

6.

Was sind die Authentisierungsmechanismen (für Verwaltung, für WiFi, für Zugriff aus dem Internet)

7.

Verändert das Gerät seinen Zustand? (Bietet es beispielsweise ein drahtloses Netzwerk an und deaktiviert es dieses nach abgeschlossenem Setupprozess?)

13

Ausgabe 02/2016

Exploitation und Post-Exploitation

Zusammenfassung

Exploitation sowie Post-Exploitation sind grundsätzlich gleich wie bei nicht-IoT-Geräten. Die Entwicklung hardwarenaher Exploits muss – wie sonst auch – auf die jeweilige Architektur abgestimmt werden. Bestehende Exploits, die auf x86- oder 64-bit Architektur beruhen, können meist nicht ohne Veränderung übernommen werden.

Alles in allem ist PTES sehr umfassend. Wie wir in diesem Artikel zeigen konnten, ändert sich die Situation nicht massgeblich, wenn PTES auf IoT-Tests angewendet wird. Die grösste Herausforderung bleibt, bei der Erstellung der notwendigen Gefahrenmodelle, alle möglichen Vektoren im Hinterkopf zu behalten.

Ferner werden die IoT-Geräte mit abgespeckten Betriebssystemen betrieben, wie zum Beispiel einer auf Grösse optimierten Linux BusyBox-Umgebung. Diesem Fakt muss beim Erstellen der Post-Exploitation Toolchain Rechnung getragen werden.

Veit Hailperin [email protected] +41 44 404 13 13

14

Ausgabe 02/2016

MICHAEL SCHNEIDER

BELKIN WEMO SWITCH KOMMUNIKATIONSANALYSE

Wir haben in unserem vorangegangenen Beitrag Strategien zur Analyse von Geräten im Internet of Things (IoT) aufgezeigt. In diesem Beitrag setzen wir uns mit der Kommunikationsanalyse eines IoTGeräts und seiner Um-Systeme (Apps, ServerInfrastruktur) auseinander. Wir haben dazu das Produkt Belkin WeMo Switch ausgewählt. In diesem wurden bereits Schwachstellen der Klassen Privilege Escalation (VulDB 12452, Information Disclosure (VulDB 12451 und 12453), Buffer Overflow (VulDB 12454) und Weak Authentication (VulDB 12455) gefunden und durch Belkin behoben. Mit der Kommunikationsanalyse wollen wir untersuchen, ob im Austausch zwischen App, WeMo Switch und der BelkinInfrastruktur weitere Schwachstellen vorliegen, die es ermöglichen, eines oder mehrere Geräte aus der Ferne zu kontrollieren. Der Belkin WeMo Switch ist eine Steckdose, die es zulässt, beliebige angeschlossene elektronische Geräte ein- und auszuschalten. Von überall. Der WeMo Switch wird dazu mit einem vorhandenen WirelessLAN (WLAN) verbunden und über eine App (iOS oder Android) gesteuert. Wenn sich die App und der

Switch im gleichen Netzwerk befinden, kommunizieren diese direkt miteinander, ansonsten wird die Infrastruktur Belkins als Schaltzentrale genutzt. Die direkte Kommunikation basiert auf dem Netzwerkprotokoll Universal Plug and Play (UPnP) und einer einfachen REST-API. Die Remote-Kommunikation findet über HTTP statt, wobei dieselbe REST-API wie bei UPnP eingesetzt wird. WeMo Switch Setup In der Initialisierungsphase erstellt der WeMo Switch als Access Point (AP) ein eigenes WLAN. Die SSID des WLANs wird nach dem Namensschema WeMo.Switch.XXX benannt. Dabei steht XXX für die letzten drei Stellen der Seriennummer. Der Access Point (AP) ist zusätzlich auch DHCP-Server und verwendet IP-Adressen aus dem Bereich10.22.22.0/24. Zur Verwaltung des Geräts wird ein Webserver auf Port tcp/49152 eingesetzt. Die WeMo App nutzt diesen Dienst, um die Zugangsdaten des WLANs an den WeMo Switch zu übermitteln. Dabei werden die Zugangsdaten als XML-Request im folgenden Format versendet:

15

Ausgabe 02/2016

POST /upnp/control/WiFiSetup1 HTTP/1.1 Content-Type: text/xml; charset="utf-8" SOAPACTION: "urn:Belkin:service:WiFiSetup:1#ConnectHomeNetwork" Content-Length: 444 HOST: 10.22.22.1:49152 User-Agent: CyberGarage-HTTP/1.0 WeMoTest WPA2PSK edTQ/hzPJ7MpPeL/qBA5gseNRZWdNdPR5dUu9v8Br40=2d1a TKIP 7

Das Passwort wird dabei in kodierter Form übertragen. Die letzten vier Stellen, im Falle des Beispiels 2d1a, sind Hex-Werte und geben die gesamte Zeichenlänge des Passwort-Strings, der Wert 2d entspricht 45 Zeichen, sowie die tatsächliche Länge des Passworts beispielsweise ergibt der Wert 1a 26 Zeichen. Welche Kodierung für den Passwort-String verwendet wird, konnte im Rahmen der Analyse nicht identifiziert werden. Der WeMo Switch verwendet diese Zugangsdaten, um sich mit dem WLAN zu verbinden und mit den Servern Belkins zu kommunizieren.

Anschliessend wird der Remote-Access eingerichtet. Die App sendet einen Request an den WeMo Switch, dabei wird die App über eine DeviceId eindeutig identifiziert. Unter iOS wird der UniqueDeviceIdentifier (UDID) und auf Android-basierenden Geräte die International Mobile Equipment Identity (IMEI) als DeviceId verwendet.

POST /upnp/control/remoteaccess1 HTTP/1.1 Content-Type: text/xml; charset="utf-8" SOAPACTION: "urn:Belkin:service:remoteaccess:1#RemoteAccess" Content-Length: 603 HOST: 10.22.22.1:49152 User-Agent: CyberGarage-HTTP/1.0 9jiusa7pp00n3uzdbwfv2ulat5yy34x26ou1wgo2 0 TestDevice23

16

Ausgabe 02/2016

Die Antwort des WeMo Switches enthält die HomeId und zwei Schlüssel pluginprivateKey sowie smartprivateKey. Diese Schlüssel werden vermutlich im weiteren Kommunikationsverlauf zur Signierung und Verschlüsselung eingesetzt. Die HomeId besteht aus sieben Zahlen und wird möglicherweise mit der SSID oder der MAC-Adresse des WLAN-Access-Points verknüpft. In unserem Testnetzwerk wurden zwei Geräte unabhängig voneinander im gleichen Netzwerk eingerichtet und beide verwendeten dieselbe HomeId.

HTTP/1.1 200 OK CONTENT-LENGTH: 632 CONTENT-TYPE: text/xml; charset="utf-8" DATE: Fri, 24 Jul 2015 11:12:08 GMT EXT: SERVER: Linux/2.6.21, UPnP/1.0, Portable SDK for UPnP devices/1.6.18 X-User-Agent: redsonic 0000000 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy PLGN_200 Successful S 9jiusa7pp00n3uzdbwfv2ulat5yy34x26ou1wgo2 1

17

Ausgabe 02/2016

Kommunikation zwischen WeMo App und Belkin

Registrierung

Die Kommunikation zwischen der WeMo App und der Infrastruktur Belkins lässt sich in die Bereiche Registrierung, Ein- und Ausschalten sowie Firmware Update aufteilen.

Bei allen Anfragen zur Registrierung verwendet die App einen Basic Access Authentication Header, der nach folgendem Schema aufgebaut wird:

Authorization: SDU 9jiusa7pp00n3uzdbwfv2ulat5yy34x26ou1wgo2:gclbqUYLczNi+cJf+MJ5W/cmCeo=:1440403670@

18

Ausgabe 02/2016

Im Patent US9021139 B1 wird der Aufbau des Headers so beschrieben, dass der SDU String aus DeviceId,Signature und einer Ablaufzeit ExpirationTime zusammengesetzt wird. Das Feld Signature könnte gemäss des Patents wie folgt generiert werden:Signature=Base64(HMAC-SHA1(PrivateKey, StringToSign)). Dabei wird als Schlüssel vermutlich einer der beiden Schlüssel aus der InitialRegistrierung verwendet.

Bei der ersten Anfrage der Schnittstelle api.xbcs.net wird eine Liste der registrierten Geräte unter einer bestimmten HomeId abgefragt. Dabei ist die DeviceId, die zur Authentisierung eingesetzt wird, mit der HomeId verknüpft. In unseren Tests war es nicht möglich, mit einer DeviceId auf fremde HomeId zuzugreifen. Diese Anfragen wurden vom Server mit einer Fehlermeldung geblockt. Bei einem erfolgreichen Aufruf gibt der Server eine Liste der registrierten Geräte pro HomeId zurück.

HTTP/1.1 200 OK asyncServiceInvoke: false Content-Type: application/xml;charset=ISO-8859-1 Date: Mon, 24 Aug 2015 08:05:51 GMT Server: Apache-Coyote/1.1 X-Powered-By: Servlet/3.0; JBossAS-6 Content-Length: 1242 Connection: keep-alive S PLGN_200 Successful Device list retrieved successfully 0000000 this is first plugin initialization 0 1111111 00005E005300 22222222222Z00

19

Ausgabe 02/2016

Die Liste enthält weitere, bisher unbekannte Merkmale eines Geräts, unter anderem die PluginId (wird zum Teil auch als RecipientId verwendet), die macAddress sowie die Firmware-Version des WeMo Switches. Diese Merkmale werden dann für weitere Aktionen, wie das Ein- und Ausschalten des WeMoSwitches, benötigt. Zusätzlich werden auch die SSID des WLANs und die MAC-Adresse des Access-Points bei Belkin gespeichert.

Ein- und Ausschalten Der Befehl zum Ein-/Ausschalten des Geräts wird an den Host api.xbcs.net gesendet. Um diese Nachricht zu senden, ist eine Authentisierung über den Basic Access Authentication Header notwendig. Der WeMo Switch wird dabei über die Felder PluginId respektive die RecipientId und die macAddress angesprochen. Der Status der Geräte wird dabei über die Werte 0 oder 1 gesteuert.

POST /apis/http/plugin/message HTTP/1.1 Host: api.xbcs.net:8443 1111111 00005E005300 1111111 00005E005300 1 (null) (null) ]]>

20

Ausgabe 02/2016

Firmware Update Die WeMo App kann auch dazu genutzt werden, um die Firmware des WeMo Switches zu aktualisieren. Als Antwort auf die initiale Anfrage, die wiederum den Basic Access Authentication Header enthält, erhält die App einen Link zu einer Seite, welche die erhältlichen Firmware-Versionen auflistet. Der Zugriff auf die Firmware erfolgt über eine unverschlüsselte Verbindung, obwohl der Server auch per HTTPS erreichbar wäre.

Das Firmware-Binary selbst ist mittels GPG verschlüsselt und wird auf dem WeMo Switch selbst extrahiert. Die Verwendung von GPG zur Verteilung der Firmware ist grundsätzlich eine gute Idee, nur hat Belkin bei der Implementierung einen folgenschweren Fehler gemacht. Der Security Researcher Mike Davis von IOActive entdeckte 2013, dass Belkin den GPG Signing Key in das WeMo Firmware-Image integrierte. Ein Angreifer konnte diesen Key extrahieren, eine eigene Firmware damit signieren und schlussendlich auf das Gerät einspielen. Im Firmware Update von 24. Januar 2014 hatte Belkin diese Schwachstelle geschlossen.

HTTP/1.1 200 OK asyncServiceInvoke: false Content-Type: application/json;charset=ISO-8859-1 Date: Thu, 10 Sep 2015 12:35:43 GMT Server: Apache-Coyote/1.1 X-Powered-By: Servlet/3.0; JBossAS-6 Content-Length: 133 Connection: keep-alive {"fwUpgradeInfo":{"firmwareId":0,"description":"Default firmware file","fwUpgradeURL":"http:\/\/ fw.xbcs.net\/wemo\/NewFirmware.txt"}}

21

Ausgabe 02/2016

Informationen zur Belkin Infrastruktur Die Belkin Infrastruktur wird in der Amazon EC2 Cloud betrieben. Die Infrastruktur umfasst unter anderem die Systeme ota.xbcs.net, api.xbcs.net oder fw.xbcs.net. Dabei konnte der Einsatz von Red Hat Linux, Apache 2.2.15 sowie JBoss 6 identifiziert werden.

Beim Start des WeMo Switches werden Log-Daten an ein System mit der IP-Adresse 184.73.191.189 übermittelt. Die MAC-Adresse 00005E005300 des WeMo Switches wird hierbei als ID in der POST-Request verwendet. Es ist ferner keine Authentisierung notwendig und es finden keine Kontrollen des Inhalts statt. Dies bedeutet, dass beliebige Inhalte unter beliebigen MAC-Adressen an die Server Belkins übermittelt werden können. Hingegen war es nicht möglich, auf bereits übermittelten und gespeicherten Daten zuzugreifen.

PUT /ToolService/log/uploadWdLogFile/00005E005300 HTTP/1.1 Host: 184.73.191.189:8899 Content-Type: multipart/octet-stream Accept: application/xml Content-Length: 301 Expect: 100-continue [2015-08-07][08:33:35]|RT|Internet is connected [2015-08-07][08:33:39]|PLUGINREMOTEREGISTER|Plugin App Remote ReRegister [2015-08-07][08:33:37]|SIG|Connection signal strength: 55 [2015-08-07][08:33:40]|Plugin App Remote ReRegister failure| [2015-08-07][08:33:40]|Plugin App Remote ReRegister failure| HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: application/xml Content-Length: 67 Date: Fri, 07 Aug 2015 06:33:58 GMT

22

Ausgabe 02/2016

Als der WeMo Switch veröffentlicht wurde, ging es nicht lange und es wurden mehrere Schwachstellen gefunden. Im Bereich der Kommunikation zwischen App, WeMo Switch und der Server-Infrastruktur hat Belkin nun aus diesen Erfahrungen gelernt und die Remote-Kommunikation soweit gesichert, so dass Geräte ohne eine erfolgreiche Authentisierung nicht ferngesteuert werden können. Zudem werden die Geräte und Heimnetzwerke miteinander verknüpft und es ist nicht ohne weiteres möglich, andere Heimnetzwerke und deren Geräte durch Ausprobieren oder Durchnummerieren zu finden. Dadurch ist es für einen Angreifer nicht so leicht, Angriffe aus der Ferne auszuführen. Es bleibt zu hoffen, dass auch andere IoT-Hersteller aus diesen Erfahrungen ihre Lehren ziehen und die Produkte von Beginn an mit entsprechenden Sicherheitsfunktionen versehen.

Michael Schneider [email protected] +41 44 404 13 13

23

AUS DER VERGANGENHEIT LERNEN.

FÜR DIE ZUKUNFT.

Bildquelle: https://flic.kr/p/6B7F1a

Ausgabe 02/2016

VULNERABILITY SUMMARY

TOP SCHWACHSTELLEN DES AKTUELLEN MONATS

1 2 3 4

GOOGLE ANDROID MEDIASERVER PUFFERÜBERLAUF http://www.scip.ch/?vuldb.80768 Eine sehr kritische Schwachstelle wurde in Google Android 5.0/5.1.1/6.0/6.0.1 entdeckt. Betroffen davon ist eine unbekannte Funktion der Komponente Mediaserver. Ein Upgrade vermag dieses Problem zu beheben. Das Erscheinen einer Gegenmassnahme geschah sofort nach der Veröffentlichung der Schwachstelle. Google hat hiermit unmittelbar reagiert.

CISCO ASA IKEV1/IKEV2 IKEV2_ADD_RCV_FRAG() PUFFERÜBERLAUF http://www.scip.ch/?vuldb.80921 Eine Schwachstelle wurde in Cisco ASA bis 9.5 entdeckt. Sie wurde als sehr kritisch eingestuft. Es geht hierbei um die Funktion ikev2_add_rcv_frag() der Komponente IKEv1/IKEv2. Ein Aktualisieren auf die Version 8.4(7.30), 8.7(1.18), 9.0(4.38), 9.1(7), 9.2(4.5), 9.3(3.7), 9.4(2.4) oder 9.5(2.2) vermag dieses Problem zu lösen. Das Erscheinen einer Gegenmassnahme geschah sofort nach der Veröffentlichung der Schwachstelle. Cisco hat so unmittelbar gehandelt.

ORACLE JAVA SE AWT UNBEKANNTE SCHWACHSTELLE http://www.scip.ch/?vuldb.80546 Eine Schwachstelle wurde in Oracle Java SE 6u105/7u91/8u66 gefunden. Sie wurde als sehr kritisch eingestuft. Es geht hierbei um eine unbekannte Funktion der Komponente AWT. Ein Upgrade vermag dieses Problem zu beheben. Das Erscheinen einer Gegenmassnahme geschah sofort nach der Veröffentlichung der Schwachstelle. Oracle hat entsprechend unmittelbar reagiert.

GNU GLIBC RES_SEND.C SEND_VC PUFFERÜBERLAUF http://www.scip.ch/?vuldb.80983 In GNU glibc – die betroffene Version ist nicht bekannt – wurde eine kritische Schwachstelle entdeckt. Dabei geht es um die Funktion send_dg/send_vc der Datei resolv/res_send.c. Die Schwachstelle lässt sich durch das Einspielen des Patches 8479f23a lösen. Die Schwachstelle kann zusätzlich durch das Filtern von UDP DNS Packet Length > 512 Bytes / TCP Reply Length > 1024 Bytes mittels Firewalling mitigiert werden. Als bestmögliche Massnahme wird das Installieren des jeweiligen Patches empfohlen. GNU hat damit gehandelt.

25

Ausgabe 02/2016

VULNERABILITY LANDSCAPE

AKTUELLE STATISTIKEN AUS UNSERER VULDB MEISTBETROFFENE PRODUKTE IM VERGANGENEN MONAT

VERLAUF DER SCHWACHSTELLEN DER VERGANGENEN 12 MONATE 100% 90%

80% 70% 60% 50%

40% 30% 20%

10% 0%

2015-2

2015-3

2015-4

2015-5

2015-6

2015-7

2015-8

2015-9

2015-10

2015-11

2015-12

2016-1

sehr kritisch

14

7

10

0

0

1

0

0

1

1

1

4

2016-2 3

kritisch

219

241

292

219

258

287

359

354

394

174

416

311

133

problematisch

259

284

279

210

331

336

301

290

433

180

226

444

132

Datenquelle: http://www.scip.ch/?vuldb

26

Ausgabe 02/2016

S C I P M O N T H LY S E C U R I T Y S U M M A R Y

IMPRESSUM ÜBER DEN SCIP MONTHLY SECURITY SUMMARY Das scip Monthly Security Summary erscheint monatlich und ist kostenlos. Anmeldung: [email protected] Abmeldung: [email protected] Verantwortlich für diese Ausgabe: Stefan Friedli / Marc Ruef

Eine Haftung für die Richtigkeit der Veröffentlichungen kann trotz sorgfältiger Prüfung durch die Redaktion des Herausgebers, den Redaktoren und Autoren nicht übernommen werden. Die geltenden gesetzlichen und postalischen Bestimmungen bei Erwerb, Errichtung und Inbetriebnahme von elektronischen Geräten sowie Sende und Empfangseinrichtungen sind zu beachten.

ÜBER DIE SCIP AG

Wir überzeugen durch unsere Leistungen. Die scip AG wurde im Jahr 2002 gegründet. Innovation, Nachhaltigkeit, Transparenz und Freude am Themengebiet sind unsere treibenden Faktoren. Dank der vollständigen Eigenfinanzierung sehen wir uns in der sehr komfortablen Lage, vollumfänglich herstellerunabhängig und neutral agieren zu können und setzen dies auch gewissenhaft um. Durch die Fokussierung auf den Bereich Information Security und die stetige Weiterbildung vermögen unsere Mitarbeiter mit hochspezialisiertem Expertenwissen aufzuwarten.

Weder Unternehmen noch Redaktion erwähnen Namen von Personen und Firmen sowie Marken von Produkten zu Werbezwecken. Werbung wird explizit als solche gekennzeichnet. scip AG Badenerstrasse 623 8048 Zürich Switzerland +41 44 404 13 13 www.scip.ch

27