Endian IDS

C

COKE CAN

Limp Gawd
Joined
Nov 12, 2006
Messages
391
Can some one explain the following?

Code: 
Date:	12/23 17:13:58  	Name:	Portscan detected from 70.xx.xxx.91 Talker(fixed: 30 sliding: 14) Scanner(fixed: 0 sliding: 0)
Priority:	n/a 	Type:	n/a
IP info: 	n/a:n/a -> n/a:n/a
References: 	none found 	SID: 	n/a
Date:	12/23 17:14:05 	Name:	Portscan detected from 70.xx.xxx.91 Talker(fixed: 4 sliding: 30) Scanner(fixed: 0 sliding: 0)
Priority:	n/a 	Type:	n/a
IP info: 	n/a:n/a -> n/a:n/a
References: 	none found 	SID: 	n/a
Date:	12/23 21:29:56 	Name:	(http_inspect) DOUBLE DECODING ATTACK
Priority:	n/a 	Type:	n/a
IP info: 	192.168.1.199:2782 -> 192.168.1.1:8080
References: 	none found 	SID: 	n/a
Date:	12/23 21:29:56 	Name:	(http_inspect) DOUBLE DECODING ATTACK
Priority:	n/a 	Type:	n/a
IP info: 	70.xx.xxx.91:40901 -> 65.206.60.124:80
References: 	none found 	SID: 	n/a

This came out of yesterday's log
 
No one can provide any assistance?

I did a whois on 65.206.60.124 and found this is a Verizon IP. Should I send them a copy of the log?
 
I just looked at my log and found teh same thing, plus other junk, I never check the logs lol
 
YARDofSTUF said:
I just looked at my log and found teh same thing, plus other junk, I never check the logs lol
Click to expand...

haha

Same IP address? Because I keep getting that same IP address. There were some more from last night
 
taken from Snort docs "README.http_inspect"

* double_decode [yes/no] *
The double_decode option is once again IIS specific and emulates IIS functionality. How this works is that IIS does two passes through the request URI, doing decodes in each one. In the first pass, it seems that all types of IIS encoding is done: UTF-8 unicode, ASCII, bare byte, and %u. In the second pass the following encodings are done: ASCII, bare byte, and %u. We leave out UTF-8 because I think how this works is that the % encoded UTF-8 is decoded to the unicode byte in the first pass, and then UTF-8 decoded in the second stage. Anyway, this is really complex and adds tons of different encodings for one char. When double_decode is enabled, so is ascii to enforce correct decoding.
 
basically, what's happening in double decode is an exploitation of URL canonicalization.

from Wikipedia:
Should "C:\inetpub\wwwroot\cgi-bin\..\..\..\Windows\System32\cmd.exe" be executed? Clearly not. The fault is failure to canonicalize the filename to a unique (simplest) representation, namely: C:\Windows\System32\cmd.exe, before doing the path check. This type of fault is called a directory traversal vulnerability.
Click to expand...
UTF-8 was noted as a source of vulnerabilities and attack vectors in Cryptogram Newsletter July 2000 by Bruce Schneier and Jeffrey Streifling.

When Microsoft added unicode support to their Web server, a new way of encoding ../ was introduced into their code, causing their attempts at directory traversal prevention to be circumvented.

Multiple percent encodings, such as

* %c1%1c
* %c0%9v
* %c0%af

translated into / or \ characters.

Why? Percent encodings were decoded into the corresponding 8-bit characters by Microsoft webserver. This has historically been correct behavior as Windows and DOS traditionally used canonical 8-bit characters sets based upon of ASCII.

However, the original UTF-8 was not canonical, and several strings were now string encodings translatable into the same string. Microsoft performed the anti-traversal checks without UTF-8 canonicalization, and therefore not noticing that (HEX) C0AF and (HEX) 2F were the same character when doing string comparisons.
Click to expand...

Now, onto the question of whether or not you should worry... Well, do you even run IIS web server? and do you have all patches applied to IIS?
 
Most of the stuff Snort picks up on the Red/WAN interface can be shrugged off. If you start seeing traffic actually getting through to your systems then you have something to be worried about.
 
Stang Man said:
basically, what's happening in double decode is an exploitation of URL canonicalization.

from Wikipedia:


Now, onto the question of whether or not you should worry... Well, do you even run IIS web server? and do you have all patches applied to IIS?
Click to expand...

No sir, I am not keen on what IIS is exactly.
 
Orinthical said:
Most of the stuff Snort picks up on the Red/WAN interface can be shrugged off. If you start seeing traffic actually getting through to your systems then you have something to be worried about.
Click to expand...

How can I recognize what exactly is getting in. Are there any examples on "teh intarwebz" for n00bz like myself?
 
COKE CAN said:
How can I recognize what exactly is getting in. Are there any examples on "teh intarwebz" for n00bz like myself?
Click to expand...
Snort has a lot of good documentation right on their website. Wiki links to some good sites as well.
http://www.snort.org/
http://en.wikipedia.org/wiki/Snort_(software)

On IPCop, you'd enable Snort on the Green (LAN) interface and watch for hits there. I'd imagine Endian allows you to do much the same. Typically you have little to worry about unless you're forwarding a massive amount of ports to a specific system or you have a box in the DMZ. Your greatest defense? Make sure everything's patched. :)
 
COKE CAN said:
No sir, I am not keen on what IIS is exactly.
Click to expand...

IIS is Microsoft's web server, "Internet Information Services"

if you don't have IIS up and running, don't worry about it
 
You must log in or register to reply here.
Back
Top