寫在前面的話

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

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

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

概念驗(yàn)證PoC腳本可以點(diǎn)擊【這里】獲取。

[[384139]]

攔截EC2消息

如果你曾經(jīng)攔截過SSM代理的流量，你就會發(fā)現(xiàn)它會不斷地調(diào)用ec2messages:GetMessages。默認(rèn)情況下，代理將持續(xù)執(zhí)行此操作，保持連接打開大約20秒的時(shí)間。在這20秒的時(shí)間間隔內(nèi)，代理將會持續(xù)監(jiān)聽消息。如果接收到了消息，比如說某個(gè)組件調(diào)用了ssm:SendCommand，它將會通過這個(gè)打開的連接來接收消息。

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

我們可以通過反復(fù)打開新的連接來確保我們擁有最新的連接，通過這種方法，我們可以確保我們的連接始終是最新的，并實(shí)現(xiàn)EC2消息的攔截。為了測試我的想法，我創(chuàng)建了一個(gè)簡單的PoC，它監(jiān)聽send-command消息并竊取其中的命令內(nèi)容。

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

攔截SSM會話

EC2消息的實(shí)現(xiàn)相對簡單，你可以檢查你是否接收到了消息，并根據(jù)情況執(zhí)行操作或予以響應(yīng)。不幸的是，SSM會話相對來說就比較復(fù)雜了，其中會涉及到多個(gè)Web套接字連接和一個(gè)獨(dú)特的二進(jìn)制協(xié)議等等。

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

負(fù)責(zé)處理兩端消息傳輸?shù)氖且粋€(gè)專用的二進(jìn)制協(xié)議。幸運(yùn)的是，我們是可以獲取到SSM代理的【源代碼】的，那么我們要做的就是檢查其源代碼以及定義的規(guī)范就可以了。

從攻擊者的角度來看，攔截SSM會話比攔截EC2消息要更加可靠。這是因?yàn)榭刂菩诺赖拇婊顗勖L，就跟EC2消息一樣，AWS只與最新的信道進(jìn)行通信。這樣一來，我們就可以創(chuàng)建自己的控制信道并監(jiān)聽傳入的會話了。通過使用SSM代理的源代碼，我們能夠以二進(jìn)制格式制作消息(如果你查看了我給的PoC代碼的話，你就會發(fā)現(xiàn)我剛剛翻譯了Go To Python)，并于會話進(jìn)行交互。

那么現(xiàn)在，我們所能做到的事情如下圖所示：

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