With the announcement of SecureSphere version 10.0, Imperva added a crowd-sourced threat intelligence service that aggregates and validates attack data from WAFs to protect against hackers, automated clients, and zero-day attacks. We can then validate the data and stop attack campaigns in almost real-time. The “Community Defense” service has already proven successful in deterring new and original attacks when they strike the first time.
In a spirit of collaboration, our ADC team wants to share an example of a threat we have analyzed, researched and mitigated for the entire community.
This is an interesting case where the second that the vulnerability got announced, we were able to identify exploitation attempts coming from attackers around the world. Community Defense was able to mitigate the threat early on and keep our clients safe.
A Wild CVE is on the Prowl
On June 6 the “Parallels Plesk Panel phppath/php vulnerability” was publicly disclosed. According to Parallels and The Vulnerability Notes Database:
“Parallels Plesk Panel versions 9.0–9.2.3 on Linux platforms may be exploited by a combination of CVE-2012-1823 and the Plesk phppath script alias usage. There have been reports that this vulnerability is being exploited in the wild.”
In case you don’t know, CVE-2012-1823 is a vulnerability in php-cgi, enabling remote attackers to execute arbitrary code by placing command-line options in the query string. For example, if the URL http://www.example.com/index.php is requested and php is configured to work in cgi mode, then a remote attacker can set php.ini security directives and execute arbitrary PHP code.
The “Plesk phppath script alias” relates to a php-cgi configuration directive on the web server — namely, ScriptAlias /phppath/ "/usr/bin/" — which tells the web server that any request for a resource beginning with /phppath/ should be served from the directory /usr/bin/ and treated as a CGI program.
Now if the URL http://www.example.com/phppath/php is requested, the web server will attempt to execute the file /usr/bin/php and return the output. And since /usr/bin/php is a default PHP path and the file is executable, the php interpreter is called directly.
By exploiting the combination of these two vulnerabilities, a remote unauthenticated attacker can run arbitrary code under the context of the web server user.
Capturing the CVE in action
Imperva has seen this vulnerability exploited in the wild. An example is shown below in Figure 1. The attacker sends a specially crafted HTTP request to the URL /phppath/php of the vulnerable web application. Here are the names of the parameters in the request’s body:
Set PHP environment flags, as described in CVE-2012-1823
Execute shell commands on the attacked server via PHP (using the PHP security bypass created by the environment flags). The shell commands can, for example, download and install a shell environment controlled by the attacker.
The attacks we observed very nearly coincided with the disclosure of the vulnerability, as can be seen in Figure 2. Many web applications were repeatedly attacked every few hours using this vulnerability over a long period of time (Figure 4).
As we’ve seen before, a single web application can be targeted by multiple attack sources (according to their IP addresses). At the same time, a single attack source can target multiple potentially vulnerable applications. Figure 4 illustrates the complex relationship between attackers and targets.
A similar relationship exists between attackers and injected shell URLs (Figure 5). A successful exploit of the vulnerability downloads a malicious shell code and executes it on the web server. ADC has also seen that URLs from which malicious shell codes are downloaded are used by more than one attacker and originating in more than one geo location.
As is often the case for this type of malware, it’s written in Perl and remotely controlled by the attacker using an IRC channel. One of the commands the controller can issue to the shell that runs on a compromised server is to look for other vulnerable web applications, in order to virally spread itself on the web.
Figure 1: Sample of attack exploiting the vulnerability
Figure 2: HTTP traffic exploiting the vulnerability (each target application marked with a different colour)
Figure 3: HTTP traffic exploiting the vulnerability targeting 4 sample web applications
Figure 4: Attackers (in red) and targets (web applications, in green) during 23/6-30/6
Figure 5: Sample of attackers and injected URLs during 23-29/6