Perch, a popular CMS with freelancers and small web agencies, recently experienced a serious security breach, which is being exploited in the wild.
Perch have released a patch and recommend all users of the CMS apply it immediately. However, it’s also important that all Perch users check whether they’re been affected, as the breach allows anyone who knows what they’re doing to gain full access to your server, and potentially access confidential information stored in any databases.
What is the vulnerability
The breach makes use of a vulnerability in the image_upload.php file of MarkItUp, a rich text editor bundled with Perch. By using the vulnerability, a malicious user can upload a PHP file directly to the server, then essentially gain free reign to carry out attacks. Unfortunately, one of our clients’ sites was affected by this breach, so we’ve seen first hand the damage that can be caused.
In our case, and in others reported online, the malicious users have managed to download the entire Perch database, and any other databases on the same hosting account. If your CMS contains private pages, contact form submissions, or other confidential data, these hackers could now have easy access to this data.
Similarly, if you host other applications on the same server, and the database details are stored unencrypted in a configuration file, or use the same username and password as your Perch account, the hackers may be able get access to these databases as well.
The vulnerability does rely on servers treating .phtml files as PHP. Phtml files are the file extension used by PHP2, and many servers will no longer execute this filetype as PHP. However, many still do, and we’ve seen many reports of this vulnerability being exploited, so it’s clearly a widespread issue.
How to check if you’ve been affected
Look for .phtml files on your server
The easiest way to check if you’ve been affected is to check your /perch/resources folder for any files with the extension .phtml.
In the examples we’ve seen, the file is called cantseeme.phtml, but it’s perfectly possible the exploiters will rename the file to make detection more difficult.
Also check the folder for any .sql files, as the malicious users have been performing mysql dumps on affected sites, which get dumped into the same /perch/resources folder.
Check your access logs
The script we’ve seen used has the ability to self-destruct, to avoid identification. This hasn’t been used in the examples we’ve seen, but it’s perfectly possible that it has been in some cases. As such, a more robust way to check if your site has been exploited is to check your raw access logs, to see if the image_upload.php file has been accessed, and if any .phtml scripts have been run.
If you’re a cPanel user, you can access these logs under ‘Raw Access Logs’. Download logs for any domains that use Perch.
Typically, raw access logs only store a few hours’ worth of data, so if you’ve got arching turned on, download the archived logs and check them as well. If you haven’t got archiving turned on, and only have access to a few hours worth of data, it would be worth contacting your hosts to see if they have access to the logs. If not, use our first method of checking the /perch/resources folder for any suspicious files.
Open your logs using any text editor, then search for ‘image_upload.php’. This is the file that’s being exploited. If your site has been targeted, you will see a line similar to:
18.104.22.168 - - [23/Nov/2015:20:00:00 +0000] "POST /perch/addons/plugins/editors/markitup/image_upload/image_upload.php HTTP/1.1" 200 52 "http://www.[YOURSITE].com/perch/addons/plugins/editors/markitup/image_upload/image_upload.html" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36"
You may see this file being accessed legitimately, if you’re using MarkItUp to upload images. However, keep reading the lines below this one. if your site has been exploited, you will likely start to see lines like the following:
22.214.171.124 - - [23/Nov/2015:20:05:00 +0000] "GET /perch/resources/cantseeme.phtml HTTP/1.1" 200 31475 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36"
In the examples we’ve seen, the script allows the malicious user to explore your entire file system. Typically, they will look for the Perch configuration file, or the configuration file for any other CMSs on your server, so they can get access to the database username and password.
Using this, then can they dump your entire database, and potentially get access to personal or customer information you may have stored. If you use the same username and password for multiple databases, they’ll probably be able to get access to all databases you have stored on that server.
If you continue to read the logs line by line, exploring any with the .phtml extension, you can typically see what actions have been carried out, as the commands in the script are passed via GET. For example:
126.96.36.199 - - [24/Nov/2015:23:53:27 +0000] "GET /perch/resources/cantseeme.phtml?act=ls&d=%2Fhome%2[USERNAME]%2Fpublic_html%2F&sort=0a HTTP/1.1" 200 7657 "http://www.[YOURSITE].com/perch/resources/cantseeme.phtml" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36"
Here, you can see the ‘ls’ command was carried out on the /home/[USERNAME]/public_html directory. ls is a shell command that shows all files in that directory. In this exploit, the user typically explores the filesystem, looking for configuration files, so as to gain access to your database’s login details.
Search for mysqldump – if you find instances of this in the log, carried out using the .phtml file, then the user has likely downloaded a full dump of your database, potentially gaining access to confidential information.
Protecting your site in the future
To protect yourself, first and foremost, make sure your version of Perch is patched. The latest version of Perch (2.8.15) fixes the vulnerability, so if possible make sure you’re using the very latest version. If you aren’t able to upgrade, Perch have released individual patches for all versions of the CMS from version 2 upwards (available here), so download the individual patch and apply it as soon as possible.
Also, change your database password if you suspect you’ve been affected. For best practice, also ensure that all your databases use a different user, with a different password.
If you’re still worried, we recommend you get in touch with official Perch support on their Perch Official Forum.