Apache HttpComponents client Hostname verification MITM attack

2014-08-18 / 2014-08-21
Risk: Medium
Local: No
Remote: Yes
CWE: CWE-Other


CVSS Base Score: 5.8/10
Impact Subscore: 4.9/10
Exploitability Subscore: 8.6/10
Exploit range: Remote
Attack complexity: Medium
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: None

Security Advisory - Apache Software Foundation Apache HttpComponents / hc.apache.org Hostname verification susceptible to MITM attack CVE-2014-3577 / CVSS 1.4 Apache HttpComponents (prior to revision 4.3.5/4.0.2) may be susceptible to a 'Man in the Middle Attack' due to a flaw in the default hostname verification during SSL/TLS when a specially crafted server side certificate is used. Background - ---------- During an SSL connection (https) the client verifies the hostname in the URL against the hostname as encoded in the servers certificate (CN, subjectAlt fields). This is to ensure that the client connects to the 'real' server, as opposed to something in middle (man in the middle) that may compromise end to end confidentiality and integrity. Details - ------- The flaw is in the default Apache HttpComponents org.apache.http.conn.ssl.AbstractVerifier that is used in client mode for verification of hostname of the server side certificate. It parsed the entire subject distinguished name (DN) for the occurrence of any <CN=> substring (regardles of field). Therefore a DN of with a O field such as O='foo,CN=www.apache.org' and a CN of "www.evil.org” and ordered such that the O appears prior to the CN field would incorrectly match match on the <www.apache.org> in the O field as opposed to just the values in the CN and alternative subject name(s). The doctored field can be any field but the CN field itself; including the <E> or emailAddress field as long as it appears before the CN (some CAs reorder the DN). A third party in posession of such a doctored certificate and who also has the ability to intercept or reroute the traffic to a https server under its control (e.g. through DNS doctoring or various forms of traffic rerouting or spoofing) can thus perform a 'man in the middle' attack and compromise end to end confidentiality and integrety. Note that while some certificate authorities may be relatively strict on what they allow in the various fields - most are NOT; and allow for a relatively large amount of leeway in, for example, the OU and E fields. Impact: - ------- A man-in-the-middle can interpose itself between the server and the code using an affected version of Apache HttpComponents as a client. Leading to complete loss of end to end confidentiality and end to end integrety of the connection. Versions affected: - ------------------ All versions prior to HttpClient 4.3.5 (including the Android port) and HttpAsyncClient 4.0.2. The fix was introduced in these versions. http://search.maven.org/#artifactdetails|org.apache.httpcomponents|httpclient|4.3.5|jar http://search.maven.org/#artifactdetails|org.apache.httpcomponents|httpasyncclient|4.0.2|jar These have been silently pushed out to Maven central and Apache Dist as of 2014-08-1. An Android build was released on 2014-08-15. Resolution - ---------- A fix has been applied as of revision 1614065 and is part of release HttpClient 4.3.5 (including HttpClient port for Android against the official Google Android SDK)and HttpClient (async) 4.0.2. Upgrading to these versions newer resolves this issue. Mitigations and work arounds - ---------------------------- If upgrading to version 4.3.5/4.0.2 is not an option; one could change the default org.apache.http.conn.ssl.AbstractVerifier of earlier versions for revision 1614065 of newer. Note that exploitation of this flaw also requires some level of DNS or IP spoofing (or existing 'in the middle infrastructure' such as a corporate proxy or other TCP level equipment en-route). This need may allow for site specific alternative mitigations. Reproducing the flaw - -------------------- If so required; the following statements will allow the testing of a Apache HttpComponents client against a server with a thus crafted certificate: openssl req -new -x509 -keyout /dev/stdout \ -subj "/O=foo, CN=www.apache.org/CN=machine-domain-name/" \ -set_serial 86653 -nodes |\ openssl s_server -cert /dev/stdin -accept 8443 -www and a Apache HttpComponents client that connects to "https://www.apache.org:8443/"; with the DNS entry for www.apache.org pointing to the machine-domain-name. Credits and timeline - -------------------- The flaw was found and reported by Subodh Iyengar <http://www.subodh.io>, and Will Shackleton <http://www.shackleton.io/> from Facebook. It was reported on the 23rd of July. A fix was applied by and released on 2014-08-01. An Android build was released on the 2014-08-15. This security advisory fully discloses the issue and current insights known to the Apache Software foundation (the vendor). Apache would like to thank all involved for their help with this. A similar issue was reported by Florian Weimer of Red Hat in 2012 and was fixed by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692442#56. It has now been assigned CVE-2012-6153. Common Vulnerability Scoring (Version 2) and vector - --------------------------------------------------- CVSS Base Score 5.8 Impact Subscore 4.9 Exploitability Subscore 8.6 CVSS Temporal Score 4.8 CVSS Environmental Score 1.4 Modified Impact Subscore 5.2 ------------------------------ Overall CVSS Score 1.4 CVSS v2 Vector AV:N/AC:M/Au:N/C:P/I:N/A:P/E:F/RL:OF/RC:C/CDP:L/TD:L/CR:H/IR:L/AR:L 1.09 / : 1692 $

References:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692442#56


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top