5步建立起更好的IoT安全基線
企業接入點製造商Ruckus又補上了一堆指令注入漏洞,這些漏洞可致ZoneDirector控制器和Unleashed AP虛擬控制器被黑客完全掌控。其中一個漏洞,與去年被披露的Ruckus Web-GUI問題極端相似。雖說任何足夠複雜的軟體都難免出現漏洞,但仍有幾個緩解方法可以大幅減小成功漏洞利用的影響。
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,限制缺乏基本安全控制的聯網設備的增值擴散,就顯得越來越重要。
推薦閱讀:
※什麼叫漏洞 hash?
※邏輯漏洞簡單的分析
※metasploit 學習筆記 (二)
※Dirty Cow, CVE-2016-5195漏洞的危害大概怎麼樣,有沒有修復方案建議?
※【阿里聚安全技術公開課】移動APP漏洞風險與解決方案