2 edits | reply to mysec
Re: Browser Redirect to 7.7.7.0 - interesting The file in question seems to be dated well before it could possibly be. I just installed this system in the last month, and the file is dated April 2008.
I am getting hits with the OneCare online scanner, so I'll keep you posted on whether it will be able to remove it. Looks like Microsoft might be the most reliable source for identifying this thing for now.
-edit-
Ok, yeah, OneCare online did indeed detect and remove Trojan:Win32/Daonol.B (along with Chepdu.B and Zbot.BU, apparently Symantec is totally useless crap, I'm particularly annoyed about Zbot). So, if you're seeing evidence of the 7.7.7.0 exploit, I suggest doing an online scan at Windows Live: OneCare |
mysecPremium
join:2005-11-29
kudos:4 | said by falcomadol:The file in question seems to be dated well before it could possibly be. I just installed this system in the last month, and the file is dated April 2008.
Note this comment from a Google blog:
»www.google.com/support/forum/p/W···8d&hl=en
The infected files have an interesting characteristic: the Creation Date in explorer shows up as later than the Date Last Accessed and Date Modified ones. In my system, the Creation Date showed as 28/10/2006 while the others showed 4/8/2004!
This is certainly a puzzling exploit: none of the write ups shows a file which delivered the trojan. A Google blog makes reference to a PDF file but evidently none have been retrieved and sent to an AV vendor.
»www.google.com/support/forum/p/W···8d&hl=en
They seem to come in via infected Adobe pdf files read with older versions of adobe reader: mine was version 7 and it had the security hole. As part of my work, I have to read a lot of pdf files from all sorts of places relating to databases and Unix, hence how my system became infected.
Too bad he didn't find the file that triggered the exploit.
That no PDF file has been retrieved may be due in part to the fact that a user is not aware of the infection until using a search engine. By then, files which were in a temporary directory could have been deleted.
Exploits don't just happen in outer cyberspace. A file has to download/cache in order for code to execute. When you view a web page, your browser is reading it from the cache or temporary internet folder. Start with an empty cache, connect to DLSR and look at all of the files that download/cache for the page to display.
So, the drive-by exploit is triggered from a file that is cached. That is why disabling scripting in the browser will prevent those exploits from running which depend on a javascript file, for example.
You can test for yourself, if you like. I'll send the URL in IM.
With scripting disabled, go to
hxxp://proantiviruspcscan.com/xxxxx
Using Opera: the HTML page caches but just a blank screen displays because this code in the HTML page could not execute to load the window.js file which does all of the work:
script src='window.js'></script>
Using Opera: if I enable Javascript, reload the page, now things start happening:
_________________________________________________
(This is not a nasty one - you can cancel and then close the window)
Looking back on some exploits, we can see how a cached file is necessary.
WMF (Windows Media File) MS06-001
In an above post, I showed how the payload was blocked. This screenshot shows the WMF file actually downloading, followed by its appearance in the cache, at which point the trojan will download.
This code in the HTML page triggers the wmf file to download:
i frame src="wmf_exp.wmf" i frame
_________________________________________________________
ANI (Animated Cursor) MS07-017
The code in the HTML page caches the .ani file:
style>
* CURSOR: url("./exp_2/1.ani");}
style>
_________________________________________________________
at which point code in the .ani file attempts to download the trojan:
PDF exploit
I have not been able to test a PDF exploit, so here is an analysis of CVE-2008-0655 by ISC from last year, where a banner ad served up the PDF file. The user would have been unaware of this happening in the background, nor aware that the PDF file cached:
Adobe Reader exploit in the wild
»isc.sans.org/diary.html?storyid=3958
Since January 20, 2008 banner ads are actively serving malicious PDF files that exploit the vulnerability and install the Zonebac Trojan. A malicious PDF file (called 1.pdf in this example) served from IP address "85.17.221.2" downloads a malware specimen called Trojan, a variant of Zonebac...
Until 2 days ago, this attack did not have a patch available while being actively exploited in the wild...
No anti-virus vendors currently detect the malicious PDF files though we have provided samples to all. This type of exploit works for both web browser and email attack vectors. 
(image credit: PcPrimiPassi.it FORUM)
_______________________________________________________
I referenced a paper in an above post with details of various code exploits possible in a PDF file.
This current trojan file wdmaud.sys could have been delivered by any of the above exploits, or by one yet to be revealed!
We should start a contest to see who can be the first to discover the secret. Proof of a file required.
----
rich |
