- Chỉ một quy tắc bảo mật Firebase cấu hình sai đã dẫn đến việc dữ liệu người dùng của hàng trăm trang web bị lộ, với quy mô đã xác nhận lên tới khoảng 124,6 triệu bản ghi
- Cuộc điều tra bắt đầu bằng cách tìm biến cấu hình Firebase trong các website và các gói JavaScript được tải; do vấn đề bộ nhớ của scanner Python, công cụ này được viết lại bằng Go
- Scanner phụ trợ Catalyst tự động kiểm tra khả năng đọc được của các collection Firebase, rồi dựa trên dữ liệu mẫu để ước tính loại thông tin bị lộ và quy mô rò rỉ
- Các mục bị lộ được tổng hợp gồm 84.221.169 tên, 106.266.766 email, 33.559.863 số điện thoại, mật khẩu dạng văn bản thuần 20.185.831 mục, và thông tin thanh toán 27.487.924 mục
- Nhóm nghiên cứu đã gửi 842 email báo cáo trong 13 ngày, nhưng chỉ 24% chủ sở hữu trang web sửa cấu hình, 1% phản hồi, và chỉ 2 trang web đề nghị bug bounty
Quét phơi lộ Firebase ở quy mô Internet
- Sau vụ xâm phạm Chattr.ai, một cuộc quét toàn Internet đã được khởi động để tìm PII bị lộ thông qua các instance Firebase cấu hình sai
- Scanner Python đầu tiên kiểm tra các biến cấu hình Firebase trong website hoặc các gói
.jsđược tải, nhưng khi chạy với khoảng 500 thread, mức sử dụng bộ nhớ tăng lên và bị OOM trong vòng 1 giờ - Sau đó, scanner được viết lại bằng Go đã chạy trên 5,5 triệu domain, mất 2–3 tuần, lâu hơn ước tính ban đầu khoảng 11 ngày
- Chỉ với việc rà soát thủ công ban đầu, nhóm đã tìm thấy 136 trang web và 6,2 triệu bản ghi, nhưng khi danh sách ứng viên trở nên quá lớn, việc tự động hóa hoàn toàn là cần thiết
Catalyst và ước tính quy mô phơi lộ
- Catalyst nhận website ứng viên hoặc các gói JavaScript làm đầu vào, tự động kiểm tra quyền truy cập đọc đối với các collection Firebase phổ biến và các collection được nhắc trực tiếp trong JavaScript
- Khi tìm thấy collection có thể đọc được, công cụ thu thập mẫu 100 bản ghi để xác định loại thông tin chứa trong đó, rồi nhân với kích thước toàn bộ collection để ước tính mức độ ảnh hưởng
- Supabase, một đối thủ Firebase mã nguồn mở dựa trên PostgreSQL, được chọn làm kho lưu trữ kết quả; dữ liệu đã xử lý được tải lên các bảng cơ sở dữ liệu riêng tư
- Các số liệu tổng hợp như sau, và quy mô phơi lộ thực tế vẫn có thể lớn hơn con số được hiển thị
- Tổng số bản ghi: 124.605.664
- Tên: 84.221.169
- Email: 106.266.766
- Số điện thoại: 33.559.863
- Mật khẩu: 20.185.831
- Thông tin thanh toán: thông tin ngân hàng, hóa đơn, v.v. 27.487.924
Những trang web bị ảnh hưởng lớn
-
Silid LMS
- Hệ thống quản lý học tập dành cho học sinh và giáo viên
- Bị lộ bản ghi người dùng của 27 triệu người, bao gồm tên, email và số điện thoại, là quy mô lớn nhất
-
Mạng lưới cờ bạc trực tuyến
- Gồm 9 trang web được reskin từ nhau
- Một số lượt spin bị thao túng để xác suất thắng là 0%
- Thông tin đăng nhập chi tiết tài khoản ngân hàng bị lộ nhiều nhất, với 8 triệu mục
- Mật khẩu dạng văn bản thuần cũng ở mức lớn nhất trong các trang bị ảnh hưởng, với 10 triệu mục
- Trong quá trình cố gắng báo cáo vấn đề, bộ phận hỗ trợ khách hàng đã tán tỉnh trong cuộc trò chuyện
-
Lead Carrot
- Dịch vụ tạo lead trực tuyến cho cold call
- Đứng trong top 3 về quy mô thông tin người dùng bị lộ, ảnh hưởng tới 22 triệu người
-
MyChefTool
- Ứng dụng quản lý kinh doanh và POS cho nhà hàng
- Đứng đầu về số tên bị lộ và đứng thứ hai về số email bị lộ, lần lượt là 14 triệu và 13 triệu mục
Phản ứng sau khi báo cáo
- Nhóm nghiên cứu đã gửi 842 email trong 13 ngày
- 85% được gửi thành công và 9% bị trả lại
- 24% chủ sở hữu trang web đã sửa cấu hình sai
- Chỉ 1% chủ sở hữu trang web phản hồi
- 2 chủ sở hữu trang web, tương đương 0,2%, đã đề nghị bug bounty
1 bình luận
Ý kiến trên Hacker News
Tôi đã làm ở Firebase một thời gian dài, và vấn đề security rules đã dai dẳng ám sản phẩm suốt nhiều năm
Chúng tôi đã thử nhiều cách như quy tắc mặc định tự hết hạn, tăng cường đào tạo, v.v., nhưng rốt cuộc vẫn thấy rất nhiều cơ sở dữ liệu không an toàn
Lý do thì phức tạp, nhưng security rules kiểu Firebase vẫn là một khái niệm khá lạ, và khi một lập trình viên mới thêm dữ liệu vào vị trí sẵn có, họ thường không sửa cả rule để phản ánh thay đổi trong yêu cầu riêng tư của dữ liệu
Thêm nữa, kiểu “bảo mật nhờ sự mơ hồ” mà backend tự xây trước đây mang lại đã biến mất, khiến việc quét trên diện rộng trở nên dễ dàng
Đặc biệt, rule của Realtime Database vừa khó viết vừa không mở rộng tốt, nhưng vì việc quét tự động thường chỉ tìm dữ liệu mở, nên chỉ cần tốt hơn
read write truemột chút là đã có thể chặn đượcVề mặt kỹ thuật thì cách tiếp cận của Firebase không hẳn là sai, nhưng vì đây gần như là backend duy nhất dùng mô hình xoay quanh dữ liệu lưu trữ và security rules, nó dễ bị hiểu sai, dùng sai và gặp những sự cố như thế này
Ở backend, việc kiểm tra và quy tắc bảo mật trông như một phần của đặc tả, còn security rules của Firebase là một quy trình tách riêng nên rất dễ bị quên, và mỗi khi làm tính năng mới lại phải đánh giá lại
Có lẽ phải escalte lên cấp khá cao bên trong Firebase thì mới thu hút được sự chú ý của người có thể thông báo cho chủ dự án
Ví dụ, các mẫu như “chỉ chủ sở hữu nội dung được truy cập” hay “truy cập theo thuộc tính / theo vai trò” trong bài có đủ bao phủ phần lớn mẫu ứng dụng không, hay thực sự vẫn cần rất nhiều rule tùy biến
Vấn đề lớn của việc viết security rules là gần như mọi sai sót đều trở thành vấn đề bảo mật, nên nếu không cần thì tôi không muốn đụng vào
Nếu rule khóa quá chặt thì ứng dụng sẽ hỏng và lộ ra ngay, nhưng nếu mở quá rộng thì thường không dễ nhận ra cho tới khi ai đó chủ động chọc thử quyền truy cập quá mức
Liên quan đến đó, cũng đáng cân nhắc việc buộc lập trình viên phải viết các test case ví dụ bị từ chối truy cập cho từng security rule
fireplansẽ thêm rule mặc định"$other": {".read": false, ".write": false}cho mọi thuộc tínhNhờ vậy, các field mới phải được thêm một cách tường minh, khiến việc giá trị mới vô tình “kế thừa” rule cũ gần như không thể xảy ra
Tôi đã dùng Firebase hơn 10 năm nên không rõ các công cụ rule mới nhất có làm như vậy không
Phần thực sự hữu ích sẽ là hỗ trợ mặc định cho việc đổi tên field hoặc thay đổi cấu trúc dữ liệu trong bối cảnh có nhiều phiên bản client khó kiểm soát, cách test rule nhẹ nhàng mà không cần dựng database, và thông tin debug tốt hơn khi rule thất bại trong môi trường production
Mỗi lần thất bại, hệ thống nên ghi lại mọi giá trị mà rule đã truy cập, để có thể debug các lỗi thoáng qua phát sinh do dữ liệu thay đổi
Đây là một mô hình khái niệm chưa được giải thích đầy đủ
Trong dự án, tôi thường nói rằng mỗi collection nên có các hồ sơ bảo mật như công khai, dữ liệu người dùng, chỉ hiển thị cho người dùng đã xác thực, chỉ dành cho quản trị viên; và nên tiếp cận theo hướng dùng các hàm security rule để ép buộc những nhóm này, thay vì viết điều kiện tùy biến cho từng collection
Nghĩ về bảo mật ở cấp collection thay vì cấp field sẽ giúp giảm việc trộn lẫn các ý đồ bảo mật khác nhau trong cùng một document
Nếu collection là công khai thì không nên chứa field không công khai; nếu cần, có thể dùng Firestore trigger để sao chép dữ liệu từ ngữ cảnh nhạy cảm sang ngữ cảnh công khai, nhưng không thể theo chiều ngược lại
Vấn đề là phải tài liệu hóa ý đồ của rule ở bên ngoài chính bản thân rule, nên rất dễ áp dụng sai; trước đây việc viết test cũng rất khổ sở, nhưng giờ đã khá hơn nhiều
Tôi nhớ đến “How I pwned half of America’s fast food chains, simultaneously.”: https://mrbruh.com/chattr/
HN: https://news.ycombinator.com/item?id=38933999
After the initial buzz of [pwning Chattr.ai] had settled down, […]Nếu tôi không nhìn nhầm, thì tính đến cuối bài, nghĩa là 75% các website có lỗ hổng kiểu này vẫn còn mở toang và có thể dump dữ liệu đúng không?
Quá điên rồ
Có những ngày tôi nghĩ rằng muốn chạm vào máy tính thì nên cần có giấy phép
Họ thuê ngoài cho các agency làm website, còn agency thì liên tục thay người: lúc đầu giao cho người giỏi, sau đó miễn là công ty không phàn nàn thì hợp đồng sẽ được chuyển cho các lập trình viên kém kinh nghiệm hơn
Email thông báo lỗ hổng có thể đã bị bỏ qua như spam, hoặc được chuyển tiếp rồi bị bỏ mặc, hoặc bị đưa vào hàng chờ họp của PM như một hạng mục sẽ sửa trong khi vẫn cố tính phí khách hàng tối đa
Ngay cả trong những ngành bắt buộc phải có giấy phép hành nghề cũng có rất nhiều người có giấy phép nhưng vẫn kém năng lực
Bác sĩ cũng phải trải qua đào tạo và yêu cầu cấp phép cực kỳ khắt khe, nhưng bác sĩ lang băm và những người hành nghề y học thay thế có giấy phép cũng chẳng hề hiếm
Tôi đã cố hết sức bằng cách gửi email tùy chỉnh cho từng website, nêu rõ nội dung bị ảnh hưởng, cách khắc phục và cách liên hệ
Đây là kết quả tất yếu của việc PM chọn rẻ và nhanh trong tam giác cheap-fast-good
Đáng tiếc là những lo ngại của một số khách hàng và người dùng đã bị loại khỏ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ả
Trong số các công ty được liệt kê ở đây, tôi sẽ cẩn trọng với những nơi đã đưa ra quyết định như vậy mà đội ngũ lãnh đạo vẫn không thay đổi
Việc nhiều công ty không thực sự quan tâm đủ để bảo vệ khách hàng đã được chứng minh nhiều lần, và lịch sử luôn lặp lại
Tôi có một câu hỏi rất cơ bản về Firebase: phần lớn các ứng dụng trong bài này có được xây dựng chỉ bằng JavaScript phía client được host tĩnh, không có code server tùy chỉnh không?
Ý là backend chỉ là cấu hình Firebase do Google host 100% phải không?
Nếu vậy thì tôi không biết rằng kiểu kiến trúc này lại trở nên phổ biến đến thế ở các site có hàng triệu người dùng
Khi đặt mô hình bảo mật mặc định cho phép ở API thì kết cục tất yếu sẽ là như vậy
Đáng tiếc là trong các thư viện nhắm tới lập trình viên JavaScript, các giá trị mặc định không an toàn là chuyện thường gặp, và GraphQL cũng có vẻ là một khu vực dễ phát sinh kiểu vấn đề này
Firebase còn có Firebase Functions, tức các hàm có thể gọi trên đám mây, và code của chúng không được công khai
Nhưng Firestore hay Firebase Realtime Database thì đều yêu cầu người dùng tự thiết lập quy tắc bảo mật, nếu không thì ai cũng có thể đọc toàn bộ dữ liệu
Điều quan trọng là phải giúp việc viết các quy tắc phân quyền đúng đắn ở backend trở nên dễ dàng
Đọc mấy chuyện như thế này khiến tôi thấy may vì đã chọn dùng trình quản lý mật khẩu và thẻ ảo từ lâu
Dù vậy, Internet vẫn ngày càng đáng sợ hơn
Phần lớn mọi người hoàn toàn không biết web mong manh đến mức nào và bản thân họ đang bị phơi lộ ra sao
Các AI agent sẽ tìm lỗ hổng hiệu quả hơn bot rất nhiều, nên có cảm giác như một tương lai kỳ quái đang chờ phía trước
Bạn nên dùng địa chỉ email riêng biệt cho từng dịch vụ mình đăng ký
Như vậy khi có sự cố sẽ giới hạn được thiệt hại, đồng thời ngăn việc thu thập thông tin công khai bằng cách đối chiếu với các dịch vụ khác
Thỉnh thoảng nếu email độc hại được gửi đến đúng địa chỉ riêng đó, bạn thậm chí có thể phát hiện bị xâm phạm còn sớm hơn cả người vận hành website
Có ai biết thêm về đoạn “một chương trình Python với khoảng 500 thread bắt đầu ngốn bộ nhớ theo thời gian” không?
Tôi cũng có một scraper bằng Python với vài trăm thread và có vẻ nó đang ăn khá nhiều bộ nhớ
Tôi muốn biết có cách lách nào không, hay giải pháp duy nhất là viết lại bằng ngôn ngữ khác
Cá nhân tôi thích process hơn thread, và dùng worker pool cùng message bus thay vì shared memory
Cách này cũng có nhược điểm và một chút overhead, nhưng bạn sẽ ít phải lo về vấn đề bộ nhớ hơn nhiều
Crawler có số lượng process tương đối ổn định và công việc của từng process là độc lập, nên có vẻ mô hình process phù hợp hơn
import multiprocessing as threadingViết lại gần như là giải pháp thực tế duy nhất
Đây là một use case cực kỳ phù hợp
Làm tốt lắm
Tôi tò mò không biết bạn đã đi đến kết luận rằng số người dùng bị ảnh hưởng thực tế có thể còn lớn hơn bằng cách nào
Nhìn qua thì có vẻ một số site như cờ bạc hay Lead Carrot có thể lẫn rất nhiều dữ liệu tài khoản giả
Đây là cách chỉ hoạt động tốt trên các site tiếng Anh
Lý do tôi nói con số có thể lớn hơn là vì những dịch vụ khác không có trong danh sách quét cũng có khả năng dễ bị tổn thương