Translated ['src/pentesting-ci-cd/gogs-security/README.md'] to pl

src/pentesting-ci-cd/gogs-security/README.md

@@ -0,0 +1,103 @@
+# Gogs Security
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Czym jest Gogs
+
+**Gogs** to **self-hosted lekką usługą Git** napisaną w Go. Z perspektywy atakującego traktuj to jako **multi-tenant platformę hostingu Git**, gdzie użytkownik o niskich uprawnieniach może nadal kontrolować nazwy branchy, pull requesty, webhooks, tokens i ustawienia repozytorium.
+
+## Git option injection przez refs / nazwy branchy
+
+Jeśli aplikacja przekazuje kontrolowaną przez atakującego **nazwę ref** bezpośrednio do polecenia Git **bez `--` lub `--end-of-options`**, branch zaczynający się od `--` może zostać zinterpretowany jako **Git option** zamiast jako dane.
+
+Typowy niebezpieczny wzorzec:
+```bash
+git <subcommand> <user-controlled-ref>
+```
+Bezpieczniejszy wzorzec oczekiwany w defensive code:
+```bash
+git <subcommand> -- <user-controlled-ref>
+# or
+git <subcommand> --end-of-options <user-controlled-ref>
+```
+Częstym błędnym założeniem jest to, że walidacja ref za pomocą `git rev-parse --verify <ref>` wystarcza. To **nie** wystarcza:
+
+- atakujący może najpierw **utworzyć prawdziwą branch**, której nazwa zaczyna się od `--`
+- `rev-parse --verify` sprawdza tylko, czy ref rozwiązuje się do obiektu
+- późniejsze niebezpieczne wywołanie Git może nadal zinterpretować tę samą wartość jako **option**
+
+To zamienia każdą funkcję hostującą Git, która ponownie używa zapisanych nazw branchy, w potencjalny primitive RCE.
+
+## Nadużycie `git rebase --exec` do RCE
+
+`git rebase` obsługuje `--exec=<cmd>`, które uruchamia polecenie przez `sh -c` po odtworzeniu commitów. Dlatego jeśli base branch pull requestu dochodzi do wywołania podobnego do:
+```bash
+git rebase --quiet <baseBranch> <headBranch>
+```
+and `<baseBranch>` jest kontrolowany przez atakującego, branch taki jak:
+```bash
+--exec=touch${IFS}/tmp/rce_proof
+```
+może zostać zinterpretowane jako **Git flag** zamiast nazwy branch.
+
+### Dlaczego `${IFS}` ma znaczenie
+
+Git refs nie mogą zawierać dosłownych spacji, ale shell expansion nadal zachodzi, gdy Git wykonuje `--exec` przez `sh -c`. `${IFS}` rozwija się do whitespace w runtime, umożliwiając payloads takie jak:
+```bash
+--exec=touch${IFS}/tmp/rce_proof
+--exec=id${IFS}>/tmp/out
+```
+Dla payloads wymagających znaków zabronionych przez Git (`:`, `~`, `^`, `?`, `*`, `[`, `\\`, `//`), zakoduj rzeczywiste polecenie i zdekoduj je w czasie wykonania:
+```bash
+--exec=echo${IFS}<base64_payload>|base64${IFS}-d|sh
+```
+## Windows-specific payload delivery
+
+Na Windows inline payloads są bardziej ograniczone, ponieważ Git przechowuje branch refs jako pliki, a NTFS zabrania znaków takich jak `|` w nazwach plików. Praktyczną alternatywą jest:
+
+1. Zacommituj payload script do repository (na przykład `.abcdef`)
+2. Utwórz branch taki jak:
+```bash
+--exec=sh${IFS}.abcdef
+```
+Jeśli Git for Windows uruchamia payload przez **MSYS2 `sh`**, metacharacters PowerShell mogą zostać zniekształcone. Praktycznym obejściem jest pozwolić, aby zatwierdzony script wywołał:
+```bash
+cmd.exe //c .abcdef.bat
+```
+gdzie `//c` jest bezpieczną dla MSYS2 formą Windows `/c`.
+
+## Nadużycie stanu maszyny merge / PR
+
+Podczas testowania platform hostujących Git, nie sprawdzaj tylko końcowego niebezpiecznego polecenia. Sprawdź też **wcześniejsze ścieżki walidacji** oraz **ponowne sprawdzenia w tle**.
+
+Przydatny wzorzec exploitacji to:
+
+1. Początkowa ścieżka walidacji używa **bezpiecznego** flow clone/fetch z `--end-of-options`, więc złośliwa gałąź jest akceptowana jako dane
+2. Pull request staje się **mergeable**
+3. Późniejsza ścieżka merge lub checkout ponownie używa zapamiętanej nazwy gałęzi w **niebezpiecznym** wywołaniu Git
+4. Code execution następuje nawet jeśli późniejszy krok się nie powiedzie, a UI zwróci **HTTP 500**
+
+Oznacza to, że funkcja może być exploitable nawet wtedy, gdy końcowy merge kończy się błędem, a repozytorium docelowe może zostać pozostawione w **uszkodzonym częściowym stanie rebase** po tym, jak payload już się wykonał.
+
+## Praktyczne pomysły na hunting
+
+Podczas przeglądania instancji Gogs lub podobnej usługi Git, sprawdź:
+
+- Nazwy branchy zaczynające się od `--`
+- Błędy merge związane z `git checkout '--exec=...'`
+- Pull requesty zablokowane jako mergeable, mimo że późniejsza walidacja branchy się nie powodzi
+- Repozytoria pozostawione w częściowym stanie rebase / uszkodzonym stanie Git po nieudanych merge
+- Nieoczekiwane commity plików pomocniczych na Windows payload paths (na przykład dotfiles plus launchery `.bat`)
+- Podejrzane API tokens utworzone krótko przed nieudanymi merge PR
+
+Przykładowy artefakt logu:
+```text
+merge: git checkout '--exec=<...>': exit status 128 - error: unknown option `exec=<...>'
+```
+## References
+
+- [Rapid7 - Authenticated RCE via Argument Injection in Gogs (NOT FIXED)](https://www.rapid7.com/blog/post/ve-authenticated-rce-via-argument-injection-gogs-unfixed)
+- [Metasploit module PR for Gogs rebase argument injection](https://github.com/rapid7/metasploit-framework/pull/21515)
+- [Git rebase documentation (`--exec`)](https://git-scm.com/docs/git-rebase)
+
+{{#include ../../banners/hacktricks-training.md}}