Lỗ hổng bảo mật XSS trên sinhvienit.net
Một ngày đẹp trời, tớ lên Google kiếm link tải Visual Studio. Như thường lệ, SVIT (sinhvienit.net) và VNZ (vn-zoom.com) luôn đứng top khi tìm kiếm mấy phần mềm… cr@ck. Khỏi phải suy nghĩ, tớ liền nhấn vào một link có thể tin tưởng (là trang nào thì các bạn cũng biết rồi đấy, liên quan tới bài viết mà).
Vào đọc lướt qua, kéo tới phần tải về. Chợt tớ để ý vào link đầu tiên mà chúng ta có thể nhận ra ngay là một trình chuyển hướng (redirector):
Vốn là tay thích săn lỗ hổng, tớ nghĩ thoáng qua trong đầu… “Không biết lão Lai dùng meta refresh, java_script hay PHP header để chuyển hướng nhỉ?”. Nghĩ vậy, tớ liền nhanh tay copy link và thêm “view-source:” vào đầu.
Như vậy là sử dụng JavaScript, phần dữ liệu trên URL được in lại khá nhiều trong trang. Thử kiểm tra XSS xem nào!
Tất cả vị trí đều bị mã hóa ký tự HTML. Thử lại với nháy đơn thôi xem!
Hừm, có vẻ ổn. Một hi vọng lóe lên trong đầu! Tại vị trí này, chúng ta không cần sử dụng thẻ HTML nào vì chúng ta đang ở ngay giữa (pháo đã lên nòng, chỉ việc châm lửa). Bypass thôi nào!
- Kết thúc việc gán giá trị vào biến redirUrl: ‘;
- Bắt đầu exploit payload của chúng ta: alert(‘Juno_okyo’)
- Vô hiệu hóa các ký tự thừa bằng chú thích: //
Kết hợp lại tớ được vector XSS như sau: ‘;alert(‘Juno_okyo’)//
Và kết quả là:
Từ XSS thành CSRF
Vì lỗ hổng XSS này nằm trên trình chuyển hướng liên kết ra ngoài SVIT nhưng link chuyển hướng lại cùng hostname với diễn đàn, tức là khả năng chiếm phiên làm việc hoàn toàn khả thi. Hơn nữa, Security Token của vBB không thay đổi (token không tự tái tạo lại sau mỗi truy vấn mà giữ nguyên trong suốt một phiên làm việc), tớ nghĩ ngay tới khả năng có thể chiếm token để thực hiện mọi thao tác dưới danh nghĩa người dùng bất kỳ => CSRF.
Xây dựng kịch bản tấn công
- Tạo một URL chuyển hướng sử dụng DOM để chèn một file JS chứa mã khai thác.
- Tạo một trang HTML sử dụng Iframe trỏ tới URL ở bước 1.
- Trong file JS ở bước 1, tạo truy vấn tới SVIT để chiếm Security Token và sử dụng token để đăng xuất tài khoản của thành viên đã vô tình truy cập vào trang web ở bước 2.
Nếu bước 3 thành công, chúng ta xác nhận rằng lỗ hổng CSRF tồn tại!
Proof of Concept
Video này tớ sẽ demo lại toàn bộ kịch bản tấn công ở trên. Và với việc tớ quay lại demo thì hẳn các bạn đã đoán ra kết quả của kịch bản này như thế nào rồi đó!
Nguồn: Techtalk.vn
