{"id":272887,"date":"2022-09-16T00:10:00","date_gmt":"2022-09-15T22:10:00","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=272887"},"modified":"2022-09-15T23:53:01","modified_gmt":"2022-09-15T21:53:01","slug":"achtung-backdoor-in-techlogix-networx-power-delivery-unit-vom-internet-isolieren-und-patchen","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2022\/09\/16\/achtung-backdoor-in-techlogix-networx-power-delivery-unit-vom-internet-isolieren-und-patchen\/","title":{"rendered":"Achtung: Backdoor in TechLogix Networx Power Delivery-Unit, vom Internet isolieren und patchen"},"content":{"rendered":"<p><img decoding=\"async\" style=\"float: left; margin: 0px 10px 0px 0px; display: inline;\" title=\"Stop - Pixabay\" src=\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2021\/06\/Stop01.jpg\" alt=\"Stop - Pixabay\" align=\"left\" \/>[<a href=\"https:\/\/borncity.com\/win\/?p=26576\" target=\"_blank\" rel=\"noopener\">English<\/a>]In Stromversorgungskomponenten (Power Delivery-Units) des US-Herstellers TechLogix Networx gibt es eine gravierende Schwachstelle in deren Firmware. Die Firmware nimmt in \u00e4lteren Versionen (vor Version 2.0.2a) keine Authentifizierung vor, d.h. man kann \u00fcber Netzwerk die Power Delivery-Unit abschalten. Das ist t\u00f6dlich, 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\u00fcglich 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.<\/p>\n<p><!--more--><\/p>\n<h2>Die TechLogix Networx Power Delivery-Unit<\/h2>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/vg01.met.vgwort.de\/na\/f2c2b5583ff84180961b0417132531af\" alt=\"\" width=\"1\" height=\"1\" \/>Vom US-Hersteller TechLogix Networx gibt es sogenannte Power Delivery-Units, z.B. die <a href=\"https:\/\/www.tlnetworx.com\/collections\/power\/products\/tl-rkps-01\" target=\"_blank\" rel=\"nofollow noopener\">TL-RKPS-01<\/a>, zur Stromversorgung von Komponenten &#8211; speziell in Rechenzentren.<\/p>\n<p><img decoding=\"async\" title=\"TechLogix Networx Power Delivery Unit TL-RKPS-01\" src=\"https:\/\/i.imgur.com\/BcyaaDR.png\" alt=\"TechLogix Networx Power Delivery Unit TL-RKPS-01\" \/><br \/>\nTechLogix Networx Power Delivery Unit TL-RKPS-01<\/p>\n<p>Diese Einheit ersetzt bis zu zw\u00f6lf 5V, 12V und\/oder 24 Volt Netzteile mit einem eigenen Rack. Jeder Kanal ist laut Hersteller ausw\u00e4hlbar, so dass er f\u00fcr verschiedene Ger\u00e4tefabrikate und -modelle (Extendern \u00fcber Splitter bis hin zu Switchern) geeignet ist. Au\u00dferdem k\u00f6nnen einzelne Kan\u00e4le per Fernsteuerung von jedem beliebigen Standort aus umgeschaltet werden.<\/p>\n<p><img decoding=\"async\" title=\"TechLogix Networx Power Delivery Unit TL-RKPS-01 GUI\" src=\"https:\/\/i.imgur.com\/hQ8URgg.png\" alt=\"TechLogix Networx Power Delivery Unit TL-RKPS-01 GUI\" \/><br \/>\nNetworx Power Delivery Unit TL-RKPS-01 GUI, Quelle: TechLogix<\/p>\n<p>Die 100 ms-Startsequenzierung sorgt f\u00fcr einen reibungslosen Neustart der Stromversorgung. Diese Power Delivery Units werden daher gerne in Rechenzentren zur Stromversorgung eingesetzt.<\/p>\n<h2>Eine Backdoor und deren z\u00e4he Beseitigung<\/h2>\n<p>In der Firmware dieser Power Delivery Unit existiert in \u00e4lteren Versionen eine Backdoor, die es Dritten erm\u00f6glichen w\u00fcrde, an der Unit angeschlossene Ger\u00e4te 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\u00fcr ein responsible disclosure gesetzt habe, abgelaufen sind, h\u00e4tte ich die Details auch ohne Patch jetzt offen gelegt.<\/p>\n<h3>Ein Leser meldet eine Backdoor<\/h3>\n<p>Am 11. Juni 2022 meldet sich ein Blog-Leser mit einem Kommentar, dass er auf eine Backdoor in einer &#8211; in Rechenzentren &#8211; genutzten Power Delivery-Unit gesto\u00dfen sei. Der Hersteller wolle diese Backdoor nicht fixen, obwohl man die an der Unit angeschlossene Ger\u00e4te ohne Zugangsdaten per http remote ein- und ausschalten k\u00f6nne. Der Leser, der anonym bleiben will, fragte, an wen er sich wenden k\u00f6nne. 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:<\/p>\n<blockquote><p>Es war denkbar einfach: Das Ger\u00e4t hat kein CLI, sollte aber aus einer Anwendungsoberfl\u00e4che ein- und ausgeschaltet werden k\u00f6nnen.<\/p>\n<p>Da ich ohnehin mit Python Skripten \u00fcber librequests andere Ger\u00e4te angesprochen hatte, hab ich das einfach auch hier gemacht. Das \u00fcbliche vorgehen: Im Firefox die hin- und her gesendeten json requests nachvollziehen und in Python \u00fcbernehmen. Wichtige Parameter dann per CLI Parameter (IP, User, Kennwort, PDU-Ausgangs-Port, ein\/aus\/cycle) \u00fcbergeben lassen und sanitizen.<\/p>\n<p>Als ich dann testweise Mal ein falsches Kennwort \u00fcbergeben habe, um zu pr\u00fcfen ob die Kennwort\u00fcbergabe aus der CLI klappt, musste ich feststellen, dass sich die Ger\u00e4te immer noch ein- und ausschalten lassen.<\/p>\n<p>Hab dann erst gedacht, da w\u00e4re 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\u00e4uft. Die Login-Prozedur konnte ich schlicht entfernen.<br \/>\nDer Hersteller (US) als auch H\u00e4ndler wurde von meinem Chef angesprochen, aber der Hersteller sagt: Teilemangel, wir k\u00f6nnen keine neuen Ger\u00e4te liefern, also haben wir auch alle Programmierer entlassen, ergo: Kein Fixen m\u00f6glich.<\/p><\/blockquote>\n<p>Der Leser hat mir noch folgenden Code-Schnipsel zukommen lassen, mit dem er die Power Delivery Unit gezielt ein- oder ausschalten kann.<\/p>\n<pre><code>#!\/usr\/bin\/env python3\r\nimport requests\r\nsession = requests.session()\r\nresponse = session.post('http:\/\/192.168.1.2:80\/cgi-bin\/MMX32_Keyvalue.cgi', data='{Input01CMD=12$!')<\/code><\/pre>\n<p>Der obige Beispielcode schaltet Ausgangsport 12 auf <em>Strom aus<\/em>, wobei die 12 im Data-Field eine Zahl von 1 &#8211; 12 sein kann, ohne f\u00fchrende 0. Der Leser schrieb dazu:<\/p>\n<blockquote><p>Dass der String mit einer geschweiften Klammer anf\u00e4ngt, die nicht geschlossen wird sieht f\u00fcr mich nach Obfuscation aus.<\/p><\/blockquote>\n<p>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\u00f6nnte dann per Netzwerk, Internet etc. die Stromversorgung f\u00fcr beliebige Komponenten, die an der Power Delivery Unit h\u00e4ngen, ausknipsen. W\u00e4re dann ein wahr gewordener Alptraum f\u00fcr die Betreiber.<\/p>\n<h3>Kontakt mit dem Hersteller, dem BSI und CERT-Bund<\/h3>\n<p>An dieser Stelle habe ich schrittweise versucht, den Hersteller TechLogix Networx zu kontaktieren und sp\u00e4ter das BSI sowie CERT-Bund mit ins Boot zu nehmen, um ggf. eine Warnung an Rechenzentrumsbetreiber zu schicken.<\/p>\n<ul>\n<li>14. Juni 2022: TechLogix Networx wurde per Mail kontaktiert und gefragt, was man denn bez\u00fcglich der Schwachstelle zu tun gedenke.<\/li>\n<li>15. Juni 2022: Die Antwort lautete, dass das Firmware-Entwicklungsteam in ein paar Wochen ein Firmware-Update zum Testen zur Verf\u00fcgung stellen sollte. Das Firmware-Update werde die\u00a0 erw\u00e4hnte Sicherheitsl\u00fccke beheben und die Umbenennung der Eing\u00e4nge erm\u00f6glichen, um mehr Klarheit bei der Verwendung des Ger\u00e4ts zu schaffen.<\/li>\n<\/ul>\n<p>Das war dann der Zeitpunkt, wo ich mir den Fall auf Wiedervorlage und Ver\u00f6ffentlichung nach 90 Tagen gelegt habe.<\/p>\n<ul>\n<li>22. Juli 2022: Der Blog-Leser hat ein Firmware-Update zum Testen erhalten. Der Leser schrieb: <em>Das hat eine Menge \"Drawbacks\", weil laut Hersteller alles auf Werkseinstellung gesetzt wird, u.a. IP und Spannung, was nat\u00fcrlich beim Rechenzentrumsbetrieb ein No-Go ist. Ich habe das hier mal testweise durchgef\u00fchrt: Fazit: Es wird gar nichts auf Werkseinstellung gesetzt, das Update l\u00e4uft durch (neue Firmware im Webinterface zu sehen), aber. &#8230; der Bug ist nicht weg.<\/em><\/li>\n<li>23. Juli 2022: Nachfrage bei TechLogix Networx \u00fcber den Stand der Sache.<\/li>\n<li>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\u00fchrte].<\/li>\n<\/ul>\n<p>An dieser Stelle habe ich den Leser kontaktiert und \u00fcber das weitere Vorgehen beraten. Meine Idee war, das BSI zu kontaktieren und zu fragen, ob da eine Warnung an Rechenzentrumsbetreiber erfolgen k\u00f6nne. Der Leser antwortete seinerzeit zum Sachstand folgenderma\u00dfen:<\/p>\n<blockquote><p>Normalerweise sollte ein guter Betreiber diese Power Delivery Units (PDUs) nicht direkt ins Internet h\u00e4ngen, aber ich kann nicht beurteilen, wie das kleine Anbieter handhaben. Mir fehlt da glaube ich ein Gef\u00fchl f\u00fcr den\u00a0 Zustand am unteren Ende der IT-Sicherheitsskala.<\/p>\n<p>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:<\/p>\n<p>Laut Hersteller wird das Ger\u00e4t auf Werkseinstellung gesetzt (IP Adresse, Spannung), sodass es sich nat\u00fcrlich verbietet, dieses im laufenden Betrieb aufzuspielen, sprich: Koordination mit dem Rechenzentrumsbetreiber ist notwendig, nat\u00fcrlich au\u00dferhalb der regul\u00e4ren Gesch\u00e4ftszeiten, weil ja auch Kundenequipment in der Zeit nicht erreichbar ist.<\/p>\n<p>Wir haben daher vorher mit einem Test-Ger\u00e4t getestet und es stellte sich raus: Stimmt alles nicht, Ger\u00e4t wird nicht auf Werkseinstellung gesetzt, h\u00e4ngt sich aber im Rahmen des Reboots auf.<\/p>\n<p>Alle Ger\u00e4te laufen weiter, aber die Steuerung ist erst wieder m\u00f6glich, wenn man einmal den Strom zieht, was nat\u00fcrlich wieder nur au\u00dferhalb der regul\u00e4ren Verf\u00fcgbarkeitszeiten m\u00f6glich ist.<\/p>\n<p>Neue Firmware war aufgespielt, das zeigte die Versionsanzeige an. Es war also nicht so, dass die Firmware schlicht nicht aufgespielt wurde.<\/p><\/blockquote>\n<p>Der Blog-Leser ging dann in Urlaub und \u00fcberlie\u00df 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.<\/p>\n<ul>\n<li>03. August 2022: 2. Meldung in grober Form (ohne Details) an BSI mit Nachfrage der Vorgehensweise<\/li>\n<li>08. August 2022: Eingangsbest\u00e4tigung von CERT-Bund \u00fcber die gemeldete Schwachstelle, mit der Bitte um Konkretisierung.<\/li>\n<li>18. August 2022: R\u00fcckmeldung von CERT-Bund, das die Schwachstellenmeldung abgelehnt werde &#8211; war mein Fehler, mit fehlte die Zeit, die Details nach zu melden.\u00a0 Ich habe zum 18.8. die Details per Antwort-Mail an CERT-Bund gemeldet.<\/li>\n<li>26. August 2022: Antwort des CERT-Bund mit folgendem Text: <em>vielen Dank f\u00fcr Ihre R\u00fcckmeldung und die weiterf\u00fchrenden Informationen. Wenn wir das soweit richtig nachvollziehen konnten, hat der Hersteller einen Patch bereitgestellt, welcher jedoch noch fehleranf\u00e4llig zu sein scheint (\"Ger\u00e4t h\u00e4ngt sich auf\" usw.). Da der Hersteller bereits informiert ist und der Meldende die Problematik (fehleranf\u00e4lliges einspielen des Patches) nochmals gemeldet hat, sehen wir aktuell keinen Mehrwert in einer \u00dcbernahme der Schwachstellenmeldung durch das CERT-Bund.<\/em><\/li>\n<\/ul>\n<p>An dem Punkt war das Thema f\u00fcr CERT-Bund durch und ich habe mich darauf vorbereitet, den Sachverhalt hier im Blog aufzubereiten.<\/p>\n<h3>Ein Firmware-Update kommt<\/h3>\n<p>Kurz vor Ver\u00f6ffentlichung dieses Blog-Beitrags gab es dann neue Informationen und ein Firmware-Update, welches das Problem behebt.<\/p>\n<ul>\n<li>06. September 2022: R\u00fcckmeldung des Lesers (auf meine R\u00fcckfrage), dass kein weiteres Feedback vom Hersteller vorliege, nur eine weitere Firmware, die den Bug aber nicht beseitigt. In einer weiteren Mail schrieb der Leser: <em>Laut Anleitung des Herstellers (<\/em><a href=\"https:\/\/www.manualslib.com\/manual\/1372078\/Techlogix-Network-Tl-Rkps-01.html?page=14#manual\" target=\"_blank\" rel=\"nofollow noopener\"><em>Seite 14 ff<\/em><\/a><em>), 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\". \u00c4ndert 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.<\/em><\/li>\n<li>13. September 2022: Der Blog-Leser schreibt mir: <em>ich habe heute eine neue Firmware erhalten. Der Fehler ist gefixt. Man muss nun ein Kennwort mitsenden, sonst kann man keine Befehle absetzen.<\/em><\/li>\n<\/ul>\n<p><em><img decoding=\"async\" title=\"Authentifizierung\" src=\"https:\/\/i.imgur.com\/QwGI3nA.png\" alt=\"Authentifizierung\" \/><\/em><\/p>\n<p>Auf meine Nachfrage erg\u00e4nzte er, dass man die neue Firmware Version 2.0.2a per Google Drive erhalten habe. Weiterhin schrieb der Leser:<\/p>\n<blockquote><p>Mit dieser [Firmware] wird ein ungesalzener md5 Hash des Passworts mit jedem abgesendeten Kommando verlangt. Die Kommunikation findet nach wie vor \u00fcber http statt. Das ist nat\u00fcrlich anf\u00e4llig f\u00fcr replay Attacken, aber zumindest besser im Hinblick auf offen erreichbare Ger\u00e4te im Internet.<\/p>\n<p>Beim Update h\u00e4ngt sich die Kiste auf und muss selbst stromlos gemacht werden, aber Ger\u00e4te laufen bis auf das kurze stromlos machen weiter.<\/p><\/blockquote>\n<p>An dieser Stelle bleibt also festzuhalten, dass der Hersteller kurz vor Ablauf der gesetzten Frist f\u00fcr ein resposible disclosure eine verbesserte Firmware freigeben hat, die eine Authentifizierung verlangt. Unsch\u00f6n ist, dass alles weiterhin per http \u00fcbertragen wird (man scheut wohl die f\u00fcr https erforderlichen Zertifikate).<\/p>\n<p>Wie dem auch immer sei &#8211; war alles in allem ein z\u00e4her Vorgang &#8211; mein Dank an den Blog-Leser f\u00fcr 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).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>[English]In Stromversorgungskomponenten (Power Delivery-Units) des US-Herstellers TechLogix Networx gibt es eine gravierende Schwachstelle in deren Firmware. Die Firmware nimmt in \u00e4lteren Versionen (vor Version 2.0.2a) keine Authentifizierung vor, d.h. man kann \u00fcber Netzwerk die Power Delivery-Unit abschalten. Das ist t\u00f6dlich, &hellip; <a href=\"https:\/\/borncity.com\/blog\/2022\/09\/16\/achtung-backdoor-in-techlogix-networx-power-delivery-unit-vom-internet-isolieren-und-patchen\/\">Weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[731,426],"tags":[3081,4328],"class_list":["post-272887","post","type-post","status-publish","format-standard","hentry","category-gerate","category-sicherheit","tag-geraete","tag-sicherheit"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/272887","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=272887"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/272887\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=272887"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=272887"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=272887"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}