Varnost nekega omrežja
Pred časom mi je odgovorni urednik predlagal zanimivo idejo o izvedbi penetracijskega preizkusa nekega konkretnega produkcijskega omrežja. Zamisel je bila odlična z več vidikov: preverili bi varnostno stanje omrežja, pokrpali morebitne pomanjkljivosti, pa še temo za članek bi imeli. Rečeno storjeno.
Varnost nekega omrežja
Seveda smo najprej določili pravila. Dogovor je bil preprost: odpadejo vse oblike socialnega inženiringa, tudi "client-side" napadi v obliki pošiljanja PDF/DOC/XLS datotek z nameščenimi stranskimi vrati na e-naslove zaposlenih so bili izločeni. DoS napadi so dovoljeni, vendar le v predhodno dogovorjenem časovnem terminu. O izvajanju preizkusa bo obveščena le peščica vodilnih, kar je tudi predpogoj za verodostojnost testa. Če so zaposleni seznanjeni s tem, "da se nekaj dogaja", so največkrat bolj previdni, kot bi bili sicer.
Tudi cilji so bili jasno določeni: v primeru razobličenja (defacement) spletnih strani, dostopa do gesel ali datotek z internih ali eksternih produkcijskih računalnikov, popisa notranjega omrežja (IP naslovi ter imena računalnikov) ali uspešnega napada z zavrnitvijo storitve (Denial of Service) zmagajo "napadalci".
Velja omeniti, da test že v osnovi ni bil zamišljen kot "profesionalno izveden", saj bi za nekaj takega potrebovali bistveno več časa, sredstev in kadra. Tudi tak preizkus pa je lahko povsem zadovoljiv indikator varnostnega tveganja. Nedvomno pa testiranje v takšni obliki in obsegu ne more biti merodajno za institucije in podjetja, ki upravljajo s kritično infrastrukturo. Napake tukaj stanejo veliko več kot bi najem strokovnjakov in izvedba profesionalnega preizkusa.
Osnove
Kaj sploh je penetracijski preizkus (pentration testing) informacijskega sistema? Če povzamemo odlično definicijo g. Mitje Kolška, gre dejansko za praktično, nadzorovano in dokumentirano simulacijo poskusa vdora v informacijski sistem s strani enega ali več "napadalcev" (v žargonu je ta skupina znana kot "tiger team"). Pri tem ti uporabljajo vnaprej dogovorjene in dovoljene metode ter poskušajo z njihovo pomočjo in s pomočjo posebnih orodij poiskati in izrabiti ranljivosti sistema za dostop do zavarovanih informacij in storitev.
Primarni smoter takega preizkusa ni vdor v sistem za vsako ceno, temveč preverjanje učinkovitosti implementiranih varovalnih mehanizmov, varnostne ozaveščenosti zaposlenih ter varnostne politike na splošno. Četudi "napadalcem" vdor oz. dostop do zaupnih informacij spodleti, lahko med potekom preizkusa odkrijejo marsikatero pomanjkljivost in nepravilnost ter jo nato posredujejo naročniku. Popoln penetracijski preizkus seveda zajema tudi svetovanje, kako odkrite pomanjkljivosti sanirati in odpraviti, izjemoma pa lahko zajema celo pregled kode (peer review) interno razvitih aplikacij. Da bi se izognili nevšečnostim, je izvajalec dolžan naročniku posredovati IP naslove, s katerih se bo izvajalo testiranje, sicer bi lahko kdo od zaposlenih sklepal, da gre za načrtni napad.
Med začetnim usklajevanjem se naročnik in izvajalec dogovorita, katera oblika penetracijskega preizkusa se bo izvajala. Ločimo naslednje načine izvedbe: "black-box test", "white-box test" in "grey-box test". V prvem primeru "tiger team" nima nikakršnih informacij o produkcijskem omrežju. Naročnik mu ponavadi posreduje le IP spletnega strežnika. Tak pristop je najpopolnejša simulacija zunanjega napadalca.
V primeru "white-box" pristopa je izvajalec podrobno seznanjen z infrastrukturo in topografijo notranjega omrežja. Na razpolago ima IP naslove, diagrame omrežja, informacije o operacijskih sistemih ter aplikacijah v uporabi itd. V praksi se ta način izvedbe dejansko največ uporablja, saj predstavlja "črni scenarij", torej zunanjega napadalca, ki si je pridobil dostop v interno omrežje.
Namen "grey-box" pristopa pa je simulacija najpogostejšega vzroka varnostnega incidenta v podjetjih, t.i. "notranje nevarnosti" ali natančneje zlonamernega zaposlenega. Izvajalec v tem primeru dobi tudi uporabniško ime in geslo ter dostop do različnih internih spletnih storitev (mail, ftp, file server ...) ter aplikacij. Na razpolago ima tudi vse informacije in vire, ki so dostopni drugim zaposlenim.
Sistematičnost in metodičnost sta ključa do kakovostnega izvedenega penetracijskega testa. Tipičen varnostni preizkus informacijskega sistema je sestavljen iz nekaterih določenih zaporednih korakov, ki gredo v naslednjem vrstnem redu: "reconnaissanse" (poizvedovanje, ogledovanje) se nanaša na iskanje informacij o omrežju; "enumeration" (popisovanje, oštevilčevanje) pa je proces pridobivanja informacij z odkritih "živih" sistemov. Nekateri ta dva koraka imenujejo preprosto skeniranje (scanning) ali zbiranje informacij (information gathering). Obe fazi sta nadvse pomembni in "pen-testerji" jima dejansko namenjajo največ časa.
Naslednji korak je pridobivanje dostopa, kjer se tudi konkretno uporablja izkoriščevalna koda (exploits), sledi faza implementacije stranskih vrat in na koncu še faza brisanja sledov. V praksi se testiranje pogosto konča po tretjem koraku, nato "tiger team" izdela poročilo, v katerem so navedena odkritja in opisi pomanjkljivosti ter postopki za njihovo odpravljanje.
Kako pogosto pa je penetracijski preizkus priporočljivo izvajati? Frekvenca izvajanja je seveda pogojena z dejavniki, ki smo jih že omenili (sredstva, kader, čas ...). Nepisano pravilo pa priporoča izvajanje preizkusa na tri mesece, s tem da se najmanj enkrat na leto najame zunanje izvajalce. To niti ni tako pogosto, ko vzamemo v zakup to, da se vsak dan odkrije na desetine novih vrzeli in proizvede enako število zlonamernih programov. Če je produkcijsko omrežje danes uspešno prestalo preizkus, ni nobene garancije, da ga bo tudi jutri. Vzemimo kot zgled eno največjih IT podjetij: Microsoft. Po uradnih podatkih iz leta 2004 so njihovi IDS (Intrusion Detection System) sistemi zaznali vsak mesec približno 100.000 poskusov vdorov. Drži, niso vsa podjetja tako "zanimiva" kot Microsoft, vendar so napadalci povečini oportunisti, ki se ne bodo odrekli lahkemu plenu. Še en "zombie" računalnik v DDoSnetu je vedno dobrodošel. Skeptiki si seveda lahko namestijo različne aplikacije za preprečevanje in odkrivanje vdorov (IDS/IPS/WAF) ter opazujejo dogajanje. Po nekajdnevnem preverjanju dnevniških zapisov bo tudi njim jasno, zakaj je splet prej "divji zahod" kot "vesolje veselja".
Akcija
Kocka je torej padla na "black-box test". V rokavu seveda nismo imeli nobene vrzeli "0-day". Uporabili smo le ponudbo v spletu in lastno iznajdljivost. Kar je tudi realno najbližje tipičnemu napadalcu. Prvi korak je seveda "ogledovanje", ki je lahko pasivno ali aktivno. Pri pasivnem ogledovanju napadalec nikdar ne pride v neposreden stik s "tarčo". V spletu najdemo številne storitve, ki nam omogočajo pasivno poizvedovanje oddaljenega sistema. Če navedemo le nekatere: robotex.com, centralops.net, serversniff.net ...
Aktivno ogledovanje pa zahteva uporabo orodij, kot so ping, traceroute, pathping, nslookup, dig, ping sweep, host, whois, nmap ... Kot smo že omenili, je namen poizvedovanja pridobivanje informacij o omrežju, to pa med drugim obsega odkrivanje razpona (network range), pregledovanje razpona in odkrivanje "živih" naslovov (ping sweep), odkrivanje imenskih strežnikov ter prenos zone (DNS zone transfer), pregledovanje whois baze, pregledovanje odprtih TCP/UDP vrat na odkritih sistemih (port scanning), odkrivanje nameščenih operacijskih sistemov (OS detection) ... Kakovosten "reconnaissance" dejansko zahteva veliko časa, vendar se vloženi trud nemalokrat obrestuje. Naše ogledovanje omrežja je vsekakor obrodilo sadove. Odkrili smo, da ima "tarča" štiri zunanje naslove IP, izmed katerih sta dva tudi strežnika DNS.
Ranljivi DNS
In tukaj smo že našli prvo vrzel! Eden izmed imenski strežnikov je omogočal neavtoriziran prenos zone (zone transfer). Prenos zone (tudi transfer AXFR) je mehanizem, s pomočjo katerega sekundarni domenski strežnik usklajuje svojo zbirko podatkov s tisto iz primarnega strežnika DNS. Nepooblaščeni prenos zone pa je v primeru, ko interni imenski strežniki niso ločeni od zunanjih, v internet povezanih strežnikov, huda pomanjkljivost s katero smo si pridobili načrt (IP naslovi/imena) internega omrežja!
Ogledovanje strežnikov DNS si nedvomno zasluži podrobnejšo analizo. Z uporabo orodij dig in nslookup smo odkrili, da prvi strežnik uporablja bind NS različice 9.3.4-P1.2, medtem ko drugi uporablja Microsoft DNS (Windows Server 2003), ki pa je bil najverjetneje le nadgradnja predhodno nameščenega strežnika Windows 2000.
Naslednji korak je preverjanje, ali sta imenska strežnika ranljiva na famozni "Kaminsky bug", sicer bolj znan kot "zastrupljanje DNS predpomnilnika" (DNS cache poisoning). Z izrabo ranljivosti lahko napadalec podtakne lažne DNS podatke v predpomnilnik in tako preusmeri promet iz legitimnih v lažne strežnike, kar je nujno pri naprednem ribarjenju (phishing). Ta pomanjkljivost je pred časom dvignila silno veliko medijskega prahu, dejansko pa je izkoriščanje vrzeli zelo nezanesljivo, saj je učinkovitost izkoriščevalne kode krepko pod optimalnim. Še en zanimiv podatek: tudi ob uspešnem zastrupljanju predpomnilnika je obstojnost lažnega DNS vnosa zelo kratka (nekje med 10-30 sekundami). Okno priložnosti je torej tudi za spretnega napadalca zelo majhno. Čeprav sta bila oba strežnika zakrpana, smo čez vseeno pognali tudi Metasploit modul. Za vsak primer. Neuspešno.
pentest metasploit.jpgPregledovanje odprtih vrat s programom Nmap
So kakšna vrata vendarle odprta?
Sledi faza, brez katere si varnostnega testiranja sploh ne moremo zamisliti: pregledovanje odprtih vrat (port scanning). Gre za proce,s s katerim odkrijemo odprta TCP/UDP vrata. Na odprtih vratih seveda poslušajo določene storitve, ki jih bomo nato poskusili kompromitirati. Katero orodje izbrati, je najbrž popolnoma nesmiselno vprašanje. Program Nmap (Network Mapper) je na tem področju brez konkurence. Nmap je zmogljiv program, ki omogoča pregledovanje na različne načine (SYN, NULL, FIN, ACK, Xmas ...), s katerimi poskuša pretentati varovalne mehanizme, da bi odkrili in zabeležili pregledovanje sistema. Standardno TCP Connect() pregledovanje je namreč zelo "glasna" zadeva, ki jo odkrije vsak IDS/IPS, saj se pri takem načinu izvede popoln proces sinhronizacije in ustvarjanja povezave t. i. tri-smerno usklajevanje (three-way handshake).
Rezultat pregledovanja odprtih vrat štirih zunanjih IPjev je bil naslednji: produkcijsko omrežje uporablja tako tipične storitve (HTTP/S, SMTP, FTP, DNS, IMAP, POP3) kot storitve, namenjene upravljanju in dostopu na daljavo (RDP, VNC, SSH). Nameščeni operacijski sistemi so Debian Linux, Windows 7 in Windows Server 2003.
Preverjanje ranljivosti
Zbiranje informacij nadaljujemo z avtomatiziranim preverjanjem znanih ranljivosti (vulnerability scanning). Izbira primernega orodja je tukaj veliko bolj pestra. Čeprav smo uporabili Nessus (stara navada pač), se tudi alternative, kot so Retina, OpenVas, SARA in SAINT, povsem enakovredno merijo s "kentavrom".
Orodje Metasploit med zastrupljanjem DNS medpolnilnika
Preverjanje ranljivosti na eksternih produkcijskih računalnikih je razkrilo bore malo ali nič. Treba je priznati, da so skrbniki sistema zelo dobro poskrbeli za varnost. Nessus je dejansko odkril le dve vrzeli. Za kritično je označil prekoračitev medpomnilnika (buffer overflow) v enem izmed strežnikov FTP. Vrzel je opisana tukaj:
www.arnes.si/si-cert/cve/pokazi.shtml?id=CAN-2006-2172
Čeprav za omenjeno ranljivost v spletu nismo našli delujoče izkoriščevalne kode, bi "exploit" lahko napisali tudi sami - če bi se stvari nagnile v našo korist. Pa se niso. Nikakor nam ni uspelo najti ustrezne, res že nekoliko postarane različice strežnika Gene6 FTP, ki bi jo nato namestili v naš testni mlinček. Na pomoč nam je priskočil upravitelj "tarče", ki smo jo preverjali, in nam omogočil dostop do ranljivega strežnika. Vendar, glej ga zlomka, strežnika FTP nam nikakor ni uspelo "sesuti". Tako smo zopet naleteli na podoben primer kakor pri "Kaminsky bugu": zanesljivost. Tudi "exploiti" imajo takšne in drugačne "luknje" in celo najenostavnejši "proof-of-concept" včasih preprosto ne deluje.
Vendar resnici na ljubo priznajmo, da bi bilo vrzel tudi v optimalni pogojih praktično nemogoče izrabiti. FTP strežnik je namreč domoval na Windows 7. Izkoriščanje prekoračitev medpomnilnika v tem operacijskem sistemu pa je trenutno domena peščice strokovnjakov.
Druga, milejša vrzel, se je nanašala na puščanje informacij (information leakage) iz DNS strežnikov, saj sta dopuščala t. i. "DNS cache snooping", ki omogoča vohljanje za obiskanimi spletnimi stranmi.
Odkrivanje pomanjkljivosti s programom Nessus
Napad na splet!
Vendar puške še nismo odvrgli v koruzo, saj smo imeli v rokavu še nekaj potez, med drugim tudi preverjanje varnosti spletnih aplikacij. Pozornost je bila torej usmerjena na dva spletna strežnika (Apache in IIS6). Najprej smo se zadev lotili ročno in v vnosna polja vnašali posebne znake, ki bi lahko "zmedli" ustaljeno delovanje aplikacije. Če navedemo le nekatere: ', '', %, '>, -9999, -1.1, %s, %d, %x, %n, %0a, %00, ... Namen vnašanja znakov je izpis poročila o napaki, ki bi nam lahko dal več informacij o spletni aplikaciji, strukturi spletnega strežnika ali zbirke podatkov.
Ročno delo smo nadaljevali z iskanjem preprostih vrzeli oz. tistega, kar v slengu označejo z "low hanging fruit". V to kategorijo spadajo XSS, CSRF, prečkanje imenikov (directory traversal), utrjevanje seje (session fixation) ter pregledovanje za namestitvenimi datotekami in imeniki, kot so: phpinfo.php, htaccess.txt, robots.txt, crossdomain.xml, iisadmpwd, perl-status... Vloženi trud je prinesel želene rezultate, saj smo se dokopali do datoteke phpinfo.php (http://php.net/manual/en/function.phpinfo.php), ki je prava zakladnica informacij o PHP okolju, spletnem strežniku in operacijskem sistemu!
Žal je pregled php.ini kmalu razkril, da ima konfiguracijska datoteka problematične parametre (allow_url_include, allow_url_fopen, register_globals, magic_qoutes_gpc,...) ustrezno nastavljene, s tem pa je izključena možnost vključevanja datotek PHP (file inclusion) in prečkanja imenikov.
Končno je prišel čas tudi za uporabo avtomatiziranih orodij za iskanje ranljivosti v spletnih aplikacijah (web application vulnerability scanner). Avtomatizirana orodja seveda niso popolnoma zanesljiva, pregledovalniki spletnih aplikacij pa so še veliko bolj površni. Za primer, uporabili smo tri različne programe in v vseh primerih so se rezultati nekoliko razlikovali. Na srečo pa je izbira res velika (Nikto, Acunetix, Netsparker, Wapiti, Scrawlr, WebInspect ...). Nekateri pregledovalniki imajo sicer slabo lastnost, da pokleknejo na strežnikih z velikim številom strani. Prijetno pa smo bili presenečeni nad novim Netsparkerjem, ki ga razvija priznani strokovnjak za varnost spletnih aplikacij Ferruh Mavituna. Čeprav je program še v beta fazi testiranja, je izjemno hiter, stabilen, pregleden in zanesljiv.
Netsparker je odličen pregledovalnik vrzeli v spletnih aplikacijah
S pomočjo pregledovalnikov smo odkrili, da je v enem izmed spletnih strežnikov nameščena hroščata različica aplikacije OpenX, ki služi prikazovanju oglasov. Pregledovalniki so namreč zabeležili kar nekaj potencialnih vrzeli (XSS, prečkanje imenikov, vrivanje SQL) v različnih PHP datotekah. Aplikacijo smo si torej namestili na testni mlinček in se lotili podrobnejše analize.
XSS vrzeli so se izkazale za praktično neuporabne, saj so bile v upraviteljskem delu aplikacije. Le uporabnik z aktivno skrbniško sejo lahko doseže ranljive skripte. Možnost, da bi tak uporabnik kliknil podtaknjeno povezavo, ki bi "ugrabila sejo" (session hijacking) je izredno majhna.
Prečkanje imenikov je trivialna, vendar zelo uporabna vrzel, s katero lahko pregledujemo vsebino nekaterih datotek v sistemu. Izredno zanimiva je na primer datoteka /etc/passwd, s katero lahko pridobimo imena vseh uporabnikov. V našem primeru je bil URL videti nekako takole:
http://server/web/delivery/fc.php?MAX_type=../../../../../../etc/passwd%00
Zadeva kakopak ni delovala. Že omenjeni zapisi v php.ini preprečujejo podobne napade. Takoj ko smo na testnem mlinčku spremenili vrednosti "allow_url_fopen" in "register_globals" se je v brskalniku prikazala vsebina datoteke /etc/passwd. Seveda pa na pravem sistemu nismo imeli dostopa do php.ini.
Preostalo nam je le še vrivanje SQL. Najprej pa smo potrebovali zagotovilo, da skript res dopušča vrivanje SQL poizvedb. Da bo celotna zgodba še nekoliko bolj zapletena, je šlo v tem primeru za t. i. slepo vrivanje SQL (blind SQL injection), pri katerem odgovori na poizvedbe niso prikazani v brskalniku. Vrivanje dejansko poteka "na slepo", edini indikator pa je odzivni čas. Nič kaj preprosta zadeva. Delo so nam precej olajšali nasveti varnostnega raziskovalca Sandra Gaucija, ki je vrzel tudi odkril.
Sestavili smo testno SQL poizvedbo, ki nam bo v primeru obstoječe vrzeli prikazala stran po 10 sekundah. Na testnem mlinčku je poizvedba delovala, ne pa tudi na ciljnem strežniku. Eden izmed možnih razlogov, zakaj vrivanje v slednjem primeru ni delovalo, je onemogočeno pregledovanje imenika, v katerem je ranljivi skript. Privzeto je pregledovanje namreč dovoljeno.
Tako sta nam preostali le še dve možnosti: napad z grobo silo (brute-force) in zavrnitev storitve (denial of service). Prvega smo izločili. Verjetno je vsakomur jasno naslednje: če dovolj dolgo izvajaš napad z grobo silo, boš prej ali slej odkril ali "razbil" še tako kompleksno geslo. Težava pa je nekje drugje, zato je smiselno pred začetkom izvedbe napada z grobo silo odgovoriti na naslednja vprašanja: "kdaj je dovolj dolgo", "kaj s tem pridobimo" in "ali se to splača".
Nekaj podobnega velja tudi za napade z zavrnitvijo storitve: z dovolj velikim številom "botkov" lahko spraviš na kolena čisto vsak strežnik. To je dejstvo, ki ne potrebuje nikakršnega testiranja. Prav zato preverjanje DDoS (distributed denial of service) napadov ni posebno zanimivo. Čisto druga zgodba pa so DoS napadi, pri katerih je učinek dosežen že z majhnim številom paketkov.
DoS v praksi
Orodje Nessus ima možnost iskanja t. i. stanja DoS sicer privzeto izključeno in to je tudi povsem razumljivo. Nihče si v produkcijskem omrežju ne želi nenadzorovanega kaosa, ki ga takšno pregledovanje lahko povzroči. Sploh pa zato, ker je takšna izbira tudi povsem nepotrebna. Do zdaj smo o omrežju pridobili dovolj uporabnih informacij, da lahko takšna stanja odkrijemo tudi sami.
Konkretno sta bili odkriti dve možni tarči: imenski strežnik Bind ter dva spletna strežnika Apache. Med nadzorovanim in dogovorjenim testiranjem DoS se je izkazalo, da imenski strežnik ni podlegel napadu, medtem ko sta oba spletna strežnika odpovedala poslušnost in pokleknila po nekaj sto poslanih paketkih. Namen napada dejansko ni "sesutje" strežnika, temveč nedosegljivost spletnih strani. Nedvomno gre za kritično vrzel, ki je sicer javno znana in dokumentirana od leta 2007, vendar je razvijalci pri Apache Foundation do danes iz povsem neznanih razlogov še niso zakrpali. Po neuradnih virih je vrzel menda mogoče omiliti/preprečiti z modifikacijo nekaterih parametrov v konfiguracijski datoteki strežnika Apache, to pa lahko povzroči več težav kot koristi. Strokovnjaki menijo, da je edina rešitev uporaba kakovostnih uravnalnikov obremenitve (load balancer). Kot zanimivost - Microsoftov IIS teh težav nima.
Na tej stopnji je penetracijski test končan. Sledi izdelava poročila in odpravljanje odkritih pomanjkljivosti. In kakšna ja torej stopnja varnost testiranega omrežja? Po našem skromnem mnenju je danes nadvse spodobna. Jutri pa je že nov dan :-)
Posebna zahvala: Sandro Gauci (Enable Security), Ferruh Mavituna (Mavituna Security)
Čisto kot zanimivost še beseda ali dve o napadih DDoS. Številni skrbniki in informatiki se verjetno spomnijo famoznih distribuiranih napadov z zavrnitvijo storitve, ki so februarja leta 2000 spravili na kolena velikane, kot so Yahoo, Amazon, CNN, eBay, Dell ... Da je "pobalin", odgovoren za te napade, danes medijska osebnost, ni nobena skrivnost. Manj znano pa je, da je enega izmed uporabljenih programov, Trinoo, napisal 13-letnik.