針對某國際信息通信公司從前期探測到內網提權的一次成功漏洞測試

本文記錄的是作者針對某國際大型信通公司進行的一次漏洞測試,測試過程中,作者通過敏感信息泄露、錯誤配置、RCE等多種線索組合,最終成功實現了內網應用系統提權,可獲取到目標公司內網系統的相關資料和應用數據,漏洞提交后收獲了$9000的獎勵。作為招式的分享學習,我們一起來看看。

本文作者為印度尼西亞安全專家YoKo Kho,漏洞眾測平臺Bugcrowd MVP,具備12多年行業的資深信息安全Web漏洞挖掘和滲透測試經驗, 擁有OSCP、SISE(iOS Application Security Expert)、道德黑客CEH等多項技能認證。《Bug Hunting 101》作者。

從Github發起探測偵察

前期,我已經收集了目標公司將近數千的子域名,但有了這些東西,我卻有點無從下手,于是乎我只有從原始的目標公司個人信息收集入手。我嘗試從Github上去發現一些目標公司開發人員留下的蛛絲馬跡,這不這個視頻-Github Recon and Sensitive Data Exposure(從Github平臺探測發現敏感數據)給了我一些啟發。

其中主要講述的是如何從Github被上傳代碼庫中發現憑據類敏感信息,然后去驗證受影響公司的相關服務,測試是否有效,但是,從中我也得到另外的信息收集思路。我接下來做的是:

1、收集目標公司泄露在Github上的密碼憑據(不管是否有效),然后嘗試去發現密碼規律,這樣做的原因是從中或許能發現管理員在用戶注冊分配密碼時預先會給定的一些默認密碼,這種思路在后續我們會用到。非常不錯,我幸運地在Github平臺收集到了與目標公司相關的近50個密碼憑據信息:

2、收集目標公司相關的IP地址。這樣做主要有幾種考慮:一是我們可以從一些公開的Github漏洞報告中去發現目標公司相關的IP地址,因為白帽們提交的漏洞報告多少總會包括一些細節分析,才會被眾測平臺接收,雖然有些包含目標系統內部資產信息的漏洞有時候也會存在誤報可能,但是我們可以從這些公開披露的漏洞中去尋找一些IP線索,總結規律,嘗試從中發現一些開發代碼庫或系統信息。這不,我從bugcrowd平臺就發現了自己提交的與目標公司Github相關的5個P1嚴重級漏洞:

二是這樣方便后續我們做內網探測時,可以更快地連接到內部網絡相關的系統資產;三是通過目標公司泄露在Github上的信息,可以間接判斷出目標公司的開發習慣和開發文化,比如我可以通過上述信息在兩三個小時就能弄清其大概的開發框架和內網應用。最后,這樣做也能從代碼審計層面去發現目標公司在用服務的潛在問題。執行了以上幾個前期步驟后,就可以針對目標公司收集到很多的線索信息。

利用Github進行密碼探測

之前那個視頻Github Recon and Sensitive Data Exposure中,涉及到了密碼安全問題,主要是:一些公司內部開發人員在使用類似Github的協同代碼平臺時犯下的錯誤,比如,會把包括相關密碼信息的代碼直接上傳到Github上,這要么是太大意,要么是完全不知道Github有“隱私”功能,那么這種錯誤就有可能被惡意攻擊者發現并利用。對于想要進行內網測試的攻擊者來說,這種開發錯誤還是非常有用的。

接下來,我們需要做的就是登錄我們自己的Github賬號,用以下搜索請求進行搜索:

target.com是目標公司的網站域名,當然“password”字段也可替換成telnet、ftp、ssh、mysql、jdbc、oracle等特定關鍵字。雖然我不太了解Github的查詢機制,但利用這兩個搜索語法我發現了很多有用的東西。

如果你通過上述語法發現某些項目代碼存在密碼泄露,那么,可以繼續深挖,比如可以針對特定代碼庫和特定開發者用戶進行搜索查詢:

或者再找找該開發者的其它代碼庫。如果這些搜索方式都沒啥發現,那么我們可以去找找哪些與當前項目開發者或擁有者存在開發協作關系或互動,然后再針對這個用戶再繼續用上述語法搜索一遍。以下為我總結的Github信息收集(Recon)流程圖:

活用Google Dork搜索語法收集信息

接下來,我嘗試用Google Dork搜索,這里我用到的語法關鍵字是目標公司的一個內部非公開子域名和相關密碼模式,該內部子域名是我在第一階段Github平臺中發現的,當時通過它我又關聯到了好幾個子域名。由于這些子域名無法通過外網訪問到,我猜想這些子域名是目標公司用于開發之用的。

雖然這些子域名是內部域名,但我還是想嘗試看看Google大法的神奇,于是就用以下Google Dork語法進行了搜索:

竟然真的有所發現!從中我發現了目標公司內部域名和服務端相關的大量密碼憑據(如FTP/SSH)和內部IP地址等信息,盡管它們需要從內網才能訪問或利用,但也算有所發現。

通過調整搜索關鍵字,如已知的IP地址、產品應用(如Oracle、MySQL、MSSQL等) 、服務名稱 (FTP, SSH, DB等)和其它登錄鍵值字段(如password、pwd、pass、username、userid等),或與登錄相關的dashboard、cms等內容。

另外,通過Google大法,我還在某些眾測平臺披露的漏洞報告中發現了目標公司相關的4個賬號,在披露漏洞中這4個賬號都可以訪問到顧客數據,而且這些賬號都使用了我在Github中發現的密碼模式。

另外,我還發現了不在測試范圍內的另一超級管理員賬號(super admin),該賬號信息涉及目標公司客戶的多項交易數據,可惜它所屬于的系統并不在于我滲透測試范圍內,為了保密只放出具體漏洞報告示例,賬號信息就不截圖了。

通過舊版本Atlassian Crowd應用發現未授權RCE漏洞

手上有了一堆內網信息和其密碼配置模式,但還缺少一個有效的內網訪問渠道。為此,我又想從其子域名中發現更多線索,這次我用到了域名和主機可視化發現工具aquatone。之后我發現了目標公司在用的一個老版本服務端,從其顯示線索中來看,只有一些帶有類似 1st words、2nd words、3rd words和crowd關鍵字的可點擊鏈接,其中的“crowd”引起了我的注意,于是我點擊了“crowd”的關鍵字鏈接,然后它跳轉到了一個Atlassian Crowd應用的子域名網站,從中注意到是2017年的版本。

面對該Atlassian Crowd應用,我想有三種可利用方式:

可測試一些用過的賬戶密碼;

可測試發現未修復的補丁;

可測試發現配置型漏洞。

當然,首先可用Google來搜索其漏洞利用方式:

經過一番查找,我發現了該版本的Atlassian Crowd存在CVE-2019-11580漏洞,之后就是看看該漏洞是否存在公開的利用代碼(exploit),然后我在Github中發現了這個遠程代碼執行(RCE)的exploit:

接下來的就是調試當前Atlassian Crowd應用是否存在該漏洞了。可以在其/admin/路徑下的上傳操作端uploadplugin.action點擊查看,如果當前Atlassian Crowd應用回顯了一個錯誤消息“HTTP Status 400 – Requires POST” ,那么這種情況說明它是存在該RCE漏洞的,也就是說其uploadplugin插件可以被未授權利用。

RCE代碼執行

現在,我們從https://github.com/jas502n/CVE-2019-11580下載漏洞利用代碼CVE-2019-11580.py,以當前Atlassian Crowd應用為目標,它確實存在CVE-2019-11580漏洞,并反彈回了一個webshell,如下:

接著,就可以通過瀏覽器瀏覽http://xx.xx.xx.xx/crowd/plugins/servlet/exp?cmd=command_here,訪問到這個webshell了,當然其中的command_here可以替換成其它系統命令。如下:

所以,總結來看,該漏洞利用有三個好處:

1、無需任何用戶賬戶密碼;

2、RCE是以root身份執行的;

3、該Atlassian Crowd應用無任何安全防護。

但這還不夠,我們需要一個能與目標系統執行交互的Webshell!

這里,我的想法是通過我的Attacker主機,實現對目標應用系統的操控交互。通常我用的是PentestMonkey上提供的反彈Shell,但可惜的是,其中的交互命令在與我的Attacker主機連接執行時沒有任何回連顯示,很可能是目標Web應用過濾了如> & 以及‘ “這些特殊字符。

為此,我只有在我的Attacker主機放置了一個回連python腳本reverse.py,然后通過之前的RCE命令迫使目標Web應用來對它執行下載,然后再通過我的Attacker主機連接它,實現控制。具體的python回連腳本reverse.py如下:

目標Web應用從我的Attacker主機中下載python回連腳本reverse.py:

就這樣,我們就向目標Web應用系統中植入了一個反彈腳本,之后,需要對該腳本文件進行chmod權限修改以便我們能訪問執行,如可以把它修改為700:

目標Web應用下載了reverse.py后,我們這邊的Attacker主機需要設置一個監聽端口:

然后,用之前的RCE shell使目標Web應用執行腳本reverse.py。但是,這還不算真正意義上的交互shell,如果把它設置為偽終端方式就更好了,所以,可以在終端窗口中執行以下python命令實現腳本的偽終端顯示:

到此,我們就獲得了目標Web應用系統的一個控制shell:通過運行reverse.py,我們就能無障礙地去連接目標Web應用系統中的數據庫或其它運行服務了:

內部系統探測

這里我們獲得的RCE,一個有利因素就是該服務器位于目標公司的內部網絡中,當在上述交互webshell是去ping一些目標公司的公開系統時,返回響應中得到的是一些內部IP地址。也就是說,我們在這個全球知名大型信息通信技術公司的內部網絡系統中實現了據點潛伏。之前階段我們收集獲得的大量內部網絡信息,在這里就可派上用場了。但是,為了不造成嚴重影響破壞,不能再深入了,就點到為止吧。

聲明:以上主要展示前期信息收集對后期滲透測試的重要性,最終說明問題即可收手,另外這些測試都是在允許授權之內開展的。

最終,盡管發現的該漏洞不在眾測范圍之內(out-scope),但確實是一次奇妙的滲透之旅。能以信息收集、目標分析和線索映證測試的方式,從知名信通公司的外部網絡中打到內部系統,并實現RCE,已經非常不簡單了。就像我們白帽平時開玩笑說的“要在漏洞測試中發現RCE漏洞,簡單就是天方夜譚”。之后我及時上報了該漏洞,并收到目標公司的快速響應。

連接內部Crowd應用數據庫

上述因為目標公司部署有Atlassian Crowd應用的系統存在漏洞,導致了最終我的RCE。那或許有人會問,能不能嘗試登錄其它的Atlassian Crowd應用或相關數據庫呢?

我們也來看看。經測試發現,為配合Atlassian Crowd的使用,目標公司在該服務器上也安裝了Atlassian協同辦公組件Confluence,而我對Atlassian Crowd和Atlassian Confluence的協同工作機制根本不懂,但我在netstat命令下觀察到了數據庫連接,所以我想其中肯定涉及到一些密碼信息的存儲。經過對Atlassian Confluence的研究分析,我發現其密碼信息存儲在<confluence_home>/confluence.cfg.xml文件中。

使用locate命令,我在目標系統中發現了confluence.cfg.xml文件,更高興的是,其中的密碼信息完全是明文:

就這樣,利用其中的密碼信息,我成功登錄到了其相關數據庫:

登錄了上述Crowd數據庫之后,我就在想能不能把這個登錄密碼進行修改,換成我們自己的呢?我覺得應該是可行的,因為Atlassian在官方文檔里有密碼替換更改的說明,在如下介紹中,我們可以用哈希過的字符串去替換管理員原來的密碼。

由于這是一個漏洞測試項目,因為沒有密碼修改授權,所以我們不能擅自進行這種密碼替換更改。但如果在真實的攻擊場景下,攻擊者完全可以實現這種操作,對系統造成影響。那如果不能修改替換密碼,我們可以選擇創建一個新賬戶的方法來測試。經過查找發現,只要知道管理員賬號密碼,就可以通過REST請求方式來創建Atlassian Crowd的新賬戶:

上述操作的請求格式如下:

your_new_user_here = 將要創建的賬戶名

crowd_administrator_username_here = Crowd的管理員名稱

crowd_administrator_password_here = Crowd的管理員密碼

your@email_here.tld = 將要創建賬戶的綁定郵箱

your_new_user_password_here =將要創建賬戶的密碼

之后,進行賬戶激活,我們就可成功創建一個新的Crowd賬戶:

然后進行登錄:

經驗總結

1、前期的信息收集(Recon)至關重要,通過其我們可以了解目標應用的API工作機制和開發環境等因素。在此借用大牛@Mongobug和@NahamSec對Recon的原話:

“前期信息收集(Recon)不僅可以發現目標系統的資產環境和過期版本信息,還可以掌握相關的應用架構,并獲取到一些很難探測到的功能特性。因此,成功的測試需要在前期信息收集和實際滲透過程中保持一種平衡。”

2、不要丟掉任何你搜集到的數據和信息,說不定在之后的測試中可以發揮作用。該次測試中,我就是綜合利用了前期收集的有用線索,最終成功在后續階段實現了突破驗證了RCE漏洞,收獲了$9,000的獎勵;

3、享受你的每次漏洞測試或滲透測試活動,不要太過于看重賞金(Bounty)。盡量去測試那些合法或官方的項目,多動手多思考多學習,這樣才能快速地提高你的測試技能,擴展你的知識面;

4、可以多參與一些官方的漏洞責任披露項目,從中好好練手,儲備經驗;

5、高手和大牛都不是天生的,他們曾經也是菜鳥。

NOTE:詳細技術報告,請點此下載PDF版本。

【via@freebuf.com