How to implement analysis of sqlmap time-based inject

1. Preface

How to detect SQL injection?

My answer is: When Party A is doing security, SQL injection detection is relatively easy to do.

1) Error injection detection.

2) Don’t inject bool error reports as false positives are relatively high.

3) Do time-based time injection, contact operation and maintenance to do slow log db recording, monitor sleep, benchmark keyword monitoring, you can add the ID number of the scanning task to the decimal point of the sleep time , convenient for positioning. (p.s. This method can find 99% of SQL injections)

Therefore, when doing time-based time injection, I limit the time error very harshly. However, @chengable is doing security-related work on Party B, and time-based time injection is generally not possible. It is understood that he mainly filters the existence of injection points first, and then detects sqlmapapi.py. I also used sqlmap for testing earlier. The problems I encountered were many false positives and long scanning time. Then I tried sqlmapapi.py. The problem was that the scanning time was too long, and it did not support json format injection (details). However, sqlmap's time injection is relatively accurate. What if you don't want to use sqlmapapi.py? Here I will move out the time-based injection logic of sqlmap.

2. Brief analysis of time-based injection of sqlmap

Complain: the code of sqlmap is not standardized, ugly, and large. Someone recommended me to read the sqlmap source code and learn a lot. Now that I think about it, I gave up early.

So, if you are lazy and don’t want to look at the source code, add --technique=T -v 3 and look at the sqlmap detection payload first.

Looks like I was lazy and found some ways, as you can see from the screenshot:

First, sqlmap stuffed the injection payload of sleep:

First stuffed sleep(5), after it was found that it was executed; then stuffed sleep(0), and finally stuffed it again sleep(5).

Then make a guess. The general check idea is to sleep(5) first, and then sleep(0) if the second delay is successful. If no delay is found, continue sleep(5). If the delay is successful again, a reminder that there may be an injection will appear:

Finally, What is very clever is that in order to prevent false positives, sqlmap uses if judgment conditions to exclude false positives. From the above figure, you can see that sqlmap tests twice to make the equation true and twice to make the equation not true. According to the second delay to determine false positives based on current circumstances.

3. In-depth analysis of the source code

Return to the source code to take a look: Based on some of the previous keywords, let’s go directly to the code to take a look. For example, *appears to be* appears before searching and you see the code of the first step:

sqlmap/lib/controller/checks.py:

What I found here is very close to what I guessed before.

Look for where the payload is, especially the payload with if condition, or use keyword query, and find it here:

sqlmap/xml/payloads/time_blind.xml:

You can see that the payload of each if condition is in the vector field.

4. Closure

The characters before the closed injection point are the key to whether it can be injected.

Observed tools/sqlmap/xml/boundaries.xml, so we also need to refer to the various closure situations here:

5. Determine whether there is a delay

5.1 Method 1

Referring to the previous injection of awvs, I thought of a detection method that is easier to understand. Take the consumption time of 6 normal tests without injected payload, and calculate the average value as the native request time (ori_time).

When the injection time is sleep(5), subtract ori_time from the current time as sleep_time. If sleep_time is less than 4, it is considered that the delay has not occurred. (Here, considering that ori_time is affected by the network and becomes larger, the threshold is adjusted to four seconds)

When the injection time is sleep(0), subtract ori_time from the current time as sleep_time. If sleep_time is greater than 2, it means there is a false alarm in the delay.

5.2 Method 2

Look at the sqlmap code again, they used a mathematical problem that I don’t understand (details)

Follow up: Request. queryPage --->wasLastResponseDelayed You can see that the logic is: take the consumption time of 30 normal tests without injected payload, and put them into kb.responseTimes. Calculate the standard deviation 30 times as deviation, and calculate the slowest response time based on deviation as lowerStdLimit:

Its value is the average of 30 times plus TIME_STDEV_COEFF*standard deviation (deviation). As for TIME_STDEV_COEFF, setting it to 7 can make the judgment accuracy 99.9999999997440%.

Finally determine whether the consumption time of the current request is greater than lowerStdLimit. If it is greater, it means that delay occurs, and if it is less than it means that there is no delay (in addition, when lowerStdLimit is less than 0.5 seconds, lowerStdLimit takes 0.5 seconds).

Emotion tells me that I should choose method one, and rationality tells me that I should choose method two. I still chose method two and measured the injection point (details). Very stable scanning found injection vulnerabilities.

The above is the detailed content of How to implement analysis of sqlmap time-based inject. For more information, please follow other related articles on the PHP Chinese website!