Forensic Investigations / Fi Blog

Fi Blog

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.


BlackHat Las Vegas 2011 - Embedding Security

BlackHat Las Vegas 2011 - Embedding Security

USB-Angriffe sind nicht neu. Prominente Beispiele sind der 'LNK-Bug ' oder der im Frühjahr auf der BlackHat DC gezeigte Angriff per simulierter Tastatur . Auf noch niedriger Ebene ging Andy Davis von NGSSecure vor.

Mit einem Testgerät, das mit einem selbstgeschriebenen Programm instrumentiert wurde, gelang es ihm nach eigener Aussage, Schwachstellen u.a. in Windows 7, der Xbox 360, Solaris 11 Express, Apple OS X und diversen Embedded-Systemen zu finden. Dies ermögliche "Jailbreaks", Entsperren gesperrter Arbeitsstationen, heimliche Installation von Schadsoftware oder Diebstahl sensitiver Daten.

Da Endpoint Protection Lösungen meist auf höherer Ebene arbeiteten, seien Sie gegen solche Angriffe und Sicherheitslücken in USB-Treibern oft wirkungslos. Der einzig effektive Schutz sei das Abschalten der USB-Schnittstellen im BIOS des Systems oder deren Versiegelung mit Epoxidharz.


BlackHat Las Vegas 2011 - Embedding Security

BlackHat Las Vegas 2011 - Embedding Security

Jerome "Jay" Radcliffe ist Diabetiker und Hacker. Er trägt eine fest implantierte Insulinpumpe, die per Funk von einem Blutzucker-Messgerät Dosisvorgaben bekommt. Das Messgerät bekommt seine Daten von einem Sensor ("Kontinuierlich messender Glukosesensor "), der ebenfalls im Körper sitzt. Als Hacker interessierte ihn natürlich die Frage, ob es ihm gelingen würde, dieses "menschliche SCADA-System" auszutricksen.

Die richtige Dosierung des Insulins sei durchaus nicht trivial, da der Blutzuckerspiegel einen gewissen Korridor nicht verlassen sollte. Ein zu hoher Blutzuckerspiegel führe zu Kopfschmerzen, verschwommenem Sehen und Schädigung der Nieren. Zu niedriger Blutzuckerspiegel wiederum könne zu Betrunkenheitsgefühl, Ohnmacht, Atem- oder Herzstillstand führen. Eine hohe Insulingabe kann also lebensgefährliche Konsequenzen haben.

Durch Reverse Engineering der Hardware, öffentliche Dokumentation und Patentschriften konnte er die Frequenzen herausfinden, auf denen die Geräte kommunizieren. Mit einer selbst gebauten Arduino-basierten Lösung gelang es ihm, Signale aufzufangen und zu senden. Seine Theorie hat sich voll bestätigt, dass das System in keinster Weise gesichert ist, lediglich eine leicht zu ermittelnde individuelle Gerätenummer muss bekannt sein, um manipulierte Signale abzusetzen.

Im Moment müsse der Patient die Insulindosis noch "manuell" bestätigen. In Zukunft solle die Insulingabe vollkommen automatisch geschehen. Neuere Geräte würden auch teilweise mit Bluetooth arbeiten, was Vor- und Nachteil zugleich seien könne. Bleibt zu hoffen, dass bis dahin auch entsprechende Sicherheit in die Geräte integriert wird.


Man mag es als 'Dummheit' bezeichnen, Automatisierungssysteme ins öffentliche Netz zu stellen, aber es ist nicht unbedingt Dummheit.

Arroganz der Sicherheitsfachleute

Ich halte es da mit Bruce Schneiers Kommentar (deutschsprachiger Bericht bei WinFuture ), der auf eine Untersuchung , wie viele Benutzer gefundene USB-Sticks arglos in PCs einstecken, feststellte, dass dies keine Dummheit wäre. Schließlich seien USB-Sticks doch genau dafür da. Dummheit wäre es, zu versuchen 'darauf zu spielen wie auf einer Okarina ' oder damit 'ein Omelett zubereiten' zu wollen. Er wirft den Sicherheitsleuten Arroganz vor und hält die Untersuchung an sich für sinnlos. Für ihn ist es, als würde man zu der Erkenntnis gelangen '75 Prozent der Menschen, die eine liegen gelassene Zeitung im Bus finden, lesen diese'. Im Hintergrund eines Computersystems gingen jedoch zu viele implizite Dinge vor sich, von denen der Benutzer im Allgemeinen nichts wüsste. Er sieht hier klar die Hersteller in der Pflicht, nicht einfach Programme von potentiell nicht vertrauenswürdigen Datenträgern zu starten. Microsoft hat hier im Übrigen auch gehandelt .

1 Fehler + noch 1 Fehler = 1 Problem

Ähnlich ist es auch im vorliegenden Fall: SPS'en sind dazu gemacht, sie ans Netz anzuschließen, wenn auch nicht unbedingt ans öffentliche Netz. Dennoch geben weder Beschreibung noch die Administrationsoberfläche einen solchen Hinweis ('Sind Sie sicher, dass Sie eine öffentliche IP-Adresse verwenden möchten?'). Auch ein werksseitig individuell pro Gerät gesetztes Passwort gibt es leider nicht ('secure by default'). Wenn zusätzlich noch eine Sicherheitslücke vorhanden ist, und sich die SPS gar noch ohne ein Passwort stoppen lässt ('Denial of Service'), ist das Desaster perfekt.

Die Legende vom 'Air Gap' oder 'Inselnetz'

Selbst ohne öffentlich im Netz erreichbar zu sein, sind Automatisierungssysteme Gefahren ausgesetzt. Gelingt ein Einbruch in das Firmennetzwerk, kann ein Hacker oder eine Schadsoftware von dort auf die Automatisierungssysteme zugreifen. Die Legende vom 'Air Gap', der physikalischen Trennung von Firmennetz und Anlagennetz, wird zwar immer noch hartnäckig propagiert, dürfte jedoch für Anwender komplexerer oder verteilter Anlagen mit Produktionsplanung-Steuerung, Extranet und Koordination mit Zulieferern/Kunden kaum realisierbar sein. Selbst physikalisch isolierte Netzwerke sind nicht ohne Risiko, da über tragbare Rechner und Wechseldatenträger ebenso Schadsoftware eingeschleppt werden kann, nichts anderes war bei Stuxnet der Fall. Vor fast einem Jahr hatte ich über diese und weitere Fakten bereits geschrieben . Wie einer der amerikanischen Kollegen jüngst festgestellt hatte, existiert ein solches 'Air Gap' nicht einmal in den Sicherheits-Leitfäden von SIEMENS oder Rockwell – er spottete 'Can you spot the air gap [...]? Funny, neither can I.'

Fazit

Überall wo Menschen arbeiten, passieren Fehler. Vorausschauendes und verantwortliches Handeln eines Platformanbieters kann jedoch größeren Schaden durch einen solchen Fehler häufig verhindern. Vor allem flächendeckenden Schaden. Platformanbieter und Implementierer sind hier aus meiner Sicht mehr in der Pflicht als der Endkunde, dennoch muss auch der Endkunde seinen Blick für Gefahren schärfen, da er letztendlich auch immer der primär Betroffene sein wird.

Es gibt jedoch in der heutigen vernetzten Welt keine Alternative – Automatisierungssysteme müssen sicher werden. Hört endlich auf, den Kunden die Schuld zu geben.

P.S.: (!) Wer seine S7-300-Firmware schon Ewigkeiten nicht mehr aktualisiert hat, sollte dies schleunigst tun. Auch hier gab es hart-codierte Passwörter ('Backdoors'), die seit heute öffentlich im Netz stehen (ICS-CERT Security Alert 11-204-01B ). Auffindbar für jeden, der es nicht ohnehin schon wusste.



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