Před nedávnem proběhla na undergroundu soutěž týkající se díry v PHP. Všichni jsme si užili s touto soutěží kopu srandy, o čemž svědčí i některé obzvláště vydařené screenshoty.
Ale jaké informace se vlastně daji dírou v php ze serveru ziskat? Co všechno vlastně touto dírou můžeme na serveru přečíst? Poměrně dost. Systém práv na un*xech je naprosto jasný. Máme tři druhy práv u každého souboru. Vlastník, skupina a ostatní. Asi nejobvyklejší práva na souborech v systému jsou -rw-r--r--, tj. vlastník pochopitelně smí všechno, ostatní, co jsou s ním ve skupině smí číst a zbytek světa smí také číst. Takže pohoda (pro útočníky), i když je admin natolik opatrný, že spouští apache jako jiného uživatele, nežli root, což dělá v současnosti asi každý, s vyjímkou tří specifických skupin administrátorů:
1) Typ blbec- Je mu to jedno... dyk to vrčí, takže vocogo..
2) Typ agent- Tajný agent firmy Malý&Měkký snažící se diskreditovat konkurenční software
3) Typ worm- Nemá rád šéfa, šéf nemá rád jeho. Shodou okolností se mu doma v crontabu válí link na skript destroy_my_server_field s datem nastaveným shodou okolností o tři dny vyšším od vypršení jeho neprodloužené pracovní smlouvy.

I přesto, že administrátorů tajných agentů je málo, nechávají nám poměrně široké pole působnosti, takže se můžem o dané pixle dost dozvědět. Takovouto procházku po serveru si můžeme udělat cvičně v klídku na konzoli našeho počítače coby běžný uživatel, s nohama na stole a cigárem, protože je podstatně pohodlnější popojíždět v MC kurzorovými klávesami, nežli pracně datlit url, na to budeme mít dost času potom, co si ujasníme, co všechno teoreticky můžeme ze serveru získat.
Nuže... nejsme hacker, my jsme hodní kluci, ale kdybychom byli hacker, co by nás na systému asi tak zajímalo?
1) S jakou pixlou vlastně máme čest? Je to šikovný louskáček na hesla, nebo jen velmi nešikovný louskáček na ořechy?
2) Jaký systém tam vlastně běhá? (V souvislosti s php pravděpodobně un*x, ale to je stále poměrně široká odpověď)
3) Podařilo by se nějakými triky přečíst /etc/shadow?
4) Konektí se ta mašina někam? V tom případě by se možná daly najít nějaké loginy jako plain text.
5) Jaké verze programů tam vlastně běží, abychom je mohli potenciálně exploitovat?

Tak... a dost řečí, víme co chceme, takže nohy na stůl, zapálit cigáro (protože kouřením člověk přispívá velkou měrou do státní pokladny, což se vládě pochopitelně nemůže líbit a proto se snaží kuřákům pokud možno co nejvíc znepříjemnit život), login: polacek (tedy běžný uživatel... to je ten uživatel bez nálepky, co pere o polovinu hůř, nežli root, který navíc pere o polovinu levněji), mc+enter a jedem... Já teď zrovna sedím u Red Hata, jestli máte nějaký jiný systém, možná budete občas muset trošku zaimprovizovat podle místních zvyklostí.

1) Kterak hardware oscanovati:
Máme dokonce na výběr z více možností, poměrně přehledné info získáme ve /var/log/dmesg. Takže teď už víme, jaký kernel bootuje, kolik má mašinka paměti, jaký druh procesoru má a jak rychlý, jaká je tam síťovka, jaké disky.
To je docela úspěch na první pokus, ne? :-)
Ale buďme perfekcionisté, ještě stále se můžeme o počítači dozvědět víc, třebas taková myš...
cat /etc/sysconfig/mouse|grep F
Další hardwarové okénko máme v /etc/sysconfig/hwconf, tady se dokonce dozvíme jakou má mašinka grafiku a jaké chipsety na boardu. Prostě tohle je ten nejkompletnější seznam, který můžeme chtít. Ale možností je samozřejmě víc. Vzhledem k tomu, že můžeme celkem bez zásadních restrikcí procházet /proc, můžeme nahlédnout do dalších souborů, které nám potvrdí to, co jsme právě zjistili (např. /proc/cpuinfo).

2) Tučňák v červeném tvrďáku, nebo chameleon?
Když budeme mít kliku, tak by nám mohl stačit výpis z /etc/issue, nebo issue.net, ale příliš bych na to nespoléhal. Issue je notoricky profláknutý soubor a každý admin si tam může napsat co chce, chtělo by to tedy nějaký spolehlivější zdroj informací. Můžeme nahlédnout do /etc/rc.d/rc.local, jestli administrátor nedal natvrdo psaní nějakého lživého blábolu do issue, nebo přepisování issue zrušil a do issue napsal nějaký duchaplný reklamní slogan na widle, v takovém případě je tu možnost, že (konkrétně tedy u RH) v /etc/redhat-release najdeme originální text.
Dobrým vodítkem může být také původní jádro. Záznam o něm můžeme najít v /etc/lilo.conf, pokud je záznam smazán, můžeme ještě zkusit najít jádro v /boot, nebo hledat zdrojové kódy starého jádra. Určitě, kdyby si dal člověk tu práci, by se nechaly také najít nějaké relace mezi distribucí a softwarem, který je v ní použit. Myslím, že například anacrontab v RH5.2 nebyl, ale (6.1 jsem v životě neviděl) v RH6.2 je. Nějak podobně je to možná s kerberosem, takže přítomnost souborů /etc/anacrontab a /etc/krb5.conf mohou být určitým vodítkem.
Můžeme se také pokoušet hledat soubory s dokumentací. Pokud nejsou smazané (jako to mám já, takže se o tom moc nerozepíšu), je v dokumentaci určitě někde zmínka, ke které verzi programu je psaná. Kdybychom byli hackeři, zajímala by nás určitě verze bindu... a to nejen kvůli zjištění systému.
Můžeme se také zkusit podívat do /etc/rc.d/sysinit, tady bývá nějaký uvítací blábol, který vítá uživatele, aby si naivně mysleli, že je má počítač rád. Nic lepšího mě momentálně nenapadá, možná některý ze čtenářů bude mít nějaký nápad, v komentářích je na ně místa dost.

3) Shadow..
Bohužel, v tomto směru zůstávám skeptický. Vzhledem k tomu, že shadow je soubor, který smí číst pouze root, nám se ho přecíst asi nepodaří. V případě, že by daemon neběžel jako root, ale byl s ním ve skupině, nabízela by se cesta přes čtení disku skrz /dev/hda1 (nebo prostě disk s tou částí adresářové struktury, ve které je etc), kde rootova skupina má právo čtení. Disk na serveru by si asi sice trochu zachroupal, ale grepováním jmen uživatelů by zahashované heslo určitě vypadlo. Ale tohle také patří spíš do oblasti sci-fi.

4) Plaintextové loginy
I v tomto případě bych raději zůstal zdrženlivý. Pokud je server zároveň firewallem, administrátor bude v tomto případě asi poměrně paranoický a pokud například přesouvá komprimované logy (nebo prostě cokoliv jiného) na jinou mašinku, bude to spíš vypadat tak, že nějaký skript spouštěný z crontabu zapakuje logy a nakopíruje do nějakého adresáře, odkud si ho jiný počítač vyzvedne přes ftp, sambu, nebo nějakou jinou důmyslnou službu.
Nicméně pokud by to někomu stálo za tu práci, může si napsat skript, který bude procházet adresáře v /proc a číst soubor cmdline. Na mém počítači by tímto způsobem jedno heslo získal. Připojuji si sambou jeden disk na jiném serveru v síti a protože jsem tvor líný, napsal jsem si skriptík, který disk připojuje a mám na něj linky normálně z rc.dx. Tohle je ale strašná zvrhlost, kterou si mohu dovolit jedině proto, že tento systém používám sám. Mohl bych zabránit čtení skriptu nastavením paranoidních práv, ale nemohl bych zabránit ostatním uživatelům, aby si přečetli příkaz v /proc/xxx/cmdline.
Možná vám připadá poněkud krkolomné prolézat adresáře jednotlivých procesů místo hledání skriptu, ale je potřeba si uvědomit, že do url musíme zadávat jen dotaz na soubor o jehož existenci dopředu víme a také, že práva souboru admin určitě nezapomene upravit. Naproti tomu skript, který zkouší vcházet do adresářů, jejichž název je prosté číslo a který v každém adresáři hledá to samé není tak obtížné vytvořit.

5) Verze běžících daemonů
Jednu možnost jsem již popsal... soubory s dokumentací. Nicméně tyto soubory nemusí být aktuální, nemusí existovat, nemusí být na standardním místě, nic spolehlivého. Jak tedy na to? Jednou možností jsou logy daemonů, pokud do nich daemon vypisuje svůj název a verzi. Pokud se nám podaří přečíst inicializační skripty daemonů, víme, kde jsou konfigurační soubory a z nich lze vyčíst, kde jsou logy a jak se jmenují (v případě, že nejsou na standardním místě).
Další možností je nechat si vypsat obsah binárky daného daemona. Snad každý program zná parametr -v, nebo --version, takže je velmi pravděpodobné, že v kódu se nechá číslo verze najít. Pokud bychom nenašli cestu k binárce ve spouštěcím skriptu, můžeme si ji najít v /proc/xxx/maps. Tady bude záležet i na tom, jestli v binárce nejsou nějaké speciální znaky, které by byly pro skript php nestravitelné, ale za zkoušku to určitě stojí.

Tak... tolik tedy teorie, nakolik se bude praxe od teorie odlišovat?
Vyzkoušejme to. Budem potřebovat přístup k inetu, browser (celkem libovolný lynxem počínaje, exploderem konče), nějaký ten děravý server, želatinové medvídky a kávu.
Vzhledem k tomu, že pomalu měsíc po ukončení soutěže na undergroundu je ještě hromada serverů neošetřených, vybral jsem náhodně nějaké tři odkazy, které ještě fungují:
http://www.sunny-martin.sk
http://www.semet.cz
http://www.trinecko.cz

Napřed procházka hardwarovou zahrádkou:

semet.cz
Síťovka: 3Com Corporation|3c905B 100BaseTX [Cyclone]
Grafika: Cirrus Logic GD543x
CDROM: LTN403
SCSI: Wdigtl WD91 ULTRA2
Procesor: Pentium II (Deschutes) MHz : 400.917 cache size : 512 KB
Paměť: 128 MB
A jen tak z recese myš: sériová, dvoutlačítková na ttyS0

suny-martin.sk
Síťovka: 3Com Corporation|3c905B 100BaseTX [Cyclone]
Grafika: Silicon Integrated Systems [SiS]|86C326
CDROM: CD-524E
IDE: WDC AC24300L
Procesor: Celeron (Mendocino) MHz : 300.681329 cache size : 128 KB
Paměť: 64MB
Bez myši... admin je asi skalní unixák

trinecko.cz
Síťovka: tr0: Hardware address : 00:20:AF:0E:9F:11 tr0: Maximum MTU 16Mbps: 4056, 4Mbps: 4568
Grafika: Mach64 desc: "ATI|Rage 128 VR AGP 1x/2x"
Disky: 2xWDC WD84AA
Procesor: Celeron (Mendocino) MHz : 467.734441 cache size : 128 KB
Paměť: 64 MB
Myš: dvoutlačítková PS/2

Pěkné, že? :-)

A nyní se porozhlédnem po systému:
semet.cz: Red Hat Linux release 6.2 (Zoot) kernel-2.2.16 ,jádro z instalace a ještě jedno starší jádro...
sunny-martin.sk: Red Hat Linux release 6.2 (Zoot) kernel-2.2.14-5.0 standardní jádro distribuce...
trinecko.cz: Red Hat Linux release 6.1 (Cartman) kernel-2.2.14 tohle je asi taky standardní jádro distribuce..

Místo pátrání po heslech se radši budem chvilku déle zabývat zkoumáním verzí běžícího software, nejsme přece hackeři, my jen zjišťujeme, co všechno se mohou hackeři touto cestou dozvědět. ;-)

Tak například jsme zvědaví na poštu webmastera...
Init skript "httpd" se v systému jaxi nenalézá, zkusíme hledat "apache", přijde mi to nejlogičtější název..
http://www.sunny-martin.sk/streetball/sablona.php3?url=/etc/rc.d/init.d/apache
vytáhnem si cestu ke konfiguračnímu souboru a hledáme usera, pod kterým daemon běží...
http://www.sunny-martin.sk/streetball/sablona.php3?url=/etc/apache/httpd.conf
paráda, teď už víme, že běží jako user www, tudíž už nám nic nebrání si přečíst "naší" poštu...
http://www.sunny-martin.sk/streetball/sablona.php3?url=/var/spool/mail/www
No vida... a vypadla na nás 23 letá roštěnka i s adresou a telefoníma číslama, která se chce učit anglicky. :-)
Škoda, že je ze slovenska a že nepřidala i fotku...

Napadá mne nyní jedna kacířská otázka... co by se stalo, kdybychom na tuto mailovou adresu zaslali náš php skript? Skript by pravděpodobně neproběhl kvůli hlavičce mejlu, ale situace by mohla být jiná, kdybychom poslali html formulář, který by nám umožnil zasílat skripty na server. Prohlížeče jsou obvykle koncipované alespoň trochu blbuvzdorně, takže by s největší pravděpodobností hlavičku mailu ignorovaly, nebo na začátku vypsali pár blábolů, které bychom hrdě ignorovali a formulář by možná normálně fungoval. Co si o tom myslíte vy? Netestoval jsem to...

Nebo jiný příklad. Řekněme, že nás zajímá verze bindu na semet.cz.
Opět si ho najdem podle spouštěcího skriptu.
http://www.semet.cz/inter.php?cat=../../../../../../../../../../../etc/rc.d/init.d/named
Nyní již víme, že se nachází v /usr/sbin/named, zkusme ho nechat vypsat, budeme-li mít štěstí, zjistíme jeho verzi z kódu.
http://www.semet.cz/inter.php?cat=../../../../../../../../../../../usr/sbin/named
V kódu můžeme najít tento text: (Berkeley) 7/1/91 $Id: ns_main.c,v 8.142 2001/01/15 20:06:25


Možností je určitě podstatně víc, nejsem hacker a nemám nejmenší představu, co všechno by ho mohlo zajímat, ale myslím, že je zřejmé, že by tato díra mohla částečně nahrazovat portscan. Myslím také, že logy http daemona nejsou administrátory nijak pečlivě sledované. A pokud ano, tak není pravděpodobné, že z nich grepují slova jako /proc, /etc/passwd, takže pravděpodobnost, že by si toho admin všiml je poměrně minimální. I kdyby se útočníkovi nepodařilo nakonec na server proniknout a nemohl logy vyčistit, je dost pravděpodobné, že admin by si nikdy nevšiml jeho činnosti. Přesvědčili jsme se, že dírou v php lze získat i tak lechtivá data, jako je mail, je vic, než zjevné, že touto cestou si lze o serveru udělat slušnou představu. Možná by nám tato díra umožnila i uploadovat vlastní skripty. Přesto je tato chyba velmi často administrátory a autory aplikací podceňována ( v současné době se už nedá mluvit o neinformovanosti). Dokladem toho jsou i url, které jsem zde uváděl a které (i přes to, že admini byli po ukončení soutěže upozorněni) jsou stále funkční. Pokud jste administrátor provozující webserver s php a momentalně sebou znepokojeně vrtíte na židli s neodkladnou touhou jít se přesvědčit, že váš server je vpořádku, pak se mi nejspíš podařilo to, co jsem tímto článkem zamýšlel. Pokud ne, možná se najde nějaký binárnější sxizofrenik, který napíše volné pokračování o tom, jak s takto získanými daty naložit.

Od 26.3.2001 začne vycházet nový český ezin Sova v síti, určený především začínajícím a méně zkušeným webmasterům. Své čtenáře si však jistě najde i mezi zkušenějšími autory a správci firemních, školních, profesních, zájmových i osobních webových stránek.

Cílem ezinu je poskytovat svým čtenářům praktické návody, rady a tipy z oblasti tvorby a provozování webových stránek. Obsah bude rovnoměrně rozdělen mezi tři hlavní tematické okruhy, které by měl ovládat každý správný webmaster:

• Technické základy tvorby webových stránek, tj. HTML, CSS, JavaScript, zpracování grafiky, atd.
• Problematika designu, navigace, použitelnosti a obsahu webových prezentací.
• Internetová strategie, propagace a marketing.

Veškeré informace budou podávány formou krátkých, stručných a zcela prakticky zaměřených návodů, rad a tipů. Součástí každého čísla budou i odkazy na další související zdroje (literaturu, obsáhlejší návody na internetu, aktuální články na českých webzinech, atd.) Úroveň odbornosti je zvolena tak, aby byl obsah plně srozumitelný zejména těm čtenářům, pro které není tvorba a správa WWW stránek hlavní profesí.

Sova v síti je klasickým ezinem a bude ted