Jedním ze základních stavebních kamenů internetu je protokol BGP. Ten slouží sítím k předávání informací o propojích a zároveň obsluhovaných IP adresách. Každý router připojený do „nejvyššího patra“ internetu se pomocí něj dozvídá více než 700 000 záznamů (prefixů) o tom, kterým směrem a jak daleko nějaká síť je a jaké adresy k ní patří.
Různých cest může být mnoho: přímé propoje, mezinárodní tranzitní operátoři nebo třeba peeringová centra. Router tedy dostane všechny informace najednou a je pak schopen rozhodovat o tom, kam poslat pakety s danou cílovou adresou. Tyto informace samozřejmě nejsou tajné, můžete si je prohlížet například pomocí služby RIPEstat nebo pomocí BGP Toolkit od Hurricane Electric.
Únik IP adres
Občas se ovšem stává, že dojde k takzvanému BGP leaku (úniku). Tedy k situaci, kdy někdo ze své sítě ohlašuje IP adresy, které takto ohlašovat nemá. Pokud například tranzitní operátor ohlašuje svým zákazníkům adresy jiného svého zákazníka, je to obvykle v pořádku a obě strany si mohou ověřit, že mají takové chování povolené.
K chybám obvykle dochází kvůli chybě konfigurace, kdy router omylem posílá dál rozsahy, které by neměl nebo třeba zveřejní IP adresy, které by měly být používány jen uvnitř sítě a on je začne propagovat okolním sítím. Takové chyby jsou lokálního rázu a šíří se jen v části sítě. Routery musí navíc vámi ohlašovaný prefix přijmout a použít ho namísto toho původního. Jednoduše, musíte být pro ně zajímavější.
Toho se dosáhne jedním ze dvou způsobů: buď pošlete delší (a specifičtější) prefix nebo pošlete stejný, ale cesta (počet routerů) k vám bude kratší. V obou případech budete pro cílový router lákavější destinací, protože délka prefixu a cesty jsou metriky, podle kterých se router rozhoduje o směrování komunikace.
Toho je možné samozřejmě úmyslně zneužít a odklonit část provozu do své sítě. Buď proto, že chcete poslouchat nebo prostě spustíte vlastní verzi služby a budete odbavovat uživatele u sebe. Zásadní je, že uživatel si toho nemá jak všimnout, protože na jeho straně vše funguje normálně.
Krademe kryptoměny
Cloudflare zveřejnil detaily včerejšího útoku, který byl proveden právě takto. Včera kolem poledne se v globální BGP tabulce objevily následující záznamy:
BGP4MP|04/24/18 11:05:42|A|205.251.199.0/24|10297 BGP4MP|04/24/18 11:05:42|A|205.251.197.0/24|10297 BGP4MP|04/24/18 11:05:42|A|205.251.195.0/24|10297 BGP4MP|04/24/18 11:05:42|A|205.251.193.0/24|10297 BGP4MP|04/24/18 11:05:42|A|205.251.192.0/24|10297 ... BGP4MP|04/24/18 11:05:54|A|205.251.197.0/24|4826,6939,10297
Ty reprezentují specifičtější variantu následujících rozsahů IP adres:
- 205.251.192.0/23
- 205.251.194.0/23
- 205.251.196.0/23
- 205.251.198.0/23
Tyto adresy jsou přiděleny Amazonu (AS16509), ale najednou je začal ohlašovat eNet Inc (AS10297) a přes jeho sousední sítě byla informace předána k Hurricane Electric (AS6939). Amazon tyto adresy používá pro DNS servery služby Route53.
Podvržené DNS servery, na které byl takto dvě hodiny směrován provoz, odpovídaly na všechny dotazy SERVFAIL. S výjimkou domény myetherwallet.com, pro kterou vracely funkční IP adresu phishingového serveru. Zbytek je phishing na steroidech: uživatel se připojuje na správnou doménu, systém DNS mu vrátí správnou IP adresu, ale ozve se podvodný server.
Podařilo se
Útok se opravdu podařilo dotáhnout do konce, podle informací společnost Chainalysis se během dvou hodin podařilo ukrást v přepočtu něco přes tři miliony korun. Byly totiž napadeny autoritativní servery dané domény, takže se falešnou informací nakazily všechny DNS resolvery, které se na informace o doméně zeptaly. Včetně přibližně pětiny Google DNS a včetně některých resolverů od Cloudflare.
BGP hijack this morning affected Amazon DNS. eNet (AS10297) of Columbus, OH announced the following more-specifics of Amazon routes from 11:05 to 13:03 UTC today:
— InternetIntelligence (@InternetIntel) April 24, 2018
205.251.192.0/24
205.251.193.0/24
205.251.195.0/24
205.251.197.0/24
205.251.199.0/24
Ovlivněné DNS rekurzory vracely IP adresu serveru u ruského poskytovatele (AS48693 a AS41995). Vaše síť tedy nemusela být nijak přímo úpravou BGP ovlivněna, stačilo, abyste použili odkloněné autoritativní DNS servery a dostali jste se na jinou IP adresu.
Pokud jste měli tu smůlu, mohli jste předat session cookie nebo přihlašovací údaje autorovi phishingové stránky. Někteří uživatelé to evidentně udělali a stali se tak obětí krádeže.
Kdo za to může? Jako obvykle je stran více: poskytovatel připojení ohlašující špatný prefix, tranzitní operátoři nekontrolující ohlášení jiné sítě, poskytovatel akceptující nové routy, chybějící ochrany na straně legitimního serveru, poskytovatel hostingu v Rusku a uživatel, který měl ještě možnost problém objevit při zobrazení nedůvěryhodného certifikátu.
Obrana existuje
Tady je odpověď na druhou část titulku článku. Pokud web používá HTTPS, nedokáže se za něj nikdo vydávat, pokud nemá privátní klíče. Ty autor phishingového webu samozřejmě neměl, takže se jeho server prokazoval nedůvěryhodným self-signed certifikátem. Uživatel tedy ještě musel udělat jednu nezodpovědnou věc: odsouhlasit neznámý certifikát a explicitně ho prohlásit za správný. V tu chvíli bylo spojení sice šifrované, ale pomocí klíčů patřících útočníkovi.
Možná vás napadá, že by si útočník mohl nechat vystavit DV certifikát (třeba od Let's Encrypt), když už ovládá DNS. Musel by ovšem ovlivnit všechny rekurzivní servery dané autority, čemuž se obvykle brání tím, že se autorita dotazuje z několika velmi geograficky i síťově vzdálených míst. Pokud se odpovědi neshodují, odmítne certifikát vystavit.
Pokud tedy uživatel důsledně dbal na bezpečnost a odmítl divně se chovající web navštívit, nebezpečí mu nehrozilo. Ne každý se tak ale zachoval, ti nezodpovědní předali klíče ke své peněžence do cizích rukou. Kdyby server používal hlavičku HSTS (a takto citlivý server by měl), nedovolil by prohlížeč uživateli na web vůbec vstoupit. Hlavička totiž prohlížeči vysvětlí, že na této doméně musí být za všech okolností důvěryhodný certifikát. Pokud tam není, konverzace se nekoná.
Stejně tak by byl dobrou ochranou proti tomuto útoku DNSSEC, protože záznamy na autoritativním serveru pak musejí být podepsány správným privátním klíčem. Pokud útočník odkloní provoz na síťové úrovni, nedokáže vytvořit validní DNS záznamy, protože mu opět chybí privátní klíče právoplatného provozovatele.
ČLÁNKY DO MAILU