Z-Wave是一種新興的智能家居技術，里面使用了Z-Way通信協(xié)議，這種無線組網(wǎng)規(guī)格在歐美已經(jīng)非常成熟。最近我購置了一塊RaZberry板子，開始了我的家具智能化研究之旅。

[[133848]]

什么是Z-Way

我之所以選擇RaZberry板子，而不是傳統(tǒng)的Z-Wave控制器，主要是因為它擁有對樹莓派的兼容特性，讓我可以通過程式化訪問Z-Wave協(xié)議和通用輸入輸出(GPIO)設備，這對于研究我家里面的報警傳感器非常有幫助。順便提一句，Z-Way會提取Z-Wave的特性來設計REST(Representational State Transfer)API，使得該API更加易用。Z-Way項目甚至擁有基礎的web界面，包括網(wǎng)關管理界面。

測試過程

在給RaZberry板子安裝軟件，并連上部分設備后，我開始觀察管理設備時產(chǎn)生的web請求包。Z-Way使用了Angular的JS框架開發(fā)了一個API，可以應對來自web和安卓app的訪問。

以下是一個我開燈的請求：

下面是響應包：

但此時，我發(fā)現(xiàn)了一個嚴重的問題，Angular的API并不需要認證。我在官網(wǎng)找了找，發(fā)現(xiàn)有用戶提出了這么一個問題(FAQ)：

問：HTTP/JSON的API有經(jīng)過HTTP認證麼?

答：當然沒有，你的內網(wǎng)被廠商假定為絕對安全的，自身有著第三方防火墻和密碼的保護，不會有外界侵入。如果你想要用密碼保護Z-Way，你可以使用ngnix或者其他反向代理服務器做額外的設置。

看來廠商早發(fā)現(xiàn)了這個問題，但并沒有去親自解決它。但這也說的過去，使用這些硬件的大多數(shù)都是技術極客，普通用戶占少數(shù)。不過，鄙人仍然覺得這里面潛伏著危機，因為畢竟它給用戶帶來的是未知的恐懼。

用戶的局域網(wǎng)可能會比較安全，但這并不意味著來自遠程攻擊是不可能實現(xiàn)的。我開始思考從局域網(wǎng)外攻擊API接口的方法。突然，我想起了上面的應答包。注意， Z-Way的web服務器默認的CORS(跨域資源共享)頭部允許任何origin來源，它會響應一個Access-Control-Allow-Origin: *，即允許所有origin來源，這顯而易見將導致跨域攻擊。

下面的POC將向你展示，黑客如何用惡意JS代碼掃描內網(wǎng)主機，從而實現(xiàn)對Z-Wave的操作。由于這些請求是異步的，受害者并不能意識到正在發(fā)生著什么。

首先，腳本循環(huán)嘗試局域網(wǎng)主機，向API發(fā)送POST請求。接著，它會找出返回狀態(tài)碼不為0的主機，確定其存活。如果受害者的控制器設備號小于99，腳本會遍歷設備ID號，上限為15，嘗試打開燈。這種漏洞的影響，更多地體現(xiàn)在解開門鎖、開啟車庫、以及處理其他敏感設備上。

下面的測試模擬了某主機被黑的場景，返回的響應碼為200時就是成功了：

攻擊者可以嘗試探測更多的默認內網(wǎng)網(wǎng)段，如果受害人的瀏覽器支持WebRTC，攻擊者可以得到更多的信息。在這種情況里，我們可以發(fā)出STUN請求，確定受害人的內網(wǎng)IP，從而估算內網(wǎng)范圍。

廠商要通過認證加強Razberry的安全不太容易，但用戶通過其他設置做到這一點可能并不算難。此外廠商可以做出的另一個改進，則是在CORS策略中需要指定允許的origin，而非來者不拒。Z-Way請求包的這個漏洞很有意思，它揭示了自由CORS實現(xiàn)的風險，并展示了如何攻擊他們。