IPS 4270-20 signature 1466/0 not working?

[MJonkers]

Hi, we installed the latest signature db on the appliance. When we test signature

1466/0 the signature does not fire.

The exploit is running on a test webserver.

Why does it not work?

Regards Marc

[nearchib]

Hi MJonkers,

Thank you for letting us know. Could you please provide a little more information about the conditions of your tests.

Did you test this using the Metasploit module? Or another exploit? Were you using IE to test.

If you using Metasploit can you show us the parameters that you used? This would make it easier to debug and answer your question.

Thanks

Neil Archibald

IPS Signature Team

[MJonkers]

Hi Neil,

I'm responsible for the IPS, I cannot find a entry in the metasploit database with which I can test. So we did not use metasploit.

Our security department tested it on a external test webserver with the html code in the zip file I enclosed, a windows xp machine in our network was the test station (traffic passes through IPS). They say it's the exploit mentioned. I have no idea if it is the exploit. But when the signature not fires I think it's not the correct exploit but I am not sure. So if you could please verify with me.

Pls see enclosed file.

regards, Marc

File is encrypted because McAfee sees it as a trojan horse. Password is infected

[nearchib]

Hi,

I looked at the HTML you provided, this is just setting up the heap using heaplib.

I see at the top there is an IFRAME with the source:

Do you have a copy of this file too?

Thanks

Neil

[MJonkers]

Hi Neil,

Here's the other file, pw is infected.

Regards, Marc

[nearchib]

Hi Marc,

I just replayed this HTML through the IPS and the signature fired and caught it.

Was the second file definitly accessed through the IPS too?

Any chance they could make a packet capture of what the IPS is seeing?

I am not sure what could be causing it not to fire.

Thanks

Neil

[MJonkers]

Hi Neil, could it have to do with strict or asymmetric mode when scanning? The ips is configured in asymmetric mode.

Regards Marc

Sent from Cisco Technical Support iPhone App

[nearchib]

Hey Marc,

This shouldn't make a different, it seems to fire on both.

Do you know what port they sent this over?

- Neil

[MJonkers]

Hi Neil,

I will provide a iplog file from the ips. Working on it now.

Regards,

Marc

[MJonkers]

The iplog file ...

I see the string

/YMjf%E0%B0%88%E0%B0%8CKDogjsiIejengNEkoPDjfiJDIWUAzdfghjAAuUFGGBSIPPPUDFJKSOQJGH

on row no. 44

Regards

[nearchib]

Hey Marc,

This is really interesting.

The reason the sig is not firing, is because the content of the webserver serving the exploit is compressed with gzip.

We can see this with the header:

Accept-Encoding: gzip, deflate.

It is interesting that you can see the string: YMjf%E0%B0%88%E0%B0%8CKDogjsiIejengNEkoPDjfiJDIWUAzdfghjAAuUFGGBSIPPPUDFJKSOQJGH being requested frm the webserver though, since they set the arrr[0].src to it.

I don't think blocking this request will prevent the exploit working, although i can test.

However we could modify our signature to include uri encoding of the unicode characters so we would at least see the exploitation attempt request in the gzipped content cases.

Thankyou for looking into this.

I will let you know how my testing goes.

Regards

Neil

[MJonkers]

Hi Neil,

Did the tests give any result?

Regards,

Marc

[nearchib]

Hey Marc,

I added a subsig to 1466-0 (1466-1) which covers the outbound uri request in cases where gzip compression is added.

This should be shipped in the next sig release.

Hope this helps.

Regards

Neil Archibald