Forensic Investigations / Fi Blog

Fi Blog

Lange schon war die Nachahmung des Stuxnet-Wurms in der Diskussion . Nun ist den Analysten von Symantec eine Duqu [dyü-kyü] getaufte Software aus dem europäischen Raum zugespielt worden. Die Malware sei Duqu getauft worden, da sie Dateien mit dem Präfix "~DQ" anlege. Symantec hat dazu ein technisches Papier , F-Secure und McAfee berichteten, das ICS-CERT hat ALERT-11-291-01 ALERT-11-291-01A ALERT-11-291-01B ALERT-11-291-01D ALERT-11-291-01E herausgegeben.

Anatomie des Rootkit-Teils von Duqu. Bild (c) Symantec

F-Secure schreibt , der Kernel Rootkit Treiber von Duqu (JMINET7.SYS) sei Stuxnet so ähnlich, dass deren Analyse-Systeme es für Stuxnet (MRXCLS.SYS) hielten.

Während Stuxnet mutmaßlich gestohlene Zertifikate der taiwanesischen Firmen RealTek und JMicron verwendete, sei die Duqu Malware mit einem Zertifikat der ebenfalls taiwanesischen Firma C-Media Electronics Incorporation signiert. Wie die beiden anderen Zertifikate sei es von VeriSign ausgestellt und am 14.10.2011 zurückgezogen worden. Dies dürfte aber nur wenig Wirkung zeigen, da ältere Systeme wie Windows XP dies nicht ausreichend überprüfen.

Symantec berichtet , Duqu sei nicht darauf ausgelegt, Automatisierungssysteme direkt zu sabotieren, sondern vielmehr sehr spezifische Dokumente wie Anlagen- und Gerätedesigns zur Vorbereitung zukünftiger Attacken zu stehlen. Der informationsstehlende Trojaner verfüge über eine Command & Control Infrastruktur, mit der er per HTTP oder HTTPS kommuniziere. Der C&C Server, über den die Steuerung des so gebildeten Botnets erfolgt, stünde in Indien und sei noch aktiv.

Das zurückgezogene Zertifikat der Rootkit-Komponente von Duqu (cmi4432.sys)

Der Verbreitungsweg sei noch unbekannt, die Malware würde sich im Gegensatz zu Stuxnet nicht selbst replizieren, sei also kein Wurm. Die Zahl der Organisationen, auf die die Malware abziele, sei sehr klein (<=2), darunter befänden sich Hersteller von Industrieautomatisierungssystemen. Als wahrscheinlichsten Verbreitungsweg kann man deshalb Social Engineering mittels Email- Scams mutmaßen. Die Schadsoftware würde sich zudem nach 36 Tagen selbst zerstören.

Zu den Fähigkeiten der Schadsoftware gehörten das Sammeln von Systeminformationen, Auswerten der Netzwerktopologie und das Aufzeichnen von Tastatureingaben ("Keylogging"). Es seien bereits mehrere Varianten aufgetaucht.

McAfee's Blogeintrag kann derzeit keine neuen Erkenntnisse beisteuern.

In den Medien wird hier vom "Vorgänger vom Nachfolger", "Sohn" oder "Bruder" von Stuxnet gesprochen. Bruder trifft es wohl am ehesten, da beide "genetisch" ähnlich sind. Ob es tatsächlich der "Vorgänger vom Nachfolger" ist, erscheint aus meiner Sicht spekulativ und unlogisch. Warum man erst von bestimmten Herstellern Informationen stehlen sollte erscheint schleierhaft, da ein weiterer Angriff nach diesem Schema auch so leicht möglich wäre.

UPDATE 21.10.2011: Das ICS-CERT hat einen aktualisierten Alert Alert , der die unzensierte IP-Adresse des Command&Control Servers benennt. Der Server wurde mittlerweile abgeschaltet.

Das Symantec-Papier zeigt keine wirklichen Besonderheiten des Trojaners. Interessant ist aber, dass Duqu die schon von Stuxnet bekannte Liste der zu umgehenden Virenscanner um die zwei chinesischen Hersteller Rising International und 360 erweitert hat. Auch interessant: Symantec hat laut Paper keine Ahnung, wie der Trojaner genau mit dem C&C Server kommuniziert(e), und wo im Code sich ein Selbstzerstörungsmechanismus befinden soll, weiß aber gleichzeitig, dass es genau nach 36 Tagen ist, und der Trojaner es selbst tut, und nicht ferngesteuert. Na dann.

Die Hashsummen der bisher bekannten vier Varianten des Duqu-Rootkits.

UPDATE 22.10.2011: Jetzt ist es offiziell: Duqu zielt NICHT auf Betreiber oder Hersteller von Automatisierungssystemen ab, vermeldet das ICS-CERT in Koordination mit Symantec und CrySyS , den Entdeckern von Duqu. Ich wollte es nicht so direkt schreiben, wie aber schon vermutet handelt es sich wohl um eine PR-Ente von Symantec. Ob die Geschichte mit dem Diebstahl sensitiver Dokumente von Automatisierungsherstellern gänzlich frei erfunden oder eine bloße Vermutung war, die als Faktum verkauft wurde, werden wir wohl nie erfahren. Der ICS-Security-Community wurde damit ein echter Bärendienst erwiesen.

Nebenbei hat das ICS-CERT im aktualisierten Duqu-Papier versäumt zu melden, dass neben den zwei bekannten Varianten noch zwei weitere gefunden wurden, weswegen ich das mit dem "ganz gezielten Angriff" auch nicht glauben konnte.
Die Rootkit-Treiber der vier bisher bekannten Varianten heißen "cmi4432.sys ", "jminet7.sys ", "adpu321.sys " und "nfrd965.sys ". Lediglich "cmi4432.sys" trägt eine vormals gültige digitale Signatur. Das zum Signieren benutzte Zertifikat wurde aber mittlerweile zurückgezogen.

UPDATE 27.10.2011: Aktualisierter Alert des ICS-CERT. Ergänzt werden Informationen aus einem Blog-Artikel von Kaspersky Labs. Berichtet wird dort von einem Infektionsfall im Sudan und drei Fällen im Iran. Dabei seien weitere, jeweils unterschiedliche, Dateinamen des Rootkit-Treibers festgestellt worden, namentlich "adp55xx.sys", "iraid18.sys", "igdkmd16b.sys", "bpmgs.sys" und "noname.sys". Ein Zusammenhang mit industriellen Automatisierungssystemen oder zwischen den Opfern bestünde nicht.

UPDATE 02.11.2011: Aktualisiertes Symantec-Papier zu Duqu. Symantec spricht von mittlerweile 14 Varianten.

Das "Verfallsdatum" des Trojaners lässt sich laut einem Blogeintrag von ESET in dessen Konfigurationsdatei angeben, analog zu Stuxnet. Dieses Verfallsdatum kann offenbar entsprechend verlängert werden.

Der Dropper (Duqu-"Installationsprogramm") wurde mittlerweile ebenfalls entdeckt. Er soll in einem Word-Dokument enthalten sein und nutzt eine bisher unbekannte Sicherheitslücke ("0day") in Microsoft-Betriebssystemen aus. Microsoft hat die Lücke bestätigt und arbeitet an der Behebung .

Command and Control Weiterleitung an das interne Netz mittels RPC-over-SMB. Bild (c) Symantec

Ein weiterer Server zur Fernsteurung ("Command & Control") in Belgien wurde entdeckt und vom Netz genommen.

Symantec und ESET berichten übereinstimmend, Duqu besitze einen zu Stuxnet analogen Kommunikationsmechanismus . Dieser könne Kommandos von einem infizierten Rechner mit Internetverbindung an einen internen Rechner ohne Internetverbindung weiterreichen. Dabei verwende Duqu RPC über SMB ("Named Pipes "), was von keiner Firewall blockiert werden wird.

Insgesamt also viele Parallelen, neben den völlig verschiedenen Payloads und Angriffszielen. Symantec spricht von mittlerweile 3 verschiedenen Payloads, die alle Informationen zu eingesetzten Systemen und/oder der Netztopologie entwenden.

UPDATE 04.11.2011: (!!!WICHTIG!!!) Microsoft hat ein Advisory und ein Fix-It herausgegeben, das die Ausnutzung der Sicherheitslücke (CVE-2011-3402 ) durch den Duqu-Installer verhindern soll. Die Sicherheitslücke betrifft alle Windows-Versionen und ermöglicht Privilegieneskalation. Der Fehler steckt im Windows-Kernel, genauer gesagt dem Parsen von TrueType Fonts. Voraussichtlich wird Microsoft diese Lücke mit dem November-Patchday am nächsten Dienstag (08.11.2011) noch nicht endgültig schließen. Es empfiehlt sich deshalb die Benutzung des Fix-Its, um kein zu großes Zeitfenster für eine Infektion entstehen zu lassen.

UPDATE 05.11.2011: Die im Advisory 2639658 beschriebenen manuellen Workarounds funktionieren unter Windows XP und Server 2003 nur für englischsprachige Windows-Versionen. In nicht-englischen Windows-Versionen ist der Benutzergruppenname "everyone" durch das jeweilige lokalisierte Äquivalent zu ersetzen (z.B. Deutsch: "Jeder"). Das Fix-It funktioniert auch auf nicht-englischen Sprachversionen. Sowohl die manuelle als auch die automatische Methode verhindern den Zugriff auf die Datei "t2embed.dll". Unter Windows XP und Server 2003 führt das zu der unerwünschten Nebenwirkung, dass die Updates KB972270 (MS10-001) und KB982132 (MS10-076) ständig erneut angeboten werden, auch wenn diese schon installiert sind oder nochmals installiert werden. Es empfiehlt sich deshalb, diese Updates entweder zu ignorieren oder auszublenden.

UPDATE 09.11.2011: Neues gemeinsames Papier des US-CERT und des ICS-CERT ("Joint Security Awareness Report"). Keine neuen Erkenntnisse, lediglich Zusammenfassung.

UPDATE 13.12.2011: Microsoft schließt die Duqu-Lücken im Windows-Kernel-Treiber win32k.sys (MS11-087 /CVE-2011-3402 ) wie erwartet im Zuge des Dezember-Patchdays . Das oben beschriebene Fix-It wird damit obsolet. Diese (Symantec PR- und FUD-)Story ist damit beendet.


Das ICS-CERT hat die "Protokollmängel" und Sicherheitslücken nochmals in dem Dokument ICS-ALERT-11-223-01 ICS-ALERT-11-223-01A zusammengefasst, das leider nur wenig Konkretes und wenig Klarheit liefert. Hier das Wichtigste in Kürze:

Lesen und Schreiben von Speicherinhalten

("Read/Write of Memory")

  • Auslesen von Speicherinhalten der SPS – Bild (c) Dillon Beresford/NSS Labs

    bestätigt für S7-1200
  • unbestätigt für S7-200/S7-300/S7-400
  • dies soll lediglich ein designgemäßer Mangel des ISO-TSAP Protokolls sein, unklar warum es also nicht für andere Geräte bestätigt wird

 

Ausführen von Befehlen über nicht-verschlüsselte und nicht-authentifizierte Kanäle

("Execution of commands over a clear-text, unauthenticated protocol")

  • bestätigt für S7-1200/S7-200/S7-300/S7-400
  • dies soll lediglich ein designgemäßer Mangel des ISO-TSAP Protokolls sein

Umgehung des Passwort-Authentifizierungsverfahrens

("Bypass of a PLC password protection algorithm")

  • bestätigt für S7-1200/S7-200/S7-300/S7-400
  • soll für S7-1200 behoben sein

Unautorisiertes Abschalten des Passwort-Authentifizierungsverfahrens

[durch Schreiben des Speichers, Anmerkung des Verfassers] ("Unauthorized disabling of a password protection mechanism")

  • Die SPS gibt bereitwillig Auskunft über Typ, Seriennummer und Firmwarestand, sodass etwaige Sicherheitslücken einfach und automatisiert ausgenutzt werden können – Bild (c) Dillon Beresford/NSS Labs

    bestätigt für S7-1200

  • soll für S7-1200 behoben sein
  • unbestätigt für S7-200/S7-300/S7-400
  • unklar warum hier kein konkreter Status (betroffen/nicht betroffen) für diese Geräte benannt wird

Denial-of-Service (DoS) Schwachstelle im eingebetteten Webserver der SPS Firmware

("Denial-of-service (DoS) vulnerability in the Web server embedded in the PLC firmware")

  • bestätigt für S7-1200
  • soll für S7-1200 behoben sein
  • es fehlt ein expliziter Hinweis, dass andere Geräte nicht betroffen sind

Authentifizierte Diagnosefunktionen über TELNET und HTTP mit hartcodiertem Passwort

[konkret auch Hintertürchen genannt, Anmerkung des Verfassers] ("Authenticated diagnostic command shell through both TELNET and HTTP using hardcoded credentials"

  • bestätigt für S7-300 (nur bestimmte ältere Versionen, siehe ICS-ALERT-11-204-01B )
  • Benutzername und Passwort sind bereits öffentlich bekannt
  • es fehlt ein expliziter Hinweis, dass andere Geräte nicht betroffen sind

Mysteriosum: das Transportprotokoll ist an allem Schuld

Es stimmt zwar, dass das ISO-TSAP v3 Protokoll (RFC 1006 ) Authentifizierung und Verschlüsslung nicht vorgesehen hat und damit im wahrsten Sinne des Wortes für 'offene Kommunikation' steht. Es wurde im Mai 1987 letzmalig überarbeitet und ist damit seit nahezu einem viertel Jahrhundert unverändert.

Aber: ISO-TSAP definiert lediglich den Transport, aber nichts zum Lesen und Schreiben von Speicherinhalten, Passwortsicherungen, oder dem Ausführen von Kommandos. Es ist, als würde man behaupten, TCP/IP wäre daran Schuld, dass die Kennwortsicherung meines FTP-Servers nicht funktioniert.

Die Authentifizierung und Verschlüsslung muss auch nicht auf Ebene des Transports passieren; dies ist sogar die Regel, wenn wir prominente Internet-Protokolle wie HTTPS oder SSH betrachten, die alle nicht auf der Transportebene sichern.

Warum ist die Information immer noch so vage?

Sowohl dem ICS-CERT als auch SIEMENS als Hersteller stehen Dillons Exploits und entsprechende SPS'en zur Verfügung. Welche Geräte von welchen Problemen betroffen sind, läßt sich locker in weniger als einer Stunde ermitteln. Der geneigte Leser mag sich die Frage stellen, wieso fast drei Monate nach dem Bekanntwerden der Probleme immer noch so wenig Information verfügbar ist und das Papier des ICS-CERT für einige Probleme auf einigen Maschinen immer noch ein "unconfirmed" ("unbestätigt") enthält.

Der Hersteller, der nicht will, und das CERT, das nicht darf?

Dale G. Peterson gibt hierzu eine eigene Theorie ab . Er erklärt, dass ICS-CERT sei identisch mit dem Idahoe National Laboratory (INL). Das INL hätte seit Jahren Sicherheitsuntersuchungen mit hohen Budgets für die großen Hersteller durchgeführt und Equipment im Wert von Hunderttausenden von Dollar für Ihre Labore erhalten.

Anschließend sei das INL mit der Aufgabe als Industrial Controls Systems Computer Emergency Response Team (ICS-CERT) betraut worden, da dies der richtige Platz für die Ansiedlung zu sein schien.

Die vorhandenen Kontakte zu den großen Herstellern seien jedoch kein Kapital für das INL gewesen, sondern Verpflichtungen. Zudem sei das INL aus früheren Zeiten mit Geheimhaltungsvereinbarungen geknebelt, sodaß es seine Aufgabe gar nicht wahrnehmen könne, und darüber hinaus in einem riesigen Interessenskonflikt stünde.

Hier noch die Dokumente von Dillon Beresford. Für Insider: es lohnt sich besonders, den Abschnitt "Disclosure Process" im White Paper zu lesen und zu überdenken.

UPDATE 23.08.2011: Das ICS-CERT hat Update A zum ICS-ALERT-11-223-01 veröffentlicht, Link oben aktualisiert. Statt mehr Transparenz in die Sache zu bringen, als einzige Ergänzung die zweizeilige Ansage, das es "auf Grund der getroffenen Designentscheidungen" nicht möglich sei, alle Probleme kurzfristig zu lösen. Ich hätte da schon einen Tipp, auf was das hinausläuft...

Der Kollege Ralph Langner hat nun auch einen Artikel, in dem er die "fehlerhafte Analyse und irreführenden Ratschläge " des ICS-CERT viel ausführlicher beschreibt, als ich das oben getan habe. Er kommt zur gleichen Schlussfolgerung, dass eben nicht das offene Transportprotokoll ISO-TSAP der Grund für die Mängel ist und hat sogar den selben Vergleich mit FTP + TCP/IP herangezogen wie ich.


'Stuxnet 2.0' Demo - Bild (c) Dale G. Peterson

Symantec zeigte auf dem Ausstellungsflur der BlackHat eine 'Stuxnet 2.0' Demo. Hierbei hätten Sie das 'Payload', also die 'Nutzlast' des Stuxnet-Codes ausgetauscht. Ebenso wie beim originalen Stuxnet sei die Manipulation des SPS-Codes durch einen Operator nicht zu erkennen, da diese beim Auslesen versteckt würde.

Die 'Nutzlast' könnte Steuerungen auf vielfältige Weise manipulieren. Die trivialste mögliche Manipulation hatte Ralph Langner schon vor einiger Zeit demonstriert . Mit 14 Bytes implementierte er eine simple Zeitbombe, die auf ein bestimmtes Datum wartet, und ab dann einfach das restliche Steuerungsprogramm überspringt. Kleine Ursache, große Wirkung: dies wäre noch schlimmer als ein unkontrollierter Stromausfall an der Steuerung, alle Regelungen kommen zum erliegen, aber der letzte Signalzustand liegt noch an. In diesem Fall kann man nur noch darauf hoffen, dass die physikalischen Sicherungssysteme auch für diesen Fall wie gewünscht greifen. Die Diagnose eines 'unsichtbaren' Fehlers dürfte ebenfalls schwierig werden.


Laut englischem Bericht des Wired Magazine wurde ein Vortrag auf der Takedown Sicherheitskonferenz in Dallas vergangenen Mittwoch kurzfristig abgesagt, nachdem das Department of Homeland Security (DHS) und SIEMENS Bedenken angemeldet hätten.

In dem Vortrag "Chain Reactions - Hacking SCADA " von Dillon Beresford von NSS Labs und dem unabhängigen Sicherheitsforscher Brian Meixell sollte über vier neu entdeckte Sicherheitslücken in SIEMENS Kontrollsystemen berichtet werden. Mindestens eine der Lücken soll sich eventuell auch auf Kontrollsysteme anderer Hersteller auswirken.

Dem Bericht zufolge nach geht es -im Unterschied zu den von uns entdeckten Sicherheitslücken - um Sicherheitsprobleme direkt in Speicherprogrammierbaren Steuerungen (SPS) . SIEMENS würde noch an Sicherheitsupdates arbeiten und hätte zwischenzeitlich eine Methode gefunden, die die Ausnutzung der Sicherheitslücke verhindern sollte. Beresford konnte diese Methode nach eigenen Angaben jedoch ohne Weiteres ebenfalls überlisten, irgendwie ein "Déjà Vu" für mich.

NSS Labs hätte betont, das es entgegen der Gerüchteküche auf Twitter keinen juristischen Druck seitens des Department of Homeland Security (DHS) oder SIEMENS gegeben hätte und man die Entscheidung, den Vortrag abzusagen, frei aus eigenen Erwägungen getroffen hätte. Dies ist womöglich eine weise Entscheidung.

Fi Untersuchung: meherere Dutzend SPS frei zugänglich im Netz!

Noch vor kurzem hatte ich bei einer kurzen Websuche mehrere Dutzend Webadministrationsoberflächen von SPS'en frei zugänglich in Netz gefunden. Stichproben ergaben, dass einige Administrationsoberflächen noch nicht einmal durch ein Kennwort gesichert waren – darunter unter anderem mehrere Energieversorger und Unternehmen der Lebensmittelindustrie. Über diese Oberflächen wäre es direkt möglich gewesen, die Steuerungen herunterzufahren oder -schlimmer- manipulierte Firmware einzuspielen. Ein sträflicher Leichtsinn der mich in größtes Erstaunen versetzt hat.

Fazit

Es bleibt abzuwarten, um welche Mängel es sich hier tatsächlich handelt. Womöglich sind dies auch einige, die schon lange Zeit bekannt sind, ohne dass es jemanden zu interessieren scheint. Das mit den frei zugänglichen Administrationsoberflächen ist prinzipiell auch ein Fehler des Herstellers, zumindest einer, den der Hersteller einfach vermeiden könnte. Hersteller, die WLAN-Router für unter 100€ verkaufen, machen vor, wie es gehen könnte ;)

Das Idaho National Laboratory und SIEMENS haben sich bei Ihrer großen Security-Untersuchung 2008 mit Millionenetat und allem erdenklichen Equipment wahrscheinlich nicht gerade mit Ruhm bekleckert. Meines Erachtens nach hat sich selbst fast ein Jahr nach Stuxnet nichts Wesentliches getan. Die von uns entdeckten Sicherheitsprobleme sind unserer Kenntnis nach weiterhin nicht behoben, jedenfalls hat man es nicht für nötig erachtet, eine eventuell vorhandene Lösung mit uns zusammen zu verifizieren.

UPDATE 26.05.2011: Bisher ist lediglich öffentlich bekannt, dass Dillon Beresford die Mängel zumindest in kleineren S7-1200-Steuerungen belegen konnte, die wohl kaum in hochsensitiven Bereichen eingesetzt werden. Es bleibt abzuwarten, ob davon auch größere Systeme betroffen sind, bei denen ein potentiell hoher Schaden entstehen könnte. Offenbar ist man sich seiner Sache aber selbst nicht so sicher, sonst hätte man Beresford wohl nicht dazu bewegen müssen, seinen Vortrag abzusagen.

Unterbleibt eine klare Kommunikation, entstehen Spekulationen und Bedenken. Zudem wurden die Sicherheitsmängel als „durch Außenstehende schwer zu beurteilende“ „unter Laborbedingungen entstandene“ „Unregelmäßigkeiten“ bagatellisiert, die bei „normalen IT-Sicherheitsmaßnahmen kein Risiko darstellen“ und „nicht leicht von jedermann auszunutzen“ seien. Statt dieser äußerst wackeligen Argumentationsweise wäre es womöglich angebrachter gewesen, konstruktiv Risiken, betroffene Systeme und Konfigurationen sowie Möglichkeiten zur Schadensbegrenzung zu nennen und eine Problemlösung anzupacken.

Laut Beresford sei es bei den betroffene(n) Steuerunge(n) möglich

  • sie zu stoppen, sodass lediglich eine Unterbrechung der Stromzufuhr die Steuerung wieder aktivieren kann (DoS )
  • den Speicher auszulesen und zu beschreiben
  • eine Reprogrammierung durchzuführen

UPDATE 15.06.2011: Wie schon gemutmaßt betrifft das Problem S7-1200 Steuerungen (ICS-CERT Security Alert 11-161-01 , SIEMENS Security Advisory 625789 , Updates ). Die S7-1200 ist ohne das Update anfällig für das Abspielen aufgezeichneter Passwortfolgen ("Password-Replay") und kann zudem durch "Denial of Service (DoS)"-Attacken lahm gelegt werden. Das ICS-CERT konnte die Beseitigung der Probleme durch das Update bestätigen.

UPDATE 06.07.2011: Nun meldet das ICS-CERT (ALERT 11-186-01 ), dass die Passwort-Replay-Attacken offenbar doch nicht nur S7-1200er Steuerungen betreffen, sondern auch alle Modelle der S7-200er, S7-300er, und S7-400er Serien. Dies ist dem Hersteller seit 8 Wochen(!) bekannt oder wäre seitdem zumindest in 10 Minuten ermittelbar gewesen. Besonders für die größeren S7-400er hätte ein Update aufgrund der Einsatzbereiche wesentlich höhere Priorität gehabt als für die S7-1200er-Serie, bei der das Problem mittlerweile behoben ist. Hinzu kommt, dass selbst jetzt weder beim SIEMENS CERT noch auf dem Industrial Security-Portal des Herstellers vor dem Problem gewarnt wird. Das ist es, was ich mit unklarer Kommunikation und mangelnder Transparenz meinte.

UPDATE 04.08.2011: Auf der Industrial Security Seite hat SIEMENS mittlerweile einen Hinweis eingefügt, dass auch Modelle der S7-200er, S7-300er und S7-400er Serien mit ähnlichen Problemen zu kämpfen haben wie die S7-1200er Modelle. Updates stehen noch aus.

Durch die Berichterstattung zur laufenden BlackHat-Konferenz ist das Thema von offen im Internet zugänglichen Automatisierungssystemen hochgekocht, das eigentlich nur eine "Randnotiz" dieses Blog-Artikels war. Dies ist natürlich erst einmal eine Fehlkonfiguration seitens des Kunden bzw. Implementierers. Die Hersteller hätten jedoch leicht die Möglichkeit, die Geräte so vorzukonfigurieren, dass selbst eine solche Fehlkonfiguration nicht zum Desaster führen kann. Es ist häufig eine Verkettung von Fehlern auf seiten der Hersteller und der Benutzer, die zu einem potentiell angreifbaren System führen.

UPDATE 19.08.2011: Aktuellere Erkenntnisse hier , fortlaufende Berichterstattung im Blog .

Read this article in English - Google Translate sry for bad English!


Diesen Monat haben zwei Institutionen unabhängig voneinander Studien zur IT-Sicherheit in der Energiewirtschaft bzw. in der Energie- und Wasserwirtschaft veröffentlicht. Deren wichtigste Ergebnisse will ich im Folgenden zusammenfassen und einordnen. Insgesamt waren die Ergebnisse aus meiner Sicht wenig überraschend.

Q1 Labs/Ponemon Institute Studie

In einer von Q1 Labs und dem Ponemon Institute durchgeführten Studie wurden international 291 zufällig ausgewählte IT-Verantwortliche aus der Energiewirtschaft befragt. Die Studie kommt u.a. zu folgenden Ergebnissen:

  • 75% der Organisationen hätten mindestens einen erfolgreichen Cyberangriff in den letzten 12 Monaten verzeichnet
  • 71% der IT-Verantwortlichen sagten, Ihr Management verstünde oder würdige IT-Sicherheit nicht
  • 72% sagten, bisherige Ansätze seien nicht effektiv, aussagekräftige Daten über tatsächliche oder mögliche Attacken (z.B. Echtzeitalarme, Bedrohungsanalysen und Priorisierung) zu erhalten
  • nur 21% glaubten, dass ihre existierenden Mechanismen ausreichend seien, um Attacken aus SmartGrids oder von SmartMeter -verbundenen Geräten zu verhindern
  • nur 39% glaubten, gegen Advanced Persistent Threats (APTs ) ausreichend abgesichert zu sein
  • 67% seien eigenen Angaben zufolge nicht auf dem aktuellen "Stand von Wissenschaft und Technik "

McAfee/CSIS Studie

In einer zweiten, von McAfee und dem Center for Strategic and International Studies (CSIS) durchgeführten Studie wurden die Antworten von 200 zufällig ausgewählte Führungspersonen privater Betreiber aus der Energie- und Wasserwirtschaft in insgesamt 14 Ländern analysiert. Um einen vollständiges Bild erfassen zu können, habe ich die Veröffentlichung der gesamten Studie in der Woche vor Ostern abgewartet, statt die auszugsweise Vorab-Berichterstattung anderer Medien aufzugreifen.

Mehr Erpressungen, mehr Angriffe, neue Risiken

  • 25% wären Opfer von Erpressungen innerhalb der letzten 24 Monate geworden, 2009 lag die Zahl noch bei 20%. Regional angeführt würde die Statistik von Mexiko und Indien, wo gar 80% bzw. 60% Opfer von Erpressungen gewesen seien.
  • die Frequenz der Angriffe steige
  • die Einführung von SmartGrids und SmartMetering würde das Risiko zusätzlich erhöhen

Stuxnet: Infektionszahlen und Konsequenzen

Der berüchtigte Stuxnet-Wurm sei

  • bei rund 40% aller befragten Unternehmen gefunden worden
  • mit 46% aller Unternehmen sei die Elektrizitätsbranche besonders betroffen gewesen
  • Spiegel Online hatte unter Berufung auf McAfee vorab berichtet , in Deutschland seien gar 59% der Energie- und Wasserversorger befallen gewesen; in der Studie selbst finden sich jedoch keine auf Länder heruntergebrochenen Zahlen.

Die größten Konsequenzen aus dem Stuxnet-Vorfall seien in den Vereinigten Arabischen Emiraten, Italien und Japen gezogen worden, die vergleichsweise geringe Infektionszahlen gehabt hätten. Diese gehören jedoch zu den Staaten, die lt. der Studie allgemein die meisten Sicherheitsmaßnahmen implementiert hätten, mehr dazu im Folgenden.

Risikoeinschätzung der Branche und Realität

  • Malware: fast 80% sähen sich "sehr gut" oder "gut" vorbereitet, dennoch wurden 40%+ alleine Opfer von Stuxnet (Gesamtzahlen inklusive anderer Malware liegen leider nicht vor). Hinzu kommt, dass Stuxnet über ein Jahr sein Unwesen treiben konnte, ohne das irgendjemand etwas bemerkt hatte. Gute Vorbereitung sieht m.E. anders aus.
  • Netzwerkeinbrüche: knapp über 60% sähen sich "sehr gut" oder "gut" gewappnet, dennoch wurden 85% Opfer eines solchen Angriffs. Die o.g. Einschätzungen aus der Ponemon-Studie scheinen ebenfalls ein deutlicher Widerspruch zu diesem Wert zu sein.
  • Denial of Service (DoS ): lediglich ca. 50% sähen sich "sehr gut" oder "gut" vorbereitet, 80% wurden in der Praxis mit dem Problem konfrontiert, über die Auswirkungen gibt es aber leider ebenfalls keine Daten.

Erstaunlich finde ich hier, dass sich 80% bzw. 60% Malware und Netzwerkeinbrüchen entspannt gegenüber sehen, während dies bei der aus meiner Sicht wesentlich geringeren und einfach zu beseitigenden Gefahr der DoS-Attacken nur bei 50% der Fall ist. M.E. zu Recht werden in der Studie DoS-Attacken als "Kinderkram" bezeichnet, verglichen mit moderner Malware.

Besonders bei den Themen Malware und Netzwerkeinbrüchen legen die Zahlen auch eine deutliche Schere zwischen "gefühlter" und "realer" Sicherheit nahe. Dies bestätigt meine schon häufig geäußerte Beobachtung eines überzogenen Glaubens an Firewalls und Virenscanner .

Regional gibt es ebenfalls interessante Beobachtungen:

  • in Brasilien, wo 2005 und 2007 große Stromausfälle beobachtet wurden, die nicht wenige Experten auf Malware-Befall zurückführen, fühlen sich 91% unvorbereitet für Malware-Attacken
  • in Australien, wo große Aufklärungskampagnen in Sachen Cybersecurity und Schutz kritischer Infrastrukturen seitens der Regierung durchgeführt wurden, fühlten sich 90% unvorbereitet auf Netzwerkeinbrüche

Umsetzung von Sicherheitsmaßnahmen zu langsam

Alle Branchen hätten die Sicherheitsmaßnahmen seit 2009 erhöht. Gemessen wurde hier jedoch nur die Zahl der eingesetzten Technologien, nicht jedoch deren Effizienz, Ausgewogenheit oder technische und organisatorische Umsetzung. Diese Zahlen können also nur als Anhaltspunkt zur Sicherheitslage gesehen werden und geben nicht unbedingt direkt Auskunft über das absolute Sicherheitsniveau.

  • die Wasserver- und Entsorgungsbranche hätten nominell die meisten zusätzlichen Maßnahmen von 38% auf 46% verzeichnet, bildeten aber dennoch weiter das Schlusslicht unter den untersuchten Branchen
  • Öl und Gas hätten nominell von 45% auf 48% zugelegt
  • die Elektrizitätsbranche hätte sich von 50% auf 51% nominell lediglich minimal gesteigert

Die Studie kommt dabei zu dem Schluss, dass die Adaption von Sicherheitstechnologien mit dem Fortschreiten der Bedrohungslage nicht Schritt halten könne.

Regional gibt es ebenfalls signifikante Unterschiede:

  • China (59%), Italien (55%) und Japan (54%) führten die Statistik an
  • Mexiko, Frankreich und Brasilien bildeten die Schlusslichter
  • die restlichen Staaten, u.a. Deutschland, lägen im Mittelfeld um 43%

Staatliche Kontrolle und Regulierung

Staatliche Audits sind in vielen Ländern in unterschiedlichem Ausmaß üblich.

  • Japan (100%), China (70%) und die Vereinigten Arabischen Emirate (ca. 65%) hätten hier die höchsten Quoten
  • Deutschland läge mit 40% abermals im Mittelfeld
  • die geringste Anzahl staatlicher Audits fänden in Italien, den Vereinigten Staaten, Spanien und im Vereinigten Königreich statt

Interessanter Weise stiege das Vertrauen in staatliche Institutionen mit der Dichte der Kontrollen. Einen Ausnahmestatus hätte das japanische Modell inne, bei dem man durchgängig auf "Public-Private Partnerships" setzte, die die Autonomie der Infrastrukturbetreiber ausdrücklich anerkennen, und eher motivieren statt regulieren möchten.

Staaten als Bedrohung

Die Unternehmen befürchteten auch Spionage oder Sabotage fremder Staaten. Dies ist nicht verwunderlich, können Cyberwaffen doch – im Gegensatz zu konventionellen – mit relativ geringem Budget auch von kleineren Staaten hergestellt werden, und ohne wesentlich erhöhten Aufwand mehrere Ziele parallel anvisieren.

  • China (30%), Russland (16%), die Vereinigten Staaten (12%) und Nordkorea (11%) würden global am häufigsten gefürchtet
  • die deutlichste Veränderung hätte sich bei den Vereinigten Staaten (12%) ergeben, die 2009 noch von 36% gefürchtet worden wären

Naturgemäß gibt es besonders hier regional signifikante Unterschiede

  • in China sähen 3/4 die Vereinigten Staaten als größte Gefahr
  • in Japan hätten 2/3 aller Befragten China oder Nordkorea als am gefährlichsten benannt
  • in den Vereinigten Arabischen Emiraten sähen 2/3 die Nachbarn im Mittleren Osten mit Argwohn
  • in Australien sähe man Russland als größte Bedrohung (40%)
  • in Indien fürchtete man erstaunlicher Weise das Vereinigte Königreich (fast 1/3) deutlich mehr als China (14%)

Fazit

Mit zunehmender Aufklärung oder praktischer Konfrontation mit einem konkreten Problem steigt auch das Risikobewusstsein der Unternehmen. Dies untermauern auch die o.g. Beispiele von Brasilien und Australien. Nicht selten sind auch Kommunikationsprobleme zwischen IT-Bereich und Management die Ursache für mangelnde oder wenig sinnvolle Investitionen in die Sicherheit, was auch die Ponemon-Studie verdeutlicht.

In unseren Security Audits und Penetrationstests setzen wir theoretische Szenarien praktisch um und veranschaulichen damit, wie ein Angriff durch Insider, Hacker oder Schadsoftware ablaufen würde und welche Konsequenzen dies hätte. Hieran lassen sich die Effizienz vorhandener Sicherheitstechnik oder geplanter Anschaffungen praktisch erfassen und eventuell vorhandene Schutzlücken aufdecken. IT-Abteilungen können so Ihr Management effektiv von der Notwendigkeit einer Maßnahme überzeugen. Umgekehrt kann das Management den Nutzen der Maßnahmen der IT-Abteilungen direkt nachvollziehen. Nehmen Sie Kontakt mit uns auf, gerne beraten wir Sie individuell, schulen Ihre Mitarbeiter, oder geben verbindliche Gutachten (z.B. herstellerneutrale Produktvergleiche, Aufwand/Nutzen, Machbarkeit, Strategieempfehlungen) zu geplanten Maßnahmen ab.


Betrachtung und Kriterien

Die hier untersuchten Daten zu Marktanteilen stammen von OPSWAT (PDF , März 2011), die Leistungswerte von VirusBtn (April 2011) und NSS Labs (PDF , Q3-2010).

Pandasoft (Marktanteil 4,76%) und TrendMicro (Marktanteil 1,77%) tauchen bei VirusBtn aktuell nicht mehr auf und bleiben deshalb hier außer Betracht.

Kernkriterien

Die Erkennungsquote (Schutzumfang) ist sicherlich das wichtigste Kriterium für eine solche Lösung. Daneben spielen die Performance-Auswirkungen und die Bedienung eine Rolle, da sie ansonsten mangelnde Akzeptanz beim Endanwender finden und der Schutz vielfach torpediert wird. Laut einer Untersuchung von Avira schalten 25% der Endanwender Virenschutzlösungen einfach aus, wenn diese zu große Auswirkungen auf die Performance Ihres Systems zeigen .

"Reaktive" und "proaktive" Erkennung

VirusBtn differenziert bei der Erkennungsquote zwischen "reaktivem" und "proaktivem" Schutz, wobei sich "reaktiv" auf muster-("Pattern"-)basierte Erkennung bekannter Schadsoftware bezieht, und "proaktiv" auf die Erkennung unbekannter Schadsoftware durch verhaltens-basierte Verfahren oder generische Muster. Proaktive Erkennung ist besonders bei neuer Schadsoftware wichtig, da für diese häufig noch keine passenden Erkennungsmuster vorliegen. Verhaltens-basierte Erkennung, automatische Klassifikation oder händische Analyse durch Sicherheitsforscher sind auch die einzigen Wege, ein Programm überhaupt als Schadsoftware einzustufen, um anschließend Erkennungsmuster davon erstellen zu können. Die reaktive Erkennung kann (theoretisch) 100% aller (bekannten) Schadprogramme erreichen, während eine proaktive Erkennung von 100% (auch unbekannter) Schadprogramme unmöglich sein dürfte.

Platzierungen: Leistung und Marktanteile divergieren deutlich

  • Leistungswerte Virenscanner Oktober 2010 bis April 2011, Copyright www.virusbtn.com

    Lavasoft (Marktanteile Platz 10 mit 0,98%) mit Lavasoft Total führt punktgleich mit Coranti als quasi bedeutungslosem Hersteller (die Homepage weist weniger als 150.000 Downloads aus), Lavasoft Pro liegt im Mittelfeld (mehr dazu im Abschnitt Multi-Engine vs. Single-Engine Scanner)
  • weitere Spitzenplätze belegen Kaspersky PURE, Checkpoint und Trustport, dahinter folgen Avira Free und Pro, G-Data, ESET, F-Secure und Avast mit ähnlich guten Werten, etwas zurück in der Spitzengruppe liegen AVG, Kaspersky Internet Security, Microsoft Security Essentials, EmsiSoft und BitDefender
  • der einstige einsame MarktführerMcAfee (historisch >50% Marktanteil) liegt weit abgeschlagen im Mittelfeld mit Quoten gerade noch um die 75%, hat aber noch deutlich mehr Marktanteil als viele besser bewertete Produkte – solange der Marktanteil noch passt und die Milliarden von Intel fließen , ist die Produktentwicklung womöglich auch eher zweitrangig
  • Comodo, Fortinet, eEye, CA Business und Norman bilden die Schlusslichter des Hauptfeldes
  • Rising International und Kingsoft liegen weit abgeschlagen vom Feld

Multi-Engine vs. Single-Engine Scanner

Bringen mehrere parallel verwendete Erkennungssysteme ("Engines") Vorteile? Theoretisch ja – außer bei der Performance vielleicht.

  • Lavasoft Total kann sich zwar von Lavasoft Pro absetzen, dies hat jedoch wohl eher hausinterne, marktstrategische Gründe
  • Coranti liegt wie oben erwähnt punktgleich mit Lavasoft Total an der Spitze – dies ist wenig verwunderlich, verwendet es doch die Engines von Lavasoft Total (Anti-Spyware und Anti-Virus), BitDefender, und Frisk F-Prot parallel – durch die zwei zusätzlichen Engines kann es sich offenbar dennoch nicht von seinem Halbbruder Lavasoft Total absetzen

Business vs. Consumer

Sind Business-Lösungen sicherer als Consumer-Lösungen? Sie sollten es sein, da Unternehmen mutmaßlich einen höheren Schutzbedarf haben als Privatanwender – in der Praxis ist jedoch meist das Gegenteil der Fall.

  • CA Business (~60%/60%) liegt weit schlechter als CA Consumer (~80%/80%)
  • F-Secure Client (Business-Version) liegt ebenfalls hinter F-Secure Internet Security (Consumer)
  • Lediglich bei Microsoft lässt sich dieser Trend nicht eindeutig bestätigen – Microsoft Forefront (kostenpflichtig, Business) ist reaktiv etwas besser, Microsoft Security Essentials (kostenfrei, Consumer) ist proaktiv etwas besser. Zu Security Essentials liegt aber nur eine Messung vor; bei der wichtigeren reaktiven Technik scheint jedoch auch hier das Consumer-Produkt technologisch weiter fortgeschritten.

Was sind die Gründe für diese Schieflage? Bei der Anschaffung von Business-Lösungen wird primär auf die leichte Administration geachtet. Consumer-Lösungen sind zudem die größere Geldmaschine, weshalb die Hersteller diese vermeintlich primär fokussieren. Ein Vertriebler von Symantec beispielsweise hatte dies auch unverholen eingeräumt . Geld drucken scheint klar wichtiger zu sein als Orientierung an Kundenbedürfnissen. Meiner Meinung nach ist die Einteilung in Business- und Consumer-Produktlinien ohnehin ein großer Unsinn.

Kostenlose kontra kostenpflichtige Versionen

Erstaunlicherweise liefert das kostenlose Avira Free sowohl im reaktiven und proaktiven Bereich etwas bessere Ergebnisse als das kostenpflichtige Avira Pro. Avira Pro bietet jedoch erweiterte Funktionalität. Da dies unlogisch erscheint, haben wir Avira angeschrieben, worin dies begründet sein könnte, eine Antwort steht noch aus.

Bewertung, Kritik – und was die Zahlen nicht hergeben

  • man muss sich bewusst sein, dass sich je nach verwendeten Testmethodiken andere Zahlen ergeben ("Glaube keiner Statistik, die Du nicht selbst gefälscht hast")
  • zudem besteht durch solche Testverfahren die Gefahr, das sich AV-Hersteller um "gut auszusehen" einem solchen "künstlichen" Szenario anpassen, statt auf die real existenten Bedrohungen abzustellen – prominentes Beispiel in der Vergangenheit waren die Grafikkarten-Hersteller, die Ihre Produkte mehr für Benchmark-Programme optimiert haben, als für reale Anwendungsszenarien
  • alle Testmethodiken können lediglich bekannte Schadsoftware berücksichtigen; da viele Schadprogramme lange Zeit oder gar für immer "unter dem Radar" der AV-Hersteller bleiben werden, liegen die absoluten Werte in der Realität weiter unten auf der Skala
  • nahe am Ausbruch eines neuen Virus verschiebt sich zumindest die reaktive Erkennungsquote ebenfalls nach unten; da Cyberkriminelle ihre Schadsoftware i.d.R. auf Erkennung testen, wandert auch die proaktive Erkennungsquote auf oder Richtung null
  • der Durchschnitt der Erkennungsquote konzentriert sich bei ca. 80%; allein für den Testzeitraum von sechs Monaten bedeutet dies 1,98 Mio. neue, nicht erkannte Schadprogramme (bei ca. 55.000 neuen Viren täglich )
  • beim Exploit-Schutz sieht es lt. den Zahlen von NSS Labs noch schlechter aus: die Erkennungsquoten liegen hier bei gerade 75% beim besten Produkt, mehr als ein Drittel der getesteten Programme liegt gar unter 20%
  • NSS Labs kritisiert weiter, dass je nach Eintrittspunkt der Infektion (z.B. Web-Download oder Laden vom Fileserver) Schadsoftware erkannt würde oder eben auch nicht. Sie kritisieren ferner, dass je nach Produkt 10% bis 60% der Umgehungstricks ("evasion techniques"), die Cyberkriminelle typischerweise verwenden, gänzlich unbemerkt blieben. Zudem würden rein speicherresidente Schadprogramme von weniger als einem Drittel der Produkte erkannt, was gerade für besonders bedrohte Infrastrukturen, die sich eventuell sogar persistenten Angriffen ("Advanced Persistent Threats") gegenübersehen, ein zusätzliches Risiko darstellen dürfte.

Fazit

Virenscanner sind im Gegensatz zu verbreitetem Glauben nicht die "Ultima Ratio" in puncto Sicherheit. Sie stellen vielmehr lediglich einen Grundschutz dar und sollten je nach Schutzbedarf durch weitere Maßnahmen ergänzt werden. Nehmen Sie Kontakt mit uns auf, wir beraten Sie gerne.


Das (schwarze) Lamm

Bild (c) Don & Tonya Christner

Gestern berichtete heise online über aktuell aufgetauchte Sicherheitslücken in SCADA-Produkten . Luigi Auriemma hat eine Liste mit 35 Schwachstellen in SCADA-Produkten von SIEMENS Tecnomatix (FactoryLink ), Iconics (Genesis32 und Genesis64), 7-Technologies (IGSS ) und DATAC (RealWin ) veröffentlicht.

Der Löwe

Desweiteren hat Gleg Ltd. das Agora SCADA+ Pack herausgegeben, das neben öffentlich bekannten Sicherheitslücken auch 9 Zero-Day-Exploits enthält. Davon betroffen sind u.a. Produkte von Atvise , ClearSCADA , DataRate und InduSoft .

Der schlafende Drache

Im Januar dieses Jahres war die Sicherheitspolitik des Herstellers WellinTech, der die hauptsächlich im chinesischen Markt verbreitete Prozessvisualisierungs-Software KingView vertreibt, öffentlich in die Kritik geraten. Dieser wusste offenbar seit September letzten Jahres um die Sicherheitslücken in seinen Produkten. Erst die Veröffentlichung eines Exploits konnte den "schlafenden Drachen" dazu bringen, seine Sicherheitsprobleme zu beseitigen . Offenbar war jedoch nur ein Kommunikationsproblem dafür verantwortlich, dass der Fehler nicht früher beseitigt wurde. Inzwischen ist jedoch ein weiterer Exploit für das Produkt öffentlich geworden, zu dem es meiner Kenntnis nach keine Berichterstattung gibt. Auch der Status einer Fehlerbehebung ist unbekannt.

Der (ebenfalls schlafende?!) Dickhäuter

Die von uns entdeckten Sicherheitslücken in SIEMENS SIMATIC WinCC & PCS7 sind durch das Sicherheitsupdate (Stand SP1 von Ende Januar 2011) nach wie vor nicht geschlossen.

Advisory-Panne: Wenigstens hat man das völlig unübersichtliche Advisory bereinigt; dabei "bereinigt" wurde auch die neuste Version des Sicherheitsupdates, über die Seite ist nurmehr eine Vorgängerversion Stand Oktober 2010 erreichbar. Eine deutliches Indiz, dass der Hersteller in dem Chaos wohl selbst die Übersicht verloren hat.

Was lange währt wird ... schließlich doch nichts? Die Zeitspanne, mehr als ein halbes Jahr (Juni 2010 bis Januar 2011) an einem Sicherheitsupdate "herumzudoktoren", dass sich dann immer noch in 60 Sekunden umgehen lässt, stellt wohl eine traurige Rekordmarke dar.

Hack me, yes you can! Aber es kommt noch dicker: die Passwörter, die die Ausnutzung des WinCC-Datenbank-Bugs ermöglichen, sind nun wieder frei für jedermann in einem SIEMENS-eigenen Forum zu lesen - obwohl dieser Eintrag zwischenzeitlich bereits gesperrt war. Eine wirklich herausragende Glanzleistung.

Neuer Zero-Day Nebenbei bin ich -quasi zufällig- noch über eine weitere Zero-Day-Lücke durch einen gravierenden Design-Fehler in den Produkten gestoßen, die in unter 10 Minuten gefunden war. Wer sich mit dem Thema schon beschäftigt hat weiß, dass es normalerweise Stunden, Tage oder gar Wochen dauern kann (und sollte), solche Fehler zu finden.

Es bleibt abzuwarten, ob und in welcher Zeit diese Hersteller ihre Sicherheitsprobleme beheben. Falls Sie eines der o.g. Produkte einsetzen und um Ihre Sicherheit besorgt sind, wenden Sie sich gerne an uns. Wir können prüfen, ob Sie von den entsprechenden Lücken betroffen sind und ggf. Maßnahmen zur Beseitigung oder Abmilderung des Risikos anbieten oder ausarbeiten.

UPDATE 25.03.2011: Kaum geschrieben, schon sind weitere Lücken aufgetaucht: betroffen sind BroadWin (WebAccess ), CSE-Semaphore (T-BOX ) RTUs und Ecava (IntegraXor SCADA/HMI ). Während Ecava brav war, und einen Fix veröffentlicht hat, meint BroadWin offenbar auch, den Fehler verneinen zu können, woraufhin ein Exploit veröffentlicht wurde.

UPDATE 04.04.2011: In SIEMENS Tecnomatix FactoryLink sind weitere Lücken entdeckt worden, nur wenige Tage nachdem bei den oben angesprochenen nachkorrigiert wurde (ICS-CERT Advisory 11-091-01 , SIEMENS Advisory SSA-630126 , Updates ). Ob diese Updates die Mängel zuverlässig beseitigen, ist weder dem ICS-CERT noch uns bekannt, da uns weder die Software noch ein Auftrag zur Prüfung vorliegt. Details zu den neuen Lücken liegen noch nicht öffentlich vor.

Ebenfalls unbekannt ist, wie viele weitere Sicherheitsmängel sich noch in dem Produkt befinden. Es spricht schon Bände, wenn ein Sicherheitsforscher innerhalb von 2 Manntagen mit einfachsten Mitteln bereits 6 hochgefährliche Lücken entdecken konnte. Wenn dann aber kurz nach der Veröffentlichung eines Updates ein weiterer Forscher innerhalb von Minuten noch weitere gleich geartete Lücken findet, deutet dies m.E. auf generelle systemische Mängel im Sicherheitsmanagement hin. Bei Microsoft etwa ist es selbstverständlich, ähnliche Fehler im Zuge eines Updates ebenfalls zu beseitigen. Im README zum Update heißt es bezeichnend "this module is being made available AS IS WITH NO WARRANTY OF ANY KIND" – das macht Mut.

Interessanter Weise befindet sich der Link zum FactoryLink-Advice auch noch völlig unvermittelt inmitten des Stuxnet-Advisories , bei dem es ja um ein völlig anderes Produkt und um eine völlig andere Problematik geht. Womöglich ist das ein neues Kommunikationskonzept "Confusion redefined" ;-)

UPDATE 14.04.2011: Nun kommen auch noch das Honeywell ScanServer ActiveX Control (ICS-CERT Advisory 11-103-01 , Updates ) und das Invensys Wonderware InBatch Client ActiveX Control (ICS-CERT Advisory 11-094-01 , Invensys Security Bulletin LFSEC00000054 , Updates ) hinzu. Beide Fehler sind lt. ICS-CERT mit den vorgenannten Updates behoben. Die Nummerierung lässt erahnen, dass demnächst noch so einiges folgt...

UPDATE 19.04.2011: Iconics hat ebenfalls reagiert und schließt in Genesis32 und Genesis64 die 13 ursprünglich entdeckten sowie eine weitere, nachträglich entdeckte Sicherheitslücke (ICS-CERT Advisory 11-108-01 , Updates ). Das ICS-CERT konnte die korrekte Fehlerbeseitigung verifizieren.

UPDATE 21.04.2011: DATAC schließt die Sicherheitslücken in RealWin ebenfalls (ICS-CERT Advisory 11-110-01 , Updates ). Das ICS-CERT konnte die korrekte Fehlerbeseitigung verifizieren. Von den Problemen sei nur die Demo-Version betroffen gewesen.

UPDATE 26.04.2011: Gleg Ltd. hat das Agora SCADA+ Pack v1.1 herausgegeben, das neben Exploits zu einigen bekannten Lücken in SIEMENS Tecnomatix FactoryLink, Iconics Genesis32/Genesis64, 7-Technologies IGSS, DATAC RealWin und WellinTech KingView und einer ZeroDay-Lücke in Beckhoff TwinCAT ENI Server v1.1.6.0 enthält.

UPDATE 02.05.2011: 7-Technologies hat Updates zu IGSS veröffentlicht (ICS-CERT Advisory 11-119-01 , Updates ). Die Software kann auch über die Update-Funktion in der Applikation aktualisiert werden. Der Entdecker der Sicherheitslücke hat die korrekte Fehlerbeseitigung durch das Update bestätigt.


Die Hackercommunity "Anonymous" geriet im Zusammenhang mit den Angriffen auf Paypal , Visa, MasterCard und andere erstmals in den Fokus der Medien. Diese Angriffe erfolgten als Reaktion auf die Einstellung der Transaktionen für die Enthüllungsplattform WikiLeaks durch diese Unternehmen.

Die der US-Regierung nahestehende Sicherheitsfirma HBGary kündigte die angebliche Veröffentlichung der Klarnamen der Mitglieder der Hackercommunity an und wurde daraufhin selbst angegriffen . Dabei wurde die Website des Unternehmens Ziel eines sogenannten Defacements , über das gehackte Twitter-Konto von HBGary's CEO Aaron Barr wurden kompromitierende Nachrichten sowie das Dokument mit den angeblichen Mitgliedern verbreitet . Sämtliche Server des Unternehmens seien abkopiert und anschließend gelöscht worden.

Unter den entwendeten Daten befanden sich auch über 75.000 Emails, die zwei Schritten veröffentlicht wurden. Einige Quellen berichten, aus diesen Emails ginge hervor, HBGary sei unter anderem an der Vermietung von Botnetzen und der Entwicklung eines geheimen Rootkits mit dem Codenamen "Magenta" beteiligt, und habe versucht, die Untersuchung des Stuxnet Wurms zu behindern.

HBGary sei inzwischen 'untergetaucht' und habe seine Beteiligung an der RSA-Konferenz abgesagt . Die ehemaligen Kooperationspartner Palantir und Berico haben sich inzwischen von HBGary und den weiteren Plänen zur 'Unschädlichmachung' von WikiLeaks distanziert. Weitere Hintergründe bei heise online.

Als weitere Drohung hat Anonymous nun den Quellcode des Stuxnet Wurms für jedermann frei zugänglich ins Netz gestellt . Es ist damit leichter denn je, eine Neuauflage des Wurms in den Umlauf zu bringen. Die Veröffentlichung ist diesmal real und kein bloßes Gerücht .

Neue Sicherheitslücken, die zur Infektion von Systemen verwendet werden können, werden immer wieder bekannt, jüngst beispielsweise der bisher unbehobene Fehler in Windows-Dateifreigaben . Zudem sind alle SIEMENS PCS7 und WinCC Systeme unseres Wissens nach wie vor über die von uns entdeckten Sicherheitslücken angreifbar, mehr als ein halbes Jahr nach dem wir SIEMENS davon berichteten. Weitere Sicherheitsmängel wollte man sich bis heute nicht einmal anhören. Dennoch sind viele Kunden in der Industrie augenscheinlich erstaunlich entspannt.


BlackHat DC 2011 - "Master Offense"

Das sich Schadsoftware über Wechseldatenträger verbreiten kann, dürfte spätestens seit Stuxnet bekannt sein. Auch unter Linux war es möglich –entsprechende Fehlkonfiguration vorausgesetzt – Rechner durch bloßes Verbinden von USB-Geräten zu hacken .

Die Autostart-Funktion von Betriebssystemen wie Windows zu unterbinden ist nur die offensichtlichste und weithin bekannte Methode zur Linderung des Problems. Microsoft hat dem Problem inzwischen auch Rechnung getragen und die Autostart-Funktion teilweise zu Grabe getragen .

Im Falle des von Stuxnet bekannten 'LNK-Bugs' war auch das Deaktivieren der Autostart-Funktion nicht ausreichend. Zu viele Prozesse laufen implizit im System ab, die der normale Anwender nicht mitbekommt.

Nun haben Angelos Stavrou und Zhaohui Wang auf der BlackHat DC 2011 eine weitere Methode gezeigt, wie sich Rechner durch ein SmartPhone hacken lassen. Das SmartPhone gibt sich gegenüber dem Rechner als Tastatur (USB HID ) aus und kann so Kontrolle über den Rechner erlangen, ohne das der Benutzer eine Möglichkeit zum Eingriff hätte. Statt eines SmartPhones ließe sich auch ein winziges USB-Gerät bauen, das die gleiche Funktion erfüllen könnte.

Selbst eine Endpoint Protection Lösung verhindert diesen Angriff in der Regel nicht, da die Geräteklasse USB-HID normalerweise standardmäßig von allen Beschränkungen ausgenommen ist.

In sensitiven Umgebungen empfiehlt es sich deshalb wenn möglich USB oder andere Hot-Plug Schnittstellen generell abzuschalten. Alternativ lassen sich bei einigen Endpoint Security Lösungen – genauso wie für Wechseldatenträger – Seriennummern für erlaubte USB-HID-Geräte hinterlegen. Jedoch stellen leider nicht alle USB-Tastaturen Seriennummern zu Verfügung um dies zu ermöglichen. Eine Beschränkung auf Hersteller-ID und Typ-ID wird ohne jeden Wert sein, da ein Angreifer mit physikalischem Zugang sicher auch Hersteller und Typ der Tastaturen erkennen wird und somit alle nötigen Daten besitzt.


BlackHat DC 2011 - "Master Offense"

Obwohl ich mit der Berichterstattung sehr hinterher hinke, und noch nicht einmal alle Artikel zum 27. Chaos Communication Congress fertiggestellt habe, hier dennoch vorab der erste Kommentar zur gestern zu Ende gegangenen BlackHat DC 2011 Sicherheitskonferenz.

Wirklich ein 'Meisterwerk'?

Tom Parker erläuterte kürzlich , dass der Code von Stuxnet keinesfalls so ausgeklügelt sei, wie vielfach in den Medien berichtet. Für die aufmerksamen Leser dieses Blogs ist das nichts wirklich Neues; bereits im Oktober hatte ich beispielsweise berichtet , dass der Wurm über keine besonders ausgeklügelte Rootkit -Technologie verfügt und sich sehr leicht entfernen lässt.

Der Embedded Systems Security-Spezialist Nate Lawson kommentierte deshalb m.E. zu Recht, dass er entsprechende Techniken schon in den 90er Jahren von "bulgarischen Teenagern" gesehen hätte.

Anti-Forensische Maßnahmen nicht einmal durschnittlich

Wie Parker wiederum richtig ausführt, enthält Stuxnet zwar Code, um AntiVirus-Software auszutricksen, aber keine fortgeschrittenen Anti-Debugging-Routinen oder Tricks zur Code-Obfuscation , wie Sie heutzutage in fast jeder Malware gängig sind. Diese Tricks können eine Analyse des Programmcodes wesentlich erschweren und verzögern.

Lawson merkt weiterhin zu Recht an, dass Stuxnet keine fortgeschrittenen Design-Patterns wie 'Hash-and-Decrypt' verwendet, bei dem der Schlüssel zum Entpacken der 'Nutzlast' aus Umgebungsparametern zusammengesetzt wird, was eine Entschlüsselung somit nur auf dem tatsächlichen Zielsystem erlaubt hätte. Durch diesen 'Mangel' war es für jedermann leicht möglich, den enthaltenen SPS-Schadcode zu analysieren.

Ich ergänze dazu mal noch Folgendes:

  • Stuxnet installiert sich direkt nach dem Exploit des 'LNK'-Bugs, statt eine gewisse 'Inkubationszeit' einzuhalten, um den Infektionsweg zu verschleiern
  • bei der Installation werden ganz unverhohlen Registry-Keys wie "SOFTWARE\SIEMENS\WinCC\Setup" oder "SOFTWARE\SIEMENS\STEP7" abgefragt, womit die SIEMENS-Software sofort als Ziel ausgemacht werden kann. Ein ausgeklügelter Virus würde beispielsweise das 'Programme'-Verzeichnis listen, Hashes von den Namen der Verzeichniseinträge erstellen, und diese dann mit dem Hash der Zeichenkette 'Siemens' vergleichen. Letzteres Verfahren würde nicht in den ersten fünf Minuten der Analyse auffliegen.

Netzwerkkommunikation unterentwickelt

Parker führte auch aus, dass Stuxnet nur über eine vergleichsweise rudimentäre "Command & Control " Struktur verfüge und die Netzwerkkommunikation unverschlüsselt abliefe. Zumindest Ersteres kann ich so bestätigen.

Schlussfolgerung

Sowohl Parker als auch Lawson ziehen den Schluss, dass es eher unwahrscheinlich sei, dass ein westlicher Geheimdienst so dilettantisch seien würde. Es darf auch als unwahrscheinlich gelten, dass die Urheber eine Entdeckung des Wurms billigend in Kauf genommen hätten.

Entgegen dem viel diskutierten, aber wenig substanziierten Bericht der New York Times, die USA und Israel würden hinter Stuxnet stecken und SIEMENS habe unfreiwillig Schützenhilfe geleistet , und den ebensolchen Vermutungen Irans selbst , halte ich diese Theorie zumindest für wesentlich schlüssiger begründet, die der Autor Jeffrey Carr auch nochmals verteidigt hat .

Zumindest das Ziel des Angriffs dürfte in der Fachwelt mittlerweile weitgehend unstreitig sein.



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