Vom Web-Login zur Steuerung: eine Angriffskette in fünf Stationen

Der Angriff beginnt nicht an der Steuerung

Wer eine Produktionsanlage absichert, schaut zuerst auf die Steuerung. Genau dort klopft ein Angreifer aber selten zuerst an. Die Firewall am Übergang zur Produktion mag sauber konfiguriert sein, die SPS in einem eigenen Segment liegen, der Fernzugriff geregelt. Der Weg in die Anlage führt trotzdem hinein, nur eben nicht über die Vordertür.

Er beginnt an einer Stelle, die mit der Produktion auf den ersten Blick nichts zu tun hat: an einer vergessenen Web-Anwendung im Büronetz. Von dort pflanzt sich der Zugriff Schritt für Schritt fort. Kein einzelner spektakulärer Exploit, sondern eine Kette aus Schwächen, die jede für sich klein wirkt. Erst ihre Verkettung trägt einen Angreifer von außen bis an die Steuerung.

Der Weg im Überblick

Bevor wir die Stationen einzeln betrachten, der gesamte Weg in der Übersicht:

Fünf Stationen, zwei Welten. Die ersten drei liegen im Büronetz, die letzten beiden in der Produktion. Dazwischen steht die Netzsegmentierung, die genau diesen Übergang verhindern soll. Wie sie überwunden wird, zeigen die einzelnen Schritte.

Station 1: Der Einstieg über eine vergessene Web-Anwendung

Am Anfang steht fast immer eine Anwendung, die aus dem Netz erreichbar ist und die niemand mehr aktiv betreut. Ein internes Portal, ein altes Reporting-Werkzeug, eine Schnittstelle, die für ein Projekt eingerichtet und nie wieder angefasst wurde. Sie läuft, also fällt sie nicht auf.

Die Schwachstellen sind dabei selten exotisch. Eine SQL-Injection, über die sich Datenbankinhalte auslesen oder eine Anmeldung umgehen lässt. Ein Path-Traversal, das den Zugriff auf Dateien außerhalb des Web-Verzeichnisses erlaubt. Eine Server-Side Request Forgery, mit der die Anwendung interne Dienste anspricht, die von außen nicht erreichbar sein sollten. Oder schlicht ein Standardpasswort, das seit der Inbetriebnahme unverändert ist.

Das Ergebnis ist in jedem Fall dasselbe: ein erster Fuß im internen Netz. Der Angreifer steht jetzt auf einem System, das regulär im Büronetz eingebunden ist, und sieht von dort, was ein Außenstehender nie zu Gesicht bekommt.

Station 2: Passwörter in Commits sind Zeitbomben

Von diesem ersten System aus ist häufig ein selbst gehosteter Git-Server erreichbar. Entwicklungsteams betreiben ihn intern, um Quellcode, Konfigurationen und Skripte zu verwalten. Für einen Angreifer ist er eine Fundgrube, denn Quellcode verrät, wie die Umgebung aufgebaut ist, welche Systeme miteinander sprechen und mit welchen Zugangsdaten.

Der entscheidende Punkt ist die Versionsgeschichte. Ein Entwickler trägt vor Jahren ein Passwort direkt in eine Datei ein, bemerkt den Fehler später und entfernt es wieder. Im aktuellen Stand ist das Geheimnis verschwunden. In der Historie steht es weiter, abrufbar mit einem einzigen Befehl. Dass das Passwort inzwischen geändert wurde, hilft wenig, wenn dasselbe Passwort an anderer Stelle weiterlebt oder ein Muster erkennen lässt.

Station 3: Die Engineering-Workstation als Brücke

Die erbeuteten Zugangsdaten führen weiter, und ein lohnendes Ziel ist die Engineering-Workstation. An ihr programmieren Techniker die Steuerungen, hier liegen Projektdateien und Konfigurationen. Diese Maschine hat eine Eigenheit, die sie für einen Angreifer wertvoll macht: Sie hängt mit einer zweiten Netzwerkkarte zugleich im Büronetz und im OT-Netz, weil ihre Aufgabe beides verlangt.

Damit ist sie die Brücke, die die Segmentierung eigentlich verhindern soll. Wer sie kontrolliert, steht ohne weiteren Umweg im Produktionsnetz. Warum ein solcher doppelt angebundener Rechner die Trennung zwischen Büro und Produktion aushebelt und welche weiteren Brücken es gibt, behandelt der Artikel Warum Netztrennung Ihre Produktion nicht schützt.

Station 4: Eine SPS ist ein vollwertiger Computer

Über die Workstation ist nun die Laufzeitumgebung der Steuerung erreichbar. Hier zeigt sich ein Irrtum, der in vielen Anlagen steckt: Die SPS wird als Black Box verstanden, die einfach ihren Prozess fährt. Tatsächlich ist sie ein vollwertiger Rechner mit Betriebssystem, Netzwerkdiensten und oft schwacher Härtung.

Viele Laufzeitumgebungen erlauben angemeldeten Nutzern, eigene Logik oder eigenen Code einzuspielen. Dieser Code läuft beim Start der Steuerung mit den Rechten des Dienstkontos, in der Regel weitreichend. Wer die Laufzeit kontrolliert, kontrolliert damit das Betriebssystem darunter. Häufig genügt schon das Standardpasswort der Umgebung, das nie geändert wurde.

Selbst ohne diesen Schritt bleibt die Prozessebene angreifbar. Industrieprotokolle wie Modbus kennen in vielen Anlagen keine Authentifizierung. Wer das Gerät über das Netz erreicht, kann Prozesswerte lesen und oft auch schreiben.

An diesem Punkt ist die Kette geschlossen. Vom ersten Zugriff auf eine vergessene Web-Anwendung bis zur Steuerung der Anlage hat der Angreifer keine einzige OT-spezifische Lücke gebraucht. Er hat lediglich eine Reihe gewöhnlicher IT-Schwächen aneinandergereiht.

Warum die Kette hält

Wenn die einzelnen Schritte so klar benennbar sind, liegt die Frage nahe, warum sie sich nicht einfach unterbrechen lassen. Der Grund liegt darin, dass jedes Glied für sich genommen vertretbar wirkt. Eine alte Web-Anwendung, die noch läuft. Ein Passwort, das vor Jahren in einen Commit rutschte. Eine Workstation, die ihre zweite Netzwerkkarte braucht. Eine Steuerung, die seit der Inbetriebnahme zuverlässig arbeitet. Jede Entscheidung war nachvollziehbar, niemand hat die Summe betrachtet.

Dazu kommt die Eigenart der OT. In der IT steht die Vertraulichkeit im Vordergrund, in der Produktion die Verfügbarkeit. Ein Anlagenstillstand kostet unmittelbar Geld und kann Menschen gefährden. Steuerungen laufen über viele Jahre, sie lassen sich nicht beliebig patchen oder austauschen. Eine Legacy-Steuerung ohne Sicherheitsfunktionen lässt sich nicht härten, sie lässt sich nur abschirmen. Maßnahmen, die das Risiko eines ungeplanten Stopps erhöhen, stoßen daher zu Recht auf Widerstand.

Wie man die Kette bricht

Eine einzelne Maßnahme genügt nicht, weil eine einzelne Lücke genügt. Hilfreich ist, an jeder Station anzusetzen.

Secrets-Hygiene. Geheimnisse gehören nicht in den Quellcode. Ein Secret-Scanning im Repository und in der Pipeline findet versehentlich abgelegte Passwörter, bevor es ein Angreifer tut. Was einmal eingecheckt wurde, gilt als kompromittiert, wird rotiert und aus der Historie entfernt.

Segmentierung statt Brücken. Der doppelt angebundene Rechner verschwindet, wenn der Zugriff auf die OT über einen gehärteten Jump-Host läuft, der jede Sitzung protokolliert und als einziger Übergang dient. Die Hintergründe dazu stehen im Artikel über die Netztrennung.

Härtung der Steuerungsebene. Standardpasswörter der Laufzeitumgebungen werden geändert, der Zugriff auf die Steuerungen auf das Nötige beschränkt. Da viele Geräte sich selbst nicht schützen können, muss der Schutz auf der Netzwerkebene liegen, über kontrollierte Conduits und eingeschränkte Schreibzugriffe.

Sichtbarkeit und Monitoring. OT-Verkehr ist erstaunlich vorhersehbar. Eine passive Überwachung, die den Normalzustand kennt, erkennt einen unerwarteten Scan oder einen neuen Kommunikationspartner schnell, ohne in den Prozess einzugreifen.

Welche dieser Brücken in einer konkreten Anlage tatsächlich offen stehen, zeigt sich erst in der Prüfung. Ein OT-orientierter Penetrationstest geht genau diesen Weg nach, schonend, eng abgestimmt und wo immer möglich passiv. Das Ergebnis ist kein abstraktes Risiko, sondern eine belastbare Liste der konkreten Schritte, mit denen ein Angreifer von außen bis an die Anlage gelangen würde.

Abschluss

Der Angriff begann nicht an der Steuerung, sondern an einer vergessenen Web-Anwendung. Darin liegt das Tückische dieser Kette: Wer nur die Produktion absichert und den Weg davor übersieht, schützt die Anlage nicht. Die Steuerung ist am Ende nur so sicher wie das schwächste Glied einer Kette, die im Büronetz beginnt.

Der ergänzende Blick auf die Bruchstellen der Trennung selbst: Warum Netztrennung Ihre Produktion nicht schützt.