abraxas/gitea-stargazers-hiddenPreuve de concept et laboratoire pour une divulgation d'informations non authentifiée dans Gitea : l'API des stargazers et watchers divulgue des noms d'utilisateur que les endpoints de profil masquent.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitea-stargazers-hidden
Write-up : https://abraxaslabs.tech/research/gitea-stargazers-hidden
Gitea 1.27.3 - Gitea
Les utilisateurs limités et privés sont censés disparaître pour les visiteurs anonymes. GetInfo leur renvoie déjà un 404. Les listes d'abonnés appliquent déjà isUserVisibleToViewerCond en SQL. GetStargazers est une jointure sur star sans filtre de visibilité. ListStargazers applique ensuite convert.ToUser à l'ensemble. ListSubscribers présente la même forme pour les watchers.
Sans se connecter, le JSON des stargazers d'un dépôt public nomme des utilisateurs que GET /users/{name} masque.
| ID | pas encore de CVE |
| CWE | CWE-200 |
| CVSS | Moyen : 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
| Produit | Gitea |
| Affecté | jusqu'à v1.27.3 (146cc3e) |
| Auth | non authentifié |
| Licence | GNU Affero GPL v3.0 |
| Lab | 127.0.0.1 uniquement |
Sans se connecter, lire les stargazers et les watchers d'un dépôt public et découvrir des noms d'utilisateur que GET /users/{name} masque. C'est de la reconnaissance sur des comptes limités et privés ayant mis une étoile ou suivi quelque chose de public : des personnes ayant réglé leur visibilité pour ne pas apparaître dans la recherche, puis ayant quand même cliqué sur l'étoile.
C'est un nom d'utilisateur, pas un e-mail, pas une lecture de dépôt privé, pas une RCE. Combiné à l'oracle Follow 204 vs 404, vous pouvez confirmer qu'un identifiant masqué existe même lorsque le profil renvoie 404.
La visibilité était un thème de la vague de GHSA de la 1.27.3. Quand un produit renvoie volontairement un 404 sur un profil, la question suivante est de savoir quels endpoints de liste joignent encore user sans cette condition. Les étoiles et les watchers le font.
J'ai créé hidstar en tant que compte limité, il a mis une étoile et suivi un dépôt public, puis j'ai interrogé l'instance sans jeton. GET /api/v1/users/hidstar non authentifié renvoie 404. Le JSON des stargazers non authentifié inclut hidstar. Les watchers non authentifiés incluent hidstar. Le HTML des abonnés non authentifié ne l'inclut pas. Le profil est discret. La table des étoiles ne l'est pas.
Fausses pistes déjà consignées : GET /users/hidstar non authentifié renvoyant 200 (la visibilité est alors entièrement désactivée - le lab exige un 404) ; le HTML des abonnés listant hidstar (ce chemin applique déjà la condition) ; considérer un 200 sur /stargazers avec uniquement des noms publics comme un SUCCÈS ; un reverse shell. Du théâtre. La fuite, c'est l'identifiant limité dans le JSON.
cd lab
./run.sh
Ciblez uniquement http://127.0.0.1:18133. Compose autorise la visibilité public,limited,private et laisse les stars activées.
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
Appliquer isUserVisibleToViewerCond dans GetStargazers / GetRepoWatchers. Les stargazers et watchers non authentifiés doivent omettre hidstar de la même manière que les followers le font déjà.
star.go · modèle star.go · subscriber.go · GetInfo · GetUserFollowersGNU Affero GPL v3.0. Voir LICENSE. Laboratoire en boucle locale uniquement. Aucune garantie.