Certificate Transparency: Vì sao mọi subdomain của bạn đều công khai

Certificate Transparency logs thực sự là gì?

Mọi chứng chỉ TLS được các tổ chức tin cậy công khai cấp hiện nay đều phải được công bố lên Certificate Transparency (CT) log trước khi trình duyệt chấp nhận mà không hiển thị cảnh báo. Chrome đã áp dụng quy định này từ năm 2018; các nền tảng của Apple cũng thực hiện tương tự. Đây là những Merkle tree chỉ cho phép ghi thêm (append-only), được vận hành bởi các công ty như Let's Encrypt (Sunlight), Google (Argon), Cloudflare (Raio), DigiCert và Sectigo. Một CA không thể âm thầm cấp chứng chỉ cho staging.yourcompany.com rồi giữ nó ngoài hồ sơ công khai — Signed Certificate Timestamp mà trình duyệt yêu cầu là bằng chứng chứng chỉ đó đã nằm trong một trong các log này.

CT được xây dựng để phát hiện chứng chỉ bị cấp sai hoặc gian lận, chứ không phải để làm danh bạ subdomain. Tuy nhiên, hệ quả của nó là vĩnh viễn: trường SAN (Subject Alternative Name) của mọi chứng chỉ đều công khai, và trường này liệt kê tất cả hostname mà chứng chỉ bao phủ. Một wildcard cert cho *.yourcompany.com hoặc chứng chỉ SAN bao phủ năm công cụ nội bộ sẽ đưa cả năm hostname đó vào hồ sơ vĩnh viễn, bất kể chúng có từng xuất hiện trong DNS công khai, sitemap hay kết quả tìm kiếm Google hay không.

Đây là điểm nhiều người thường đánh giá thấp. Việc không đưa một subdomain vào zone transfer hoặc không liên kết nó trên website công khai không giúp subdomain đó biến mất khỏi CT logs — nếu nó từng sử dụng HTTPS, nó đã được ghi lại. Môi trường dev, trang quản trị, API nội bộ và endpoint tích hợp bên thứ ba: chỉ cần có người yêu cầu cấp chứng chỉ cho chúng là thông tin đã nằm trong log.

Cách truy vấn CT logs thủ công cho một domain

crt.sh, do Sectigo vận hành, là giao diện được nhiều người sử dụng đầu tiên. Truy vấn trên trình duyệt có dạng https://crt.sh/?q=%.example.com, đồng thời công cụ này cũng cung cấp JSON endpoint để chạy script:

curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -u

Một dòng lệnh này là cách nhanh nhất để lấy danh sách subdomain thô từ command line — không cần đăng ký, API key hay brute-force DNS. crt.name cũng bao phủ phạm vi tương tự nhưng được thiết kế theo hướng API-first: GET https://crt.name/v1/search?apex=example.com trả về danh sách phẳng gồm mọi subdomain mà chỉ mục đang lưu, được tạo bằng cách phân tích các trường SAN từ Static CT đang hoạt động và các mục log cũ theo RFC 6962 ngay khi chúng xuất hiện, sau đó bổ sung các hostname cũ từ log được phát lại, Common Crawl và nguồn zone file. Ưu điểm của crt.name so với crt.sh khi tự động hóa là không cần scrape HTML và không gặp bất ngờ về rate limit với một yêu cầu GET thông thường.

Hãy chạy một trong hai truy vấn trên với domain lớn và bạn sẽ nhận thấy ngay một điều: danh sách có cả những chứng chỉ được cấp từ hàng chục năm trước cho các dịch vụ không còn tồn tại. CT logs chỉ cho phép ghi thêm — không có dữ liệu nào bị xóa, vì vậy kết quả truy vấn phản ánh lịch sử chứ không chỉ những gì đang hoạt động. Điều này hữu ích cho recon và đôi khi cũng khiến chủ domain khá khó xử.

crt.sh, crt.name, subfinder và amass: nên dùng công cụ nào?

Những công cụ này thực ra không cạnh tranh trực tiếp với nhau — chúng nằm ở các vị trí khác nhau trên trục tốc độ và độ bao phủ, đồng thời một quy trình thực tế thường sử dụng nhiều hơn một công cụ.

Để kiểm tra nhanh một domain, crt.sh hoặc crt.name là đủ. Với bài toán lập bản đồ attack surface thực sự — chẳng hạn trước một đợt đánh giá mức độ sẵn sàng cho agent hoặc đánh giá bảo mật — hãy bắt đầu bằng subfinder để có tốc độ, sau đó chạy amass nếu target đủ lớn để việc bỏ sót subdomain trở nên đáng kể.

Danh sách này thực sự được dùng vào việc gì?

Bản thân danh sách subdomain không đồng nghĩa với một vụ xâm nhập. Điều thay đổi là điểm xuất phát của kẻ tấn công: thay vì phải đoán hạ tầng của bạn, họ có ngay inventory theo hostname để bắt tay vào các bước có mục tiêu.

• Tìm các mục tiêu dễ tấn công trước. Các subdomain như admin., staging., internal-api. và vpn. thường chạy phần mềm cũ hơn, cơ chế xác thực yếu hơn hoặc cấu hình mặc định, vì “không ai biết URL” từng được xem là toàn bộ mô hình bảo mật.
• Chiếm quyền subdomain. Nếu một subdomain đã xuất hiện trong CT vẫn phân giải qua CNAME tới một dịch vụ cloud đã ngừng hoạt động (chẳng hạn S3 bucket cũ, ứng dụng Heroku đã xóa hoặc SaaS bên thứ ba hết sử dụng), kẻ tấn công thường có thể đăng ký tài nguyên đó và phân phối nội dung từ subdomain của bạn — cùng lịch sử chứng chỉ và mức độ tin cậy của domain.
• Phishing trông có vẻ hợp lệ. Danh sách hostname mang dáng dấp hệ thống nội bộ sẽ khiến trang đăng nhập giả mạo hoặc email spear-phishing thuyết phục hơn nhiều so với một hostname đoán ngẫu nhiên.
• Ưu tiên quét lỗ hổng. Mỗi hostname được phát hiện là thêm một entry point để fingerprint và probe — CT logs biến passive recon thành danh sách mục tiêu mà không cần gửi bất kỳ packet nào đến hệ thống của bạn.

Biến chính kỹ thuật này thành công cụ phòng thủ

Bạn không thể ngăn chứng chỉ của mình được ghi vào log, và cũng không nên muốn làm vậy — CT chính là cơ chế giúp phát hiện chứng chỉ gian lận được cấp cho domain của bạn ngay từ đầu. Cách làm đúng là giám sát cùng nguồn dữ liệu mà kẻ tấn công truy vấn, để bạn phát hiện subdomain và chứng chỉ mới trước họ.

1. Thiết lập baseline cho các subdomain hiện tại. Chạy truy vấn crt.sh hoặc crt.name trên mọi apex domain bạn sở hữu và xem kết quả là inventory tài sản thực tế, thay vì chỉ dựa vào danh sách trong wiki nội bộ.
2. Kiểm tra bản ghi DNS bị bỏ lại. Với mọi subdomain xuất hiện trong CT nhưng không còn được sử dụng, hãy xác minh bản ghi DNS của nó còn trỏ tới đâu không — một CNAME bị quên trỏ tới dịch vụ đã deprovision là nguy cơ takeover đang chờ xảy ra.
3. Thiết lập giám sát định kỳ. Cert Spotter và một số CT-log aggregator hỗ trợ cảnh báo khi có chứng chỉ mới cho domain. Nếu muốn không phụ thuộc vào bên thứ ba, bạn cũng có thể chạy truy vấn crt.sh hoặc crt.name theo lịch bằng cron job.
4. Ngừng sử dụng đúng cách. Khi loại bỏ một subdomain, hãy xóa bản ghi DNS chứ không chỉ xóa ứng dụng phía sau. Dù thế nào thì chứng chỉ vẫn nằm trong CT logs vĩnh viễn, nhưng một bản ghi DNS đã chết và không trỏ tới đâu sẽ là ngõ cụt với kẻ tấn công thay vì một cánh cửa đang mở.

Đây cũng là nền tảng passive-recon mà chúng tôi thực hiện trước khi hardening hạ tầng công khai của khách hàng — kết hợp phát hiện qua CT logs với công việc rà soát DNS và crawler-facing trong dịch vụ phát triển phần mềm tùy chỉnh và hardening bảo mật giúp phát hiện subdomain mồ côi trước khi chúng trở thành entry point.