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.
Mitigating Fortnite Vulnerabilities with BIG-IP ASM
A recently published research by Checkpoint introduced a couple of undiscovered vulnerabilities in the online gaming platform of “Epic Games” – the developers of the famous "Fortnite" game. The impact demonstrated in the Checkpoint research stemmed from an SQL Injection andCross Site Scripting vulnerabilities. The payloads published can be mitigated by BIG-IP ASM with the following signatures: Figure 1: Cross Site Scripting Payload blocked by existing signatures. Figure 2: SQL-Injection payload blocked by multiple existing signatures. Additional Reading https://research.checkpoint.com/hacking-fortnite/
DRUPAL Critical SQLI (CVE-2014-3704)
Drupal is an open source framework written in PHP and is ranked as the third most popular content management system by W3Techs. It has introduced a database abstraction API to prevent SQL injection attacks, so only sanitized queries will be executed. However, recently a highly critical SQL injection vulnerability was discovered in the API itself allowing attackers to execute arbitrary SQL queries. Successful exploitation may result in a complete system compromise. Several exploits are already published. Most are exploiting this vulnerability to create an administrative account. Mitigation using F5 ASM Attack Signatures While running the SQLI exploit on an ASM protected application the attacker will be blocked by generic SQL injection signatures. Those signatures are part of the generic signature set that is assigned to any security policy by default. The injection is inside a parameter name called “name”. An example exploit vector will update the “users” table with a user named “owned”. The vulnerable parameter “name” will contain following SQL query: name[0 ;update users set name='owned' , pass = <hash> where uid = '1';;# ]=test3 This exploit will trigger 3 signatures. Two of them (200002289, 200002248) will catch the attempt to update a certain table, while one (200005005) catches the attempt to specify the “uid” attribute (specifying user id), which is used in LDAP injection attacks as well.4 Reasons We Must Redefine Web Application Security
Mike Fratto loves to tweak my nose about web application security. He’s been doing it for years, so it’s (d)evolved to a pretty standard set of arguments. But after he tweaked the debate again in a tweet, I got to thinking that part of the problem is the definition of web application security itself. Web application security is almost always about the application (I know, duh! but bear with me) and therefore about the developer and secure coding. Most of the programmatic errors that lead to vulnerabilities and subsequently exploitation can be traced to a lack of secure coding practices, particularly around the validation of user input (which should never, ever be trusted). Whether it’s XSS (Cross Site Scripting) or SQL Injection, the root of the problem is that malicious data or code is submitted to an application and not properly ferreted out by sanitization routines written by developers, for whatever reason. But there are a number of “web application” attacks that have nothing to do with developers and code, and are, in fact, more focused on the exploitation of protocols. TCP and HTTP can be easily manipulated in such a way as to result in a successful attack on an application without breaking any RFC or W3C standard that specifies the proper behavior of these protocols. Worse, the application developer really can’t do anything about these types of attacks because they aren’t aware they are occurring. It is, in fact, the four layers of the TCP/IP stack - the foundation for web applications – that are the reason we need to redefine web application security and expand it to include the network where it makes sense. Being a “web” application necessarily implies network interaction, which implies reliance on the network stack, which implies potential exploitation of the protocols upon which applications and their developers rely but have little or no control over. Web applications ride atop the OSI stack; above and beyond the network and application model on which all web applications are deployed. But those web applications have very little control or visibility into that stack and network-focused security (firewalls, IDS/IPS) have very little awareness of the application. Let’s take a Layer 7 DoS attack as an example. L7 DoS works by exploiting the nature of HTTP 1.1 and its ability to essentially pipeline multiple HTTP requests over the same TCP connection. Ostensibly this behavior reduces the overhead on the server associated with opening and closing TCP connections and thus improves the overall capacity and performance of web and application servers. So far, all good. But this behavior can be used against an application. By requesting a legitimate web page using HTTP 1.1, TCP connections on the server are held open waiting for additional requests to be submitted. And they’ll stay open until the client sends the appropriate HTTP Connection: close header with a request or the TCP session itself times out based on the configuration of the web or application server. Now, imagine a single source opens a lot – say thousands – of pages. They are all legitimate requests; there’s no malicious data involved or incorrect usage of the underlying protocols. From the application’s perspective this is not an attack. And yet it is an attack. It’s a basic resource consumption attack designed to chew up all available TCP connections on the server such that legitimate users cannot be served. The distinction between legitimate users and legitimate requests is paramount to understanding why it is that web application security isn’t always just about the application; sometimes it’s about protocols and behavior external to the application that cannot be controlled let alone detected by the application or its developers. The developer, in order to detect such a misuse of the HTTP protocol, would need to keep what we in the network world call a “session table”. Now web and application servers keep this information, they have to, but they don’t make it accessible to the developer. Basically, the developer’s viewpoint is from inside a single session, dealing with a single request, dealing with a single user. The developer, and the application, have a very limited view of the environment in which the application operates. A web application firewall, however, has access to its session table necessarily. It operates with a view point external to the application, with the ability to understand the “big picture”. It can detect when a single user is opening three or four or thousands of connections and not doing anything with them. It understands that the user is not legitimate because the user’s behavior is out of line with how a normal user interacts with an application. A web application firewall has the context in which to evaluate the behavior and requests and realize that a single user opening multiple connections is not legitimate after all. Not all web application security is about the application. Sometimes it’s about the protocols and languages and platforms supporting the delivery of that application. And when the application lacks visibility into those supporting infrastructure environments, it’s pretty damn difficult for the application developer to use secure coding to protect against exploitation of those facets of the application. We really have to stop debating where web application security belongs and go back to the beginning and redefine what it means in a web driven distributed world if we’re going to effectively tackle the problem any time this century.Using Resource Obfuscation to Reduce Risk of Mass SQL Injection
One of the ways miscreants locate targets for mass SQL injection attacks that can leave your applications and data tainted with malware and malicious scripts is to simply seek out sites based on file extensions. Attackers know that .ASP and .PHP files are more often than not vulnerable to SQL injection attacks, and thus use Google and other search engines to seek out these target-rich environments by extension. Using a non-standard extension will not eliminate the risk of being targeted by a mass SQL injection attack, but it can significantly reduce the possibility because your site will automatically turn up in cursory searches seeking vulnerable sites. As Jeremiah Grossman often points out, while cross-site scripting may be the most common vulnerability discovered in most sites, SQL injection is generally the most exploited vulnerability, probably due to the ease with which it can be discovered, so anything you can do to reduce that possibility is a step in the right direction. You could, of course, embark on a tedious and time-consuming mission to rename all files such that they do not show up in a generic search. However, this requires much more than simply replacing file extensions as every reference to the files must also necessarily be adjusted lest you completely break your application. You may also be able to automatically handle the substitution and required mapping in the application server itself by modifying its configuration. Alternatively there is another option: resource obfuscation. Using a network-side scripting technology like iRules or mod_rewrite, you have a great option at your disposal to thwart the automated discovery of potentially vulnerable applications. HIDE FILE EXTENSIONS You can implement network-side script functionality that simply presents to the outside world a different extension for all PHP and ASP files. While internally you are still serving up application.php the user – whether search engine, spider, or legitimate user – sees application.zzz. The network-side script must be capable of replacing all instances of “.php” with “.zzz” in responses while interpreting all requests for “.zzz” as “.php” in order to ensure that the application continues to act properly. The following iRule shows an example of both the substitution in the response and the replacement in the request to enable this functionality: when HTTP_REQUEST { # This replaces “.zzz” with ".php” in the URI HTTP::uri [string map {".zzz" ".php"} [HTTP::uri]] } when HTTP_RESPONSE { STREAM::disable If {[HTTP::header value "Content-Type"] contains "text" } { STREAM::expression "@.php@.zzz@" STREAM::enable } } One of the benefits of using a network-side script like this one to implement resource obfuscation is that in the event that the bad guys figure out what you’re doing, you can always change the mapping in a centralized location and it will immediately propagate across all your applications – without needing to change a thing on your servers or in your application. HIDE YOUR SERVER INFORMATION A second use of resource obfuscation is to hide the server information. Rather than let the world know you’re running on IIS or Apache version whatever with X and Y module extensions, consider changing the configuration to provide minimal – if any – information about the actual application infrastructure environment. For Apache you can change this in httpd.conf: ServerSignature Off ServerTokens Prod These settings prevent Apache from adding the “signature” at the bottom of pages that contains the server name and version information and changes the HTTP Server header to simply read “Apache”. In IIS you can disable the Server header completely by setting the following registry key to “1”. HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\DisableServerHeader If you’d rather change the IIS Server header instead of removing it, this KnowledgeBase Note describes how to use URLScan to achieve your goals. If you’d like to change the HTTP Server header in a centralized location you can use mod_security or network-side scripting to manipulate the Server header. As with masking file extensions, a centralized location for managing the HTTP Server header can be beneficial in many ways, especially if there are a large number of servers on which you need to make configuration changes. Using iRules, just replace the header with something else: when HTTP_RESPONSE { HTTP::header replace Server new_value } Using mod_security you can set the SecServerSignature directive: SecServerSignature "My Custom Server Name" These techniques will not prevent your applications from being exploited nor do they provide any real security against an attack, but they can reduce the risk of being discovered and subsequently targeted by making it more difficult for miscreants to recognize your environment as one that may be vulnerable to attack.BusinessWeek takes viral advertising a little too seriously
Yesterday it was reported that BusinessWeek had been infected with malware via an SQL injection attack. [begin Mom lecture] Remember when we talked about PCI DSS being a good idea for everyone, even though it's just a requirement for the payment card industry? If I've told you once, I've told you a million times: safer is better, more protection never hurts. [end Mom lecture] The coolest thing about the web is that, unlike being a mom with one teenager left in the house, I don't have to actually repeat myself. I can just link to it again...and again...and again. Interestingly, the aforementioned report indicates that "Sophos informed BusinessWeek of the infection last week, although at the time of writing the hackers' scripts are still present and active on their site." Why would that be? Perhaps because it takes time to find and fix the code responsible, and then actually deploy it out into production. This is one of the scenarios in which a web application firewall or an application delivery platform could be of assistance, as either could be quickly and easily configured to strip the offending scripts from all responses, giving developers the time they need to address the problem in the application. Where's F5? VMWorld Sept 15-18 in Las Vegas Storage Decisions Sept 23-24 in New York Networld IT Roadmap Sept 23 in Dallas Oracle Open World Sept 21-25 in San Francisco Storage Networking World Oct 13-16 in Dallas Storage Expo 2008 UK Oct 15-16 in London Storage Networking World Oct 27-29 in Frankfurt Related reading: White Paper: SQL Injection Evasion Detection Article: Preventing SQL InjectionsWhy it's so hard to secure JavaScript
The discussion yesterday on JavaScript and security got me thinking about why it is that there are no good options other than script management add-ons like NoScript for securing JavaScript. In a compiled language there may be multiple ways to write a loop, but the underlying object code generated is the same. A loop is a loop, regardless of how it's represented in the language. Security products that insert shims into the stack, run as a proxy on the server, or reside in the network can look for anomalies in that object code. This is the basis for many types of network security - IDS, IPS, AVS, intelligent firewalls. They look for anomalies in signatures and if they find one they consider it a threat. While the execution of a loop in an interpreted language is also the same regardless of how it's represented, it looks different to security devices because it's often text-based as is the case with JavaScript and XML. There are only two good options for externally applying security to languages that are interpreted on the client: pattern matching/regex and parsing. Pattern matching and regular expressions provide minimal value for securing client-side interpreted languages, at best, because of the incredibly high number of possible combinations of putting together code. Where's F5? VMWorld Sept 15-18 in Las Vegas Storage Decisions Sept 23-24 in New York Networld IT Roadmap Sept 23 in Dallas Oracle Open World Sept 21-25 in San Francisco Storage Networking World Oct 13-16 in Dallas Storage Expo 2008 UK Oct 15-16 in London Storage Networking World Oct 27-29 in Frankfurt As we learned from preventing SQL injection and XSS, attackers are easily able to avoid detection by these systems by simply adding white space, removing white space, using encoding tricks, and just generally finding a new permutation of their code. Parsing is, of course, the best answer. As 7rans noted yesterday regarding the Billion More Laughs JavaScript hack, if you control the stack, you control the execution of the code. Similarly, if you parse the data you can get it into a format more akin to that of a compiled language and then you can secure it. That's the reasoning behind XML threat defense, or XML firewalls. In fact, all SOA and XML security devices necessarily parse the XML they are protecting - because that's the only way to know whether or not some typical XML attacks, like the Billion Laughs attack, are present. But this implementation comes at a price: performance. Parsing XML is compute intensive, and it necessarily adds latency. Every device you add into the delivery path that must parse the XML to route it, secure it, or transform it adds latency and increases response time, which decreases overall application performance. This is one of the primary reasons most XML-focused solutions prefer to use a streaming parser. Streaming parser performance is much better than a full DOM parser, and still provides the opportunity to validate the XML and find malicious code. It isn't a panacea, however, as there are still some situations where streaming can't be used - primarily when transformation is involved. We know this already, and also know that JavaScript and client-side interpreted languages in general are far more prolific than XML. Parsing JavaScript externally to determine whether it contains malicious code would certainly make it more secure, but it would also likely severely impact application performance - and not in a good way. We also know that streaming JavaScript isn't a solution because unlike an XML document, JavaScript is not confined. JavaScript is delimited, certainly, but it isn't confined to just being in the HEAD of an HTML document. It can be anywhere in the document, and often is. Worse, JavaScript can self-modify at run-time - and often does. That means that the security threat may not be in the syntax or the code when it's delivered to the client, but it might appear once the script is executed. Not only would an intermediate security device need to parse the JavaScript, it would need to execute it in order to properly secure it. While almost all web application security solutions - ours included - are capable of finding specific attacks like XSS and SQL injection that are hidden within JavaScript, none are able to detect and prevent JavaScript code-based exploits unless they can be identified by a specific signature or pattern. And as we've just established, that's no guarantee the exploits won't morph and change as soon as they can be prevented. That's why browser add-ons like NoScript are so popular. Because JavaScript security today is binary: allow or deny. Period. There's no real in between. There is no JavaScript proxy that parses and rejects malicious script, no solution that proactively scans JavaScript for code-based exploits, no external answer to the problem. That means we have to rely on the browser developers to not only write a good browser with all the bells and whistles we like, but for security, as well. I am not aware of any security solution that currently parses out JavaScript before it's delivered to the client. If there are any out there, I'd love to hear about them.
