So another version of a potential RCE has lightened up the web including some controversy around the disclosure and what’s a vulnerability.
Some Timeline of the Log4j
Below is a timeline of the discovery of Log4Shell and its effects:
- July 2014 – Log4j v2 was released
- Aug 5 2015 – Log4j 2 1.4 was released in response to the previous vulnerabiltiies
- November 26 2021: MITRE assigns the CVE identifier CVE-2021-44228
- November 29 2021: An issue, LOG4J2-3198, is created to fix the vulnerability
- November 30 2021: The commit fixing the vulnerability is pushed to the Log4j codebase
- December 09 2021: On December 9, 2021, a zero-day vulnerability involving arbitrary code execution in Log4j 2 was published by the Alibaba Cloud Security Team and given the descriptor “Log4Shell”.
- December 10 2021: LunaSec publishes an analysis and detailed advisory of the vulnerability
- December 10 2021: Mass scanning and exploitation attempts of the vulnerability are recorded (see: Greynoise analysis)
- December 15 2021: CVE-2021-45046 update
- December 18 2021: CVE-2021-45105 additional CVE with DDoS
- December 28 2021: CVE-2021-44832 gets released with the newer version 2.17.1 and 2.12.4 following briefly after
Analysis
First of all let’s put some context, this vulnerability is not easy to exploit as the original CVE-2021-44228 has kicked off the whole internet’s hornet nest (for good reason)
This vulnerability was original disclosed by Yaniv Nizry a researcher of Checkmarx,
This early disclosure did of course cause a storm as it was released on the web before the team of apache could act on it and publish a resolution…nonetheless CVE was assigned quickly and resolution (2.17.1) was released promptly
The post/disclosure flared up and caused several security researchers to animatedly comment (to say the least).
Immediately after a clarification came from Yaniv that the vulnerability was triggered in an arbitrary mode (not always triggered) and under specific circumstances
With the following comments and a few others that spent quite a lot of time verifying 2.17.0 solidity like 2, 3, 4.
The vulnerability
CVE-2021-44832, with 6.6 CVSS score, concerns non-default scenarios of Log4j versions from 2.0-beta7 up to and including 2.17.0.
following some time another researcher (Aaditya Purani) discovered an alternative way to get a much more malicious version of the RCE:
The controversy was sparked mostly by CVE assignment and the immediate request as there are a lot of applications using config files where you can specify the JNDI address to fetch the JDBC data source as discussed here:
Conclusion
Should you panic and update the whole system? Our suggestion is to assess whether the vulnerability really can affect you with testing (some tooling below). Nonetheless, the 2.17.0/1 remains the most secure and you should consider a path to resolution as per the matrix above or at least perform an assessment if the vulnerability is exploitable, prioritizing the one that are visible from external networks.
“This is why research and reporting of vulnerabilities done by the community is a boon to open source. But It can quickly become a bane if not done responsibly.”
The topic of open source maintenance and disclosure remains hot with the following quotes
“One of the biggest takeaways from the events surrounding Log4j is that it is humanly impossible for maintainers of open source projects to cover each and every attack vector while fixing known vulnerabilities.”
“Irresponsible disclosures stand to undermine the work of open source projects, as well as their maintainers and this issue will only grow bigger if not addressed.”
Early disclosure can expose organizations to vulnerabilities and attacks as clearly happened with the public disclosure on the 9th of December Log4Shell PoC exploit leak following a firm hit by a $5 million ransom demand, following a successful Log4Shell attack after the PoC exploit leaked.
Latest List of vulnerable vendors:
The Log4j library is frequently used in software and the links below provide a non-exhaustive list of vulnerable products:
- Github – CISA Log4j vulnerability guidance
- Github – NCSC-NL Log4j overview related software
- Mvnrepository – Artifacts using Apache Log4j Core
Our deepest support goes to them and all the vendor e-mail that has gone around 🙂
We have instead been silent and helping organizations where they can and if they need more they can ask later (karma anyone )
Some good elements and flow have gone out to test for vulnerability
You can refer to the original existing report here and our overall vulnerability page updated with the latest data here
Recomandations
Some good news and attention from National Cyber Security Centre on cyber security impact. You can see the full post here
The challenges organisations face are, therefore:
- asset inventory and application composition
- where are deployed and how they get affected
- prioritizing the ones that are internet-facing
- monitor and threat model as well as real-world assessment (test and check if you see an answer back)
No Change to the advice:
users should upgrade according to their version of Java.
- Java 8 or later: v.2.17.1, available on Maven Central
- Java 7: v.2.12.4
- Java 6: v.2.3.2
- Older releases: confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.
Mitigation and testing
We are maintaining a mindmap of resolution ourselves to track all the variation and remediation but most importantly how to tackle Vulnerability at scale
check the latest version of the vulnerable vendors
https://github.com/cisagov/log4j-affected-db
Scanners Available:
Scan & Remediation
- Dependency Check
- Appsec Phoenix request access here. we will give access for jan and feb to the unlimited version
- Dependabot
Just scan:
Read More
For more information look at log4shell summary page with details on the flow and the original post on the vulnerability
Other References
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
CISA: https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
CISA Github: https://github.com/cisagov/log4j-affected-db
Apache Vuln page: https://logging.apache.org/log4j/2.x/security.html
