天融信防火墻密碼恢復手記
天融信防火墻密碼恢復手記
公司在用的一款天融信防火墻,密碼意外遺失,無法登陸管理平臺。雖然防火墻可以正常工作,但卻無法修改配置,不能根增加和刪除訪問列表中的IP地址,不能調整訪問策略。防火墻默認僅開通https web管理界面,未開啟telnet、ssh等其他管理通道。下面是學習啦小編跟大家分享的是天融信防火墻密碼恢復手記,歡迎大家來閱讀學習。
天融信防火墻密碼恢復手記
聯(lián)系天融信廠家尋求技術支持,被告知必須返廠更換芯片,費用大約在2000元左右(網(wǎng)上搜了一下,幾乎所有密碼遺失的客戶最終都只能選擇返廠)。公司用于該網(wǎng)絡聯(lián)網(wǎng)的僅此一臺防火墻設備,終端數(shù)量在500以上,無其他硬件備份方案。因用戶眾多,管理要求細致,防火墻配置非常復雜,保存的配置文件也不是最新的。若返廠維修的話,則無法找到完備的替代方案。
于是決定先自己想辦法,開啟密碼恢復之旅。Go!
猜測密碼,自動驗證
首先想到的是根據(jù)可能的密碼規(guī)則和常用組合,構造一個密碼字典,通過編寫簡單的python腳本進行登錄驗證。萬一不行的話,就窮舉來嘗試暴力破解。
可是開始跑腳本的時候發(fā)現(xiàn)想法實在太天真了,存在兩個致命的問題:
防火墻白天負荷過重,Web響應非常慢。有時候一個請求可能在半分鐘以上。
Web管理平臺有登錄次數(shù)限制,大約6次密碼錯誤以后,就會鎖定賬號一段時間。
在嘗試了幾十個最可能出現(xiàn)的密碼組合后,徹底放棄了這條捷徑。
看來偷懶是不成了,必須得動真格的。
搜尋漏洞,獲取控制權
nmap掃描發(fā)現(xiàn)防火墻只開通了https端口。不是專業(yè)的安全研究人員,只能在網(wǎng)上搜索該款防火墻的漏洞資料,不(suo)幸的是,還真發(fā)現(xiàn)了不少。
找到的第一篇文章 《看我如何在2小時內(nèi)控制100+天融信安全設備的》 提到了Heartbleed漏洞,卻未對漏洞利用方式做過多解釋。需要更多學習資料,根據(jù)這個方向繼續(xù)搜索,又找到了一些文章:
NSA Equation Group泄露的天融信產(chǎn)品漏洞分析(一)
天融信率先發(fā)布BASH爆出高危漏洞規(guī)則庫
天融信防火墻openssl漏洞可能導致信息泄漏
天融信防火墻關于“方程式組織”漏洞處置公告
其中,NSA Equation Group那篇文章信息量最高,對漏洞的特征和產(chǎn)生的原因分析的非常透徹,利用方式也做了簡要說明。按照文章的提示,用Brup進行Eligible Candidate漏洞測試(打算用Postman,但因chrome的https證書問題放棄),漏洞果然還在!
懷著激動的心情,嘗試了 ls -la />/www/htdocs/1、find / -type f>/www/htdocs/1 等指令,對防火墻文件系統(tǒng)的目錄結構進行初步了解,也看到了配置文件存放的位置。執(zhí)行cp /tos/conf/config>/www/htdocs/1,把配置文件down下來一看,果然是新鮮的味道。
啟動telnetd服務并嘗試連接,報錯,估計是沒有加特定啟動參數(shù)的緣故,沒做深入研究??磥頃簳r還是只能通過https漏洞方式跑命令了。
隨著執(zhí)行命令次數(shù)越來越多,Brup構造請求的方式效率太低,于是寫了簡單的Python函數(shù)在IPython下面跑,終覺得靈活性不夠。最后決定采用HTTPie命令行的方式發(fā)送https請求(curl沒有httpie方便),后續(xù)所有命令都通過這種方式交互。
1 $ http --verify=no https://x.x.x.x/cgi/maincgi.cgi 'cookie: session_id=x`ls -la /tmp>/www/htdocs/1`'
文件上傳,執(zhí)行腳本文件
之前都是一次請求執(zhí)行一條命令,效率太低,也存在諸多限制。最好的方式是上傳一個sh腳本在防火墻上執(zhí)行,這就需要以某種方式傳送文件到防火墻上去。
另一方面,根據(jù)漏洞名稱和Equation Group搜索到這篇文章:Equation Group泄露文件分析,才注意到這是國際頂尖黑客組織,也是NSA合作的方程式黑客組織(Equation Group),被另一個名為“The ShadowBrokers”的黑客組織攻下了,珍藏的系列高級工具被打包分享。這可是個好東西!趕緊下載解密,找到ELCA的漏洞利用代碼,運行后卻發(fā)現(xiàn)沒有如逾期般的啟動nopen遠程管理軟件,原因未知,頗有些失望。不過在py源碼中看到了文件上傳的方式,其實就是利用了cgi文件上傳處理方式,它每次會在/tmp目錄下生成一個cgi*的臨時文件。ELCA利用代碼的流程是連續(xù)執(zhí)行多次指令,第一次 rm /tmp/cgi*清理tmp目錄,接著post上傳文件同時復制保存一份cp /t*/cg* /tmp/.a,再加執(zhí)行權限chmod +x /tmp/.a,最后執(zhí)行 /tmp/.a。
當然,代碼并沒有直接上傳一個可執(zhí)行文件,而是巧妙(恕見識少,我知道*nix下經(jīng)常這樣干)的將需要的多個文件用tar打包后,附到sh腳本的最后。在sh腳本中用dd命令將tar包copy出來再解壓運行。下面是工具中stage.sh的部分代碼:
文件tar打包的Python代碼片段:
就我的需求而言,只是上傳腳本執(zhí)行,就不用做得那么復雜了。簡單的post我的sh腳本,同時執(zhí)行sh /tmp/cgi*。前提是我的sh腳本中都做了清理工作rm /tmp/cgi*。
1 http --verify=no -b -f POST https://x.x.x.x/cgi/maincgi.cgi 'Cookie: session_id=x`sh /t*/cg*`' a@test.sh; http --verify=no https://x.x.x.x/1
HTTPie可以用 uploadfilename@localfilename 的方式很方便的實現(xiàn)文件上傳。之所以兩條指令在一行是為了方便查看前一個腳本的輸出。
123456789101112 #!/bin/sh# 清除/tmp/cgi*,防止干擾下次運行rm -f /t*/cgi* echo =============================== >/www/htdocs/1date >>/www/htdocs/1 echo "***************" >>/www/htdocs/1cd /tmpps>>/www/htdocs/1netstat -nltp >>/www/htdocs/1ls -la /tos/etc /data/auth/db /tmp >>/www/htdocs/1
上面的示例腳本就可以一次進行多種操作,獲取進程信息、網(wǎng)絡連接情況、目錄文件等多種信息,大幅減少交互次數(shù)提高效率。
逆向分析,尋找密碼
做了很多準備工作,找到了比較便捷的腳本執(zhí)行方式。而且根據(jù)ps結果來看,指令是以root權限運行的。接下來要開始干正事了,tar cf /home/htdocs/1 / 打包文件系統(tǒng),down下來準備逆向分析。因為web登錄入口指向maincgi.cgi,就從它開始。
逆向分析的過程相當繁雜、漫長、枯燥乏味,具有相當?shù)奶魬?zhàn)性,所以需要堅定的毅力和不時涌現(xiàn)的靈感。無數(shù)次調整思路和方向,無數(shù)次尋找新的突破口。
我現(xiàn)在也記不清當初分析時的前因后果,就把一些分析的結果整理下,做一個簡單的分享。
入口 maincgi.cgi
maincgi.cgi 位于 /www/cgi/ 目錄下。用IDA進行逆向分析。
根據(jù)登錄form提交的 username 和 passwd 在string窗口搜索,x跟蹤調用情況分析,最終來到 000403D4 函數(shù)內(nèi)。
下面是更容易理解的C偽代碼(我開始分析的時候沒找到可用的hexrays,這是事后撰寫此文時找到的。:-( 工欲善其事必先利其器啊!):
可以看到,username和passwd參數(shù)都原封不動的傳入到login函數(shù),想必沿著這個方向一定能找到密碼保存的地方。
跟進發(fā)現(xiàn)login是import函數(shù),不在maincgi.cgi中實現(xiàn)。為了方便,我把lib和so目錄下所有文件的符號表都進行了分析,結果保存在一個文件中備查。
1 $ nm -D tos/lib/* tos/so/* > symbols.txt
很快發(fā)現(xiàn) login 函數(shù)在 /tos/so/libwebui_tools.so 中實現(xiàn)。
入了RPC的坑
本以為找到 libwebui_tools.so 中的login實現(xiàn),一切皆可水落石出。誰料還是 too young, too naive。
根據(jù)export表很快定位到login函數(shù)的實現(xiàn),開始是TLS連接127.0.0.1:4000,接著是一堆錯誤處理代碼。
其中有一個 gui_send_reqx 函數(shù)的調用參數(shù) CFG_AUTH 引起了我的注意,猜測是一種自定義的類RPC實現(xiàn)。
唉,還是C偽代碼看得清楚啊!再次哭暈在廁所 :-(
既然不是通過本地.so調用,那只有知道到底是誰提供了這個rpc服務,才能找到接下來的路。
好用的netstat
好在我們有執(zhí)行代碼的權限,好在防火墻里面有netstat命令。執(zhí)行netstat -nltp >>/www/htdocs/1 得到下面的結果:
一目了然。原來服務是 tos_configd 提供的呀!被ELCA漏洞利用腳本誤導了,以為是只是一個命令行shell,之前跟過,但沒有細看。這不,還是要回頭找它。
百轉千回
tos_configd 分析過程并非一帆風順。
根據(jù)RPC傳遞的參數(shù)CFG_AUTH作為線索進行追蹤,看到RPC支持多個命令。當命令為CFG_AUTH時,將數(shù)字5寫到參數(shù)傳入的內(nèi)存區(qū)域某個變量中。沒有其他更多的信息,看來只能根據(jù)caller向上一步步追了。
代碼回到rpc的消息處理thread中,經(jīng)過逐步分析,定位到消息處理函數(shù)中。
跟進去,可以看到大致的處理流程。有一個switch過程,case 5后面就是CFG_AUTH的處理代碼。5就是前面第一個過程中設置的變量。topsec_manager_auth函數(shù)用于接管用戶密碼鑒權工作,它是一個import函數(shù),按照前面的方法查到它在 /tos/so/libmanager.so 中實現(xiàn)。
勝利的曙光
libmanager的export表非常簡練,似乎每一個都讓人頗感興趣。
先看看我們的目標函數(shù)topsec_manager_auth:
信息量很大,到這里基本上就看到了勝利的曙光。
首先看到的是用戶名+密碼的MD5,然后傳入到 j_match_manager_name 函數(shù)中進行校驗。這不就是經(jīng)典的用戶名密碼校驗過程嘛(未加salt)。
需要說明一下的是,上圖中看到的username參數(shù)名稱是我綜合各類分析得知內(nèi)容后改名的,并不是想當然,更不是IDA智能更名。username+32是密碼明文,這也是在前面的分析過程中得出的結論。
跟進match_manager_name函數(shù),并沒有立即發(fā)現(xiàn)直觀的密碼文件讀取過程。取而代之的是,內(nèi)存中存在最多500個struct,其中包含了用戶名和MD5值,鑒權過程就是與其一一進行匹配比對。Local_db_dev_node是一個全局buffer,搞清楚它的數(shù)據(jù)來源就找到根源了。
按X查看Local_db_dev_node的reference,還真不少。
第一個read_dev_manager_file就很像,跟進去看一下。
Bingo!就是它了! /tos/etc/Tos_dev_manager_info 其實這個文件之前也注意到,不過沒曾想它居然保存了鑒權信息,而且是用戶名密碼拼接MD5這么簡單!
用hexdump查看之前下載的Tos_dev_manager_info進行驗證,大小104字節(jié),與分析得到的struct大小完全一致。再看用戶名和密碼的位置,和分析Local_db_dev_node結構完全一致。
清除最后的障礙
終于找到密碼保存到文件了,三下五除二,自己設定一個密碼,計算MD5值,修改Tos_dev_manager_info對應的區(qū)域。文件上傳,覆蓋,重啟,等結果……
12 import hashlibprint(hashlib.md5('superman' + '111111').hexdigest())
幾分鐘后,設備起來了,趕緊試一下密碼,錯誤!!!
郁悶,怎么會呢?down下/tos/etc/Tos_dev_manager_info一看,還是老數(shù)據(jù)??磥硎枪ぷ鬟€沒到位。
想起 libmanager 不是有那么多可疑的函數(shù)嗎?挑感興趣的進去看看,比如write_memdata2flash:
對,就它了。一般網(wǎng)絡設備修改配置以后,不都還來一個 wr mem 嗎?估計 /data/auth/db/ 才是最終保存數(shù)據(jù)的地方,/tos/etc可能重啟的時候會重新copy覆蓋。
再重新上傳一次修改好的Tos_dev_manager_info文件,只不過這次同時覆蓋了幾個目錄下的文件。重啟,用設定的密碼登錄,搞定!!!
走過的彎路
當然,我分析過的文件遠不止上面這些,也不是按照本文的思路一步一步走下來,走了不少彎路。憑感覺,或為了尋找新線索,或漫無目的地毯式搜索。除了上面列舉的部分之外,還分析過其他幾個.so文件,跟蹤過上百個函數(shù),多數(shù)與我需要的東西關系并不太大。
逆向分析就是這樣,不可能一帆風順,也沒有既定的方法和思路。就是要有一種執(zhí)著的精神,在不斷的嘗試、糾錯和總結過程中達到目的地。成功后那一刻豁然開朗的成就感一直是我所癡迷的。
關于MD5破解不得不說的事
既然知道了算法,也有了MD5數(shù)據(jù),是不是可以真正的找回當初的密碼呢?
和第一步猜測密碼類似,用python按照一定規(guī)則,生成可能的密碼序列。調用hashlib.md5() 計算hash值與目標進行比對,結果跑了一天沒結果。
想著這種計算密集型的程序,在python和c之間切換太頻繁可能影響效率。又在網(wǎng)上找到一個 Fast MD5 hash implementation in x86 assembly 匯編實現(xiàn)的快速算法,并且根據(jù)實際需求做了一定的優(yōu)化。運行,依然無結果。
不甘心,再到網(wǎng)上搜索資料,發(fā)現(xiàn)人家都用GPU跑字典。好吧,我也找來一個 Hashcat,在 i5 8G內(nèi)存 的iMac 上試跑,的確速度非???。然而,由于密碼長,計算量過大,最終也沒跑出結果,就此作罷。
現(xiàn)在想想,如果沒有密碼長度、規(guī)則等任何信息的話,光憑暴力破解一個非典型密碼,幾乎是 Mission Impossible。
搞定,收工
很久沒寫過長文,也沒發(fā)過技術類文章。上一次可能要追溯到2001年8月的時候,曾以打雞血似的飽滿激情寫過一篇軟件逆向習作。
此次防火墻密碼成功恢復,其漏洞功不可沒。對我而言,又重溫了一把當初年少時對技術的執(zhí)著。
最后,小結一下:
軟件逆向分析是個體力活。
工欲善其事必先利其器。
安全問題無時無刻不在。