This hacking does not takes place by any PHP application vulnerability nor any kernel bug nor apache bug nor cpanel or Plesk bug. Those accounts files are affected whose FTP logins are leaked.

ONLY THOSE ACCOUNTS ARE HACKED WHOSE FTP LOGIN DETAILS ARE LEAKED AND ARE WITH HACKER !!!!

How it’s done

This is a sophisticated operation, and the infection cycle is involved, but basically, the hacker(s) are setting up innocent looking sites (or using previously hacked sites where the owner is usually unaware of being compromised) and loading them with expensive hacking tools like Mpack. When someone visits that site, their browser is detected and attacked (browsers affected are IE, firefox and opera). The visitor is unaware that they may have a keylogger that sends the persons passwords ect to the hacker(s) and moves on. If the innocent visitor has an ftp or root password for any internet sites, the hackers use a program that goes to the persons site(s) and instantly adds the hidden iframe to every index type page. This is why there seems to be no indication that the site has been compromised, as the hackers already have the ftp or root passwords to login. And since they have at least your account ftp pass, whatever permissions your folders and files are set to make no difference.

After they put the iframe code into that person’s pages, anyone visiting that site will be redirected to the hackers infection site, where the person’s computer will be injected and infected. The hackers are depending on site owners not knowing their sites have been hacked so that the number of hacked sites will grow (as they have starting in Italy) into the tens of thousands… Please don’t think you can depend solely on your antivirus software to protect your computer. It more than likely won’t help you. For $1000 dollars, the russian hacking bulletin boards are offering Mpack with 1 year support and a GUARANTEE that virus programs will not catch the keyloggers. SO, keep your virus program updated, but don’t depend on it completely!

This way this hack is spreading fastly from one computer to another broadcasting the passwords to hackers.During my research in this, I even found some of the password files collected by the hack on some of the hacked server, where they pass this password file to thier tool to add the code. In some cases Google bots picks this files and you can even find the login details of FTP accounts and Server root login details in google.

===============================================
Solution:
===============================================

For Server Administrators:

If you are having this problem server wide then the only possibility is your root password is used for this. Just change the password and this HACK WILL STOP

For individual person owning just a domain and not server:

If you are facing this problem and your administrator says its only your account, just change the FTP password and it will stop

You must have removed the code many times and it comes again, why ???
As you dont change the FTP password. So change that first.

Just changing password is not complete solution but is the first step.
Whats next, your password is leaked that means your computer is sending out the passwords, so I would suggest you to do a clean format first and then install any antivirus of spyware which you think could block it. But the best solution is to clean format the computer.

Just do the two things:

1) Change the FTP or root password of server
2) Clean format the PC

and take care in future, you dont visit any of the virus links made by this hack.
Also to keep your password secure I would suggest you to use any password manager software.

Warning: do not try the URLs here unless your system is locked down properly. I suggest using a “virual machine”  (I use VMware) to test things like this. The hack itself is complicated, the system is simple – skip the complicated part if you’re in a hurry.

It all started with a posting like this:

When I do a google search for [Jonathan Wentworth Associates] the first result is:

Jonathan Wentworth Associates, LTD
Welcome to Jonathan Wentworth Associates, a respected resource for world-class orchestral soloists,
conductors, opera, chamber music, chamber orchestras, …
www.jwentworth.com/ – 19k – Cached – Similar pages – Note this

The: “Jonathan Wentworth Associates, LTD” is highlighted and is a link to the web site. If you place the mouse over the link, it shows http://www.jwentworth.com. However, if you click the link it immeately attempts to download the trojan. My McAfee immediatly blocked it.

Looking at the page in question, it doesn’t appear to be hacked, it doesn’t appear to have any kind of scripts injected, etc. However, using LiveHTTPHeaders with Firefox, while doing the same steps (search, click on the top result) you see the following:

GET / HTTP/1.1
Host: www.jwentworth.com
HTTP/1.x 302 Found
Location: http://85.255.117.38/ind.htm?src=324&surl=www.jwentworth.com&sport=80…

GET /ind.htm?src=324&surl=www.jwentworth.com&sport=80&suri=%2F HTTP/1.1
Host: 85.255.117.38
Referer: http://www.google.com/search?q=Jonathan+Wentworth+associates
HTTP/1.x 302 Found
Location: http://www.jwentworth.com/

Without going through Google, the page is returned right away, just like it should. Search engine crawlers also get it like that. After the step through Google however, the site does a 302 redirect to some IP-Address and then returns to the original site. The average browser won’t see that, but if you’re quick you might spot it in the status-bar. A search engine crawler or any user who knew the address would get there without a redirect and not notice a thing.

Strange.

That’s something that deserves to be looked at more closely. What’s on that server? How could I be able to see it?

I had seen something similar a few months back which redirected me to an affiliate site the first time I went to that site through a Google referrer (in my case, the gmail.google.com referrer was enough). It would only trigger once per IP-Address. This looks like a similar hack.

When I was able to download the files, I had a nice collection of:

• an encrypted javascript file that downloaded exploits based on browser and operating system
• an exploit from free-spy-cam.net
• an affiliate sales page for an antivirus software. Oh the irony. “We just infected you, buy our antivirus to get clean.” That is, if that software isn’t infected with something else.
• an affiliate signup link on that page

A search engine crawler will never see these things. A user, coming in from Google, will get redirected and if the IP address is not known, it will trigger a few exploits based on the system the user has and then display an affiliate ad page. The next time the user comes, the redirect will happen but the normal page will be shown.

Spotting the hack on your site

It would be good to know how you could spot a hack like this on your site. In general, you wouldn’t be able to. You can check for this particular hack, but it might not trigger every time … not to mention that there are likely way too many hacks that you would need to check for.

A simple way to check for it would be to use wget to access the page, and check for strange redirects, eg:

>wget –user-agent Firefox –save-headers –referer “http://www.google.com/search?q=duuude” “http://www.jwentworth.com/”

However, as mentioned, that might not work every time.

The technical details

(skip this part, if you are lost already )

The original spotting of the anomaly was using LiveHTTPHeaders with Firefox, while doing the steps: search, click on the top result. You see the following:

GET / HTTP/1.1
Host: www.jwentworth.com
(…)
Referer: http://www.google.com/search?q=Jonathan+Wentworth+associates

HTTP/1.x 302 Found
Date: Thu, 23 Aug 2007 06:38:04 GMT
Server: Apache/1.3.37 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/
1.2 mod_bwlimited/1.4 PHP/4.4.6 FrontPage/5.0.2.2635.SR1.2 mod_ssl/
2.8.28 OpenSSL/0.9.7a
Location: http://85.255.117.38/ind.htm?src=324&surl=www.jwentworth.com&sport=80…
(… added space to prevent linking …)

GET /ind.htm?src=324&surl=www.jwentworth.com&sport=80&suri=%2F HTTP/1.1
Host: 85.255.117.38
(…)
Referer: http://www.google.com/search?q=Jonathan+Wentworth+associates
HTTP/1.x 302 Found
Date: Thu, 23 Aug 2007 06:38:05 GMT
(…)
Location: http://www.jwentworth.com/

A strange redirect like that is a really bad sign. How can we check the URL that is given to see what they are sending? Apparently it can only be triggered once per IP-address and I had already used that chance earlier. In order to view the initial page, I had to find an IP address that was not yet registered with the remote server (at least that’s my explanation). I used a proxy server from one of the lists online. Using the proxy server and wget, I was able to access the page:

>set http_proxy=81.63.140.37:3128

>wget –user-agent “Firefox” –save-headers “http://85.255.117.38/ind.htm?src=324&surl=www.jwentworth.com&sport=80&suri=%2Findex%2Ehtml”

Connecting to 81.63.140.37:3128… connected.
Proxy request sent, awaiting response… 200 OK
Length: unspecified [text/html]
20:43:23 (79.20 KB/s) – `ind.htm@src=324&surl=www.jwentworth.com&sport=80&suri=%
2Findex.html.2′ saved [414]

The page that was returned was a normal frameset:

The second frame was kind of funny, “about:blank”? The first one was a bit more interesting though: http://85.255.117.38/site.htm?lng=1&trg=cln&oip=0&trk=zszuyhbinthnpzt
Notice the “trk” parameter.

Accessing that page with Opera within a VMware virtual machine running Windows 2000 (heh, paranoid is good), I was able to access that page. I saved it for analysis (and had Ethereal running on the side just to be sure). I tried to refresh and it returned 404. You could only view the page once.

Looking at the files you see some interesting things:

- an encrypted javascript file
- an exploit from free-spy-cam.net
- an affiliate sales page for the antivirus software
- an affiliate signup link on that page

The ZIP-File contains a full copy of the files as downloaded by the Opera browser. Check the files at your own risk, they contain the full exploit.

The encrypted javascript file looks like this (pulled apart and reformatted; called “__cntr000.htm” in the ZIP file):

The contents of the file are encrypted with some variation of Base64 encoding. You can decode the javascript by replacing:
eval(dd1+”.”+dd2)
with
document.write(”<xmp>” + r + “</xmp>”);

Doing that will display the full contents of the encrypted data (called “__cntr000-decoded.htm” in the ZIP file).

It is yet another javascript that triggers an exploit based on the operating system (it even test for XP service pack 2) and browser that the user is using. The exploit is also tagged with the “trk” parameter and couldn’t be downloaded separately. You can bet that’s it’s not a picture of your favorite celebrity, however.

Next steps

You could follow these up with:

• Checking the whois of the payload-server and notifying the hoster (in this case probable fruitless)
• Checking the sales page, search for the affiliate ID and the setups running and complain to the affiliate networks about this webmaster
• Mirror a copy of the original server for analysis
• Obviously move to a different server, perhaps even a different hoster

Summary

The hacker had managed to patch the server side code (most likely the Apache server) so that
- search engines see the normal page
- new users from search engines are hacked with several exploits and shown an ad for anti-virus software

Spotting something like this on your own sites is close to impossible. The search engine crawlers would not notice anything.

Recognizing something like this algorithmically on Google’s side would be possible with the Googlebar-data. Assuming all shown URLs are recorded, they could compare the URL clicked in the search results with the URL finally shown on the user’s browser (within the frames). At the same time, the setup could be used to detect almost any kind of cloaking.

Scary stuff.