[SOLVED] Cs6035 fall25 log4shell flag1 to 6

Welcome!

For this assignment you will exploit a real world vulnerability: Log4Shell.

This will be a capture-the-flag style project where you will exploit a web application with a vulnerable version of log4j.

A correct solution will output a ‘flag’ or ‘key’. There are 7 tasks to complete for 7 total flags. 6 required and 1 extra credit for a possible total of 102%. You will submit these flags in json format to Gradescope for grading in a file named project_log4shell.json.

There is a template in the /home/log4j/Desktop/log4shell folder of the VM: project_log4shell.json. Copy this file and fill out the appropriate values for the flags found. Submit this file to Gradescope for immediate feedback with the autograder. Your grade will be reflected here in Canvas after the assignment has closed.

You’ll use the same virtual machine you’ve been using. Links to an external site.

If you need to redownload the VMLinks to an external site., do it early in case you run into slow downloads.

The VM username and password is log4j and HangingGardens_600

Go here for project details on the course Github Pages site:

https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/Log4Shell/

Good luck and have fun!

Necessary Disclaimer:
THIS IS A REAL WORLD CRITICAL VULNERABILITY THAT MOST VENDORS HAVE PATCHED BUT THERE STILL COULD BE APPLICATIONS WITHOUT THE PATCH. THIS PROJECT IS FOR EDUCATIONAL PURPOSES ONLY. ATTEMPTING THIS ON REAL APPLICATIONS COULD PUT YOU IN VIOLATION OF THE LAW AND GEORGIA TECH IS NOT RESPONSIBLE.

 

 

 

 

Log4Shell

Important Disclaimer:

This project explores a real-world critical vulnerability (CVE-2021-44228). Any attempt to use these techniques on systems you do not own or have explicit permission to test is illegal and may result in criminal charges. Georgia Tech assumes no responsibility for misuse of this educational material.

Learning Goals of this Project:

Exploring a real world critical Java exploit in the Log4J logger: Log4Shell

By completing this project, students will:

Technical Background

Log4J Framework

Log4J is a widely-used open-source logging framework for Java applications that enables developers to:

Java Naming and Directory Interface (JNDI)

JNDI provides a standardized way for Java applications to:

Lightweight Directory Access Protocol (LDAP)

LDAP serves as a communication protocol for:

The Vulnerability Mechanism

The Log4Shell vulnerability exploits Log4J’s lookup feature, which performs string substitution using the syntax ${prefix:name}. For example:

When Log4J processes a malicious JNDI lookup string, it connects to the attacker-controlled server and executes the retrieved code, leading to complete system compromise.

Here is a visual of the Log4j exploit and how it is accomplished (you can zoom in if this is too small via ctrl + scroll):

 

Required Resources

Essential Reading Materials

Video Resources

Technical Documentation

Practical Examples

Tools and Utilities

Table of contents

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Frequently Asked Question(s) (FAQ)

Start With:

Note: To ensure that the autograder accurately grades your submission, you should create/update your .JSON file in a text editor on the VM and submit from the VM. Do not use a word document program like LibreOffice or Word. The submission must be proper JSON format for the autograder to give credit.

VM Questions

Common troubleshooting steps for VirtualBox:.

Submission and Gradescope

Flag Task Hints and Questions

Resolved [org.springframework.web.HttpMediaTypeNotAcceptableException: Could not parse ‘Accept’ header [Java version 1.8.0_20]: Invalid mime type “Java version 1.8.0_20”: does not contain ‘/’]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Setup

This setup process requires 4 separate terminal windows running simultaneously. Complete each step in order and keep all terminals active throughout the lab.

Step 1: User Authentication and Container Start

You will need to switch users to log in to log4j user via:

Credentials can be found in Canvas on the Log4Shell Assignment page

From the log4j user’s home directory, start the container:

./StartContainer.sh

Success Indicator: Container starts without errors and returns to command prompt.

Step 2: Log Monitoring Setup

Open Terminal Window #2 and navigate to the logs directory:

cd Desktop/log4shell/logs

Monitor application activity using one of these commands:

For application logs:

tail -f cs6035.log

For console debug output:

tail -f console.log

Success Indicator: You should see log output similar to the image below.

**Log Rollover Issue: If logs stop updating, restart the tail command. This happens when log files become too large and rotate to new files.**

Step 3: LDAP Reference Server:

Open Terminal Window #3 and navigate to the target directory:

cd ~/Desktop/log4shell/target

Start the LDAP server:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer “http://172.17.0.1:4242/#Exploit”

Critical Configuration Notes:

It is very important that this matches the port specified in the Malicious server. If your exploit is not working because it is not connecting to the malicious server, your ports likely do not match OR the vm’s IP is not correct.

Success Indicator: Output shows server listening on 0.0.0.0:1389

Step 4: Malicious Payload Server

Open Terminal Window #4 and navigate to your flag-specific directory:

python3 -m http.server 4242

Your malicious .class file must be served from the directory your server is running in.

Port Synchronization: This port (4242) must match the port specified in the LDAP server URL from Step 3.

Success Indicator: Server confirms it’s serving HTTP on port 4242.

Step 5: Network Traffic Monitoring (Flag 2 Required, Others Optional)

Open Terminal Window #5 (if needed) and start a network listener:

nc -nlvp <your_desired_port>

Success Indicator: Output shows listener ready on your specified port.

Development and Debugging

Adding Debug Output to Your Exploit

To monitor debug statements from your Java exploit code:

Setup Verification Checklist

Before proceeding with exploitation, verify all components are running:

Common Troubleshooting

Connection Issues Between Servers

Problem: Exploit not connecting to malicious server

Solutions:

Log Monitoring Issues

Problem: Logs stop updating

Solutions:

Server Startup Failures

Problem: LDAP or HTTP server won’t start

Solutions:

Ready to Proceed

Once all servers are running and verified, you’re ready to begin the exploitation phases. Keep all terminal windows open and active throughout the lab.

 

 

 

 

Introduction Flag

Overview

This introductory exercise will help you understand Log4j fundamentals and verify your exploit environment is working correctly. You’ll learn to identify vulnerable logging patterns and execute your first successful Log4Shell exploit.

Understanding Log4j Logging

Basic Log4j Structure

Log4j is a logging framework that outputs program information defined by developers. A typical log statement follows this pattern:

static Logger log = LogManager.getLogger(RestServlet.class.getName());

log.debug(“ApplicationId: {}”, applicationId);

Key Components:

Log Output Analysis

The code above produces output like this:

Output Breakdown:

Log Levels Explained

Log levels control output verbosity:

Current Configuration: This application is set to DEBUG level, showing all message types.

Vulnerability Identification

The Attack Vector

The vulnerability exists wherever user-controlled input is logged without sanitization. In our example:

log.debug(“ApplicationId: {}”, applicationId);

The applicationId variable can contain malicious Log4j lookup expressions that will be processed and executed.

Initial Application Testing

Environment Verification

Before attempting exploits, verify the application responds correctly to normal requests.

Required Header: All requests must include the GATECH_ID header.

Basic Connectivity Test

Open a new terminal and execute:

curl ‘http://localhost:8080/rest/wizards/isAlive’ -H ‘GATECH_ID:123456789’ -H ‘Accept:application/json’

Analyzing the Response

Switch to your log monitoring terminal to examine the output. Look for:

Expected Output:

Note: You can zoom in by using ctrl + scroll

Identifying Exploit Opportunities

From the log output, you should see the application logging:

First Exploit: Java Version Lookup

Target Headers

The application checks and logs these headers (not all may be exploitable):

Constructing the Payload

Your goal is to create a Log4j lookup expression that retrieves the Java version from the server.

Executing the Exploit

Craft a curl command that includes your malicious payload in one of the target headers. The payload should use Log4j’s lookup syntax to extract system information.

Success Verification

If successful, you should see output similar to:

Success Indicator: Look for Java version information in the logs. You may need to scroll up to find the output.

Expected Result: The logs should display detailed Java runtime information, confirming successful exploitation.

Understanding Your Success

What Just Happened?

Security Implications

This demonstrates how Log4Shell can be used for:

Next Steps and Exploration

Additional Lookups to Try

Experiment with other Log4j lookup expressions:

Important Reminders

Save Your Work: Regularly save your progress outside the VM to prevent data loss from system crashes or unexpected issues.

Troubleshooting

No Log Output Visible

Exploit Not Working

Success Confirmation

You’ve successfully completed this section when:

FLAG 1: Environment Echo (5 pts)

Overview

This exercise builds upon your Log4Shell foundation by targeting environment variables. You’ll use Log4j lookup expressions to extract sensitive configuration data stored in the server’s environment, specifically the ADMIN_PASSWORD variable containing your flag.

Prerequisites

Required Completion

Before attempting this flag, ensure you have successfully completed:

Verification Steps

Confirm your environment is ready by checking:

Environment Setup

Container Initialization

If not already running, start the vulnerable application:

./StartContainer.sh

Important: Execute this script from the home directory of the log4j user to ensure proper path resolution.

Connectivity Verification

Test the target endpoint to confirm it’s accessible:

curl ‘http://localhost:8080/rest/wizards/isAlive’ -H ‘GATECH_ID:123456789’ -H ‘Accept:application/json’

Expected Behavior:

Understanding Environment Variables

What Are Environment Variables?

Environment variables are key-value pairs that store configuration data outside the application code. They commonly contain:

The Challenge

Your objective is to extract the ADMIN_PASSWORD environment variable, which contains the flag for this exercise.

Attack Vector Selection

From your intro flag experience, you know that HTTP headers are logged and processed. You’ll need to:

Success Verification

When successful, you should see log output similar to:

Flag Format

Look for the specific message pattern: “Congratulations! Your flag1 is: __________“

Submission Requirements

Flag Recording

Once you’ve successfully extracted the flag:

Important Reminders

Simplicity Focus: You do not need Java code, LDAP servers, Python scripts, or other complex tools for this flag. The solution uses only curl and Log4j lookup expressions.

Header Experimentation: If your first attempt doesn’t work, try different headers.

Case Sensitivity: Environment variable names are typically case-sensitive. Ensure you’re using the exact variable name: ADMIN_PASSWORD

Troubleshooting

No Flag Visible

Exploit Not Working

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FLAG 2: Get a Shell (5 pts)

Overview

This exercise demonstrates the most dangerous aspect of Log4Shell: remote code execution (RCE). You’ll craft a malicious Java payload that exploits JNDI/LDAP lookups to gain root shell access on the vulnerable server. This represents a critical security breach that could compromise an entire system.

Prerequisites

Required Completion

Before attempting this flag, ensure you have successfully completed:

Essential Reading

Critical: You MUST read through the suggested readings about JNDI lookups before proceeding. Understanding the underlying mechanism is essential for crafting effective payloads.

Knowledge Requirements

This exercise assumes you understand:

Understanding the Exploit Chain

The Attack Flow

Log4Shell RCE follows this sequence:

Why This Works

The vulnerability exists because:

Environment Setup

Container Initialization

Ensure the vulnerable application is running:

./StartContainer.sh

Connectivity Verification

Test the target endpoint:

curl ‘http://localhost:8080/rest/wizards/isAlive’ -H ‘GATECH_ID:123456789’ -H ‘Accept:application/json’

Multi-Terminal Setup

You should have 5 terminal windows open:

Java Version Verification

Critical Version Requirement

This exploit requires Java version 1.8.0_20 specifically. Other versions have security patches that prevent JNDI lookups.

Version Check

Verify your Java version before proceeding:

java -version

Expected Output:

Version Importance

Why This Matters:

Critical Warning: Using the wrong Java version will waste significant time as your exploit will fail silently. Always verify the version first.

Payload Development

Exploit.java Analysis

Navigate to your Exploit.java file and examine its structure. This file will contain the malicious code that executes when the JNDI lookup occurs.

Payload Objectives

Your Exploit.java should:

Debugging Capabilities

The environment includes logging support for development.

Log File Location: ~/Desktop/log4shell/logs/console.log

Debugging Method:

System.out.println(“Debug message here”);

Monitor your debug output:

tail -f ~/Desktop/log4shell/logs/console.log

Compilation Process

Working Directory

Navigate to the correct directory:

cd Desktop/log4shell/Flagx

Important: Ensure you’re in the correct directory before compilation

Java Compilation

Compile your exploit code:

javac Exploit.java

Expected Result:

Success Indicator: This creates Exploit.class in the same directory

Compilation Troubleshooting

If compilation fails:

Service Coordination

HTTP Server Setup

From the directory containing Exploit.class, start your HTTP server:

python3 -m http.server 4242

Purpose: This serves your malicious Java class to the vulnerable server

Port Management

Critical: Pay close attention to port numbers throughout this exercise. Mismatched ports are a common failure point.

Port Usage:

Service Verification

Ensure all services are running:

Exploit Execution

Payload Construction

Craft a JNDI lookup payload in your attack vector that:

Monitoring Success

Watch for activity across all terminals:

Success Verification

Expected Console Output

When successful, you should see output similar to:

Python server output:

LDAP server output:

NC output:

Shell Access Confirmation

In your netcat terminal, you should receive a shell connection. Test with:

whoami

Expected Response: root

Root Access Achieved

If you see “root” in response to whoami, congratulations! You have successfully:

Flag Retrieval

Navigation

From your root shell, navigate to the flag location:

cd ../..

Flag Execution

Run the flag retrieval program:

java -jar Flag2.jar

Expected Output:

Flag Submission

Add the retrieved flag to your project_log4shell.json file under the “Flag2” field.

Security Implications

This exploit shows how Log4Shell can lead to:

Real-World Impact

In production environments, this level of access could enable:

Troubleshooting

Common Issues

No LDAP/HTTP Server Activity

Symptoms: No requests reaching your servers

Solutions:

Compilation Failures

Symptoms: javac command fails or produces errors

Solutions:

Shell Connection Issues

Symptoms: No reverse shell connection received

Solutions:

Service Coordination Problems

Symptoms: Partial success but missing components

Solutions:

Debugging Strategy

Important Reminders

Java Version Critical: Always verify Java 1.8.0_20 before starting. Wrong versions cause silent failures.

Port Coordination: Mismatched ports are the most common failure point. Double-check all port configurations.

Debug Logging: Use System.out.println statements liberally to trace execution flow.

Multi-Terminal: Keep all four terminals visible to monitor the complete attack chain.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FLAG 3: Config.Properties Surprise (25 pts)

Overview

This exercise demonstrates Log4Shell’s ability to manipulate application configuration files in real-time. You’ll exploit the vulnerability to modify a properties file that controls wizard magic powers, showcasing how attackers can alter application behavior through configuration tampering. This represents an attack that combines file manipulation with application logic exploitation.

Prerequisites

Required Completion

Before attempting this flag, ensure you have successfully completed:

Advanced Concepts Required

This exercise assumes familiarity with:

Environment Setup

Container Initialization

Ensure the vulnerable application is running:

./StartContainer.sh

API Endpoints

The /wizards/ resource provides these relevant endpoints:

GET All Records:

curl ‘http://localhost:8080/rest/wizards/wizardList’ -H ‘GATECH_ID:123456789’

GET By ID:

curl ‘http://localhost:8080/rest/wizards/wizard/<id>’ -H ‘GATECH_ID:123456789’

Configuration Architecture

The application uses a config.properties file stored in the root directory that:

Initial Reconnaissance

Perform preliminary reconnaissance to understand the application behavior:

Reconnaissance Phase

Data Structure Analysis

Execute the list command to examine available wizard records:

curl ‘http://localhost:8080/rest/wizards/wizardList’ -H ‘GATECH_ID:123456789’

Analysis Objectives:

Individual Record Inspection

Select a wizard ID from the list and examine its detailed response:

curl ‘http://localhost:8080/rest/wizards/wizard/<id>’ -H ‘GATECH_ID:123456789’

Key Observations:

Attack Vector Identification

Critical: Look for unusual or “out of place” variables in the logged output that might serve as attack vectors. These could include:

Understanding the Configuration System

Properties File Structure

The config.properties file contains key-value pairs that control application behavior:

Tamper Detection Mechanism

The application includes security measures:

Attack Objective

Your goal is to modify the properties file so that:

Security Filter Analysis

Someone might have tried to roll their own patch and tried to deny requests containing malicious string patterns.

This suggests:

Filter Bypass Strategies

Consider these approaches:

Payload Development

Payload Construction Considerations

Your payload must:

Injection Point Selection

Based on your reconnaissance, identify where user input is logged and processed. This could be:

Testing Strategy

Success Verification

Expected Response Behavior

When successful, wizard API responses should show:

Flag Retrieval

If successful, you should receive your flag in the house field of the response:

Response Analysis

Important: Error messages in the logs are informational and don’t necessarily indicate exploit failure. Focus on:

Troubleshooting

Common Issues

Blank Flag Response

Symptoms: Flag field appears empty or missing

Solution: Restart the container environment:

./stopContainer.sh

./startContainer.sh

Filter Bypass Failures

Symptoms: Payload appears blocked or filtered

Solutions:

Configuration Not Persisting

Symptoms: Properties revert to original values

Solutions:

Injection Point Identification

Symptoms: Unable to locate the attack vector

Solutions:

Debugging Methodology

Security Implications

Configuration Tampering Impact

This exploit demonstrates:

Real-World Consequences

In production environments, configuration tampering could enable:

Important Reminders

Reconnaissance Critical: Careful analysis of logged output is essential to identify the attack vector.

Filter Awareness: Basic string filtering may be in place – prepare bypass techniques.

File Integrity: Maintain all existing properties to avoid tamper detection.

Container Reset: If flag appears blank, restart the container environment.

GATECH ID Target: Use your GATECH ID as the magicPower value.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FLAG 4: Command and Concat (25 pts)

Overview

This exercise demonstrates Log4Shell’s capability for Java deserialization attacks combined with out-of-the-box obfuscation techniques. You’ll exploit a p2p payment endpoint to achieve file creation on the server through malicious object deserialization. The flag name “Command and Concat” provides critical hints about the exploitation technique involving command execution and string concatenation methods.

Prerequisites

Required Completion

Before attempting this flag, ensure you have successfully completed:

Advanced Concepts Required

This exercise requires deep understanding of:

Understanding Deserialization Attacks

What is Java Deserialization?

Java deserialization converts byte streams back into Java objects. When untrusted data is deserialized, it can lead to:

Log4Shell + Deserialization

This attack combines:

The Attack Chain

The complete exploit flow involves:

Environment Setup

Container Initialization

Ensure the vulnerable application is running:

./StartContainer.sh

Target Analysis: Payment Endpoint

API Endpoint Structure

The vulnerable endpoint accepts payment creation requests:

curl -X POST ‘http://localhost:8080/rest/payments/payment’ -H ‘GATECH_ID:123456789’ -H ‘Content-Type:application/json’

–data-raw

‘{

“paymentId”:”1″,

“amount”:”100″,

“payer”: {

“id”:”2″,

“firstName”:”test”,

“lastName”:”test”,

“accountNumber”:”321″

},

“payee”: {

“id”:”1″,

“firstName”:”test”,

“lastName”:”test”,

“accountNumber”:”123″

},

“paymentDateTime”: “2025-03-06T06:00:00.923163”

}

‘

Request Analysis

Key Components:

Initial Reconnaissance

Execute the provided curl command to understand baseline behavior:

curl -X POST ‘http://localhost:8080/rest/payments/payment’ -H ‘GATECH_ID:123456789’ -H ‘Content-Type:application/json’

–data-raw

‘{

“paymentId”:”1″,

“amount”:”100″,

“payer”: {

“id”:”2″,

“firstName”:”test”,

“lastName”:”test”,

“accountNumber”:”321″

},

“payee”: {

“id”:”1″,

“firstName”:”test”,

“lastName”:”test”,

“accountNumber”:”123″

},

“paymentDateTime”: “2025-03-06T06:00:00.923163”

}

‘

Analysis Objectives:

Log Message Format Analysis

Critical: Pay close attention to logged message formats. The hint emphasizes that message formatting is key to exploitation.

Look for:

Payload Development Strategy

File Creation Objective

Your Exploit.java must create a file with these exact specifications:

Execution and Monitoring

Execute your payload while monitoring:

Success Verification

Expected Log Output

Upon successful exploitation, you should see output similar to:

Success Indicators:

File Verification

The exploit should create:

Flag Extraction

The flag appears in the log output after successful file creation. Look for flag information in the logged messages following the postPayment method execution.

Troubleshooting

Common Issues

No File Creation

Symptoms: Exploit executes but file isn’t created

Solutions:

Deserialization Failures

Symptoms: JNDI lookup succeeds but no execution

Solutions:

Injection Point Issues

Symptoms: Payload doesn’t trigger JNDI lookup

Solutions:

Blank Flag Response

Symptoms: Flag field appears empty

Solution: Restart the container environment:

./stopContainer.sh

./startContainer.sh

Debugging Strategy

Security Implications

Deserialization Attack Impact

This exploit demonstrates:

Real-World Consequences

In production environments, deserialization attacks enable:

Important Reminders

Exact Specifications: File must be named Ronnie.txt with content TimeToBleed! exactly.

Hint Utilization: “Command and Concat” directly indicates the exploitation technique.

Log Analysis: Careful examination of log message formats is crucial for finding injection points.

Container Reset: If flag appears blank, restart the container environment.

FLAG 5: PubSub Override (25 pts)

Overview

This exercise demonstrates Log4Shell’s capability to manipulate application messaging systems through configuration file exploitation. You’ll exploit the vulnerability to redirect publish-subscribe communications to alternative topics, showcasing how attackers can intercept and manipulate real-time messaging infrastructure. This represents an attack that combines configuration tampering with message routing manipulation.

Prerequisites

Required Completion

Before attempting this flag, ensure you have successfully completed:

Advanced Concepts Required

This exercise assumes familiarity with:

Environment Setup

Container Initialization

Ensure the vulnerable application is running:

./StartContainer.sh

Target Endpoint

The user update endpoint that triggers the messaging system:

PUT User Update:

curl -X PUT ‘http://localhost:8080/rest/users/user’ -H ‘GATECH_ID:123456789’ -H ‘Content-Type:application/json’ –data-raw ‘{“id”:8,”userId”:”2134″,”userName”:”RSANCHEZ1″,”userRole”:”R&D”,”adminYN”:”Y”}’

Configuration Architecture

The application uses a config.properties file that:

Understanding the Messaging System

PubSub Architecture

The application implements a publish-subscribe pattern where:

Configuration Integration

The config.properties file contains:

Attack Objective

Your goal is to:

Reconnaissance Phase

Log Analysis Preparation

Critical Hint: Look through the cs6035.log to find clues about what this other topic could be.

Execute the user update command while monitoring logs:

curl -X PUT ‘http://localhost:8080/rest/users/user’ -H ‘GATECH_ID:123456789’ -H ‘Content-Type:application/json’ –data-raw ‘{“id”:8,”userId”:”2134″,”userName”:”RSANCHEZ1″,”userRole”:”R&D”,”adminYN”:”Y”}’

Log Output Analysis

Analysis Objectives:

Message Flow Investigation

Monitor the application logs for:

Configuration Manipulation Strategy

Based on previous properties file exploitation knowledge:

Payload Development Strategy

File Creation Objective

Your exploit must:

Execution and Monitoring

Testing Methodology

Success Verification

Expected Log Output

Upon successful exploitation, you should see output similar to:

Verification Steps

Success Indicators

Troubleshooting

Common Issues

Blank Flag Response

Symptoms: Flag field appears empty or missing

Solution: Restart the container environment:

./stopContainer.sh

./startContainer.sh

Topic Discovery Difficulties

Symptoms: Unable to identify alternative topics in logs

Solutions:

Properties File Corruption

Symptoms: Application errors after exploitation attempt

Solutions:

Message Publishing Failures

Symptoms: No messages appear in logs after user update

Solutions:

Debugging Methodology

Security Implications

Message Routing Manipulation

This exploit demonstrates:

Real-World Consequences

In production environments, PubSub manipulation could enable:

Enterprise Messaging Security

Consider the broader implications:

Important Reminders

Log Analysis Critical: Careful examination of cs6035.log is essential to discover alternative topics.

GATECH_ID Requirement: Ensure your GATECH_ID is appropriately included in the published message account number field for valid flag generation.

Container Reset: If flag appears blank, restart the container environment using the provided scripts.

Properties Integrity: Maintain existing properties structure to avoid application errors.

Message Monitoring: Watch the complete message publishing sequence to verify successful exploitation.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FLAG 6: Restful Data (15 pts)

Overview

This exercise demonstrates Log4Shell’s capability to exploit data persistence layers through malicious record injection. Unlike previous flags that focused on real-time request processing (“data in transit”), this challenge explores “data at rest” exploitation where malicious payloads are stored in databases and triggered during subsequent data retrieval operations. This represents a persistence attack that combines database manipulation with delayed payload execution.

Prerequisites

Required Completion

Before attempting this flag, ensure you have successfully completed:

Advanced Concepts Required

This exercise assumes familiarity with:

Environment Setup

Container Initialization

Ensure the vulnerable application is running:

./StartContainer.sh

Wizards API Endpoints

The /wizards/ resource provides comprehensive CRUD operations:

GET All Records:

curl ‘http://localhost:8080/rest/wizards/wizardList’ -H ‘GATECH_ID:123456789’

GET By ID:

curl ‘http://localhost:8080/rest/wizards/wizard/<id>’ -H ‘GATECH_ID:123456789’

GET By House:

curl ‘http://localhost:8080/rest/wizards/wizard?house=exampleHouse’ -H ‘GATECH_ID:123456789’

POST Create/Update:

curl -X POST ‘http://localhost:8080/rest/wizards/wizard’

-H ‘GATECH_ID:123456789’

-H ‘Content-Type: application/json’

-d ‘{

“name”: “wizard”,

“wand”: “occulus”,

“magicPower”: “skill”,

“powerLevel”: 1,

“house”: “maxwell”

}’

Database Architecture

The application uses an in-memory database that:

Understanding Data at Rest Exploitation

Attack Vector Distinction

Data at Rest vs. Data in Transit:

Database Persistence Strategy

The exploitation process involves:

Target Configuration

Similar to previous flags, you must:

Reconnaissance Phase

Initial Data Structure Analysis

Examine the existing wizard structure:

curl ‘http://localhost:8080/rest/wizards/wizardList’ -H ‘GATECH_ID:123456789’

Analysis Objectives:

Endpoint Behavior Investigation

Test each endpoint while monitoring logs to understand:

Log Output Pattern Analysis

Critical: You will need to inspect logs for each of the endpoints to come up with a successful attack strategy.

Monitor application logs during:

Attack Vector Development

Malicious Record Design

Your malicious wizard record must:

Field Selection Strategy

Consider which wizard fields are most likely to:

Payload Construction Considerations

Hint: The obfuscation technique in this flag will be different than previous ones. Try out the KISS approach on this.

Payload Development Guidelines

Simple Payload Construction

Following the KISS principle, start with basic Log4j syntax:

Database Persistence Verification

Ensure your malicious record:

Success Verification

Expected Log Output

Upon successful exploitation, you should see output similar to:

Verification Sequence

Success Indicators

Troubleshooting

Common Issues

Blank Flag Response

Symptoms: Flag field appears empty or missing

Solution: Restart the container environment:

./stopContainer.sh

./startContainer.sh

Note: This will delete all persisted records due to in-memory database

Payload Not Triggering

Symptoms: Malicious record created but no LDAP callback occurs

Solutions:

Record Persistence Failures

Symptoms: Malicious record not successfully stored

Solutions:

Configuration Update Failures

Symptoms: LDAP callback occurs but config.properties not updated

Solutions:

Debugging Methodology

Security Implications

Data Persistence Attack Vectors

This exploit demonstrates:

Real-World Consequences

In production environments, data at rest exploitation could enable:

Database Security Implications

Consider the broader impact on:

Important Reminders

Data at Rest Requirement: This flag specifically requires a data at rest approach – data in transit methods will not work.

KISS Principle: Use simple, straightforward payload construction rather than complex obfuscation techniques.

Database Reset: Container restart will delete all records due to in-memory database architecture.

Log Inspection Critical: Carefully analyze logs from each endpoint to identify successful trigger points.

Wizard ID Tracking: Note the assigned wizard ID for proper config.properties update.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FLAG 7 (Extra Credit): SQL Attack Authorization Persuasion (2 Pts)

Overview

This extra credit exercise represents a unique database exploit through log4shell. Unlike traditional SQL injection attacks that exploit application queries, this challenge requires using Log4Shell to execute arbitrary code that directly manipulates the database at the system level. You’ll demonstrate persistence techniques by injecting a malicious user record that bypasses application authorization controls, showcasing how Log4Shell can be weaponized for privilege escalation and access control circumvention.

Prerequisites

Required Completion

Before attempting this flag, ensure you have successfully completed:

Advanced Concepts Required

This exercise assumes mastery of:

Environment Setup

Container Initialization

Ensure the vulnerable application is running:

./StartContainer.sh

Target Endpoint Analysis

The user deletion endpoint that enforces admin authorization:

DELETE User by ID:

curl -X “DELETE” ‘http://localhost:8080/rest/users/user/<id>’ -H “GATECH_ID:123” -H “X-NetworkUserId:MWAD10”

Authorization Architecture

The application implements strict access controls where:

User List Inspection

Examine existing users for authorization testing:

curl ‘http://localhost:8080/rest/users/all’ -H ‘GATECH_ID:123456789’

Understanding the Attack Challenge

Non-Traditional SQL Attack

Critical Distinction: This is NOT a typical SQL injection attack

Log4Shell Execution Context

Key Constraint: Log4shell does not allow you to interact with the program’s state itself, only execute arbitrary code at the level of access the vulnerable program itself is running on.

This means:

Attack Objective Requirements

You must create a user with specific attributes:

Reconnaissance Phase

Database Information Gathering

Critical Hint: Look in the logs for information on the database, the schema, and what could be useful for this attack.

Analyze application logs for:

Log File Analysis Strategy

Systematic Log Examination Required:

Schema Discovery Objectives

Look for information about:

Attack Vector Development

Multi-Stage Attack Strategy

Hint 2: You will need to leverage one of the previous flags’ curls to get the keys to unlock this flag.

Java Standard Library Exploitation

Constraint: You will not need anything outside the java standard library for this attack.

Focus on Java built-in capabilities:

Direct Database Manipulation Strategy

Since traditional SQL injection won’t work:

Technical Implementation Considerations

Database Connection Strategies

Depending on discovered database type:

User Record Construction

Ensure proper record format:

Success Verification

Expected Log Output

Upon successful exploitation, you should see output similar to:

Verification Sequence

Success Indicators

Troubleshooting

Common Issues

Database Access Failures

Symptoms: Unable to establish database connection or access

Solutions:

User Insertion Failures

Symptoms: EDBOY user not created or missing required attributes

Solutions:

Authorization Still Failing

Symptoms: DELETE operation still denied despite EDBOY creation

Solutions:

Flag Generation Issues

Symptoms: Authorization succeeds but no flag appears

Solutions:

Debugging Methodology

Security Implications

Advanced Persistence Techniques

This exploit demonstrates:

Real-World Consequences

In production environments, this attack could enable:

Enterprise Security Implications

Consider the broader impact on:

Important Reminders

Log Analysis Critical: Thorough examination of both log files is essential to discover database configuration and schema information.

Java Standard Library Only: Use only built-in Java capabilities for database manipulation – no external libraries required.

Previous Flag Integration: Leverage techniques from previous flags as delivery mechanisms for this advanced payload.

Exact User Attributes: EDBOY user must have precise userName, userRole, and adminYN values as specified.

GATECH_ID Requirement: Ensure your GATECH_ID is appropriately included for valid flag generation.

System-Level Thinking: This requires direct database manipulation, not traditional application-level SQL injection.

 

 

 

FLAG 8 (Extra Credit): Pen Testing Challenge (2 pts)

Overview

This extra credit exercise represents the ultimate Log4Shell penetration testing challenge. Unlike previous flags that provided specific attack vectors and detailed guidance, this challenge simulates real-world penetration testing where attackers must discover vulnerabilities through systematic reconnaissance and creative exploitation. You’ll demonstrate mastery of all previous techniques while developing the critical thinking and methodical approach essential for professional security assessment.

Prerequisites

Required Completion

Before attempting this flag, ensure you have successfully completed:

Advanced Concepts Required

This exercise assumes complete mastery of:

Environment Setup

Container Initialization

Ensure the vulnerable application is running:

./StartContainer.sh

Available Attack Surfaces

You have access to all previously explored endpoints and techniques:

Endpoint Selection Freedom

Critical Note: You can choose to use whichever one you prefer.

This means:

Understanding the Pen Testing Challenge

Real-World Simulation

This challenge simulates authentic penetration testing where:

Discovery-Based Methodology

Key Challenge: The attack vector will not be given and you might even need to use a couple steps to reveal the attack vector.

This requires:

Information Gathering Priority

Critical Requirement: Pay very close attention to every log message, hint, error, etc as it will be vital to figuring out the sequence of events.

Focus on:

Reconnaissance Methodology

Systematic Endpoint Analysis

Since no specific attack vector is provided, systematically analyze all available endpoints

Log Analysis Strategy

Comprehensive Log Monitoring Required:

Hidden Functionality Discovery

Look for indicators of:

Professional Pen Testing Approach

Systematic Testing Methodology

Documentation and Tracking

Maintain detailed records of:

Persistent Investigation

When initial attempts fail:

Success Verification

Success Indicators

Verification Process

Submission

For this flag, you will need to append your “key” to the generated flag hash in the following format.

“flag8”: “fullKey:a703a52cb1c6d955c1e521fbd8c9c0af393ef94aa2a922a680c8a12ab16daa4d”

Troubleshooting

Common Challenges

Attack Vector Not Obvious

Symptoms: Unable to identify clear exploitation opportunities

Solutions:

Multi-Stage Attack Confusion

Symptoms: Partial success but unable to complete exploitation

Solutions:

Log Analysis Overwhelm

Symptoms: Too much information to process effectively

Solutions:

Flag Generation Failures

Symptoms: Exploitation attempts don’t generate expected flag

Solutions:

Debugging Methodology

Security Implications

What You’ve Demonstrated

Professional Penetration Testing Skills

This challenge demonstrates:

Real-World Penetration Testing

The skills developed here directly apply to:

Advanced Attack Sophistication

Consider the implications of:

Important Reminders

No Guidance Provided: This challenge intentionally provides no specific attack vector – discovery is part of the exercise.

Multi-Stage Possibility: Be prepared for attacks requiring multiple steps or techniques in sequence.

Every Detail Matters: Pay close attention to all log messages, errors, and subtle behavioral changes.

Systematic Approach: Use professional penetration testing methodology for comprehensive coverage.

GATECH_ID Integration: Ensure your GATECH_ID is properly included in the final exploitation chain.

Documentation Critical: Maintain detailed records of your discovery and exploitation process.

Persistence Required: Real penetration testing requires methodical investigation and creative thinking.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Project Submission Instructions

Submission Platform

This project must be submitted through Gradescope for automated grading.

Access Gradescope:

Grading Information

Important: Always verify your intended submission is marked as “active” before the deadline.

File Preparation

Required File Format

Create a file named project_log4shell.json containing your collected flags in proper JSON format.

Template Location

A pre-formatted template is available at:

~/Desktop/log4shell/project_log4shell.json

Recommended Text Editors

Use only plain text editors:

Critical: Do NOT use LibreOffice, Microsoft Word, or any rich text editors. These applications introduce special characters that will cause the autograder to fail.

JSON File Structure

Template Format

{

“flag1”: “<copy flag 1 here>”,

“flag2”: “<copy flag 2 here>”,

“flag3”: “<copy flag 3 here>”,

“flag4”: “<copy flag 4 here>”,

“flag5”: “<copy flag 5 here>”,

“flag6”: “<copy flag 6 here>”,

“flag7”: “<copy flag 7 here>”

}

Completed Example

{

“flag1”: “4ec60c3e084d8387f0f33916e9b08b99d5264a486c29130dd4a5a530b958c5c0f1faeaca2ce30b478281ec546a4729f629b531a86cb27d86c089f0c542”,

“flag2”: “f496d9514c01e8019cd2bc21edfeb8e33f4a29af14a8bf92f7b3c14b5e06c5c0f1faeaca2ce30b478281ec546a4729f629b531a86cb27d86c089f0c442”,

“flag3”: “b621bba0bb535f2f7a222bd32994d3875bcfcad651160c543de0a01dbe2e0c5c0f1faeaca2ce30b478281ec546a4729f629b531a86cb27d86cf0c49542”,

“flag4”: “b34235hjghg34g23g4uy23g4yg12h1j2g4f12hj4gj1h2g4g12h4g12h4ghj12g4jh1g24khj1g24jhg1k4gh1h24g1j24h1g24hjg124hg12k4hg1hj4gj1h2”,

“flag5”: “6kj2348932ur98wef89yawfsf89asdyf87adtsguihasidogy87dsghiausdyg87adshgo87dshg9ueg90ojawoeigj9we8ye8t9yqwethijkfdjfa98y89eje”,

“flag6”: “5g87a8d9sg7a0sd98g79asd87g890as7dg8sadg7ads908gydsiayhgkjtj4tk535j3lk4523j23j4c698ddd5f6a5df67b6xc6vzx786vzx5cv87v8z69xv76”,

“flag7”: “afasdfasfafjealjfeioajfoje8auf98yu943h894yt0894h089tyu89igjnafjaffjafjafasdfua-9eufaiejfiajdskfljaslkdfj;aljsdfl;kajdfkl;a”

}

Pre-Submission Validation

JSON Format Verification

Before submitting, verify your JSON file is properly formatted:

Quick Validation Command

Test your JSON syntax using:

python3 -m json.tool project_log4shell.json

Success: File contents display correctly

Error: Fix syntax issues before submitting

Submission Workflow

Step-by-Step Process

Submission Confirmation

After uploading, confirm:

Troubleshooting Common Issues

JSON Format Errors

Problem: Autograder reports JSON parsing errors

Solutions:

Missing Flags

Problem: Autograder shows 0 points for some flags

Solutions:

File Upload Issues

Problem: Cannot upload file to Gradescope

Solutions:

Final Submission Checklist

Before the deadline, verify:

Deadline: Check Canvas for specific due date and time

Late Policy: Refer to course syllabus for late submission guidelines