Forensic Investigations / Fi Blog

Fi Blog

US-Verteidigungsminister Robert Gates sieht Cyberwar als Bedrohung für kritische Infrastrukturen, Unternehmen und Behörden und will deshalb die Zusammenarbeit staatlicher Stellen und der Privatwirtschaft weiter ausbauen.

Zuletzt hatte auch die ENISA im Rahmen der CyberEurope 2010 eine europaweite Übung zur Cyber-Security gestartet , die aber diesmal noch auf behördliche Stellen beschränkt war. Wie anfällig europäische Infrastrukturen für Hacker-Angriffe sind, war ebenfalls nicht Gegenstand der Übung.

Erstmals wurde in diesem Jahr mit Stuxnet ein Fall öffentlich, dem nicht wenige Experten die Beteiligung eines oder mehrerer Nationalstaaten nachsagen. Das IT-Sicherheitsunternehmen Imperva sieht daher staatlich geförderte oder politisch motivierte Cyber-Angriffe gar als Nummer 1 unter den IT-Security Trends für 2011 .

Daneben wiesen die Veranstalter der DeepSec Security-Konferenz darauf hin , dass auch die GSM-Mobilfunknetze zu den kritischen Infrastrukturen eines Landes zu rechnen seien. Mobilfunk-gestützte Sicherheitssysteme in Banken, Behörden oder Firmen wären ohne dieses nicht mehr einsatzbereit und auch Notrufe könnten nicht mehr abgesetzt werden.


Es gibt entsprechende Warnungen, Stuxnet könnte der Anfang einer gänzlich neuen Kategorie von Malware seien, die auf kritische Infrastrukturen abzielt, u.a. die Europäische Agentur für Internetsicherheit (European Network and Information Security Agency, ENISA ) hatte gewarnt .

Ralph Langner erläutert , dass ein in S7-Steuerungen vorhandener Designfehler vorhandenes 'Feature' den durch Stuxnet durchgeführten Man-In-The-Middle Angriff überhaupt erst ermögliche.

Er weißt m.E. zu Recht darauf hin , dass damit sowohl Überwachung als auch Steuerung der Automatisierungssysteme gänzlich unmöglich gemacht würden, und ein solches Angriffsschema generisch in entsprechenden Crimeware-Paketen implementiert werden könnte, was die Durchführung eines solchen Angriffs praktisch für Jedermann -vollkommen ohne Insider-Kenntnisse- ermöglichen würde.

Die Leute vergäßen zudem, das Stuxnet in der bekannten Form lediglich einen Transportmechanismus darstelle, damit das eigentliche Problem aber nicht beseitigt sei.


Das Industrial Control Systems Cyber Emergency Response Team (ICS-CERT ) warnte vor Shodan, einer Suchmaschine zum Aufspüren bestimmter Serverdienste im Internet, heise online hatte berichtet . Zu Recht weißt Daniel Bachfeld in dem Artikel darauf hin, das dies eigentlich ein alter Hut ist.

Zudem ist das Aufspüren von SCADA-Diensten noch viel einfacher: über öffentliche 'Whois' Datenbank-Einträge lassen sich die IP-Adressbereiche bekannter Anwender ermitteln und dann entsprechend durchforsten.

Empfehlungen

Neben den Empfehlungen des ICS-CERT rate ich daher dringend davon ab, solche Dienste im eigenen, öffentlich bekannten IP-Adressraum zu betreiben, selbst wenn diese durch ein vorgeschaltetes VPN abgeschirmt sind. Eine Sicherheitslücke im VPN-Dienst könnte gravierende Folgen haben und gezielte automatische Attacken ("autopwnage") ermöglichen.


TrendMicro hat das Stuxnet Scanner Tool herausgegeben , des es ermöglicht, mit dem Wurm infizierte Rechner im Netzwerk aufzuspüren. Es täuscht dazu einen Stuxnet-infizierten Rechner vor und verwendet reproduzierte Remote Procedure Call Anfragen, wie sie Stuxnet normalerweise nutzt, um andere Rechner im Netz mit aktualisiertem Schadcode zu versorgen. Ein infizierter Rechner antwortet auf diese Anfragen und kann dadurch entlarvt werden.

Finally still not really 0wning Stuxnet

Optimal ist diese Vorgehensweise dennoch nicht, da eine manuelle Entfernung des Virus nach wie vor nötig ist. Unter dem Arbeitstitel "0wning Stuxnet" haben wir hier schon länger ein Konzept erdacht, dass Stuxnet im Netzwerk ein Update zu dessen Konfigurationsblock schicken sollte, der neue Command & Control Server beinhaltet, die unter Kontrolle des betroffenen Anwenders stehen.

Über diese Command & Control Infrastruktur wäre es dann möglich gewesen, Stuxnet infizierten Rechnern im Netzwerk direkt einen Code-Block zu schicken, der Stuxnets interne Deinstallationsroutine aufruft. Dadurch hätte man Stuxnet quasi mit seinen eigenen Waffen geschlagen und eine Selbstzerstörung des Botnets ausgelöst.

Aufgrund mangelnder Ressourcen haben wir das jedoch nie realisiert, da wir als neutrale, unabhängige und objektive Sicherheitsforscher keinerlei Unterstützung durch den betroffenen Hersteller SIEMENS AG erhalten.

Kollektives Versagen oder mangelnde Koordination?

Unklar bleibt, warum die großen AV-Hersteller oder SIEMENS nicht etwas derartiges realisiert haben, Ressourcenmangel kann hier ja wohl kaum der Grund sein.

Symantec gar hat hier die Command & Control Server schon seit mindestens Juli in der Hand, da ich aber die Kollegen nicht ungerechtfertigt kritisieren will, werfe ich lediglich die Frage auf, ob die auf einem solchen Server generierten Daten nicht der Allgemeinheit gehören und allen Sicherheitsforschern zu Verfügung stehen sollten, statt einem einzigen Wirtschaftsunternehmen zum alleinigen Vorteil zu dienen. In jedem Fall stellt sich aber die Frage, ob die Bekämpfung einer solchen Seuche nicht generell besser koordiniert werden sollte; an dieser Stelle sind wohl internationale Anstrengungen erforderlich.

Letzlich lassen sich Stuxnet-infizierte Rechner auch aufspüren, in dem man die DNS-Auflösung mitprotokolliert. Infizierte Rechner versuchen früher oder später, die Domains www.mypremierfutbol.com und/oder www.todaysfutbol.com aufzulösen und eine Verbindung zur entsprechenden IP herzustellen.


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


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