Lỗ hổng bảo mật trên Discord: Cách theo dõi người đọc tin nhắn dù không có tính năng "Seen"

Discord từ lâu đã nổi tiếng với việc không cung cấp tính năng "xác nhận đã đọc" (read receipts). Đây được coi là một lời hứa ngầm về quyền riêng tư của nền tảng này: bạn có thể đọc tin nhắn của người khác mà không cần báo cho họ biết. Tuy nhiên, một lỗ hổng bảo mật mới được phát hiện gần đây đã cho phép kẻ tấn công phá vỡ lớp bảo vệ này, biến Discord thành công cụ theo dõi chi tiết hành vi người dùng.

Giao diện và logo của Discord

Cơ chế hoạt động bình thường của Discord

Khi bạn gửi một đường link (URL) trong tin nhắn, hệ thống backend của Discord sẽ tự động truy cập trang web đó để lấy thông tin thẻ meta OpenGraph, bao gồm cả hình ảnh xem trước (og:image). Để bảo vệ người nhận khỏi bị theo dõi, Discord không cho phép máy khách của người dùng tải hình ảnh trực tiếp từ máy chủ gốc. Thay vào đó, Discord sử dụng một máy chủ proxy (images-ext-1.discordapp.net) để lấy hình ảnh, lưu vào bộ nhớ đệm (cache) và phục vụ cho tất cả người xem.

Quy trình này đảm bảo rằng máy chủ gốc chỉ nhận được hai yêu cầu: một để xác thực hình ảnh và một để điền vào cache của proxy. Sau đó, bất kể bao nhiêu người mở tin nhắn, máy chủ gốc đều không nhận thêm tín hiệu nào nữa. Đây là cơ chế bảo vệ quyền riêng tư mà Discord đã thiết kế.

Cách khai thác lỗ hổng

Vấn đề nằm ở chỗ: Điều gì sẽ xảy ra nếu bộ nhớ đệm của proxy không bao giờ được điền?

Nhà nghiên cứu bảo mật Paul Koeck đã nhận thấy rằng yêu cầu xác thực và yêu cầu lấy ảnh để lưu cache là tách biệt. Yêu cầu xác thực xảy ra ngay khi tin nhắn được gửi, trong khi yêu cầu lấy ảnh cache chỉ xảy ra khi có một client (thường là người gửi) hiển thị khung xem trước.

Bằng cách thiết lập máy chủ riêng để phân biệt hai yêu cầu này, ông đã trả về một hình ảnh hợp lệ cho yêu cầu xác thực (để Discord chấp nhận tạo embed), nhưng trả về lỗi 500 Internal Server Error cho yêu cầu lấy ảnh cache. Khi proxy nhận được lỗi 500, nó sẽ không lưu gì cả và chuyển lỗi đó xuống client.

Mô hình thử lại: Chìa khóa của việc theo dõi

Đây là lúc "phép màu" xảy ra. Khi client của Discord gặp lỗi tải hình ảnh, nó không bỏ cuộc ngay mà sẽ tự động thử lại. Tổng cộng, nó sẽ thực hiện 6 lần thử lại với các khoảng trễ tăng dần theo một nhịp điệu rất cụ thể:

• Yêu cầu 1 → chờ 2 giây → Yêu cầu 2 → chờ 3 giây → Yêu cầu 3 → chờ 4 giây
• → Yêu cầu 4 → chờ 5 giây → Yêu cầu 5 → chờ 6 giây → Yêu cầu 6

Vì bộ nhớ đệm không bao giờ được tạo (do lỗi 500 liên tục), mỗi lần thử lại đều là một yêu cầu mới đánh thẳng vào máy chủ của kẻ tấn công. Điều này tạo ra một tín hiệu thời gian rõ ràng.

Thông tin kẻ tấn công có thể thu thập được

Nhờ vào mô hình thử lại này, người gửi link độc hại có thể biết được ba thông tin quan trọng:

1. Khi nào tin nhắn được đọc: Yêu cầu thử lại đầu tiên xuất hiện ngay khi client của người nhận hiển thị khung xem trước.
2. Bao nhiêu người đã đọc: Trong các kênh nhóm, mỗi người xem sẽ tạo ra một chuỗi yêu cầu riêng. Kẻ tấn công có thể nhóm các chuỗi này lại để đếm số lượng người đọc thực tế.
3. Bao lâu họ đã đọc: Số lượng yêu cầu thử lại trước khi client dừng lại tương ứng với thời gian khung xem trước hiển thị trên màn hình. Nếu người nhận đóng kênh chat sớm, chuỗi yêu cầu sẽ bị cắt ngang.

Bằng chứng khái niệm (PoC)

Để chứng minh tính khả thi, một ứng dụng nhỏ đã được xây dựng để tự động hóa quy trình này. Nó sử dụng các kỹ thuật tinh vi hơn như:

• Gom nhóm phiên: Sử dụng nhịp điệu cố định của các yêu cầu để phân biệt dữ liệu từ từng người dùng riêng lẻ.
• Kéo dài thời gian theo dõi: Bằng cách thêm độ trễ nhân tạo 30 giây (tối đa cho phép) vào mỗi phản hồi lỗi, tổng thời gian theo dõi có thể kéo dài hơn 3 phút thay vì chỉ 20 giây.
• Che giấu link: Sử dụng các ký tự đặc biệt vô hình trong Markdown (như chữ rho in nghiêng U+1D75A) để làm cho link gần như không thể nhìn thấy được, trong khi hình ảnh xem trước vẫn tải.

Kết luận và Khắc phục

Lỗ hổng này là một ví dụ điển hình cho thấy cách các tính năng tiện lợi như xem trước link có thể bị biến thành công cụ xâm phạm quyền riêng tư nếu không được xử lý cẩn thận.

Vấn đề đã được báo cáo cho Discord thông qua chương trình HackerOne vào ngày 21/12/2024. Vào ngày 15/01/2025, Discord đã xác nhận tính hợp lệ của báo cáo, trả tiền thưởng và giải quyết vấn đề. Việc công bố rộng rãi đã được chấp thuận vào ngày 10/02/2025. Người dùng có thể yên tâm rằng lỗ hổng này hiện đã được vá, nhưng nó để lại những bài học quý giá về thiết kế bảo mật và quyền riêng tư trên các nền tảng nhắn tin hiện đại.