Uncovering Potential Issues with the Contact Form 7 Vulnerability: More Data Needed
Update: The Proof of Concept posted on exploit-db has been removed since the publication of this article. We have updated the link to point to an archived copy.
On December 17, 2020, the Astra research security team disclosed that they had discovered a critical severity Unrestricted File Upload vulnerability in Contact Form 7, the most popular WordPress plugin of all time. The lead researcher, Jinson Varghese, also published a blog post providing limited information about this vulnerability.
The initial disclosure claimed that “By exploiting this vulnerability, attackers could simply upload files of any type, bypassing all restrictions placed regarding the allowed upload-able file types on a website.”
At the time, we were unable to duplicate the exploit and published our analysis based on the best information available, which indicated that the vulnerability would be difficult to exploit and would likely require a very specific configuration, but we wanted to wait until a public Proof of Concept was available.
A minimal Proof of Concept submitted to wpvulndb by the original researcher was made available on December 31, 2020. A separate, unverified Proof of Concept appeared on exploit-db on December 20, 2020. On January 10, 2021, the Astra Security team updated their vulnerability announcement stating that a full Proof of Concept would not be released.
None of our threat analysts were able to use these initial Proofs of Concept or any variants thereof to achieve unrestricted file upload, and indeed we had already attempted several variants of each Proof of Concept when the vulnerability was first disclosed because our analysis of the plugin patch indicated that these might be a viable approach.
We were able to use a double extension plus a unicode character to pass a single security check, the wpcf7_antiscript_file_name function, but this function was only one of several security measures in place for the upload process, and bypassing it did not allow the ability to upload files with extensions that would be executable on any of our test configurations. The most recent of these additional security features, the addition of a randomized directory, has been in place for more than 6 years.
We were not able to successfully upload files ending in a “.php” extension, nor were we able to upload files with double extensions (e.g. file.php.jpg, or file.jpg.php, with or without an invisible unicode separator between the two extensions) that would be parsed by any recent web server configuration we have tested. Configurations we have tested include Apache with a PHP AddHandler directive, Apache with an anchored SetHandler directive, Apache + PHP-FPM, NGINX + FastCGI, Litespeed, and IIS. Additionally, we have not seen any evidence of this vulnerability being successfully exploited in the wild.
We contacted the original security researcher requesting more information, but have not heard back at the time of this publication. We also contacted the plugin developer, who indicated that he recognized the bypass in the wpcf7_antiscript_file_name function as a potential vulnerability but had not been supplied with a Proof of Concept that bypassed the other security measures. We reached out to Astra Security who pointed us to their updated blog post indicating that no Proof of Concept would be released and that they had also not seen any evidence that the vulnerability was being exploited in the wild.
Open source security research is incredibly important and makes the entire WordPress ecosystem safer. It is critically important that vulnerable configurations are known; any server configuration that allows this vulnerability to be exploited could allow currently undiscovered vulnerabilities in other plugins to be exploited as well. It is also important to the credibility of our industry that this research be independently verifiable. While we realize that there may be good reasons not to make a Proof of Concept public, providing such a Proof of Concept to other security researchers allows the industry to improve its response to known threats.
For these reasons, we are requesting that the Astra Security research team, or anyone else in the WordPress or Security community who is able to do so, provide us more information about this vulnerability, as we would like to be able to independently duplicate the issue in order to confirm its impact, not only for the millions of users of Contact Form 7, but also for the wider WordPress ecosystem. We are requesting vulnerable server and plugin configurations in which it is possible to upload an executable PHP file via this vulnerability, as well as an unabridged Proof of Concept that allows us to duplicate the issue.
This article was written by Ramuel Gall, a former Wordfence Senior Security Researcher.
Comments
9:29 am
Please keep my website secured forever.
1:58 pm
Capaz y se equivocaron y no existe tal vulnerabilidad por eso no están aportando mas datos.
2:20 pm
Thanks as always to the great team at WordFence for getting us the facts to protect our websites
2:54 pm
Are Wordfence users, both paid and free, still protected if any vulnerability with contact form 7 does exist?
I sure hope so, keep up the great work! :)
7:33 am
Hi Chris,
Just like Contact Form 7 has several security features to prevent executable files from being uploaded, Wordfence also has several firewall rules that should prevent executable files from being uploaded. When we attempted to duplicate the exploit, we did verify that our firewall rules would prevent executable PHP from being successfully uploaded via the contact form, even before the security features in Contact Form 7 could kick in.
1:55 am
Hi,
motivated by your article here I scanned my log files for any suspecious activities on the WP sites I'm currently running (all with WF). As I have an additional own light "firewall" on top of the WP installation, which is working with the abuseipdb.com database, I can filter quite easy to those IP with clear criminal intention.
What I can see is some direct access to the file /wp-content/plugins/drag-and-drop-multiple-file-upload-contact-form-7/assets/js/dnd-upload-cf7.js since DEC 31. Luckily my own on-top-firewall was already able to block these accesses successfully, so Wp as well as WF had no chance to see this activity. I'll extend my code to log some details about the POST data, which may can help to see more in detail, whats going on there.
Rgds,
Armin
7:40 am
Hi Armin,
The activity you're seeing is likely not related to Contact Form 7, but may have been scanning for a vulnerability in a separate addon plugin by a different author, "Drag and Drop Multiple File Upload – Contact Form 7" which had a vulnerability in versions <1.3.5.5 reported in September. We actually updated one of our firewall rules to cover this vulnerability, though this is another case where only a few server configurations were vulnerable.
5:27 am
Reading this makes me leery of using Contact Form 7. Should we hesitate to use it at this point?
7:29 am
Hello EM,
I would not hesitate to use Contact Form 7 at all. If you're using a current version of Contact Form 7, you should be safe. If you are not using the Contact Form 7 file upload capability, you should be safe. Even if you are, though, you are likely still safe (but you should still update plugins ASAP when potential security issues are found). Contact Form 7 has numerous security features that should prevent this from being exploited. At every step of this process, the author of Contact Form 7 has acted responsibly - he fixed the issue immediately, even though there was little evidence that the vulnerability could be successfully exploited in a typical environment. To our knowledge, no one apart from Astra has been able to successfully exploit this.
10:12 am
Thank you Ram! Your take is much appreciated.
8:42 pm
Hello Wordfence team,
I am also a security researcher and trying to reproduce this vulnerability on my localhost for last 1 month but unable to reproduce. I also asked some help from @ramonvfer (researcher who published incomplete POC on exploit-db) and original researcher of Astra but they both are not ready to share anything and more over @ramonvfer have blocked me on twitter so I can't ask him anything further. It seems @ramonvfer is also unable to reproduce the issue and have submitted the exploit-db poc only for just having one exploit published in his name and it quite disappointing that exploit-db team have accepted and published his POC without any verification.
I totally agree that public POC (after giving sufficient time to patch) is more useful to study the vulnerabilities in detail and get prepared for such sort of attacks in future.
Thanks wordfence for your genuine blog as other sites have given only incompleted POC without even verifying that they are actually working (just by copying each other's work).