Tóm Tắt

Trong bài viết này, tôi sẽ chia sẻ về một lỗ hổng bảo mật thú vị mang tên "Đổi Mật Khẩu Không Cần Xác Thực Mật Khẩu Cũ". Lỗ hổng này cho phép kẻ tấn công chiếm đoạt tài khoản và khóa trái phép người dùng. Ban đầu, lỗ hổng này không được đánh giá cao, nhưng nhờ sự kiên trì của tôi, nó đã được công nhận và nhận thưởng bounty. Hãy cùng tôi khám phá hành trình đầy kịch tính này nhé!

Nội Dung Chi Tiết

1. Tự Đánh Giá Lỗ Hổng

Mức độ nghiêm trọng: Thấp đến Trung Bình

Tại một trong những cuộc săn lùng lỗ hổng gần đây, tôi phát hiện ra một lỗi bảo mật khá nghiêm trọng: "Password Change without Current Password Validation". Điều này có nghĩa là hệ thống cho phép người dùng thay đổi mật khẩu mà không cần nhập mật khẩu cũ. Nếu kẻ tấn công có được token phiên, họ có thể chiếm quyền truy cập tài khoản của người dùng một cách dễ dàng.

Khi kiểm tra mục chỉnh sửa thông tin người dùng, tôi thấy chức năng thay đổi mật khẩu và bắt đầu suy nghĩ rằng nếu mình không nhập mật khẩu cũ trong yêu cầu thì sao? Tôi đã thử nghiệm và phát hiện ra rằng lỗ hổng này là một ví dụ rõ ràng về "Missing Authentication for Critical Function", cho phép thay đổi mật khẩu mà không cần xác thực. Điều này là trái với nguyên tắc bảo mật và không đảm bảo sự toàn vẹn của hệ thống.

2. Nhận Diện và Báo Cáo Lỗ Hổng

Ban đầu, tôi chỉnh sửa một ký tự trong trường current_password và gửi yêu cầu. Thật bất ngờ, hệ thống vẫn trả về mã trạng thái 200. Tôi quyết định xóa hoàn toàn giá trị của current_password. Kết quả là hệ thống không hề yêu cầu trường này khi thay đổi mật khẩu! Điều này có nghĩa là bất cứ ai có token phiên đều có thể thay đổi mật khẩu mà không cần biết mật khẩu cũ.

Các Bước Khai Thác Lỗ Hổng:

Đăng nhập như một người dùng hợp lệ và chặn yêu cầu khi cố gắng thay đổi mật khẩu.
Chỉnh sửa yêu cầu để cập nhật mật khẩu mà không cung cấp current_password. Có thể thay thế current_password bằng một chuỗi trống.

Ví dụ yêu cầu:

Copy

PATCH /v3/users/me HTTP/2

Host: redacted.com

Authorization: Bearer token

Content-Type: application/json

Content-Length: 96

{ "current_password": "", "password": "Sup3rStr0ngP@ss", "password_confirmation": "Sup3rStr0ngP@ss" }

Khi quan sát phản hồi từ máy chủ, tôi nhận thấy rằng yêu cầu được xử lý thành công và mật khẩu đã được thay đổi mà không cần xác minh mật khẩu cũ.

Tác Động của Lỗ Hổng:

Chiếm Đoạt Tài Khoản: Kẻ tấn công có thể dễ dàng chiếm đoạt tài khoản người dùng mà không cần biết mật khẩu cũ.
Nguy Cơ Từ Chối Dịch Vụ: Người dùng hợp pháp có thể mất quyền truy cập vào tài khoản của họ nếu mật khẩu bị thay đổi mà không thông báo.
Rủi Ro Bảo Mật: Tài khoản dễ bị tấn công và có thể dẫn đến rò rỉ thông tin nhạy cảm.

3. Quan Điểm từ Từ Triager

Câu Chuyện Nhận Bounty Thú Vị

Khi tôi gửi báo cáo, phản hồi từ triager ban đầu không mấy khả quan. Họ cho rằng đây chỉ là một lỗi nhỏ và không có mức độ nghiêm trọng. Sau đây là những diễn biến “drama” giữa tôi và đội triage:

Ngày 25/10: Triager nghĩ rằng không phải là một lỗ hổng bảo mật nghiêm trọng vì kẻ tấn công cần có quyền truy cập vào token người dùng. Tuy nhiên, họ vẫn khuyến khích tôi thử nghiệm thêm để tăng mức độ nghiêm trọng.
Ngày 28/10: Sau vài vòng phản hồi, triager đánh giá báo cáo chỉ ở mức “Informative” do thiếu minh chứng. Nhưng họ đã mở lại báo cáo để xem xét liên kết với các lỗ hổng khác.
Ngày 29/10: Sau khi nhận được giải thích rõ ràng từ tôi về nguy cơ chiếm quyền tài khoản, triager đã chuyển báo cáo sang trạng thái “Triage” và gửi đến công ty chính để xem xét.
Ngày 3/11: Cuối cùng, công ty đã thông qua báo cáo với mức độ nghiêm trọng “Low” và chấp nhận chi trả bounty cho tôi. Họ chân thành cảm ơn sự đóng góp của tôi cho an ninh hệ thống.

Kết Quả

Báo cáo không chỉ được chấp nhận mà còn mang về cho tôi một phần thưởng. Đây là minh chứng cho việc kiên trì trong việc săn bug bounty. Thỉnh thoảng, bạn cần lấy lại lòng tin vào bản thân và bảo vệ những gì bạn tin là sai.

Kết Luận

Lỗi không yêu cầu xác thực mật khẩu cũ là một vấn đề phổ biến nhưng rất nghiêm trọng. Nếu không được giải quyết, nó có thể dẫn đến nhiều trường hợp chiếm đoạt tài khoản. Hy vọng thông tin này sẽ giúp ích cho các bạn trong việc tìm kiếm lỗ hổng và xử lý các tình huống tương tự. Hãy kiên nhẫn và bảo vệ quan điểm của bạn nếu bạn tin rằng đó là một lỗi thật sự!

Bonus: Dựa vào logic đó, nếu cần thay đổi địa chỉ email cũng cần xác thực mật khẩu. Tôi cũng thử nghiệm tương tự như trên và đã nhận được sự công nhận về lỗi! Quá tuyệt vời!

Cảm ơn các bạn đã theo dõi!
source: viblo

Lỗ Hổng Bảo Mật: Đổi Mật Khẩu Không Cần Xác Thực Mật Khẩu Cũ - Hành Trình Từ Phát Hiện Đến Bounty