309 lines
14 KiB
Markdown
309 lines
14 KiB
Markdown
# `wosuid`-laboratoriet — root-RCE **uden** setuid-bit
|
||
|
||
```
|
||
foowosd en bevidst sårbar daemon, der er root, fordi den blev *STARTET* som
|
||
root (port 2344, kun loopback som standard)
|
||
foowosc exploitet: forvandler et stack-overløb til en **root**-shell ved at
|
||
udføre shellcode — de samme 23 bytes, der knækkede user-level-
|
||
`food`-daemonen i det overordnede laboratorium
|
||
```
|
||
|
||
Det er det tredje laboratorium i serien. Samme exploit-værktøjskæde, samme
|
||
stil, én fundamental forskel:
|
||
|
||
| Laboratorium | hvordan target-processen bliver root | `uid=0(root)`-shell? |
|
||
|----------|------------------------------------------------|----------------------|
|
||
| food/fooc| aldrig — det er en almindelig user-daemon | nej |
|
||
| foosd/foosc | SUID-bitten (`chmod u+s`) — euid 0, ruid 1000 | ja (kræver `setreuid` i shellcoden, fordi bash nulstiller euid→ruid) |
|
||
| **foowosd/foowosc** | **ingen — root *starter* daemonen** (sudo / systemd `User=root`) | **ja (almindelig `execve`-shellcode)** |
|
||
|
||
Setuid-bitten er et *transportmiddel* for privilegier — ikke privilegierne
|
||
selv. En daemon startet af root har reelle, effektive og gemte uid alle lig 0.
|
||
For kernen er det root, punktum; den kan og vil ikke vide, om processen kom
|
||
derhen via `+s` på en fil eller via `sudo ./foowosd`. Overløbet i en
|
||
root-started daemon er altså et root-exploit — *"jeg har ingen
|
||
SUID-binærfiler" er ikke det samme som "jeg er ikke udnyttelig".*
|
||
|
||
Det er hele lektionen i dette laboratorium. Alt herunder er maskineriet.
|
||
|
||
---
|
||
|
||
## Hurtig start (hvad brugeren bad om)
|
||
|
||
```
|
||
cd wosuid
|
||
make # bygger daemonen, exploitet og test-harnessen
|
||
```
|
||
|
||
### Det ægte — kør daemonen som **root**
|
||
|
||
```
|
||
sudo make run-root # starter foowosd som uid 0 (proces, ikke filtilstand)
|
||
make test-root # hver teknik skal nu give uid=0(root)
|
||
```
|
||
|
||
### Ikke sudo? Den identiske kernel-sti via en user-namespace
|
||
|
||
```
|
||
make run-root-ns # uid 0 i en user-namespace — ingen adgangskode nødvendig
|
||
make test-root # samme domme; bruges af CI og alle uden sudo
|
||
```
|
||
|
||
### Baseline — daemon som din normale bruger (intet root nogen steder)
|
||
|
||
```
|
||
make run # foowosd kører med dine uider
|
||
make test # exploits lander shells, men `root` forventes MISSING
|
||
```
|
||
|
||
### Oprydningsritual (altid: dette er et root-shell-laboratorium)
|
||
|
||
```
|
||
make stop
|
||
```
|
||
|
||
`foowosd` er *ikke* setuid, og intet i dette bibliotek laver nogensinde
|
||
`chmod +s` — det er pointen. Den farlige tilstand er **processen**, ikke
|
||
filen.
|
||
|
||
---
|
||
|
||
## Når du bliver bedt om at sætte SUID-bitten
|
||
|
||
Det kommer du **ikke** til. Dette laboratorium har bevidst ingen SUID-bit:
|
||
|
||
- `foowosd` bygges, ejes og har almindelige tilstande som ethvert andet program.
|
||
- Det bliver root, som rigtige daemoner gør — ved at blive *startet* af root.
|
||
- `make run-root` bruger `sudo` til præcis det, og `make run-root-ns` får en
|
||
ægte uid-0-proces helt uden noget af det.
|
||
|
||
Suid-bitten tilhører *søster*-laboratoriet (`foosd`). Kontrasten mellem de to
|
||
er pensum:
|
||
|
||
1. SUID-laboratoriet: bitten giver **euid 0, men ruid 1000** →
|
||
`execve("/bin/sh")` nedgraderes af bashs vagt (`euid != ruid` → reset) →
|
||
shellcoden må først kalde `setreuid(0,0)` (32-byte-payload).
|
||
2. Dette laboratorium: root **starter** processen → **ruid == euid == 0** →
|
||
vagten har intet at nulstille → den almindelige 23-byte `execve`-shellcode
|
||
beholder root.
|
||
|
||
Samme overløb. Samme teknik. Forskellig *oprindelse* af privilegier, anderledes
|
||
payload-form. Det er lektionen i miniature.
|
||
|
||
---
|
||
|
||
## Protokollen
|
||
|
||
Uanset hvilken slags klient der forbinder, hilser foowosd på den med:
|
||
|
||
```
|
||
FOOWOSD 1.0 ids=0/0 leak stack=0x7ffd… libc=0x7f… (banneret + leaks)
|
||
BUF=0x7ffd… (bufferadressen)
|
||
```
|
||
|
||
`ids=euid/ruid` er *"er jeg root?"*-sidekanalen. foowosc printer en høj
|
||
advarsel, når euid ikke er 0 (dvs. du startede daemonen som en almindelig
|
||
bruger): payloaden lander stadig, men shellen bliver en bruger-shell, og at
|
||
kalde exploitet "i stykker" ville være forkert — det eskalerer bare ikke.
|
||
|
||
> Staveform-bemærkning: `ids=`, ikke `euid=`/`ruid=`. Test-harnessen beviser et
|
||
> levende `id` ved at matche den bogstavelige form `uid=NNN(`, så banneret må
|
||
> aldrig indeholde en delstreng, der selv opfylder tjekket. (I SUID-laboratoriet
|
||
> producerede præcis den fælde et spektakulært falsk positivt.)
|
||
|
||
---
|
||
|
||
## Exploit-teknikkerne (`foowosc -t …`)
|
||
|
||
Alle fire exploit-stier nedenfor virker mod foowosd. Når daemonen er root,
|
||
giver **alle, der spawner noget, root** — i modsætning til SUID-laboratoriet,
|
||
hvor ret2win/ret2libc stille og roligt blev nedgraderet til uid 1000 af bashs
|
||
vagt. Her er der intet mismatch at vogte mod.
|
||
|
||
| `-t` | hvad der sker | når daemonen er root |
|
||
|---------------|---------------------------------------------------------------------|---------------------|
|
||
| `shellcode` | 23-byte-`execve("/bin/sh", NULL, NULL)` kører på stacken. | **root-shell** (standard) |
|
||
| `ret2win` | hop til `win()` → `execl("/bin/sh")` | **root-shell** |
|
||
| `ret2libc` | ROP: `pop rdi; ret` → `"/bin/sh"` → `system()` | **root-shell** |
|
||
| `demo` | kun junk-overløb — forvent et SIGSEGV i daemon-loggen | nedbrud, efter design |
|
||
| `leak` | printer bare leaks, sender ingen payload | n/a |
|
||
|
||
```
|
||
./foowosc -t shellcode # interaktiv; standard-target 127.0.0.1:2344
|
||
./foowosc -t shellcode -n # send og rapporter, ingen interaktiv session
|
||
```
|
||
|
||
En vellykket interaktiv session videresender din terminal til shellen *på
|
||
offeret* — der er præcis én shell i billedet, og det er `/bin/sh`, der kører
|
||
som root inde i foowosd. Skriv `id` for at se `uid=0(root)`.
|
||
|
||
### Hvorfor der ikke er nogen `ret2win-root`-teknik her
|
||
|
||
foosc havde én — den hoppede til et `win_root()`, der kaldte `setreuid(0,0)`
|
||
før exec, fordi en setuid-proces kørte med en reelle uid, der stadig sagde
|
||
1000. En root-*startet* proces har den reelle uid allerede 0; der er intet at
|
||
rydde, så den ekstra funktion og teknik ville ikke lære noget. Fjernet.
|
||
|
||
---
|
||
|
||
## Hvad foowosc gør, trin for trin
|
||
|
||
1. **Statisk analyse** — `objdump -d` af `./foowosd`. Finder
|
||
`vulnerable_handler`, `win()`, det `lea -0x50(%rbp)`, der adresserer `buf`,
|
||
og det første nøgne `ret`. Ud fra forskydningen beregner det
|
||
`rip_off = 80 + 8 = 88`. Intet er hardkodet; det overlever en genbygning.
|
||
2. **Selv-introspektion** — læser sit eget `/proc/self/maps` og `dlsym()`er
|
||
`system`/`read` for at lære libc-*offsets*. Targetets libc-base er
|
||
`leaked_read − off_read`, derefter `system = base + off_system`, osv. Denne
|
||
delta-aritmetik er grunden til, at exploits overlever libc-versioner.
|
||
3. **Forbind** — læser banneret/leaks (`ids=`, `stack=`, `libc=`, `BUF=`).
|
||
4. **Byg payloaden** — for `shellcode`: 23 bytes maskinkode, padding til
|
||
`rip_off`, derefter den gemte RIP = `buf` (så `ret` hopper ind på koden). For
|
||
`ret2win`/`ret2libc`: adresser beregnet ud fra analysen — ingen udførelse af
|
||
stacken nødvendig.
|
||
5. **Justeringsfixen** — et kapret nøgent `ret` giver callee'en
|
||
`rsp ≡ 8 (mod 16)`, og glibcs SSE2-kode `movaps`-fault'er på en ikke-justeret
|
||
stack (crash-reporteren logger `si_addr=(nil)` — fingerpeget). foowosc
|
||
indsætter ét ekstra `ret`-gadget før det rigtige target og genopretter
|
||
invarianten. Silkehandsketeknik i et shellcode-laboratorium, men det er
|
||
forskellen mellem en payload, der "nogle gange virker", og en, der altid
|
||
virker.
|
||
6. **Send, derefter videresend** — offerprocessen *er* shellen; denne proces
|
||
splisser kun bytes. Ingen lokal shell, ingen anden læser — single-read-
|
||
cursor-fejlen (ét spist byte per chunk) er dokumenteret i `become_shell()`.
|
||
|
||
---
|
||
|
||
## Daemonens bevidste fejl (alle i `foowosd.c`, alle ægte CWE-klasser)
|
||
|
||
| # | fejl | CWE | note |
|
||
|---|-----|-----|------|
|
||
| 1 | `read(fd, buf, 512)` ind i et 64-byte stack-buffer | [CWE-120](https://cwe.mitre.org/data/definitions/120.html) | overløbet: 448 bytes forbi `buf`, gemt RIP ved +88 |
|
||
| 2 | kun `snprintf(line, …, "%.*s", …)`; men angriber-`%` i echo-stien | [CWE-134](https://cwe.mitre.org/data/definitions/134.html) | leaket er her den reelle payload; et `%n` i en *root*-proces ville være write-what-where som root |
|
||
| 3 | børn beholder root, mens de håndterer utroverdige inputs | [CWE-271](https://cwe.mitre.org/data/definitions/271.html) | det korrekte `drop_privs()` (setgroups→setgid→setuid, i den rækkefølge, med verifikation) står i filen, kommenteret, *bevidst aldrig kaldt* |
|
||
| 4 | `ids=`, `stack=`, `libc=`, `BUF=` afsløret til enhver klient | [CWE-200](https://cwe.mitre.org/data/definitions/200.html) | uden disse leaks kunne shellcode- og ret2libc-teknikkerne ikke beregne adresser (ASLR ville besejre dem) |
|
||
|
||
Handleren har præcis samme `buf[64]`/`read(512)`-form som de to andre
|
||
laboratorier, så den fælles objdump-baserede erkendelsespipeline virker
|
||
uændret.
|
||
|
||
---
|
||
|
||
## Sådan inspicerer du daemonen (læringssti)
|
||
|
||
```
|
||
make status # kører den? som hvilken uid? filtilsand vises
|
||
make run-root # eller run / run-root-ns
|
||
./foowosc -t leak # se banneret og leaks, send intet
|
||
./foowosc -t demo # junk-overløb -> SIGSEGV, logget med RIP/rsp
|
||
./foowosc -t shellcode # den interaktive root-shell
|
||
make test-root # fuld matrix, alle teknikker, --must-root
|
||
```
|
||
|
||
Crash-reporter: Ved SIGSEGV logger daemonen fejladressen, RIP og RSP. Et `ret`
|
||
ind i en ikke-kanonisk `0x4141…` fault'er ved `ret`-et selv (RIP som `0x4028xx`,
|
||
`si_addr=(nil)`) — værd at vide, før du fejllæser en loglinje som en
|
||
NULL-dereference.
|
||
|
||
---
|
||
|
||
## Hvorfor shellcoden er 23 bytes, ikke 32
|
||
|
||
```
|
||
31 f6 xor esi, esi ; argv = NULL
|
||
31 d2 xor edx, edx ; envp = NULL
|
||
48 bf 2f62696e2f736800 movabs rdi, "/bin/sh\0"
|
||
57 push rdi
|
||
48 89 e7 mov rdi, rsp
|
||
6a 3b push 0x3b ; 59 = execve
|
||
58 pop rax
|
||
0f 05 syscall
|
||
```
|
||
|
||
SUID-laboratoriet har brug for `setreuid(0,0)` foran dette. Dette
|
||
laboratorium ikke, af den grund der gentages overalt: **ruid er allerede 0**,
|
||
fordi root startede processen. `make verify` beviser, at bytes i `foowosc.c`
|
||
er byte-for-byte det, `shellcode.S` assemblerer til.
|
||
|
||
---
|
||
|
||
## Modforanstaltninger — hvad `make hardened` ændrer
|
||
|
||
Hærdet build (`-fstack-protector-strong -fPIE -pie -z noexecstack`):
|
||
|
||
| teknik | sårbar `foowosd` | hærdet `foowosd_hardened` |
|
||
|-----------|----------------------|------------------------------|
|
||
| `shellcode` | root-shell (eksekverbar stack) | SIGSEGV ved canary-tjekket / NX |
|
||
| `ret2win` / `ret2libc` | root-shell | canary abort'er `ret` — men bemærk: en *PIE*-build gør også disse adresser tilfældige |
|
||
| `demo` | SIGSEGV, logget | SIGSEGV, logget |
|
||
|
||
`make test-hardened` demonstrerer det live. Den vigtige observation er ikke
|
||
bare, at modforanstaltningerne dræbte teknikkerne — det er, at de **ikke**
|
||
gjorde daemonen til "ikke-root". En hærdet build, der stadig *startes* som
|
||
root, er stadig en root-daemon; modforanstaltningen hæver kun barren for
|
||
angriberen. Least privilege (`drop_privs()`) og hukommelsessikkerhed er to
|
||
forskellige fejl, og en daemon, der ikke behøver root, bør ikke have det.
|
||
|
||
---
|
||
|
||
## Sikkerhedsgelændere (samme politik som SUID-laboratoriet)
|
||
|
||
- **Kun loopback.** foowosd nægter at binde andet end `127.0.0.1` /
|
||
`localhost` / `::1`, medmindre du giver `-L`. En root-daemon på en rigtig
|
||
grænseflade er en *fjern* root-tjeneste. `-L` findes kun for at vise vagten;
|
||
brug den ikke på noget, der betyder noget.
|
||
- **Tilstanden logges højt.** Ved start printer den `ruid/euid` og om dette er
|
||
en root-proces, så du altid ved, hvilket exploit-resultat du skal forvente.
|
||
- **Domme kommer fra exit-status** i `make test*` (pty-harnessens
|
||
returkode), aldrig fra at greppe dens stdout — grebbart output lyver.
|
||
- **pty'en skal køre cooked + ECHO off**, ellers ekkoer harnessen sin egen
|
||
kommandolinje og forfalsker markøren. Harnessen slår ECHO fra og beholder
|
||
ECHONL på.
|
||
- **Oprydningsritual:** `make stop` efter hver session. Hvis daemonen er
|
||
root-ejet, siger `stop` dig at køre `sudo pkill -x foowosd`.
|
||
- Kør aldrig dette på en host, du holder af. Det findes for at uddele
|
||
`uid=0`-shells over loopback-grænsefladen.
|
||
|
||
---
|
||
|
||
## Øvelser
|
||
|
||
1. Kør `make run` (user-daemon), derefter `./foowosc -t shellcode`. Hvorfor er
|
||
shellen ikke root? (Tjek `ids=` i banneret — foowosc siger dig det, før du
|
||
overhovedet forbinder.)
|
||
2. `make stop && sudo make run-root && make test-root`. Forklar ud fra
|
||
bannerlinjen, hvorfor alle fire teknikker nu giver `uid=0(root)`.
|
||
3. Find i `foowosd.c` `drop_privs()` og læs, *hvorfor rækkefølgen* af
|
||
`setgroups → setgid → setuid` betyder noget. Beslut, hvor i `main()` den
|
||
ville høre hjemme, og hvad laboratoriets angrebsflade bliver, når den
|
||
faktisk kaldes.
|
||
4. Beregn `rip_off` i hånden ud fra `objdump -d foowosd`: find `buf`s
|
||
`lea -0xNN(%rbp)` inde i `vulnerable_handler`, derefter `NN + 8`. foowosc
|
||
gør præcis det; tjek dens regnestykke mod dit eget.
|
||
5. `make hardened && make test-hardened`. Hvilken teknik falder for canaryen,
|
||
og hvilken for NX? Hvorfor ændrer hærdning ikke, hvad `make status`
|
||
rapporterer om *processen*?
|
||
6. Sammenlign de to laboratoriers shellcodes: 23 bytes her, 32 for foosd. Hvad
|
||
gør de ekstra 9 bytes, og hvorfor behøves de kun i SUID-tilfældet?
|
||
7. Læs `become_shell()`s kommentar om den enkelte læse-cursor. Genskab
|
||
fiaskotilstanden mentalt: to læsere på én socket betyder, at login-shellen
|
||
æder ét byte per chunk — "uid=1000…" ankommer som "id=1000…". Hvorfor kan en
|
||
relay-proces aldrig have denne fejl?
|
||
|
||
---
|
||
|
||
## Filer
|
||
|
||
```
|
||
foowosd.c den sårbare root-daemon (hver linje kommenteret)
|
||
foowosc.c exploitet (hver linje kommenteret)
|
||
shellcode.S reference-assembly for 23-byte-payloaden
|
||
tests/pty_wosuid_test.c pty-harnessen (markør + strenge id-form-tjek)
|
||
Makefile build / run / run-root / run-root-ns / test /
|
||
test-root / verify / hardened / clean …
|
||
```
|
||
|
||
Søster-laboratorier: `../food.c`/`../fooc.c` (user-level-baseline, port 2342)
|
||
og `../suid/` (SUID-root-daemon `foosd`/`foosc`, port 2343). Portene er bevidst
|
||
forskellige — du kan køre alle tre på én gang og krydstjekke deres `ids=`-linjer
|
||
i banneret.
|