Locked out of my own database

[evansste]

I recently launched my new website, and in just a few days I have been locked out of my MySQL database.

 

My website makes use of a few tables within a MySQL database.  However, now when my website tries to access that database, it is given no access -- and neither am I when I try to access it via the control panel.

 

I'm pretty sure that someone changed the password to my database.  For my website, I wrote several PHP functions that use tables within the database.  In order to connect to the database, I had to give the username and password within the PHP functions using the "mysql_connect" function.

 

mysqli_connect(host,username,password,dbname);

 

Because this information can be found inside the PHP functions, and because my PHP functions are located inside the "public" directory for my web host, could someone have gotten this information, and then changed my password through my control panel?

 

I have contacted my web host and they are investigating the issue of my password being changed.  But does it sound as if someone could do something like this if the source code for all of my pages is in the "public" directory?

 

I'm no expert when it comes to building websites.  I was happy to finally get my website to work.  Now, it seems, that I have to deal with people being malicious.  What's the best way to keep someone from being able to change the password to my database?  Is it a problem for me to keep my functions in the same directory (the "public" directory) as my other website pages?

 

The good news is that people are starting to visit my website.  The bad news is that some of these people have bad intent.

 

Thanks for your time.

[mac_gyver]

a visitor to your web site cannot see or access the raw php code, assuming it's stored in .php files.

 

if your database credentials are stored in a file ending in a non .php extension and someone has guessed the file name, they can request the file and see the contents of the file. they could likely then access the web host's phpmyadmin page and make alterations.

 

however, if your web host hasn't secured the folders for each account so that only that account has permission to access its folders, other accounts can access anything on the server.

 

another possibility is that you have code that allows anyone to read/display/download an arbitrary file and someone used it to cause your own code to output the contents of your .php files.

[ginerjm]

Jacques1 will have a field day with this post soon.

 

Anyway - You shoud create one small include file that does your connect process and ONLY in that place should you put your credentials.  Then that script should be stored outside your public web tree along with all of your other (my practice) important code.

 

And yes - there are plenty of malicious users out there as J will tell you.  Always always practice security.

[evansste]

Thanks so much to both of you!

 

After reading what mac_gyver said about .php files with the .php extension not being able to be seen by users, I started to feel a sense of relief.  All of my php files have the .php extension.  But then mac_gyver said that if my site allows downloads, this may be another way that the information could have been obtained.

 

My site doesn't allow users to download any file that they want arbitrarily, but it does generate a separate .php file that users are allowed to visit so that they can download a specific file that the website has generated for them.  The php link is simple, and is as follows.

 

<?php
header('Content-disposition: attachment; filename=expression_.txt');
header('Content-type: text/plain');
readfile('expression_.txt');
?>

 

As you can see, the file that they are then allowed to download is a simple text file -- In this case "expression_.txt".  The site directs them to a web page that contains only the code that's shown above.  So when they go to the given link, they are able to download the file.

 

Could a link to something that is as simple as what's shown above, allow people to download my password and username for my database?  Or is it too specific to allow them that kind of access.

 

I'll certainly do what you've suggested, ginerjm, about putting the "connect" statement in a separate include file, and restricting the information to that file alone.  It's a smart thing to do that I never considered.  At the very least, if I ever decide to change web hosts, and have to change the log in information, I'd only have to do it for one file.  Smart idea.  Thank you for that.

 

The information that both of you have given thus far is invaluable, and I thank you greatly for it.  This is a very useful forum!

[mac_gyver]

if the 'expression_.txt' filename can be specified by the visitor in any way shape or form (pun not intended), via a form field, hidden or not, a parameter in a link, a cookie, or via a database query where sql injection is possible..., then yes, they can get your code to download any file they want.

 

another possibility, is if your site allows uploading files, someone could have uploaded a .php script and has their own file manager script somewhere on your site. 

[evansste]

Thanks for your response, mac_gyver.

 

The website does generate the file name.  However, it does so incrementally.  Therefore, it may not take a genius to figure out what the next name would be.  But I can make it so that the file names, that the site generates, are more random.

 

As for uploading -- the site does allow people to upload files.  However, it only allows text files to be uploaded.  Would their uploaded file have to have the .php extension in order to sabotage my system?  The site only allows files that have the .txt extension.  Does this offer any security?

 

Thanks again for your responses.

[gizmola]

Hi evansste,

Security is a very complicated subject. In my experience, and unless you have some enemies out there targeting you, it's highly unlikely that someone would spend the time to try and exploit your specific site. Most attack vectors are automated, and the exploiters are not interested in your specific system. Typically exploits attack some known weakness of the operating system or a specific package you might be running like wordpress or joomla or phpbb.

 

Scripts you run that you otherwise don't understand would be the most likely culprits.

 

You currently don't have enough information to even determine that your password was changed. That's an assumption that could be entirely incorrect. We could all conjecture until the cows come home, but I find it unlikely that someone would exploit your site with the specific goal of changing your mysql password which only serves to tip you off that something has changed.

 

Really, your specific hosting setup is the first thing someone would need to understand. There are bad shared hosting setups for example, as alluded to previously, which make it easy for someone on the same shared host to read all the files in your webspace, but I find it hard to believe in 2014 that there are too many shared hosts who still run those types of setups. For the most part, they implement fastcgi and insure that the apache process(s) run as your user, so that those types of "trusted user" exploits aren't possible anymore.

 

For all we know they had a blip in their setup or someone screwed something up so that you can't attach to their mysql server as the same user anymore. If you did have a sql exploit, they might also have dropped your entire database (if it's an especially malignant and destructive bot) but again, that is not the goal of most exploitations.

 

What they want is access to your resources, typically to run programs, store files and serve them (leeching your bandwidth) or send spam email through your server. All this is automated. In order to get what they want, they have to be able to control their botnet, and often this is done through IRC channels, so a telltale sign of compromise is that they setup outbound irc connections to their control channels. Sometimes their scripts screw up, but changing a mysql password is just something these exploit scripts wouldn't do intentionally.

 

Only someone with root access is going to be able to probe and figure out what exactly has gone on with your server/instance etc.

[evansste]

Thanks, gizmola.

 

I truly hope you're right and it turns out that my web host simply dropped the ball somewhere along the line.  If that's the case, that would be terrific.  It's an easy fix, and it's all work that they have to do.  I already alerted them that I can't get into my database, and they're looking into it.

 

One of the things that I hate most about the idea of it being a malicious attack is that a person may see this as some sort of game.  They like the idea of outsmarting a system.  If that's the case, then that requires me to have to try to think of things that they may think of, and, as I've said, I'm no expert when it comes to programming a website.  I hate the idea of having to spend all of my time dealing with this sort of thing, when all I want is a website that works.  So I truly, truly hope you're right.

 

My website is relatively simple.  I have a database that only has two tables in it, and each table only contains one column.  The entire website only has 46 script pages -- that's including all of my functions and test pages.  It wasn't very hard to figure out that my access to my database was changed.  There are only four functions that access the database, and two test pages that I can use to easily view the contents.  The site has been running successfully for about two days, and I've made no changes to anything during that time.  Then, all of a sudden, I noticed that jobs were backing up -- they weren't being sent out like they're supposed to.  One of the functions, that needs to access the database, isn't able to connect to it.  So I tried one of my test pages in order to view the contents of the two tables in the database.  I received a message saying that I don't have access.  So I tried to log in to the database via control panel.  I received a message saying that the information that I entered was incorrect.

 

Access to the database is, without a doubt, the problem.  I spoke with my web host, and they weren't able to gain access to the database with my information either.  Hopefully you're right and they end up telling me that it was some mistake that they made.  Then my website can go back to working properly, as before, and I won't have to fix anything.

 

I do still intend to make the change that ginerjm suggested -- putting all of my credentials in a single include file.  But that's an easy change because there are so few functions that use the database.

 

You're right that I jumped to the conclusion that my password had been changed.  This is because one day I have access, and now today, I don't.  I didn't change my password, so I couldn't think of another reason why it was saying that my information was wrong.  I didn't consider that the web host could have dropped the ball.  After all, I've been working on the site for weeks with no incident like this.  Then, two days after launching the site and promoting it, I run into this.

 

Security wasn't my focus when I built the site.  I was just happy to get it to work.  So my assumption of sabotage is logical, but you're right that it could be something else.  I hope you're right.  Then all of this would just go away.

[gizmola]

Just out of curiosity, why would it take so long to get an answer on your db access?

 

Here's the way mysql security works: First you have users. The form of a user name is sort of like an email address:

 

 

user@hostname

 

 

So to begin with, it is possible to have something like this:

 

 

user@foo.ourdomain.com

 

or

 

user@30.232.33.15

 

When you run mysql on the same server, users are typically constrained as:

 

user@localhost

 

This means that only someone attempting to attach from the same machine (via localhost) will be given access.

 

If you want to understand this better you can google for "mysql GRANT" which is the SQL used to create a user and grant them access to a database.

 

Again, knowing nothing about your hosting company, they could have a mysql server that is on a different machine. This is easy enough to determine from the host string instructions that show up in your control panel. If you're connecting to a remote mysql server (or more specifically, if your php script is connecting from the hosting machine across their network to another box) then the specifics of that connection have to be configured correctly.

 

So it's possible for you to have a user where due to issues with IP's or DNS names internal to their network, had access but now is being rejected.

 

There are a number of different problems, and really only the hosting company can do much. However, it wouldn't hurt for you to write a simple connect script that tried the connection and then returned the specific mysql error.

 

 

<?php

$db = new mysqli('host', 'user', 'pass', 'database');

if ($db->connect_errno > 0) {
    die('Unable to connect to database [' . $db->connect_error . '] - Errorno:' . $db->connect_errno );
} else {
    echo 'Connected ok';
}

[evansste]

Thanks for your response, gizmola.

 

My hosting company finally did get back with me yesterday.  They sent me an E-mail message showing my new credentials.  They didn't state what the problem was -- only that they fixed it.  I have since gotten the site up and running again with the new credentials that they gave.  I also implemented the changes that ginerjm suggested.  Having all of the credentials in a single file really will come in handy if I ever need to make changes to my password, or anything else.

 

One of my test pages connects and shows me the contents of the tables in my database.  Because it connects to the database, it's very similar to the example that you gave about making a connection and seeing what errors pop up.  When I ran my test page, during the period of time when things weren't working, it simply gave me the error that I was denied access to the database.  It confirmed that I was trying to use a password, and that I didn't have access.

 

I have noticed that my web host has changed my password, but, as I've said, they never really stated what the problem was.  Quite frankly, I'm just happy to have the site working again.

 

If you're right that the web host simply made some mistake with their server, and that no one was trying to sabotage my web site, then I shouldn't run into this problem again -- or at least not very often.  But if someone is trying to do something malicious, I would guess that they'll see that my site is working, and they may try something else.  Hopefully you're right, and there is no one out there trying to do something like this.  You have a lot more experience than I do, and your suggestions on the issue make a lot of sense.  So hopefully, this is the last time I'll run into this problem.

[gizmola]

Glad you got it working again.

 

My point about the script I provided was that it would give you the exact mysql error string and error number. Those specifics are important for anyone trying to delve into the issue, but that's not a problem at the moment.

 

What ginerjm suggested is indeed best practice, so that's good. You don't want any configuration files, or user submitted files to be placed beneath the webroot to avoid exploits based on default webserver configuration behavior or unintended execution.

 

You also don't want any of those directories to be writable by the web server process either. Of course to understand how to lock things down, you have to understand the way the web host has set things up, which typically involves being able to ssh into your server and look at the web server processes using ps, as well as the directory permissions.

 

So in terms of uploads, while this might be a bigger project for you, it's ideal if you store those files outside the webroot as well, and utilize a script that returns them to users when access is desired.

[erikla]

Interesting Thread! I have often thought about how safe database passwords really are. At my former Web Hotel they offered a directory below the root of the webpage. Here I placed the php-file (say passw.php) containing the password and linked to it from the other php files with a require(passw.php) command - better than include, I have been told. Then I changed webhotel and the new one didn't have any directories below the webroot. So I wondered if it was now less secure. After asking, I trusted their explanation that it isn't necessary. 

 

As from what has been discussed above, I conclude that the password cannot be accessed by strangers if it is placed in a php-file, unless other files on the site, for example pages with HTML forms, are vulnerable to sql injection OR if certain settings in the web hotel allow for free downloads OR if people working at the webhotel accidentally makes any mistakes, which will exploit the site ... I hope this is correct? 

 

I have never considered the different settings at my web hotel. I hope the default settings are so that people cannot download freely. What should I be looking for?

 

From what I read from your last contribution, gizmola, I understand that you suggest that the file containing the database password should NOT be placed below the webroot and even in the webroot. Is that correct? Then it could be in a folder just above the root ...

 

Thanks for a great Forum!

 

Erik   

[kicken]

Interesting Thread! I have often thought about how safe database passwords really are. At my former Web Hotel they offered a directory below the root of the webpage. Here I placed the php-file (say passw.php) containing the password and linked to it from the other php files with a require(passw.php) command - better than include, I have been told. Then I changed webhotel and the new one didn't have any directories below the webroot. So I wondered if it was now less secure. After asking, I trusted their explanation that it isn't necessary.

Your post makes it sound like your idea of above vs below the web root differs from what most people believe. That may lead to some confusion. Think of the folder structure as an upside down tree with the root folder at the top and everything else below that moving down.

 

So if you web root was defined as /var/www/example.com/public_html then the folder /var/www/example.com/includes is considered to be above (or same-level as) the web root. The folder /var/www/example.com/public_html/includes/ would be considered to be below the web root.

 

Placing your configuration files somewhere above the web root is ideal if possible. By doing that if the server ever happened to be mis-configured and not parse the PHP files properly then someone will be unable to read them as the web server will not serve them. If you must put them below the web root then you need to ensure they are named with a .php extension so they are parsed by PHP and will result in a blank page as output rather than dumping their contents as text.

 

Regardless of where you put the files, you also need to ensure you protect yourself and ensure any download scripts you might have cannot be coerced into reading an arbitrary file. Even files above the web root could be read and downloaded this way if you had an exploitable download script, all someone would need to know is the path to the file.

[erikla]

My trees have their roots at the bottom. I realize this is not the common way Sorry about the confusion. Anyway, with your description I now better understand the issues concerning security.

 

Thanks, Erik