COMMAND

	IE SSL man in the middle attack

SYSTEMS AFFECTED

	 IE 5 and 5.5 are vulnerable straight-up, and IE 6 is mostly vulnerable.

	 Outlook S/MIME (tested with Outlook Express 5 w2k/SP3)

	

PROBLEM

	Mike      Benham      [moxie@thoughtcrime.org]      of      thoughtcrime
	[http://www.thoughtcrime.org] found :
	

	

	Internet Explorer's implementation of SSL contains a vulnerability  that
	allows for an active, undetected, man in the middle attack.  No  dialogs
	are shown, no warnings are given.
	

	 Description

	 ===========

	

	In the normal case, the administrator  of  a  web  site  might  wish  to
	provide secure communication  via  SSL.  To  do  so,  the  administrator
	generates a certificate and has it signed by  a  Certificate  Authority.
	The generated certificate should list the URL of the secure web site  in
	the Common Name field of the Distinguished Name section.
	

	The CA verifies that the administrator legitimately owns the URL in  the
	CN field, signs  the  certificate,  and  gives  it  back.  Assuming  the
	administrator is trying to secure www.thoughtcrime.org, we now have  the
	following certificate structure:
	

	[CERT - Issuer: VeriSign / Subject: VeriSign]

	-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]

	

	When a web browser receives this, it should verify  that  the  CN  field
	matches the domain it just connected to, and that it's  signed  using  a
	known CA certificate. No man in the middle attack  is  possible  because
	it should not be possible to substitute a certificate with  a  valid  CN
	and a valid signature.
	

	However, there is a slightly more complicated scenario. Sometimes it  is
	convenient to delegate signing authority to more localized  authorities.
	In this case, the administrator  of  www.thoughtcrime.org  would  get  a
	chain of certificates from the localized authority:
	

	[Issuer: VeriSign / Subject: VeriSign]

	-> [Issuer: VeriSign / Subject: Intermediate CA]

	   -> [Issuer: Intermediate CA / Subject: www.thoughtcrime.org]

	

	When a web browser receives this, it should verify that the CN field  of
	the leaf certificate matches the domain it just connected to, that  it's
	signed by the intermediate CA, and that the intermediate  CA  is  signed
	by a known CA certificate. Finally, the web browser  should  also  check
	that all intermediate certificates have valid CA Basic Constraints.
	

	You guessed it, Internet Explorer does not check the Basic Constraints.
	

	 Exploit

	 =======

	

	So what does this mean? This means that  as  far  as  IE  is  concerned,
	anyone with a valid CA-signed certificate for ANY domain can generate  a
	valid CA-signed certificate for ANY OTHER domain.
	

	As  the  unscrupulous  administrator  of  www.thoughtcrime.org,  I   can
	generate a valid certificate and request a signature from VeriSign:
	

	[CERT - Issuer: VeriSign / Subject: VeriSign]

	-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]

	

	Then I generate a certificate for any domain I want, and sign  it  using
	my run-of-the-mill joe-blow CA-signed certificate:
	

	[CERT - Issuer: VeriSign / Subject: VeriSign]

	-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]

	   -> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com]

	

	Since   IE   doesn't   check    the    Basic    Constraints    on    the
	www.thoughtcrime.org certificate, it accepts this certificate  chain  as
	valid for www.amazon.com.
	

	Anyone with any CA-signed certificate  (and  the  corresponding  private
	key) can spoof anyone else.
	

	 Severity

	 ========

	

	I would consider this to be  incredibly  severe.  Any  of  the  standard
	connection hijacking techniques can be combined with this  vulnerability
	to produce a successful man in the middle attack. Since all you need  is
	one constant CA-signed certificate (and the corresponding private  key),
	an attacker can use that to  generate  spoofed  certificates  for  other
	domains as connections are intercepted (on the fly). Since  no  warnings
	are given and  no  dialogs  are  shown,  the  attacker  has  effectively
	circumvented all security that an SSL certificate provides.
	

	There is  some  level  of  accountability,  though,  since  a  user  who
	randomly chooses to view the certificate of the web site she's  visiting
	will see the attacker's certificate  in  the  chain.  However,  by  that
	point the damage has already been done. All "secure"  data  has  already
	been transmitted.
	

	 Update (13 August 2002)

	 ======

	

	Proof of concept code to perform described hijacking is available at :
	

	http://www.thoughtcrime.org/ie.html

	

	

	 Update (03 September 2002)

	 ======

	

	Mike Benham adds :
	

	Outlook's S/MIME implementation is vulnerable to the  certificate  chain
	spoofing attack, despite Microsoft's claim that IE is the only  affected
	application. The  vulnerability  allows  anyone  to  forge  the  digital
	signature on an email that is to be viewed  with  Outlook.  No  warnings
	are given, no dialogs are shown.
	

	For a complete description of the certificate chain attack, see:
	

	http://online.securityfocus.com/archive/1/286290

	

	As  with  the  IE  SSL  vulnerability,  an  attacker  generates  a   bad
	certificate chain:
	

	[Issuer:VeriSign | Subject:VeriSign]

	>[Issuer:VeriSign | Subject:www.thoughtcrime.org]

	 >[Issuer:www.thoughtcrime.org | Subject:Bill Gates/billgates@microsoft.com]

	

	Outlook fails  to  check  the  Basic  Constraints  on  the  intermediate
	certificate and accepts the leaf certificate as valid.
	

	 Exploit

	 =======

	

	1) Put a valid CA-signed certificate and private key in a file "middle.pem"

	

	(If you don't have a valid CA-signed certificate, there's one bundled with

	sslsniff: http://www.thoughtcrime.org/ie.html)

	

	2) Generate a fake leaf certificate signing request:

	

	  a) openssl genrsa -out key.pem 1024

	  b) openssl req -new -key key.pem -out leaf.csr

	

	3) Sign the CSR with your "intermediate" certificate:

	

	  a) openssl x509 -req -in leaf.csr -CA middle.pem -CAkey middle.pem 

	     -CAcreateserial -out leaf.pem

	

	4) Sign a spoofed mail message:

	

	  a) openssl smime -sign -in mail.txt -text -out mail.msg -signer leaf.pem -inkey 

	     key.pem -certfile middle.pem -from billgates@microsoft.com -to 

	     whomever@wherever.com -subject "SM Exploit"

	

	5) Send the mail:

	

	  a) cat mail.msg | sendmail whomever@wherever.com

	

SOLUTION

	When the CA Basic Constraint on the  middle  certificate  is  explicitly
	set to false and marked as critical, IE 6 does  not  follow  the  chain.
	When it's  not  mentioned  at  all,  IE  6  follows  the  chain  and  is
	vulnerable.
	

	This just  means  that  an  attacker  needs  to  use  a  VeriSign-issued
	certificate to exploit IE 6.
	

	Nothing yet.