是否存在“內部安全應用程式”場景，其中軟體因為較早的 Log4J 版本而比沒有它時更容易受到攻擊？
我在下面概述了關于這個問題的一些細節。
我正在做一些作業來減輕最近的 Log4J 漏洞帶來的風險。我知道一些方法涉及從組織的所有計算機、服務器、遠程桌面和所有東西中洗掉早期 Log4J jar 檔案的所有痕跡，在完成此操作之前，組織被視為“處于危險之中”。但是，我也想知道如此大量的全盤投入是否成正比 [edit 22-Dec-21 12:15 - 道歉：要清楚我試圖通過“成比例”來理解的是我們是否會通過將大量精力集中在某些 Log4J 代碼使用上而較少精力用于其他代碼，從而獲得更好的結果，考慮到在相同的組織作業負載期間我們可以解決其他非 Log4J 漏洞]。
我對該漏洞有基本的了解，例如來自https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021- 44228-log4j-2-exploitation/，其中不良行為者發送包含 JNDI 命令的 HTTP 訊息，然后在程式下一次嘗試寫入日志時執行該訊息。對于面向公眾的應用程式來說，那里的風險似乎很明顯，讓我想起了眾所周知的 SQL 注入攻擊（我想到了經典的姓氏：SMITH;DROP TABLE CUSTOMERS）。
但是一個“全面”的解決方案正在尋求降低軟體的風險，例如
- 內部 Java Web 應用程式，通過防火墻和 DMZ 等技術受到外部世界（內外）的保護
- 我希望在執行程序中不受篡改的內部 Java 批處理程式
- Citrix 虛擬桌面確實可以在管理員模式下運行，具體取決于用戶，但我希望從外部世界完全無法訪問。
到目前為止，我聽到的關于“全面”的唯一理由是，壞人可能能夠通過隧道進入網路并導致 Log4J 漏洞被執行，但在這種情況下，壞人似乎可以隧道進入網路network 可以直接執行自己的惡意軟體，而不必費心尋找使用早期版本 Log4J 的程式。
uj5u.com熱心網友回復：
考慮了@f1sh 和@hfontanez 的評論并與更多人交談后，我很高興我了解了此漏洞的獨特方面，即盡管在安全環境中運行，內部應用程式仍應被視為易受攻擊的方面。
我認為這個漏洞的顯著特點是問題在日志記錄的程序中表現出來，并且日志記錄無處不在。日志記錄甚至發生在本身試圖處理企圖入侵的代碼中，這方面可能會打開來自不良行為者的新攻擊線。
關于在安全組織中運行內部代碼，我知道有可能在組織外部發生一系列事件，最終可能導致 Log4J 漏洞在組織內部被利用。目前，這可能比現實更有可能，但鑒于此漏洞的獨特性質，它可能會使此類攻擊更容易執行。
消除此漏洞的一點是確保內部應用程式在不需要的情況下無法在組織外部進行網路呼叫的重要性，并且任何對外部的有效呼叫都僅限于需要的范圍。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/396809.html
上一篇：如何修復Wordpress中的DDOS攻擊和強制攻擊？
下一篇：隱藏在jpg中的資料