One Article Review
| Source |  Veracode |
|---|---|
| Identifiant | 3775521 |
| Date de publication | 2021-12-10 11:59:05 (vue: 2021-12-10 19:05:34) |
| Titre | URGENT: Analysis and Remediation Guidance to the Log4j Zero-Day RCE (CVE-2021-44228) Vulnerability |
| Texte | A previously unknown zero-day vulnerability in Log4j 2.x has been reported on December 9, 2021. If your organization deploys or uses Java applications or hardware running Log4j 2.x your organization is likely affected. Technical summary Yesterday a new Log4J zero-day vulnerability was reported on Twitter: https://twitter.com/P0rZ9/status/1468949890571337731 . The first PoC (Proof of Concept) of the vulnerability is already available at the time of writing - https://github.com/tangxiaofeng7/apache-log4j-poc According to RedHat (source: https://access.redhat.com/security/cve/cve-2021-44228) it's rated as 9.8 CVSSv3 which is almost as bad as it gets. If successfully exploited on your infrastructure, it will result in attackers being able to perform a RCE (Remote Code Execution) attack and compromise the affected server. Given the relative simplicity of the exploit, it's likely that your incident response team will need to deal with an attack. There are multiple reports that the vulnerability is being actively exploited in the wild and needs to be patched promptly, there's already a patched Log4j version available: https://logging.apache.org/log4j/2.x/security.html Am I affected? To check whether your application is likely affected you must verify: Log4j version – all 2.x versions before 2.15.0 (released today, Friday, December 10, 2021) are affected JVM version - if lower than: Java 6 – 6u212 Java 7 – 7u202 Java 8 – 8u192 Java 11 - 11.0.2 If both are true, your Log4j version is older than 2.15.0 and your Java version patch level is older than listed above, you're almost certainly affected. At this time, it's likely that your internet-facing infrastructure may have been already compromised as this vulnerability is being actively exploited, according to this report: https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-acti… Please bear in mind that even if your application does not use log4j directly its surrounding infrastructure such as the application server, message queue server, database server, network devices may be using that combination of Java and log4j version that expose you to this vulnerability. Remediation Using Java 1.8 or higher? Download the latest Log4j mitigated version 2.15.0 from its download page. If you can't upgrade immediately and are using Java 8u121 or later If the Java version is >= 8u121 it is possible to mitigate the issue by setting com.sun.jndi.rmi.object.trustURLCodebase to false and com.sun.jndi.cosnaming.object.trustURLCodebase to falseIt's still preferable to update log4j version to secure one as soon as possible. Using Java version less than 1.8 Source: https://logging.apache.org/log4j/2.x/security.html In earlier versions of log4j >= 2.10 it is possible to mitigate this issue by Setting the system property formatMsgNoLookups: true Or Set the JVM parameter -Dlog4j2.formatMsgNoLookups=true Or Removing JndiLookup class from the classpath example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class How Veracode helps you to address this problem Thanks to our Software Composition Analysis (SCA) product, you can quickly verify whether an application portfolio that you're scanning with us is affected and at elevated risk of being exploited. To verify whether your applications are using vulnerable versions of log4j, log in to the Veracode Platform. Check versions of log4j that are dependencies of your applications by following this guide: https://docs.veracode.com/r/c_SCA_comps *Please note* Veracode SCA customers are able to scan for this vulnerability across their applications. The entry for the vulnerability in our database is here: https://sca.analysiscenter.veracode.com/vulnerability-database/libraries/apache-log4j-2/java/maven/lid-344173/summary Risk management procedures While the development teams work on finding the impacted applications and update all the relevant dependencies, it is advisable to update your Intrusion Prevention Systems (IPS) rulesets to gain more time to work on the remediat |
| Envoyé | Oui |
| Condensat | *please 2/java/maven/lid 2021 344173/summary 44228 6u212 7u202 8u121 8u192 able above according across actively acti… address advisable affected against all almost already analysis analysiscenter apache application applications are attack attackers attempts available available: bad bear been before being both can cert certainly check class classpath code com com/blog/research/exploiting com/p0rz9/status/1468949890571337731 com/r/c com/security/cve/cve com/tangxiaofeng7/apache com/veracode com/vulnerability combination composition compromise compromised comps concept core cosnaming customers cve cvssv3 database database/libraries/apache day day/ deal december dependencies deploys detection development devices directly dlog4j2 does download earlier elevated ensure entry even example: execution exploit exploited exploited/ expose facing falseit false and finding first following formatmsgnolookups: formatmsgnolookups=true friday from gain gets given gov/vuln/detail/cve govt guidance guide: hardware has have helpful helps here: higher how html https://access https://docs https://github https://logging https://nvd https://sca https://twitter https://www ids immediately impacted incident infrastructure injections internet intrusion io/docs/blog/log4j ips ips/ids issue its jar java jndi jndilookup jvm later latest less level likely listed log log4j lower lunasec management may message mind mitigate mitigated more multiple must need needs network new nist not note* nz/it object older one org/apache/logging/log4j/core/lookup/jndilookup org/log4j/2 organization out page parameter patch patched perform platform please poc portfolio possible preferable prevention previously problem procedures product promptly proof property queue quickly rated rce reach reaching recommend redhat references relative released relevant remediation remote removing report: reported reports research/rogue response result risk rmi rulesets running same sca scan scanning secure server set setting show simplicity software soon source: specialists/advisories/log4j stop successfully such summary sun surrounding system systems team teams technical testing than than: thanks there though time today true trusturlcodebase twitter: unknown update upgrade urgent: use uses using vendor veracode verify verify: version versions vulnerability vulnerable whether which wild will work would writing x/security yesterday you your zero zip https://github |
| Tags | Vulnerability |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.