Mein Hetzner-Server wurde gehackt und begann, Monero zu schürfen

 (blog.jakesaunders.dev)
1 Punkte von GN⁺ 2025-12-19 | 1 Kommentare | Auf WhatsApp teilen
  • Auf einem privat betriebenen Hetzner-Server wurde eine ungewöhnliche CPU-Auslastung festgestellt; die Untersuchung ergab, dass ein Kryptowährungs-Miner für Monero (xmrig) lief
  • Ursache war ein Angriff auf den Umami-Analytics-Container, der die Remote-Code-Execution-Schwachstelle in Next.js (CVE-2025-66478) enthielt
  • Glücklicherweise lief der Container als Non-Root-Benutzer und ohne Host-Mounts oder Privilegienerweiterung, sodass der Einbruch auf den Container beschränkt blieb
  • Die Angreifer nutzten unsichere Deserialisierung in Next.js Server Components, um eine schädliche Payload auszuführen und den Miner zu installieren
  • Der Vorfall zeigt die Bedeutung von Dependency-Management und sicheren Container-Einstellungen; der Autor verschärfte daraufhin seine Sicherheitsmaßnahmen mit aktivierter Firewall, gehärtetem SSH und regelmäßigen Updates

Der Hack und die erste Reaktion

  • Von Hetzner kam eine Warn-E-Mail, dass der Server externe Netzwerke gescannt habe
    • Einschließlich des Hinweises, dass der Server ohne Gegenmaßnahmen innerhalb von 4 Stunden gesperrt werden könnte
  • Nach dem Login per SSH zeigte sich ein Prozess mit 819 % CPU-Auslastung unter /tmp/.XIN-unix/javae sowie mehrere xmrig-Prozesse
  • Es stellte sich heraus, dass etwa 10 Tage lang Kryptowährungs-Mining betrieben worden war

Untersuchung des Angriffswegs

  • Alle schädlichen Prozesse liefen unter dem Benutzer mit UID 1001, was zum Umami-Container passte
  • Im Verzeichnis /app/node_modules/next/dist/server/lib/xmrig-6.24.0/ wurde die Miner-Binärdatei gefunden
  • Der Ausführungsbefehl enthielt die Adresse des Mining-Pools auto.c3pool.org:443 sowie einen Benutzerschlüssel

Next.js-Schwachstelle und Angriffsmethode

  • Ursache war die Deserialisierungs-Schwachstelle in React Server Components von Next.js (CVE-2025-66478)
    • Wenn Angreifer eine manipulierte HTTP-Anfrage senden, kann auf dem Server beliebiger Code ausgeführt werden
    • Dadurch wurde die Installation und Ausführung eines Kryptomining-Programms möglich
  • Der Autor war davon ausgegangen, „Next.js nicht direkt zu verwenden“, erkannte jedoch erst später, dass Umami auf Next.js basiert

Bestätigung der Container-Isolation

  • Es wurde bestätigt, dass /tmp/.XIN-unix/javae nicht im Host-Dateisystem existierte
    • Dass der Prozess in der Ausgabe von Docker-ps erschien, war lediglich ein Anzeigeeffekt; tatsächlich blieb die Isolation erhalten
  • Ergebnis von docker inspect:
    • Benutzer: nextjs
    • Privileged: false
    • Mounts: keine
  • Deshalb konnte die Schadsoftware nicht auf den Host zugreifen, keine Cronjobs eintragen, keine Systemdienste anlegen und kein Rootkit installieren

Wiederherstellung und Härtung der Sicherheit

  • Nach dem Stoppen und Löschen des infizierten Umami-Containers normalisierte sich die CPU-Auslastung
  • Durch das Aktivieren der UFW-Firewall wurden nur noch SSH, HTTP und HTTPS erlaubt
  • Nach dem Bericht der Untersuchungsergebnisse an Hetzner wurde das Ticket innerhalb einer Stunde geschlossen

Lehren und Verbesserungen

  • „Ich nutze X nicht“ gilt nicht automatisch für Abhängigkeiten
    • Man muss prüfen, aus welchem Technologie-Stack die verwendeten Tools bestehen
  • Die Wirksamkeit von Container-Isolation wurde bestätigt
    • Non-Root-Benutzer, nicht privilegierter Modus und der Verzicht auf unnötige Volumes verhinderten eine Ausweitung des Schadens
  • Notwendig ist eine mehrschichtige Sicherheitsstrategie (Defense in Depth)
    • Firewall, fail2ban, Monitoring und regelmäßige Updates sind essenziell
  • Hervorgehoben wurde die Bedeutung eines selbst geschriebenen Dockerfiles und minimaler Container-Berechtigungen

Maßnahmen nach dem Vorfall

  • Umami wurde auf die neueste Version aktualisiert und alle Third-Party-Container auditiert
    • Geprüft wurden Laufzeitbenutzer, Mounts, Update-Zeitpunkt und Notwendigkeit
  • Umstellung auf SSH-Schlüssel-basierte Authentifizierung, Deaktivierung des Passwort-Logins und Einrichtung von fail2ban
  • Ausbau des Monitorings mit Grafana und Node Exporter sowie sofortige Anwendung von Sicherheitsupdates

Fazit

  • Durch die Next.js-Schwachstelle in Umami wurde der Server 10 Tage lang zum Monero-Mining missbraucht,
    doch dank Container-Isolation und Non-Root-Konfiguration blieb der Schaden begrenzt
  • Durch diese Erfahrung erkannte der Autor die Wichtigkeit von Dependency-Transparenz, Sicherheitskonfiguration und Update-Management
  • Der Vorfall war in etwa zwei Stunden behoben und bleibt ein Praxisbeispiel für die tatsächliche Wirksamkeit von Container-Sicherheit

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-19
Hacker-News-Kommentare

  • Früher habe ich UFW aktiviert, aber heute empfehle ich firewalld.
    UFW wird mit der Zeit schwer zu verwalten, während firewalld mit XML-basierten Einstellungen deutlich robuster ist.
    Mit dem Befehl firewall-cmd lassen sich SSH, HTTPS, Port 80 usw. konfigurieren, und es ist besser, das nftables-Backend zu verwenden.
    Bei Docker werden Ports oft unter Umgehung der Firewall-Regeln geöffnet, daher ist es sicherer, in /etc/firewalld/firewalld.conf StrictForwardPorts=yes zu setzen.

    • Statt Ports wie 8080:8080 zu öffnen, ist es besser, sie wie 192.168.0.1:8080:8080 an eine private IP zu binden.
      Ich betreibe Docker auf einer VM mit 10.0.10.11, die nur über WireGuard erreichbar ist, und nutze davor bequem Caddy als Reverse Proxy.
    • Es wird empfohlen, statt Docker Podman zu installieren. Bei Docker treten Probleme mit Firewall-Umgehung häufig auf.
    • Egal welches netfilter-Frontend man nutzt: Ohne Beschränkung ausgehender Verbindungen ist das alles sinnlos.
      Schadsoftware versucht, sich mit externen Mining-Pools oder C2-Servern zu verbinden, daher muss der Netzwerkzugriff nicht erlaubter Binärdateien blockiert werden.
      Hilfreich ist auch, die Ausführungsrechte für /tmp, /var/tmp und /dev/shm zu entfernen.
    • Hetzner bietet eine kostenlose externe Firewall an, die sich als erste Verteidigungslinie nutzen lässt.
    • Persönlich finde ich, dass schon nftables.conf allein einfach und klar genug ist.
      iptables ist bereits abgekündigt, daher braucht man nicht zwingend eine zusätzliche Schicht wie firewalld.

  • Das scheint ein Problem im Zusammenhang mit React2Shell CVE-2025-55182 zu sein.
    Es ist seltsam, dass eine Schwachstelle, die seit über einem Jahr Auswirkungen hat, kaum Aufmerksamkeit bekommt.
    Wenn du in den letzten 12 Monaten eine Web-App mit Next.js ausgerollt hast, ist sie mit hoher Wahrscheinlichkeit bereits Teil eines Botnetzes.
    Es ist frustrierend, dass die Branche nur Ratschläge auf dem Niveau von „Nutze Docker“ oder „Aktiviere eine Firewall“ gibt.
    In letzter Zeit bin ich vom Frontend-Ökosystem so ernüchtert, dass ich überlege, meine Karriere eher in Richtung C++ zu verlagern.

    • Der Technologiewechsel-Zyklus im Frontend hat sich im Vergleich zu früher stark beruhigt.
      Heute ist die Kombination aus Next.js, React, Tailwind und Postgres seit fünf Jahren fast schon als Standard zementiert.
      Verglichen mit der Zeit der Framework-Schwemme Ende der 2000er bis Anfang der 2010er ist das ziemlich stabil.
      Wenn dir Trends und Veränderungen nicht gefallen, dann verändert sich AI-Entwicklung deutlich schneller.
    • Man kann Web-Apps problemlos bauen, ohne die neuesten JS-Frameworks zu verwenden.
      Im Backend kann man solide Tech-Stacks wie .NET, Java oder Go einsetzen und das Frontend frei wählen.
      So gibt es weniger CVEs und weniger technische Ermüdung.
    • Meine Pangolin-Instanz wurde ebenfalls über diese Schwachstelle kompromittiert.
      Zugehörige GitHub-Diskussion
    • Ich habe ebenfalls ungefähr 100 Next.js-Frontends ausgerollt, war aber zum Glück nicht betroffen, weil ich keine Server Components verwendet habe.

  • Wenn man die CPU-Nutzung eines Docker-Containers mit --cpus="0.5" begrenzt, können fehlfunktionierende Dienste oder Miner nicht das gesamte System beeinträchtigen.

    • Wenn man Container im Read-only-Modus betreibt, lässt sich die Angriffsfläche weiter reduzieren.
    • Ist das CPU-Limit allerdings zu niedrig, kann ein Eindringling unauffällig bleiben und die Erkennung verzögern.
    • Man sollte das Leistungsprofil der Anwendung gut kennen. Kommt später Burst-Traffic dazu, kann unbeabsichtigt gedrosselt werden.
    • Es ist sinnvoll, zusätzlich Soft- und Hard-Limits für den Speicher zu setzen.

  • Einen Server ohne Firewall zu betreiben, ist eine ziemlich mutige Entscheidung.
    Nutzt man zusätzlich Hetzners externe Firewall, hat man bei Fehlern noch eine weitere Schutzschicht.
    Ich erlaube SSH nur von meiner Heim-IP aus und öffne es bei Bedarf von außen vorübergehend über die Hetzner-Website.

    • In den meisten Fällen bringt eine Firewall keinen großen Effekt.
      Wirklich wichtig ist, keine Software mit RCE-Schwachstellen zu betreiben.
      Dass Docker wie ein Retter wirkt, ist in Wahrheit oft einfach nur Glück.
    • Für öffentliche Webservices hilft eine Firewall nicht besonders viel.
      Stattdessen kann man einen Bastion Host einsetzen und Ein- und Ausgaben über einen HTTP-Proxy steuern, aber die Einrichtung ist komplex.
    • In 30 Jahren Linux-Betrieb wurde ich nur dann gehackt, wenn ich bekannte Ports offen hatte.
      Schon die Nutzung nicht standardisierter Ports war überraschend effektiv.
    • Passwort-Authentifizierung aktiviert zu lassen, ist riskant. Persönlich halte ich fail2ban nicht zwingend für notwendig.
    • Ich ändere den SSH-Port zufällig, um Port-Scannern auszuweichen.
      Ob das wirklich wirksam ist, weiß ich nicht, aber es fühlt sich wie eine psychologische Art Regenschirm an.

  • Ich habe mich gefragt, ob ein Docker-Container, der als root läuft, auch den Host angreifen kann.

    • Docker ist keine Sicherheitsgrenze. Es bietet nur Isolation auf Prozessebene.
      Für nicht vertrauenswürdigen Code sollte man VMs (KVM/QEMU) oder Technologien wie gVisor(https://gvisor.dev/) und Firecracker(https://firecracker-microvm.github.io/) verwenden.
      Docker sollte man eher als isolierte Laufzeitumgebung verstehen, nicht als Sandbox.
    • Ein Angreifer kann auch innerhalb eines Containers CPU nutzen und Monero minen.
      Die Standardkonfiguration von Docker begrenzt RAM-, CPU- und Festplattennutzung nicht und ist daher auch anfällig für DoS-Angriffe.
      Außerdem empfehlen viele Anleitungen riskante Optionen wie --privileged oder CAP_SYS_PTRACE.
    • Im privilegierten Modus ist über den Docker-Socket Zugriff auf das Root-Dateisystem des Hosts möglich.
      Man kann auch einen neuen Container starten und sich Root-Rechte verschaffen.
    • Erst mit aktivierten User Namespaces entsteht eine echte Sicherheitsgrenze.
      Bei Docker ist das noch nicht der Standard, daher ist das Ausbruchsrisiko hoch, wenn man es nicht konfiguriert.
      Die meisten Container-Escapes in der Vergangenheit hätten durch User Namespaces verhindert werden können.
    • Container-Escapes existieren zwar, aber meist handelt es sich nur um einfache automatisierte Mining-Angriffe.
      Bei Servern, die keine sensiblen Daten verarbeiten, reicht es oft aus, nur den Container aufzuräumen.

  • Um die Angriffsfläche zu verringern, sollte man Dienste, die nicht öffentlich sein müssen, nicht nach außen exponieren.
    Zum Beispiel kann man Analyse-Tools so konfigurieren, dass sie nur über WireGuard oder einen SSH-SOCKS-Proxy erreichbar sind.

  • Ich hatte auf einem Hetzner-Server ebenfalls eine Monero-Miner-Infektion.
    Zum Glück trat sie nur innerhalb eines LXC-Containers unter Incus auf, und wegen der niedrigen CPU-Priorität habe ich es zunächst nicht bemerkt.
    Dem root-Konto wurden SSH-Schlüssel hinzugefügt, und ein Remote-Management-Agent war installiert worden.
    Letztlich habe ich den Container verworfen, aber ich habe einige Lehren daraus gezogen.

    • Man sollte davon ausgehen, dass ein System irgendwann kompromittiert wird, und deshalb Isolation und Ressourcenlimits konfigurieren.
    • Wenn man regelmäßig ZFS-Snapshots und Backups pflegt, ist die Wiederherstellung einfach.
    • Idealerweise verwirft man ein kompromittiertes System, aber je nach Situation ist auch ein Rollback mit anschließender Härtung möglich.
    • Der Miner fiel auf, weil er schlecht konfiguriert war; wäre der Eindringling leiser vorgegangen, hätte ich es womöglich nicht bemerkt.
    • Es geschah in einem Container, in dem Umami installiert war.

  • Der Beitrag enthielt AI-Halluzinationen, die nicht von einem Menschen gegengelesen worden waren.
    Wiederholt wurde behauptet, es handle sich um eine Schwachstelle rund um Puppeteer, was aber nicht stimmt.

    • Im ersten Absatz des Originaltexts stand ausdrücklich, dass es sich um ein Transkript einer Claude-Session handelte.

  • In letzter Zeit werden an vielen Stellen Monero-Miner über eine React-19-Schwachstelle installiert.
    Ich hatte dasselbe Problem.

    • Solche Mining-Malware ist auffällig und richtet relativ wenig Schaden an, was sie fast schon nützlich macht.
      Sie funktioniert wie eine Art automatisches Bug-Bounty-System und weist einen auf die Schwachstelle hin.
      Wenn Netzwerk- oder Prozessmonitoring gut eingerichtet ist, lässt sie sich leicht erkennen.
    • Auf Oracle Cloud wurde ein Umami-Server infiziert, woraufhin ich den Server zurückgesetzt habe.
      Das war zugleich ein guter Anlass, mein Backup-System zu verbessern.

  • Wenn ich solche Fälle sehe, bin ich froh, keinen VPS selbst zu betreiben.
    Ich habe das früher gemacht, aber ich bin eben nur ein durchschnittlicher Administrator, und es fiel mir schwer, die Sicherheit aufrechtzuerhalten.
    Deshalb überlasse ich es heute lieber Experten und zahle dafür, was mir deutlich mehr Ruhe gibt.