CERT-Bund meldet ein infiziertes Gerät. Welches?
TL;DR
- CERT-Bund meldete BadBox an der öffentlichen IP eines Kunden. Dahinter hängt ein ganzes Netz, darunter ein Bewohner-WLAN.
- Ein Verbindungslog gab es nicht. Ziel-IP und Domain kamen in keinem Log vor.
- Gefunden haben wir das Gerät trotzdem: über DHCP-Leases, die An- und Abmeldungen der Access Points und den Hersteller der MAC-Adresse.
Am Morgen kam die Mail von CERT-Bund. Ein Gerät hinter der öffentlichen IP unseres Kunden habe am Vorabend um 20:42 Uhr Kontakt zu ycxrl.com aufgenommen. Einstufung: android.badbox.
Der Kunde ist eine Einrichtung mit Bewohner-WLAN. Hinter der einen IP stehen eine UniFi Dream Machine Pro, über 20 Access Points, mehrere VLANs. Das Bewohnernetz ist als Gastnetz eingerichtet und kommt nicht ins LAN, aber ins Internet. Welches Gerät war es?
Was wir nicht hatten
Wir haben ein Support-Bundle von der UDM gezogen und durchsucht, auch die gepackten Archive. Die Ziel-IP: kein Treffer. Die Domain: kein Treffer.
Das lag nicht an der Suche. Die UDM schreibt von Haus aus keine Verbindungen weg, keine DNS-Abfragen und keine Firewall-Treffer. Die NAT-Tabelle im Bundle war eine Momentaufnahme vom nächsten Morgen. Den gemeldeten Quellport konnten wir damit keinem Gerät zuordnen. Mehr dazu in Ohne Logs keine Antwort .
Was wir hatten
Drei Dinge, die eigentlich für anderes gedacht sind:
- Die AP-Logs. Jeder Access Point schreibt mit, wann sich ein Gerät an- und abmeldet. Damit ließ sich sagen, wer um 20:42 Uhr verbunden war. 17 Geräte.
- Die DHCP-Leases. Sie liefern IP, MAC und Hostnamen, mit Zeitstempel.
- Den Hersteller der MAC. Die ersten drei Bytes einer MAC-Adresse verraten den Hersteller des Netzwerkchips.
Von den 17 waren sechs Android- oder IoT-Geräte. Eines fiel heraus:
- Hostname
android-plus 16 Hex-Zeichen, das alte Standardschema von Android. - WLAN-Chip von AMPAK. Diese Module stecken typischerweise in billigen TV-Boxen.
- Nur 2,4 GHz, obwohl das Netz auch 5 GHz sendet.
- Und vor allem: nur an diesem einen Abend im Netz, 26 Minuten lang. Zur gemeldeten Sekunde war es verbunden.
Genau so sieht BadBox aus: eine billige Box, kurz eingeschaltet, meldet sich sofort beim Steuerserver und ist wieder weg. Was BadBox ist, steht in BadBox: Die Malware steckt schon im Karton .
UniFi selbst zeigte übrigens nur „Google Inc., Android Device“. Das ist der generische DHCP-Fingerprint jedes Android-Clients, kein Modell. Der Hersteller aus der MAC hat mehr verraten als die Oberfläche.
Die falsche Fährte
In derselben Nacht meldete die UDM einen IP-Konflikt. Dazu ein Fernseher im Bewohnernetz mit rund 1.200 fehlgeschlagenen DNS-Abfragen. Das sah verdächtig aus.
Es war harmlos. Der Fernseher läuft auf einer Linux-Plattform, nicht auf Android. Er hielt nach Ablauf des Leases einfach seine alte Adresse fest, die DHCP inzwischen neu vergeben hatte. Seine DNS-Abfragen gingen an Mediatheken und HbbTV. Ein eigenes Problem, aber kein BadBox.
Was wir getan haben
- MAC gesperrt. Das Gerät war offline, die Sperre greift beim nächsten Einschalten.
- Stolperdraht gelegt. Eine Firewall-Regel blockiert das Gastnetz Richtung bekannte BadBox-Ziele, mit Log. Meldet sich das Gerät oder ein zweites, sehen wir es mit IP und MAC. Warum die Regel auf Domains gehen muss: IP sperren reicht nicht .
- Vor Ort nachfragen. Wir kennen den Access Point und den Zeitraum. Wer hat an diesem Abend eine TV-Box, einen Stick oder einen Bilderrahmen eingeschaltet?
Unsere Zuordnung hat mittlere Konfidenz. Zeitpunkt, Gerätetyp und Hersteller passen genau, ein direkter Verbindungsbeleg fehlt. Für die Sperre reicht das, für Gewissheit nicht. CERT-Bund bekommt die Rückmeldung, wenn das Gerät gefunden und vom Netz ist.
Die Lehre: Ohne Verbindungslogs ist das Detektivarbeit. Es geht, aber nur mit Glück, dass die Logs der richtigen Access Points noch nicht rotiert waren. Bei zehn von über 20 begann das Log erst nach dem Ereignis.