Přejít k navigační liště

Zdroják » Různé » Jdu hacknout váš server… díl 3

Jdu hacknout váš server… díl 3

Články Různé

Naposledy jsem na cílovém serveru získal omezený přístup přes PHP shell. Pro připomenutí – jedná se o krátký skript, který přes exec/passthru pouští příkazy, které mu zadáme pomocí GET nebo POST požadavku. Na server jsem ho v tomto příkladu dostal přes SQL injection, další možností mohlo být třeba nesprávně ošetřené nahrávání souborů.

Nálepky:

Postup

PHP shell je sice hezká věc, ale má své úskalí: neumožňuje interaktivní vstup jako využívá např. nano (editování souborů) a vypisuje pouze běžný výstup stdout. Oboje se dá většinou řešit, v prvním případě například stačí celý stáhnout a nahrát upravený, v druhém můžeme chybový výstup přesměrovat pomocí >&1. Nicméně hlavní zádrhel je omezené oprávnění.

Mám před sebou dva poslední kroky, přes které získám ssh přístup s root oprávněním. Exploit typu privilege escalation/local root využije chyby v nějaké konkrétní aplikaci na to, aby pod vyšším oprávněním spustil shell (bash). A tím narážíme na omezení PHP shellu: jakmile se mi podaří spustit tento exploit, otevře se prakticky další interaktivní vstup, do kterého už přes passthru z PHP nic zapsat nejde.

Teoreticky by stačilo exploit upravit tak, aby nepouštěl shell, ale například náš skript. Jako rychlejší se mi osvědčilo využít jiného typu expoitu: bindshell/bac­kdoor. Ten poslouchá na libovolném portu a dá se na něj přes telnet připojit. Příkazy spouští podle oprávnění, pod kterým byl spuštěn. Stále sice nezvládá interaktivní vstup, nicméně se nezavře po každém požadavku jako PHP shell. To znamená, že musím připravit local root exploit tak, aby spustil bindshell, připojím se přes telnet, upravím nastavení ssh a vložím do authorized_keys vlastní id_rsa  klíč.

Používáme exploit

Než se pustíme do zdlouhavého vymýšlení vlastního exploitu, je dobré prohledat místa internetu, na která mnozí shlížejí s despektem. Mám na mysli databáze různých bezpečnostních děr. Dalo by se říct, že to jsou takové bug reporty s přiloženým testem, který vždy projde. Nebo neprojde, záleží na úhlu pohledu. Označení skript-kiddie není na místě, nemá smysl objevovat znovu chyby, které už někdo jiný zpracoval. Kromě toho jsou nalezené skripty spíš takový sandbox a vyžadují ještě nějaké to upravování, obzvlášť když pracujeme s odlišnou verzí OS / cílové knihovny a podobně.

Asi nejobsáhlejší databáze je dnes exploit-db.com. Naprostá většina je psaná v C/ C++, minimum využívá jiné jazyky. Můj nejoblíbenější příklad je tento PHP skript, který na portu 4444 otevře backdoor: exploit-db.com/exploit­s/3525/. Využívá špatné správy paměti PHP knihovnou GD.

Řekněme, že chceme použít nějaký exploit napsaný v C. První postup je nahrát zdrojový kód na server (ideálně do /tmp) a zkompilovat ho úplně přes úplně základní gcc -o /tmp/code /tmp/code.c. Stane-li se, že uživatel, pod kterým běží PHP shell, nemá oprávnění gcc spouštět, je nutné zkompilovat si exploit jinde. Není problém stáhnout i hodně staré verze různých systémů a virtualizovat je u sebe. Složitějším se může zdát nahrání binárního souboru na cílový server; pochopitelně to nepůjde z prohlížeče přes GET, ale jde využít curl, případně je možností napsat si na to nějakou utilitu/skriptík.

Zkompilovaný backdoor spustíme z PHP shellu jako jakoukoli jinou aplikaci. Je prozíravé si do exploitu přidat nějaký výstup typu „všechno běží“, ať hned víme, jak si stojíme. Pokud se všechno tváří funkčně, můžeme se zkusit připojit: telnet 173.194.70.138 4444, samozřejmě na pravou IP a port, který jsme si napsali v exploitu. Často se stane, že vstup posílaný na server je o několik bajtů posunutý a tedy oříznutý. Určitě můžeme celý exploit opravit a překompilovat, někdy stačí doplňovat bílé znaky na konec každého příkazu. Vždy záleží na konkrétní situaci.

Stane-li se, že žádný použitelný exploit nenajdete, čeká vás dlouhá cesta. Nutný předpoklad je kniha Hacking — Umění exploitace (Jon Erickson, Zoner Press 2009), kde se autor dostává k teorii i k pokročilým metodikám. Mimo jiné vás naučí assembler, který je pro toto nízkoúrovňové programování nezbytností.

Local root

Oprostil jsem se od omezeného PHP shellu a pracuji se serverem přes telnet. Anabázi z posledního kroku si zopakuji ještě jednou, tentokrát s local root exploitem, nicméně všechno by mělo jít mnohem rychleji, protože vím, kde kompilovat, a mám připravené prostředí a skripty. Když máme oba dva exploity funkční, musíme pustit nejprve local root a z něj backdoor. Obráceně to nejde kvůli podstatě otevíraného připojení (pro připomenutí: nezvládá interaktivní vstup, což bash rozhodně je). Máme dvě možnosti: vytvořit skript, který příkaz na spuštění backdooru předá přes trio spawn/expect/send, nebo upravíme local root exploit tak, aby nespouštěl bash, ale rovnou otevíral port.

Přístup na ssh

Nyní mám neomezené (=root) možnosti a můžu se serverem dělat, co si zamanu. Bylo by milé se zbavit závislosti na otevřeném portu, který je pro administrátora jeden velký červený vykřičník. Najdu nastavení ssh (zpravidla /etc/ssh/sshd_config a ujistím se, že PermitRootLogin je nastavené na yes, případně změním. Ještě musím vědět, kde hledá soubor authorized_keys, což je uvedeno pod AuthorizedKeysFile. Většinou je v adresáři .ssh pod domovským adresářem uživatele. Na konec tohoto souboru vložím svůj vlastní veřejný klíč: echo "klíč==" >> /root/.ssh/authorized_keys a restartuji ssh daemona  /etc/init.d/ssh restart.

Závěr

Ještě než propadnu euforii a začnu si se serverem hrát, měl bych po sobě uklidit. Rozhodně nesmím zlikvidovat všechny logy, to dá rozum, ideální je promazat jenom záznamy o mně. Týká se to logů samotného webového serveru (apache, nginx nebo na čemkoliv jiném server běží), ale i PHP a nyní i ssh. Dále je dobré po sobě pročistit  .bash_history.

Mám přístup na ssh jako root. Můžu číst celou databázi a všechny procházející maily, upravovat libovolné soubory. A to celé jenom kvůli jednomu neošetřenému vstupu…

Komentáře

Subscribe
Upozornit na
guest
25 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jenda

id_rsa.pub, ehm ;)

Sten

A přesměrování stderr je „2>&1“

Jenda

Jo a po přidání klíče jsem nikdy sshd nerestartoval.

Rejpal

Já po editaci sshd configu ano.

Sim

Ahoj,

bylo by milé kdyby jsi své články obohati a nějaké nápady jak zamezit/zmírnit/de­tekovat/automa­ticky odstřihnout/… případné útočníky. Různé programy, vhodné konfigurace a praktiky,…

RPajik

Dobry zacatek je v php zakazat vsechy fce, ktere zde hacker zminuje – tedy exec, system apod – na netu najdete jiste spolehlivy seznam ( klicove slovo je disable_functions )

Pak je treba klienta uzavrit do jeho adresare pres open_basedir.

No a na zaver pridejte parametr noexec pro oddil daty co se zobrazuji na webu.

Striktnim firewallem utocnikovi take zivot minimalne hodne zneprijemnite.

NN

suhosin: suhosin.execu­tor.eval.blac­klist system,shell_e­xec,popen,proc_o­pen,exec,passthru

RPajik

a escapeshellcmd ne ? :-)

N

A k čomu? Tá funkcia vráti escapovaný string a nič nevykoná.

maleprase

spoustu veci resi selinux – nepovoli httpd_t otevrit port 4444, nepovoli rootovi ale zase s httpd_t upravovat ssh_home_t soubory (~/.ssh/…), …

martin-ux

na zaciatok urcite davat weby do jailu (fbsd), pripadne zon (*solaris) alebo domU (xen/linux). ak nieco rootne, tak stale len sandbox.

michal_sjx

300 webu a kazdy do vlastniho jailu? Nebo jeden jail a do nej 300 webu? A nebo kombinaci?
Tak jednak na tu „virtualizaci“ spotrebujes dost systemovych prostredku a druhak je jedno jestli ma roota v jailu nebo v hostujicim systemu. Stejne muze editovat weby, vidi hesla k DB a muze rozesilat spam.
Podle me je potreba zabezpecit oboje ;). Jedina pridana hodnota jailu v tomto pripade je, ze nemusis kvuli preinstalaci ownuteho systemu startovat auto.

martin-ux

no tvrdit, ze to bude stacit by bola velka hlupost :) .. preto som napisal, ze ‚na zaciatok‘.

najviac co moze jail brat je miesto na disku. ale vsak si spravis flavor jailu pre web (apache/php/per­l,etc.), ten pouzijes potom na kazdom webe. ostatne resources su – diplomaticky povedane – take iste, ako keby bezal ten process v nejail systeme.

to ze to nezaisti posielanie spamu a dostane sa k DB – to je uz druha vec. to je uz problem aplikacny, nie OS. k zabezpeceniu appl sa vyjadrit neviem.

ono toto je na diskusiu na dlsie. pri fbsd+zfs mi nerobi problem (== sa da krasne vyuzit zfs) tie weby sekat do jailov, kazdy na vlastny dataset.

michal_sjx

Toho „na zacatek“ jsem si asi nevsiml.
Z hlediska zabezpeceni proti neopranenemu pristupu se musi provest stejna opatreni na virtualnim i na fyzickem serveru. To jsem tim chtel rict :). No a taky ze je to kanon na komara.

Aby mne hacker z 3. dilu nenapadl, tak staci mit DB na jinem stroji/jaiu, nemit dostupne vyvojove nastroje, fierewall vse zakazano a jen poskytovane sluzby povoleno, kazdy vhost aby mel vlastni uid.

Aha

Prvnimu a druhemu dilu sem jeste docela rozumel. Tmudle uz skoro vubec :-). Pekne napsane. GJ.

flv

Tak on si to nejlepsi autor nechal pro sebe, viz. „Stane-li se, že žádný použitelný exploit nenajdete, čeká vás dlouhá cesta“. Slovo „nejlepsi“ mozna patri do uvozovek, osobne jestli si mam vybrat mezi tim studovat nizkourovnovy programovani za ucelem tvorby exploitu a klasickym OOP pro tvorbu neceho uzitecnyho tak je pro me jasnym kanidadatem druhe uvedene. Uznavam ze prvni ma v sobe kouzlo studia „systemu“, nicmene odrazuje me ucel, druhe mi proste prijde vic potrebne.

Samot10

pokial chces tvorit EFEKTIVNE aplikacie, tak je imo assembler dost dolezity

František Kučera

I kdybys tu efektivitu* měřil čistě jen výpočetním výkonem, tak je to sporné – v mnoha případech bude stroják/asembler vyrobený kompilátorem efektivnější než asembler naspaný ručně člověkem.

*) kromě toho efektivita je taky to, za kolik člověkodnů dokážeš vyvinout software podle zadání

wr

Tak nějak mi příjde, že moc nepobírám o čem, že tenhle díl vlastně je?
O bezpečnosti?
Težko.
O hackování?
Ani omylem.
Systém konfigurovaný způsobem jaký popisuje autor článku bych asi standardně objevil u někoho, kdo si předevčírem nahodil nějakou hodně špatnou LAMP instalaci a snaží se na ní rozběhat turoriálové přiklady php.
Vzhledem k tomu, že článek budou předpokládám hlavně číst lidi z oboru, očekával bych uvedení nějaké reálné konfigurace systému, popisy průniků a aktuálních hrozeb spojených s danou technologií a né obecné nic neříkajicí tlachy o exploitech. Když už si autor hraje na hackera, měl by alespoň zmínit jak si zaručí, že nebude při útocích odhalen a vystopován a jak takový typický postup vypadá, co s tím může dělat admin serveru aby takové pokusy identifikoval apod.
Hlášky typu: „Složitějším se může zdát nahrání binárního souboru na cílový server; pochopitelně to nepůjde z prohlížeče přes GET, ale jde využít curl, případně je možností napsat si na to nějakou utilitu/skriptík.“
nebo „Nyní mám neomezené (=root) možnosti a můžu se serverem dělat, co si zamanu“
Ve mě vyvolávají pocit, že autor by měl psát raději o něčem jiném.
Navíc na laika to celé může klidně působit, že apache s php jsou technologie děravé jak cedník, což samozřejmě jsou, ale lze je poměrně jednoduše a dobře zabezpečit, případně izolovat tak, aby v případě průniku nedošlo k žádným zásadním škodám jak už bylo zmíněno v jiných příspěvcích.

Jenda

„Systém konfigurovaný způsobem jaký popisuje autor článku bych asi standardně objevil u někoho, kdo si předevčírem nahodil nějakou hodně špatnou LAMP instalaci a snaží se na ní rozběhat turoriálové přiklady php.“

Nebyl podobným způsobem vyownován NBÚ SR a různé podobné instituce?

wr

Když si někto nezamyká auto, případně nechává ztažené okýnko a ještě lépe klíček v zapalování, je velmi pravděpodobné, že mu tam někdo vleze a něco mu ukradne.
Je to v celku logické a samozřejmě stává se to i dnes :)
Myslíte si, že článek s titulkem „Jdu vykrást vaše auto“ popisující průnik do tímhle způsobem zabezpečeného vozu je na místě?
Poenta byla trochu jiná, to co autor popsal není pro většinu zkušenějších adminů reálná hrozba. Málo kdo (výjma snad statních institucí) vystavuje do internetu tímto způsobem zabezpečené důležité služby, bez monitoringu, bez zónování kde ideálně všechno běží na jednom systému pod rootem se všemi otevřenými porty :)
Pokud by název článku byl „Jak jsem před devíti rokama hacknul server KSČM“ pak bych asi nic nenamítal, ale ambiciózní název článku „Jdu hacknout váš server“
ve mě evokuje otázku, čí vlastně je to server? :)

flv

Nepamatuju si ze bych na rootu cetl podobny clanek (pokud tu neco podbneho bylo je k dispozici odkaz?), takze bych nebyl tak striktni, budme radi za to co autor napsal. Je pravda ze tech podminek ktere autor uvedl co by nutne pro uspesny prulom je pomerne dost, na druhou stranu vas optimismus ohledne bezpecnosti vetsiny serveru bych chtel sdilet :).

Mozna bysme autora „prekecali“ aby napsal neco o technikach, nastrojich uzivanych pro hledani novych exploitu, to mi prijde zajimave.

Jirka V.

Když seš tak dobrej, napiš něco lepšího. Zase tak slabý ten článek není, a možnosti SQL injection naznačuje pěkně. A zbastlených aplikací, které vstupy vůbec neřeší, je bohužel pořád dost – protože stále přicházejí nějací začátečníci. A právě třeba pro ně, je tohle dobrý začátek na co si dát pozor.

wr

Asi jste nepochopil, co jsem se snažil svých komentářem sdělit, rozhodně to nebylo o zpochybnění technik, které byly v článku prezentovány nebo toho, že neexistují děravé aplikace, či nezabezpečené systémy.
Poukazoval jsem pouze na reálnost té popsané situace.
A právě naopak začátečníka to bude mást v tom smyslu, že si bude myslet, že to tak prostě jednoduše funguje. Pokud v článku není zmíněna ochrana, případně nějaké best practices ohledně ošetřování vstupů aplikací, způsob spouštění a zabezpečení aplikací a služeb, tak si z toho žádný začátečník stejně nic moc neodnese.

Místo vlastního článku
bych spíše doporučil old school zdroj http://web.archive.org/web/19981206154944/http://hysteria.sk/ kde je k tématu spousta velmi poučného a reálně použitelné čtiva, které je sice 14 let staré, ale stále up2date.

P.S. Ještě, že se nám ten internet archivuje :)

passpartout

Treti dil se mi libil, protoze ukazuje, jak lze postupne skladat utok.

Mozna ze nektere (mezi)kroky nejsou jsou zrychlenne, ale autor je muze rozebrat v dalsich clancich.

Vas’y !

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.