企業接入點制造商Ruckus又補上了一堆指令注入漏洞，這些漏洞可致ZoneDirector控制器和Unleashed AP虛擬控制器被黑客完全掌控。其中一個漏洞，與去年被披露的Ruckus Web-GUI問題極端相似。雖說任何足夠復雜的軟件都難免出現漏洞，但仍有幾個緩解方法可以大幅減小成功漏洞利用的影響。

[[213358]]

2017年，沒理由讓某些設計缺陷在一個又一個產品中不斷復現。安全人員是時候開始對供應商期待更多了。

以下幾個安全操作，我們應納入IoT安全基線來考慮：

1. 別再什么都用root權限來運行

或許在嵌入式Linux早期，資源限制讓開發者不得不放棄傳統基于用戶的安全模式，而轉向什么都用root用戶來執行。時至今日，再沒有任何借口連Web服務器都以uid為0的最高權限來運行了。

默認情況下，管理界面應以較小權限運行，只可執行部分特權操作。只要Ruckus采用了任何形式的權限分離，就不會發生曝出的漏洞被直接用于完全入侵的狀況。

2. 反跨站請求偽造令牌應普遍應用

跨站請求偽造(CSRF)是嵌入式設備中最常見的安全缺陷之一。再加上大多數IoT產品本就設計成盲目信任局域網，或壓根兒不能恰當地驗證身份令牌，情況就更嚴重了。

如果Ruckus在接到漏洞報告之后就實現了CSRF防護，這些新漏洞最多也就能算作是內部人威脅。然而，現實是，編寫JavaScript代碼在局域網上定位設備并中繼轉發攻擊，并不是太難的事。

3. 建立漏洞利用緩解機制

防御技術最近幾年有了長足發展，但沒看到嵌入式設備對此有何利用。很多設備都沒采用地址隨機化(ASLR)、位置無關可執行文件(PIE)，或不可執行(NX)之類的技術。雖然這本身不是什么漏洞，這些技術也并不完美，但它們確實抬高了利用內存崩潰漏洞的門檻。

當然，供應商們采用更新一點的技術，比如控制流完整性(CFI)，甚或某些運行時殺軟，也很棒。但這不是不采用早在15年前就可供Linux使用的安全功能的理由。

4. 身份驗證請求

設備默認來自局域網的請求已通過驗證的情況太普遍了。比如說，Belkin WeMo智能開關就允許用戶家庭網絡中的任何人進行控制，并關聯上你的家庭賬戶。Mios Vera智能家居控制器想要啟用任何形式的身份驗證，都要求用戶翻遍各設置選項才能找到，如果其間遇到互聯網服務中斷，還會讓設備無法使用。

同時，Control4智能家居系統需要身份驗證才能登錄App，但設備卻無需任何令牌或口令，就可以通過基于XML的協議接受指令。授權機制的缺乏或脆弱，再加上CSRF，可使惡意網頁在無需受害者之前已驗證過的情況下，就直接操縱設備。

5. 別再用那么多的HTTP

即便不通過Web瀏覽器訪問設備，也很有可能有臺Web服務器正在運行。路由器和智能家居控制器之類設備的Web管理界面，通常都是攻陷設備的最大攻擊界面。雖然路由器這種東西的管理界面極少被用到，但HTTP服務器卻是一直在運行，隨時等待接收請求。

HTTP服務器的使用意味著，托管惡意Web內容的攻擊者(可能是惡意廣告)，可以直接向服務器發出請求。即便CSRF緩解措施就位，Web服務器實現中的漏洞本身，往往就是致命的。

舉個例子，多款NETGEAR路由器，為其所有管理功能使用了基于時間戳的CSRF防護，但因為該Web服務器中的一個低級錯誤，這些路由器都可通過CSRF進行利用。

理想狀態下，我們當然更希望看到大多數設備通信，都從HTTP遷移到更專用的協議上來，比如消息隊列遙測傳輸協議(MQTT)，這樣就基本上能對跨站和跨協議漏洞利用免疫了。配置頁面之類的情況，或許HTTP/HTTPS是最佳選擇，但既然用到它們的時候極少，又何必隨時開啟呢?

一個簡單的解決方案是，用個按鈕或其他某種非HTTP觸發器，來啟動管理界面，然后在特定超時期限后自動禁用。

總結

以上5個相對簡單的策略顯然不算完整，但實現它們確實可以大幅減小攻擊界面。隨著現實世界IoT攻擊的增多，比如曾經的Mirai和現在的Reaper，限制缺乏基本安全控制的聯網設備的增值擴散，就顯得越來越重要。