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
(alexschapiro.com)- Cerca Dating App kết hợp đăng nhập dựa trên số điện thoại với API bị lộ, tạo ra tình trạng nguy hiểm khi mã xác thực được chứa ngay trong phản hồi OTP và thậm chí có thể dẫn đến tra cứu thông tin cá nhân
api.cercadating.comsẽ làm lộ các endpoint qua openapi.json trong/docsnếu gắn header phiên bản ứng dụng, và một số yêu cầu còn có thể thao túng cả logic nghiệp vụ như ép hai người được ghép cặpuser/{user_id}trả về PII như tên, vị trí, ngày sinh, trường học, số điện thoại, email, trạng thái hồ sơ... chỉ với một user ID hợp lệ, và khi kết hợp với lỗ hổng OTP có thể dẫn đến chiếm đoạt tài khoản- Sau khi truy cập được tài khoản, có thể tiếp cận cả thông tin hộ chiếu hoặc giấy tờ tùy thân, URL ảnh selfie và tin nhắn riêng tư đối với những người dùng đã gửi dữ liệu này; bằng script xác minh đã tìm thấy 6.117 người dùng, 207 người đã nhập thông tin giấy tờ và 19 người được đánh dấu là sinh viên Yale
- Lỗ hổng đã được báo cho Cerca vào ngày 23/2/2025 và còn có cuộc gọi vào ngày 24/2, nhưng cho đến thời điểm công bố ngày 21/4 vẫn không có phản hồi tiếp theo hay thông báo tới người dùng, chỉ việc vá lỗi là được xác nhận độc lập
Phản hồi bị ngắt quãng sau khi báo cáo
- Cerca Dating App có lỗ hổng bảo mật ứng dụng hẹn hò khiến tin nhắn riêng tư, thông tin hộ chiếu, xu hướng tình dục và các dữ liệu cá nhân khác có thể bị lộ
- Sau khi phát hiện lỗ hổng, tác giả đã báo cho đội ngũ Cerca qua email vào ngày 23/2/2025, rồi trong cuộc gọi video ngày hôm sau đã thảo luận về lỗ hổng, biện pháp giảm thiểu và các bước tiếp theo
- Đội ngũ Cerca thừa nhận mức độ nghiêm trọng của vấn đề, cảm ơn vì việc công bố có trách nhiệm, đồng thời hứa sẽ khắc phục lỗ hổng và thông báo cho người dùng bị ảnh hưởng
- Sau đó, tác giả đã yêu cầu cập nhật về kế hoạch sửa lỗi và thông báo cho người dùng vào ngày 5/3 và 13/3, nhưng đến thời điểm công bố 21/4/2025 vẫn không nhận được phản hồi
- Trước khi công bố, việc lỗ hổng đã được vá được xác nhận độc lập, và việc công bố được thực hiện dựa trên điều đó
Truy cập tài khoản bắt đầu từ đăng nhập OTP
- Ứng dụng chỉ dùng đăng nhập dựa trên OTP gửi mã đến số điện thoại
- Để kiểm tra các yêu cầu mạng, tác giả đã chặn các request từ ứng dụng iPhone bằng Charles Proxy
- Trong phản hồi kích hoạt OTP, mật khẩu dùng một lần được đưa trực tiếp vào phản hồi
- Với cấu trúc này, chỉ cần biết số điện thoại của người dùng là có thể truy cập vào tài khoản đó
- Vì cần một con đường khác để biết số điện thoại của chủ tài khoản, tác giả tiếp tục dò tìm các endpoint API
Các endpoint bị lộ qua tài liệu OpenAPI
- Tác giả dùng directory fuzzer để liệt kê các đường dẫn trên
api.cercadating.com - Nếu không có header liên quan đến ứng dụng thì không thể truy cập bất kỳ phần nào của trang
- Khi thêm header đó vào Gobuster, tác giả tìm thấy endpoint
/docs, tại đó có cung cấpopenapi.json - Tác giả dùng tính năng match-and-replace của Burp Suite để luôn gắn header phiên bản ứng dụng và bearer token lấy từ Charles Proxy
- Một số endpoint không được bảo vệ còn tác động đến logic nghiệp vụ, thậm chí có thể gửi yêu cầu để ép hai người được ghép cặp
Hồ sơ người dùng và lộ thông tin cá nhân
- Endpoint
user/{user_id}trả về nhiều loại thông tin cá nhân nếu nhận được một user ID hợp lệ - Phản hồi bao gồm các thông tin sau
- Tên, giới tính, giới tính quan tâm, thành phố, vĩ độ và kinh độ
- Email trường học và trạng thái xác minh, ngành nghề, công việc, ngày sinh, chiều cao
- ID trường học và tên trường, trạng thái hoàn thiện hồ sơ
- Trạng thái xác minh ID quốc gia, xác minh di động và email
- Trạng thái premium, trạng thái tài khoản đang hoạt động, tạm dừng hay onboarding
- Số điện thoại, email, user ID, số lượt tìm kiếm còn lại
- Ảnh hồ sơ, sở thích ghép đôi, prompt của người dùng, thông tin liên hệ hai chiều, thời điểm tạo và sửa, tuổi...
- Bằng script Python, có thể tìm user ID hợp lệ và liệt kê dữ liệu người dùng trên diện rộng
- Các số điện thoại được trả về có thể kết hợp với lỗ hổng OTP để dùng cho truy cập toàn bộ tài khoản
- Thông tin cá nhân của người dùng bị lộ ngay cả khi không cần đăng nhập OTP
Truy cập dẫn tới cả giấy tờ tùy thân và tin nhắn riêng tư
- Trường
national_id_verifiedcho thấy hệ thống có lưu thông tin hộ chiếu hoặc giấy tờ tùy thân - Phản hồi liên quan đến giấy tờ tùy thân bao gồm các thông tin sau
verification_type:PASSPORTdocument_numberfront_side_urlback_side_urlselfie_url- trạng thái, ID, user ID
- Dữ liệu này chỉ được cung cấp cho người dùng đã đăng nhập, nhưng do lỗ hổng OTP nên có thể đăng nhập dưới danh nghĩa người dùng bất kỳ
- Tác giả cho biết cấu trúc này cho phép xem thông tin giấy tờ của bất kỳ ai đã nộp, nhưng trên thực tế đã không làm vậy
- Cũng có thể xem tin nhắn riêng tư với những người hẹn hò tiềm năng và, nếu đã nộp, cả thông tin hộ chiếu
Quy mô lộ lọt đã được xác minh
- Bằng một script nhanh, tác giả đã thống kê số người dùng có thể lấy được thông tin, số người dùng được đăng ký là sinh viên Yale và số người đã nhập thông tin giấy tờ
- Script hoạt động bằng cách đếm các user ID hợp lệ và dừng lại nếu không tìm thấy ID hợp lệ nào trong 1.000 lần liên tiếp
- Cách này không loại trừ khả năng vẫn còn nhiều người dùng hơn nữa
- Cerca cho biết số người dùng trong tuần đầu là 10.000
- Các con số được xác minh như sau
- 6.117 người dùng
- 207 người dùng đã nhập thông tin giấy tờ
- 19 người dùng được đánh dấu là sinh viên Yale
Cam kết bảo vệ dữ liệu và rủi ro thực tế
- Chính sách quyền riêng tư của Cerca nói rằng họ “bảo vệ dữ liệu bằng mã hóa và các biện pháp tiêu chuẩn ngành khác”
- Khi so với tình trạng lỗ hổng thực tế, câu này có thể gây hiểu nhầm
- Dữ liệu có nguy cơ bị lộ bao gồm xu hướng tình dục, tin nhắn riêng tư và nhiều loại thông tin cá nhân khác
- Nếu kẻ xấu truy cập được các dữ liệu này, hậu quả có thể là đánh cắp danh tính, theo dõi, tống tiền
- Vì ứng dụng hẹn hò xử lý dữ liệu nhạy cảm, bảo mật dữ liệu người dùng phải được ưu tiên hơn tốc độ ra mắt ứng dụng
1 bình luận
Các ý kiến trên Hacker News
Ứng dụng này có vẻ là một dự án khá sơ khai do sinh viên đại học làm. Đúng là họ nên cố gắng hết sức để tuân thủ đúng các thông lệ về bảo mật và giao tiếp, nhưng nghĩ đến việc cả những “công ty người lớn” nhận vốn VC lớn cũng xử lý những vấn đề tương tự rất tệ, tôi không muốn chỉ trích quá gay gắt
https://georgetownvoice.com/2025/04/06/georgetown-students-c...
Giống như một tài xế gây tai nạn chết người rồi hóa ra còn không có bằng lái
Bài gốc nói họ đã liên hệ với đội Cerca vào tháng 2, nên hoặc đây là lỗi được phát hiện vào ngày ra mắt, hoặc cấu trúc có gì đó kỳ lạ. Dù sao thì đây cũng là “lỗ hổng tồn tại hai tháng” và là “ứng dụng/dịch vụ do sinh viên làm mới hai tháng”
Hơn nữa đây không phải đồ làm cho vui mà là sản phẩm thương mại. Các mục mua trong ứng dụng đang được niêm yết là Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99, 5 Searches $2.99
Là kỹ sư ở một công ty nhỏ, đôi khi tôi lo về trách nhiệm cá nhân của mình. Có quá nhiều công ty hoạt động trong các ngành không bị quản lý, không áp dụng PCI hay HIPAA; ở các tổ chức nhỏ, bảo mật không được xem là nghĩa vụ ở cấp tổ chức mà chỉ bị đẩy thành mối quan tâm của đội kỹ thuật
Đội sản phẩm tập trung vào tính năng, PM vào lịch trình, QA vào tìm lỗi, và hiếm có ai lên tiếng một cách hợp lý về bảo mật. Kỹ sư không được kỳ vọng làm gì hơn ngoài hoàn thành các việc trên bảng. Nếu có thể làm cho an toàn mà không ảnh hưởng lịch trình thì tốt, còn không thì sẽ bị PM hoặc người khác gây áp lực
Bạn sẽ nghe những câu như “mất bao lâu?”, “nguy cơ chuyện đó thực sự xảy ra là bao nhiêu?”, “để sau xử lý bảo mật, trước mắt cứ đưa MVP cho khách hàng đã”. Với tư cách nhân viên, tôi làm việc mà chủ yêu cầu, nhưng nếu công ty bị kiện vì bị hack hoặc rò rỉ dữ liệu, liệu tôi có phải chịu trách nhiệm cá nhân vì là người duy nhất “đáng lẽ phải biết” không?
Tuy vậy, việc thiếu tiêu chuẩn bảo mật trên toàn tổ chức, bất kể quy mô, là đáng thất vọng. Có vẻ việc ra tính năng mới lúc nào cũng được ưu tiên hơn bảo đảm các thông lệ bảo mật tốt
Tuy nhiên tôi hiểu rằng ở startup chỉ có một hai lập trình viên thì ngay cả việc này cũng khó. Nếu cảm thấy họ không theo đuổi những việc hợp pháp, có lẽ tôi sẽ rời đi
Việc đó không dễ, nhưng là chuyện quan trọng có thể đánh chìm cả doanh nghiệp nếu không được xử lý nghiêm túc
Cần có email ghi lại việc bạn nêu lo ngại về thiếu sót bảo mật, và phản hồi của cấp trên bảo bạn đừng bận tâm. Không rõ ở khu vực nào, nhưng tôi chưa biết trường hợp nhân viên bình thường nào phải chịu trách nhiệm pháp lý cá nhân vì rò rỉ dữ liệu. Thường thì các vụ rò rỉ dữ liệu không khiến ai chịu hậu quả thực chất, công ty chỉ nộp một khoản phạt mang tính hình thức rồi cho qua
Với tư cách nhà nghiên cứu, để giảm rủi ro pháp lý thì có lẽ chỉ cần tạo tài khoản thứ hai hoặc nhờ bạn bè tạo hồ sơ và đồng ý cho truy cập là đủ
Không cần thật sự thu thập dữ liệu để chứng minh lỗ hổng liệt kê. Nếu ID của tôi là 12345 và bạn tôi đăng ký được 12357, thế là đủ bằng chứng rằng có thể tìm ID của bất kỳ người dùng nào và truy cập hồ sơ của họ
Như những người khác đã nói, để xác minh và công bố lỗ hổng, không cần truy cập nhiều thông tin định danh cá nhân của người dùng khác đến vậy
Vừa muốn thông tin định danh cá nhân được bảo vệ, lại vừa thu thập nó để chứng minh, là điều không cần thiết và đạo đức giả
Bài viết khá rối. Phần nói rằng trong đăng nhập dựa trên OTP, phản hồi của yêu cầu mật khẩu dùng một lần trả về nguyên OTP còn thiếu giải thích, nhưng có lẽ ý là do một API kiểu api.cercadating.com/otp/, nên nếu đoán được số điện thoại thì có thể nhận mã OTP ngay cả khi không sở hữu số đó
Ngoài ra, tác giả nói đã dùng một script dừng lại nếu không có người dùng hợp lệ trong 1.000 ID liên tiếp để tìm ra 6.117 người, 207 người có thông tin giấy tờ tùy thân và 19 người tự nhận là sinh viên Yale; không rõ tác giả có hiểu việc này nguy hiểm đến mức nào không. Về cơ bản nó khá giống cách weev xâm phạm AT&T, và anh ta đã phải vào tù[0]
Dù đó là một công ty lớn hơn và một vụ rò rỉ lớn hơn, tôi không nghĩ mình sẽ công khai khoe rằng đã lợi dụng lỗ hổng bảo mật để truy cập trái phép dữ liệu của hàng nghìn người. Tôi không có ý phán xét đạo đức, và cho rằng các nhà nghiên cứu bảo mật cần có không gian để cảnh báo, nhưng luật pháp khá bất lợi cho họ
[0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...
Các bị cáo trong vụ đó cũng bị cáo buộc công khai thông tin nhận dạng cá nhân cơ bản, còn ở đây thì không có vẻ là đã xảy ra việc như vậy
Tôi từng gặp chuyện tương tự với một ứng dụng hẹn hò khác, nhưng bên đó rốt cuộc không bao giờ phản hồi. Để thu hút sự chú ý của nhà sáng lập, tôi đổi phần giới thiệu của anh ta thành câu “hãy liên hệ với tôi”, rồi họ khôi phục bản sao lưu
Vài năm sau, thấy quảng cáo trên Instagram nên tôi kiểm tra xem vấn đề còn không, và nó vẫn còn. Chỉ cần biết API endpoint rất dễ tìm qua app-proxy-server là bất kỳ ai cũng có toàn quyền quản trị và truy cập được tất cả tin nhắn, ghép đôi, v.v.
Tôi đang nghĩ có nên quay lại thử thêm lần nữa không
Trước khi nhận những thông tin nhạy cảm như hộ chiếu hay địa chỉ, cần buộc mọi người suy nghĩ kỹ lại. Không thể cứ xem chuyện này là trẻ con làm app rồi cho qua
Với một trang hẹn hò, API chỉ cần trả về boolean verified/not-verified cho trạng thái giấy tờ, hoặc một enum như ‘not-verified’, ‘passport’, ‘drivers-license’ là đủ. Không có nhu cầu thực sự phải hiển thị chi tiết trên client/UI
Trường hợp như ứng dụng hàng không, nơi phải chọn giấy tờ định danh cho mục đích xuất nhập cảnh, có thể là ngoại lệ và hiển thị nhiều thông tin hơn, nhưng như app United chỉ hiện vài chữ số cuối của số hộ chiếu là được. Tôi cũng mong API nội bộ chỉ gửi đến mức đó
Hoặc nếu không thì một nơi “gần như chính phủ” như Apple hay Google cũng có thể đảm nhận
https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
Việc trả về OTP trong phản hồi của API yêu cầu là vô lý. Tại sao lại làm vậy?
Nếu không nghĩ đến bảo mật thì đó là một giải pháp rất có vẻ hợp lý và hiển nhiên. Ứng dụng hẹn hò vốn là một trong những loại app nguy hiểm nhất để xây dựng vì bắt buộc chứa nhiều thông tin nhận dạng cá nhân, và chuyện này thật kinh khủng
Trong các proof of concept nhanh hoặc MVP, người ta thường dùng thẳng model lưu trữ làm phản hồi API để tiết kiệm thời gian, nên rất dễ bỏ sót
Khi API mới của Pinterest ra mắt, nó rải toàn bộ thông tin người dùng cho mọi app dùng tích hợp OAuth, thậm chí bao gồm cả bí mật xác thực hai yếu tố. Tôi đã báo cáo và nhận tiền thưởng, nhưng những chuyện kiểu này vẫn xảy ra ngay cả ở API của các công ty lớn vốn đáng lẽ phải hiểu rõ hơn
Có khả năng là do framework. Có lẽ họ đưa đối tượng lưu vào cơ sở dữ liệu rồi ORM hoặc hệ thống lưu trữ nào đó tuần tự hóa thẳng nó thành phản hồi HTTP
https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
Đây là một bài viết khác về vụ này
Ước gì có luật khiến việc lưu trữ thông tin nhận dạng cá nhân nguy hiểm ngang với lưu trữ chất thải hạt nhân. Nếu bị rò rỉ, công ty gần như chắc chắn phải phá sản, và những người chịu trách nhiệm phải đối mặt với rủi ro pháp lý
Tôi nghĩ đây là cách tốt nhất để căn chỉnh lại động cơ. Hiện giờ gần như không có bất lợi nào khi lưu càng nhiều thông tin người dùng càng tốt. Rò rỉ dữ liệu ư? Đăng một tweet xin lỗi rồi tiếp tục là xong
Như vậy vấn đề này mới nhận được sự chú ý xứng đáng
Nếu “không nhận được bất kỳ phản hồi nào”, thì đã đến lúc thông báo rằng nếu sự im lặng tiếp diễn, lỗ hổng sẽ được công bố sau 90 ngày