Introduction
Các địa chỉ email dạng "no‑reply" không phải là nơi an toàn để gửi dữ liệu nhạy cảm – chúng đang trở thành bẫy thu thập thông tin cho các nhà nghiên cứu độc lập.
Q: Tại sao các công ty lại gửi email tới địa chỉ "no‑reply"?
A: Họ cho rằng những địa chỉ này không được kiểm tra và do đó không gây phiền hà cho người dùng.
Q: Những loại dữ liệu nào đã bị rò rỉ qua các địa chỉ này?
A: Từ báo cáo thương tích của thành phố, đơn đặt pizza, tới chứng nhận tài khoản học sinh và hình ảnh CCTV.
Q: Có cách nào ngăn chặn việc này không?
A: Sử dụng miền .invalid, kiểm tra cấu hình catch‑all và thực hiện audit định kỳ các hệ thống email tự động.
Các nhà nghiên cứu và quy mô sự cố
Cory Solovewicz, một chuyên gia bảo mật, đã thu thập 401.796 tin nhắn kể từ tháng 12/2024, tương đương 699,99 tin mỗi ngày. Ông sở hữu các miền noreply.us (mua năm 2020) và noreply.net (mua năm 2024). Trên noreply.net, có 28.365 email có đính kèm, trong khi noreply.us nhận 37.255 tin trong 2.345 ngày hoạt động. Tổng cộng, các tin nhắn đến từ hơn 14.000 địa chỉ “from” và 6.200 tên miền gốc.
Lý do các hệ thống lại gửi tới miền không tồn tại
Nhiều doanh nghiệp chuyển đổi địa chỉ cá nhân thành dạng placeholder khi nhân viên rời công ty hoặc tài khoản bị xóa. Họ tin rằng email tới "noreply" sẽ bị bỏ qua, nhưng thực tế các máy chủ email vẫn chấp nhận và chuyển tiếp chúng. Một ví dụ điển hình là việc gửi email tới [company]@noreply.net hoặc [user]@deleteduser.com mà không kiểm tra tính hợp lệ.
Các ví dụ thực tế về dữ liệu rò rỉ
- Báo cáo thương tích của một thành phố được gửi tới miền của Solovewicz.
- Đơn đặt pizza của khách hàng được gửi tự động từ hệ thống đặt món.
- Thông tin đăng ký tài khoản học sinh từ một nền tảng giáo dục.
- Hình ảnh CCTV từ một công ty AI ở Trung Đông, bao gồm hàng nghìn khung hình.
- Đơn đặt phòng khách sạn chứa họ và tên đầy đủ.
- Lời mời tham dự tiệc BBQ của một công ty ở San Francisco, gửi tới "Dear Deleted User".
Các biện pháp khắc phục và trách nhiệm công khai
Solovewicz đã thông báo cho hơn 14.000 tổ chức, nhưng phản hồi chỉ đến một phần nhỏ. Anh đã trình bày phát hiện tại hội nghị Defcon, nhấn mạnh việc sửa lỗi cấu hình là trách nhiệm của doanh nghiệp. Ngoài ra, Mike Sheward của Xeal đã mua miền deleteduser.com với giá 15 USD và nhận được email từ ít nhất 100 tổ chức khác nhau. Cả hai đã mua hơn 30 miền để giảm thiểu nguy cơ các hacker khai thác.
Tầm nhìn tương lai và các chuẩn đề xuất
Nếu không có biện pháp ngăn chặn, các miền placeholder sẽ tiếp tục thu thập dữ liệu, tạo ra “bãi rác” thông tin có giá trị cho tội phạm mạng. Các chuyên gia đề xuất: 1. Áp dụng chuẩn RFC 2142 để định nghĩa miền .invalid cho các địa chỉ không thực. 2. Thực hiện kiểm tra catch‑all tự động trong quá trình triển khai hệ thống email. 3. Đào tạo nhân viên IT về rủi ro khi cấu hình địa chỉ trả lời tự động. 4. Sử dụng giải pháp giám sát lưu lượng email để phát hiện bất thường.
Conclusion
Bước tiếp theo thực tế: kiểm tra ngay các miền nội bộ của bạn, loại bỏ mọi cấu hình catch‑all và thay thế địa chỉ "no‑reply" bằng miền .invalid hoặc địa chỉ nội bộ không công khai. Điều này không chỉ bảo vệ dữ liệu khách hàng mà còn giảm thiểu rủi ro pháp lý cho doanh nghiệp.