Message-ID: <F6242D340921D5118D1E00508BB9837A07657D38@tlnmail1.toplayer.com>
From: kquest at toplayer.com (kquest@...layer.com)
Subject: Microsoft IIS SSL PCT vulnerability

 

-----Original Message-----
From: Ami Chayun
To: full-disclosure@...ts.netsys.com
Sent: 4/25/04 1:45 PM
Subject: Re: [Full-Disclosure] Microsoft IIS SSL PCT vulnerability
Importance: High

On Saturday 24 April 2004 22:32, kquest@...layer.com wrote:
> I just thought it would be nice to have a little bit more analysis for
this
> vulnerability...
> with all these exploits coming out because everybody probably wants to
know
> how to stop what's out now and what will follow. To do that we need to
> understand
> how the vulnerability is triggered. Unfortunately I don't have time to
do a
> complete
> analysis, but here's a simplified (and incomplete) version:
>
> The exploits seem to be using CLIENT HELLO packets...,
> but they don't seem to be PCT client hello packets.
>
> PCT CLIENT HELLO packet format:
>
> LEN (2 or 3 bytes) <-- 0x80 0x62 (in this case it's two bytes... you
know
> that it's two bytes bc MSB is set)
> MSG_TYPE (1 byte) <-- 0x01 for CLIENT HELLO
> CLIENT_VER (2 bytes) <-- 0x02 0xbd
> PAD (1 byte)
> SESSION_ID_DATA (32 bytes)
> CHALLENGE_DATA (32 bytes)
> OFFSET (2 bytes)
> ...
> the rest goes here....
>
> If you look at the exploits though, they don't seem to match the
format.
> If you look at the client version it doesn't appear to be PCT1 ( 0x80
> 0x01). Instead it's 0x02 0xbd. What is this magic number? Well, it
appears
> that it's not magic. For the vulnerability to be triggered, this
number
> needs to have either 0x0100 or 0x0200 bits set... (but not at the same
> time). The other values don't matter, so all these values will be good
> enough too: 0x0201, 0x0202, 0x0204, 0x0101, 0x0200, 0x0100, 0x02ff,
0x01ff,
> etc.
>
> Next, let's look at the length field (0x8062). It says that the
> SSL/PCT/whatever
> message is suppose to be 98 bytes, while the actual packet is 326
bytes.
> It seems that the key thing here is that the actual length is greater
than
> the
> declared length. As long as the declared length is 11 or over bytes,
you
> are all set.
>
> To be continued...
>
> Kyle

Looking at 
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/*checkout*/gnutls/doc/protocol/
draft-benaloh-pct-01.txt?rev=HEAD&cvsroot=GNU+TLS+Library&content-type=t
ext/plain

You will notice the PCT version 2 will actually set the CLIENT_VER to
0x02 
(PCT_VERSION_V2 := 0x0002), so our packet is not PCT version 1.0 but
rather 
version 2.0.

The CLIENT_HELLO of PCT v2 looks like (The original draft baddly labled
the 
version as the third parameter, which is not logical, as it won't be 
compatible with SSL/PCTv1):
char CH_CLIENT_VERSION[2]
char CH_SESSION_ID_DATA[30]
char CH_CHALLENGE_DATA[30]
char CH_OFFSET[2]

So the sub version, is not that crucial and as you seen in your finding,
can 
be set to anything you desire.

\x80\x62 = Length
\x01 = CLIENT_HELLO
\x02\xbd = Version 2.189 (what?)
...

So can we conclude that this is actually PCT v2?

And what we are overflowing is a mis-allocated buffer? (malloc 98 bytes 
followed by a malloc that is much bigger :) ).


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

Ami, you are probably correct about the PCT V2 CLIENT HELLO labeling.
It's probably a typo...

I doubt that it is a PCT v2 message (or even PCT v1) because 
what you have after 0x02bd does not match the PCT protocol.
You are suppose to have the SESSION ID DATA, which is 32/30
bytes long. It's not there in the exploits....

In my initial posting I did not provide all of the info...
For example, the VERSION's MSB could also be 0 while
the LSB is any number except 1 (e.g., 0x0004, 0x0010, etc).
What's even more intersting is that version field could
be set to SSLv2 (0x0002)!!! I intend to post a new PoC
for this vulnerability that will look very different from
the exploit we've seen so far. It won't be caught by 
the Snort's PCT signature either. 

Stay tuned...

Kyle

Powered by blists - more mailing lists