Subdomain Takeover: Cách Tìm và Khắc phục Dangling DNS trước khi Hacker ra tay

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Bản ghi 3.000 USD bị bỏ quên: Tại sao việc dọn dẹp DNS lại quan trọng

Lúc đó là 2 giờ sáng khi điện thoại của tôi rung lên vì một cảnh báo nghiêm trọng. Một thợ săn tiền thưởng lỗ hổng (bug bounty hunter) vừa gửi báo cáo: họ đã chiếm quyền điều khiển thành công subdomain marketing-campaign-2022.ourcompany.com.

Việc khắc phục chỉ mất năm phút, nhưng thực tế đằng sau đó thật đáng suy ngẫm. Chúng tôi đã ngừng hoạt động một AWS S3 bucket cũ từ sáu tháng trước, nhưng bản ghi CNAME trong hệ thống DNS vẫn trỏ vào vùng không gian trống đó. Nhà nghiên cứu chỉ đơn giản là đăng ký tên bucket đó trong tài khoản AWS của chính họ, và ngay lập tức, họ đã sở hữu một phần hạ tầng chính thức của chúng tôi.

Subdomain takeover xảy ra khi một bản ghi DNS trỏ đến một tài nguyên không còn tồn tại. Điều này thường được gọi là “dangling DNS” (DNS treo). Kẻ tấn công tìm kiếm các bản ghi này để xác nhận quyền sở hữu tài nguyên đã hết hạn trên các nhà cung cấp như AWS, GitHub hoặc Azure. Một khi kiểm soát được điểm cuối (endpoint), chúng có thể lưu trữ các trang web lừa đảo, đánh cắp cookie phiên thông qua quyền truy cập cấp domain hoặc vượt qua Chính sách bảo mật nội dung (CSP). Chỉ riêng trong năm 2023, các lỗ hổng này đã chiếm một phần đáng kể trong các khoản chi trả bug bounty mức độ nghiêm trọng cao.

Quản lý mười bản ghi thì đơn giản. Nhưng quản lý 5.000 bản ghi trên ba nhà cung cấp đám mây khác nhau là một công thức dẫn đến thảm họa.

Nếu quy trình ngừng hoạt động (decommissioning) của bạn không bao gồm bước dọn dẹp DNS, bạn đang thực sự để cửa trước không khóa. Trong khi thiết lập môi trường giám sát, tôi đã sử dụng trình tạo mật khẩu tại toolcraft.app/vi/tools/security/password-generator để tạo thông tin xác thực root an toàn. Nó tạo mọi thứ cục bộ trong trình duyệt của bạn, giữ cho các khóa của bạn không bị lộ trên mạng trong khi bạn vá lại vành đai bảo mật của mình.

Xây dựng bộ công cụ phát hiện

Kiểm tra thủ công sẽ không hiệu quả khi bạn phải đối mặt với cơ sở hạ tầng khổng lồ. Chúng ta cần một quy trình tự động hóa việc tìm kiếm và xác minh. Chiến lược của chúng ta dựa trên hai công cụ tiêu chuẩn trong ngành: Subfinder để tìm các subdomain ẩn và Nuclei để xác minh xem chúng có thực sự dễ bị tấn công hay không.

Điều kiện tiên quyết

Tôi khuyên bạn nên chạy các công cụ này trên một VPS bảo mật chuyên dụng. Bạn sẽ cần cài đặt Go, vì hầu hết các công cụ DNS hiệu suất cao đều được xây dựng bằng ngôn ngữ này. Một thực thể Ubuntu 22.04 cơ bản với 2GB RAM là đủ để quét một tổ chức quy mô trung bình.

# Cài đặt Go trên Ubuntu/Debian
sudo apt update
sudo apt install golang -y

# Thiết lập đường dẫn môi trường
echo 'export GOPATH=$HOME/go' >> ~/.bashrc
echo 'export PATH=$PATH:$GOPATH/bin' >> ~/.bashrc
source ~/.bashrc

Cài đặt các công cụ cốt lõi

Subfinder cực kỳ mạnh mẽ trong việc tìm kiếm thụ động bằng cách truy vấn hàng chục nguồn như Censys và Shodan. Nuclei sau đó sẽ lấy danh sách đó và chạy các kiểm tra dựa trên chữ ký (signature). Nó tìm kiếm các chuỗi lỗi cụ thể, chẳng hạn như “There isn’t a GitHub Pages site here” hoặc “The specified bucket does not exist,” vốn là dấu hiệu của một cơ hội takeover.

# Cài đặt Subfinder để tìm kiếm subdomain
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

# Cài đặt Nuclei để quét lỗ hổng
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Tải các mẫu (templates) mới nhất từ cộng đồng
nuclei -ut

Tự động hóa quy trình giám sát

Bảo mật không phải là sự kiện diễn ra một lần; đó là một quá trình liên tục. Cơ sở hạ tầng thay đổi hàng ngày khi các nhà phát triển tạo mới và hủy bỏ các môi trường. Chúng ta cần một script đóng vai trò như một người giám sát định kỳ, cảnh báo ngay khi một bản ghi trở nên “dangling”.

Script tìm kiếm

Tạo một tệp có tên scan_takeovers.sh. Script này tự động hóa việc chuyển giao kết quả từ bước tìm kiếm sang bước kiểm tra khai thác. Nó lưu kết quả vào một thư mục có đóng dấu thời gian để dễ dàng kiểm tra sau này.

#!/bin/bash

DOMAIN=$1
OUTPUT_DIR="./scans/$DOMAIN"
mkdir -p $OUTPUT_DIR

echo "[+] Bắt đầu tìm kiếm subdomain cho $DOMAIN..."
subfinder -d $DOMAIN -o $OUTPUT_DIR/subdomains.txt

echo "[+] Đang kiểm tra nguy cơ takeover bằng hơn 500 mẫu..."
nuclei -l $OUTPUT_DIR/subdomains.txt -t takeovers/ -o $OUTPUT_DIR/takeovers_found.txt

if [ -s $OUTPUT_DIR/takeovers_found.txt ]; then
    echo "[!] CẢNH BÁO: Phát hiện các nguy cơ subdomain takeover!"
    cat $OUTPUT_DIR/takeovers_found.txt
else
    echo "[+] Không phát hiện nguy cơ takeover. DNS sạch."
fi

Cấp quyền thực thi cho script bằng lệnh chmod +x scan_takeovers.sh. Bạn có thể dễ dàng sửa đổi khối if để gửi Slack webhook hoặc email nếu tệp takeovers_found.txt không trống.

Lọc các kết quả dương tính giả

Không phải mọi lỗi 404 đều là lỗ hổng. Một số nền tảng, như GitLab hoặc các dịch vụ Azure mới hơn, hiện yêu cầu bản ghi DNS TXT để xác minh tên miền trước khi bạn có thể xác nhận quyền sở hữu subdomain. Các mẫu của Nuclei được cập nhật thường xuyên để lọc bỏ các trường hợp này, nhưng bạn nên luôn thử “xác nhận” tài nguyên đó trong một tài khoản cá nhân trước khi tuyên bố đó là tình trạng khẩn cấp nghiêm trọng.

Các phương pháp hay nhất để phòng thủ lâu dài

Khi bạn đã dọn dẹp xong các bản ghi treo hiện tại, mục tiêu là ngăn chúng xuất hiện trở lại. Tự động hóa là lưới an toàn, nhưng quy trình nội bộ mới là phương thuốc thực sự. Đây là cách tôi cấu trúc quy trình làm việc của nhóm mình để giữ hệ thống luôn sạch:

  • Infrastructure as Code (IaC): Nếu bạn sử dụng Terraform để triển khai một S3 bucket và bản ghi Route53 của nó, hãy giữ chúng trong cùng một module. Khi bucket bị hủy, bản ghi DNS cũng phải được tự động xóa bỏ.
  • Quản lý DNS tập trung: Đừng để các nhóm riêng lẻ quản lý DNS trong các tài khoản tách biệt. Hãy sử dụng một tài khoản trung tâm hoặc một công cụ như Cloudflare để duy trì một nguồn dữ liệu xác thực duy nhất.
  • Kiểm tra định kỳ hàng quý: Cứ ba tháng một lần, hãy chạy script để đối chiếu các tài nguyên đám mây đang hoạt động với các tệp vùng DNS của bạn. Bất kỳ CNAME nào trỏ đến một nhà cung cấp bên ngoài mà không nằm trong danh mục tài nguyên đang hoạt động của bạn đều phải được gắn cờ ngay lập tức.

DNS thường là một nhiệm vụ theo kiểu “thiết lập rồi quên luôn”, nhưng tư duy đó là một rủi ro lớn trong thế giới ưu tiên đám mây (cloud-first). Bằng cách tự động hóa việc tìm kiếm và tích hợp nó vào các bước kiểm tra bảo mật hàng ngày, bạn sẽ biến một công việc thủ công rủi ro cao thành một quy trình chạy ngầm. Điều này giúp thương hiệu của bạn được bảo vệ trong khi đội ngũ tập trung vào việc xây dựng, thay vì đi dập lửa.

Share: