----- Original Message -----
From: "Ivars Suba" <IvarsSbank.lv>
> I would like to prefer operate with notorious facts at all and share
> with facts known myself, not with suspicions but it's everyone self
> matter . And so, RC4 key scheduling vulnerability in Win NT 4.0 and W2K:
> 1. W2K Kerberos TGT and service ticket - RC4-HMAC- unknown

I think that's an accurate statement, whether or not the security is truly
vulnerable is unknown, but I believe the security is questionable. I've been
looking at the internet-draft that I assume is associated with the RC4-HMAC
encryption type
(http://www-uxsup.csx.cam.ac.uk/netdoc/internet-drafts/draft-brezak-win2k-kr
b-rc4-hmac-02.txt) and I can be confident is saying that they tried to add
security, but failed at least partially.

For decryption the key is
K0 = MD4(UNICODE(password))
K1 = HMAC(K0, mode information)
realKey = HMAC(K1, checksum)

where checksum is communicated in the channel. This poses some interesting
security problems. It is clearly of the muddle idea of cryptography, which
makes analysis harder, but the construct more likely to be weak. The HMAC
chosen is not case complete so it actually loses entropy before it reaches
the full size, this will make recovering realKey easier, but K0 more
difficult. The checksum though only has 64-bits of (assumed) random
information, other than that it is derived from K0. Given this information
there are only 2^64 possible realKeys for each entity, and that is not a
cryptographicly secure number. In fact because the 64-bits are randomly
chosen it is expected that a duplicate realKey will appear after merely 2^32
connections. This leads to being able to determine realKey fairly easily.
However reversing this to get K0 is more difficult, MD5 was chosen which
makes life easier for the attacker, since MD5 has known weaknesses, that
leaves solving equations close to the form of:
realKey0 = MD5(password, checksum0)
realKey1 = MD5(password, checksum1)
...
realKeyn = MD5(password, checksumn)

While not entirely vulnerable it is possible to filter out possible values
for password, this combined with password limitations built into Windows
leads to a not very significant challenge.

> 2. Secure NetLogon Channels - RC4 - possible vulnerable( I know how it
> works, but havn't any public reference)

I couldn't find an immediate reference so I'll skip this one.

> 3. PPTP MPPE Key derivation with:
> 3.1. MS-CHAP credentials and 40 or 56 bit Session keys -
> vulnerable - session key obtained directly from with pswd SHA hash
> without any challenge.

Completely vulnerable, even to just the old vigenere attacks.

> 3.2 MS-CHAP credentials with 128 bit session key and MS-CHAPv2
> credentials- not vulnerable- session key obtained with pswd and
> challenge SHA hash. For more info
> http://search.ietf.org/internet-drafts/draft-ietf-pppext-mppe-keys-03.txt

For this I'll just point to the work of Schneier, et al. They completely
broke PPTP v1 and showed that PPTP2 was better but still vulnerable.

>4. MS IIS 5.0 amd IE5.0 SSLv3 - not vulnerable

correct.

>5. SAM password protection with Syskey - unknown

Vulnerable for a different reason. The Syskey has to be stored somewhere,
back step as many times as necessary until the key is stored in a known
location without any significant protection.

                Joe

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]