Từ một tin nhắn chat Twitch đến chiếm quyền điều khiển máy tính của streamer

Một lỗ hổng XSS trong overlay chat Twitch, trình duyệt Chromium không có sandbox bên trong OBS, và một lỗi V8 đã bị khai thác ngoài thực tế — chỉ bấy nhiêu là đủ để nội dung do người xem kiểm soát trở thành thực thi mã trên máy streamer, trong khi OBS vẫn giữ nguyên cấu hình mặc định.

Câu chuyện này đáng chú ý không nằm ở bản thân lỗi XSS, mà ở chỗ nội dung web do kẻ tấn công kiểm soát đang được chạy ở đâu. Khi overlay chat render tin nhắn người xem dưới dạng HTML thô, toàn bộ trình duyệt nhúng trong OBS trở thành bề mặt tấn công, và không có sandbox nào chặn lại.

Khởi đầu từ một dòng code trong bức ảnh chụp màn hình

Mọi chuyện bắt đầu khi một người bạn đăng ảnh chụp màn hình overlay chat Twitch do anh ấy tự viết cho OBS. Với những ai chưa quen với hệ thống livestream, overlay chat thực chất chỉ là một trang web nhỏ mà OBS hiển thị đè lên luồng stream thông qua Browser Source. Trang này có thể kéo về tin nhắn chat trực tiếp, cảnh báo, donate, hoặc bất cứ thứ gì bạn muốn khán giả nhìn thấy trên màn hình.

Bức ảnh tình cờ lộ cả một đoạn code, và một dòng khiến tác giả chú ý ngay lập tức: tin nhắn chat được đưa thẳng vào trang dưới dạng HTML, không hề được làm sạch.

Đó là một lỗi XSS kinh điển. Người xem kiểm soát nội dung tin nhắn, overlay lại xử lý nó như HTML thay vì văn bản thuần, và nội dung do kẻ tấn công kiểm soát có thể thực thi ngay trong trang. Hướng khai thác này gợi nhớ đến một video cũ của Micode về tấn công OBS qua giao diện WebSocket: dùng XSS trong chat làm điểm xâm nhập, sau đó nói chuyện với máy chủ WebSocket cục bộ của OBS để chuyển scene hoặc dừng stream.

Bài đăng khởi đầu cho toàn bộ quá trình điều tra

Tuy nhiên, con đường đó ngày nay đã kém hấp dẫn hơn nhiều. Máy chủ WebSocket của OBS mặc định bị tắt, và khi được bật thì nó yêu cầu mật khẩu do chính OBS tự sinh ra. Mục tiêu của tác giả vì thế đặt cao hơn: một tin nhắn Twitch duy nhất, OBS phiên bản mới nhất, cấu hình nguyên bản, streamer không cần thao tác gì, và kết quả là thực thi mã trên chính máy tính đó.

OBS thực chất nhúng cả một trình duyệt Chromium

Browser Source của OBS vận hành nhờ Chromium thông qua CEF (Chromium Embedded Framework). Chúng được dùng cho hộp chat, cảnh báo, widget donate, hiệu ứng động và các overlay tùy chỉnh. Chính thành phần trình duyệt này cũng chạy các browser dock và phần tích hợp dịch vụ.

Nghĩa là cái khung chat nhỏ bé kia thực chất đang chạy bên trong một trình duyệt Chromium đầy đủ được nhúng vào OBS. Với lỗi XSS đã có sẵn, JavaScript do người xem kiểm soát giờ đây đang thực thi bên trong Chromium trên máy của streamer.

Chỉ riêng điều đó thì chưa phải là thực thi mã trên Windows. Trình duyệt có các ranh giới bảo mật được thiết kế đúng để ngăn nội dung web biến thành quyền điều khiển máy chủ. Nhưng trình duyệt của OBS lại đang thiếu đúng một ranh giới quan trọng như vậy.

Sandbox của Chromium đã bị vô hiệu hóa

Chrome thông thường cô lập các tiến trình renderer bằng sandbox. Kể cả khi kẻ tấn công khai thác được một lỗi hỏng bộ nhớ và đạt thực thi mã gốc trong renderer, chúng vẫn phải vượt qua sandbox trước khi chạm tới máy chủ.

OBS lại khởi tạo trình duyệt CEF nhúng của mình với dòng thiết lập sau:

settings.no_sandbox = true;

Thiết lập này xuất hiện trực tiếp trong mã nguồn obs-browser hiện hành. XSS vẫn chỉ cho JavaScript. Nhưng nếu đoạn JavaScript đó khai thác được V8 để trở thành thực thi mã gốc bên trong renderer, thì không còn sandbox Chromium nào để thoát ra nữa.

Vậy nên câu hỏi tiếp theo là OBS đang phát hành phiên bản Chromium nào. Và câu trả lời không được như mong đợi.

CVE-2024-7971 xuất hiện đúng lúc

Phiên bản OBS mới nhất tại thời điểm kiểm chứng dùng Chromium 127.0.6533.120 và V8 12.7.224.18. Điều này đáng chú ý bởi CVE-2024-7971, một lỗi type confusion trong V8, ảnh hưởng đến các phiên bản Chromium trước 128.0.6613.84. Google đã vá nó trong Chrome 128 vào ngày 21 tháng 8 năm 2024.

Đây không phải lỗi lý thuyết. Microsoft ghi nhận nó bị khai thác bởi nhóm tấn công Triều Tiên mà họ theo dõi với mật danh Citrine Sleet, và CISA đã đưa nó vào danh mục các lỗ hổng đã bị khai thác thực tế.

Trong cuộc tấn công mà Microsoft quan sát được, khai thác V8 cho phép thực thi mã bên trong renderer đã có sandbox của Chrome. Kẻ tấn công vẫn cần thêm một lỗ hổng nữa để thoát sandbox. Còn bên trong OBS, rào chắn đó vốn đã bị tắt từ đầu.

Sơ đồ chuỗi tấn công từ tin nhắn chat đến thực thi mã

Các mảnh ghép khớp với nhau: overlay chat có XSS → JavaScript thực thi trong CEF → khai thác lỗi V8 → thực thi mã gốc trong renderer → không còn sandbox để vượt qua → toàn quyền trên máy streamer.

Xây dựng chuỗi khai thác

Không có bản proof of concept công khai nào nhắm đúng bản CEF đang được kiểm chứng, nên tác giả tự viết một bản. Trong quá trình phát triển, ông bật tính năng gỡ lỗi từ xa của Chromium và dùng giao thức DevTools để kiểm tra renderer và gỡ lỗi khai thác.

Ở mức tổng quát, lỗi V8 cho trang web quyền truy cập bộ nhớ mà đáng lẽ nó không bao giờ được có. Từ đó, khai thác phát triển thành quyền truy cập bộ nhớ tiến trình rộng hơn, rồi cuối cùng là thực thi mã gốc. Phần nội dung chi tiết của khai thác được tác giả chủ động lược bỏ khỏi bài viết.

Kết quả cuối cùng thì dễ diễn giải hơn nhiều: người xem gửi một tin nhắn Twitch độc hại, overlay lỗ hổng biến nó thành thực thi JavaScript, khai thác V8 biến nó thành thực thi mã gốc, và kẻ tấn công có được mã tùy ý chạy trên máy của streamer.

"Cấu hình mặc định" ở đây nghĩa là gì

Điều này không có nghĩa là một bản cài OBS mới toanh sẽ bị bất kỳ ai trong chat Twitch tấn công từ xa. Điểm xâm nhập không cần click trong phần trình diễn chính là overlay lỗ hổng: streamer phải đang dùng một Browser Source render nội dung do người xem kiểm soát mà không làm sạch đúng cách.

Tuy nhiên, một khi trang đó đã được nạp, tác giả không hề làm yếu OBS để phần còn lại của chuỗi hoạt động. Không có thiết lập WebSocket nào, không có quyền quản trị, không có tùy chọn sandbox nào bị người dùng thay đổi, và streamer không phải click gì cả.

Overlay chat Twitch cũng chỉ là một cách để chạm tới trình duyệt. Nói rộng hơn, một trang do kẻ tấn công kiểm soát được nạp vào Browser Source hoặc browser dock của OBS hoàn toàn có thể bắt đầu ngay từ giai đoạn khai thác trình duyệt. Chính XSS trong chat là thứ khiến chuỗi này trở nên từ xa và không cần click dưới góc nhìn người xem.

Phần đáng quan tâm vì thế không phải bản thân lỗi XSS, mà là nơi nội dung web do kẻ tấn công kiểm soát đang được chạy.

Vì sao điều này quan trọng với người làm nội dung

Các thiết lập livestream đầy ắp nội dung web. Hộp chat, cảnh báo donate, thông báo người theo dõi và widget tùy chỉnh đều là những trang web, và phần lớn dữ liệu của chúng đến từ người lạ trên internet.

Nguyên tắc rất đơn giản:

• Nếu tin nhắn chat là văn bản, hãy render nó như văn bản.
• Nếu thực sự cần HTML, phải làm sạch đúng cách.
• Bất cứ thứ gì trong Browser Source đều nên được coi là đầu vào không đáng tin cậy.
• Không widget nào được phép render nội dung của người xem dưới dạng HTML.

Đây là thứ mà streamer hoặc tác giả overlay có thể sửa ngay hôm nay, trước khi các bản vá của OBS được phát hành.

OBS đang xử lý ra sao

Nhóm phát triển OBS xác nhận cả hai hướng khắc phục đều đã được triển khai.

Thứ nhất là nâng cấp trình duyệt nhúng. Rào cản chính trước đây là Chrome Runtime mới, vốn cho đến gần đây chưa hỗ trợ kiểu kết xuất ngoài màn hình mà OBS phụ thuộc vào. Chromium 127 đạt bản ổn định từ tháng 7 năm 2024, nghĩa là engine trong OBS 32.2.2 đã chậm khoảng hai năm. Một pull request chuyển obs-browser lên CEF 128+ đang được xem xét và nhắm tới cột mốc OBS Studio 33.0. Sau khi được hợp nhất, nó sẽ vá đúng lỗi V8 được dùng trong bài viết này.

Thứ hai là bật lại sandbox của CEF, cũng đang được thử nghiệm trong cùng đợt cập nhật. Trước đây nó bị tắt vì phá vỡ xác thực của một số tích hợp dịch vụ, nhưng nhóm phát triển cho rằng những vấn đề đó có thể đã được giải quyết. Nếu sandbox bật lại được, khai thác trình duyệt sẽ không còn đủ: kẻ tấn công còn phải cần thêm một lỗ hổng thứ hai để thoát khỏi sandbox.

Với một thành phần mà toàn bộ nhiệm vụ là render nội dung web có khả năng không đáng tin cậy, cả hai lớp bảo vệ đều quan trọng. Giữ engine trình duyệt bám sát các bản vá bảo mật hiện hành cũng quan trọng không kém việc có sandbox bao quanh nó.

Mốc thời gian công bố

• 14 tháng 2 năm 2026: Phối hợp với tác giả overlay.
• Tháng 7 năm 2026: Tái hiện toàn bộ chuỗi tấn công từ đầu đến cuối trên Windows 11.
• 19 tháng 8 năm 2026: Báo cáo cho OBS.
• 20 tháng 8 năm 2026: OBS xác nhận, quá trình cập nhật CEF đang tiến hành, không tách riêng CVE theo chính sách.
• 25 tháng 8 năm 2026: OBS xác nhận việc bật lại sandbox đang được thử nghiệm trong cùng đợt cập nhật.
• 10 tháng 9 năm 2026: Pull request 523 được hợp nhất trong obs-browser.
• 17 tháng 9 năm 2026: Pull request 13890 được hợp nhất trong obs-studio.
• 22 tháng 9 năm 2026: Công bố.

Bài học cho cộng đồng streamer Việt Nam

Với các streamer và nhà phát triển overlay tại Việt Nam, câu chuyện này là lời nhắc đáng cân nhắc. Rất nhiều overlay, widget donate và thông báo chat được chia sẻ miễn phí trong các cộng đồng, nhưng ít ai kiểm tra xem chúng xử lý tin nhắn người xem như thế nào.

Vài việc nên làm ngay:

• Rà soát lại mọi Browser Source đang dùng, đặc biệt là các overlay tải từ nguồn không rõ ràng.
• Ưu tiên overlay có mã nguồn công khai và được cập nhật thường xuyên.
• Cập nhật OBS lên phiên bản mới nhất khi bản vá CEF và sandbox được phát hành.
• Cân nhắc chạy OBS trong môi trường tách biệt nếu máy tính còn lưu dữ liệu quan trọng.

Điểm mấu chốt là một lỗi XSS tưởng như vô hại trong một widget nhỏ có thể leo thang thành quyền điều khiển toàn bộ máy tính, miễn là nó chạy trong một môi trường thiếu sandbox và dùng engine trình duyệt đã lỗi thời. Trong thế giới livestream, nơi nội dung từ người lạ liên tục đổ vào màn hình, khoảng cách giữa một tin nhắn chat và thực thi mã độc có thể ngắn hơn nhiều so với ta tưởng.