[Snort-sigs] Signatures for .ida attempt

robert 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 = 
>> 3
>> 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.
Don't know.

>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 mailing list