Megint meghekkelték az internetet!

Az utóbbi időben rendszeresen bukkannak fel szenzációhajhász hírek az elektronikus sajtóban arra vonatkozóan, hogy „feltörték az internetet”. A híradások nagy része elnagyoltan foglalkozik a konkrét okokkal, a konkrét sebezhetőséggel, sokkal inkább a hatásokra koncentrál: „A legtitkosabb adatokhoz - tehát például gmail, PayPal és Facebook információkhoz is - az SSL encryption nevű védőrendszer feltörésével tudnak könnyedén hozzáférni az adattolvajok.”, „már az SSL-lel védett weboldalakon sincsenek biztonságban az információk”.

A valóság a hírekkel szemben az, hogy a Black Hat konferencián múlt héten bemutatott sebezhetőség nem rengeti meg alapjaiban az SSL-lel, és az X509-es tanúsítványokkal kapcsolatos eddigi képünket. Való igaz, hogy a sebezhetőség súlyos, és a rengeteg, SSL-t implementáló szoftverben megtalálható, azonban ezek az SSL-re és az X509-es tanúsítványok kezelésére vonatkozó RFC hanyag implementációjából, illetve a böngészők és weboldalak felhasználónak adott jelzéseiből fakadnak.

Miben áll a technikai sebezhetőség?

Amikor valamilyen SSL-t megkövetelő szolgáltatáshoz csatlakozik egy kliens, lehetősége van arra, hogy a konkrét adatforgalom megkezdése és a titkosított SSL csatorna felépítése előtt tanúsítványok segítségével meggyőződjön arról, hogy a kommunikációban részt vevő másik fél az, akinek mondja magát.

Az algoritmus, amit a kliens követ, meglepően egyszerű:

1. Nézd meg, hogy a kapott tanúsítvány annak a nevére szól-e, akitől kaptad.
2. Nézd meg, a kapott tanúsítvány lejárt-e.
3. Nézd meg, hogy a tanúsítványt aláíró hatóság (Certificate Authority, CA) ismeretes-e előtted. Ha igen, fogadd el a tanúsítványt és építsd fel a csatornát, majd forgalmazz.
4. Ha nem ismered a tanúsítványt aláíró CA-t, nézd meg az aláíró CA tanúsítványának érvényességét a fenti algoritmussal.

Az algoritmus háromféleképp végződhet.

1. Minden tanúsítvány megfelelő és találunk benne egy CA-t, amelyet elfogadunk hitelesnek (Pl. a Microsoft, a VeriSign, vagy akár a NetLock). Az egész láncot elfogadjuk hitelesnek, és továbblépünk.
2. Valamelyik tanúsítványban hibát találunk. Ekkor jelezzük a felhasználónak, hogy mi a hiba, és megkérdezzük, hogy mi legyen: kommunikáljunk, vagy ne.
3. Minden tanúsítvány megfelelő, viszont elérünk egy olyan CA-hoz, amelynek nincs „felettes” CA-ja (pl. úgy, hogy saját maga írta alá a tanúsítványát). Ez esetben megkérdezzük a felhasználótól, hogy mi legyen.

A tanúsítványok lánca elég hosszú lehet, az SSL implementációjától függ, hogy milyen hosszút tud kezelni. Ha például a böngészőnknek az alábbi tanúsítványláncot adja egy oldal (legyen ez mondjuk a Gigabank netbank alkalmazása), akkor először megnézi a netbank.gigabank.hu tanúsítványát: ezt rendben találja (1. és 2. pont), viszont a Gigabank írta alá a tanúsítványt, így a Gigabank tanúsítványának ellenőrzése következik. Ezt a NetLock írta alá, a NetLock pedig elfogadja hitelesnek a böngészőnk (hiszen bele van égetve, mint hiteles tanúsítványszolgáltató), így megnyugtató kis lakat jelenik meg a böngésző címsorában, megkezdődhet a tényleges adatforgalom. (Az ábrákon zöld háttérrel jelöljük a legitim, pirossal az illegitim tanúsítványokat, a nyilakon pedig a tanúsítvány el (nem) fogadását jelöljük.)

Miért jó ez? Ha a támadó közbeékelődést hajt végre (pl. ARP spoofinggal, vagy egyéb technikával), nem tudja hitelesen megszemélyesíteni a Gigabankot, ugyanis nem fogja tudni aláírni a Gigabank titkos kulcsa nélkül a kliensnek adandó tanúsítványt, a kliens pedig (hibás tanúsítványt kapott) a felhasználótól kérdezi meg, hogy mi legyen. Természetesen a támadó behazudhatja az általa adott tanúsítvánnyal kapcsolatban, hogy a Gigabank adta ki, de ez esetben sem lesz megfelelő az aláírás.

Figyelem, most jön a csavar.

Mi történik akkor, ha a támadónak van egy, a VeriSign által aláírt, hiteles tanúsítványa a Bela Kft. nevére és a saját tanúsítványával hitelesíti az általa generált (hamis) tanúsítványt, amivel az áldozat böngészője számára megszemélyesíti a netbank.gigabank.hu-t?

A hitelesítési algoritmus lefut, a netbank.gigabank.hu tanúsítványát igazolja a Bela Kft., a Bela Kft.-ét pedig a VeriSign. A böngészőnk elfogadja hitelesnek a kapott tanúsítványt.

De hát miért nem gondoltak erre a támadásra a tanúsítványkiadó rendszer kitalálói?

De igen, gondoltak rá. A tanúsítványokban található egy mező, amellyel azt jelölik, hogy használható-e további tanúsítványok aláírására: ez a mező a „Basic Constraints – CA:TRUE/FALSE” mező. Olyan visszakövethető tanúsítványa, amellyel továbbiakat lehet aláírni, csak a tanúsítványkiadóknak lehet, az általuk kiadott tanúsítványokon kellene szerepelnie a CA:FALSE mezőnek, és minden, SSL-t implementáló kliensnek hibát kell(ene) jeleznie, ha CA:FALSE mezős tanúsítvánnyal írtak alá továbbiakat.

Amennyiben használják és jól használják ezt a mezőt, kétféle tanúsítvány lehet forgalomban:

1. Root CA-ig visszakövethető, viszont további tanúsítványok generálására alkalmatlan.
2. További tanúsítványok generálására alkalmas, viszont nem követhető vissza megbízható Root CA-ig.
   

A gyakorlatban azonban mindkét oldalról hibázik a dolog, ugyanis egyrészről sok CA nem teszi bele explicit módon a tanúsítványaiba a mezőt, másrészről az SSL implementációi sem ellenőrzik a mező meglétét. A két hiba bármelyikének fennállásakor előállhat a harmadik ábrán látható helyzet, mely szerint a böngészőnk hitelesnek fogad el el illegitim tanúsítványt.

Mit lehet tenni a fenti helyzet megoldására? Sajnos az a helyzet, hogy a végfelhasználó nem tud sok mindent tenni: a böngészők fejlesztőin a sor, hogy javítást adjanak a fenti helyzetre.

Betörés a Facebook segítségével

Az IT-biztonság üzlet, mégpedig nem is kicsi. Rengeteg pénzt és erőforrást költenek mindenféle tűzfalrendszerekre, többutas authentikációs eljárásokra, IDS és IPS rendszerekre – viszont gyakran elkövetik azt a hibát, hogy a számításokból kihagyják az emberi tényezőt. Ennek illusztrálására álljon itt egy friss, nagyon tanulságos történet egy biztonsági levelezőlistáról. A történet eredetije itt olvasható.

Tesztelési csapatunk néhány éve kezdett el internet alapú social networking eszközöket használni a megbízó IT rendszereibe történő betöréshez. Az ilyen oldalakat a [social networking] koncepció megszületése óta használják támadási vektorként, azonban a média csak mostanában kezd foglalkozni a témával: emiatt döntöttünk úgy, hogy bemutatjuk a Facebook használatát hackerszemszögből.

(…)

Emberként hajlunk arra, hogy bízzunk egymásban. Ha kapunk „valamit” a másikról, a bizalmi viszony többnyire kialakul. Ez a „valami” többnyire adott, ha szemtől szembe találkozunk az illetővel, de sokszor ez sem szükséges. A munkáink során célba vett személyek 90%-a megbízott bennünk, mivel úgy gondolták, hogy ugyanannak a cégnek dolgozunk, munkatársak vagyunk, holott egyszer sem találkoztunk személyesen.

A Facebook (az iwiw is – a ford.) lehetőséget biztosít arra, hogy kulcsszavak alapján keressünk személyeket. Sok felhasználó kiírja a profiljában a munkahelyét, sőt több cég munkatársai külön csoportot, klubot alapítottak maguknak – emiatt az első lépés az, hogy felderítést hajtunk végre a Facebookot használó alkalmazottak keresésére. Ez a legegyszerűbben magával a Facebook felülettel hajtható végre, de remek külső eszközök is használhatóak (Maltego, pipl.com). A felderítés katonai eredetű kifejezés, olyan tevékenységet értünk alatta, amely támadás előtti információszerzésre irányul. Jelen esetben a felderítés emberi (alkalmazottak) és technológiai (tűzfalak, szerverek, routerek stb.) célpontok ellen is irányul: rendszerint mindkét tevékenységet elvégezzük.

Az ideális támadás véghezviteléhez két dolog hasznos, azonban ezek közül csak egy szükséges. A hasznos fél egy Cross-site script sebezhetőség a célpont valamely webszerverén, a szükséges pedig egy Facebook profil.

Egy munkánk során 1402 alkalmazottat találtunk, ezek közül 906 használta a facebookot. Nem néztük végig mind a 906-ot, csak 200 körüli mennyiségűt, de ezek alapján fel tudtuk építeni hamis alkalmazotti profilunkat.

A technikai felderítés több XSS sebezhetőséget is felszínre hozott, ezek egyike a megbízó központi webszerverén volt megtalálható. (…) Az XSS támadás kihasználásával lehetőségünk nyílt arra, hogy felépítsünk egy, a céges portál bejelentkező felületével megegyező kinézetű weboldalt. Amikor az áldozat rákattint a speciálisan kialakított linkre, a hamis weboldal jelenik meg: az oldalon figyelmeztető üzenetet jelenítettünk meg, hogy a felhasználónevek és jelszavak kompromittálódtak, emiatt újbóli megadásuk szükséges a mellékelt űrlapon. Amikor a felhasználók beütötték az azonosítási adatikat, egy, a (…) webszerveren felállított, automatizált eszköz kapta meg és mentette el az elküldött adatokat.

Klasszikus client based phishing technikát alkalmaztak a kollégák. Az említett sebezhetőség abból adódik, hogy az érintett weboldal nem validálja kellőképp a felhasználó felől érkező inputokat. Tankönyvi példája az XSS-sel sebezhető kódnak az alábbi php függvény:

test.php:
< ?php
echo"Kapott parameter:";
$foo=$_GET["bar"];
echo $foo;
? >

Ha ugyanis az alábbi módon hívja meg a test.php-t: test.php?bar=< script> alert ("XSS")< /script>, akkor a linkre kattintó felhasználó egy felugró ablakot kap. Ilyen módon tetszőleges javascriptes kódot le lehet futtatni: az idézett példában a document.body.innerhtml függvény hívásával "dobták ki" az eredeti weboldalt és építették fel a hamis bejelentkező képernyőt, amely hű másolata volt az eredetinek, viszont illegitim helyre küldte el a beírt adatokat.

Az eszközök elkészítése és üzembe állítása után felépítettünk egy megbízhatónak és szimpatikusnak tűnő facebook profilt. Mivel a célpont alkalmazottainak nagy része 20 és 40 év közötti férfi, úgy döntöttünk, hogy a legcélravezetőbb egy nagyon csinos, 28 éves nő profilját felépíteni. Google segítségével kerestünk megfelelő fényképeket, és a személyes adatok megadásánál felturbóztuk a profilunkat a valódi alkalmazottak profiljaiban talált céges információk alapján.

A profil elkészültével csatlakoztunk a megbízó facebook csoportjához: nem volt nehéz feladat, ugyanis a csatlakozási igényünket néhány órán belül visszaigazolták. Húsz perccel a csatlakozás után kaptunk jónéhány „bejelölést” valódi alkalmazottaktól és a megbízó valódi ügyfelei részéről, másrészről mi is küldtünk több százat. Ismerőseink listája gyorsan nőtt, és rövidesen beletartozott több igazgató, felsővezető és még néhány beszállító is.

Több száz ismerős begyűjtése után chatelni kezdtünk a megbízó alkalmazottaival. Beszélgetéseink elsősorban munkához kapcsolódó témákról szóltak, amelyhez az információt a valódi alkalmazotti profilokból merítettük. Három nap beszélgetés és ismerkedés után elküldtük facebook profilunkra a speciálisan kialakított linket azzal a szöveggel, hogy „Feltörték a weboldalunkat és ellopták a jelszavamat! Nézd meg a linket!” Nyilvánvalóan sokan rákattintottak a linkre, és megadták személyes azonosítóikat.

Vicces, hogy az első beérkező adat pont attól a személytől jött, akitől a megbízást kaptuk. A begyűjtött adatokat webes és vpn-es szolgáltatások elérésére használtuk fel, amelyek hozzáférést adtak a megbízó belső hálózatához, az Active Directory szerverhez, a checkpoint tűzfalkonzolhoz stb. A játék itt véget ért, a jó öreg Facebook-hack megint bejött.

A tesztelés során bejártuk a megbízó teljes informatikai infrastruktúráját. (…)

A munka zárásaként bevezettünk egy olyan megoldást a megbízónál, amellyel meg tudják előzni az ilyen jellegű fenyegetéseket – implementálás után (2008 eleje) 4 ilyen támadást regisztráltak.

Webkamera

Vajon mi viszi rá egy szerverterem üzemeltetőjét, hogy beállítson és elérhetővé tegyen a neten egy webkamerát, aminek a látóterében kimondottan érdekes dolgok (is) találhatóak?

A teljesség igénye nélkül:

• Egy monitor, amin kis matricával ráragasztva megtalálható az adminjelszó
• Egy számzáras széf, aminek a billentyűzete remekül szemmel tartható, miközben valaki beüti a kódot
• Egy hatalmas rackszekrény, amelyen kis sárga matricával található minden fontosabb információ a szekrényben lévő eszközökről.

...és nem véletlenül került a tagek közé a "google".

Mi a gond?

Az első és legfontosabb probléma az, hogy a webkamera üzembe állításával az üzemeltetők kimondva-kimondatlanul felvállalják, hogy illetékteleneknek is információkat adnak a szerverteremről - egy olyan helyiségről, amelyet valószínűsíthetően számos fizikai biztonsági kontroll véd (kulcs, kártya stb.), és az ott szerezhető információk megkönnyítik a támadó dolgát.

Másodszor a szerverterem (hanyag) használati gyakorlatán szemmel láthatóan nem sokat alakítottak, amikor betették a kamerát: kis sárga post-it cetlik a monitor szélén és a rackszekrény oldalán, rendetlenség az oldalsó asztalon. Tisztán megállapíthatóak az eszközök gyártói. A rendező kapcsolási sémáját kis türelemmel bárki lerajzolhatja, és a széf is kristálytisztán látható az asztal alatt.

A kamera képeinek vizsgálatával a triviális támadásokon túl (lefigyeljük a széf kódját, megjegyezzük a cetlin mosolygó jelszavakat stb.) egészen finom social engineering támadásokra is lehetőség nyílik: profilozhatóak a rendszerüzemeltetők, ki mikor szokott bemenni a szerverterembe - a terem állapotából ítélve (pl. ég a villany, PET-palackokkal teli szemetes az asztal alatt, szék a közlekedőfolyosón, alatta kopásnyomok a szék ki-betologatásától, személyes vicik-vacakok és tollak az asztalon) az üzemeltetők sok időt töltenek ott.

A találékony támadó öltözhet úgy, mint a telefontársaság embere, amelynek a logója tisztán kivehető a modemen. Jöhet karbantartani a *** márkájú szervereket. A lehetőségek végtelenek...

How to suck at information security

Nemrég jelent meg egy nagyon tanulságos összeállítás Lenny Zeltser tollából a sans.org-on arról, hogy milyen klasszikus hibákat követünk el az informatikai biztonság témakörében. Az összeállításnak a kissé provokatív "How to suck at information security" címet adta, és határozottan érdemes végigböngészni.

Security Policy and Compliance

Ignore regulatory compliance requirements.

Assume the users will read the security policy because you've asked them to.

Use security templates without customizing them.

Jump into a full-blown adoption of frameworks such as ISO 27001/27002 before you're ready.

Create security policies you cannot enforce.

Enforce policies that are not properly approved.

Blindly follow compliance requirements without creating overall security architecture.

Create a security policy just to mark a checkbox.

Pay someone to write your security policy without any knowledge of your business or processes.

Translate policies in a multi-language environment without consistent meaning across the languages.

Make sure none of the employees finds the policies.

Assume that if the policies worked for you last year, they'll be valid for the next year.

Assume that being compliant means you're secure.

Assume that policies don't apply to executives.

Hide from the auditors.

Security Tools

Deploy a security product out of the box without tuning it.

Tune the IDS to be too noisy, or too quiet.

Buy security products without considering the maintenance and implementation costs.

Rely on anti-virus and firewall products without having additional controls.

Run regular vulnerability scans, but don’t follow through on the results.

Let your anti-virus, IDS, and other security tools run on "auto-pilot".

Employ multiple security technologies without understanding how each of them contributes.

Focus on widgets, while omitting to consider the importance of maintaining accountability.

Buy expensive product when a simple and cheap fix may address 80% of the problem.

Risk Management

Attempt to apply the same security rigor to all IT assets, regardless of their risk profiles.

Make someone responsible for managing risk, but don't give the person any power to make decisions.

Ignore the big picture while focusing on quantitative risk analysis.

Assume you don't have to worry about security, because your company is too small or insignificant.

Assume you're secure because you haven’t been compromised recently.

Be paranoid without considering the value of the asset or its exposure factor.

Classify all data assets as "top secret".

Security Practices

Don't review system, application, and security logs.

Expect end-users to forgo convenience in place of security.

Lock down the infrastructure so tightly, that getting work done becomes very difficult.

Say "no" whenever asked to approve a request.

Impose security requirements without providing the necessary tools and training.

Focus on preventative mechanisms while ignoring detective controls.

Have no DMZ for Internet-accessible servers.

Assume your patch management process is working, without checking on it.

Delete logs because they get too big to read.

Expect SSL to address all security problems with your web application.

Ban the use of external USB drives while not restricting outbound access to the Internet.

Act superior to your counterparts on the network, system admin, and development teams.

Stop learning about technologies and attacks.

Adopt hot new IT or security technologies before they have had a chance to mature.

Hire somebody just because he or she has a lot of certifications.

Don't apprise your manager of the security problems your efforts have avoided.

Don't cross-train the IT and security staff.

Password Management

Require your users to change passwords too frequently.

Expect your users to remember passwords without writing them down.

Impose overly-onerous password selection requirements.

Use the same password on systems that differ in risk exposure or data criticality.

Impose password requirements without considering the ease with which a password could be reset.

Google hacking

Melyik a leghasznosabb és legerősebb eszköz a tesztelők kezében a betörési teszt legelején?

A google.

A google-t a legtöbb esetben arra használják, hogy kulcsszavak alapján tartalmakat találjanak a segítségével az interneten, azonban ezen az „alap” működésen kívül számtalan egyéb célra is használható – akár betörési tesztelési eszközként is. Ilyen minőségében egészen kiváló választás: anonimitást biztosít, a célpont nem értesül a vizsgálatok tényéről és néha egészen, komolyan mellbevágó találatokat ad: ilyenkor a célpont hanyag beállítása két ász az asztalon, a google pedig a másik kettő a kezünkben.

Néhány meglepő példa az eddigi tapasztalatainkból:
• Banki biztonsági kamerák hanyagságból „ott felejtett”, streamelhető képei
• Jelszavak(!)
• Hibaüzenetek, közöttük néhány olyan, amely részleteket közöl az adott webalkalmazás PHP-kódjából, illetve a működtető SQL query-kből
• E-mail címek
• Belsős anyagok, telis-tele érzékeny információval, levelezés
• Korábbi biztonsági auditok jegyzőkönyvei
• Triviális módon kompromittálható hosztok listája (egy specifikus funkciójú oldal keresésével – többet nem írunk…)
• Személyes adatok (név, bankszámlaszám, lakcím stb.)

A google hackinggel kapcsolatban több munka is megjelent a közelmúltban: ott van elsőként a téma első komoly művelőjeként Johnny Long tollából két könyv (Amazonon itt és itt lehet megrendelni őket), másrészt on-line formában is elérhető Google Hacking Database.

A GHDB ezernél is több keresősztringet listáz, ezeket azonban szerencsére nem kell egyesével, kézzel végigkeresni: több céleszköz is rendelkezésre áll. Ezek közül betörési tesztek során leginkább a Wikto-t szoktuk használni, de számtalan egyéb eszköz is használható.

Mit lehet tenni a “google dork”-ká válás megelőzésére? Körültekintően kell eljárni a nyilvánosan elérhető webhelyek tartalmának összeállításakor, az alkalmazott jogosultságkezelési eszköz megválasztásakor (például jó gyakorlatként kerülendő a .htaccess és a public_html könyvtár együttes használata) és rendszeresen ellenőrizni kell, hogy a google mit talált meg és mentett el.