Khi hostname nội bộ bị rò rỉ lên đám mây

• Phát hiện trường hợp thiết bị NAS gia dụng gửi hostname chỉ dùng nội bộ tới dịch vụ bên ngoài
• Script báo cáo lỗi sentry.io có trong giao diện web của NAS gửi hostname nội bộ ra ngoài cùng với stack trace
• Quan sát thấy phía sentry.io thử thiết lập kết nối TLS ngược tới hostname đó, nhưng không gửi yêu cầu thực tế nào
• Nhờ cấu hình sẵn DNS wildcard nên có thể phát hiện việc rò rỉ, và nếu dùng hostname nhạy cảm thì có nguy cơ lộ thông tin nghiêm trọng
• Một vấn đề bảo mật tiềm ẩn là nếu cơ chế này bị lạm dụng, nó có thể kích hoạt quét DNS đối với các host tùy ý

---

Cài đặt NAS và cấu hình hostname nội bộ

• Mua thiết bị NAS, lắp ổ đĩa và kết nối vào mạng gia đình, vận hành ở chế độ HTTPS
• Cài đặt chứng chỉ TLS wildcard cho một subzone của miền công khai không mang nhiều ý nghĩa (ví dụ: *.nothing-special.whatever.example.com)
• Thêm mục chỉ dùng cục bộ như 172.16.12.34 nas.nothing-special.whatever.example.com vào tệp /etc/hosts để truy cập từ trình duyệt

Phát hiện truy cập bất ngờ từ bên ngoài

• Vài ngày sau khi cài NAS, bắt đầu xuất hiện yêu cầu từ bên ngoài ("outside world") tới cùng hostname đó
• Hostname này là một tên hoàn toàn chỉ dùng nội bộ, chỉ tồn tại trong tệp /etc/hosts của laptop
• Vì đã cấu hình sẵn bản ghi DNS wildcard cho toàn bộ *.nothing-special.whatever.example.com trỏ về máy do mình quản lý nên có thể phát hiện việc rò rỉ
• Mỗi khi tải NAS, một host GCP lại cố kết nối bằng cách đưa hostname nội bộ đó vào SNI

Nguyên nhân rò rỉ: báo cáo lỗi qua sentry.io

• Giao diện web của NAS có chức năng phone home, trong đó một phần là gửi stack trace tới sentry.io
• Khi trình duyệt callback tới sentry.io, nó đồng thời truyền kèm hostname đang dùng cho thiết bị lưu trữ nội bộ
• Xác nhận rằng phía sentry.io tạo kết nối TLS ngược tới hostname đó, nhưng hoàn toàn không gửi bất kỳ yêu cầu HTTP thực tế nào

Hàm ý bảo mật và cách ứng phó

• Nếu hostname chứa thông tin nhạy cảm (ví dụ tên như mycorp-and-othercorp-planned-merger-storage) thì có nguy cơ rò rỉ thông tin nghiêm trọng
• Có thể dùng cơ chế báo cáo của sentry này để kích hoạt quét DNS đối với các host bên ngoài tùy ý (cách làm cụ thể xin để độc giả tự suy nghĩ)
• Biện pháp ứng phó là chạy Little Snitch và chặn toàn bộ miền đó đối với mọi ứng dụng

[GN⁺]

Ý kiến trên Hacker News

• Có vẻ mọi người đang hiểu nhầm. Đây không phải vấn đề của CT log mà liên quan đến chứng chỉ wildcard
  Sentry thu thập trace phía client, trích xuất hostname đã gửi request rồi lại cố poll vào đó và bị từ chối

  • Có lẽ đây là nỗ lực lấy favicon để hiển thị trong giao diện trace UI
  • Nhưng với cấu trúc như vậy, Sentry có thể phát sinh lỗ hổng bảo mật cho phép gửi request tới IP tùy ý. Đặc biệt còn có thể lặp lại truy cập vào các IP tự động báo cáo lưu lượng độc hại
  • Lý do mọi người nhầm lẫn là vì bài blog được viết quá rối rắm và thiếu rõ ràng

• Về bản chất, hostname không phải thông tin riêng tư
  Nó bị lộ ra bên ngoài qua nhiều đường như truy vấn DNS hay chứng chỉ TLS
  Nếu muốn che giấu dịch vụ riêng tư thì tốt hơn nên đặt bí mật ở đường dẫn URL thay vì hostname
  Ví dụ như fileservice.example.com/my-hidden-service-007-abc123/ thì chỉ được truyền qua HTTPS nên mức độ lộ lọt sẽ ít hơn nhiều

  • Tất nhiên ngay cả trong trường hợp này, đường dẫn vẫn có thể bị gửi tới dịch vụ bên ngoài như Sentry, nên cần dùng URL mờ đục và giữ thói quen không đưa bí mật vào URL
  • Cũng có người hỏi rằng “Nếu chỉ dùng HTTP thì loại lộ lọt này có giảm đi không?”

• Có người thắc mắc liệu “clown GCP Host” có phải là thuật ngữ kỹ thuật không. Hóa ra tác giả dùng cách nói này để châm biếm cloud
  Điểm cốt lõi của vấn đề là giao diện web NAS gửi log tới Sentry kèm theo hostname nội bộ
  Trong trường hợp như vậy, tôi có lẽ sẽ thay bằng OS mã nguồn mở đáng tin cậy, hoặc chặn các lời gọi tới Sentry bằng DNS filtering như PiHole

  • “clown” là cách mỉa mai cloud của Big Tech, và nghe nói ngày xưa trên IRC cũng từng có cụm “clown computing”
    Có người giải thích rằng họ dùng DNS cục bộ và TLS proxy để chặn hoàn toàn lưu lượng đi ra ngoài
  • Một người khác nói thêm rằng “clown” là thuật ngữ cũ dùng để châm biếm các nhà cung cấp cloud lớn và người dùng của họ
  • Có người đùa rằng thay vì “clown” thì đôi khi họ dùng từ “weenie”
  • Cũng có kiểu hài hước như “rạp xiếc đã rời đi nhưng bọn hề vẫn ở lại”

• Chính vì những trường hợp như thế này mà tôi xem uBlock Origin là mức tối thiểu cho bảo mật web
  Hầu hết các trang web nạp quá nhiều script bên thứ ba và làm rò rỉ dữ liệu, mức độ nghiêm trọng là quá lớn
  Đây không phải giải pháp tận gốc, nhưng là điều tốt nhất chúng ta có thể làm ngay lúc này

  • Tôi cũng cài AdGuard Home trên router và thấy 15~20% lưu lượng bị chặn. Điều đó cho thấy tracking và quảng cáo đang tệ tới mức nào

• Để ngăn kiểu vấn đề này, tốt nhất là đặt Nginx reverse proxy ở phía trước và chèn header CSP
  Làm vậy không ngăn được NAS tự gửi request ra ngoài, nhưng có thể chặn trường hợp trình duyệt gửi thay
  Ví dụ cả request avatar Steam (https://avatars.steamstatic.com/HASH_medium.jpg) cũng có thể bị chặn bằng chính sách CSP
  Nếu cần thì chỉ mở một phần. Ngoài ra còn thêm Referrer-Policy: no-referrer để hostname không xuất hiện trong log bên ngoài

  • Có người chỉ ra cách nói lặp như “ATM machine”
  • Và một người khác đùa đáp lại rằng “NPM thì khá đơn giản”

• Tôi đã mua Synology NAS và đã hối hận nhiều lần
  Ngoài phần mềm cộng đồng thì hầu như không làm được gì
  Việc áp dụng SSL với Let's Encrypt cũng phức tạp, đường dẫn lại không chuẩn nên rất khó tìm chỗ cấu hình
  Có nhiều bất mãn như phiên bản rsync cũ, thiếu utility mặc định, v.v. Lẽ ra tôi nên dùng NAS dựa trên Linux hoặc BSD

  • Cũng có ý kiến nói rằng nếu chỉ dùng Synology như file server thì nó rất ổn định nên vẫn hài lòng. Tuy vậy, vì chính sách khép kín nên có người dự định chuyển sang UniFi NAS
  • Cũng có phản hồi rằng “muốn một server nhưng lại phàn nàn NAS không phải server” là mâu thuẫn
  • Có người chia sẻ rằng trên diễn đàn Doozan có hướng dẫn cài Debian mới nhất lên Synology NAS
  • Cũng có lời khuyên rằng “cứ để nó làm file/iSCSI server thôi thì rất ổn định, đừng động vào”
  • Ngược lại, có người nói họ mua mẫu RS217 với giá $100 và đó là món hời nhất. Họ dùng Synology Office thay cho Google Docs và rất ấn tượng với độ hoàn thiện của UI

• Gần đây tôi có cấu hình Sentry và thấy hệ thống này có tính năng cố gắng tự động thiết lập uptime monitoring
  Khi nhận diện được host, nó sẽ ping định kỳ, và nếu phản hồi ổn định trong vài ngày thì hiện thông báo kiểu “Bạn có muốn thiết lập uptime monitoring cho host này không?”

  • Có người chỉ bình luận ngắn là “cơ hội mở rộng”

• Cá nhân tôi chặn toàn bộ các domain liên quan đến Sentry
  Đây không phải giải pháp chung, nhưng trong môi trường của tôi thì đó là lựa chọn tốt nhất

• Máy chủ tra cứu địa chỉ ngược thường cũng cố phân giải cả địa chỉ mạng nội bộ (ULA, RFC1918)
  Nếu kết hợp dữ liệu này với thông tin khác thì có thể suy ra trạng thái bên trong
  Có người nói rằng “trong lúc thu thập Darknet, từng bắt được cả âm thanh UDP”

  • Đáp lại có câu hỏi rằng “Phần âm thanh UDP đó là lưu lượng SIP của năm nào vậy?”

• Trước đây tôi từng điều tra hiện tượng tương tự trên Heroku
  Khi tạo app mới, hệ thống gán một subdomain ngẫu nhiên, và dù chưa hề có truy vấn DNS thì request từ máy quét lỗ hổng đã lập tức xuất hiện
  Khi hỏi Heroku, họ nói là vì URL của app mới được công khai trong Certificate Transparency (CT) log

  • Có người nói rằng “chẳng khác nào gắn tấm biển ‘hãy tấn công tôi’ lên mỗi dịch vụ mới”, đồng thời chỉ ra rằng CT log lẽ ra chỉ nên ghi hash thay vì chứng chỉ thật
    Họ cũng chia sẻ link Cách hoạt động của Certificate Transparency
  • Một người khác đăng ảnh chụp màn hình (link ảnh) và nói rằng “Tôi dùng wildcard domain nên tránh được vấn đề đó”