Luki znalezione w Dnsmasq umożliwiają fałszowanie zawartości pamięci podręcznej DNS

Niedawno informacje o zidentyfikowano 7 podatności w pakiecie Dnsmasq, który łączy buforowany program rozpoznawania nazw DNS i serwer DHCP, którym przypisano nazwę kodową DNSpooq. Problems pozwalają na nieuczciwe ataki na pamięć podręczną DNS lub przepełnienia bufora mogłoby to doprowadzić do zdalnego wykonania kodu atakującego.

Chociaż niedawno Dnsmasq nie jest już domyślnie używany jako solver w zwykłych dystrybucjach Linuksa, nadal jest używany w systemie Android oraz wyspecjalizowane dystrybucje, takie jak OpenWrt i DD-WRT, a także oprogramowanie układowe do routerów bezprzewodowych wielu producentów. W normalnych dystrybucjach możliwe jest niejawne użycie dnsmasq, na przykład podczas korzystania z libvirt można go uruchomić w celu świadczenia usługi DNS na maszynach wirtualnych lub można go aktywować, zmieniając ustawienia w konfiguratorze NetworkManager.

Ponieważ kultura aktualizacji routera bezprzewodowego pozostawia wiele do życzenia, badacze obawiają się, że zidentyfikowane problemy mogą pozostać nierozwiązane przez długi czas i będą zaangażowani w zautomatyzowane ataki na routery w celu przejęcia nad nimi kontroli lub przekierowania użytkowników na fałszywe złośliwe witryny.

Istnieje około 40 firm opartych na Dnsmasq, w tym Cisco, Comcast, Netgear, Ubiquiti, Siemens, Arista, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE i Zyxel. Użytkownicy takich urządzeń mogą zostać ostrzeżeni, aby nie korzystali z udostępnionej na nich zwykłej usługi przekierowywania zapytań DNS.

Pierwsza część luk odkryte w Dnsmasq dotyczy ochrony przed atakami typu „cache” DNS, na podstawie metody zaproponowanej w 2008 roku przez Dana Kaminsky'ego.

Zidentyfikowane problemy powodują, że istniejąca ochrona jest nieskuteczna i pozwalają na fałszowanie adresu IP dowolnej domeny w pamięci podręcznej. Metoda Kaminsky'ego polega na manipulowaniu niewielkim rozmiarem pola identyfikatora zapytania DNS, które ma tylko 16 bitów.

Aby znaleźć poprawny identyfikator potrzebny do sfałszowania nazwy hosta, wystarczy wysłać około 7.000 140.000 żądań i zasymulować około XNUMX XNUMX fałszywych odpowiedzi. Atak sprowadza się do wysłania dużej liczby fałszywych pakietów związanych z IP do resolwera DNS z różnymi identyfikatorami transakcji DNS.

Zidentyfikowane luki zmniejszają 32-bitowy poziom entropii oczekuje się, że będzie musiał odgadnąć 19 bitów, co sprawia, że ​​atak zatrucia pamięci podręcznej jest całkiem realistyczny. Ponadto obsługa rekordów CNAME przez dnsmasq umożliwia sfałszowanie łańcucha rekordów CNAME w celu skutecznego fałszowania do 9 rekordów DNS naraz.

  • CVE-2020-25684: brak walidacji ID żądania w połączeniu z adresem IP i numerem portu podczas przetwarzania odpowiedzi DNS z serwerów zewnętrznych. To zachowanie jest niekompatybilne z RFC-5452, który wymaga użycia dodatkowych atrybutów żądania podczas dopasowywania odpowiedzi.
  • CVE-2020-25686: Brak walidacji oczekujących żądań o tej samej nazwie, co pozwala na użycie metody daty urodzenia w celu znacznego zmniejszenia liczby prób sfałszowania odpowiedzi. W połączeniu z luką CVE-2020-25684 funkcja ta może znacznie zmniejszyć złożoność ataku.
  • CVE-2020-25685: użycie zawodnego algorytmu haszującego CRC32 przy weryfikacji odpowiedzi, w przypadku kompilacji bez DNSSEC (SHA-1 jest używany z DNSSEC). Luka ta może zostać wykorzystana do znacznego zmniejszenia liczby prób, umożliwiając wykorzystanie domen, które mają ten sam skrót CRC32, co domena docelowa.
  • Drugi zestaw problemów (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 i CVE-2020-25687) jest spowodowany błędami, które powodują przepełnienia bufora podczas przetwarzania niektórych danych zewnętrznych.
  • W przypadku luk CVE-2020-25681 i CVE-2020-25682 możliwe jest tworzenie exploitów, które mogą prowadzić do wykonania kodu w systemie.

Wreszcie jest o tym mowa luki w zabezpieczeniach zostały usunięte w aktualizacji Dnsmasq 2.83 jako obejście zaleca się wyłączenie rozszerzeń DNSSEC i buforowania zapytań za pomocą opcji wiersza poleceń.

źródło: https://kb.cert.org


Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.