Internet Explorer ‘feature’ causing drive-by malware attacks

[MrBrian]

Internet Explorer ‘feature’ causing drive-by malware attacks (http://blogs.zdnet.com/security/?p=1361)

{QUOTE-> The attack, discovered at a compromised legitimate site, is using a modified GIF file to exploit the cross-site scripting feature/vulnerability.

Schouwenberg said he reported the vulnerability to Microsoft a long time ago, warning the company that JavaScript embedded into GIF files can be executed under certain circumstances. Microsoft disagreed and the issue was never patched. <-QUOTE}

[huangker]

Would turning scripting off in IE have prevented this?

[aigle]

Any POC? Any live exploit site of it? Pls PM e.

Thanks

[Rmus]

Just sent.

The site was reported on another forum on Wednesday. The .gif file still displays:

200993
____________________________________________

Here is the code of the .gif file with the i-frame at the bottom:

200994
_________________________________________________________________

There was no execution of the .gif file when I tried the link Wednesday.
The URL in the code was shut down when I tried it:

200995

Yesterday this exploit was also analyzed here - same .gif file and code:

IE feature exploited ITW
http://www.viruslist.com/en/weblog?weblogid=208187540

I posted a comment asking what the "certain circumstances" were which would exploit the .gif file.
I'm hoping to get an answer.

Note this in the blog:

{QUOTE-> Clicking "view source" doesn't reveal any malicious code – and this makes a quick analysis of the threat more difficult. <-QUOTE}If the i-frame were in the HTML code itself, it would be easily flagged. By hiding it inside another file, that file itself would have to be scanned, as it already has been. Here is one analysis:

http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=HTML%5FIFRAME%2EAZ&VSect=T

Goldwindos2000.com is not exactly a family organization:

goldwindos2000.com
http://www.siteadvisor.com/sites/goldwindos2000.com/summary/


----
rich

[aigle]

Hi Rmus, thanks for the links and details. Unfortunately the exploit is not working as ususall.

Nice screenshots and explanation by you as always. :thumb:

[Rmus]

Hello aigle,

You are welcome, and yes, too bad that we can't see how this works. Microsoft evidently isn't concerned about this "feature" and the person who discovered this is vague in his blog about it needing "certain circumstances" to work.

Anyway, it uses a double trigger: the .gif file triggers an iframe which triggers the connection to the malicious site to download the payload.

When I saw the file hker.htm I thought I recognized the name, but not until looking more closely at the McAfee SiteAdvisor page did I see this other file stored at windos2000.com:

test.chm

Both of these files were used in the BellSouth.com exploit which I looked at early last year, where BellSouth users were hit by the attack when viewing their Support page. There were actually five different exploits bundled together attempting to find a vulnerability in the user's computer.

It's possible that this is a repackaging of an old exploit in a new bottle - a .gif file. At that time the executable payload was identifed as Trojan-Downloader.Win32.Small.

We'll have to watch to see if this particular .gif exploit surfaces in other places.

There are still a couple of live links for this hker.htm file if you want to look at it, but it requires IE unpatched to make it work, since it exploits MS06-014 (MDAC function) vulnerability to download the executable.


----
rich

[aigle]

{QUOTE->
There are still a couple of live links for this hker.htm file if you want to look at it, but it requires IE unpatched to make it work, since it exploits MS06-014 (MDAC function) vulnerability to download the executable.
<-QUOTE}
Pls PM ,e and i will try.

By the way, what if i change the URL in the gif file to a working legit download link and open it via IE? I did this and nothing happened. Seems a stupid guess by me.

[Rmus]

It 's not a stupid guess - we just don't know how this "feature" is supposed to work. I change the URLS often in exploits when the existing one has been taken down - just to watch the code at work. Here, until we know more, we are left wondering...

I sent you a working URL for the hker.htm file - it's useful exercise for a couple of things.

First, to see the difference between a direct download, and a remotely executed download, of an executable.

Here is the pertinent part of the code of the hker.htm file - it uses the MS06-014 (MDAC function) vulnerability:

--> gives the URL for the download of the executable, here, masquerading as an .html file (test.htm) to avoid flagging by extension
--> sets the attribute for MDAC
--> sets the path to the /temp folder and assigns a filename (svchost.exe)
--> copies the .htm file to /temp and opens as svchost

201018
_____________________________________________________________


If I take the URL from the code and attempt to download directly, IE dutifully displays the Download Prompt:

201019
______________________________________________________________


However, if I go to the link for the hker.htm file, I can simulate what could happen if this .gif "feature" did work
as described in the article MrBrian linked to.

The exploit bypasses any call for the Download Prompt. Svchost cannot execute because the executable
file has been prevented from downloading:

201020
________________________________________________________________


So, the second point is that even though the "trigger" of the exploit (the .gif file in this case) may not be blocked,
if the payload is a malicious executable, other protection in place will prevent the exploit from completing its task.

If aigle can get this to run, we'll see how Geswall stops it.


If the hker.htm file tested is the same used in this exploit, then we can say that in its present form,
it depends on two vulnerabilities, both requiring IE:

1) the .gif "feature"

2) MS06-014 unpatched

For example, trying to use the hker.htm link in Opera fails, because the MDAC vulnerability is specific to IE


----
rich

[aigle]

Hi Rumus, thanks for the links. It worked with IE 6 but not IE7. Interesting.

Here are the alerts by CFP. I allowed everything except the last action. Sorry as I have no time to write down the nice details like you. Have to take some sleep brfore duty. Alerts are self explanatory.

Good to see again CFP flagging malicious files by heuristics( see second alert pop up and the last alert). :thumb: :thumb: :thumb: It seems to have good heuristics as I see flagging it many malicious files.

201041
201042
201043

[aigle]

Here are the same alserts by EQS but I denied creation of file index.htm in system 32 folder, the last pop up.

201044
201045

[aigle]

Here is GesWall,s log and Attack Notification. It stops the malware from creating file in system 32 folder and malicious process dies at this step.

Excellent silent protection against driveby attacks. No popups and works out of the box. :thumb: :thumb: I have just added a global rule in it to stop network access of all isolated applications and then allowed individual applications like browsers, messengers etc as needed.
201038
201039
201040

[aigle]

Lastly I tried ThreatFire. It detected the attempt of execution of svchost.exe by IE in an unusuall manner. :thumb:

Will post the screenshot later. I lost it. >:(

Here is the screenshot. Kill and quarantine actually just terminates IE and stops execution of malicious svchost.exe.

[aigle]

Good old Neoava Guard. :thumb: I really miss it. >:(

201047
201048

[aigle]

OA free

[aigle]

SafeSpace isolated all files in virtual HD and files were deleted on purging the SafeSpace. But as the malware was allowed to execute fully via virtualization it did try for outbound internet access unlike GW where the malware died before it could ask for outbound network access.

SBIE works same as SafeSpace.

I think it,s time for SafeSpace people to add some sort of outbound network access control for isolated application( allowing only for needed applications via default or custom made rules).

201052
201054

[Rmus]

Hi aigle,

Thanks for all of your work to run these tests!

{QUOTE-> It worked with IE 6 but not IE7. Interesting. <-QUOTE}I assume this is because IE7 has incorporated all previous patches for exploits, including this one - MS06-014

It's evident from your tests how many different solutions there are to prevent malicious executables from being remotely executed from the internet -- or other media, such as USB drives.

To this list I can add:

SRP (tested by SpikeyB) - he said that he received the usual message that svchost.exe
was blocked by SRP, please contact system administrator.

I'm sure there are more solutions.

It's interesting to see how the various products handle the steps of the exploit. Svchost, of course is not the Windows svchost, but the original malicious file test.htm renamed and copied to the /temp directory. Here again are the steps in the code of the exploit:

--> gives the URL for the download of the executable, test.htm
--> sets the attribute for MDAC
--> sets the path to the /temp folder and assigns a filename (svchost.exe)
--> copies the .htm file to /temp and opens as svchost.exe

I noticed that Comodo (post #9) and OA (post #14) both of which have firewalls, picked up the attempt by svchost to connect out to the internet.

These tests are a great comparison of the differences in the approach to handling malware. Users today have many solutions available. I've sent this link to a couple of people to test with AV. However, since the link is more than 1 year old, it certainly should be flagged by most AV.

If the .gif "feature" reported in the article posted by MrBrian were to execute its code, this scenario is one possibility as to what could happen to a user redirected to a malicious site to download malware by remote code execution.

Thanks again for taking the time to do this. I'll contact you by PM to see about using your screenshots in another writeup I'm doing.


----
rich

[aigle]

Thanks Rmus!

Can you tel me how you opened the code in notepad?

Thanks

[aigle]

I tried HauteSecure (http://hautesecure.com/). It seems an interesting hybrid sandbox for ordinary users. Seems good against driveby attacks. :thumb: See the screenshots.

201065
201066
201067

[aigle]

I am curious to know how PRSC will act against this driveby attack?

Anyone please? Thanks

[Rmus]

{QUOTE-> Thanks Rmus!

Can you tel me how you opened the code in notepad?

Thanks <-QUOTE}You are welcome.

Yes - the hker.htm file should be in the cache (Temporary Internet Files). I r-click on the file and open in a text editor.


----
rich

[aigle]

Hmmm... That was simple. I thought some way you got the code from web page. :)

Thanks

[aigle]

BTW OA run safer option also stops it. Malicious svchost.exe executes but dies shortly. It fails to create any file in system32 folder and no outbount network access attempt as well.

[Rmus]

{QUOTE-> Hmmm... That was simple. I thought some way you got the code from web page. :)

Thanks <-QUOTE}Actually, it is the web page but opening in IE triggers the exploit.

Opening the link in Opera -- nothing happens and you can view the page source.


----
rich

[Rmus]

{QUOTE-> I am curious to know how PRSC will act against this driveby attack?

Anyone please? Thanks <-QUOTE}What is PRSC?

I mentioned above that I sent this link to SpikeyB to test with Software Restriction Policies,
and was curious as to what the alert messages look like, so he sent me some screen shots.
Later I thought maybe others who don't use SRP might like to see.

You will notice that SRP works on the Default-Deny Principle - there is no prompt to Allow-Block:


201068
________________________________________________

201069
________________________________________________

[aigle]

Thanks for screenshots. PRSC is Primary Response Safe Connect (http://www.sanasecurity.com/)/ Norton Antibot (http://www.symantec.com/norton/antibot).