현수 DNS 항목 방지 및 하위 도메인 인수 방지
이 문서에서는 하위 도메인 인수라는 일반적인 보안 위협에 대해 설명하고 이를 완화하기 위해 수행할 수 있는 단계를 설명합니다.
하위 도메인 인수란?
하위 도메인 인수는 정기적으로 많은 리소스를 만들고 삭제하는 조직에 자주 발생하는 높은 심각도의 위협입니다. 프로비전 해제된 Azure 리소스를 가리키는 DNS 레코드가 있는 경우 하위 도메인 인수가 발생할 수 있습니다. 이러한 DNS 레코드는 "현수 DNS" 항목으로도 알려져 있습니다. CNAME 레코드는 특히 이 위협에 취약합니다. 하위 도메인 인수를 통해 악의적인 행위자는 조직의 도메인에 대한 트래픽을 악의적인 활동을 수행하는 사이트로 리디렉션할 수 있습니다.
하위 도메인 인수의 일반적인 시나리오는 다음과 같습니다.
생성:
FQDN(정규화된 도메인 이름)
app-contogreat-dev-001.azurewebsites.net을 사용하여 Azure 리소스를 프로비전합니다.Azure 리소스에 트래픽을 라우팅하는 하위 도메인
greatapp.contoso.com을 사용하여 DNS 영역에 CNAME 레코드를 할당합니다.
프로비전 해제:
Azure 리소스는 더 이상 필요하지 않으면 프로비전 해제 또는 삭제됩니다.
이 시점에서 CNAME 레코드는 DNS 영역에서
greatapp.contoso.com제거되어야 합니다. CNAME 레코드가 제거되지 않은 경우 활성 도메인으로 보급되지만 활성 Azure 리소스로 트래픽을 라우팅하지 않습니다. 이제 "현수" DNS 레코드가 있습니다.현수 하위 도메인
greatapp.contoso.com은 이제 취약해지고 다른 Azure 구독의 리소스에 할당되어 인수될 수 있습니다.
인수:
위협 행위자가 일반적으로 사용 가능한 방법 및 도구를 사용하여 현수 하위 도메인을 검색합니다.
위협 행위자는 사용자가 이전에 제어했던 동일한 리소스 FQDN을 사용하여 Azure 리소스를 프로비전합니다. 이 예제에서 해당 이름은
app-contogreat-dev-001.azurewebsites.net입니다.하위 도메인
greatapp.contoso.com으로 전송되는 트래픽은 이제 콘텐츠를 제어하는 악의적 행위자의 리소스로 라우팅됩니다.
하위 도메인 위험의 인수
DNS 레코드가 사용할 수 없는 리소스를 가리키는 경우 레코드 자체는 DNS 영역에서 제거되어야 합니다. 삭제되지 않으면 "현수 DNS" 레코드이며 subdo기본 인수 가능성을 만듭니다.
현수 DNS 항목을 통해 위협 행위자는 연결된 DNS 이름을 제어하여 악성 웹 사이트 또는 서비스를 호스트할 수 있습니다. 조직의 하위 도메인에 악성 페이지 및 서비스가 있을 경우 다음과 같은 결과를 낳을 수 있습니다.
하위 문서의 콘텐츠에 대한 제어 상실기본 - 조직의 콘텐츠 보호 불가능, 브랜드 손상 및 신뢰 상실에 대한 부정적인 언론.
의심하지 않는 방문자로부터 쿠키 수집 - 웹앱이 세션 쿠키를 subdo기본s(*.contoso.com)에 노출하는 것이 일반적입니다. 모든 하위 기본 액세스할 수 있습니다. 위협 행위자는 하위 도메인 인수를 사용하여 진짜처럼 보이는 페이지를 빌드하고 의심하지 않는 사용자가 방문하도록 유도하여 쿠키를(심지어 보안 쿠키까지) 수집할 수 있습니다. 일반적인 오해는 SSL 인증서 사용이 사이트 및 사용자의 쿠키를 인수로부터 보호한다는 것입니다. 그러나 위협 행위자는 하이재킹된 하위 도메인을 사용하여 유효한 SSL 인증서를 신청하고 발급받을 수 있습니다. 유효한 SSL 인증서는 위협 행위자에게 보안 쿠키에 대한 액세스 권한을 부여하며 악성 사이트를 더 진짜처럼 보이게 할 수 있습니다.
피싱 캠페인 - 악의적인 행위자는 피싱 캠페인에서 본격적인 하위 기본 악용하는 경우가 많습니다. 위험은 악의적인 웹 사이트와 MX 레코드로 확장되며, 이를 통해 위협 행위자는 신뢰할 수 있는 브랜드와 관련된 합법적인 하위 기본 이메일을 받을 수 있습니다.
추가 위험 - 악성 사이트는 XSS, CSRF, CORS 바이패스 등 다른 클래식 공격으로 에스컬레이션하는 데 이용될 수 있습니다.
현수 DNS 항목 식별
조직에서 현수 DNS 항목을 식별하려면 Microsoft의 GitHub 호스팅 PowerShell 도구 'Get-DanglingDnsRecords'를 사용합니다.
Azure 고객은 이 도구를 사용하여 구독 또는 테넌트에서 만든 기존 Azure 리소스에 연결된 CNAME이 있는 모든 도메인을 나열할 수 있습니다.
CNAME이 다른 DNS 서비스에 있고 Azure 리소스를 가리키는 경우 입력 파일의 CNAME을 도구에 제공합니다.
이 도구는 다음 표에 나열된 Azure 리소스를 지원합니다. 도구는 모든 테넌트의 CNAME을 추출하거나 입력으로 사용합니다.
| 서비스 | Type | FQDNproperty | 예시 |
|---|---|---|---|
| Azure Front Door | microsoft.network/frontdoors | properties.cName | abc.azurefd.net |
| Azure Blob Storage | microsoft.storage/storageaccounts | properties.primaryEndpoints.blob | abc.blob.core.windows.net |
| Azure CDN | microsoft.cdn/profiles/endpoints | properties.hostName | abc.azureedge.net |
| 공용 IP 주소 | microsoft.network/publicipaddresses | properties.dnsSettings.fqdn | abc.EastUs.cloudapp.azure.com |
| Azure Traffic Manager | microsoft.network/trafficmanagerprofiles | properties.dnsConfig.fqdn | abc.trafficmanager.net |
| Azure Container Instance | microsoft.containerinstance/containergroups | properties.ipAddress.fqdn | abc.EastUs.azurecontainer.io |
| Azure API Management | microsoft.apimanagement/service | properties.hostnameConfigurations.hostName | abc.azure-api.net |
| Azure App Service | microsoft.web/sites | properties.defaultHostName | abc.azurewebsites.net |
| Azure App Service - 슬롯 | microsoft.web/sites/slots | properties.defaultHostName | abc-def.azurewebsites.net |
필수 조건
다음 권한을 가진 사용자로 쿼리를 실행합니다.
- Azure 구독에 대한 읽기 권한자 수준 이상의 액세스 권한
- Azure Resource Graph에 대한 읽기 액세스 권한
조직의 테넌트의 전역 관리 주체인 경우 권한 상승 액세스의 지침에 따라 모든 Azure 구독 및 관리 그룹을 관리하여 조직의 모든 구독에 대한 액세스 권한을 얻습니다.
팁
Azure Resource Graph에는 Azure 환경이 클 경우 고려해야 하는 제한 및 페이징 제한이 있습니다.
대규모 Azure 리소스 데이터 세트 작업에 대해 자세히 알아보세요.
이 도구는 구독 일괄 처리를 사용하여 이러한 제한 사항을 방지합니다.
스크립트 실행
PowerShell 스크립트 Get-DanglingDnsRecords.ps1에 대해 자세히 알아보고 GitHub에서 다운로드하세요. https://aka.ms/Get-DanglingDnsRecords.
현수 DNS 항목 수정
DNS 영역을 검토하고 매달려 있거나 인계되는 CNAME 레코드를 식별합니다. 하위 도메인이 현수 항목 또는 인수된 것으로 확인되는 경우 다음 단계를 통해 취약한 하위 도메인을 제거하고 위험을 완화합니다.
DNS 영역에서 더 이상 프로비전되지 않는 리소스의 FQDN을 가리키는 모든 CNAME 레코드를 제거합니다.
트래픽을 컨트롤의 리소스로 라우팅할 수 있도록 하려면 현수 하위 작업의 CNAME 레코드에 지정된 FQDN을 사용하여 더 많은 리소스를 프로비전합니다기본.
애플리케이션 코드에서 특정 하위 도메인에 대한 참조를 검토하여 잘못되었거나 오래된 하위 도메인 참조를 업데이트합니다.
손상이 발생했는지 조사하고 조직의 인시던트 대응 절차에 따라 조치를 취합니다. 팁 및 조사 모범 사례:
애플리케이션 논리로 인해 OAuth 자격 증명과 같은 비밀이 발생하거나, 현수 하위 기본 전송되거나, 개인 정보 보호에 민감한 정보가 해당 하위 기본 전송되는 경우 이 데이터가 제3자에게 노출될 가능성이 있습니다.
리소스가 프로비전 해제되었을 때 CNAME 레코드가 DNS 영역에서 제거되지 않은 이유를 파악하고 나중에 Azure 리소스를 프로비전 해제할 때 DNS 레코드가 적절하게 업데이트되도록 조치를 취합니다.
현수 DNS 항목 방지
조직에서 현수 DNS 항목 및 그로 인한 하위 도메인 인수를 방지하는 프로세스를 구현하는 것은 보안 프로그램의 중요한 부분입니다.
일부 Azure 서비스는 예방 조치를 구현하는 데 도움이 되는 기능을 제공하며 아래에 자세히 설명되어 있습니다. 이 문제를 방지하는 다른 방법은 조직의 모범 사례 또는 표준 운영 절차를 통해 정립해야 합니다.
App Service용 Microsoft Defender 사용하도록 설정
클라우드용 Microsoft Defender의 통합 CWPP(클라우드 워크로드 보호 플랫폼)는 Azure, 하이브리드 및 다중 클라우드 리소스와 워크로드를 보호하기 위한 다양한 계획을 제공합니다.
App Service용 Microsoft Defender 플랜에는 현수 DNS 검색이 포함됩니다. 이 플랜을 사용하도록 설정하면 App Service 웹 사이트를 서비스 해제했지만 DNS 등록 기관에서 해당 사용자 지정 도메인을 제거하지 않은 경우 보안 경고가 발생합니다.
클라우드용 Microsoft Defender의 현수 DNS 보호는 도메인이 Azure DNS 또는 외부 도메인 등록 대행자를 통해 관리되고 Windows 및 Linux의 App Service에 적용되는지 여부에 관계없이 사용할 수 있습니다.
App Service용 Microsoft Defender 소개에서 이 Microsoft Defender 플랜의 이점 및 기타 이점에 대해 자세히 알아봅니다.
Azure DNS 별칭 레코드 사용
Azure DNS의 별칭 레코드는 DNS 레코드의 수명 주기를 Azure 리소스와 결합하여 현수 참조를 방지합니다. 공용 IP 주소 또는 Traffic Manager 프로필을 가리키는 별칭 레코드로 정규화된 DNS 레코드를 예로 들어보겠습니다. 이러한 기본 리소스를 삭제하면 DNS 별칭 레코드가 빈 레코드 집합이 됩니다. 삭제된 리소스를 더 이상 참조하지 않습니다. 별칭 레코드로 보호할 수 있는 항목에는 제한이 있다는 점에 유의해야 합니다. 현재 이 목록은 다음으로 제한됩니다.
- Azure Front Door
- Traffic Manager 프로필
- Azure CDN(Content Delivery Network) 엔드포인트
- 공용 IP
현재 제한된 서비스 제공 사항에도 불구하고, 가능하면 항상 별칭 레코드를 사용하여 하위 도메인 인수로부터 보호할 것을 권장합니다.
Azure DNS의 별칭 레코드 기능에 대해 자세히 알아보세요.
Azure App Service의 사용자 지정 도메인 확인 사용
Azure App Service에 대한 DNS 항목을 만들 때 도메인 확인 ID를 사용하여 asuid.{subdomain} TXT 레코드를 만듭니다. 이러한 TXT 레코드가 있는 경우 다른 Azure 구독이 사용자 지정 도메인을 확인, 즉 인수할 수 없습니다.
이러한 레코드는 다른 사용자가 CNAME 항목에 있는 것과 동일한 이름을 사용하여 Azure App Service를 만드는 것을 방지하지 않습니다. 도메인 이름의 소유권을 증명할 수 없으면 위협 행위자는 트래픽을 수신하거나 콘텐츠를 제어할 수 없습니다.
기존 사용자 지정 DNS 이름을 Azure App Service에 매핑하는 방법을 자세히 알아보세요.
위협을 완화하는 프로세스 구축 및 자동화
일반적으로 현수 DNS 위협을 방지하기 위해 정리 프로세스를 실행하는 것은 개발자 및 운영 팀 몫이 될 것입니다. 다음 관행은 조직이 이 위협으로부터의 피해를 방지하는 데 도움이 됩니다.
예방 절차 구축:
애플리케이션 개발자에게 리소스를 삭제할 때마다 주소를 다시 라우팅하도록 교육합니다.
서비스를 해제할 때 필수 검사 목록에 'DNS 항목 제거'를 포함합니다.
사용자 지정 DNS 항목이 있는 모든 리소스에 삭제 잠금을 설정합니다. 삭제 잠금은 리소스가 프로비전 해제되기 전에 매핑을 제거해야 함을 나타내는 표시기 역할을 합니다. 이와 같은 조치는 내부 교육 프로그램과 함께 사용할 경우에만 유효할 수 있습니다.
검색 절차 구축:
DNS 레코드를 정기적으로 검토하여 하위 도메인이 모두 Azure 리소스에 매핑되는지 확인합니다.
- 존재 - *.azurewebsites.net 또는 *.cloudapp.azure.com 같은 Azure 하위 도메인을 가리키는 리소스의 DNS 영역을 쿼리합니다(Azure 도메인의 참조 목록 참조).
- 소유 - DNS 하위 도메인이 대상으로 하는 모든 리소스를 소유하는지 확인합니다.
Azure FQDN(정규화된 도메인 이름) 엔드포인트 및 애플리케이션 소유자의 서비스 카탈로그를 유지 관리합니다. 서비스 카탈로그를 빌드하려면 다음 Azure Resource Graph 쿼리 스크립트를 실행합니다. 이 스크립트는 사용자가 액세스할 수 있는 리소스의 FQDN 엔드포인트 정보를 프로젝션하고 CSV 파일로 출력합니다. 테넌트의 모든 구독에 대한 액세스 권한이 있는 경우 스크립트는 다음 샘플 스크립트와 같이 해당 구독을 모두 고려합니다. 결과를 특정 구독 집합으로 제한하려면 스크립트를 다음과 같이 편집합니다.
수정 절차 구축:
- 현수 DNS 항목이 발견되면 팀에서 손상이 발생했는지 여부를 조사해야 합니다.
- 리소스를 서비스 해제할 때 주소가 다시 라우팅되지 않은 이유를 조사합니다.
- 더 이상 사용하지 않는 경우 DNS 레코드를 삭제하거나 조직에서 소유한 올바른 Azure 리소스(FQDN)를 가리키도록 합니다.
DNS 포인터 정리 또는 DNS 다시 클레임
기존 클라우드 서비스 리소스를 삭제하면 Azure DNS 정책에 따라 해당 DNS가 예약됩니다. 예약 기간 동안 DNS를 원래 소유한 구독의 Microsoft Entra 테넌트에 속하는 구독을 제외하고 DNS의 재사용은 사용할 수 없습니다. 예약이 만료되면 모든 구독에서 DNS를 무료로 요청할 수 있습니다. DNS 예약을 통해 고객은 1) 해당 DNS에 대한 연결/포인터를 정리하거나 2) Azure에서 DNS를 회수할 수 있는 시간이 주어집니다. 원치 않는 DNS 항목을 가장 일찍 삭제하는 것이 좋습니다. 예약 중인 DNS 이름은 해당 클라우드의 DNS 영역에 클라우드 서비스 이름을 추가하여 파생될 수 있습니다.
- 공용 - cloudapp.net
- Mooncake - chinacloudapp.cn
- Fairfax - usgovcloudapp.net
- BlackForest - azurecloudapp.de
예를 들어, "test"라는 이름의 공용 호스티드 서비스는 DNS "test.cloudapp.net"을 갖게 됩니다.
예: 구독 'A' 및 구독 'B'는 Microsoft Entra 테넌트 'AB'에 속하는 유일한 구독입니다. 구독 'A'에는 DNS 이름이 'test.cloudapp.net'인 클래식 클라우드 서비스 'test'가 포함되어 있습니다. 클라우드 서비스 삭제 시 'test.cloudapp.net'이라는 DNS 이름으로 예약이 진행됩니다. 예약 기간 동안 구독 'A' 또는 구독 'B'만 'test'라는 클래식 클라우드 서비스를 만들어 DNS 이름 'test.cloudapp.net'을 요청할 수 있습니다. 다른 구독은 이를 클레임할 수 없습니다. 예약 기간이 지나면 Azure의 모든 구독은 이제 'test.cloudapp.net'을 클레임할 수 있습니다.
다음 단계
하위 도메인 인수로부터 보호하는 데 사용할 수 있는 관련 서비스 및 Azure 기능에 대해 자세히 알아보려면 다음 페이지를 참조하세요.