CloneGuard durchsucht fremde Repos nach Diebstahl-Tricks, bevor du sie ausführst
HN: CloneGuard – scan a repo for credential-stealing tricks before you run it
Ein angeblicher Recruiter schickt eine „Demo-App“, du klonst sie, führst npm install aus – und schon wandern SSH- und AWS-Schlüssel nach draußen. Genau dafür hat tharun208 CloneGuard gebaut: ein kleines Go-Kommandozeilenwerkzeug ohne Abhängigkeiten, das ein Projekt nur liest und nie ausführt. Es erkennt Zugriffe auf Zugangsdaten, versteckte Netzwerkaufrufe, obfuskierten Code und Auto-Run-Hooks wie .vscode/tasks.json und vergibt ein Urteil von clean bis dangerous.
„Keine roten Flaggen gefunden“ ist kein Beweis für Sicherheit. Es heißt nur, dass keiner dieser gängigen Tricks entdeckt wurde.
- tharun208
Hi HN, ich habe CloneGuard gebaut, nachdem mich ein falscher Recruiter in einem Call einen „Take-home“-Codebase hatte ausführen lassen. Ich habe ihn einmal laufen lassen, gestoppt und später ein KI-Tool gebeten, den Code zu erklären. Es war ein Stealer, der es auf SSH- und AWS-Keys abgesehen hatte. Ich habe es sofort der IT gemeldet, aber es hat mir klargemacht, dass ich keine schnelle Möglichkeit hatte, ein Repo zu prüfen, bevor ich es anfasse.
Bei diesen Angriffen ist die Payload oft nicht die App selbst. Es ist ein npm-Install-Skript oder eine .vscode/tasks.json-Aufgabe, die ausgeführt wird, sobald du den Ordner öffnest. Genau nach so etwas sucht CloneGuard.
Es ist eine einzelne Go-Binary ohne Abhängigkeiten und sie ist read-only. Sie führt nie etwas aus, installiert oder importiert nichts aus dem Projekt.
cloneguard clone https://github.com/someone/demo-app
cloneguard scan ./some-folder
Was es meldet:
Lesezugriffe auf SSH-Keys, Cloud-Credentials (AWS, GCP, Azure, kube), Browserdaten, Wallets
Verbindungen zu rohen IPs, Webhooks, Pastebins, Tunneln
Download-and-Run-Muster (eval, curl | sh)
Auto-Run-Hooks (npm-Skripte, VS-Code-Tasks, setup.py)
verschleierten Code und eingecheckte Binaries
Eine Datei, die sowohl Secrets liest als auch mit einem verdächtigen Server kommuniziert, wird zu „critical“ hochgestuft. Exit-Codes (0-3) machen es einfach, es in ein Skript oder einen Git-Hook einzubauen. Der demo/-Ordner enthält ein absichtlich bösartiges Beispiel, an dem du es ausprobieren kannst.
Einschränkungen: Es basiert auf Regex und Heuristiken, daher kann ein entschlossener Angreifer es umgehen, und legitimer Code (zum Beispiel ein Passwortmanager) kann Fehlalarme auslösen. „Clean“ bedeutet nicht sicher. Bei Code von Fremden solltest du trotzdem eine Wegwerf-[…]
- rsoto2
Wie wäre es, wenn wir einfach keinen Code ausführen, dem wir nicht vertrauen. Auf einem Laptop läuft schon genug bösartiger Code herum. Und an die Leute, die Bewerber dazu bringen, nicht vertrauenswürdigen Code auszuführen, und ihnen Desktop-Zugriff von Dritten geben: Warum findet ihr Idioten nicht heraus, wie man mit Menschen REDET, sich ihre Erfahrung anschaut und einen Einstellungsprozess auf die Beine stellt wie jedes normale Unternehmen, das nicht von unfähigen, umweltfeindlichen, menschenfeindlichen psychopathischen CEOs geleitet wird. Es ist wirklich nicht so schwer, über Pseudocode zu diskutieren, über Projekthistorie und Design zu sprechen und die Problemlösungsfähigkeiten von jemandem herauszufinden.
- bandie91
cool, jetzt wissen sie, wie sie sich besser verstecken können.
Warum nicht das Tooling verbessern, um nicht vertrauenswürdigen Code in isolierten Umgebungen auszuführen? Das deckt eine breitere Palette anwendbarer Situationen ab.