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

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

　　

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

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

　　猜測密碼，自動驗證

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

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

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

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

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

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

　　搜尋漏洞，獲取控制權

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

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

　　NSA Equation Group洩露的天融信產品漏洞分析***一***

　　天融信率先發布BASH爆出高危漏洞規則庫

　　天融信防火牆openssl漏洞可能導致資訊洩漏

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

　　其中，NSA Equation Group那篇文章資訊量最高，對漏洞的特徵和產生的原因分析的非常透徹，利用方式也做了簡要說明。按照文章的提示，用Brup進行Eligible Candidate漏洞測試***打算用Postman，但因chrome的https證書問題放棄***，漏洞果然還在!

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

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

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

　　1 $ http --verify=no '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*。

　　1 http --verify=no -b -f POST 'Cookie: session_id=x`sh /t*/cg*`' [email protected]; http --verify=no

　　HTTPie可以用 uploadfilename@localfilename 的方式很方便的實現檔案上傳。之所以兩條指令在一行是為了方便檢視前一個指令碼的輸出。

　　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

　　上面的示例指令碼就可以一次進行多種操作，獲取程序資訊、網路連線情況、目錄檔案等多種資訊，大幅減少互動次數提高效率。

　　逆向分析，尋找密碼

　　做了很多準備工作，找到了比較便捷的指令碼執行方式。而且根據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目錄下所有檔案的符號表都進行了分析，結果儲存在一個檔案中備查。

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

　　很快發現 login 函式在 /tos/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 得到下面的結果：

 

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

　　百轉千回

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

　　根據RPC傳遞的引數CFG_AUTH作為線索進行追蹤，看到RPC支援多個命令。當命令為CFG_AUTH時，將數字5寫到引數傳入的記憶體區域某個變數中。沒有其他更多的資訊，看來只能根據caller向上一步步追了。

 

　　程式碼回到rpc的訊息處理thread中，經過逐步分析，定位到訊息處理函式中。

 

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

 

　　勝利的曙光

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

 

　　先看看我們的目標函式topsec_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!就是它了! /tos/etc/Tos_dev_manager_info 其實這個檔案之前也注意到，不過沒曾想它居然儲存了鑑權資訊，而且是使用者名稱密碼拼接MD5這麼簡單!

　　用hexdump檢視之前下載的Tos_dev_manager_info進行驗證，大小104位元組，與分析得到的struct大小完全一致。再看使用者名稱和密碼的位置，和分析Local_db_dev_node結構完全一致。

　　清除最後的障礙

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

　　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檔案，跟蹤過上百個函式，多數與我需要的東西關係並不太大。

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

　　關於MD5破解不得不說的事

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

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

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

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

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

　　搞定，收工

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

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

　　最後，小結一下：

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

　　工欲善其事必先利其器。

　　安全問題無時無刻不在。