blog.phuture.sk

určite ste to už čítali alebo počuli. hackeri prenikli do počítačov nbú, prípadne iné hutné titulky. počas včerajšieho dňa (streda) sa dalo na danú tému prečítať naozaj všeličo “zaujímavé”, ale nikde som nevidel žiaden podrobnejší rozbor problému. verbálne útoky na úrad ako taký nechajme pre tentokrát bokom a pozrime sa na vec z technickej stránky.

podľa e-zinu, kde bol zverejnený stručný popis prieniku sa dalo pomerne ľahko zistiť, že prvotný vektor útoku smeroval cez framework horde napísaný v jazyku php. samozrejme, všade sa píše, že to je webmail, pritom webmail je len jedna z komponent nad týmto aplikačným frameworkom. meno webmail aplikácie je imp. na stránke (resp. v mailing liste s oznamami) tvorcov frameworku bola v skorých ranných hodinách 28.marca 2006 oznámená závažná bezpečnostná chyba a odporúčanie na okamžitú aktualizáciu. tento problém bol zaevidovaný v databáze cve pod číslom CVE-2006-1491. následne bola informácia zverejnená cez zdroje podobných oznámení, napríklad na portáli securityfocus bola táto informácia publikovaná 28.marca o 12. hodine. problém našiel, opravil a reportoval jeden z vývojárov projektu horde, jan schneider.
ako vyplývalo z uvedených oznamov prípadne referencií, problémom bol zobrazovač nápovedy, ktorý pomocou kombinácie funkcií eval() a passthru() umožňoval vykonávať vzdialene príkazy na systéme v kontexte používateľa pod ktorým bežal web server. obyčajne je to používateľ apache alebo http. práve toto bol spôsob, ako bol skompromitovaný framework horde prevádzkovaný na serveri webmail.nbusr.sk. dôležité je všimnúť si, že takto bolo možné vykonať akýkoľvek príkaz na systéme. ako vidíme z rozdielového logu cvs servera, táto závažná chyba bola odstránená vyňatím zbytočného volania eval v predmetnom zobrazovači pomoci. potom nasledovala séria veľmi nešťastných skutočností. po zneužití popísanej chyby a zobrazení databázy systémových používateľov, ten (tí?) kto systém napádal sa pokúsil prihlásiť k takto zistenému účtu s názvom nbusr a veľmi jednoduchým heslom nbusr123, ktoré skončilo úspechom… to bolo otvorenie cesty k systému. podobný prístup by bolo možné zabezpečiť aj vyššie popisovanou chybou vo frameworku horde a spustiť na niektorom porte (ak by boli zvonku dostupné) shell a prístup k systému získať týmto spôsobom. jednoducho, možností na využitie úvodného vektora bolo viacero, čo len svečí o jeho veľkej nebezpečnosti. ďaľšia popisovaná činnosť už súvisela s tým, že takto zistený názov účtu a aj heslo bolo použiteľné na viacerých systémoch na dostupnej vnútornej sieti. ďalšia veľmi nešťastná skutočnosť bolo zistenie “hesla” 123456, ktoré bolo kľúčom pre prístup k superpoužívateľskému účtu na všetkých serveroch ako aj routroch a switchoch. toto bola obzvlášť poľutovaniahodná skutočnosť. vďaka tomuto bola celá sieť, všetky dostupné systémy, všetky pripojené sieťové prvky ovládateľné tak, že ich bolo možné nakonfigurovať do ľubovoľného režimu a monitorovať tak sieťovú ako aj “príkazovú” prevádzku. záleží len od topológie a fyzického oddelenia systémov, ako ďaleko sa takýmto spôsobom dalo dostať. podľa zverejnených informácií sa takto dalo dostať veľmi ďaleko, aj napriek bagatelizovaniu predstaviteľov úradu. zverejnená bola aj informácia, že touto cestou sa podarilo získať prístup na servery a zariadenia prevádzkovateľa internetového pripojenia úradu, spoločnosti netlab plus. všetko so všetkým súvisí… aké sú, resp. boli možnosti takýmto nepríjemnostiam predchádzať? rozhodne sa oplatí takto rozsiahle a potencionálne nebezpečné web aplikácie prevádzkovať na samostatnom systéme s dobre zabezpečeným, od systému izolovaným, interpreterom php. možností je mnoho. vidíme, že v tomto prípade by pomohlo obmedzenie množiny systémových príkazov, ktoré je možné spúšťať na systéme (obyčajne nie sú potrebné žiadne..). ďalšie dobré pravidlo je použitie silnej autorizácie a autentikácie pri vzdialenom prístupe k systémom. kombinácia verejného a privátneho kľúča, pričom privátny kľúč je uložený na izolovanom mieste, je už dávno elegantným a aj dostatočne účinným spôsobom. zabudnite na heslá.. to len ako prevencia. zabezpečenie priebežného aktualizovania systémov, sledovanie oznamov o aktualizáciách prevádzkovaných aplikácií a iné kroky sú potom už len bežná operatíva. čo dodať na záver? celú kauzu, ako tradične, celkom dobre mediálne pokryl denník sme, keď v sérii článkov pomerne laickým spôsobom (ako obyčajne so značným technickým zjednodušovaním) popísal problém, jeho dopad, reakcie prevádzkovateľa ako aj anonymný rozhovor s jedným z narušiteľov bezpečnosti. úplne nakoniec, smutné konštatovanie je, že už sa objavili námety na stíhanie ľudí zodpovedných za tento trochu avantgardný spôsob na poukázanie bezpečnostného problému. žeby sme sa dočkali prvého precedensu? nie je to prvý podobný problém a zatiaľ sme sa nedočkali ani len začatia stíhania v podobných prípadoch aj napriek mnohým silným slovám. je celkom zrejmé, že aj v tomto prípade bude “pozametané” tak, že žiaden vyšetrovateľ nebude mať žiadne dôkazy a kde nie sú dôkazy… a kde je vlastne vina? kto je bez viny, nech hodí kameňom. bude to dodávateľ systému? prevádzkovateľ? zadávateľ projektu? realizátor bezpečnostného projektu, ak vôbec dáky existuje? alebo to budú tvorcovia jazyka php? tvorcovia frameworku horde? alebo ľudia, ktorím bolo umožnené chybu zneužiť? vina je pojem veľmi relatívny….
v každom prípade, slušný crack (nie, týchto ľudí nepovažujem v tomto kontexte za hackerov) a celkom lukratívny cieľ. nech sú logy dobre premazané na všetkých v akcii zúčastnených systémoch

Filed under:
bezpečnosť, informačné technológie by future