01、概述
阿基米德曾經說過:給我一個支點,我就能撬起地球。”那么,在漏洞挖掘的過程中,如果給你一個支點(pivot),能否快速發掘更多漏洞呢?上一篇分析了研華公司(Advantech)HMI/SCADA軟件AdvantechWebAccess的一個遠程代碼執行漏洞(傳送門:https://www.freebuf.com/vuls/205987.html),這一篇嘗試以該漏洞為支點,發掘更多高危漏洞。
從ZDI上關注到Mat_Powell大神提交了大量CVE,其中很多漏洞具有相似性,暫且對比看:CVE-2019-6550、CVE-2018-7499兩個漏洞:
漏洞對應的相關組件分別為:bwthinfl.exe、bwaccrts.exe、upandpr.exe;入口分支均為0×2711 IOCTL;漏洞描述幾乎完全相同,漏洞成因均為:未對用戶輸入的數據做合適驗證從而導致棧溢出。暫且我們可以推測次兩個漏洞為同類漏洞,接下來的問題是造成漏洞的相關函數是什么呢?
02、漏洞分析
仔細查看上述第三張截圖,漏洞詳情中似乎已“道破天機”,“罪魁禍首”是大家熟知的scanf函數?接下來唯有上IDA對此三個組件逆向求證了:
果然三個組件中均使用了sscanf函數,而這個函數是微軟在安全編程中禁止使用的函數之一:https://docs.microsoft.com/en-us/previous-versions/bb288454(v=msdn.10)
03、PoC改造
下載AdvantechWebAccess V.8.0軟件,在Win7x64虛擬機中安裝,查看端口開放情況,確認軟件運行正常:
以組件upandpr.exe為例進行PoC改造和調試,上一篇中分析到最終代碼執行通過lpCommandLine參數傳入一個文件名或路徑給CreateProcessA函數(于是可以指向任何文件了),則可以通過合理構造參數:將執行的目標指向upandpr.exe組件并執行scanf函數,PoC改造部分如下所示:
由于整個漏洞利用執行(函數調用)的基本流程是webvrpcs.exe->drawsrv.dll->upandpr.exe(sscanf),當用戶提供的輸入數據覆蓋了堆棧,函數返回時候將發生異常。上調試器進行調試運行吧,目標當然是upandpr.exe(sscanf),此時涉及一個問題是:當upandpr.exe啟動、發生異常時,調試器自動被加載,可參考:https://www.52pojie.cn/thread-196194-1-1.html,進行一番設置之后,便可觀察改造后的PoC能否能夠按照既定的思路運行了:
PoC執行后,upandpr.exe被加載,F9繼續執行后異常發生,如下圖所示:
接下來是最熟悉的場景:
進一步IDA查看sscanf函數處偽碼:
可精確推算出覆蓋堆棧需要的junk長度只需0x4D0,再次改造一下PoC進行測試:
可見EIP被精確劫持。那么再下一步,即可繼續根據堆棧情況設計布局shellcode了,對于shellcode編寫一個更有利的消息便是WebAccess軟件的模塊代碼編寫中幾乎未啟用Windows系統的相關安全機制,如ASLR、DEP:
04、總結
從上述分析可知,由軟件的一個漏洞收獲了其他大量漏洞,攻擊面由此進一步擴大,小伙伴們可以借題發揮大量收割CVE啦(不過之前版本的CVE貌似都被Mat大神給收割了)。另外,基本的安全編程的思想對于碼農來說尤為重要,微軟早已禁用函數還是不用為好。