Dieses Repository enthält die Ergebnisse meiner Forschung vom August 2020 zur Firmware von Tiandys IPC/NVR-Geräten. Ich habe zwei Sicherheitslücken gefunden, die genutzt werden konnten, um das Administrator-Passwort remote wiederherzustellen und Root-Zugriff auf das Gerät zu erlangen.
Dieses Repository enthält die Ergebnisse meiner Recherche aus August 2020 über Tiandys IPC/NVR-Firmware (diese Geräte werden auch als OMNY verkauft). Diese „Recherche“ war nicht erschöpfend, aber ich habe mehrere Methoden gefunden, um das Administrator-Passwort aus der Ferne wiederherzustellen, Telnet zu aktivieren und das Root-Passwort zu ändern.
Es ist schwer zu sagen, welche Versionen genau betroffen sind, da wir nur die neueren herunterladen können. Alle diese herunterladbaren Versionen sind betroffen:
DVRS_V9.12.7.20200422
DVRS_V11.7.4.20200721
NVSS_V13.6.1.20200723
NVSS_V22.1.0.20200722
Es gibt nicht nur verschiedene Zweige für verschiedene Geräte, sondern einige Komponenten werden separat versioniert und aktualisiert, wie zum Beispiel die Web-API, bei der ich eine Authentifizierungsumgehung gefunden habe, die nur für Versionen funktioniert, die seit Mitte 2019 veröffentlicht wurden, unabhängig von der Firmware-Versionsnummer. Falls du mehr über betroffene Versionen weißt, freue ich mich über deine Hilfe.
Ich betreibe hier vollständige Offenlegung, aber das ist angemessen. Ein Patch vom Anbieter (unwahrscheinlich, da sie nicht reagieren) würde das Problem nicht verschwinden lassen, besonders wenn keine online erreichbaren Geräte die neueste Firmware haben (nicht einmal annähernd). Die eigentliche Schwachstelle ist, dass diese Geräte dem Internet ausgesetzt sind. Und das ist etwas, das Endbenutzer beheben müssen, nicht Tiandy.
Als Bonus füge ich auch den Firmware-Entpacker und einige Informationen dazu bei, wie man über RTSP/RTMP auf die Streams zugreift (viel Glück beim Finden davon im Handbuch).
Zuerst stelle ich die Skripte vor:
Dann versuche ich kurz zu erklären, was diese Skripte tun und warum. Ich wiederhole den Code nicht, aber ich versuche, genug Kontext zu liefern, damit du den Code verstehst:
Schließlich wird es etwas technischer:
Du brauchst Python 3 mit PyCrypto.
Versuche zuerst recover.py. Dafür muss Port 3001 erreichbar sein:
python3 recover.py [HOST]
Wenn alles gut läuft, werden die Administrator-Zugangsdaten ausgegeben.
Falls dieser Port nicht erreichbar ist, könnte der Web-Port funktionieren. Dafür wird die URL benötigt:
python3 cgi_recover.py http://123.45.67.89
python3 cgi_recover.py https://123.45.67.89
Wenn keiner der obigen Wege funktioniert, prüfe, ob Telnet aktiviert ist. Falls ja, kannst du das Gerät direkt rooten – knacke einfach diesen Hash:
support:$1$$AErA9BQgLjrxTJB1748k71:501:501:Linux User,,,:/home/support:/bin/sh
(öffne auf jeden Fall einen PR, falls du ihn tatsächlich knackst :D)
In älterer V7-NVR-Firmware kannst du direkt Befehle ausführen:
python3 ftpupdate.py [host] [adminpass] '[cmd]'
allerdings gibt es keine Ausgabe zurück. Um das zu vereinfachen, habe ich diese Abkürzung eingebaut:
python3 ftpupdate.py [host] [adminpass] adduser [username] [password]
Das fügt einen weiteren Benutzer mit uid 0 hinzu.
Aktiviere zuerst Telnet mit:
python3 telnet.py [host] [adminpw]
oder bei neueren Geräten:
python3 cgi_recover.py [host] telnet
Dann kannst du /etc/passwd überschreiben (ich gehe davon aus, dass du weißt, wie das funktioniert). Versuche zuerst filetransport.py (für NVRs):
python3 filetransport.py [host] [adminpass] put /etc/passwd <[source_file]
das gibt keine Rückmeldung; du musst es testen, indem du dich anzumelden versuchst ...
Für IPC-Modelle, bei denen filetransport.py nicht funktioniert, versuche upgrade_rw.py:
python3 upgrade_rw.py [url] [adminpass] /etc/passwd <[source_file]
(das gibt ebenfalls keine Rückmeldung)
Schließlich kann das bei noch neueren Geräten auch über die Web-API erfolgen:
python3 cgi_recover.py [url] write /etc/passwd <[source_file]
Falls keiner der obigen Wege funktioniert hat (prüfe, ob du dich anmelden kannst), versuche alle Methoden erneut, aber überschreibe stattdessen /config/etc/passwd. In manchen Firmware-Versionen ist /etc/passwd ein Symlink dorthin. Schließlich kannst du auch versuchen, /tdfs/etc/passwd zu überschreiben, aber danach ist möglicherweise ein Neustart des Geräts erforderlich. Verwende zum Neustarten:
python3 reboot.py [host] [adminpass]
Die alte V7-Firmware (IPC und NVR) scheint nicht betroffen zu sein, aber wenn du das Administrator-Passwort hast, gibt es für NVRs eine authentifizierte RCE (ftpupdate.py), und für IPCs kann das Skript upgrade-rw.py verwendet werden, um /etc/passwd zu überschreiben.
Spätere Versionen der NVR-Firmware (V9 und V11) enthalten ein Standardkonto, das in Kombination mit einer „passiven“ Privilegienausweitung die Wiederherstellung des Administrator-Passworts ermöglicht. Danach können wir /etc/passwd mit filetransport.py überschreiben.
Während das Standardkonto in der IPC-Firmware nicht vorhanden ist, taucht eine weitere Wiederherstellungsmethode auf – die PSW-Methode. Das ist ein Mechanismus zur Passwort-Wiederherstellung ganz ohne Sicherheit. Er ist in allen herunterladbaren Firmware-Versionen seit V9 vorhanden. Während filetransport.py nur auf NVRs funktioniert, erreicht upgrade_rw.py denselben Zweck auf IPCs, indem es den Upgrade-Mechanismus nutzt, sodass wir trotzdem Root-Zugriff erhalten.
Die Firmware von 2019 führt einen weiteren Angriffsvektor ein – eine Authentifizierungsumgehung über die Web-API. Indem wir die Konfigurationsdatei ohne Authentifizierung exportieren, können wir das Passwort wiederherstellen und ein Upgrade-Paket vorbereiten, um beliebige Dateien zu überschreiben.
Was Schwachstellen betrifft, gibt es vier davon:
Beachte, dass ich die „Cloud“-Funktionen nicht untersucht habe, d. h. ob es möglich ist, Geräte zu enumerieren und sich dadurch mit Geräten zu verbinden, die nicht im Internet freigegeben sind (wie es bei Xiongmai-Geräten der Fall ist).
In alten Versionen ist Telnet standardmäßig aktiviert, und genau das finden wir in der Datei /etc/passwd:
support:$1$$AErA9BQgLjrxTJB1748k71:501:501:Linux User,,,:/home/support:/bin/sh
(Das Root-Passwort wird dynamisch aktualisiert; außerdem habe ich diesen Hash nicht geknackt, also sind Pull Requests mehr als willkommen :D)
Der Benutzer support (der eigentlich in allen Firmware-Versionen vorhanden ist) mag unprivilegiert erscheinen, aber natürlich hat dieser Benutzer genügend Rechte, um das Admin-Passwort zu lesen und weltweit beschreibbare Init-Skripte in /etc/init.d zu überschreiben oder sogar neue zu erstellen :)
Vom Konzept her ist die Methode wirklich einfach. Wir senden einfach ein Login-Paket und lesen die Antwort. Das ist alles, denn die Antwort „Anmeldung erfolgreich“ enthält die Zugangsdaten aller Benutzer, unabhängig von unseren Rechten. Obwohl das auch in V7 so war, wurde diese Methode praktisch erst nützlich, als das Standardkonto in der NVR-Firmware eingeführt wurde. Das nicht entfernbare „Default“ hat keine Fernzugriffsrechte, man kann also nichts damit anfangen. Naja, vielleicht abgesehen vom Lesen des Administrator-Passworts ...
Auch wenn das trivial klingt, war die Implementierung nicht ganz so trivial. Für die Kommunikation wird ein eigenes Protokoll verwendet, und die Passwörter werden mit DES verschlüsselt, allerdings mit umgekehrten Bits (das Herauszufinden war der schwierigste Teil), wobei der Schlüssel vom Server übertragen wird. Da es keine Schlüsselableitung gibt, könnte ein Lauscher problemlos alles entschlüsseln. Trotzdem muss man erst einmal herausfinden, dass die Bits umgekehrt sind, oder das Ganze von Grund auf neu implementieren ...
Die Implementierung findest du in der Funktion recover_with_default in der Datei recover.py.
Bei der Analyse der Binärdatei fällt dieser Mechanismus sofort ins Auge. Sein einziger Zweck ist es ... die Passwort-Wiederherstellung zu ermöglichen, und das tut er tatsächlich gut. Zu gut, würde ich sagen ...
Was ist hier los? Ich denke, das sollte ein Mechanismus zur Passwort-Wiederherstellung sein, vermutlich geschaffen, damit Anbieter Gerätebesitzern eine Möglichkeit bieten können, ihre Passwörter wiederherzustellen.
Ich kann vermuten, dass der Ablauf so gedacht war:
Das ist alles schön und gut, nur fehlt eines ... wo ist die Sicherheit? Nirgendwo, wie sich herausstellt. Es gibt nichts, das uns davon abhält, dieses Paket zu senden, den Sicherheitscode abzuleiten und das Passwort eines beliebigen erreichbaren Geräts wiederherzustellen.
Ich finde das erstaunlich, denn es ist nicht so, dass es einen Fehler im Mechanismus gibt, der die Sicherheit aushebelt. Es gibt schlichtweg keine Sicherheit. Es gibt nichts zu beheben, aber für mich sieht das auch nicht nach einer offensichtlichen Hintertür aus. Es hinterlässt Spuren in den Logs und hat 3 verschiedene Ableitungsschemata, jedes ausgefeilter als das vorherige. Das hat tatsächlich Zeit gekostet, das zu implementieren ...
Zurück zur Methode: Damit das funktioniert, muss dem Gerät eine Telefonnummer/E-Mail zugeordnet sein. Bei der älteren Version habe ich gesehen, dass nur der Administrator das tun kann, aber dann fand ich einen Weg, das zu umgehen. Überraschenderweise ist dieser Umweg in der neueren Firmware nicht mehr nötig, da es ausdrücklich möglich ist, die E-Mail des Geräts ohne Authentifizierung zu ändern. Und genau hier vermute ich, dass die Hintertür sein sollte :)
Technisch gesehen ist dieser Mechanismus ziemlich kompliziert und war am schwierigsten zu reverse-engineeren und neu zu implementieren. Es gibt 3 Versionen dieses Mechanismus, jede verwendet einen anderen Algorithmus zur Ableitung des Sicherheitscodes. Neben DES mit umgekehrten Bits ist eine eigene Substitutions-Chiffre mit einem hartcodierten Schlüssel beteiligt. Aber das ist alles vergebens, denn Tiandy kann symmetrische Verschlüsselung mit einem hartcodierten Schlüssel nicht sicher machen, egal wie sehr sie es versuchen.
Eine Sache, die ich beobachtet habe: Da sich der Sicherheitscode jede Minute ändert, besteht die Möglichkeit, dass der ursprüngliche Prozess einfach deshalb fehlschlägt, weil sich der Code zwischen dem Paket aus Schritt 3 und dem aus Schritt 5 geändert hat, egal wie wenig Zeit zwischen dem Senden vergangen ist. Das habe ich berücksichtigt, sodass mein Skript den Vorgang wiederholt, falls sich der Code als ungültig erweist.
Der gesamte Prozess, einschließlich des Festlegens der E-Mail (die uns nicht gehören muss), ist in der Datei recover.py implementiert.
Diese funktioniert mit neueren Firmware-Versionen (2019 und später), die über die „moderne“ Weboberfläche verfügen (diejenige mit der „Karte“. Ich mag diese Karte, auch wenn Australien etwas verzerrt wirkt).
Diese Umgehung ist einfach. Während die meisten API-Endpunkte authentifiziert sind, gibt es einige Ausnahmen. Die Prüfung, ob die Authentifizierung übersprungen werden soll, und der Abgleich, welcher Endpunkt aktiviert werden soll, sind jedoch an verschiedenen Stellen implementiert. In den meisten Fällen wird die Authentifizierung übersprungen, wenn der URL-Pfad gleich einer bestimmten Zeichenfolge ist – das ist sicher.
Neuere Versionen führen jedoch eine weitere Ausnahme ein, die aktiviert wird, wenn die Zeichenfolgen Record/DownLoad und ID= einfach irgendwo im URL-Pfad vorhanden sind.
Bei Endpunkten, bei denen der vollständige Pfad abgeglichen wird, ist das weiterhin sicher. Da Security/users einer dieser Endpunkte ist, können wir das Passwort nicht direkt wiederherstellen. Zu unserem Glück wird der Endpunkt für den Konfigurationsexport ausgewählt, indem geprüft wird, ob der URL-Pfad mit einer bestimmten Zeichenfolge beginnt (mittels strncmp). Wir können diese Zeichenfolgen also einfach an den Pfad anhängen und die Konfigurationsdatei exportieren.
Die Wiederherstellung des Passworts unter Ausnutzung dieses Fehlers ist in cgi_recover.py implementiert.
Theoretisch kann der Administrator die Firmware aktualisieren, und die Firmware ist weder signiert noch verschlüsselt. Aber brauchen wir wirklich ein eigenes Firmware-Paket? Manchmal nicht. Manchmal schon, und ich war verrückt genug, es tatsächlich zu implementieren ...
Wenn du das Passwort hast, gibt es eine Befehlsinjizierungsschwachstelle, die du nutzen kannst: das Skript ftpupdate.py. Dabei sagen wir dem Gerät, es soll ein Upgrade über FTP holen, und ftpget wird für diese Aufgabe verwendet. Wenig überraschend fließen unsere Parameter direkt in die system()-Funktion.
In der NVR-Firmware enthält das binäre Protokoll den Befehl FILETRANSPORT, der genau das tut, was er sagt. Eigentlich gibt es nichts weiter zu sagen, denn du könntest genauso gut das SDK herunterladen und denselben Befehl verwenden. Natürlich wollte ich ihn neu implementieren – um zu sehen, wie das funktioniert, wirf einen Blick auf filetransport.py.
IPC-Modelle haben diesen Befehl allerdings nicht, aber wie ich bereits sagte, können wir die Firmware immer aktualisieren. Während es unpraktikabel ist, den gesamten Flash vorzubereiten, erlauben uns Tiandys Upgrade-Pakete, einzelne Dateien zu ersetzen – genau das, was wir brauchen (siehe Entpacken der Firmware).
Nur ist es nicht so einfach. Das „Box“-Dateiformat enthält Metadaten und dann ein Array von Dateien. Die erste Datei muss ProductModule heißen und passende Geräteparameter enthalten, sonst wird das Upgrade nicht fortgesetzt. Wir brauchen nicht nur die Werte dieser Parameter, sondern auch die Parameter selbst. Zusätzlich wird auch der Metadaten-Teil (einschließlich der Box-Dateiversion) geprüft.
Das manuelle Zusammenbauen scheint unpraktikabel, aber glücklicherweise gibt es einen anderen Weg. Die Exporte der Konfigurationsdatei verwenden dasselbe „Box“-Dateiformat, mit allen passenden Metadaten und der ProductModule-Datei – nur ohne das Feld für den Upgrade-Typ.
Ich konnte herausfinden, wie man dieses Feld ausfüllt, und habe den Prozess daher implementiert. Der Mechanismus ist zwar auch in der NVR-Firmware vorhanden, funktioniert dort aber nicht auf dieselbe Weise. Eine weitere Analyse ist jedoch zwecklos, da NVRs den zuvor beschriebenen FILETRANSPORT-Befehl haben.
Das Skript upgrade_rw.py nutzt den Upgrade-Prozess. Der Name deutet allerdings auf mehr hin ... Das liegt daran, dass wir beim Export der Konfigurationsdatei angeben, welche Dateien namentlich exportiert werden sollen, und wenig überraschend funktioniert jede Datei. Wir können die Box also herunterladen und diese Datei dann mit demselben Code lesen, der zum Extrahieren der Firmware verwendet wird.
Sowohl der Export als auch das Upgrade können auch über die Web-API durchgeführt werden. In diesem Fall ist es nicht möglich, beliebige Dateien zu lesen. Ich wollte das trotzdem implementieren, weil die API stabiler zu sein scheint – siehe cgi_recover.py.
Bei Modellen mit FTP-Unterstützung könnte es möglich sein, Shell-Befehle in das Benutzerpasswort zu injizieren (wenn ein Befehl ausgeführt wird, der diesen Benutzer anlegt, damit er sich per FTP anmelden kann).
Tiandy-Geräte haben Port 3001 offen. Dieser Port wird für die Nicht-Web-Methoden benötigt. Neuere Modelle haben RTSP auf Port 9100 zusätzlich zu Port 554, und sie haben auch RTMP auf Port 1935. IPC-Modelle verwenden Port 8082 für ONVIF. HTTP und HTTPS laufen auf ihren Standard-Ports.
Geräte mit der älteren Weboberfläche (mit unserer geliebten ActiveX-Technologie) enthalten eine der folgenden Zeichenfolgen in ihrer HTTP-Antwort:
<title>Net Video Browser</title>
tdvideo.css
Geräte mit der neueren Weboberfläche (diesmal mit ... Flash) enthalten Folgendes in der Antwort:
res/app-0.1.0.css
(Der Last-Modified-Header verrät uns freundlicherweise das genaue Veröffentlichungsdatum)
Wir können diese Geräte auch am Zertifikat erkennen, auch wenn HTTPS nicht immer aktiviert ist. Für alle Geräte werden nur zwei Zertifikate verwendet, die sich in der heruntergeladenen Firmware finden lassen, was ihr Pinning nutzlos macht.
Das ältere:
C=CN, ST=Tianjin, O=Tiandy Tech, CN=dvr_ui
Das neuere:
C=CN, ST=Tianjin, L=Tianjin, O=Tiandy Tech Ltd, CN=NetDevice
Übrigens ... Die HTTPS-Unterstützung wird über einen separaten stunnel-Prozess realisiert. Das funktioniert, aber wie nicht anders zu erwarten geht dabei die IP-Adresse verloren, sodass die Logs immer 127.0.0.1 anzeigen.
Tiandy behauptet, dass ihre Geräte RTSP und RTMP unterstützen. Das ist cool, aber was wir im Handbuch nicht finden können, ist, wie man diese Protokolle tatsächlich nutzt, denn wir können die notwendigen RTSP- und RTMP-URLs nicht finden. Zum Glück habe ich diese Informationen als Nebenprodukt der Analyse erhalten, also kann ich sie teilen.
Für NVR:
Zum Ansehen des Live-Streams für Kanal C (beginnend mit 1) mit Stream-Typ S (1, 2, 3):
rtsp://username:password@host/C/S
Für IPC:
Zum Ansehen des Live-Streams mit Stream-Typ S:
rtsp://username:password@host/S
RTMP-URLs sind nicht so einfach, weil sie einen eigenen Hash erfordern, damit die Anfrage authentifiziert werden kann. RTMP erlaubt uns jedoch auch, aufgezeichnete Inhalte abzuspielen.
Die URL für den Live-Stream lautet:
rtmp://host/live/C/S/authstring
wobei C der Kanal und S der Stream-Typ ist.
Die URL für die Wiedergabe lautet:
rtmp://host/vod/START-STOP/C/S/authstring
wobei sowohl START als auch STOP Unix-Zeitstempel sind.
authstring wird wie folgt berechnet:
base64("username:"+md5("username:password")+":unix_timestamp")
Das Werkzeug rtmpauth.py kann ihn erzeugen:
python3 rtmpauth.py username password
Da dieser Zeitstempel geprüft wird und die Differenz nicht mehr als 2 Tage betragen darf, gibt es Einschränkungen:
Firmware-Upgrades sind in einem proprietären „Box“-Dateiformat verpackt, das weder signiert noch verschlüsselt ist. Aus Sicht des Entpackers ist dieses Format eigentlich sehr einfach. Es gibt einen Header, den wir überspringen, und ein Array von Dateien zum Entpacken, wobei jede Datei einen Header fester Größe mit Dateiname und Größe (zweimal) enthält, gefolgt von den Daten.
Das Werkzeug unbox.py entpackt die Datei in ein Verzeichnis, das wie die Box-Datei benannt ist, oder in das angegebene Verzeichnis:
python3 unbox.py [box_file]
python3 unbox.py [box_file] [target_dir]
Dieses Werkzeug sollte sicher zu verwenden sein (ich habe diese Zeile geschrieben, dann das Werkzeug erneut geprüft und eine Schwachstelle gefunden ... ups), weil absolute Pfade in relative umgewandelt werden, .. durch __ ersetzt wird und es keine Symlinks gibt.
Manchmal musst du das Werkzeug zweimal ausführen, denn du wirst feststellen, dass die Datei in einer .box eine weitere .box ist.