Removing database tables allows anyone to take over all website files

[winternetstudio]

Posted first on HackerOne but was referred to here.

Summary

If one by mistake removes the WordPress' database tables but files are left intact, a hacker or anyone can "install" WordPress again and do whatever he wants. It's a bad design choice that puts WordPress installations at additional risk.

Consequences

Hacker can install any plugin he wants, even a rogue one that he uploads himself (we had that actually happen and our hosting provider's malware detection triggered and suspended our entire Enterprise account with many domains). Through that he can then ie. access any content files, any potential other files outside the wordpress folder, the database credentials in wp-config.php and thereby access the database itself and any other databases/tables that the given mysql user has access to. In case the hosting provider allows direct mysql access with those credentials he can even do that without ever accessing WordPress. (I know some of these would not occur if following very strict hosting conventions, but our hosting provider (Simply.com who is the biggest in Scandinavia) do not sandbox every domain - neither does most others that I know of)

Steps To Reproduce

1. I moved a WordPress installation (incl. database tables) somewhere else but I didn't realize there was another WordPress installation using that same database (with a different prefix for the tables of course). So that left the database completely empty but all the files still intact.

2. When the hacker (or anyone!) now accesses the site that has no database tables WordPress will offer do an install, of course using the db credentials it already knows about. He creates admin account and everything, and now totally owns the site.

Recommendations

Once a WordPress installation has been completed another installation process should never be allowed again using those same files. Either by setting a flag somewhere, or better yet, by simply removing the installation script (many packages do this).

Can't imagine any downsides in doing so. The scenario might not happen very often but eventually it will (it did for us) so that risk might as well be eliminated.

Impact

Take over your entire site, access database and potentially other content on the server.

[apmarshall]

So I am just trying to think through the possible scenarios here. Here is what I have:

1. Someone accidentally deletes the database AND a hacker happens to be opportunistically lurking and leaps in to install their own site on your build.
2. A hacker has mySQL permissions to delete the database and uses this as a way to take over your install.
3. A malicious insider uses this vector to flush the site and make their own.

In all three cases, the old site is effectively gone, right? Database wiped, you/the hacker are starting from scratch.

[apmarshall]

Also: if you have deleted the database, then you need a new database to initiate the install, right? So there is one more intervening step here, which is that either a new database with the same credentials needs to be created OR a new database created and new credentials put in wp-config.php

Edit: or, rereading the original post, instead of deleting the database itself, you need to essentially wipe it of all content/tables (either accidentally or intentionally), thereby leaving the original credentials still operational.

[winternetstudio]

Replying to apmarshall:

1. Someone accidentally deletes the database AND a hacker happens to be opportunistically lurking and leaps in to install their own site on your build.
2. A hacker has mySQL permissions to delete the database and uses this as a way to take over your install.
3. A malicious insider uses this vector to flush the site and make their own.

In all three cases, the old site is effectively gone, right? Database wiped, you/the hacker are starting from scratch.

That's correct - database (ie. the tables) is gone, but all files including potentially sensitive ones are still there. And in case of an account with many sites hacker would have access to it all. Even a rogue WordPress plugin I guess could purposely delete all the tables in order to gain this kind of access

Replying to apmarshall:

Edit: or, rereading the original post, instead of deleting the database itself, you need to essentially wipe it of all content/tables (either accidentally or intentionally), thereby leaving the original credentials still operational.

Correct - I'm not talking about deleting the database, only deleting the tables. If database were deleted it would of course likely not be possible for a hacker to recreate it.

[anonymized_17160716]

Replying to winternetstudio:

If one by mistake removes the WordPress' database tables but files are left intact, a hacker or anyone can "install" WordPress again and do whatever he wants. It's a bad design choice that puts WordPress installations at additional risk.

If someone deleted the tables in a database and left everything in this form, then this is a 100% human factor, which has a mediocre relationship to WordPress.

The same can be said if a user with administrator privileges has the password like "qwe123", then a hacker can easily gain access to the administrative panel and take control of the entire site. This is not a security issue of WordPress engine for sure, not to mention the fact that this method was used for mass hacks many years ago, when users uploaded the WordPress files to a home directory, but did not complete the installation.

[winternetstudio]

Replying to m0ze:

Replying to winternetstudio:

If one by mistake removes the WordPress' database tables but files are left intact, a hacker or anyone can "install" WordPress again and do whatever he wants. It's a bad design choice that puts WordPress installations at additional risk.

If someone deleted the tables in a database and left everything in this form, then this is a 100% human factor, which has a mediocre relationship to WordPress.

The same can be said if a user with administrator privileges has the password like "qwe123", then a hacker can easily gain access to the administrative panel and take control of the entire site.

That's a different matter - the user is directly removing a security measure. Deleting database tables is not a direct security reduction in any way. You could in fact argue that a user will think it would improve security! Besides, a rogue plugin could do this (which a user installs in good faith) - and no user can be blamed for that scenario.

So, since is no reason for allowing to install a wordpress installation a second time, it might as well be removed to fix the very scenario we experienced.

[anonymized_17160716]

Replying to winternetstudio:

That's a different matter - the user is directly removing a security measure. Deleting database tables is not a direct security reduction in any way. You could in fact argue that a user will think it would improve security! Besides, a rogue plugin could do this (which a user installs in good faith) - and no user can be blamed for that scenario.

If you delete tables in a database, then in general you should understand what you are doing and why, and what the consequences will be. The same goes for the weak password for the administrator account.

Dropping the tables allows you to restart the installation - this is the security degradation due to human factor. I have seen many configurations, ranging from a backup database in the configuration file, to the banal protection by using a BasicAuth while working with the website. If the user himself doesn't know what he's doing with the website and doesn't know how it works in general, then all the consequences of his decisions are his problem. It's like twisting the keys to an apartment on your finger, losing them, and then blaming the door company that you lost the keys.

It is more profitable and easier for a "rogue plugin" to immediately take control of the CMS without damaging the regular operation of the site, and there is a lot of solutions for this kind of stuff.

You are trying to see the problem where there is none. More precisely, there is a problem - it's a human factor, but it has no direct relation to WordPress.

[winternetstudio]

Replying to m0ze:

So there is no reason whatsoever to try and avoid user errors?? Whether they are on purpose or by mistake (which was our scenario)?! Why do you think serious websites go through leaps and bounds by implementing password strength enforcements, 2FA, and all kinds of stuff to help the human factor not to become a problem?

Your logic is really flawed.

And please answer me on this: You ignore the point that there is no reason to have the possibility to install WordPress a second time - why is it more important to have that feature than helping to avoid human mistakes (or even malicious plugins)?

[anonymized_17160716]

Replying to winternetstudio:

Your emotionality in this matter and an attempt to make a big problem out of it suggests that you're simply trying to absolve yourself of responsibility for your own mistake and for all subsequent consequences of this mistake. Like, "the problem isn't in our actions, but in the WordPress CMS". But no, it was exactly your mistake. The second mistake is that you didn't insure yourself in advance against further problems, which, rather, speaks of little experience with this engine, and looks like you don't want to learn the lesson from this situation.

Just in case, let me remind you that WordPress has always been a compact basis for a blog, the functionality of which has been expanded due to plugins, hacks, etc. Over the past ~8 years, this engine has left the blog niche and has become extensively used in the development of various projects, but the essence remains the former is a minimal user-friendly framework that can be extended by plugins. Apparently, you didn't know this either, and you didn't install any plugins to hedge yourself against "accidents", right?

Nobody said that this option is more or less important, but this doesn't mean in any way that it should be otherwise. Again, you are trying to create a huge issue where it doesn't exist, raising your personal case to an absolute. Your negative experience is the consequences of your ignorance and your actions (and inaction, in the case of dropped database tables). To be honest, I can hardly imagine how it's possible to drop tables (!) in a database of a working website, and leave it all in this form. Tell me at least how these tables were deleted? phpMyAdmin? Plugin?

On the other hand, instead of learning a lesson from this situation, you start talking about how this is a huge security problem for the WordPress CMS, because there is practically no "foolproof". Strong logical skills over here, yes.

[winternetstudio]

You can think whatever you want - but your assumptions are incorrect. I know that I'm not trying to make an excuse for my mistake, of course I should have been more careful. My emotionality is because I'm really surprised about your arguments which I don't think hold water at all.

If you can't understand how I could do this by mistake you obviously haven't read my report (in moving the site I used a MySQL client if you think that is relevant). Of course it's not a "huge" security issue but I understand that you rather want to keep an unneeded feature than help alleviating potential security problems. Got it. Ciao.

[anonymized_17160716]

Replying to winternetstudio:

You can think whatever you want - but your assumptions are incorrect.

which I don't think hold water at all.

So do you. Just an opinions.

I understand that you rather want to keep an unneeded feature than help alleviating potential security problems. Got it. Ciao.

This is a "security problem" only in your imagination, when you are careless and don't check the results of your work, so that in the end another website is left without tables in the database. We all make mistakes sometimes, the question is what we do next.

of course I should have been more careful.

That's the point. End of the story.

[SergeyBiryukov]

Related: #23487, #29794.

[winternetstudio]

Replying to m0ze:

So you think WordPress couldn't care less about protecting against user errors (or in your words, dumb users like me) even though it easily could. You must be against 2FA and password strength plugins as well then. Interesting philosophy.

[anonymized_17160716]

Replying to winternetstudio:

So you think WordPress couldn't care less about protecting against user errors (or in your words, dumb users like me) even though it easily could.

If this is a very common mistake/error, why not? But when these are isolated cases, then, rather, the users themselves need to be more attentive to their own projects.

If you try to please every inexperienced or inattentive user, the engine will acquire a lot of unnecessary options and warnings, as has already happened with the theme and plugin editor, and with changing the website administrator's email, and with some other functionality. In other words, favorable conditions are created for a beginner to remain a beginner, and this is a very bad vector for the development of any system.

Moreover, practice shows that such "safety" options help some users, but start to interfere with others. The only humor is that no one will remove the added options.

[SergeyBiryukov]

Related: #56141