1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Využití exploitů pro penetrační testování BAKALÁŘSKÁ PRÁCE Lukáš Lazar Brno, podzim 20052 Prohlášení Prohl...
Využití exploitů pro penetrační testování BAKALÁŘSKÁ PRÁCE Lukáš Lazar
Brno, podzim 2005
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Poděkování Tímto bych chtěl poděkovat panu Ing. Mgr. Zdeněkovi Říhovi, Ph.D. za odborné vedení bakalářské práce a poskytnutí cenných rad a připomínek, které jsem využil při její tvorbě.
2
Shrnutí Cílem této práce je uvést čtenáře do světa bezpečnostních chyb a exploitů a popsat jejich využití pro penetrační testování. Dále popsat a srovnat nástroje v penetračním testování používané. Praktická část popisuje a obhajuje zvolený způsob kategorizace exploitů do vytvořené databáze.
3
Klíčová slova bezpečnostní chyba, CVE, exploit, penetrační testování, bezpečnostní skener
4
Obsah 1. ÚVOD ...............................................................................................................................6
2.1 RŮZNÁ DĚLENÍ EXPLOITŮ ...............................................................................................8 2.2 BEZPEČNOSTNÍ CHYBY ...................................................................................................8 2.2.1 Přetečení bufferu (buffer overflow, BO) .................................................................8 2.2.2 Útok na formátovací řetězec.................................................................................11 2.2.4 Cross-site scripting (XSS) ....................................................................................13
3. EXPLOITY A BEZPEČNOSTNÍ CHYBY V ŠIRŠÍCH SOUVISLOSTECH.............14 3.1 OTÁZKA ZVEŘEJNĚNÍ ...................................................................................................14 3.2 ŽIVOTNÍ CYKLUS BEZPEČNOSTNÍ CHYBY .......................................................................15 3.3 SNAHA O STANDARDIZACI ............................................................................................16
4.1 PRINCIP .......................................................................................................................18 4.2 STANDARDNÍ METODOLOGIE ........................................................................................18 4.3 NÁSTROJE ...................................................................................................................18 4.3.1 Bezpečnostní skenery ...........................................................................................18 4.3.2 Srovnání ..............................................................................................................19 4.3.3 Nessus..................................................................................................................21 4.3.4 Vlastní zkušenosti s testováním.............................................................................21
5. VLASTNÍ IMPLEMENTACE ......................................................................................22
5.1 DATOVÝ MODEL .........................................................................................................22 5.2 APLIKACE ..................................................................................................................23
LITERATURA ...................................................................................................................27
5
Kapitola 1
1. Úvod Tato práce se týká bezpečnosti IT, tedy oblasti, jejíž závažnost dlouho a vytrvale roste. První motor zájmu o tuto oblast přišel s rozvojem Internetu. Ten otevíral případným útočníkům naprosto nové možnosti páchaní škod. Oproti starému způsobu šíření virů „pučením“ (pučíš si disketu a máš ho), nabízel mnohem rychlejší e-mail, FTP, RPC a další služby. Jako první tento nový způsob ukázal tzv. Morrisův červ v roce 1988. Nejde však jen o viry a červy, vůbec samotný princip vzdáleného ovládnutí stroje, tedy alfa a omega hackingu, přešel do obecného povědomí až s rozšířením Internetu. Druhý hlavní poháněč zájmu o bezpečnost IT, který je v podstatě náplní této práce, je důsledkem prvního, tedy rozvoje Internetu. S ním totiž přišla obrovská spousta různého softwaru ke stažení, často zdarma nebo zdarma alespoň na prozkoušení. Nikdy v historii IT nebylo tak jednoduché získat ten program, který potřebujete. To s sebou ovšem nese značné riziko, protože můžete jen hádat, jak moc si dali autoři práce s otestováním z hlediska bezpečnosti. V podstatě platí jednoduchá úměra, že čím víc máte nainstalovaného softwaru, tím většímu bezpečnostnímu riziku se vystavujete. Než přikročím k hlavní části práce, krátce vyložím základní pojmy, které budu používat: útočník – Kdokoli, kdo svou činností ohrožuje jednu ze tří základních složek bezpečnosti tj. důvěrnost, integritu nebo dostupnost. Útočníci se v terminologii dále dělí podle úrovně znalostí, viz. níže. důvěrnost (confidentality) – Znamená, že přístup k aktivům organizace (datům, hardwaru atd.) má pouze autorizovaný subjekt. Jde o přístup pouze ve smyslu prohlížení nikoli modifikace, tedy kdo co může vidět. integrita (integrity) – Modifikace aktiv je umožněna pouze autorizované straně. dostupnost (availability) – Autorizovaný subjekt musí mít k aktivům přístup, nemůže být odmítnut. hacker – Význam tohoto pojmu se s časem mění, konstantou však zůstává, že je to člověk s vysokou technickou odborností. V minulosti se tak označovali právě lidé s velkou erudicí v IT, dnes se k tomu navíc přidává i to, že těchto svých znalostí využívají k často ilegální činnosti např. pronikání do cizích systémů a kradení dat. script kiddie – Jak už název napovídá, je to útočník s malou nebo žádnou úrovní znalostí, často teenager. Využívají programy, které napsali a zveřejnili zkušenější a jednoduše testují stovky či tisíce počítačů v síti, zda nejsou takovým programem napadnutelné. hacking – Náplň činnosti hackera. Z velké části je to nepříliš „romantické“ sbírání informací. Samotný průnik do systému se pak často děje na základě v různé míře kreativního využití známé nebo hackerem objevené bezpečnostní chyby.
6
etický hacking (ethical hacking) – Tento pojem vešel ve známost s tzv. penetračním testováním. Technologický postup je stejný s postupem hackera, rozdíl je v tom, že nalezené bezpečnostní chyby nejsou využity k čemukoli nekalému, jsou pouze oznámeny. bezpečnostní chyba (security vulnerability) – Je to chyba v návrhu, implementaci či konfiguraci softwaru, kterou je možné využít k útoku. exploit – Softwarový kód, který využívá bezpečnostní chyby. penetrační testování (penetration testing) – Je způsob testování bezpečnosti vnitřní sítě organizace, při kterém testeři postupují podobně jako skuteční hackeři, toužící tuto síť napadnout – náplní jejich činnosti je tzv. etický hacking viz. výše.
7
Kapitola 2
2. Exploity 2.1 Různá dělení exploitů Jak už jsme si řekli v úvodu, exploitem, nazýváme kus kódu, který využívá bezpečnostních chyb v softwaru k páchání činnosti, kterou by si autor nepřál. Někdy tak bývá označována sama bezpečnostní díra. Můžeme je třídit podle několika charakteristik, mezi něž patří zejména [1]: • •
•
Typ bezpečnostní chyby, kterou využívá; např. přetečení bufferu, útok na formátovací řetězec, SQL injection atd. Fakt zda jde o exploit vzdálený, tj. použitelný na síti bez vlastnictví jakýchkoli uživatelských účtů, nebo lokální, tj. využívající chyby v lokálním systému například k eskalaci privilegií (využití chyby v aplikaci běžící s vyšším oprávněním než mám jako přihlášený uživatel k provedení příkazů v jejím kontextu). Akce, kterou využitím bezpečnostní chyby provádí; např. provedení kódu, DoS, přístup k datům.
2.2 Bezpečnostní chyby Následuje podrobnější výčet nejdůležitějších typů bezpečnostních chyb spolu se známými exploity minulosti spadajících do dané kategorie:
2.2.1 Přetečení bufferu (buffer overflow, BO) Do této kategorie patří možná nejvíc a nejnebezpečnějších exploitů. Princip spočívá v naplnění bufferu (dočasné paměťové úložiště) větším množstvím dat, než pro které byl vytvořen. V programovacích jazycích, které nehlídají integritu paměti jako je C a C++, to vede k přepsání kusu paměti, který vám nepatří, vašimi daty. Tato data mohou být např. proveditelným kódem, který bude v nějakém okamžiku volán [2]. Nejlépe se BO využívá, pokud je buffer lokální v nějaké funkci. Pak se totiž jako každá lokální proměnná nachází na zásobníku a jeho přetečením můžeme přímo ovládat běh daného programu. Tento speciální případ BO nazýváme přetečení zásobníku (stack overflow, SO) a ilustrujeme si ho na příkladu: int main () { int buffer[10]; int i; for (i=0; i<=29; i++) { buffer[i] = 'X'; }
8
} Toto je syntakticky správný kus kódu, který bez problémů přeloží každý překladač jazyka C. K přetečení dojde, když je lokální pole „buffer“, pro které je alokována paměť na deset prvků typu int, naplněno prvky dvaceti. V tomto případě to může vést k nepředvídatelnému chování, pravděpodobně ukončení programu z důvodu porušení segmentace. Aby jsme pochopili proč a jak toho využít sofistikovaněji, podíváme se na další kus kódu a zároveň strukturu zásobníku: void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; } void main() { function(1,2,3); } bottom of memory <------
buffer2 [
top of stack
top of memory buffer1 sfp ret a ][ ][ ][ ][
b ][
c ][
]
bottom of stack
Ze schématu je patrné pořadí, v jakém se na zásobník ukládají data v případě volání funkce „function()“ v main(). Nejdříve se na zásobník uloží argumenty funkce čili hodnoty 1, 2 a 3 a poté se zavolá funkce: pushl $3 pushl $2 pushl $1 call function Instrukce call, která realizuje volání funkce na úrovni procesoru, pak obstará několik dalších činností. Především uloží na zásobník tzv. návratovou adresu, což je obsah registru IP neboli Instruction Pointeru (na různých architekturách se může jmenovat jinak, např. u PowerPC je to PC alias Program Counter), aby věděl, kde má pokračovat v provádění programu po návratu z funkce a registru SFP neboli Stack Frame Pointeru, což je adresa začátku aktuálního rámu – části zásobníku příslušející jednomu volání jedné funkce (opět závislé na platformě, např. PowerPC Frame Pointer nepoužívá vůbec, má jen Stack Pointer a rámy mají fixní délku; kruhová architektura procesoru SPARC zase způsobuje, že hodnota SFP je vždy starou hodnotou SP). Nakonec se na zásobník ukládají lokální proměnné.
9
Dostáváme se k základnímu principu stack overflow – tím je přepsání návratové adresy tak, aby po opuštění funkce začal program vykonávat naše instrukce. V našem prvním příkladě jsme návratovou adresu přepsali binární hodnotou znaku 'X' a ta pak pravděpodobně ukazovala mimo adresní prostor programu, což vedlo k zmíněné chybě segmentace a jeho ukončení. Teď zkusíme něco chytřejšího: void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; int *ret;
}
ret = buffer1 + 12; (*ret) += 8;
void main() { int x;
}
x = 0; function(1,2,3); x = 1; printf("%d\n",x);
V tomto příkladě už měníme cíleně pouze návratovou adresu. Víme, že těsně před polem buffer1 je registr SFP a hned za ním návratová adresa. Registr SFP má 4 byty a pole buffer1 ve skutečnosti 8 (násobky 4 bytů), čili návratová adresa je přesně 12 bytů od začátku pole buffer1. K návratové adrese přičteme 8, to je délka instrukce MOV, která vznikne přeložením přiřazovacího příkazu x = 1. Ten tak přeskočíme a program nám jako hodnotu x vypíše nulu. Lépe je to vidět na výpisu z ladícího programu GDB: $ gdb example3 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc... (no debugging symbols found)... (gdb) disassemble main Dump of assembler code for function main: 0x8000490 <main>: pushl %ebp 0x8000491 <main+1>: movl %esp,%ebp 0x8000493 <main+3>: subl $0x4,%esp 0x8000496 <main+6>: movl $0x0,0xfffffffc(%ebp) 0x800049d <main+13>: pushl $0x3 0x800049f <main+15>: pushl $0x2
Mezi nejznámější exploity této kategorie patří internetový červ Code Red z roku 2001, který napadal systémy Windows NT a 2000 s IIS 4.0 nebo 5.0 a nainstalovaným Index Server 2.0. Postihoval též některé směrovače. Oproti svým předchůdcům jako byl Love Letter nepotřeboval k šíření žádnou interakci s uživatelem, jako otevírání emailové přílohy. Připojoval se k náhodně vybraným strojům na TCP portu 80, očekávajíc webový server. Při úspěšném navázání spojení poslal na vzdálený stroj speciálně vyrobený paket a pokusil se tak využít buffer overflow chyby ve zmíněné indexovací službě. Pokud byl úspěšný, začal na kompromitovaném stroji operovat, což se projevovalo především charakteristickou odpovědí „HELLO! Welcome to http://www.worm.com! Hacked By Chinese!“ na všechny příchozí HTTP požadavky. Další aktivita záležela na datu systémových hodin následovně: • den 1 - 19: Červ se snaží výše popsaným postupem dále šířit. • den 20 - 27: Denial of Service útok zaplavením pakety na některé fixní IP adresy mj. adresu Bílého domu. Několikero dalších zlopověstných červů také využívalo tohoto typu chyby, za všechny jmenujme alespoň vůbec prvního internetového červa Morrise, dále SQLslammera a Blastera.
2.2.2 Útok na formátovací řetězec Jako ohrožení využívající nový druh bezpečnostní chyby byl tento způsob útoku objeven v roce 2000. Využívá množinu formátovacích funkcí standartní knihovny jazyka C - fprintf(), printf(), sprintf(), snprintf(), vprintf(), vsprintf(), vsnprintf() atd. Mají společné to, že berou jako první argument tzv. formátovací řetězec, který určuje jednak to jak se budou další argumenty vypisovat (formát, odtud formátovací) a jednak jejich počet. Bezpečností díra nastává, když má uživatel možnost ovlivnit formátovací řetězec [3]. K nejznámějším exploitům této skupiny patří exploit na wu-ftpd, který byl první vlaštovkou tohoto nového typu útoků. Chybu ve wu-ftpd také využíval linuxový červ Ramen. Mezi dalšími můžeme jmenovat exploity proti BSD-ftpd, proftpd, rpc.statd a také přímo proti PHP 3 a PHP 4.
11
2.2.3 SQL injection Útok tohoto typu nastává, pokud je neoprávněný uživatel schopen zasahovat do řetězce obsahujícího SQL dotaz. Jednoduchým příkladem, může být třeba tato situace: aplikace si od uživatele vyžádá jméno a příjmení spisovatele a tyto údaje bez kontroly předá do SQL dotazu, který má vyhledávat díla daného autora [4]: select book_name from books author_surname = 'smith'
where
author_forename
=
'john'
and
pokud útočník disponuje snadno zjistitelnou informací, že řetězce jsou u tohoto DB serveru uvozovány apostrofy, může jako jméno autora zadat třeba toto: jo'; drop table books-a vymazat tak tabulku knih. Aplikací sestrojený dotaz do DB totiž vypadá takto: select book_name from books where author_forename = 'jo'; drop table books--' and author_surname = 'smith' přičemž znak ';' ukončuje jeden příkaz a začíná druhý a znaky '--' znamenají jednořádkový komentář, který zařizuje, že tento dotaz neskončí parsovací chybou. Abychom se dostali k zajímavějším datovým manipulacím, potřebujeme co nejlépe znát strukturu dané databáze a jejích tabulek. Tu můžeme dobře prozkoumat, pokud máme přístup k chybovým hláškám, které databáze vyhazuje. Mějme např. tabulku vytvořenou SQL dotazem create table users(id varchar(255), privs int)
int,
username
varchar(255),
password
a naplněnou těmito daty: insert insert insert insert
Jestliže chce útočník přidat svůj účet, nemůže být úspěšný pokud neví o této tabulce, nezná její strukturu a význam jednotlivých polí. Nejdříve se tudíž pídí po tabulkách, na kterých dotaz operuje a jejich sloupcích. Zde pomůže klauzule HAVING příkazu SELECT: Username: ' having 1=1--
12
vyprodukuje tuto chybovou hlášku: [Microsoft][ODBC SQL Server Driver][SQL Server] Column 'users.id' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause. Útočník nyní zná jméno prvního sloupce, přičemž stejným způsobem může zjistit všechna další. Chyby tohoto druhu jsou velice časté např. v CMS (content management system) napsaných v PHP, jako je PHP Fusion a PHP Nuke nebo jiných webových aplikacích, jako jsou různé nástěnky (PhpBB), návštěvní knihy atp.
2.2.4 Cross-site scripting (XSS) Tento způsob exploitování je považován za méně nebezpečný než ostatní, protože je většinou (ale ne vždy) k úspěchu potřeba i jistá dávka sociálního inženýrství. Klasická bezpečnostní díra typu XSS je velice jednoduchá: nastává pokud se uživatelský vstup z formuláře bez kontroly přidá do dynamicky generované stránky. Uživatel tak má možnost zadat jako vstup skript v některém z klientských jazyků a ten bude ve výsledné stránce proveden [5]. Takto ovšem provedeme skript pouze na svém stroji, čímž ničeho podstatného nedosáhneme. Je třeba použít již zmiňované sociální inženýrství. Stačí, když přinutíte uživatele, aby klikl na vámi sestrojený odkaz na XSS-zranitelné stránky, který má ve správném parametru query_stringu váš skript. Ve vrácené stránce se pak tento skript provede na jeho počítači a může např. krást session cookies či jiné citlivé údaje. Takovéto odkazy se nejčastěji umísťují na diskusní fóra. Nejnebezpečnější případ XSS, který se obvykle nazývá persistentní (výše uvedenému se říká nepersistentní), nastává, když se nekontrolovaná data od uživatele ukládají přímo na serveru do databáze, souborového systému či jinam. Pak stačí, aby útočník vložil skript pouze jednou a může napadnout velké množství uživatelů. Chyba tohoto typu byla nalezena např. v Hotmailu v roce 2001 a umožňovala krást Microsoft .NET Passport session cookies. Exploit této chyby zasílal podvržené emaily uživatelům Hotmailu, které obsahovaly speciálně sestrojené HTML. To prošlo přes kontrolní filtrovací kód na webu Hotmailu a provedlo se v Internet Exploreru klienta.
13
Kapitola 3
3. Exploity a bezpečnostní chyby v širších souvislostech 3.1 Otázka zveřejnění Objevení chyby v kódu je příčina a exploit je následek. To je nejkratší možné shrnutí celé nauky o exploitech. Důvodem proč tato nauka vznikla je, že počet objevených chyb neustále stoupá (je to především díky stoupající složitosti a propojenosti softwarových systémů a také kvůli obrovskému množství z Internetu dostupných programů, jejichž autoři si dali malou nebo žádnou práci s testováním svých výtvorů na bezpečnost):
Na tomto grafu je vidět celkový počet zveřejněných bezpečnostních chyb, bez jakýchkoli omezujících podmínek na jejich závažnost či jinou charakteristiku, od roku 1995 do roku 2005. Zdrojem těchto vynikajících on-line statistik je National Vulnerability Database. Spolu s počtem chyb stoupá též počet úspěšných útoků a finančních ztrát postižených společností. Větším z nich až tak, že vydávají nemalé prostředky na komplexní strategie obrany, včetně tzv.
14
vulnerability managementu. Ten v sobě zahrnuje především pravidelné aktualizování databáze bezpečnostních rizik, skenování vnitřní sítě na jejich přítomnost a automatickou aplikaci patchů. Jeho detailní rozbor je však mimo rozsah této práce. Klíčovou otázkou totiž je, co má hacker, programátor od výrobce softwaru, odborník u firmy zabývající se bezpečností IT či náhodný kolemjdoucí, dělat poté, co chybu objeví. V zásadě existují dva protikladné přístupy a mezi nimi známá zlatá střední cesta. První říká, že by se měly zveřejnit všechny známé informace o chybě tj. jak ji detekovat a jak jí využít, včetně už napsaného exploitu. Počítá totiž s tím, že oprava takto odhalené chyby bude ze strany výrobce rychlá, aby si nepokazil reputaci, a doba, po kterou je možné chybu využít, bude co nejkratší. Méně otevřená varianta tohoto přístupu zvaná „zodpovědné zveřejnění“ (responsible disclosure) tvrdí, že by se před plným zveřejněním na veřejnosti měly dát informace o chybě výrobci, aby mohl během nějaké rozumné doby (např. měsíc) vytvořit patch. V obou případech se však jednou dostane přesný návod na využití konkrétní chyby k bezpečnostním útokům na veřejnost, což je důvod proč řada odborníků tento přístup odmítá a razí názor „bezpečnost díky utajení“ (security through obscurity) [6]. Tento diametrálně odlišný přístup je postavený na teorii, že chyba není nebezpečná, pokud se o ní neví. Spoléhá se tedy na to, že ji útočník nemá možnost objevit. To je pochopitelně obtížné v případě open-source softwaru, takže je tento přístup úzce spojen pouze s produkty dodávanými v binární formě. Oba přístupy však mají společný cíl: bezpečnost, liší se pouze prostředky jak jí dosáhnout.
3.2 Životní cyklus bezpečnostní chyby Podívejme se nyní podrobněji na životní etapy chyby a jejího řešení [7]:
• •
•
objevení chyby (vulnerablity discovered) – Okamžik, kdy je chyba objevena, typicky bezpečnostními odborníky specializované organizace či samotného výrobce. zveřejnění chyby (vulnerablity disclosed) – Klíčová chvíle, kdy jsou informace o chybě uvolněny veřejnosti skrze newsgroups, fóra či elektronický tisk. Pravděpodobnost, že bude napsán exploit, který chybu využívá se dramaticky zvyšuje. dostupná oprava (fix available) – Okamžik, kdy je k dispozici testovaný patch od výrobce.
15
•
•
dostupný exploit (exploit code available) – Druhá klíčová chvíle, ve které je zveřejněn funkční exploit dané chyby. To umožňuje jak zkušeným kodérům, tak amatérům (tzv. script kiddies) mnohem snadněji vyvíjet útočný kód. chyba opravena (fix deployed or vulnerability mitigated) – Okamžik, kdy uživatel aplikoval výrobcův patch nebo novou verzi softwaru. Kromě toho má ovšem uživatel i jinou možnost jak hrozbu zmírnit a to např. přestat používat ohrožený software. Takovýto separátní krok může provést například hned po zveřejnění chyby.
Pro dobu, kdy je uživatel chybou ohrožen, máme anglický termín „Window of exposure“. Začíná zveřejněním chyby. Ve snaze minimalizovat tuto dobu by měli všechny zainteresované subjekty konat asi takto: Výrobce softwaru • • •
Dělat software s méně chybami s menší závažností. Opravy poskytovat co nejrychleji po zveřejnění chyby. Zajistit, aby patch opravil opravdu celý problém a nevytvořil další.
Objevitel chyby •
By měl dobře zvážit, kdy, komu a kolik informací o chybě poskytnout. Jejím zveřejněním dobu „Window of exposure“ startuje.
Uživatel • •
Aplikovat patche od výrobce co nejdříve to jde. Pokusit se i jinak zmírnit riziko např. vypnout ohroženou službu.
3.3 Snaha o standardizaci Není tedy žádným překvapením, že klíčovým prvkem při řešení problému je komunikace mezi jednotlivými aktéry a standardizace pojmů a postupů. Je to dlouhodobý úkol, který má své průběžné výsledky. Jedním z hlavních je tzv. CVE (Common vulnerability exposure), což je seznam standardizovaných jmen pro všechny známé chyby, umožňující snadnou výměnu dat mezi nejrůznějšími databázemi chyb. Pokud se objeví nová chyba je na základě diskuze a hlasování přidána do oficiální databáze CVE nevýdělečné organizace Mitre a je jí přidělen unikátní CVE identifikátor [8]. S CVE souvisí i standard CVSS (Common vulnerability scoring system), který sjednocuje dosavadní metriky pro posuzování vážnosti chyb na jednu otevřenou platformu. Skóre závažnosti chyby se stanovuje výpočtem na základě faktorů ze tří skupin [9]: •
SKUPINA ZÁKLADNÍCH METRIK (BASE METRIC GROUP) obsahuje vlastnosti chyby, které se s časem nemění a které jsou dány od jejího vzniku. Například:
16
•
SKUPINA DOČASNÝCH METRIK (TEMPORAL METRIC GROUP) obsahuje vlastnosti chyby, které se můžou s časem měnit a ovlivňovat její závažnost. Například:
•
jde o chybu exploitovatelnou lokálně nebo vzdáleně? je třeba k využití chyby nějaké autentizace? jaký stupeň poškození Integrity, Důvěrnosti či Dostupnosti chyba umožňuje?
exploitovatelnost: existuje už k chybě ukázkový kus kódu (tzv. proof of concept), odzkoušený a funkční exploit nebo zatím vůbec nic? je dostupný oficiální patch, neoficiální, uživatelsky vyvinutá, ale funkční oprava nebo není k dispozici nic?
METRIKY PROSTŘEDÍ (ENVIRONMENTAL METRICS) obsahuje charakteristiky chyby, které jsou vázány k prostředí, ve kterém se vyskytuje. Například:
stupeň potenciálního poškození – jaké všechny vedlejší škody může úspěšné zneužití chyby způsobit procento systémů v daném prostředí, které jsou chybou ohroženy
Na základě vlastností ze SKUPINY ZÁKLADNÍCH METRIK se stanoví základní skóre. To pak může ztratit 0 - 33% své hodnoty násobením vyčíslenými faktory ze SKUPINY DOČASNÝCH METRIK. Na závěr jsou vzaty v úvahu vlastnosti z METRIK PROSTŘEDÍ, které stanoví konečné skóre.
17
Kapitola 4
4. Penetrační testování 4.1 Princip Penetrační testování je způsob, jak odhalit slabá místa v konkrétní IT infrastruktuře. Na tento typ „auditu“ je takřka bez výjimky přizván externí subjekt, který se vžije do role útočníka. Rozeznáváme dva základní typy penetračního testování a to interní a externí [10]. Interní PT se provádí na vnitřní síti zákazníka a jeho cílem je zjistit, jaké možnosti má potenciální útočník zevnitř organizace. Externí se naopak provádí pouze z vnějšku (Internetu) a zkoumá potenciální slabiny z pohledu vzdáleného útočníka. Dalším důležitým faktorem je, zda se PT provádí bez jakékoli znalosti zkoumaného systému (tzv. black-box nebo též zero-based knowledge) nebo s předem dohodnutým rozsahem znalostí (white-box). Zastánci black-box PT tvrdí, že se tento způsob nejvíce blíží skutečnému postupu útočníka. To je sice pravda, ale dá se předpokládat, že ten kdo na vaši organizaci útočí už o vaší IT infrastruktuře má nějaké informace, možná i vynikající (bývalý zaměstnanec, ne-li bývalý správce sítě). Je lepší počítat s nejhorším případem a všechny informace testerům poskytnout předem.
4.2 Standardní metodologie Pro PT existuje několik standardizovaných metodologií, které zaručují systematický přístup k testování (nic není opomenuto) a použitelnost výsledků. Zde jsou některé z nich [11]: • • •
OSSTMM (Open Source Security Testing Methodology Manual) OWASP (Open Web Application Security Project) ISSAF (Information System Security Assessment Framework)
4.3 Nástroje 4.3.1 Bezpečnostní skenery Jsou to základní nástroje PT, slouží k testování sítě nebo jednotlivých strojů na přítomnost bezpečnostních děr. Pokud testujete síť, výsledkem je typicky seznam všech jejích strojů a odhad na nainstalované operační systémy. Dále ke každému stroji seznam otevřených portů a na nich běžících služeb, spolu s možnými riziky. Skenery se také můžou pokoušet zjistit, např. zachytáváním bannerů (banner grabing), konkrétní verzi programu zajišťujícího danou službu a reportovat jeho bezpečnostní chyby. Pokud testujete konkrétní stroj lokálně, tj. s bezpečnostním skenerem běžícím přímo na něm, má skener přístup k veškerému nainstalovanému softwaru a může tak provést důkladnou kontrolu. Na
18
pravidelně používaném PC, jehož majitel se příliš nezajímá o bezpečnost, to bývají řádově desítky nebo i stovky chyb. Bezpečnostní skenery můžeme srovnávat podle několika měřítek. Nejdůležitějším z nich je určitě počet nalezených bezpečnostních děr. To značně závisí na tom, jak velkou a aktuální má skener svou databázi chyb. Tu si podobně jako antivirové programy aktualizuje z Internetu. Proto je dobré vybrat si produkt od společnosti na jejíž schopnost, udržovat si databázi chyb aktuální, se dá spolehnout. Další měřítka jsou např. počet špatných detekcí (pokud jich je příliš, je to pro testera značná ztráta času), rychlost skenování nebo kvalita výsledných reportů.
4.3.2 Srovnání Uznávané srovnání bezpečnostních skenerů provedla v roce 2003 společnost MaxPatrol. Testovala těchto šest z nich [12]: • • • • • •
IS - Internet Scanner 7.0 LG - LanGuard 3.2 Ns - Nessus 2.0.6 NR - NetRecon 3.6 Rt - Retina 4.9.97 MP - MaxPatrol 7.0
Testovaných systémů bylo také šest, různých platforem (Solaris, Linux, Windows). Bodovalo se podle této tabulky: Vulnerability
Detected
Falsely Detected
Critical
+3
-1.5
Average
+2
-1
available information
+1
-0.5
Výsledek je dobře vidět v tabulce nebo následném grafu: IS
LG
MP
Ns
NR
Rt
Total correct detections
74
39
133
111
39
89
Penalty for false detections
-7
-1.5
-1.5
-16
-6.5
-7.5
Grand total (with penalty)
67
37.5
131.5
95
32.5
81.5
19
Jako další kritérium kvality skenerů posloužila přítomnost či nepřítomnost jiných než základních funkcionalit, kterými může skener disponovat. Jsou to: • • • • • •
Schopnost aktualizovat skener i databázi z Internetu. Zabudovaný plánovač úloh. Dostupnost různých skenovacích profilů a možnost vytvářet profily pro specifické úkoly. Přítomnost funkce „pause“ pro zastavení skenování v případě problémů na síti, stejně tak jako funkce „resume“ pro opětovné rozjetí ze stejného místa. Reporty generované pro použití jak administrátory tak managementem. Možnost vzdáleného skenování přes klienta připojeného na server.
Jak dopadly skenery v tomto srovnání je vidět na této tabulce: IS
LG
MP
Ns
NR
Rt
Scheduler
+
-
+
-
-
-
Profiles
+
-
+
+
-
+
Scan Pause
+
-
+
-
+
+
Report Variety
+
+
+
+
-
+
Client-Server
+
-
-
+
-
-
Možnost aktualizace z Internetu byla vypuštěna, protože jí disponují všechny srovnávané skenery. Nakonec si povíme něco o jediném z testovaných produktů, který je zdarma.
20
4.3.3 Nessus Mezi bezpečnostními skenery je nejpopulárnější z jednoduchého důvodu: patří k nejlepším a je zdarma. Podporuje ho mj. institut SANS a používá ho odhadem 75 000 organizací po celém světě. Nessus často přinášel převratné technologické novinky, které pak konkurence bez problémů přejala, jelikož jde o projekt doposud vyvíjený pod GPL, tedy jako open-source. To je asi jeden z hlavních důvodů, proč se autor Nessa Renaud Deraison rozhodl s tímto přestat a novou verzi už nevyvíjet pod GPL. Stále bude zdarma, ale už to nebude open-source. Jednou z těchto novinek byl speciální jazyk NASL (Nessus Attack Scripting Language), ve kterém jsou napsány všechny testy. Aktualizování Nessa tak spočívá ve stahování plug-inů napsaných v tomto jazyce, nemusí se stahovat žádný neověřený binární kód. Firma Network Associates’ (nyní přejmenovaná na McAfee) ji převzala a vytvořila podobný jazyk CASL pro svůj produkt CyberCop. Další věcí kterou posléze převzala i konkurence je tzv. smart service recognition, tedy nespoléhání se na to, že služby budou běžet na standardních, jim přiřazených portech podle IANA. Nessus tak rozezná např. FTP server běžící na portu 31337 nebo webový server na portu 8080.
4.3.4 Vlastní zkušenosti s testováním Testoval jsem s pomocí dvou skenerů, jedním byl Nessus a druhým Retina. Retina je komerční produkt, k dispozici je ovšem plně funkční trial verze. Nessus je samozřejmě zdarma, měl jsem ho jako součást softwarového vybavení na live cd s názvem Auditor. To se mi ovšem neosvědčilo tak, jako standardní instalace Nessa z jeho domovských stránek. Retina má jednoduché a intuitivní ovládání, ve kterém jsou volby a nastavení pro zkušené testery spíše skryty a vidět jsou hlavně ty základní. Testoval jsem s ní lokálně dva systémy s Windows XP. Na prvním, víceméně čistém tj. s minimem nainstalovaného softwaru, našla 34 chyb, z toho 5 vážných. Na druhém, běžně používaném PC, našla 80 chyb, z toho 11 vážných. Vyzkoušel jsem také generování výsledných reportů, jedna varianta je pro management a druhá pro administrátory. To jde snadno poznat z toho, že na první je spousta grafů a statistik typu „TEN MOST DANGEROUS VULNERABILITIES“, ale jinak je celkem k ničemu, kdežto na druhé je přesně vypsáno jaká chyba, na kterém stroji, závažnost a možnost nápravy. Nessem jsem testoval jednak jeden také víceméně čistý stroj s Windows XP a to tak, že jsem na jiném, Linuxovém PC rozjel nessusd a ze stroje s Windows XP se na něj přes grafickou konzoli (ta je také volně ke stažení na webu Nessa) přihlásil. Našel 39 chyb, z toho 10 závažných při vypuštění testů, během kterých by mohl testovaný stroj „spadnout“ (tuto volbu v sobě Nessus obsahuje). Poté jsem zkoušel testovat část sítě, čítající asi tři stroje, u kterých jsem rozjel služby na nestandardních portech, abych vyzkoušel jeho schopnost „smart service recognition“. Našel a správně označil všechny.
21
Kapitola 5
5. Vlastní implementace 5.1 Datový model Databáze je fyzicky implementována jako adresářová struktura. V jediném hlavním adresáři má každý kategorizovaný exploit svůj podadresář, ve kterém je uložen jeho zdrojový kód. Metadata pro vyhledávání jsou uložena v klasické databázi, v mé implementaci je to MySQL. Rozhodl jsem se pro ni, protože datový model je velice jednoduchý, počet tabulek nepřekročil desítku. Kromě toho MySQL postačujícím způsobem implementuje fulltextové vyhledávání, které má aplikace potřebuje. S ním ovšem souvisela i nutnost vzdát se tzv. cizích klíčů (foreign keys) a hlídání referenční integrity. MySQL má totiž jak známo, kromě dalších, dva hlavní ukládací enginy tabulek – MyISAM a InnoDB. MyISAM je engine základní, čili když explicitně nezadáte jiný, bude vaše tabulka používat tento. Nepodporuje transakce a tudíž je velice rychlý, kromě toho je jediný, který podporuje fulltextové vyhledávání. Jestliže ho tedy chcete nad nějakým sloupcem použít musí mít daná tabulka engine MyISAM. InnoDB oproti tomu transakce podporuje, díky čemuž je značně pomalejší než MyISAM. Jako jediný také podporuje cizí klíče. Pokud máte mezi dvěma tabulkami 1 ku n vazbu a chcete, aby o ní vaše databáze „věděla“ a tudíž mohla hlídat referenční integritu, musíte cizí klíč zadefinovat explicitně. Aby jste to mohli udělat, musí mít obě svázané tabulky engine InnoDB. Bohužel tedy nemůžete mít tabulku, na které by se dalo fulltextově vyhledávat a zároveň by byla referenčně svázaná s jinou tabulkou. Integritu dat jsem tedy musel zajistit na úrovni aplikace. Vazby na schématu datového modelu níže jsou tedy pouze pro orientaci, fyzicky implementovány nejsou.
22
5.2 Aplikace Nad touto databází je postavena aplikace, která každému uživateli umožňuje již zmíněné vyhledávání exploitů podle několika omezujících kritérií: • • • • • • •
slovo z názvu či klíčové slovo s exploitem související doba od – do, ve které byl exploit zveřejněn platforma (Windows, Unix, Cisco, Mac atd.) typ využité bezpečnostní chyby (buffer overflow, SQL injection, XSS atd.) typ útoku (DoS, code execution, command execution atd.) možnost použití – lokální nebo vzdálený použitý programovací jazyk (c, php, perl, python, HTML, SQL atd.)
Z těchto kritérií jsou jasné použité kategorizační charakteristiky exploitů, nyní si je rozebereme podrobněji: • •
•
• •
•
Doba zveřejnění. Nebývá zcela jednoznačná, což je důvod proč se s přesností omezuji pouze na měsíce. Postižená platforma. Často není možné ji přesně specifikovat, např. mnohé webové aplikace mohou jet na jakékoli platformě, stejně tak má mnoho programů své verze pro Windows, Unix i Mac a chyba se může vyskytovat ve všech. Jedná se tedy o kategorii nepovinnou. Pokud ji specifikovat lze, tak nejpřesněji, jak je to možné. Například pokud se chyba týká několika určitých verzí MS Windows a jiných ne, musí se zadat nejmenší možný „uzávěr“ a tím je Windows. Typ chyby. Zkušený tester ví, že na typu chyby do značné míry závisí i její závažnost a způsob jakým se dá využít. Navíc nemusí být odborníkem na všechny typy, ale pouze na některé, takže rozdělení podle této charakteristiky jistě uvítá. Typ útoku. Určuje výsledek, jakého můžeme využitím chyby dosáhnout. To umožňuje rozlišit exploity podle závažnosti. Vzdálenost. Velice důležitá charakteristika, která vymezuje možnost použití exploitu. Vzdálený je možno použít přes Internet bez jakékoli autentizace, kdežto lokální pouze s přihlášením na konkrétním stroji. Použitý jazyk. Ne každý ovládá všechny používané jazyky, což je důvod proč je tato charakteristika užitečná. Exploity je totiž před použitím často nutno modifikovat.
Správci umožňuje aplikace data také aktualizovat – přidávání nových záznamů, změnu stávajících a mazaní starých. K této aktualizaci používá aplikace jazyk XML. Formát záznamů si nyní vysvětlíme na příkladě: <exploit> <description>
23
The following Metasploit module exploits a SQL injection flaw in the Lyris ListManager software for Microsoft SQL Server. This SQL injection flaw allows for arbitrary commands to be executed with administrative privileges by calling the xp_cmdshell stored procedure. <system name="Lyris ListManager" version="8.x" /> <system name="Lyris ListManager" version="7.x" /> <system name="Lyris ListManager" version="6.x" /> <system name="Lyris ListManager" version="5.x" /> LyrisListManager <month>12 2005WindowsSQL injectioncommand executionremoteperl <external-links> http://metasploit.com/projects/Framework/modules/exploits/lyri s_attachment_mssql.pm Použité značky mají tento význam: • • • • • • • • • • •
<description> obecný popis exploitu uzavírá postižené systémy <system> postižený systém s atributy jméno, verze a atributem, který určuje, zda jsou postiženy i předchozí verze uzavírá klíčová slova klíčové slovo <month> měsíc zveřejnění exploitu rok zveřejnění exploitu postižená platforma – Windows, Unix, Cisco atd. typ bezpečnostní chyby – SQL injection, Buffer overflow atd. typ útoku – Denial of Service, code execution, command execution atd. možnost útoku – remote, local
24
• • • •
jazyk, ve kterém je exploit napsán – c, php, perl, python, SQL atd. <external-links> uzavírá odkazy na další zdroje informací odkaz na další zdroj informací adresář, ve kterém je exploit uložen
25
Kapitola 6
6. Závěr Tato práce nejdříve seznamuje čtenáře s problematikou bezpečnostních chyb a exploitů obecně a poté ukazuje jejich souvislost s penetračním testováním. Dále představuje a srovnává nástroje, které se pro penetrační testování používají. V praktické části se rozebírá zvolená kategorizace exploitů, návrh a implementace databáze metadat pro vyhledávání a aplikace, která je nad databází postavena. Kritériem použitelnosti celé práce je možnost jednoduché aktualizace databáze. Ta se proto provádí daty ve formátu XML. Dále je popsán způsob jakým se dá v databázi vyhledávat. Vyhledávací kritéria neboli charakteristiky exploitů jsou vyjmenována a je vysvětlen jejich význam. Vytvořená databáze exploitů může typicky sloužit jako rychlá pomůcka penetračního testera v případě, že nemá k dispozici nebo nemůže použít sofistikovanější nástroje. Také se velice hodí pokud tester přesně ví, co potřebuje, takže zdlouhavé skenování sítě by bylo zbytečné.
26
Literatura [1] Wikipedia. Exploit (computer security). Dokument dostupný na URL http://en.wikipedia.org/wiki/Security_exploit [2] Aleph1. Phrack 49 – Smashing the stack for fun and profit. Dokument dostupný na URL http://www.phrack.org/show.php?p=49&a=14 [3] Andreas Thuemmel. Analysis of format string bugs. Dokument dostupný na URL http://downloads.securityfocus.com/library/format-bug-analysis.pdf [4] Chris Anley. Advanced SQL Injection In SQL Server Application. Dokument dostupný na URL http://www.ngssoftware.com/papers/advanced_sql_injection.pdf [5] Wikipedia. Cross site scripting. Dokument dostupný na URL http://en.wikipedia.org/wiki/Cross_Site_Scripting [6] Wikipedia. Vulnerability (computer science). Dokument dostupný na URL http://en.wikipedia.org/wiki/Security_vulnerability [7] Jeffrey R. Jones. Putting Days-of-Risk to Practical Use. Dokument dostupný na URL http://www.microsoft.com/technet/security/secnews/articles/itproview point060904.mspx [8] CVE Homepage. http://www.cve.mitre.org [9] Mike Schiffman. A Complete Guide to the Common Vulnerability Scoring System (CVSS). Dokument dostupný na URL http://www.first.org/cvss/cvss-guide.html [10] Corsaire. Penetration testing guide. Dokument dostupný na URL http://www.penetration-testing.com [11] Wikipedia. Penetration test. Dokument dostupný na URL http://en.wikipedia.org/wiki/Penetration_testing [12] MaxPatrol. Comparison Of Network Security Scanners. Dokument dostupný na URL http://www.maxpatrol.com/pd_cmp.asp
