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á.
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
Sdružení CZ.NIC, správce české národní domény, představuje novou podobu svých oficiálních webových stránek. Stránky logicky propojují klíčovou správu domény .CZ, partnerství s reg…
Organizátoři devátého setkání nejen českých a slovenských správců sítí CSNOG 2027 vyhlásili Call for Abstracts. Zájemci o vystoupení na této akci mohou své abstrakty přihlašovat d…
V harmonogramu Akademie CZ.NIC na druhou polovinu letošního roku se objevují dva nové kurzy. Na své si přijdou jak příznivci Linuxu, tak všichni, které zajímá problematika exfiltr…