Advanced search  

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Pages: [1]   Go Down

Author Topic: Snort Generates error when User tries to login / view  (Read 4652 times)

0 Members and 1 Guest are viewing this topic.

DK1

  • Coppermine newbie
  • Offline Offline
  • Posts: 3
Snort Generates error when User tries to login / view
« on: June 16, 2004, 03:17:12 am »

I have installed CPG 1.3.0 on my custom Redhat 7.3 server, and I must say this is very nice, install went smooth, no problems setting up what so ever and am happily using it right now, all in all a very professional distro, well done.

The only problem I have is that I also have Snort and Guardian installed and now my acid logs are filling up with
DOUBLE DECODING ATTACK
OVERSIZE CHUNK ENCODING
BARE BYTE UNICODE ENCODING
APACHE WHITESPACE (TAB) and lastly
NON-RFC HTTP DELIMITER .errors whenever CPG is accessed / logged into, the upshot of which is guardain blocks the offending IP, damn, no more photos for you.
Any suggestions, other than disabling guardian ?
Thanks

Damn, sorry just realised this post is on the wrong board, can admin please move it to the support forum ?
« Last Edit: June 16, 2004, 03:32:21 am by DK1 »
Logged

Tarique Sani

  • VIP
  • Coppermine addict
  • ***
  • Offline Offline
  • Gender: Male
  • Posts: 2712
    • http://tariquesani.net
Re: Snort Generates error when User tries to login / view
« Reply #1 on: June 16, 2004, 04:40:12 am »

Can you give pointers to what each of these errors mean and possibly which part of the out put generates it?
Logged
SANIsoft PHP applications for E Biz

DK1

  • Coppermine newbie
  • Offline Offline
  • Posts: 3
Re: Snort Generates error when User tries to login / view
« Reply #2 on: June 20, 2004, 03:21:09 am »

Sorry about the no responding thing, I ddint get an update email so didnt know you had posted....

So after actually doing some research (Note - Next time do this bit first)
Here are the results

From : http://www.snort.org/docs/snort_manual/node17.html#SECTION003810000000000000000

Found that all these errors are generated by http inspect :-
HttpInspect is a generic HTTP decoder for user applications. Given a data buffer, HttpInspect will decode
the buffer, find HTTP fields, and normalize the fields. HttpInspect works on both client requests and
server responses.

So here are the errors, there desricption and matched with the http access log...

BARE BYTE UNICODE ENCODING
Bare byte encoding is an IIS trick that uses non-ASCII chars as valid values in decoding UTF-8 values.
This is NOT in the HTTP standard, as all non-ASCII values have to be encoded with a %. Bare byte encoding
allows the user to emulate an IIS server and interpret non-standard encodings correctly.
The alert on this decoding should be enabled, because there are no legitimate clients that encoded UTF-8 this way, since it is non-standard."

Acid log : - (http_inspect) BARE BYTE UNICODE ENCODING        2004-06-19 14:18:29
Httpd access log : -
www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:18:07 +1200] "GET /stilllife/upload.php
HTTP/1.1" 200 10068 "http://www.derivedsingularity.com/stilllife/modifyalb.php?album=18" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.0)"www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:20:16 +1200] "POST /stilllife/upload.php
HTTP/1.1" 200 7185 "http://www.derivedsingularity.com/stilllife/upload.php" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.0)"
------------------------------
apache_whitespace
This option deals with non-RFC standard of tab for a space delimiter. Apache uses this, so if the
emulated web server is Apache you need to enable this option. Alerts on this option may be interesting,
but may also be false positive prone.

Acid log :- (http_inspect) APACHE WHITESPACE (TAB)        2004-06-19 14:18:33
Http access log : -
www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:18:07 +1200] "GET /stilllife/upload.php
HTTP/1.1" 200 10068 "http://www.derivedsingularity.com/stilllife/modifyalb.php?album=18" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.0)"www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:20:16 +1200] "POST /stilllife/upload.php HTTP/1.1" 200 7185 "http://www.derivedsingularity.com/stilllife/upload.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
-----------------------------
NON-RFC HTTP DELIMITER
non_rfc_char { <byte> [<byte ...>] }
This option let's users receive an alert if certain non-RFC chars are used in a request URI. For
instance, a user may not want to see NULL bytes in the request-URI and we can give an alert on that.
Please use this option with care, because you could configure it to say, alert on all '/' or something
like that. It's flexible, so be careful.

Acid log :- (http_inspect) NON-RFC HTTP DELIMITER        2004-06-19 14:18:29
Http access log :- See above (Apache whitespace & Bare Byte errors for this time stamp)
-----------------------------
DOUBLE DECODING ATTACK
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.

ACID Log :-[snort] (http_inspect) DOUBLE DECODING ATTACK        2004-06-19 22:15:51
Http access log :-
www.derivedsingularity.com 210.54.97.213 - - [19/Jun/2004:22:15:51 +1200] "GET /stilllife/index.php
HTTP/1.1" 200 26678 "http://www.derivedsingularity.com/stilllife/thumbnails.php?album=11" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"www.derivedsingularity.com 210.54.97.213 - - [19/Jun/2004:22:15:51 +1200] "GET /stilllife/albums/userpics/10003/thumb_1_multipart_xF8FF_3_silver%2520ww%25204wks5.jpg HTTP/1.1" 200 4019 "http://www.derivedsingularity.com/stilllife/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
-----------------------------
OVERSIZE CHUNK ENCODING  
chunk_length <non-zero positive integer>
This option is an anomaly detector for abnormally large chunk sizes. This picks up the apache chunk
encoding exploits, and may also alert on HTTP tunneling that uses chunk encoding.

Acid log :- (http_inspect) OVERSIZE CHUNK ENCODING        2004-06-19 14:21:00    
Httpd Log :-
www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:21:00 +1200] "POST /stilllife/upload.php
HTTP/1.1" 200 6648 "http://www.derivedsingularity.com/stilllife/upload.php" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.0)

So after all that im going to tune my snort install and remove the IIs allerters, but that still leaves the specific apache errors that appear to be being generated by uploading to an album.

Cheers
Logged
Pages: [1]   Go Up
 

Page created in 0.02 seconds with 20 queries.