作者：風起@知道創宇404實驗室
時間：2021年8月9日

前言

    大家好，我是風起，最近一直在做安全研究及Kunyu的開發維護，已經好久沒有寫紅隊攻防相關的文章了，那么近期將帶來 “紅隊實戰攻防技術” 系列的文章。

    當前行業內組織的 “紅藍對抗演習” 在檢驗企業安全的同時也在磨練技術人員的技術水平，在近幾年的演習中可以發現攻防雙方的水準都有了極大的提升，本文將以紅隊的視角去闡述技術思想。與常規的滲透測試相比，紅隊攻防更多的是滲透思想上的差異，而我個人的理解認為 “隱蔽”、“持久化”是最重要的思想，如何做到快速、高效的拿下目標，隱蔽、持久的進一步操作，也正是核心的差異所在。熟悉我的讀者，一定看過之前 “紅隊攻防基礎建設” 相關的文章，本文也會串聯之前知識點靈活的運用到實戰場景下。

    作為本系列的第一篇文章，將以一次公司紅藍對抗實戰演練平臺的滲透，引出一系列的知識點及滲透時的一些小Tips，希望能夠對您有所幫助。

    本文僅做安全研究作用，切勿違法亂紀。

快速打點

    拿到一個目標，我們首先要做的就是快速的對目標進行信息收集。對相關的功能點進行測試、熟悉網站的業務流程，這是非常重要的一個環節。應對不同的滲透場景，可以將這個環節仔細或簡略去做。

    這里建議在打點的時候下掛代理，選擇SSR的負載均衡模式，防止被封禁IP、IP定位到真實位置，尤其是企業專線，例如埃文科技、IPIP對于企業專線的定位非常準確。

    使用Kunyu快速對該站點進行信息收集，可能大家會想空間測繪去做信息收集是否會有一定的不準確性？是的，對于一些新增的資產可能未必會及時更新上去。但是通常對于一些成熟的業務站點，并不會去頻繁的對站點進行變動端口服務等操作，所以在快速打點時這樣的方式無疑大大提高了效率，同時也避免了主動掃描可能造成的影響。

    如上圖，通過 Title 不難判斷出不同端口相關的業務，首先來看第一個。

    Eureka 是 Netflix 開源的一款提供服務注冊和發現的產品，可以與Spring boot構建的微服務很容易的整合起來。這里我們發現該服務直接暴露在公網中可未授權訪問，于是我們快速對其進行信息收集分析。

    但是很遺憾，這些實例所指向的是內網地址且端口不對外開放，但是我們得到了本服務器的內網IP，并且得知是一臺Aliyun IDC服務器。這里讀者們可以留意一下，我們下面會再次迂回到這里。

    繼續看一下6363端口的服務，推薦大家使用Wappalyzer對站點框架信息快速收集，下圖中可以直接通過 Wappalyzer 得知目標環境，當然上面 “小綠葉” 的 ICO 圖標也可以看出是SpringBoot的框架。

    對于SpringBoot框架的站點，我們可以快速FUZZ下未授權端點。

    這里有一個Tips，Spring Boot Actuator 1.x版本默認路由的起始路徑為/，2.x版本則統一以/actuator為其實路徑。通過上圖不難看出目標站點是Spring Boot Actuator 1.x版本。這里造成信息泄露的原因是相關人員沒有更改配置文件，忘記切換環境配置。

    這里我們重點關注env、jolokia、heapdump、trace四個端點即可。

    env 獲取全部環境屬性
    jolokia 獲取全部環境屬性
    heapdump 返回一個GZip壓縮的hprof堆轉儲文件
    trace 提供基本的 HTTP 請求跟蹤信息

    當我們訪問未授權的/env端點的時候，Spring Actuator將會返回一些配置信息，其中不乏一些用戶憑證，但是會將一些含關鍵字(如 password、secret)的屬性用 * 替換以達到脫敏的效果，如下圖。同時也會有一些未進行脫敏的屬性，像本次的目標比較有趣的是它使用了二層加密，致使我們得到這些屬性信息也無法進行直接利用。這個加密以 @ 分隔前面一段像是hash，后面像是base64加密，有熟悉的同學可以留言交流一下。

    前面FUZZ我們得知目標開放了/jolokia端點，我們可以據此進行讀取脫敏數據或GETSHELL獲取權限。

    通過調用 org.springframework.cloud.context.environment.EnvironmentManager 類實例的 getProperty 方法獲取脫敏后的數據，得到的屬性值在返回JSON的value中。如上所說，也是二層加密后的數據。

    可能小伙伴會問，如果恰好沒有開放/jolokia這個端點呢？確實在很多情況下，并不一定都會開放這個端點。所以此時可以關注一下/heapdump，通過下載本端點的文件可獲取到服務器相關堆信息，通過對該文件進行審計也可能獲取到經過脫敏處理的數據，可以使用MemoryAnalyzer或者VisualVM打開該文件，這里經過測試發現我們想獲取到的屬性值都經過了二層加密，所以就不進行審計了，下面貼一張圖。

    根據關鍵字匹配找相關的值就行，考驗眼功的時候到了。

    最后是/trace端點，可以獲取到一些 http 請求包訪問跟蹤信息，有可能在其中發現內網應用系統的一些請求信息詳情；以及有效用戶或管理員的 cookie、jwt token 等信息。

    主要的作用還是幫助我們得到一些用戶的登錄cookie信息，從而登錄到后臺。但是值得注意的是，并不是其中記錄的所有Cookie都可以使用并登錄，因為有一些未經過鑒權之前的請求也會記錄在里頭，這時我們可以通過判斷請求的資源來確認哪些是登陸后進行的。當然如果距離該請求的時間過久，Cookie失效了同樣也不行。

漏洞利用

    那么上面說到通過/jolokia端點可以進行RCE，現在我們轉變戰略，先拿SHELL再進行審計。

    這里我們利用的是jolokia Realm JNDI RCE漏洞，基礎理論知識這里不再贅述，感興趣的同學可以看下面的文章，很詳細的把Spring Boot的各類安全問題都進行了梳理，但是我們這里的利用會有點不同尋常。

    https://github.com/LandGrey/SpringBootVulExploit

   利用條件：

• 目標網站存在 /jolokia 或 /actuator/jolokia 接口
• 目標使用了 jolokia-core 依賴（版本要求暫未知）并且環境中存在相關 MBean
• 目標可以請求攻擊者的服務器（請求可出外網）
• 普通 JNDI 注入受目標 JDK 版本影響，jdk < 6u141/7u131/8u121(RMI)，但相關環境可繞過

   這里如何判斷什么時候用哪一種利用方式其實很簡單，訪問 /jolokia/list 接口，查看是否存在 type=MBeanFactory 和 createJNDIRealm 關鍵詞。其他的利用方式也是同理，去查看相匹配的關鍵字，如果有那么基本就是可用的。

   首先我們跟著上面鏈接所指出的利用方式走一遍，但是出現了一個很有意思的問題：marshalsec 接收到了目標請求，并且請求到了 JNDIObject.class，但是沒有正常反彈回來shell，如下圖：

   根據經驗，我首先意識到這種情況下只能是目標主機執行了命令請求到了架設的RMI服務，但是命令執行了卻未成功。那么調轉槍頭，在Github上找另一份可以執行指定命令的EXP，進行高版本JDK的JNDI注入。

   通過which python命令發現目標主機有python2環境，可以提升至完全交互式Shell，防止意外掉線，當然這里一定要注意，像這一類的反彈shell我們一定要用反向代理之類的手段隱匿真實VPS IP，并對Netcat進行流量加密，隱匿效果如下：

   可以看到顯示的僅是我們的代理地址，并且網絡連接為代理服務器的IP及端口，與實際本地監聽端口不同，而流量加密可以幫助我們執行的命令不會被態感設備捕獲到，這也是紅隊攻防基礎建設的一環，非常重要。

   目標JAVA版本為1.8.0_241，是高于上面所述的普通JNDI注入要求的利用條件，這也解釋了我們剛開始利用失敗的原因。

   這里發現目標主機開放了大量的Web服務以及redis數據庫服務，并且都是以jar包的形式啟動Web服務的，這也就是說，除非我們把jar包下載回來進行反編譯修改添加WebShell并替換重啟原有的Web服務才可以添加WebShell，通常來講為了不破壞原有業務正常運轉，我們是不能進行這種操作的。

   很遺憾redis服務并沒有未授權漏洞，所以我們繼續對jar包下載回來進行反編譯，對源碼進行審計，看一下有沒有一些用戶憑證或者服務配置信息等。

   這里配置的IP均為內網地址，這也對應了我們最開始獲取到的內網IP為當前主機。其中包含了不少內網其他主機的登錄憑證接口管理平臺、消息推送平臺等服務的Toekn，這里發現redis的密碼為XXRedis639020XX 這時，機智的風起哥立馬發現了他的命名規則是根據redis的端口來設置的，其中前后綴不變，僅改變中間的端口號，這里我們直接拿下了當前服務器多個redis數據庫。

   繼續審計，發現了Aliyun的AK/SK。

   至此控制目標多臺云服務器，并且發現均為同一內網下，這時根據之前獲得的其他憑證即可進一步橫向移動，不乏例如：mongodb、Mysql等搭建在其他服務器的數據庫服務憑證。

   這時在當前目標上起一個反向代理，因為實際測試過程中發現，目標SSH服務并不能通過外網直接連接，所以利用這樣的方式進行連接，當然也有一個好處，就是目標上記錄日志的登錄IP為內網本地的，也達到了一些隱匿的效果。

   當然，查看日志也發現了， 另一個登錄的IP為企業專線，這也解釋了，目標服務器的登錄應該是做了安全組限制了登錄SSH服務的網段僅能從其企業內網連接。

   至此，演示結束。

權限維持

   這里因為不準備進一步橫向，所以僅以本地環境講解思路。對于Linux的主機我們在外部打點之后，首先需要做的就是權限維持，其實紅隊演練與APT相似的是核心同樣在于 “持久化” ，我通常習慣留私鑰登錄以及創建高權限用戶，一般創建的用戶名以服務命名非常迷惑，但是通過這么不尋常的權限也一定能看出來端倪。這時不要為了方便而這么做，非常容易暴露，這時可以做一些sudo提權或者SUID文件等操作間接的使用root權限，如下圖(反面例子)：

   當然，紅隊攻防不僅僅是一個人戰斗，所以在拿到shell后可以上線到自己C2上，Linux上線CobaltStrike的方式可以使用CrossC2插件進行，這里僅作安全研究，所以不做此操作。而使用nohup的方式留以持續性的代理的方式也比較容易被發現，所以建議使用frp進行代理，也因為它的可拓展性非常高，通過免殺或修改配置文件等方式可以進行躲避流量監測。

   需要注意的是，一定要對痕跡進行清理。在藍隊處置的過程中，重點關注的對象就是一些登錄、服務日志、進程、端口，新建文件，這也是雷區所在，一定要在這些方面下功夫。尤其是歷史命令，不清理被還原出攻擊路徑的概率非常大，這也會被一步步揪出來。如果能夠順利通過處置人員的排查，那么恭喜你可以安心繼續了，因為在非必要或確認失陷的情況，沒有甲方愿意去隔離當前業務，尤其是對外服務、內部OA、工控系統等，停止業務系統都可能造成不可估量的損失。當然要是一些不重要的業務，也可能直接就給關掉了，雖然不符合規定。

   在進入內網環境下，每一步操作都需要非常的慎重，尤其是涉及端口、進程的操作。因為稍有不慎，被捕獲到異常操作，會引起防守方極大的重視。尤其是多次異常告警的情況下，通常在第一次告警的情況下，藍隊成員未排查出異常操作后會對該主機進行重點關注，如果繼續出現告警，那么極有可能直接進行單機隔離。那么此時在權限掉線又沒有辦法清理痕跡的情況下，不要慌張，去泡杯花茶，這樣涼涼后會比較香。

   對于一些新晉紅隊的同學，風起哥建議首先做好基礎建設，比如免殺、隱匿、工具特征改造、匿名VPS、郵箱、手機號、身份信息等，最好在純凈的虛擬機中進行滲透操作（別擱虛擬機里看什么騰訊視頻）。如果被蜜罐抓到ID，那么基本上被溯源出來的概率就很高了，你可能還在愉快的滲透著，突然告訴你出局了。別驚訝，多看看群，是不是有藍隊兄弟問到你的ID了哈哈哈（除非你叫什么張三、李四、王二麻子這種迷惑的ID）。

   就先講到這里，上面一段全是文字了，想必在讀的同學也懶得看了，這里系列后面的文章再講

后記

   感謝各位讀者的支持，在前一陣發布了Kunyu(坤輿)，也是文章開始時使用的信息收集工具，感興趣的小伙伴可以自行下載使用，是一款非常不錯的被動信息收集工具，風起強烈推薦哦~

   本篇文章，從紅隊的視角剖析了滲透的思路，對一些需要注意的細節進行了著重講解。滲透的過程不是關鍵，重要的是其中的思路，所以本文有一些利用細節都給省略了，僅以輔助去講解，我認為這種結合實際的講解是非常必要的，如果僅僅只去講思路，誰會去聽？嘿嘿，除非特別棒，要不我是不看的。我覺得自己是一個比較實在的人，有一說一的那種，所以也很喜歡去做一些分享，或許也是希望更多的同學能夠去做我想做的，間接的彌補我的遺憾吧。

   最后，祝各位心想事成，美夢成真！

Community

   有想要認識一下，或者交流技術的同學，可以通過以下方式聯系作者:

參考鏈接

   https://github.com/knownsec/Kunyu/    https://blog.csdn.net/weixin_40418457/article/details/116424252    https://github.com/LandGrey/SpringBootVulExploit#0x05jolokia-realm-jndi-rce

本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1666/