重點摘要

在許多企業與機構將服務線上化，又稱「上雲」的過程中，經常需透過 WAF （Web Application Firewall） 保護企業對網際網路公開的應用程式服務。透過 WAF，攻擊者對於網路應用程式所發起的 SQL injection 攻擊，容易被發現和阻擋；然而，近日研究者發現，攻擊組織 Team 82 透過 WAF 開發者對於 JSON 資料庫格式不熟悉的特性，將 JSON 置於 SQL 攻擊的語法前，以繞過 WAF 對此攻擊的偵測；並利用其他漏洞，滲出並竊讀企業的重要資訊。經過研究者的測試，此攻擊手法可以成功繞過由 Palo Alto Networks, Amazon Web Services, Cloudflare,  F5, 和  Imperva 所開發的 WAF，成功執行 SQL 攻擊。

 

潛在攻擊內容

網路應用程式防火牆 （WAF） 是防止網路應用程式或是API服務受到惡意的外部 https 攻擊，例如：跨站腳本攻擊 （Cross-Site Scripting，XSS） [註1] 與 SQL 資料隱碼攻擊 （SQL injection），進而獲得使用者的個人資訊，像是：session cookies, tokens, SSH keys 和 password hashes （加密後的用戶密碼字串）. 雖然目前SQL的攻擊的修補方式相對其他攻來的容易，但是SQL  injection 相關的漏洞卻是在各自動掃描經常上榜的漏洞，同時也是企業常見漏洞之一。

本次欲討論之潛在攻擊內容主要依靠 （1） WAF 如何辨識並標記可疑的 SQL 語法 以及 （2） 找出WAF 無法辨便的語法，在本次的討論中，就是 JSON。

JSON 是一種標準的檔案和資料交換格式，經常被使用在 server 和網路應用程式 （web application） 間的通訊中。 

僅管 JSON 經常性的被使用於資料庫的引擎中，對於WAF而言卻是陌生的。鮮少的 WAF 開發者將在 WAF 中加上 JSON技援，才導致了可能透過 SQL inject 鍵入 JSON 語法的潛在攻擊手法，繞過 WAF 的安全性防護。

透過此新型攻擊手法，攻擊者可能取得用戶後端的資料並利用其他弱點從雲端或是直接滲出用戶的資料。

 

此攻擊手法的細節

Claroty 研究者在檢視雲端架構 cnMaestro時，並發現：在正常情況中，一個 cmMastro 雲端應用程式的使用者可以透過 cmMastro 註冊一個個人的 URL （是 cmMastro 服務所屬公司- Cambium 透過 Amazon AWS 建立的主雲之下的子網域） 以及一個企業的識別碼。在此雲端架構下，Claroty的 Team 82 研究團隊總共發現了7個不同的弱點 （詳請見 Team 82 的研究公告） 其中的新 WAF 漏洞 （CVE-2022-1361），便是本次主要討論的範圍。

此弱點的核心在於開發者在開發時並沒有使用安全的帳號密碼附加（append） 方式，將使用者的帳號密碼資料存入資料庫中後並清除；而是單純將帳號密碼存入資料庫中 （db.Query）。因此可能受到惡意攻擊者的 SQL injection 攻擊。然而此攻擊卻有以下三個困難，然而Team 82 發現此三個困難卻也都有對應的破解方法，細節如下：

1. 【攻擊者困難一】攻擊後所回傳的資料只能由整數的形式回傳
   由於原先程式撰寫的請求只能回傳數字，因此此攻擊僅管可以呼叫取得使用者的帳號密碼，但卻無法直接回傳字串 （例如攻擊者可能感興趣的資料- session tokens, SSH keys 等等），只能回傳整數值。然而此困難可以使用 stringtoarray 和 ASCII 的SQL functions ，將攻擊者希望取得之字串轉換為各別的 ASCII 編碼陣列 （array） 即可以突破。
   圖片轉載：https://claroty.com/team82/research/js-on-security-off-abusing-json-based-sql-to-bypass-waf

2. 【攻擊者困難二】回傳的資料的順序是隨機排序的
   由於開發程式被撰寫時，開發者透過呼叫async.parallel的函數，將回傳的資料順序打亂。故若攻擊者將字串轉換為各別的 ASCII 編碼陣列時，其回傳的字母順序會被打亂。然而，Team 48 發現此困難也可透過事先記錄每一個 array的順序，並將其建立成一個row index，再使用 row_number SQL 依照事先所記錄的 row index，將 ASCII array 字串轉換為字母，便可以得到照原順序排列的資料字串。
   

          圖片轉載：https://claroty.com/team82/research/js-on-security-off-abusing-json-based-sql-to-bypass-waf

 

3. 【攻擊者困難三】每一次要求資料回傳只能回傳特定數量的資料
   由於開發者有設定資料回傳的時間限制 （timeout），且接口端點 （API endpoint） 的速度也很慢，因此若一次只要求回傳一次資料，對於攻擊者而言有些花費時間。Team 82 找到了一個優雅的解決方案：使用 ASCII 編碼，因為其編碼特性一個數值只需要使用一個 byte 的資料傳輸空間 （在原使用的 PsterSQL中，一個數值需要花費 4個 byte 的傳輸空間來儲存）, 可提升四倍的傳輸速度；除此之外，攻擊者也可以透過BIGINT 將回傳的數值轉換為Bigint 進而將回傳的傳輸空間提升至 8 bytes. 

          

     圖片轉載：https://claroty.com/team82/research/js-on-security-off-abusing-json-based-sql-to-bypass-waf
 

在突破上述三個攻擊困境之後，攻擊者便可以透過回傳所得到的資料，進一步提取用戶的私人資料，例如：sessions cookies, token, ssh keys 和 hashed password 等等。

 

怎麼樣的 SQL 語法會被 AWS WAF 標記成可疑的語法呢？

Team 48 為了找出答案，自行設定並建立了具有 SQL injection 弱點的 AWS WAF，並對此WAF發送了百餘則不同的請求，並分析出 WAF 可能是依照以下兩個規則對於請求進行標記：

1. 根據內建的 SQL injection 指令黑名單 （blacklist） 進行篩選：若存在過多與黑名單中指令相符的 functions，WAF 會將此請求標記為「可疑的」。

2. 將請求中的 SQL 語法進行拆解：WAF 將請求的不同部份分解可辨識的 SQL 語法。 如果 WAF 成功識別 SQL 語法，它可能將此請求標記為惡意 SQL injection  嘗試。 

 

其他危害

除了有取得用戶使用資料的可能性之外，模擬惡意攻擊者可能利用WAF和資料庫引擎在開發時對於 JSON 語法的理解差異，使用 JSON 語法的條件運算子「@<」或任意安插不同 JSON 語法於惡意負載 （payload） 中，以此繞過 （bypass） WAF 的檢測，使此惡意負載得以被傳送至目標資料庫引擎並且被執行。

透過此技巧，攻擊者可以存取使用者伺服器後端的企業與顧客資料，並利用其他的弱點，從而對企業的伺服器或雲端進行管理與控制。雖然 JSON 語法已知被大量地使用於 SQL 資料庫或是很多後端的應用程式開發架構中，但對於許多網路安全工具，這仍是一個陌生的語法。

此攻擊資訊對於上雲的 OT 和 IoT 企業尤其重要。目前具有此漏洞的 WAF 製造廠 （F5 Big-IP, amazon AWS ELB, Cloudflare, Imperva 和 Palo-Alto Next Generation Firewall）皆已被通知，並對於旗下所生產的 WAF 加上了 JSON 語法支援，完成對於此漏洞的修正。

 

註1：XSS 攻擊是當網站讀取時，執行攻擊者提供的程式碼。XSS 通常是透過 HTML/JavaScript 這類不在 伺服器端執行、而在使用者端的瀏覽器執行。可用來竊取用戶的 cookie，甚至於冒用使用者的身份。像是網路 銀行、電子郵件、部落格或其他需要有帳號才能進入的網站。（參考資料：叡揚資訊 GSS 資安電子報 第 0067 期-跨站腳本攻擊（Cross-Site Scripting, XSS）概述）

 

參考資料：
{JS-ON: Security-OFF}: Abusing JSON-Based SQL to Bypass WAF, claroty.com T82 （Dec 8, 2022）- https://claroty.com/team82/research/js-on-security-off-abusing-json-based-sql-to-bypass-waf