今天看到有駭客 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]() 的鏡像中，增加了 POW 部分的驗證, 所以對於部分腳本小子來說，會更有難度，因此選擇在今天開始攻擊。

原文連結