Ich habe Stackoverflow analysiert – Matan-h

Hintergrundgeschichte

Manchmal lese ich Hackernews und Artikel wie „Ich habe den gesamten Code von PyPI auf GitHub gespiegelt und analysiert“ ließen mich denken, dass es vielleicht weniger offensichtliche Stellen mit durchgesickerten Informationen gibt.

Das hatte ich bis vor kurzem im Hinterkopf, als ich versuchte, zum Buildozer-Projekt beizutragen. Ich habe umfangreiche Protokolle implementiert und hatte das Gefühl, Buildozer zu verstehen, also suchte ich nach Stackoverflow-Fragen dazu. Dann entdeckte ich, dass buildozer im Gegensatz zu beeware tatsächlich die gesamte Umgebung speichert, wenn ein Befehl fehlschlägt (z. B. eine Ausgabe, siehe diese alte Frage), und dachte: „Was wäre, wenn dieser Benutzer die App mit einer sensiblen API erstellen würde?“

Also habe ich stackOverflow vom Dump von stackexchange archive.org heruntergeladen und angefangen, darüber nachzudenken, wie ich es analysieren kann. Es handelt sich um eine riesige (103G) XML-Datei, in der jede Zeile eine Frage oder Antwort darstellt.

Ich habe verschiedene „Leckerkennungs“-Tools ausprobiert, die meisten sind abgestürzt oder haben zu viel CPU beansprucht:

• Gitleaks: fatal error: runtime: out of memory

• truffleHog: Funktioniert tatsächlich (und benötigt 100 % CPU), liefert aber sehr schlechte Ergebnisse (z. B. eine einfache %s gilt als SQL Server Base64-codiert: Detector Type: SQLServer,Decoder Type: BASE64,Raw result: %s ).

• ripsecrets: 1 Stunde nachdem ich es ausgeführt habe, keine Ausgabe.

• (Yelp) Erkennungsgeheimnisse: Traceback (most recent call last): ... MemoryError

• ripgrep: Mein System friert nach ein paar Minuten ein.

Also kehrte ich zu meinem ZSH zurück und tat es grep und ich schreibe sogar ein eigenes Rust-Skript, um die Suchvorgänge durchzuführen.

Wie ich vermutet habe, gibt es viele Lecks im Stackoverflow (im Diagramm werden nur eindeutige und keine Junk-Daten angezeigt. Klicken Sie auf eine Beschriftung, um sie auszublenden):

Wie Sie sehen, viele Daten.

Dann fragte ich mich: Was könnte ein Angreifer mit diesen Informationen anfangen? Es stellt sich heraus, dass das meiste davon nutzlos ist:

Für die Nutzung der meisten Daten benötigen Sie mehr Informationen als nur den API-Schlüssel. Für Stripe benötigen Sie beispielsweise die Kunden-ID. Für Grafana eine Instanz-URL. Für aws eine Website-URL.

Und selbst wenn Sie über einen API-Schlüssel verfügen, der an einen zentralen Ort gesendet wird, ohne dass ein „Benutzername“ erforderlich ist, sind die meisten Daten veraltet. Alle JWTs (JSON Web Tokens) – vergessen Sie sie, die durchschnittliche Lebensdauer eines JWT beträgt einen Monat.

Bis ich einen einfachen Scan durchführe (wieder mit den besten Hacking-Tools: xargs Und curl ) gegen alle 74 echt aussehenden GitHub-Benutzertokens (ein Token, das praktisch dem gesamten GitHub-Benutzer Zugriff gewährt) und stellte fest, dass 6 davon tatsächlich gültig sind.

Dennoch haben nur zwei von ihnen tatsächlich eine Biografie und eine E-Mail-Adresse, aber einer von ihnen (AC/C++-Entwickler) hat ein Repo mit 3.4k Sterne. So fand ich endlich den Weg, den ein Angreifer einschlagen würde.

Ich habe beiden Entwicklern eine E-Mail geschickt (ich habe ihnen von dieser Recherche erzählt und sie auf die Frage verwiesen, wo sie den Token preisgegeben haben, mit einem kleinen „Wenn Sie diese Nachricht hilfreich finden, können Sie mir einen Kaffee spendieren“ am Ende) und beiden hat die Token widerrufen (und beide haben mir tatsächlich einen Kaffee gekauft, das erste Mal, dass ich Geld bekam, seit ich im März 2021 dieses buymeacoffee-Konto eröffnet habe!).

Ich konnte offensichtlich nicht alle Geheimnisse überprüfen. Von den meisten davon werde ich wahrscheinlich ausgeschlossen, also habe ich mich hierher geworfen.

Ursache

Im Gegensatz zu PyPi- und GitHub-Leaks-Artikeln ist dieser Artikel nicht darauf zurückzuführen, dass Personen das Passwort in ihrem Browser hinterlassen haben deploy-to-server.py und es versehentlich begehen (na ja, manchmal kopieren sie deploy-to-server-example.py in den Stackoverflow und vergiss, die ID zu maskieren …).

Die meisten Lecks treten in der Ausgabe von Tools auf, einer langen Ausgabe, die die Leute aufgrund der Veröffentlichung gerne direkt in den Stackoverflow kopieren/einfügen, ohne sie wirklich anzusehen die Ausgabe/die Tool-Konfigurationsdatei des Tools, das sie verwenden (z. B. wussten Sie das? curl -v Zeigt Ihre Anfrage auch mit den Kopfzeilen oder einer langen an package.json mit privaten Abhängigkeiten enthalten kann git+your-private-gh-token ? )

why is this not working?  I run this command curl -v --path-as-is 'https://matan-h.com/[redundant]'
and I get this output:
*   Trying 185.199.108.153:80...
* Connected to matan-h.com (185.199.108.153) port 80 (#0)
> GET /404/../ddebug/../my-windows-shell/../list-of-online-converter-tools/../exec_python_code_super_secret_4h0a4b?code=print("hi") HTTP/1.1
> Host: matan-h.com
> User-Agent: curl/40.4.0
> Accept: */*
> Accept-Encoding: deflate, gzip, br
>
< HTTP/1.1 301 Moved Permanently

Ich hoffe, Ihnen hat der Artikel gefallen und Sie achten mehr darauf, was Sie in StackOverflow kopieren/einfügen.