Et team av forskere fra University of California, Riverside har publisert en ny variant av SAD DNS-angrepet (CVE-2021-20322) som fungerer til tross for beskyttelser lagt til i fjor for å blokkere CVE-2020-25705-sårbarheten. Den nye metoden er generelt lik fjorårets sårbarhet og skiller seg bare i bruk av en annen type ICMP-pakker for å sjekke aktive UDP-porter. Det foreslåtte angrepet gjør det mulig å erstatte fiktive data i DNS-serverbufferen, som kan brukes til å erstatte IP-adressen til et vilkårlig domene i hurtigbufferen og omdirigere forespørsler til domenet til angriperens server.
Предложенный метод работоспособен только в сетевом стеке Linux из-за привязки к особенности работы механизма обработки ICMP-пакетов в Linux, который выступает источником утечки данных, упрощающих определения номера UDP-порта, использованного server для отправки внешнего запроса. Изменения, блокирующие утечку информации, приняты в состав ядра Linux в конце августа (исправление вошло в состав ядра 5.15 и сентябрьских обновлений LTS-веток ядра). Исправление сводится к переходу на использование в сетевых кэшах алгоритма хэшировния SipHash вместо Jenkins Hash. Статус устранения уязвимости в дистрибутивах можно оценить на данных страницах: Debian, RHEL, Fedora, SUSE, Ubuntu.
По данным выявивших проблему исследователей уязвимости подвержено около 38% находящихся в сети открытых резолверов, включая популярные DNS-сервисы, такие как OpenDNS и Quad9 (9.9.9.9). Что касается серверного ПО, то атака может быть проведена при использовании на Linux-сервере таких пакетов, как BIND, Unbound и dnsmasq. На DNS-серверах, запущенных с использованием Windows и BSD-систем, проблема не проявляется. Для успешного совершения атаки необходимо использовать спуфинг IP, т.е. требуется чтобы провайдер атакующего не блокировал пакеты с поддельным исходным IP-адресом.
Som en påminnelse omgår SAD DNS-angrepet beskyttelsen lagt til DNS-servere for å blokkere den klassiske DNS-cache-forgiftningsmetoden foreslått i 2008 av Dan Kaminsky. Kaminskys metode manipulerer den lille størrelsen på DNS-spørrings-ID-feltet, som bare er 16 biter. For å velge riktig DNS-transaksjonsidentifikator som er nødvendig for forfalskning av vertsnavn, er det nok å sende omtrent 7000 forespørsler og simulere omtrent 140 tusen fiktive svar. Angrepet koker ned til å sende et stort antall pakker med en fiktiv IP-binding og med forskjellige DNS-transaksjonsidentifikatorer til DNS-resolveren. For å forhindre bufring av det første svaret, inneholder hvert dummy-svar et litt modifisert domenenavn (1.example.com, 2.example.com, 3.example.com, etc.).
For å beskytte mot denne typen angrep implementerte DNS-serverprodusenter en tilfeldig fordeling av antall kildenettverksporter som oppløsningsforespørsler sendes fra, noe som kompenserte for den utilstrekkelig store størrelsen på identifikatoren. Etter å ha implementert beskyttelse for å sende et fiktivt svar, i tillegg til å velge en 16-bits identifikator, ble det nødvendig å velge en av 64 tusen porter, noe som økte antallet valgmuligheter til 2^32.
SAD DNS-metoden lar deg radikalt forenkle bestemmelsen av nettverksportnummeret og redusere angrepet til den klassiske Kaminsky-metoden. En angriper kan oppdage tilgang til ubrukte og aktive UDP-porter ved å dra nytte av lekket informasjon om aktiviteten til nettverksporter ved behandling av ICMP-svarpakker. Metoden lar oss redusere antall søkealternativer med 4 størrelsesordener - 2^16+2^16 i stedet for 2^32 (131_072 i stedet for 4_294_967_296). Lekkasjen av informasjon som lar deg raskt fastslå aktive UDP-porter er forårsaket av en feil i koden for behandling av ICMP-pakker med fragmenteringsforespørsler (ICMP Fragmentation Needed-flagg) eller omdirigering (ICMP Redirect-flagg). Sending av slike pakker endrer tilstanden til cachen i nettverksstakken, noe som gjør det mulig å bestemme, basert på serverens svar, hvilken UDP-port som er aktiv og hvilken som ikke er det.
Angrepsscenario: Når en DNS-resolver prøver å resolvere et domenenavn, sender den en UDP-spørring til DNS-serveren som håndterer domenet. Mens resolveren venter på et svar, kan en angriper raskt bestemme kildeportnummeret som ble brukt til å sende spørringen og sende et forfalsket svar, og utgi seg for å være DNS-serveren som håndterer domenet ved hjelp av forfalskning. IP-adresserDNS-resolveren vil mellomlagre dataene som sendes i det forfalskede svaret, og vil i en periode returnere IP-adressen som angriperen har erstattet med i alle andre DNS-spørringer for domenenavnet.
Kilde: opennet.ru
