某打印機固件更新校驗突破
漏洞復現
復現一下一些比賽的漏洞,學習一下,也方便之後打比賽。
某打印機可以通過篡改更新包實現惡意固件上傳。
先拿到官方給的更新工具
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b554e3428d3b71886d7987527400dddb2481c0078fb67704c0ea750ae0aa8af75.jpg)
看到是個exe,直接執行了會報錯,直接丟進binwalk,看到解出了一些東西,直接對MICE_ALL.fw進行分析
![](http://mdimg.wxwenku.com/getimg/ccdf080c7af7e8a10e9b88444af983935eb553cb5564d1f1bc96d1dc3cae13d94cbc90baa04d2aa64194bb6d519cea32.jpg)
丟IDA裏全是亂碼,發現有gzip的壓縮頭,意識到固件可能分塊了,繼續丟binwalk,能看到壓縮包,-e解出來發現還有四個包。
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b5ba843a03c6e5fe95f5ac8a7f310d8350e1d6b2f3580f071ac20e181bed44593.jpg)
直接把simple.bin丟進IDA開始分析,搜索firmware、fw、update、upgrade等字符串去定位,設備沒有shell,只能靜態分析。
大概如下
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229bb59f3528cdd5a1ee0247e9cf178c850c407982eb81f8c45220c72c3812270c4b.jpg)
定義了一個header的結構體,從固件包裏獲取0x18字節的頭信息存進header裏,從代碼裏知道信息包括偏移,文件大小,長度,checksum,於是結合文件頭來分析
![](http://mdimg.wxwenku.com/getimg/ccdf080c7af7e8a10e9b88444af983934ff4394858c59e8591ebce5f9bb94ed4285738ead5ee43c4c2859d212dcd80e7.jpg)
先計算文件長度
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b81eb3ee113704884bd560f6366a5a873bd98c0716c28ceef833e5698b1f5f07f.jpg)
發現頭部有8CDEED倒序出現,確定了文件長度的存放位置
發現文件長度下面還有個8CDE69,與文件長度十分相似,做個差0x8CDEED – 0x8CDE69 = 0x84
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229bd27c63f605736380ad8d412ca50ba78a2887c12de241ef02960d9cdb1a2c0264.jpg)
於是猜測此為偏移量(header長度),文件總長度,文件數據長度,文件頭長度
![](http://mdimg.wxwenku.com/getimg/ccdf080c7af7e8a10e9b88444af983935a24ebea45fb81a87e44dbe44f1e99f92df62d8cacef023bd838de8f418e2bc4.jpg)
現在開始計算checksum,由於checksum的方法比較多,甚至有可能自己設計,所以得根據代碼去分析,定位到代碼
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b752348d3eaa244fcd536760271335f6103eabdf9218bf085dbc16bbdbf1469f5.jpg)
邏輯比較簡單,單純的將DATA每位相加,最後獲取一個總和。
可以用工具粗略判斷一下
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4bc8c5e16ef8f97d5ec74dceeec456f502788298d3746868abd8d0c5ec60fe4826.jpg)
也可以自己寫腳本驗證
![](http://mdimg.wxwenku.com/getimg/ccdf080c7af7e8a10e9b88444af98393e92cd54d42f44ba83cda7415b648360d78c8362d2c5939a066247946776c6a99.jpg)
繼續分析代碼,發現頭最開始的四個字節代表的是這個塊的標識,決定這是什麼固件,走什麼樣的解析
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b630b9d69ba7313856ea227adcd792c2406602eaea00fbc0bded0cfbb11df10c8.jpg)
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229b73f182c6b99f2ef237a7fd8926ed8cff7d572381536a857cac90ac5c6e2bf4d0.jpg)
有明文意義的可以當做設備和固件型號,也有把廠商或者是工具的標籤寫在頭裏的。
現在包頭還有兩個四位的信息意義未知
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229b9015aa43572230eb7b0d95424d5d035c717b16fb5595dc9beadbd7f4cef35551.jpg)
跟着邏輯找沒有找到關於這兩個地方的代碼,可能需要一點猜測。
看到gzip包有字段和他比較相似,
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4ba16d1eea3943329830ffeccd7b4f3c5ba14e84d50d834aa82402f6bd24814d0b.jpg)
看了下gzip的文件結構,發現這是時間戳,那麼這個地方就大概率是時間戳了。
最後一個地方,發現沒有對header進行校檢的操作,猜測有可能是對header進行校檢,用工具試了試
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229b827478a98feda1b3e2a0221e5b5a63cfde228d5a479d7f3bb259cedfefb353d3.jpg)
到這裏基本是分析完了,要注意的是他採取的是多個header校檢的方式,最外面的header校檢通過了以後,才開始校檢data的header,這個過程十分耗時,即使採用了最簡單的校檢和
格式如下
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4ba9253e4d21bef38b3a586accecb6671b913fcf2fb460fb561d50735cd2d2768a.jpg)
![](http://mdimg.wxwenku.com/getimg/ccdf080c7af7e8a10e9b88444af983937806564429a6217d096df0b6b0ba97bff6c03c0279b759de2a6bd40c7db36d04.jpg)
還遇到點小問題,直接用系統的gzip沒法還原壓縮包,得設置個壓縮等級,最後用python的Gzip函數,compresslevel參數0-9一個一個試過去,發現6壓縮出來的包與目標一致
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b8505e07b8958de0a03672d9cd4d9b0cc3d0ccd713e5cd93a532f855f7b8591c7.jpg)
每次改包+上傳至少得三四十分鐘,十分磨人,放兩張對比圖
原來的報錯頁面
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b10d72747df6e3324ba8a480cb05170186bb79bbd07825a4b11fd735a5912f8ba.jpg)
改過的報錯頁面
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b288a503f7baf17bf5fb0f93979df5bb3fd524de61ab6aec5daf722b1947acb76.jpg)
到此分析完畢。