Lessons Learned from SQL Injection Fix in Joomla 3.7.0

Dingjie Yang

Last updated on: September 7, 2020

The Joomla community recently patched a SQL injection vulnerability introduced in Joomla 3.7.0. The article reporting this vulnerability explains how to identify the vulnerability (which was discovered via static code analysis) and how to craft an attack, e.g.

http://example.com/joomla/index.php?option=com_fields&view=fields&layout=modal&
list[fullordering]=exploitation_code

After reviewing the description of the vulnerability, I wondered whether an automated web application scanner, known as a DAST (Dynamic Application Security Testing) tool, could identify an instance of this vulnerability without digging into the source code.

Qualys WAS (Web Application Scanner) has a good track record performing security audits against Joomla 3.3.3, as evidence by the XSS vulnerability discovered in the Joomla core code in 2014. Based on this past success, I installed the vulnerable Joomla 3.7.0 in our lab and launched an automation scan against it using Qualys WAS.

Detect the SQL Injection Vulnerability with a DAST Tool

As described in the article reporting the vulnerability, the cause of the SQL injection vulnerability in Joomla 3.7.0 is the non-sanitized parameter list[fullordering] in an administrative component feature which can be publically accessed by an unprivileged user. This means scanning the administration panel can expose the vulnerability.

It took less than 10 hours without any manual intervention for Qualys WAS to discover and report the SQL vulnerability after launching a scan against the Joomla administration panel. As an aside, the time required can be reduced by limiting the number of links crawled. Below is a proof of concept (PoC) of this vulnerability as reported in the Qualys WAS scan result:

POST: http://example.com/Joomla_3_7_0/administrator/index.php?option=com_content&view=articles
Content-Type: application/x-www-form-urlencoded
Cookie: 43cebfbc4cfd7f8b22410edf3e395a17=73kk9nqs40poi0c6ctec25rvn
Data: filter[search]=test&list[fullordering]=%20%2B%20(SELECT
%200%20FROM%20(SELECT%20SLEEP(28))qsql)%20&list[limit]=
20&filter[published]=&filter[category_id]=&filt
er[access]=&filter[author_id]=&filter[language]=&
filter[tag]=&filter[level]=&batch[language_id]=&
batch[assetgroup_id]=&batch[category_id]=&batch[mov
e_copy]=m&batch[tag]=&limitstart=0&task=&
boxchecked=0&b3f17395d768016d233d9e467ae2edb0=1

The PoC clearly indicates the parameter list[fullordering] is vulnerable to a SQL injection attack: the exploit code %20%2B%20(SELECT%200%20FROM%20(SELECT%20SLEEP(28))qsql)%20 will make the MySQL Database Server sleep 28 seconds when the request is sent.

More Than a SQL Injection Vulnerability

After spending some time on this vulnerability, I realized that there are two other important security issues besides the SQL injection vulnerability.

CSRF token is not functioning in some requests

The first is that the CSRF token is not required for this function. In the PoC request discovered by WAS engine, the parameter b3f17395d768016d233d9e467ae2edb0 is acting as CSRF token. A CSRF token consists of a random string that is generated and changed per session, which is a robust method to mitigate CSRF attacks. However, in the PoC request, the CSRF token is not required. In other words, the request could still be submitted and processed by the server in the absence of the parameter b3f17395d768016d233d9e467ae2edb0 as shown below:

POST: http://example.com/Joomla_3_7_0/administrator/index.php?option=com_content&view=articles
Content-Type: application/x-www-form-urlencoded
Cookie: 43cebfbc4cfd7f8b22410edf3e395a17=73kk9nqs40poi0c6ctec25rvn
Data: filter[search]=test&list[fullordering]=%20%2B%20(SELECT
%200%20FROM%20(SELECT%20SLEEP(28))qsql)%20&list[limit]=
20&filter[published]=&filter[category_id]=&filt
er[access]=&filter[author_id]=&filter[language]=
&filter[tag]=&filter[level]=&batch[language_id]
=&batch[assetgroup_id]=&batch[category_id]=&
batch[move_copy]=m&batch[tag]=&limitstart=0&
task=&boxchecked=0

Not requiring the CSRF token seems to have been done on purpose by Joomla. I presume this was done because search is generally not a sensitive action. In the absence of the SQL injection vulnerability, CSRF protection would not be needed. On the other hand, the SQL injection is only possible because the CSRF protection isn’t implemented for this action. So it’s the combination of the vulnerability and the lack of protection that makes the application exploitable in this case.

Method Interchange

The second security issue is caused by method interchange, and this makes the vulnerability easier for an attacker to exploit.

Method Interchange vulnerability has been forgotten or ignored by many web masters. Though method interchange itself is impossible to use to exploit some vulnerabilities, it could be combined with other vulnerabilities for a successful attack. In a previous posted blog, I have described how some low level vulnerabilities can lead to a major security vulnerability.

The issue is that the Joomla server will process the search action as either a GET request or a POST request. As described in the article above, “exploiting XSS in a POST parameter requires a GET-to-POST script on a 3rd party server, resulting in a suspicious link with which to exploit a user.” Since a GET request does not require a 3rd party server, there is no suspicious link to tip off the user targeted in the attack. An attacker just needs to send the vulnerable link to the logged-in administration user and trick the user into clicking the following link:

GET: http://example.com/Joomla_3_7_0/administrator/index.php?
option=com_content&view=articles&filter[search]=
test&list[fullordering]=%20%2B%20(SELECT%200%20FROM%20
(SELECT%20SLEEP(28))qsql)%20&list[limit]=20&filter
[published]=&filter[category_id]=&filter[access]=
&filter[author_id]=&filter[language]=&filter
[tag]=&filter[level]=&batch[language_id]=&batch
[assetgroup_id]=&batch[category_id]=&batch[move_cop
y]=m&batch[tag]=&limitstart=0&task=&boxchecked=0
Cookie: 43cebfbc4cfd7f8b22410edf3e395a17=73kk9nqs40poi0c6ctec25rvn

Conclusion

The discovery of this SQL injection vulnerability outlines the fact that even very mature open source web application frameworks could suffer from server security holes. Adopting a DAST solution like Qualys WAS could help organization to quickly identify the security threats in the web application framework they are relying on; especially when there is a lack of resources to do thorough static code analyzing. For web developers, input validation function should be built into their projects and called once a user input is fed into the web applications. Trivial security issues should be treated seriously because many trivial issues could open doors for larger devastating security issues and attacks.

Share your Comments

Comments

Your email address will not be published. Required fields are marked *