Team82 Logo Claroty
Zurück zum Blog

Von Exploits zu Forensik: Enträtselung des Unitronics-Angriffs

/

Zusammenfassung 

  • Team82 veröffentlicht Einzelheiten unserer Untersuchung der integrierten PLCs/HMIs von Unitronics, die nach den zahlreichen Angriffen auf kritische Infrastrukturen im letzten Herbst, insbesondere auf Wasseraufbereitungsanlagen in den Vereinigten Staaten und Israel, begann. 

  • Das mit dem Iran verbundene Unternehmen CyberAv3ngers soll für diese Angriffe verantwortlich sein. 

  • Wir haben zwei Tools entwickelt, die wir heute kostenlos zur Verfügung stellen. Diese Tools können verwendet werden, um forensische Informationen aus integrierten HMIs/SPS von Unitronics zu extrahieren.

  • Das erste Werkzeug, PCOM2TCPermöglicht die Umwandlung von seriellen PCOM-Nachrichten in TCP-PCOM-Nachrichten und umgekehrt. PCOM ist das firmeneigene Kommunikationsprotokoll von Unitronics.

  • Die zweite, genannt PCOMClientermöglicht es dem Benutzer, eine Verbindung zu seiner Unitronics Vision/Samba-Serien-SPS herzustellen, diese abzufragen und forensische Informationen aus der SPS zu extrahieren.

  • Dieser Blog beschreibt unseren Forschungsaufbau, den Prozess, mit dem wir das proprietäre PCOM-Protokoll entpackt haben, und die Notwendigkeiten, die uns dazu veranlasst haben, beide Tools zur Extraktion von Informationen aus den Geräten zu entwickeln. 

  • Im Rahmen dieser Untersuchung haben wir zwei neue Sicherheitslücken CVE-2024-38434 und CVE-2024-38435 entdeckt. Unitronics empfiehlt allen Benutzern ein Upgrade auf v9.9.1

Einführung

Die Angriffe auf die integrierten HMIs/SPS von Unitronics im November letzten Jahres haben gezeigt, dass APT-Akteure wie die mit dem Iran verbundenen CyberAv3ngers nach wie vor bestrebt sind, Panik und Angst in Bezug auf die Cybersicherheit kritischer Infrastrukturen zu schüren und Propaganda zu politischen Zwecken zu verbreiten. 

Die Angriffe richteten sich gegen Geräte, die in Wasseraufbereitungsanlagen in Israel und den Vereinigten Staaten eingesetzt werden, und zeigten, dass die Gruppe Zugang zu diesen in Israel hergestellten HMI/PLCs hat. Obwohl die Wasseraufbereitung und -qualität nicht beeinträchtigt wurde, verunstaltete die Gruppe die Unitronics-Geräte und hinterließ eine Botschaft, in der sie andere ähnliche, in Israel hergestellte Technologien bedrohte. 

CyberAv3ngers nutzte die Tatsache aus, dass die Unitronics Vision- und Samba-Produktreihen zu diesem Zeitpunkt keinen PCOM-Passwortschutz hatten. Die Angreifer konnten sich mit der Unitronics VisiLogic Engineering Workstation-Software mit den Geräten verbinden und diese fernsteuern, um ein bösartiges Projekt auf die SPS herunterzuladen und sie zu verunstalten. 

Eine verunstaltete integrierte HMI/SPS von Unitronics. (Quelle: Unitronics).

Angesichts von Angriffen, die Hunderte von Geräten auf der ganzen Welt betreffen, haben wir uns entschlossen, ein Tool zu erforschen und zu entwickeln, mit dem Benutzer forensische Informationen aus ihren Unitronics Vision/Samba HMI/PLCs extrahieren können. Die von unserem Tool extrahierten Informationen - eines von zwei, die wir heute auf unserer GitHub-Seite frei zur Verfügung stellen - können dazu verwendet werden, Angreifer zu identifizieren, die auf diese Geräte zugreifen, und zusätzlich kritische Informationen aus dem Gerät zu extrahieren, um bei Angriffen forensische Informationen zu erhalten. 

Für die Entwicklung unserer Tools mussten wir das proprietäre PCOM-Kommunikationsprotokoll erforschen und verstehen, das von den Vision/Samba-HMI/SPSen verwendet wird. Die einzige vorhandene Dokumentation des PCOM-Protokolls wurde von einer Gruppe von Forschern erstellt, die sich mit Unitronics-Geräten befassten(A Comprehensive Security Analysis of a SCADA Protocol: from OSINT to Mitigation, Luis Rosa et al., 2019). 

Das erste von uns entwickelte Tool mit der Bezeichnung PCOM2TCP ermöglicht es den Benutzern, serielle PCOM-Nachrichten in TCP-PCOM-Nachrichten zu konvertieren und vice versa. Das zweite Tool mit der Bezeichnung PCOMClient ermöglicht es den Anwendern, eine Verbindung zu ihrer SPS der Serie Unitronics Vision/Samba herzustellen, sie abzufragen und forensische Informationen aus der SPS zu extrahieren.

Kein Ethernet-Anschluss, kein Problem

Der erste Schritt zum Verständnis des PCOM-Protokolls und der Artefakte, die aus einem Unitronics-Gerät extrahiert werden können, war der Kauf eines Geräts. Mit einem physischen Gerät konnten wir eine Verbindung herstellen und mit ihm kommunizieren. Wir kauften also ein Gerät, schickten es in unser Büro und warteten geduldig, um mit unseren Forschungen zu beginnen. Als es endlich ankam, mussten wir jedoch feststellen, dass wir einen Fehler gemacht hatten: Unser Gerät verfügte über keinen Ethernet-Anschluss. Die Geräte der Vision-Serie von Unitronics werden standardmäßig nicht mit Ethernet-Anschluss geliefert, sondern nur mit seriellen Anschlüssen; eine Ethernet-Karte ist separat erhältlich. Dies bedeutete, dass wir keine Möglichkeit hatten, eine Verbindung zu unserem Gerät herzustellen.

Unitronics Vision 570 PLC-Anschlüsse.

Um dieses Problem zu lösen, mussten wir die Dokumentation von Unitronics lesen, um die Pinbelegung des RJ11-Anschlusses zu verstehen. Damit die SPS über eine serielle Schnittstelle kommunizieren kann, hat Unitronics einen seriellen Anschluss mit einem RJ11-Stecker und RS232 als Kommunikationsstandard implementiert. Unser Ziel war es, ein benutzerdefiniertes Kabel zu erstellen, das die Vision-SPS und unseren Laptop verbindet (unter Verwendung des DB9-Anschlusses an unserem Laptop). In der Unitronics-Dokumentation fanden wir heraus, dass der RJ11-Anschluss wie folgt aufgebaut ist:

Unitronics RJ11-Anschlussbelegung (RS232-Standard)

Mit dieser Pinbelegung im Hinterkopf war es unser Ziel, ein RJ11-Kabel zu nehmen und es so zu modifizieren, dass es am anderen Ende einen DB9-Anschluss (männlich) hat, so dass wir eine Verbindung zur SPS über die RJ11-Seite und zu unserem Laptop über einen DB9-Anschluss herstellen können. Auch hier haben wir im Internet nach einer Dokumentation über die DB9-Pinbelegung gesucht, die wie folgt aussieht:

DB9 M Pinout.

Nachdem wir uns die beiden Pinbelegungen angeschaut hatten, mussten wir nur noch den RX-Pin mit dem TX-Pin verbinden und umgekehrt, sowie das Massekabel anschließen, was folgendermaßen aussah:

Verbindung von RX mit TX, TX mit RX und Masse mit Masse.

Durch die Erstellung dieses benutzerdefinierten Kabels waren wir in der Lage, eine voll funktionsfähige Einrichtung zu schaffen, die das Unitronics V570 mit unserem Labor-Laptop verbindet.

Unser Aufbau, der Anschluss der SPS an unseren Laptop.

Damit konnten wir über die VisiLogic Engineering Workstation (EWS) von Unitronics eine Verbindung zu unserer SPS herstellen. Wir luden die EWS von der Unitronics-Website herunter, installierten sie und schlossen sie an unsere SPS an.

Verbindung zu unserer SPS mit VisiLogic.

Als Nächstes wollten wir eine Man-in-the-Middle-Einrichtung (MiTM) zwischen dem PLC und unserem EWS einrichten. Dies bedeutete, dass wir den gesamten Datenverkehr zwischen diesen beiden Endpunkten abhören und beliebige Pakete verändern konnten. Da wir jedoch unser eigenes Kabel und keine Ethernet-Erweiterungskarte verwendet haben, kommunizierten unsere EWS und die SPS über eine serielle Verbindung. Normalerweise ist dies kein Problem, da Wireshark die Möglichkeit bietet, serielle Kommunikation zu sniffen. In diesem speziellen Fall war dies jedoch nicht möglich, da die EWS die serielle Schnittstelle in einem Exklusivmodus unter Windows, was bedeutet, dass kein anderer Prozess diesen Port öffnen kann. Aus diesem Grund war Wireshark nicht in der Lage, sich mit diesem Port zu verbinden und zu schnüffeln. Dies veranlasste uns zur Entwicklung unseres ersten Tools PCOM2TCP um diese Einschränkung zu umgehen.

Wir konnten den Datenverkehr zwischen dem EWS und dem Vision-Gerät nicht abhören, da das EWS die serielle Schnittstelle im Exklusivmodus öffnet.

PCOM2TCP Tool erklärt

Das PCOM-Kommunikationsprotokoll ermöglicht dem Visilogic EWS die Verbindung mit der SPS über eine von zwei Verbindungsmethoden: seriell oder Ethernet. Zu diesem Zweck hat Unitronics das PCOM-Protokoll entweder in einer seriellen oder einer TCP-Version (unter Verwendung von TCP/20256) implementiert. In beiden Fällen ist die PCOM-Basisschicht vorhanden, der einzige Unterschied besteht darin, dass bei der TCP-Verbindung das PCOM-Basispaket mit der PCOM/TCP-Schicht gekapselt ist.

Das brachte uns auf eine Idee: Wenn wir keine MiTM-Einrichtung über eine serielle Verbindung erstellen können, könnten wir vielleicht ein Python-Tool entwickeln, das serielle PCOM-Nachrichten in PCOM/TCP-Pakete umwandelt. Auf diese Weise würde unser EWS eine Verbindung zu unserem Python-Skript über TCP/IP statt über eine serielle Verbindung herstellen, und wir würden die Pakete in serielle PCOM-Nachrichten umwandeln und sie an die SPS senden. Dann könnten wir den Datenverkehr mit Wireshark (auf der Suche nach dem TCP/IP-TCP-Stream) abhören und überwachen und bestimmte Pakete in unserem Python-Skript ändern.

Unser Setup verwendet PCOM2TCP, was es uns ermöglicht, den Datenverkehr zwischen EWS und PLC zu MiTM und Sniffing zu nutzen.

PCOM-Verkehr: PCOM seriell zu TCP

Dies war ein großer Meilenstein für unsere Forschung, denn nun konnten wir endlich mit der Fehlersuche beginnen und versuchen, den PCOM-Verkehr zu analysieren.

Grundlagen des PCOM-Kommunikationsprotokolls

Im Kern besteht das PCOM-Protokoll aus Anfragen, die von der EWS gesendet werden, und Antworten, die von der SPS gesendet werden. Um zwischen verschiedenen Befehlen/Verfahren zu unterscheiden, implementiert PCOM eine breite Palette von Funktionscodes (Opcodes), die jeweils eigene Fähigkeiten und Parameter haben. Auf diese Weise kann das EWS mit Hilfe verschiedener Opcodes unterschiedliche Anfragen und Prozeduren in der SPS aufrufen.

Zusätzlich zu den verschiedenen Funktionscodes (Opcodes) hat Unitronics zwei verschiedene Protokolle als Teil des PCOM-Protokolls implementiert: PCOM ASCII und PCOM Binary. Diese beiden Protokolle implementieren unterschiedliche Opcodes, was bedeutet, dass man, um das PCOM-Protokoll vollständig zu verstehen, beide Implementierungen untersuchen muss. Lassen Sie uns beide analysieren:

Betrachten wir zunächst eine PCOM-Binär-Anfrage/Antwort. In diesem Protokoll muss jedes Paket mit einer magischen/hardcodierten Bytefolge beginnen, die aus der Zeichenfolge /_OPLC , gefolgt von einer ID, einigen reservierten Parametern und dem eigentlichen Opcode. Die vollständige Struktur der binären PCOM-Nachricht ist hier zu sehen:

Die PCOM-Binärnachrichtenstruktur.

Um zu prüfen, ob es sich bei einer bestimmten Nachricht um eine Anforderung oder eine Antwort handelt, müsste man das höchstwertige Bit (MSB) des Opcodes prüfen; ist es 0, handelt es sich um eine Anforderung, ist es 1, handelt es sich um eine Antwort.

Überprüfung des MSB des Opcodes, um festzustellen, ob eine Anfrage oder eine Antwort vorliegt.

Das PCOM-ASCII-Nachrichtenformat weist die folgende Struktur auf:

PCOM-ASCII-Format.

Im Gegensatz zu PCOM Binary, bei dem man, um zu sehen, ob es sich bei einer Nachricht um eine Anfrage oder eine Antwort handelt, den Befehls-Opcode überprüfen muss (in diesem Fall - Befehlscode), haben in PCOM ASCII eine Anfrage und eine Antwort unterschiedliche Magie. Im Falle einer Anfrage ist die Magie / verwendet, und wenn die Nachricht eine Antwort ist, wird die magische /a verwendet werden.

Nachdem wir die Grundlagen des PCOM-Protokolls verstanden hatten, machten wir uns daran, einen einfachen PCOM-Client zu erstellen, wobei wir unbekannte Opcodes erforschten und entdeckten.

PCOMClient: Ein Unitronics Forensik-Client

Der nächste Schritt in unserer Forschung war die Implementierung eines vollwertigen PCOM-Clients, auf dem wir beliebige Funktionscodes/Prozesse aufbauen konnten. Dies gab uns die Möglichkeit, verschiedene Opcodes zu testen, die Anwendung zu debuggen und zu versuchen, undokumentierte Opcodes zu verstehen. 

Unser Client ermöglicht es den Benutzern, eine Verbindung zu ihrer Unitronics-SPS herzustellen, ihre genaue Version, ihren Namen und ihren Typ zu extrahieren sowie ihren Rohspeicher zu lesen und zu schreiben. Zusätzlich zu allen grundlegenden Funktionen haben wir eine Schnittstelle zum Hinzufügen neu entdeckter Opcodes hinzugefügt.

Hinter den Kulissen hat Unitronics für die Kommunikation mit der SPS Dutzende verschiedener Funktionscodes implementiert, von denen jeder verschiedene Funktionen innerhalb der SPS aufruft. Um zum Beispiel die SPS aufzufordern, ihren Namen wiederzugeben, müsste man eine PCOM-Binäranfrage mit dem Code 0x0C Funktionscode. Einige Opcodes wurden bereits von Forschern erforscht und dokumentiert, die sich zuvor mit dem PCOM-Protokoll von Unitronics befasst haben (Umfassende Sicherheitsanalyse eines SCADA-Protokolls: von OSINT bis zur Schadensbegrenzung, Luis Rosa et al., 2019). 

Um unseren Client zu erstellen, mussten wir die verschiedenen von Unitronics implementierten Funktionscodes untersuchen und verstehen. Dies geschah hauptsächlich durch Reverse-Engineering sowie durch die Protokollanalyse der Wireshark-Pakete, die wir aufzeichnen konnten. 

Ein weiterer interessanter Opcode ist 0x42die es den Benutzern ermöglicht, die Passwort hochladen Mechanismus. Aus dem Benutzerhandbuch von Unitronics haben wir erfahren, dass Bediener ein Kennwort einrichten können, um ihr Projekt zu schützen. Mit diesem Kennwort können die Bediener ihre Projekte sperren und verhindern, dass andere sie lesen. Wir haben herausgefunden, dass dieser Opcode auf eine bestimmte Weise verwendet werden kann, um die Passwort hochladenund meldete dieses Problem an Unitronics, das mit der Aufgabe betraut wurde CVE-2024-38434. Dies ist eine von zwei Schwachstellen, die bei unseren Nachforschungen aufgedeckt und dem Anbieter mitgeteilt wurden. 

Hier ist eine Liste der bekannten Funktionscodes im PCOM-Protokoll (wichtiger Hinweis: Die Beschreibungen, die wir für jeden Opcode gewählt haben, sind einfach unsere Interpretation des Opcodes):

Funktionscode (Anfrage / Antwort)

Beschreibung

0x01 / 0x81

Speicher lesen

0x02 / 0x82

Passwort prüfen

0x0C / 0x8C

PLC-Name abrufen

0x10 / 0x90

Ressource finden

0x16 / 0x96

Ressourcenindex in Adresse übersetzen*

0x1A / 0x9A

Speicherpuffer leeren

0x41 / 0xC1

Speicher schreiben

0x42 / 0xC2

Upload-Kennwort zurücksetzen (CVE-2024-38434)

0x4D / 0xCD

Operand lesen

0xFF

Fehler

ID (ASCII)

PLC-ID abrufen

UG (ASCII)

PLC UnitID abrufen

GF (ASCII)

PLC-Version abrufen

Extrahieren forensischer Beweise

Nachdem wir das Ökosystem der Unitronics VIsion-Serie sowie das PCOM-Kommunikationsprotokoll recht gut verstanden hatten, kehrten wir zu unserem ursprünglichen Ziel zurück: die Gewinnung forensischer Beweise aus einer angegriffenen SPS. Nach weiteren Nachforschungen entdeckten wir zwei Methoden, mit denen forensische Beweise extrahiert werden können, die unserer Meinung nach dazu verwendet werden können, den Angriff besser zu verstehen und sensible Informationen über das Gerät und die auf dem Gerät durchgeführten Operationen zu erhalten.

VisiLogic-Projektdatei

Die erste Beweisquelle, die wir entdeckten, war die VisiLogic-Projektdatei. Immer wenn ein Techniker VisiLogic (Unitronics EWS) verwendet, um eine Verbindung zur Vision-SPS herzustellen, beginnt er mit der Erstellung eines Projekts. Mit diesem Projekt kann der Techniker dann die SPS, ihren Betrieb, ihre Funktionen und ihren HMI-Bildschirm einrichten. Mit diesem Projekt kann der Techniker die Vision-SPS vollständig steuern.

Ein VisiLogic-Projekt von Unitronics, das die Funktion der SPS veranschaulicht. (Quelle: Unitronics).

Hinter den Kulissen speichert die EWS alle diese Konfigurationen sowie den Funktionscode in einer Zip-Datei, die eine Access-DB-Datenbank enthält (im Speicher der SPS wird diese Datei in einem verschlüsselten Format mit einem fest kodierten Passwort gespeichert). Durch das Parsen dieser Datenbank (mit unserem Access DB Python-Parser) und die Suche nach bestimmten Feldern in bestimmten Tabellen ist es möglich, eine Menge interessanter Daten und forensischer Informationen über den Computer und die Einrichtung des Benutzers zu extrahieren, einschließlich des vollständigen Pfads, in dem das Projekt erstellt wurde (enthält normalerweise den Benutzernamen des Computers), des Tastaturlayouts des Angreifers (wurde in der Vergangenheit zur Identifizierung von Angreifern verwendet, z. B. von Mandiant zur Identifizierung von APT-1), des vollständigen Protokolls aller Verbindungen zur SPS und vieles mehr.

Vollständiger Pfad des Projekts, gespeichert in der Tabelle ProjectTable.
Datum der Projekterstellung, gespeichert in der Tabelle ProjectTable.

Auf dem Computer installiertes Tastaturlayout, gespeichert in der Tabelle tblKeyboards.

Die Projektdatei enthält zwar unzählige forensische Informationen, aber die Datei selbst wird nicht immer auf der SPS gespeichert. Im Unitronics-Ökosystem kann man beim Herunterladen eines Projekts auf eine SPS wählen, ob die Projektdatei "gebrannt"werdensoll. Im Unitronics-Ökosystem ist "Projekt brennen" eine Einstellung während des Download-Vorgangs, die festlegt, ob die Projektdatei auf die SPS heruntergeladen wird und später zum Hochladen zur Verfügung steht. Wenn ein Projekt auf die SPS heruntergeladen wird, ohne es zu brennen, können die Benutzer keinen Upload-Vorgang durchführen und das Projekt später von der SPS abrufen. Dieser Mechanismus wurde geschaffen, um es Ingenieuren zu ermöglichen, ihr Projekt zu "schützen" und zu verhindern, dass Personen mit Zugriff auf die SPS selbst es einfach hochladen und Zugriff auf das Projekt erhalten. 

Ein weiterer Schutzmechanismus, den Unitronics implementiert hat, um Ingenieuren die Möglichkeit zu geben, ihr Projekt zu schützen, ist die Möglichkeit, ein "Upload-Passwort" einzurichten, das die Durchführung eines Upload-Vorgangs nur denjenigen erlaubt, die das eingerichtete Passwort kennen. Es ist uns zwar gelungen, eine Umgehung dieses Kennworts zu finden (wodurch die Kennwortanforderung umgangen wird und wir das Projekt ohne Kenntnis des Kennworts hochladen können), aber wenn das Projekt nicht gebrannt wird, kann nichts aus der SPS ausgelesen werden. All dies wurde zu unserem benutzerdefinierten PCOM-Client hinzugefügt.

Im Falle des Unitronics-Angriffs brannten die Angreifer das Projekt nicht, als sie den Downloadvorgang durchführten. Dies bedeutete, dass wir das Projekt des Angreifers nicht erhalten konnten. Unser Tool konnte jedoch weiterhin auf das alte Projekt zugreifen, das auf die SPS heruntergeladen wurde (bevor die Angreifer es überschrieben), allerdings nur, wenn es gebrannt wurde.

PLC-Artefakt: Unterschriftenprotokoll

Nachdem wir mit der Projektdatei in eine Sackgasse geraten waren, suchten wir nach forensischen Beweisen im Speicher der SPS selbst. Dabei entdeckten wir ein auf der SPS gespeichertes Artefakt namens Signature Log. Dieses Protokoll enthält eine Liste aller Interaktionen, die Benutzer mit der SPS durchgeführt haben.

Die Extraktion dieses Protokolls ist ein langwieriger und mühsamer Prozess, aber wir haben es geschafft, es in unsere PCOMClient. Mit unserem Client kann jeder das Signaturprotokoll aus seiner SPS extrahieren.

Ein Signaturprotokoll, das von einem angegriffenen PLC extrahiert wurde.

Im Signaturprotokoll finden wir eine Menge hochinteressanter forensischer Informationen, darunter die genauen Daten der Verbindungen zu einer SPS, den vollständigen Pfad des heruntergeladenen Projekts, den Benutzernamen des Computers, der die Verbindung hergestellt hat, sowie Informationen über den Computer, einschließlich des Betriebssystems, der Tastaturbelegung usw.

Der von den Angreifern verwendete Projektpfad, extrahiert aus dem Signaturprotokoll.

Der von den Angreifern verwendete Benutzername, der dem Signaturprotokoll entnommen wurde.

Das von den Angreifern verwendete Verbindungsdatum, das dem Signaturprotokoll entnommen wurde.

Das von den Angreifern verwendete Tastaturlayout, wie es aus dem Signaturprotokoll hervorgeht.

Die von den Angreifern verwendeten Verbindungsinformationen, die dem Signaturprotokoll entnommen wurden.

Hier ist eine Liste der meisten forensischen Beweise, die aus einer Unitronics Vision Series PLC extrahiert werden können:

Forensische Beweise

Ist innerhalb der Unterschriftentabelle

Ist innerhalb der Projektdatei

Projekt Pfad

Ja

Ja

PC-Benutzername

Ja

Nein (könnte im Pfad sein)

Datum der Projekterstellung

Nein

Ja

PLC-Verbindungstermine

Ja

Ja

Computer-Tastaturen

Ja

Ja

PLC-Verbindungszeichenfolge

Ja

Ja

Projekt-Bilder

Nein

Ja

Projektfunktionen

Nein

Ja

Mitbringsel

Die umfangreichen Untersuchungen von Team82 zu den integrierten HMIs/PLCs von Unitronics begannen nach der Aufdeckung von Angriffen auf zahlreiche Wasseraufbereitungsanlagen und andere kritische Infrastrukturen Ende letzten Jahres. Eine mit dem Iran verbundene Gruppe nutzte die schwache Authentifizierung dieser Geräte aus, um auf sie zuzugreifen und sie zu verunstalten. 

Zwar wurden keine Auswirkungen auf die Wasserqualität festgestellt, doch dienten die Angriffe dem Ziel der Gruppe, Chaos und Angst vor der Cybersicherheit kritischer Infrastrukturen in diesen Gebieten zu verbreiten. 

Das hat uns dazu veranlasst, diese Vorfälle und die betroffenen Unitronics-Steuerungssysteme genauer zu untersuchen. Angriffe, die direkt auf industrielle Steuerungssysteme abzielen, sind nach wie vor relativ selten. Wenn es also ein Problem wie dieses gibt, möchte unser Team die Gründe dafür verstehen und Lösungen anbieten, die ein sichereres Ökosystem hervorbringen. 

Als wir uns das von Unitronics entwickelte proprietäre PCOM-Protokoll für die Kommunikation zwischen Geräten und Netzwerken ansahen, wurde uns klar, dass wir unsere eigenen Tools entwickeln mussten, um nicht nur das Innenleben des Protokolls zu verstehen, sondern auch forensische Informationen im Falle zukünftiger Angriffe zu gewinnen. 

Heute haben wir unsere beiden Tools frei verfügbar gemacht. PCOM2TCP ermöglicht es dem Benutzer, serielle PCOM-Nachrichten in TCP-PCOM-Nachrichten zu konvertieren und vice versa. Das zweite Tool, PCOMClient genannt, ermöglicht es den Benutzern, sich mit ihrer Unitronics Vision/Samba-Serien-SPS zu verbinden, sie abzufragen und forensische Informationen aus der SPS zu extrahieren.

Die Informationen, die Sie extrahieren können, liefern unschätzbare Hinweise auf das Verhalten der Angreifer auf dem Gerät, einschließlich Verbindungsdaten, Tastaturlayout, Dateisystempfade und vieles mehr. Wir empfehlen den Nutzern dringend, alle Programme herunterzuladen und ihre analytischen und forensischen Fähigkeiten zu verstehen.

Bleiben Sie auf dem Laufenden

Erhalten Sie den Team82-Newsletter

Offenlegung verwandter Schwachstellen

Claroty
LinkedIn Twitter YouTube Facebook