- Các dịch vụ phân tích URL/mã độc như urlscan.io, Hybrid Analysis và Cloudflare Radar URL Scanner lưu trữ liên kết để chia sẻ tình báo mối đe dọa, nhưng do lỗi người dùng hoặc trình quét cấu hình sai, liên kết nhạy cảm có thể bị lưu lại dưới dạng dữ liệu công khai
- Các dịch vụ mà bản thân URL được dùng như quyền truy cập như Dropbox, iCloud, AWS S3, Zoom, OneDrive, Airtable, liên kết đặt lại mật khẩu và liên kết đăng nhập OAuth có thể bị ảnh hưởng đặc biệt
- Không phải mọi liên kết đều bị lộ ngay lập tức, nhưng trên thực tế đã tìm thấy các tài liệu như hồ sơ thuế, hóa đơn, ảnh, trao đổi công việc, bí mật chia sẻ qua onetimesecret, bản ghi nhà thông minh và bản ghi cuộc họp
- urlscan Pro hiển thị không chỉ các lượt quét Public mà cả lượt quét Unlisted cho khách hàng trả phí, và có thể tồn tại các đường dẫn vô tình gửi ở chế độ unlisted, như cấu hình Cortex-Analyzers của TheHive
- Trong 24 giờ gần đây, số lượt quét trên urlscan.io là 398.563 Public, 328.147 Unlisted và 955.432 Private; thử nghiệm canary token cũng xác nhận có truy cập trong vòng 1 giờ sau khi gửi, nên cần quản lý khả năng hiển thị của lượt quét
Liên kết nhạy cảm còn lại trong các dịch vụ phân tích URL
- urlscan.io, Hybrid Analysis và Cloudflare Radar URL Scanner lưu trữ nhiều liên kết để phân tích URL và mã độc
- Vấn đề là liên kết riêng tư, nhạy cảm cũng có thể đi vào các kho lưu trữ này
- Người dùng gửi liên kết nhạy cảm để quét mà không biết rằng chúng sẽ trở thành thông tin công khai
- Trình quét hoặc tiện ích mở rộng cấu hình sai gửi các liên kết riêng tư quét từ email thành dữ liệu công khai
Các liên kết và tài liệu có thể bị lộ
- Các liên kết được phát hiện bao gồm URL chia sẻ và URL liên quan đến xác thực của nhiều dịch vụ
- Chia sẻ tệp trên các kho lưu trữ đám mây như Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive và AWS S3
- NAS kết nối đám mây như Western Digital Mycloud
- Công cụ giao tiếp doanh nghiệp như Slido, Zoom, OneDrive và Airtable
- Liên kết đặt lại mật khẩu và liên kết đăng nhập OAuth
- Vì lý do bảo mật, các dịch vụ này thường cho phép truy cập bằng một liên kết riêng tư duy nhất có chứa định danh ngẫu nhiên
- Một số liên kết được bảo vệ thêm bằng mật khẩu hoặc passphrase, nên chỉ truy cập vào liên kết không nhất thiết làm lộ dữ liệu ngay lập tức
- Nội dung nhạy cảm thực tế đã được phát hiện gồm:
- Tệp riêng tư như hồ sơ thuế, hóa đơn, ảnh và trao đổi công việc
- Bí mật được chia sẻ qua onetimesecret
- Bản ghi từ thiết bị nhà thông minh
- Bản ghi cuộc họp lưu trên đám mây
Khoảng trống trong đường dẫn gửi và trách nhiệm
- Nhiều lượt gửi được xác nhận trên urlscan.io có thẻ falconsandbox, từ đó phạm vi phân tích được mở rộng sang cả Hybrid Analysis
- Cloudflare Radar cũng có thể được dùng rộng rãi hơn và hiện đã bao gồm một số liên kết riêng tư trong dữ liệu công khai
- Điều khoản của Hybrid Analysis nêu rằng nội dung do người dùng gửi có thể được phân tích, công khai và chia sẻ, đồng thời họ không chịu trách nhiệm về thông tin vô tình có trong nội dung gửi hoặc báo cáo được tạo tự động
- Điều khoản của urlscan.io cũng nêu rằng họ không chịu trách nhiệm về nội dung hay hành vi của người dùng, và người dùng chịu trách nhiệm về nội dung cùng hoạt động được đăng dưới tài khoản của mình
- Có vẻ không có cơ chế rõ ràng để rà soát nội dung hiện có nhằm đánh dấu hoặc xóa liên kết nhạy cảm, và việc tự động hóa điều này cũng có thể không đơn giản
- Phân tích của Positive Security đã dùng canary token nhắm vào urlscan.io để phát hiện nguồn tự động, và đề cập rằng nguyên nhân có thể là các công cụ bảo mật quét liên kết độc hại trong email
- Hành vi tương tự cũng được xác minh bằng liên kết canary
Lượt quét Unlisted và quyền truy cập urlscan Pro
- urlscan Pro cung cấp cho người dùng trả phí và doanh nghiệp quyền truy cập vào phạm vi quét rộng hơn, không chỉ Public mà cả lượt quét Unlisted
- Trên urlscan.io, Unlisted không xuất hiện trên trang công khai hoặc 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
- urlscan Pro được giới thiệu là giới hạn cho các nhà nghiên cứu bảo mật đã được xác minh hoặc các doanh nghiệp có uy tín
- Cortex-Analyzers của TheHive là một ví dụ cho thấy đường dẫn phơi lộ ngoài ý muốn
- Bộ phân tích urlscan.io sử dụng rõ ràng cấu hình
public:on - Do cấu hình này, ngay cả khi khả năng hiển thị của tài khoản urlscan là Private, liên kết vẫn có thể xuất hiện dưới dạng unlisted
- Mã liên quan nằm trong urlscan.py của Cortex-Analyzers
- Bộ phân tích urlscan.io sử dụng rõ ràng cấu hình
- Trong trường hợp này, dù dữ liệu không hoàn toàn công khai, nó vẫn có thể được người dùng urlscan Pro nhìn thấy, khiến khả năng lộ thông tin nhạy cảm hơn vẫn còn tồn tại
Số lượt quét và kết quả canary token
- Số lượt quét trên urlscan.io trong 24 giờ gần đây như sau:
Public: 398.563 lượtUnlisted: 328.147 lượtPrivate: 955.432 lượt
- Kết quả truy cập được xác nhận bằng canary token như sau:
- Liên kết gửi lên urlscan.io ở chế độ
unlistedđược truy cập 12 lần trong vòng 1 giờ sau khi gửi - Liên kết gửi lên Hybrid Analysis qua
APIthay vì trình duyệt được truy cập 10 lần trong vòng 1 giờ sau khi gửi - Một số địa chỉ IP đã truy cập đồng thời các liên kết duy nhất được gửi lên cả hai dịch vụ và sử dụng dịch vụ ẩn danh hóa IP nguồn
- Liên kết gửi lên urlscan.io ở chế độ
- Danh sách các địa chỉ IP này được công bố trong tệp riêng
Xóa liên kết nhạy cảm và lưu ý khi sử dụng
- urlscan.io và Hybrid Analysis cung cấp quy trình báo cáo để xóa liên kết
- Với Hybrid Analysis, việc xóa và phạm vi chia sẻ phức tạp hơn
- Mọi tệp được gửi lên Public Sandbox đều có thể tìm kiếm và được cung cấp trên toàn thế giới
- Ngay cả khi chọn hộp kiểm “Do not share my sample with the community”, ảnh chụp màn hình và báo cáo thực tế vẫn tiếp tục được cung cấp
- “do not share” chỉ áp dụng cho mẫu đầu vào thực tế
- Khi sử dụng dịch vụ, trước tiên cần kiểm tra khả năng hiển thị của lượt quét
- Nếu truy cập liên kết hoặc tệp trong các cơ sở dữ liệu URL này, có thể gặp các nỗ lực phishing, tệp độc hại thực sự hoặc liên kết độc hại
- Nếu cần truy cập, nên kiểm tra trong môi trường sandbox
1 bình luận
Các ý kiến trên Hacker News
Vấn đề căn bản nằm ở chỗ các liên kết không có kiểm soát truy cập được xem là riêng tư chỉ vì không có chỉ mục định danh công khai
Tháng trước, câu chuyện tìm ID tài khoản AWS thông qua bucket cũng khá nổi trên HN[0], và sự đồng thuận trong phần bình luận là kỳ vọng bảo mật dựa trên giả định rằng định danh tài khoản là riêng tư là sai
Khái niệm tương tự cũng áp dụng ở đây; đây không hẳn là một vấn đề bảo mật mới mà chỉ là một phương pháp dò tìm dựa trên toán tử tìm kiếm (dorking) khác
[0]: https://news.ycombinator.com/item?id=39512896
Về lý thuyết, một liên kết hex dài 256 ký tự, tức 1024 bit, khó đoán hơn rất nhiều so với tên người dùng 32 ký tự và mật khẩu 32 ký tự
https://site.com/[256chars] có 2^1024 tổ hợp nên brute force gần như là không thể
Trong khi đó, https://site,com/[32chars] và mật khẩu 32 ký tự có 2^256 tổ hợp, cũng gần như không thể nhưng vẫn có khả năng hơn so với trường hợp trước
Có thể xem như https://site,com/[32chars][32chars]
Tuy nhiên, dù trường hợp trước khó đoán hơn, URL lại bị lộ nhiều hơn mật khẩu rất nhiều
Ở đây, tin nhắn được hiểu rộng, bao gồm email, DM, cho đến các liên kết dán vào tài liệu
Tôi thấy không thoải mái nên cuối cùng chọn cách khác, nhưng điều đó khiến tôi cứ suy nghĩ mãi rằng trên thực tế, “bí mật” nằm trong URL khác với bí mật nằm trong token được gửi khi yêu cầu URL đến mức nào
Kết luận của tôi là token có thể được cấp theo từng khách hàng, và có thể theo dõi log truy cập để phát hiện hành vi đáng ngờ rồi thu hồi
Như những người khác đã nói, cách nhìn về việc coi việc giữ bí mật danh sách tên file quan trọng đến đâu cũng khác nhau
Ở quy mô những việc Amazon có thể làm sai, việc vô tình để lộ danh sách tên file của một bucket công khai có lẽ là chuyện 99% người dùng không bận tâm, nên có vẻ có mức ưu tiên thấp
Dĩ nhiên công ty chúng tôi đã thua trong cuộc cạnh tranh đó
Từ đó, mỗi lần làm với AWS, tôi rút ra một bài học nhỏ là tên bucket thường nên được đặt theo dạng -
Nếu thực sự cần riêng tư, có thể mã hóa cả tên dự án, rồi cung cấp script liệt kê bucket bằng những tên “thân thiện”
Dịch vụ hosting luôn có những sự đánh đổi kỳ lạ, nên cách hoàn hảo về mặt kỹ thuật là dùng định danh hoàn toàn ngẫu nhiên rất có thể sẽ tạo gánh nặng vận hành lớn hơn nhiều so với cách không hoàn hảo là dùng tên có tính mô tả
Bitwarden Send tạo một liên kết có thể chuyển cho người khác, với một chuỗi ngẫu nhiên dài sau dấu
#Tôi dùng nó thường xuyên nên muốn biết liệu có vấn đề bảo mật nào không
Ít nhất thì liên kết có thể bị hủy và có thể tự động hết hạn sau vài ngày, còn mật khẩu thông thường thì thường không hoạt động như vậy
Nếu muốn tạo liên kết chia sẻ riêng tư, có thể lưu giá trị riêng tư trong phần hash của URL
Hash không được gửi qua truy vấn DNS hay HTTP request
Ví dụ, khi truy cập links.com?token=, liên kết đó sẽ được gửi kèm cả tham số truy vấn và có thể bị lưu lại bởi trung gian như Cloudflare
Ngược lại, khi truy cập links.com#, phần hash sẽ không rời khỏi trình duyệt
Khi xử lý dữ liệu trong phần hash, mã hóa thành chuỗi URL Safe Base64 sẽ tiện lợi
Tức là luồng JS Object ↔ JSON String ↔ URL Safe Base 64 String
Phần còn lại là đúng, tôi chỉ muốn bổ sung sắc thái về mã hóa HTTPS này
Đưa vào fragment thì có ích, nhưng không hoàn hảo
Tôi không chỉ nói theo lý tưởng; thực tế tôi đã thấy token riêng tư trong fragment bị rò rỉ theo cách này nhiều lần
[https://example.com?token=](<https://example.com?token=<secret>>;) chỉ nên tạo truy vấn DNS cho “example.com”
Các bot đi theo liên kết trong email có chạy JavaScript không? Có nguy cơ JavaScript kích hoạt hành động thật bằng một POST do nó dẫn dắt không?
Những liên kết không phải là một phần của vòng lặp redirect nhanh thì chắc chắn sẽ được sao chép và dán để chia sẻ
URL vốn được dùng cho mục đích đó, có tính phổ quát và giúp dễ truy cập tài nguyên được cung cấp qua bất kỳ giao thức nào
Kiểm soát truy cập đối với những thứ không có vòng đời ngắn nên được thực hiện bên ngoài URL
Nếu chia sẻ liên kết qua kênh không có mã hóa đầu cuối, chủ thể đầu tiên truy cập URL đó không phải là người nhận mà là dịch vụ của kênh
Điều đó có thể chính đáng, như Bitwarden tìm favicon vì trải nghiệm người dùng, hoặc có thể ác ý, như crawler của Facebook Messenger muốn biết thêm người dùng chia sẻ gì trong tin nhắn riêng tư
Các công cụ quét kiểu này sẽ không làm trải nghiệm người dùng tốt hơn
Nếu nói rõ rằng kết quả quét sẽ được công khai, một số người dùng sẽ nghĩ lại trước khi dùng dịch vụ, và điều đó không tốt cho việc kinh doanh, dù là người dùng miễn phí hay người dùng có license pro
Các liên kết “riêng tư” có thể dùng không giới hạn luôn khiến tôi hơi nghi ngờ
Rốt cuộc đó là bảo mật dựa vào tính mơ hồ
Khi chia sẻ thứ như Google Docs, ít nhất cũng có tùy chọn nói rõ “bất kỳ ai có URL đều có thể truy cập”
Khi cần kiểu này trong hệ thống mình xây, tôi thường dùng URL đã ký chỉ có thời hạn vài phút
URL phần lớn là chi tiết triển khai và không hiển thị trực tiếp cho người dùng, nhưng vẫn có khả năng nhìn thấy trong màn hình debug của trình duyệt
Nếu trên Internet, thứ như vậy không được bảo vệ bởi gì ngoài một chuỗi ngẫu nhiên trong URL, thì thực tế nó không riêng tư
Cũng giống câu chuyện về các webcam kết nối Internet mà tìm là thấy
Chẳng phải ta đã biết chuyện này rồi sao? Không hiểu vì sao phần “ai chịu trách nhiệm” lại hoàn toàn không đề cập điểm này
Không phải mọi thứ đều cần mức bảo mật cao nhất; đôi khi chỉ cần một rào cản để ngăn chia sẻ rộng rãi là đủ
Ví dụ, trong thư viện ảnh, khi bấm “tạo liên kết chia sẻ” rồi gửi liên kết ảnh cho ai đó, tôi không muốn người đó phải nhập mật khẩu
Mở liên kết ra thì ảnh phải hiện, và với mục đích đó thì ổn
Một trong các ví dụ ở đây đúng chính xác là trường hợp như vậy, và phù hợp với ca sử dụng đó
Ngay cả về lo ngại quyền riêng tư, dù có quy trình đăng nhập thì người dùng cuối ở thời điểm đó vẫn có thể chia sẻ lại ảnh chụp màn hình
Tức là mức bảo mật phù hợp với ca sử dụng
Đây là tình huống người dùng hiện có liên kết ảnh và cũng có thể chia sẻ lại, nhưng ta tin rằng họ sẽ không cố ý làm vậy
Vấn đề lớn ở đây không nằm ở bản thân liên kết, mà ở việc công cụ phân tích bảo mật quét mọi liên kết người dùng nhận qua email và khiến những người dùng khác trong cộng đồng đó cũng truy cập được
Đó là mức chia sẻ lại lớn hơn rất nhiều so với ý định của tôi khi gửi ảnh cho ai đó
Cách né vấn đề xác thực dựa trên email này là dùng mã tạm thời dùng một lần, không cần đi đến mức tạo tài khoản bằng mật khẩu
Khi đó dù URL bị chia sẻ nhầm cũng không thành vấn đề lớn
Hơi lạc đề, nhưng liên kết dẫn đến Cloudflare Radar, và dịch vụ này apparently có vẻ đang khai thác dữ liệu 1.1.1.1
Tôi từng hiểu rằng 1.1.1.1 không dùng dữ liệu người dùng cho bất kỳ mục đích nào
Mong có người thông minh hơn giải thích giúp. Hai cái sau khác nhau ở điểm nào?
Giả sử cả hai đều có cùng cơ chế chống brute-force hoặc giới hạn tốc độ, hoặc cả hai đều không có, thì vì sao 1 lại an toàn hơn 2?
Trên thực tế thì có khác
Bí mật dựa trên sở hữu và bí mật dựa trên tri thức là khác nhau
URL là thứ bạn có; nếu để nó ở nơi có thể truy cập thì có thể bị lấy mất
Mật khẩu là thứ bạn biết, và nếu quản lý tốt thì không bị lấy mất. Ngoại lệ là tấn công bằng ống chì
Còn một loại nữa là dựa trên sinh trắc học, như quét võng mạc hoặc vân tay
(1) cần thông tin từ một kênh riêng để xác thực, và đó là loại thông tin mọi người quen giữ an toàn
Trong khi đó URL của (2) được đối xử như URL
URL thường xuyên bị ghi log, ghi lại, chia sẻ và truyền đi khắp nơi
Ví dụ, nếu tường lửa công ty ghi lại tên người dùng và mật khẩu dùng để đăng nhập vào dịch vụ nào đó thì rõ ràng là tệ, nhưng việc ghi lại URL đã truy cập thì rất có thể trông có vẻ ổn
Trường hợp sau chỉ là ví dụ; do bảo đảm đầu cuối của TLS, cả hai lẽ ra đều không thể bị truy cập
Thêm nữa, nếu domain.com/12-char-password được yêu cầu mà không qua HTTPS, thì dù có redirect, yêu cầu đầu tiên vẫn được gửi không mã hóa và có thể bị tấn công trung gian
Trong khi đó với trang đăng nhập, có nhiều cách hơn để bảo đảm việc gửi mật khẩu chỉ xảy ra qua HTTPS
Một vấn đề lớn là nhiều ứng dụng logging ghi toàn bộ URL ở đâu đó, như vậy thực chất là ghi “mật khẩu” vào log
Mọi media và ảnh đăng lên ứng dụng airtable.com riêng tư đều là liên kết công khai
Nếu biết URL thì có thể truy cập mà không cần xác thực
Thẻ ảnh thông thường không thể đặt header Authorization chứa token trong request như khi dùng fetch() cho API request
Các lựa chọn khả thi chỉ là thêm token vào URL hoặc dùng xác thực bằng cookie
Xác thực bằng cookie chỉ hoạt động khi CDN nằm trên cùng domain, và trong nhiều trường hợp ngay cả subdomain cũng có thể gây vấn đề
Tôi đồng ý rằng nó có thể tiềm ẩn vấn đề
Liên kết cuộc họp Zoom thường gắn mật khẩu dưới dạng tham số truy vấn
Liên kết này có phải là liên kết “bảo mật riêng tư” không? Liên kết thiếu mật khẩu có phải là liên kết “bảo mật riêng tư” không?
Vì đến lúc URL xuất hiện ở nơi khác thì cuộc họp đó có lẽ đã kết thúc và biến mất rồi
Nhưng trên thực tế, chẳng ai bận tâm, họ muốn “nhấp để tham gia” mà không phải nhập đủ thứ
Cách làm trước đây là “chỉ dùng ID cuộc họp” thì quá dễ đoán