Ein Botnetz meldet Maschinen über die Docker Engine API an

Die Containerisierung entwickelt sich rasant und ist de facto für Cyberkriminelle von Interesse. Experten von Cado Security beobachteten eine Kampagne, die von einem Botnet namens OracleIV angeführt wurde, das auf Denial-of-Service-Angriffe spezialisiert war. Es hat die Besonderheit, Umgebungen mithilfe der Docker Engine-API über ein bösartiges Image anzugreifen. „Das Hosten des bösartigen Containers in Dockerhub, der Container-Image-Bibliothek von Docker, rationalisiert diesen Prozess weiter“, betonen die Forscher in einem Rapport.

Schädliches OracleIV-Bild

Der von Cado beobachtete Angriff beginnt mit einer HTTP-POST-Anfrage „/images/create“ an die ungeschützte Docker-API-Instanz. Als Nächstes verweisen Parameter auf ein Bild namens oracleiv_latest, das von einem Benutzer namens robbertignacio328832 auf Docker Hub hochgeladen wurde. Diese Anfrage entspricht einem Docker-Pull-Befehl, der das Container-Image herunterlädt und lokal installiert, gefolgt von einem Befehl zum Starten des Containers. Die gezielte Ausrichtung auf öffentlich zugängliche und ungeschützte Docker-Engine-APIs ist nicht neu. Mehrere Angreifergruppen suchen nach solchen Instanzen und setzen in der Regel Cryptojacking-Malware ein.

Dies ist der Fall bei einer Gruppe namens TeamTNT, die es hauptsächlich auf Cloud-Umgebungen abgesehen hat. Diese Gruppe steht hinter einem Wurm namens Silentbob, der Anfang des Jahres veröffentlicht wurde und auf unsichere Docker- und Jupyter-Notebook-Instanzen abzielte und AWS-Anmeldeinformationen stahl. Wie bei diesem Angriff hat TeamTNT seine bösartigen Container-Images von mehreren Konten aus auf Dockerhub gehostet. Das von Cado gefundene OracleIV-Image wurde regelmäßig aktualisiert und hatte über 3.000 Downloads, was darauf hindeutet, dass die Kampagne aktiv und erfolgreich war.

DDoS-Botnetz und Kryptojacking

Nach dem Start führt das kompromittierte Container-Image eine ELF-Binärdatei namens aus oracle.shSendungsverfolgung wget die eine Variante des XMRig-Kryptominers mit einer benutzerdefinierten Konfiguration anziehen und ausführen. Die XMRig-Instanz wird eigentlich nicht genutzt und diese Angreifer sind vielmehr daran interessiert, Serverressourcen für DDoS-Angriffe zu kapern. Die ausführbare Datei oracle.sh wurde ursprünglich in Python-Code geschrieben und mit Cython (C-Erweiterungen für Python) kompiliert. Der Code implementiert mehrere verschiedene DDoS-Methoden, darunter TCP-, UDP- und SYN-Paketfluten, sowie spezifische Variationen, die darauf abzielen, verschiedene Abwehrmaßnahmen zu überwinden. Beispielsweise umfasst das Standard-UDP-Flooding 40.000-Byte-Pakete, die aufgrund der Paketgrößenbeschränkung von UDP fragmentiert sind, wodurch auf dem Ziel ein Rechenaufwand entsteht, um die Fragmente wieder zusammenzusetzen. Allerdings implementiert das Botnetz auch UDP-Überläufe mit 18-, 20- und 8-Byte-Paketen. Diese werden mit Befehlen namens FIVE, VSE und OVH gestartet und scheinen auf FiveM-Server, Valves Source-Spiele-Engine und den französischen Cloud-Anbieter OVH abzuzielen.

Das Botnetz führt auch einen Slowloris-Angriff durch, bei dem zahlreiche Verbindungen zu einem Server geöffnet und kontinuierlich kleine Datenmengen gesendet werden, um diese Verbindungen offen zu halten. Der Client des Bots verbindet sich mit einem Command-and-Control-Server über eine gewöhnliche, hartcodierte, schlüsselbasierte Authentifizierung, sendet grundlegende Informationen über das Hostsystem und wartet auf Befehle. „Die Portabilität, die die Containerisierung mit sich bringt, ermöglicht die deterministische Ausführung bösartiger Payloads auf Docker-Hosts, unabhängig von der Konfiguration des Hosts selbst“, erklärten Cado-Forscher. „Obwohl es sich bei OracleIV technisch gesehen nicht um einen Supply-Chain-Angriff handelt, sollten Docker-Hub-Benutzer sich darüber im Klaren sein, dass in der Docker-Image-Bibliothek schädliche Container-Images vorhanden sind, ein Problem, das offenbar nicht gelöst wird. wird in naher Zukunft nicht behoben.“ Das Sicherheitsunternehmen empfiehlt Unternehmen, die Docker-Images, die sie vom Docker Hub abrufen, regelmäßig zu überprüfen, um sicherzustellen, dass sie nicht in Trojaner umgewandelt wurden. Darüber hinaus sollten sie sicherstellen, dass alle APIs und Schnittstellen zur Verwaltung von Cloud-Technologien wie Jupyter, Docker und Redis durch Authentifizierung gesichert und durch Firewall-Regeln geschützt sind.