이 글에서는 서브도메인 점령이라는 일반적인 보안 위협과 이를 완화하기 위해 취할 수 있는 조치들을 설명합니다.
하위 도메인 인수란?
서브도메인 점거는 정기적으로 많은 자원을 생성하고 삭제하는 조직에서 흔하고 심각한 위협입니다. 프로비전 해제된 Azure 리소스를 가리키는 DNS 레코드 가 있는 경우 하위 도메인 인수가 발생할 수 있습니다. 이러한 DNS 레코드는 "현수 DNS" 항목으로도 알려져 있습니다. CNAME 레코드는 특히 이 위협에 취약합니다. 하위 도메인 인수를 통해 악의적인 행위자는 조직의 도메인에 대한 트래픽을 악의적인 활동을 수행하는 사이트로 리디렉션할 수 있습니다.
서브도메인 탈취의 일반적인 시나리오:
창작:
app-contogreat-dev-001.azurewebsites.net의 완전한 도메인 이름(FQDN)을 가진 Azure 리소스를 프로비저닝합니다.Azure 리소스에 트래픽을 라우팅하는 하위 도메인
greatapp.contoso.com을 사용하여 DNS 영역에 CNAME 레코드를 할당합니다.
프로비전 해제:
Azure 리소스는 더 이상 필요하지 않게 되면 디프로비저닝되거나 삭제됩니다.
이 시점에서 CNAME 레코드는 DNS 영역에서
greatapp.contoso.com제거되어야 합니다. CNAME 레코드가 제거되지 않으면 활성 도메인으로 광고되지만 활성 Azure 리소스로 트래픽을 라우팅하지는 않습니다. 이제 “dangling” DNS 레코드가 생깁니다.이제
greatapp.contoso.com의 남아 있는 하위 도메인은 취약해졌으며, 다른 Azure 구독의 리소스에 할당되어 탈취될 수 있습니다.
인수:
일반적으로 널리 사용되는 방법과 도구를 사용해 위협 행위자가 이 dangling 서브도메인을 발견합니다.
위협 행위자가 이전에 사용자가 관리하던 리소스와 동일한 FQDN을 가진 Azure 리소스를 프로비저닝합니다. 이 예제에서 해당 이름은
app-contogreat-dev-001.azurewebsites.net입니다.서브도메인
greatapp.contoso.com으로 전송된 트래픽은 이제 악의적인 행위자의 자원으로 라우팅되어 그들이 콘텐츠를 통제합니다.
하위 도메인 위험의 인수
DNS 레코드가 더 이상 사용할 수 없는 리소스를 가리키는 경우 해당 레코드는 DNS 영역에서 제거해야 합니다. 삭제되지 않으면 “dangling DNS” 레코드가 되며 서브도메인 탈취 가능성이 생깁니다.
Dangling DNS 항목은 위협 행위자가 연결된 DNS 이름을 장악해 악성 웹사이트나 서비스를 호스팅할 수 있게 만듭니다. 조직의 서브도메인에 있는 악성 페이지나 서비스는 다음과 같은 결과를 초래할 수 있습니다.
서브도메인 콘텐츠에 대한 통제권 상실: 조직이 콘텐츠 보안 실패, 브랜드 손상, 신뢰 상실에 대한 부정적인 언론 보도.
무심한 방문자로부터 쿠키 수집: 웹 앱이 세션 쿠키를 서브도메인(*.contoso.com)에 노출하는 경우가 흔합니다. 모든 하위 도메인에서 쿠키에 액세스할 수 있습니다. 위협 행위자들은 서브도메인 장악을 이용해 진짜처럼 보이는 페이지를 만들고, 아무것도 모르는 사용자를 속여 방문하게 하며, 그들의 쿠키(심지어 보안 쿠키도 포함)를 수집할 수 있습니다. 흔히 오해하는 것은 SSL 인증서가 사이트와 사용자의 쿠키를 탈취로부터 보호한다는 것입니다. 그러나 위협 행위자는 하이재킹된 하위 도메인을 사용하여 유효한 SSL 인증서를 신청하고 발급받을 수 있습니다. 유효한 SSL 인증서는 보안 쿠키에 대한 접근을 가능하게 하며, 악성 사이트가 더 합법적인 것처럼 보이게 만들어 신뢰도를 더욱 높일 수 있습니다.
피싱 캠페인: 악의적인 행위자들은 종종 진짜처럼 보이는 하위 도메인을 이용해 피싱 캠페인을 이용합니다. 위험은 악성 웹사이트와 MX 기록 모두에 미칩니다. MX 기록은 위협 행위자가 신뢰할 수 있는 브랜드와 연관된 합법적인 하위 도메인으로 향한 이메일을 받을 수 있게 할 수 있습니다.
추가 위험: 악성 사이트는 XSS, CSRF, CORS 우회 등 다른 고전적인 공격으로 확대될 수 있습니다.
현수 DNS 항목 식별
조직 내에서 늘어져 있을 수 있는 DNS 항목을 식별하려면 Microsoft의 GitHub에 호스팅된 PowerShell 도구 "Get-DanglingDnsRecords"를 사용합니다.
이 도구는 구독이나 테넌트에서 생성한 기존 Azure 리소스와 연관된 CNAME이 있는 모든 도메인을 나열하는 데 도움을 줍니다.
CNAME이 다른 DNS 서비스에 있고 Azure 리소스를 가리키는 경우 입력 파일의 CNAME을 도구에 제공합니다.
이 도구는 다음 표에 나열된 Azure 리소스를 지원합니다. 도구는 모든 테넌트의 CNAME을 추출하거나 입력으로 사용합니다.
| 서비스 | 유형 | FQDN 속성 | 예제 |
|---|---|---|---|
| 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 네트워크/공개 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 Instances | 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 구독에 대해 최소한
Reader역할의 액세스 권한이 필요합니다. - Azure Resource Graph에 대한 읽기 액세스 권한.
조직 테넌트의 글로벌 관리자라면, Elevate access의 지침을 따라 모든 Azure 구독과 관리 그룹을 관리하여 조직의 모든 구독에 접근할 수 있도록 하세요.
팁
Azure 환경이 큰 경우 Azure Resource Graph의 스로틀링 및 페이징 제한을 고려하세요.
대규모 Azure 리소스 데이터 집합 작업에 대해 자세히 알아봅니다.
이 도구는 이러한 제한을 피하기 위해 구독 단위로 일괄 처리를 사용합니다.
스크립트 실행
PowerShell 스크립트에 대한 자세한 내용은 Get-DanglingDnsRecords.ps1를 참조하세요.
현수 DNS 항목 수정
DNS 영역을 검토하고 연결이 끊긴 CNAME 레코드나 탈취될 수 있는 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에 적용됩니다.
이 기능과 Microsoft Defender 계획의 기타 이점에 대한 자세한 내용은 'Microsoft Defender for App Service' 소개를 참조하세요.
Azure DNS별칭 레코드 사용
Azure DNS 별칭 레코드는 DNS 레코드의 수명 주기를 Azure 리소스와 결합하여 지연된 참조를 방지할 수 있습니다. 예를 들어, 공용 IP 주소나 Traffic Manager 프로필을 가리키는 별칭 DNS 레코드를 생각해 볼 수 있습니다. 해당 기본 리소스를 삭제하면, DNS 별칭 레코드는 빈 레코드 집합이 됩니다. DNS 별칭 레코드는 더 이상 삭제된 자원을 참조하지 않습니다. 별명 기록에는 보호할 수 있는 범위에 한계가 있습니다. 현재 목록은 다음과 같이 제한되어 있습니다:
- Azure Front Door
- Traffic Manager 프로필
- Azure Content Delivery Network(CDN) 엔드포인트
- 공용 IP
오늘날 제공되는 서비스가 제한적임에도 불구하고, 가능한 한 서브도메인 탈취를 막기 위해 별명 기록을 사용하세요.
자세한 내용은 Azure DNS 별칭 기록 기능을 참조하세요.
Azure App Service의 사용자 지정 도메인 검증 기능을 사용하세요.
Azure App Service에서 DNS 항목을 생성할 때, 도메인 검증 ID가 포함된 TXT 레코드를 asuid.{subdomain} 생성하세요. 이러한 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, Azure 포털 또는 다른 자산 인벤토리 프로세스를 사용하여 접근할 수 있는 자원의 FQDN 엔드포인트 정보를 정기적으로 내보내세요. 테넌트 내 모든 구독에 접근할 수 있다면, 인벤토리에 모든 구독을 포함시키세요. 만약 없다면, 재고가 포함하는 구독 항목을 문서화하세요.
수정 절차를 만듭니다.
- 팀이 미해결 DNS 항목을 발견하면, 침해가 발생했는지 조사하세요.
- 리소스가 종료될 때 주소가 다른 경로로 전환되지 않은 이유를 조사하세요.
- 더 이상 사용하지 않는 DNS 레코드는 삭제하고, 필요할 경우 조직이 소유한 올바른 Azure 리소스(FQDN)를 가리키도록 수정하세요.
DNS 포인터를 정리하거나 DNS를 되찾으세요
클래식 클라우드 서비스 리소스를 삭제하면, Azure는 Azure DNS 정책에 따라 해당 DNS 이름을 예약합니다. 예약 기간 동안, 원래 DNS 이름을 소유한 구독의 Microsoft Entra 테넌트에 속한 구독만 재사용할 수 있습니다. 예약이 만료되면 모든 Azure 구독자가 DNS 이름을 청구할 수 있습니다. DNS 예약은 연결 상태를 정리하거나 DNS 이름으로 가는 포인터를 정리하거나 Azure에서 DNS 이름을 되찾을 시간을 줍니다. 원하지 않는 DNS 항목은 가능한 빨리 삭제하세요. 예약된 DNS 이름은 해당 클라우드의 DNS 존에 클라우드 서비스 이름을 추가하여 도출할 수 있습니다.
- 퍼블릭:
cloudapp.net - 월병:
chinacloudapp.cn - 페어팩스:
usgovcloudapp.net - 블랙포레스트:
azurecloudapp.de
예를 들어, Public test 이름의 호스팅 서비스는 DNS 이름 test.cloudapp.net이 있습니다.
예: A 및 B 구독만 Microsoft Entra 테넌트 AB에 속합니다. 구독에는 A DNS 이름test으로 지정된 test.cloudapp.net 클래식 클라우드 서비스가 포함되어 있습니다. 클라우드 서비스를 삭제하면 Azure가 DNS 이름을 test.cloudapp.net예약합니다. 예약 기간 동안에는 구독 A 또는 구독 B만이 test.cloudapp.net라는 이름의 클래식 클라우드 서비스를 만들어 DNS 이름 test을 확보할 수 있습니다. 다른 어떤 구독도 이를 차지할 수 없습니다. 예약 기간이 끝난 후에는 어떤 Azure 구독이든 청구test.cloudapp.net할 수 있습니다.
다음 단계
하위 도메인 탈취를 방어하기 위해 사용할 수 있는 관련 서비스와 Azure 기능에 대해 자세히 알아보려면, 다음 페이지를 참조하세요.