Při vývoji DNS resolveru Knot Resolver se Laboratořím CZ.NIC podařilo odhalit bezpečnostní chybu, která umožňuje obejít zabezpečení DNSSEC na load-balancerech výrobce F5 a způsobit tak nedostupnost služby. Tyto výrobky jsou nasazeny například na některých internetových bankovních aplikacích i českých bank a úřadů. Z pohledu uživatele se úspěšný útok pomocí této chyby projeví např. tak, že prohlížeč při práci s internetovým bankovnictvím náhle zahlásí chybu „adresu nelze nalézt“ a služba přestane být dostupná.
Výrobce byl o chybě informován již v srpnu 2018 a nyní vydal doporučenou konfiguraci k obejití problému. Protože operátoři DNS resolverů na chybu již naráží i v běžném provozu, publikujeme podrobný popis chyby, abychom informovali odbornou veřejnost a zvýšili povědomí o tomto problému.
Podstatou chyby, kterou jsme objevili při testování nové verze Knot Resolveru, byl technický detail skrytý v softwaru dodavatelské společnosti F5, který obsahuje chybnou implementaci technologie DNSSEC.
V první části tohoto článku je popsána samotná chyba a její důsledky, v druhé potom způsob jejího zneužití a poučení na závěr.
To hlavní zní: Pokud používáte load-balancer F5, požadujte od výrobce co nejdříve opravu pro chybu označenou jako Bugzilla ID 744937. Než bude oprava dostupná, použijte postup popsaný v článku výrobce.
Kde je chyba?
Celý příběh by se dal zkrátit do věty „příčinou chyby je nedodržení technického standardu RFC5155 sekce 3.1.8„, nejspíš jako důsledek snahy o zjednodušení si práce při implementaci.
Aby čtenáři mohli docenit celý princip chyby a její důsledky, ilustrujeme si chybu na příkladu, kde se uživatel snaží připojit na webový server se jménem „www.example.com.“, na němž je nasazen load-balancer. Jako první krok pro připojení musí webový prohlížeč přeložit doménové jméno „www.example.com.“ na IPv4 nebo IPv6 adresu. Překlad prohlížeč provede tak, že najednou odešle dva dotazy na DNS resolver:
- www.example.com. AAAA (záznam pro IPv6 adresu; dejme tomu, že tato adresa neexistuje)
- www.example.com. A (záznam pro IPv4 adresu; tato adresa v našem příkladu existuje)
Pořadí, v jakém budou dotazy obslouženy DNS resolverem, je v podstatě náhodné. V následujícím příkladu popisujeme situaci, kdy resolver zpracovává jako první dotaz na IPv6 adresu (typ DNS záznamu AAAA). Levý sloupec popisuje chování korektní implementace, pravý sloupec ukazuje chybu ještě nedávno přítomnou v load-balancerech F5:
| Správná implementace | Chyba v implementaci F5 | |
| 1. | Webový prohlížeč odešle DNS resolver dotaz na www.example.com. AAAA (typ záznamu AAAA je IPv6 adresa). | – stejné – |
| 2. | DNS resolver v cache nemá odpověď, protože uživatel danou stránku otevírá poprvé, takže se DNS resolver zeptá autoritativního serveru skrytého za load-balancerem. | – stejné – |
| 3. | Protože v našem hypotetickém příkladu existuje pouze IPv4 adresa (typ A) a neexistuje IPv6 adresa (typ AAAA), load-balancer musí zpět poslat „DNSSEC důkaz neexistence“. | – stejné – |
| 4. | Load-balancer pošle zpět odpověď obsahující správný důkaz neexistence pro záznam www.example.com. AAAA: | Load-balancer pošle zpět odpověď obsahující nesprávný důkaz neexistence pro záznam www.example.com. AAAA: |
| MIFDNDT3NFF3OD.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OE A Na konci důkazu je seznam typů záznamů, které na jméně www.example.com existují: V našem případě jsou to pouze záznamy typu A (IPv4 adresa). Důkaz je tedy správný a DNS resolver dostává signál: AAAA tu není, máme jenom A. |
MIFDNDT3NFF3OD.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OD TXT Úplně na konci důkazu je nekorektní část, která říká, že jméno www.example.com obsahuje pouze záznamy typu TXT. To zároveň znamená, že dotaz na typ A nemá smysl – z uvedeného důkazu by totiž DNS resolver získal chybnou informaci, že neexistuje. |
|
| 5. | Resolver si uloží důkaz neexistence do vyrovnávací paměti (cache). | – stejné – |
| 6. | Nyní resolver stejným způsobem zpracovává dotaz www.example.com. A (IPv4 adresa). | – stejné – |
| 7. | DNS resolver z předchozí odpovědi už ví, že A existuje, ale zatím neznal jeho hodnotu. Jinými slovy, v cache má důkaz, že existuje záznam www.example.com. A, který dosud není v cache, takže se zeptá autoritativního serveru. | DNS resolver v cache má chybný důkaz, že neexistuje záznam www.example.com. A. |
| 8. | Resolver přijme A záznam od autoritativního serveru, zvaliduje DNSSEC podpis a odešle záznam webovému prohlížeči. | Na základě chybné informace získané v kroku 4 resolver ihned odpoví webovému prohlížeči, že záznam s IPv4 adresou neexistuje. |
| 9. | Webový prohlížeč má IPv4 adresu a může se připojit na web. | Webový prohlížeč nemá žádnou IP adresu a nemůže se připojit na web. |
Útok odepření služby
Chybu ilustrovanou výše může útočník zneužít k útoku typu odepření služby (DoS), a to dokonce dvěma způsoby:
- Prostým posláním dotazu na DNS resolver s podporou agresivní cache. Útočníkovi se stačí zeptat na cílové jméno a libovolný neexistující typ. Jediným dotazem tak způsobí nedostupnost konkrétní domény a s ní spojené služby pro všechny uživatele daného DNS resolveru, typicky např. všechny zákazníky daného poskytovatele připojení k Internetu.
- V případech, kdy útočník nemůže poslat dotaz na resolver, nebo daný resolver nepodporuje agresivní cache, lze použít dlouho známou techniku podvržení DNS odpovědi. V tomto případě je útok proveden ve dvou fázích, přípravné a útočné, které popisujeme níže:
Příprava na podvržení odpovědi
- Útočník pošle zranitelnému load-balanceru dotaz na cílovou doménu a neexistující typ, např.
www.example.com. AAAA (nebo kterýkoliv jiný neexistující typ, např. HINFO) - Zranitelný load-balancer odpoví důkazem neexistence, který stejně jako v předchozím příkladě obsahuje nekorektní informaci, ale je validně podepsán podepisovacím klíčem domény:
MIFDNDT3NFF3OD53O7TLA1HRFF95JKUK.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OD53O7TLA1HRFF95JKUL TXT - Útočník si uloží nekorektní důkaz neexistence pro pozdější použití.
Útok podvržením odpovědi
- Oběť se zeptá na cílovou doménu a existující typ, např.
www.example.com. A - Útočník podvrhne dříve získanou odpověď místo „pravé“ odpovědi od load-balanceru.
- Podvržený důkaz neexistence zdánlivě splňuje všechny požadavky DNSSEC standardu a dokazuje, že typ A neexistuje, a je proto uložen do cache resolveru.
- Resolver na základě podvrženého důkazu neexistence odpoví oběti, že požadovaný záznam neexistuje.
- Oběť se nemůže na cílový web připojit.
Jak jsme chybu odhalili?
V Laboratořích CZ.NIC se zabýváme vývojem vlastního DNS resolveru a chceme, aby patřil mezi nejefektivnější na trhu. Proto jsme vloni náš software rozšířili o podporu tzv. „agresivní cache s podporou NSEC3“, kterou doposud nemá žádný „konkurenční“ software. Jedná se o novou techniku popsanou ve standardu RFC 8198, která umožňuje DNS resolveru používat všechny informace zabezpečené DNSSEC a odpovídat na některé dotazy přímo z cache resolveru (viz kroky 7 a 8 výše, v odstavci „Kde je chyba“). Když jsme toto rozšíření nasazovali, setkali jsme se s tím, že uživatelé sice získali zefektivnění odpovídání na DNS dotazy, ale zároveň si někteří z nich stěžovali na nevysvětlitelné potíže s připojením na weby některých bank a státních úřadů, a co je nejhorší, „problém sám po chvíli zmizel“, což velmi ztěžovalo analýzu.
Podrobně jsme analyzovali problematické dotazy a odhalili, že problém není v naší implementaci standardu, ale je na straně autoritativního serveru (přesněji load-balanceru) a že se projeví, jen když se dotazy sejdou „v nešťastném pořadí“. Problém pak trvá do vypršení platnosti záznamů v cache DNS resolveru. Chybu jsme nahlásili výrobci a čekali na opravu. Výrobce F5 původně žádný termín opravy nesliboval, ale když jsme podrobně popsali potenciál ke zneužití, tak během několika měsíců publikoval návod, jak chybu obejít změnou konfigurace.
Závěrem
Snad se nám podařilo ilustrovat, jak nebezpečné je používat při implementaci „zkratky“, které jsou v rozporu se standardem. Každá taková nestandardní zkratka sebou nese riziko zavlečení bezpečnostních chyb.
V tomto případě paradoxně byly postiženy systémy institucí, které uživatelé považují za nejbezpečnější a které aktivně investují do „obrany“ pomocí řešení od externího dodavatele. Inu, i subdodavatelé se musí držet technických standardů.
Pokud se chcete o technologii DNSSEC dozvědět víc, zveme vás na kurz v Akademii CZ.NIC.
Agresivní cache dle RFC 8198 implementoval Bind 9.12 vydaný již 23. ledna 2018. Knot resolver 2.0.0 implementující tuto funkcionalitu byl vydaný až 31. ledna.
Není tedy pravdou tvrzení, že by žádný jiný „konkurenční“ software tuto funkcionalitu neměl. ISC bylo o něco rychlejší.
Tohle jsou správné termíny pro NSEC. Potíž popsanou v tomto článku jsme zaznamenali jen s NSEC3, kde se agresivní cache implementovala později, v případě Knot Resolveru vydáno 3. července 2018 (tam byl myslím první, ale přesně nesleduji).
Ještě by to chtělo naučit se psát stejným způsobem i o vlastních chybách. A že jich Knot resolver také má spoustu! Je jednoduché psát o chybách druhých. A u toho se tvářit, jak naše výtvory jsou bez chyb. Rozhodně nejsou. Například DoH je aktuálně v takovém rozvalu, že je prakticky nepoužitelné. Proč? Protože kdosi něco tak úplně nedomyslel. V principu stejný problém jako u té F5. A zatímco o chybách druhých se píší sáhodlouhé články, o vlastních chybách se příliš nahlas hovořit nechce.