abraxas/gitea-public-only-pat-orgЛаборатория proof-of-concept для обхода авторизации в Gitea, где PAT с доступом только к публичным ресурсам и правом write:organization создаёт приватную организацию через 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 на PAT должен быть гарантией того, что токен не может касаться приватных ресурсов. В POST /user/repos есть rejectPublicOnly. В POST /orgs есть tokenRequiresScopes и reqToken. Но нет rejectPublicOnly. DEFAULT_ALLOW_CREATE_ORGANIZATION по умолчанию true.
PAT с public-only и write:organization создаёт приватную организацию. Тот же токен не может создать приватный пользовательский репозиторий.
| ID | пока нет CVE |
| CWE | CWE-863 |
| CVSS | Средний: 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N |
| Продукт | Gitea |
| Затронуто | по v1.27.3 (146cc3e) |
| Аутентификация | PAT с public-only и правом записи в организацию |
| Лицензия | GNU Affero GPL v3.0 |
| Лаборатория | только 127.0.0.1 |
Использовать украденный или выданный с избыточными правами PAT с public-only, у которого также есть write:organization. Создать приватную организацию. Эта организация — тайник, который токен не должен был иметь возможности создать. Тот же токен по-прежнему не может создать приватный пользовательский репозиторий, и эта уязвимость не открывает чужой существующий приватный git.
Это нарушение целостности, а не выгрузка приватного git. Полезно, когда жертва выдала «public-only» намеренно: CI, бот, токен подрядчика, который, как она думала, не может вырастить приватную организацию.
Создание репозитория в организации проверяет только видимость организации. Устаревший POST /org/{org}/repos полностью пропускает public-only. Я воспроизвёл в лаборатории создание организации. Этого достаточно.
Тот же проход по остаткам, что и в лаборатории hostmatcher 0.0.0.0/8: v1.27.3 после волны GHSA, затем обработчики, которые всё ещё пропускают проверку, уже присутствующую у соседнего обработчика. Баги видимости и области действия токена были темой той волны. Я выполнил grep по rejectPublicOnly в api.go. У создания пользовательского репозитория она есть. У создания организации — нет.
Я выпустил PAT со скоупами public-only,write:organization,write:repository,write:user. Создание приватной организации вернуло 201. Тот же токен, создание приватного пользовательского репозитория — 403 this endpoint is not available for public-only tokens. Этот 403 — контроль. Если бы оба вернули 201, промежуточное ПО исчезло бы полностью. Если бы оба вернули 403, нечего было бы оформлять.
Ошибочные пути уже зафиксированы: считать HTTP 201 при создании организации достаточным (подтвердите visibility=private через GET); успешное создание приватного пользовательского репозитория (тогда rejectPublicOnly исчезла — лаборатория требует 403); чтение содержимого существующего приватного git; обратная оболочка. Театр.
cd lab
./run.sh
Цель только http://127.0.0.1:18132. Compose устанавливает 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
Добавить rejectPublicOnly() в POST /orgs и также считать создание репозитория в организации чувствительным к public-only. Создание организации с public-only должно возвращать 403 так же, как уже делает создание приватного пользовательского репозитория.
api.go (rejectPublicOnly, POST /orgs, POST /user/repos)GNU Affero GPL v3.0. См. LICENSE. Только лаборатория на loopback. Без гарантий.