[Snort-sigs] Signatures for .ida attempt
cmg at ...26...
Wed Jan 16 14:24:04 EST 2002
robert <rroot at ...254...> writes:
Shortend this up a bit
attempt -> uricontent:".ida?"; nocase; dsize:>239;
access -> uricontent:".ida";
> Looking at this logically, I still can not figure this out.
> <not the rules, I understand them. but why this is happening>
> 1. For the rules, the ".ida" trigger is part of the "URI" content.
> 2. I am receiving these in a series of 3 or more packets.
> 3. The first packet is an HTTP Get of only a few bytes, which varies
> 4. The second packet contains the ".ida" content
> 5. In my system this <the .ida> is being reported as part of the "Request Method", not the URI
> 6. Although the ".ida" is reported as part of the "request method";
> The rules catch these packets some of the times.
> Could this be particular to my OS? <win 2k>
> I am using winsock 2, sockets version 2.2.
snort uses pcap which is below the sockets layer. I don't believe it
has anything to do with your os though
> I have studied the packets which triggered a rules alert
> and the packets which did not.
> For the life of me, I can not figure out any reason why
> some ".ida" packets are getting caught / or slipping through.
> At first I thought it was because my system is reporting the ".ida?" as part of the
> "Request Method" and not as part of the URI, but that was not it.
> My system is showing all of the packets which contain ".ida?", as being part of the
> "Request Method". Not just the ones which slipped through.
> I mentioned I am receiving the ".ida?" data within the second packet of the
> original http GET request. Could this be part of the cause.?
Do you have stream4 enabled? All things being equal, uricontents are
pretty dumb right now (as in not terribly sophisiticated).
A uricontent is special in that it only looks at the
GET uriportion?werewrwer\r\n and the split up packet is giving us a
packet that doens't match that view of the world
Stream4 will help create fake packets for streams so that enough of
the url up to the newline is reassembled so then the uricontent will
be able to look at GET /default.ida even if it is across two packets.
> Does anyone know if usually the ".ida?> is contained within the
> first http GET? My first http get contains only this:
Most of my alerts have this.
> HTTP: GET Request (from client using port 3965)
> HTTP: Request Method = GET
> HTTP: Uniform Resource Identifier =
> 00000: 00 01 02 87 97 19 00 20 78 D1 27 AF 08 00 45 00 ....... x.'...E.
> 00010: 00 2C 92 C4 40 00 6E 06 47 27 D8 B0 98 23 C0 A8 .,.. at ...258...'...#..
> 00020: 01 64 0F 7D 00 50 8A E0 0F C9 7A 02 9F 90 50 18 .d.}.P....z...P.
> 00030: 25 30 F8 48 00 00 47 45 54 20 01 33 %0.H..GET .3
> Notice the URI content only contains a hex 01 33. This also varies from
> attempt to attempt.
> TCP flags are Ack & Push
I'm not sure what causes that split, perhaps there is some equipment
along the way doing this. I saw on some forum asking if this was a
new variant but I think the consensus was no.
> I realize I could change the "uricontent" to "content" in the web-iis.rules.
That is one
> Or add 2 more rules to my local.rules with "content:" Or change the
> "/.ida?" to something like "HOST:www.worm.com" or the hex
> equivalent. This would be a jury rig fix at best, for my particular
> system only.
The ida is for the specific vulnerability. A www.worm.com would be
for the specific exploit. It would be a positive indicator and
applicable to more than just your system, just not more than your exploit.
> I am snipping part of the packets that have no bearing.
> Also I included notes to the right side. This shows where the
> "Request Method" and the "URI", starts and ends as reported by my OS.
> Any thoughts, or slaps up beside the head?? <bg>
> All are welcome.
Putting a full-blown HTTP decoder into snort 2.0 is a very high
priority and I think you've illustrated parts of how dumb we can be
currently. The request method is anything up to the first space and
the uri is the first set of nonspaces after that. You're seeing the
problems with protocol decoding at the packet level.
Putting stream4 in helps matters a great deal but there are still a
few ways to trick snort unfortunately.
Chris Green <cmg at ...26...>
"Not everyone holds these truths to be self-evident, so we've worked
up a proof of them as Appendix A." -- Paul Prescod
More information about the Snort-sigs