沒有RCE?那就直接SSH進去啊!

Translated by NotSurprised
Apr 18, 2018

何不食肉糜?

[My Profile Photo

Jasmin Landry, a.k.a JR0ch17

2018年1月25日 • 在bugbounty RCE ShellLFD XSS XXE SSH

這篇博文是關於我的第一篇 RCE shell(或者隨便你想怎麼叫它),是篇我在2017年夏季獲得了一個Bug Bounty(錯誤賞金)計劃。這絕對沒有什麼特別之處,你甚至可能不會學到任何新東西,但如果你這樣做,我很高興我能幫你!我只是覺得這是一種獲得一個盒子的不同方式,特別是在Bug Bounty方面。

偵察總是挺有趣的

使用Sublist3rAquatoneNmap等工具對*.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我吧~ :)