I have an IPS from a major vendor, and the following exploit was not blocked or noticed. I contacted the vendor, and they could not identify the exploit in order to recommend which signature to block on.

The following was in my Apache access_log:
SEARCH /\x90\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9

\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9 \xc9\xc9\xc9\xc9\xc9\xc9\x

c9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\x c9\xc9\xc9\xc9\xc9\xc9\xc9

\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9 \xc9\xc9\xc9\xc9\xc9\xc9\x

c9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\x c9\xc9\xc9\xc9\xc9\xc9\xc9

\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9 \xc9\xc9\xc9\xc9\xc9\xc9\x

c9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\x c9\xc9\xc9\xc9\xc9\xc9\xc9

\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9 \xc9\xc9\xc9\xc9\xc9\xc9\x

c9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\x c9\xc9\xc9\xc9\xc9\xc9\xc9

It's only a small part of the whole exploit. Does anyone know which exploit or vulnerability it is?

Thanks

i think it's some windoze exploit. are you running apache? i don't think it's dangerous except for the b.s. it's adding to your logs. if it were me, i would block the IP at the firewall, and then keep an eye out for it coming back. maybe even report the IP to their ISP, for whatever good it does, if it's even in the US.

Without seeing the entire exploit, it looks like the WebDAV exploit in Microsoft IIS. AFAIK, Apache doesn't even support the SEARCH method.

Very good/extensive reading on it:
http://www.sans.org/resources/malwar...av-exploit.php

thanks for the info. I'll read that sans link. I keep my linux servers fully patched, it's just that I'm paying for an IPS box which is supposed to stop exploits like this (at least they claim to)

I would be concerned if it's not stopping that. Unless they've specifically configued it to filter only *Nix exploits/vulns (which is still questionable from a security standpoint) then there is something wrong or it's a PoS (no offense). Either way you should be getting your moneys worth.

There is a problem identifying it because apache cuts of the payload padding because "URI" to long, so I can never see the exact exploit code. However, the next post command is the following

205.238.242.191 - - [21/May/2006:16:30:41 -0500] "POST /_vti_bin/_vti_aut/fp30reg.dll HTTP/1.1" 403 311 "-" "-"

this makes me think it's a older front page exploit CVE-2001-0341.

A tech support person called me today, I was surprised. However, they were still in the dark about this one.

I have enabled Etheral on the webserver and filter on the offending ip range! This person comes back very frequently with this exploit, I'm sure I can capture all the packets.

I hope this IPS is not a POS!

1. The "\xc9\"s are the exploits being run against the web server...that's what matters. The URI isn't so important.

2. This is indeed a WebDAV buffer overflow exploit, as Capt Caveman stated, and a rather old exploit at that. I see many of these daily at work (I'm a security engineer/analyst) and it is usually paired with the Frontpage exploit also. As long as you aren't running IIS (and if so, it should be patched since the exploits are so old), you're safe.

3. The IPS platform, what is it? The IPS is most likely not a POS. All IPSs and IDSs require customization and up-to-date signature sets. Since these are older exploits (I'm talking like 3+ yrs old), the signatures should be on the IPS, unless someone disabled them, which is entirely possible. I'd definitely check to see when the last signature update occurred and what signatures are enabled and disabled. If you aren't running any MS-based software, these two signatures don't need to be enabled, as you don't normally want to see attacks that won't affect your network, only the ones that have the potential to.

the ips is uptodate, the vendor reviewed the system logs. I'm not running any Windows boxes but I do want to get value for my money.

I don't want to flame the vendor yet because they have been responsive and concerned. But I am VERY surprised that the box did not catch an old exploit like this.

Once I capture the packets with Etheral the vendor can confirm if the sig is there or not (I hope )

n/t.............

I can understand wanting to get the best bang for your money, BUT having an IDS/IPS alert on malicious activity that will have no affect whatsoever on your network isn't going to provide that bang for the buck and may very well put your device under an undue load.

If anything, just check to see if the IPS is performing as advertised. When I ask if the IPS is up-to-date, I don't mean a flash-rom update or update of the application. I mean, be sure that the attack signature set is at its latest version. If it is, also be aware that the device may be tuned to your specific environment. You mentioned that you aren't running any Windows boxes on your network. The first thing a security engineer is going to do when tuning any IPS/IDS is get rid of any signatures that aren't specific to his network. Did an engineer (from the vendor or your company) tune this device?

Lastly, I've got a payload capture (from Snort) of WebDAV and Frontpage. It is here.

thanks for the payload capture.

I installed the device myself, and all the signatures are uptodate. You are probably right, why put a load on the box for outdated exploits.

If it's a true IPS that's sitting inline, then allowing remote systems to inject 65kb+ malicious packets into your LAN isn't any less of a performace hit than dropping it at the gateway and putting an entry in the database. Apache is going to have to deal with it if the IPS doesn't...

If you don't want to deal with added noise, only enable necessary MS alerts or just use a BPF rule.

I was pointing more toward ALL MS-related sigs or most of them. I can see turning on a few just so discern what's hitting your network, but honestly, it doesn't make any sense to do that when you've server logs and/or ethereal/tcpdump to do the ocassional spot check of traffic you may not be recording.

Another reasoning is that if you turn on everything to try to catch everything, eventually you'll be running into drive space issues. Also, the more you attempt to record, the more load the IPS/IDS will be under. If you've ever run Snort with EVERYTHING turned on, then checked your memory usage, even without much traffic to sniff through the IDS will be eating a LOT of memory. And, if you're on a busy network, Snort will definitely load up the CPU considerably.

You just can't deploy an IDS without considering things such as this.

Your last point was a good point though, especially the BPF rule (although, with alot of traffic triggering the BPF rule has the potential to DoS your IPS/IDS).