모든 DNS 확인자에 영향을 미치는 NXNSAttack 공격

텔아비브 대학교와 헤르츨리야(이스라엘) 학제간 센터의 연구자 그룹 발전했다 새로운 공격 방식 NXNS공격 (PDF), 모든 DNS 확인자를 트래픽 증폭기로 사용할 수 있어 패킷 수 측면에서 최대 1621배의 증폭 속도를 제공합니다(확인자로 전송된 각 요청에 대해 피해자 서버로 전송되는 1621개의 요청을 달성할 수 있습니다). 트래픽 측면에서 최대 163배입니다.

이 문제는 프로토콜의 특성과 관련이 있으며 다음을 포함하여 재귀적 쿼리 처리를 지원하는 모든 DNS 서버에 영향을 미칩니다. 묶다 (CVE-2020-8616), 매듭 (CVE-2020-12667), PowerDNS (CVE-2020-10995), Windows DNS 서버 и 매여 있지 않은 (CVE-2020-12662), Google, Cloudflare, Amazon, Quad9, ICANN 및 기타 회사의 공용 DNS 서비스도 포함됩니다. 수정 사항은 DNS 서버 개발자와 협력하여 제품의 취약점을 수정하는 업데이트를 동시에 출시했습니다. 릴리스에 구현된 공격 보호
언바운드 1.10.1, 매듭 해결 프로그램 5.1.1, PowerDNS 리커서 4.3.1, 4.2.2, 4.1.16, 바인드 9.11.19, 9.14.12, 9.16.3.

공격은 이름 결정이 위임된 이전에 볼 수 없었던 다수의 가상 NS 레코드를 참조하는 요청을 사용하는 공격자를 기반으로 하지만 응답에서 NS 서버의 IP 주소에 대한 정보가 포함된 글루 레코드를 지정하지 않습니다. 예를 들어, 공격자는 공격자.com 도메인을 담당하는 DNS 서버를 제어하여 sd1.attacker.com이라는 이름을 확인하기 위한 쿼리를 보냅니다. 공격자의 DNS 서버에 대한 확인자의 요청에 대한 응답으로, IP NS 서버를 자세히 설명하지 않고 응답에 NS 레코드를 표시하여 sd1.attacker.com 주소 결정을 피해자의 DNS 서버에 위임하는 응답이 발행됩니다. 언급된 NS 서버는 이전에 발견된 적이 없고 IP 주소가 지정되지 않았기 때문에 확인자는 대상 도메인(victim.com)을 서비스하는 피해자의 DNS 서버에 쿼리를 보내 NS 서버의 IP 주소를 확인하려고 시도합니다.

문제는 공격자가 존재하지 않는 가상의 피해자 하위 도메인 이름(fake-1.victim.com, fake-2.victim.com,...fake-1000)을 사용하여 반복되지 않는 거대한 NS 서버 목록으로 대응할 수 있다는 것입니다. 피해자.com). 확인자는 피해자의 DNS 서버에 요청을 보내려고 시도하지만 도메인을 찾을 수 없다는 응답을 받은 후 목록에서 다음 NS 서버를 결정하려고 시도하는 등 모든 것을 시도할 때까지 계속됩니다. 공격자가 나열한 NS 레코드입니다. 따라서 한 공격자의 요청에 대해 확인자는 NS 호스트를 확인하기 위해 엄청난 수의 요청을 보냅니다. NS 서버 이름은 무작위로 생성되고 존재하지 않는 하위 도메인을 참조하기 때문에 캐시에서 검색되지 않으며 공격자가 요청할 때마다 피해자의 도메인을 서비스하는 DNS 서버에 요청이 쇄도합니다.

연구진은 해당 문제에 대한 공용 DNS 리졸버의 취약성 정도를 연구한 결과, CloudFlare 리졸버(1.1.1.1)로 쿼리를 보낼 때 패킷 수(PAF, Packet Amplification Factor)를 48배까지 늘릴 수 있다고 판단했으며, 구글은 이를 (8.8.8.8) - 30번, FreeDNS(37.235.1.174) - 50번, OpenDNS(208.67.222.222) - 32번. 보다 눈에 띄는 지표가 관찰됩니다.
레벨3(209.244.0.3) - 273회, 쿼드9(9.9.9.9) - 415회
SafeDNS (195.46.39.39) - 274배, Verisign (64.6.64.6) - 202배,
Ultra(156.154.71.1) - 405번, Comodo Secure(8.26.56.26) - 435번, DNS.Watch(84.200.69.80) - 486번, Norton ConnectSafe(199.85.126.10) - 569번입니다. BIND 9.12.3 기반 서버의 경우 요청 병렬화로 인해 게인 수준이 최대 1000에 도달할 수 있습니다. Knot Resolver 5.1.0에서는 게인 수준이 약 수십 배(24~48)로 결정됩니다. NS 이름은 순차적으로 수행되며 단일 요청에 허용되는 이름 확인 단계 수에 대한 내부 제한에 따라 결정됩니다.

두 가지 주요 방어 전략이 있습니다. DNSSEC가 있는 시스템의 경우 에 의해 제안 사용 RFC-8198 요청이 임의의 이름으로 전송되므로 DNS 캐시 우회를 방지합니다. 이 방법의 핵심은 DNSSEC를 통한 범위 확인을 사용하여 권한 있는 DNS 서버에 연결하지 않고 부정적인 응답을 생성하는 것입니다. 더 간단한 접근 방식은 단일 위임된 요청을 처리할 때 정의할 수 있는 이름 수를 제한하는 것입니다. 그러나 이 방법은 프로토콜에 제한이 정의되어 있지 않기 때문에 일부 기존 구성에 문제가 발생할 수 있습니다.

출처 : opennet.ru