技术解读io.net是如何被黑的

今天看到有黑客 ionet 的所有设备都改了，看到大家很恐慌，其实这个并不困难，主要还是 io 自己的安全意识太差了

大概讲讲他是怎么做的。

IO 的工作流程

首先对 IO worker 的工作流程进行分析，其实主要是三个部分，分别是 数据抓取 上报 Uptime（不过在新版本中已经被下掉了）

初始化

在一开始启动的时候，io.net 会去 Secret 的 API 请求非常多的 配置信息，这里包含了最新的镜像，启动命令，各个 API 调用的 AuthKey。

数据抓取部分

数据抓取的部分包和代码

内容很简单，主要是一系列的设备信息的抓取，也可以在容器的 /tmp/scrape_metrics.json 中看到抓取的结果。

数据上报

/tmp/scrape_metrics.json

然后就是数据上报，这个也是黑客主要用的手段之一，他会分别往两个 DB 中写入数据，分别是 Redis 和 Postgresql。

Postgresql 的数据插入

其次是 Redis 的 Put 和修改，这里是主要是为了前端页面的现实和查询速度，这也是黑客的主要修改目标之一，这个接口比较简单，只需要有 Device ID 就可以了

Redis 的修改 以及 TTL 的覆盖

以上是关于 IO.net 的 Worker 是如何工作的主要流程。

黑客是如何污染其他用户的

这里其实就提到了刚才说的，io.net 自己的 安全意识不足，上述的上报接口中，其实是基本没有做鉴权的，你只需要拿到 USER_ID 和 DEVICE_ID，就可以手动上报设备，当然这个也是为什么之前能加这么多设备的原因，因为一个 HTTP Call 就足够了

设备上报接口

在这里 只需要提供 USER_ID 和 DEVICE_ID 就可以往官方插入一个新的设备，然后就是如何获取这些信息的问题了

获取 Device ID

在官方的 Explore 中, 是可以看到所有 Device 的信息的，通过抓接口遍历，我们也是可以拿到所有的 DEVICE_ID 的

获取 USER ID

注意：该方式已经反馈过官方安全团队 并已经于前些天被修复。

这个原理非常简单，在最早的 Worker 的初始化过程中，设备会去获取自身的状态，比如如果是 terminated 或者其他状态，就停止运行，这个接口在之前一直是可以获取 User ID 的。

早期接口

所以，在前几天的时候，只需要通过 DEVICE_ID 就可以获取所有人的 USER_ID ,

只需要拿到这两个 ID 就可以任意上报对应的设备。

访问别人的网络

这里其实就是加入到 tailscale 以后 进行了一次 nmap 扫描，只能算上这是脚本小子的自嗨。

由于 io.net 对于网络之间的通信使用的是 Tailscale, 而初始化过程中，是会把 AuthKey 下发到设备上的，所以只需要拿到 Authkey，就可以加入到 网络中，因此所有人都可以做到同样的事情。

不要担心 你的设备在没有被使用的时候是不会加入 tailscale 的。

总结

是否应该恐慌

就整个过程来说，其实并没有什么难度，只要愿意的话并具有一部分网络安全知识的话，大家都可以轻易做到。

由于 io.net 没有对 PUT/POST 的接口做 Auth，导致整个表现像 DB 被黑了一样，但实际上 收到影响的也只有 上报部分的数据，钱包和 AuthN 部分，看起来还是完全不用担心的。

为什么是今天

我个人猜测可能是因为昨天 [io.net](<http://io.net>) 的镜像中，增加了 POW 部分的验证, 所以对于部分脚本小子来说，会更有难度，因此选择在今天开始攻击。