從Log4shell事件看資產風險運營工程化的困局與盲點
這幾天想必各位同行都被這個漏洞折騰瘋了，不管是甲方的同學還是乙方的同學，毫不夸張的這個漏洞應該是近五六年以來僅次于永恒之藍事件的安全事件了，只要你是 Java 公司，或多或少都會收到這個漏洞的影響。從上周五開始，幾乎所有的小伙伴們都開始在群里喊應急了，我本人也是因為這個事兒毀了一個周末，本來還約了人去滑雪。但是周一一看國內基本上收斂了，但是國外開始了，各種黑產和僵尸網絡開始層出不窮的出現。根據 360netlab 那邊的數據，最早從 12 月 1 號開始就有黑產開始利用這個漏洞摸魚了，并且各個廠商也不斷的去更新各種各樣的 IoC，有趣的事情是，卡巴斯基旗下 SecureList 更新了差不多 10 幾個 IoCs，緊接著趨勢馬上把這個數量拉到了將近 100 個，可見黑產有多么的狂歡（IP 大多數來自于俄羅斯）。
在這篇文章中，我們不會討論是誰泄露了漏洞的信息，也不討論各家的修復建議是不是靠譜等一些技術性的問題。單純就說從這次推修的過程中，我們如何去重新思考整個資產風險運營體系和工程化這件事情。
0x01 到底發生了什么事情
為了防止有圈外的人不知道發生了什么，我先用一個通俗易懂的例子來說一下這幾天發生了啥。
你們鎮上有一個遠近聞名的磚廠，因為物美價廉而且質量穩定可靠，生產出來的成品磚暢銷海內外。有一天有一個韓國人發現自己用這個磚廠生產的磚蓋房子的時候發現可以添加一些物質使得磚搭起來更容易，成本能降低。然后這個韓國人就找到了磚廠廠長說了自己的方案，連原材料配方啥的都拿過來了。廠長一聽這事兒靠譜，然后就把這個整個廠的生產線全都應用了這個技術。過了很久之后，有一個大爺在遛狗的時候，不小心磕到了墻上，結果發現墻裂了一塊，因為大爺是一個已經退休的質檢科科長，于是他便去分析了一下情況。好么，這一分析發現這個韓國人給的東西完全不靠譜，只要碰的角度和方向對了，可以不費吹灰之力直接把墻撞塌了。大爺直接急了，把情況反饋給了廠長，然后經過廠內技術專家的反復確認，這個東西確實有問題。然后便把這件事兒同步給了應急管理相關的機關單位。機關單位聽完之后當場說出**倆字，然后經過一輪排查后發現，不僅是最近幾年蓋得樓房，連學校、醫院、政府大樓這些事業單位的建筑都用了這批磚，而且廠房的二期工程用的也有這批磚，不但如此，好多宅基地上自建的一些平房也都用了這批磚，可以說沒有不用的。結果應急管理相關的同志們開始評估并制定加固方案，但是因為影響范圍巨大，導致全量處置完需要的時間可能不是一點半點，至少今年是沒戲了。除此之外，應急管理部門還發現這個配方只有在韓國本土才有人用，連他北邊的鄰居都不用。最后磚廠花了幾天時間把生產線又改回了原樣。
回歸到事件本身，針對這個事件本身而言，實際上現在還在處于控制損失的階段，因為你只能保證你自己不用有問題的版本，并不能保證你用的組件里面用的開源組件不用有問題的版本，也不能保證你買的商業產品里面用的開源技術不用有問題的版本。所以這個漏洞的修復肯定不是一時半會兒能夠解決的，未來估計會和新冠病毒一樣與信息基礎設施長期共存。
0x02 資產風險運營工程化的若干點忠告
（1）盡量避免“單線作戰”，要進行“多線作戰”，重視對抗工作但不要為主
首先先來闡述一個觀點，對于 Log4shell 這種事兒而言，不要把它當成一個常規的資產風險推修事情去處理。我非常能理解企業內部建設資產風險運營相關的流程、能力和平臺這件事兒是為了去更好的解決資產風險運營的事情，但是我還是想說這件事情應該當做一個專項來處置。因為這種類型的事件往往不是“單線作戰”，而是“兩線作戰”甚至是“三線作戰”，僅僅依靠把握修復進度而言是遠遠不夠的，對于這種熱度很高且利用難度極低的漏洞而言，入侵對抗層面也是有著非常大的壓力。所以要在運營修復質量的同時，也要注意對抗層面的工作，具體對抗層面的工作包含：
- 緩解與修復方案的制定與研究
- 補丁繞過的機制與分析
- 流量側風險利用感知
- 終端側風險利用感知
- 風險威脅情報 /IoCs/ByPass 檢測策略的信息收集
雖然說要強調對抗工作的重要性，但是不能以其為主，工作的人力、資源和重心一定要放在 push 風險修復進度這件事兒上，畢竟人家打不打你是一個概率事件，風險的存在是必然事件。
（2）專項啟動前對修復需要用到基礎設施進行性能勘測和評估
平臺化解決資產風險運營工作的思路是對的，但是在設計的時候有沒有仔細考慮過運營平臺的上限是什么？因為當前風險超過產品本身的性能指標的 case 有一個比較經典的：2011年島國大地震的時候直接把福島核電站震塌了，拋開實際操作不當這些運營層面上的事兒不談，這個核電站在設計的時候最多只能扛得住 8 級地震，但是 2011 年的那次遇到的是 9 級的超級地震，導致核電站直接芭比 Q 了。所以平臺在設計的時候，設計指標并不一定能扛得住 Log4Shell 這種影響范圍的漏洞，嚴格意義上來講也沒有必要。這件事兒對于資產風險運營平臺來說，甚至對于企業內部的代碼倉庫、CI/CD 平臺、發版系統來說也是個不小的挑戰（畢竟要頻繁改代碼、編譯、上線調試，對于平臺的壓力可想而知）。所以資產風險運營平臺需要提供必要的工具鏈，在平臺失效的情況下也可以利用工具鏈完成風險運營 SOP 進行風險事件的處置，當然擴容能解決的問題，擴容就好了。我估計至少有 90% 以上的企業在修 Log4Shell 之前都不會去評估自己的基礎設施是否能扛得住大規模推修，然后等要出數據的時候發現數據有延遲、計算的不對的情況，那個時候已經晚了。
（3）風險信息獲取要前置，只簡單同步風險數據庫很危險
這個問題其實我在 ISC2019 的時候強調過一次，從 xcodeghost 帶火供應鏈攻擊這件事情以后，資產風險信息的獲取工作就不能是去同步 NVD、CNVD 這些成品漏洞庫了，一定要去分析在用組件的 commit、issue 和 jira 等 PR 材料，這樣才能提前獲取高危風險的修復版本，甚至我還在公司的技術博客上又強調了一遍：《美團安全應急響應中心》。且不說慢不慢的問題，漏洞其實只是風險的一小部分，現在馬上就 2202 年了，如果要是在僅僅憑借爬朋友圈、同步漏洞數據庫這種簡單的操作去做外部風險識別與發現，已經完全不能 cover 的住這種風險的運營工作了，現在還這么干相當于是 50 年加入國民黨還在留守大陸。奉勸各位搞個 Apache 的 ICLA 吧，真的不難。
除了風險信息之外，要及時的建立起來風險運營的一整套體系，最少應該包含資產-風險關聯規則、配套中間件和SDK、關聯規則插件和引擎、外部配套的API
（4）SCA/RASP 在這類風險面前的作用可能比黑盒掃描器更安全好用
之前很多企業都不重視 RASP 和 SCA 這兩個產品，實際上在這類場景中，SCA 作為分析項目的依賴情況可以迅速判斷出來哪些項目有問題，結合 HIDS 的進程數據、環境變量數據，可以很輕松的排查出來那些項目受影響。RASP 這種東西實際上在檢測這種 JNDI 注入的攻擊時候成功率非常的高。但是看一下企業內部 SCA/RASP 的覆蓋度，大家就明白我在說什么了，不出意外的話明年3月我會分享一下我在 SCA 層面上的一些建設。為什么不要用黑盒掃描器，在你對你的 PoC 能夠說出不會影響業務并且有 benchmark 之前，不要亂用黑盒掃描器，因為你也不知道業務的實現邏輯，很容易掃掛了，掃掛的后果輕則業務打電話直接噴人，重則。。。你懂的吧。此外你在企業內部有大把的數據可以用，為什么非要采取這種白帽子或者是黑產才會用的手段為主呢？
（5）不要盲目聽信升級版本可以解決問題，有時候緩解可能會更好
升級版本可以解決問題么？當然可以解決，但前提條件是你要能保證你升級的版本是對的。何為對的版本，徹底解決該類風險，比如 2.16.0-rc 版本中徹底移除 lookup 功能，當然算是一個正確的版本。但是，很遺憾，絕大多數企業內的情況并不適合直接升級版本，雖然我在給 Log4J2 作者發郵件詢問 patch 的時候，Log4J2 的作者表示升級版本這件事兒是一件非常 smooth 的事情，但是實際情況是，升級版本會引來很多的兼容性問題，嚴重的會直接導致業務崩潰起都起不來了。這是一件很嚴重的事情，甲方公司內部安全部門存在的價值就是為了保障業務的安全，你給出的 Solution 直接把業務弄死了，你還好意思說自己有存在的價值嗎？在沒有出現徹底的解決方案之前，緩解才是第一要素，緩解可以提高攻擊成本，能夠給你爭取更多的修復窗口時間。而不是一上來就去直接升級版本，企業內部升級版本又不是 2.14.1->2.15.0-rc 這么簡單，而是 2.1.x\2.2.x\2.3.x\2.4.x\2.5.x\2.6.x\2.7.x\2.8.x\2.9.x.....->2.16.0-rc 這樣，而且你會發現各個分支版本所占比重都差不太多，這個時候如果盲目強推新版本，你覺得不會有兼容性問題么？所以選擇最適合企業內部情況的才是最好的，沒必要糾結是不是升級版本，財大氣粗的企業自己寫一套不香么？
（6）需要有“一言堂”的人出現，高效分配手頭資源
何為一言堂，敢在團隊面前說“你們要聽我指揮，出了問題我來背鍋”。當然說前半句的人有而且還挺多的，完整說出來的人不多。這個時候需要有人去全局統籌研發資源、運營資源等現有的資源來更高效的去解決這個 case，如果沒有這種人，就會出現胡亂爭搶資源的情況，有一些雞毛蒜皮的小事兒完全可以通過 FAQ 或者迭代檢測規則就能完事兒，非要上升到給平臺的 PM 提需求，導致資源被浪費，拖慢了修復進度。這個時候大量的資源要傾斜到推送漏洞修復和迭代入侵對抗策略上，惡意爭搶資源的需求這個時候需要被一票否決，等以后再說。
0x03 總結
希望這種事兒以后能少一點是一點吧，我要先去睡覺了，有想深入交流這一部分的，可以加微信 e1knot
