寫在前面的話

在這篇文章中，我將跟大家分享我在利用SSM代理通信實現后滲透利用方面所作的一些研究。需要注意的是，我這里指的并不是SSM代理或SSM中的安全漏洞。

考慮到SSM處理身份驗證的方式，如果我們可以訪問EC2實例的IAM憑證，則意味著我們可以攔截EC2消息以及SSM會話。這樣一來，即使是低權限用戶也可以攔截這些通信。

接下來，我們還會解釋為了攻擊者能夠攔截和修改這些通信流量，并完全阻止資源的擁有者訪問EC2實例。此外，這些內容還可以幫助大家更好地了解SSM代理是如何在低級別上運行的。

概念驗證PoC腳本可以點擊【這里】獲取。

[[384139]]

攔截EC2消息

如果你曾經攔截過SSM代理的流量，你就會發現它會不斷地調用ec2messages:GetMessages。默認情況下，代理將持續執行此操作，保持連接打開大約20秒的時間。在這20秒的時間間隔內，代理將會持續監聽消息。如果接收到了消息，比如說某個組件調用了ssm:SendCommand，它將會通過這個打開的連接來接收消息。

我們也可以自行調用ec2messages:GetMessages，這將允許我們攔截到傳入實例的EC2消息。不過這里有個小問題，SSM代理將大約每20秒就會建立一次這種連接。如果同時存在兩個有競爭關系的連接呢?AWS只會響應最新建立的連接。因此，如果SSM代理先運行，我們就可以在它上面創建一個新連接并實現消息的攔截了。

我們可以通過反復打開新的連接來確保我們擁有最新的連接，通過這種方法，我們可以確保我們的連接始終是最新的，并實現EC2消息的攔截。為了測試我的想法，我創建了一個簡單的PoC，它監聽send-command消息并竊取其中的命令內容。

這種方式的另一個好處就在于，我們可以回復任意一個我們想要回復的響應。比如說，我們可以提供一個“Success”并返回一條有意思的消息。下面給出的是一個PoC樣例：

攔截SSM會話

EC2消息的實現相對簡單，你可以檢查你是否接收到了消息，并根據情況執行操作或予以響應。不幸的是，SSM會話相對來說就比較復雜了，其中會涉及到多個Web套接字連接和一個獨特的二進制協議等等。

SSM代理啟動后不久，它將創建一個回連至AWS的WebSocket連接。這條連接將被作為控制信道來使用，主要負責監聽連接請求。當用戶嘗試啟動SSM會話(ssm:StartSession)時，控制信道將會接收請求并生成數據信道。而這條數據信道主要負責傳輸用戶和EC2實例之間的實際通信消息。

負責處理兩端消息傳輸的是一個專用的二進制協議。幸運的是，我們是可以獲取到SSM代理的【源代碼】的，那么我們要做的就是檢查其源代碼以及定義的規范就可以了。

從攻擊者的角度來看，攔截SSM會話比攔截EC2消息要更加可靠。這是因為控制信道的存活壽命要更長，就跟EC2消息一樣，AWS只與最新的信道進行通信。這樣一來，我們就可以創建自己的控制信道并監聽傳入的會話了。通過使用SSM代理的源代碼，我們能夠以二進制格式制作消息(如果你查看了我給的PoC代碼的話，你就會發現我剛剛翻譯了Go To Python)，并于會話進行交互。

那么現在，我們所能做到的事情如下圖所示：

或者說，我們也可以做一些其他的事情，比如竊取命令并提供我們自己的輸出，或者嘗試去截獲并讀取發送至設備的用戶憑證等等。