Vậy là mình cũng đã dấn thân vào con đường tìm lỗ kiếm tiền rồi! Anh em trong giới giang hồ mạng ai cũng viết blog hết, nên mình cũng tập tành viết theo, chả biết có ai đọc không nữa ¯\(ツ)/¯. Bài này mình viết về những trải nghiệm đầu tiên của bản thân khi chân ướt chân ráo bước vào nghề.

Đầu tháng 11, trời Sài Gòn hôm nắng hôm mưa, mình được giao dự án pentest đầu tiên cho một khách hàng nước ngoài, mục tiêu của dự án này là tìm ra các lỗ hổng có trên ứng dụng web với tên miền target.com. Với một pentester gà mờ như mình thì có nhiều điều bỡ ngỡ lắm, kiểu như:

• Dự án chỉ được thực hiện trong vòng 1 tuần.
• Nghĩ về cả vài chục (hoặc có thể cả trăm) chức năng cần phải kiểm tra (ckầm kảm luôn >.<).

Nhưng có làm thì mới có ăn, nên cũng phải nhanh chóng lao vào làm thôi vì thời gian không cho phép mình nghĩ nhiều, và đây là những gì mình làm trong thời gian thực hiện dự án:

• Ngày thứ 1 - Mình đóng vai người dùng Internet thông thường dùng browser lướt website mục tiêu, hình thành cái nhìn tổng quan về các chức năng mà website cung cấp. Ứng dụng này là một CMS được thiết kế khá lạ, vì phần front-end và back-end chạy trên 2 cổng khác nhau, phần front-end chủ yếu chứa mã JavaScript gọi các API ở back-end.
• Ngày thứ 2 - Mình bật hacker mode lên để fuzz các params ở các chức năng, chủ yếu là để luyện tập cảm giác. Nhưng cũng chán, vì mình tiêu cả ngày mà không tìm được gì hấp dẫn.
• Ngày 3, 4, 5 - Mình quyết định không tìm lỗ hổng theo cảm xúc nữa mà chuyển sang dùng checklist của công ty, nhờ vậy mà công việc của mình trở nên có trình tự, có hệ thống hơn.

Việc chiếu vào checklist giúp mình tìm được một số lỗ hổng có mức độ nghiêm trọng HIGH trên ứng dụng target.com:

1. CSRF - Lỗ hổng này mình nhìn thấy đầu tiên do các chức năng quản trị của ứng dụng đều vắng bóng CSRF token. Hơi khó viết mã khai thác do ứng dụng dùng dữ liệu JSON, nhưng sau khi dùng google đại pháp thì mình cũng đã viết được. Mã khai thác được viết với mục đích lừa người dùng đặc quyền cao click vào link, payload sẽ giúp tạo ra một người dùng mới với username:password định trước và quyền admin.
2. Upload file không an toàn - Ứng dụng có chức năng upload ảnh, mình bắt đầu kiểm tra lỗi upload file không an toàn và phát hiện ứng dụng cho phép upload file với extension bất kỳ, content bất kỳ. Mình quyết định chuẩn bị một chiếc JSP webshell nho nhỏ để upload lên server, nhưng khi truy cập vào đường dẫn tới file thì browser lại hiện lên pop up hỏi lưu file hay không, ôi chỉ còn một bước chân nữa là đi tới RCE rồi mà! Có lẽ ứng dụng đã ngăn chặn việc các file bị thực thi, hoặc cũng có thể đội ngũ developers đã không đủ sai lầm khi cài đặt Content-Type đúng đắn. Mất đi cơ hội RCE qua webshell rồi, nhưng không sao, mình vẫn còn có thể làm vài thứ với lỗ hổng này, ví dụ như upload tệp HTML chứa mã JavaScript tấn công XSS hay upload reverse shell rồi tìm cách lừa admin ấn vào.
3. Host header attack qua JSON param - Ứng dụng có chức năng reset password qua email, người dùng cần nhập username và ấn nút “SEND EMAIL” để dùng chức năng này. Mình bắt lại request để điều tra thì thấy JSON param tên hostname=target.com, lập tức nghi ngờ bị dính Host header attack nên mình sửa hostname lại là domain của mình (ví dụ attacker.com) và chuyển tiếp request. May mắn, kiểm tra mail box thì nhận được một email với nội dung kiểu:

    Hello, username
    You have requested to reset your password.
    Please click the link below to set a new password: http://attacker.com?code=very-secret
   

   Như bạn biết đấy, trong trường hợp người dùng nhận được email kiểu này, khả năng rất cao là họ sẽ click vào link để cài mật khẩu mới do lo ngại bị mất tài khoản. Và cũng có thể bạn cũng biết rồi, nếu nạn nhân click vào link thì giá trị very-secret của tham số code sẽ được chuyển về domain của attacker, attacker có thể tái tạo lại URL để cài password mới, chiếm quyền tài khoản người dùng nạn nhân. Một anh trong team mình cũng tìm ra attacker vector khác với chức năng khác, đó là HTML injection vào username, tuy nhiên mình thấy tính hiệu quả không cao do cần phải xác thực thì mới có quyền thay đổi username ở trang cá nhân.

Ngoài những lỗ hổng với mức độ nghiêm trọng HIGH như trên, mình còn tìm được một số lỗ hổng LOW như:

1. Lộ thông tin server qua debug info
2. Session vẫn còn hiệu lực sau khi đăng xuất
3. Không có rate limit ở chức năng reset password
4. Liệt kê username/email qua chức năng reset password

Chắc mình cũng như bao người làm cái nghề này - cảm thấy vui khi tìm thấy một lỗ hổng nào đó, vui ít hay nhiều thì lại tùy thuộc vào mức độ nghiêm trọng của lỗ hổng. Mình vẫn chưa tìm thấy lỗ hổng nào có mức độ nghiêm trọng CRITICAL trong ứng dụng lần này, cũng không có gì đáng nói nữa đâu, nên mình dừng chém ở đây vậy. Cảm ơn vì bạn đã đọc.