09-18-2012 10:11 PM - edited 03-10-2019 05:46 AM
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
09-19-2012 08:07 AM
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
09-19-2012 09:51 AM
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
09-19-2012 11:01 AM
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
09-19-2012 11:17 PM
09-20-2012 07:12 AM
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
09-20-2012 07:53 AM
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
09-20-2012 12:40 PM
Hey Marc,
This shouldn't make a different, it seems to fire on both.
Do you know what port they sent this over?
- Neil
09-20-2012 01:16 PM
Hi Neil,
I will provide a iplog file from the ips. Working on it now.
Regards,
Marc
09-20-2012 01:28 PM
09-20-2012 02:14 PM
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
09-27-2012 10:00 AM
Hi Neil,
Did the tests give any result?
Regards,
Marc
09-28-2012 12:23 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: