Ứng dụng nhắn tin tự xưng “siêu bảo mật” làm lộ số điện thoại của mọi người dùng

• Một lỗ hổng nghiêm trọng đã được phát hiện trong Freedom Chat, ứng dụng nhắn tin theo chủ đề MAGA (phe bảo thủ Mỹ), làm lộ số điện thoại và mã PIN của người dùng
• Ứng dụng này là phiên bản kế tiếp của dự án trước đó mang tên Converso, vốn cũng từng gặp lỗi triển khai mã hóa và vấn đề lộ dữ liệu
• Kết quả phân tích cho thấy thông qua tính năng kênh, mã PIN của toàn bộ thành viên bị gửi cho người dùng khác, và thông qua API đồng bộ danh bạ có thể ghép số điện thoại với UID
• Nhà nghiên cứu xác nhận hoàn toàn không có giới hạn tốc độ (rate limiting), nên chỉ trong một ngày đã có thể thu thập số điện thoại của toàn bộ người dùng Freedom Chat
• Vụ việc bị chỉ ra là một trường hợp mà ứng dụng “nhấn mạnh bảo mật” lại thất bại ngay cả trong việc bảo vệ quyền riêng tư cơ bản

---

Từ Converso sang Freedom Chat

• Ra mắt năm 2023, Converso từng tuyên bố có “cấu trúc phi tập trung không máy chủ” và “E2EE hiện đại nhất”, nhưng phân tích của nhà nghiên cứu crnković cho thấy mọi tuyên bố đều là giả
  • Trên thực tế, ứng dụng sử dụng máy chủ trung tâm và dịch vụ mã hóa bên thứ ba (Seald), đồng thời khóa mã hóa có thể được suy ra từ thông tin công khai
  • Tất cả tin nhắn đều được tải lên một bucket Firebase công khai, nên ai cũng có thể xem được
• Sau đó, CEO Tanner Haas đã rút ứng dụng này và đổi thương hiệu thành Freedom Chat, với lý do là “mối lo ngại về quyền riêng tư của phe bảo thủ”
  • Ông từng nhắc đến bài học “hãy tiếp nhận phê bình và cải thiện”, nhưng các vấn đề bảo mật lại tiếp tục lặp lại

Cấu trúc và tính năng của Freedom Chat

• Ứng dụng sử dụng đăng ký bằng số điện thoại và xác thực mã 2FA, còn việc đặt PIN là tùy chọn
• Các tính năng chính là chat 1:1 và kênh (Channels), với cấu trúc tương tự Telegram
• Ứng dụng quảng bá tính năng chặn chụp màn hình như một “tính năng bảo mật”, nhưng điều này thực tế không liên quan đến mức độ an toàn thực sự

Lộ mã PIN

• Kết quả từ yêu cầu API /channel cho thấy trong đối tượng người dùng (user object) của 1.519 thành viên kênh có chứa trường PIN
  • Cùng với UID, khóa Seald, ngày tạo của từng người dùng, mã PIN 6 chữ số bị lộ dưới dạng văn bản thuần
• Sau khi tạo một tài khoản mới để kiểm tra, nhà nghiên cứu xác nhận PIN của chính mình cũng xuất hiện nguyên vẹn trong dữ liệu phản hồi
• Nói cách khác, PIN của tất cả người dùng còn ở trong kênh mặc định đều bị lộ cho những người dùng khác

Lỗ hổng ghép số điện thoại

• API /user/numbers kiểm tra sự tồn tại của liên hệ theo cách giống WhatsApp
  • Nếu một số trong yêu cầu thuộc về người dùng Freedom Chat, API sẽ trả về UID và khóa Seald
• Nhà nghiên cứu xác nhận API này hoàn toàn không có giới hạn tốc độ, nên có thể lần lượt thử toàn bộ số điện thoại Mỹ
  • Kết quả là có thể ghép số điện thoại với UID, và khi kết hợp với dữ liệu UID-PIN đã bị lộ trước đó, sẽ hoàn thiện được ánh xạ số điện thoại-PIN

Thử nghiệm làm lộ dữ liệu toàn bộ người dùng

• Nhà nghiên cứu đã viết một script Python để tự động gửi yêu cầu với toàn bộ số điện thoại Bắc Mỹ (tổ hợp 7 chữ số × mã vùng)
  • Mỗi yêu cầu gửi 40.000 số, thời gian phản hồi trung bình khoảng 1,5 giây
  • Trong 27 giờ, mọi yêu cầu đều được xử lý thành công, qua đó thu thập xong số điện thoại của toàn bộ người dùng Freedom Chat
• Máy chủ vẫn phản hồi không có giới hạn tốc độ hay biện pháp chặn nào, tức là dữ liệu ở trạng thái có thể bị xem toàn bộ

Ứng phó và các bước tiếp theo

• 2025-11-23: phát hiện lỗ hổng
• 2025-12-04: phóng viên TechCrunch Zack Whittaker thông báo lỗ hổng cho Freedom Chat
• 2025-12-05: phía Freedom Chat giải thích rằng “PIN không dùng để khôi phục tin nhắn” và cho biết đã tiến hành quy trình kiểm toán
• 2025-12-09: thông báo đã khắc phục xong vấn đề
• 2025-12-11: công bố đồng thời báo cáo này và bài viết của TechCrunch

Bài học cốt lõi

• Freedom Chat tự nhận là “siêu bảo mật”, nhưng thiếu thiết kế xác thực, giới hạn tốc độ và bảo vệ dữ liệu ở mức cơ bản
• Kết quả là số điện thoại và PIN của toàn bộ người dùng bị lộ, khiến các tính năng bảo mật gần như mất tác dụng
• Đây được xem là một ví dụ điển hình cho khoảng cách giữa marketing về bảo mật và triển khai thực tế

[GN⁺]

Ý kiến trên Hacker News

• Hệ thống tra cứu số điện thoại được mã hóa của Signal khá thú vị
  Máy chủ tra cứu số bằng phép XOR ở mức bit trong RAM được mã hóa bằng phần cứng, nên ngay cả khi quan sát hệ thống ở tầng thấp nhất cũng không thể biết số điện thoại được yêu cầu có tồn tại hay không
  Tất nhiên, rate limiting vẫn là một vấn đề quan trọng riêng. Khi xây dựng hệ thống bảo mật, có rất nhiều trường hợp biên cần phải bao phủ

  • Tôi không nghĩ cách này hay. Ngay từ đầu, nếu là một trình nhắn tin bảo mật thì không nên yêu cầu số điện thoại, vốn là một định danh cá nhân
  • Tôi tự hỏi liệu nếu chính phủ gửi yêu cầu tra cứu cho toàn bộ số điện thoại thì Signal có thể ngăn được không
    Với các nền tảng phi thương mại, đặt quyền riêng tư làm trung tâm như Matrix, bản thân kiểu ánh xạ này nên là điều không thể xảy ra
    Ví dụ, có thể đề xuất cách tải lên giá trị băm của số điện thoại giữa từng cặp người dùng, để chỉ những người có trong danh bạ của nhau mới tìm thấy nhau
    Ưu điểm là không gian băm đủ lớn để khó bị suy ngược, và người dùng có thể tự quyết định phạm vi cho phép bị phát hiện
    Nhược điểm là kẻ tấn công có thể tạo ra mọi tổ hợp số để trích xuất quan hệ trong danh bạ, và chính phủ cũng có thể chặn xác thực SMS để lạm dụng điều này
  • Phần máy chủ dùng XOR trong RAM được mã hóa bằng phần cứng rất thú vị. Tôi muốn biết có tài liệu tham khảo thêm nào về việc này không
  • Tôi vẫn thấy đáng tiếc vì vẫn yêu cầu số điện thoại. Mãi gần đây mới có tính năng username giúp tránh lộ số, nhưng việc tài khoản vẫn dựa trên SIM vẫn khiến tôi không thoải mái
  • Nhưng vì chúng ta không thể tự build và vận hành máy chủ Signal, nên cũng không thể chắc rằng máy chủ thực sự xử lý theo cách đó

• Trường pin trong đối tượng người dùng khá đáng ngờ
  Có lẽ đây là vấn đề phát sinh do dùng thư viện tuần tự hóa kiểu opt-out. Mặc định nó tuần tự hóa toàn bộ đối tượng, nên nếu lập trình viên quên cấu hình loại trừ một trường cụ thể thì nó sẽ bị lộ nguyên trạng
  Hoặc cũng có thể máy chủ chỉ dùng một JS dictionary đơn giản rồi không xóa trường đó trước khi trả phản hồi
  Lỗ hổng này là một vấn đề cũ từng được nhắc đến trong bài báo của nhóm nghiên cứu Đại học Vienna, và đã bị khai thác theo đúng cách này trên Telegram năm 2016, khi chính phủ Iran thu thập số điện thoại của 15 triệu người dùng
  Liên kết liên quan: blog Telegram

  • Khi rà soát mã ở công ty cũ, tôi đã phát hiện những lỗ hổng do tuần tự hóa như thế này ở khắp nơi. Các lập trình viên thực sự nên ngừng dùng các thư viện kiểu đó
  • Kiểu vấn đề này thật sự rất phổ biến. Trường nhạy cảm bị gửi về phía client, nhưng vì UI không hiển thị nên chẳng ai nhận ra
  • Việc PIN bị lộ đã là vấn đề, nhưng chuyện nó được lưu ở dạng văn bản thuần còn nghiêm trọng hơn. Lẽ ra phải xử lý bằng thuật toán băm mạnh như với mật khẩu

• Phần lớn lỗ hổng bảo mật ngày nay đơn giản chỉ bắt nguồn từ việc gọi các HTTP endpoint theo những cách không được dự tính trước
  Nói đến hacking vào năm 2025 người ta hay nghĩ đến kỹ thuật phức tạp, nhưng thực tế lại là triển khai một API thậm chí không có rate limiting. Chỉ một dòng cấu hình Nginx là giải quyết được

  • Nghe câu “chỉ cần một dòng cấu hình Nginx”, tôi lại nghĩ đến kiểu phản ứng “cái đó không có trong tutorial Docker nên tôi không biết nó là gì”
  • Phát triển phần mềm đã tiến bộ, nhưng các nguyên tắc phát triển bảo mật thì hầu như không lớn lên được bao nhiêu
    Phần lớn mục tiêu là giảm ma sát cho người dùng và tăng hiệu quả thương mại. Nhiều lập trình viên chỉ lo triển khai tính năng mà không hề biết những lỗ hổng cơ bản như XSS hay SSRF
  • Dù là cấu hình đơn giản thì cũng phải biết là nó tồn tại mới áp dụng được
  • Trước đây tôi nghĩ các công cụ quét bảo mật nội bộ tự động là vô dụng, nhưng sau khi thấy quá nhiều trường hợp bỏ sót các cấu hình cơ bản, tôi cảm thấy chúng là thứ bắt buộc
    Những sai sót bảo mật cơ bản như lỗi ánh xạ cổng Docker hay thiếu CSP xảy ra quá thường xuyên
  • Nhưng chỉ rate limiting thôi vẫn chưa đủ. Kẻ tấn công có thể phân tán IP để gửi các yêu cầu song song

• Khi đọc câu “Tôi muốn chỉ mang đến cho độc giả những bài blog tốt nhất”, tôi có cảm giác như vừa tìm thấy một người có cùng kiểu khí chất với tác giả

• Tôi tự hỏi liệu Freedom Chat® có tính năng ngăn nhà báo tham gia chat nhóm không. Nửa đùa nửa thật, tôi hỏi thay cho một người bạn trong DoD

• Chỉ riêng năm nay thôi đã có nhiều trường hợp ứng dụng bảo mật làm rò rỉ dữ liệu người dùng khi xử lý chúng
  Chỉ những vụ tôi nhớ được cũng đã cỡ 20 xu (= 4 vụ), nhưng có lẽ còn nhiều hơn thế
  Các trường hợp liên quan: 1, 2, 3

  • Tôi nghĩ vụ này càng cho thấy việc dịch chuyển ra khỏi Facebook Messenger là điều quan trọng
  • Và đó mới chỉ là một phần trong những gì chúng ta biết

• Năm ngoái tôi tình cờ thấy một bảng tin tuyển dụng của GOP, và hồ sơ ứng tuyển lại được lưu trong cùng chỉ mục tìm kiếm với bài đăng tuyển dụng
  Tôi gõ thử “bob” thì CV và câu trả lời của các ứng viên hiện ra nguyên vẹn, thật sự sốc

  • Tôi muốn biết đó là trang nào

• Sau vụ Anom, có lẽ cần một từ còn phù hợp hơn honeypot
  Một trình nhắn tin thật sự an toàn sẽ không xuất hiện theo kiểu này. Nhưng marketing vẫn tiếp diễn, và mỗi lần lại có người dùng mới bị cuốn vào

  • Giờ là thời đại mà thất bại trở thành tính năng
    Rò rỉ dữ liệu xảy ra quá thường xuyên đến mức mọi người đã tê liệt cảm xúc. Ngay cả tiền bồi thường từ kiện tập thể rốt cuộc cũng trở thành một quá trình cung cấp thêm dữ liệu cá nhân
    Những thứ như thị trường dự đoán, tiền mã hóa... cũng cho cảm giác như đang đóng gói một thất bại mang tính cấu trúc gây thiệt hại cho người tham gia thành “thành công”
  • Có người đề xuất từ mới là “Petepot”

• Freedom Chat nói rằng họ đã “sửa xong vấn đề”, nhưng tôi nghi ngờ liệu nó có thực sự được sửa hay chưa

• Nếu câu “Tôi không có kinh nghiệm phát triển ứng dụng di động, nhưng tôi nghĩ vì mình thông minh nên chắc sẽ không khó” là trích dẫn thật, thì nó gần như giống một câu thoại trong hài độc thoại