Cloud
Security Breaks: TeamTNT’s DockerHub Credentials Leak
One of our honeypots based on exposed Docker REST APIs showed cybercriminal group TeamTNT’s potential attack scenario and leak of container registry credentials for docker-abuse malware. The full version of this research will be presented at the c0c0n XV Hacking and Cyber Security Conference in September 2022.
Wir setzen unsere Honeypots ständig ein, um einen Überblick über aktiv ausgenutzte Schwachstellen und Fehlkonfigurationen auf Plattformen und Services zu erhalten, die ein Sicherheitsrisiko für die Cloud darstellen. Einer dieser Honeypots basiert auf der exponierten Docker REST API und soll der Untersuchung aus der Perspektive der Anbieter und Nutzer von Cloud-Diensten dienen. Über die Analyse der Samples konnten wir uns ein Bild darüber machen, wie die Bedrohungsakteure die Container-Registry-Funktionen für Docker-Malware und Taktiken, Techniken und Verfahren (TTPs) nutzen.
Unsere Honeypots zeigten, dass TeamTNT Anmeldeinformationen von mindestens zwei von den Angreifern kontrollierten DockerHub-Konten (alpineos mit über 150.000 Zugriffen und sandeep078 mit 200 Zugriffen), weitergegeben hatte. Wir haben Docker über diese Konten informiert.
Das Konto alpineos wurde von Mitte September bis Anfang Oktober 2021 dreimal für Angriffsversuche auf unsere Honeypots verwendet, und wir konnten die IP-Adressen der Einsätze bis zu ihrem Standort in Deutschland zurückverfolgen. Die Bedrohungsakteure waren in ihren Konten in der DockerHub-Registrierung angemeldet und hatten wahrscheinlich vergessen, sich abzumelden. Diese DockerHub-Profile wurden aktiv genutzt, um bösartige Images bereitzustellen, die Rootkits, Docker Escape Kits, XMRig Monero Miner, Credential Stealer und weitere Malware enthielten.
Bereits im Juli 2021 publizierten wir unsere Recherche zu TeamTNTs bösartigen Aktivitäten und lieferten Beweise dazu, dass die Gruppe sich über Docker API eingeschleust hatte. Wir hatten 26 einzigartige DockerHub-Konten gefunden, die entweder kompromittiert oder bösartig sind. Für die Untersuchung am interessantesten ist das alpineos-Konto, das bösartige Container-Images mit über 150.000 Pulls gehostet hat.
Container Registries und Docker Daemon
Docker ist eine Plattform für Container-Services, die die Entwickler dabei unterstützt, eine Write-Once-Run-Anywhere (WORA)-Praxis zu verfolgen. Sie ist einfach zu bedienen und Entwickler schätzen sie, da sie Services und Anwendungen sehr schnell erstellen und bereitstellen können. Am wichtigsten ist, dass Docker mit jeder Plattform funktioniert.
Container-Registries sind Speicher- und Verteilungsplattformen für Container-Images, ähnlich wie Codes oder Programme auf Repositories wie GitHub gehostet werden. Mit dem richtigen Autorisierungskontext kann man einfach ein Image „ziehen“, einen darauf basierenden Container erstellen und Anwendungen bereitstellen. Viele Container-Registries wie DockerHub, Amazon Elastic Container Registry (ECR) und Alibaba Container Registry hosten Container-Images.
Beim Erstellen eines Containers sucht der Container-Daemon das Image standardmäßig in der Container-Registry. In unserer Analyse verwenden wir DockerHub als Beispiel.
Wird die Registry nicht angegeben, so gilt standardmäßig DockerHub. Docker bietet Entwicklern eine Funktion zur Erstellung von Containern auf einem entfernten Host, wenn der Docker-Daemon (auf dem Server) so konfiguriert ist, dass er über den TCP-Port lauscht, der standardmäßig Port 2375 ist. Dies erleichtert Entwicklern die Remote-Entwicklung und -Bereitstellung, da es eine Schnittstelle zu verschiedenen Docker-Diensten wie Images, Containern, Netzwerken und Medien mit Tools wie curl, wget und docker-cli bietet. Den Ablauf der Erstellung eines Containers mit Docker REST API können Sie im Originalbeitrag nachlesen.
In einem legitimen Anwendungsfall möchte ein Benutzer möglicherweise sein DockerHub-Repository authentifizieren, um Container auf der Grundlage der Images in seinem privaten Repository zu erstellen. Vergisst der Benutzer jedoch, sich von DockerHub abzumelden, und erstellt Container auf nicht vertrauenswürdigen Hosts mit dockerd, die über TCP offengelegt werden, ist er einem Risiko ausgesetzt, da seine Benutzernamen und Kennwörter hart codiert und nicht verschlüsselt sind, ganz zu schweigen von der Base64-Codierung.
Credential Leak-Szenarien
Im ersten Szenario ist das Opfer bei seiner DockerHub-Registry angemeldet. Ein Angreifer verschafft sich Zugriff auf die virtuelle Maschine (VM) des Opfers und versucht, einen Container auf einem Remote-Server mit dem über TCP exponierten dockerd zu erstellen. Wenn das Image, das der Container zu erstellen versucht, nicht existiert, wird das Image aus DockerHub gezogen und der Header X-Registry-Auth wird mit den Base64-kodierten Anmeldeinformationen gefüllt.
Sobald sie missbraucht werden, können diese kompromittierten Konten dazu verwendet werden, die folgenden Informationen einzusehen und sogar auf die folgenden Arten zu verändern:
- Zugehörige Mails und wiederverwendete Anmeldedaten. Cyberkriminelle können nach Passwörtern suchen, die über verschiedene Plattformen hinweg wiederverwendet werden, und nach Passwort-Leaks sehen.
- Private Repositories und Images. Diese können Anmeldeinformationen wie API-Schlüssel enthalten und private Images durch Backdoors verändern.
- Zugriffs-Token. Diese können verwendet werden, um dauerhaften Zugang zum Konto zu erhalten.
- Werkzeuge für Entwickler. Pro-Funktionen (wie Teams, Organization und Build-Pipelines) können genutzt werden, um die auf Docker basierenden Build-Pipelines zu infizieren und so Supply-Chain-Angriffe durchführen.
Ein anderes Angriffsszenario könnte das Konto des Angreifers selbst betreffen, wobei die Cyberkriminellen bei ihrer eigenen DockerHub-Registry angemeldet sind und ihre Konten Anmeldedaten durchsickern lassen. Legitime Benutzer machen sich vielleicht keine Gedanken über den Diebstahl der Anmeldedaten von Bedrohungsakteuren, aber wir haben untersucht, dass das Verfahren zur Erstellung eines neuen Containers auch für die Ergreifung von Bedrohungsakteuren geeignet ist, die sich aus ihren jeweiligen Konten nicht ausgelogg haben. Vielleicht versuchen sie, einen Container mit einem exponierten Dockerd über TCP zu erstellen. Da in unserem Honeypot tcpdump läuft und den Netzwerkverkehr als Packet Capture (PCAP) aufzeichnet, können wir die in Base64 codierten Anmeldedaten des Angreifers abrufen.
Fazit
Kleine Lücken wie Fehlkonfigurationen von Komponenten in Containern können von Cyberkriminellen missbraucht werden. Sie führen über diese Lücken schädliche Aktivitäten durch, wie z. B. die Kompromittierung des Hosts für Kryptowährungs-Mining, die Exfiltration sensibler Informationen wie Schlüssel und Anmeldedaten oder übernehmen im schlimmsten Fall die Kontrolle über die Server der Opfer, um neben anderen illegalen Aktivitäten die Nutzung von Botnet-Malware auszuweiten. Solange es Komponenten und Konten gibt, die missbraucht werden können, hören cyberkriminelle Gruppen wie TeamTNT so schnell nicht auf. Aufgrund unserer Beobachtungen konnten wir die Konten von TeamTNT aufgrund des Fehlers eines Mitglieds dreimal identifizieren.
Wir raten Sicherheitsteams, Richtlinien für den Zugriff und die Verwendung von Anmeldeinformationen und Bedrohungsmodelle für ihre Umgebungen zu erstellen. Sie können diese nutzen, um Entwickler darüber aufzuklären, was schiefgehen kann. Im Folgenden finden Sie einige Maßnahmen zur Schadensbegrenzung für Unternehmen und Entwickler:
- Bei der Erstellung von Containern auf einem Remote-Host über die REST-API des Docker-Daemons sollten sich die Entwickler bewusst sein, dass die DockerHub-Anmeldeinformationen ebenfalls weitergegeben werden, wenn sie Images von der angegebenen Container-Registry erstellen. Sie sollten dies nur dann tun, wenn der entfernte Host vertrauenswürdig ist.
- Angesichts der steigenden Zahl bösartiger Open-Source-Pakete, die es auf die Anmeldedaten von Benutzern abgesehen haben, sollten Benutzer es vermeiden, Anmeldedaten in anderen Komponenten wie Umgebungsvariablen zu speichern. Stattdessen sollten sie Tools wie Credential Stores und Helpers verwenden.
- Wenn Benutzer den Docker-Daemon über die REST-API über das Internet verwenden müssen, wird empfohlen, die exponierte REST-API mit dem TLS-Protokoll (Transport Layer Security) zu konfigurieren, um Man-in-the-Middle-Angriffe (MiTM) zu vermeiden.
Eine vollständige Liste der IOCs finden Sie in unseren Blogeinträgen zu früheren Vorfällen, die wir hier und hier dokumentiert haben.