- Một cậu bé 15 tuổi thích săn lỗi trong thời gian rảnh đã phát hiện một lỗi liên quan đến xác thực email trong Zendesk, dịch vụ được các công ty thuộc Fortune 500 sử dụng
- Cậu đã báo cáo lỗi này cho nhiều công ty và kiếm được hơn 50.000 USD, nhưng bài viết giới thiệu quá trình Zendesk đã vá lỗi mà hoàn toàn không trả tiền thưởng cho người báo cáo
Giới thiệu về Zendesk
- Zendesk là công cụ dịch vụ khách hàng được các doanh nghiệp hàng đầu thế giới sử dụng
- Khi kết nối email hỗ trợ với Zendesk, Zendesk sẽ quản lý email đến và tạo ticket
- Điều đáng ngạc nhiên là nhiều tập đoàn lớn lại phụ thuộc vào Zendesk thay vì tự xây dựng hệ thống ticket riêng
Mắt xích yếu nhất
- Đúng như câu nói “chỉ mạnh bằng mắt xích yếu nhất”, Zendesk thường bị xem như một công cụ ticket đơn giản nên được dùng mà không cấu hình cẩn thận
- Nếu dùng tên miền
@company.com cho đăng nhập một lần (SSO) và liên kết với Zendesk, có thể phát sinh lỗ hổng bảo mật
- Vì Zendesk xử lý email của tên miền đó, nếu hệ thống SSO không xác thực đúng địa chỉ email thì bất kỳ ai truy cập được Zendesk cũng có thể lạm dụng hệ thống nội bộ.
Giả mạo email
- Tác giả đã phát hiện một lỗ hổng nghiêm trọng trong Zendesk, cho phép kẻ tấn công đọc ticket hỗ trợ khách hàng của các công ty dùng Zendesk
- Zendesk không có cơ chế bảo vệ hiệu quả trước giả mạo email
- Nếu biết địa chỉ email hỗ trợ và ID ticket, kẻ tấn công có thể dùng giả mạo email để mạo danh người gửi ban đầu và truy cập ticket
- Tác giả đã báo lỗi nhưng ban đầu Zendesk không quan tâm
- Họ trả lời rằng giả mạo email (các vấn đề SPF, DKIM, DMARC) nằm ngoài phạm vi xử lý
- Báo cáo được xử lý qua dịch vụ HackerOne, và yêu cầu báo trực tiếp cho thành viên nhóm Zendesk đã bị từ chối
Mở rộng sự cố này thành chiếm quyền Slack
- Tác giả có thể báo lỗi giả mạo email cho từng công ty riêng lẻ, nhưng muốn tạo tác động lớn hơn
- Trước đây đã có một nhà nghiên cứu khác xâm nhập Slack của hàng trăm công ty thông qua Zendesk (TICKETTRICK)
- Tác giả cố tái hiện điều này bằng lỗi của mình nhưng gặp một vài khó khăn
- Slack đã thay đổi sang cách xác minh bằng cách thêm token ngẫu nhiên vào địa chỉ email
- Tuy nhiên, khi đăng nhập bằng Apple ID thông qua OAuth thì token này không được dùng, nên có thể vượt qua
Các bước tái hiện: Apple → Zendesk → Slack
- Tạo Apple ID bằng
support@company.com và yêu cầu mã xác thực, khi đó một ticket Zendesk sẽ được tạo
- Trên cổng hỗ trợ của
company.com, tạo ticket bằng email của chính mình để theo dõi phạm vi ID
- Dùng lỗi giả mạo email để thử thêm bản thân vào tất cả ticket trong phạm vi ID đó
- Đăng nhập vào cổng hỗ trợ của công ty bằng tài khoản
daniel@wearehackerone.com và kiểm tra các ticket đã được CC
- Nhập mã xác thực vào Apple ID
- Dùng tính năng “Đăng nhập bằng Apple” của Slack để đăng nhập bằng Apple ID có email
@company.com và đăng nhập vào Slack
Tác giả đã áp dụng 6 bước này cho hàng trăm instance Zendesk và Slack
Hệ quả của vụ việc
- Trong suốt một tuần, tác giả báo lỗ hổng cho từng công ty; một số xử lý ngay, nhưng cũng có nơi nói rằng đây là vấn đề của Zendesk
- Khi một vài công ty liên hệ Zendesk, Zendesk cuối cùng đã yêu cầu giữ kín báo cáo và đòi các bước tái hiện lỗ hổng chiếm quyền Slack
- Sau khi nhận PoC chiếm quyền Slack, Zendesk xác nhận vấn đề nhưng mất 2 tháng mới khắc phục xong
- Nhiều công ty đã vô hiệu hóa tính năng cộng tác qua email để bảo vệ instance của mình
- Thông qua báo cáo bug bounty này, tác giả đã nhận hơn 50.000 USD tiền thưởng từ các công ty riêng lẻ trên HackerOne và các nền tảng khác
- Một số công ty đã chấm dứt hợp đồng với Zendesk
Bản vá của Zendesk và khoản bounty 0 USD của tôi
- Sau 2 tháng, Zendesk xác nhận đã giải quyết vấn đề
- Họ dùng bộ lọc thư rác Cloudmark và Rspamd EAP, nhưng do không tận dụng điểm số Rspamd nên nhiều email đã không bị giữ lại
- Ban đầu, họ sửa bằng cách tự động chuyển sang Rspamd trong một số điều kiện nhất định
- Sau đó, họ triển khai bộ lọc tự động giữ lại email xác thực từ Apple và Google
- Dù đã khắc phục xong, Zendesk cuối cùng vẫn quyết định không trả thưởng cho báo cáo bug bounty này
- Vì tác giả đã chia sẻ lỗ hổng với các công ty bị ảnh hưởng, vi phạm hướng dẫn công khai của HackerOne
Kết luận
- Một lỗi email nhỏ có thể dẫn tới việc xâm nhập hệ thống nội bộ của những công ty lớn nhất thế giới
- Zendesk cuối cùng đã sửa lỗ hổng, nhưng quá trình từ chối, phản hồi chậm và phớt lờ khiến mọi thứ rất khó khăn
- Đó là thực tế của việc săn lỗi: có lúc thắng, có lúc thua
Ý kiến của GN⁺
- Vụ Zendesk cho thấy rủi ro của việc đưa giải pháp bên thứ ba vào sử dụng một cách thiếu phản biện. Dù là sản phẩm của công ty nổi tiếng đến đâu, việc rà soát bảo mật vẫn là bắt buộc.
- Việc chiếm quyền hệ thống nội bộ ở các doanh nghiệp lớn có thể gây thiệt hại khổng lồ, nên phản ứng chậm chạp của Zendesk là vô cùng thiếu trách nhiệm. Việc từ chối trả bounty cũng không tốt cho động lực của các nhà nghiên cứu bảo mật.
- Doanh nghiệp cần chọn miền SSO cẩn trọng và tăng cường quy trình xác thực email. Cần tích cực áp dụng các công nghệ xác thực email như DMARC, SPF, DKIM.
- Hướng dẫn công khai của HackerOne từ góc nhìn của nhà nghiên cứu là quá cứng nhắc. Với các lỗ hổng nghiêm trọng, việc chia sẻ nhanh chóng là cần thiết, nên có lẽ cần áp dụng linh hoạt hơn tùy tình huống.
- Săn lỗi nên là mối quan hệ đôi bên cùng có lợi cho cả doanh nghiệp lẫn nhà nghiên cứu. Hy vọng sẽ hình thành một văn hóa tôn trọng thiện chí, công sức và có đền đáp xứng đáng cho nhà nghiên cứu.
2 bình luận
Nhìn những vụ như thế này, có vẻ các giải pháp liên quan đến bảo mật thà đưa chuyên gia bảo mật về rồi đào tạo, bồi dưỡng còn tốt hơn nhiều so với chỉ mang sản phẩm về dùng TT
Ý kiến trên Hacker News
Một người dùng cho biết đã báo cáo cùng một lỗi cho Zendesk, Apple và Slack vào tháng 6 năm 2024, và lý do họ không trả thưởng cho lỗi này có lẽ là vì người đó không phải người đầu tiên phát hiện
Một người dùng khác cho rằng Zendesk đã tạo ra một ban nhạc giả tên là "Zendesk Alternative" để làm ô nhiễm kết quả tìm kiếm trên Google
Một người dùng nói rằng việc Zendesk từ chối trả thưởng cho lỗi này là điều đáng thất vọng, và đó là cách khiến mọi người không muốn tham gia các chương trình thưởng lỗi quy mô lớn
Một người dùng khác nhận xét rằng các chương trình bug bounty kém hiệu quả gây tác động tiêu cực đến các dịch vụ phần mềm
Một người dùng chỉ trích việc Zendesk không trả thưởng dù là công ty có doanh thu 1,3 tỷ USD là một cách nhìn ngắn hạn
Một người dùng khác giải thích rằng có lẽ Zendesk đã phớt lờ vấn đề vì họ không hiểu đúng mức độ ảnh hưởng của lỗi
Một người dùng chỉ ra rằng Zendesk chỉ sửa vấn đề email xác minh tài khoản Apple, còn vấn đề cốt lõi thì chưa được giải quyết
Có hai lỗ hổng riêng biệt được nêu ra
Có ý kiến chỉ trích việc Zendesk phớt lờ vấn đề và cố giữ kín nó
Cuối cùng, một người dùng chỉ trích việc Zendesk từ chối trả thưởng cho lỗi, đồng thời nhấn mạnh rằng người báo cáo đã thực hiện đúng mọi quy trình