Blind SQL injection with conditional errors for oracle database.

Blind SQL Injection with Conditional Errors (Oracle Database)

Lab Overview

This lab demonstrates a blind SQL injection vulnerability in an Oracle database environment, where data is not directly returned in HTTP responses. Instead, information is extracted by forcing conditional database errors, allowing the attacker to infer results based on whether the application generates an error or behaves normally.

Unlike classic UNION-based SQL injection, this technique relies on Oracle-specific behavior, particularly the use of CASE, TO_CHAR, ROWNUM, and error generation through invalid arithmetic operations (such as division by zero).

The exploitation flow consists of:

• Building boolean-based error logic
• Verifying database structure and table existence
• Extracting data using conditional errors
• Automating password extraction using Burp Suite Intruder

This type of SQL injection is highly effective in Oracle systems because errors can be deliberately triggered to represent TRUE conditions.

Understanding Oracle Blind SQL Injection via Errors

Oracle behaves differently from other database engines like MySQL or PostgreSQL. One key difference is how it handles runtime errors inside expressions.

In this lab, a critical technique is used:

• TO_CHAR(1/0) → forces a database error (division by zero)
• If executed → response changes (TRUE condition)
• If not executed → no error (FALSE condition)

This creates a binary oracle (true/false) response system, which can be exploited to extract data.

Instead of retrieving data directly, we manipulate SQL logic so that:

• TRUE condition → triggers error → observable response change
• FALSE condition → no error → normal response

This allows inference-based extraction.

Step 1: Verifying SQL Injection Context in Oracle

Before extraction begins, we confirm that the injection point allows SQL expression chaining.

Oracle string concatenation is commonly used:

'|| <payload> ||'

This breaks out of a string context and injects SQL logic into the query execution path.

---

Step 2: Verifying Table Existence

Before targeting sensitive data, we verify whether tables exist in the database.

Test 1: Invalid table check

'||(SELECT '' FROM not-a-real-table)||'

If the table does NOT exist:

• Oracle throws an error
• Response behavior changes

If it exists:

• Query executes silently

This helps confirm how the database responds to invalid references.

---

Test 2: Valid table confirmation

'||(SELECT '' FROM users WHERE ROWNUM = 1)||'

This payload confirms the existence of the users table.

Explanation:

• ROWNUM = 1 limits output to one row
• SELECT '' ensures no visible output is returned
• If the table exists → query executes successfully
• If not → error occurs

This confirms that:

• The users table exists
• The injection point executes subqueries correctly

---

Step 3: Building Boolean Error Logic

The core of this attack is forcing Oracle to generate errors based on conditions.

Test payload (true condition triggers error):

'||(SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM dual)||'

Explanation:

• CASE WHEN (1=1) → always TRUE
• TRUE branch executes: TO_CHAR(1/0)
• Division by zero causes Oracle runtime error
• Error = observable response change

This confirms:

• Conditional logic is executed
• Errors can be used as boolean indicators

If condition is FALSE:

• No error is triggered
• Response remains normal

This establishes a true/false inference channel. 

---

Step 4: Determining Password Length (Brute Force Logic)

Once boolean logic is confirmed, we begin extracting data by testing password length.

Main Payload:

'||(SELECT CASE WHEN LENGTH(password) > 1 THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username = 'administrator')||'

How it works:

• If password length > 1 → error triggered
• If password length ≤ 1 → no error

By incrementing the number (1, 2, 3, …), we identify the exact password length.

---

Result inference process:

We repeat:

LENGTH(password) > X

until:

• TRUE stops being triggered at a certain point

This reveals the exact password length.

---

Step 5: Extracting Password Characters (Core Exploitation)

Once the password length is known, we extract it character by character using SUBSTR.

Character validation payload:

'||(SELECT CASE WHEN SUBSTR(password,1,1)='a' THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username = 'administrator')||'

OR

'||(SELECT CASE WHEN SUBSTR(password,1,1)='a' THEN TO_CHAR(1/0) END FROM users WHERE username = 'administrator')||'

The double hyphen is for commenting out the rest of the sql querry on the backend database.

Explanation:

• SUBSTR(password,1,1) extracts first character
• Compares it with 'a'
• If match → error triggered
• If not match → normal response

This creates a character validation oracle.

---

Iterative process:

We repeat for:

• Position 1 → 20 (or discovered length)
• Characters:
  • a-z
  • 0-9

Each correct match produces:

• Error response (TRUE)
  Each incorrect match produces:
• Normal response (FALSE)

This allows full password reconstruction.

---

Step 6: Full Brute Force Strategy(Cluster Bomb Attack) Using Burp Suite Intruder

To automate extraction, Burp Suite Intruder is used.

Attack configuration:

• Attack type: Cluster Bomb
• Payload set 1: character position (1 → password length)
• Payload set 2: character list (bruteforce set)

Why Cluster Bomb is used:

Cluster Bomb allows:

• Testing multiple positions simultaneously
• Testing multiple characters per position
• Full Cartesian combination coverage

---

Intruder logic flow:

For each request:

1. Inject position index
2. Inject character guess
3. Observe response:
   • Error → correct character
   • No error → incorrect character

This transforms manual inference into an automated extraction engine.

Oracle error-based blind SQL injection is especially effective because:

• Errors are highly distinguishable
• CASE statements allow conditional execution
• Arithmetic errors (1/0) are reliable triggers
• SUBSTR and LENGTH functions simplify extraction logic

Unlike time-based attacks, error-based inference is:

• Faster
• More reliable
• Easier to detect in response behavior 

From a security standpoint, this attack produces subtle but detectable patterns.

Indicators include:

• Repeated conditional SQL payloads
• Frequent use of CASE WHEN
• Repeated access to users table
• Systematic variation in input parameters

Security tools such as ModSecurity can detect:

• SQL syntax patterns
• Repeated injection attempts
• Oracle-specific function misuse

Database auditing in Oracle can also log:

• Repeated errors from 1/0
• Suspicious use of SUBSTR and LENGTH
• Unusual query repetition patterns

Root Cause and Remediation

The root cause is insecure SQL construction and lack of input sanitization.

Even though output is hidden, SQL logic is still executed.

Recommended fixes:

• Use parameterized queries (prepared statements)
• Disable dynamic SQL concatenation
• Restrict database privileges
• Avoid exposing Oracle error behavior
• Implement uniform application responses
• Monitor and log SQL error patterns

Additional Oracle hardening:

• Restrict access to system functions like CASE, SUBSTR
• Limit exposure of user tables
• Enable strict auditing