
Démontre un oracle d'énumération de comptes Gitea : la requête authentifiée PUT /api/v1/user/following/{username} renvoie 204 pour les comptes masqués et 404 pour les noms inconnus, avec un lab en boucle locale.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitea-follow-existence
Gitea 1.27.3 - Gitea
GetInfo renvoie déjà un 404 pour les utilisateurs masqués et ment sur la raison : fake ErrUserNotExist error message to not leak information about existence. PUT /user/following/{username} charge la cible avec UserAssignmentAPI() et appelle Follow. Pas de IsUserVisibleToViewer. Nom inexistant : 404 user redirect does not exist. Nom masqué qui existe : 204.
204 signifie que le compte existe. 404 signifie que vous avez deviné un nom qui n'est pas là. Le JSON du profil reste fermé.
| ID | pas encore de CVE |
| CWE | CWE-203 |
| CVSS | Moyen : 4.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N |
| Produit | Gitea |
| Affecté | jusqu'à v1.27.3 (146cc3e) |
| Auth | compte connecté |
| Licence | GNU Affero GPL v3.0 |
| Lab | 127.0.0.1 uniquement |
Se connecter (l'inscription ouverte par défaut est peu coûteuse). Prouver qu'un compte masqué ou limité existe même lorsque l'API de profil renvoie un 404. Pas de dump de profil. Pas de git privé. Combiné avec unauth stargazers, vous pouvez trouver un identifiant masqué sur un dépôt public puis confirmer qu'il existe toujours après que le profil a été masqué.
Check et Unfollow se trouvent sur le même groupe. Même vérification manquante.
Même passe de visibilité que stargazers. Quand un handler se donne autant de mal pour mentir, on regarde toutes les autres routes qui prennent {username}. Follow ne le fait pas.
J'ai enregistré un attaquant restreint, suivi le nom masqué, suivi un nom qui n'existe pas, et comparé les codes de statut. Les utilisateurs publics sont censés renvoyer 204. Ce n'est pas SUCCESS. Masqué 204 vs inconnu 404 alors que GET est 404, c'est SUCCESS.
Fausses pistes déjà consignées : Follow masqué renvoyant 404 (alors la visibilité est sur cette route) ; le JSON du profil pour l'utilisateur masqué (GetInfo renvoie déjà 404 - ce bug est une classe de statut, pas un dump) ; traiter Follow 204 sur un utilisateur public comme SUCCESS ; un reverse shell. Du théâtre.
cd lab
./run.sh
Cible uniquement http://127.0.0.1:18134. Compose autorise la visibilité public,limited,private.
get-hidden status=404
follow-hidden status=204
follow-unknown status=404 user redirect does not exist
oracle hidden=204 unknown=404
SUCCESS GITEA-FOLLOW-ORACLE
Appeler IsUserVisibleToViewer dans Follow (et Check/Unfollow) avant FollowUser. Les noms masqués doivent renvoyer 404 de la même manière que GetInfo le fait déjà.
follower.go · api.go following group · GetInfoGNU Affero GPL v3.0. Voir LICENSE. Lab en loopback uniquement. Aucune garantie.