|




 
 

Gros, Charles-
Charles-Henri
Haley, David
Lisanke, Bob
Schaff, Clovis
ð 

h ðverview of Windows Security Issues
h Various Protocols and Problems

h Introducing MSCHAP
h MSCHAP to MSCHAP2
h MSCHAP2 to PEAP
h Mur£
Mur £ Models

h Lessons Learned



  
 
h Wed Mar 10, 6:55 PM ET
SEATTLE (Reuters) - Microsoft Corp. (Nasdaq:MSFT - news)
upgraded a recent security warning to "critical" after
discovering new ways in which an attacker could run
malicious software on a vulnerable computer, the world's
largest software maker said on Wednesday.
The software flaw, which affects the two latest versions of
Microsoft's ðutlook e e--mail, calendar and contacts program,
were initially rated as "important" in Microsoft's monthly
security bulletin issued on Tuesday.
 


h Transport Layers
ƛ NetBIðS, NetBEUI, TCP/IPƦ
h Protocols on top
ƛ SMB, RPC, NetMeetingƦ
h Many dialects of protocols
ƛ SMB: PCNP1.0, LanMan 1.0/2.0,
NT LM 0.12, CIFSƦ
  
 

h Backwards compatibility between all
various dialects
h More implementations: more potential
for human error (incorrect codeƦ)

h Most protocol weaknesses seem

unrelated to the protocol itself


 

h ðld friends like Buffer ðverflows

h Holes in client-
client-side code (ActiveXƦ)

h Poor crypto implementation might be easier

to crack

h Programmer Laziness/Carelessness
 

 
 
h Windows empowers the user, less
restrictive environment
h Easy for the unwary user to execute
unwanted code (email virus)
h Convenience vs. Security (automatic
parsing of HTML email, etc.)
h Uneducated user = highly vulnerable
    

h Completely and utterly depends on

secrecy and strength of password
h Many ways to fool uneducated user
into giving away password
(impersonating administrators, etc.)
h Reused password = less secure
|
 


h Hard to find current specifications

h Hard to tell off-
off-hand why some
services are running, others arenƞt
h Many are activated for unclear reasons
(e.g. SQL server)
h To understand requires a competence
which most end-
end-users lack
|   

!
  
"
h There seem to be no formal specs for CIFS
(protocol for Windows file-
file-sharing)
ƛ ƠWithout a current and authoritative protocol
specification, there is no external reference
against which to measure the Ɲcorrectnessƞ of an
implementation, and no way to hold anyone
accountable. Since Microsoft is the market leader
[Ʀ] the behavior of their clients and servers is
the standard against which all other
implementations are measured.ơ
Christopher Hertel, http://www.ubiqx.org/cifs/SMB.html

 
 

 



h Windows supports:
ƛ Password Authentication Protocol
ƛ CHAP: Challenge-
Challenge-Handshake Authentication Protocol
ƛ MSCHAP: MS extensions to CHAP
ƛ MSCHAP2: Fixes to MSCHAP
ƛ ðthers (EAP, PEAPƦ)
h PAP: passwords transmitted in plaintext
h Acceptable before when networks were very small
h (MS)CHAPƞs major improvement: passwords no
longer transmitted in plain text!
h Sounds goodƦ
° "
CHAP does not specify which
encryption algorithm to use.
MSCHAP on the other hand, does.
 

#
°
$

h August 1996
ƛ RFC 1334: CHAP
h ðct 1998
ƛ RFC 2433: MSCHAP1
h Jan 2000
ƛ RFC 2759: MSCHAP2
h Nov 2001
ƛ 1.4 Update to Win98 Dial-
Dial-Up-
Up-Networking, implements
MSCHAP2
h ðct 2003: PEAP Internet Draft
ƛ Protected Extensible Authentication Protocol. Combines
TLS and MSCHAP2.
á

 


 
  
 %& 
 %&  
 %

  &

h For Virtual Private Network, connection over TCP/IP

link
h Microsoftƞs implementation breaks down:
ƛ Authentication level = MS-
MS-CHAP
ƛ Encryption = RC4

h Point to Point Tunneling Protocol: data channel

encapsulated in PPP packets;
ƛ no protocol specification for security
h MS--PPTP: server under WinNT
MS
ƛ auth. options: clear password, or hashed, or challenge-
challenge-
response
''
   ()
   ()


 
h Windows NT hash functions:
ƛ LanManager hash based on DES; Win NT hash based on
MD4

h LMƞs hash is Ơhome-

Ơhome-madeơ and weak:
ƛ truncates password to 14-
14-char string;
ƛ converts lowercase to uppercase;
ƛ splits 14-
14-byte in two 7-
7-byte halves, giving two DES keys
ƛ with keys, encr. magic "KGS!@#$%" -> 2 8- 8-byte strings
ƛ concatenate those string : 16-
16-byte hash value
h WinNT hash: 16-
16-byte hash with MD4, no salt either
''
   * )

'' 


h MS--CHAP Challenge-
MS Challenge-Response step:
ƛ Authenticator Challenge:
Challenge:
h 8-byte random value
ƛ Client side: for both LM and NT hash functionƦ
1. computes 16-
16-byte hash value
2. Zero--Pad to get to 21-
Zero 21-byte value -> 3 7-
7-byte DES
keys
3. encrypt challenge with each DES key
4. concatenate those 3 8-8-byte values -> 24-
24-byte
response
ƛ Client Response
Response::
h send back both values, with a flag
 '

   +)
'   +)
 
# 

à

à à
à à à à à à à à à
à

à
 à


 DES (opt.)























  !"#

 
        




 







$%%&'& &!"&()!%%&' DES

 
        






 
 
 
 
 
 
''

   ,)
   ,)

$
''

$

h Cryptanalysis of MS-
MS-CHAP:
h Dictionary attack [Lðpht proved it is efficient]
ƛ ðffline: pre-
pre-computed DES encryption of each
likely values of P0ƦP6 and P7ƦP13
ƛ Given R0ƦR7 R8ƦR15 R16ƦR23 seen on link:
1. Retrieve K14 and K15 : average 215 DES ops.
2. for N2 likely values of P7ƦP13 : (DES encr. known)
K14 and K15 retrieved : N2/216 DES trials max
3. for N1 likely values of P0ƦP6:
K7 retrieved : N1/28 DES trials max
h Cryptanalysis of MS-
MS-PPE: secret key also
based on password
-ð .
$
 


  
h Creator: Mudge, Schneierƞs co-
co-author of the article

h April 97, Electronic Engineering Times

Times::
Explanation of Mudgeƞs motivations; Nash, MS Ɲdirector of
marketing for Windows NT Serverƞ, answers back.
ƛ Mudge would like to have MS policy on security changed;
ƛ Nash claims enough internal beta-
beta-testing
h July 98, Windows & .NET magazine
magazine::
ƝNT Server Security Checklistƞ excerptsƦ
ƛ Enforce strong password policy
ƛ Use password crackers:
h ƠThe latest version of L0phtCrack is Microsoft's worst nightmare and
every NT administrator's new best friend.ơ
 £
£ 

/+
/

h CHAP and MSCHAP both suffer from

man--in-
man in-the-
the-middle (no server
authentication). Mur£
Mur£ verified this.

h MSCHAP1: Failure_PasswordExpired
forces bad LanMan hash to be sent
  (

h MSCHAP2 addresses two points:

ƛ Cryptography: uses SHA-
SHA-1, MD4
ƛ Man-
Man-in-
in-the-
the-middle partially solved: server
authentication through client challenge
h Client sends its own challenge along
with its response
h In success message server sends
monster--hash back
monster
(
h To be able to generate response hash, one needs
to have the plain-
plain-text or 1-
1-step hashed password
available.

h According to Mur£
Mur£ however there is still a man-
man-in-
in-
the--middle attack
the
h Solution: send serverƞs name in the hash
h MSCHAP2 still depends on password integrity!

h Microsoft decided to keep backwards compatibility

with MSCHAP1 ƛ so the attacker can convince both
the client and server to negotiate that instead!


 

h Modeled CHAP ƛ discovered basic

attack (MitM)
h Modeled MSCHAP1 ƛ verified MitM,
and that intruder could convince client
to send LanMan hash
h Modeled MSCHAP2 ƛ but ran into a
wall

0 
 

h Schneier article Ơpollutedơ first attempt.

ƛ We knew what we wanted to show, so we
designed the model to show it!
ƛ Left out many possible intruder moves
ƛ Model Ơfelt badơ and was obviously incomplete
” Redesigned model to have a much more
robust intruder.
” This confirmed MitM for MSCHAP2, which
did not appear with weaker model


  


h Hard to sort through morass of informal

specifications
h MSCHAP2 seems to fix MSCHAP1 problems,
but allows for version rollback attacks
h Mur£
Mur £ seems adequate for this protocol
h However, the found attacks are obvious
enough after having formalized the RFCs


  
1

.
h MSCHAPv2: better crypto, but still only as secure as
password
h Backwards compatibility removes much of the point
of an upgrade ƛ both for MSCHAPv1 (LanMan hash)
and MSCHAPv2 (compatibility with v1)
h MSCHAPv1 mistake (poor hash) should have been
avoided
ƛ Improper, insufficient cryptanalysis
h Big problem with MSCHAPv1 is not the fault of the
protocol itself
h MSCHAPv2: more robust crypto, but protocol is still
flawed




h RFCs
ƛ http://www.zvon.org/tmRFC/RFC2759/ðutput/index.html
ƛ http://www.zvon.org/tmRFC/RFC2433/ðutput/index.html
ƛ http://www.zvon.org/tmRFC/RFC1994/ðutput/index.html
h Schneier papers:
ƛ http://www.schneier.com/paper-
http://www.schneier.com/paper-pptp.html
ƛ http://www.schneier.com/paper
http://www.schneier.com/paper--pptpv2.html


1

.

h MS Knowledge Base
ƛ Articles 297816, 285189, 297840, 297818
h MSDN:
ƛ http://msdn.microsoft.com/library/en-
http://msdn.microsoft.com/library/en-us/wceeap/html/
cxconextensibleauthenticationprotocol.asp
h SMB/CIFS:
SMB?, Richard Sharpe, 2002,
ƛ What is SMB?,
http://samba.org/cifs/docs/what--is
http://samba.org/cifs/docs/what is--smb.html
CIFS, Christopher R. Hertel, 2003,
ƛ Implementing CIFS,
http://www.ubiqx.org/cifs/