[Snort-sigs] Signatures for .ida attempt
rroot at ...254...
Thu Jan 17 14:56:04 EST 2002
On Wed, 16 Jan 2002 16:23:55 -0600, you wrote:
>robert <rroot at ...254...> writes:
>Shortend this up a bit
>attempt -> uricontent:".ida?"; nocase; dsize:>239;
>access -> uricontent:".ida";
>snort uses pcap which is below the sockets layer. I don't believe it
>has anything to do with your os though
<you should have put that below the, slaps up beside the head <bg>>
>> 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.
MSS was my first thought.
The Fragment flag was set to Do Not Fragment.
>I saw on some forum asking if this was a
>new variant but I think the consensus was no.
I was wondering the same thing. But only because the rules have missed a few.
Not because I understand the worms methodology inside & out.
>> 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.
I believe you touched on something there.
Decoding the information.
I was *assuming the packet decoder I used, interpreted the packet correctly.
It gave me the information I relayed in the previous message, about the .IDA?
not being in the URI.
I just assumed it was correct. I was leaning more towards the packet being
malformed as part of the worms methodology of propagation.
>Putting stream4 in helps matters a great deal but there are still a
>few ways to trick snort unfortunately.
For now, I am going to place a generic catch all type of rule in my local.rules.
Thanks for the information. More food for thought
More information about the Snort-sigs