Lỗ hổng bảo mật Cross-Site-Scripting (XSS) có gì nguy hiểm?

Hacker typing on a laptop

Mỗi khi đăng những bài writeup về một lỗ hổng XSS được phát hiện trên một trang web nào đó, tôi biết sẽ có những người nhếch mép cười khẩy vì lúc đó trong đầu họ sẽ nghĩ:

• “Cái lỗi XSS này thì có cái quái gì nguy hiểm cơ chứ?”
• “Ngoài việc hiện lên một hộp thoại thì XSS làm được cái đếch gì nữa không?”
• “Một lỗ hổng vớ vẩn thôi mà. Ơ mà hiện hộp thoại cũng được gọi là lỗ hổng hả?”
• …

Vậy thì, XSS có gì nguy hiểm?

Thay vì viết ra đống lý thuyết nhàm chán, chúng ta sẽ cùng xem xét những hình thức tấn công khai thác XSS đã được áp dụng trong thực tiễn. Nói trước để những bạn nào còn chưa biết về XSS thì nên Google xem nó là gì trước khi đọc tiếp bài viết này nha.

XSS worm

XSS worm là một dạng sâu/mã độc trên nền web và hiển nhiên là viết bằng JavaScript với mục tiêu lây nhiễm tới toàn bộ người dùng truy cập vào trang web. Ví dụ điển hình thường gặp nhất là trên mạng xã hội Facebook.

Với số lượng người dùng quá lớn của mình, XSS worm có tốc độ phát tán chóng mặt trên Facebook mà chúng ta thường thấy theo hình thức: A bị nhiễm > gửi tin nhắn chứa mã độc cho B, C, D,… (nằm trong danh sách bạn bè của A). B, C, D và những người bạn đó cũng tiếp tục gửi tin nhắn cho toàn bộ bạn bè của chính họ. Và thế là con worm được lây lan theo cấp số nhân không thể kiểm soát.

* Để có thể gửi được tin nhắn, XSS worm sẽ kết hợp với CSRF.

Thông tin thêm: Trên Facebook còn một hình thức phổ biến khác được gọi là Self-XSS(loại này kết hợp với kỹ năng Social engineering). Facebook luôn cảnh báo mỗi khi bạn nhấn F12 (mở Console) chính là để bảo vệ bạn khỏi biến thể XSS này.

Browser-based Botnet

Năm 2014, hãng bảo mật Incapsula (đối thủ của CloudFlare) đã có bài viết về vụ việc một trong những trang web lớn nhất thế giới (Top 50 Alexa) bị hack, khiến toàn bộ người truy cập trở thành zombie cho một cuộc tấn công DDoS. Và các bạn đoán được điều gì đã biến người dùng trở thành zombie không? Vâng, chính là XSS. Cụ thể trong trường hợp này là một lỗ hổng Persistent XSS.

Dựa theo bài viết, thì lỗ hổng nằm trong phần thay đổi ảnh hồ sơ (avatar/profile picture). Kẻ tấn công đã chèn đoạn mã độc JavaScript vào thẻ <img> sử dụng sự kiện onload, mỗi khi ảnh được tải thì đồng nghĩa với việc đoạn JS kia sẽ được thực thi.

Vì là trang web nằm top nên lưu lượng người truy cập lớn đã bị lợi dụng để thực thi đoạn JS sử dụng truy vấn Ajax trỏ vào trang web bất kỳ. Và thế là trang web đó trở thành nạn nhân bị DDoS.

* Thông tin thêm: Cách đây 3, 4 năm tôi có phát hiện ra một lỗ hổng SQL Injectiontrong một diễn đàn lớn (hiện tại nằm trong Top 500 Alexa VN) sử dụng vBB. Sau khi liên hệ báo lỗi với Ban Quản Trị nhưng lại bị chửi vì họ một mực khẳng định tôi “có âm mưu phá hoại diễn đàn” của họ, lúc ấy tôi giận lắm.

Với lỗ hổng SQLi trong tay, tôi khai thác được Password (hash) và Salt của toàn bộ tài khoản Admin sau đó crack ra được mật khẩu (plain text) của một tài khoản. Truy cập vào AdminCP trong phần tạo thông báo, tôi chèn một đoạn JavaScript tạo truy vấn trỏ thằng về Blog của tôi. Nói thẳng là tự DDoS đi cho dễ hiểu, vì tôi biết chắc Blog của tôi không thể sập được (Google bảo kê mà, hehe). Kết quả là số người truy cập diễn đàn kia trở thành lượng traffic lớn dội thẳng vào Blog của tôi, rank Alexa tăng vọt.

XSS > CSRF > Upload Web-Shell

Đây là kịch bản mà tôi quen thuộc nhất vì đã áp dụng nó rất nhiều, từ hồi vBB (vBulletin) còn phổ biến. Ngoài ra thì kịch bản này thường dễ áp dụng với WordPress do cấu trúc quản lý plugin của nền tảng này. Chi tiết về cách thức tấn công:

1. Tìm một lỗ hổng XSS.
2. Thử chiếm Security Token của người dùng dựa theo lỗ hổng XSS tìm thấy.
3. Sử dụng Security Token để tạo plugin (hoặc thay đổi code của plugin có sẵn), từ đó có được Form Upload.
4. Sử dụng Form Upload ở bước 3 để tải lên Web-Shell. Bạn đã toàn quyền quản lý trang web đó thông qua Web-Shell. Lúc này có thể bắt đầu cài cắm back-door hoặc tải toàn bộ Cơ sở dữ liệu của trang web về.

* Bạn có thể tạo ra web-shell ngay từ bước 3 nhưng thường thì code của một con shell rất lớn, có thể ảnh hưởng tới tốc độ truy vấn khi khai thác. Do đó tôi thường tạo ra một Form Upload trước.

Ảnh demo trong vBB:

Video demo quá trình khai thác lỗ hổng DOM-based XSS trong Yoast SEO (a.k.a WordPress SEO) – một trong những plugin được sử dụng nhiều nhất theo thống kê từ WordPress.

Tổng kết

Trong bài viết này, tôi đã đưa ra 3 kịch bản nguy hiểm nhất khi khai thác lỗ hổng bảo mật XSS theo đánh giá của cá nhân tôi. Ngoài ra sẽ còn rất nhiều kịch bản khác dựa theo sức sáng tạo và kỹ năng của một Hacker. Bạn còn biết kịch bạn nào thú vị hơn? Hãy để lại dưới phần bình luận nhé!