Sự cố nhắm tới RCE với 20 USD nhưng vô tình trở thành quản trị viên .mobi

 (labs.watchtowr.com)
2 điểm bởi GN⁺ 2024-09-12 | 1 bình luận | Chia sẻ qua WhatsApp
  • watchTowr Labs đã đăng ký tên miền dotmobiregistry.net đã hết hạn với giá khoảng 20 USD, qua đó kiểm soát hostname máy chủ WHOIS cũ của .mobi, và xác nhận rằng các WHOIS client cũ cùng luồng xác minh chứng chỉ TLS/SSL vẫn tin cậy địa chỉ này
  • Máy chủ WHOIS chính thức của .mobi đã chuyển sang whois.nic.mobi, nhưng nhiều công cụ vẫn tiếp tục truy vấn địa chỉ cũ whois.dotmobiregistry.net do đã hardcode địa chỉ này
  • Sau khi triển khai máy chủ WHOIS tạm thời vào ngày 30/8/2024, đến ngày 4/9 đã có hơn 135.000 hệ thống duy nhất và 2,5 triệu truy vấn gửi tới, cho thấy một tên miền legacy bị bỏ mặc vẫn liên kết rộng rãi với hạ tầng Internet thực tế
  • Một số tổ chức cấp chứng chỉ TLS/SSL dùng xác minh qua email dựa trên WHOIS để kiểm tra quyền sở hữu tên miền .mobi; trong thử nghiệm với GlobalSign, whois@watchtowr.com được hiển thị là một ứng viên email xác minh cho microsoft.mobi
  • Nhóm nghiên cứu không thực sự phát hành chứng chỉ độc hại; sau đó NCSC của Anh và ShadowServer đã đưa tên miền này vào sinkhole để proxy các phản hồi WHOIS hợp pháp cho .mobi

Tên miền hết hạn giá 20 USD sống lại thành hạ tầng WHOIS

  • Mục tiêu ban đầu của watchTowr Labs là tìm một lỗi RCE có thể khai thác thực tế trong quá trình WHOIS client phân tích phản hồi từ máy chủ
  • Trong các thử nghiệm ban đầu, họ giả lập máy chủ WHOIS trả về chuỗi rất dài và xác nhận một số client dễ dàng bị crash
  • Tuy nhiên, để kẻ tấn công kiểm soát được phản hồi WHOIS, thông thường cần một trong các điều kiện sau
    • MITM để chặn lưu lượng WHOIS ở tầng mạng
    • Quyền truy cập vào máy chủ WHOIS thật
    • WHOIS referral trỏ tới máy chủ do kẻ tấn công kiểm soát
  • Những điều kiện tiên quyết này là rào cản lớn trong tấn công thực tế, nhưng tình hình đã thay đổi khi tên miền máy chủ WHOIS cũ của .mobi hết hạn
  • Máy chủ WHOIS của .mobi trước đây đã chuyển từ whois.dotmobiregistry.net sang whois.nic.mobi, và tên miền cũ dotmobiregistry.net đã ở trạng thái hết hạn vào khoảng tháng 12/2023
  • Sau khi đăng ký tên miền này, watchTowr đặt một máy chủ WHOIS phía sau whois.dotmobiregistry.net để kiểm tra liệu các WHOIS client hardcode địa chỉ cũ có vẫn truy vấn hay không

Bề mặt tấn công do hardcode địa chỉ máy chủ WHOIS

  • WHOIS dùng máy chủ riêng cho từng TLD, nhưng thiếu một cơ chế chuẩn hóa mạnh để client tìm máy chủ đó theo thời gian thực
  • Trên thực tế, cách phổ biến là các công cụ WHOIS tham khảo danh sách văn bản do IANA công bố rồi hardcode địa chỉ máy chủ tại thời điểm phát triển
  • Khi địa chỉ máy chủ không thay đổi thường xuyên, vấn đề ít lộ rõ; nhưng khi địa chỉ thay đổi và tên miền cũ hết hạn, các client cũ có thể tiếp tục truy vấn tới địa chỉ đã bị loại bỏ
  • watchTowr phản hồi các yêu cầu WHOIS gửi tới máy chủ lglass và trả về thông tin WHOIS giả khiến mọi đối tượng được truy vấn trông như thuộc sở hữu của watchTowr
  • Phản hồi cũng bao gồm ASCII art và yêu cầu dừng truy vấn

Quy mô và nguồn gốc truy vấn quan sát được

  • Sau khi triển khai máy chủ WHOIS vào ngày 30/8/2024, chỉ trong vài giờ đã có hơn 76.000 IP nguồn duy nhất truy vấn
  • Trong khoảng hai ngày, SQLite DB đã tích lũy 1,3 triệu truy vấn; tính đến ngày 4/9/2024, ghi nhận 2,5 triệu truy vấn và hơn 135.000 hệ thống duy nhất
  • Nguồn truy vấn bao gồm các nhà đăng ký tên miền lớn và các website cung cấp chức năng WHOIS
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • Các dịch vụ phân tích bảo mật cũng dùng máy chủ WHOIS .mobi cũ
    • urlscan.io dùng kết quả WHOIS đó trên trang tên miền .mobi
    • VirusTotal truy vấn máy chủ WHOIS tạm thời của watchTowr và hiển thị kết quả
  • Nhiều máy chủ mail và bộ lọc spam cũng được ghi nhận
    • Bộ lọc spam có thể thực hiện tra cứu WHOIS đối với tên miền người gửi
    • Bao gồm từ cheapsender.email cho tới các host có vẻ thuộc hạ tầng chính phủ Bangladesh như mail.bdcustoms.gov.bd
  • Các địa chỉ liên quan tới .gov được ghi nhận ở nhiều quốc gia
    • Argentina, Pakistan, India, Bangladesh, Indonesia, Bhutan, Philippines, Israel, Ethiopia, Ukraine, USA
    • Ví dụ liên quan tới Brazil gồm antispam.ap.gov.br, master.aneel.gov.br
  • Trong nguồn .mil, Swedish Armed Forces được nêu làm ví dụ
  • Cũng ghi nhận các nguồn từ .edu và các công ty bảo mật; Group-IB, Detectify, Censys được nhắc tới
  • Nếu các máy chủ .gov và máy chủ mail truy vấn máy chủ WHOIS mỗi khi nhận email từ tên miền .mobi, sẽ có khả năng quan sát thụ động ai đang liên lạc với ai

Lỗ hổng WHOIS client cũ và khả năng RCE

  • watchTowr tìm các tiền lệ về lỗ hổng phân tích phản hồi WHOIS và tổng kết rằng trong 26 kết quả tìm kiếm CVE liên quan, chỉ còn 3 lỗi được kích hoạt bởi phản hồi WHOIS sai định dạng
  • Việc có ít trường hợp như vậy có thể liên quan đến nhận thức rằng khai thác thực tế cần những điều kiện khó, chẳng hạn kiểm soát máy chủ WHOIS của TLD
  • phpWHOIS CVE-2015-5243 là lỗ hổng cho phép RCE do dữ liệu nhận từ máy chủ WHOIS được thực thi bằng PHP eval
    • Mã dễ tổn thương chỉ escape không đầy đủ " trong chuỗi phản hồi WHOIS rồi chuyển cho eval
    • Phân tích của Netitude đưa ra payload ví dụ như ”;phpinfo();//
    • Phiên bản phpWHOIS dễ tổn thương đã hardcode whois.dotmobiregistry.net
  • Fail2Ban CVE-2021-32749 là lỗ hổng cho phép chèn lệnh vì đầu ra WHOIS được chuyển tới công cụ mail mà không được làm sạch đúng cách
    • Fail2Ban có thể tra cứu thông tin chủ sở hữu của IP bị chặn qua WHOIS và đưa vào email gửi quản trị viên
    • Tuy nhiên, lỗ hổng này xảy ra khi tra cứu WHOIS cho địa chỉ IP, nên chỉ riêng việc watchTowr kiểm soát máy chủ WHOIS tên miền .mobi là chưa thể trực tiếp chạm tới nó
  • Để thực thi mã trên thực tế, vẫn cần đồng thời có client tiếp tục truy vấn máy chủ WHOIS .mobi cũ và một triển khai client dễ tổn thương

Ảnh hưởng tới cả luồng xác minh chứng chỉ TLS/SSL

  • Một số tổ chức cấp chứng chỉ TLS/SSL hỗ trợ cách phân tích email liên hệ quản trị từ dữ liệu WHOIS rồi gửi liên kết xác minh tới email đó để kiểm tra quyền sở hữu tên miền
  • Các ví dụ về tổ chức cấp chứng chỉ hoặc reseller hỗ trợ xác minh quyền sở hữu dựa trên WHOIS mà watchTowr liệt kê gồm
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • Trong thử nghiệm với GoGetSSL, khi tải lên CSR giả cho watchTowr.mobi, whois@watchtowr.com do watchTowr thiết lập không được hiển thị; chỉ có một email placeholder xuất hiện, có vẻ WHOIS chưa thành công
  • Trong thử nghiệm với Entrust, bản ghi WHOIS hợp pháp của microsoft.mobi được phân tích và chỉ các email thuộc tên miền microsoft.com được hiển thị làm ứng viên xác minh; còn watchTowr.mobi không được phân tích
  • Trong thử nghiệm với GlobalSign, ban đầu có vẻ họ không phân tích được bản ghi WHOIS của microsoft.mobi, nhưng kết quả thay đổi khi watchTowr sao chép định dạng đầu ra microsoft.mobi từ máy chủ WHOIS hợp pháp và cung cấp qua máy chủ WHOIS của mình
  • GlobalSign đã truy vấn máy chủ WHOIS của watchTowr, phân tích whois@watchtowr.com trong phản hồi và đề xuất nó làm email xác minh cho microsoft.mobi
  • watchTowr dừng lại ở điểm này và không thực sự phát hành chứng chỉ TLS/SSL độc hại
  • Luồng tấn công về mặt lý thuyết như sau
    • Đặt máy chủ WHOIS độc hại tại hostname từng có thẩm quyền trước đây
    • Cố gắng mua chứng chỉ TLS/SSL cho tên miền .mobi mục tiêu
    • Tổ chức cấp chứng chỉ tra cứu WHOIS và gửi email xác minh tới email của kẻ tấn công thay vì chủ sở hữu thật
    • Khi kẻ tấn công nhấp vào liên kết, họ có thể nhận chứng chỉ TLS/SSL cho tên miền mục tiêu
  • Với năng lực này, về lý thuyết có thể thực hiện các cuộc tấn công như chặn lưu lượng hoặc giả mạo máy chủ mục tiêu

Biện pháp sau sự cố và vấn đề còn lại

  • Trước khi công bố, NCSC của Anh và ShadowServer Foundation đã cùng phối hợp ứng phó
  • Tên miền dotmobiregistry.net và hostname whois.dotmobiregistry.net được trỏ tới hệ thống sinkhole do ShadowServer cung cấp
  • Sinkhole này proxy các phản hồi WHOIS hợp pháp cho tên miền .mobi
  • Quy trình thông báo cho các bên bị ảnh hưởng cũng được thiết lập
  • Trường hợp này cho thấy khiếm khuyết mang tính cấu trúc phát sinh khi hạ tầng legacy, tên miền bị bỏ mặc, xử lý dựa trên WHOIS và quy trình xác minh của tổ chức cấp chứng chỉ TLS/SSL cùng vận hành
  • Chủ thể có khả năng MITM cũng có thể giả mạo dữ liệu WHOIS để thử cùng kiểu tấn công; dù có các cơ chế như Certificate Transparency, các rào cản vận hành vẫn tồn tại đối với tấn công quy mô lớn

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-12
Ý kiến trên Hacker News

  • Hẳn là đã có sai sót của nhiều người chồng chất mới dẫn đến tình huống này, nhưng có một điều rõ ràng lẽ ra có thể ngăn cuộc tấn công cụ thể này: tuyệt đối đừng để tên miền hết hạn
    Máy chủ WHOIS của tên miền cấp cao nhất .MOBI đã được chuyển từ whois.dotmobiregistry.net sang whois.nic.mobi vài năm trước, và có vẻ tên miền dotmobiregistry.net đã bị bỏ mặc cho hết hạn vào khoảng tháng 12/2023
    Khi một công ty bắt đầu dùng một tên miền mới với giá 10 USD/năm, tên miền đó trên thực tế trở thành một tài sản phải trả 10 USD/năm mãi mãi. Một khi tên miền đã gắn với hoạt động kinh doanh, không thể cắt đứt hoàn toàn mối liên hệ đó

    • Đây là lý do rõ ràng nhất cho thấy vì sao Verisign là nhà vận hành độc quyền và cần được quản lý như một tiện ích công cộng như điện, nước. Nói rằng có lựa chọn và không bị phụ thuộc gần như là ảo tưởng; một khi mua và bắt đầu dùng tên miền thì về cơ bản sẽ bị trói vào đó mãi mãi. Verisign cũng biết điều đó nên họ chiến đấu tuyệt vọng để giữ độc quyền
    • Ngay cả Google cũng từng làm hỏng việc này trong chốc lát
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • Luôn phải dùng tên miền con. Trong suốt vòng đời tồn tại, một doanh nghiệp chỉ cần một tên miền 10 USD/năm là đủ
    • Tôi thích điểm này. Nó khiến tôi nhớ đến các bài blog của Backblaze tính xác suất có nhiều ổ đĩa hỏng đến mức làm mất dữ liệu người dùng
      Cuối cùng tôi cho rằng bản thân con số tính toán không quá quan trọng, vì khả năng quên thanh toán do thẻ tín dụng hết hạn hoặc bỏ lỡ thông báo gia hạn vì lọc spam còn lớn hơn
      Các tập đoàn khổng lồ làm thế nào để không quên trả phí tên miền? Họ giao việc gia hạn trong khoảng thời gian gần như “vô hạn” cho các nhà đăng ký đắt tiền chăng? Có vẻ là một bài toán vận hành kinh doanh khá khó

  • Tôi có cảm giác một sáng nào đó thức dậy, mình sẽ thấy tin rằng toàn bộ Internet đã biến mất vì ai đó trong một phòng khách sạn hẻo lánh làm gì đó bằng một chiếc Raspberry Pi kết nối vào điểm phát Wi-Fi của quán cà phê gần đó

    • Gợi nhớ chuyện ở ký túc xá đại học, ai đó cắm bừa một router mang từ nhà lên rồi phát địa chỉ DHCP sai bét, làm hỏng Internet. Cảm giác như chuyện đó xảy ra ở quy mô toàn cầu
    • Thực ra khá nhiều thứ đúng là đang đứng trên hy vọng và lời cầu nguyện [0], nhưng Internet được thiết kế để vững chắc [1]. Trong trường hợp này phạm vi bị giới hạn ở .mobi
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • Việc này liên quan đến tin gần đây “White House asks agencies to step up internet routing security efforts” [1] hoàn toàn chỉ là trùng hợp ngẫu nhiên
      [1] https://news.ycombinator.com/item?id=41482087

  • Vì sao các công cụ lại hardcode danh sách máy chủ WHOIS để dùng?
    Có vẻ có một cách chuẩn để đăng ký việc này trong DNS, nhưng thử nhanh thì thấy nhiều tên miền cấp cao nhất thiếu bản ghi. Ví dụ hoạt động là dig _nicname._tcp.fr SRV +noall +answer, và trả về _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
    Ngoài ra còn có một bản nháp Internet đã hết hạn về việc này: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • Chỉ cần có mobi.whois.arpa. CNAME whois.nic.mobi là đã có thể giải quyết vấn đề. Tuy nhiên, việc khiến mọi người đồng thuận và áp dụng cách này rất khó
      Như fanf2 nói bên dưới, có lẽ cũng có thể truy vấn máy chủ WHOIS của IANA trước. Nếu truy vấn mobi tại https://www.iana.org/whois, một phần phản hồi trả về là whois: whois.nic.mobi
    • Trong thực tế có nhiều chuỗi hardcode hơn rất nhiều so với mức ta tưởng tượng, và hơn cả mức lẽ ra nên có
    • WHOIS có lẽ còn lâu đời hơn rất nhiều so với khái niệm bản ghi SRV
    • Những công cụ kiểu này thường được tạo ra vì một nhu cầu dùng một lần, rồi được công khai để người khác dùng hoặc để chính tác giả tham khảo sau này. Các “kỹ sư” khác không do dự sao chép rồi dán vào, và khi nó đi vào môi trường vận hành thì sẽ trở thành CVE như lần này
      Năng lực nhà phát triển yếu cũng là vấn đề, nhưng ảo giác AI sẽ còn làm tình hình tệ hơn

  • Tôi đã thấy quá nhiều đội không nhận ra rằng một khi bắt đầu dùng một tên miền theo cách có ý nghĩa, thì trên thực tế phải gia hạn nó cho đến khi vũ trụ chết nhiệt, hoặc ít nhất là đến khi đội đó chết nhiệt
    Dù là trường hợp như thế này, hay một URL cũ nhưng quan trọng còn sót đâu đó, hay một thành viên trong đội đã đăng ký dịch vụ bằng email ở tên miền cũ, thật quá khó để biết lúc nào có thể thực sự buông một tên miền cũ

  • Bề mặt tấn công phát sinh chỉ từ việc mua một tên miền đã hết hạn của máy chủ WHOIS cũ thật sự khổng lồ

  • Giải pháp thực sự cho WHOIS là RDAP
    Đáng tiếc là nó không bắt buộc với các tên miền cấp cao nhất mã quốc gia, và ngay cả trong số các tên miền cấp cao nhất không phải mã quốc gia cũng có nhiều nơi không hoạt động đúng
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • Nó giảm nhẹ các vấn đề được mô tả trong bài viết như thế nào?

  • Một việc làm rất tuyệt
    Tên miền dotmobiregistry.net và hostname whois.dotmobiregisry.net hiện được cho là trỏ tới hệ thống sinkhole do ShadowServer cung cấp, và hệ thống này proxy các phản hồi WHOIS hợp lệ của tên miền .mobi
    Nếu các tên miền này đã được lên kế hoạch loại bỏ, có lẽ trả về phản hồi kiểu 404 sẽ tốt hơn. Nếu cứ để chúng tiếp tục hoạt động như bình thường thì động lực chuyển sang tên miền chính thức sẽ giảm đi

    • Whois không hỗ trợ mã trạng thái HTTP, nhưng sinkhole của ShadowServer phản hồi như sau:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • Đọc bài thì có vẻ nó đã ở trạng thái hỏng trong vài năm rồi, và nhiều client đã không nhận ra điều đó

  • Tôi cho rằng cách tiếp cận với máy tính nói chung tự thân nó đã được định sẵn là sẽ thất bại. Nó dựa vào bảo mật hoàn hảo, và giả định rằng mức bảo mật đó đạt được nhờ kiểm tra SBOM cùng các bản cập nhật thường xuyên
    Nhưng chuyện đó tuyệt đối sẽ không xảy ra. Chỉ riêng log4j thôi, 40% tổng lượt tải xuống vẫn là các phiên bản có lỗ hổng. Chưa kể khi một nhà cung cấp trong chuỗi cung ứng phá sản hoặc ngừng bảo trì một thành phần nào đó
    Giống như cơ thể chúng ta luôn là chiến trường với vi sinh vật, mọi thứ lúc nào cũng buộc phải đầy lỗi và đầy lỗ hổng

    • Không, chậm rãi nhưng chắc chắn, ta có thể viết mã tốt và đáng tin cậy, rồi dùng nó để tạo ra công cụ tốt hơn, sau đó lại dùng công cụ đó để xây tiếp những thứ tiếp theo
      Có lẽ sẽ mất vài chục năm, nhưng con đường trông khá rõ ràng. Chỉ cần bỏ công sức, áp dụng kiến thức rút ra từ mọi “bài học”, và không dừng lại

  • Nhìn chung tôi thích bầu không khí kiểu “chúng tôi vốn không muốn làm chuyện này, nhưng tình hình cứ phình to ra, và ở mỗi bước chúng tôi lại nhận được thứ lớn hơn dự kiến”
    Nếu những người phản đối chịu lắng nghe và sửa phần parsing, có lẽ các tác giả đã đỡ phải vất vả như vậy

  • Nhìn ngược lại, có phải chúng ta nên tin rằng mọi máy chủ WHOIS trên toàn thế giới luôn là thật và an toàn không?
    Đặc biệt, từ góc nhìn của các cơ quan chứng thực thực hiện xác minh TLS, họ hẳn sẽ không muốn biết rằng chỉ cần chạy whois somethingarbitrary.ru là có thể bị phơi nhiễm trước thực thi mã từ xa do máy chủ Nga