何不食肉糜?
[
2018年1月25日 • 在bugbounty 、RCE 、Shell、LFD 、XSS 、XXE 、SSH
這篇博文是關於我的第一篇 RCE shell（或者隨便你想怎麼叫它），是篇我在2017年夏季獲得了一個Bug Bounty(錯誤賞金)計劃。這絕對沒有什麼特別之處，你甚至可能不會學到任何新東西，但如果你這樣做，我很高興我能幫你！我只是覺得這是一種獲得一個盒子的不同方式，特別是在Bug Bounty方面。
偵察總是挺有趣的
使用Sublist3r，Aquatone，Nmap等工具對*.domain.com 範圍內的網域進行定期偵察後，我最終列出了數百個子域。我不知道從哪裡開始，因此我決定使用EyeWitness截取網頁截圖，以便了解哪些目標看起來很脆弱，以便我可以從這些截圖開始破冰。在EyeWitness報告中，有一個應用程序在8080埠上運行，它有一個我從未聽說過的CMS的默認主頁，因此我決定首先查看是那個CMS。通過瀏覽目標，我很快找到了一個登錄頁面，幸運的是，我的默認憑據是 admin：admin。然而，它的管理面板中完全沒有任何東西，沒甚麼有料的訊息，完全沒有，它根本是空的。但我仍然決定將它以“管理面板中的默認憑據”為標題的問題報告給Bug Bounty計劃，幸運的是即使我沒有獲得任何敏感訊息，他們也願意將其作為一個重要的bug進行獎勵。
Jobert的名言
僅僅通過默認主頁的外觀以及它在管理面板中的樣子，我覺得應該還有更多細節在裡面。正如Jobert曾經說過的那樣，如果它看起來很老很脆弱，那很可能就是你想的那樣！我決定看看CMS的網站，看看我能否獲得更多的訊息。這是一個開源軟體，所以我想我會在AWS上啟動一個EC2實例並將它安裝在那裡，以便我可以自己玩。我注意到該服務必須以sudo權限運行，這顯然不是最佳實作方式（稍後請牢記這點）。完成設置後，我做了一個快速的Google搜索，看看能否找到該軟體的任何現有CVE，有趣的是，再也找不到任何東西。所以這意味著很有可能沒有人對此軟體進行安全審查或滲透測試。我知道事實後該秀一波了!
簡潔快速的去發現些甚麼吧
我瀏覽了大約30分鐘到一個小時，以便很好地了解它是如何運作的。在我這樣做的時候，我很快找到了2個XSS; 一個存儲型，一個及時反應型。然後在檢查Burp Suite中的所有請求後，我最終找到了1個LFD和2個XXE。它有很多API終端，所以我查看了他們的API文檔，並很快意識到在該CMS上的每個可能的操作都有不正確的訪問控制。這意味著未經身份驗證的遠程攻擊者可以利用存儲的XSS，LFD和兩個XXE攻擊其自身，甚至無需登錄管理頁面。最重要的是，它也沒有CSRF保護，所以如果攻擊者不想利用這些漏洞，他們也可以很容易地創建一些CSRF攻擊並嘗試讓管理員為他們自動做這件事！
/directory traversal救世界！
此時此刻我已經預見，在這個CMS上成功製造RCE只是一個時間的問題。我只是需要繼續探索，然後我最終絕對會找到一個。我之前發現的一個有趣的終端是我可以更新模板文件。它有趣的點是它用於更新模板的參數。下面這就是它的樣子。 (所有敏感信息已處理)
在成功更新後，回覆將如下所示。
我必須嘗試的下一個邏輯是將路徑更改為其他內容，用以查看是否可以將文件上傳到/config文件夾中。所以我給了它如下路徑:/../../../../../../../../../../../../tmp/test.txt並用This is a test.替換了POST的主體。我得到了與以前的請求相同的Response…太神啦！但是，我接下來該如何確認該文件是否已真正上傳完成了？不要忘記，這個測試是在我自己的伺服器上完成的，所以我可以自己檢查文件是否在那裡，但這太白箱了。我想走黑箱路線並找到另一種方法來確認這件事。於是就請到LFD來拯救世界啦！使用我已經發現的LFD/directory traversal來幫助我檢查確認文件是否完成上傳。而它真的上去了！
沒有RCE，現在該怎麼辦？
好了！現在我知道我們可以上傳文件，而且不僅僅是傳到伺服器上的某些固定位置，我可以將它們上傳到任何我想要的地方，因為服務是以root權限運行。
當然，下一步是嘗試執行我上傳的文件嗎？那麼，事實證明，對我來說實際上是一個問題。該服務在Tomcat中是作為一個war文件進行部署，所以沒有一個真正可以上傳和執行文件的特定路徑。也許如果有別人幫助的話，我可能已經想出如何解決這一點的方法，但由於我不太熟悉又沒人幫助，所以我很不幸的在那個時候無法做任何事情往下深入。這讓我回想起我在OSCP工作的日子。我手邊仍然有我的筆記，所以我翻了翻他們，並藉此獲得了一些想法。我首先上傳了一個bash腳本到cron.hourly資料夾，但使用默認的操作系統配置，但這步棋並沒有成功。假設Bug Bounty計劃具有相同的默認設置，那麼這招很可能也無法成功運作。然後我告訴自己:好吧，我手上有root權限了，為什麼不直接SSH連到盒子裡？
為此，我必須將我的SSH密鑰上傳到伺服器。這很簡單，我只需要相應地配置路徑參數，並將我的SSH密鑰放在POST請求的主體中。
剩下的最後一件事就是嘗試用我新上傳的SSH密鑰登錄。你看看，這不就成功了？
現在我已經完成了我的目標，我決定是時候報告這些錯誤了。我聯繫了CMS的開發團隊，讓他們知道這些漏洞，他們立即回答我是否想加入他們的Slack團隊，以便我們可以更多地討論我的報告。我們通過幾次電話聯繫來澄清幾點，他們讓我在更新發布之前先測試看看他們的新版本。
我還將這些錯誤報告給使用該CMS的Bug Bounty計劃。我顯然沒有在他們的網站上測試任何東西，因為它不符合道德規範，但我確實為我的所有發現提供了一個清晰的PoC，要求他們測試他們的結果。我的所有報告都經過了驗證並被接受，其中也一併包括SSH密鑰的文件上傳的部分。這是我被認可的第一個“RCE”的Bug Bounty計劃！
如有任何問題或意見，請不要猶豫，直接在Twitter上DM我吧~ :)