Dangerous trojans on the loose

In both cases you reported receiving different results from Google than others. While there is undoubtedly a cracked server involved in malware distribution, anyone receiving out-of-the-ordinary Google links should check for malware rewriting pages to include redirects to malicious sites. Such a technique can also be used to better disguise phishing sites.

 

Several who tested this SloanTreeFarm referer|redirect exploit noted that you could not access the malware site
twice in succession -- you had to disconnect|reconnect to the internet.

In Finjan's latest quarterly report,

http://www.finjan.com/Pressrelease.aspx?id=1527&PressLan=1230&lan=3

first posted here by InfinityAz

https://www.wilderssecurity.com/showpost.php?p=1019067&postcount=1

is a discussion of a type of "evasive technique" which may have been used in this case:

The benign page in this case is the SloanTreeFarm site - the URL appended to the spoofed URL.

I noticed that each time I ran the exploit, a different set of characters was appended to the cached URLs following the =

The last file in the list is the URL which downloads of the spoofed *.gif executable file:


_____________________________________________________________


_____________________________________________________________


Normally after testing and seeing how the executable can be blocked from downloading,
I can use this cached URL to download the file directly so as to scan, etc.

In this case, trying to run this URL again returns an error page that the file cannot be located.

Finjan's report has nice graphics illustrating the stages of this type of evasive technique.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

I just did a Google search for awfulplasticsurgery.com, clicked the link, and was directed to the antivirus page at 85.255.115.221. I run Firefox 2.0.0.4 with NoScript, so no JavaScript was executed, no re-directs, so nothing happened.

The URL that Google linked to is:
hxxp://85.255.115.221/ind.htm?src=284&surl=awfulplasticsurgery.com&sport=80&suri=%2Findex%2Ehtml

A Google search on the IP address (85.255.115.211) brought me to this thread. Just throwing this information out there because it is still happening. Anyone figured out for sure what is going on?

 

Google's first link for me was www.awfulplasticsurgery.com itself - I'd suggest you check your system for malware modifying your search results. Castlecops' Malware Removal and Prevention Guide provides useful information on how to go about this.

 

Confirmed. Blocked by my firewall before their web server redirected. Using IE6SP2 with javascript enabled. On the surface seems to be the same sort of redirect as the Sloan's site:

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/msword, */*
Referer: hxxp://www.google.com/search?hl=en&q=awfulplasticsurgery.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 14 Jun 2007 22:37:40 GMT
If-None-Match: "1b0aa3-118a2-4671c334"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: xxx.awfulplasticsurgery.com
Connection: keep-alive

+++RESP 136+++
HTTP/1.1 302 Found
Date: Fri, 15 Jun 2007 05:08:45 GMT
Server: Apache/1.3.36 (Unix) PHP/4.4.2
Location: hxxp://85.255.115.221/ind.htm?src=284&surl=awfulplasticsurgery.com&sport=80&suri=%2F
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
+++CLOSE 136+++

+++GET 137+++
GET /ind.htm?src=284&surl=awfulplasticsurgery.com&sport=80&suri=%2F HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/msword, */*
Referer: http://xxx.google.com/search?hl=en&q=awfulplasticsurgery.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 14 Jun 2007 22:37:40 GMT
If-None-Match: "1b0aa3-118a2-4671c334"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 85.255.115.221
Connection: keep-alive

Unusually, when I tried the first Google search results link without a firewall running I was sent to xxx.awfulplasticsurgery.com (appeared to be the normal web site). When I tried it again, but this time with the firewall running (85.255.115.221 was added to Blocked Zone) the firewall blocked it.
Like the Sloan's redirect if you are running IE, if you do a full refresh (Ctrl-Refresh) a few times it will help you get to where you don't want to go. (I changed http to hxxp and www to xxx in this post to prevent problems with others clicking on the links.) Good find!

 

Here are my results for comparison (taken from Proxomitron's log, with filter/blocklist match comments removed):

Noway's results show that he has something on his system redirecting Google queries to 85.255.115.221 - a Hosts file entry for Google.com would be the simplest method but there are other ways of redirecting HTTP traffic also (BHOs for IE only, LSP filters, DNS nameserver entries to point to a hijacked server, etc). A ping to Google.com should provide a better indication of which method is being used.

 

Also confirmed, IE6 on Win2K.

AE blocked the attempted download of the spoofed .gif file as it did in the SloanTreeFArm exploit.

I noticed the cached HTML files are using a different obfuscation than what we observed in
the SloanTreeFarm exploit.

I notified the Webmaster.

Whether a site is compromised to host|download an exploit, or redirect to a malicious web site,
or even just the juvenile defacing of a web site - by being vigilant and notifying the victims
we can help a little bit to thwart the success of these perpetrators.

-rich

 

No it doesn't. If you look closer at:

+++RESP 136+++
HTTP/1.1 302 Found
Date: Fri, 15 Jun 2007 05:08:45 GMT
Server: Apache/1.3.36 (Unix) PHP/4.4.2
Location: hxxp://85.255.115.221/ind.htm?src=284&surl=awfulplasticsurgery.com&sport=80&suri=%2F
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
+++CLOSE 136+++

...you will notice that the Location header that initiates the redirect is from the REMOTE WEB SERVER and HAS NOTHING TO DO WITH MY COMPUTER. The computer that this has something to do with is shown by the Server header:

Server: Apache/1.3.36 (Unix) PHP/4.4.2

Also, I wouldn't have expected you to be able to duplicate my (IE + Proxomitron BYPASSED) results with your (Opera + Proxomitron FILTERING) method. It is also possible that the range of IPs that YOU use are not coded into the exploit making you invulnerable at this time.

 

If that response was the first header you received when trying a Google search, then there it is most certainly something on your system, since it would not otherwise be connecting to a non-Google server when accessing google.com (with the possible exception of DNS cache poisoning of your ISP DNS servers). It is simply not possible for one server to modify unlinked webpage content from another (which you seem to be suggesting) without something on your system being involved.

If that 302 response wasn't the first HTTP header, then that opens up the possibilities a lot more - in which case, seeing the prior ones would be helpful in diagnosing what is going on.

Filtering shouldn't make any difference when it comes to reviewing links on Google search page (in this case, it keeps the log short by blocking image downloads also). As for it being IP-specific, this can only apply with servers that the attacker controls which would mean either that they have cracked Google's security or yours. Now which seems the more likely?

 

No it wasn't. The GET in my post (and the response) are from clicking on the first link in the Google results page. The link appeared normal and showed the correct xxx.awfulplasticsurgery.com url when hovered over it.

With the Sloan's server problem, redirection was dependent on the browser's outgoing referrer header, which is checked by the compromised server. Mine is shown in the GET as well...the server at Sloan's would be looking for certain referrers only. The Sloan's redirection happened exactly the same using MSN Search but didn't for some other search engines I tried. And typing in the correct address into the address bar (www.whatever.com) wouldn't trigger it because the browser does not send a referrer when the link is accessed from the address bar.

On http://search.msn.com/results.aspx?q=awfulplasticsurgery.com&FORM=MSNH the first link leads to the same url and the awfulplasticsurgery.com server behaves the same.

On an obscure search engine below, the first link leads to the same url but there is not a redirect done by the awfulplasticsurgery.com server:
http://www.icerocket.com/search?tab=web&q=awfulplasticsurgery.com

I guess the compromise must involve a list of referrers it checks before doing the redirect. There could be other things it checks too, based on the headers it sees from the browser, etc. It could be made infinitely complex if it considered all browser headers and varied them with time/day of week, IP address and so on. For example it could be set to redirect only IE6 users running Windows XP only, between the hours of 6 p.m. and 10 p.m. on Tuesdays and Thursdays only, coming from an IP range of 24.10.22.0-24.10.255.255, where that particular IP address has never been there before, and who have just come from Google or MSN but not from Icerocket search engines. We won't discover the exact mechanism here without the assistance of the owner of the compromised server itself and having him submit what he finds to anti-malware companies.

 

My machine has does not contain malware, and never has. I'll do some double checking, but I doubt the problem is on my end.

I use a custom hosts file for ad blocking, and there is nothing fishy in it. The bogus URL redirected me one time, and I haven't been able to duplicate it, but I haven't tried more than a handful of times. Subsequent Google searches correctly direct me to awfulplasticsurgery.com. I think other's successful duplication of the redirect shows that this is a similar problem to the Sloan Tree Farm exploit.

 

Paranoid2000, I use Opera exclusively with the same setup as you and I get the same log entries. Switch to IE with default settings, without Proxomitron and you'll see the results. These redirects are designed to exploit IE.

 

It seems like you have to log off - log back on so as to use a different IP address. See my post #377 above.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

That may be true here. In the Sloan exploit I could get the redirect to occur in Opera (see my post #365 above). However, I've not been successful this time with Opera - only using IE do I get a redirect.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

A fake (or modified) Google results page can quite easily appear legitimate (and include an appropriate tooltip via Javascript). Knowing what happened when you actually did the Google search is what is important.

Again though, this would happen if you had malware present (via hosts, BHO, etc) that only targeted requests to Google or other major search engines.

Your log above shows no such redirect by this server (which is at 216.17.106.60) - instead you are connecting to a totally different server at 85.255.115.221. Either Google's search results have been compromised (in which case, I would expect to see similarly suspicious results myself - I have tried accessing Google without a proxy and also by "faking" IE's user agent with no effect) or you have something on your system. I have already suggested methods of checking this above so see no need to elaborate further.

Hmmm - it is very difficult to make such a claim unless you are actually running software like Process Guard or SSM that requires you to approve every program and you are zealous in checking anything before permitting it. If you meant "My antivirus has never found anything" then that is no guarantee at all - malware that just makes the occasional modification to search results pages can remain very well hidden since it doesn't need to make any type of network connection.

An IE exploit undoubtedly - but I have tried again (as noted above) with the IE user agent set (via a Proxomitron header filter - I don't use IE, ever), with Proxomitron's web filtering and remote proxy disabled and not seen any difference. Here are my logs from this just to confirm (only blocklist matches removed this time):

 

Sorry but you are completely wrong again and I'm not sure you are familiar with the HTTP transaction. My browser's initial request for the page DOES go to 216.17.106.60. I could attach my firewall log to show you but I really don't have the time or the inclination.

 

Here is the sequence as I observed it:

First, a Server query:


__________________________________________________________

Firewall logging

First Connecting to Google,
then after clicking on "Awful" - a connection to that site
followed immediately by redirect to inhoster.com


__________________________________________________________

Later, screen shots showing the sequence:


__________________________________________________________


__________________________________________________________

 

Noway,

The portion of the log you have posted doesn't show that traffic, so if you actually have anything that provides more detail than what you have shown so far, by all means post it.

Rmus,

Thanks for taking the time to post screenshots, but they don't really give any better indication of the root cause. An extract of the HTML code for the link your browser sees from Google (along the lines of what I posted in #372 above) may help more, but even then it could not confirm whether it was the actual HTML Google served or something modified locally (and Google don't offer an https option).

Using an anonymising proxy that encrypts your connection (Tor or JAP) should foil any hosts file redirection, but even that may not affect LSP-based malware which could modify unencrypted content between the browser and the anonymising proxy client. An HTTPS proxy (where content is encrypted within the browser itself) like Proxify HTTPS would likely be the only way to work around such a situation and even that may be compromisable with IE or IE-based browsers.

 

Then you're never going to see it.

 

I was using Firefox 2.0.0.4 when I was redirected to the antivirus page at 85.255.115.211. The only time I use IE is for Windows updates. So the redirect works if you aren't using IE (at least in my case), but I'm guessing you may not get infected.

 

Do you have NoScript installed?

 

Yes. Nothing happened when I was redirected to the site.

 

http://www.symantec.com/enterprise/...log/2007/05/mpack_packed_full_of_badness.html

http://www.symantec.com/enterprise/...og/2007/06/italy_under_attack_mpack_gang.html


Recently saw this info from Symantec re Mpack. Sort of related to this thread I guess. Couldn't make out the IP Address in the first pic of the second link...otherwise would have added it to firewall blocked zone.

Update: A new dedicated thread has been started here in the meantime re Mpack https://www.wilderssecurity.com/showthread.php?t=177912

 

noway

I see what you mean. When i go to those two links with Firefox & script enabled i get a pop up box saying script is trying to run stop or continue? If disabling script I get no pop up. I was thinking it had to do with comodo's verification engine though.

controler

 

Here is a better screenie.

If I go to the site listed, my firewall warns of an updater trying to work. This happens with javascript turned off in Firefox. Not using NoScript at the moment.