Forensic Investigations / Fi Blog

Fi Blog

Bereits vorletzte Woche berichteten u.a.heise online und The Register mit Bezug auf einen Bericht von Sky News (ACHTUNG: geht Richtung RTL2-Niveau!), der Code von Stuxnet sei in einem Underground-Forum aufgetaucht und werde dort gehandelt.

Man muss hier sehr fein differenzieren, was Dichtung und Wahrheit ist. Der Wurm wird keine nukleare Katastrophe auslösen können. Ebenso unrealistisch ist aber die Betrachtungsweise in einem Anfang November beim CIP Seminar von SIEMENS offiziell veröffentlichtem Papier , das mit lauter schönen grünen Häckchen suggeriert, alles sei in bester Ordnung, und es drohe keinerlei Gefahr mehr. Die Wahrheit liegt wie immer zwischen den Extremen.

Quellcode im Umlauf oder nicht, wo liegt der Unterschied?

Auch wenn der Bericht von Sky News nahezu reißerisch verfasst ist, und die darin enthaltenen Schlussfolgerungen größtenteils falsch sind: ich halte das Auftauchen des Quellcodes für sehr wahrscheinlich, da es mit hoher Wahrscheinlichkeit entsprechende Verbindungen der Stuxnet-Macher mit der Cybercrime-Szene gab oder gibt, und der Quellcode sicher sehr begehrt ist.

Letztendlich macht es aber relativ wenig Unterschied, ob der Quellcode nun aufgetaucht ist oder nicht. Man muss dazu zunächst verstehen, dass

  • Stuxnet modular aufgebaut ist. Die enthaltenen Exploits sind austauschbar und stellen auch lediglich einen Transportweg für den tatsächlich enthaltenen Schadcode dar, der Steuerungen manipulieren kann. Bis jetzt ist dies nicht oder nicht in großem Umfang geschehen, aber wohl nur aus dem Grund, dass es auch gar nicht so beabsichtigt war.
  • es nicht genügt, dass alle aktuellen Virenscanner Stuxnet in seiner jetzigen Form erkennen können, selbst ohne den Quellcode ist es möglich den Wurm zu verändern oder/und mit im Umlauf befindlichen Crimeware-Paketen durch Polymorphismus nicht detektierte Varianten herzustellen
  • der in Stuxnet enthaltene Weg zur Manipulation von Steuerungen generischer Natur ist, und der tatsächliche Angriffscode relativ leicht austauschbar und weniger umfangreich ist

Es macht also lediglich einen Unterschied beim Zeitfenster aus, in dem neue Angriffe erwartet werden können: mit dem Quellcode könnte ein Angreifer wahrscheinlich bereits jetzt schon wieder sein Unwesen treiben.

Neue Transportwege und komplette Übernahme von Systemen - auch jetzt im Moment möglich

Transportwege

Als Transportweg stünden einem modifizierten Stuxnet-Wurm auch im Moment diverse Wege offen, zu denen beispielsweise der seit ca. 6 Wochen bekannte Internet Explorer 0day (CVE-2010-3962 ) gehört, zu dem gar ein öffentlicher Exploit verfügbar ist, oder der von uns entdeckte SIMATIC Code-Execution Bug .

Systemübernahme

Für die anschließende totale Übernahme des Rechners stehen zudem mindestens drei verschiedene Wege zur Verfügung: der nicht behobene Fehler im Task Planer , der Windows UAC-Bypass und die von uns entdeckte WinCC Datenbank-Lücke . Für die ersten beiden Bugs sind öffentliche Exploits verfügbar, letzterer ist auch von drittklassigen Cyber-Kriminellen mit einer Zeile Änderung in Stuxnet ausnutzbar.

Steuerungen generell anfällig

Der Designfehler Das 'Feature', dass es erst ermöglicht, Steuerungen nach dem Schema von Stuxnet zu manipulieren ist nach wie vor vorhanden . Durch dieses Angriffsschema werden sowohl Überwachung als auch Steuerung der Automatisierungssysteme gänzlich unmöglich gemacht.

Stand des SIEMENS Stuxnet-Papiers

  • Die von uns entdeckten Sicherheitslücken mit extrem hohen Risk-Scores (errechnet nach dem CVSS -Standard) werden großzügig verschwiegen und ignoriert, offiziell existieren Sie scheinbar nicht:
  • Sämtliche Fehler zur Privilegieneskalation sind in dem Papier ebenfalls nicht enthalten
  • Immerhin findet der Bug im Druckerwarteschlangendienst schonmal Erwähnung, im Advisory fehlt jeder Hinweis darauf aber weiterhin
  • Der Aspekt der Neukompilierung, Repaketierung, des Polymorphismus oder des Auftetens neuer Varianten fehlt ebenso, der Schluss "zukünftige Infektionen unwahrscheinlich" ist deshalb m.E. so weder zulässig noch richtig
  • Nichts zum Thema der generellen Anfälligkeit der Steuerungen
  • Ralph Langners Kommentar zu dem besagtem Papier: "[go] back to the lab, please "

Risiken missachten – die schlechteste aller Strategien – Aussitzen geht schief

Eine nachhaltige Problemlösung ist weiterhin, nach nun fast viereinhalb Monaten, nicht in Sicht. Offenbar sollen seitens SIEMENS alle Probleme mittels PR-Mechanismen 'weggelächelt' oder ausgesessen werden. Solange einige der großen Kunden derartig geschönter 'Information' Glauben schenken, könnte dieses Konzept auch aufgehen.

Nächste Schritte

Als nächsten Schritt könnten wir das US-CERT kontaktieren, wenn SIEMENS nicht endlich reagiert und die Mängel offiziell bestätigt und beseitigt. In ähnlich gelagerten Fällen haben andere Sicherheitsforscher auch nach Ablauf einer gewissen Frist alle Details öffentlich herausgegeben ("Full Disclosure "), womit jedermann die Sicherheitslücken ausnutzen konnte, wenn die Hersteller anderweitig nicht zur Raison zu bringen waren. Die von der zum HP-Konzern gehörenden Firma TippingPoint geleitete "Zero Day Initiative " tut das beispielsweise automatisch nach 6 Monaten .

Ich kann nur nochmals an SIEMENS appellieren, handeln Sie, vor allem im Interesse Ihrer Kunden. Für den Code-Execution Bug haben wir bereits eine Lösung parat . Wie sagte der SIEMENS-Gründer Werner von Siemens so schön: "Es kommt nicht darauf an, mit dem Kopf durch die Wand zu rennen, sondern mit den Augen die Tür zu finden." Diese Tür steht nach wie vor offen.

Gefährliche Signale

Bitte ändern Sie deshalb DRINGENDST Ihre Strategie im Umgang mit Sicherheitslücken. ES GEHT NICHT, die Entdecker solcher Sicherheitslücken einfach zu ignorieren oder gar noch verteufeln zu wollen. Sicherheitslücken verschwinden nicht von alleine. Am Schwarzmarkt werden wohl 6-stellige Beträge für diese Lücken bezahlt; Sicherheitsforscher brauchen dem gegenüber ein Geschäftsmodell.

Wer sich als Hersteller so verhält und nicht bereit ist, solche Leute zu unterstützen, setzt damit ein ganz gefährliches Signal für die Zukunft: man treibt mit dieser Austrocknungsstrategie talentierte Sicherheitsfachleute vielleicht fast geradezu vorsätzlich in die Hände unseriöser Leute. Das Potential talentierter Leute sollte man als Unternehmen nutzen, ansonsten könnte es sich gegen einen richten, und es kann gewaltig sein. Insbesondere, wenn man selbst ein 'Hack Proof Products' Programm betreibt, das angesichts der Sachlage wie ein schlechter Scherz anmutet.

'Bug Bounty' Programm stellt Glaubwürdigkeit (wieder) her

Installieren Sie ein 'Bug Bounty' Programm, das erhöht die Vielfalt der Kompetenzen der beteiligten Personen und bietet hohe Glaubwürdigkeit in die Sicherheit der Produkte, die ein geschlossenes System niemals leisten kann. Nebenbei senkt es wahrscheinlich auch noch die Kosten. Wenn die eigenen Produkte in puncto Sicherheit halten, was sie versprechen, braucht man zudem nie etwas auszuzahlen.

Aber vielleicht hat man es aber auch einfach nicht nötig, sichere Produkte zu schaffen, insbesondere nachdem der Banken-Status nunmehr auch offiziell ist .


Während der Datenbank-Bug in WinCC große öffentliche Aufmerksamkeit gefunden hat , ging dabei ein anderes Thema völlig unter: ein Programmierfehler (Video 2.2) sorgt dafür, dass Projektdateien von WinCC, WinCC Web Navigator, PCS7 und anderen Tools des SIEMENS SIMATIC Pakets so manipuliert werden können, das beim simplen Öffnen einer solchen Datei Schadcode ausgeführt werden könnte.

Wir hatten hier entsprechende Demo-Exploits angefertigt, die das belegen, aber natürlich statt Schadcode nur den Taschenrechner starten wie im Video zu sehen. Diese dienen auch dazu, als Gegenbeweis die korrekte Funktion des FixIt zu auditieren.

Das Problem ist deshalb so brisant, weil dies Schadcode von am Internet hängenden Engineering-PCs auf Anlagen einschleppen könnte. Dienstleister könnten von diesem Problem besonders betroffen sein.

Wir haben uns deshalb an die Arbeit gemacht, um SIEMENS SIMATIC WinCC und PCS7-Anwender vor diesem Risiko zu schützen. Eine Lösung für dieses Problem ist fertiggestellt.

Solange SIEMENS jedoch die Verweigerungshaltung in Bezug auf uns und das Thema Sicherheitslücken nicht ändert, sehen wir uns ausserstande, den Fix zu veröffentlichen. Durch die Veröffentlichung würden Details zum Problem in weiten Kreisen bekannt. Dies könnte Anwender, die nicht regelmäßig bei uns vorbeischauen, oder die aus Haftungsgründen den Einsatz eines inoffiziellen FixIt scheuen, in ernsthafte Gefahr bringen.

Der Teufelskreis ist nur durch Sie, die Anwender zu durchbrechen: bitten (oder falls erforderlich nötigen) Sie Ihren Automatisierungshersteller seine Verweigerungshaltung aufzugeben, es geht um Ihre Sicherheit.

SIMATIC Code-Execution Bug: Schweregrad nach CVSS-Standard

Berechnung des Schweregrads für eine typische Automatisierungs-Umgebung nach dem CVSS -Standard (Ihr CISO sollte Ihnen helfen können, diese Metriken und Vektoren zu interpretieren, weitere Informationen finden Sie auch hier ):

  • CVSS Overall Score: 10 /10


Hier finden Sie aktuelle Themen und Hintergründe rund um Sicherheit, Internet und Recht, das Sachverständigenwesen und die Computer-Forensik.

Mon Di Mi Do Fr Sa So
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31