Apache Log4j2 遠端程式碼執行漏洞已爆發一週，安全廠商提供各類防禦方案和檢測工具，甲方團隊連夜應急。
影響持續至今，網上流傳的各種利用和繞過姿勢還在層出不窮，影響面持續擴大。所有安全人都開始反思一個問題：當前的防禦是否有效？針對這樣的 0day 再次發生，什麼是有效的手段？
阿里雲安全團隊此次參與了諸多客戶應急，並從雲平臺自身防禦總結經驗，嘗試丟擲一些觀點以供討論。
首先，我們先來從技術層面分析一下為什麼這次 Log4j2 這麼難搞。
Apache Log4j2 漏洞們的特質
此次 Log4j2 漏洞有兩個很棘手的特質：
可以實現任意遠端程式碼執行
“懂規矩”的漏洞，危險大的利用門檻高，利用門檻低的危害小，還算符合自然規律。這個漏洞並不按常規出牌，不但影響面廣，利用門檻低，危害還極大。三個因素重疊，到處被冠上“史詩級”的頭銜。
Java 的應用極其廣泛且生態龐大，而 Log4j 作為日誌處理的基礎元件被幾乎所有應用程式所使用。
通過 JNDI 注入的手段，可以實現任意遠端程式碼執行，意味著攻擊者可以在存在漏洞的伺服器上為所欲為。
即使在內網環境中 JNDI 外聯無法成功，攻擊者也可以結合 lookup 特性去讀取很多敏感資訊（如資料庫密碼、JAVA 環境變數等），再通過 DNS 協議把敏感資訊帶出內網。
流量特徵隱蔽
某些場景下幾乎沒有可以跟正常請求區分開來的強特徵。
本次漏洞 PoC 構造非常簡單，漏洞觸發的點廣泛而靈活，配合各種變數和協議的巢狀繞過方式，導致流量特徵非常複雜和隱蔽。Log4j2 的 lookup 功能支援一些特殊的寫法來對字元做二次處理，如 ${lower:j}Ndi、${upper:JN}di、${aaa:vv:cc:-j}ndi 等寫法，都能打破字串的連續性，造成利用時候的流量特徵極為不明顯。
這是對所有基於流量特徵安全防護產品的巨大挑戰。
當流量特徵不夠明顯時，基於流量特徵的規則陷入尷尬：要麼覆蓋不到，要麼產生嚴重誤報。只能持續不斷補充規則，在繞過和被繞過中迴圈往復。這種防禦手段，能在 0day 爆發初期非常有效的為漏洞修復爭取時間。但隨著各種利用手段的變化越來越多，則很難保證沒有被繞過或誤報。
與 Log4j2 漏洞的某些“弱特徵”甚至“0 特徵”利用方式類似的場景，還有加密流量、記憶體馬等，這些手段都曾在大型攻防演練中大放異彩，難以檢測的原理是類似的。
所以，有沒有一種技術，可以無視漏洞利用手法在流量特徵上的各種變化或隱藏，防禦的更天然，甚至不依賴規則更新就可以防禦這類 0day？
RASP 在此次事件中重回視野
RASP（Runtime Application Self-Protection），執行時應用自我防護，安全行業其實對其並不陌生，卻因為傳統印象而採納不多。
這類技術的優勢在於，以疫情類比，傳統的邊界防禦類產品，類似口罩/防護服，而 RASP 則類似疫苗，會將自己注入到應用當中，伴隨應用一起執行，通過 hook 關鍵函式實時檢測應用執行的高危行為。
RASP 是哪一類 0day 的天敵
不同於基於流量特徵的檢測，RASP 核心關注應用行為，而非流量本身。
當 RASP 發現一個應用，做了它正常不應該做的事情時，大概率意味著當前應用已經被攻擊者利用漏洞攻陷並做了一些高危操作（比如命令執行、檔案讀取、檔案上傳、SSRF 等）。
其第一個優勢是：凡是被 RASP 防禦的行為，都已經是真正可以被成功利用的攻擊行為。
而應用的行為型別，相比於變幻無窮近乎無限的流量特徵來說，往往是可以窮舉的。從應用行為異常的角度去檢測，範圍可以大幅收斂到有限的型別，這是RASP可以無視流量特徵並且不依賴規則更新就可以防禦幾乎全部0day（包括加密流量和記憶體馬） 的根本原因。
0day 和一些弱特徵漏洞利用方式之所以難以防禦的原因，上文已經提及。但不管流量特徵如何變化，漏洞利用的本質：還是要回歸到讓應用來做一些不安全的動作上——也就是應用行為或者企圖。
以此次漏洞來看，RASP 並不關注請求中的流量是否包含了惡意的 payload，而是去關注 Log4j2 究竟使用 JNDI 功能去做了什麼。如果進行正常的 JNDI 查詢，就沒有問題；但如果企圖使用 JNDI 功能進行命令執行，就是一個顯而易見的危險行為。
RASP 正是在這個階段發揮了極其重要的作用：在應用犯錯之前將其“懸崖勒馬”。
從這個角度上還可以引申出 RASP 的第二個優勢：誤報極低。
比如：如果應用壓根沒有使用 Log4j2，基於 payload 中的惡意特徵上報攻擊就意味著誤報，一定程度上消耗安全人員的精力。
而由於 RASP 執行在應用內部，可以明確知道來自流量層的 payload 是否成功進入了 Log4j2 的危險函式，所以不會存在“無效告警”。
近些年來，從 weblogic 到 shiro、dubbo 再到今天的 Log4j2，由第三方元件導致的 0day 不斷的大規模爆發。
因為這類元件的程式碼並不由使用它的應用的開發們維護，一旦漏洞爆發，安全人員第一時間首先需要投入大量的精力去排查哪些應用在使用存在漏洞的元件，這並不是一個容易的事情。特別是對應用眾多、迭代快速的企業來說，自己也說不清楚哪些應用、在使用哪些元件的、哪些版本是非常正常的事情。
這裡引出了 RASP 的第三個優勢：第三方元件自查。
當一個 0day 出現時，可以第一時間排查到受影響元件的路徑，如下圖所示：
（通過阿里雲RASP定位的Log4j元件路徑）
對於歷史上已經爆出過 CVE 漏洞的元件，RASP 可以自動檢測並關聯其對應的 CVE 漏洞編號、漏洞等級等資訊，方便安全和開發人員及時修復。
雲原生 RASP，架構優勢加速落地
2014 年，Gartner 就將 RASP 列為應用安全的關鍵趨勢，但實際上 RASP 在生產環境中大規模落地一直比較緩慢，目前也只有少數頭部的網際網路公司做到了。究其原因，最大的阻礙在於 RASP 技術對應用自身的入侵性，開發人員會非常擔憂產生效能、穩定性、相容性下降等問題。
阿里巴巴集團從 2015 年開始部署自研的 RASP 產品，多年實踐已完成在生產網的大規模部署，並且經歷了生產網超大流量業務的實戰檢驗，在效能、穩定性和安全性（自我保護）控制方面實現最佳表現。不得不說，這其中的確需要大量時間來沉澱經驗和教訓，不斷調優，這也是甲方安全團隊自建 RASP 最大的難點。
阿里雲安全團隊將 RASP 最佳實踐嘗試輸出，去年推出更通用、更適合使用者場景的 RASP 版本，並在多個金融、教育使用者的生產網中部署和應用。今年，打通雲架構優勢，實現雲原生 ARMS 產品應用一鍵接入 RASP 的絲滑體驗（開啟路徑：阿里雲 ARMS-應用安全選單），極大降低雲上使用者使用 RASP 防禦能力的門檻。
近期事件接入 RASP 的使用者中，阿里雲安全團隊觀測到非常凶猛的 Log4j2 漏洞利用和危險行為。以某金融使用者為例，接入 2 天，RASP 檢測並攔截了涉及 8 個 Java 應用的 184 次真實攻擊，其中包含 43 次命令執行和 141 次 DNS 漏洞探測。如果缺少 RASP 的防禦一環阻攔，這些是極大可能真實執行成功的攻擊。
當前版本免費公測，應急的安全同志們可以接入 RASP 再從容升級。如果需保護應用暫時沒有上雲，也可以聯絡我們部署線下版 RASP。
PS：因漏洞管理規定，文中圖片漏洞細節通過馬賽克做了模糊處理，敬請諒解
點選**此處**，瞭解更多ARMS相關資訊！
對 ARMS 感興趣的同學，可以釘釘搜尋群號（34833427）或掃描下方二維碼入群交流、答疑～