Odpočúvanie šifrovaných spojení

SSL (Secure Socket Layer) je navrhnutý ako protokol na zaistenie integrity a tajnosti prenášaných dát, rovnako ako aj na autentizáciu servera (prípadne klienta). Ak je implementovaný a používaný správne, tak tieto vlastnosti zaručuje. V opačnom prípade nie je problém niektoré z jeho vlastností narušiť.

Nadviazanie spojenia a výmena kľúčov

Najzraniteľnejšou časťou protokolu SSL je výmena kľúčov. Ako vyzerá nadväzovanie SSL spojenia:

• klient pošle serveru správu ClientHello, kde oznamuje podporované šifrovacie algoritmy a verzie SSL
• server odpovie správou ServerHello, oznámi svoje podporované šifrovacie algoritmy s verziami SSL a hlavne zašle svoj certifikát
• (pokračovanie protokolu momentálne pre nás nepodstatné, podrobnosti napríklad na Wikipedii)

Akonáhle klient obdrží certifikát, mal by nejakým spôsobom overiť, že naozaj patrí danému serveru. To musí spraviť buď človek alebo to spraví sám browser ak rozpozná certifikačnú autoritu (vystaviteľa certifikátu – issuer), ktorá certifikát vydala. To znamená, že browser je schopný certifikát overiť, len ak má koreňový certifikát danej certifikačnej autority a zároveň elektronický podpis certifikátu sedí.

Certifikáty a certifikačné autority

Marketingovo znejúce pojmy certifikát a certifikačná autorita znejú mnohým ľuďom komplikovane, ale ide o jednoduchú myšlienku. Certifikačná autorita vystupuje v úlohe notára, ktorá vydaním certifikátu podpísaného certifikátu hovorí: „Na svoju zodpovednosť prehlasujem, že mnou podpísaný serverový certifikát websajt.cz potvrdzuje identitu serveru websajt.cz“. Ak sa rozhodneme veriť podpisu tejto certifikačnej autority, nainštalujeme si jej koreňový certifikát do browsera. Veľa ich je štandardne predinštalovaných – napr. vo Firefoxe pozrite v Preferences menu Advanced → Manage certificates → Authorities. (V českém Firefoxu je to: Předvolby → Ostatní → Správa certifikátů → Certifikační autority. – pozn. šéfredaktora)

Psychologický element

Ak sa klient pripojí k serveru, ktorého identitu nemôže overiť, tak užívateľovi vyskočí ten známy dialóg „Unable to verify the identity of websajt.cz as a trusted site“. Neprezradím zrejme žiadne tajomstvo, ak poviem, že viac než 99 % užívateľov (a nielen bežných Frantov!) dá OK bez rozmýšľania.

Nádherná ilustrácia: v máji 2005 sa jedna novozélandská banka omeškala (11 hodín) s nainštalovaním nového certifikátu. Za ten čas sa k elektronickému bankovníctvu pripojilo 300 klientov. Len jeden jediný z nich odmietol certifikát. Mohli by sme si síce myslieť, že užívatelia si všimli, že certifikát vypršal len nedávno, a tak zhodnotili, že riziko je malé…ale navzdory skúsenostiam by bola dosť naivita tomu veriť.

Nielen užívatelia, ale aj správci serverov …

Nie je vôbec ojedinelé naraziť na server, ktorý má „self-signed“certifikát. Self-signed certifikát znamená, že vystaviteľ (issuer) je rovnaký ako príjemca (issued-to). Jediná možnosť overiť taký certifikát je, keď administrátor serveru zverejní na hash (fingerprint) toho certifikátu, najlepšie na fyzicky inom serveri. Toto robia napríklad certifikačné autority – pretože ich certifikáty nikto nepodpísal, nemajú inú možnosť (ale certifikačné autority dávajú koreňové certifikáty na stiahnutie, nikdy ich nepoužívajú na identifikáciu serveru, len na overenie podpisu).

Inak si akurát môžme povedať „s najväčšou pravdepodobnosťou práve teraz na mňa nikto neútočí, tak certifikát prijmem, uložím si ho a budem sledovať, či sa nezmenil“. No z bezpečnostného hľadiska je to skôr z núdze ctnosť.

Druhá skupina problematických certifikátov sú „takmer self-signed certifikáty“. Je to názov, čo som si práve vymyslel, a znamená: websajt.cz si vygeneruje svoj koreňový certifikát certifikačnej autority, nazve si ju trebárs „websajt.cz CA“ a podpíše ňou serverový certifikát serveru websajt.cz. Koreňový certifikát ale pre istotu nikde nezverejní (prípadne na mieste, kde nie je v ľudských silách sa doklikať alebo dopátrať vyhľadávačmi). Efektivita rovnaká ako pri self-signed certifikátoch, tj. overiť ich môžem akurát tak, že si hodím kockou.

Takéto neoveriteľné certifikáty vznikajú väčšinou z nevedomosti – netušia, aké ľahké môže byť ich obísť. Na druhej strane, nie každý má dôvod platiť za komerčný certifikát, ale dá sa to riešiť aj inteligentne.

Dosť bolo omáčok…ako teda útok funguje?

Jedna z možností je využiť iptables a stunnel. Iptables asi netreba dvakrát predstavovať, je to štandardný nástroj na filtrovanie paketov (firewall) a rôznu manipuláciu s paketmi (routovanie, NAT). Stunnel je nástroj na pridávanie podpory SSL v k aplikáciám, ktoré SSL natívne nepodporujú (napr. vytvorenie pop3s démona z pop3 démona).

Prvý krok spočíva v presmerovaní paketov – na routeri používajúcom iptables stačí pridať do reťazca PREROUTING v tabuľke nat pravidlo, ktoré zmení cieľ z pôvodného ciel.cz (IP 10.20.30.40 v našom príklade) na localhost.

Útočník ďalej spustí dvakrát stunnel, raz ako server prijímajúci SSL spojenia (predkladá falošný certifikát) a druhý krát v klientskom móde, ktorý čaká na prichádzajúce spojenie, ktoré „obalí“ do SSL a nasmeruje na skutočný server. Na obrázku dole beží serverový stunnel na localhost:1234 a presmerováva ich na localhost:2345, kde beží stunnel v klientskom móde.

Pakety od obete namiesto na pôvodné určenie (ciel.cz) prídu na načúvajúci stunnel na routeri. Ten mu pošle falošný certifikát. Ak ho obeť odsúhlasí, spojenie pokračuje a router ho môže rozšifrovať, pretože pozná kľúč.

Všetky prenášané dáta sa dajú monitorovať nástrojmi ako napr. tcpdump, snort nebo ethereal. Prípadne medzi dvomi tunelmi môže byť program, ktorý bude monitorovať/meniť len určité pakety.

Dá sa samozrejme druhý koniec tunela namiesto na https://ciel.cz vyviesť na úplne ľubovolné miesto v Internete a obeť to nemá šancu poznať.

A čo útočníci mimo routeru?

Tí tiež nie sú až takí bezradní. Existuje mnoho techník, ako počítač obete „presvedčiť“, nech posiela pakety útočníkovi namiesto routeru/skutočného serveru. V rámci lokálnej siete je možné použiť napr. ARP poisoning, ICMP redirect útok, STP spoofing. Ak útočník nie je nikde po ceste paketov k cieľu, je možný DNS cache poisoning, prípadne nejako použiť na obeť sociálne inžinerstvo a presvedčiť obeť, aby použila nejaký útočníkom ovládaný proxy server. Útočníci si medze nekladú.

„Falošné pravé“ certifikáty

Existuje ale aj možnosť, že certifikačná autorita vydá certifikát nepravému vlastníkovi. Je to skôr zriedkavosť, ale už sa to stalo – nejaký „vtipálek“ sa vydával za zamestnanca Microsoftu a získal pár certifikátov od VeriSignu. Tieto certifikáty boli vystavené za účelom podpisovania kódu, takže bolo nimi možné podpisovať vírusy alebo iný škodlivý kód. Ťažko povedať, či to niekto naozaj zneužil, alebo si len chcel posilniť ego.

Asi je jasné, že je takáto situácia predstavuje ľudovo povedané „značný průs …“ – je takmer nemožné sa brániť. Človek sa môže rozhodnúť nedôverovať VeriSignu, ale neviem, či tým viac získa než stratí. Našťastie je to dosť ojedinelé.

Záverom

Podobne sa dajú napadnúť všetky šifrovacie protokoly, ktoré sú iniciované výmenou kľúčov – SSH, rôzne vrstvy šifrovania nad ICQ, atď.

Neočakávam zatiaľ, že by podobný typ útokov bol nejak veľmi rozšírený, počítačové podsvetie momentálne používa jednoduchšie prostriedky – načo napadať router, keď môžu napadnúť rovno cieľové počítače. Ale ich techniky sa takisto vyvíjajú – po zlepšení bezpečnosti browserov sa začali zaujímať o diery v antivírovom softwari. Kým pred rokom-dvoma bola väčšina vírov „manuálnych“ (tj. človek si ich musel sám kliknúť a spustiť, občas dokonca najprv rozpakovať), dnes si už dajú crackeri námahu s DNS poisoningom, ktorý presmeruje obete na stránky, ktoré im nainštalujú 18 (!) MB spyware všetkých odrôd a chutí potichu cez nezaplátované diery v browseroch.