The first plugin that will be analyzed in detail is called All In One WP Security & Firewall. It adds some additional layers of security to Wordpress, for example a brute force protection for the login or file permission checks. There are definitely quite a lot of good ideas integrated into this plugin, but some functionality cuts both ways. Meaning, it closes some attack vectors and opens new ones. Take the file permission manager for example. It is intended to change file permissions to something secure, but if an attacker gets access to the administration panel it can also be used to change the file permissions to something insecure, i.e. make read-only files writable. Another dangerous function is the ability to backup and restore the Wordpress configuration files because it can be used to inject PHP code into `wp-config.php`. In combination with the file permission manager, a code execution is guaranteed in case there is a cross-site scripting vulnerability somewhere on the...
The first plugin that will be analyzed in detail is called All In One WP Security & Firewall. It adds some additional layers of security to Wordpress, for example a brute force protection for the login or file permission checks. There are definitely quite a lot of good ideas integrated into this plugin, but some functionality cuts both ways. Meaning, it closes some attack vectors and opens new ones. Take the file permission manager for example. It is intended to change file permissions to something secure, but if an attacker gets access to the administration panel it can also be used to change the file permissions to something insecure, i.e. make read-only files writable. Another dangerous function is the ability to backup and restore the Wordpress configuration files because it can be used to inject PHP code into `wp-config.php`. In combination with the file permission manager, a code execution is guaranteed in case there is a cross-site scripting vulnerability somewhere on the page. Indeed, RIPS detected one in the plugin itself. In the end, the usage of this security plugin can bring more security risks than running Wordpress without it. `admin/wp-security-dashboard-menu.php` 1~12Line: var $menu_tabs_handler = array( ‘tab1’ => ‘render_tab1’, ‘tab2’ => ‘render_tab2’, ‘tab3’ => ‘render_tab3’, ‘tab4’ => ‘render_tab4’, ‘tab5’ => ‘render_tab5’, ); ⋮ function render_menu_page() { $tab = $this->get_current_tab(); $this->render_menu_tabs(); call_user_func(array(&$this, $this->menu_tabs_handler[$tab])); 33~36Line： function get_current_tab() { $tab_keys = array_keys($this->menu_tabs); $tab = isset($_GET['tab']) ? sanitize_text_field($_GET['tab']) : $tab_keys[0]; return $tab; 716~ Line public function render_tab3() { ⋮ echo '<input type="hidden" name="tab" value="' . $_REQUEST['tab'] . '" />'; This cross-site scripting vulnerability is quite interesting because at the first look this does not seem to be exploitable. After all, the function `render_tab3()` is only called when the parameter `tab` is tab3. We can still exploit this because the function `get_current_tab()` uses `$_GET['tab']` whereas `render_tab3()` uses `$_REQUEST['tab']`. The super global `$_REQUEST` is a combination of `$_GET`, `$_POST` and `$_COOKIE`. So what happens if we send `tab` as both a GET and a POST variable? The POST value overwrites the GET value, but only inside of `$_REQUEST`. So all we have to do is to send a cross-site scripting payload as POST parameter `tab` to `admin.php?page=aiowpsec&tab=tab3.` The cross-site scripting vulnerability is of course fixed by now, and so are other issues that we reported. Some of the issues still exist though, because the only way to fix them is by removing the functionality completely.
