Introduction
Recently, during a penetration test for a client, I discovered a peculiar SQL injection. It was peculiar because the database connection encoding of the system was inconsistent with the actual database encoding, and the database table field names used Chinese characters, making it impossible to retrieve database data through normal means.
The Story Begins
1. After obtaining the asset list, I found a site like this.
2. I conducted a simple test and found that the page had no CAPTCHA, no password verification limit, allowing for brute force attacks. However, after a round of brute forcing, I did not obtain any usable accounts.
3. I obtained the phone numbers of the person in charge and the maintainer from the system asset list.
4. Using the person in charge’s phone number as the account, I brute-forced a weak password 186xxxxxxxx/12345678 to log into the system.
5. After briefly reviewing the page, I found that the following page contained a base64 encoded sid parameter, which decoded to the phone number 186xxxxxxxx. Changing it to 186xxxxxxxx’ and re-encoding would result in an error.
6. At this point, I was very excited, as it was clear that there should be an SQL injection based on error display. Without further ado, I used SQLMAP, which successfully identified the injection point and revealed that the database user was an administrator.
sqlmap -r sql.txt -p sid --tamper base64encode --technique E --is-dba7. Thus, this vulnerability was confirmed. I initially did not want to dig deeper, but then I discovered that the system had a backend page, so I wanted to retrieve an account from the database to log in and take a look.
8. When I skillfully used SQLMAP to retrieve the field names, I was stunned; the developer actually used Chinese field names.
sqlmap -r sql.txt -p sid --tamper base64encode --technique E -D CANTEEN -T XXX_INFO_USER --columns
9. Following the usual command to dump a few data entries, it indeed did not return any results.
sqlmap -r sql.txt -p sid --tamper base64encode --technique E -D CANTEEN -T XXX_INFO_USER -C 工号,密码 --start 1 --stop 3 --dump
10. At first, I thought it was just a compatibility issue with SQLMAP regarding Chinese characters, so I tried several methods without success:
Not using error-based injection, but using boolean blind injection
Running on Linux
—encoding GBK/—encoding UTF-8, etc.
Setting the cmd page encoding to utf8
11. So, I used SQLMAP’s debug output to examine the data packets and discovered something strange: the error page actually had two types of encoding!
sqlmap -r sql.txt -p sid --tamper base64encode --technique E -D CANTEEN -T XXX_INFO_USER -C 工号,密码 --start 1 --stop 3 --dump -v 7
12. To verify my hypothesis, I replayed SQLMAP’s request on Burp Suite. Indeed, the web database connection encoding was inconsistent with the backend database encoding. The current Burp setting was utf8, so I suspected that the garbled part in the image below was encoded in gbk. The correctly encoded part in the red box in Figure 11 happened to be the garbled part in Burp, so I speculated that SQLMAP was using gbk for decoding display.
13. At this point, I had a moment of frustration. After venting, I still had to think of a solution, as the work still needed to be done. I reorganized the character encoding conversion process and encoded the field names as follows. Yes, you read that correctly; it was indeed encoded into an abnormal character, and SQLMAP correctly identified the encoding, successfully retrieving the data:
sqlmap -r sql.txt -p sid --tamper base64encode -T XXX_INFO_USER -C 宸ュ彿,瀵嗙爜 --start 1 --stop 3 --dump
Principle Analysis
1. From the above experiment, I suspect that the encoding of the web middleware connecting to the database is gbk, while the actual encoding of the database field names is utf8.
2. To summarize the data flow from the user-initiated HTTP request to the database, the key encoding process is as follows (the following is just my not-so-professional understanding and may not be accurate). The key issue is that the payload input to SQLMAP is encoded into a byte stream using gbk, and then decoded by the database using utf8.
3. Since we know the encoding logic, we can reverse the encoding to allow the database to receive the correct Chinese string. For example, if the two characters of the password need to be decoded by the database, their byte stream should be \xe5\xaf\x86\xe7\xa0\x81.
ss = '密码'
e = s.encode('utf-8')
print(e)4. The string 瀵嗙爜 also has a byte stream of \xe5\xaf\x86\xe7\xa0\x81 after gbk encoding, so the database can correctly query the Chinese field name:
5. Therefore, r0yanx performed the above operation, encoding the Chinese string first in utf8 and then decoding it in gbk to obtain the string. The Python example code is as follows:
#!/usr/bin/python
s = '密码'
e = s.encode('utf-8')
print(e.decode('gbk'))*This article is an original work by r0yanx and belongs to the FreeBuf original reward program. Reproduction without permission is prohibited.
Recommended Highlights
