一次未授權的訪問到獲取系統shell的過程

本文記錄了從一次未授權的訪問到獲取系統shell的滲透測試過程，文中主要闡述了攻擊方法、漏洞成因以及防御思路。在進行攻防過程階段，最重要的工作莫過于信息收集，本文不想記錄對信息收集中的數據反復甄別的過程，而是想對一次重大的發現進行過程記錄，通過對收集的數據進行反復的篩選發現了2375端口，相信很多在做云原生或者做容器化部署的朋友，應該對這個端口不陌生，沒錯這個就是docker swarm。從官方的文檔可以看出swarm是用來管理docker集群的，本次獲取shell權限的過程就與此有著莫大的關系。

起因

有一位運維同學在部署docker swarm的時候，在管理的docker 節點上會開放一個TCP端口2375，綁定在0.0.0.0上，相信很多有經驗的運維大牛應該知道swarm是用來管理docker集群的，應該放在內網才對。但是不知道出于什么原因，他是在公網上的幾臺機器上安裝swarm的，并且2375端口的訪問策略是開放的，所以可以直接訪問，那么這就造成了可以遠程執行docker命令。

漏洞利用過程

當發現2375端口是開放的，所以肯定要訪問一下該服務，發現是可以直接訪問。

現在可以確定存在一個未授權的訪問漏洞，難道滲透測試就此結束了嘛！恐怕也才是開始，既然這個端口可以遠程執行docker指令所以肯定要好好利用一番，首先要看一下所有鏡像。

已經獲取到了鏡像ID，這個在后續的過程中會有利用的，所以先記錄一下，接著查看一下容器內部。

又是簡單的收集了一波信息，現在要做的就是要獲得宿主機的權限了，畢竟現在一直在容器里。首先要做的就是啟動一個容器，掛載宿主機的var/spool/cron/目錄，之后將反彈shell的腳本寫入到/var/spool/cron/root中做一個執行計劃，攻擊機nc -vv -l -p Port進行監聽，這個時候會得到一個反彈的shell。

通過執行命令，我們獲得了宿主機的反彈shell。現在你會發現docker逃逸成功了，拿下了該服務器。

就這樣，我們不僅拿下了服務器，甚至還是獲得了root權限，總體來說還是獲得了不錯的成果。從一次未受權的訪問漏洞到獲取的系統shell，是對一個漏洞的深入挖掘，達到攻擊的目的，其實后果造成的危害還是很大的，但其實修復這個漏洞是比較容易的。企業在信息安全建設中，如果只是修復漏洞，那會變得疲于奔命，所以對這種問題還是要構建完整的防御體系，從未授權的訪問到獲取到系統root權限，需要經過很長的攻擊鏈，如果能及時的阻斷攻擊鏈，也是對漏洞攻擊面的縮小。

防御思路

1.簡單的方法就是對2375端口做網絡訪問控制，如ACL控制，或者訪問規則等；

2.修改docker swarm的認證方式，使用TLS認證，Docker CLI 在發送命令到docker daemon之前，會首先發送它的證書，如果證書是由daemon信任的CA所簽名的，才可以繼續執行。

寫在最后

在企業安全體系的建設過程中，是離不開滲透測試或者說安全攻防的，安全的生命周期鏈路比較長，從安全需求再到安全的持續運營階段，其實滲透測試已經在安全生命周期的末端了，發現漏洞的情況已經是產品的末期。其實還是要在產品的初期，引入安全自動化平臺對產品的安全質量進行閾門控制。并且建設整體的安全架構，及時的阻斷攻擊鏈，把漏洞對環境的影響面降到最低。