Kein Ausfall, kein Datenverlust, kein laufender Schadcode -- aber ein echter
Schreibzugriff von aussen.
Um 21:13:56 rief jemand /api/internal/manager/add-logger auf, legte einen
Datei-Logger auf die .gitconfig, liess die Nutzlast als Logzeile hineinschreiben
und entfernte den Logger eine Sekunde spaeter wieder. Eingeschleust war ein
packObjectsHook, der bei JEDEM Klonen einen Monero-Miner nachgeladen und per
crontab verankert haette.
WARUM TROTZDEM NICHTS LIEF: die Nutzlast beginnt mit "[uploadpack]\n", wobei
das \n als TEXT in der Datei steht statt als Umbruch. Git bricht mit "bad
config line 23" ab, der Hook wurde nie gueltig. Nachgemessen: kein Prozess,
keine Datei, keine crontab-Zeile, nichts in den Repos, kein Docker-Socket im
Container, keine fremden Konten oder Token. Der einzige Schaden war, dass alle
Git-Operationen ausfielen -- daran ist es aufgefallen.
DER WEG HINEIN: Gitea lag mit 0.0.0.0:3000 direkt im Internet, am Proxy vorbei.
Damit war /api/internal/* von aussen erreichbar, geschuetzt nur durch das
INTERNAL_TOKEN. Woher der Angreifer es hatte, liess sich NICHT klaeren -- es
steht in keinem Repo, und RDP war es nicht (2756 Fehlversuche in 14 Tagen, aber
alle 33 erfolgreichen Anmeldungen von der IP des Betreibers). Genau deshalb ist
die Antwort nicht "Token tauschen", sondern den Weg zumachen.
GEAENDERT: .gitconfig gesaeubert; Port 3000 gar nicht mehr veroeffentlicht; NPM
haengt jetzt mit in gitea_default und spricht gitea:3000 an (dafuer musste der
nginx-Resolver auf Dockers DNS 127.0.0.11 umgestellt werden); INTERNAL_TOKEN
und SECRET_KEY getauscht (gefahrlos: 2FA und Anmeldequellen jeweils 0);
/api/internal/ gibt am Proxy 404; frisches Abbild statt des elf Tage alten.
Gegengeprueft: Port 3000 von aussen 000, /api/internal/ 404, git.d4rkst3r.de
200, LFS-Direktiven alle drei erhalten, Push geht beim ersten Versuch, Repos
identisch mit den lokalen Klonen.
DIE LEHRE: der offene Port war nie noetig -- der Proxy haette von Anfang an
uebers interne Netz gehen koennen. Und aufgefallen ist es nicht, weil etwas
ueberwacht wurde, sondern weil der Angreifer geschludert hat. Haette er sein \n
richtig gesetzt, liefe der Miner noch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D4rkst3randClaude Opus 5
9727eae0f5