CWE-532 Project: TechCorp Internal Chat System

Overview

CWE-532: Insertion of Sensitive Information into Log Files is a critical security weakness where applications log sensitive data (passwords, tokens, private messages) that can be exploited by attackers.

Business Case: TechCorp Internal Chat System

Scenario: TechCorp is a mid-sized technology company rolling out an internal team chat platform for 50-100 employees across Engineering, Marketing, and Operations departments. Their goal is to use this tool to streamline internal communication for employees to chat with personnel of any department to allow for easier cross-department synchronicity.

• Registration requires invite code (TECHCORP2025) shared during onboarding
• Username/password authentication for existing employees
• Logging enabled during "pilot phase" to troubleshoot authentication issues
• System shows most recent activity on the server so that IT can determine root cause of issues

The Vulnerability: During the pilot phase, developers enabled comprehensive debug logging to diagnose issues. In case of issues, they wanted a complete picture of recent events on the chat server to help them diagnose:

• Employee passwords during login attempts
• Invitation codes during registration
• Private message content between employees
• All authentication credentials

Attack Scenarios

Scenario 1: Disgruntled Employee

Attacker Profile: TechCorp employee was not given a raise they were working hard to get for the last 2 years.

1. They know the invitation code from their own onboarding (TECHCORP2025)
2. Authenticates successfully and uses LOG command to view recent server logs
3. Extracts employee passwords from failed/successful login attempts
4. Harvests private messages between employees discussing confidential projects
5. Uses stolen credentials to access other TechCorp systems (email, file servers, databases)
6. Leaks company information to direct competitor

Scenario 2: Leaked Invitation Code

Attacker Profile: External threat obtained the invitation code:

• Committed to public GitHub repo
• Visible on office photographs
• Never changed over the years

1. Attacker finds TECHCORP2025 in a GitHub commit history search
2. Registers account, authenticates, and runs LOG command repeatedly
3. Automates log extraction over days to capture:
   • All employee credentials as they authenticate
   • Confidential messages about product launches, discussions, financial data

Scenario 3: Social Engineering Attack

Attacker Profile: Sophisticated phisher targeting TechCorp employees

1. Attacker calls TechCorp reception desk posing as new hire: "Hi, I start Monday in Engineering. HR was supposed to email me the chat invitation code but I can't find it. Can you help?"
2. Helpful receptionist provides the code: "Oh sure, it's TECHCORP2025. Welcome aboard!"
3. Attacker registers account using believable username (sarah_eng)
4. Monitors logs to identify high-value targets (executives, admin accounts)
5. Uses extracted passwords to impersonate authenticated personnel

Scenario 4: Third-Party Vendor Access

Attacker Profile: Contractor working for TechCorp's IT support vendor

1. Vendor employee legitimately receives invitation code for support purposes
2. Vendor employee (curious or malicious) registers personal account
3. Periodically checks logs to gather intelligence on TechCorp operations
4. Sells harvested credentials on dark web forums

Project Files

VulnerableServer.java

Key Vulnerabilities:

1. Password Logging During Login
2. Credential Logging During Registration
3. Message Content Logging
4. LOG Command Access
5. Debug Mode Enabled

FixedServer.java

Security Improvements:

1. Debug Mode Disabled
2. Sanitized Login Logging
3. Sanitized Registration Logging
4. Metadata-Only Message Logging

Client.java

Simple chat client.

How to Run

Compilation

javac vulnserver/VulnerableServer.java

javac fixserver/FixedServer.java

javac client/Client.java

NOTE:

Please choose one server version, and ensure the server is running prior to running clients. You can run as many clients in separate terminals as you like. Each of -server- or -client- requires its own instance of terminal.

IF RUNNING SERVER AND CLIENT ON SCHOOL SERVERS, PLEASE ENSURE YOU ARE CONNECTED TO THE SAME MACHINE (CSX1, 2, 3) BECAUSE CLIENTS ATTEMPT TO CONNECT TO SOCKETS ON THE SAME LOCAL MACHINE

Running the Vulnerable Server

java vulnserver.VulnerableServer

Running the Fixed Server

java fixserver.FixedServer

Running the Client

In a new terminal (for each unique client):

java client.Client

Exploitation

The actual attack.py file is sophisticated enough to be realistically usable by a bad actor, allowing the attacker to decide length of time and number of times to run the log file. An attacker would let this program run over a long period, extracting as much data as possible and parsing that data using regular expressions to find sensitive information.

IMPORTANT: The python script takes command line arguments. On no arguments, default values are used. Invitation code only exists to visualize a real attack vector - this will not work with any other codes at this time (use defaults).

Running the Attack Script

python exploit/attack.py [OPTIONS]

Available Options:

• -d <seconds> - Duration to monitor logs (0 = single poll, default: 0)
• -i <seconds> - Polling interval between checks (default: 60)
• -u <username> - Attacker username (default: badguy)
• -p <password> - Attacker password (default: pwnd)
• -c <code> - Invitation code (default: TECHCORP2025)

Examples:

python exploit/attack.py

python exploit/attack.py -d 300 -i 30

python exploit/attack.py -u hacker -p password123 -c TECHCORP2025

Mitigation Strategies

1. Disable Debug Logging in Production

private static boolean debugMode = false;

In the scope of this project, this act is sufficient to prevent the exploit from working. However, we cannot be certain that no other bugs exist across the rest of the code that may expose our logging information to bad actors. The same server written in a variant of C may be exposed to buffer overflow attacks, which can redirect code execution to force debugMode functions to be called. Logs can still leak, files can still be misconfigured, and end-points can still be unsecure - so this is actually a mitigation step - see below for more concrete prevention strategies.

2. Sanitize Log Entries

Never log:

• Passwords or password hashes
• API keys, tokens, session IDs
• Invitation codes or access codes
• Message content or private data
• Credit card numbers, SSNs, PII

Instead, log:

• Usernames (if not considered PII)
• Timestamps and event types
• Success/failure status
• Metadata, not content

3. Implement Access Controls on Logs

• Restrict log access to security/operations teams only
• Remove user-accessible log commands from production

4. Regular Security Audits

• Review all log(), println(), write(), and other relevant calls for sensitive data

5. Encrypt Log Files

If logs must contain sensitive data:

• Encrypt log files
• Implement deletion policies

6. Monitor Log Access

• Audit who accesses log files and when
• Alert on unusual log access patterns
• Implement least-privilege principle for log readers