MicroWeber is an open-source Content Management System (CMS) written in PHP. It allows web administrators to easily build a website by dragging and dropping components where they want them to be. It is a popular choice among those looking to start a website that is both easy to set up and is very customizable.

In this blog post, I will be detailing a critical vulnerability I discovered in MicroWeber where an attacker could disclose the entire users database, which includes admin password hashes and emails. No authentication was required to exploit the vulnerability, making it very high impact.

Being a PHP-based CMS, MicroWeber calls upon multiple PHP scripts to handle different parts of its functionality. This allows MicroWeber to be customizable and users can plug in their own scripts or easily modify existing ones to change how the CMS operates.

One such piece of this customization functionality is the aptly named modules system. Modules allow for different functions like embedding Tweets or a search utility to be added into MicroWeber. This allows web administrators to easily extend the functionality of their MicroWeber site by finding or writing a module that adds the functionality they need.

The vulnerability was discovered in the “controller.php” script, which is part of MicroWeber’s users module.

This PHP script does nothing but run Laravel’s dump and die function on the users database. Dump and die simply prints the contents of the entire PHP variable (in this case, the users database) out to HTML and then halts execution of the script, hence the “dump and die”.

For a module’s functionality to be invoked by a user, a user must submit a POST request to the /modules/ endpoint which has to contain a few arguments, the most important of which is the “module” parameter. This parameter is the path to the PHP script for the particular module that is being invoked.

To trigger the vulnerability, a user just needs to submit the following POST request to the /modules/ endpoint:

When this is submitted, the “controller.php” script will be executed, and the entire users database will appear in the response. This requires no authentication as MicroWeber allows modules to be invoked without being authenticated.

When the vulnerability is successfully exploited, you have access to the entire users database, including administrator users. Every bit of information that is stored about an individual user by MicroWeber is revealed.

MicroWeber does not store passwords as plain-text, so the hashes must be cracked. By default, MicroWeber is using bcrypt for hashing. MicroWeber administrators are free to implement another hash algorithm if they want, but the only supported option out of the box is bcrypt. These hashes are crackable with Hashcat under the default configuration, making it feasible for an attacker to obtain administrator passwords by cracking the hash.

MicroWeber staff fixed this vulnerability by removing controller.php from the MicroWeber source code. According to a MicroWeber developer, Controller.php was a leftover from the early days of MicroWeber’s development. Now that controller.php has been removed from the source, this vulnerability is no longer possible to exploit.

Disclosing this vulnerability was overall a positive experience. The MicroWeber team was prompt and responsive in getting it fixed up and I thank them for that. I will definitely be researching MicroWeber more in the future and look forward to our next interaction.

Thanks for reading! Check back frequently for more blog posts, research, and tool releases. In the meantime, follow us on Twitter for news and updates: @RhinoSecurity, @Hun10sta

04-27-2020 – Vulnerability Disclosed to MicroWeber

05-22-2020 – MicroWeber staff confirms the vulnerability and begins working on a fix. The CVE is assigned CVE-2020-13405

06-22-2020 – MicroWeber 1.1.20 is released which fixes the vulnerability