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

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

Powered by blists - more mailing lists