Forensic Investigations / Fi Blog

Fi Blog

Da ich in letzter Zeit zum Thema Sicherheit so oft höre, "wir haben doch Virusscanner und Firewalls", möchte ich hier einmal grob auf den Themenkomplex Netzwerksicherheit/Firewalls eingehen und mit ein paar Mythen aufräumen. Zum Thema Virenscanner hatte ich ja bereits hier berichtet.

Das Hype-Thema der diesjährigen it-sa schlechthin waren die sogenannten "Advanced Evasion Techniques " (AETs), die in der Lage sind, fast alle Firewalls und Intrusion Detection Systeme auszuhebeln. Hype deshalb, weil viele dieser Techniken in Security-Kreisen längst bekannt sind, wie auch heise online im Artikel "Alarmanlagen fürs Netz weitgehend nutzlos " zu Recht anmerkt.

Dennoch ist die Kernaussage wahr, viele dieser Systeme lassen sich durch verschiedenste Tricks überlisten. Längst gibt es entsprechende Frameworks, die solche Techniken auf TCP/IP Ebene umsetzen und einfach nutzbar machen. Ist das verwendete System einem Angreifer zudem bekannt, kann dieser bequem vorher ausprobieren, ob es Alarm schlägt und wie das umgangen werden kann.

Statt Alarme zu vermeiden könnten diese ebenso auch in großer Zahl gezielt ausgelöst werden, damit der eigentliche Angriff durch all diese 'Nebelkerzen' nicht mehr oder nur noch schwer erkennbar ist.

Die Krux für Firewalls mit Content Filtern oder Intrusion Detection Systeme ist grundsätzlich, dass diese lediglich auf nicht zugelassene Protokolle/Quellen/Destinationen oder bekannte Signaturen reagieren und entsprechend einen Angriff melden können. Dies ist analog zu Antivirus-Produkten , die auch nur auf Signaturen bekannter Bedrohungen zuverlässig reagieren können. Heuristiken existieren zwar in den meisten Produkten, aber diese können schwerlich alle möglichen Varianten abdecken – zumal sie keine zu großen Auswirkungen auf das Laufzeitverhalten der Systeme haben dürfen und nicht zu viele Fehlalarme auslösen dürfen. Durch vorherige Tests und entsprechende Abwandlung lassen sie sich meist zuverlässig umschiffen.

Beispielsweise verwenden die meisten Botnetze oder Trojaner von Haus aus HTTP zur Steuerung, das in fast allen Umgebungen als legitimer Datenverkehr betrachtet wird, und sich so auch meist nicht ohne Weiteres blocken oder als bößartig einstufen läßt.

Firewalls verhindern Angriffe nicht, sie vermindern lediglich die Angriffsfläche. Zwar können sie einige Dienste von der Außenwelt abschotten, dennoch verbleiben immer mindestens die unverzichtbaren Dienste wie beispielsweise Web oder Email als Angriffsfläche. Sicherheitslücken in der entsprechenden Software werden dort auch durch Firewalls nicht kompensiert. Solche Lücken bleiben immer wieder , wenn dies auch teilweise nur für ein relativ kurzes Zeitfenster zutrifft. Ein SQL-Server wird zwar normalerweise nicht vom Internet aus zugänglich sein, könnte aber dennoch kompromitiert werden, wenn eine Schadsoftware auf anderem Wege ins interne Netz gelangt, populäres Beispiel war 2003 der SQL Slammer .

Auf die weiteren Fakten, beispielsweise dass Firewalls meistens nicht ausreichend parametriert sind, und i.d.R. alle ausgehenden Verbindungen zulassen, sowie die Tatsache, dass auf kompromitierten Hosts befindliche Firewalls von üblicher Malware neutralisiert werden, will ich hier – um nicht wieder völlig den Rahmen zu sprengen – gar nicht mehr im Detail eingehen.


Vereinbaren Sie jetzt einen Termin für die SPS/IPC/DRIVES Messe 2010 , die dieses Jahr vom 23. bis 25. November im Nürnberger Messezentrum stattfindet. Gerne erläutere ich Ihnen dort, wie sich die hier im Blog geschilderten Sicherheitslücken in Automatisierungssoftwarelösungen auswirken können und diskutiere Lösungswege mit Ihnen persönlich.

Ein paar Termine sind kurzfristig noch zu vergeben. Ich freue mich sehr auf ein persönliches Kennenlernen.

UPDATE 26.11.2010: Vielen Dank an alle für die interessanten und konstruktiven Gespräche auf der Messe!

Ein paar Aufnahmen von der diesjährigen SPS/IPC/Drives:

Der Stand von Vacon in Halle 1

Frequenzumrichter Vacon NX Serie

Frequenzumrichter Vacon NX Serie (Nahaufnahme)

Siemens glänzte mit einem riesigen Stand in Halle 2 ...

...zumindest für Präsentation ist offenbar immer Geld genug vorhanden.

Eine Bildgalerie mit weiteren Impressionen von der Messe finden Sie hier:


Die Datenbanksicherheitslücke in WinCC (Video 2.1) ist offenbar nicht in jeder Situation von Remote ausnutzbar. Unter Windows XP ist der TCP-Port des SQL-Servers in der Standardkonfiguration durch die Windows-Firewall geschützt, was die Ausnutzung des Konfigurationsfehlers zumindest von aussen verhindert.

Wurde der Port jedoch geöffnet, beispielsweise um mit einem ERP-System auf die Daten zuzugreifen, ist besondere Vorsicht geboten.

Unter Windows XP scheint die Datenbanksicherheitslücke deshalb normalerweise 'nur' zu einer lokalen Privilegieneskalation (EoP) zu führen. Unter den vielen noch laufenden älteren Windows 2000-Systemen, die aufgrund der dort noch nicht standardmäßig vorhandenen Windows-Firewall normalerweise ungeschützt sind, kann die Lücke von Remote ausnutzbar sein.

Bewertung

Unter Windows 2000 muss die Lücke nach wie vor als 'kritisch' eingestuft werden, da standardmäßig kein Firewall installiert ist, was sie von Remote ausnutzbar machen könnte. Unter Windows XP ist die Gefahr immer noch als 'hoch' anzusehen, da sie einem Angreifer Administrator-Rechte verschaffen könnte. Ursache für das Problem sind die in beiden Fällen mit vollen 'sysadmin'-Rechten ausgestatteten Benutzer "WinCCAdmin" und "WinCCConnect". Dies entspricht wohl nicht der üblichen 'Best Practice' oder den Empfehlungen von Microsoft . Da der primäre Infektionsweg von Stuxnet ('LNK-Bug') geschlossen ist, besteht zumindest durch die bisher bekannten Varianten keine akute Gefahr.

Vorsichtsmaßnahmen

Überprüfen Sie unbedingt, ob der SQL-Server TCP-Port auf Ihren Systemen von außen erreichbar ist. Eventuell können Sie den Zugriff auf diesen Port auf dem System oder zumindest auf einer vorgelagerten Hardware-Firewall blockieren, um die Angriffsfläche zu vermindern. Falls bei Ihnen keine SQL-Kommunikation über TCP/IP stattfindet, können Sie mit dem SQL Server-Konfigurations-Manager auch die Bindung des SQL-Servers an TCP/IP entfernen. Achten Sie in jedem Fall darauf, eventuell erforderliche Kommunikation nicht zu blockieren.

Wenn Sie den Port nicht schließen können, beschränken Sie den Zugriff auf die Systeme, die tatsächlich Zugriff benötigen (z.B. ERP/BI Serversystem(e) statt ganzem Subnetz).

Achten Sie sorgfältig darauf, keine infizierten Rechner oder Datenträger in Ihr Netzwerk einzuschleppen.

Weitere Informationen auch zur Codeausführung beim Öffnen von Projekten (Video 2.2) folgen in den nächsten Tagen. Sie können auch unseren RSS-Feed nutzen, sich registrieren und über Änderungen benachrichtigen lassen , oder persönlich mit uns in Kontakt treten. Demnächst hier auch ein SCADA-Security-Forum.

UPDATE 10.12.2010: Weitere Informationen zur Codeausführung beim Öffnen von Projekten finden sie hier .

WinCC Datenbank-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 Windows 2000: 8.9 /10
  • CVSS Overall Score Windows XP (SQL Server Port closed=default): 8.4 /10
  • CVSS Overall Score Windows XP (SQL Server Port open): 8.7 /10

Im Zuge der Auswertung der Stuxnet-Angriffe auf SIEMENS SIMATIC WinCC und PCS7 haben Kaspersky Labs und Symantec weitere Lücken entdeckt, die von Stuxnet ausgenutzt werden . Microsoft hat die Lücken bestätigt .

Dazu gehört der über das Netzwerk ausnzutzbare Fehler im Druckerwarteschlangendienst von Windows (CVE-2010-2729 /MS10-061 ), der mit dem September-Bulletin geschlossen wurde, sowie zwei weitere lokal ausnutzbare Lücken (Laden von Tastaturlayout Definitionsdateien, Taskplaner), die einem Angreifer höhere Rechte verschaffen und höchstwahrscheinlich mit dem Oktober-Bulletin am Dienstag geschlossen werden. Die Lücke beim Laden von Tastaturlayout Definitionsdateien (CVE-2010-2743 /MS10-073 ) wurde mit dem Oktober-Bulletin geschlossen, die weitere Lücke steht noch offen im Taskplaner (CVE-2010-3338 /MS10-092 ) wurde nunmehr mit dem Dezember-Bulletin geschlossen.

Ineffiziente Incident Response

Der SIEMENS Security Advice zu Stuxnet geht auf die nicht-ganz-so-neu bekannt gewordenen Fakten leider in keinerlei Hinsicht ein, alte Falschinformationen wurden immer noch nicht entfernt.

Der mittlerweile lange bekannte Bug (CVE-2010-2772 ) wird durch das dort angebotene 'SIMATIC Security Update' weiterhin ebensowenig beseitigt wie die von Forensic Investigations entdeckte weitere Datenbank-Lücke in WinCC (siehe Video 2.1 "Remote-Einbruch in die WinCC-Datenbank" am Ende dieses Artikels ).

Analysen haben ergeben, dass das sog. 'Sicherheitsupdate' neben der –wie im Video zu sehen– völlig unzureichenden Datenbank-Konfigurationsänderung rein gar nichts aktualisiert, sondern lediglich ein 'getarntes Desinfektions-Tool' oder ein Placebo zur Beruhigung der Kunden darstellt.

Neben diesen uns lange bekannten Mängeln, die neben Anderen, bisher nicht näher spezifizierten Sicherheitslücken bereits Ende Juli von unserer Seite an die SIEMENS AG kommuniziert wurden, kommt nun noch eine weitere von uns Mitte August aufgedeckte Sicherheitslücke dazu.

2 Stunden 200€ Software Audit von Fi bringt weitere gravierende Mängel ans Tageslicht

Ein Software Audit von weniger als 2 Stunden (entspricht Kosten <200€) konnte weitere offensichtliche Mängel zutage fördern, die Projekte infizieren können. Sowohl SIEMENS SIMATIC WinCC als auch PCS7 und weitere Tools aus der Produktfamilie sind davon betroffen. Dies führt dazu, dass Infektionen ohne Weiteres von Engineering Stationen mit Internetzugang an Anlagen-PCs ohne Internetverbindung weitergetragen werden können. Die Auswirkungen sind also durchaus mit denen des "LNK-Bug" vergleichbar, diesmal allerdings liegt die Ursache dafür einzig und allein im Verantwortungsbereich des Automatisierungsherstellers (siehe Video 2.2 "Code-Ausführung beim Öffnen eines WinCC-Projekts" am Ende dieses Artikels ). 'Proof of Concept' Demo Exploits sind auf Anfrage bei uns erhältlich führen wir Ihnen auf Anfrage vor.

Die Legende vom "Inselnetz"

Die Mär vom "Inselnetz" dürfte damit wenigstens für etwas vorausschauende Menschen ein für alle mal widerlegt sein. Selbst auf Inseln läßt man Goldschätze nicht einfach achtlos herumliegen, da es Wasserfahrzeuge, Fluggeräte und Brückenbau gibt. Diese Wasserfahrzeuge, Fluggeräte und der Brückenbau sind in unserem Beispiel Wechseldatenträger, das Roaming von Engineering Stationen, Remote Access Lösungen u.ä. Das nächste Desaster ist schon vorprogrammiert, wenn hier kein grundlegender Mentalitätswechsel stattfindet.

Sicherheit - oft ein menschliches Problem, kein technisches oder betriebswirtschaftliches

Klar hatte bereits Mark Twain (1835-1910) erkannt, dass ein Dutzend verlogener Komplimente leichter zu ertragen seien als ein einziger ehrlicher Tadel, aber es führt kein Weg daran vorbei, sich den Realitäten zu stellen. Wo Menschen arbeiten passieren Fehler, auch bei Weltfirmen.

Die Gründe dafür können vielfältig sein: Zeitdruck, Mangel an Wissen, fehlende Sorgfalt, organisatorische Defizite oder Beratungsresistenz sind nur einige der möglichen Ursachen.

Selbst wenn die gemachten Fehler als trivial und leicht vermeidbar einzustufen sind, ist es nicht unbedingt gleich als töricht einzustufen, solche Fehler zu begehen. Die wirkliche Torheit beginnt erst an dem Punkt, an dem man auf die Fehler aufmerksam gemacht wird und trotz minimalster Kosten nicht handelt, vermeintlich um sich keine Blöße zu geben. Dies birgt jedoch neben hohen Schadenersatzrisiken das Risiko eines irreparablen Vertrauensverlustes bei den Kunden.

Nahezu alle großen Hersteller haben hier mittlerweile Ihre Lektionen gelernt, sieht man einmal von Apples CEO Steve Jobs ab, der das Empfangsproblem beim iPhone unter "no issue" verbuchte und statt einer Problemlösung lieber kritische, aber wohl wahre Forumsdiskussionen löschen ließ .

Do your homework – the OTHER SIDE WILL

Bei all diesen Nachforschungen haben wir aus Kostengründen nur ein kleines bisschen an der Oberfläche gekratzt. Mit einem Etat wie es die Urheber des Stuxnet Wurms wohl hatten – ich schätze die Kosten für den Angriff auf mindestens 200.000€, 0days am Schwarzmarkt und Programmierkosten zusammen – lassen sich sicher Unmengen von Bugs aufdecken. Uns hat schon ein Tausendstel davon gereicht, um einen solchen kritischen Bug zu finden. Die Beseitigung der Mängel ist alternativlos, und von einer Person jeweils innerhalb eines Tages ohne Probleme zu erledigen – inklusive Kaffeepausen und Meetings. Ein einziges Problem durch einen Sicherheitsmangel kostet sicher ein Zigfaches. Und ein solches Problem wird kommen, da Cyberkriminelle SCADA und ICS Netze spätestens jetzt als lukratives Ziel erkannt haben dürften. Mehr zum Thema finden Sie auch in unserer Präsentation "SCADA and Industrial Control Systems (ICS) network security in 2010 ".

Die Automatisierungshersteller sollten womöglich eine Prämie von sagen wir 20.000€ pro gefundenem Bug zahlen – wenn sie Ihrer Software nur ein bisschen vertrauen. Selbst Mozilla oder Google zahlen hier 5.000€ für gefundene Fehler in Ihren Browsern – diese verteilen Ihre Software im Unterschied dazu aber kostenlos und sind in deutlich weniger sicherheitsrelevanten Bereichen beheimatet.

Um es mit den fachfremden, aber auch hier zutreffenden Worten von Phil Taylor zu formulieren:
"If you don't practice every day, the others will".

Maßnahmen

Als minimalstes Minimum sollte neben dem Update zum LNK-Bug unbedingt das schon o.g. Druckerwarteschlangendienst-Update (CVE-2010-2729 /MS10-061 ) eingespielt werden, das der Automatisierungshersteller offiziell autorisiert hat , aber leider nicht im Zusammenhang mit Stuxnet empfiehlt. Dies ist jedoch nur eine punktuelle Maßnahme.

Wie schon in einem vorigen Post berichtet fanden wir jeweils viele Dutzend Lücken, die ebenso als kritisch einzustufen waren. Ich kann allen Kunden, die kritische Infrastrukturen mit SIEMENS SIMATIC WinCC und PCS7 betreiben deshalb nur weiterhin dringendst anraten, Ihre Netze von einer neutralen Instanz auditieren zu lassen und entsprechende Maßnahmen zu ergreifen, die Gefahren für industrielle Systeme nachhaltig ausschließen .

Daneben gibt es ein "Hintertürchen" in Stuxnet, das die Infektion eines Rechners durch die gegenwärtig bekannten Varianten verhindert. Auf Anfrage stellen wir Ihnen gerne Informationen dazu bereit, um Ihre Systeme zu schützen.

Es bleibt abzuwarten, ob der Automatisierungshersteller nun nach fast 3 Monaten endlich reagiert, die Lücken schließt und vor Allem solche Vorfälle durch eine geeignete Maßnahmen nachhaltig verhindert. Unsere Lösungen hierfür liegen seit Jahren auf Halde, da sie [wie man sieht] "nicht benötigt" werden.

UPDATE 13.10.2010: Informationen zum Oktober-Patchday im ersten Absatz ergänzt.

UPDATE 03.11.2010: Wir hatten uns zwischenzeitlich dazu entschlossen aus Sicherheitsgründen die 'Proof of Concept' Demo Exploits erst herauszugeben, wenn ein entsprechender Fix verfügbar ist, Text oben entsprechend abgeändert.

UPDATE 22.11.2010: Inzwischen ist ein öffentlicher Exploit zu der Privilegieneskalation im Taskplaner erschienen. Dies war zu erwarten, da ESET ausreichend Informationen veröffentlicht hatte, um die Lücke nachvollziehen bzw. implementieren zu können. Es bleibt zu hoffen, dass dieser Bug im Zuge des nächsten 'Patch Tuesday' am 14.12. geschlossen wird.

UPDATE 14.12.2010: Die Privilegieneskalation im Taskplaner ist als nunmehr letzte von Stuxnet genutzte Sicherheitsanfälligkeit geschlossen. Entsprechende Informationen zum Dezember-Patchday im ersten Absatz ergänzt


Möglicher Hintergrund: Angriff auf iranisches Atomprogramm!?

Die Spekulationen mehrten sich in den letzten Wochen, Stuxnet sei vermeintlich ein Angriff auf das iranische Atomprogramm , vor allem geschürt durch Frank Riegers Artikel bei FAZ.NET . Rieger stellt darin die Aussage auf, Stuxnet sollte sich bereits im Januar 2009 selbst deaktivieren und sei schon lange vorher im Umlauf gewesen. Entsprechende Belege, Quellenangaben oder wenigstens Indizien fehlen aber leider. Aus anderen Quellen oder eigenen Nachforschungen kann ich diese Aussage nicht bestätigen, obwohl ich alle Berichte zu diesem Thema seit dem Bekanntwerden Mitte Juli akribisch sammle und auswerte.

Ebensowenig geht Riegers Artikel darauf ein, dass Steuerungen in Kernkraftwerken normalerweise nach dem SIL4 Standard gemäß DIN/EN/IEC 61508 ausgerichtet sind, und sich nur in einem manuell zu schaltenden Modus reprogrammieren lassen. Der Wurm würde jedoch automatisch abwarten, bis die Steuerungen in diesen Modus versetzt werden, und dann seinen Schadcode in die Steuerungen implantieren. Bei einem der mutmaßlichen Ziele, dem Kernkraftwerk in Buschehr (Google Maps ), das demnächst ans Netz gehen soll , dürfte dies während der Inbetriebsetzung in den vergangenen Monaten sicher recht häufig der Fall gewesen sein.

Ein IT-Experte des Ministeriums für Industrie und Bergbau erklärte gegenüber der iranischen Agentur Mehr News Agency , insgesamt seien über 30.000 Rechner von Industrieanlagen allein im Iran befallen worden (Wirtschaftswoche , Handelsblatt , Financial Times Deutschland , Welt , Spiegel Online u.a. hatten daraufhin berichtet).

Mehr News Agency hat inzwischen ergänzt , dass sich die Inbetriebnahme des Kraftwerks Buschehr verzögere, dies hinge laut dem Chef der iranischen Atomenergiebehörde Atomic Energy Organization of Iran (AEOI) jedoch nicht mit Stuxnet zusammen.

Stuxnet ein Machwerk des Mossad?

Ob der Angriff nun durch internationale Dienste ausgeführt wurde und tatsächlich dem iranischen Atomprogramm galt, bleibt weiter im Bereich der Spekulation. Die Darstellung, lediglich Nationalstaaten hätten die Resourcen, einen solchen Angriff zu implementieren, greift m.E. aber etwas zu kurz: Mitbewerber, Kriminelle oder Terrororganisationen wären sicher ebenso zu einem solchen Angriff in der Lage, selbst wenn die Kosten in Millionenhöhe gelegen haben sollten und hätten ebenso ein Motiv.

Die Gerüchteküche wurde noch zusätzlich angeheizt, da der Code von Stuxnet das vermeintliche Datum "19790509" enthält. Am 09. Mai 1979 wurde der Präsident der "Jüdischen Gesellschaft Teherans", der jüdisch-iranische Industrielle Habib Elghanian , von einem Erschießungskommando in Teheran hingerichtet. Dies kann auch ein reines Ablenkungsmanöver sein; in der Regel hinterlassen Autoren von Schadsoftware kaum absichtlich Hinweise, die auf Ihre Spur führen.

...oder doch von Cyberkriminellen?

Da Stuxnet befallene Rechner unter die Kontrolle der Angreifer bringt, und prinzipiell jeden beliebigen Code ausführen kann, halte ich einen 'opportunistischen' Ansatz des Angriffs ohne ein konkretes Ziel ebenfalls für sehr wahrscheinlich: erstmal infizieren, dann sehen wen man erwischt hat, und was man für Vorteile daraus schlagen kann. Wäre der Angriff 100% auf Iran gerichtet gewesen, hätte der Wurm womöglich auf die Infektion anderer Anlagen verzichtet, um das Entdeckungsrisiko nicht unnötig zu erhöhen. Ebenso könnte dies jedoch eine Ablenkungsstrategie sein, die das eigentliche Ziel verschleiern soll.

Gegen die Theorie von Cyberkriminellen als Urheber spricht die Tatsache, dass die von Stuxnet verwendete Rootkit -Technologie nicht besonders ausgeklügelt ist. Womöglich hat der Angreifer sich hier auf ein sehr laxes Management der Anlagen-Software verlassen. Das Stuxnet noch den eigentlich uralten Fehler im Server-Dienst (MS08-067 /'Conficker '-Bug) auszunutzen versucht, spricht ebenfalls dafür.

Ebenso ist der Wurm im Vergleich zu anderen im Umlauf befindlichen Schadprogrammen auch sehr leicht zu entfernen. Der Urheber hat offensichtlich damit gerechnet, dass die Mission vor dem Bekanntwerden der Schadsoftware erfolgreich abgeschlossen sein würde, und er sich nicht vehement gegen seine Entfernung zur Wehr setzen müsste.

Die insgesamt vier in Stuxnet enthaltenen Zero Day Exploits legen aber zumindestens Kontakte zur Cybercrime-Szene nahe.

Besonders interessant ist auch die Tatsache, dass der Urheber von Stuxnet einen Mechanismus geschaffen hat, der die Infektion bestimmter Systeme durch ein 'Hintertürchen' verhindert. Es wäre hochinteressant zu wissen, wo dieses schon lange Zeit im Umlauf ist. (Weitere Informationen, wie Sie dieses Hintertürchen zu Ihrem Schutz vor Stuxnet nutzen können erhalten Sie auf Anfrage bei uns.)

Was die vermeintlich gestohlenen Zertifikate betrifft, mit denen die Dateien von Stuxnet signiert sind, wurden beide betroffenen Zertifikate von der US-Firma VeriSign ausgegeben. Statt dem Diebstahl der Zertifikate könnte man -wenigstens theoretisch- auch die Ausgabestelle dazu bringen, Kopien der ausgestellten Schlüssel herauszugeben ('persuade'/überreden, 'compel'/zwingen). VeriSign verdient neben den Zertifikatsdiensten hauptsächlich an Überwachungsdiensten für Behörden nach dem Communications Assistance for Law Enforcement Act (CALEA) , die von vielen Telekommunikationsanbietern an das Unternehmen ausgelagert wurden. Man sagt dem Unternehmen auch deshalb sehr enge Kontakte zur amerikanischen Regierung nach.

Stuxnet-Epidemie in China

Inzwischen ist auch China unter den Opfern von Stuxnet, das einige wohl ebenfalls im Kreise der verdächtigen Urheber des Wurms sehen oder sahen. Chinesischen Medienberichten zufolge seien im Land Millionen von Rechnern und nahezu 1000 Industrieanlagen befallen, berichtete Heise Online. Laut der South China Morning Post wolle die Regierung eine landesweite Untersuchung von Anlagen mit Siemens-Software durchführen und weitere Aufträge an Siemens prüfen.

Belastbare Zahlen zu den Infektionen in China liegen jedoch nicht vor. Jedenfalls dürfte die von SIEMENS immer wieder genannte Zahl von 15 Infektionen fernab der praktischen Realität liegen. Bei genauerem Hinsehen zeigt sich weiterhin, dass es sich hierbei nur um die Anzahl der bei SIEMENS gemeldeten Infektionen handelt, die auch niemand tatsächlich nachvollziehen kann.

Fazit

Viele Spekulationen über die Urheberschaft von Stuxnet wurden angestellt, einige davon sind sicher falsch, gänzlich unbelegt oder rein in die Irre führend, es verbleiben jedoch mehrere gleichermaßen tragfähige Theorien. Dementsprechend läßt sich im Augenblick weder der Urheber des Angriffs, noch ein definitives Ziel mit sehr hoher Wahrscheinlichkeit festmachen.

Lediglich eines ist sicher: sowohl Betreiber kritischer Infrastrukturen als auch Automatisierungshersteller müssen dringend handeln und solche Risiken nachhaltig in den Griff bekommen. Lösungen existieren, der Handlungsbedarf wurde praktisch aufgezeigt. Einfach nur Abwarten ist womöglich die schlechteste aller möglichen Strategien.

UPDATE 21.10.2010:The Registerberichtete unter Bezug auf iranische Quellen , eine als 'nuclear spies' bezeichnete Personengruppe wäre im Iran verhaftet worden, die jedoch lt. Angaben des iranischen Geheimdienstministers Heidar Moslehi in keinerlei Verbindung mit Stuxnet stünden.

UPDATE 16.11.2010: Laut Informationen von Symantec scheint es sich bei der von Stuxnet gesuchten besonderen Konfiguration um 6ES7-315-2 Steurungen zu handeln, die über CP 342-5 Profibus Kommunikationsmodule und Frequenzumrichter der Typen KFC750V3 (Profibus Geräte-ID: 7050h, Hersteller: Fararo Paya - Teheran, Iran) und Vacon NX (Profibus Geräte-ID: 9500h, Hersteller: Vacon AG - Vaasa, Finnland) mindestens 33 Wechselstrommotoren ansteuern.

Diese Frequenzumrichter unterlägen lt. Symantec der Exportkontrolle der Atomenergiebehörde, da sie u.a. zur Ansteuerung von in der Uran-Anreicherung verwendeten kaskadierte Gaszentrifugen verwendet werden könnten. Die Minimalzahl und die hohe Drehzahl der Motoren (807-1210 Hz bzw. 48420-72600 U/min), die Stuxnet sucht und die Art und Weise, wie diese manipuliert werden, könnte ebenso darauf hindeuten. Daneben gibt es im Bereich der Ultrazentrifugation noch Anwendungsgebiete in der Biochemie. Falls ein Leser weitere Einsatzszenarien solcher schnell drehender Motoren in tagelang dauernden Prozessen kennt, bitte ich um Mitteilung .

UPDATE 10.12.2010: Im Gegensatz zu Symantecs Analyse, die anführt weiterer Schadcode für 6ES7-417 Steuerungen sei abgeschaltet oder nicht vollständig schreibt Ralph Langner in seinem Blog, dieser Code könnte dazu dienen, 1000 Megawatt Turbinen des Typs K-1000-60/3000-3 (Hersteller: Power Machines – Moskau, Russland) in Buschehr zu sabotieren, sofern diese nicht über entsprechende Schutzschaltungen verfügten, oder sich gegen eine übergeordnete Schaltung zur Kaskadierung von Gaszentrifugen richten. Zumindest eine Turbine des o.g. Typs scheint in Buschehr zu laufen .

UPDATE 10.12.2010: Bei Anschlägen auf zwei Atomphysiker im Iran sei einer der beiden Physiker getötet worden .

Mehrere Quellen meldeten , Irans Präsident habe mittlerweile bestätigt, dass Stuxnet "begrenzte" Schäden an den Gaszentrifugen in Natanz angerichtet habe, dies aber "nun nicht mehr möglich" sei. Iran ist bezüglich seines Atomprogramms mittlerweile auch an den Verhandlungstisch zurückgekehrt .

Die 'Cablegate ' Veröffentlichungen erweitern die Liste der Staaten, die ein potentielles Interesse an der Beendigung des iranischen Atomprogramms gehabt haben könnten.

UPDATE 20.01.2011: Weitere Nahrung für Spekulationen hier und hier .


Es hat in der Vergangenheit viele Warnungen gegeben, SCADA -Netze besser zu managen, adäquat zu sichern und deren Integrität sicherzustellen, u.a. auch von uns . Mehrfach und seit Jahren weise ich auf die Gefahren hin, bis an höchste Stellen bei SIEMENS. Obwohl den Verantwortlichen eine vollständige Studie zum kompletten LifeCycle-Management der Anlagen vorliegt, die das bisherige Verfahren im Detail mit möglichen Alternativen vergleicht hat SIEMENS diese bis ins Detail durchdachten Empfehlungen leider nicht aufgegriffen, was sich nun im Nachhinein wohl als gravierender Fehler erwiesen hat.

Traditionell herrscht im SCADA-Umfeld geringe Security Awareness, da sich der Mythos vom "Inselnetz" trotz gegenteiliger Erfahrungen und diverser Studien hartnäckig zu halten scheint.

Der beinahe-GAU

Nun ist es gekommen wie es kommen mußte und auch prophezeit war: seit einigen Wochen ist bekannt, dass ein Wurm kursiert, der gezielt die SIEMENS SCADA/Industrial Control Systeme SIMATIC WinCC und PCS7 befällt .

Dieser hat sich u.a. über den sog. "LNK-Bug " (CVE-2010-2568 , Microsoft Security Bulletin MS10-046 ) verbreitet, bei dem es genügt, ein Verzeichnis mit einer speziell manipulierten Verknüpfung zu öffnen(!) um den Exploit auszulösen. Der somit gestartete Schadcode installiert ein Win32.Stuxnet genanntes Rootkit . Findet der Wurm ein SIMATIC System, manipuliert er dieses inklusive dessen Microsoft SQL Server Datenbank und infiziert gezielt alle Projektdateien, um sich auch auf diesem Wege weiter zu verbreiten. Ansonsten infiziert er erreichbare Laufwerke.

Hartcodierte Passwörter und Datenbank-Bugs

Da die Benutzerkonten und Passwörter für die WinCC MSSQL-Server Datenbank hartcodiert d.h. weltweit in allen Anlagen konstant sind (CVE-2010-2772 ), und zudem seit vielen Jahren in SIEMENS-eigenen Foren öffentlich zu lesen waren , ist der Angriff auf die Datenbank besonders leicht. Zumindestens einen dieser Beiträge hat SIEMENS -nach entsprechender "Bedenkzeit"- mittlerweile vom Netz genommen, Belege dafür liegen uns jedoch vor. Zusätzlich haben wir einen weiteren gravierenden Fehler in der Datenbankkonfiguration gefunden, der bis jetzt nach unseren Informationen nicht öffentlich bekannt ist, und eine eigene CVE-Nummer bekommen müßte. Auf unsere Hinweise dazu reagierte SIEMENS bisher jedenfalls nicht mit der Beseitigung der Fehler.

Unzureichendes Update und Fehlinformationen

Das von SIEMENS veröffentlichte SIMATIC Security Update (aktuell: v1.0.0.11 vom 18.08.2010) ist unzureichend, behebt BEIDE Fehler nicht, und verhindert auf älteren Anlagen u.U. noch nichtmal die Weiterverbreitung des Wurms über Projektdateien. Neben der sehr unübersichtlichen Struktur des dazugehörigen Security Advice sind darin auch noch gefährliche Falschinformationen enthalten:

  • "Um eine solche Infektion zu verhindern, wird dringend empfohlen, dass die Anwender nur über Hauptbenutzer-Rechte verfügen. Ein Hauptbenutzer hat nicht die nötigen Rechte, um Code von einem anderen Laufwerk zu starten". (Hervorhebungen durch den Autor)

Wenig Reaktion auf dramatische Probleme, Entdeckung lange später reiner Zufallsfund

Auf diese Hinweise mit dem Zusatz, dass neben diesen drei Sicherheitslücken noch mehr als ein Dutzend weitere vorhanden sind -Sie ahnen es- keine ernsthafte Reaktion.

Durch das von uns seit Jahren angeprangerte fehlende Sicherheits- und Integritätsmanagement wurde der Virusbefall noch nicht einmal von SIEMENS selbst festgestellt, sondern durch Frank Boldewins Zufallsfund bei der Analyse einer Malware, der durch die Presse ging .

Der Wurm soll mindestens seit über einem Jahr (Juni 2009) unbemerkt in mehreren Varianten kursieren und lt. neuesten Informationen sogar SPS -Systeme mit einem Rootkit infizieren und nebenbei auch die 'Conficker'-Sicherheitslücke (MS08-067 ) zur Verbreitung nutzen können.

Da die Reaktion des Herstellers aus meiner Sicht punktuellen Aktionismus statt einer nachhaltigen Problemlösung darstellt, kann ich allen SIEMENS SIMATIC WinCC und PCS7 Nutzern nur dringend empfehlen, Ihre Netze von einer neutralen Instanz auditieren zu lassen und entsprechende Gegenmaßnahmen zu ergreifen.

Security Audit in der Praxis

In von uns durchgeführten Security Audits wurden -auf lediglich mit PCS7 installierten PCs- zwischen 76 und 266 kritische (d.h. von remote ausnutzbare) Sicherheitslücken festgestellt (insgesamt: zwischen 153 und 389).

Für die Auditierung können Sie sich auch vertrauensvoll an uns wenden . Forensic Investigations berät Sie gerne und bietet Ihnen entsprechende Lösungen und Services für Integritäts- und Sicherheitsmanagement , Endpoint Security, Desaster Recovery, Auditierung, Vulnerability Assessment und Patchmanagement – speziell zugeschnitten auf die Anforderungen in SCADA/Industrial Control Systems Netzwerken .

Daneben bieten wir Beratung zu Incident Response Strategien sowie die digitale forensische Sicherung, Analyse und Auswertung solcher Vorfälle an.

Wir verfügen über 25 Jahre Erfahrung im Sicherheitssektor, 10 Jahre Erfahrung beim Softwaremanagement im Anlagenumfeld und über mehr als 30 Jahre Erfahrung im Automatisierungssektor. Wie effizient weltweites Analagenmanagement im konkreten Fall aussehen hätte können, sehen Sie in den folgenden Videos.


Mittlerweile sei die Version 3 des bekannten Banking-Trojaners Zbot/ZeuS in der freien Wildbahn erschienen, berichten CA in ihrem Community Blog . Die neue Version betreibt gezielt Treibjagd auf die am häufigsten mit Trojanern infizierten, wohlhabenden Länder wie USA, Spanien, das Vereinigte Königreich und auch Deutschland und erschwere die Analyse durch Sicherheitsspezialisten weiter.

Unter den betroffenen deutschen Banken befänden sich u.a. die Commerzbank, die Deutsche Bank, und das Finanzportal des IT-Sicherheitsdienstlers Fiducia IT AG aus dem Volksbanken-Reiffeisenbanken Verbund. Eine kurze Überprüfung der betroffenen deutschen Sites hat nebenbei ergeben, das die u.a. betroffene Website commerzbanking.de nicht einmal die PCI-DSS Richtlinien für die Bankensicherheit zu erfüllen scheint und auch als schwach bekannte Verschlüsselungsverfahren zulässt.

Das TAN, iTAN und HBCI -Verfahren konnte der Trojaner bereits in den vorigen Versionen überwinden .

Das iTANplus-Verfahren muss ebenfalls als gebrochen angesehen werden. Beim iTANplus-Verfahren werden die Transaktionsdaten vor der Eingabe der TAN nochmals in einem CAPTCHA zusammen mit dem Geburtsdatum des Kontoinhabers dargestellt. Das Verfahren ist (nahezu) so leicht zu brechen wie das iTAN-Verfahren, lediglich die Information des Geburtsdatums muss der Angreifer erfassen und dem Konto zuordnen. Dies kann entweder über automatische Texterkennung , über Datenbanken mit Geburtsdaten, oder einmalig manuell geschehen. In den Entwicklungs- und Schwellenländern hat sich jedoch bereits eine regelrechte Industrie gebildet, um CAPTCHAs zu brechen . Anschließend ist es ebenso wie die anderen Verfahren per Man-in-the-Middle-Angriff zu überwinden.

Das mTAN-Verfahren , bei dem der Kontoinhaber TAN und ggf. Transaktionsdaten per SMS auf sein Handy bekommt, bietet hier aufgrund des Medienbruchs zwar etwas mehr Sicherheit, ist aber auch zu brechen, wenn die Telefonnummer des Handys online mit Hilfe der PIN geändert werden kann (bad idea™). Werden die Transaktionsdaten gar nicht mitgesendet, hat der Kontoinhaber trotz größter Sorgfalt keine Möglichkeit, einen MITM-Angriff durch einen Trojaner zu erkennen.

Fiducias Pressemitteilung zur kürzlich im Rahmen der InitiativeD21 (N)Onliner-Atlas2010 erschienen Sonderstudie "Online-Banking - mit Sicherheit! " liest sich mit Aussagen wie "Online-Banking wird immer beliebter" sehr positiv. Etwas unter den Tisch fällt dabei, dass obwohl die Kunden lt. der Studie Sicherheit und Datenschutz als die wichtigsten Kriterien überhaupt ansehen, sich der Anteil der Menschen, die Online-Banking aus diesen Gründen kategorisch ablehnen, von 4,3% in 2009 auf 20,2% in 2010 nahezu verfünffacht habe (u.a. Heise Online berichtete ).

Dies ist auch völlig berechtigt, meldet der Sicherheitsdienstleister Secunia doch in seinem Halbjahresbericht 2010 , dass allein in der ersten Jahreshälfte 2010 fast so viele Sicherheitslücken in PC-Software gefunden worden wären, die das Eindringen von Trojanern ermöglichen, wie im ganzen Jahr 2009. Die ohnehin schon höchste Bedrohungslage aller Zeiten wird durch den vermehrten Einsatz von Smartphones, die ebenfalls durch Trojaner und Viren infiziert werden können, zusätzlich angeheizt.

Interessant für die Online-Banking Studie wäre gewesen zu ermitteln, welcher Anteil unter den tatsächlichen Nutzern Bedenken beim Online-Banking hat, und welche.

Nebenbei fiel mir noch zufällig auf, dass die Studie ohne Quellenangabe teilweise wortwörtlich von Wikipedia abzuschreiben scheint (vgl. S. 15 der Studie unten mit "SmartTAN " und "SmartTANplus "), jedenfalls wenn man dem Changelog von Wikipedia glauben darf.

Da die Kunden, wie der Studie ebenfalls zu entnehmen ist, kaum selbst bereit seien, etwas für die Sicherheit zu tun, oder gar dafür zu bezahlen, und Datenschutz und Sicherheit als Selbstverständlichkeit sähen, liegt hier m.E. dringend Handlungsbedarf auf Seiten der Banken, die unsicheren Verfahren auszutauschen.

Ebenfalls Handlungsbedarf sehe ich im Bereich der Politik und der Rechtssprechung, hier für mehr Verbraucherschutz zu sorgen, und zumindest bei Einsatz bekanntermaßen unsicherer Verfahren die Haftung in Richtung der Banken zu verlagern.

Bankkunden, Banken, Bankenaufsicht, Politiker oder Organe der Rechtspflege können sich gerne jederzeit für prophylaktische Beratung, Schulung oder forensische Beweisführung vertrauensvoll an uns wenden .

UPDATE 29.07.2010: Gemäß der von Verizon Business veröffentlichten Studie "Data Breach Report 2010 " sei die Finanzbranche das Angriffsziel Nummer 1 von Online-Kriminellen, berichtet Heise Online.

UPDATE 29.07.2010:McAfee berichteten in Ihrem Blog, dass Zbot/ZeuS mittlerweile den im Zusammenhang mit den Angriffen auf die SIEMENS Simatic WinCC und PCS 7 SCADA -Systeme bekannt gewordenen, hochkritischen 'LNK Bug' (CVE-2010-2568 ) aktiv ausnutzt.

UPDATE 03.09.2010: Die Deutscher Bank Research, GfK und Google hätten eine Studie veröffentlicht, dass der Anteil der Online-Finanzgeschäfte immer höher würde , was den Handlungsdruck m.E. verstärkt oder wenigstens verstärken sollte.

UPDATE 27.09.2010: Die neuste Version von ZeuS nehme nun auch SMS-TAN (auch mobile TAN, mTAN genannt) ins Visier , berichtet heise online unter Bezug auf eine Veröffentlichung von S21sec . Die Malware versuche dabei, dem Opfer ein angebliches Sicherheitsupdate für das Handy unterzujubeln, welches ebenfalls einen Man-in-the-middle Angriff ausführe. Die ZeuS-Handy-Malware sei bisher auf die Infektion von Symbian und BlackBerry SmartPhones ausgerichtet.

UPDATE 09.10.2010:16-jähriger demonstriert Sicherheitslücken bei 17 Banken , er nutzte hierbei XSS -Lücken, die sich auch für Man-in-the-middle Angriffe nutzen lassen. Das bestätigt meinen Eindruck weiter, dass hier nie oder nicht regelmäßig nach Änderungen professionelle Audits stattfinden und selbst triviale Methoden ausreichend sind, die meisten Websites zu überlisten.


Eine neue Studie (PDF /Kurzfassung PDF )der Messaging Anti-Abuse Working Group (MAAWG) zum Anwenderverhalten bei Spam-Emails belegt einmal mehr, dass die Risiken von Spam-Emails von Anwendern nach wie vor unterschätzt werden.

43% gaben laut der Studie an, Emails zu öffnen, die sie für Spam hielten, 11% klickten enthaltene Links an, 8% öffneten die enthaltenen Anhänge, 4% antworteten auf die Emails. Die Zahlen nahmen mit dem Alter der Befragten jeweils minimal ab.

Alle oben angegebenen Verhaltensweisen sind jedoch falsch. Bereits das Öffnen einer solchen Spam-Nachricht kann zur Infektion des Rechners führen, wenn Sicherheitslücken in der verwendeten Email-Software vorhanden sind.

Die Anhänge zu öffnen ist besonders gefährlich, selbst vermeintlich harmlose PDFs können zu Infektionen führen. Das Anklicken von Links öffnet sehr häufig Webseiten die Schadcode (sog. Exploits ) ausführen und den Rechner infizieren.

Besonders beliebt ist immer noch das Anklicken von "Unsubscribe"-Links zum angeblichen Austragen aus Listen. Aber Spammer sind Spammer und bleiben Spammer, sie nutzen diese "Unsubscribe" Funktion lediglich, um sich bestätigen zu lassen, dass die Email-Adresse des Anwenders existiert und gelesen wird, um die Adresse mit höherem Erlös weiterverkaufen zu können oder/und Infizieren sie auf dieser Seite mit Schadcode.

Das Gleiche passiert durch antworten auf die Email. Hier wüste Beschimpfungen reinzuschreiben, mag zwar innerlich befriedigend sein, ist aber dennoch nicht wirksam, da auf solchen Konten eh nur automatisierte Systeme laufen, und ist zudem wie schon gesagt sogar kontraproduktiv.

Als Gründe für ihr Verhalten gaben 57% an, sich nicht sicher gewesen zu sein, ob die Nachricht Spam ist, 33% klickten aus Versehen auf die Nachricht, aber immerhin noch 46% öffneten Spam-Nachrichten mit Absicht (25% um sich von der Liste abzumelden oder sich zu beschweren , 18% um zu sehen was passiert, und 15% aus Interesse an den angebotenen Produkten).

Zu große Neugier kann nicht selten ins Auge gehen. Öffnen Sie nur Nachrichten, die in jeder Hinsicht unverdächtig erscheinen, löschen Sie Spams direkt oder verschieben Sie in Ihren Spam-Ordner, und ignorieren Sie sie ansonsten vollständig.

Als in der Verantwortung stehend nannten 65% ihren Internet Service Provider, der i.d.R. gar nichts tut, Anti-Virus-Hersteller mit 54%, die der Bedrohungslage wohl ebenfalls nicht mehr gewachsen sind , und erst auf Platz 3 mit 48% sich selbst.

Während in Spanien und Kanada noch 69% bzw. 68% Angaben, Opfer von Virenbefall geworden zu sein, steht Deutschland hier mit 45% am hintersten Platz der untersuchten Länder. Weniger als ein Drittel der Deutschen (30%) hielten eine Infektion mit einem Bot für wahrscheinlich und bildet damit auch hier zusammen mit dem Vereinigten Köngreich (29%) das Schlusslicht in puncto Awareness. Angeführt wird die Liste von den Deutschen jedoch, dass sich hier mit 83% die meisten Anwender für wenigstens einigermaßen erfahren halten.

Die Praxis spricht jedoch eine andere Sprache, mit den tatsächlichen Infektionen liegt Deutschland selbst bevölkerungsbereinigt weit vor Kanada, Spanien und dem Vereinigten Königreich. Die Deutschen scheinen Infektionen also lediglich weniger zu bemerken. Dies ist auch kein Wunder, waren die genannten Methoden, wie Anwender Viren oder Botnetze erkennen, allesamt höchstens für zufällige Entdeckung in Einzelfällen geeignet. Die Ausnahme stellte die Benachrichtigung von Dritten wie der Kredikartenfirma/Bank (in diesem Fall ist dann wohl bereits Schaden entstanden) bzw. dem installierten Antivirusprogramm dar, auf das aber auch kein wirklicher Verlass ist. Es ist wohl an der Zeit, besonders die Deutschen Anwender einmal mehr an die Hacker-Regel Nummer 1 zu erinnern:

"Don't think you are smart, you are NOT"

(Glaube nicht, dass Du pfiffig bist, Du bist es NICHT)


Laut dem Bericht von Heise Online wird den Discountern vorgeworfen, für PCs, Laptops, DVD/Blu-ray-Player, TV-Empfänger und -Geräte ihrer Hausmarken Tevion (Aldi) und Silvercrest (Lidl) keine MPEG-2-Patentgebühren abgeführt zu haben.

Ohne es genau recherchiert zu haben, gehe ich jetzt mal davon aus, dass Aldi und Lidl keine eigenen Entwicklungsabteilungen für Soft-und Hardware unterhalten, und die Geräte von irgendwelchen Herstellern, wahrscheinlich aus Fernost labeln lassen und zukaufen. Weiterhin gehe ich davon aus, dass ihnen die Patentrechtsverletzung durch die Geräte nicht bekannt war, als sie diese in den Handel brachten.

Fürs nächste Mal ist es deshalb für solch einen hypothetischen Fall womöglich eine gute Idee, einen Sachverständigen zu kontaktieren , und die Geräte auf Verletzung von Verletzung von Lizenz- und Patentrechten überprüfen zu lassen .

Im Zweifelsfall bleibt man ansonsten als große Handelskette auf nicht mehr verkaufbaren Geräten, Kosten für einstweilige Verfügungen, Gerichtsverhandlungen, Nachzahlung von Lizenzgebühren usw. sitzen, wenn sich die Fernost-Klitschen mit ihrer lokalen Gesetzgebung aus der Affäre ziehen oder einfach schnell pleite machen. Gerade Hersteller aus Fernost sind in puncto Qualitätsmanagement, Compliance und Normen auch oft nicht so auf der Höhe und schreiben nicht selten auch gerne alles Mögliche mit in den Vertrag, ohne es später zu halten, zu prüfen oder dafür gerade zu stehen.

Ob allerdings Patente überhaupt noch zeitgemäß sind, ist eine andere Frage, in der man durchaus geteilter Meinung sein kann.


Die Gartner Group stellt in einer Studie die Aussage auf, der Trend zur Virtualisierung führe in den nächsten Jahren zu weniger Sicherheit , berichtet. Heise Online.

Als Gründe werden hauptsächlich soziologische Aspekte wie fehlende Ausbildung im Umgang mit diesen Techniken, zu geringe Beachtung von Sicherheitsaspekten in Migrationsprojekten und unklare Verantwortlichkeiten genannt. Auch seien die Tools für diese Techniken nicht so ausgereift wie im konventionellen Sektor.

Als weiterer wichtiger technischer Aspekt wird benannt, die Virtualisierung hebele existierende Sicherungsmechanismen wie die Kontrolle des Netzwerkverkehrs effektiv aus. Durch Sicherheitslücken in virtuellen Maschinen könne ein "Single Point of Failure " entstehen und die Kompromittierung einer physikalischen Maschine größere Tragweite haben als bisher. Tatsächlich gab es solche Sicherheitslücken in virtuellen Maschinen schon, beispielsweise mit der "VMWare Directory Travesal Vulnerability (CVE-2009-3733) " eine besonders gravierende.

Gar nicht genannt werden hingegen die schon im letzten Jahr bekannt gewordenen von Joanna Rutkowska entdeckten Implementierungsfehler bei der Hardware-Virtualisierung auf Intel-Plattformen , die wirklich sichere Implementierung von virtuellen Maschinen gegenwärtig noch immer unmöglich macht.

UPDATE 18.03.2010: Gerade mal einen Tag nach meinem Blogeintrag ist eine weitere Sicherheitslücke bei der Implementierung von virtuellen Maschinen aufgetaucht . Diesmal in VirtualPC, und auch wenn es keine wirkliche "direkte" Sicherheitslücke ist, setzt sie die Sicherheit von virtuellen Maschinen herab und erhöht das Risiko der Ausnutzbarkeit von Lücken in anderer Software.



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