[논문 리뷰] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS

Philipp Jeitner, Haya Shulman|arXiv (Cornell University)|2022. 05. 11.

Web Application Security Vulnerabilities참고 문헌 30인용 수 10

한 줄 요약

이 논문은 DNS의 투명성 원칙에 기인한 핵심 보안 취약점을 드러낸다. 악성 페이로드가 DNS 레코드에 인코딩되어 응용 프로그램과 서비스를 대상으로 삽입 공격(예: DNS 캐시 오염 및 원격 코드 실행)을 유도할 수 있다. 저자들은 96퍼센트 이상의 개방형 DNS 해석기가 취약하다고 밝히며, 이러한 공격은 DNSSEC 및 입력 정제와 같은 기존 보호 조치를 우회함을 입증한다.

ABSTRACT

The traditional design principle for Internet protocols indicates: "Be strict when sending and tolerant when receiving" [RFC1958], and DNS is no exception to this. The transparency of DNS in handling the DNS records, also standardised specifically for DNS [RFC3597], is one of the key features that made it such a popular platform facilitating a constantly increasing number of new applications. An application simply creates a new DNS record and can instantly start distributing it over DNS without requiring any changes to the DNS servers and platforms. Our Internet wide study confirms that more than 1.3M (96% of tested) open DNS resolvers are standard compliant and treat DNS records transparently. In this work we show that this `transparency' introduces a severe vulnerability in the Internet: we demonstrate a new method to launch string injection attacks by encoding malicious payloads into DNS records. We show how to weaponise such DNS records to attack popular applications. For instance, we apply string injection to launch a new type of DNS cache poisoning attack, which we evaluated against a population of open resolvers and found 105K to be vulnerable. Such cache poisoning cannot be prevented with common setups of DNSSEC. Our attacks apply to internal as well as to public services, for instance, we reveal that all eduroam services are vulnerable to our injection attacks, allowing us to launch exploits ranging from unauthorised access to eduroam networks to resource starvation. Depending on the application, our attacks cause system crashes, data corruption and leakage, degradation of security, and can introduce remote code execution and arbitrary errors. In our evaluation of the attacks in the Internet we find that all the standard compliant open DNS resolvers we tested allow our injection attacks against applications and users on their networks.

연구 동기 및 목표

• DNS의 DNS 레코드 처리 방식에서의 투명성 원칙이 검증 없이 신뢰할 수 없는 데이터를 유지하는 데 초래하는 보안 영향을 조사하기 위해.
• DNS 데이터를 소비하는 응용 프로그램에서 입력 검증의 부재가 새로운 유형의 삽입 공격을 가능하게 하는 방식을 규명하기 위해.
• 기존 방어 조치—예를 들어 DNSSEC, DNS over HTTPS, DNS over TLS—가 이러한 최신 공격 벡터에 대해 얼마나 효과적인지 평가하기 위해.
• DNS 입력을 검증하지 않는 한계로 인해 조차도 eduroam 및 LDAP과 같은 잘 보호된 시스템이 이러한 공격에 취약하다는 것을 입증하기 위해.
• 하위 계층(DNS 포함)이 모든 데이터 무결성 검사를 담당해야 한다는 가정을 도전하며, 응용 프로그램 수준에서 DNS 데이터 검증을 권장하기 위해.

제안 방법

• 저자들은 후속 응용 프로그램의 문자열 해석 오류를 악용하는 인코딩된 페이로드를 가진 악성 DNS 레코드를 설계한다.
• 300만 개의 개방형 DNS 해석기 대상으로 대규모 인터넷 측정을 수행하여, 96퍼센트가 DNS 레코드 내용을 수정 없이 유지하는 것으로 확인한다.
• 공격 모델은 사회공학 기법(예: 이메일, 광고 네트워크)을 통해 해석기를 속여 악성 레코드를 캐시하도록 유도하며, 이를 통해 공격 대상 응용 프로그램에 전달한다.
• 실제 시스템에 대한 삽입 공격을 구현하고 테스트하며, 악성 DNS 응답을 사용해 DNS 캐시 오염, XSS, LDAP 삽입 공격을 수행한다.
• DNSSEC, DoT, DoH 및 기타 방어 조치의 내구성을 평가하여, 응용 프로그램 수준의 검증이 부재함으로써 이러한 공격을 차단하지 못함을 입증한다.
• 공격 모델 분석을 통해 DNS 재결합 공격 및 기존 웹 삽입 공격과의 비교를 수행하며, 전달 방식과 영향의 핵심 차이점을 강조한다.

실험 결과

연구 질문

• RQ1 DNS가 레코드 처리에서 보이는 투명성이 새로운 삽입 공격 표면을 얼마나 넓히는가?
• RQ2 암호화 및 전송 계층 보호 기능을 제공하는 DNSSEC, DoT, DoH와 같은 기존 방어 조치가 암호화 및 전송 보호를 제공함에도 불구하고 이러한 삽입 공격을 차단하지 못하는 이유는 무엇인가?
• RQ3 이러한 취약성은 실제 DNS 인프라, 특히 개방형 해석기에서 얼마나 널리 퍼져 있는가?
• RQ4 eduVLAN, LDAP, DNS 캐시와 같은 응용 프로그램 및 서비스 중에서 이러한 공격이 가장 효과적인 곳은 어디인가?
• RQ5 프rotocol의 투명성과 응용 프로그램의 DNS 데이터 신뢰 간의 보안 격차를 메우기 위해 어떤 아키텍처적 변경이 필요한가?

주요 결과

• 시험한 개방형 DNS 해석기 중 130만 개 이상(96퍼센트)이 표준 준수하며, 악성 페이로드를 수정 없이 DNS 레코드에 유지한다.
• 저자들은 105,000개의 개방형 DNS 해석기에 대해 DNS 캐시 오염 공격을 성공적으로 시연하였으며, 이는 후속 응용 프로그램에서의 입력 검증 부재에 기인한다.
• 모든 시험한 eduroam 서비스가 삽입 공격에 취약하여, 무단 액세스 및 자원 고갈 공격가능성이 있다.
• 웹 응용 프로그램의 기존 입력 정제 조치는 이러한 공격을 보호하지 못한다. 왜냐하면 악성 데이터가 사용자 입력이 아닌 DNS를 통해 전달되기 때문이다.
• 일반적인 구성에서 DNSSEC는 이러한 공격을 방지하지 못한다. 공격은 DNS 데이터 위조가 아니라 응용 프로그램 수준의 잘못된 해석을 악용하기 때문이다.
• 최신 보호 조치인 DNS over HTTPS와 DNS over TLS도 이러한 공격을 완화하지 못한다. 이는 응용 프로그램 계층에서 DNS 레코드의 의미적 내용을 검증하지 않기 때문이다.