Single column enumeration (-C) broken for Firebird backend

[ptitdoc]

Describe the bug
When using sqlmap against a firebird backend, the -C options does not work properly.

When counting the number of items in the column, the select request appends the database name FIREBIRD_MASTERDB to the column name, which does not exists in a firebird context.

The consequence is that sqlmap shows all rows as NULL.

To Reproduce

1. Run sqlmap with the options -C MY_COLUMN_NAME on an sql injection with a firebird backend
2. See all rows reported as NULL

Expected behavior
sqmap should have a positive count of rows and start enumerating all rows.

Running environment:

• sqlmap version: 1.5.2
• Installation method: pacman -S sqlmap
• Operating system: Archlinux
• Python version: 3.9.1

Target details:

• DBMS: Firebird

Additional context
This problem can be avoided by retrieving the data using a select query.

It is also possible to write a tamper script to clear the invalid database name in all requests:

from lib.core.enums import PRIORITY

__priority__ = PRIORITY.NORMAL

def tamper(payload, **kwargs):

    retVal = payload.replace("FIREBIRD_MASTERDB.","")
    return retVal

[stamparm]

@ptitdoc i can't reproduce this with any technique. Additionally, it is very strange that the "meta" database name FIREBIRD_MASTERDB is going to the payload being sent to the other end.

[stamparm]

Closed this down. Please give more details as I am not able to reproduce this "problem" based on given information

[stamparm]

p.s. i was able to reproduce this with --sql-shell and --sql-query, but you are not supposed to use "meta" database/schema FIREBIRD_MASTERDB in such cases

[stamparm]

p.p.s. with the latest revision --sql-shell and --sql-query should automatically remove that FIREBIRD_MASTERDB too if being used in the user's query

[ptitdoc]

Hello, I confirm that I never added FIREBIRD_MASTERDB explicitely. Also, the database name was only added for the COUNT query (the one counting the number of rows in the columns).

I also use successfully --sql-query to solve this issue.

[ret2src]

Problem

I just observed the same problem with sqlmap version 1.8.6.3#dev.
I can successfully dump actual content with --sql-query, but --dump returns only NULL values.

For example, the following fails:

sqlmap -r sqli_request.txt --batch --level=5 --risk=3 --dump --threads=10 --technique=B --dbms=firebird -T 'USERS' -C 'EMAIL' --no-cast

While the following works:

sqlmap -r sqli_request.txt --batch --level=5 --risk=3 --technique=B --dbms=firebird --no-cast --sql-query 'SELECT EMAIL FROM USERS' 

The number of entries is determined correctly in both cases.

Explanation

As for the differences recorded with -t traffic.txt, I see the following:

Success (i.e., actual values):

GET /endpoint/sqliparam=003224925897' OR NOT ASCII_VAL(SUBSTRING((SELECT EMAIL FROM USERS ROWS 3 TO 3) FROM 1 FOR 1))>112 AND 'eltm' LIKE 'eltm&... HTTP/1.1

Failure (i.e., values are NULL):

GET /endpoint/sqliparam=003224925897' OR NOT (SELECT COUNT(EMAIL) FROM FIREBIRD_MASTERDB.USERS)>0 AND 'azEw' LIKE 'azEw&... HTTP/1.1

Difference is FROM USERS vs. FROM FIREBIRD_MASTERDB.USERS, which seems to be exactly what OP wrote.

Workaround

To work around the issue, you can place OP's tamper script in your distribution's respective tamper script folder and tell sqlmap to use it.

For example, on Arch:

$ cat /opt/sqlmap/tamper/firebirdfix.py

from lib.core.enums import PRIORITY

__priority__ = PRIORITY.NORMAL

def tamper(payload, **kwargs):

    retVal = payload.replace("FIREBIRD_MASTERDB.","")
    return retVal

Next, use the --tamper=firebirdfix.py flag:

$ sqlmap -r sqli_request.txt --batch --level=5 --risk=3 --dump --threads=10 --technique=B --dbms=firebird -T 'USERS' -C 'EMAIL' --no-cast --drop-set-cookie --tamper=firebirdfix.py

@stamparm You might want to take a look at this, as you indicated it should have been fixed for a while now (regression?).

[stamparm]

@ret2src I've pushed a related patch, but I am not sure that it will solve the problem. Thing is that I am not able to reproduce this in any way. Tried with different techniques and different options, on Firebird, and I am always getting proper results

[ret2src]

Maybe it's related to the version? In my case, the affected system ran Firebird 2.5.7

[stamparm]

in my case, it is Firebird 2.0. nonetheless, you should retry with the latest revision (i made some (maybe) related change)