When it comes to improving the security of websites among the many problems is that the public doesn’t have a good understanding of how much risk various security issues pose. That leads to among other things, people believing that websites must have been hacked due to software on a website that contained a known vulnerability despite no evidence to support that and it being very unlikely that the vulnerability would be exploited, much less that it could have lead to the website being hacked. Unfortunately we often find those involved in security are the ones overstating the risk posed by vulnerabilities.

On Monday we detailed a vulnerability that had been fixed in the plugin Metronet Tag Manager, where the changelog entry for the version it was fixed in was “Fixed serious security issue. Please Update.” A possible explanation why it was labeled as such despite not being anywhere near a “serious” issue came yesterday, as on Tuesday the finder of the vulnerability, dxw, released a report on the vulnerability with the title “CSRF in Metronet Tag Manager allows anybody to do almost anything an admin can”. The third sentence of the description seems to explain that claim:

As this vulnerability allows adding arbitrary JavaScript, the attacker can use it to control an admin user’s browser to do almost anything an admin user can do.

That all makes it sounds like it would be likely to be used to hack websites, but in reality there is about zero chance that the vulnerability would be exploited average website at this time. The chances of exploitation of that type of vulnerability could change at some point and it could be of more interest in a targeted attack, but it isn’t something of major concern for the average website at this time. The reason for that isn’t all that complicated and it also explains why that title is so misleading.

With a cross-site request forgery (CSRF) vulnerability an attacker could cause someone else to take an action they didn’t intend to take. In this case, for the vulnerability to be exploited, an attacker would need to get someone logged in as Administrator user on a WordPress installation to access a page the attacker controls. That is something that we don’t see hackers trying to do against the average website whether with this type of vulnerability or others that rely on that same type of action. Nowhere in their report did dxw mention the need to be logged in at all to exploit this, much less as an Administrator to have been able to exploit this, despite that clearly being a requirement.

What makes dxw claim more problematic to us is that to us saying anybody can do something would imply that anyone could take the action, whereas you would need to get one of a limited amount of people to take an action. This isn’t one time claim, for example with another recent CSRF vulnerability they titled their report “CSRF in WP User Groups allows anybody to modify user groups and types”.

Details Matter

In looking at another of their recent discovered vulnerabilities to add it to our data set we found another overstated claim. The title for a report on that vulnerability is “WP ULike allows anybody to delete any row in any WordPress table”. One of the claims made in it is:

The plugin contains a wp_ajax action which allows any authenticated user (it doesn’t check permissions) to delete any row of almost any table in the database (the table must begin with $wpdb->prefix).

Another is this (emphasis ours):

In a real attack, the form could be made to auto-submit on page load, and submit the form multiple times with different table and id values meaning that a single user falling for a phish could wipe the whole database.

The line of code that handles the deletion referred to in those statements is this:

$wpdb->delete( $wpdb->prefix.$table ,array( 'id' => $id ));

The critical part of that is “array( ‘id’ => $id )” as that defines what gets deleted from the table. That will delete a row from table where the “id” columns value is the value specified by $id, which comes from user input. If a table doesn’t contain an “id” column then nothing can be deleted. While two important WordPress tables, posts and users, have an “ID” column, which unless case sensitivity is in place their entries can be deleted, the others do not, so this could not be used to “wipe the whole database”.

dxw is at least aware of the column limitation as the last steps of their proof of concept states:

The value of id or table can be changed allowing deleting any row in any table with the WordPress prefix at the start of its name, and having an id column

So either they didn’t fully checks things over before making a sensational claim or they knew better and included that claim anyway.