
Proof-of-Concept und Lab für eine unauthentifizierte Gitea-Information-Offenlegung: Die Stargazers- und Watchers-API gibt Benutzernamen preis, die Profil-Endpunkte verbergen.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitea-stargazers-hidden
Gitea 1.27.3 - Gitea
Eingeschränkte und private Benutzer sollen für anonyme Betrachter verschwinden. GetInfo liefert für sie bereits 404. Follower-Listen wenden bereits isUserVisibleToViewerCond in SQL an. GetStargazers ist ein Join auf star ohne Sichtbarkeitsfilter. ListStargazers ruft dann convert.ToUser für die gesamte Menge auf. ListSubscribers hat dieselbe Form für Watcher.
Ohne Anmeldung nennt das Stargazers-JSON eines öffentlichen Repos Benutzer, die GET /users/{name} verbirgt.
| ID | noch keine CVE |
| CWE | CWE-200 |
| CVSS | Mittel: 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
| Produkt | Gitea |
| Betroffen | bis v1.27.3 (146cc3e) |
| Auth | unauthentifiziert |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1 |
Ohne Anmeldung die Stargazers und Watcher eines öffentlichen Repos lesen und Benutzernamen erfahren, die GET /users/{name} verbirgt. Das ist Recon auf eingeschränkte und private Konten, die etwas Öffentliches mit einem Stern versehen oder beobachtet haben: Personen, die die Sichtbarkeit so eingestellt haben, dass sie nicht in der Suche auftauchen, und dann trotzdem auf den Stern geklickt haben.
Es ist ein Benutzername, keine E-Mail, kein Lesezugriff auf privates Git, kein RCE. In Kombination mit dem Follow 204 vs 404-Orakel lässt sich bestätigen, dass ein verborgenes Login existiert, selbst wenn das Profil 404 liefert.
Sichtbarkeit war ein Thema der GHSA-Welle von 1.27.3. Wenn ein Produkt ein Profil absichtlich mit 404 beantwortet, ist die nächste Frage, welche Listen-Endpunkte weiterhin user ohne diese Bedingung joinen. Stars und Watcher tun das.
Ich habe hidstar als eingeschränkt angelegt, ein öffentliches Repo mit einem Stern versehen und beobachtet und die Instanz ohne Token angesprochen. Unauth GET /api/v1/users/hidstar ist 404. Das Unauth-Stargazers-JSON enthält hidstar. Unauth-Watchers enthalten hidstar. Unauth-Followers-HTML nicht. Das Profil ist schüchtern. Die Star-Tabelle ist es nicht.
Bereits dokumentierte Irrwege: unauth GET /users/hidstar liefert 200 (dann ist die Sichtbarkeit komplett aus - das Lab erfordert 404); Followers-HTML listet hidstar auf (dieser Pfad wendet die Bedingung bereits an); ein 200 auf /stargazers mit nur öffentlichen Namen als SUCCESS zu werten; eine Reverse Shell. Theater. Das Leck ist das eingeschränkte Login im JSON.
cd lab
./run.sh
Ziel nur http://127.0.0.1:18133. Compose erlaubt die Sichtbarkeiten public,limited,private und lässt Stars aktiviert.
unauth-user-get status=404
unauth-stargazers status=200 stargazer-names=['hidstar']
unauth-watchers leak=True
unauth-followers-web limited-in-html=False
SUCCESS GITEA-STARGAZERS-HIDDEN
isUserVisibleToViewerCond in GetStargazers / GetRepoWatchers anwenden. Unauth-Stargazers und -Watchers müssen hidstar genauso auslassen, wie es Followers bereits tun.
star.go Router · star.go Modell · subscriber.go · GetInfo · GetUserFollowersGNU Affero GPL v3.0. Siehe LICENSE. Nur Loopback-Lab. Keine Gewährleistung.