帶你讀《物聯網滲透測試》之一：IoT滲透測試

網絡空間安全技術叢書 點選檢視第二章 點選檢視第三章

物聯網滲透測試

IoT Penetration Testing Cookbook

亞倫·古茲曼（Aaron Guzman）

阿迪蒂亞·古普塔（Aditya Gupta）

王　濱　戴　超　冷　門　張　鹿　譯

第1章

IoT滲透測試

雖然1999年美國麻省理工學院（MIT）的自動識别實驗室（Auto-ID Labs）就首次提出了IoT（物聯網）的概念，但嵌入式裝置技術在數十年之前就已存在了。IoT裝置同嵌入式裝置之間的差別在于，在嵌入式裝置的設計決策和配置過程中，從未将建立自身同公共網際網路的連接配接考慮在内。正是由于衆多制造業公司沒有考慮到裝置聯網的後果，是以随着聯網裝置數量的不斷增多，目前出現了針對IoT裝置的大規模漏洞利用，并導緻了多起創紀錄的大規模分布式拒絕服務（Distributed Denial of Service，DDoS）攻擊。本書中，我們将從多個方面介紹針對IoT裝置的滲透測試，為測試人員提供具有可操作性的安全實踐指導，并幫助使用者在現實環境中實作對IoT裝置的攻擊防護。

讀者可以通路以下連結了解IoT的起源：

http://autoid.mit.edu/iot_research_initiative

。

要了解針對IoT裝置的DDoS攻擊詳情，可以通路以下連結：

https://www.us-cert.gov/ncas/alerts/TA16-288A

本章将主要介紹以下主題：

• 定義IoT生态系統與滲透測試生命周期。
• 固件入門。
• IoT中的Web應用。
• IoT中的移動應用。
• 硬體裝置基礎。
• IoT無線通信簡介。
• IoT滲透測試環境的部署。

1.1　簡介

本章主要關注開展IoT滲透測試所需的基礎知識，向讀者介紹IoT裝置攻擊面的基本概念，為幫助測試人員建構IoT滲透測試的實驗環境奠定基礎。

我們首先讨論目前IoT滲透測試的現狀，以及所有可能存在的攻擊面，進而了解滲透測試的進展情況。之後我們将介紹固件安全、Web應用安全、移動應用安全、硬體安全和無線電通信方面的基礎知識。

最後，我們将向讀者介紹如何對開展滲透測試所需的軟硬體工具進行配置。

1.2　定義IoT生态系統與滲透測試生命周期

在過去的幾年中，基于IoT裝置不斷上漲的數量、為業務提供的便利性、自身的易用性以及為資訊安全帶來的潛在風險等諸多因素，IoT裝置赢得了廣泛關注。由于IoT概念的火爆就出現在我們身邊，是以即便是作為一個普通人也可以感受到這個技術奇點距離自己并不遙遠。而對IoT和網際網路越來越高的依賴度使得人們不由地對人身安全、隐私安全與資訊安全産生了擔憂。同時，IoT裝置幾乎已經用在所有行業領域，如消費、娛樂業、工商業、醫療業、工業、能源業以及制造業等領域。但是，過往案例已經證明了無論是消費者還是将IoT技術商用的廠商和開發者，都難以采取有效的方式來確定裝置安全。如果指望裝置廠商在制造裝置時采用諸如安全設計之類的方法提供安全保障，又嚴重依賴于裝置所面向的行業，那麼需要廠商對行業業務具有深刻的了解，這對廠商顯然提出了非常高的要求。

各個行業也可能因垂直細分與所處區域而制訂不同的測試規範。是以，為了確定不違反相關法律規定，在對IoT裝置開展滲透測試之前需要了解有關的法律法規。在部分地區，我們以美國為例，隻要研究是出于符合社會規範的善意目的，通過合法管道獲得被測裝置，在受控環境下開展測試，并且也未違反2016年10月頒布的《計算機欺詐和濫用法案》（Computer Fraud and Abuse Act，CFAA），那麼是允許安全人員對消費級裝置開展安全研究的，并且不受《數字千年版權法》（Digital Millennium Copyright Act，DMCA）的追究。這也就意味着目前對網聯汽車、攝像頭、各種智能家居裝置、視訊遊戲機和越獄移動裝置的安全研究都是合法的。在經過與《數字千年版權法》和安全界的漫長協調之後，廣大安全研究人員取得了一個巨大的勝利。

在取得相關法律法規許可的情況下（這也是我們開展安全測試的依據所在），接下來将對裝置固件、Web應用、移動應用、硬體和無線電通信開展安全評估。首先，我們需要了解IoT所涉及的所有領域，包括滲透測試方法和生命周期，進而識别出所有可能的攻擊面。下面我們來了解一下IoT裝置中各元件的基本原理，以便知曉其攻擊原理。

滲透測試方法

無論是否出現攻擊事件，對應用、網絡和裝置開展安全測試、查找其中隐藏的漏洞對于保障網際網路安全都是至關重要的。無論是由廠商、第三方咨詢公司、企業安全團隊，還是由普通的安全人員來實施測試，測試方法的選擇都取決于能夠提供給測試人員的資訊。理想情況下，一次全面的測試應該包括整個IoT系統及其基礎設施，而不僅僅是IoT裝置本身，但考慮到成本與技術能力，現實中的通常隻針對IoT系統中的某個子集開展測試。

1.黑盒測試

由于黑盒測試成本相對較低，是以黑盒測試是最為常見的測試方法。黑盒測試是在不了解裝置所采用的技術原理或實作方式的情況下進行的測試。通常情況下，安全研究人員或第三方咨詢公司都會采用黑盒測試方法，但有時内部安全團隊也會采用該方法進行風險評估。

漏洞公開注意事項

如果在安全研究過程中挖掘出了漏洞，那麼披露漏洞時需要遵循廠商要求的漏洞公開流程。如果廠商未制訂漏洞公開流程，那麼計算機安全應急響應中心（CERT）可以協助安全研究人員以适當的方式送出漏洞。關于CERT的漏洞公開處理流程的詳細内容可以參考連結

http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm

中的内容。

2.白盒測試

如果測試人員能夠接觸到源代碼、網絡拓撲圖、架構圖、資料流圖以及其他目标裝置所采用技術的詳細資訊，那麼此時開展的測試即白盒測試。通常來說，預先能夠向測試人員提供的目标裝置或應用的資訊越多，測試效果就會越好。白盒測試的成本相對較高，但能夠確定對裝置的安全控制措施及其實作情況進行更加全面、徹底的篩查。

3.灰盒測試

相對于被測機構内部人員而言，如果測試人員對被測系統的了解有限，僅能擷取到被測系統的部分資訊，那麼此時所開展的測試即灰盒測試。在灰盒測試過程中，測試人員通常隻知道所用到的應用程式棧和庫檔案，但是沒有關于API的詳細文檔。

讀者可以通路以下連結了解更多開展安全研究過程中有關《數字千年版權法》（DCMA）的内容：

https://www.ftc.gov/news-events/blogs/techftc/2016/10/dmca-secu-rity-research-exemption-consumer-devices

1.3　固件入門

固件是一種寫入硬體裝置的軟體，作用是對應用和各項系統功能實施控制。固件中包含底層代碼，這些代碼能夠幫助軟體實作對硬體的操作。運作固件的裝置稱為嵌入式系統，嵌入式系統的硬體資源在存儲能力以及記憶體等方面往往具有諸多限制。舉例來說，智能手機、交通信号燈、網聯汽車、某些類型的專用計算機、無人機和有線機頂盒都是運作固件的嵌入式裝置。

顯然，從城市運作所依賴的關鍵基礎設施，到人們生活中必不可少的銀行ATM和智能家居，嵌入式技術及運作在嵌入式裝置之上的固件控制着我們的日常生活。了解固件的二進制檔案中都包含哪些内容以及與之關聯的屬性是非常重要的。固件通常由bootloader、核心、檔案系統以及其他資源組成。根據嵌入式Linux、嵌入式Windows、Windows IoT核心以及各種實時作業系統（Real Time Operating System，RTOS）的差別，固件也有多種類型。本書主要針對基于嵌入式Linux的環境進行介紹，但是，本書中所涉及的原理對于其他平台也是同樣适用的。

讀者可以從以下連結中了解更多關于固件的内容：

https://wiki.debian.org/Firmware

圖1-1展示了固件的組成，即閃存、bootloader、核心和根檔案系統。

1.3.1　固件深度分析

首先讓我們先了解一下bootloader。bootloader的作用主要包括RAM初始化（目的是存儲易失性資料）、序列槽初始化、機器類型檢測、核心參數連結清單（kernel tagged list）設定、 initramfs（基于RAM的初始檔案系統）加載以及核心鏡像調用等。bootloader通過闆級支援包（Board Support Package，BSP）初始化硬體驅動，其中闆級支援包通常由第三方廠商開發。可以将bootloader存儲在單獨的電可擦除可程式設計隻讀存儲器（Electrically Erasable Programmable Read-Only Memory，EEPROM）中，但這種情況一般不太常見，更為常見的形式是直接将bootloader寫入閃存存儲器。從某種程度上說，我們可以将bootloader看作啟動PC時的BIOS。深入分析bootloader的各項功能已經超出了本書所讨論的範疇，這裡我們隻對本書用到的bootloader特性進行介紹。ARM、MIPS架構中部分常見的bootloader包括：Redboot、u-boot以及barebox等。當bootloader啟動核心之後，檔案系統就完成了加載。

固件可以采用的檔案系統類型有很多，有時根據裝置的差別也會采用某些專有檔案類型。部分較為常見的檔案系統類型包括SquashFS、cramFS、JFFS2、YAFFS2以及ext2等。其中裝置（尤其是消費級電子裝置）最常采用的檔案系統是SquashFS。分析人員可以使用諸如unsquashfs或者改進後的unsquashfs等工具從SquashFS檔案系統中提取資料。有部分廠商會對SquashFS檔案系統進行改進，以確定能夠對非标準的SquashFS檔案系統壓縮算法提供支援，比如說LZMA壓縮算法（在SquashFS 4.0之前，官方支援的唯一壓縮格式為.zlib），而此時就需要用到改進後的unsquashfs工具進行解壓，同正常的标準SquashFS檔案系統相比，非标準的SquashFS檔案系統啟動時的偏移量同之前會有所差別。在本書後面的内容中，我們将會對偏移的定位與識别進行專門的介紹。

讀者如果想了解有關嵌入式Linux檔案系統的更多内容，可以通路以下連結：

http://elinux.org/images/b/b1/Filesystems-for-embedded-linux.pdf

Sasquatch是一套能夠對非标準SquashFS檔案系統進行解壓、從中提取檔案系統的工具，即可以從以下連結下載下傳：

https://github.com/devttys0/sasquatch

與之類似，固件鏡像也可以采用LZMA、.gzip、.zip、.zlip和.arj等多種檔案壓縮類型。每種檔案類型在壓縮後的檔案尺寸、壓縮時間、解壓時間以及裝置自身的業務需求等方面都各有擅長。從滲透測試的角度出發，我們可以把檔案系統看作存儲配置檔案、服務、賬戶密碼、散列值、應用程式代碼以及啟動腳本的地方。在下一章中，我們将介紹如何查找裝置中的檔案系統，以及如何确定其采用的壓縮方式。

1.3.2　固件的開發供應鍊

檔案系統中包含同裝置強相關的代碼，這些代碼通常采用C、C++或者Lua之類的程式設計語言編寫。與裝置相關的代碼，甚至是固件自身，都可以外包給第三方開發人員，即原始設計制造商（ODM），也可以由内部開發人員同原始裝置制造商（OEM）協作開發。ODM是嵌入式裝置開發供應鍊中的一個重要環節。在亞洲，有很多這樣的小公司，并且開發成本也較為低廉。有些OEM信任自己産品線上的ODM，而有些OEM則會選擇對單一産品報價最低的ODM。在某些行業中，ODM也可以稱為供應商。需要特别注意的是，ODM是能夠同多家不同的OEM開展合作的，甚至可以采用相同的代碼庫。讀者可能已經知道這個情況，或者驚訝于為什麼一個嚴重的軟體漏洞公告就會影響到十餘家裝置廠商。究其原因就在于ODM自身并未建立安全開發生命周期流程，而OEM對此也疏于驗證。一旦ODM完成了應用開發成果的傳遞，這個成果可能是OEM的一個SDK也可能是固件，OEM就會直接把傳遞的代碼融入固件之中，實作起來可能就是簡單地在Web界面添加OEM的一個logo。根據ODM和OEM代碼融合方式的不同，實作過程也有所差別，其中一種較為常見的方式是，ODM向OEM直接提供二進制檔案。OEM負責固件分發、固件管理以及對裝置自身提供支援，其中也包括解決第三方研究人員送出的固件安全問題，如果ODM持有源代碼，而OEM僅能拿到二進制檔案，那麼OEM難以有效緩解固件中的安全隐患，進而将面臨巨大的壓力。

在第3章中，我們将通過了解如何識别檔案系統、壓縮方式，以及如何建構二進制檔案的仿真測試環境來實作對固件二進制鏡像的逆向分析，進而對固件中常見的漏洞開展利用。

1.4　IoT中的Web應用

網站，也稱為Web應用，已經無須對其進行過多的介紹了。基本的Web應用程式通常最少由前端HTML頁面、JavaScript腳本、1台背景Web伺服器、1台應用程式伺服器和1套資料庫組成。随着Web應用的發展，為了降低後端架構或裝置的計算載荷，Web應用程式開始更多地依賴JavaScript腳本等前端代碼。但是運作在網際網路中的Web應用同運作在嵌入式裝置中的Web應用略有不同。

讀者所熟悉的Web應用元件之間存在更多的依賴關系，因為常見的Web應用會将Web伺服器、應用伺服器、資料庫伺服器以及背景運作的微服務進行分離。其中伺服器的分離是出于性能和可用性等方面的考慮。而通常嵌入式Web應用被設計為在自包含的環境中運作。從更深層次上來說，也就是對嵌入式Web應用的性能和可用性方面關注較少。

目前IoT領域中主要有兩種不同的Web應用模型，分别是混合雲模型與獨立嵌入式伺服器模型。混合雲模型中包含了廠商或者供應商提供的基于軟體即服務（Software as a Service，SaaS） 的Web應用，作用是同運作在嵌入式裝置固件中的Web應用程式建立連接配接，然後，将資料從廠商的雲伺服器中同步到本地網絡的嵌入式裝置中。有些IoT裝置則會直接使用IoT雲服務提供商的SDK，例如AWS提供的IoT SDK和Azure提供的IoT SDK，并且将這些SDK編譯進裝置的Web應用程式棧中。為了確定符合機構的服務條款并且遵循所在區域的法律規範，混合雲模型的識别非常重要。許多采用混合雲模型的IoT公司經常以OEM的方式借助第三方軟體開發公司或ODM來管理其Web應用。這些ODM的Web應用通常被貼牌為某款OEM産品，在沒有設定通信流量代理的情況下，使用者通常不會注意到這種情況。

IoT裝置的混合雲模型如圖1-2所示，其中IoT裝置能夠連接配接到網際網路。該場景中，在廠商雲平台與使用者裝置之間由裝置接口提供Web服務，使用者通路裝置接口進行操作或者進行資料收集。

如前所述，嵌入式裝置的Web應用在裝置固件内部運作，以lighttpd或者nginx等程式作為嵌入式Web伺服器，而不存在外部依賴。讀者可能對這些獨立嵌入式Web應用比較熟悉，在列印機、VoIP電話和家庭路由器中都可以找到這些應用。通常情況下，使用者輸入直接發送到裝置固件，如果未對使用者輸入進行驗證或過濾，攻擊者則可以向裝置發起攻擊嘗試執行任意指令。在某些情況下，出于防止外部攻擊或者便于管理的目的，嵌入式Web應用設計為僅在區域網路（Local Area Network，LAN）環境中運作。這也是家用IoT、工控裝置和商用裝置中的典型情況。通常将裝置限定在區域網路環境下是出于安全方面的考量，但從我們所了解的情況來看，這種方式難以有效地緩解攻擊。這是因為，持有這種觀點的裝置廠商在現實中發現客戶總是會有意無意地将裝置連接配接到網際網路上，進而給使用者網絡帶來安全隐患。

圖1-3展示了使用者通過Web浏覽器連接配接獨立嵌入式Web應用的過程，其中該應用不依賴于外部系統。

Web通信

浏覽器、嵌入式伺服器和Web應用伺服器之間的通信通常要麼借助簡單對象通路協定（Simple Object Access Protocol，SOAP）/XML等Web服務，要麼借助基于HTTP/HTTPS符合REST規範的API來實作。SOAP請求中通常包含1個envelope元素、1個xmlns:soap命名空間、1個encodingStyle屬性，此外還包括其他元素，例如SOAP中的body元素。讀者可以通過通路連結

https://www.w3schools.com/xml/xml_soap.asp

了解更多關于SOAP協定的内容。

下面展示了一個查詢賬戶餘額的HTTP SOAP請求示例：

REST風格的API用到了多個HTTP方法，而這些方法的使用并不符合傳統Web應用的用法，例如傳統Web應用采用PUT方法更新資源，采用DELETE方法删除資源，而采用REST風格的請求則是通過URL（對于敏感資料不推薦采用此方法進行處理），或者以JSON格式表示的HTTP協定封包等方式調用參數。

在電子郵件分發清單中添加郵件位址[email protected]的REST請求示例如下：

可以采用中間人代理來檢視基于SOAP協定或符合REST風格的請求封包。常用的Web代理工具包括Burp Suite與OWASP ZAP，借助這些工具可以檢視從浏覽器和移動應用發送到Web應用後端的所有請求。我們将在第4章中詳細介紹如何配置代理來檢視應用流量。

對于IoT裝置而言，常常采用Web應用對其裝置進行控制，是以，無論是從網絡内部還是網絡外部來看，Web應用都是發起攻擊的常見途徑。在第4章中，我們将會了解如何識别IoT裝置中Web應用的缺陷與漏洞。

1.5　IoT中的移動應用

在IoT領域，移動應用模型同前面介紹的Web應用模型類似。雖然對移動裝置平台的安全模型進行深入探讨超出了本書的範圍，但是了解移動應用開發模型的基本概念将有助于後面的學習。

1.5.1　混合應用

安裝在Android、iOS或Windows Phone裝置中的移動應用可以是混合應用也可以是原生應用。雖然同Web應用相比，混合和原生在移動應用中具有不同的含義，但是其原理相似。混合應用既用到了HTML/HTML 5、CSS和JavaScript等Web技術，也用到了部分原生平台硬體，如GPS子產品或藍牙子產品。隻有使用混合架構提供的插件才能夠通路硬體資源。可以将混合應用看作包含了Web應用的封裝包，而原生平台可以使用該封裝包。這意味着Web開發人員無須學習新的開發語言即可編寫移動應用。

混合應用在Windows Phone、Android和iOS等多個平台上可以使用同一個代碼庫，當考慮将IoT裝置應用投放市場時這是一個巨大的優勢。通過嵌入式Web浏覽器WebView就可以調用Web應用。目前，市場中流行的應用有多種流行的混合架構可以選擇，包括Apache Cordova、Adobe PhoneGap以及Xamarin等。

每套移動混合架構都包含一個第三方市場，在其中提供可以實作各種功能的插件。為了實作快速開發，部分架構會采用一種程式設計語言（C#）編寫，然後再翻譯成另一種本地語言（Objective C或者Java），例如Xamarin就是如此。然而，從原生平台的高危遠端代碼執行到隐私洩露，這些移動架構存在着諸多安全隐患，這也并非什麼秘密。如果讀者在應用中恰好發現用到了某套移動混合架構，那麼最好查閱一下相應的漏洞庫，興許就能夠找到可以直接利用的漏洞。

為了幫助讀者更好地了解混合應用運作的架構，圖1-4展示了應用代碼、WebView、插件以及移動裝置自身之間的各個元件。需要注意的是，大多數封裝包的代碼和插件都是由混合架構或參與混合架構開發的第三方開發人員開發的。

1.5.2　原生應用

原生應用是為特定作業系統開發的，采用Java、Objective C、Swift等裝置平台原生語言編寫，其中對于Windows Phone平台而言則需要采用C#語言。原生應用使用各自平台的SDK實作同攝像頭、藍牙和GPS等硬體的互動。原生應用的性能和安全性取決于開發人員對原生平台語言的熟悉程度。如果平台API經常更新并且經常棄用某些類或方法，那麼将會增加開發工作的難度。越來越多的平台，例如iOS和Android等平台，正在開發安全的原生API，這樣開發人員就無須再利用第三方庫即可直接使用安全API，進而提高通信和資料存儲的安全性。

同混合應用架構相比，原生應用架構簡單得多。圖1-5展示了原生應用在裝置上直接運作原生代碼通路硬體資源的過程，在應用通路硬體資源的過程中未借助第三方元件。

了解每種移動應用模型的優缺點對于高效地開展滲透測試而言非常重要。由于移動應用擁有裝置的控制權，是以是針對裝置實施攻擊的另一個重要突破口，并且同其他方法比起來，有時通過移動應用突破IoT裝置要更加容易一些。在第5章中，我們将分解IoT裝置，對IoT移動應用中最常見的漏洞展開深入分析。

1.6　硬體裝置基礎

下面從印制電路闆（Printed Circuit Board，PCB）開始，對IoT裝置中所涉及的硬體進行介紹。PCB由玻璃纖維、銅箔、阻焊層、絲印層、布線層和基闆組成，在其上焊接有電阻、電容、Wi-Fi晶片、EEPROM、序列槽和微控制器等元件。闆上布有多層銅箔作為PCB的導電體，而絕緣層則不導電。在檢視印制電路闆外觀時，準确識别出感興趣的元件非常重要。這些元件主要包括裝置固件直接或間接的輸入源。其中，EEPROM晶片、NAND閃存晶片、UART（Universal Asynchronous Receiver/Transmitter）接口和JTAG（Joint Test Action Group）接口通常都是滲透測試過程中最為關注的元件。

數字視訊錄像機（Digital Video Recorder，DVR）的PCB如圖1-6所示。

硬體輸入

EEPROM是非易失性存儲器，以單個位元組為機關進行讀寫。EEPROM可以通過電荷或紫外線照射擦除資料。同其他閃存類似，EEPROM晶片的讀寫次數有限。我們關注EEPROM晶片的原因在于，固件一方面可以加載到EEPROM晶片中，另一方面也可以從PCB中擦除而讀取到EEPROM讀寫器上，進而便于進一步的分析。圖1-7是EEPROM的示意圖。

NAND閃存以區塊為機關讀寫，通常用在USB驅動器中，但也可以用在IoT裝置和遊戲機中。NAND閃存中通常存儲着裝置的bootloader，bootloader依據指令引導作業系統啟動，此外使用者還可以對bootloader進行操作，關于bootloader的内容我們将在後文詳細介紹。

UART接口是通路裝置最為常見的方式。廠商在部署裝置時可以使用UART接口進行裝置診斷、日志記錄等操作，還可以作為調試接口來驗證配置，這使得UART接口成為固件中最常見的輸入源之一。由于廠商主要使用UART接口進行裝置調試，是以通常連接配接該接口後即可獲得root權限。然而有些情況下，通過UART接口通路裝置需要輸入密碼，這時可能需要分析人員額外花費時間進行暴力破解。UART接口晶片包含兩條串行線，這兩條串行線分别用于接收資料和傳輸資料（Rx/Tx）。UART收發資料均需要借助資料總線。資料以并行方式從資料總線傳輸至UART傳輸器。UART傳輸器從資料總線中取得并行資料（并行資料通常包含5～8位資料位，其中7位資料位和8位資料位較為常見，因為ASCII标準字元集采用7位編碼，擴充字元集采用8位編碼）後，添加起始位、校驗位以及停止位建立資料幀。接下來，資料幀以串行方式在Tx引腳逐位傳輸。UART接收器則從Rx引腳逐位讀取資料幀，繼而将串行資料轉換為并行資料，并删除起始位、校驗位以及停止位。最後，UART接收器以并行方式将資料幀傳輸至接收端資料總線。由于是異步通信，是以UART接口工作時不需要外部時鐘，發送端和接收端會按照固定的波特率來進行資料采樣。PCB上UART接口的引腳定義中包括了Tx、Rx、Vcc（電壓）和GND（接地）4個引腳。連接配接UART接口前需要使用萬用表識别出Tx、Rx和GND引腳。有時，個别裝置中UART接口的識别可能會比其他裝置更加困難一些。有些廠商可能會直接移除PCB上UART接口的排針插座，對于這種情況，研究人員就需要将排針插座重新焊接到PCB上去。還有些廠商會選擇覆寫掉UART接口排針插座的絲印，還會将另一塊內建電路覆寫在接口的插座上，而對于這種情況解決起來就比較麻煩了。

JTAG接口是遵循IEEE 1149.1标準的另一種國際标準測試協定，主要用于晶片級與系統級測試。類似于UART接口，廠商也可以采用JTAG接口作為調試的輸入。JTAG接口能夠提供密碼保護，但是也可以通過BYPASS（旁路）模式進行通路。通過JTAG接口可以進行固件轉儲，友善後續對固件的分析，也可以用于固件更新。JTAG接口可以直接通路閃存或者RAM等闆載硬體。JTAG接口包含TDI（資料輸入）、TDO（資料輸出）、TMS（測試模式選擇）、TCK（測試時鐘）和TRST（測試複位）等5個引腳。JTAG接口可以連接配接到晶片上的TAP（測試通路口），通過TAP通路晶片上的寄存器時可以改變寄存器狀态。與UART接口類似，廠商也會隐藏JTAG接口的排針插座或者線路。

通過拆解裝置或者搜尋

https://fccid.io

等第三方網站，可以觀察IoT裝置中的PCB構造并定位元件位置。美國聯邦通信委員會（Federal Communications Commission，FCC）ID是FCC配置設定的産品ID，其作用是掌握市場上無線産品的具體資料。fccid.io網站真是棒極了！該網站提供了大量關于裝置的詳細資訊。其中，FCC還會公布裝置的設計文檔、資料表、内部結構圖檔、外觀圖檔、測試報告、各種手冊、裝置采用的無線頻率等内容。在第6章中，我們将會對硬體攻擊方法、硬體細節進行介紹。

1.7　IoT無線通信簡介

同IoT裝置建立連接配接并與其進行互動的最常見方式是采用無線射頻（Radio Frequ-ency，RF）通信方式。目前市場上有許多不同的無線頻率、調制子產品和協定，其中既有專有無線協定，也有标準協定。是以打開裝置外殼，使用者往往能夠發現其中包含了一個或多個用于無線通信的晶片。這對于需要接收多種不同無線通信協定和頻率的IoT網關和IoT Hub來說尤為常見。無線技術與無線通信裝置的一個優勢在于能夠實作裝置的遠端控制。當通過無線通信方法對裝置開展漏洞利用時也正是利用了這一點。是以，了解每種無線技術所能達到的最遠通信距離對實際測試而言非常重要。有的無線協定支援105英尺（約32米）遠的距離，而有的可能隻支援20厘米遠，差别非常大。在IoT生态系統的衆多無線協定中，最常用的協定主要包括Wi-Fi（802.11）、ZigBee（802.15.4）、Z-Wave、藍牙（802.15.1）和低功耗藍牙等。

1.7.1　Wi-Fi

多年以來，Wi-Fi一直是衆多裝置最常采用的無線技術，其通常使用2.4 GHz或5 GHz ISM頻段。同時也提出了多套Wi-Fi協定标準，例如802.11a、802.11b、802.11g、802.11n和802.11ac等。其中802.11b和802.11g協定使用2.4 GHz頻段，802.11a、802.11n和802.11ac協定使用5 GHz頻段。2.4 GHz頻段根據不同頻率又分為14個無線子信道。在部分地區，Wi-Fi路由器還必須采用特定的廣播信道。

1.7.2　ZigBee

ZigBee是基于IEEE 802.15.4協定為實體層和媒體接入控制層實作的規範，支援低功耗無線Mesh網絡。不同地區的ZigBee協定使用不同的ISM頻段，但主要還是在全球使用2.4 GHz頻段，在美國使用915 MHz頻段，歐盟使用868 MHz頻段。ZigBee網絡由協調器（ZigBee Coordinator，ZC）、路由器（ZigBee Router，ZR）和終端節點（ZigBee End Device，ZED）組成。建立ZigBee網絡時協調器自動啟動進行組網。每個網絡隻允許有一個協調器，它是整個網絡的信任中心，負責對入網節點的認證與驗證，并且擁有唯一的入網密鑰。路由器主要負責在各節點之間傳送資料，并将協調器與終端節點連接配接起來。

為了確定封包在網絡中的正确傳遞，路由器需要一直處于工作狀态。終端節點就是IoT裝置，例如電燈開關、傳感器、攝像頭或者監控裝置。終端節點不能在網絡中路由資料，在沒有資料傳輸的情況下會以低功率模式休眠。ZigBee網絡基于兩個安全密鑰，即網絡密鑰和鍊路密鑰。網絡密鑰是網絡中所有裝置共享的128位密鑰，主要用于確定傳輸通信的安全。鍊路密鑰是隻在互相通信的兩個裝置之間共享的128位密鑰，主要用于確定ZigBee應用層單點傳播通信的安全。鍊路密鑰可以預先配置設定給裝置或通過密鑰交換進行分發。但是在ZigBee網絡中，已知裝置配對過程中的密鑰交換存在漏洞，攻擊者能夠利用該漏洞嗅探網絡密鑰交換過程，進而影響整個網絡的安全。

2015年，Blackhat安全大會上分享了一個關于ZigBee網絡漏洞利用的議題，該議題的幻燈片連結為

https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Ex-ploitedThe-Good-The-Bad-And-The-Ugly-wp.pdf

1.7.3　Z-Wave

Z-Wave是另一種低功耗無線通信協定，該協定支援主從模型的Mesh網絡。Z-Wave使用低于1 GHz的頻段，具體頻段因地區而異（美國使用916 MHz頻段，歐盟使用868.42MHz頻段）。基于Z-Wave協定實作的實體層和媒體接入控制層經ITU認可成為國際标準G.9959。采用Z-Wave協定的裝置最遠通信距離能夠達到328英尺（約100米），但在Mesh網絡中，當流量通過Z-Wave裝置時最遠距離能夠達到600英尺（約200米）。Z-Wave網絡采用4位元組（32比特）的HomeID進行辨別，該辨別也是控制器或主節點的唯一辨別。每個節點加入網絡時，控制器會為其配置設定1位元組（8比特）的NodeID。HomeID不同的節點間不能通信。Z-Wave協定可以采用AES加密算法，這也是Z-Wave Hub所支援的加密算法，但是到底是否實作對于廠商而言是可選的。Z-Wave協定還具有良好的信号幹擾檢測特性，能夠防止拒絕服務（Denial of Service，DoS）攻擊。

關于Z-Wave協定的更多内容請通路網站

http://www.z-wave.com

1.7.4　藍牙

藍牙是一種常用的短距離資料通信的無線技術标準（IEEE 802.15.1）。藍牙在2.4 GHz～2.485 GHz頻段進行廣播，最遠通信距離可以達到100米，但常用于10米以内的通信。由于大量IoT裝置采用藍牙作為主要通信手段，後文将對藍牙和低能耗藍牙（Bluetooth Low Energy，BLE）的滲透測試技術進行介紹。關于藍牙的其他内容可以參看連結

https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works

1.8　IoT滲透測試環境的部署

介紹完了IoT技術的所有基礎概念，下面我們開始着手搭建IoT滲透測試環境。由于IoT裝置用到了多種技術，是以在對軟硬體開展滲透測試時會用到多款工具。其中既包括需要花錢采購的商用工具，也包括免費工具。為了不影響測試，部分硬體和無線電分析工具需要提前采購。盡管Web應用代理工具的許可費用并不高，但是在這裡我們還是盡可能地選擇花費不多的工具，如果有免費工具的話則盡可能使用免費工具。

1.8.1　軟體工具要求

軟體工具主要包括固件、Web應用以及移動應用測試工具。對于這三種類型的測試工具而言，除了用于Web測試的Burp Suite之外，大多數測試工具都是免費的。為了友善應用，建議最好提前部署好虛拟環境，并将固件分析、Web應用測試、移動應用測試（測試内容有限）以及無線電分析過程需要用到的大多數工具安裝好。本節中，我們将所有可能用到的工具進行了彙總。

1.固件分析工具

幸運的是，大多數固件分析工具都是免費并且開源的。有些工具會自動更新，而另一些工具雖然已經長期沒有更新，但仍然可以用于測試。讀者可以使用下面列出的固件工具來分析固件鏡像、提取鏡像以及在運作時附加到固件程序中以友善調試：

• Binwalk
• Firmadyne
• Firmwalker
• Angr
• firmware-mod-toolkit
• Firmware Analysis Toolkit
• GDB
• Radare2
• Binary Analysis Tool（BAT）
• Qemu
• IDA Pro（可選）

2. Web應用滲透測試工具

Web應用滲透測試的常見工具主要包括Burp Suite和OWASP ZAP。Burp Suite有免費版和專業版之分，專業版的價格也不算離譜。而ZAP則是完全免費并且開源的，在需要控制成本的情況下，ZAP不失為一種比較好的選擇。在對Web服務和API進行測試時，還可以加載插件。但是，如果要安裝Burp Suite的插件，則需要先購買專業版。這裡列出的所有工具都是跨平台的，它們要麼是基于Java開發的，要麼可以内置在浏覽器中：

• Burp Suite
• OWASP Zed Attack Proxy（ZAP）
• REST Easy Firefox Plugin
• Postman Chrome Extension

3.移動應用滲透測試工具

同固件分析工具一樣，大多數移動應用安全工具也都是免費并且開源的。根據下面所列出的移動平台可以對移動應用滲透測試工具進行分類。

（1）Android

在撰寫這本書的時候，網上已經有很多Android滲透測試工具和虛拟機了。有些工具完全側重于APK代碼的靜态分析，還有些工具則側重于應用運作時的動态分析。已發行的大多數Android滲透測試虛拟機都是免費的，其中包含了測試Android SDK等Android應用所需要的工具。雖然我們列出了一些Android滲透測試工具，但是依然建議讀者下載下傳與自己的測試需求最為契合的Android滲透測試虛拟機，并在虛拟機中安裝其他用到的滲透測試工具。

在這裡，雖然沒有明确要求Android測試工具同本機互相隔離，但是為了確定移動應用測試環境更加穩定，并避免出現檔案依賴問題，我們還是建議讀者将Android測試環境同本機隔離起來。

• 發行版Android滲透測試虛拟機：Android SDK、Android Emulator
• Enjarify
• JD-Gui
• Mob-SF
• SQLite Browser
• OWASP ZAP

（2）iOS

由于iOS平台比較特殊，是以在開始滲透測試前需要準備好OS X計算機和已越獄的蘋果裝置。如果不滿足這兩個前提條件，那麼是無法對iOS應用開展滲透測試的。下面是對iOS應用進行滲透測試時用到的部分工具。

下面列出的是需要在OS X計算機上安裝的iOS應用滲透測試工具和安全評估工具：

• idb
• Xcode Tools
• Class-Dump
• Hopper（可選）

下面列出的是為開展滲透測試需要安裝在越獄裝置上的軟體：

• Cydia
• openURL
• dumpdecrypted
• ipainstaller
• SSL Kill Switch 2
• Clutch2
• Cycript

1.8.2　硬體分析工具需求

根據所分析裝置的不同，硬體分析工具也有所不同。然而，有一些基本的分析工具對于所有硬體甚至是電氣元件都是适用的。裝置商在制造裝置時會使用不同型号的螺絲、外殼和保密位以防止使用者拆解硬體。有時，螺絲會隐藏在标簽或橡膠墊下，分析人員需要撕開标簽或者揭開橡膠墊才能找到封裝裝置的螺絲。在硬體拆解過程中，确定螺絲型号至關重要。隻有确定了螺絲型号，我們才能夠借助專用工具拆解裝置，繞過廠商設定的阻礙。圖1-8可以幫助測試人員區分出螺絲類型。

下面列出了本書中将要用到的硬體工具和硬體分析軟體。

1.硬體工具

開始硬體測試前需要提前購買一些硬體工具。以下是拆解裝置、查找接地引腳以及通路裝置接口所需要的工具：

• 萬用表

• 用于硬體拆解的IFixit classic pro tech toolkit工具套裝
• Bus Pirate
• USB轉序列槽轉接器：Shikra、FTDI FT232、CP2102、PL2303、Adafruit FTDI Friend
• JTAG接口轉接器：Shikra、JTAGulator、Arduino with JTAGenum、JLINK、Bus Blaster
• 邏輯分析儀（可選）：Saleae Logic等

讀者可以通路以下連結了解更多的資訊：

• https://www.ifixit.com/Store/Tools/Classic-Pro-Tech-Toolkit-/IF145-072-1
• http://int3.cc/products/the-shikra
• https://www.sparkfun.com/products/12942
• http://www.grandideastudio.com/jtagulator/
• https://www.saleae.com/

2.硬體分析工具

下面列出的都是免費的硬體分析工具。這些工具能夠幫助讀者連接配接Console口等硬體接口，或者将固件以side-loading方式刷入裝置：

• OpenOCD
• Spiflash
• Minicom
• Baudrate

1.8.3　無線電分析工具需求

為了嗅探無線網絡流量，需要準備特定的無線晶片組。在本書中我們将主要關注ZigBee和Z-Wave協定流量的嗅探。在無線網絡流量嗅探過程中，部分特定軟體需要配合無線網卡與軟體狗進行使用。無線網卡和分析軟體的使用建議如下。

1.無線電分析硬體

下面列出了用于分析無線電頻譜的硬體裝置：

• Atmel RZ Raven USB裝置（KillerBee攻擊架構）
• Attify Badge（或者C232HM-DDHSL-0線纜同Adafruit FTDI Breakout開發闆的搭配）
• HackRF One
• Yardstick One
• 帶有Xbee Shield子產品的XBee擴充闆
• Ubertooth
• BLe擴充卡

2.無線電分析軟體

下面列出了常用的無線電分析軟體工具，列出的大部分工具在本書中都會用到。

• KillerBee架構
• Attify ZigBee架構
• GNU Radio
• BLEAH
• GQRX
• Ubertooth tools
• Blue Hydra
• RTL-sdr
• Hackrf packages
• EZ-Wave