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
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 sur l'ensemble. ListSubscribers a 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 watchers d'un dépôt public et apprendre des noms d'utilisateur que GET /users/{name} masque. C'est de la reconnaissance sur des comptes limités et privés qui ont mis une étoile ou surveillé quelque chose de public : des personnes ayant réglé leur visibilité pour ne pas apparaître dans la recherche, puis ayant cliqué sur l'étoile malgré tout.
C'est un nom d'utilisateur, pas un email, pas une lecture de dépôt privé, pas de RCE. Combiné à l'oracle Follow 204 vs 404, vous pouvez confirmer qu'un identifiant masqué existe même lorsque le profil renvoie un 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 limité, mis une étoile et surveillé un dépôt public, puis sollicité l'instance sans token. 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 timide. La table des étoiles ne l'est pas.
Fausses pistes déjà consignées : GET /users/hidstar non authentifié renvoyant 200 (alors la visibilité est entièrement désactivée - le lab exige un 404) ; le HTML des abonnés listant hidstar (ce chemin applique déjà la condition) ; traiter un 200 sur /stargazers avec uniquement des noms publics comme un SUCCESS ; un reverse shell. Du théâtre. La fuite, c'est l'identifiant limité dans le JSON.
cd lab
./run.sh
Cible uniquement http://127.0.0.1:18133. Compose autorise les visibilités public,limited,private et laisse les étoiles 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 abonnés le font déjà.
star.go · modèle star.go · subscriber.go · GetInfo · GetUserFollowersGNU Affero GPL v3.0. Voir LICENSE. Lab en loopback uniquement. Aucune garantie.