Internet-Kommunikations-Analyse der von AliExpress gekauften TV-Box H20 mit Badbox-Malware

Weblog vom 14.01.2025: Internet-Kommunikations-Analyse der von AliExpress gekauften TV-Box H20 mit Badbox-Malware
Kategorie:IT Security
Stichworte:Internet, Router, Station, TVBox, Hongtop, Hongxin, Shenzhen, AliExpress, China, H20, H20 pro, Malware, BadBox, Firmware, Vodafone, BSI, Firmware, SmartTV, Android, ADB, Analyse, File-Analyse, NHG47K, DNS


Wie in meinem vorhergehenden Artikel erwähnt, habe ich mir zwei Android-TV-Boxen auf AliExpress gekauft und bekam dann irgendwann eine Warn-e-mail von meinem Provider Vodafone, die mir mitteilte, dass irgendwas bei mir mit der Badbox-Malware infiziert sei und Schindluder im Internet treibt.

Mein Verdacht fiel auf die "üblichen Verdächtigen": Billig-Produkte als China und da hatte ich gleich die beiden TV-Boxen H20 und H20 pro im Sinn. Da dank BSI-Sinkhole zur zeit nicht viel passieren kann, hängte ich das H20 pro wieder ans Internet und beobachtete weiter. Es traten keine Vorfälle mehr auf und damit stand fest: Die mails kamen wegen dem H20 und nicht wegen des H20 pro.

Nachdem ich beim letzten Mal das Android-System der H20-Badbox näher untersucht habe (Ergebnisse siehe dort), will ich mir jetzt ein wenig die Internet-Kommunikation anschauen, also welche Internet-Server die Badbox so kontaktiert und ob da etwas verdächtiges dabei ist.

Verdächtige Domains

Aus den Quellen (siehe Seitenende) lassen sich folgende verdächtige Domainnamen zusammentragen:
6f33933ce4a5c0e1b32fea736a61351a.com bitemores.com bluefish.work cast.jutux.work catmos99.com cbphe.com cbpheback.com coslogdydy.in cxlcyy.com cxzyr.com dcylog.com echojoy.xyz flyermobi.com giddy.cc goologer.com home.1ztop.work huuww.com jolted.vip jutux.work logcer.com meiboot.com msohu.shop mtcpmpm.com old.1ztop.work pccyy.com pcxrl.com pcxrlback.com pixelscast.com pixlo.cc soyatea.online swiftcode.work tvsnapp.com veezy.sitev ycxad.com ycxrl.com ycxrldow.com yydsmr.com ztword.com
Außerdem soll die Badbox Malware den Kontakt zum Command-and-Control-Server mit einem POST /terminal/client/apiInfo aufnehmen.

Schauen wir doch einmal, ob das bei meiner H20 Badbox auch der Fall ist.

Analyse auf dem Gerät mittels NoRoot Firewall

Wir können den Internet-Traffic auf dem Android Gerät selbst anschauen mithilfe der Android App NoRoot Firewall von GreyShirts, oder auf deutsch: Firewall ohne Root, dass ich in Version 4.0.2 als APK bei uptodown gefunden habe.

Installiert und gestartet, fängt die App über ein VPN die Internet-Kommunikation der TV-Box ab und protokolliert sie. In der Firewall können Regeln nach App und anderen Kriterien erstellt werden, um bestimmten Internet-Traffic zu blockieren oder zuzulassen.

Da meine H20 Box gerade im Startmenü verharrt und sonst nichts gestartet ist, dürfte sich der Traffic in Grenzen halten. Trotzdem muss ich nicht lange warten, um einen verdächtigen Treffer im Protokoll vorzufinden:



Die App, oder besser gesagt der App-Bulk "Android-System, Bugreport, CleanUp, com.android.wallpaperbackup.com, example.changeled, DeviceTest, eHomeMediaCenter, Eingabegeräte, Einstellungen, Einstellungen, Einstellungsspeicher, FileExplorer, HLauncher, HXDeviceMonitor, HX[chin.], Kombinierte Standortbest., My Application, OS Update, rcs, Schlüsselbund, Stresstest for 7.O, System Cleaner, System Update, UnStop, WifiDisplay" (was nicht gerade wenig ist) ist dabei höchst verdächtig.

Dabei frage ich mich, warum es zweimal einen Eintrag "Einstellungen" gibt. Da ist schon mal verdächtig. Genauso wie die Apps My Application, HXDeviceMonitor, eHomeMediaCenter, DeviceTest, example.changeled. eHomeMediaCenter ist mir öfters aufgefallen, öfters mal mit einer Absturzmeldung aufgepoppt zu sein.

Bei dem Protokolleintrag wird versucht, eine Verbindung zu der IP 43.34.58.89 herzustellen, die aber vom Sinkhole des BSI auf der IP 89.58.34.43 umgeleitet wird und als DNS Name sinkhole.caad.fkie.fraunhofer.de zurückliefert, was mir sagt, dass das Sinkhole angeschlagen und funktioniert hat. Mehr zum Thema BSI-Sinhole in meinem ersten Artikel zum Thema Badbox.

Das Sinkhole ist ganz normal bei dem deutschen Hoster Netcup gehostet (witzigerweise im selben Rechenzentrum in Nürnberg, in dem auch mein Webserver steht) und wird wohl von einer Fraunhofer Forschungseinrichtung betrieben. Die 43.34.58.89 steht übrigens für die IP des Server, nur eben als "umgedrehte" ARPA-Adresse..

Der Umstand, dass genau hier das Sinkhole anschlägt, das mir dann ja letztendlich die BSI-Warn-Mails über die Badbox-Malware geschickt hat, und dass die ursprüngliche IP-Adresse in einer chinesischen Cloud hängt, lässt mit hoher Wahrscheinlichkeit darauf schließen, dass eine der oben genannten App die Badbox-Malware inne hat.

Nur zu dumm, dass das gleich so viele Apps auf einmal sind, die da laut NoRoot-Firewall in Frage kommen.

Die Internet-Kommunikation ist mit dem versacken im Sinkhole dann auch beendet. Das wird die erste Kommunikation mit dem Command-and-Control-Server sein. Wenn der nicht erreicht werden kann, wird die Malware keine weiteren Versuche unternehmen, seinen schadhaften Code auszuführen. Von der Seite her blockiert das Sinkhole auch die Forschungen von IT-Security-Experten, die der Sache eingehender analysieren wollen.

Denn so stellt die Badbox nur ein-, zweimal am Tag eine Verbindung ins Internet her. Und es erfordert eine Menge Geduld, die wenig nach außen getragenen Informationen aufzufangen.

Eventuell kann ich später mit einem eigenen Proxy und einer Umleitung über das Ausland das Sinkhole umgehen und so mehr Einblick in den "bösen" Datenverkehr bekommen.

Analyse der DNS-Anfragen via Pi-Hole auf einem Raspberry Pi

Da mir das BSI-Sinkhole die DNS-Abfragen verbiegt, fange ich sie schon vorher ab, indem ich im Android der H20-Badbox für das Ethernet-Netzwerk manuelle Eingaben mache und dort als DNS-Server meinen Raspberry Pi angebe, auf dem Pi-Hole läuft. Pi-Hole ist normalerweise dazu gut, Werbung aus dem Internet-Verkehr auszufiltern, protokolliert aber auch alle Zugriffe.

So werden die DNS-Anfragen der Badbox, also die Auflösung von Domainnamen zu IP-Adressen, zuerst an mein Pi-Hole gesendet, dort protokolliert, dann an einen regulären DNS-Server im Internet gesendet und das Ergebnis bekommt dann die Badbox zurück. Die Verbindungen der Badbox landen dann zwar immer noch im Sinkhole, aber ich kann beobachten, mit welchen Domains die Badbox sich versucht, zu verbinden.

Als außergewöhnlich fallen mir folgende Domains auf:
2025-01-11 16:15:54 A ota.szhxws.com 2025-01-11 16:17:27 A www.szhxws.com 2025-01-11 16:24:39 A dcylog.com
Der Rest der Anfragen stammt von Firefox, dem Play Store und anderen bekannten Diensten.

Der Hersteller der Box ist ja Shenzhen Hongxin Netvision Digital Technology Co. Ltd. in China, so steht es auch auf der Verpackung, in der die H20 und H20pro Boxen von AliExpress geliefert wurden. www.szhxws.com ist die ganz normale Homepage der Firma. Ich schätze mal, dass der Hersteller nicht direkt etwas mit der Malware zu tun hat, und die Box hin und wieder mal "nach Hause telefoniert", damit Hongxin weiß, wie viele Boxen da draußen von ihnen laufen.

ota.szhxws.com könnte für Over The Air (OTA) stehen und für eventuelle Updates zuständig sein. Ein Blick in das Android-Logfile via logcat bestätigt, dass es es sich um eine Update-Anfrage handelt, denn sie wird vom Programm RKUpdateService abgesetzt, das wohl Updates für Boxen mit Rockchip (RK) wie die H20 durchführt:
H20:/ # logcat | grep szhx 01-13 15:40:59.309 1512 1512 D RKUpdateService: remote uri is http://ota.szhxws.com/OtaUpdater/android?product=H20&version=202309281601&sn=6UKR5FYF1W&country=DE&language=de
Die Domain ota.szhxws.com antwortet auch auf Port 80 (HTTP) und wenn man sich den Source-Code der Seite ansieht, dann ist dort auskommentiert eine Umleitung auf einen Shop bei 1688.com.



Das ist eine B2B-Platform im Besitz der Alibaba Group, den eigenen Worten der China Marketing & E-Commerce Agentur HAMKAI GmbH auf Linkedin zufolge "Chinas größter B2B-Online-Marktplatz".


Wäre die Umleitung auf https://shop1386867398135.1688.com aktiv, sähe man den Shop von Shenzhen Hongxin, eben dem Hersteller der Box mit seinen Produkten, im Bild wird gerade die TV-Box H9-X3 (mit Android 9) promotet.

Also auch nicht unbedingt etwas Verwerfliches.

Die Shop-Webseite bietet noch einiges an Zusatzinformationen über die Herstellerfirma der Box. Das macht eigentlich alles einen seriösen Eindruck, für chinesische Verhältnisse.

Eine spätere Aufzeichnung des Internet-Traffics wird zeigen, dass die Box via HTTP ein GET /Update/rk322x/H20/A32/7.1.2_25/version.json absetzt, die folgendes Ergebnis liefert:



Wobei ich nicht glaube, dass irgendwas unter der lokale IP 192.168.1.253 herunterladbar sein wird. Die SystemUpdate.apk habe ich mal heruntergeladen und durch VirusTotal geschickt, ohne wesentlich Befund. Vielleicht kann ich ja später mal versuchen, die APK auszuführen und damit auf eine Malware-freie Version updaten? Wer weiß...

dcylog.com lässt auf Malware schließen

Viel interessanter ist allerdings die Domain dcylog.com, die alle 5 Minuten aufgerufen wird:
2025-01-11 16:24:39 A dcylog.com android-xxxxxxxxxxxxxxxx.local 2025-01-11 16:29:40 A dcylog.com android-xxxxxxxxxxxxxxxx.local 2025-01-11 16:34:40 A dcylog.com android-xxxxxxxxxxxxxxxx.local 2025-01-11 16:49:40 A dcylog.com android-xxxxxxxxxxxxxxxx.local 2025-01-11 16:54:40 A dcylog.com android-xxxxxxxxxxxxxxxx.local 2025-01-11 17:04:40 A dcylog.com android-xxxxxxxxxxxxxxxx.local
Diese Domain ist momentan gar nicht bei einem Registrar konnektiert:
>> whois dcylog.com No match for "DCYLOG.COM". >>> Last update of whois database: 2025-01-12T08:59:24Z <<<
Vielleicht hat man die Domain mittlerweile auch schon "von Amts wegen" diskonnektiert. Was nichts daran ändert, dass die Badbox noch immer versucht, sie zu erreichen.

In einem Bericht von Human Security (23) über Badbox und PeachPit findet man die Domain dcylog.com in den Netzwerk-Indikatoren wieder:
Domain Malware cbphe.com BADBOX cbpheback.com BADBOX ycxrl.com BADBOX dcylog.com BADBOX flyermobi.com PEACHPIT
Auch LevelBlue-Labs und Cloudflare Radar sind der Meinung, dass die Domain mit Malware in Zusammenhang steht.

Was an dcylog.com übertragen werden soll

Wenn ich der Badbox via Pi-Hole weiß mache, dcylog.com hätte die IP eines meiner lokalen Webserver und damit die Anfragen der Box an dcylog.com umleite, bekomme ich folgende Einträge im Logfile:
2025-01-13 16:28:24 10.10.10.4 POST /terminal/client/register - 80 - 10.10.10.123 Dalvik/2.1.0+(Linux;+U;+Android+10;+H20+Build/NHG47K) - 404 0 2 53 2025-01-13 16:33:24 10.10.10.4 POST /terminal/client/register - 80 - 10.10.10.123 Dalvik/2.1.0+(Linux;+U;+Android+10;+H20+Build/NHG47K) - 404 0 2 5 2025-01-13 16:38:24 10.10.10.4 POST /terminal/client/register - 80 - 10.10.10.123 Dalvik/2.1.0+(Linux;+U;+Android+10;+H20+Build/NHG47K) - 404 0 2 3 2025-01-13 16:43:24 10.10.10.4 POST /terminal/client/register - 80 - 10.10.10.123 Dalvik/2.1.0+(Linux;+U;+Android+10;+H20+Build/NHG47K) - 404 0 2 4
Es sollen also Infos an /terminal/client/register übertragen werden. Interessant ist auch der User Agent, den die Box mitliefert: Hier taucht wieder das verdächtige "NGH47K" auf und selbst das Modell der TV-Box "H20".

Bemüht man eine Suchmaschine, findet man heraus, dass Bitsight ebenfalls bei einer Analyse im Rahmen der Badbox Malware (21) auf diese URL gestoßen sind. Außerdem fand in deren Analyse ein POST /terminal/client/apiInfo statt. Dazu findet man noch mehr Quellen im Internet, die diese URL der Badbox Malware zuschreiben.

Ein POST lässt immer darauf schließen, dass der Client Daten an die URL mitschickt. Die taucht allerdings nicht im Logfile meines lokalen Webservers auf. Jetzt könnte ich natürlich ein PHP-Script oder ähnliches mit der URL /terminal/client/register schreiben, um dort dann die Post-Daten zu protokollieren. Aber ich dachte mir, ich gehe den einfachen Weg und benutze Wireshark. Der "Kabel-Hai" lieferte für den Request folgenden Eintrag:
Frame 2699: 674 bytes on wire (5392 bits), 674 bytes captured (5392 bits) on interface \Device\NPF_{E33209FF-2DAC-4594-8DC9-DBD9004C6E04}, id 0 Ethernet II, Src: 48:92:xx:xx:xx:xx (48:92:xx:xx:xx:xx), Dst: GigaByteTech_xx:xx:xx (xx:xx:xx:xx:xx:xx) Internet Protocol Version 4, Src: 10.10.10.123, Dst: 10.10.10.4 Transmission Control Protocol, Src Port: 38291, Dst Port: 80, Seq: 1, Ack: 1, Len: 620 Hypertext Transfer Protocol POST /terminal/client/register HTTP/1.1\r\n Connection: Keep-Alive\r\n Content-Type: application/x-www-form-urlencoded\r\n User-Agent: Dalvik/2.1.0 (Linux; U; Android 10; H20 Build/NHG47K)\r\n Host: dcylog.com\r\n Accept-Encoding: gzip\r\n Content-Length: 375\r\n \r\n [Response in frame: 2700] [Full request URI: http://dcylog.com/terminal/client/register] File Data: 375 bytes HTML Form URL Encoded: application/x-www-form-urlencoded
Die mitgeschickten Post-Daten (HTML Form Data) lauten dann (URL-decoded):
NKEoZ74+EVqcUxD19V3VcF0Co55nE5swr5rYPYB9rGkKDus4AG9fTCu7UsIbwOAyKtwLi5Aa+72PxpJGY0hh3uWgceW/+ug+NJyugNCnpyPskgm8dlObE1vWrcS1T/2W/gfua9TqAI0mUqkgq73w/h6AEygfP61AktVNZy+fA5RLa2k5cqgjH5fKD+O8StfWzsu7SkWFS7k26lrFtgF+857b9NoxzvtGSw3UpP6HXUQqRNvNQfsyq11F/hlG0sJRx/MGG5fE1YW4/XCHOKa8wrOOVkAP9cNcCz+5CIYtQY/+9gc9/B66Cp4Lvauy7h53VOi49W2hKSc=
was höchstwahrscheinlich BASE-64-enkodiert ist und sich mit z. B. der Seite Kryptografie.de dekodieren lässt zu folgenden Binärdaten (in Hexcode-Schreibweise):
34A12867 BE3E115A 9C5310F5 F55DD570 5D02A39E 67139B30 AF9AD83D 807DAC69 0A0EEB38 006F5F4C 2BBB52C2 1BC0E032 2ADC0B8B 901AFBBD 8FC69246 634861DE E5A071E5 BFFAE83E 349CAE80 D0A7A723 EC9209BC 76539B13 5BD6ADC4 B54FFD96 FE07EE6B D4EA008D 2652A920 ABBDF0FE 1E801328 1F3FAD40 92D54D67 2F9F0394 4B6B6939 72A8231F 97CA0FE3 BC4AD7D6 CECBBB4A 45854BB9 36EA5AC5 B6017EF3 9EDBF4DA 31CEFB46 4B0DD4A4 FE875D44 2A44DBCD 41FB32AB 5D45FE19 46D2C251 C7F3061B 97C4D585 B8FD7087 38A6BCC2 B38E5640 0FF5C35C 0B3FB908 862D418F FEF6073D FC1EBA0A 9E0BBDAB B2EE1E77 54E8B8F5 6DA12927
Das ist allerdings kein lesbares ASCII, sondern etwas wahrscheinlich Verschlüsseltes. Man kann für die Binärdaten die Shannon Entropie berechnen, die für die "Informationsdichte", also quasi die Gleichverteilung der benutzten Zeichen (mehr siehe unter dem Link), steht.

Die Shannon Entropie für die Binärdaten oben ist 7,104.

Ein deutscher oder englischer Text hat eine Entropie von etwa 4.0, eine Zip-komprimierte Datei eine Entropie von etwa 7.2, was in etwa auch für eine mit AES 128-verschlüsselte Datei gilt.

Damit sind die vorliegenden Binärdaten komprimiert oder verschlüsselt, wobei ich auf das Zweite tippe. Der Inhalt der zu /terminal/client/register übertragenden Binär-Daten, der alle 5 Minuten erfolgt, ist übrigens jedes mal der Gleiche. Wenn es sich um eine symmetrische Verschlüsselung zwischen TV-Box und Command-and-Control-Server handelt, dann müssen die Daten in irgendeinem Programm auf der TV-Box verschlüsselt werden und es muss auch irgendwo auf der TV-Box der Schlüssel hinterlegt oder zusammengesetzt werden.

Und welches Programm (App bzw. Package) genau schickt jetzt etwas an dcylog.com?

Um hier weiter zu forschen, müsste man als Erstes das Programm auf der Badbox ausfindig machen, das den HTTP-Post an dcylog.com abschickt und dieses dann genauer analysieren. Heißt: Reverse Engineering und Dekompilierung betreiben, um herauszufinden, was das Programm macht. Ein Riesen-Aufwand. Eventuell würde man dann auch die Stelle finden, bei dem der Schlüssel verarbeitet wird und könnte den extrahieren, um dann schließlich herauszufinden, was da genau in den POST-Daten im Klartext übertragen werden soll.

In das Wireshark-Tool androiddump, das bei mir seltsamerweise nur in C:\Program Files\Wireshark funktioniert, obwohl die .exe woanders liegt, hatte ich diesbezüglich Hoffnungen gelegt, denn es läuft über ADB auf dem Android Gerät, also der Badbox und zeichnet dort den TCP-Traffic auf. Leider ohne den Namen des Prozesses oder die App dazuzuschreiben. Auch tcpflow über ADB Shell liefert keinen App-Namen mit.

Dann stolpere ich über die Android App PCAPdroid, die wieder auf der Badbox selbst läuft und Wireshark-kompatible Cap-Files erstellt, die dann den App-Namen beinhalten sollen. Das tun sie auch, nachdem extra ein Plugin dafür in Wireshark installiert ist:



Allerdings stehe ich hier wieder vor dem Problem wie beim Artikel Analyse des Android bzw. in diesem Artikel mithilfe von "Firewall ohne Root" (siehe weiter oben), dass die App hier einfach nur "Android" heißt und das schließt ja bekanntermaßen zahlreiche Apps mit ein:



Man kann zwar in PCAPdroid auch nur für bestimmte Apps die Protokollierung einschalten, aber die Auflistung der Apps ist nicht kleinteilig genug und richtet sich nicht nach den installierten Packages. Und da waren mir ja eher com.hx.guardservice, com.hx.devicemonitor, com.hx.update, com.hx.appcleaner, com.hx.rcs, com.hx.mboxlauncher, com.hxdevicetest und com.hx.videotest suspekt.

Es stellte sich leider heraus, dass meine zweite TV-Box, die H20pro ebenfalls Anzeichen eines Malware-Befalls zeigt. Darum unterziehe ich auch sie einer Untersuchung des DNS und HTTP-Internetverkehrs.

Vielleicht sollte ich als nächstes versuchen, ein verdächtiges Paket nach dem anderen zu deinstallieren und dann zu schauen, ob die Zugriffe auf dcylog.com dann immer noch geschehen. Sollten die Zugriffe nach Deinstallation eines bestimmten Pakets aufhören, dann wird dieses das mit der Malware sein und ich habe hoffentlich wieder eine saubere H20-Box - oder ich habe sie dann gebricked.

Aber das soll Stoff für einen eventuell weiteren Artikel sein, den ich dann ggf. hier verlinken werde.

Zusammenfassung Netzwerkverkehr Analyse

Die Badbox-Malware auf meiner H20 TV-Box kann also durch folgende Vorkommen im Netzwerk-Traffic identifiziert werden:

Nachtrag 2025-01-29

Ich habe einen Desinfektionsversuch der Badbox Malware an der TV-Box H20 (RK3228a CPU und Mali-400MP2 GPU) unternommen, bin diesmal aber gescheitert. Die Malware scheint hier zu tief im System verankert zu sein, als dass man sie entfernen könnte und gleichzeitig läuft die Box noch.

Nachtrag 2025-01-31

Und auch bei dieser Box, der H20pro gibt es Neuigkeiten und einen neuen Artikel: Entfernen der Badbox Malware von der bei AliExpress gekauften TV-Box H20pro (Allwinner H616 CPU und Mali G31 GPU)



Quellen, Literaturverweise und weiterführende Links