Safe
Úvod a kontext
Safe kombinuje dvě odlišné disciplíny. User část je klasická binární exploitace nad vlastní síťovou službou na portu 1337, zatímco root část stojí na chybné správě tajemství po získání lokálního shellu. První polovinu řetězce rozebírám obecněji v článku Memory corruption a binary exploitation v praxi.
Na tomhle stroji je důležité nemíchat dohromady vstupní vektor a následnou stabilizaci přístupu. Shell nevzniká přes SSH, ale přetečením vlastní echo služby; SSH se hodí až později jako pohodlnější kanál po získání důvěryhodných údajů.
Počáteční průzkum
Vyhledání otevřených portů
Už první scan ukázal, že veřejný web na portu 80 není hlavní cíl. Zajímavější byla vlastní služba na 1337, která vracela dodaný vstup zpět klientovi.
nmap -p 1-65535 -T4 -A -sC -v $IP
22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u6
80/tcp open http Apache httpd 2.4.25 ((Debian))
1337/tcp open waste?
| fingerprint-strings:
| GenericLines:
| What do you want me to echo back?
| GetRequest:
| What do you want me to echo back? GET / HTTP/1.0
To je silná indicie k reverzní analýze binárky a ke kontrole hranic vstupu. Služba nejen přijímá vlastní data, ale přímo je vrací zpět, což u podobných úloh často usnadňuje ladění offsetu i ověření pádu procesu.
Analýza zjištění
Buffer overflow v echo službě
Další krok proto vedl přes klasickou binární analýzu: určit délku přetečení, najít vhodné gadgety a připravit krátký ROP řetězec, který skončí voláním system("/bin/sh"). Důležité je, že tady nešlo o odhad nebo „zkusím random exploit“, ale o standardní postup pro ověření přetečení zásobníku ve vlastní službě.
Praktický výsledek byl shell v běžném uživatelském kontextu. Tím šlo potvrdit user.txt a přejít z čisté exploitace do lokální enumerace hostu.
Získání přístupu
Shell z vlastní služby
U podobných binárních úloh má smysl považovat user část za uzavřenou ve chvíli, kdy exploit vrátí reprodukovatelný shell a je možné s ním pracovat bez dalších ručních zásahů. Přesně to se zde povedlo: echo služba na 1337 poskytla první lokální přístup a SSH v této fázi sloužilo už jen jako následný komfortnější kanál, pokud se podaří získat další přihlašovací údaje.
Eskalace oprávnění
KeePass databáze na stejném hostu
Po footholdu se ukázalo, že v uživatelském kontextu leží databáze KeePass (.kdbx) spolu s doprovodným materiálem potřebným k jejímu otevření. Z hlediska obrany je to zásadní chyba: trezor sice existuje, ale jeho ochranný faktor je uložený na stejném kompromitovaném stroji. Přesně tento typ lokálních tajemství rozebírám i v článku Klientské, desktopové a ne-textové artefakty po footholdu.
Jakmile šla databáze otevřít, vedla přímo k root tajemství. Root část zde tedy není o kernelu, sudo ani SUID, ale o tom, že citlivý secret byl po prvním shellu prakticky připravený k použití.
Shrnutí klíčových poznatků
- Veřejný Apache zde nebyl podstatný; rozhodující plocha útoku byla vlastní echo služba na portu
1337. - User přístup vznikl exploitací buffer overflow a krátkým ROP řetězcem, nikoli zneužitím SSH nebo webu.
- Root fázi rozhodla špatná správa tajemství: KeePass databáze a materiál potřebný k jejímu otevření byly dostupné ve stejném kompromitovaném kontextu.
Co si odnést do praxe
- Vlastní síťové utility a pomocné démony jsou plnohodnotná útočná plocha. Pokud přijímají neomezený vstup a běží mimo běžný aplikační review, velmi snadno z nich vznikne binární exploitace.
- Stabilní shell po exploitu je jen první polovina práce. Skutečný dopad často určí až to, co je po footholdu lokálně uložené: klíče, trezory hesel, zálohy nebo pomocné poznámky.
- Password manager nebo šifrovaný trezor chrání jen tehdy, když je oddělený od ostatních faktorů. Pokud databáze i keyfile nebo odpovídající hint leží na stejném hostu, po kompromitaci účtu z nich bývá už jen odložený root.