DHCP DNS 동적 업데이트를 악용하는 DNS 레코드 스푸핑

서론

DNS 레코드를 스푸핑하는 기능은 민감한 데이터 유출, 인증정보 감염, 심지어 원격 코드 실행 등의 심각한 결과를 초래할 수 있으므로 공격자에게 매우 매력적입니다.

이 블로그 게시물에서는 거의 연구되지 않았으며 겉보기에 무해한 DHCP 기능에 의해 노출되는 DNS의 공격표면에 대해 조사합니다. 이를 통해 공격자가 Microsoft DNS 서버의 DNS 레코드를 스푸핑할 수 있는 여러 가지 방법을 발견했습니다. 여기에는 인증되지 않은 임의 DNS 레코드 덮어쓰기를 포함합니다.

공격 흐름과 함께 Microsoft DHCP 서버의 내부 작동, DNS 및 Active Directory와의 상호 작용 및 이러한 인터페이스를 적절히 보호하는 방법에 대해서도 자세히 설명합니다. 비록 온라인에 존재하는 DHCP에 대한 리소스는 많이 흩어져 있지만(게다가 부정확하고!), 우리는 이 블로그 게시물이 보안팀 직원을 위한 모든 중요한 정보가 한 곳에서 제공되는 주제에 대한 정확하고 포괄적인 리소스라고 믿습니다.

DNS 동적 업데이트의 중요한 기능 중 하나는 보안 업데이트로  영역에서 각 DNS 레코드를 수정할 수 있는 사용자를 제어하도록 설계되었습니다. 보안 업데이트가 없으면 DNS 서버는 모든 업데이트 요청을 맹목적으로 따르므로 공격자가 기존 레코드를 쉽게 덮어쓸 수 있습니다. 이 기능을 사용하면 기본적으로 ADI 영역에 대한 DNS 서버에서 보안 업데이트만 허용됩니다(그림 3).

기본 제공되는 일부 강력한 그룹을 제외한 다른 보안 주체는 레코드에 대한 사용 권한을 가질 수 없습니다. 다른 보안 주체가 소유하지 않거나 사용 권한이 없는 DNS 레코드를 수정하려고 하면 서버에서 업데이트를 거부합니다.

ADIDNS 영역은 공격자에게 매우 흥미로울 수 있습니다. Kevin Robertson의 NETSPI 관련 이전 연구는 이러한 DNS 영역에 대한 몇 가지 흥미로운 공격을 강조했습니다. 이 공격표면을 확장하고자 했기 때문에 추가적인 관련 기능을 조사하기 시작했으며, 이에 따라 DHCP DNS 동적 업데이트라는 흥미로운 기능이 개발되었습니다.

DHCP DNS 동적 업데이트 프로세스는 그림 6에 나와 있습니다.

이 기능은 유용하지만 오늘날 일반적으로 사용되지는 않습니다(언급했듯이 대부분의 최신 Windows 클라이언트는 단순하게 자체 레코드를 생성합니다). 그럼에도 불구하고, Microsoft DHCP 서버에는 이 기능이 기본적으로 활성화되어 있습니다. 즉, DHCP 서버가 DNS 레코드를 요청하는 모든 클라이언트에 대해 DNS 레코드를 등록합니다.

DHCP DNS 동적 업데이트는 DHCP 클라이언트의 인증이 필요하지 않습니다 - 네트워크의 모든 사용자가 DHCP 서버에서 IP를 임대할 수 있으므로 공격자는 본질적으로 DHCP 서버를 사용하여 자신을 대신하여 DNS 서버에 인증할 수 있습니다. 공격자는 인증정보 없이 ADIDNS 영역에 접속할 수 있습니다.

Microsoft는 이 기능이 야기하는 잠재적인 리스크를 인식하고 그 중 일부를 인정하는 것으로 보이지만, 공격자와 보안팀 직원은 이 공격표면을 대부분 알지 못합니다.

다음 섹션에서는 DHCP DNS 동적 업데이트를 악용하여 수행할 수 있는 공격에 대해 자세히 설명합니다.

1. 네트워크의 호스트가 "pc.aka.test"라는 이름을 확인하려고 시도하고 DNS 서버에 쿼리를 보냅니다.

2. “PC.aka.test”는 DNS 서버에 알려지지 않았으므로 “그런 이름 없음”으로 응답합니다.

3. 그런 다음 호스트는 LLMNR 멀티캐스트를 전송하여 LAN에서 "pc.aka.test"를 찾습니다.

4. 공격자는 이러한 시도를 식별하고 "pc.aka.test"를 FQDN으로 사용하여 DHCP 서버에 IP 임대를 요청합니다.

5. 서버에서 DNS 서버로 동적 업데이트 요청을 보내면 레코드가 만들어집니다.

이제 네트워크의 모든 호스트가 "pc.aka.test"를 해결하려고 시도하면 공격자에게 리디렉션됩니다. 이제 공격자는 ntlmrelayx.py 를 실행하고 인증 시도를 기다립니다.

이 방식은 표준 LLMNR/NBNS 스푸핑 방법 및 ADIDNS 스푸핑 변형보다 낫습니다. 

• 클래식 LLMNR/NBNS 스푸핑은 인증이 필요하지 않지만 동일한 LAN의 피해자로 제한됩니다(LLMNR/NBNS는 브로드캐스트 기반).

• ADIDNS 스푸핑은 DNS가 서브넷에서 작동하기 때문에 LAN 외부의 피해자를 대상으로 할 수 있었지만 인증된 사용자가 필요했습니다.

DHCP DNS 동적 업데이트를 사용하면 LAN 외부의 피해자를 대상으로 공격이 이루어지며 인증이 필요하지 않습니다.

이것만으로도 훌륭하지만 더 나은 방법도 가능합니다.

기존 레코드 덮어쓰기

존재하지 않는 DNS 레코드를 만드는 것은 좋지만, 이는 다른 선택지를 떠올리게 만들었습니다. 이미 존재하는 호스트 이름에 대한 레코드를 생성하려고 하면 어떻게 될까요? 어떻게든 덮어쓸 수 있을까요? 이상적으로는 가능하지 않을 겁니다, 그렇지 않나요? 하지만...

인증되지 않은 공격자가 기존 레코드를 덮어쓸 수 있는 사례를 확인했습니다. 우리는 이 기술을 DHCP DNS 덮어쓰기라고 부르기로 했습니다. 이러한 사례를 살펴보기 전에 DHCP 동적 업데이트 프로세스에 대해 좀 더 자세히 알아보겠습니다.

이 클라이언트들의 중요한 차이점은 소유자입니다. 우리가 이 게시물의 앞에서 설명했듯DNS 업데이트가 수행되면 클라이언트 레코드가 만들어지고 업데이트 요청을 보낸 주체가 레코드 소유자로 할당됩니다. 일반 Windows 클라이언트의 경우 이 보안 주체는 클라이언트의 머신 계정입니다.

관리되는 레코드도 요청 클라이언트가 소유할 것으로 예상할 수 있지만 그렇지 않습니다. DHCP 서버가 클라이언트 대신 DNS 업데이트를 보낼 때 자체 머신 계정을 사용하여 인증하는데, 이는 레코드 소유자가 됩니다.

이 차이는 그림 12에서 확인할 수 있습니다. PC2는 클라이언트가 소유하는 클라이언트 레코드이고, PC1은 DHCP 서버가 소유하는 관리되는 레코드입니다.

간략한 내용은 다음과 같습니다. 공격자가 DHCP 서버를 사용하여 임의의 DNS 업데이트를 보낼 수 있지만 DNS 레코드는 ACL로 인해 덮어쓰기로부터 안전해야 합니다.

이제 덮어쓰기를 방지하는 메커니즘을 이해했으므로 덮어쓰기를 어떻게 수행할 수 있는지 살펴보겠습니다.

이 레코드는 DHCP 서버 머신 계정이 소유합니다. 이제 공격 머신에서 임대 과정의 DHCP 서버와 동일한 FQDN을 요청합니다. DNS 영역을 확인한 결과 덮어쓰기가 성공했으며, 이제 레코드는 방금 임대된 IP를 가리킵니다(그림 17).

이 공격은 괜찮지만 관리되는 레코드에만 영향을 미치기 때문에 영향은 제한적입니다. 앞서 언급했듯이 이러한 레코드는 이 공격의 영향을 받지 않는 클라이언트 레코드보다 훨씬 덜 일반적입니다. 그럼에도 불구하고 다음과 같이 클라이언트가 자신의 레코드를 등록할 수 없는 경우에 관리되는 레코드를 찾을 수 있습니다.

• 비 Windows 클라이언트

• 레거시 Windows 클라이언트 

• 클라이언트 DNS 업데이트를 비활성화한 Windows 클라이언트

이 공격은 더욱 안정적입니다. Microsoft DHCP 서버가 네트워크에 있는 경우 일치하는 클라이언트 레코드가 보장되는 반면, 관리되는 레코드(이전 덮어쓰기 시나리오에 필요함)는 더 드뭅니다.

이에 따른 영향으로는 공격자가 DHCP 서버로 향하는 모든 통신을 가로챌 수 있습니다. 심각도는 이 트래픽의 특성에 따라 달라집니다. 대부분의 경우 DHCP 서버로 향하는 통신을 가로채는 기능은 인증정보를 가로채서 릴레이하거나 서버에 설치될 수 있는 다른 서비스의 민감한 트래픽을 캡처하기 위해 악용될 수 있습니다.

민감한 서비스에 대해 언급하자면 DHCP 서버가 도메인 컨트롤러(DC)에 설치된 경우 어떻게 할까요? DC 레코드를 덮어쓸 수 있을까요? 네, 할 수 있습니다.

우리의 데이터는 이러한 위험한 설정이 매우 일반적이라는 것을 보여줍니다. Microsoft DHCP 서버를 사용하는 관찰된 네트워크 중 57%가 DC에 DHCP 서버를 설치했습니다. 이러한 모든 도메인은 기본적으로 취약합니다.

하지만 이 리스크는 Microsoft의 문서에서도 인정하고 있으며, 우리는 이러한 잘못된 설정에 대한 인식이 잠재적 영향과 일치하지 않는다고 믿습니다.

DHCP DNS 공격에 대한 방어 및 우회 방법

지금까지 설명한 모든 공격은 Microsoft DHCP 서버의 기본 설정에서 작동합니다. 그러나 이 중 일부를 방어하는 데 도움이 되는 두 가지 설정이 있습니다. 그것들을 살펴보고, 어떻게 우회할 수 있는지 살펴 보겠습니다.

보시다시피 DHCID 레코드 값은 Base64로 인코딩된 데이터 청크입니다. 이 값(이 게시물의 뒷부분에서 분석)은 레코드 생성 또는 업데이트를 요청한 DHCP 클라이언트를 식별하기 위한 고유 서명입니다.

DHCP 서버가 DNS 레코드를 수정하도록 요청되면 클라이언트의 DHCID 값을 계산하고 해당 DHCID 값과 함께 업데이트된 데이터를 포함하는 DNS 업데이트를 보냅니다. 

DNS 서버에 레코드가 없으면 레코드와 일치하는 DHCID 레코드만 만들어집니다. 그러나 호스트(A) 및 DHCID 레코드가 있는 경우 기존 DHCID 값을 DHCP 서버에서 전송한 값과 비교합니다. 값이 일치하는 경우에만 업데이트가 수행됩니다.

따라서 기본적으로 DHCID 레코드는 DNS 레코드를 만든 클라이언트와 DNS 레코드를 연결합니다. 이 연결이 만들어지면 이 원래 클라이언트만 레코드를 수정할 수 있습니다.

고유 식별자는 단순히 클라이언트의 MAC 주소입니다. 클라이언트로부터 Release 메시지를 수신하면 DHCP 서버는 주소와 ID가 일치하는 기존 엔트리를 찾아 발견 시 삭제합니다. DHCP DNS 동적 업데이트가 활성화되면 IP 주소를 해제하는 것 외에도 DHCP 서버는 DNS 동적 업데이트를 전송하여 클라이언트의 관련 DNS 레코드를 삭제합니다.

대상 ID와 일치하는 고유 ID(MAC 주소)를 사용하여 DHCP Release를 보낼 수 있다면 DHCP 서버는 레코드를 삭제하여 사용자가 직접 등록할 수 있도록 합니다. 이름 보호를 우회하기 위한 유일한 요구 사항은 피해자의 MAC 주소입니다! (실제 MAC을 변경할 필요가 없습니다. 값은 DHCP 헤더에서 가져옵니다.)

만약 우리가 타겟과 같은 랜에 있다면, MAC을 찾는 것은 매우 사소한 일이다; 예를 들어, ARP 요청을 보냄으로써 찾을 수 있다. 하지만 동일한 LAN에 있지 않다면 어떻게 될까요? 다른 옵션이 있습니다.

이름 보호를 우회하도록 DHCID 레코드 무차별 대입

DHCID 레코드는 RFC 4701에 정의되어 있고, 그 알고리즘은 매우 간단합니다.

1. • DHCP HTYPE(하드웨어 종류) 값을 연결합니다. 이더넷의 경우 값은 01입니다. 

   • DHCP 클라이언트 ID 옵션

   • FQDN 기록(DNS 유선 형식)

2. SHA256 결과

3. DHCID 데이터 비트 추가(Windows 구축에서 이 값은 상수)

4. Base64에서 결과를 인코딩

그림 23은 DHCID 계산의 예를 보여줍니다.

참조된 코드는 지정된 매개 변수를 기반으로 DHCID 값을 계산하는 데 사용할 수 있습니다.

즉, 일치하는 값이 없으면 업데이트가 실패합니다. 클라이언트 레코드에는 DHCID 레코드가 없어야 하므로, 이름 보호가 활성화되어 있으면 클라이언트 레코드를 우회할 방법이 없는 DHCP DNS 덮어쓰기로부터 보호해야 합니다. 그렇게 하는 것이 맞습니다.

이름 보호는 기본적으로 관리되는 레코드만 보호하기 위한 것이므로 이름 보호 기능의 일부가 아닙니다. 이는 이름 보호 기능의 부산물입니다. 그러나 방금 설명한 논리 때문에 클라이언트 레코드도 보호할 수 있습니다. 그러나 이러한 우연한 방어조차도 우회할 수 있습니다.

범위로 분리하면 주소 분배를 보다 효율적으로 관리할 수 있으며 서브넷마다 서로 다른 정책을 적용할 수 있습니다. 이름 보호는 이러한 정책 중 하나이며 범위 수준에서 사용하도록 설정되어 있으므로, 서로 다른 범위에 서로 다른 설정이 있을 수 있습니다.

이 게시물의 앞부분에서 언급했듯이, 클라이언트 레코드에 대한 DHCP DNS 덮어쓰기는 임대가 이름이 보호되는 DHCP 범위에서 이루어졌기 때문에 실패했습니다. 그러나 이해해야 할 중요한 것이 있습니다. 범위는 DHCP 용어입니다. 클라이언트 레코드는 이러한 정보를 인식하지 못하며 범위와 연결되지 않습니다.

따라서 이름 보호가 비활성화된 다른 범위에서 임대를 받을 수 있다면 이 방어 조치를 ‘우회’할 수 있습니다. (이름 보호가 비활성화된 다른 범위에서 임대를 받는 방법은 이 게시물의 범위를 벗어나지만 DHCP 릴레이 옵션)

즉, 서버의 단일 범위에 이름 보호가 비활성화되어 있더라도 공격자는 앞에서 설명한 잘못된 설정 중 하나를 고려하여 클라이언트 레코드를 덮어쓸 수 있습니다.

DHCP 서버가 DC에 설치된 예로 돌아가 보겠습니다. DNS 레코드를 업데이트할 때 영역의 모든 레코드에 대한 사용 권한이 있는 계정인 DC 머신 계정이 사용되었습니다. DNS 인증정보가 설정되어 있으면 취약한 계정을 대신 사용할 수 있으며 공격은 더 이상 작동하지 않습니다.

DNS 인증정보를 설정하면 DHCP 서버가 노출하는 공격표면을 줄일 수 있으므로 DNS 인증정보를 설정하는 것이 매우 중요합니다. 앞서 설명한 가장 심각한 공격을 방어할 수 있어야 합니다.

그러나 이 기능을 사용할 때는 다음 두 가지 세부 사항을 고려해야 합니다.

• 설정된 인증정보는 약한 사용자여야 합니다. 예를 들어 도메인 관리자로 설정하면 DHCP 서버가 임의의 레코드를 덮어쓸 수 있습니다.

• DHCP 서버에서 만든 DNS 레코드는 여전히 동일한 인증정보에 의해 소유되며 DHCP DNS 덮어쓰기에 취약합니다.

DnsUpdateProxy 그룹

Microsoft의 DHCP 및 DNS와의 상호 작용을 조사하는 동안 악용될 수 있는 또 다른 기능은 DnsUpdateProxy 그룹입니다. 이 그룹은 관리되는 레코드의 두 가지 권한 관련 문제, 즉 업그레이드된 클라이언트 문제와 다중 DHCP 서버 문제를 해결하기 위한 것입니다.

두 번째 효과는 ‘레코드 인계’ 기능입니다. 즉, DnsUpdateProxy 멤버가 만든 레코드를 수정하는 첫 번째 클라이언트에 대한 소유권이 부여되고 인증된 사용자의 쓰기 권한이 제거됩니다. 이렇게 하면 클라이언트가 필요한 경우 자신의 레코드를 수정하고 넘겨받을 수 있으므로 업그레이드된 클라이언트 문제가 해결됩니다.

이 문제는 이 그룹의 추가 기능 때문에 DnsUpdateProxy를 사용하여 다시 해결할 수 있습니다. DnsUpdateProxy 의 멤버가 다른 멤버가 소유한 레코드를 수정하려고 하면 ACL로 인해 업데이트가 성공한 것입니다. 그러나 이번에는 ACL과 소유권이 바뀌지 않습니다. 이를 통해 여러 서버에서 레코드를 ‘공동 소유’할 수 있습니다.

보안 리스크 및 버그

이제 DnsUpdateProxy 그룹이 보안 리스크를 노출한다는 것을 이해했을 것입니다.  이 그룹의 구성원이 만든 모든 레코드는 인증된 사용자가 ‘훔칠’ 수 있습니다. 이것은 취약점이 아니라 기능 디자인을 남용한 것입니다. Microsoft는 이 리스크를 인지하고 있습니다.

이외에도 DnsUpdateProxy 기능 구축의 버그로 보이는 문제에서 비롯된 또 다른 문제를 확인했습니다. 그룹의 구성원이 생성한 자체 DNS 레코드는 인증된 사용자에게 쓰기 권한이 있는 동일한 취약한 ACL로 만들어집니다.

그림 31은 예를 보여줍니다. DHCP 서버 dhcp1.aka.test 레코드에 초기에 보안 ACL이 있습니다.

이제 도메인 사용자가 새 DNS 레코드를 쓸 수 있습니다. 이것은 분명히 기능의 의도된 부분이 아닙니다. 서버에서 만든 관리되는 레코드는 수정된 ACL을 갖도록 되어 있지만 서버의 자체 클라이언트 레코드는 영향을 받지 않습니다.

DHCP DNS 공격 방어

DHCP DNS 동적 업데이트와 관련된 수많은 리스크가 있습니다. 가능한 모든 서버 설정을 요약하고 방금 설명한 공격을 방어하는 방법을 알아보겠습니다.

여기서는 DHCP 서버에서 만든 관리되는 레코드와 Windows 클라이언트에서 직접 만든 두 가지 종류의 클라이언트 레코드를 참조합니다.

TL;DR 버전은 다음과 같습니다.

• 필요하지 않은 경우 DHCP DNS 동적 업데이트를 사용하지 않습니다.

• 취약한 사용자를 DNS 인증정보로 설정하면 클라이언트 레코드가 안전해집니다.

• 관리되는 레코드는 어떤 설정으로도 스푸핑으로부터 보호할 수 없습니다. 가능하면 중요한 비 Windows 호스트에 정적 DNS 레코드를 사용하세요.

• DnsUpdateProxy를 사용하지 말고, 대신 모든 DHCP 서버에서 동일한 DNS 인증정보를 사용하세요.

DNS 인증정보

클라이언트 레코드에 대한 DHCP DNS 덮어쓰기를 방어하는 가장 좋은 방법입니다. 이러한 용도로 사용되는 강력한 암호를 사용하여 약한 사용자를 설정합니다. DC에서 DHCP 서버를 실행하는 경우 이는 매우 중요합니다. 이 설정은 관리되는 레코드에 대한 DHCP DNS 덮어쓰기를 중지하지 않습니다.

이름 보호

이름 보호는 이론적으로 관리되는 레코드를 보호해야 하지만 실제로는 공격자가 쉽게 우회할 수 있습니다. 덮어쓰기를 덜 중요하게 만들려면 여전히 활성화해야 합니다.

이름 보호가 클라이언트 레코드를 보호하기 위한 것은 아니지만 서버의 모든 범위에서 이름 보호를 사용하도록 설정하면 덮어쓰기 공격이 방어됩니다.

Microsoft DHCP에서 이름 보호를 설정할 때 이를 적용하는 방법에는 서버 수준과 범위 수준이 있습니다. 서버 수준에서 이름 보호가 활성화되면 서버 수준에서 이름 보호가 활성화된다고 생각할 수 있습니다. 그렇지만 항상 적용되는 것은 아닙니다. 서버 수준에서 이름 보호를 활성화하면 신규 서버의 범위는 설정을 사용하도록 설정하여 만들어지지만 기존 범위에서는 사용할 수 없습니다. 서버에 있는 각 범위의 범위 수준에서 이름 보호가 설정되어 있는지 확인하는 것이 중요합니다.

DnsUpdateProxy

이 그룹을 사용하면 안 됩니다. 해당 구성원이 만든 모든 레코드가 덮어쓰기 쉽기 때문에 보안상 위험합니다.

DHCP 서버가 여러 개 있고 이 서버가 함께 작동하도록 하려면 DNS 인증정보를 대신 사용해야 합니다. 모든 DHCP 서버에서 동일한 DNS 인증정보를 설정하기만 하면 서로의 레코드를 편집할 수 있습니다.

DnsUpdateProxy는 곧 업그레이드할 Windows NT 4.0 이전 클라이언트가 있는 경우에만 유용합니다. 그리고 그 빈티지의 아무거나가 있는 경우에, 당신은 DnsUpdateProxy 보다는 더 큰 문제가 있어.

어떤 이유로 DnsUpdateProxy를 사용해야 하는 경우에는 각 그룹 구성원에 대해 정적 DNS 레코드를 만드는 것이 좋습니다. 정적 레코드는 생성 계정이 소유하며, 이는 다른 서버의 머신 계정과 달라야 합니다. 이렇게 하면 서버가 안전하지 않은 권한으로 자체 레코드를 만들지 못하게 됩니다.

DHCP DNS 스푸핑

인증되지 않은 공격자가 존재하지 않는 DNS 레코드를 만드는 것을 막을 방법은 없습니다. 이렇게 하는 유일한 방법은 모든 DHCP 서버에서 DHCP DNS 동적 업데이트를 비활성화하는 것입니다. 일반적으로 사용자 환경에서 DHCP DNS 동적 업데이트 기능이 필요하지 않은 경우에는 사용하지 않도록 설정하는 것이 좋습니다. 이렇게 하면 일부 리스크가 제거되고 공격표면을 줄일 수 있습니다.

요약

Microsoft는 모든 조사 결과를 Microsoft에 보고했으며, Microsoft는 위에서 언급한 모든 문제가 설계에 의한 것이거나 해결책을 받을 정도로 심각하지 않다고 응답했습니다.

우리는 동의하지 않는 경향이 있습니다. 우리가 강조한 공격의 영향은 매우 클 수 있습니다. 인증 없이 DNS 레코드를 덮어쓸 수 있기 때문에 공격자는 도메인의 호스트에서 중간 위치에 머신을 확보할 수 있습니다. 이렇게 하면 민감한 정보와 인증정보가 쉽게 노출될 수 있으며 릴레이 공격이 발생하여 공격자가 AD 도메인을 침해하고 권한을 상승시킬 수 있습니다. 이 게시물에서 공유한 통계는 많은 데이터 센터 네트워크에 대한 위협이 얼마나 견고한지 보여줍니다.

이러한 문제에 대한 해결책이 계획되어 있지 않으므로, 보안팀 직원은 Invoke-DHCPCheckup을 사용해 환경을 검사하여 우리가 강조한 위험한 설정 오류를 찾아내야 합니다. 스포일러 알림 - 기본 설정을 변경하지 않으면 취약해집니다.