CERT CA-2003-09 / MS03-007

[mcerha]

The recent IIS 5.0 WebDAV vulnerability can be successfully detected with signature 5322. This signature is disabled by default. We recommend that the signature parameter MinMatchLength be tuned to a value of 50000. This will significantly reduce the chance of false alarms occuring. We are currently researching possibilities for a more comprehensive signature. Users may also want to filter OUT -> IN on their DMZ web server networks to futher reduce false positive alarms.

[pheuch]

I'm sorry but I think this is not working.

1. WebDAV is not using GET requests, if I understood RFC 2518 correct. It is using its own methods: COPY, PROPFIND, DELETE, PROPPATCH, MOVE, LOCK and UNLOCK

2. It seems to me that the IDS engine is not able work with buffers larger 16000 bytes. To proove this I changed the MinMatchLength of 5322 to 2000. Thank I sent overlong GET requests with following commands:

perl -e 'print "GET " . "A"x15000 . " HTTP/1.1\nHost: www.ibmde.com\n\n"' | nc -v hostname

perl -e 'print "GET " . "A"x16000 . " HTTP/1.1\nHost: www.ibmde.com\n\n"' | nc -v hostname

The first command did create an event , the second not. I was not able to get the exact buffer limit , because the range about 15720 not every GET request was recognized.

---

A custom signature has the same problem. I setup a custom signature with following regex:

[CFLAMcflam][OIEToiet][PNTCVpntcv][YDEHKydehk] [^ ]+ HTTP

with MinMatchLength set to 1000 ([CFLAM]... are the last 4 characters of the WebADV methods). This signature is also not able to detect large requests.

Tested on 3.1(3)S39

Peter

[pheuch]

I got the info that it is a GET request, but it should not be an overlong URL.

Regards Peter

[mcerha]

From the traffic sample and exploit that we have for this vulnerability, the attack does send a GET request with 65K of data in the URI. What exactly this attack has to do with WebDAV specifically I 'm not sure.

Also, we should be able to theoretically handle matching the length of patterns in excess of 4 billion characters. So, from your examples, I did this and the alarm fired for me:

perl -e 'print "GET /" . "A" x 75000 . " HTTP/1.1\nHost: http://www.cisco.com\n\n"' | nc foghat 80

[ktimm]

Didn't work for me. I verified the network traffic using snoop. All the IDS reported was a connection request

[mcerha]

Did you enable the signature?

[ktimm]

Yes I did. I found the problem I wasn't using GET as the request. I was a nasl test that uses SEARCH. If this is exploitable by using other methods than there is a false negative condition

[mcerha]

Agreed. There is a chance of a false negative for this. The example of the traffic we have access to uses a GET method. Currently, signature 5322 is implemented in the STRING.TCP engine for performance reasons with a hard coded GET method. I will look into seeing if this can be moved into the STATE.HTTP engine, or we might add additional sub-signatures for other methods in the STRING.TCP engine.

[pheuch]

I found the source of my problem with this signature. The webserver I used for the test is sending its return message after a few thousand bytes are received. Than it drops the connection.

I guess your signature is looking for something like "GET +[^ ] +HTTP" ? So the HTTP was never received and the signature could not fire.

Sorry for the confusion.

Regards Peter

[ktimm]

Is there currently a way to do this with SigWiz or SigOfStringMatch ? I tried using .{10000,} regex but it failed to detect. Likewise with creating a signature with STRING.TCP and just adding a method as the regex and minmatchlength. These both failed to detect. Am I missing something ?

[mcerha]

Below is a custom signature for this vulnerability.

Tune Signature Parameters : CSIDS Signature Wizard

_______________________________________________________________________

Current Signature: Engine STATE.HTTP SIGID 20003

SigName: IIS WebDAV Overflow

_______________________________________________________________________

0 - Edit ALL Parameters

1 - AlarmInterval =

2 - AlarmThrottle = FireOnce

3 - ArgNameRegex =

4 - ArgValueRegex =

5 - ChokeThreshold =

6 - DeObfuscate = True

7 - Direction = ToService

8 - FlipAddr =

9 - HeaderRegex = [Tt][Rr][Aa][Nn][Ss][Ll][Aa][Tt][Ee][:][ \t][Ff]

10 - LimitSummary =

11 - MaxArgFieldLength =

12 - MaxHeaderFieldLength =

13 - MaxInspectLength =

14 - MaxRequestFieldLength =

15 - MaxUriFieldLength = 65000

16 - MinHits = 1

17 - RequestRegex =

18 - ResetAfterIdle = 15

19 - SigComment =

20 - SigName = IIS WebDAV Overflow

21 - SigStringInfo =

22 - ThrottleInterval = 15

23 - UriRegex =

24 - WantFrag =

d - Delete a value

u - UNDO and continue

x - SAVE and continue

_______________________________________________________________________

[brok3n]

This is a signature that alarms on the vulnerability being exploited via the Translate method -- its not detecting the root behavior. When will cisco have a generic trigger for this alarm?

Thanks,

-brkn!

[ktimm]

From different code I have seen this still would be susceptable to false negatives. Personally it would seem that a possible way would be to look for no \r\n\r\n in the first several thousand bytes or traffic destined to port 80 however this does not seem to be possible with the current Signature Engines. If it is please let me know how to accomplish this.

[pheuch]

If seen three different exploit codes, none of them did include the translate string in the exchanged data. Two were using the SEARCH method, one the LOCK method. A common criteria is the lenght of the line and two has been using a large amount of NOPs (hex 90).

I created two custom signatures for it, which seems to work:

Both are using the TCP.STRING engine.

long line: [ ].+\x0a MinMatchLength set to 25000. Ignore outgoing, because the signature triggers on https traffic if the client port was one of the http ports (8000, 8080, ...)

NOPs : .\x90. MinMatchLength set to 400

Hope this helps

Peter

[DSmirnov]

Sorry guys,

but when new signature update will be available?

Same time, why there are no update for version 4.0 on support site? I'm affraid to upgrade...