Achtung: Backdoor in TechLogix Networx Power Delivery-Unit, vom Internet isolieren und patchen

Stop - Pixabay[English]In Stromversorgungskomponenten (Power Delivery-Units) des US-Herstellers TechLogix Networx gibt es eine gravierende Schwachstelle in deren Firmware. Die Firmware nimmt in älteren Versionen (vor Version 2.0.2a) keine Authentifizierung vor, d.h. man kann über Netzwerk die Power Delivery-Unit abschalten. Das ist tödlich, wenn diese Einheiten zur Stromversorgung in Rechenzentren eingesetzt werden und per Internet erreichbar sind. Nach einem Leserhinweise habe ich den Hersteller und CERT-Bund diesbezüglich kontaktiert. Nach vielem hin und her gibt es nun ein funktionierendes Update. Nachfolgend lege ich die Details offen. Betreiber sollten die PDUs dringen isolieren und das Firmware-Update zeitnah installieren.


Anzeige

Die TechLogix Networx Power Delivery-Unit

Vom US-Hersteller TechLogix Networx gibt es sogenannte Power Delivery-Units, z.B. die TL-RKPS-01, zur Stromversorgung von Komponenten – speziell in Rechenzentren.

TechLogix Networx Power Delivery Unit TL-RKPS-01
TechLogix Networx Power Delivery Unit TL-RKPS-01

Diese Einheit ersetzt bis zu zwölf 5V, 12V und/oder 24 Volt Netzteile mit einem eigenen Rack. Jeder Kanal ist laut Hersteller auswählbar, so dass er für verschiedene Gerätefabrikate und -modelle (Extendern über Splitter bis hin zu Switchern) geeignet ist. Außerdem können einzelne Kanäle per Fernsteuerung von jedem beliebigen Standort aus umgeschaltet werden.

TechLogix Networx Power Delivery Unit TL-RKPS-01 GUI
Networx Power Delivery Unit TL-RKPS-01 GUI, Quelle: TechLogix

Die 100 ms-Startsequenzierung sorgt für einen reibungslosen Neustart der Stromversorgung. Diese Power Delivery Units werden daher gerne in Rechenzentren zur Stromversorgung eingesetzt.

Eine Backdoor und deren zähe Beseitigung

In der Firmware dieser Power Delivery Unit existiert in älteren Versionen eine Backdoor, die es Dritten ermöglichen würde, an der Unit angeschlossene Geräte ohne weitere Authentifizierung ein- oder auszuschalten. Ich bin seit Juni 2022 hinter dem Thema her, vor einigen Tagen hat der Hersteller TechLogix Networx nun ein Update bereitgestellt, welches diese Schwachstelle beseitigt. Da am 11. September 2022 auch die 90 Tage, die ich als Frist für ein responsible disclosure gesetzt habe, abgelaufen sind, hätte ich die Details auch ohne Patch jetzt offen gelegt.

Ein Leser meldet eine Backdoor

Am 11. Juni 2022 meldet sich ein Blog-Leser mit einem Kommentar, dass er auf eine Backdoor in einer – in Rechenzentren – genutzten Power Delivery-Unit gestoßen sei. Der Hersteller wolle diese Backdoor nicht fixen, obwohl man die an der Unit angeschlossene Geräte ohne Zugangsdaten per http remote ein- und ausschalten könne. Der Leser, der anonym bleiben will, fragte, an wen er sich wenden könne. Ich habe dann den Leser per E-Mail kontaktiert, nach Details gefragt und angeboten, den Hersteller und ggf. das BSI zu kontaktieren. Hier die Antworten des Lesers, die ich leicht redigiert habe:

Es war denkbar einfach: Das Gerät hat kein CLI, sollte aber aus einer Anwendungsoberfläche ein- und ausgeschaltet werden können.

Da ich ohnehin mit Python Skripten über librequests andere Geräte angesprochen hatte, hab ich das einfach auch hier gemacht. Das übliche vorgehen: Im Firefox die hin- und her gesendeten json requests nachvollziehen und in Python übernehmen. Wichtige Parameter dann per CLI Parameter (IP, User, Kennwort, PDU-Ausgangs-Port, ein/aus/cycle) übergeben lassen und sanitizen.

Als ich dann testweise Mal ein falsches Kennwort übergeben habe, um zu prüfen ob die Kennwortübergabe aus der CLI klappt, musste ich feststellen, dass sich die Geräte immer noch ein- und ausschalten lassen.

Hab dann erst gedacht, da wäre noch etwas im Cache, aber als mir ziemlich schnell klar wurde, dass ein beendetes Python Skript nicht irgendwo Daten aus einem Cache nutzt, wenn ich es neu starte, war klar, wo der Hase lang läuft. Die Login-Prozedur konnte ich schlicht entfernen.
Der Hersteller (US) als auch Händler wurde von meinem Chef angesprochen, aber der Hersteller sagt: Teilemangel, wir können keine neuen Geräte liefern, also haben wir auch alle Programmierer entlassen, ergo: Kein Fixen möglich.

Der Leser hat mir noch folgenden Code-Schnipsel zukommen lassen, mit dem er die Power Delivery Unit gezielt ein- oder ausschalten kann.


Anzeige

#!/usr/bin/env python3
import requests
session = requests.session()
response = session.post('http://192.168.1.2:80/cgi-bin/MMX32_Keyvalue.cgi', data='{Input01CMD=12$!')

Der obige Beispielcode schaltet Ausgangsport 12 auf Strom aus, wobei die 12 im Data-Field eine Zahl von 1 – 12 sein kann, ohne führende 0. Der Leser schrieb dazu:

Dass der String mit einer geschweiften Klammer anfängt, die nicht geschlossen wird sieht für mich nach Obfuscation aus.

Zu diesem Zeitpunkt schrieb mir der Leser, dass der Hersteller wohl endlich dran sei, sich den Bug anzuschauen. Beim Blog-Leser werden die Power Delivery Unit in einem Rechenzentrum, allerdings abgeschirmt vom Internet, eingesetzt. Es ist zu vermuten, dass nicht alle Rechenzentrumsbetreiber dies so handhaben; sprich: Ein Angreifer könnte dann per Netzwerk, Internet etc. die Stromversorgung für beliebige Komponenten, die an der Power Delivery Unit hängen, ausknipsen. Wäre dann ein wahr gewordener Alptraum für die Betreiber.

Kontakt mit dem Hersteller, dem BSI und CERT-Bund

An dieser Stelle habe ich schrittweise versucht, den Hersteller TechLogix Networx zu kontaktieren und später das BSI sowie CERT-Bund mit ins Boot zu nehmen, um ggf. eine Warnung an Rechenzentrumsbetreiber zu schicken.

  • 14. Juni 2022: TechLogix Networx wurde per Mail kontaktiert und gefragt, was man denn bezüglich der Schwachstelle zu tun gedenke.
  • 15. Juni 2022: Die Antwort lautete, dass das Firmware-Entwicklungsteam in ein paar Wochen ein Firmware-Update zum Testen zur Verfügung stellen sollte. Das Firmware-Update werde die  erwähnte Sicherheitslücke beheben und die Umbenennung der Eingänge ermöglichen, um mehr Klarheit bei der Verwendung des Geräts zu schaffen.

Das war dann der Zeitpunkt, wo ich mir den Fall auf Wiedervorlage und Veröffentlichung nach 90 Tagen gelegt habe.

  • 22. Juli 2022: Der Blog-Leser hat ein Firmware-Update zum Testen erhalten. Der Leser schrieb: Das hat eine Menge "Drawbacks", weil laut Hersteller alles auf Werkseinstellung gesetzt wird, u.a. IP und Spannung, was natürlich beim Rechenzentrumsbetrieb ein No-Go ist. Ich habe das hier mal testweise durchgeführt: Fazit: Es wird gar nichts auf Werkseinstellung gesetzt, das Update läuft durch (neue Firmware im Webinterface zu sehen), aber. … der Bug ist nicht weg.
  • 23. Juli 2022: Nachfrage bei TechLogix Networx über den Stand der Sache.
  • 27. Juli 2022: Antwort von TechLogix Networx, dass der Blog-Leser die aktualisierte Firmware zum Testen erhalten habe [diese funktioniert aber nicht, wie der Leser oben ausführte].

An dieser Stelle habe ich den Leser kontaktiert und über das weitere Vorgehen beraten. Meine Idee war, das BSI zu kontaktieren und zu fragen, ob da eine Warnung an Rechenzentrumsbetreiber erfolgen könne. Der Leser antwortete seinerzeit zum Sachstand folgendermaßen:

Normalerweise sollte ein guter Betreiber diese Power Delivery Units (PDUs) nicht direkt ins Internet hängen, aber ich kann nicht beurteilen, wie das kleine Anbieter handhaben. Mir fehlt da glaube ich ein Gefühl für den  Zustand am unteren Ende der IT-Sicherheitsskala.

Ich habe vor ca. 1,5 Wochen ein Firmware-Update erhalten (v. 2.0.1) sowie ein weiteres (v. 2.0.2). Letzteres habe ich am Freitag erst installiert. Das Ding war eine Frechheit:

Laut Hersteller wird das Gerät auf Werkseinstellung gesetzt (IP Adresse, Spannung), sodass es sich natürlich verbietet, dieses im laufenden Betrieb aufzuspielen, sprich: Koordination mit dem Rechenzentrumsbetreiber ist notwendig, natürlich außerhalb der regulären Geschäftszeiten, weil ja auch Kundenequipment in der Zeit nicht erreichbar ist.

Wir haben daher vorher mit einem Test-Gerät getestet und es stellte sich raus: Stimmt alles nicht, Gerät wird nicht auf Werkseinstellung gesetzt, hängt sich aber im Rahmen des Reboots auf.

Alle Geräte laufen weiter, aber die Steuerung ist erst wieder möglich, wenn man einmal den Strom zieht, was natürlich wieder nur außerhalb der regulären Verfügbarkeitszeiten möglich ist.

Neue Firmware war aufgespielt, das zeigte die Versionsanzeige an. Es war also nicht so, dass die Firmware schlicht nicht aufgespielt wurde.

Der Blog-Leser ging dann in Urlaub und überließ seinen Vorgesetzten weitere Tests, so dass der Vorgang erst einmal offen blieb. Ich hatte dann das BSI kontaktiert und von denen den Hinweis erhalten, dass ich das bei CERT-Bund melden soll.

  • 03. August 2022: 2. Meldung in grober Form (ohne Details) an BSI mit Nachfrage der Vorgehensweise
  • 08. August 2022: Eingangsbestätigung von CERT-Bund über die gemeldete Schwachstelle, mit der Bitte um Konkretisierung.
  • 18. August 2022: Rückmeldung von CERT-Bund, das die Schwachstellenmeldung abgelehnt werde – war mein Fehler, mit fehlte die Zeit, die Details nach zu melden.  Ich habe zum 18.8. die Details per Antwort-Mail an CERT-Bund gemeldet.
  • 26. August 2022: Antwort des CERT-Bund mit folgendem Text: vielen Dank für Ihre Rückmeldung und die weiterführenden Informationen. Wenn wir das soweit richtig nachvollziehen konnten, hat der Hersteller einen Patch bereitgestellt, welcher jedoch noch fehleranfällig zu sein scheint ("Gerät hängt sich auf" usw.). Da der Hersteller bereits informiert ist und der Meldende die Problematik (fehleranfälliges einspielen des Patches) nochmals gemeldet hat, sehen wir aktuell keinen Mehrwert in einer Übernahme der Schwachstellenmeldung durch das CERT-Bund.

An dem Punkt war das Thema für CERT-Bund durch und ich habe mich darauf vorbereitet, den Sachverhalt hier im Blog aufzubereiten.

Ein Firmware-Update kommt

Kurz vor Veröffentlichung dieses Blog-Beitrags gab es dann neue Informationen und ein Firmware-Update, welches das Problem behebt.

  • 06. September 2022: Rückmeldung des Lesers (auf meine Rückfrage), dass kein weiteres Feedback vom Hersteller vorliege, nur eine weitere Firmware, die den Bug aber nicht beseitigt. In einer weiteren Mail schrieb der Leser: Laut Anleitung des Herstellers (Seite 14 ff), die ich gefunden habe deutet es darauf hin, als ob das so gewollt ist. Da stehen alle Parameter drin, die man hinsenden kann und was die Kiste dann macht.Ggf. Also "works as intended". Ändert aus meiner Sicht nichts daran, dass es ohne Kennwort schlicht ein Sicherheits-Bug ist. Die Anleitung bezieht sich auf serial Con, klappt aber eben auch per http Post Kommando in der von mir gesendeten Form mit der "geschweiften Klammer auf" beginnend.
  • 13. September 2022: Der Blog-Leser schreibt mir: ich habe heute eine neue Firmware erhalten. Der Fehler ist gefixt. Man muss nun ein Kennwort mitsenden, sonst kann man keine Befehle absetzen.

Authentifizierung

Auf meine Nachfrage ergänzte er, dass man die neue Firmware Version 2.0.2a per Google Drive erhalten habe. Weiterhin schrieb der Leser:

Mit dieser [Firmware] wird ein ungesalzener md5 Hash des Passworts mit jedem abgesendeten Kommando verlangt. Die Kommunikation findet nach wie vor über http statt. Das ist natürlich anfällig für replay Attacken, aber zumindest besser im Hinblick auf offen erreichbare Geräte im Internet.

Beim Update hängt sich die Kiste auf und muss selbst stromlos gemacht werden, aber Geräte laufen bis auf das kurze stromlos machen weiter.

An dieser Stelle bleibt also festzuhalten, dass der Hersteller kurz vor Ablauf der gesetzten Frist für ein resposible disclosure eine verbesserte Firmware freigeben hat, die eine Authentifizierung verlangt. Unschön ist, dass alles weiterhin per http übertragen wird (man scheut wohl die für https erforderlichen Zertifikate).

Wie dem auch immer sei – war alles in allem ein zäher Vorgang – mein Dank an den Blog-Leser für die Informationen. Betreiber von Rechenzentren, die diese PDUs verwenden, wissen jetzt was zu tun ist: Sicherstellen, dass die PDUs vom allgemeinen Netzwerk/Internet isoliert sind und dann die aktualisierte Firmware des Herstellers installieren (beachten, dass die PDU beim Firmware-Update stromlos gemacht werden muss).


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Geräte, Sicherheit abgelegt und mit Geräte, Sicherheit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

3 Antworten zu Achtung: Backdoor in TechLogix Networx Power Delivery-Unit, vom Internet isolieren und patchen

  1. Marcell sagt:

    Wer macht denn sowas? So Zeug ins Internet stellen?

    • Günter Born sagt:

      Hat mich auch eine Mitgliederin in einer professionellen englischen Facebook Cyber-Security-Gruppe gefragt. Ist natürlich ein Argument – habe dann diesen Fehler gemaßt und Shodan befragt … waren nicht alles PDUs, aber einige NetWrox-Geräte, die diesem Internet ihre Präsenz gezeigt haben.

      PS: Unter dem Strich hätte ich mich aber besser ins Bett gelegt und an den Füßen gespielt – wäre für mich mit weniger Arbeit verbunden gewesen. Mal schauen, ob der Beitrag über 500 Abrufe kommt (Wetten darauf nehme ich keine an) – das Jammern der Verantwortlichen beginnt dann, wenn was passiert ist – konnte ja keiner ahnen ;-).

  2. Christian Krause sagt:

    Leute die meinen, dass man IT auch selbst machen kann, die stellen sowas ins Internet. Während Umbauten an deinem Auto ne TÜV Abnahme benötigen, ist das bei IT Equipment nicht der Fall.
    Hab schon defekte Mainboards gesehen, weil der PCIE Stecker halt auch in den 12 V CPU Port passte.
    Frage des Kunden: "Woher soll ich wissen, dass man das da nicht reinstecken darf."
    Gute Frage. Z.b. aus der Ausbildung.
    Bei 4 Milliarden IP Adressen ist die Wahrscheinlichkeit halt gross, dass es doch wer gemacht hat.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.