Summary
Hello mọi người, lại là mình đây! Đợt vừa rồi, mình vừa có một hành trình "cày bug" đầy thú vị trên Intigriti. Không phải mình muốn khoe, nhưng lần này mình đã tìm được tận 5 lỗi Unrestrict File Upload ở các API khác nhau của cùng một hệ thống! Kết quả? Công ty không chỉ sửa lỗi mà còn cập nhật cả Out of Scope để bỏ qua các lỗi tương tự trong tương lai. Nghe thú vị đúng không? Cùng mình ngồi xuống, làm một ly cafe và khám phá hành trình này nhé!
Hành Trình Tìm Lỗi – Khi Một Lỗ Hổng Dẫn Đường
Vẫn là phương châm:
Biết mình biết ta, trăm trận trăm thắng
Mình đã ngồi tìm hiểu tất cả các chức năng của hệ thống, list ra các chức năng của nó. Việc hay nhất là mình có một cái Threat modeling đơn giản nhằm tối ưu thời gian tìm lỗi của mình. (Nếu mọi người thấy hay, có thể comment vào bài viết để mình chia sẻ nhé!)
Bắt tay vào tìm lỗ hổng thôi!
Nhìn vào threat modeling thì mình thấy được rằng nên bắt đầu từ đâu, đó là các lỗ hổng đơn giản trước: XSS, SQLi, Invalid input... Và lỗ hổng lần này khá thú vị. Về cơ bản, hệ thống đã không kiểm tra chặt chẽ loại file được upload, cho phép mình "vượt rào" và tải lên những file không được phép như script thực thi hoặc file độc hại.
Câu chuyện bắt đầu khi mình phát hiện ra một endpoint upload file. Nhưng mà có điều là ở FE thì việc kiểm tra rất tốt, nếu không hợp lệ sẽ bị loại, còn hợp lệ thì sẽ thực hiện 2 request lên hệ thống là:
- Tải lên thông tin của tệp như tên, id, địa chỉ upload. Kỳ lạ ở bước này đổi tên file thành gì cũng được vẫn ok !?!
- Ở bước 1 sẽ không tải lên kèm data, ở request 2 này thì mới tải lên file, và lúc này là lúc để chúng ta bypass (thay đổi nội dung file, content-type...)
Thấy cơ hội, mình thử nghiệm và thành công tải lên một file PHP đơn giản. File được chấp nhận và lưu lại trên hệ thống mà không gặp bất kỳ hạn chế nào. Một cảm giác "ngọt ngào" dâng trào khi mình nhận ra đây là một lỗi tiềm năng. Và rồi, mình quyết định mở rộng phạm vi:
- Kiểm tra các API upload khác.
- Áp dụng mẹo tương tự để thử tải file độc hại lên.
- Kết quả? Bùm! Thêm 4 lỗi tương tự ở các API khác nhau!
Triage: Khi Báo Cáo Nhiều Đến Mức Công Ty Phải Đổi Scope
Khi gửi báo cáo đầu tiên, mình nhận được phản hồi rất nhanh, còn chả thèm nhắn gì luôn:
Đầy tự hào, mình tiếp tục gửi báo cáo thứ hai, thứ ba, và rồi... đến báo cáo thứ năm. Mỗi lần gửi, mình đều nhận được phản hồi kiểu:
"Lại lỗi tương tự hả? Cảm ơn bạn vì đã giúp chúng tôi phát hiện vấn đề ở những endpoint khác."
Đến lúc này, mình bắt đầu cảm thấy như mình đang làm QA nội bộ cho công ty. Và quả thật, công ty không chỉ sửa lỗi mà còn quyết định thay đổi Out of Scope để chặn trước các lỗi tương tự trong tương lai.
)
Out of Scope: Khi Lỗi Của Bạn Trở Thành Cột Mốc
Với nhiều người, việc một lỗi bị đưa vào Out of Scope có thể là điều đáng buồn. Nhưng với mình, đây lại là một khoảnh khắc đáng tự hào. Tại sao ư? Vì điều đó chứng minh rằng những phát hiện của mình đã tạo ra thay đổi thực sự trong chính sách bảo mật của công ty.
Bài Học Rút Ra
- Kiểm tra mọi ngóc ngách: Đôi khi, một lỗi ở một endpoint có thể tồn tại ở nhiều endpoint khác. Hãy kiểm tra tất cả!
- Đừng ngại gửi nhiều báo cáo: Miễn là lỗi hợp lệ, bạn đang giúp công ty cải thiện bảo mật của họ.
- Chill dù được gì hay mất gì: Đôi khi, kết quả không phải chỉ là bounty, mà còn là cảm giác đã đóng góp thực sự vào việc tăng cường an ninh hệ thống.
- Nên có một kế hoạch: Việc định hình và hiểu hệ thống giúp tăng cơ hội nhìn thấy lỗ hổng
Lời Nhắn Nhủ Cuối
Nếu bạn cũng từng tìm thấy những lỗi tương tự như mình, đừng quên kiểm tra toàn diện các API liên quan. Đôi khi, một phát hiện nhỏ có thể dẫn đến hàng loạt lỗi khác và tạo nên một thay đổi lớn.
Hẹn gặp lại trong những hành trình bug bounty thú vị tiếp theo! Cheers! 😎
