基於智慧手機的近源滲透測試案例分享（二）

作者：Duncan SecTeam

0x00、引言

自從Team轉向IoT安全後，我們確實發現了一些有趣的現象以及讓人揪心的網路安全隱患，本以為這些問題只存在於中小微企業或者說非網路安全企業，直到發表上一篇文章【1】之後，我們才開始反思之前的假設或者基於已有經驗得出的推定。隨著網際網路的飛速發展以及智慧化裝置（手機，平板，智慧家電，智慧機器人以及智慧查詢終端），傳統的企業資訊化不可避免的要向物聯網過渡，一是節約企業建設和運營成本（比如，部署WiFi/IP攝像頭可以減少傳統網路佈線的人財物消耗），二是智慧裝置的引入的確可以進一步壓縮人力成本支出（HR和財務部門最喜歡這個吧）。 中小微企業出於成本考慮，往往會在安全與效益這個兩難抉擇中，“莫名其妙”地選擇後者（或許，這也是國內網路安全企業生存壓力始終沒能緩解的原因之一吧）。當然，Team前一篇文章【1】中的某網路安全公司應該不能算作此例之中，他們內網的曝露的確是公司IoT建設中的一個絕對偶然。

然而，小白最近因為家中遭受災害的原因，意外發現了成都市某消防部門IoT裝置所導致的一系列安全隱患。出於小白天生的“呆萌”與“自保”心理，小白第一時間把詳細情況和關鍵截圖全部提交到該消防部門的2家主管單位（由於該消防部門的主管衙門上報渠道實在太少了，費了很大力氣終於成功提交了相關內容，好不容易得到了所上報事件的處理流水單號）。本想上報了就完了，沒想到今天因為同樣的原因，小白又去了一趟該消防部門，相關漏洞還沒有被堵上，想了想還是寫點東西吧，萬一成都市政府資訊部門的技術大牛看到了，咱好歹也算為消防工作做了點貢獻吧，再不濟還有幾百大洋的稿費啊（畢竟，快過年了嘛）。

0x01、背景介紹

前些日子，小白因為自己家裡的事情去消防部門配合工作。出於職業習慣，小白透過某WiFi共享軟體在該消防部門的大門口（確切地說，還在圍牆外面），發現了一個名為“cd****”的WiFi，並檢視到WiFi密碼為“xfdd119”（**是該消防部門管轄區域的拼音縮寫），該WiFi訊號強度不算強，沒有達到滿格訊號。由於這個消防部門周圍沒有任何商業設施（不要說咖啡廳，就連麻將館或者茶館都沒有啊），小白心想這應該就是這個消防大隊的WiFi了吧。

向站崗的消防隊員出示證件並報備後（還用84消毒液噴了鞋底，但沒消毒手部，WHY？），小白進入了該消防部門，此時的WiFi訊號強度已經明顯變強，最終WiFi訊號滿格。此外，WiFi訊號在大院裡頭（因為旁邊全是消防車，小白不敢拍照，不能犯原則性錯誤），一樓以及三樓等不同地理位置訊號強度都是滿格，當然只是基於一加6手機檢測到的訊號，至於iPhone是否能夠如此，不得而知（畢竟，iPhone爛的掉渣站的WiFi晶片早已臭名昭著）。由此可見，這個部門應該部署了一個很專業的無線路由器並且應該配備了很多無線中繼，或許是因為消防部門內部需要部署的很多專業裝置必須入網咖。整個測試的背景大概就是這樣個情況。

以下是近源滲透過程中的軟硬體及網路資源：

硬體：

——一加（OnePlus） 6，8G+128G

——型號：ONEPLUS A6000

軟體：

——Android：10

——H2OS：A6000_22_201022

——檔案管理器：X-plore （Android）

——Linux模擬器：Andrax v5

——Linux模擬器：Kali NetHunter

0x02、接入網路

小白此次整個測試過程的起點，也算是整個網路的接入點，就是這個名為“cd****”的WiFi。手機接入的是該WiFi的4G頻段，後來發現該WiFi還有一個5G頻段。

0x03、基於Android手機的近源測試

如前文所說，因為家裡遭受了災害損失，小白需要到該消防部門報告情況並申領相關表格，因此沒有帶膝上型電腦，身邊可用計算裝置就只有一臺快停更的OP6（一加6）手機。

按照常規的測試套路，小白分別在andrax和nethunter上做了一些簡單的內部網路探測操作。下面是andrax是執行nmap掃描的操作結果和轉換為xls格式的掃描結果。內網裡面有不少開放telnet的裝置，好奇……

如team之前釋出的文章所說【1】，andrax預設沒有安裝traceroute，懶惰的小白選擇了使用Nethunter來檢視路由，但是忘了儲存截圖。小白很清楚的記得，traceroute的第二條是一個公網地址，所以認為這個部門的網路建設還是不錯的，至少WiFi網路沒有透過別的內部網路再接入網際網路。WiFi網路直接進網際網路的話，最起碼可以少暴露一些不必要的資訊，加大內網發現難度，尤其在近源測試的時候，測試人員幾乎是沒有足夠的時間進行A段，B段網路的掃描的（即便帶了一個2萬毫安的充電寶）。

從掃描結果看得出來，192。168。*。0/24網段閘道器應該是192。168。*。1，畢竟開放的埠還是很典型的閘道器埠。於是，小白試了試，確實看到了一個H3C路由器的管理登入口，發現admin賬戶（H3C預設的管理員賬戶，預設密碼與使用者名稱相同）的密碼居然與WiFi密碼相同！！！恕小白直言，這樣的低階錯誤真不應該出現在這麼重要的職能部門，畢竟這個錯誤完全賴不著別人，全是網管人員自己給自己挖的坑。

其中，111。9。*。22這個公網IP居然在被靜態綁定了，那麼就有意思了，我想擅長內網滲透的大牛應該半秒就懂了吧，小白屬於後知後覺那種型別的（愚鈍型），反應了老長時間才想明白。。。然後，用nmap嘗試探測了111。9。*。0/24網段，挺有意思的，感覺是該部門完全使用的一個公網C段。

透過Android上超好用的X-plore，小白驗證了一下SMB服務都是可以訪問的，進一步印證111。9。*。0/24是一個有公網IP的內部網段，估計是運營商預留的。對於消防等涉及老百姓安危的行業和部門，這麼做完全合情合理！

其中，有一個網段的445使用的全是SMB v1。0協議，另一個網段使用的是SMB v2。0及以上協議，並且設定了密碼保護，這算是網管做的很好的地方（此處應有掌聲）。

0x04、後續處理

雖然小白只是一個IoT安全領域的小學生，但是基本的法律常識是有的，不僅講“武德”，還遵紀守法，以白帽子的標準嚴格要求自己，因此該部分不給出任何可能的內網（橫向）滲透措施，並且第一時間通告了該消防部門的2家主管單位。

0x05、總結

1。IoT環境下，WiFi是一種高效、便捷的通訊手段，但也是駭客入侵的一種有效途徑，是IoT環境下很現實的網路安全隱患。

2。網路安全運維人員的安全意識仍舊是IoT網路安全中一個不可忽視的短板（至少相對較短的短板）。

3。年底了，各位同行主要保重身體，同時更要保住Job，下班了彆著急回家“吃雞”，“打農藥”，看看自己的一畝三分地有沒有被WiFi密碼洩露給坑了。

4。建議政府機構暢通一下網路安全反饋渠道，健全反饋機制，比如找安全客合作一下什麼的。白帽子想要做點好事真的好難啊，要麼反饋網站錯誤，要麼無法提交反饋，要麼提交了反饋卻始終不搭理你……

參考：

1。基於智慧手機的近源滲透案例分享——“點到為止”的測試某網路安全公司。https：//www。anquanke。com/post/id/229286

2。雙龍戰記：Andrax vs。 Nethunter。 https：//www。anquanke。com/post/id/223493

3。IoT環境下的滲透測試之構建高效WiFi破解字典。 https：//www。anquanke。com/post/id/219315

4。基於安卓裝置的Hacking。 https：//www。freebuf。com/articles/terminal/246679。html

5。pHacking Highway Service Station。 https：//www。freebuf。com/articles/terminal/247145。html