Threat actors love—and when I say love, I mean they really, really love—email. It’s direct marketing for their scam! The trouble is that, to an even greater degree than legitimate direct marketers, they need to keep operating costs very low, so the fiscally responsible ones don’t want to just outsource it. Instead, they spend time uncovering clever tricks to send out their messages on the cheap.
Actors distributing Locky ransomware are no exception. During a mid-July campaign, it appears these actors were abusing an unpublished vulnerability in certain PHP web-to-email forms which allowed them to send emails from any source address to any destination—with their ransomware attached! In this post we’ll dig into that vulnerability and look at one set of circumstances under which such a thing might occur.
I think the first ever web-to-email form I came across was form2mail.pl. The concept was simple: you have a website and you want your visitors be to able to contact you through a form. You write the HTML side for the WebUI and when the visitor submits the form, it sends a POST to the web-to-email application which takes the data, bundles it in an email, and sends it to you. Free scripts to implement this pattern are available for just about every language. Locky distributors focused on PHP scripts.
A trivial vulnerability
The key security mechanism in these scripts is that you (the site owner) define the destination email on the server side which is inaccessible to the web visitor. You can also statically define content, the email subject, and virtually every other component of the email itself, but the big obvious risk is mostly mitigated by defining the destination address, server side. So in theory, the only thing an attacker could do is target *you*, and potentially send *you* lots of convincing spam.
This all falls apart when the web-to-email form does something
What happens here is that the application takes every key/value pair POST’ed by the visitor and assigns each key as a PHP variable populated by its corresponding value. On the surface this might not be too bad if there are not any overlapping POST parameters with PHP variables; however, since we don’t have strict control over the data POST’ed by the user, the application is severely vulnerable to attack. Why? Let’s look more broadly at the code (simplified, only the important parts shown):
Consider the visitor sending POST data which contains a parameter DestinationAddress with an arbitrary email address. Since the whole loop effectively overwrites the PHP variable $DestinationAddress with whatever the visitor provided in their POST request, and since that variable is used as the destination email address to the mail() function, the visitor just sent an email to an arbitrary address! In other words, an actor just spam’ed out an email with a link to their Locky download site using the vulnerable web server. The same concept is used to overwrite the subject line of the email and embed a file in the request and attach it.
Similar vulnerabilities have been found over the last 10 or so years in many PHP web applications, and the web forms that we found vulnerable all had newer versions available which address the issue. However, we were unable to find any publicly reported instances of these vulnerabilities in the specific PHP webforms we saw being abused. We did reach out to the vendor(s) we could identify, requesting contact information, but received no reply to date and thus we’re choosing not to identify the specific applications containing the vulnerabilities. Updating to the latest version of your PHP web-to-email form should fix the issue.
Are Site Owners Negligent?
I was curious and wanted to dig a little deeper into why some of these sites were vulnerable to begin with, and given the geographical proximity of one company hosting vulnerable web-to-email forms to my own location, I contacted the small business. A few days later, the business owner responded and seemed to be genuinely concerned that their site was facilitating attack. Once we dug in a little deeper, an all-too-familiar story emerged: the site was all but abandoned.
The owner had initially hired a local third party design and hosting company to develop and manage the site. After some time, the owner requested certain site updates with which the designer disagreed and refused to make. This minor conflict turned nasty when the designer changed the password to the management interface of the site, effectively locking out the owner. The owner claims to have lost all control over the registration and management of the site, and the designer/hosting company is not responding to his attempts to contact them. It appears that this designer’s actions could be having a much larger effect, given that the site was being used to distribute ransomware.