Joomla! SQL Injection Vulnerability
Recently, details about three serious CVE vulnerabilities in the Joomla CMS platform were released to the public (CVE-2015-7297, CVE-2015-7857, CVE-2015-7858). These CVE’s were discovered by Trustwave SpiderLabs researchers, and full details of the vulnerability can be found in the article that was published: https://www.trustwave.com/Resources/SpiderLabs-Blog/Joomla-SQL-Injection-Vulnerability-Exploit-Results-in-Full-Administrative-Access/ The truth about these vulnerabilities is that they don’t present anything new regarding SQL Injections. This article shows how F5 ASM deals with this kind of zero day attacks. The Joomla! CMS Platform Joomla is a free and open-source content management system (CMS) for publishing web content. It has been downloaded over 50 million times, and there are over 7,700 free and commercial extensions for it. According to Wappalyzer, there are over 500,000 different websites using the Joomla Platform. According to Alexa, 25,000 out of the top 1 Million websites use Joomla. This makes Joomla one of the most popular CMS platforms today, second only to WordPress. Weakness in the Core As mentioned previously, there are thousands of community maintained plugins and extensions for Joomla. It’s not uncommon for vulnerabilities to be discovered in those plugins, even on a weekly basis. However, the vulnerabilities mentioned in this article were found in Joomla core platform – this makes the severity of this vulnerability very high since it affects 100% of Joomla installations (only vulnerable versions of course). The vulnerabilities allows a remote unauthenticated attacker to retrieve sensitive data from within the Joomla database, including active administrator session tokens. This basically allows complete site takeover with very little effort. Probe and Exploit Most of the attack attempts that have been seen in the wild (Source: https://blog.sucuri.net/2015/10/joomla-sql-injection-attacks-in-the-wild.html) follow a similar pattern. This pattern includes sending innocent probe requests prior to sending the actual exploit. Some examples for these probe requests: /index.php?option=com_contenthistory&view=history&list[select]=1 POST /index.php HTTP/1.1 User Agent: “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)” BODY:option=com_contenthistory&view=history&list[select]=testsearch /plugins/system/cache/cache.xml As we can see, the probe requests are varied, but they all have a common goal of discovering whether or not the target website is vulnerable to this attack. The first request is providing the website with an erroneous SQL query, expecting the site to return an SQL error. The second request is similar to the first one, but tries to masquerade itself as a “Googlebot” request. The third request attempts to uncover the actual Joomla version installed on the website. Note: In the latest ASM version, fake Googlebot requests are blocked using the Bot Detection feature. Those requests are being validated by checking the source IP of the request. ASM Mitigation The actual exploitation attack vectors used in this vulnerability were found to be blocked by ASM SQL-Injection attack signatures: As we can see, the attack vectors use various SQL keywords and an SQL query format, which ASM detects and is able to block. We recommend installing the latest ASM signature update file, and making sure your policy is protected with the “SQL Injection Signatures” set.
ASM : Drupal template
Hi, I have trouble with securing a drupal website without tons of false positive. In ASM, I would like to know if there is a security policy template for Drupal. I do not have a sufficant amount of visits for using the Real Time Policy Builder. Since drupal give the capacity to CMS admin of writing there own variable beginning with "field_", it is quite difficult to make wildcard parameters different than "field_*". It may be a bad idea, but I have come with the idea of using the following wildcard param: field_*date field_*value Thanks for your help