Memory corruption a binary exploitation v praxi

Úvod a kontext

Memory corruption se často bere jako disciplína z CTF světa, která v běžném průniku nemá velkou hodnotu. V reálné infrastruktuře ale pořád existuje dost prostředí, kde:

• běží vlastní síťová služba,
• někdo zveřejní její binárku nebo zálohu,
• vstup není dostatečně omezený,
• a první shell vznikne právě přes klasickou binární chybu.

BigHead, Safe a Rope ukazují tři užitečné varianty téhož problému. BigHead stojí na klasickém stack overflow ve vlastní službě, Safe na přetečení echo démonu s ROP řetězcem a Rope naopak připomíná, že ne každá binary exploitation začíná buffer overflow. Stačí i format string, který dovolí přepsat chování programu za běhu.

Tenhle článek není pwn tutoriál krok po kroku. Je o tom, jak podobné situace rozpoznat, jak si správně pojmenovat typ chyby a kdy dává smysl věnovat energii lokální analýze binárky místo dalšího slepého skenování.

O čem tenhle článek je a o čem není

Tenhle text neřeší assembler po instrukcích ani exploit development do posledního gadgetu. Řeší praktický model:

1. kdy má smysl uvažovat o memory corruption,
2. co odlišuje stack overflow, format string a podobné chyby,
3. proč je vlastní binárka nebo její kopie tak cenná,
4. a jak z technického nálezu udělat stabilní foothold.

Jinými slovy: nejde o to naučit čtenáře napsat univerzální exploit. Jde o to naučit ho poznat situaci, kde je binary exploitation nejracionálnější další krok.

Kdy má memory corruption v reálném útoku smysl

Nejsilnější indicie obvykle vypadají takto:

• nestandardní služba na neobvyklém portu,
• vlastní server místo běžného Apache nebo nginxu,
• služba, která přijímá volný vstup a vrací ho zpět,
• veřejně dostupná binárka, záloha nebo klientský archiv,
• nebo velmi staré prostředí bez rozumného hardeningu.

To je důležitý filtr. Binary exploitation nebývá první volba na běžném moderním webu. Dává smysl tam, kde prostředí samo říká, že aplikace je vlastní, slabě chráněná a analyzovatelná offline.

Safe: klasický stack overflow ve vlastní síťové službě

Safe je velmi čistá ukázka klasického přístupu. Veřejný scan odhalil:

• SSH,
• běžný Apache,
• a hlavně vlastní echo službu na 1337.

To je přesně ten typ povrchu, kde web nebývá hlavní cíl. Důležitý je vlastní démon, který:

• přijímá data,
• vrací je klientovi,
• a tím usnadňuje ladění offsetu i ověřování pádu procesu.

Na Safe měla další práce jasnou logiku:

1. určit hranici vstupu,
2. potvrdit přetečení zásobníku,
3. připravit krátký ROP řetězec,
4. a skončit voláním system("/bin/sh").

To je důležitá obranná lekce. Memory corruption v praxi často nevzniká v „velké“ aplikaci, ale v malé pomocné službě, která nikdy neprošla stejným review jako hlavní stack.

BigHead: offline exploit nad binárkou z veřejné zálohy

BigHead ukazuje jiný důležitý vzorec. Útočník nemusel ladit exploit přímo na cílovém hostu. Veřejné archivy BHWS_Backup.zip vydaly binárku BigheadWebSvr 1.0, takže šlo:

• rozebrat implementaci offline,
• najít offset,
• identifikovat vhodný JMP ESP,
• a připravit exploit bez hlučného pokusnictví proti produkční instanci.

To je zásadní rozdíl proti náhodnému fuzzingu na živé službě. Jakmile máš kopii programu, cíl přestává být jedinou laboratoří.

BigHead je proto výukově cenný hlavně v tom, že ukazuje propojení dvou světů:

• špatná správa vývojových artefaktů,
• a následná binary exploitation vlastní služby.

Právě takhle často vypadá reálný chain. Exploit nepadne z čistého nebe. Připraví ho únik binárky, zálohy nebo interního buildu.

Rope: ne každá binary exploitation je buffer overflow

Rope je důležitá korekce proti příliš úzkému pohledu na memory corruption. Ve vlastním HTTP serveru nešlo o klasické přetečení zásobníku, ale o format string:

printf(param_3);

Tím se situace mění zásadně. Útočník nemá jen možnost číst paměť přes formátovací sekvence, ale při správném zacílení i zapisovat přes %n.

Na Rope pak dával smysl jiný model exploitace:

• získat binárku,
• potvrdit, že vstup končí v printf,
• najít vhodnou GOT položku,
• a přepsat budoucí puts() na system().

To je velmi důležitá praktická lekce. Když se řekne binary exploitation, nemá to automaticky znamenat stack overflow, shellcode a ROP. Důležité je nejdřív správně pojmenovat primitivum, které chyba skutečně dává:

• čtení,
• zápis,
• kontrolu nad návratovou adresou,
• nebo přepsání pointeru či GOT.

Co mají BigHead, Safe a Rope společné

Na první pohled jde o různé techniky, ale ve všech třech případech se opakuje stejný rámec:

1. Cíl používá vlastní nebo málo obvyklou službu

To je první varovný signál. Když služba není široce auditovaný mainstream komponent, je výrazně vyšší šance na chyby v práci s pamětí.

2. Existuje cesta k lokální analýze binárky

• veřejná záloha,
• přímé stažení binárky,
• nebo klientský artefakt.

Bez tohoto kroku by byla exploitace pomalejší a méně jistá.

3. Exploit není cíl, ale prostředek k prvnímu shellu

Ve všech těchto případech binary exploitation slouží hlavně k footholdu. Další část útoku pak často stojí na úplně jiných disciplínách:

• credential hygiene,
• lokální artefakty,
• SUID chyba,
• nebo stabilnější SSH kanál.

To je důležité i pro obranu. Jakmile první shell vznikne přes memory corruption, zbytek útoku často už není „pwn“. Je to běžná post-exploitation práce.

Jak podobné situace hodnotit po prvním skenu

Při analýze nestandardní služby dává smysl držet se několika otázek:

Je to vlastní nebo málo známá implementace

simple http server, vlastní echo služba nebo interní webserver jsou silnější kandidáti na binární chyby než standardní dobře známý server.

Dá se získat binárka nebo její starší kopie

To je často rozhodující faktor. Pokud ano, hodnota lokální analýzy rychle roste.

Jaký typ chyby dává chování služby tušit

• echo služba a pád po delším vstupu naznačují overflow,
• vlastní logger nebo formátovaný výstup mohou naznačit format string,
• vlastní parser nebo serializace mohou vést jinam.

Jaká je návratnost proti jiným cestám

Pokud web nic nedává a vlastní služba má zjevně analyzovatelný povrch, je binary exploitation často racionálnější než další webová enumerace.

Kde se obrana nejčastěji plete

„Je to jen malý helper démon“

To bývá právě problém. Malé vlastní utility a pomocné servery často nevypadají důležitě, a proto neprojdou stejným review, fuzzingem ani hardeningem jako hlavní aplikace.

„Binárku nikdo neuvidí“

BigHead i Rope ukazují, jak rychle tenhle předpoklad padá. Stačí veřejná záloha, file read nebo prosté stažení binárky z vlastní služby.

„Po prvním shellu je hotovo“

Ne. Safe i BigHead připomínají, že binary exploitation obvykle uzavírá jen první fázi. Skutečný dopad pak často určují až lokální tajemství, SSH nebo chybně nastavená eskalace.

Obrana a hardening

1. Auditovat vlastní síťové služby stejně přísně jako hlavní aplikace

Custom démon na vedlejším portu není „jen pomocná utilita“. Z pohledu útočníka je to plnohodnotná veřejná attack surface.

2. Omezit únik binárek, záloh a starých buildů

Veřejně dostupný archiv nebo možnost stáhnout si binárku výrazně snižují cenu exploitu. Útočník pak nepotřebuje riskovat ladění přímo na cíli.

3. Používat hardening překladače a runtime ochrany

Canary, PIE, RELRO, ASLR a další ochrany nejsou kosmetika. U vlastních služeb často rozhodují o tom, zda chyba skončí pádem procesu, nebo spustitelným exploitem.

4. Fuzzovat a code-reviewovat vstupní cesty

Zvlášť rizikové jsou:

• vlastní parsery,
• logovací funkce,
• síťové démony,
• a všechny komponenty, které pracují s neomezeným vstupem a běží v C/C++ nebo podobně nízkoúrovňovém kódu.

5. Nezaměňovat „nestandardní“ za „bezpečné“

Vlastní služba s neobvyklým portem není bezpečnější jen proto, že na ni neexistuje hotový veřejný exploit. Často jen čeká na to, až si ji někdo rozebere sám.

Shrnutí klíčových poznatků

• Memory corruption a binary exploitation mají v reálném průniku smysl hlavně tam, kde běží vlastní nebo slabě auditovaná síťová služba.
• Safe ukazuje klasický stack overflow, BigHead hodnotu offline analýzy uniklé binárky a Rope důležitou korekci přes format string a GOT overwrite.
• Nejdůležitější není typ exploitu samotný, ale správné rozpoznání primitiva, které chyba dává: overflow, format string, čtení nebo zápis.
• První shell přes binary exploitation obvykle jen otevírá další fázi útoku; konečný dopad často určují až lokální tajemství a provozní chyby.

Co si odnést do praxe

• Když narazíš na vlastní službu na podivném portu, neptej se jen je na ni CVE. Ptej se i dá se získat binárka a rozebrat offline.
• Ne každá binary exploitation je buffer overflow. Správné pojmenování chyby rozhoduje o celé další strategii.
• Obrana proti memory corruption nezačíná u exploitu. Začíná u toho, jestli vlastní služby vůbec dostávají review, fuzzing a hardening, který by vývojář od hlavní aplikace považoval za samozřejmost.