900 trang web, 125 triệu tài khoản, 1 lỗ hổng

Lần thử đầu tiên

• Một trình quét cơ bản viết bằng Python kiểm tra các biến cấu hình Firebase.
• Dừng hoạt động trong vòng một giờ do vấn đề tiêu thụ bộ nhớ.

Lần thử thứ hai

• Trình quét được viết lại bằng Go không còn rò rỉ bộ nhớ.
• Việc quét hơn 5 triệu tên miền mất nhiều thời gian hơn dự kiến.

Kiểm tra thủ công tất cả tên miền

• Kiểm tra thủ công từng mục trong tệp văn bản 550 nghìn dòng.
• Đã xác nhận 136 trang web và 6,2 triệu bản ghi bị ảnh hưởng, nhưng nhận ra cần một phương pháp tự động hóa.

Chất xúc tác

• Kiểm tra danh sách các trang web có khả năng bị ảnh hưởng bằng một trình quét phụ có tên là Catalyst.
• Tự động kiểm tra quyền truy cập đọc vào các collection Firebase phổ biến từ trang web hoặc các gói .js.
• Thu thập mẫu 100 bản ghi và xác định loại thông tin để đánh giá mức độ tác động của dữ liệu.
• Chọn Supabase (đối thủ mã nguồn mở của Firebase) để lưu trữ kết quả.

Các con số

• Tổng số bản ghi: 124.605.664
• Tên: 84.221.169
• Email: 106.260.766
• Số điện thoại: 33.559.863
• Mật khẩu: 20.185.831
• Thông tin thanh toán: 27.487.924
• Lưu ý rằng các con số này có thể lớn hơn thực tế.

Danh sách các trang web bị ảnh hưởng

1. Silid LMS

• Hệ thống quản lý học tập dành cho học sinh và giáo viên.
• Làm lộ nhiều hồ sơ người dùng nhất, ảnh hưởng đến 27 triệu người.

2. Mạng cờ bạc trực tuyến

• Gồm 9 trang web, tất cả đều có thiết kế khác nhau.
• Một số trò chơi bị thao túng để xác suất thắng là 0%.
• Khi cố gắng báo cáo vấn đề, bộ phận hỗ trợ khách hàng lại tìm cách dụ dỗ.
• Làm lộ nhiều thông tin tài khoản ngân hàng nhất, 8 triệu bản ghi.
• Làm lộ nhiều mật khẩu dạng văn bản thuần nhất, 10 triệu bản ghi.

3. Lead Carrot

• Công cụ tạo lead trực tuyến cho hoạt động gọi điện chào hàng.
• Là một trong 3 trang web đứng đầu về lượng thông tin người dùng bị lộ, ảnh hưởng đến 22 triệu người.

4. MyChefTool

• Ứng dụng quản lý kinh doanh và point-of-service cho nhà hàng.
• Làm lộ nhiều tên nhất và nhiều email đứng thứ hai, lần lượt là 14 triệu và 13 triệu.

Kết quả

• Gửi 842 email trong 13 ngày.
• 85% email đến được nơi nhận.
• 9% email bị trả lại.
• 24% chủ sở hữu trang web đã sửa lỗi cấu hình.
• 1% chủ sở hữu trang web đã phản hồi.
• 0,2% (2) chủ sở hữu trang web đã đưa ra bug bounty.

Ý kiến của GN⁺

• Nghiên cứu này cho thấy việc cấu hình sai thiết lập bảo mật Firebase có thể xảy ra dễ đến mức nào. Đây là một ví dụ quan trọng giúp nâng cao cảnh giác của các nhà phát triển đối với cấu hình bảo mật.
• Có thể thấy phản ứng của các chủ sở hữu trang web rất đa dạng khi phát hiện vấn đề bảo mật. Phần lớn đã khắc phục sự cố, nhưng một số đã phớt lờ hoặc không đưa ra đền bù phù hợp.
• Các công cụ tự động được dùng để tìm ra những lỗ hổng bảo mật này cũng có thể hữu ích cho các nhà nghiên cứu bảo mật khác. Những công cụ cung cấp chức năng tương tự có thể kể đến OWASP ZAP, Burp Suite.
• Khi sử dụng các dịch vụ đám mây như Firebase, việc hiểu và áp dụng chính xác các thiết lập bảo mật là rất quan trọng. Cấu hình sai có thể dẫn tới rò rỉ dữ liệu quy mô lớn.
• Trường hợp này cũng có thể giúp ích khi cân nhắc các dịch vụ khác, bao gồm cả lựa chọn mã nguồn mở Supabase, để so sánh tính năng bảo mật và mức độ dễ sử dụng. Supabase dựa trên PostgreSQL và cung cấp các tính năng tương tự Firebase nhưng là mã nguồn mở.

[GN⁺]

Ý kiến trên Hacker News

• Một người dùng từng làm việc lâu năm với Firebase cho biết các vấn đề liên quan đến quy tắc bảo mật luôn là nỗi đau của sản phẩm này. Dù đã thử nhiều cách tiếp cận khác nhau, họ vẫn nhận thấy rất nhiều cơ sở dữ liệu dễ bị tổn thương về bảo mật. Nguyên nhân là do quy tắc bảo mật của Firebase là một khái niệm mới và phức tạp, và các nhà phát triển có xu hướng không sửa quy tắc bảo mật khi thêm dữ liệu mới vào dữ liệu hiện có. Ngoài ra, vì không có backend tùy chỉnh nên việc quét trên diện rộng trở nên dễ dàng, còn việc viết quy tắc bảo mật cho cơ sở dữ liệu thời gian thực thì khó và kém khả năng mở rộng. Tuy nhiên, vì các đợt quét tự động thường chỉ tìm dữ liệu đang mở, nên vấn đề này không xảy ra thường xuyên như người ta nghĩ. Bản thân cách tiếp cận của Firebase không có vấn đề kỹ thuật, nhưng vì đây là một trong số ít backend duy nhất dựa trên dữ liệu được lưu trữ và quy tắc bảo mật, nên rất dễ bị hiểu sai, sử dụng không đúng cách và dẫn đến những vấn đề như thế này.
• Một người dùng nói rằng tình huống này khiến họ nhớ đến vụ hack các chuỗi thức ăn nhanh ở Mỹ.
• Một người dùng khác chỉ ra rằng theo phần cuối của bài viết, 75% số trang web có lỗ hổng này vẫn đang chờ bị tung dữ liệu dump, và đánh giá điều đó là điên rồ. Họ nói thêm rằng đôi khi họ nghĩ nên cần chứng chỉ thì mới được dùng máy tính.
• Một người dùng nhận xét rằng đây là hệ quả tất yếu của việc chọn thứ rẻ và nhanh; một số lo ngại của khách hàng/người dùng đã bị bỏ ngoài cuộc thảo luận, và dữ liệu cá nhân của họ đã trở thành cái giá phải trả. Họ cảnh báo nên cẩn trọng với những công ty trong danh sách này mà ban lãnh đạo vẫn chưa thay đổi, vì đã nhiều lần được chứng minh rằng nhiều công ty không thực sự quan tâm đủ đến việc bảo vệ khách hàng.
• Một người dùng khác đặt câu hỏi cơ bản rằng phần lớn các ứng dụng được nhắc đến trong bài này có phải được triển khai hoàn toàn bằng JavaScript phía client được host tĩnh, với backend là cấu hình Firebase được Google host 100% hay không. Nếu đúng như vậy, họ nói rằng trước giờ mình không nhận ra kiến trúc kiểu này lại phổ biến đến thế ở các trang web có hàng triệu người dùng.
• Một người dùng đùa rằng: 900 trang web, 125 triệu tài khoản, 1 lỗ hổng, 0 bạn gái.
• Một người dùng khác bày tỏ sự biết ơn vì đã chọn dùng trình quản lý mật khẩu và thẻ ảo từ lâu do những tình huống như thế này. Họ nói rằng Internet giờ thấy đáng sợ hơn, vì đa số mọi người không biết web mong manh đến mức nào và bản thân họ dễ bị tổn thương ra sao.
• Một người dùng cho biết họ phát hiện một chương trình Python có khoảng 500 thread ngày càng dùng nhiều bộ nhớ hơn theo thời gian, và hỏi liệu có thêm thông tin hay cách giải quyết nào cho vấn đề này không. Họ nói scraper Python của mình cũng có hàng trăm thread và có vẻ dùng rất nhiều bộ nhớ.
• Một người dùng khen đây là một công việc tốt, đồng thời muốn biết tác giả đã đi đến kết luận rằng số người dùng bị ảnh hưởng có thể còn nhiều hơn bằng cách nào. Họ nghi ngờ một số trang được nhắc đến (cờ bạc, lead carrot) có thể chứa đầy dữ liệu tài khoản giả.
• Cuối cùng, một người dùng cảm ơn vì bộ phận hỗ trợ khách hàng đã mang lại tiếng cười.