Bezpečnostní chyba v DNS, upgrade doporučen

25.07.2008 14:52

V souvislosti s bezpečnostní chybou v DNS, uveřejněnou již dříve pod číslem VU#800113 americkým CERT, se objevil na internetu exploit, který tuto chybu zneužívá. Důrazně je doporučován upgrade DNS software!

Následuje český překlad oznámení VU#800113 (originální text oznámení v angličtině najdete na stránkách US CERT).

Oznámení Vulnerability Note VU#800113
Mnohé implementace DNS jsou ohroženy útoky typu cache poisoning

Přehled
Nedostatky DNS protokolu a jeho běžných implementací umožňují útoky typu DNS cache poisoning.

Popis
Domain Name System (DNS) je odpovědný za překlad hostitelských jmen na IP adresy a naopak a je kritickým prvkem,
potřebným pro normální fungování Internetových systémů. DNS cache poisoning (nebo také cache pollution) je technika
útoku, která útočníkům dovoluje umístit falešnou DNS informaci do cache (mezipaměti) caching nameserveru. DNS cache
poisoning není nový koncept, byla publikována řada článků o nedostatcích DNS protokolu a běžných DNS implementací,
které DNS cache poisoning umožňují. Příklady takových nedostatků a chyb jsou tyto:

Nedostatečný transaction ID prostor
Specifikace DNS protokolu obsahuje i pole transaction ID o délce 16 bitů. Pokud je specifikace implementována správně
a transaction ID je náhodně vybráno robustním generátorem náhodných čísel, bude útočník potřebovat v průměru 32 768
pokusů, aby ID mohl předpovědět. Některé nekvalitní implementace mohou pro toto pole používat menší počet bitů,
takže útočníci potřebují méně pokusů. Existují také známé nedostatky generování náhodných čísel v poli transaction ID.
Amit Klein v roce 2007 některé z nich prověřoval. Tato rizika jsou popsána v těchto upozorněních vulnerability notes:
VU#484649 - Microsoft Windows DNS Server je ohrožen útoky typu cache poisoning
VU#252735 - ISC BIND generuje kryptograficky slabé ID pro DNS querry
VU#927905 - BIND verze 8 generuje kryptograficky slabé identifikátory DNS querry

Mnohonásobné nevyřešené požadavky
Některé implementace DNS služeb obsahují slabá místa, díky nimž mnohonásobné a identické požadavky na stejný záznam
resource record (RR) generují mnohonásobné nevyřešené požadavky na tento záznam. To pak umožňuje útok typu 'birthday
attack,' který značně zvyšuje útočníkovu naději na úspěch. Tato problematika byla popsána v dokumentu VU#457875. Řada
dodavatelů a implementátorů již své produkty upravila.

Pevný zdrojový port generace dotazů
Některé současné implementace alokují při startu nějaký port (někdy náhodně vybraný) a pak jej používají jako zdrojový port
pro všechny odchozí dotazy. U některých implementací je zdrojový port pro odchozí dotazy dokonce pevný, na tradičním
čísle portu DNS serveru 53/udp.

Nedávný další výzkum těchto problémů a metod, kombinovaných za účelem zlepšování útoků typu cache poisoning odhalil
zvláště efektivní techniky. Caching DNS resolvery jsou ohroženy nejvíce, a to jak ty otevřené (DNS resolver je otevřený, pokud
poskytuje rekurzivní informace o jménech pro klienty mimo svou administrativní doménu), tak ty uzavřené. Caching resolvery
jsou pro útočníky nejčastějším cílem, nicméně ohroženy jsou i stub resolvery.

Protože tyto útoky spočívají ve schopnosti útočníka předvídatelně přesměrovávat provoz, je použití randomizace zdrojových
portů praktickou obranou proti nim i při omezeních současné specifickace protokolu DNS. Randomizace zdrojových portů
zajistí zhruba dalších 16 bitů, které musí útočník uhodnout. I když technicky existuje 65 535 portů, nelze je použít všechny
(čísla portů <1024 mohou být rezervována, jiná mohou být již použita, atd.). I tak ale randomizace dostupných portů přidá
podstatnou odolnost proti útokům. Je důležité upozornit, že bez změn DNS protokolu, jako jsou změny, představené v rámci
DNS Security Extensions (DNSSEC), nemohou tyto metody cache poisoningu zabránit úplně. Pokud jsou ale správně použity,
redukují několikanásobně šance útočníků a udělají podobné útoky nepraktickými.

Dopad
Útočník, schopný provést úspěšný útok typu cache poisoning může způsobit, že klienti napadeného nameserveru kontaktují
nesprávné a potenciálně nebezpečné hostitelské počítače. Tak může být Internetový provoz, Email a další důležitá data
přesměrována na systémy pod kontrolou útočníka.

Řešení
Použijte záplatu od dodavatele
Řada dodavatelů uvolnila záplaty, implementující randomizaci zdrojových portů nameserveru. Taková záplata značně redukuje
praktičnost útoků typu cache poisoning. Detailní informace o jednotlivých dodavatelích viz část Ovlivněné systémy.

Stub resolvery mohou být těmto útokům také vystaveny, takže systémoví administrátoři by měli provést patch stub resolverů,
které vydávají v reakci na chování útočníka dotazy a na které mohou útočníci posílat pakety. Administarátoři by si měli
opatřit záplaty operačních systémů klienta, které implementují randomizaci portů na stub resolveru.

Omezte přístup
Další cestou, zvláště pro administrátory, kteří nemají k dispozici záplaty, je limitovat možnost útoků omezením zdrojů, které
mohou požadovat rekurzi. Omezení přístupu však v útocích nezabrání útočníkům, kteří mají přístup k autorizovaným
hostitelským počítačům. Dokument "Securing an Internet Name Server" (Ochrana Internetového nameserveru) obsahuje
instrukce pro omezení rekurze v ISC BIND.

Filtrujte přístupy na hranici sítě
Protože k provedení těchto útoků je nutná schopnost produkovat falešné IP adresy, měli by administrátoři takové falešné
adresy filtrovat na hranici sítě. Dokumenty IETF Request for Comments (RFC) RFC 2827, RFC 3704 a RFC 3013 popisují
současné nejlepší praktiky implementace této ochrany. Před rozhodnutím o tom, které změny uplatníte, je důležité znát
konfiguraci vaší sítě a požadavky na jednotlivé služby.

Používejte místní DNS cache
Namísto robustní randomizace portů stub resolveru mohou administrátoři své systémy chránit použitím místních caching
resolverů jak na klientských systémech, tak na serverech, které jsou topograficky blízké klientským systémům. Použití
takových resolverů by mělo být doprovázeno segmentací sítě a filtrováním podle popisu výše.

Deaktivujte rekurzi
Deaktivujte rekurzi na jakémkoli nameserveru, odpovídajícím na DNS požadavky z nedůvěřivých systémů. Dokument
"Securing an Internet Name Server" (Ochrana Internetového nameserveru) obsahuje instrukce pro omezení rekurze v ISC
BIND.

Používejte randomizaci zdrojového portu
Dodavatelé DNS software by si měli prostudovat dokument IETF "Measures for making DNS more resilient against forged
answers" (Opatření ke zvyšování odolnosti DNS protokolu proti falešným odpovědím na dotazy). Tento dokument je ve
stadiu návrhu a před publikací ve formě RFC dokumentu se může změnit. Implementátoři systémů by si měli prostudovat
i dokument IETF "Port Randomization" (Randomizace portů), který obsahuje informace o tom, jak může randomizace
portů přispět k ochraně před ostatními druhy spoof útoků.

Ovlivněné systémy
Dodavatel Statut Datum aktualizace
3com, Inc. Neznámý 10/7/2008
Akamai Technologies, Inc. Neznámý 21/4/2008
Alcatel Neznámý 21/4/2008
Apple Computer, Inc. Neznámý 5/5/2008
AT&T Neznámý 21/4/2008
Avaya, Inc. Neznámý 21/4/2008
Avici Systems, Inc. Neznámý 21/4/2008
Belkin, Inc. Neznámý 13/7/2008
BlueCat Networks, Inc. Neznámý 5/5/2008
Check Point Software Technologies Zabezpečený 10/7/2008
Cisco Systems, Inc. Nezabezpečený 10/7/2008
Conectiva Inc. Neznámý 5/5/2008
Cray Inc. Neznámý 5/5/2008
D-Link Systems, Inc. Neznámý 2/5/2008
Data Connection, Ltd. Neznámý 21/4/2008
Debian GNU/Linux Nezabezpečený 9/7/2008
djbdns Zabezpečený 10/7/2008
dnsmasq Nezabezpečený 11/7/2008
DragonFly BSD Project Neznámý 3/7/2008
EMC Corporation Neznámý 21/4/2008
Engarde Secure Linux Neznámý 5/5/2008
Ericsson Neznámý 21/4/2008
Extreme Networks Neznámý 21/4/2008
F5 Networks, Inc. Nezabezpečený 14/7/2008
Fedora Project Neznámý 5/5/2008
Force10 Networks, Inc. Zabezpečený 11/7/2008
Foundry Networks, Inc. Zabezpečený 10/7/2008
FreeBSD, Inc. Nezabezpečený 14/7/2008
Fujitsu Neznámý 21/4/2008
Gentoo Linux Nezabezpečený 12/7/2008
Gnu ADNS Neznámý 5/5/2008
GNU glibc Neznámý 5/5/2008
Hewlett-Packard Company Neznámý 21/4/2008
Hitachi Neznámý 21/4/2008
Honeywell Neznámý 21/4/2008
IBM Corporation Nezabezpečený 12/7/2008
IBM Corporation (zseries) Neznámý 5/5/2008
IBM eServer Neznámý 21/4/2008
Infoblox Nezabezpečený 10/7/2008
Ingrian Networks, Inc. Neznámý 5/5/2008
Intel Corporation Neznámý 21/4/2008
Internet Systems Consortium Nezabezpečený 14/7/2008
JH Software Zabezpečený 10/7/2008
Juniper Networks, Inc. Nezabezpečený 10/7/2008
Linux Kernel Archives Neznámý 3/6/2008
Lucent Technologies Neznámý 21/4/2008
Luminous Networks Neznámý 21/4/2008
Mandriva, Inc. Neznámý 5/5/2008
MaraDNS Zabezpečený 10/7/2008
Men & Mice Neznámý 5/5/2008
Metasolv Software, Inc. Neznámý 5/5/2008
Microsoft Corporation Nezabezpečený 8/7/2008
MontaVista Software, Inc. Neznámý 5/5/2008
Motorola, Inc. Neznámý 21/4/2008
Multinet (Process Software Corporation) Neznámý 21/4/2008
Multitech, Inc. Neznámý 21/4/2008
NEC Corporation Neznámý 21/4/2008
NetApp Neznámý 3/7/2008
NetBSD Neznámý 5/5/2008
Netgear, Inc. Neznámý 21/4/2008
Network Appliance, Inc. Neznámý 21/4/2008
Nixu Nezabezpečený 9/7/2008
NLnet Labs Zabezpečený 10/7/2008
Nokia Neznámý 21/4/2008
Nominum Nezabezpečený 10/7/2008
Nortel Networks, Inc. Neznámý 21/4/2008
Novell, Inc. Nezabezpečený 14/7/2008
OpenBSD Neznámý 5/5/2008
OpenDNS Zabezpečený 10/7/2008
Openwall GNU/*/Linux Neznámý 5/5/2008
PePLink Zabezpečený 10/7/2008
Posadis project Neznámý 14/7/2008
PowerDNS Zabezpečený 10/7/2008
Q1 Labs Zabezpečený 11/7/2008
QNX, Software Systems, Inc. Neznámý 5/5/2008
Red Hat, Inc. Nezabezpečený 10/7/2008
Redback Networks, Inc. Neznámý 21/4/2008
Secure Computing Network Security Division Neznámý 9/7/2008
Shadowsupport Neznámý 5/5/2008
Siemens Neznámý 8/7/2008
Silicon Graphics, Inc. Neznámý 5/5/2008
Slackware Linux Inc. Nezabezpečený 12/7/2008
Sony Corporation Neznámý 21/4/2008
Sun Microsystems, Inc. Nezabezpečený 10/7/2008
SUSE Linux Nezabezpečený 11/7/2008
The SCO Group Neznámý 5/5/2008
Trustix Secure Linux Neznámý 5/5/2008
Turbolinux Neznámý 5/5/2008
Ubuntu Nezabezpečený 10/7/2008
Wind River Systems, Inc. Nezabezpečený 9/7/2008
ZyXEL Neznámý 21/4/2008

Reference
http://www.kb.cert.org/vuls/id/484649
http://www.kb.cert.org/vuls/id/252735
http://www.kb.cert.org/vuls/id/927905
http://www.kb.cert.org/vuls/id/457875
http://www.cert.org/archive/pdf/dns.pdf
http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience
http://tools.ietf.org/html/rfc3833
http://tools.ietf.org/html/rfc2827
http://tools.ietf.org/html/rfc3704
http://tools.ietf.org/html/rfc3013
http://tools.ietf.org/html/rfc4033
http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization
http://cr.yp.to/djbdns/dns_random.html
http://cr.yp.to/djbdns/dns_transmit.html
http://cr.yp.to/djbdns/forgery.html
http://www.trusteer.com/microsoftdns
http://www.trusteer.com/bind9dns
http://www.trusteer.com/bind8dns
http://www.sans.org/reading_room/whitepapers/dns/1567.php

Poděkování
Děkuji Danu Kaminskému z IOActive za identifikaci účinnosti a použitelnosti DNS cache poisoning a Paulu Vixiemu
z Internet Systems Consortium (ISC) za zdůraznění urgence tohoto problému. Daniel J. Bernstein je původním autorem
a implementátorem randomizovaných zdrojových portů na DNS resolveru.
Autorem tohoto dokumentu je Chad R Dougherty.

Další informace
Datum publikace 08/07/2008
Datum první publikace 08/07/2008 14:46:15
Datum poslední aktualizace 14/07/2008
CERT poradenství
CVE jméno CVE-2008-1447
US-CERT technická varování TA08-190B
Metrika 27,54
Revize 62