標題：利用JSON 語法繞過WAF 對SQL 注入攻擊的檢測

JSON 語法自2012 年開始作為新特性被各類SQL 數據庫支持，目前所有主流數據庫都已支持JSON 語法，但目前的主流WAF並沒有做相應跟進，從而可以被繞過。

Team82開發了一種通用的繞過行業領先的web應用程序防火牆(WAF)的方法。 攻擊技術包括將JSON語法附加到WAF無法解析的SQL注入有效負載。

主要的WAF供應商在他們的產品中缺乏JSON支持，儘管大多數數據庫引擎已經支持了十年。 大多數WAF可以很容易地檢測到SQLi攻擊，但是將JSON前置SQL語法使WAF無法檢測到這些攻擊。

使用這種技術的攻擊者將能夠繞過WAF的保護，並使用其他漏洞來竊取數據。

簡介Web應用防火牆(WAF)旨在保護基於Web的應用程序和API免受惡意外部HTTPs流量的影響，尤其是跨站腳本和SQL注入攻擊，這些攻擊危險似乎還未解除。

WAF的引入在很大程度上是為了應對這些編碼錯誤。 WAF現在是保護存儲在數據庫中的組織信息的關鍵防線，這些信息可以通過web應用程序訪問。 WAF也越來越多地用於保護基於雲的管理平台，這些管理平台監督連接的嵌入式設備，如路由器和接入點。

能夠繞過WAF的流量掃描和攔截功能的攻擊者通常可以直接訪問敏感的業務和客戶信息。值得慶幸的是，這樣的繞過並不常見，而且針對特定供應商的實現是一次性的。

目前，Team82引入了一種攻擊技術，它是業界領先供應商銷售的多個web應用程序防火牆的第一個通用繞過。該繞過適用於五個主要供應商銷售的WAF: Palo Alto, F5, Amazon Web Services, Cloudflare和Imperva。目前，所有受影響的供應商都承認Team82的披露，並實施了修復，將JSON語法支持添加到其產品的SQL檢查過程中。

Team82的技術首先依賴於理解WAF如何識別和標記惡意SQL語法，然後找到WAF看不到的SQL語法。這是JSON。 JSON是一種標準的文件和數據交換格式，通常用於將數據從服務器發送到web應用程序。

在SQL數據庫中引入JSON支持可以追溯到大約10年前。現在的數據庫引擎默認支持JSON語法、基本搜索和修改，以及一系列JSON函數和操作符。雖然JSON支持是數據庫引擎的標準，但WAF卻並非如此。供應商在添加JSON支持方面一直進展緩慢，這使得Team82能夠創建新的SQL注入有效負載，其中包括繞過WAF提供的安全性的JSON。

使用這種新技術的攻擊者可以訪問後端數據庫，並使用額外的漏洞，通過直接訪問服務器或通過雲竊取信息。

這對於已經轉向基於雲的管理和監控系統的運行和物聯網平台尤為重要。 WAF提供了來自云的額外安全性的承諾，能夠繞過這些保護的攻擊者可以廣泛地訪問系統。

Team82在去年開發了這項技術，當時他們正在對Cambium Networks的無線設備管理平台進行不相關的研究，包括其內部或云端銷售的cnMaestro無線網絡管理器。

Cambium Networks無線接入點

Cambium的cnMaestro雲架構允許用戶從雲端遠程配置和控制他們的AP Wi-Fi設備

為了了解平台是如何構建的，以及它的許多內部API和路由，Team82從Cambium的網站下載了cnMaestro內部部署的開放虛擬化格式虛擬機。

Team82了解到cnMaestro是由許多不同的NodeJS後端服務構建的，這些服務處理用戶對特定路由的請求。這些服務都有輕微的混淆，使得研究平台變得困難。為了將每個請求代理到正確的服務，Nginx被用來通過所請求的URL來傳遞請求。

cnMaestro提供了兩種不同的部署類型:

本地部署：創建一個由用戶託管和管理的專用cnMaestro服務器。

雲部署：位於Cambium Networks雲基礎設施上的cnMaestro服務器，cnMaestro的所有此類實例都以多租戶架構託管在Cambium組織下的Amazon AWS雲上。

雲部署託管在亞馬遜AWS上的cnMaestro雲部署包括一個cnMaestro的主要實例(託管在https://cloud.cambiumnetworks.com上)，它處理登錄、設備部署，並將大部分平台數據保存在主數據庫中。

任何註冊到cnMaestro Cloud應用程序的用戶都會獲得一個個人Amazon AWS實例，其中包含個人URL (Cambium主雲的子域)和組織標識符。這有助於在多租戶設計中分離不同的用戶。為了訪問你的cnMaestro實例，將按照以下方案生成一個唯一的URL：https://us-e1-sXX-XXXXXXXXXX.cloud.cambiumnetworks.com

在Team82對Cambium cnMaestro的研究結束時，他們發現了7個不同的漏洞，可以在這里和Team82的披露儀表板上看到。然而，一個特別的漏洞讓Team82陷入了一個巨大的兔子洞，導致Team82發現並開發了這項新技術。

很難利用的零日漏洞Team82發現的一個特殊的Cambium漏洞被證明更難利用：CVE-2022-1361。該漏洞的核心是一個簡單的SQL注入漏洞，但實際的開發過程需要Team82跳出思維定式，創建一個全新的SQL技術。利用這個漏洞，Team82能夠竊取用戶的會話、SSH密鑰、密碼哈希、令牌和驗證碼。

此漏洞的核心問題是，在這種特殊情況下，開發人員沒有使用準備好的語句將用戶提供的數據附加到查詢中。他們沒有使用將用戶參數附加到SQL查詢並清除輸入的安全方法，而是直接將其附加到查詢中。

Team82在CVE-2022-1361中濫用的SQL注入匯點

正如我們在上面的匯點中看到的，應用程序接受用戶提供的數據（在本例中為a.serialNo或a.mac），並將其附加到SQL查詢中。我們使用此漏洞的目的是過濾存儲在數據庫中的敏感數據。然而，雖然這看起來很簡單，但在快速分析了該漏洞後，我們意識到它有三個關鍵漏洞/限制：

Team82只能檢索作為返回行的整數；

返回的行按隨機順序返回；

在每個請求中，Team82只能返回有限數量的行。

讓我們深入分析這些限制。

限制1：Team82只能檢索整數第一個限制只返回整數，而不返回字符串。由於原始請求返回整數，我們將使用的任何联合語句也必須返回整數。在SQL中，如果執行聯合操作，則必須確保兩列的類型相同，並且由於一方獲取整數，因此我們也必須返回整數。由於我們要過濾的數據很可能是字符串（會話令牌、SSH密鑰等），因此我們必須以某種方式獲得過濾字符串的能力。

通過將想要過濾的任何字符串轉換為整數數組，並將每個字符作為單獨的行返回，可以輕鬆克服這一限制。為此，Team82使用了stringarray和ASCIISQL函數。

一個SQL查詢，返回字符串作為其字符的整數列表

限制2：返回的行按隨機順序返回第二個限制是，當Team82返回多行時，web服務器將以隨機順序返回給Team82。當Team82查看漏洞後執行的代碼時，Team82看到對於SQL查詢返回的每一行，服務器將執行一些其他異步操作(這可以通過調用async.parale函數看到)。這意味著返回行的原始順序將不會被保留，相反，該順序將是異步操作完成的順序。

這意味著，如果Team82將字符串作為整數數組進行過濾，就會丟失字符順序，從而使過濾變得無關緊要。

Team82通過添加行索引來克服這一限制，行索引使用row_number SQL函數將字符串中字符的索引轉換為返回的整數。因為Team82只返回ASCII字符，所以每個字符的值被限制為128。通過將索引號乘以1000 (i * 1000)並將其附加到結果中，Team82總是可以通過簡單的除法和模塊操作來確定字符索引。

一個SQL有效負載，返回字符串中每個字母的ascii值，加上字符的索引乘以1000

在檢索到過濾的數據之後，Team82可以簡單地將每個返回行除以1000，以了解字符索引。 Team82還可以通過對返回值使用模塊操作來恢復原始字符ASCII值。

限制3：在每個請求中只能返回有限數量的行最後一個限制是最難克服的：超時問題。對於返回的每一行，服務器都執行了一些其他操作，包括另一個SQL查詢和數據操作。當我們試圖檢索大量行時，請求超時。更糟糕的是，API端點相當慢，因此每次檢索一行非常耗時。

Team82的解決方案實際上非常高級，Team82不是為每個字符返回一行，而是從許多行中構造一個整數。這是可能的，因為整數和字符之間的字節大小不同。在PostgreSQL中，一個整數是4字節長，而Team82試圖過濾的字符是1字節長(只要是ascii字符)。這意味著通過執行簡單的字節操作，Team82可以在每個整數中容納四個不同的字符。此外，如果Team82在union命令中將整數轉換為BIGINT，這在PostgreSQL中是可能做到的，Team82可以將每行擴展為8字節。

PostgreSQL類型大小

這意味著，如果要為Team82過濾的每個字符附加8個字節，並將其附加到BIGINT中，Team82可以在每個請求中過濾7倍多的字符(1個字節保留給字符索引)。

一個SQL查詢，它接受一個字符串，並每隔幾個字符創建一個BIGINT

使用這種方法，Team82能夠在每個請求中提取多達8倍的數據。這減少了Team82竊取大量數據所需的時間，並使攻擊場景變得可信。

構建有效負載在Team82繞過所有三個限制之後，Team82就得到了一個大的有效負載，允許提取任何Team82選擇的數據:

事實上，當Team82使用這個有效負載時，Team82設法竊取了存儲在數據庫中的敏感信息，從會話cookie到令牌，SSH密鑰和哈希密碼。

使用SQLi有效負載提取的數據示例

雲端漏洞在成功利用了雲部署漏洞後，下一步是在Cambium的雲端嘗試相同的漏洞。很快，Team82就找到了相應的雲路由，並成功確認它也容易受到同樣的漏洞的攻擊。然後Team82嘗試了一個安全版本的有效負載，並收到了這樣的響應。

對SQL注入漏洞的響應，可以看到Team82的請求被釋放了，返回一個403 Forbidden

接下來，我們注意到了包含awselb/2.0的HTTP服務器，這意味著，應用程序並沒有停止Team82的請求，而是AWS WAF釋放了Team82的請求，因為它可能將其標記為惡意請求。

對AWS WAF的研究為了研究AWS WAF，我們首先創建了自己的設置，在其中控制所有的活動部件：應用程序、客戶端和WAF設置和日誌。我們在AWS雲上創建了一個簡單的設備，並設置了AWS WAF來保護應用程序免受惡意請求(Team82設置了WAF)。

用於配置WAF規則集的界面

然後，Team82創建了一個帶有SQLi漏洞的web應用程序，並將其託管在AWS上。

Team82創建的易受攻擊的Flask web應用程序

最後，Team82開始發送數百個自定義的請求，試圖分析WAF是如何將請求標記為惡意的。

被WAF標記為惡意的請求被阻止，在這個請求中，Team82傳遞一個通用的SQLi有效負載，它由WAF標記

WAF通常有兩種方法將請求標記為惡意：

搜索黑名單單詞：WAF可以搜索它並將其識別為SQL語法的單詞，如果請求中存在太多匹配項，它會將該請求標記為惡意SQLi嘗試。

從請求中解析SQL語法：WAF可以嘗試使用請求的不同部分解析有效的SQL語法，如果WAF成功識別SQL語法，它將標記該請求為惡意SQLi嘗試。

雖然大多數WAF除了使用WAF特有的方法外，還會使用這兩種方法的組合，但它們都有一個共同的漏洞：它們需要WAF識別SQL語法。這引發了Team82的興趣：如果Team82能夠找到WAF無法識別的SQL語法，該怎麼辦？

SQL JSON目前，JSON已經成為數據存儲和傳輸的主要形式之一。為了支持JSON語法，並允許開發人員以類似於在其他應用程序中與數據交互的方式與數據交互，SQL中需要JSON支持。

目前，所有主要的關係數據庫引擎都支持原生JSON語法，這包括MSSQL, PostgreSQL, SQLite和MySQL。此外，在最新版本中，所有數據庫引擎默認啟用JSON語法，這意味著它在今天的大多數數據庫設置中很普遍。

開發人員選擇在SQL數據庫中使用JSON特性，原因有很多，首先是更好的性能和效率。由於許多後端已經使用JSON數據，因此在SQL引擎本身執行所有數據操作和轉換可以減少所需的數據庫調用數量。此外，如果數據庫可以使用JSON數據格式(後端API很可能也會使用JSON數據格式)，那麼所需的數據預處理和後處理就會更少，從而允許應用程序立即使用它。

通過在SQL中使用JSON，應用程序可以在SQL API中獲取數據、從數據庫中組合多個數據源、執行數據修改並將其轉換為JSON格式。然後，應用程序可以接收json格式的數據並立即使用它，而不需要處理數據。

在SQL中使用JSON的數據流，允許開發人員在SQL中使用JSON API更好地與數據交互

雖然每個數據庫都選擇了不同的實現和JSON解析器，但每個數據庫都支持不同範圍的JSON函數和操作符。此外，它們都支持JSON數據類型和基本的JSON搜索和修改。

對每個主要數據庫的JSON支持級別

然而，儘管所有的數據庫引擎都增加了對JSON的支持，但並不是所有的安全工具都增加了對這個“新”特性的支持。安全工具中缺乏支持可能會導致安全工具(在Team82的例子中是WAF)和實際數據庫引擎之間的原語解析不匹配，並導致SQL語法錯誤識別。

The New ‘ or ‘a’=’a

使用JSON語法，可以創建新的SQLi有效負載。由於這些有效負載不為人所知，它們可以繞過許多安全工具。使用來自不同數據庫引擎的語法，Team82能夠在SQL中編譯以下真實語句列表:

使用JSON語法

從Team82對WAF如何將請求標記為惡意的理解中，可以得出結論，Team82需要找到WAF無法理解的SQL語法。如果Team82可以提供一個SQLi有效負載，WAF不會將其識別為有效SQL，但數據庫引擎會解析它，Team82實際上就可以實現繞過。

事實證明，JSON正是WAF解析器和數據庫引擎之間的這種不匹配。當Team82傳遞使用不太流行的JSON語法的有效SQL語句時，WAF實際上並沒有將請求標記為惡意請求。

下面是一個惡意的SQLi有效負載，包含JSON語法。正如Team82所看到的，WAF並沒有將該請求標記為惡意請求，也沒有釋放它

這個簡單的JSON運算符，在本例中是@，它檢查右邊的JSON是否包含在上面左邊的JSON中，它將WAF放入一個循環中，並允許Team82提供惡意的SQLi有效負載，從而允許Team82繞過WAF。通過簡單地在請求的開頭預先添加簡單的JSON語法，Team82就能夠在雲上使用SQLi漏洞竊取敏感信息!

利用雲上的SQL注入漏洞

常見的WAF繞過上述繞過的核心問題是數據庫引擎和SQLi檢測解決方案之間缺乏一致性，這是因為SQL中的JSON並不是一個流行和廣為人知的特性，而且它的語法沒有添加到WAF解析器中。

然而，Team82認為這個問題可能不僅僅與這個WAF供應商有關，可能其他供應商也沒有添加對JSON語法的支持。所以Team82採用了易受攻擊的web應用程序，並在大多數主要WAF供應商上創建了一個設置。幾天后，Team82發現JSON語法可以繞過他們檢查過的大多數供應商:

Palo-Alto下一代防火牆

F5 Big-IP

Amazon AWS ELB

Cloudflare

Imperva

Team82使用JSON語法繞過的WAF供應商和產品列表

Team82成功地繞過了這麼多大型WAF產品，如果Team82的有效負載有任何變化，這意味著Team82有一個通用的WAF繞過。這意味著即使不知道Team82和目標之間的WAF是什麼，Team82仍然可以利用SQL注入漏洞，繞過WAF的保護。

自動化流程為了研究這種WAF繞過的危害有多大，Team82決定在最大的開源開