Cách tôi đã hack TẤT CẢ các màn hình trong học khu trung học của tôi để phát Rick Astley

Thông báo: Bài viết này chỉ dành cho mục đích giáo dục. Không thực hiện các hoạt động tương tự mà không có sự cho phép rõ ràng.

Vào ngày 30 tháng 4 năm 2021, tôi đã rickroll học khu trung học của mình. Không chỉ trường của tôi mà còn toàn bộ Học khu Trung học Township 214. Đây là học khu trung học lớn thứ hai tại Illinois, bao gồm 6 trường khác nhau với hơn 11.000 học sinh đăng ký.

Câu chuyện này không phải là một trong những trò rickroll điển hình khi học sinh lén đưa Rick Astley vào các bài thuyết trình, buổi biểu diễn tài năng hoặc cuộc gọi Zoom. Tôi làm điều đó bằng cách chiếm đoạt mọi màn hình mạng trong mọi trường để phát sóng “Never Gonna Give You Up” đồng bộ hoàn hảo. Cho dù đó là một TV trong hành lang, một máy chiếu trong lớp học, hoặc một màn hình lớn hiển thị menu ăn trưa, miễn là nó được kết nối mạng, tôi đã hack được!

Trong bài viết này, tôi sẽ giải thích cách tôi đã làm điều đó và cách tôi tránh bị phát hiện, cũng như hậu quả khi tôi tiết lộ bản thân và không gặp rắc rối.

The Big Rick

Trước khi chúng ta bắt đầu, đây là một số hình ảnh về toàn bộ sự kiện:

Chúng tôi đã chuẩn bị tài liệu hoàn chỉnh về mọi thứ chúng tôi đã làm, bao gồm các đề xuất để khắc phục các lỗ hổng chúng tôi phát hiện. Chúng tôi đã viết một báo cáo kiểm thử xâm nhập 26 trang đầy đủ cho nhóm kỹ thuật D214 và làm việc cùng họ để giúp bảo mật mạng của họ.

Với những gì đã được nói, những gì chúng tôi làm là rất vi phạm pháp luật và các cơ quan quản lý khác có thể đã khiếu nại. Chúng tôi rất biết ơn vì ban quản lý D214 đã hiểu cho chúng tôi.

Tiếp cận ban đầu

Câu chuyện bắt đầu từ năm đầu tiên của tôi khi tôi chưa có nhiều kỹ thuật — một thời kỳ mà tôi chỉ có thể miêu tả là sự bắt đầu của giai đoạn script kiddie của tôi. Tôi không hiểu về đạo đức cơ bản hoặc việc tiết lộ có trách nhiệm và nhảy vào mọi cơ hội để phá vỡ điều gì đó.

Vì vậy, rõ ràng, tôi trở nên tò mò về công nghệ tại trường trung học của mình. Và khi nói về "tò mò," tôi có nghĩa là quét cổng toàn bộ dải địa chỉ IP của mạng nội bộ học khu.

Tôi có vài người bạn giúp đỡ cho dự án này — và ôi, chúng tôi đã quét! Việc quét của chúng tôi tạo ra nhiều lưu lượng truy cập đến nỗi giám đốc công nghệ của trường chúng tôi đã phát hiện ra và đến một lúc nào đó để yêu cầu chúng tôi dừng lại. Tất nhiên, chúng tôi đã làm điều đó ngay lập tức, nhưng vào thời điểm đó, chúng tôi đã hoàn thành việc quét nửa đầu tiên của không gian địa chỉ 10.0.0.0/8 của học khu — tổng cộng là 8.388.606 địa chỉ IP.

Từ kết quả, chúng tôi đã tìm thấy các thiết bị khác nhau đang tiếp xúc trên mạng của học khu. Điều này bao gồm máy in, điện thoại IP... và thậm chí cả camera an ninh không có bất kỳ xác thực mật khẩu nào.

Đây là nơi tôi nhắc lại thông báo từ từ: không bao giờ truy cập vào các hệ thống khác một cách trái phép mà không có sự cho phép.

Hệ thống IPTV Exterity

Trước khi tiếp tục, tôi sẽ giải thích ngắn gọn về hệ thống IPTV. Hệ thống bao gồm ba sản phẩm:

• AvediaPlayer (thiết bị nhận)
• AvediaStream (thiết bị mã hóa)
• AvediaServer (quản lý)

AvediaPlayer là những hộp màu xanh nhỏ kết nối với máy chiếu và TV. Chúng có thể gửi các lệnh tuần tự đến thiết bị tương ứng để bật/tắt hiển thị, thay đổi nguồn vào/âm lượng, chuyển kênh, v.v. Các thiết bị nhận này bao gồm cả giao diện web và máy chủ SSH để thực thi các lệnh tuần tự. Ngoài ra, chúng chạy trên hệ điều hành Linux nhúng với công cụ BusyBox và sử dụng một kiến trúc CPU lạ mà được thiết kế cho các thiết bị IoT gọi là ARC (Argonaut RISC Core).

Tiếp theo, bộ mã hóa AvediaStream kết nối với các thiết bị phát trực tiếp video. Chúng mã hóa luồng trực tiếp đến các thiết bị nhận AvediaPlayer, hiển thị luồng. Bộ mã hóa được gắn vào các máy tính cần phát sóng, như vòng tròn văn bản hoặc thông báo sáng. Chúng cũng có phần mềm nhúng tương tự như các thiết bị nhận AvediaPlayer.

Cuối cùng, AvediaServer cho phép quản trị viên kiểm soát tất cả các thiết bị nhận và mã hóa cùng một lúc. Chúng có bộ xử lý x86_64 điển hình và chạy hệ điều hành Linux doanh nghiệp, CentOS. Giống như các thiết bị nhận và mã hóa, chúng cũng có giao diện web và máy chủ SSH.

Kể từ năm đầu tiên, tôi đã có quyền truy cập hoàn toàn vào hệ thống IPTV. Tôi chỉ phá hoại nó vài lần và có kế hoạch cho trò nghịch ngợm năm cuối, nhưng nó dần được lãng quên.

Chuẩn bị

Chuyển đến học kỳ hai của năm cuối, đầu năm 2021: tất cả các trường đều thực hiện học hệ lai vì đại dịch COVID-19. Đến thời điểm này, học tập trực tiếp là tùy chọn, với hầu hết học sinh ở xa, bao gồm cả tôi. Nhưng vào tháng Ba, hiệu trưởng thông báo rằng việc học trực tiếp sẽ chuyển sang mô hình tùy chọn từ ngày 5 tháng 4.

Với gần như tất cả học sinh sẽ trở lại trường, tôi nhận ra rằng một trò nghịch ngợm của sinh viên liên quan đến hệ thống IPTV bây giờ có ý nghĩa. Một vài ngày sau đó, tôi quyết định chia sẻ suy nghĩ của mình với một vài người bạn thân.

Tôi tập hợp một nhóm nhỏ trên khắp học khu và bắt đầu chuẩn bị. Chúng tôi bắt đầu gọi chiến dịch này là “Kế hoạch Lớn Rick.”

1. Tải Payload và Khai thác

Điều đầu tiên chúng tôi tập trung vào là làm thế nào để kiểm soát tất cả các máy chiếu cùng một lúc. Trong khi chúng tôi có thể gửi lệnh đến mỗi thiết bị nhận bằng cách sử dụng giao diện web, nhưng việc spam lưu lượng HTTP đến mọi thiết bị nhận cùng một lúc không phải là lựa chọn lý tưởng.

Thay vào đó, tôi sử dụng quyền truy cập SSH trên mỗi thiết bị nhận như kênh điều khiển và điều khiển (C2). Tôi phát triển một đoạn mã shell đơn giản sẽ làm nhiệm vụ là một tải Payload được tải lên mỗi thiết bị nhận trước. Đoạn mã này chứa các chức năng khác nhau có thể thực thi yêu cầu đến giao diện web cục bộ trên thiết bị nhận. Nhờ vào tính linh hoạt tăng cao từ Payload, tôi cũng có thể sao lưu và khôi phục cài đặt của thiết bị nhận đến hệ thống tệp sau khi việc rickroll kết thúc.

Trong tải Payload thực tế, tôi lặp đi lặp lại các lệnh để duy trì việc phát rickroll. Ví dụ, mỗi 10 giây, màn hình sẽ bật và đặt âm lượng tối đa. Như vậy, nếu có ai đó cố gắng tắt máy chiếu hoặc tắt tiếng, nó sẽ quay trở lại và tiếp tục phát. Cách duy nhất để tắt nó là rút phích cắm hoặc thay đổi nguồn vào. (Việc lặp lại thay đổi nguồn gây sự chớp nháy ngay cả khi nguồn hiện tại giống như nguồn mới nhất. Tôi phải dựa vào một công tắc đổi nguồn an toàn được kích hoạt ngay trước khi rickroll bắt đầu để đảm bảo mọi người đã được kết nối. Bạn có thể thấy sự chớp nháy này trong video khi đếm ngược ở giây thứ 48.)

Các lỗ hổng được tận dụng để có quyền truy cập ban đầu là cụ thể cho việc triển khai (nghĩa là D214 có lỗi khi sử dụng mật khẩu mặc định). Tuy nhiên, tôi đã phát hiện ra các lỗ hổng tăng cường đặc quyền của nhà cung cấp trong tất cả các sản phẩm IPTV của Exterity, cho phép tôi có quyền truy cập root trên tất cả các hệ thống. Một trong những lỗi này là một GTFO-bin đơn giản, nhưng hai lỗi khác là các lỗ hổng mới mẻ mà tôi không thể (và không nên) công bố.

Vấn đề tiếp theo chúng tôi giải quyết là thiết lập một luồng video tùy chỉnh để phát rickroll trong thời gian thực. Chúng tôi cần phát sóng lưu lượng multicast, nhưng chỉ có bộ mã hóa AvediaStream hoặc AvediaServer mới có thể làm điều này do các hạn chế ACL.

Thiết lập luồng video có thể coi là phần tốn thời gian nhất trong việc chuẩn bị vì việc kiểm tra là một nỗi đau tột cùng. Tôi chỉ cần một máy chiếu duy nhất cho việc phát triển, nhưng không dễ dàng khi lúc nào cũng có lớp học sử dụng chúng trong ngày.

Vì vậy, tôi thử nghiệm vào buổi tối. Tôi sẽ kết nối từ xa với một trong các máy tính trong phòng máy tính với camera trước hướng vào máy chiếu. Sau đó, tôi sẽ ghi lại một video để kiểm tra xem máy chiếu có hiển thị luồng đúng cách hay không.

Độ trễ mà bạn thấy trong video là một trong những vấn đề sớm mà tôi gặp phải với luồng. Nó hóa ra việc cố gắng chuyển hướng lưu lượng UDP qua bộ mã hóa AvediaStream tạo ra quá nhiều độ trễ. Tôi đã sửa điều này bằng cách phát sóng đến multicast trực tiếp từ một AvediaServer bằng ffmeg.

Hy vọng là tôi không làm sợ bất kỳ nhân viên nào làm việc vào buổi tối muộn!

Đó là ngày 27 tháng 4, chỉ còn ba ngày nữa đến phần kết lớn Big Rick, khi một người đồng trang lứa của tôi phát hiện ra một dải địa chỉ IP mới đầy thiết bị IoT sau một quét. Hóa ra đó là hệ thống chuông mới được cài đặt gần đây, gọi là Hệ thống Chuông Giáo dục và Liên lạc Trả lời (EPIC). Đa số các thiết bị trong dải này là loa được tìm thấy trong hành lang, lớp học, v.v.

Tương tự như cách AvediaPlayers liên kết với AvediaServers, mỗi loa được kết nối với một máy chủ EPIC cho từng trường học tương ứng của họ. Các máy chủ này có giao diện web bị khóa đằng sau một trang đăng nhập.

Chỉ có duy nhất một máy chủ EPIC được cấu hình thông tin đăng nhập mặc định. Chúng tôi có thể thay đổi lịch chuông theo ý muốn, cũng như tải lên các âm thanh tùy chỉnh. Chúng tôi có thể thay đổi chuông để phát "Never Gonna Give You Up" thay vì chuông thông thường!

Tuy nhiên, chúng tôi chỉ có quyền truy cập vào hệ thống EPIC của trường học cá nhân này vì nó là duy nhất có thông tin đăng nhập có lỗ hổng. Hoặc có phải vậy không?

Tôi phát hiện ra rằng máy chủ EPIC mà chúng tôi xâm nhập thực hiện sao lưu hàng tuần của cấu hình của mình đến một chia sẻ tệp SMB bên ngoài. Tên người dùng và mật khẩu cho máy chủ SMB này giống với thông tin đăng nhập mặc định cho hệ thống EPIC. Mỗi bản sao lưu bao gồm một bản sao lưu SQL của tên người dùng tài khoản và băm mật khẩu.

Tuy vậy, nếu các hệ thống EPIC khác cũng có máy chủ sao lưu thì sao? Và vì các máy chủ sao lưu này tách biệt từ các máy chủ EPIC, chúng có thể vẫn sử dụng thông tin đăng nhập mặc định.

Kịch bản này chính xác là trường hợp! Từ đó, tôi có thể truy cập các băm mật khẩu cho các máy chủ EPIC khác và xác định một tài khoản quản trị cục bộ có sẵn trên tất cả các máy chủ EPIC. Sau khi thực hiện một số công việc phá mật khẩu, chúng tôi hiệu quả kiểm soát tất cả lịch chuông trong học khu.

Một trong những ưu tiên hàng đầu của chúng tôi là tránh làm gián đoạn các lớp học, có nghĩa là chúng tôi chỉ có thể thực hiện trò nghịch vào trước khi bắt đầu học, trong khoảng thời gian di chuyển hoặc sau giờ học. Trước đại dịch, một số trường học sẽ bắt đầu sớm hơn, một số sẽ bắt đầu muộn hơn, một số có lịch trình học theo khối và một số sẽ có tất cả các tiết học trong một ngày. Đáng tiện vì COVID-19, tất cả các trường trung học trong học khu bây giờ đều có cùng lịch trình học theo khối, nên chúng tôi không phải lo lịch trình cho từng trường.

Một điều khác là kỳ thi cuối kỳ sắp đến gần. Mối lo lớn nhất là việc kiểm tra chuẩn hóa, không có thời gian nghỉ giữa các khoảng thời gian di chuyển. Chúng tôi quyết định vào ngày 30 tháng 4, đó là thứ Sáu trước khi kỳ thi AP bắt đầu. Chúng tôi đã thăm dò một cách kỹ lưỡng để kiểm tra xem có bất kỳ kỳ thi quan trọng nào diễn ra vào ngày này. Chúng tôi hoàn toàn sẵn sàng hủy bỏ nếu phát hiện bất kỳ kỳ thi chuẩn hóa nào đang diễn ra.

Trước ngày Big Rick, chúng tôi đã đặt sẵn tải Payload C2 trên tất cả AvediaPlayers một cách tự động, cẩn thận phân phối hành động của chúng tôi để tránh bị phát hiện. Vào ngày Big Rick, chúng tôi đã sử dụng hai trong số bảy AvediaServers làm các bản thể C2, sẽ kết nối với tất cả AvediaPlayers và thực hiện các tải Payload.

Dưới đây là dòng thời gian sự kiện vào ngày 30 tháng 4:

Chúng tôi cũng lên lịch một chuông học khác được sửa đổi lúc 3:25 CH. Nếu các kỹ thuật viên học khu vẫn chưa hiểu rõ điều gì đã xảy ra để đưa chuông về trạng thái ban đầu, vào cuối ngày sẽ phát chuông giờ tan học trong 1 phút dạng rút gọn từ chuông ban đầu 3 giây.

Tuy nhiên, họ đã giải quyết được vấn đề, vì vậy tôi đã đính kèm tệp âm thanh ở đây để bạn thưởng thức:

Hậu quả

Vài ngày sau khi gửi báo cáo qua tài khoản email ẩn danh, chúng tôi nhận được email phản hồi từ Giám đốc Công nghệ của D214. Giám đốc cho biết do hướng dẫn và tài liệu của chúng tôi, học khu sẽ không áp dụng kỷ luật. Thực tế, ông ấy còn cảm ơn chúng tôi về những phát hiện của chúng tôi và muốn chúng tôi trình bày một bản tóm tắt cho đội ngũ kỹ thuật! Sau đó, ông ấy tiết lộ rằng chính các giám đốc cấp cao cũng đã xem xét và ấn tượng với báo cáo của chúng tôi.

Tôi rất vui mừng khi ban quản lý đã sẵn lòng khắc phục vấn đề của họ và kiểm tra chúng cùng chúng tôi. Mặc dù ban quản lý D214 đã truyền đạt những ý định tốt đẹp (và họ thực hiện trong tương lai), những người đồng nghiệp của tôi không tin tưởng vào ban quản lý và nghi ngờ về bản chất thực sự của cuộc họp - một người trong số họ gọi toàn bộ vụ việc như một chiến dịch rình rập!

Chúng tôi quyết định rằng tôi sẽ tiết lộ danh tính của mình để trình bày bài thuyết trình tóm tắt với những người còn lại giấu tên trong cuộc họp Zoom. Tôi đã dự định thông báo về sự tham gia của mình từ đầu vì tôi muốn công bố bài viết này. (Dù sao thì tôi cũng gần như là nghi can chính rồi.) Nhưng, chỉ để đề phòng, tôi đã lên lịch cuộc họp tóm tắt diễn ra sau khi tôi tốt nghiệp.

Mọi người cần biết thực sự, cuộc họp tóm tắt đã diễn ra cực kỳ tốt và hiệu quả cho tất cả mọi người. Chúng tôi đã trả lời các câu hỏi làm rõ từ đội ngũ công nghệ và đưa ra các mẹo bổ sung để khắc phục sự cố. Chúng tôi thậm chí đã thúc đẩy học khu xem xét việc mở rộng chương trình Công nghệ thông tin / An ninh mạng và hy vọng sẽ tài trợ cho một cuộc thi D214 CTF?

Đây là một trong những trải nghiệm đáng nhớ nhất mà tôi từng có trong thời điểm học trung học và tôi cám ơn tất cả mọi người đã giúp đỡ tôi. Đó là tất cả và cám ơn bạn đã đọc!

Bài viết được Minh Dương viết và được xuất bản trên WhiteHoodHacker.net. Theo dõi Minh trên Twitter qua @WhiteHoodHacker.