Trải nghiệm hack một ứng dụng hẹn hò (và cách đối xử sai lầm với các nhà nghiên cứu bảo mật)

• Một lỗ hổng bảo mật nghiêm trọng đã được phát hiện trong ứng dụng hẹn hò có tên Cerca
• OTP bị lộ ngay trong phản hồi, khiến bất kỳ ai chỉ cần biết số điện thoại cũng có thể truy cập tài khoản
• Nhiều API endpoint mở mà không cần xác thực khiến dữ liệu cá nhân bị rò rỉ rất dễ dàng
• Xu hướng tính dục, nội dung tin nhắn, giấy tờ tùy thân và các dữ liệu nhạy cảm khác của người dùng bị lộ với quy mô lớn
• Phía dịch vụ không phản hồi và không thông báo đầy đủ dù nhà nghiên cứu đã báo cáo một cách có trách nhiệm

---

Tầm quan trọng của việc các startup phải nghiêm túc với bảo mật

• Gần đây, trong quá trình gấp rút đưa sản phẩm ra thị trường, nhiều startup đã xem nhẹ bảo mật
• Dù là ứng dụng hẹn hò tập trung rất nhiều dữ liệu cá nhân, người dùng vẫn bị đặt vào rủi ro vì sự non kém trong phát triển và vận hành

Quy trình phát hiện và thông báo lỗ hổng

• Ngày 23/2/2025, tác giả đã gửi email cho phía Cerca để mô tả lỗ hổng bảo mật và các vấn đề liên quan
• Ngày 24/2, hai bên đã thảo luận chi tiết về lỗ hổng, phương án ứng phó và các bước tiếp theo qua cuộc họp video
• Nhóm Cerca cho biết họ đã nhận thức được mức độ nghiêm trọng, hứa sẽ xử lý nhanh và sẽ thông báo cho người dùng
• Sau đó, tác giả nhiều lần hỏi về tiến độ, nhưng tính đến ngày 21/4 vẫn không có phản hồi hay thông báo nào
• Theo xác minh độc lập, lỗ hổng này hiện đã được vá

Lỗ hổng OTP và quá trình hack đơn giản

• Trong quá trình đăng nhập ứng dụng, mật khẩu dùng một lần (OTP) bị lộ nguyên vẹn trong phản hồi mạng
• Kẻ tấn công chỉ cần biết số điện thoại là có thể truy cập tài khoản một cách dễ dàng và nhanh chóng

Truy cập API endpoint và rò rỉ thông tin

• Đã xác nhận rằng chỉ cần điền header phiên bản ứng dụng là có thể truy cập mọi đường dẫn API
• Toàn bộ tài liệu OpenAPI bị lộ thông qua endpoint /docs
• Có thể điều khiển API bằng cách dùng các công cụ như Burp Suite để tự động chèn header và token của ứng dụng
• Một số endpoint chỉ thay đổi business logic, nhưng các endpoint cốt lõi lại trả về lượng lớn dữ liệu cá nhân nghiêm trọng
• Với user/{user_id} và các endpoint tương tự, có thể lấy thông tin cá nhân, số điện thoại, thậm chí chiếm đoạt tài khoản

Tình trạng lộ lọt quy mô lớn dữ liệu cá nhân và giấy tờ tùy thân

• Thông qua endpoint dữ liệu cá nhân, PII như giới tính, thành phố, ngày sinh, email trường học, thông tin giấy tờ tùy thân... bị lộ trên diện rộng
• Đặc biệt, ở các trường liên quan đến giấy tờ tùy thân như national_id_verified, có thể truy cập các tệp nhạy cảm như ảnh hộ chiếu, ảnh căn cước
• Bằng script tấn công, tác giả xác định được 6.117 người dùng, trong đó 207 người đã nhập cả thông tin giấy tờ tùy thân
• Trong đó cũng có một số tài khoản ghi là thuộc Đại học Yale
• Theo Instagram chính thức của Cerca, quy mô này tương ứng với 10.000 người dùng trong tuần đầu tiên

Nguy cơ thiệt hại thực tế và mức độ nghiêm trọng của vấn đề

• Xu hướng tính dục, nội dung trò chuyện, giấy tờ tùy thân và các dữ liệu cực kỳ nhạy cảm khác đã bị lộ, dẫn đến nguy cơ nghiêm trọng như theo dõi, đánh cắp danh tính, tống tiền
• Cerca từng cho biết họ tuân thủ các tiêu chuẩn ngành như mã hóa, nhưng điều này không phù hợp với thực tế vận hành
• Người dùng không thể tự mình xác minh, nên việc nhà cung cấp ứng dụng chủ động và có trách nhiệm trong quản lý bảo mật là điều bắt buộc
• Trên thực tế, cũng có khả năng một số lượng lớn người không xác định đã đánh cắp dữ liệu cá nhân trên diện rộng

Kết luận và sự cần thiết của văn hóa bảo mật có trách nhiệm

• Việc vận hành một ứng dụng yếu kém về bảo mật đến mức ai cũng có thể hack là một vấn đề xã hội nghiêm trọng
• Nếu không đặt bảo vệ dữ liệu người dùng lên ưu tiên hàng đầu, thiệt hại có thể xảy ra theo thời gian thực
• Trường hợp của Cerca, nơi phản hồi với báo cáo của nhà nghiên cứu bảo mật và hướng dẫn người dùng đều không đầy đủ, là một bài học cảnh tỉnh
• Để xây dựng một môi trường Internet an toàn hơn, việc thiết lập hệ thống bảo mật phải là ưu tiên số một của mọi nhà phát triển

[GN⁺]

Ý kiến trên Hacker News

• Ngay cả khi xét rằng ứng dụng này là sản phẩm khá sơ cấp do sinh viên đại học làm ra, tôi vẫn nghĩ họ phải làm hết sức về bảo mật và giao tiếp. Tuy vậy, nhìn thấy cả những công ty người lớn được các VC lớn rót vốn cũng vướng các vấn đề như thế và hành xử tương tự, tôi cũng thấy không cần quá khắt khe với mấy sinh viên này. Chia sẻ link bài viết

  • Tôi không đồng ý mạnh. "Không biết" không thể là giấy miễn tội. Cứ làm tới dù không biết mới là vấn đề lớn hơn. Chuyện này giống như một người lái xe non tay gây tai nạn làm người khác bị thương khi chưa có bằng lái
  • Tôi cũng bấm vào link nguồn khi tìm thông tin về Cerca, thì đó là một bài báo tháng 4/2025 ca ngợi một ứng dụng được tạo ra khoảng hai tháng trước. Nó mang cảm giác như thứ rác do LLM ảo giác bịa ra. Như OP nói là đã liên hệ đội Cerca từ tháng 2, nên hoặc là lỗ hổng được phát hiện ngay khi vừa ra mắt, hoặc là có gì đó rất lạ. Dù sao thì cũng có yếu tố "lỗ hổng hai tháng tuổi" + "dịch vụ do sinh viên làm mới hai tháng tuổi"
  • Nếu ứng dụng được phát hành dưới tên "Cerca Applications, LLC", tôi không hiểu làm sao mọi người có thể biết đây là app do sinh viên làm để mà nương tay hơn
  • Có lẽ mấy sinh viên này nên học thứ khác thì hơn
  • Nghe như đang bào chữa cho họ. Không thể có kiểu app do sinh viên làm thì đương nhiên được bỏ qua. The Facebook ban đầu cũng do sinh viên khởi xướng. Lịch sử dài về việc Meta lạm dụng quyền riêng tư và phớt lờ bảo mật dữ liệu thì ai cũng biết. Vì vậy, tôi nghĩ kiểu hành vi này không thể được biện minh, và chỉ có cách quản lý đúng mức, phạt tiền bất kể tuổi tác hay kinh nghiệm của nhà sáng lập mới giải quyết được
  • Nếu định xử lý dữ liệu nhạy cảm như hộ chiếu và xu hướng tính dục, thì tối thiểu cũng phải phản hồi khi có người chỉ ra rằng dữ liệu đang bị lộ. Đây là thảm họa toàn diện, và mức độ thiếu bảo mật ở đây là tuyệt đối không thể chấp nhận
  • Nếu không biết gì về bảo mật ứng dụng thì đơn giản là đừng làm app. Nói hơi cảm tính, nhưng khi thấy bạn bè dùng app hẹn hò, tôi thấy quá kinh khủng khi thông tin của họ có thể bị lộ. Những người làm ra nó nên thấy xấu hổ. Họ cũng nên xấu hổ vì không trả lời liên hệ từ nhà nghiên cứu bảo mật. Nếu là tôi mà bị phớt lờ kiểu đó, tôi đã viết một bài phốt còn thẳng tay hơn nhiều. Làm ơn đừng làm app nữa

• Là một lập trình viên làm ở công ty nhỏ, đôi khi tôi lo về trách nhiệm cá nhân của mình. Nhiều công ty hoạt động trong lĩnh vực không bị ràng buộc bởi các quy định như PCI hay HIPAA. Ở các tổ chức nhỏ, bảo mật thường bị xem là việc của kỹ thuật chứ không phải trách nhiệm của toàn tổ chức. Đội sản phẩm chỉ tập trung vào tính năng, PM chỉ nhìn lịch trình, QA chỉ nhìn bug, và hiếm ai lên tiếng về bảo mật. Không khí chung là kỹ sư chỉ cần làm phần việc được giao. Nếu kỹ sư cố lo luôn cả bảo mật thì tốt, còn không thì lại bị PM hoặc người khác phàn nàn. Và lúc nào cũng nghe những câu như: "Cái này mất bao lâu?", "Khả năng chuyện đó thực sự xảy ra là bao nhiêu?", "Cứ ra MVP nhanh trước rồi vá sau". Thế nên với tư cách nhân viên, tôi chỉ làm điều công ty yêu cầu. Nhưng khi công ty bị kiện vì bị hack hay rò rỉ dữ liệu, tôi thường lo liệu mình có phải là kỹ sư "đáng lẽ phải biết rõ hơn" nên phải chịu trách nhiệm hay không

  • Thực tế thì bạn không phải kỹ sư chứng nhận, cũng không phải người ký vào giấy tờ cam kết an toàn, nên dù chứng minh được là không an toàn thì có lẽ bạn cũng không phải chịu trách nhiệm
  • Nếu công ty là LLC hay Corp thì bạn được bảo vệ bởi 'corporate veil'. Trừ khi bạn có hành vi phạm tội được ghi nhận rõ ràng, còn không sẽ không phải chịu trách nhiệm. Dù vậy, việc thiếu tiêu chuẩn bảo mật ở mọi quy mô doanh nghiệp vẫn là vấn đề lớn. Lúc nào phát hành tính năng mới cũng được coi trọng hơn bảo mật
  • Với tư cách kỹ sư ở tổ chức nhỏ, tôi nghĩ trách nhiệm của chúng ta là giáo dục đội ngũ về các rủi ro này và kiên quyết đòi hỏi phải dành thời gian phát triển cho bảo mật. Không dễ, nhưng nếu xem nhẹ phần này thì chính công ty có thể gặp nguy hiểm
  • Nếu là tôi, tôi sẽ biết luật đủ để tự bảo vệ mình, phản đối mọi yêu cầu bất hợp pháp bằng văn bản, và nếu ai đó phớt lờ thì cũng phải có phê duyệt bằng văn bản rằng có thể bỏ qua. Nhưng ở startup nhỏ thì điều đó cũng có thể khó. Nếu cảm thấy không hợp pháp thì tôi sẽ nghỉ việc luôn
  • Tôi không thích kiểu bào chữa "chỉ làm theo lệnh", nhưng trong các trường hợp này nhất định nên để lại dấu vết bằng văn bản: gửi mail nói có vấn đề bảo mật, rồi lưu lại bằng chứng sếp trả lời kiểu "không cần bận tâm". Theo tôi biết thì chưa thấy trường hợp nhân viên cấp thấp phải chịu trách nhiệm pháp lý cá nhân vì rò rỉ dữ liệu. Thường là chẳng ai phải chịu trách nhiệm, công ty chỉ nộp khoản phạt tượng trưng rồi thôi
  • Nếu không phải lãnh đạo công ty thì tôi nghĩ sẽ không có chuyện phải chịu trách nhiệm cá nhân
  • Theo kinh nghiệm của tôi thì không có chuyện đó

• Để giảm trách nhiệm pháp lý cho nhà nghiên cứu, tôi nghĩ chỉ cần tạo thêm một tài khoản hoặc tạo hồ sơ với sự đồng ý của bạn bè để có quyền truy cập là đủ. Không cần thực sự cào dữ liệu về; ví dụ nếu id của tôi là 12345 và id của bạn tôi là 12357, thì chỉ cần chứng minh có thể truy cập hồ sơ tài khoản khác bằng các id ở giữa là được. Như nhiều người đã nói, không cần phải truy cập dữ liệu cá nhân của hàng nghìn người; chỉ cần mức đủ để chứng minh lỗ hổng và công bố là được

  • Đây là cách làm tiêu chuẩn và rõ ràng mà bất kỳ ai làm nghiên cứu an toàn thông tin đều biết. Có thể bạn muốn cào dữ liệu nhạy cảm để chứng minh, nhưng điều đó là không cần thiết và còn mang tính đạo đức giả

• Bản thân bài viết này cũng khiến tôi thấy khá rối. Có vẻ API nhận OTP (mật khẩu dùng một lần) đơn giản đến mức OTP bị lộ ngay trong phản hồi từ server, nên ai chỉ cần biết số điện thoại là có thể truy cập tài khoản. Vì API kiểu như otp/số-điện-thoại và OTP nằm trong phản hồi, nên có vẻ chỉ cần đoán đúng số điện thoại là lấy được mã luôn. Rồi tác giả nói đã dùng script liệt kê ID người dùng, đặt điều kiện dừng khi gặp 1.000 ID trống liên tiếp, và xác nhận tổng cộng 6.117 người dùng, 207 thông tin giấy tờ tùy thân, 19 sinh viên Yale. Nhưng việc truy cập dữ liệu cá nhân của người khác đến mức này mà không có sự đồng ý khá giống vụ weev hack AT&T rồi vào tù trước đây. Dù quy mô nhỏ hơn, kiểu nghiên cứu này vẫn rủi ro về mặt pháp lý, và tôi lo rằng tác giả không nhận thức được môi trường pháp lý vốn không bảo vệ các nhà nghiên cứu bảo mật

  • Đang nói đến chỗ API otp/số trả lại ngay OTP cuối cùng. Nghĩa là chỉ cần đúng số điện thoại là nhận được OTP ngay lập tức
  • Nếu đọc cáo trạng ban đầu trong vụ Auernheimer, thì ở đó có đủ bằng chứng để chứng minh ý đồ phạm tội (khác với trường hợp này). Họ còn bị cáo buộc thực sự công khai dữ liệu cá nhân ra bên ngoài, nên vụ này chưa đến mức giống vậy

• Tôi cũng từng có trải nghiệm tương tự: muốn báo bug cho một app hẹn hò khác nhưng không liên lạc được, nên tôi đổi hồ sơ của nhà sáng lập thành "hãy liên hệ tôi", rồi họ phục hồi lại từ bản sao lưu. Vài năm sau tôi thấy app đó trên quảng cáo Instagram và thử lại, thì vẫn còn đúng lỗ hổng đó. Chỉ cần biết API endpoint là ai cũng có quyền admin, truy cập toàn bộ tin nhắn/match. Tôi đang cân nhắc có nên liên hệ lại không

  • Có người gợi ý nên liên hệ, thể hiện mình là một nhà phát triển có trách nhiệm, chỉ công bố vấn đề rồi dừng ở đó

• Tôi nghĩ khi thu thập dữ liệu nhạy cảm như hộ chiếu hay địa chỉ trong app thì thật sự phải cân nhắc đi cân nhắc lại. Không thể xem nhẹ kiểu "à vì là app sinh viên làm" rồi cho qua

  • Chính phủ Anh đang cố bắt các trang web khiêu dâm phải yêu cầu giấy tờ tùy thân để truy cập, và tôi đang chờ xem điều đó sẽ dẫn đến chuyện gì
  • Nếu đã yêu cầu thông tin giấy tờ như hộ chiếu, thì sau khi nhập xong, dữ liệu đó tuyệt đối không cần phải bị lộ ra ngoài nữa. Nếu có API để hiển thị dữ liệu giấy tờ trên UI, thì chỉ cần trả về vài ký tự cuối thay vì toàn bộ số là đủ. Với app hẹn hò, chỉ cần trả về việc xác minh ID hay chưa bằng kiểu boolean hoặc enum (chưa xác minh/hộ chiếu/bằng lái xe) là đủ. Những hệ thống phải chọn theo từng loại ID như app hàng không thì là ngoại lệ, nhưng ví dụ app của United cũng chỉ hiển thị vài số cuối, nên tôi mong API nội bộ cũng bị giới hạn theo kiểu đó
  • Chia sẻ link bảo mọi người tham khảo GDPR (luật bảo vệ dữ liệu cá nhân của châu Âu)
  • Tôi nghĩ cần hẳn một dịch vụ xác minh danh tính an toàn và riêng tư do chính phủ vận hành. Hoặc không thì để các công ty kiểu Apple hay Google, những thực thể gần như chính phủ, đảm nhận
  • Bình thường thì nên dùng dịch vụ xác minh danh tính của bên thứ ba, nhưng tôi vẫn thắc mắc liệu mấy dịch vụ đó có thực sự chuyển cả ảnh giấy tờ tùy thân về cho app không

• Việc trả nguyên OTP trong phản hồi API là chuyện quá khó tin. Tôi không hiểu nổi tại sao lại làm thế

  • Họ làm vậy để UI có thể so sánh trực tiếp với giá trị nhập vào. Nếu không nghĩ đến bảo mật thì nghe có vẻ hợp lý. App hẹn hò lại cần một phạm vi dữ liệu cá nhân rất lớn, nên kiểu sai lầm này thật đáng sợ
  • Làm vậy có thể giảm ngay chi phí cơ sở dữ liệu
  • Tạo OTP rồi trả luôn phản hồi từ DB hoặc cache, nếu làm POC hay MVP theo kiểu đại khái thì rất dễ bỏ sót kiểu mô hình này
  • Có vẻ OTP bị lộ nguyên trong "phản hồi cho yêu cầu gửi mật khẩu dùng một lần". Có thể là vì framework serialize toàn bộ đối tượng DB rồi trả qua HTTP
  • Trông có vẻ tốt vì tiết kiệm được một request HTTP và UX nhanh hơn. Pinterest trước đây cũng từng để lộ mọi thông tin, kể cả 2FA secret, trong API cũ. Tôi đã báo cáo và còn nhận thưởng, nên kiểu lỗi này thỉnh thoảng vẫn xảy ra cả ở Big Tech
  • Tôi cũng không hiểu. Tôi chỉ có thể nghĩ đó là một sai lầm nhằm đơn giản hóa việc build form

• Chia sẻ link một bài báo khác liên quan từ Yale Daily News

• Tôi ước có luật đối xử với dữ liệu cá nhân như chất thải hạt nhân, nguy hiểm ở mức đó. Nếu bị rò rỉ thì không chỉ công ty phá sản mà cả những người chịu trách nhiệm cũng phải đối mặt với rủi ro pháp lý. Hiện giờ việc thu thập dữ liệu người dùng quá dễ, mà lộ ra thì chỉ xin lỗi rồi cho qua

  • Đối xử với PII như vật liệu hạt nhân thì có vẻ hơi quá. Những thứ như địa chỉ email chỉ dùng để xác thực/liên hệ thì đâu có vấn đề gì lớn
  • Có khi phải có kiểu án tù cho tội phạm cổ cồn trắng thì người ta mới thực sự quan tâm

• Trên iOS tôi mới biết đến công cụ Charle's Proxy. Trước đây tôi từng pentest bằng cách tự tìm chuỗi trong binary của app. Với việc phân tích app chỉ có trên iOS, có vẻ nó sẽ cực kỳ hữu ích

  • Là công cụ ổn, đáng khuyên dùng (chỉ là nếu có SSL pinning thì sẽ không hiệu quả)