Subdomain Takeover: Hiểm họa từ bản ghi CNAME bị bỏ quên

Một chiến dịch kết thúc. Landing page bị xóa, tài khoản dịch vụ được đóng, nhưng bản ghi DNS vẫn còn. Địa chỉ từng dùng để đón khách hàng có thể tiếp tục trỏ đến một tài nguyên mà doanh nghiệp đã ngừng kiểm soát.

Nếu nền tảng cho phép người khác nhận lại tài nguyên hoặc gắn tên miền đó vào dịch vụ của họ, chính subdomain của doanh nghiệp có thể trở thành nơi phát tán nội dung lừa đảo. Kẻ tấn công không cần mua một tên miền trông gần giống thương hiệu. Họ lợi dụng cấu hình còn sót lại để đưa nội dung lên địa chỉ thật.

1. Subdomain Takeover là gì?

Subdomain Takeover là việc bên không được ủy quyền giành quyền phục vụ nội dung hoặc dịch vụ trên một tên miền con của tổ chức. Trong kịch bản CNAME bị bỏ quên, DNS vẫn trỏ đến bên thứ ba, nhưng tài nguyên hoặc cấu hình gắn tên miền ở phía nhà cung cấp đã bị bỏ.

CNAME là bản ghi tạo bí danh DNS, không phải chuyển hướng HTTP 301 hay 302. Trình duyệt vẫn truy cập hostname ban đầu; dịch vụ phía sau phải nhận diện và phục vụ hostname đó. Vì vậy, cần kiểm tra cả DNS lẫn cấu hình tiếp nhận tên miền, thường gọi là custom domain binding.

DNS, TLS và HTTP làm ba việc khác nhau

Điểm cần xác minh là nền tảng có nhận hostname của doanh nghiệp cho một tài nguyên ngoài quyền kiểm soát hay không. Một endpoint còn hoạt động chưa trả lời được câu hỏi đó.

Ví dụ minh họa, dùng các tên miền dành cho tài liệu:

promo.example.com.  300  IN  CNAME  campaign-archive.vendor.example.

Doanh nghiệp từng dùng promo.example.com cho một chương trình khuyến mại. Sau khi chương trình kết thúc, đội Marketing yêu cầu xóa landing page. Đội kỹ thuật xóa tài nguyên trên nền tảng nhưng chưa gỡ CNAME.

Bản ghi vẫn đúng cú pháp; mối liên hệ giữa tên miền và tài nguyên do doanh nghiệp sở hữu đã bị đứt.

Để biến cấu hình này thành khả năng chiếm đoạt thực tế, cần đồng thời có các điều kiện:

DNS vẫn dẫn hostname đến nền tảng liên quan.

Tài nguyên hoặc quyền gắn hostname không còn được doanh nghiệp giữ.

Bên khác có thể nhận lại tài nguyên hoặc quyền gắn hostname đó.

Nền tảng sẽ phục vụ yêu cầu gửi đến hostname của doanh nghiệp bằng tài nguyên của bên kia.

Thiếu điều kiện thứ ba hoặc thứ tư, một CNAME bị bỏ quên chưa đủ chứng minh có thể takeover. Nền tảng có thể giữ tên tài nguyên, yêu cầu xác minh quyền sở hữu hoặc ngăn tài khoản khác tái sử dụng hostname.

Phạm vi chiếm đoạt ban đầu là hostname và dịch vụ liên quan. Không thể từ đó suy ra kẻ tấn công đã có quyền sửa DNS zone, quản lý tên miền gốc hay truy cập máy chủ chính.

2. Subdomain giả mạo và subdomain chính chủ bị chiếm khác nhau thế nào?

Bài cách nhận diện tên miền giả mạo các tổ chức uy tín giúp người đọc kiểm tra tên miền thực sự đứng sau một địa chỉ. Với subdomain takeover, cần thêm một bước: xác định tên miền đúng chưa đủ để khẳng định nội dung vẫn do doanh nghiệp kiểm soát.

Giả sử tên miền chính thức là example.com:

Đây là lý do lời khuyên “chỉ bấm link có đúng domain” cần đi kèm kiểm tra ngữ cảnh. Một trang yêu cầu nhập lại mật khẩu hoặc cung cấp OTP vẫn đáng nghi, kể cả khi địa chỉ nằm dưới tên miền quen thuộc. HTTPS hợp lệ cũng chưa chứng minh nội dung đang do doanh nghiệp kiểm soát.

3. GitHub Pages, S3, Heroku và Azure: không thể áp dụng chung một kết luận

Danh sách “dịch vụ dễ takeover” chỉ có giá trị tham khảo. Khi audit, phải đối chiếu sản phẩm, loại hostname và cơ chế bảo vệ đang được dùng.

Có 3 chi tiết dễ bị bỏ qua khi audit:

Với GitHub Pages, cấu hình custom domain trong repository khác với xác minh domain ở cấp tài khoản/tổ chức. Cần giữ TXT theo hướng dẫn để duy trì trạng thái xác minh.

Với S3 shared global namespace, tên bucket sau khi xóa không được bảo đảm khả dụng ngay; có trường hợp không khả dụng trở lại. Tài liệu cũng có account regional namespace, nơi tài khoản khác không thể tạo lại tên bucket thuộc namespace của bạn. Bucket đã tạo không đổi được tên; cần đánh giá lại kiến trúc thay vì đổi tên rồi giữ nguyên CNAME.

Với Azure App Service, secure unique default hostname được thiết lập khi tạo tài nguyên và không áp dụng hồi tố. Portal tự dùng tính năng này cho tài nguyên mới được hỗ trợ; CLI/ARM/API cần bật tương ứng. Cơ chế giữ tên không phải lời bảo đảm giữ hostname vĩnh viễn.

Với Heroku, khi app bị xóa, các custom domain gắn với app được giải phóng. Vì thế, phải kiểm tra binding của custom domain, không chỉ nhìn định danh ngẫu nhiên trong hostname mặc định.

Cũng cần tách khả năng phục vụ HTTP khỏi HTTPS. S3 website endpoint không hỗ trợ HTTPS trực tiếp; nếu hệ thống có CDN hoặc lớp TLS phía trước, phải kiểm tra thêm lớp đó.

4. Subdomain Takeover gây hại SEO đến đâu?

Nội dung độc hại xuất hiện dưới địa chỉ chính chủ

Subdomain bị chiếm có thể được dùng cho trang phishing, nội dung spam hoặc chuyển hướng người dùng sang nơi khác. Nếu vẫn còn backlink, liên kết nội bộ, email cũ hay bookmark, những đường dẫn đó có thể tiếp tục đưa khách hàng đến nội dung của kẻ tấn công.

Với đội SEO, cần kiểm kê cả đường dẫn tạo ra lượt truy cập: menu, bài viết cũ, tài liệu PDF, trang đối tác và landing page đã kết thúc. Việc dọn DNS sẽ chưa giải quyết hết trải nghiệm người dùng nếu các điểm chạm này vẫn dẫn đến địa chỉ đã ngừng hoạt động.

Cảnh báo bảo mật và mất hiển thị là những hậu quả khác nhau

Google cho biết trang hoặc website có vấn đề bảo mật có thể xuất hiện cảnh báo trong kết quả tìm kiếm hoặc khi người dùng truy cập bằng trình duyệt. Nội dung bị hack cũng có thể bị loại khỏi kết quả tìm kiếm.

Google không công bố quy tắc “một subdomain bị chiếm thì toàn bộ tên miền gốc tự động bị Safe Browsing gắn cờ và de-index”. Điều này cũng không bảo đảm tên miền gốc được cách ly khỏi mọi ảnh hưởng. Muốn xác định phạm vi, phải kiểm tra hostname, URL, báo cáo bảo mật và trạng thái lập chỉ mục thực tế.

Cần phân biệt ba việc:

Security Issues: dấu hiệu bị hack, malware, phishing hoặc hành vi gây hại.

Manual Actions: tác vụ do người đánh giá của Google xác định vi phạm; báo cáo có thể nêu phạm vi một phần hoặc toàn website.

Biến động hiệu suất: giảm click, impression hoặc chuyển đổi cần điều tra nguyên nhân; riêng việc traffic giảm chưa chứng minh có hình phạt.

Nội dung được đưa lên trái phép do điểm yếu bảo mật phù hợp với định nghĩa hacked content của Google. Đây là đối chiếu định nghĩa, không phải dự đoán nhãn Google chắc chắn áp dụng cho mọi vụ takeover. Nếu có cảnh báo bảo mật hoặc tác vụ thủ công, đối chiếu nội dung và phạm vi trong báo cáo tương ứng của Search Console.

E-E-A-T không phải điểm số bị trừ theo sự cố

Một địa chỉ chính chủ dẫn đến form lừa đảo làm tổn hại niềm tin vào thương hiệu. Tuy nhiên, không nên viết rằng Google “trừ điểm E-E-A-T của toàn domain”. Google xác nhận E-E-A-T không phải một yếu tố xếp hạng cụ thể.

Công việc thực tế là bảo vệ người dùng, kiểm soát lại nội dung và cung cấp bằng chứng đã khắc phục. Bổ sung hồ sơ tác giả hay chỉnh schema không xử lý được một hostname đang phục vụ nội dung của người khác.

Đo thiệt hại SEO bằng dữ liệu nào?

Bảng dưới đây là cách phân tích đề xuất, không phải công thức xếp hạng của Google. Trước tiên, lưu các mốc: phát hiện sự cố, sửa DNS/binding, khôi phục nội dung và gửi yêu cầu xem xét. Ngày phát hiện chưa chắc là ngày bắt đầu bị chiếm.

Traffic giảm cùng thời điểm là một tín hiệu để điều tra. Chưa đủ dữ liệu thì chưa nên quy toàn bộ mức giảm hoặc chênh lệch doanh thu cho sự cố. Hướng dẫn của Google cũng yêu cầu xem xét nhiều nguyên nhân khi phân tích giảm traffic.

5. Rủi ro có thể vượt khỏi nội dung: cookie và cấu hình tin cậy

Giả sử ứng dụng đặt cookie:

Set-Cookie: session=...; Domain=example.com; Path=/; Secure; HttpOnly

Thuộc tính Domain=example.com mở phạm vi cookie tới các subdomain. Nếu người dùng truy cập hostname bị chiếm qua HTTPS hợp lệ và các điều kiện gửi cookie được đáp ứng, cookie có thể được gửi đến dịch vụ phía đó. Secure yêu cầu HTTPS; nó không xác nhận dịch vụ đang do doanh nghiệp kiểm soát.

Cookie được gửi đến dịch vụ chưa có nghĩa người chiếm nội dung chắc chắn đọc được cookie.HttpOnly vẫn ngăn JavaScript đọc cookie. Để đánh giá nguy cơ lộ cookie, phải xác minh người chiếm nội dung có khả năng quan sát request/header hoặc cơ chế truy cập phù hợp. Khả năng đó chưa chứng minh cookie của người dùng đã thực sự bị thu thập; cần thêm bằng chứng truy cập và phạm vi ảnh hưởng. Quyền sửa HTML trên một nền tảng tĩnh chưa tự chứng minh quyền đọc header Cookie.

Với cookie không cần chia sẻ giữa các host, nên cân nhắc bỏ Domain để giới hạn vào host đặt cookie. Một cấu hình minh họa:

Set-Cookie: __Host-session=...; Secure; HttpOnly; Path=/; SameSite=Lax

Tiền tố __Host- yêu cầu HTTPS, Secure, Path=/ và không có thuộc tính Domain trên trình duyệt hỗ trợ. Đây là cách giới hạn phạm vi cookie; không phải cấu hình mặc định phù hợp với mọi luồng đăng nhập.

Cùng site không có nghĩa cùng origin

https://www.example.com và https://promo.example.com là hai origin khác nhau do khác hostname, nhưng cùng site theo cách xét scheme và tên miền đăng ký. Vì thế, không thể coi SameSite là hàng rào cô lập mọi subdomain. Ngược lại, việc cùng site không tự trao quyền đọc DOM, localStorage hoặc phản hồi của origin khác.

Đội bảo mật cần kiểm tra các cấu hình đang tin cậy hostname bị ảnh hưởng:

CORS: origin đó có được phép đọc phản hồi nhạy cảm khi gửi request có thông tin xác thực không? Không dùng ví dụ Access-Control-Allow-Origin: * kết hợp credentials để kết luận có thể đọc dữ liệu, vì trình duyệt chặn truy cập phản hồi theo tổ hợp này.

OAuth: hostname có còn nằm trong redirect URI được chấp nhận không? Tác động phụ thuộc luồng xác thực và các kiểm soát liên quan. RFC 9700 yêu cầu so khớp chính xác redirect URI, có ngoại lệ về cổng localhost của ứng dụng native.

Đây là các phụ thuộc cần rà soát, không phải những quyền tự động xuất hiện sau khi một subdomain bị chiếm.

6. Cách audit: kiểm tra quyền sở hữu, không chỉ kiểm tra website còn chạy

Một subdomain trả về 200 OK vẫn có thể đang phục vụ nội dung của người khác. AWS lưu ý việc chỉ kiểm tra DNS phân giải thành công có thể bỏ sót takeover sau khi tài nguyên đã được bên khác nhận lại.

Nên bắt đầu bằng danh sách DNS do doanh nghiệp quản lý, sau đó đối chiếu với tài nguyên trên các tài khoản cloud/SaaS liên quan. Không tìm thấy tài nguyên trong một tài khoản chưa đủ kết luận bị bỏ: nó có thể nằm ở tài khoản khác hoặc bên cung cấp dịch vụ được ủy quyền. Kiểm tra cả phạm vi tài khoản và mức độ đầy đủ của dữ liệu kiểm kê.

Với mỗi hostname, tối thiểu cần có:

Chủ sở hữu nội bộ và mục đích sử dụng.

Toàn bộ chuỗi CNAME, kể cả các lớp trung gian.

Nhà cung cấp, tài khoản hoặc subscription và mã tài nguyên.

Trạng thái custom domain binding, xác minh quyền sở hữu.

Phụ thuộc liên quan: cookie, đăng nhập, API, CDN, liên kết và backlink.

Người chịu trách nhiệm cùng phương án khi ngừng sử dụng.

Có thể dùng các lệnh chỉ đọc sau để kiểm tra sơ bộ trên tên miền thuộc phạm vi quản lý:

dig +noall +answer promo.example.com CNAME
dig +noall +answer promo.example.com A
dig +noall +answer promo.example.com AAAA
curl -I --connect-timeout 5 --max-time 10 https://promo.example.com/

Nếu dùng DNS proxy, CDN hoặc CNAME flattening, truy vấn công khai có thể không hiển thị CNAME gốc; cần đối chiếu cấu hình trong hệ thống quản trị DNS.

Các lệnh này cung cấp dữ liệu DNS và phản hồi HTTP ban đầu. Chúng không xác nhận tài nguyên đang thuộc tài khoản nào; curl -I cũng không kiểm tra nội dung trang.

Nên phân loại kết quả theo bằng chứng:

Thấy một thông báo lỗi quen thuộc trong kết quả quét chưa đủ để kết luận subdomain đã bị chiếm. Chẳng hạn, GitHub Pages có nhiều nguyên nhân gây lỗi 404, bao gồm thiếu index.html. Việc xác nhận phải dựa trên tài khoản quản trị, tài liệu nền tảng hoặc phản hồi của nhà cung cấp.

Tương tự, nội dung trái phép cho thấy có sự cố nhưng chưa xác định được đường xâm nhập. Cần bằng chứng về DNS, tài nguyên và binding trước khi gọi nguyên nhân là dangling-CNAME takeover.

Về ưu tiên xử lý, hostname liên quan đăng nhập, dữ liệu nhạy cảm hoặc nội dung độc hại đang hoạt động cần được xem xét trước. Một subdomain ít traffic vẫn có thể quan trọng nếu được ứng dụng khác tin cậy.

Một tình huống audit đi đến kết luận

Tình huống sau là mô phỏng để minh họa cách đọc bằng chứng, không phải hồ sơ sự cố thực tế.

promo.example.com vẫn có CNAME tới một dịch vụ hosting. Khi mở trang, người kiểm tra thấy một trang mặc định của nhà cung cấp.

Không cần tự đăng ký lại một tài nguyên để quyết định dọn bản ghi đã xác nhận không còn cần dùng. Mục tiêu audit là khôi phục một cấu hình có chủ sở hữu rõ ràng.

7. Phát hiện subdomain bị chiếm: xử lý theo thứ tự nào?

Bước 1: Ngắt đường dẫn tới tài nguyên ngoài quyền kiểm soát

Nếu hostname không còn cần dùng, gỡ bản ghi liên quan. Nếu vẫn cần, chuyển sang tài nguyên an toàn do doanh nghiệp kiểm soát và xác minh lại binding. Hệ thống có CDN hoặc nhiều lớp hosting phải được kiểm tra từng lớp.

Lưu nhanh bằng chứng cần thiết: bản ghi DNS, thời điểm phát hiện, URL, phản hồi và cấu hình liên quan. Việc thu thập không nên kéo dài thời gian người dùng tiếp tục tiếp xúc với nội dung độc hại.

Thay đổi DNS không có hiệu lực đồng thời ở mọi nơi. Cần tính đến TTL và kiểm tra các resolver còn giữ bản ghi cũ; hạ TTL sau khi sự cố xảy ra không xóa ngay những bản ghi đã được cache.

TTL cũng không phải lời hẹn mọi resolver sẽ đổi cấu hình cùng lúc. RFC 8767 cho phép resolver dùng dữ liệu đã quá TTL trong những điều kiện không làm mới được dữ liệu từ máy chủ authoritative. Vì vậy, cần kiểm tra trạng thái thực tế thay vì chỉ chờ hết một khoảng thời gian.

Bước 2: Xác định phạm vi đã bị lợi dụng

Kiểm tra các hostname khác trỏ cùng tài nguyên, nội dung mới xuất hiện, redirect và những liên kết còn đưa người dùng đến đó.

Nếu có khả năng lộ cookie, token hoặc thông tin đăng nhập, đội phụ trách cần đánh giá việc thu hồi phiên và thông tin xác thực bị ảnh hưởng. Không nên coi việc đã sửa CNAME là bằng chứng mọi rủi ro liên quan đều đã chấm dứt.

Bước 3: Dọn nội dung và xử lý URL

Khi doanh nghiệp đã kiểm soát lại hạ tầng phục vụ hostname:

Khôi phục nội dung hợp lệ nếu trang còn giá trị sử dụng.

Với URL spam đã xóa, không có trang thay thế phù hợp, trả về 404 hoặc 410. Google sẽ loại các URL này khỏi chỉ mục sau khi xử lý lại.

Chỉ chuyển hướng URL cũ tới trang có nội dung thay thế tương ứng; tránh gom mọi URL rác về trang chủ.

Gỡ liên kết nội bộ và sitemap dẫn tới nội dung không còn tồn tại.

Nếu hostname không còn phân giải tới dịch vụ tiếp nhận request, không thể dùng dịch vụ đó để trả HTTP 410 cho lượt truy cập thông thường. Resolver còn cache địa chỉ cũ có thể vẫn đưa request tới hạ tầng trước đó; cần kiểm tra riêng trường hợp này. Mã HTTP chỉ được trả khi request tới được một dịch vụ đang xử lý hostname.

Bước 4: Làm việc với Google theo báo cáo thực tế

Kiểm tra riêng Security Issues và Manual Actions. Các URL mẫu trong Security Issues không phải danh sách đầy đủ; phải xử lý toàn bộ vấn đề trước khi gửi yêu cầu xem xét ở báo cáo tương ứng.

Nếu cần ẩn nhanh kết quả độc hại, có thể dùng Removals trong Search Console. Đây là biện pháp tạm thời để ẩn kết quả tìm kiếm, không thay thế việc sửa DNS hoặc loại bỏ nội dung.

Google hướng dẫn kiểm tra chủ sở hữu mới đáng ngờ trong Search Console khi xử lý nội dung lừa đảo. Đội vận hành cũng nên rà soát người dùng và phương thức xác minh còn hiệu lực. Quyền xuất bản trên một subdomain không tự đồng nghĩa quyền quản trị Domain property.

Theo dõi tiếp trạng thái lập chỉ mục, cảnh báo và hiệu suất theo từng hostname. Không có thời hạn phục hồi thứ hạng cố định cho mọi sự cố.

Khi nào có thể xác nhận đã khắc phục?

Đây là bộ tiêu chí nghiệm thu đề xuất cho đội vận hành:

Khôi phục quyền kiểm soát kỹ thuật và Google hoàn tất xem xét là hai mốc khác nhau. Có thể hoàn tất việc thu hồi hostname trong khi vẫn đang chờ kết quả review hoặc Google cập nhật dữ liệu. Hồ sơ sự cố cần ghi rõ trạng thái của từng phần.

8. Phòng ngừa: đưa DNS vào quy trình đóng dịch vụ

Cách phòng ngừa bền vững là quản lý tên miền cùng vòng đời tài nguyên:

Khi triển khai: giữ tài nguyên và xác minh quyền gắn hostname trước, sau đó mới công bố DNS.

Khi ngừng sử dụng: cập nhật hoặc gỡ DNS trước, xác nhận trạng thái cache liên quan, rồi mới giải phóng tài nguyên hoặc binding. Trong khoảng chờ, tài nguyên cũ cần tiếp tục được doanh nghiệp kiểm soát. Thứ tự này giúp tránh để DNS công khai trỏ đến một dịch vụ có thể được bên khác nhận lại.

Nên đưa thêm các yêu cầu sau vào vận hành:

Mỗi subdomain có một người hoặc bộ phận chịu trách nhiệm.

Ticket đóng chiến dịch phải có phần xử lý DNS, binding, liên kết và nội dung lưu trữ.

Giữ các bản ghi xác minh cần thiết trong thời gian còn sử dụng cơ chế bảo vệ; không xóa TXT chỉ vì cho rằng đó là dữ liệu cũ.

Đối chiếu DNS với tài nguyên sau mỗi thay đổi hạ tầng và theo lịch phù hợp mức rủi ro.

Kiểm tra phạm vi wildcard thay vì mặc định xác minh domain gốc sẽ bảo vệ mọi hostname ở mọi cấp. GitHub có cảnh báo riêng về trường hợp này.

Dùng Domain property trong Search Console để bao quát subdomain; thêm URL-prefix property khi cần theo dõi riêng một host.

Một cấu hình 13px] font-mono font-semibold">noindex không ngăn được takeover: nó phục vụ mục đích lập chỉ mục, không xác lập quyền sở hữu dịch vụ. Nếu còn chặn crawler bằng robots.txt, Google có thể không đọc được chỉ thị noindex.

Điều kiện để đóng một chiến dịch nên rõ ràng: hostname đã được kiểm tra, DNS đã xử lý, tài nguyên và quyền gắn tên miền đã có phương án, các liên kết cũ đã được rà soát. Nếu chưa xác định được ai đang kiểm soát dịch vụ phía sau một CNAME, công việc thu hồi vẫn chưa hoàn tất.

Nguồn tham khảo thêm:

MDN - Subdomain takeover

AWS - Virtual hosting of general purpose buckets

Microsoft - Prevent subdomain takeovers in Azure App Service

GitHub - Verifying your custom domain for GitHub Pages

AWS - General purpose bucket naming rules

Heroku - How do I mitigate subdomain reuse?

Heroku - Custom Domain Names for Apps

AWS - Website endpoints

AWS Security Blog - Threat tactic spotlight: Subdomain takeover

Google -Security issues report

Google - Manual actions report

Google Search Central - Spam policies / Hacked content

Google Search Central -Helpful content / E-E-A-T

MDN - Set-Cookie

Google - How HTTP status codes affect Google's crawlers

Google - Removals and SafeSearch reports tool

Google - Add a property to Search Console

Google Search Central -Block Search indexing with noindex

Microsoft - Prevent dangling DNS entries and avoid subdomain takeover

IETF - RFC 1034: CNAME và phân giải DNS

GitHub - Troubleshooting 404 errors for Pages

© Ghi nguồn voc.vn khi đăng tải lại nội dung này.