Dangerous trojans on the loose

Discussion in 'malware problems & news' started by TNT, Jun 22, 2006.

Thread Status:
Not open for further replies.
  1. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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.
     
  2. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,994
    Location:
    California
    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:

    cacheOrder2.gif
    _____________________________________________________________

    gifURLproperties.gif
    _____________________________________________________________


    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​
     
    Last edited: Jun 5, 2007
  3. stangbat

    stangbat Registered Member

    Joined:
    Jun 14, 2007
    Posts:
    11
    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?
     
  4. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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.
     
  5. noway

    noway Registered Member

    Joined:
    Apr 24, 2005
    Posts:
    433
    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!
     
    Last edited: Jun 15, 2007
  6. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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.
     
  7. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,994
    Location:
    California
    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
     
  8. noway

    noway Registered Member

    Joined:
    Apr 24, 2005
    Posts:
    433
    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.
     
  9. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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?
     
  10. noway

    noway Registered Member

    Joined:
    Apr 24, 2005
    Posts:
    433
    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.
     
    Last edited: Jun 15, 2007
  11. stangbat

    stangbat Registered Member

    Joined:
    Jun 14, 2007
    Posts:
    11
    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.
     
  12. SirMalware

    SirMalware Registered Member

    Joined:
    Jun 6, 2006
    Posts:
    133
    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.
     
  13. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,994
    Location:
    California
    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​
     
  14. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,994
    Location:
    California
    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​
     
  15. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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):
     
  16. noway

    noway Registered Member

    Joined:
    Apr 24, 2005
    Posts:
    433
    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.
     
  17. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,994
    Location:
    California
    Here is the sequence as I observed it:

    First, a Server query:

    awful_query.gif
    __________________________________________________________

    Firewall logging

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

    awful.gif
    __________________________________________________________

    Later, screen shots showing the sequence:

    awful_1.gif
    __________________________________________________________

    awful_2.gif
    __________________________________________________________

    awful_3.gif
     
    Last edited: Jun 15, 2007
  18. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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.
     
  19. SirMalware

    SirMalware Registered Member

    Joined:
    Jun 6, 2006
    Posts:
    133
    Then you're never going to see it.
     
  20. stangbat

    stangbat Registered Member

    Joined:
    Jun 14, 2007
    Posts:
    11
    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.
     
  21. SirMalware

    SirMalware Registered Member

    Joined:
    Jun 6, 2006
    Posts:
    133
    Do you have NoScript installed?
     
  22. stangbat

    stangbat Registered Member

    Joined:
    Jun 14, 2007
    Posts:
    11
    Yes. Nothing happened when I was redirected to the site.
     
  23. noway

    noway Registered Member

    Joined:
    Apr 24, 2005
    Posts:
    433
    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
     
    Last edited: Jun 19, 2007
  24. controler

    controler Guest

    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
     
  25. controler

    controler Guest

    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.
     

    Attached Files:

Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.