14/07/2019
https://www.root.cz/clanky/chyba-v-implementaci-dnssec-v-big-ip-load-balancerech-od-f5/?ic=gallery-last-slide-articles&icc=chyba-v-implementaci-dnssec-v-big-ip-load-balancerech-od-f5
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á.
Laboratořím CZ.NIC se podařilo odhalit DoS DNS Ú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.
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:
Ú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. C 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.
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…
