Portable phpMyAdmin – Unsafe For WordPress Consumption

In June of 2011, my colleague Sarah Gooding wrote about a phpMyAdmin plugin that posed a HUGE security risk. Because of the security risk, this plugin was removed from the WordPress repository and it was recommended that everyone stop using it and remove it.

Now, there’s another dangerous plugin in the WordPress repository – Portable phpMyAdmin.

Portable phpMyAdmin WordPress Plugin - Dangerous

How Dangerous Is This Plugin?

VERY!! In fact, stop reading right now. Go to any websites where you have this installed, deactivate it, and delete it. If after reading this you want to reinstall it, the information will still be in the database, but you’ll be protected in the meantime.

What Is It Supposed To Do?

The concept here appears to be pretty simple – and maybe that’s part of the problem. The idea is that once you are logged in to your admin section of your website, you can access your underlying database by simply navigating to the Portable PMA menu. Once you click on that selection, you’ll see phpMyAdmin open inside of your WordPress Admin section. Not so bad right? I mean, you are the admin, you should be able to see that.

Featured Plugin - WordPress Appointments Plugin

Take, set and manage appointments and client bookings without having to leave WordPress. Appointments+ makes it easy.
Find out more

O.K. So What’s The Problem?

If an admin can access this information, then there should be NO problem, correct? If you’d like to follow along with this, create a temporary WordPress installation on a test domain and create a user account with the “Subscriber” role – the least privileges that a WordPress user can have by default. Log out of your admin account and log back in using that “Subscriber” login. You should see your Subscriber Profile page as shown below:

WordPress Portable phpMyAdmin - Subscriber Login Profile Page

Well, no danger there, is it? The subscriber can only access their own personal profile page and NOTHING else. Looks pretty innocuous to the most casual observer on the scene.

Now, type the following:

http://yourdomain.com/wp-content/plugins/portable-phpmyadmin/wp-pma-mod/

into your browser address bar (changing “yourdomain.com” to your actual domain name and press “Enter”.

Surprise - WordPress Dangerous Plugin

What do you see?

You probably see phpMyAdmin and the underlying tables of your website as shown in the image below.

Portable phpMyAdmin First Screen - WordPress Plugin Danger

A subscriber to your website, who knows about this little trick, now has complete access to your underlying database. Do you think any damage can be done now?

Depending upon your server and database configuration, someone at this screen can destroy data, delete databases, create new databases, and generally wreak havoc on your WordPress website. If all your databases are common to one another, they now not only have access to the database for the website you have this installed on, but EVERY database in the cluster.

Choose a database from the dropdown on the left of the screen and see what you find. You will see all the tables in the database and a lot of information about them.

Portable phpMyAdmin List Of Database Tables - WordPress Plugin Danger

Think I’m panicking? Give it a try. Do something simple like change the UserName of your Admin Login – remember you are logged in as a subscriber ONLY and you would not normally be able to do this.

Featured Plugin - WordPress Facebook Plugin

Would you like to add Facebook comments, registration, 'Like' buttons and autoposting to your WP site? Well, The Ultimate Facebook plugin has got that all covered!
Find out more

How Do You Do This?

From the Database dropdown on the left side, choose the database you want to modify (hint, it will NOT be information_schema). Once the list of tables is showing, choose wp_users (for a single site installation) or wpmain_users (for a multisite installation).

Portable phpMyAdmin Select User To Modify

More than likely, the “Structure” tab will be active, so click the “Browse” tab and you will see the data stored in your database table in the bottom half of your screen. Click the box beside one of the usernames and click the pencil icon below the table contents. Note: Don’t use the pencil icon in the list of records as it takes you to your website and will probably give a 404 Error.

When the new screen opens, you can change the username and the email address associated with it and you now have control over that website. Don’t bother to change the password as it’s encrypted. Just use the “Forgot Password” feature in WordPress to change it and you are now set to go.

Portable phpMyAdmin Change UserName - WordPress Plugin Danger

There. That was easy wasn’t it. You have now taken over someone’s WordPress website – and it took very little time and effort to do it.

What Else Can Be Done?

As I said earlier, depending upon your server and database configuration and security settings, a lot can be accomplished. My server will not allow new databases to be created, but not all servers are configured that way. If that is not prohibited, then an unscrupulous person could create new databases, modify anything in your existing databases, delete your data or your databases, and a host of other things that can create more headaches than you really want to deal with. The simplicity and ease of accessing your database yourself is not worth the potential for problems created by someone else accessing that same information.

Convinced Yet?

Is this plugin still on your website? Well, what are you waiting for? Disable it…delete it…and never look back!

Shouldn’t The Developer Be Working On This?

The developer – and a few other people – have been working on this. In fact, Kapersky reported on December 14, 2012 that the solution was to update to version 1.3.1 because the developer had fixed the issues. Everything that you have seen in screenshots in this article is using that latest version and as you will see, the security hole still exists. Try it for yourself and verify my findings.

Regardless of the security changes that the developer – or anyone else – makes, I will not be using this plugin now or in the future. With all the other MySQL tools available, I’m not certain why you would actually need to have access to your database in the admin section like this plugin allows. There are better solutions that don’t compromise your security.

What Is A Better Solution?

There are several MySQL access solutions available on the market. Look into these:

Personally, I’ve found phpMyAdmin to be a real pain to use. I like and use Navicat regularly. I’ve found nothing so far that I’ve needed to do that Navicat could not do. As for all the others, I leave that to you without any opinion of my own.

Featured Plugin - WordPress Q&A Site Plugin

It's now incredibly easy to start your own Q&A site using nothing more than WordPress - The Q&A plugin simply and brilliantly transforms any site, or page, into a perfect support or Q&A environment.
Find out more

If you use any of these – or any other tool to access your MySQL database, please tell us about your experience in the comments below. I’d love to hear your thoughts and I’m sure our community would be interested as well.

Photo credits
woodleywonderworks via photopin cc

Comments (20)

    • Thanks for posting Alexus and I appreciate your comments.

      Supposedly that was what the “fix” was in v1.3.1 – but it didn’t fix it. Do you know how to do that easily? Personally, I don’t and I don’t want to take the time to figure it out.

      As I said, I have NO use for this plugin as I use Navicat. But, my purpose in writing this article is for the thousands of people that use WordPress daily that have NO CLUE how to modify the program or role verification or whatever. Those people may be using this plugin – thinking it’s perfectly secure – and then find themselves no longer able to use their WordPress website.

      Besides, this is NOT a WordPress page so I’m not sure any type of role verification would help anyway. It’s a “bypass” of any WordPress security as best as I can figure. To me, it’s just not worth the risk – even if I did do things to make it work. I’m pretty confident in my abilities to do things, but I’m not sure I could effectively plug the security hole.

      Bottom line, I just don’t see the need to open a security hole if there’s an equally easy way to do something that doesn’t open that security hole. But, if you have a work around, please do share it because I am interested in it and others may be as well.

      • > Do you know how to do that easily? Personally, I don’t and I don’t want to take the time to figure it out.

        Trac for WordPress or the Support forum. You could have Googled it to figure that out. Frankly, how are you even allowed to review plugins without knowing Trac?

        Not to bash you for reporting the vulnerability but still, next time at least take 1/10th the time it took you to write all of ^that and report it on Trac.

        • Thanks for your comments Chris…

          From what I understand about Trac for WordPress is that it’s for the CORE and not for plugins. The place to report issues with plugins is correctly stated as the support thread for the specific plugin. That had already been reported. Then, someone else took it upon themselves to “fix” the issue – not the original developer. But, the security hole remains.

          As I originally stated, I don’t have a single use for this plugin – even if it were airtight on security – because I use Navicat and am quite happy with it and it does so much more for me. I don’t even use phpMyAdmin – personally I find it extremely clunky and difficult to work with. Navicat is such a superior product to phpMyAdmin that I just stick with what works for me.

          As for fixing it myself, I’m not really interested. Reference my previous comment that I wouldn’t use it anyway. Feel free to fix it yourself (not you specifically, but anyone that is game). However, in the present state of the plugin, I stand by my article. It’s dangerous to use and “unfit for WordPress consumption”.

          Finally Chris, I’m sorry you feel I’m not qualified to review plugins simply because I’m unaware of Trac (your words not mine). I’ve never professed to be an expert in all things WordPress – just that I work with it a lot, I test a lot of things with it, and I take the time to document my experiences through articles that I write. I’m certain you will discover other things that you know that I do not – I’ll not deny that. But, my main job is to help my local business clients market themselves effectively in an ever changing online world. Anything that takes time away from that (such as correcting an error in someone’s plugin that I’m not going to use) is not serving my clients effectively. It is more important that I keep someone from using this plugin in it’s current state and jeopardizing their own or their client’s WordPress websites because they thought it was a slick idea – not realizing the dangers of it.

          • Gotcha Chris. Like I said, I was under the impression it was ONLY for the CORE. However, I suspect that most users of WordPress that have come on the scene in the past few years are unaware of it and would not know to check there before using a plugin. Plus, like I said, the problem has been reported in the support thread for that plugin and the error still exists. Bottom line, I felt a “Warning Article” was in order for it.

            Regardless, thanks for making me aware of this as I did not now about the Plugin Trac. I’m certain others will find your comments useful as well.

    • Goodday Miguel and thanks for the input. However, I’m curious what you like about Adminer. I could write an entire article about the things that I like when using Navicat so I’m sure you have some comments about what you like with Adminer. Please feel free to share them here so the entire community can benefit from your experience.

  1. Sadly, there isn’t yet a “perfect” db management solution for the typical user. Switching to phpMyAdmin won’t necessarily fix it as they release a security update several times per year. Adminer releases their fair share of security updates, too. Navicat and other client programs require that MySQL be accessible from external IP addresses at the server level, which itself is a security risk (MySQL releases a security update about once every two months).

    The *best* thing to do is to let your server admin maintain this type of thing for you and use the database management application offered by your host or control panel. DO NOT install your own, as it ends up increasing the security risk of the site and potentially the entire server. And if your server admin hasn’t secured MySQL so it isn’t accessible on 3306 for the whole world, consider switching providers.

    • Thanks for commenting Shawn. I always appreciate your insight and you’ve taught me a good bit about security, so when you post on a security related issue, I take note. I do have a quick question and it’s because I use Navicat – A LOT!

      I can’t access the MySQL database on my server without setting up a user in MySQL that has MY IP Address associated with it. If I take my laptop to a friends house and try to use Navicat, it will NOT connect to MySQL until I determine the IP Address at his location, and set up a user in MySQL for that IP address. When I leave his house, I destroy the access in MySQL for his IP. My IP is fixed so I don’t have to worry about someone else having access through the IP.

      Help me understand where that’s a problem because I’m really curious. I do a lot of troubleshooting and security work for clients, so Navicat is my best friend. For instance, I just resurrected a WordPress website for a new client that updated to WP v3.5 without a backup and the backup failed – taking their website down until I could get it back going. Without Navicat, my job would be a WHOLE LOT HARDER – mainly because I despise phpMyAdmin.

      • It sounds like what you’ve done (or your administrator has) is configure MySQL so that user accounts are limited by IP address (iow, users are created with explicit IP connectivity requirements, as opposed to ‘@%’). This is an absolutely wonderful step *towards* security, but isn’t quite there.

        Sadly, MySQL is still running on the server and accessible via port 3306. This means that any current (for your installed version) no-authentication-required exploits for MySQL will still work fine, and if the server has the default accounts created then anyone can login as ‘anonymous’, and if the default ‘test’ database is still there (or ANY database starting with ‘test_’), they may be able to “do evil stuff” on the MySQL server as well.

        Since MySQL is running and visible on 3306, it also exposes you to other nefarious login hacks such as setting the RDNS for the attackers IP address to ‘localhost’ – which would enable them to login to any account without a password or to perform a dictionary attack against the root/admin accounts, or any other account.

        There are still ways to minimize the risk of this, such as using IP filtering to forbid access to 3306 and only allow it to explicitly authorized IP addresses or enable it via port-knocking. But the safest way is to forbid access externally, which ensures that only users/scripts running *on* the server has access to MySQL.

        For your situation, you might want to consider setting up a VPN so you can use Navicat through your “home” connection even if you’re at a friend’s house. That’ll prevent you from wasting time with the temporary accounts and will actually increase the security of your laptop computer talking to the server. Check out Hamachi – there’s builds for most OSes. VPNs are good. :)

        • Hey Shawn.

          I copied your comments and sent them to my server engineer. He confirmed what I was thinking. We are buttoned up extremely tight. Something as simple as messing up the login ID and password from an unknown IP will get the IP banned for 60 days on the first occurrence.

          For most hosting though, you are extremely correct and I would suggest that others heed your comments and advice here.

          I remind many of my clients that whenever they try to make things “easy” on themselves, they are also making them easier on crackers tryin to access their websites. Easy doesn’t always equate to better – actually it rarely does.

    • Thanks for filing that Chris. Be sure to report back here if you get notification that something has been done to correct it. I’d be happy to retest and publish an update if the situation is corrected.

  2. Hello James, hello guys and girls. It was high time to update my plugin and fix the vulnerabilities.

    The steps I took in order to fix the vulnerability and the exploit are:

    1. I have added a GET parameter to check for direct access. If no parameter is detected, access is denied. The parameter changes with every plugin version.
    2. I have added an .htaccess DENY protection, again for direct access. I agree that phpMyAdmin (as standalone) does not have these protection layers.
    3. I have changed the phpMyAdmin directory name, in order to prevent future cached/remembered attacks.

    I have pushed the code to WordPress Plugin Repository, and I’m waiting for the approval. Let me know if there are any more vulnerabilities in the upcoming version – 1.3.2 – and I’ll try to fix them.

  3. Follow-up to my previous comment, I have pushed version 1.3.2.1 to the repository (the plugin is still hidden to the general public until review at the time of writing this comment).

    I have removed the phpMyAdmin version file (text) from its directory, and I have added a warning note:

    “This plugin should only be used for development purposes or by experienced users. If more users have access to the administration section, you should consider using the plugin only when necessary.”

    I will get some users to try and hack into the plugin and patch all existing holes (that I don’t know about yet).

Participate