Summary

Có bao giờ bạn tìm được một lỗ hổng, cảm thấy như vừa đào trúng mỏ vàng, nhưng cuối cùng lại phải ôm về... một bản duplicate? Đó chính xác là chuyện vừa xảy ra với mình, và để thêm phần thú vị, mình quyết định chia sẻ câu chuyện này với phong cách “chill” nhất có thể. Ngồi xuống, làm ly trà, và cùng mình nhìn lại hành trình báo cáo lỗi lần này nhé!

Lỗi Của Lỗi: "Broken Authentication"

Lỗ hổng lần này xảy ra ở một endpoint của trang sub.redact.com. Được trang bị Basic Authentication, nhưng hệ thống này lại quên... làm nó đúng cách! Điều này cho phép kẻ tấn công đăng nhập như bất kỳ người dùng nào chỉ với một đoạn header cơ bản. Không cần biết mật khẩu, không cần đoán tên tài khoản, cứ như đang bật cửa tự động "Welcome Hacker" vậy.

Ví dụ đoạn header “thần thánh” cho phép truy cập bất kỳ tài khoản nào:

Authorization: Basic dGVzdDp0ZXN0

Với thứ này, mình đã có thể làm mọi trò:

• Xem thông tin tài khoản người khác
• Thay đổi email đăng ký (tạm biệt chủ tài khoản, tôi làm chủ rồi!)
• Lưu và chỉnh sửa thông tin người dùng như tên, số điện thoại, thậm chí cả... sở thích ăn uống.

Hành Trình Phát Hiện Lỗi: Tưởng Là "Gold", Hóa Ra Là... "Duplicate"

Khám Phá

Trong lúc ngồi test, mình vô tình phát hiện Basic Authentication. Ban đầu, mình thử IDOR xem có được không? Ô được luôn này!!!

Nhưng khoan đã, mình lại thử với việc chỉnh sửa thông tin người dùng xem liệu có nâng được impact lỗi lên cao hơn không?

Ô lại được luôn này!!!

Trong đầu nghĩ, quả này ăn cũng nhiều phết!

Lúc này, trong đầu mới tự hỏi 1 câu hỏi, ủa nhưng tại sao lại làm được như vậy nhỉ? Thế là mình truy log từ burp ra từng dòng một, từ lúc đăng nhập đến khi xem thông tin người dùng khác, đến lúc đổi thông tin người dùng. Và mình phát hiện ra một vấn đề!

Việc quản lý trên hệ thống này có vẻ lỏng lẻo. Thử xoá từng header mang lại thông tin xác thực người dùng cơ bản như: cookie, auth bearer token... Và bùm, khi xoá đến header Authorization tất cả mở ra như cửa thiên đường. Tưởng tượng xem bạn cảm thấy thế nào khi phát hiện ra một lỗi high severity? Đúng rồi, mình đã nhảy cẫng lên! Và chính xác, lỗ hổng qua việc hệ thống tự chèn thêm header Authorization với một basic authen có sẵn quyền admin!!!

Báo Cáo Lỗi

Với đầy hào hứng, mình viết báo cáo chi tiết, kèm theo từng bước khai thác lỗi và các trường hợp sử dụng (POC) đẹp như mơ. Endpoint bị lỗi? Check. Mô tả tác động? Check. Giải pháp khắc phục? Check nốt!!!

Giá cho cái bug dự kiến là 1000€, nghĩ bụng, Tết này cũng có thể mang tiền về cho mẹ được rồi!

Chờ Kết Quả

Ngồi nhìn màn hình, refresh từng giây, mong nhận được câu "Accepted". Nhưng đời không như là mơ...

Cái Kết Đắng

Triager phản hồi:

Thank you for your submission. Unfortunately, your report is a duplicate because this has been reported before by other researchers (XXX). Bummer, we know. Better luck with your next submission!

Trời đất quay cuồng. Sao lại thế được? Mình vừa đào được mỏ vàng cơ mà! Nhưng bạn biết không, đôi khi “trái tim bị tổn thương, nhưng tâm hồn vẫn phải chill.”

Nhìn Lại Với Nụ Cười

Dù kết quả không như ý, nhưng hành trình này vẫn mang lại cho mình vài bài học lớn:

• Thế giới bug bounty là vậy: Không phải lúc nào bạn cũng là người đầu tiên. Nhưng hãy luôn cố gắng làm rõ ràng, chi tiết, và biết đâu lần sau bạn sẽ may mắn hơn. (đúng rồi, viết report kỹ vào, biết đâu công ty đọc report chuẩn chỉ, hào phóng lại thêm bonus, bữa mình vừa được xong :v)
• Chill để vui hơn: Dù sao thì việc tìm ra lỗ hổng cũng đã là một chiến thắng nhỏ. Đừng quá áp lực với việc nhận được bounty hay không.

Lời Nhắn Nhủ Cuối

Nếu bạn từng ở trong tình cảnh tương tự, hãy nhớ rằng mỗi lần "duplicate" là một lần luyện tập, và nó khiến bạn trở nên tốt hơn cho những lần tới. Dẫu biết buồn, nhưng hãy cứ cười lên, vì lỗi đã được tìm thấy, và ai biết được lần tới bạn sẽ là người đầu tiên?

Hẹn gặp lại ở những bài viết "chill guy" tiếp theo! Cheers, Một "duplicate" hunter vui tính! 😎