Identifying Vulnerabilities in Phishing Kits
While recently examining hundreds of phishing kits for ongoing research, Akamai discovered something interesting - several of the kits included basic vulnerabilities due to flimsy construction or reliance on outdated open source code. Considering the impact phishing kits have on the Internet and web hosting as a whole, the phrase "kicking someone when they're down" certainly come to mind.
A double whammy
The existence of a phishing kit on a web server is bad enough. The existence of a kit with vulnerabilities that others, with even less than honest intentions, could scan for and discover is much worse. After a vulnerability of some kind has been discovered, or the administration credentials compromised, phishing kits are often uploaded to a compromised WordPress or Joomla blog.
These attacks are often limited to the user's directory and remedied by removing the kit and updating vulnerable software. In the kits examined by Akamai researchers, an additional layer of attack exists, one that is often unknown to the person responsible for deploying the phishing kit - Web Application vulnerabilities.
With these particular vulnerabilities, a second attacker could come in after the phishing kit is installed and upload additional files, which may help it evade detection, or hinder cleanup efforts, and software updates. In addition to the ability to upload any sort of executable code, another class of vulnerabilities in these kits allow an attacker to remove files from the system if they're owned by the HTTP daemon.
All of this is compounded by criminals who host phishing kits on their own VPS accounts. In these cases, not only are the web hosts exposed to reputation harm due to having a customer running phishing scams, but now they're at risk of having other customers compromised.
Server security configuration is rarely hardened, and often file permissions are left wide open allowing full read and write access to directories (0755 / 0777). Attackers compromising these kits using this vulnerability could gain additional footholds on the web server. One PHP shell and an improperly secured script ran by CRON is all an attacker needs to take over the whole server.
File upload and removal
Akamai examined several phishing kits in order to determine if any of them had vulnerabilities, and the kits with the most positive results were those that used file upload in some fashion.
The common thread between each kit is the usage of class.uploader.php, ajax_upload_file.php, and ajax_remove_file.php, in a number of different naming conventions. The code used in these files comes from a GitHub repository that was last updated in 2017, and the project is just a collection of file upload scripts for PHP. The file names themselves are not important. The risk is the code being copied from GitHub and pasted between kits.
In multiple kits, the code for the uploader script and the uploader class file don't check for filetype. This means a user could upload executable code to the web root. If the upload path doesn't already exist, the uploader class file will create it.
The code in the file remove script doesn't sanitize user input from ".." allowing directory traversal, enabling a user to delete arbitrary files from the system if they're owned by HTTPd.
Code cloning and copying is as common in the criminal world as it is in traditional, legitimate application development.
When a developer needs to do something, and a code snippet or existing script does the job, it's often cut and pasted with a few modifications, before being pushed out for use. Criminals do the same thing when developing phishing kits, sometimes lifting entire functions and sections of kits for their own use.
Most developers know that code sharing means that any project touched by vulnerable code likely shares the same vulnerabilities. When problems are discovered, they're usually quickly addressed and corrected. Criminals do not care, nor do they actually control their code once released, so there is no real fix for vulnerabilities like these.
While Akamai hasn't determined if there have been successful secondary attacks due to these vulnerabilities, it's a real possibility. Many phishing kit developers have a background in application security, and chase bugs like these for money and notoriety. The idea that they would search for, discover, and exploit such flaws for their own gain isn't a stretch.
The real risk and concern in this situation goes to the victims - the server administrators, bloggers, and small business owners whose websites are where phishing kits like these are uploaded. They're getting hit twice and completely unaware of the serious risk these phishing kits represent. As mentioned, phishing kits are bad, but phishing kits that come pre-packaged with file upload vulnerabilities are worse.
With the proliferation of various phishing kits via underground forums and message boards we can expect their vulnerable source code to be shared, copied, and reused by adversaries that may expose victim websites to additional threats.
The files below were some of the ones tested during research. The brands being targeted by the phishing kits have been removed, as the code is swapped out between several kits across multiple brands.
Additional writing and research provided by Steve Ragan.
Banking phishing kit:
Banking phishing Kit (2):
File storage & financial service phishing kits: