Privilege Escalation via SQL Injection in Joomla 3.8.3

It is common knowledge that there are bad people attacking systems on the Internet, regardless of the nature of the business. As a defensive countermeasure, organizations put their trust in solutions for defense from these cyber threats.

The problem with this strategy is the vendor is not the victim of an attack and doesn’t absorb damages from a cyber incident. Vendors will offer protection; however, they can’t be responsible for anything outside of their product’s control.

All it takes is a missing update, configuration error, or millions of situations that can cause a breach for which the vendor will not be liable. Plus, many organizations leverage multi-vendor solutions that don’t share security intelligence, making it possible for liability to be passed back and forth between vendors.

Also Read: Live SQL Injection Exploitation with SQLMAP

For these reasons and more, we recommend the customer take ownership of the responsibility to protect assets by hardening systems from threats.

Today we’ll be demonstrating a Privilege Escalation with the help of SQL Injection vulnerability in Joomla CMS of version 3.8.3 which was released on Tuesday, 12 December 2017.

SQL Injection is one of the many web attack mechanisms used by hackers to steal data from big organizations. It is perhaps one of the most common application layer attack techniques used today. It is the type of attack that takes advantage of improper coding of your web applications that allows hacker to inject SQL commands into say a login form to allow them to gain access to the data held within your database.

In essence, SQL Injection arises because the fields available for user input allow SQL statements to pass through and query the database directly.

By Karim El Ouerghemmi, a second order SQL Injection vulnerability was reported in Joomla by 17th January 2018 which can be found here: https://blog.ripstech.com/2018/joomla-privilege-escalation-via-sql-injection/

Second-order SQL injection arises when user-supplied data is stored by the application and later incorporated into SQL queries in an unsafe way. To detect the vulnerability, it is normally necessary to submit suitable data in one location, and then use some other application function that processes the data in an unsafe way. The only step is to secure or prevent the application from Second Order SQL Injection attacks is to use parameterized queries (Prepared Statements) for all DB access.

Affected CMS – Joomla
Affected Version – <= 3.8.3 and >= 3.7.0
CVE ID – CVE-2018-6376
Vulnerable URL (Testing) – http://localhost/yeahhub/
Severity – Critical/High

It’s true that, Joomla is one of the biggest and popular CMS around the world and is very easy to use. An attacker can easily exploit this vulnerability with SQL Injection and can easily steal the other user’s Session ID values which can further extend to Privilege Escalation attack.

So what scenario is ? Here we setup a vulnerable Joomla instance of version 3.8.3 in our local system under http://localhost/yeahhub and added two roles as shown below:

chetansoni (Manager)
admin (Super Administrator)

Our goal is to escalate privilege from Manager role to Super Administrator role.

So, lets login with the user “chetansoni” and navigate to Edit profile (Edit Account) Page as shown below.

Note: Make sure that you must be logged in as Super user (admin) in some other browser so that a session ID will be available in DB table.

Let’s intercept the profile update request in BURP Suite which is one of the most popular HTTP proxy tool. As shown in figure below, the POST request with multipart-form data goes on the following resource:

http://localhost/yeahhub/administrator/index.php?option=com_admin&view=profile&layout=edit&id=817

From above all parameters, the affected parameter is “forms[params][admin_style]“.

A typical first test for SQL injection vulnerabilities is to use a single quotation mark to close the SQL query. If a SQL injection vulnerability is present, the addition of that quotation mark should cause the application to throw a SQL error, because the query will already be closed as part of the underlying code and the extra single quote will cause the SQL syntax to be incorrect.

That error will tell us that we can inject SQL queries to the site’s database using the vulnerable parameter.

Let’s insert the following payload (a single quote ‘) to the affected parameter as shown below:

Forward the request to the browser which shows “Item Saved” as success message as shown below:

Let’s access the following URL on which the SQL query gets constructed with the injected payload and is executed as shown below:

http://localhost/yeahhub/administrator/index.php

And here’s the snippet for Edit profile Page which you can further confirm this vulnerability, file located at “/administrator/components/com_admin/controllers/profile.php“.

SQLi attacks are usually a result of unescaped input being passed into a site and used as part of a database query. Now that we know a SQL injection vulnerability is present in this site, we can exploit it to run additional queries on the database that the developer never intended.

Let’s try to inject one more payload i.e. “test” in same POST request.

Now let’s, check the error message on affected main dashboard page. We got only first character of the payload in error message i.e. t.

To try further, we injected another payload AND sleep(5);–

And refreshed the dashboard page which results same first character as a result.

Its weird, lets try to check out the DB entry for above injecting payload just to verify it and it seems that the payload got stored properly but here the value treats as an array, so, index 0 of stored value will be consumed to construct a query. Here we got the answer that why only first character of payload was reflecting.

And here’s the affected instance wrt to that code is “administrator/templates/hathor/postinstall/hathormessage.php”

Now, we know that the payload is being treated as an array and index 0 will be consumed in SQL query. So, let’s try to provide an array [“test1″,”test2″,”test3”] as a payload.

Then, we were expecting the 0th index of the array i.e. (“test1”) to be consumed to structure the SQL query.

But as shown in below screenshot, the application reflected “[“ in the error message which means that the entire payload was again treated as a string.

Nope. We came up with an idea to change the parameter name and provide the 0th index of an array “admin_style“.

In below screenshot, we changed the parameter name with “jform[params][admin_style][0]” and injected the same payload to 0th index:

Now, the application reflected our full payload. Though, the payload did not worked but we see the hope at least.

Again, We injected the extractvalue(0x0a,concat(0x0a,(select database()))) to extract database name.

And the application responded with database name “joomla” which is the current DB associated with this Joomla instance.

Yippie, we successfully exploited this. Now let’s fulfil our goal to access the application with Super Administrator privileges.

The following payload will give us the session id of an Super Administrator user “admin“:

Payload: extractvalue(0x0a,concat(0x0a,(select * from n0n8z_session where username=’admin’)))

Now we can use the below session ID to impersonate the Super Administrator user with any cookie editor addon.

SQL Injection is one of the most common application layer attacks currently being used on the Internet. Despite the fact that it is relatively easy to protect against SQL Injection, there are a large number of web applications that remain vulnerable.

Though automated scanners are also great at finding known vulnerabilities in web applications, many clients build custom web applications. Sure, commercial products can automate attacks against user input fields in custom web applications, but nothing can replace a good penetration tester with a proxy when it comes to finding security issues in these applications.

We can also use tools i.e. SQLMAP which is one of the best SQL Injection Exploitation tool to automatically generate SQL queries to perform various tasks on a site using SQL injection.

All we need is an injection point; the tool does the rest.

As it seems that, the above exploitation is of Second Order SQL Injection, so you just need to save the POST request to a file, let’s suppose post.txt and the affected parameter is “jform[params][admin_style][0]“, just run the following command in your machine where SQLMAP is installed.

Command: sqlmap -r <file.txt> –dbms MySQL –second-order “http://localhost/yeahhub/administrator/index.php” -D “joomla” –dbs

To mitigate this, just update your joomla application to the latest version which is v3.8.7 which was released on 18th April 2018.

SQL injection (SQLi) vulnerabilities have been around for a long time, but they still make their way into applications. With credit card data, personal information, and other sensitive information being stored in Web apps, penetration testers need to be able to assess the security of Web applications and be able to create Proofs of Concept (POCs) to help application developers understand the severity of SQLi vulnerabilities and how they work.

Summary –

SQLi can be pretty significant and dangerous for a site. Finding this type of vulnerability could lead to full CRUD permissions to a site. In other cases it can be escalated to remote code execution. The above example from Joomla was actually one such case as there are proofs of attackers executing code via the vulnerability.

When looking for these, not only should you keep your eye out for the possibility of passing unescaped single and double quotes to a query, but also opportunities to provide data in unexpected ways, like substituting array parameters in POST data.

Post Views: 792

You may also like:

Privilege Escalation via SQL Injection in Joomla 3.8.3 – Live Exploitation

Summary –

Sarcastic Writer

Summary –

Related Posts