作者:Murkf0x
本文為作者投稿,Seebug Paper 期待你的分享,凡經采用即有禮品相送!
投稿郵箱:paper@seebug.org
廠商:Schnelder
涉及產品型號:NetBotz 750
固件版本:v5.2.0
一、固件基本信息
- 設備簡介:
- NetBotz 750用于從網絡機柜到數據中心的性能安全和環保系統監測。從邊緣網絡到數據中心的監測、感應和環境監控 獲取方式:固件可以通過官網直接下載,附件中也包含固件。 固件包文件名:NBRK075x_Build_5.2.0.3061.sedp
- 固件大小:
- 263927026 字節 (251 MiB)
- SHA256:
- E4A38B9ECABA04CDC88368A26C9150DBA7B8A08017F6DC06B4D03FC8F11863A9
- 固件文件分析:
- sedp后綴文件可直接使用zip方式解壓即可獲得相關系統鏡像
二、固件分析
固件包下載到本地后,發現后綴名為sedp,嘗試解壓,發現可以使用zip方式進行解壓

root.img為文件系統鏡像,使用binwalk 進行分析
獲悉,該固件文件系統為 EXT3 可以直接使用 binwalk 解壓

/com 以及 /sun 其中都是 java 的 class 文件 ext-root 為文件系統


通過/etc/issue 確定系統版本(大多數以linux為核心構建的工控固件系統都可以通過該文件確定系統版本)

Poky 說白了就是使用Yocto Project基于linux構建的一個定制系統。(Yocto Project 是一個開源協作項目,它提供了一些模板、工具和方法來支持面向嵌入式產品的自定義 Linux 系統,不管硬件架構是什么。)
查看 /netbotz_app 目錄下文件,發現是WEB服務目錄

先看一下這個根目錄的/start.sh 通常來講這樣的啟動腳本會告訴我們,應用運行過程中依賴有哪些組件。

我們注意到,netbotz 是一個java 應用,使用的數據庫是postgresql,然而/opt/ 這個目錄壓根就沒有,所以有關這個數據庫的配置信息以及數據庫文件到底在哪里,是一個問題。繼續往下分析

由此我們可以判斷出,數據庫開放端口以及用戶名,但數據庫用戶名依然無從知曉。繼續分析其他文件,由于此時關注點集中在數據庫組件上,我們注意到了一個文件 /upgradedb.sh,這是一個用于更新數據庫的腳本。

用戶名和密碼被我們找到了。
繼續分析/webapps/se-netbotz_app/目錄下的WEB服務

通常我們在分析java WEB應用時會先查看相關配置文件/META-INF/META-INF.MF /WEB-INF/web.xml
META-INF 會保存程序入口以及程序版本等相關信息, 每個jar 都會有這個文件夾,里面的 MANIFEST文件 記錄這些信息。
web.xml文件是我們開發Web程序的一項很重要的配置項,里面包含了我們各種各樣的配置信息,比如歡迎頁面,過濾器,監聽器,啟動加載級別等等。在服務器啟動時,第一步便會加載項目的web.xml文件,然后通過其中的各種配置來啟動項目。

探查其他,未發現有效信息。轉而對該應用進行反編譯。Java對包的命名相對來講比較嚴格,通常,包的命名中就包含相關應用的信息。比如

包的命名中包含應用的名字netbotz,說明該包內所含代碼與引用相關,通常來講,不加后綴的包,為應用主程序。
由于程序未被加密,直接使用 JD-gui 加載jar包,找到應用入口類。

在props中也發現了數據庫配置信息

并且,在包的命名中,公認的命名方式是 com/org.公司名.項目名.業務名全小寫,因此我們可以判斷出來jar包中所包含的各項功能的代碼范圍。當然,如果想要快速的審計某個漏洞的話,還需要關鍵詞搜索,來定位相關demo。
比如說,我們可以嘗試搜索一些執行系統命令的關鍵詞

從代碼中可以看出,這是一條被拼接出來的系統命令語句,用于操作ssl證書庫的更新。其中

大概可以被我們操控(密碼需要我們輸入吧。目錄需要我們指定吧)

從上述代碼中可以看得出來,最終被拼接進系統命令的 passwordStr 是 從 password處獲取到,而其中只不過執行了一個方法==String.valueOf)()==,這個方法只是一個數據類型轉換,其作用是強制把其他數據類型轉換成字符串,但這并不會對我們插入想執行的系統命令有所限制,password 則是 changeit這個字符串執行了 toCharArray() 方法得來,但 toCharArry()方法只是一個字符串轉換成一個 Character型的字符數組,并且這里面的字符是原封不動的拿進去的,意思就是說,包含一切字符均轉換成相應的字符數組。,也不會對我們的輸入進行過濾。所以,只需要我們把這個密碼改成一個命令注入語句,就可以實現命令注入。
同理我們找到設備HTTP 代理設置處

這條被拼接的系統命令執行中,proxyUserPassword也是我們可以操控的地方

通過上述代碼,可以發現,ProxyUserPassword除了進行了空值校驗外,也并沒有進行任何過濾,是直接由proxyUser + ":" + proxyPassword + "@"拼接成

而我們可以設置的用戶名和密碼,則是通過 ProxyConfig 類實例化得到

也并沒有限制,所以我們至少可以通過自定義 username 值 來進行拼接執行命令。 當然,在進行命令注入挖掘過程中,如果沒有全局的參數過濾,那基本就是全軍覆沒了,比如

這里執行的網絡參數設置中,deviceName 也沒有任何過濾。在相關應用開發過程中,應慎用系統命令執行,尤其是用戶可控數據的拼接,如果用戶所能控制的數據傳入,使其通過惡意構造執行系統命令,后果不堪設想啊。
PS : 將漏洞反饋廠商后。廠商表示,所傳輸數據通過Rest_Api 進行處理,是進行了相關參數的過濾。但筆者并沒有找到相關證據。廠商也正在對代碼進行分析,也歡迎各位同好進行相關分析。
本文由 Seebug Paper 發布,如需轉載請注明來源。本文地址:http://www.jmbmsq.com/1170/
暫無評論