Sicherheitswoche 33: Türen ohne Schlösser, Immunität für Microsoft, Reverse-Engineering und Schmerz

In diesem Rückblick finden sich zwei Themen, die augenscheinlich nichts miteinander zu tun haben, aber dennoch etwas gemeinsam haben: nämlich, dass Sicherheitslücken manchmal vom Widerwillen kommen, Sicherheitsmaßnahmen zu ergreifen.

Willkommen zu unserem Wochenrückblick. Beim letzten Mal ging es um gehackte Autos, Android Stagefright und um die Privatsphäre im Internet. Diesmal haben wir unter anderem zwei Themen, die augenscheinlich nichts miteinander zu tun haben, aber dennoch etwas gemeinsam haben: nicht, dass es irgendwo Sicherheitslücken gibt, sondern dass Sicherheitslücken manchmal vom Widerwillen kommen, Sicherheitsmaßnahmen zu ergreifen. Und das dritte Thema hat gar nichts mit Sicherheit zu tun, sondern mit Beziehungen innerhalb der Branche.

Hier noch einmal die Regeln für den Wochenrückblick: Die Redakteure von Threatpost wählen die drei wichtigsten Meldungen aus, die ich dann ausführlich und schonungslos kommentiere. Alle Wochenrückblicke finden Sie hier.

Das Hacken von Hoteltüren

Der Threatpost-Artikel.

Man sagt, es gäbe einen Gegensatz zwischen Naturwissenschaft und Geisteswissenschaft, und die Adepten der beiden Disziplinen können sich kaum gegenseitig verstehen. Und es gibt die Ansicht, dass ein Geisteswissenschaftler nie zu einem Naturwissenschaftler oder Ingenieur werden kann.

Das wurde von John Wiegand, einem ausgebildeten Musiker, widerlegt. In den 1930er Jahren war er Pianist und dirigierte einen Kinderchor – bis er sich für das Design von Audioverstärkern interessierte. In den 1940er Jahren arbeitete er an einer Neuheit dieser Zeit: der Tonbandaufnahme. Und im Jahr 1974 machte er (im Alter von 62 Jahren) seine größte Entdeckung: Den Wiegand-Sensor.

Der Wiegand-Sensor ist ein magnetisches Kabel aus einer Kobalt-Eisen/Vanadium-Legierung, das so behandelt wird, dass es eine harte äußere Schale um einen weichen Kern bildet. Externe Magnetfelder magnetisieren die äußere Schale leicht und diese widersteht auch der Entmagnetisierung, selbst wenn die externen Felder abgeschaltet werden – das nennt man höhere Koerzitivkraft. Das weiche, innere Kabel verhält sich anders: Es wird erst dann magnetisiert, wenn die äußere Hülle voll magnetisiert worden ist.

Genau zu dem Zeitpunkt, wenn die Schale des Kabels voll magnetisiert ist und der Kern beginnen kann, sich zu magnetisieren, wird die Polarität der beiden Kabelteile vertauscht. Das erzeugt einen ziemlichen Strom, der für alle möglichen Arten von Sensoren und Bewegungsregistrierungen verwendet werden. Genutzt wird das zum Beispiel in Hotelzimmerschlüsseln.

Anders als in modernen Schlüssel- oder Geldkarten, sind die Nullen und Einsen nicht auf einem Chip gespeichert, sondern in der direkten Sequenz einer speziellen Verkabelung. Es ist dadurch unmöglich, so einen Schlüssel umzuprogrammieren und deren generelle Anwendung läuft nicht wie bei modernen, berührungslosen Bahnkarten oder Zahlungskarten, sondern ähnlich den älteren Magnetkarten – nur zuverlässiger.

Sollten wir berührungslose Karten also gleich wieder abschaffen? Noch nicht. Wiegand hat seinen Namen nicht nur dem entdeckten Effekt gegeben, sondern auch dem Datenaustauschprotokoll, das bereits recht alt ist. An diesem Protokoll ist so ziemlich alles recht schlecht. Zum einen wurde es nie richtig standardisiert, so dass es viele verschiedene Implementationen davon gibt.

Zum anderen kann die originale Karten-ID nur bis zu 16 Bit enthalten, was sehr wenige Kombinationen ermöglicht. Und drittens beschränken diese berührungslosen Karten mit Verkabelung – die entwickelt wurden, bevor wir gelernt haben, einen ganzen Computer in eine Kreditkarte zu packen – die Schlüssellänge auf nur 37 Bit und die Zuverlässigkeit beim Auslesen wird bei längeren Schlüsseln immer schlechter.

Und nun zeigten die Sicherheitsforscher Eric Evenchick und Mark Baseggio auf der Black-Hat-Konferenz ihr Gerät zum Abfangen (unverschlüsselter) Schlüsselsequenzen während der Autorisierung. Das Interessanteste dabei ist, dass die Karten damit gar nichts zu tun haben, da die Informationen bei der Übertragung vom Kartenleser zum Tür-Controller gestohlen werden – und dabei wird schon immer das Wiegand-Protokoll verwendet.

Der Name des Geräts lautet BLEkey – ein kleines Stück Hardware, das in einen Kartenleser eingebaut werden muss, zum Beispiel an einer Hotelzimmertür. Die Forscher zeigten, dass die ganze Operation nur einige Sekunden dauert. Und dann geht alles ganz einfach: Man liest den Schlüssel aus, wartet, bis der Gast das Zimmer verlässt, und kann dann selbst die Tür öffnen. Oder man wartet gar nicht so lange. Oder man öffnet die Tür nie. Wie auch immer, der Dialog zwischen der Tür und dem Kartenleser/Drahtlosgerät läuft etwa so (ohne dabei in technische Details gehen zu wollen):

„Wer ist da?“

„Ich bin’s.“

„Ah, Du bist da. Komm rein!“

Das scheint alles glasklar zu sein, aber es gibt da noch eine Kleinigkeit. Wie immer sind nicht alle Zugangskontrollsysteme für diesen Angriff anfällig. Und selbst die anfälligen können geschützt werden, ohne dass man sie komplett ersetzen muss. Laut den Forschern sind die Kartenleser mit Schutzmaßnahmen vor solchen Hacks ausgestattet, allerdings sind diese Funktionen meist… nun ja… ausgeschaltet.

Manche Geräte unterstützen sogar das Open-Supervised-Device-Protokoll, das es ermöglicht, die Schlüsselsequenz verschlüsselt zu übertragen. Doch diese „Funktionen“ werden nicht verwendet. Und zwar – ich werde nicht müde, das zu sagen –, weil es günstiger und einfacher ist, Sicherheitsmaßnahmen zu ignorieren.

Es gibt noch eine weitere interessante Studie dazu aus dem Jahr 2009, inklusive technischer Details. Offensichtlich wurde die Sicherheitslücke der Karten (nicht der Kartenleser) schon im Jahr 1992 aufgezeigt, aber damals wurde vorgeschlagen, die Karten entweder zu zerlegen oder zu röntgen. Dazu musste man sie erst einmal in die Hände bekommen. Doch nun ist der Hack mit einem kleinen Gerät von der Größe einer Münze möglich. Das nenne ich Fortschritt!

Immunität für Microsoft. Die Feinheiten des Windows Server Update Service.

Der Threatpost-Artikel. Das eigentliche Whitepaper der Forscher.

Der Windows Server Update Service (WSUS) erlaubt es großen Firmen, die Updates für Computer über einen internen Server zu zentralisieren, statt eine Quelle außerhalb des Firmennetzwerks zu verwenden. Und das ist ein sehr zuverlässiges und ausreichend sicheres System. Zunächst müssen alle Updates von Microsoft signiert sein, und dann wird die Kommunikation zwischen dem Firmen-Update-Server und dem Server des Herstellers per SSL verschlüsselt.

Das ist ein recht einfaches System. Die Firmenserver erhalten eine Liste von Updates als XML-Datei, in der steht, was, wo und wie herunterzuladen ist. Doch diese erste Interaktion passiert im Klartext. Nein, das ist nicht ganz richtig: Sie muss verschlüsselt sein und wenn so ein WSUS eingeführt wird, wird dem Administrator sehr empfohlen, die Verschlüsselung einzuschalten. Standardmäßig ist sie aber ausgeschaltet.

Das ist nicht so wahnsinnig schlimm, denn es ist nicht einfach, die „Anweisungen“ zu ersetzen. Doch wenn ein Angreifer bereits die Möglichkeit hat, den Datenverkehr abzufangen (also bereits eine Man-in-the-Middle-Attacke läuft), ist auch das möglich. Die Forscher Paul Stone und Alex Chapman haben herausgefunden, dass man durch das Ersetzen der Anweisungen beliebigen Code mit hohen Privilegien auf dem aktualisierten System ausführen kann. Nein, Microsoft prüft natürlich immer noch die digitalen Zertifikate, aber dabei werden die Zertifikate jeder Firma akzeptiert. So kann man zum Beispiel das PsExec-Utility vom SysInternals-Kit schmuggeln und mit dessen Hilfe dann alles starten.

Warum ist das möglich? Der springende Punkt ist, dass das Einschalten von SSL beim Einrichten des WSUS nicht automatisiert werden kann, da man dafür ein Zertifikat generieren muss. Wie die Forscher anmerken, kann Microsoft in diesem Fall nichts anders tun, als das Einschalten von SSL zu empfehlen. Es sieht also so aus, als gäbe es da eine Sicherheitslücke und gleichzeitig auch nicht. Und man kann nichts dagegen machen. Und niemand hat Schuld, außer dem Administrator.

Kaspersky Lab entdeckte zudem die Spyware Flame, die ebenfalls Windows Update für die Infizierung nutzt, allerdings auf eine andere Art: Sie schickt einen abgefangenen und gefälschten Proxy-Request an die Microsoft-Server und die gelieferten Antwort-Dateien sind dann ein bisschen verändert, obwohl manche davon wirklich vom Hersteller signiert sind.

Reverse-Engineering und Schmerz

Der Threatpost-Srtikel. Der Original-Post von Oracle (Google Cache und eine weitere Kopie — das Internet vergisst nie).

Die beiden oben zitierten Präsentationen von der Black-Hack-Konferenz hängen zusammen, da die Autoren der Studien – Sicherheits-Experten – Fehler in Technologien oder Produkten entdeckt haben, die von jemand anderem entwickelt worden waren. Sie haben ihre Erkenntnisse veröffentlicht und im Fall von BLEKey auch den gesamten Code und die Hardware vorgestellt. Das ist die Standardvorgehensweise der IT-Sicherheitsbranche, aber nicht jedem gefällt das.

Ich will das nicht bewerten, also reicht es wohl, wenn ich sage, dass das ein sehr kontroverses Thema ist. Ist es in Ordnung, den Code anderer zu analysieren und unter welchen Bedingungen ist das richtig? Wie soll man Informationen zu Sicherheitslücken veröffentlichen, ohne Schaden anzurichten? Werde ich vielleicht für die gefundenen Fehler sogar bezahlt? Rechtliche Beschränkungen, krimineller Kodex und ungeschriebene Gesetze der Branche – sie alle beeinflussen das.

Ein Post von Mary Ann Davidson, Chief Security Officer bei Oracle, hat kürzlich einen ziemlichen Wirbel ausgelöst. Der Titel des Artikels lautete „Nein, Du darfst wirklich nicht“ und er wandte sich fast ausschließlich an die Kunden des Unternehmens (nicht an die Branche insgesamt), die Informationen über Sicherheitslücken eingesandt haben, die sie in den Produkten des Herstellers gefunden hatten.

Eigentlich wäre es wert, den ganzen Text des Artikels vom 10. August zu zitieren, aber hier die Hauptsache: Wenn ein Kunde eine Sicherheitslücke nur durch Reverse Engineering entdecken könne, verletze er damit die Lizenzvereinbarung, und das sei nicht rechtmäßig.

Zitat:

Ein Kunde darf den Code nicht analysieren, um zu prüfen, ob es eine Kontrolle gibt, die einen Angriff verhindert, den das Scanning-Tool meldet (wahrscheinlich ein False Positive). Ein Kunde darf keinen Patch für das Problem erstellen – nur der Hersteller darf das. Ein Kunde verletzt ganz sicher die Lizenzvereinbarung, wenn er ein Tool verwendet, das eine statische Analyse durchführt (die gegen den Quellcode läuft).

Die öffentliche Reaktion war so:

Und so:

Und sogar so:

Kurz, der Beitrag wurde nach einem Tag wieder gelöscht, und zwar aufgrund von „Unstimmigkeiten in Bezug auf die [offiziellen] Ansichten zur Interaktion mit Kunden“ (aber das Web vergisst nicht). Denken Sie daran, dass Oracle auch Java entwickelt und nur die Faulsten keine Java-Sicherheitslücken ausnutzen. Vor drei Jahren zählten wir 12 Monate lang die in Java neu entdeckten Sicherheitslücken – es waren 160!

In einer perfekten Welt sollte die Suche und das Schließen von Software-Sicherheitslücken vielleicht wirklich exklusiv den Herstellern vorbehalten werden. Doch in der realen Welt passiert es immer wieder, dass die Menschen, die für solche Dinge verantwortlich sind, eher dem Prinzip „Bienen gegen Honig“ folgen.

Aber lassen wir doch auch die andere Seite zu Wort kommen: In der letzten Woche sprach Jeff Moss, Gründer der Black-Hat-Konferenz, darüber, dass Software-Hersteller für Fehler in ihrem Code verantwortlich seien. Er sagte, es sei an der Zeit, die Hinweise in EULAs zu löschen, die besagen, dass der Hersteller keine Haftung gegenüber dem Kunden habe. Das ist eine interessante Erklärung, aber nicht weniger überheblich als die Forderung, „Disassembler zu verbieten“. Bisher ist nur eines klar: Wenn Anwender (Firmen und Einzelpersonen), Hersteller und Forscher sich überhaupt verstehen können, wird das nicht über protzige Aussagen und Twitter-Witze passieren.

Was gab es sonst noch?

Eine weitere Black-Hat-Präsentation über das Hacken des Square Readers, dem Ding, das man mit dem Smartphone verbinden kann, um den Sushi-Lieferservice zu bezahlen. Muss überarbeitet werden.

Und in Lenovo-Laptops wurde ein weiteres Hersteller-Rootkit entdeckt (nicht in allen Modellen, aber in einigen). Hier die frühere Geschichte.

Oldies

Die Schadprogrammfamilie „Small“

Standard-Resident-Viren, werden am Ende von .com-Dateien angefügt (außer bei Small-114, -118, -122, die an den Anfang geschrieben werden), wenn diese in den Speicher geladen werden. Die meisten Exemplare der Virenfamilie verwenden die Befehle POPA und PUSHA der 80×86-Prozessoren. Small-132 und -149 infizieren bestimmte Dateien fehlerhaft. Sie stammen von unterschiedlichen Autoren. Offensichtlich kann der Ursprung der Small-Familie als Wettbewerb um den kürzesten, speicherresidenten Virus für MS-DOS gesehen werden. Bleibt nur noch, die Größe des Preises festzulegen.

Zitat aus „MS-DOS-Computerviren“ von Eugene Kaspersky, 1992, Seite 45.

Hinweis: Diese Kolumne spiegelt die persönliche Meinung des Autors wider. Diese kann, muss aber nicht mit der Position von Kaspersky Lab übereinstimmen. Das ist Glücksache.

Tipps
Abonnieren Sie uns und bleiben Sie auf dem neuesten Stand mit unseren Beiträgen
  • Für alle anderen Länder