본문으로 이동

DNS 하이재킹

위키백과, 우리 모두의 백과사전.

DNS 하이재킹(DNS hijacking) 또는 DNS 포이즈닝(DNS poisoning) 또는 DNS 리디렉션(DNS redirection)은 도메인 네임 시스템(DNS) 쿼리 해결을 방해하는 행위이다.[1] 이는 공격자가 제어하는 불량 DNS 서버를 가리키도록 컴퓨터의 TCP/IP 구성을 재정의하는 악성 소프트웨어에 의해 달성될 수 있거나, 신뢰할 수 있는 DNS 서버의 동작을 수정하여 인터넷 표준을 준수하지 않도록 할 수 있다.

이러한 수정은 피싱과 같은 악의적인 목적으로 이루어질 수 있으며, 인터넷 서비스 제공자(ISP)의 이기적인 목적으로, 만리방화벽 및 공공/라우터 기반 온라인 DNS 서버 제공자에 의해 사용자 웹 트래픽을 ISP 자체 웹 서버로 유도하여 광고를 제공하거나 통계를 수집하거나 ISP의 다른 목적으로 사용될 수 있으며, DNS 서비스 제공자에 의해 검열의 한 형태로 특정 도메인에 대한 접근을 차단할 수 있다.

기술적 배경

[편집]

DNS 서버의 기능 중 하나는 도메인 네임을 응용 프로그램이 웹사이트와 같은 인터넷 리소스에 연결하는 데 필요한 IP 주소로 변환하는 것이다. 이 기능은 통신 프로토콜을 상당히 자세하게 정의하는 다양한 공식 인터넷 표준에 정의되어 있다. DNS 서버는 인터넷에 연결된 컴퓨터와 사용자에 의해 인터넷 도메인 소유자가 등록한 실제 주소로 이름을 올바르게 해결하는 데 암묵적으로 신뢰된다.

Dig 명령 스크린샷. 페르시아어 위키백과를 해결하려는 요청에 대해 이란 DNS 서버에서 잘못된 응답을 보여준다.

불량 DNS 서버

[편집]

불량 DNS 서버는 바람직한 웹사이트(검색 엔진, 은행, 중개인 등)의 도메인 이름을 의도하지 않은 콘텐츠, 심지어 악성 웹사이트의 IP 주소로 변환한다. 대부분의 사용자는 ISP에 의해 자동으로 할당되는 DNS 서버에 의존한다. 라우터의 할당된 DNS 서버는 라우터 펌웨어 내의 취약점을 원격으로 악용하여 변경될 수도 있다.[2] 사용자가 웹사이트를 방문하려고 하면, 대신 가짜 웹사이트로 보내진다. 이 공격을 파밍이라고 한다. 리디렉션된 사이트가 합법적인 웹사이트로 위장하여 민감한 정보를 사기적으로 얻으려는 악성 웹사이트인 경우, 이를 피싱이라고 한다.[3]

ISP의 조작

[편집]

AT&T,[4] 케이블비전의 옵티멈 온라인,[5] 센추리링크,[6] 콕스 커뮤니케이션즈, RCN,[7] 로저스,[8] 차터 커뮤니케이션스(스펙트럼), 플러스넷,[9] 버라이즌 커뮤니케이션스,[10] 스프린트 (기업),[11] T-모바일 US,[12] 버진 미디어,[13][14] 프론티어 커뮤니케이션스, 벨 심파티코,[15] 도이체 텔레콤,[16] 옵터스,[17] 미디어콤,[18] ONO,[19] 토크토크,[20] 빅폰드 (텔스트라),[21][22][23][24] TTNET, Türksat, 그리고 모든 인도네시아 고객 ISP는 광고 표시[25] 또는 통계 수집과 같은 자체 목적으로 DNS 하이재킹을 사용하거나 사용했다. 네덜란드 ISP인 XS4ALL과 Ziggo는 법원 명령에 따라 DNS 하이재킹을 사용한다. 이들은 파이러트베이에 대한 접근을 차단하고 경고 페이지를 표시하도록 명령받았다.[26] 반면 인도네시아의 모든 고객 ISP는 국가 DNS법을 준수하기 위해 DNS 하이재킹을 수행한다.[27] 이 법은 모든 인도네시아 고객 ISP가 포트 53을 하이재킹하고 자체 서버로 리디렉션하여 콤인포의 인터넷 세하트(Internet Sehat) 캠페인에 따라 Trustpositif에 등록된 웹사이트를 차단하도록 요구한다. 이러한 관행은 DNS (NXDOMAIN) 응답에 대한 RFC 표준을 위반하며,[28] 잠재적으로 사용자에게 사이트 간 스크립팅 공격을 노출시킬 수 있다.[25]

DNS 하이재킹의 문제는 NXDOMAIN 응답의 하이재킹과 관련이 있다. 인터넷 및 인트라넷 응용 프로그램은 DNS가 지정된 호스트에 대한 항목이 없는 조건을 설명하기 위해 NXDOMAIN 응답에 의존한다. 유효하지 않은 도메인 이름(예: www.example.invalid)을 쿼리하면 NXDOMAIN 응답을 받아야 한다. 이는 응용 프로그램에 이름이 유효하지 않음을 알리고 적절한 조치를 취한다(예: 오류 표시 또는 서버 연결 시도 안 함). 그러나 이러한 비준수 ISP 중 하나에서 도메인 이름이 쿼리되면 항상 ISP에 속하는 가짜 IP 주소를 받게 된다. 웹 브라우저에서는 이 동작이 짜증나거나 불쾌할 수 있는데, 이 IP 주소로의 연결이 적절한 오류 메시지 대신 제공업체의 ISP 리디렉션 페이지를 (때로는 광고와 함께) 표시하기 때문이다. 그러나 NXDOMAIN 오류에 의존하는 다른 응용 프로그램은 대신 이 스푸핑된 IP 주소로 연결을 시도하여 잠재적으로 민감한 정보를 노출시킬 수 있다.

ISP가 DNS를 하이재킹할 때 깨지는 기능의 예:

  • 윈도우 서버 도메인의 구성원인 로밍 랩톱은 도메인 컨트롤러, 이메일 서버 및 기타 인프라와 같은 리소스가 사용 가능한 것처럼 보이기 때문에 다시 회사 네트워크에 있다고 잘못 믿게 될 것이다. 따라서 응용 프로그램은 이러한 회사 서버에 연결을 시도하지만 실패하여 성능 저하, 인터넷 연결에서 불필요한 트래픽, 그리고 타임아웃이 발생한다.
  • 많은 소규모 사무실 및 가정 네트워크는 자체 DNS 서버가 없으며, 대신 브로드캐스트 이름 해결에 의존한다. 많은 버전의 마이크로소프트 윈도우는 NetBIOS 이름 해결 브로드캐스트보다 DNS 이름 해결을 우선시하도록 기본 설정되어 있다. 따라서 ISP DNS 서버가 LAN의 원하는 컴퓨터 이름에 대해 (기술적으로 유효한) IP 주소를 반환하면, 연결하는 컴퓨터는 이 잘못된 IP 주소를 사용하여 필연적으로 LAN의 원하는 컴퓨터에 연결하는 데 실패한다. 해결 방법으로는 컴퓨터 이름 대신 올바른 IP 주소를 사용하거나, DhcpNodeType 레지스트리 값을 변경하여 이름 해결 서비스 순서를 변경하는 것이 있다.[29]
  • 모질라 파이어폭스와 같은 브라우저는 더 이상 "이름으로 찾아보기" 기능이 없다(주소창에 입력된 키워드가 사용자에게 가장 일치하는 사이트로 이동).[30]
  • 최신 운영 체제에 내장된 로컬 DNS 클라이언트는 성능상의 이유로 DNS 검색 결과를 캐시한다. 클라이언트가 홈 네트워크와 VPN 사이를 전환하면 잘못된 항목이 캐시된 채로 남아 VPN 연결에서 서비스 중단이 발생할 수 있다.
  • DNSBL 스팸 방지 솔루션은 DNS에 의존하므로 잘못된 DNS 결과는 작동을 방해한다.
  • ISP에 의해 서버가 사용 가능하다고 속아서 연결하려는 응용 프로그램에 의해 기밀 사용자 데이터가 유출될 수 있다.
  • 브라우저에서 URL을 잘못 입력한 경우 어떤 검색 엔진을 사용할지에 대한 사용자 선택권이 ISP가 사용자에게 표시되는 검색 결과를 결정하기 때문에 제거된다.
  • VPN 연결과 스플릿 터널링을 사용하도록 구성된 컴퓨터는 작동을 멈춘다. 이는 터널 외부의 공용 인터넷을 통해 해결되지 않아야 할 인트라넷 이름이 가상의 주소로 해결되기 시작하고, 인터넷에서 NXDOMAIN 응답을 받을 때 VPN 터널을 통해 사설 DNS 서버에서 올바르게 해결되지 않기 때문이다. 예를 들어, 내부 메일 서버의 DNS A 레코드를 해결하려는 메일 클라이언트는 유료 결과 웹 서버로 리디렉션하는 잘못된 DNS 응답을 받을 수 있으며, 재전송 시도에도 불구하고 며칠 동안 배달 대기 중인 메시지가 쌓일 수 있다.[31]
  • 웹 브라우저가 ISP에 프록시 서버가 구성되어 있다고 잘못 믿게 하여 웹 프록시 자동 발견 프로토콜(WPAD)을 깨뜨린다.
  • 모니터링 소프트웨어를 깨뜨린다. 예를 들어, 서버의 상태를 확인하기 위해 주기적으로 서버에 연락하는 경우, 모니터가 서버의 암호화 키를 확인하려고 시도하지 않는 한 실패를 볼 수 없다.

모든 경우에 해당되는 것은 아니지만, 일부 ISP는 NXDOMAIN 응답 하이재킹을 비활성화하는 가입자 구성 가능 설정을 제공한다. 올바르게 구현되면 이러한 설정은 DNS를 표준 동작으로 되돌린다. 그러나 다른 ISP는 대신 웹 브라우저 쿠키를 사용하여 선호도를 저장한다. 이 경우 기본 동작은 해결되지 않는다. DNS 쿼리는 계속 리디렉션되지만, ISP 리디렉션 페이지는 가짜 DNS 오류 페이지로 대체된다. 웹 브라우저 이외의 응용 프로그램은 쿠키를 사용하여 이 계획에서 제외될 수 없다. 이는 제외가 실제로는 프로토콜 중립적인 DNS에서 구현되는 계획임에도 불구하고 HTTP 프로토콜만을 대상으로 하기 때문이다.

반응

[편집]

영국에서 정보통신위원회는 비자발적인 DNS 하이재킹 관행이 PECR 및 통신 트래픽 처리에 대한 명시적 동의를 요구하는 EC 지침 95/46 데이터 보호를 위반한다는 점을 인정했다.[13] 2019년 독일에서는 도이체 텔레콤 AG가 DNS 서버를 조작했을 뿐만 아니라, 사용자가 HTTPS를 사용하지 않을 때 비보안 쿠키와 같은 네트워크 트래픽을 제3자 회사로 전송했다는 사실이 밝혀졌다. 이는 DNS 조작으로 사용자들이 리디렉션된 웹 포털 T-Online이 더 이상 도이체 텔레콤 소유가 아니었기 때문이다. 한 사용자가 형사 고발을 제기한 후, 도이체 텔레콤은 추가 DNS 조작을 중단했다.[32]

최상위 도메인 이름 관리를 담당하는 국제 기구인 ICANN은 우려 사항을 강조하고 다음을 확인하는 각서를 발표했다.[31]

ICANN은 기존 gTLD, ccTLD 및 레지스트리 클래스 도메인 이름에 대한 DNS 트리의 다른 모든 수준에서 DNS 리디렉션, 와일드카드, 합성 응답 및 기타 형태의 NXDOMAIN 대체 사용을 강력히 권장하지 않는다.

해결책

[편집]

만족스럽지 못한 "옵트아웃" 옵션(예: 쿠키)에 불만을 가진 최종 사용자는 스푸핑된 NXDOMAIN 응답을 피하는 방법을 찾아 논란에 대응했다. BIND 및 Dnsmasq와 같은 DNS 소프트웨어는 결과를 필터링하는 옵션을 제공하며, 전체 네트워크를 보호하기 위해 게이트웨이 또는 라우터에서 실행될 수 있다. 구글은 현재 스푸핑된 결과를 반환하지 않는 오픈 DNS 서버를 운영하고 있다. 따라서 사용자는 구글 퍼블릭 DNS를 ISP의 DNS 서버 대신 사용할 수 있다. 단, 이 서비스를 구글의 개인 정보 보호 정책에 따라 사용하고 잠재적으로 구글이 사용자를 추적할 수 있는 다른 방법에 노출될 수 있음을 감수해야 한다. 이 접근 방식의 한계는 일부 제공업체가 외부 DNS 요청을 차단하거나 다시 작성한다는 점이다. 시스코 소유의 오픈DNS는 NXDOMAIN 응답을 변경하지 않는 유사한 인기 서비스이다.

구글은 2016년 4월 DNS-over-HTTPS 서비스를 시작했다.[33] 이 방식은 기존 DNS 프로토콜의 한계를 극복할 수 있다. 원격 DNSSEC 검사를 수행하고 보안 HTTPS 터널을 통해 결과를 전송한다.

파이어폭스 확장 기능인 NoRedirect[34]와 같은 응용 프로그램 수준의 해결 방법도 있어 일부 동작을 완화한다. 이러한 접근 방식은 하나의 응용 프로그램(이 예에서는 파이어폭스)만 수정하며, 다른 문제들을 해결하지는 못한다. 웹사이트 소유자는 특정 DNS 설정을 사용하여 일부 하이재커를 속일 수 있다. 예를 들어, 와일드카드 주소(예: *.example.com)에 "unused" TXT 레코드를 설정하는 것이다. 또는 와일드카드의 CNAME을 "example.invalid"로 설정하여 ".invalid"가 RFC에 따라 존재하지 않는다는 사실을 활용할 수 있다. 이 접근 방식의 한계는 특정 도메인에서만 하이재킹을 방지할 수 있지만, DNS 하이재킹으로 인한 일부 VPN 보안 문제를 해결할 수 있다는 점이다.

같이 보기

[편집]

각주

[편집]
  1. ↑ “What is a DNS Hijacking | Redirection Attacks Explained | Imperva”. 《Learning Center》 (미국 영어). 2020년 12월 13일에 확인함. 
  2. ↑ Constantin, Lucian (2015년 1월 27일). “DNS hijacking flaw affects D-Link DSL router, possibly other devices” (미국 영어). 2017년 6월 21일에 확인함. 
  3. ↑ “Rogue Domain Name System Servers”. Trend Micro. 2007년 12월 15일에 확인함. 
  4. ↑ “ATT DNS Assist Page”. 2017년 3월 27일. 2018년 2월 24일에 확인함. 
  5. ↑ “Optimum Online DNS Assistance”. 2009년 8월 13일에 원본 문서에서 보존된 문서. 
  6. ↑ “Re: [Qwest] Opting out of CenturyLink Web Helper hijacking not w - CenturyLink | DSLReports Forums”. 《DSL Reports》. 2016년 10월 12일에 확인함. 
  7. ↑ “Who Stole My Web Browser?”. 2009년 10월 13일. 
  8. ↑ “Rogers Uses Deep Packet Inspection for DNS Redirection”. dslreports.com. 2008년 6월 20일. 2010년 6월 15일에 확인함. 
  9. ↑ “UK ISP's providing cdn for google”. equk.co.uk. 2014년 4월 7일. 2015년 10월 25일에 확인함. 
  10. ↑ “Opting out of DNS Assistance”. 2015년 2월 12일에 원본 문서에서 보존된 문서. 2015년 2월 12일에 확인함. 
  11. ↑ “Are Sprint 3G and 4G towers hijacking NXDOMAIN responses? More information in comments... • r/Sprint”. 《reddit》. 2014년 9월 5일. 2018년 2월 24일에 확인함. 
  12. ↑ “How do I turn of NXDOMAIN hijacking? • r/tmobile”. 《reddit》. 2015년 7월 20일. 2018년 2월 24일에 확인함. 
  13. ↑ 가 나 “ICO: We won't stop Advanced Network Error Search”. 2015년 2월 17일에 원본 문서에서 보존된 문서. 
  14. ↑ “Case Reference Number ENQ0265706” (PDF). I am not convinced that there is any likelihood of detriment or harm to subscribers or users that would justify taking formal action in this case. 
  15. ↑ “Bell Starts Hijacking NS Domain Queries”. 2009년 8월 4일. 
  16. ↑ Reiko Kaps (2009년 4월 17일). “Telekom leitet DNS-Fehlermeldungen um” (독일어). 2019년 12월 9일에 확인함. 
  17. ↑ “Optus' "About the Search Results Page"”. 2012년 7월 13일에 원본 문서에서 보존된 문서. 2009년 12월 10일에 확인함. 
  18. ↑ “Want a real world example of why we need network neutrality? I have one here.”. 2009년 9월 25일. 
  19. ↑ “XSS Reflected dnssearch.Ono.es NXD redirect”. 2010년 5월 10일. 2018년 6월 12일에 원본 문서에서 보존된 문서. 2018년 2월 24일에 확인함. 
  20. ↑ “TalkTalk - Search”. 《error.talktalk.co.uk》. 2018년 2월 24일에 확인함. 
  21. ↑ “BigPond redirects typos to 'unethical' branded search page”. 《CRN Australia》. 2018년 2월 24일에 확인함. 
  22. ↑ “Charter Corrupting DNS protocol ie hijacking hosts”. 
  23. ↑ “road runner dns hijack causing slow web-pages”. 2010년 12월 10일에 원본 문서에서 보존된 문서. 
  24. ↑ “Rogers violates net neutrality by hijacking failed DNS lookups”. 2008년 7월 27일에 원본 문서에서 보존된 문서. 
  25. ↑ 가 나 Singel, Ryan (2008년 4월 19일). “ISPs Error Page Ads Let Hackers Hijack Entire Web, Researcher Discloses”. 《Wired》. 
  26. ↑ Digined. “XS4ALL blokkeert adressen Pirate Bay voorlopig | XS4ALL Weblog”. 《blog.xs4all.nl》 (네덜란드어). 2017년 10월 5일에 확인함. 
  27. ↑ Tanjung, Tidar. “Kominfo Finalisasi DNS Nasional?” (영어). 2018년 6월 11일에 확인함. 
  28. ↑ Andrews, M. (1998). 《Negative Caching of DNS Queries》. doi:10.17487/RFC2308. 
  29. ↑ “NetBIOS and WINS”. 《howtonetworking.com》. 2018년 2월 24일에 확인함. 
  30. ↑ “Using Firefox + NoRedirect Extension to Avoid DNS Hijacking”. 2011년 3월 3일에 원본 문서에서 보존된 문서. 
  31. ↑ 가 나 “Harms Caused by NXDOMAIN Substitution in Toplevel and Other Registry-class Domain Names” (PDF) (미국 영어). ICANN. 2009년 11월 24일. 2010년 9월 23일에 확인함. 
  32. ↑ “Telekom beendet DNS-Hijacking”. 《de》. 
  33. ↑ “DNS-over-HTTPS - Public DNS”. 《Google Developers》 (미국 영어). 2018년 9월 4일. 2019년 3월 12일에 확인함. 
  34. ↑ “NoRedirect – Add-ons for Firefox”. 《addons.mozilla.org》. 2018년 2월 25일에 원본 문서에서 보존된 문서. 2018년 2월 24일에 확인함. 
원본 주소 "https://ko.wikipedia.org/w/index.php?title=DNS_하이재킹&oldid=40102005"