DNS 스푸핑

DNS spoofing

DNS 스푸핑(DNS 캐시 포이즈닝이라고도 함)은 컴퓨터 보안 해킹의 한 형태로, 손상된 도메인 네임 시스템 데이터가 DNS 리졸바의 캐시에 도입되어 네임 서버가 잘못된 결과 레코드(예: IP 주소)를 반환하게 됩니다.이로 인해 트래픽이 공격자의 컴퓨터(또는 다른 컴퓨터)로 우회됩니다.

도메인 네임 시스템의 개요

주요 기사:도메인 네임 시스템

도메인 네임시스템 서버는 사람이 읽을 수 있는 도메인 이름을 변환합니다(예:example.com)를, 노드간의 통신을 라우팅 하기 위해서 사용되는 수치 IP 주소로 합니다.통상 서버는 요청된 변환을 인식하지 못할 경우 다른 서버에 요청을 하고 프로세스는 반복적으로 계속됩니다.퍼포먼스를 향상시키기 위해 서버는 보통 일정 시간 동안 이러한 변환을 기억(캐시)합니다.즉, 같은 변환에 대한 다른 요구를 수신하면 캐시가 만료될 때까지 다른 서버에 문의할 필요 없이 응답할 수 있습니다.

DNS 서버가 잘못된 변환을 수신하여 성능 최적화를 위해 캐시하면 포이즈닝된 것으로 간주되어 잘못된 데이터를 클라이언트에 공급합니다.DNS 서버가 포이즈닝되면 잘못된 IP 주소를 반환하여 트래픽을 다른 컴퓨터(대부분 공격자)[1]로 우회시킬 수 있습니다.

캐시 포이즈닝 공격

일반적으로 네트워크 컴퓨터는 ISP(인터넷 서비스 공급자) 또는 컴퓨터 사용자의 조직에서 제공하는 DNS 서버를 사용합니다.DNS 서버는 이전에 가져온 쿼리 결과를 캐싱하여 해결 응답 성능을 향상시키기 위해 조직의 네트워크에서 사용됩니다.단일 DNS 서버에 대한 포이즈닝 공격은 침해된 서버에 의해 직접 서비스되는 사용자 또는 해당 다운스트림서버에 의해 간접적으로 서비스되는 사용자에게 영향을 줄 수 있습니다.[2]

캐시 포이즈닝 공격을 실행하기 위해 공격자는 DNS 소프트웨어의 결함을 악용합니다.서버는 DNS 응답을 올바르게 검증하여 신뢰할 수 있는 소스로부터의 것임을 확인해야 합니다(예를 들어 DNSSEC 사용).그렇지 않으면 서버가 잘못된 엔트리를 로컬로 캐시하여 동일한 요구를 하는 다른 사용자에게 제공할 수 있습니다.

이 공격은 공격자가 선택한 웹 사이트에서 다른 사이트로 사용자를 리디렉션하는 데 사용할 수 있습니다.예를 들어 공격자는 특정 DNS 서버상의 타깃웹 사이트의 IP 주소 DNS 엔트리를 스푸핑하여 그 관리 대상 서버의 IP 주소로 바꿉니다.그런 다음 공격자는 대상 서버의 이름과 일치하는 파일을 자신의 제어 하에 서버에 만듭니다.이러한 파일에는 일반적으로 컴퓨터 웜이나 바이러스와 같은 악의적인 콘텐츠가 포함되어 있습니다.컴퓨터가 포이즈닝된 DNS 서버를 참조한 사용자는 비인증 서버로부터 수신된 콘텐츠를 받아들이도록 속아 자신도 모르게 악성 콘텐츠를 다운로드합니다.이 기술은 은행 및 신용 카드/직불 카드 세부 정보 등의 개인 정보를 수집하기 위해 가짜 버전의 정품 웹 사이트를 만드는 피싱 공격에도 사용할 수 있습니다.

변종

다음 변형에서는 서버의 엔트리가ns.target.example은 포이즈닝되어 IP 주소 w.x.y.z에 있는 공격자의 네임서버로 리다이렉트 됩니다.이러한 공격에서는 target.example의 네임서버가 ns.target.[citation needed]example이라고 가정합니다.

공격을 수행하려면 공격자는 대상 DNS 서버에서 공격자의 네임서버 [citation needed]중 하나에 의해 제어되는 도메인에 대한 요청을 강제로 수행해야 합니다.

대상 도메인의 네임 서버를 리디렉션합니다.

DNS 캐시 포이즈닝의 첫 번째 변형에는 공격자 도메인의 네임서버를 대상 도메인의 네임서버로 리다이렉트 한 후, 그 네임서버에 공격자가 지정한IP 주소를 할당합니다.

DNS 서버 요청: subdomain.attacker.example의 주소 레코드는 무엇입니까? 

subdomain.subdomain.subdomain.subA에서

공격자의 대응:

답변: (응답 없음)권한 섹션: attacker.example.3600 IN NS.target.example.추가 섹션: ns.target.example.IN A.x.y.z.

취약한 서버는 ns.target.example의 추가 A 레코드(IP 주소)를 캐시하여 공격자가 target.example 도메인 전체에 대한 쿼리를 해결할 수 있도록 합니다.

NS 레코드를 다른 대상 도메인으로 리디렉션

DNS 캐시 포이즈닝의 두 번째 변형에서는 원래 요구와 무관한 다른 도메인의 네임서버를 [citation needed]공격자가 지정한IP 주소로 리다이렉트 합니다.

DNS 서버 요청: subdomain.attacker.example의 주소 레코드는 무엇입니까? 

subdomain.subdomain.subdomain.subA에서

공격자의 대응:

답변: (응답 없음)권한 섹션: target.example.3600 IN NS.attacker. 예추가 섹션:ns.attacker.exampleIN A.x.y.z.

취약한 서버는 target.example의 NS 레코드(네임 서버 항목)에 대한 관련 없는 권한 정보를 캐시하여 공격자가 target.example 도메인 전체에 대한 쿼리를 해결할 수 있도록 합니다.

예방 및 경감

DNS 서버에 대한 캐시 포이즈닝 공격은 다른 DNS 서버에 의해 전달된 정보에 대한 신뢰도가 낮아지고 쿼리와 직접 관련이 없는 DNS 레코드를 무시함으로써 방지할 수 있습니다.예를 들어, BIND 9.5[3].0-P1 이후 버전에서는 이러한 [4]체크가 실행됩니다.DNS 요구에 대한 송신원포트 랜덤화와 더불어 송신원포트 및 16비트 암호화 난스를 모두 선택하기 위한 암호화 시큐어 난수를 사용함으로써 DNS 레이스 [citation needed]공격의 성공 가능성을 크게 낮출 수 있습니다.

단, 라우터, 방화벽, 프록시 및 기타 게이트웨이 디바이스가 Network Address Translation(NAT; 네트워크주소 변환), 특히 Port Address Translation(PAT; 포트 주소 변환)을 실행할 때는, 접속 상태를 추적하기 위해서 송신원포트를 고쳐 쓸 수 있습니다.송신원포트를 변경할 때, PAT 디바이스는, 네임 서버 및 스터브 [citation needed][5]리졸바에 의해서 실장되고 있는 송신원포트의 랜덤성을 삭제할 수 있습니다.

Secure DNS(DNSEC; 시큐어 DNS)는 신뢰할 수 있는 공개 키 증명서로 서명된 암호화 디지털 서명을 사용하여 데이터의 신뢰성을 판단합니다.DNSSEC는 캐시 포이즈닝 공격에 대응할 수 있습니다.2010년에는 인터넷 루트 존서버에 DNSSEC가 실장되어 있습니다만, 모든 최상위 도메인 서버에도 도입할 필요가 있습니다.[6]이러한 DNSSEC 준비 상태는 인터넷 최상위 도메인 목록에 표시됩니다.2020년 현재 대부분의 대형 국가의 국가 코드 TLD와 마찬가지로 원본 TLD는 모두 DNSSEC를 지원하지만 많은 국가 코드 TLD는 여전히 지원하지 않습니다.

이러한 종류의 공격은 접속이 확립되면 엔드 투 엔드 검증을 실행하여 트랜스포트층 또는 애플리케이션층에서 경감할 수 있습니다.일반적인 예로는 트랜스포트층 보안과 디지털서명의 사용이 있습니다.예를 들어 HTTPS(HTTP의 보안 버전)를 사용하여 서버의 디지털 인증서가 유효하고 웹 사이트의 예상 소유자에게 속하는지 확인할 수 있습니다.마찬가지로 시큐어 셸 리모트로그인 프로그램은 세션을 진행하기 전에 엔드포인트(이미 알고 있는 경우)의 디지털 증명서를 확인합니다.업데이트를 자동으로 다운로드하는 응용 프로그램의 경우 응용 프로그램은 서명 인증서 복사본을 로컬에 내장하고 소프트웨어 업데이트에 저장된 서명을 포함된 [7]인증서와 비교할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Son, Sooel; Shmatikov, Vitaly. "The Hitchhiker's Guide to DNS Cache Poisoning" (PDF). Cornell University. Archived (PDF) from the original on 14 August 2017. Retrieved 3 April 2017.
  2. ^ Storms, Andrew (2006). "Don't Trust Your Vendor's Software Distribution Methodology". Information Systems Security. 14 (6): 38–43. doi:10.1201/1086.1065898X/45782.14.6.20060101/91858.8. S2CID 15167573 – via ProQuest Central.
  3. ^ "BIND Security Matrix". ISC Bind. Archived from the original on 11 November 2011. Retrieved 11 May 2011.
  4. ^ "ISC Bind Security". ISC Bind. Archived from the original on 11 November 2011. Retrieved 11 May 2011.
  5. ^ Dearing, Christopher (2019). "Personal Information as an Attack Vector: Why Privacy Should Be an Operational Dimension of U.S. National Security †". Journal of National Security Law & Policy. 10: 351–403 – via ProQuest.
  6. ^ "Root DNSSEC". ICANN/Verisign. p. 1. Archived from the original on 10 September 2017. Retrieved 5 January 2012.
  7. ^ "The right configuration to secure your server". IONOS Digitalguide. Retrieved 29 April 2022.