Quite distressing security issues

[andrew2110]

Hi Guys,

 

Over the last couple of weeks my site has been hacked repeatedly, first the administration section of the site only - so I took steps to make this fully secure including restricting it so only certain IP / Pin number combinations can access it, followed by a login over SSL using encrypted password / username combo... Just when I was feeling proud of myself for making something I thought was pretty secure, I find out that a whole table in my database has been emptied.

 

Luckily I back everything up every night so not much was lost, but still I need to find a way to try and stop this kind of thing from happening. The only two ways I can think of that people could do something like this would be to find how to login to my plesk control panel and login to the mysql database from there from which they would see phpMyAdmin... Or do some kind of mysql injection from one of the html forms on my site.. Are there any other methods people could use to ruin my database like this?

 

If anybody fancies trying to break my system and letting me know how I can fix it, please send me a PM

[Brian W]

mysql injection is likely it. I'd give you a percentage, but i'd be out my A$$, but its a really high percentage of php related hacking is mysql injection. You need to make sure that ANYWHERE that people can input info that even touches your database (likely 100% of your forms) you have the stings being stripped of anything potentially bad; namely double and single quotes. " '

look into the manual about magic quotes

Some one else may be of more help to you, but thats my 2 cents.

[andrew2110]

I agree with you, and the only part that doesnt strip that bad things is the part that wasn't intended for public use (the admin section which was hacked into)... I'll double check that no mysql injection can take place... It's all quite terrifying why people want to try and hack my silly little site though, it's not even launched yet

[xtopolis]

Also, change ALL passwords relating to your site, and start fresh.

Plesk, mysql,etc.. all passwords, even ones only "you" know.

 

Even your admin section should have checks and balances.  But like I said, possibly start fresh, checking each page at a time as you reimplement it, or start from scratch.

[Brian W]

they hack it for kicks and grins , shits and gigles

or just to make you sad  :'(

either way, it make me mad  

lol, I like smileys... any ways.

What are you using to make their input safe for digestion?

[Brian W]

Also, change ALL passwords relating to your site, and start fresh.

Plesk, mysql,etc.. all passwords, even ones only "you" know.

 

Even your admin section should have checks and balances.  But like I said, possibly start fresh, checking each page at a time as you reimplement it, or start from scratch.

He has restricted the IP address to only his he says, thats a decent check isn't it? (only one problem, sometimes your ISP changes your IP)

For information on strong passwords: http://www.microsoft.com/protect/yourself/password/create.mspx

 

[andrew2110]

The admin section is the only section with that level of security (only allowing my IP address), I'm pretty happy that part can't be hacked now, sometimes the IP address might change and I'll have to reconfigure which IP address / pin number combo is allowed but thats a small price to pay..

 

For cleaning up all other form inputs I have:

 

$allowedTags='<p><strong><em><u><h1><h2><h3><h4><h5><h6><img>';
$allowedTags.='<li><ol><ul><span><div><br><ins><del>';
		$inputContent = strip_tags(stripslashes($_POST['inputData']),$allowedTags);
		$inputContent = addslashes($inputContent ); 

Which I thought should do the job... but perhaps not...

 

[xtopolis]

He has restricted the IP address to only his he says, thats a decent check isn't it?

 

No.  If they have access to his cpanel, mysql database, ftp, etc, they can circumvent his stuff.  That is why I suggest he starts fresh, changing every password.  Why would I use a script/webpage to do something, when I can directly interface with mysql, raw files?

 

In a vast majority of security related issues, the attacker is usually someone that the attackee knows, or that the attacker knows information about.  When it comes to security, there is no such thing as trust.  If his site is small and not yet even released, then why would someone attack it?  A good hacker will hack for value/profit, not usually for fun.  So, @the op, did you piss off anyone recently that would have a reason to hack your site?  Or does your site hold something of value?

[CroNiX]

Most likely they hacked in through the url via variables being passed through $_GET/$_POST.  One thing to do is whenever you are doing something with the database in your code and it uses something from $_GET/$_POST to access data in your db you need to sanitize that variable.

 

Like if you have some SQL that is similar to this:

SELECT * FROM tableName WHERE username = '$_POST['username']';

 

Before you run a query like that you need to properly escape it.

$username = mysql_real_escape_string($_POST['username']);

then you can

SELECT * FROM tableName WHERE tableName.username = '$username';

The problem when you are using a form or something that gets data from the user (or even just from the url variables, the user can type in SQL into that form and do just about anything they want...like DROP tableName;

If you sanitize anything retrieved via $_POST/$_GET you can eliminate most of this.

 

[discomatt]

mysql_real_escape_string() > addslashes()

 

Also keep mind that strip_tags doesn't always do it. You can include malicious javascript in an attribute of an allowed tag, and perform XSS attacks.

[andrew2110]

We're a skill gaming site and in prelaunch I think we've managed to upset a rival site - uvme.com who have seen some of their associates come over to us. Not saying thats absolutley the case that they've come and started to try and hurt us, but just speculation, but then there are several other big companies in the market who might have their feathers ruffled by us..

 

All passwords are now changed. I don't really have any friends that are capable of doing anything like this and out of the people working on the site with me, I'm the only one who's ever touched the database as the others cannot do any programming whatsoever...

 

The site is www.dukesbox.com ...

 

I think the only approach I should proceed with is one of absolute paranoia in that nothing should be trusted completley and to backup the database as frequently as possible.. (twice daily)...

 

 

@CroNiX - I'm no master of PHP but "strip_tags(stripslashes($_POST['inputData']),$allowedTags);" was intended to strip anything other than a few simple html tags that shouldnt do any kind of harm? It was my understanding mysql_real_escape_string() would also get rid of any basic html formatting I might want to let users input?

 

[CroNiX]

mysql_real_escape_string doesn't touch html, it escapes single and double quotes so the database doesn't take them literally.  Also, setup mysql so that the user account you are using to access mysql via your application doesn't have DROP privileges, unless you actually use DROP in your code.  Most people don't DROP tables in their code so I always advise this.  Also, whoever did this could have also placed malicious code in your code...so you better check it.  One of the main places to check is wherever you are creating new accounts.  One thing some hackers like to do is insert code so that when a new account is created it emails the user/pass to some address so they can use it.

[andrew2110]

Good advice about the 'Drop' and I'll apply that to 'Empty' as well. All I'll allow is update, insert, delete, select as thats all we use really...

 

Just done a scan of the code and all seem's to be ok, although we're showing that our CPU's our currently running at close to full capacity and with only a few users online and a quad core processor, leads me to think that perhaps a new attack is starting on our site (DDoS?)

 

 

[PFMaBiSmAd]

Take a lot of the guesswork out of how this is occurring by checking your mysql query log. It lists when, what mysql username, and what the query was that was executed.

[discomatt]

@CroNiX - I'm no master of PHP but "strip_tags(stripslashes($_POST['inputData']),$allowedTags);" was intended to strip anything other than a few simple html tags that shouldnt do any kind of harm?

 

<pre><?php

$str = <<<XSS
<img src="blank.gif" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%; z-index: 999;" onclick="alert( 'XSS attack goes here' )" />

<script type="malacious">
but it really doesnt matter
</script>

<br /><br /><br /><br /><br /><br /><br /><br />
some random text
<h1>other text</h1>

XSS;

echo strip_tags( $str, '<img>' );

echo '<br /><a href="#">Please click this link!</a>';

?></pre>

[andrew2110]

Right I understand now,

 

So even harmless sounding tags like <img> can include some nasty bits...

 

So:

 

$inputContent = strip_tags(stripslashes($_POST['inputData']),$allowedTags);

$inputContent = mysql_real_escape_string($inputContent);

 

strip_tags then mysql_real_escape_string() should be ok?

 

[xtopolis]

First, read PFMaBiSmAd's advice, and check your logs.

 

Secondly, use BBC style replacements instead of allowing code tags <,>  -> [,]

 

You can test common HTML injections at http://ha.ckers.org/xss.html

Mysql, can be further filtered... by accepting parameters(wrong name?) instead (read this when you have time: http://www.scribd.com/doc/2670985/SQL-Antipatterns)  It's towards the end

 

As for your site security, you should always know expected inputs, and only allow variations of those.  Even if you allow HTML code, you start with allowing NO TAGS and then enable only the ones you want..  and even then , like I said, use BBC to replace user input, and switch it back on output.

[discomatt]

Use a good HTML filter class if you MUST have HTML ( If BBCode isn't flexible enough )

 

http://htmlpurifier.org/

 

or

 

http://php-ids.org/

 

PHPIDS is strongly community backed, and has the support of a bunch of guys who wrote the XSS cheat sheet.

[xylex]

Found a few SQL injection spots in your app.  Anywhere you're putting an unquoted value, like a number, into your SQL query, the method you're using to sanitize won't do anything.  addslashes() is only designed to prevent people from breaking out of a quoted string, and they're already out at that point.

 

Sanitize user inputted numbers using intval() or quote them where appropriate in your SQL query.  These spots should be apparent, but if you need help, PM me if you need some specific spots that you have this issue.

[andrew2110]

Thanks for your advice guys, It's all been taken on board and I'm now putting all the advice to good use and hopefully making it all a lot more secure.

 

[waynewex]

You should go to the BETA part of the PHP Freaks Forums. (It's one of the sections at the bottom beside Misc and Critique). I know for a fact that a guy called DarkFreaks who frequents that area often does a free test with his Acunetix Web Vulnerability scanner. That will tell you exactly where the weak spots, and will also tell you exactly how to fix it. You also might want to give him a login so that the scanner can log in and do the same things as a regular user.

[andrew2110]

Thanks for the advice, I'll visit that part of the forum as soon as I've gone as far as I think I can with fixing any security issues

[waynewex]

One thing I never do is place my admin section inside a folder called admin. Or anything else that can be guessed via brunt force.

 

 

[discomatt]

One thing I never do is place my admin section inside a folder called admin. Or anything else that can be guessed via brunt force.

 

Security through obscurity is not good practise... nor should the location of your script be considered a security measure ( beyond storing files outside of webroot )

[Psycho]

One thing I'll throw out - although it is implied but not explicitly stated above - you should validate and sanitize AND and ALL information comng from the client.

 

For example I have seen instances where no validation was performed on a certain field because a select field was used on the input form and the person writing the code assumed the select field would prevent other values. There is nothing preventing a user from creating their own form and posting it with any values they want. So check everything even if the form would prevent them from sending unknoiwn values: select fields, hiddent fieds, checkbox values, etc.

 

Also should validate cookie values as well.