Proof-of-concept lab per un bypass di autorizzazione in Gitea in cui un PAT pubblico con write:organization crea un'organizzazione privata tramite POST /api/v1/orgs.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitea-public-only-pat-org
Gitea 1.27.3 - Gitea
public-only su un PAT dovrebbe essere la promessa che il token non può toccare risorse private. POST /user/repos ha rejectPublicOnly. POST /orgs ha tokenRequiresScopes e reqToken. Non ha rejectPublicOnly. DEFAULT_ALLOW_CREATE_ORGANIZATION è true per impostazione predefinita.
Un PAT public-only con write:organization crea un'organizzazione privata. Lo stesso token non può creare un repository utente privato.
| ID | nessuna CVE al momento |
| CWE | CWE-863 |
| CVSS | Medium: 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N |
| Prodotto | Gitea |
| Affetto | fino alla v1.27.3 (146cc3e) |
| Auth | PAT public-only con org write |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
Usare un PAT public-only rubato o emesso in eccesso che abbia anche write:organization. Creare un'organizzazione privata. Quell'org è un nascondiglio che il token non avrebbe dovuto poter creare. Lo stesso token continua a non poter creare un repository utente privato, e questo bug non apre il git privato esistente di qualcun altro.
Integrità, non un dump di git privato. Utile quando la vittima ha emesso "public-only" di proposito: CI, un bot, un token per un contractor che pensava non potesse far crescere un'org privata.
La creazione di org-repo controlla solo la visibilità dell'org. Il deprecato POST /org/{org}/repos salta del tutto il public-only. Ho testato in lab la creazione di org. È sufficiente.
Stesso passaggio di residui del lab hostmatcher 0.0.0.0/8: v1.27.3 dopo l'ondata di GHSA, poi gli handler che ancora saltano un gate che un sibling ha già. Bug di visibilità e di scope dei token erano un tema di quell'ondata. Ho fatto grep di rejectPublicOnly in api.go. La creazione di user-repo lo ha. La creazione di org no.
Ho generato un PAT con scope public-only,write:organization,write:repository,write:user. La creazione di org privata ha restituito 201. Stesso token, creazione di user-repo privato, 403 this endpoint is not available for public-only tokens. Quel 403 è il controllo. Se entrambi avessero dato 201, il middleware sarebbe del tutto assente. Se entrambi avessero dato 403, non ci sarebbe nulla da segnalare.
Vicoli ciechi già registrati: considerare sufficiente l'HTTP 201 dell'org (confermare visibility=private su GET); la creazione di user-repo privato che riesce (allora rejectPublicOnly è assente - il lab richiede 403); leggere il contenuto di git privato esistente; una reverse shell. Teatro.
cd lab
./run.sh
Target solo http://127.0.0.1:18132. Compose imposta DEFAULT_ALLOW_CREATE_ORGANIZATION=true.
token-scopes=public-only,write:organization,write:repository,write:user
org-create status=201
org-visibility='private'
user-repo-create status=403 this endpoint is not available for public-only tokens
SUCCESS GITEA-PUBLIC-ONLY-PAT
Mettere rejectPublicOnly() su POST /orgs, e trattare anche la creazione di org-repo come sensibile al public-only. La creazione di org public-only deve restituire 403 allo stesso modo in cui la creazione di user-repo privato già lo fa.
api.go (rejectPublicOnly, POST /orgs, POST /user/repos)GNU Affero GPL v3.0. Vedi LICENSE. Solo lab su loopback. Nessuna garanzia.