- Một nhà nghiên cứu bảo mật đã phát hiện trên subdomain liên quan đến a16z là
portfolio.a16z.comrằng toàn bộprocess.envcủa một Heroku instance đã được chèn động vào JavaScript - Các giá trị bị lộ bao gồm nhiều thông tin xác thực dịch vụ như
DATABASE_URL,AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,SALESFORCE_CLIENT_SECRET,OKTA_CLIENT_SECRET,MAILGUN_API_KEY... - Nhà nghiên cứu cho biết trong một lần kiểm tra thông thường để tìm secret trong file JS bằng
lunchcat, họ đã bắt được tham chiếu tới khóa AWS, và có thể xác nhận chỉ bằng tab Sources trong công cụ dành cho nhà phát triển của trình duyệt - Phạm vi ảnh hưởng được nói là bao gồm cơ sở dữ liệu chứa PII, AWS, Salesforce và Mailgun; với Mailgun, nhà nghiên cứu cho rằng có thể gửi email tùy ý từ domain a16z và đọc các email trước đó
- a16z không trả bug bounty với lý do đã có nỗ lực liên hệ công khai, còn nhà nghiên cứu nói rằng trang chính không có thông tin liên hệ và email họ tìm được cũng bị trả lại
Biến môi trường bị lộ trong quá trình kiểm tra subdomain
- Nhà nghiên cứu cho biết họ thường tìm công ty trên Twitter rồi thử pentest nhanh, và hay dùng tab
Relevant People- Lần này lộ trình là công ty liên quan đến
crypto→ quỹ đầu tư mạo hiểm crypto →a16z crypto→a16z
- Lần này lộ trình là công ty liên quan đến
- Trong quá trình điều tra a16z, họ đã thực hiện quét subdomain thông thường và dùng công cụ lunchcat để kiểm tra domain cũng như phát hiện secret trong file JS
portfolio.a16z.comtrông giống như một công cụ quản lý portfolio dành cho các công ty thuộc a16z, và trong lúc kiểm tra đã phát hiện tham chiếu tới khóa AWS ở đâu đó trên website- Trong JS có các giá trị được chèn động, trông như toàn bộ
process.envcủa Heroku instance- Các mục được đưa vào gồm
MARKETPLACE_URL,DATABASE_URL,SALESFORCE_CLIENT_ID,SALESFORCE_CLIENT_SECRET,OKTA_CLIENT_SECRET,SESSION_SECRET,MAILGUN_API_KEY,AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,COOKIE_SECRET,HEROKU_POSTGRESQL_CRIMSON_URL... - Nhà nghiên cứu cho biết họ đã nhanh chóng kiểm tra các thông tin xác thực và chúng có vẻ là thông tin thật chứ không phải giả
- Họ nói mức độ truy cập chỉ là mở tab Sources trong công cụ dành cho nhà phát triển của trình duyệt
- Các mục được đưa vào gồm
Phạm vi có thể bị lộ và tranh cãi về bug bounty
- Các dịch vụ mà nhà nghiên cứu liệt kê là có thể bị xâm phạm gồm:
- Cơ sở dữ liệu: được nói là có chứa PII
- AWS: được đề cập là có thể truy cập qua các khóa bị lộ
- Salesforce: chưa được xác minh trực tiếp, và nhà nghiên cứu bổ sung rằng quyền của tài khoản có thể bị giới hạn
- Mailgun: được nói là có thể gửi email tùy ý từ domain a16z và đọc các email trước đó
- Ngoài ra cũng có thể còn nhiều dịch vụ khác
- a16z không trả bug bounty vì cho rằng nhà nghiên cứu đã không liên hệ riêng tư mà lại cố liên hệ công khai
- Nhà nghiên cứu đưa ra hai lý do cho việc liên hệ công khai
- Không tìm thấy thông tin liên hệ khả dụng trên trang chính của a16z
- Email gửi tới địa chỉ họ tìm được đã bị trả lại
- Bài liên quan là bài viết của TechCrunch, và nhà nghiên cứu cho biết Lorenzo đã liên hệ sau khi thấy tweet họ đăng để cố gắng liên lạc với a16z rồi viết bài
1 bình luận
Ý kiến trên Hacker News
Khi chúng tôi công bố dự án mã nguồn mở của mình (https://github.com/heyPuter/puter/), Eva đã thực hiện pentest khá rộng và xử lý việc báo cáo lỗ hổng rất chuyên nghiệp.
Khi đó thậm chí chưa có chương trình bug bounty, cô ấy cũng không đòi thù lao; Eva là một hacker xuất sắc và có trách nhiệm, nên a16z đáng lẽ phải đối xử tốt hơn.
Tôi từng mắc một lỗi tương tự.
Chúng tôi dùng một CMS Node.js tên apostrophecms, và dùng phần “global settings” trong bảng quản trị để quản lý khóa API của máy chủ xác thực; vài tháng sau mới biết các giá trị đó được xuất ra mã nguồn HTML.
Nó được thiết kế như vậy để JavaScript dùng được, và tài liệu cũng có nói, nên tôi không đổ lỗi cho họ; nhưng chúng tôi đã xem nhẹ.
Điều bực hơn là chúng tôi đã trả khá nhiều tiền cho một hãng tư vấn lớn để pentest mà họ cũng không phát hiện ra. Cuối cùng tự chúng tôi phát hiện, kiểm tra log thì có vẻ chưa có dấu hiệu bị khai thác, nhưng đó vẫn là một vụ lộ dữ liệu khá sốc.
Từ trước đến nay, chưa thấy bài pentest nào vượt quá mức điền checklist.
Như bạn nói, cách chia sẻ dữ liệu này đã được ghi trong tài liệu, nhưng vẫn có thể gây bất ngờ.
Bổ sung cho những ai sẽ tìm hiểu sau này: phiên bản chính hiện được hỗ trợ của Apostrophe không còn hoạt động theo cách này nữa.
Việc chèn dữ liệu vào frontend khi chưa đăng nhập giờ là điều nhà phát triển phải chủ động lựa chọn, chính là để tránh những bất ngờ như vậy.
Tuy nhiên vẫn có các trường hợp sử dụng cần đưa khóa API vào phần thiết lập và một số nội dung của một widget cụ thể.
Nhân tiện, tôi là trưởng bộ phận thiết kế của Apostrophe và cũng đảm nhiệm vai trò kỹ thuật.
Tình huống này xảy ra vì cấu hình đa tenant của chúng tôi và vì chúng tôi chưa hiểu rõ apostrophe.
Việc ghi tài liệu về một hành vi nguy hiểm không phải là miễn trừ trách nhiệm, và tôi nghĩ bài học này giờ lẽ ra đã phải được biết đến rộng rãi.
Khi dựng một dịch vụ mới và dùng ACME để gắn chứng chỉ LetsEncrypt cho máy chủ, log gần như lập tức bị lấp đầy bởi các request rác.
Có thể thấy rõ các bot đang tìm những giá trị mặc định yếu mà lập trình viên có thể đã để mở; tôi thậm chí từng thấy chúng request cả file môi trường của process.
Tôi không hiểu sao lỗ hổng kiểu này lại chưa bị phát hiện hoặc khai thác; có thể a16z đã cực kỳ may mắn, hoặc thực ra đã bị khai thác nhưng chưa được công khai.
Một nhà nghiên cứu thiện chí, hoặc một người rảnh rỗi có tư duy white-hat, đã liên hệ trước; thật tiếc là không có khung pháp lý cho kiểu bất cẩn này, nhưng tôi nghĩ a16z nên bị phạt nặng.
Có khi đã xảy ra rồi.
Có thể để nó mở như vậy còn có giá trị hơn là phá hỏng nó.
Nhưng một vài thông tin xác thực kiểu OKTA thì có vẻ khá nguy hiểm.
Phần nói “không trả bug bounty vì họ đã liên hệ công khai. Lý do họ làm vậy là trên trang chính không có thông tin liên hệ, còn engineering@a16z.com mà họ tìm được thì email bị trả lại” nghe như một mẹo sống khôn ngoan để công ty tiết kiệm tiền.
Nếu không để cách liên hệ riêng với đội kỹ thuật, mọi báo cáo bug bounty sẽ diễn ra công khai, và như thế khỏi phải trả gì.
Chắc họ cũng tiết kiệm được khối tiền khi thuê người làm dev giá bèo trên mấy chỗ như fiverr, và nếu một nhóm ransomware Nga dễ dàng cuỗm hết thì còn gián tiếp tiết kiệm được kha khá chi phí kế toán nữa.
Nếu không có chương trình bug bounty công khai thì họ không nợ gì cả.
Hơn nữa ở cuối trang https://a16z.com/connect có địa chỉ email liên hệ, chỉ là nhà nghiên cứu tiện thể bỏ sót.
Trông có vẻ họ nhắm đến độ nhận diện hơn là công bố có trách nhiệm.
Khi các công ty nói “bị hack”, giờ nghe giống như cách diễn đạt doanh nghiệp cho câu “chúng tôi không bảo vệ đúng cách các thông tin xác thực quan trọng, nhưng xin hãy quy trách nhiệm cho một thực thể vô danh mà chúng tôi gọi là ‘hacker’”.
Có những phân biệt pháp lý như “đột nhập nhà ở”, “trộm cắp”, “xâm nhập trái phép”, và việc cửa có mở hay không có thể ảnh hưởng đến tính bất hợp pháp hoặc mức phạt, nhưng trong cách nói thường ngày thì vẫn là bị trộm.
Không trả nổi dù chỉ một khoản bounty mang tính tượng trưng cho một lỗ hổng rộng đến vậy thì khá tệ.
Họ còn bận viết whitepaper kiến trúc AI tạo sinh khổng lồ.
Hãy để họ nghỉ chút đi, họ đang mơ về một thế giới agent tương lai nơi các chatbot làm dở dang vận hành mà.
Trong khi thế giới đang bốc cháy vì một bản cập nhật phần mềm lỗi.
Bản cập nhật phần mềm lỗi hôm thứ Sáu chỉ là cú chốt hạ điểm nhấn lên trên thôi.
Không ngạc nhiên chút nào.
Nếu thực sự có thể truy cập vào instance Salesforce thì với tư cách nhà sáng lập, tôi sẽ rất bất an.
Thông thường ở những nơi như Salesforce có lưu email, và trong đó có thể vẫn còn các kế hoạch gọi vốn hoặc kế hoạch M&A mà các nhà sáng lập công ty trong danh mục chưa chia sẻ ra bên ngoài.
Nhưng dùng khóa đó để truy cập vào hệ thống không được phép là phạm tội.
Khác biệt này rất lớn.
Việc quỹ VC này không trả bug bounty cho một lỗ hổng bảo mật lớn như vậy không tạo được niềm tin.
Ban quản trị HN đã đổi tiêu đề sang một cái đỡ xấu hổ hơn rồi.
Không ngạc nhiên.
Điểm không thay đổi nhưng nó bị chuyển từ đầu xuống cuối.
Đúng là có nhiều cách để phản hồi thật.