ADLAB朱錢杭（大菠蘿）：其實它們近在咫尺
責編：mhshi ｜2017-06-15 15:49:44
朱錢杭，啟明星辰ADLAB研究員，網名大菠蘿。
隨著物聯網的普及，智能家居進入生活。雖然目前傳統的操作系統、數據庫越來越引起重視，但物聯網的安全并沒有引起重視，設備和云之間密碼明文傳輸。
智能門鎖安全
智能門鎖涉及到很多的百姓家里面，但智能門鎖的制造廠家從普通鎖轉換到門鎖的過程當中，只在普通鎖上面加了電控的控制器。在設計云、設計控制器的過程當中，他們認為這是一個密閉的環境，所以并沒有進行安全保護。
第一個案例（出于對廠家的尊重和保密對本文測試的門鎖廠家和型號保密）。本文測試的門鎖，直接通過無線路由器控制那把門鎖開鎖。介紹兩種情況，一種是知道密碼的情況下把這把鎖破解掉，另外一種就是不知道密碼的情況下直接破解這把鎖。
分析發現其實所有的指令從匹配到綁定設備，到開鎖、鎖門等等這些操作一共是用64個字節來完成的。為什么我們管它叫64個“圣旨”呢？這把鎖和路由的通訊用的是UDP協議。我們知道UDP的特性，源可以偽造，可以任意廣播，這是很方便的。另外一個就是，這把鎖對于這64個字節不會去驗證它的來源，不會去驗證它是否可信，是否準確，會無條件的去執行。在這64個字節當中，SN是設備的序列號，就像車的號一樣，在前擋風玻璃。如果你忘記帶鑰匙，廠家去應急處理的時候，能夠直接通過序列號幫你開鎖。所以序列號是直接寫在鎖的面板上面，只要打開蓋子就可以看到，而且是對外的。State就是鎖的狀況，就是控制這把鎖是開鎖、鎖門還是其他的操作。它的加密方式也是非常簡單的，直接是兩層。
通過開鎖和路由之間通訊的，對比分析，從它的綁定到開門，這64個字節的模板里面，除了狀態和序列號會改變以外，因為不同的設備會改變，而且不同的操作也會改變，其他地方是不變的。也就是說，這64個字節里面的62個字節，針對這個廠家這個型號的所有這把鎖全部是管用的，全部可以起作用。你可以認為是廠家開發的時候偷懶的一種方式，也可能是因為產品經理急著讓這個東西趕緊上市，趕緊推廣到市場，我只能說廠家太自信了。
因為這把鎖是云，可以通過無線路由去控制，所以在App Store或者是在Android的市場上面有廠家提供的App可以下載。App是誰都可以下載的，而且我們知道，現在App逆向也不是特別那么困難，這是我們把App逆向出來以后，我們發現在程序的代碼里面，先不說654321是弱密碼，這個廠家所有的鎖用的都是這一個密碼，654321在通訊，這是硬編碼的。本身App，尤其是Android的話，放到上邊里面，App可以做加固，但是這個廠家提供的完全沒有做任何的加固。逆出來之后，清清楚楚的能夠看到整個代碼邏輯。
檢測了5把電子門鎖，可以說有4把電子門鎖里面的Key是直接寫死在代碼里面的，這種情況可以說挺普遍的。控制這把門鎖的邏輯非常簡單，一種情況對方知道你的無線密碼，手機連到你的無線里面直接訪問這把鎖。我們知道它是UDP的，可以是廣播的方式。我們看到這個Mop是Find，是代表了你以什么樣的方式作用于這把鎖。當鎖收到你的Find指令的時候，會直接把自己的SN序列號告訴到你的App里面。Key也就是654321，剛才的硬編碼已經逆向出來了，這兩個關鍵的東西我們都拿到了。第二步發送的數據包，只要Mop改成Open開鎖的狀態，直接就把門鎖打開了。我們還試過更好玩的，如果我們用廣播包去做的話，直接放到桌子上的6把鎖全部解開了，完全不會去考慮來源是否可信。
下面是沒有Wi-Fi密碼的時候如何做？
我們說了SN號是寫在鎖上面的，為了廠家維修。如果到了門口，推向面板，也開啟這把鎖，是通過云來控制的。這里有一個問題，SN號需要需要你下載，硬編碼是654321，發送指令包，這把鎖就能大。最恐怖的事情并不是在這里，我們發現這把鎖的SN序列號是有規律的。我們抽的6把鎖里面，有3把鎖是連號的，我們可以看到這4位數在變。無論在哪兒，我下載完這個App，把數字從頭到尾排一遍，是不是家家戶戶的門都開了。服務器會覺得你好有錢，各地都有房產，都能開門。
簡單總結一下，這個鎖沒有綁定手機端，設備號可以預測，App本身也沒有做加固，云這邊還有一個問題，就是剛才我說的暴力檢測SN號，云沒有做嘗試次數的阻斷，你可以任性的去嘗試，不停的去嘗試。
智能手表安全
智能手表是用來防止小孩丟失的，上面有GPS定位，可以跟自己家的孩子對話。目前看上去這些表都是比較安全的，它不會像鎖那么脆弱，去連Wi-Fi路由等等，它是通過3G、4G通訊的，自己又有比較強的加密通訊的模式。同時我們知道，如果說你要去劫持3G、4G，不是不能做到，第一個是設備，第二個是時間和場地，你還要有目標人，整個過程會變得很復雜，成本高、耗費時間。如果說你是針對某家的小孩，如果針對他的智能手表搞一些壞事情的話，付出的代價是比較大的，成本和時間都是比較多的。但是問題就出在這個智能手表App的云上面，這個App誰都可以安裝，沒有智能手表也可以安裝這個App，也可以去注冊，也可以綁定設備。這個App的問題出在重置密碼，我們知道，你要拿對方的賬號，只要重置密碼就行了。如果說我針對某戶人家的小孩有惡意的話，我知道他的手機號，總會有一個手機號會注冊給他們家小孩的智能手表上面，知道手機號并不難。我只要知道手機號，就可以劫持這個手表。從表面上看，這個App因為是手機發送序列號，密碼又是6位數字加字母，排列組合方式有568億次，如果用電腦去嘗試的話比較困難，這個速度嘗試的比較慢，1秒鐘100次，實際上我們嘗試的速度比這個快得多，這個速度是遠遠不夠的，肯定不能用這個方式去暴力嘗試。
再往下走就是手機重置密碼的時候，如果我們知道手機號，不能暴力破解密碼的話，我們嘗試賬號找回。賬號找回的情況下，廠家有可能考慮到你換手機，允許你新的手機號注冊進去，這個時候手機就需要收一個驗證碼。我知道這戶人家的手機，要劫持這家小孩的智能手表，我肯定會用他的手機號，但是驗證碼會發到他的手機上面，我不可能找他要驗證碼，這個很容易引起別人的警覺，這種方式似乎是安全的。我們抓了一下數據包，就是App跟云這邊的數據包，手機找回密碼，發送驗證碼的數據包。他的驗證碼是4位的，提交驗證碼的數據是4位的，并且全部是數字。這個驗證碼本身是比較簡單的。
我們來理想化一下，這4位的驗證碼我們從4個0排到4個9999的話，其實如果1秒嘗試100次的話，我們100秒就能排列完，而且這個云對暴力嘗試也沒有做阻斷。我們知道驗證碼是有時間的，一般來說驗證碼發給你，讓你去試這個驗證碼，通常短信里都會告訴你，差不多30秒到50秒的時間。
這個智能手表的另一個問題就是，它的App會產生一個簽名的串，當然這個串是不確定的，并不是設備編號，是一個App里面帶出來的。我們嘗試了幾次發現，每次簽名串跟驗證碼是一一對應的。我不知道廠家為什么這么設計，廠家在設計這個產品的時候一定有一張表，這個表里面有兩列，一列是簽名串，一列是驗證碼。在服務器云那邊，你發送的這個簽名串就會扔給你對應的驗證碼。在App里面，也有這張表，我不知道廠家為什么這么設計，這樣就導致所有的驗證碼是可見的，而且本身App是可逆向，可修改，意味著你可以修改簽名串，你就會知道他給你什么驗證碼了，這是第一個漏洞。
另外一個漏洞更可笑，當你提交錯誤的驗證碼，服務器給你返回的時候，會把正確的驗證碼給你反饋回來。這個事情其實不能怪程序員，我簡單說一下，2001年的時候我寫過一些數據庫的攻擊，但是那個時候我寫了一篇文章，那個時候想過一個問題，就是為什么這種漏洞會出現。其實你們可以去新華書店，去海淀圖書館，看那些教你編程的那些書，甚至包括以前早期的MSDN上面的樣例。所有上面的代碼都是有問題的，不會教你如何防注入，如何防跨站，甚至講HTML的書上面會非常明確的告訴你，你要做驗證，在本地做驗證減少服務器壓力。這不是程序員的錯，教科書上面就是這么教我們的。這個案例我們可以說一半以上的智能設備上面都遇到了，減輕服務器壓力，驗證碼由App本地來處理，他可能認為App不像電腦上的程序，不會有人看源代碼，不會有人去破解。我們現在做互聯網站，做服務的開發人員有一個很大的區別，就是做物聯網開發的人員，他們現在的思想還是在5年前、10年前那種想法，就是用戶一定是按我所想的方式去用這個產品的，他絕對不會超過我想像的范圍，他肯定是這么想像的。這個智能手表就不用說了，那么多問題，甚至連驗證碼都原封不動的反饋給你的話，這個智能手表可以直接App連接到那個智能手表去控制。這個是登錄頁面，之后到第二個頁面，正常來說，第二個頁面應該是檢查的，確認你的確是登錄過了。但是這個智能手表云的第二個頁面是直接可以敲地址進去的，敲地址進去的時候，我們看到在底下有令牌，令牌的問題只在登錄第一個頁面的時候做驗證，第二個頁面去操作這塊手表的時候只是通過User ID來判斷的。也就是說它的做法是在數據庫里面產品的列表，后面判斷就是一個User ID，去操作這個設備，中間沒有做驗證。如果你去分析這個App的話，自己買一塊智能手表，你分析它整個流程的話，我知道第二個頁面的路徑，直接就可以跳到第二個頁面。暴力一個User ID的話，可以把這個廠家賣出去的智能手表全部可以控制，這也是很弱的漏洞，至少現在看來，比那個還要弱，一開始認為是很安全的。
車聯網安全
車聯網的。其實廠家犯了一些錯誤，他的App，我們知道車聯網通過App去連接那個汽車，檢查它的油號、胎壓，包括24小時定位這輛車。他的App基本上每半年更新一次，但是他犯了一個錯誤。一個老的App有一個功能就是重置密碼，這個重置密碼的頁面是有一個缺陷的，就是URL跳轉，原始驗證有沒有通過，直接第二個密碼帶著那個參數扔上去。雖然他的App是更新了，但是服務器云上面這個第二個鏈接還在。所以你只要構造豹紋，直接訪問第二鏈接的話，一樣的賬號可以重置現有的密碼。在用戶購車的時候，在4S店我們知道，現在車聯網基本上是拿你的油箱，大多數是用手機號作為用戶名注冊的，這個手機號也是很容易拿到的。再就是車架號，我們知道車的前擋風玻璃全部都有車架號，所有的都是。驗證碼跟前面那個一樣，直接反饋到本地校驗，反饋過來的驗證碼直接寫在上面了，重置驗證碼，手機短信交互，剛才說過了類似的漏洞，就不說了。我們拿它反饋過來的驗證碼，再還給他，輸入新密碼的時候，直接就驗證成功。這是登錄進來以后的頁面。
為什么我說故事還沒結束呢？這個一開始我們想得很簡單，就是進去以后拿到賬號就可以控制車了，就可以遠程開鎖了。但是實際上不是那么回事，還有第二層服務密碼。在拿到第一層密碼的時候，只能去看這輛車的信息，比如油耗、胎壓，不能控制。第二層服務密碼正常的流程需要打廠家的400電話，他要核對你的車主身份，信息全部核對完之后才會給你重置密碼，所以這條路肯定是走不通的。那么沒辦法，我們只能去逆向這個App，IDA是個好東西，我們逆向這個App之后，發現所有的操作都是自己創建的那些API的接口。當然作為第二層密碼繞過登錄的話，我們肯定關注的是登錄的接口，就是Log Manager那個接口。這個是HTTPS通訊的，做得很安全，我們Hook了這個通訊之后，我們發現字符排列是基于Base64的。我們嘗試用Base64去解，我們以為這個事情就可以解決了，但是解完之后我們發現是有亂碼的，說明這個方式肯定不對，不完全是標準的Base64，肯定這里面會有貓膩。因為不可能是傳輸亂碼的方式。我們看到前面的都是明文碼，Password，設備號和時間值，這些東西都是明文，都是我們正常能理解的。只有后面那一串是亂碼，這里面一定是有問題的因為正確的解開應該完全是明文。
我們再跟著逆向出來的代碼往里面走，我們發現是JWTEncoder的加密方式，這是比較常見的加密方式。我們從代碼里面也能看到，它是用兩個小數點隔開三個串，前面兩個是Base64，用一個固定的Key加密以后，再用小數點拼到第三部分。我下面寫了一個公式，加密方式基本上就是這樣，前面兩個自己做Base64拼起來，第三部分是前面兩個拼起來，用固定的Key去做。但是這里又犯了一個錯誤，就是我們說的電子門鎖的錯誤，就是它的Key是寫死在代碼里面的。如果這個Key是動態的話，這件事情做到這里就結束了，沒法再往下進行了，因為是寫在代碼里面的，就意味著整個加解密部分我們都可以還原了。
我們自己寫了一段代碼來嘗試能動性生成這樣的加密串。在生成加密串的時候，我們發現跟它實際的有一些不匹配。實際上他做了一些手腳，把Base64里面的算法自己做了一些小改動，不是標準的Base64算法。知道它的改動方式以后，只有字符替換方式以后，我們就可以完全模擬出它的加密串了。它傳輸的是GZIP的，解開之后拿到的也是Base64串，并且我們發現，它也是基于JWTEncoder來做的，也是那個Key，所以對于我們來說全部都是明文了，全部都解開了。
到這里登錄過程就全部分析完畢了。這個車最后我們能做到的就是知道車主的手機號，我們就可以遠程開鎖，24小時知道車的定位，還可以把車打著。因為我們知道，現在的車互聯有一個功能，就是冬天空調暖風可以預熱，所有車的空調風暖一定是通過發動機熱量的小水箱提供的，所以發動機一定會打著。至于自動擋的那個鎖是鎖著的，動不了的，其實90%的鎖里面就是一個塑料的卡扣，撬開以后就可以直接坐車了。這個車大多數的通訊指令，分別是開鎖、關鎖和24小時定位，就是隨時可以知道這個車的位置，這其實對于車主來說是比較隱私的事情。這個洞是去年我們搞車聯網的時候發現的，應該后來已經補了，后來我們沒有再跟進，但是我相信它在App這一塊，應該還有很多問題可以挖出來。
中間整個過程里面，我直接過濾到命令這一塊，因為中間還有一些小技巧，就是如何越權，從一個賬戶跳到另外一個賬戶。首先我自己手上有一個App的賬戶，有車聯網的賬戶。我中間有一些小技巧，可以跳轉到其他車的車主上面，直接操控他的車，這些小技巧今天我不能公布，因為對廠家當時確認是要保密的。
今天對于物聯網的安全我挑了三個比較貼近我們身邊的，包括智能手表、門鎖和車聯網。物聯網目前安全問題很多，而且我們說狀態也是差不多在5年前到10年前的，最大的原因一個是技術封閉，他們不太愿意接受外來的新的安全觀念或者是防護措施，我甚至碰到過這樣一件事情，我們在做風險評估的時候，他們很像那種在線交易系統的廠家。當時我們發現那個服務器上有洞，而且補丁也是半年前就出來了。他們有一句話給我的印象特別深，就是我這個補丁打了要死機了，你擔責任嗎？真的就是這么回事。對于傳統廠家也是這樣，他們的第一目的只要是能用就行，任何修復方式、防御措施串到他們的設備里面，給他們加入進去之后，他們非常擔心的就是如果出了問題我可以擔責任，現在沒有人黑這個設備，平平安安的運行，這是沒有問題的。補丁困難，對于車聯網這一塊，除了特斯拉以外，包括寶馬、奧迪、英菲尼迪、福特里面的設備和系統，我問過一些廠家，我身邊有很多朋友是做汽車行業的，他們跟我說，一旦發現漏洞，你讓我們全部召回嗎？不可能的事情，只能等下一代產品再說。但是物聯網的安全的確是一個很嚴峻的問題，而且就在我們身邊，近在咫尺，就是這么簡單。
提問：原來我搞過一個自行車的系統，那個系統比較低級，直接破了沙盒之后過去了，最可笑的是Windows7的系統，不打SPE的補丁，很容易的拿下了，是一個城市的自行車系統，在終端上直接搞到了數據，數據只是原封不動的看了一下。最后給他們通知的時候，他們也是同樣的話語，就是如果我這個系統出了問題的話，我們負不起這個責任。他說他們的系統由于是定制版還是什么原因，說一打SPE補丁的話就會出問題，我想問一下是這樣嗎？
朱錢杭：是簡化過的Win7，我們做過外面的ATM機上面的設備，打補丁之后，有可能真的是藍屏了，里面的系統文件是不全的，只要能夠跑起來就OK了。
提問：大家都知道，也是世界公認的，Windows是一個公認的靶系統，從來沒有正式存在過。我是一個新人，就想問一下為什么不會基于Linux開發呢？
朱錢杭：從開發情況來說，Windows的程序員要遠遠多過Linux的程序員，原因就是MSDN做得太好了。在Linux底下你開發，用其他的開發語言可能出來會好很多，但是畢竟只是一種腳本。在Linux底下做開發的話，幫助文檔的確有，要你自己去開源社區里面一個個去找，甚至有些時候要你自己一口口啃代碼。微軟把SDN做得太好了，全部翻譯成中文，有什么看不懂的，沒有比這個更方便的事情了。包括現在，我們說全宇宙最牛的開發平臺是什么？當你敲下一個小數點的時候，所有后面的關鍵字提示全部列出來了，你把代碼寫出來的時候，甚至會給你標出來哪個地方寫錯了，沒有比這個更加聰明的平臺了，所以大家都去開發Windows，這是很簡單的道理。
提問：菠蘿兄你好，我想問一下客戶端和服務通訊這種情況怎么保證安全？你有什么建議沒有？你剛才就說通過抓包，研究里面的規則，還有通過逆向。有沒有一個比較推薦的方法去防范這樣的問題？我們不說物聯網，我看你剛才逆向了一個應用，不管是Android還是iOS，都可以逆向，都可以抓包。你對于這一塊有沒有什么建議？服務端和客戶端通訊方面。
朱錢杭：通訊這一塊，跟傳統的支付基本上差不多，動態Key，非對稱加密，多層校驗，基本上是這樣，只不過現在很少廠家去做而已。
提問：不管是公鑰還是私鑰，只要破解App端都可以拿得到？
朱錢杭：如果是公司鑰的話，拿不到私鑰沒有用。
提問：如果是這樣的話我可以偽裝，可以模擬客戶端發請求。
朱錢杭：你是可以模擬客戶端發請求，但是你只能拿到4個密鑰的中間2個，也就是說，你只能拿到單方向通訊的數據，另外一個方向回來的你是拿不到的。
提問：如果說我把App都破解的話，我就可以重裝App，自然可以抓取數據。
朱錢杭：你完全逆向App，完全破解出來，完全模擬這個App，把雙向的數據明文全部拿到，這是沒錯的。你想知道這個防御方法是嗎？
提問：我想這一塊有沒有成熟的解決方案。
朱錢杭：以我目前知道的情況是沒有的，我實話實說，真的是這樣。如果說你能把App全部破解出來的話，整個模擬出來的話真的是沒有。因為全部通訊，包括代碼邏輯，包括整個判斷措施，你全部都能模擬了，你就是開發商。你問我如何去防御？Android所以做得比較好一點，蘋果因為要求要檢測你的程序，你不能去那種自己定制的。以前是Android比較容易被逆出來，現在是蘋果的比較容易被逆出來。
