Shulou(Shulou.com)05/31 Report--

How to analyze CVE-2018-6376 and second-order SQL injection, in order to solve this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Savan Gadhiya and Amish Patadiya will try to help us understand and discover second-order SQL injection methods and utilization techniques. It will also demonstrate how to use SQLmap to take advantage of second-order SQL injection (that is, do not repeat the wheel).

What is second-order SQL injection?

To prevent SQL injection attacks, some data input into the application is "escape", but the data is reused in query forms that are "Unescaped". At this point, the attacker may inject a PAYLOAD, which forms a SQL query statement and is executed, which is called second-order SQL injection.

Learn more: https://portswigger.net/kb/issues/00100210_sql-injection-second-order

Next, let's further understand [CVE-2018-6376] through the example of second-order SQL injection in Joomla.

Details

Affected Joomla! Version: = 3.7.0

Harm: a low-privilege user (Manager) can be promoted to a higher user privilege (Administrator' or 'Super Administrator').

Injection detection

Now, we have built a version of Joomla 3.8.3! The platform is used to test as shown in the following figure:

We created a user "amish" with "Super Users" permission, and another user "savan" with "Manager" permission, as follows:

Our goal is to upgrade the user with "Manager" permission to "Super Administrator" permission. So now we log in as user 'savan'. The following figure shows the dashboard of user 'savan', and we can also see that Super User' is currently logged in:

We know from the vulnerability report that the affected instance is located on the profile data update page. The following figure shows the profile update page for user 'savan':

Let's use BURP Suite to intercept profile update requests. As shown below, the POST request for form data is sent to the following address:

Http:///joomla/administrator/index.php?option=com_admin&view=profile&layout=edit&id=645

The affected parameter is' forms [params] [admin_style]', and we insert the following payload into the affected parameter, as follows:

PAYLOAD:'(single quotes)

After the request is successfully submitted, the profile update page displays the reference message "saved projects", as shown in the following figure:

The above does not show anything unusual, because the page does not use the injected PAYLOAD to construct the SQL query and execute it. Let's access the following URL, construct the SQL query using the injected payload, and execute it, as shown in the following figure:

Http:///joomla/administrator/index.php

Looking at the source code, we can see that the insertion of PAYLOAD is not easy to implement SQL injection attacks. The following figure shows a code snippet from the file'/ administrator/components/com_admin/controllers/profile.php', highlighting the path to the Edit configuration File function:

When the user updates the profile details, the application retrieves all parameters and returns the JForm object, as shown in the following figure:

The following figure shows that the application stores the retrieved user information in the database:

We have confirmed above that user input is not constructed for SQL queries, so PAYLOAD inserting instances is not easy to attack, so let's take advantage of it on the affected pages. As shown in the following figure, we insert the following string as PAYLOAD to see how the SQL statement is constructed:

PAYLOAD: test

From the error message displayed on the dashboard, we can see that only the first character of PAYLOAD is displayed in the error message.

Then we made a further attempt. We injected another payload'AND sleep (5);-'and refreshed the dashboard. As shown in the following figure, we get the same result:

If we look at the database at this point, we will find that the PAYLOAD we entered has been stored in the database:

After confirming that the payload is stored correctly, let's verify how the affected code constructs the SQL query. The affected instance is from the 'administrator/templates/hathor/postinstall/hathormessage.php' file. As shown in the following figure, line 40 of the code mainly takes the user's input value from the 'admin_style' parameter and passes it to the' adminstyle' variable. In line 47, the code builds the SQL query directly using user-supplied input. Here we think of it as an array, so the stored value with an index value of 0 will be used to construct the query. This is why only the first character can be seen in the error message.

Now that we know that PAYLOAD will be treated as an array, the stored value with an index value of 0 will be used to construct the query. So let's try to provide an array of'["test1", "test2", "test3"]'as PAYLOAD. The purpose of this is to test whether the 0th index (that is, "test1") will be used to construct the SQL query. To my disappointment, however, the error message still shows only the first character "[", which means that the program treats the entire PAYLOAD as a string, as shown below:

I'm a little skeptical about life at this point. Isn't this an available example of SQL injection?

In a flash, we came up with a way to change the parameter name to provide the 0th index of the array 'admin_style'. As shown in the following figure, we changed the parameter name using 'jform [params] [admin_style] [0]' and injected the same PAYLOAD into the 0th index of 'admin_style':

PAYLOAD: AND sleep (5);-

Now we can see that although the PAYLOAD is not executed, our PAYLOAD content can be fully displayed in the error message.

We then inject the following PAYLOAD to get the target database name, and we get the database name 'joomla', as shown in the following figure:

Payload: extractvalue (0x0a concat (0x0a, (select database ()

Now let's achieve our ultimate goal of accessing the application with the privileges of the Super Admin. The following PAYLOAD will get us the session id of the Super Admin user "amish", as shown in the following figure:

Payload: extractvalue (0x0a concat (0x0a, (select * from joomla_session where username='amish')

After successfully obtaining the session id, we can impersonate the Super Admin user to access the application.

Automatic utilization

When in an actual infiltration environment, it is impossible for us to test manually every time, which consumes a lot of our time. So how do we automate our tests?

Here we have to mention the scanning artifact SQLMap injected by sql. SQLMap provides us with a query switch specifically for second-order injection, and we only need to provide the target URL address where there may be second-order injection.

Note / limitation: since this is a second-order SQL injection, we cannot use multiple threads to automatically check the output of each query.

If we provide this instance directly to SQLMap, it may not work properly. To solve this problem, we need to create a query where sqlmap can inject its PAYLOAD and get the data smoothly. We constructed the following PAYLOAD as the value of the parameter 'jform [params] [admin_style] [0]' in the request, and used the SQLMap'- r 'switch to parse the request, as shown in the following figure:

PAYLOAD: extractvalue (0x0a concat (0x0a, (select @ @ version where 1 *))

The'* 'here represents the location where SQLMap is injected into PAYLOAD, for example:

Extractvalue (0x0a AND concat (0x0a, (select @ @ version where 1))

Extractvalue (0x0a AND concat (0x0a, (select @ @ version where 1))

Extractvalue (0x0a OR concat (0x0a, (select @ @ version where 1))

Extractvalue (0x0a order by concat (0x0a, (select @ @ version where 1)

Extractvalue (0x0a union all select NULL,NULL,NULL,'21231231232' concat (0x0a, (select @ @ version where 1)

As shown in the following figure, SQLMap now detects the injection and extracts all database names using the following command:

Sqlmap-r 1.txt-dbms MySQL-second-order "http:///joomla/administrator/index.php"-D" joomla "- dbs

We can easily extract more data through Sqlmap.

Protective measures

In order to avoid the impact of this kind of vulnerability on you, be sure to upgrade your Joomla! To 3.8.5 (the latest version as of the time of release of this article). Joomla! A fix for the code layer is also provided, as follows:

This is the answer to the question on how to analyze CVE-2018-6376 and second-order SQL injection. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.