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
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
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
- 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.
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 color)
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