The day after the hacking...?
April 21, 2012 7:04 AM Subscribe
My website was hacked. What now?
I have a small ASP project website that I run on a shared server using a third-party hosting provider. Upon visiting the other day, I find that the front page content had been replaced by a lovely hacked-by-so-and-so message. Based on file timestamps, it looks like this happened about March 23rd and I discovered it Wednesday (the 18th).
There appear to have been about eight files uploaded to the main site directory and the content of index.asp was changed. The new files appear to be all manner of ASP scripts designed to glean information about the other pages on the site, access to system files, etc. I can restore the original content, and I'm not as worried about the changes that were actually made. So far, it looks like none of the files in any of the important subdirectories were modified. I've already changed my password.
My questions are about the following;
1) Should my hosting provider be expected to help out or bear some responsibility for this? I called as soon as a noticed what had happened and was told to write an e-mail to technical support. The reply came the following day and basically said that I had waited too long to report the issue, that they don't have any logs remaining that would show what had happened, that they couldn't provide me with any details about whether the attacker had somehow gotten my password, and that I should change my password immediately — in other words, nothing of any use.
Is it reasonable for them to take any more responsibility or do any more to help me investigate the issue? Without more cooperation from them I can't determine what happened, so it's possible that they're at fault here. Should I demand that they look into it in more detail? Ask for my money back? Badmouth them to all my friends and clients? Or is this just the way it goes with third-party hosting?
2) Without the help of my hosting provider, how do I determine what happened?. The front page runs on ASP and AJAX — one ASP page uses AJAX to call static content from another ASP page based on the contents of a GET request. Where can I read up on AJAX vulnerabilities? What sorts of things should I look at to prevent this from happening again — if, indeed, it was my fault? With only those technologies in use, how, conceptually, might one have hacked the page? Anyone care to speculate?
I have a small ASP project website that I run on a shared server using a third-party hosting provider. Upon visiting the other day, I find that the front page content had been replaced by a lovely hacked-by-so-and-so message. Based on file timestamps, it looks like this happened about March 23rd and I discovered it Wednesday (the 18th).
There appear to have been about eight files uploaded to the main site directory and the content of index.asp was changed. The new files appear to be all manner of ASP scripts designed to glean information about the other pages on the site, access to system files, etc. I can restore the original content, and I'm not as worried about the changes that were actually made. So far, it looks like none of the files in any of the important subdirectories were modified. I've already changed my password.
My questions are about the following;
1) Should my hosting provider be expected to help out or bear some responsibility for this? I called as soon as a noticed what had happened and was told to write an e-mail to technical support. The reply came the following day and basically said that I had waited too long to report the issue, that they don't have any logs remaining that would show what had happened, that they couldn't provide me with any details about whether the attacker had somehow gotten my password, and that I should change my password immediately — in other words, nothing of any use.
Is it reasonable for them to take any more responsibility or do any more to help me investigate the issue? Without more cooperation from them I can't determine what happened, so it's possible that they're at fault here. Should I demand that they look into it in more detail? Ask for my money back? Badmouth them to all my friends and clients? Or is this just the way it goes with third-party hosting?
2) Without the help of my hosting provider, how do I determine what happened?. The front page runs on ASP and AJAX — one ASP page uses AJAX to call static content from another ASP page based on the contents of a GET request. Where can I read up on AJAX vulnerabilities? What sorts of things should I look at to prevent this from happening again — if, indeed, it was my fault? With only those technologies in use, how, conceptually, might one have hacked the page? Anyone care to speculate?
I don't know how it could take you so long to know -- my users get onto me very quickly -- are you sure of the timescale?
I don't think the forensics of what happened this time are likely to be much help against the next time.
Yes, you need to know enough about the technologies you are using to be aware of particular vulnerabilities, but you aren't doing anything spectacularly out of the ordinary, are you? You do know about sanitising any input before processing, don't you?
posted by Idcoytco at 8:22 AM on April 21, 2012
I don't think the forensics of what happened this time are likely to be much help against the next time.
Yes, you need to know enough about the technologies you are using to be aware of particular vulnerabilities, but you aren't doing anything spectacularly out of the ordinary, are you? You do know about sanitising any input before processing, don't you?
posted by Idcoytco at 8:22 AM on April 21, 2012
1) Should my hosting provider be expected to help out or bear some responsibility for this?
Not anymore than your landlord would be expected to bear responsibility for a break-in.
2) Without the help of my hosting provider, how do I determine what happened?
Commonly, this is caused by sites trusting that the data sent to them by a user (or what they believe to be another part of the site) is safe, when it might not be. Circular's example is classic: you allow users to upload attachments and then don't verify the contents of the attachments are safe. Then a user uploads "hack.asp" and visits http://yoursite.com/uploads/hack.asp, which does something nefarious with the same permissions as your web server. You need to make sure no user-submitted content can be executed by your server.
When you say you have an asp page that does things based on "the contents of a get request", what does that mean? If someone submits asp code in that get request, is it possible to execute it? What if someone asks for "static content" from an unsafe path (for instance, one beginning with "../"), can this return the source code for the site? Somewhere in the source code is there authentication information?
There are other attacks, but this one is simple and common.
posted by tylerkaraszewski at 10:25 AM on April 21, 2012
Not anymore than your landlord would be expected to bear responsibility for a break-in.
2) Without the help of my hosting provider, how do I determine what happened?
Commonly, this is caused by sites trusting that the data sent to them by a user (or what they believe to be another part of the site) is safe, when it might not be. Circular's example is classic: you allow users to upload attachments and then don't verify the contents of the attachments are safe. Then a user uploads "hack.asp" and visits http://yoursite.com/uploads/hack.asp, which does something nefarious with the same permissions as your web server. You need to make sure no user-submitted content can be executed by your server.
When you say you have an asp page that does things based on "the contents of a get request", what does that mean? If someone submits asp code in that get request, is it possible to execute it? What if someone asks for "static content" from an unsafe path (for instance, one beginning with "../"), can this return the source code for the site? Somewhere in the source code is there authentication information?
There are other attacks, but this one is simple and common.
posted by tylerkaraszewski at 10:25 AM on April 21, 2012
1) Should my hosting provider be expected to help out or bear some responsibility for this?
Be expected? Not really. If my apartment was broken into my landlord would want to be notified, but they're not going to hire a detective. It would be nice, but it's not really their responsibility. Read the fine print of your hosting agreement.
2) Without the help of my hosting provider, how do I determine what happened?
Every host is a bit different, but see what logs you have access to. My host only keeps raw access logs of the last day or 1000 visitors. It's rarely useful unless I know the minute it happened because it's tons and tons of crap showing way too much detail. ("This IP A sent a request B with version C of browser D on version E of operating system F with the request G that took H amount of time and the server responded with I and the code J". And there are about 50 of these each time someone visits one page.)
The Error log might be more helpful (My host keeps the last 300 errors) since someone, or some script, was likely monkeying around, they probably threw an error or a hundred trying different things. They probably sent some kind of data via a GET that was it's self a problem, or it triggered a flaw somewhere that allowed them subsequent access.
If your logs don't go back that far, look for crazy crap at the end of a GET request. They probably found your site by running a script by every site on the 'net and it will show in your requests.
And question 3:
3) How do I keep this from happening again?
Does your simple site really need these scripts? If not, get rid of them.
Do your site's scripts do anything that couldn't be done by a professional set of scripts? Replace them with scripts from someone who knows better. A well known and professional package will probably have been vetted by security folks who know what's what to minimize danger, and will release maintenance updates when they find new exploits.
Set up a site monitor. That link is just an example, there are dozens of free alternatives. Make sure you use one that can check the content of a page as well as uptime. (The linked one checks for the existence or absence of keyword on a page. If it's gone, someone hacked your site.) This will alert you within the hour of the hack and your host will be able to provide more information with current logs. Do not use a service that asks for login credentials to your site, they shouldn't need them.
posted by Ookseer at 10:31 AM on April 21, 2012
Be expected? Not really. If my apartment was broken into my landlord would want to be notified, but they're not going to hire a detective. It would be nice, but it's not really their responsibility. Read the fine print of your hosting agreement.
2) Without the help of my hosting provider, how do I determine what happened?
Every host is a bit different, but see what logs you have access to. My host only keeps raw access logs of the last day or 1000 visitors. It's rarely useful unless I know the minute it happened because it's tons and tons of crap showing way too much detail. ("This IP A sent a request B with version C of browser D on version E of operating system F with the request G that took H amount of time and the server responded with I and the code J". And there are about 50 of these each time someone visits one page.)
The Error log might be more helpful (My host keeps the last 300 errors) since someone, or some script, was likely monkeying around, they probably threw an error or a hundred trying different things. They probably sent some kind of data via a GET that was it's self a problem, or it triggered a flaw somewhere that allowed them subsequent access.
If your logs don't go back that far, look for crazy crap at the end of a GET request. They probably found your site by running a script by every site on the 'net and it will show in your requests.
And question 3:
3) How do I keep this from happening again?
Does your simple site really need these scripts? If not, get rid of them.
Do your site's scripts do anything that couldn't be done by a professional set of scripts? Replace them with scripts from someone who knows better. A well known and professional package will probably have been vetted by security folks who know what's what to minimize danger, and will release maintenance updates when they find new exploits.
Set up a site monitor. That link is just an example, there are dozens of free alternatives. Make sure you use one that can check the content of a page as well as uptime. (The linked one checks for the existence or absence of keyword on a page. If it's gone, someone hacked your site.) This will alert you within the hour of the hack and your host will be able to provide more information with current logs. Do not use a service that asks for login credentials to your site, they shouldn't need them.
posted by Ookseer at 10:31 AM on April 21, 2012
1) Should my hosting provider be expected to help out or bear some responsibility for this?
Depends on how attack was made. If it was a security vulnerability in your ASP code, I don't see how they could have any responsibility. They could of course help trying to track down the problem though. If it was a vulnerability on their side, yes, they have a responsibility.
2)Without the help of my hosting provider, how do I determine what happened?
I work with web application security, i.e. it is my job to try to find these kind of problems in web sites. The description you have given (files were changed on server) suggests a few possibilities (I have no idea if your site have any of the functionality I'm describing, I'm just telling about the some of the most common attacks I can think of were an attacker can change files on the server):
1) You have a file upload script that allows users to change files. E.g. a user can upload an image etc, and the path or filename is not properly checked.
2) You execute commands on the server based on user input. Often very easy to exploit.
3) Weak password. Your adminstrator password was easily guessed by a random or targeted attack. The password could also have been captured by an attacker if you accessed your server using an unsecure protocol such as FTP when connected to the Internet using e.g. a public WIFI hotspot.
4) SQL injection. Your site uses a SQL database, and you do not handle input parameters to the query directly. This doesn't match completely to your problem if it was static files that was changed, but on the other hand, if it was an MSSQL server you do have basically full access to the server after an SQL injection attack.
Does your ajax-scripts allow a user to make modifications on the server? e.g. change files, modify a database, etc? That is were I would start to look for problems.
One way to find out what happened is to have someone audit your source code. This can of course only reveal if there was any vulnerabilities in your code, it wont tell you if the hosting company had any vulnerabilities. And even if problems were found in your code, you can't be sure that was the problem either.
If your willing to share the code I could have a look for common vulnerabilities (see profile for contact details), otherwise you could contact a professionaly security company in your location. We do however usually charge a lot...
If you want to learn more yourself, Owasp is the place to start, especially the top ten list. If your site is using .net asp and not classic asp, Troy Hunts free book OWASP Top 10 for .NET developers is pretty good.
My suggestion is to check your code for security vulnerabilities, delete all files from the server, restore any databases from backups known to be clean and then upload your site again.
posted by rpn at 11:52 AM on April 21, 2012
Depends on how attack was made. If it was a security vulnerability in your ASP code, I don't see how they could have any responsibility. They could of course help trying to track down the problem though. If it was a vulnerability on their side, yes, they have a responsibility.
2)Without the help of my hosting provider, how do I determine what happened?
I work with web application security, i.e. it is my job to try to find these kind of problems in web sites. The description you have given (files were changed on server) suggests a few possibilities (I have no idea if your site have any of the functionality I'm describing, I'm just telling about the some of the most common attacks I can think of were an attacker can change files on the server):
1) You have a file upload script that allows users to change files. E.g. a user can upload an image etc, and the path or filename is not properly checked.
2) You execute commands on the server based on user input. Often very easy to exploit.
3) Weak password. Your adminstrator password was easily guessed by a random or targeted attack. The password could also have been captured by an attacker if you accessed your server using an unsecure protocol such as FTP when connected to the Internet using e.g. a public WIFI hotspot.
4) SQL injection. Your site uses a SQL database, and you do not handle input parameters to the query directly. This doesn't match completely to your problem if it was static files that was changed, but on the other hand, if it was an MSSQL server you do have basically full access to the server after an SQL injection attack.
Does your ajax-scripts allow a user to make modifications on the server? e.g. change files, modify a database, etc? That is were I would start to look for problems.
One way to find out what happened is to have someone audit your source code. This can of course only reveal if there was any vulnerabilities in your code, it wont tell you if the hosting company had any vulnerabilities. And even if problems were found in your code, you can't be sure that was the problem either.
If your willing to share the code I could have a look for common vulnerabilities (see profile for contact details), otherwise you could contact a professionaly security company in your location. We do however usually charge a lot...
If you want to learn more yourself, Owasp is the place to start, especially the top ten list. If your site is using .net asp and not classic asp, Troy Hunts free book OWASP Top 10 for .NET developers is pretty good.
My suggestion is to check your code for security vulnerabilities, delete all files from the server, restore any databases from backups known to be clean and then upload your site again.
posted by rpn at 11:52 AM on April 21, 2012
one ASP page uses AJAX to call static content from another ASP page based on the contents of a GET request
That right there is most likely your problem. Would I be correct in saying that the get request contains the url of the file to fetch/include? My asp is rusty but the same thing works in php - they create their own GET request where the filename that gets passed to your script is a text file on their server. Your server includes the file and executes the code (since its a text file the code doesn't get run/parsed on the host server), this code usually searches for insecure folders - ie ones the script can write to (although I think on windows that would be all of them) then it creates the other files - was one of them c99.asp? These files give them access to a hue amount of information about your server and power to do stuff.
Is your host responsible? Not unless they provided the script. Its possible security settings can be changed to prevent remote file includes (don't know if that's possible with asp but that's how its done with php). If you have access to change those settings and you wrote the script then you are 100% at fault. If they exist (not sure that they do) and you paid someone else to write the script then I'd say the person who wrote the script is 90% at fault and the host is 10% at fault.
posted by missmagenta at 12:32 PM on April 21, 2012
That right there is most likely your problem. Would I be correct in saying that the get request contains the url of the file to fetch/include? My asp is rusty but the same thing works in php - they create their own GET request where the filename that gets passed to your script is a text file on their server. Your server includes the file and executes the code (since its a text file the code doesn't get run/parsed on the host server), this code usually searches for insecure folders - ie ones the script can write to (although I think on windows that would be all of them) then it creates the other files - was one of them c99.asp? These files give them access to a hue amount of information about your server and power to do stuff.
Is your host responsible? Not unless they provided the script. Its possible security settings can be changed to prevent remote file includes (don't know if that's possible with asp but that's how its done with php). If you have access to change those settings and you wrote the script then you are 100% at fault. If they exist (not sure that they do) and you paid someone else to write the script then I'd say the person who wrote the script is 90% at fault and the host is 10% at fault.
posted by missmagenta at 12:32 PM on April 21, 2012
FWIW when I had a similar thing happen, examining the recent access logs was actually quite helpful--even though they didn't necessarily show the exactly time/manner of the attack, which was further in the past than the logs showed. What they did show is the type of automated attack that was routinely happening and what those types of attacks usually looked like.
Normally they will use scripts to automatically take guesses at typically software packages and the typical directories they are typically installed in--and you may be able to see the actual attack info being passed along as part of the http request. 99.999% of these attacks will fail because you don't have that software package installed, or you have patched vulnerability, or you have it installed ina different directory, etc. But that remaining .001% is where you get hacked. But by looking at these logs, even without seeing the exact hack that installed these files on your site, you may get quite a bit of inspiration into the type of things that are coming at your site and the type of thing you might be able to do to stop it happening.
When I looked at our logs I immediately started thinking about a few possibilities I hadn't considered before, that that led me to fix a security problem in a package I had earlier installed but only occasionally used--and that seemed to stop the hacks from ever happening again.
posted by flug at 6:38 PM on April 21, 2012
Normally they will use scripts to automatically take guesses at typically software packages and the typical directories they are typically installed in--and you may be able to see the actual attack info being passed along as part of the http request. 99.999% of these attacks will fail because you don't have that software package installed, or you have patched vulnerability, or you have it installed ina different directory, etc. But that remaining .001% is where you get hacked. But by looking at these logs, even without seeing the exact hack that installed these files on your site, you may get quite a bit of inspiration into the type of things that are coming at your site and the type of thing you might be able to do to stop it happening.
When I looked at our logs I immediately started thinking about a few possibilities I hadn't considered before, that that led me to fix a security problem in a package I had earlier installed but only occasionally used--and that seemed to stop the hacks from ever happening again.
posted by flug at 6:38 PM on April 21, 2012
This thread is closed to new comments.
The host helped me by offering to delete stuff. They didn't even advise me to change passwords. Since that point I'm pretty used to that behavior in the various hosts I use. What I look for is how helpful support is. They don't have to be, but many are.
posted by circular at 7:33 AM on April 21, 2012