Liên kết bảo mật riêng tư không thể truy cập công khai, thật sự là vậy sao?
- Các công cụ phân tích malware/URL phổ biến như urlscan.io, Hybrid Analysis và Cloudflare Radar URL Scanner lưu trữ số lượng lớn liên kết để thu thập và chia sẻ thông tin.
- Điều chưa được biết đến rộng rãi là các dịch vụ này đang lưu cả những liên kết riêng tư và nhạy cảm bị người dùng vô tình gửi lên hoặc bị quét thành dữ liệu công khai bởi các scanner và tiện ích mở rộng được cấu hình sai.
Đó là những loại liên kết nào?
- Các tệp được chia sẻ bằng công cụ lưu trữ đám mây (
Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3 v.v.).
- Các công cụ NAS kết nối đám mây (
Western Digital Mycloud v.v.).
- Công cụ giao tiếp doanh nghiệp (
Slido, Zoom, Onedrive, Airtable v.v.).
- Liên kết đặt lại mật khẩu, liên kết đăng nhập OAuth, v.v.
- Điểm chung của các dịch vụ này là cho phép truy cập bằng một liên kết riêng lẻ chứa định danh ngẫu nhiên. Đôi khi chúng còn được bảo vệ thêm bằng mật khẩu hoặc cụm mật khẩu; trong trường hợp đó, chỉ truy cập được liên kết không đồng nghĩa với việc dữ liệu bị lộ.
Ai phải chịu trách nhiệm?
- Theo điều khoản sử dụng của Hybrid Analysis và urlscan.io, trách nhiệm đối với nội dung được gửi lên thuộc về người dùng, và không có cơ chế rà soát hay gỡ bỏ các liên kết nhạy cảm.
- Việc triển khai điều này theo cách tự động hóa cũng có thể không hề dễ dàng.
- Với tư cách là nhà nghiên cứu bảo mật, rất khó để xác định nguồn gốc của các liên kết này.
Chúng tôi là thợ săn mối đe dọa! Mọi liên kết đều là của chúng tôi!
- urlscan Pro cho phép người dùng/doanh nghiệp trả phí truy cập không chỉ các bản quét
Public mà cả Unlisted.
Unlisted không hiển thị trên trang công khai hay trong kết quả tìm kiếm, nhưng vẫn hiển thị với khách hàng của nền tảng urlscan Pro.- Cortex-Analyzers của TheHive sử dụng rõ ràng cấu hình
public:on trong bộ phân tích urlscan.io, khiến liên kết xuất hiện dưới dạng unlisted.
- Với người dùng urlscan Pro, dữ liệu không được công khai nhưng vẫn có thể truy cập, nên nguy cơ rò rỉ thêm nhiều thông tin nhạy cảm là có thật.
Có thể gỡ các liên kết nhạy cảm như thế nào?
- Urlscan và Hybrid Analysis cho phép gắn cờ liên kết để yêu cầu gỡ bỏ.
- Với Hybrid Analysis, mọi tệp được gửi lên sandbox công khai đều có thể tìm kiếm và được công khai trên toàn thế giới.
Kết luận
- Gần như chắc chắn vấn đề này sẽ tiếp tục tồn tại. Giải pháp tốt nhất có thể là mặc định giữ các bản quét ở chế độ riêng tư, nhưng điều đó lại không phù hợp với mục tiêu chia sẻ threat intelligence và thực hành phân tích của cộng đồng bảo mật.
- Khi sử dụng các dịch vụ này, cần chú ý đến mức độ hiển thị của bản quét.
Tuyên bố miễn trừ trách nhiệm
- Nếu bạn chọn truy cập các liên kết/tệp này từ cơ sở dữ liệu URL, hãy cẩn thận với các tệp và liên kết độc hại thực sự.
- Một số có thể chỉ là các nỗ lực phishing đơn giản, nhưng cũng có thể chứa malware thật.
- Khuyến nghị sử dụng môi trường sandbox.
Liên kết hữu ích
- SOAR spot của urlscan.io: Chatty security tools leaking private data (2022)
- Search API Reference của urlscan.io
- Public API của Falcon Sandbox
- Cloudflare Radar URL Scanner
Ý kiến của GN⁺
- Bài viết này cho thấy các công cụ bảo mật có thể vô tình làm lộ thông tin nhạy cảm như thế nào, qua đó gióng lên hồi chuông cảnh báo cho cả nhà nghiên cứu bảo mật lẫn người dùng phổ thông.
- Những vấn đề này có thể phát sinh từ lỗi của người dùng hoặc cấu hình sai của công cụ, và điều đó đòi hỏi sự cẩn trọng cũng như trách nhiệm cao hơn trong cách cộng đồng bảo mật xử lý thông tin nhạy cảm.
- Bài viết cũng nhấn mạnh tầm quan trọng của việc cá nhân và doanh nghiệp cần thực hiện các biện pháp để bảo vệ dữ liệu của mình.
- Nhìn từ góc độ phê phán, các rò rỉ như vậy có thể là mối đe dọa nghiêm trọng đối với quyền riêng tư cá nhân và tính bảo mật của doanh nghiệp, đồng thời đặt ra nghi vấn về độ tin cậy của các công cụ và dịch vụ bảo mật.
- Các dự án khác cung cấp tính năng tương tự gồm có những nền tảng phân tích malware như VirusTotal hay Any.run; khi sử dụng các dịch vụ này, cần luôn xem xét kỹ liệu dữ liệu có bị công khai hay không.
1 bình luận
Ý kiến trên Hacker News
Vấn đề cốt lõi là liên kết không có kiểm soát truy cập, chỉ bị mặc định xem là riêng tư vì không có chỉ mục công khai. Gần đây trên Hacker News có một câu chuyện được quan tâm về việc phát hiện AWS account ID thông qua bucket, và đồng thuận rút ra trong phần bình luận là việc dựa vào tính không công khai của mã định danh tài khoản như một phần của bảo mật là một cách tiếp cận sai lầm. Đây chỉ đơn thuần là một cách
dorkingkhác mà thôi.dorking.Nếu muốn tạo liên kết có thể chia sẻ riêng tư, bạn nên lưu thông tin bí mật trong phần hash của URL. Phần hash không được gửi trong truy vấn DNS hay HTTP request. Ví dụ, liên kết dạng
links.com#<secret>sẽ không rời khỏi trình duyệt. Nên mã hóa dữ liệu trong phần hash thành chuỗi Base64 an toàn cho URL.Cá nhân tôi luôn thấy nghi ngờ với những liên kết "riêng tư" có thể dùng vô hạn lần. Đó chỉ là bảo mật nhờ che giấu mà thôi. Sẽ tốt hơn nếu có tùy chọn rõ ràng như Google Docs: "bất kỳ ai có URL đều có thể truy cập". Trong hệ thống tôi từng xây dựng, chúng tôi dùng signed URL có thời hạn ngắn, và URL này không hiển thị trực tiếp cho người dùng.
Những liên kết không nằm trong một vòng lặp chuyển hướng nhanh sẽ bị sao chép và chia sẻ. URL là công cụ phổ quát, giúp truy cập tài nguyên ở tầng giao thức. Kiểm soát truy cập với bất cứ thứ gì có vòng đời không quá ngắn nên được thực hiện bên ngoài URL. Khi chia sẻ liên kết qua kênh không phải e2ee, thực thể đầu tiên truy cập URL có thể là dịch vụ của kênh đó chứ không phải người nhận. Các công cụ quét như vậy sẽ không cải thiện UX nếu nói rõ với người dùng rằng việc quét là công khai.
Giải pháp cho vấn đề "xác thực qua email" là dùng mã dùng một lần, để dù URL có vô tình bị chia sẻ cũng không thành vấn đề, mà không cần thêm bước tạo tài khoản và mật khẩu. Khi người dùng truy cập một liên kết "riêng tư", website sẽ gửi lại qua email một mã dùng một lần có giới hạn thời gian, và người dùng nhập mã tạm thời đó để xác nhận họ sở hữu email.
Trên Internet, nếu URL không có lớp bảo vệ nào ngoài một chuỗi ngẫu nhiên thì về bản chất nó không riêng tư. Chuyện này cũng giống như tìm webcam kết nối Internet vậy. Lẽ ra chúng ta đã phải biết điều này rồi. Tại sao phần "ai phải chịu trách nhiệm" lại không nhắc đến điều đó?
Hơi lạc đề một chút, nhưng có một liên kết nói rằng Cloudflare Radar khai thác dữ liệu từ 1.1.1.1. Tôi cứ nghĩ 1.1.1.1 không dùng dữ liệu người dùng cho bất kỳ mục đích nào cơ mà?
Liên kết cuộc họp Zoom thường thêm mật khẩu dưới dạng query parameter. Liệu đây có phải là một liên kết "riêng tư và an toàn" không? Nếu không có mật khẩu thì nó có còn là liên kết "riêng tư và an toàn" không?
Có thể giải thích trường hợp nào trong hai trường hợp sau an toàn hơn không?
domain.com/loginngười dùng: John mật khẩu: mật khẩu ngẫu nhiên 5 ký tựdomain.com/URL ngẫu nhiên 12 ký tự Giả sử cả hai trường hợp đều có cùng mức bảo vệ về độ ngẫu nhiên/rate limit hoặc đều không có, thì vì sao trường hợp 1 lại an toàn hơn trường hợp 2?Mọi media/ảnh được tải lên ứng dụng private trên airtable.com đều là liên kết công khai, có thể truy cập không cần xác thực nếu biết URL.