[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 May 2015 22:48:04 +0500
From: "Alexander E. Patrakov" <patrakov@...il.com>
To: oss-security@...ts.openwall.com
CC: android@...ongswan.org
Subject: StrongSwan VPN client for Android leaks username to rouge server
Hello.
I found that, in the event of DNS spoofing, StrongSwan VPN client for
Android can leak the username and the MSCHAPv2 authentication value to a
rogue server if it has any valid X.509 certificate. Unless I
misunderstand something about X.509 certificates and their use for
confirming IKEv2 identities, and unless this is already known, this
might use a CVE ID.
The client that I am talking about is this Android application:
https://play.google.com/store/apps/details?id=org.strongswan.android
In the example below, the client was supposed to connect to vpn.xorp.ru
using username "alice" and a password. The server identity is validated
by a CA-issued certificate that ultimately chains to something in the
default trust store. However, a hacker has spoofed the DNS (well, in the
example, that's actually a deliberate misconfiguration by me) so that
vpn.xorp.ru points to his server (185.48.56.74 in this example) instead.
On that server, he (legitimately) has a valid certificate for
vpn.armority.ru.
The settings on the client are:
Profile Name: VPN
Gateway: vpn.xorp.ru
Type: IKEv2 EAP (Login/Password)
Login: alice
Password: <hidden>
CA Certificate: Choose automatically
And here is the log.
> May 27 21:39:23 00[DMN] Starting IKE charon daemon (strongSwan 5.2.1dr1, Linux 3.4.5-CM-gb461bba, armv7l)
> May 27 21:39:23 00[KNL] kernel-netlink plugin might require CAP_NET_ADMIN capability
> May 27 21:39:23 00[LIB] loaded plugins: androidbridge charon android-log openssl fips-prf random nonce pubkey pkcs1 pkcs8 pem xcbc hmac socket-default kernel-netlink eap-identity eap-mschapv2 eap-md5 eap-gtc eap-tls
> May 27 21:39:23 00[LIB] unable to load 9 plugin features (9 due to unmet dependencies)
> May 27 21:39:23 00[JOB] spawning 16 worker threads
> May 27 21:39:23 07[IKE] initiating IKE_SA android[3] to 185.48.56.74
> May 27 21:39:23 07[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
> May 27 21:39:23 07[NET] sending packet: from 192.168.1.237[42224] to 185.48.56.74[500] (996 bytes)
> May 27 21:39:23 11[NET] received packet: from 185.48.56.74[500] to 192.168.1.237[42224] (553 bytes)
> May 27 21:39:23 11[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
> May 27 21:39:24 11[IKE] local host is behind NAT, sending keep alives
> May 27 21:39:24 11[IKE] remote host is behind NAT
> May 27 21:39:24 11[IKE] received cert request for "C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root"
> May 27 21:39:24 11[IKE] received cert request for "C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Certification Authority"
> May 27 21:39:24 11[IKE] received 3 cert requests for an unknown ca
> May 27 21:39:24 11[IKE] sending cert request for "C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware"
> May 27 21:39:24 11[IKE] sending cert request for "C=US, O=GeoTrust Inc., CN=GeoTrust Global CA"
<many more "sending cert request" messages go here>
> May 27 21:39:24 11[IKE] sending cert request for "C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, E=pki@...ee"
> May 27 21:39:24 11[IKE] establishing CHILD_SA android
> May 27 21:39:24 11[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
> May 27 21:39:24 11[ENC] splitting IKE message with length of 3660 bytes into 3 fragments
> May 27 21:39:24 11[ENC] generating IKE_AUTH request 1 [ EF ]
> May 27 21:39:24 11[ENC] generating IKE_AUTH request 1 [ EF ]
> May 27 21:39:24 11[ENC] generating IKE_AUTH request 1 [ EF ]
> May 27 21:39:24 11[NET] sending packet: from 192.168.1.237[54739] to 185.48.56.74[4500] (1360 bytes)
> May 27 21:39:24 11[NET] sending packet: from 192.168.1.237[54739] to 185.48.56.74[4500] (1360 bytes)
> May 27 21:39:24 11[NET] sending packet: from 192.168.1.237[54739] to 185.48.56.74[4500] (1072 bytes)
> May 27 21:39:24 12[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (544 bytes)
> May 27 21:39:24 12[ENC] parsed IKE_AUTH response 1 [ EF ]
> May 27 21:39:24 12[ENC] received fragment #1 of 5, waiting for complete IKE message
> May 27 21:39:24 13[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (544 bytes)
> May 27 21:39:24 13[ENC] parsed IKE_AUTH response 1 [ EF ]
> May 27 21:39:24 13[ENC] received fragment #2 of 5, waiting for complete IKE message
> May 27 21:39:24 14[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (544 bytes)
> May 27 21:39:24 14[ENC] parsed IKE_AUTH response 1 [ EF ]
> May 27 21:39:24 14[ENC] received fragment #3 of 5, waiting for complete IKE message
> May 27 21:39:24 16[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (544 bytes)
> May 27 21:39:24 16[ENC] parsed IKE_AUTH response 1 [ EF ]
> May 27 21:39:24 16[ENC] received fragment #4 of 5, waiting for complete IKE message
> May 27 21:39:24 08[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (176 bytes)
> May 27 21:39:24 08[ENC] parsed IKE_AUTH response 1 [ EF ]
> May 27 21:39:24 08[ENC] received fragment #5 of 5, reassembling fragmented IKE message
> May 27 21:39:24 08[ENC] parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
> May 27 21:39:24 08[IKE] received end entity cert "OU=Domain Control Validated, OU=PositiveSSL, CN=vpn.armority.ru"
> May 27 21:39:24 08[IKE] received issuer cert "C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Domain Validation Secure Server CA"
> May 27 21:39:24 08[CFG] using certificate "OU=Domain Control Validated, OU=PositiveSSL, CN=vpn.armority.ru"
> May 27 21:39:24 08[CFG] using untrusted intermediate certificate "C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Domain Validation Secure Server CA"
> May 27 21:39:24 08[CFG] using trusted ca certificate "C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Certification Authority"
> May 27 21:39:24 08[CFG] reached self-signed root ca with a path length of 1
> May 27 21:39:24 08[IKE] authentication of 'vpn.armority.ru' with ECDSA-256 signature successful
Wait... we are supposed to connect to vpn.xorp.ru!
> May 27 21:39:24 08[IKE] server requested EAP_IDENTITY (id 0x00), sending 'alice'
Oops... the server admin now knows a valid login at vpn.xorp.ru.
> May 27 21:39:24 08[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
> May 27 21:39:24 08[NET] sending packet: from 192.168.1.237[54739] to 185.48.56.74[4500] (76 bytes)
> May 27 21:39:24 09[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (108 bytes)
> May 27 21:39:24 09[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
> May 27 21:39:24 09[IKE] server requested EAP_MSCHAPV2 authentication (id 0xAD)
> May 27 21:39:24 09[ENC] generating IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
> May 27 21:39:24 09[NET] sending packet: from 192.168.1.237[54739] to 185.48.56.74[4500] (140 bytes)
Now he has an authentication value and can mount an offline dictionary
attack. I don't know if he could offer something worse than EAP_MSCHAPv2
here for easier password cracking, or maybe convince the client to
reveal a plaintext password.
> May 27 21:39:25 10[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (140 bytes)
> May 27 21:39:25 10[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
> May 27 21:39:25 10[IKE] EAP-MS-CHAPv2 succeeded: 'Welcome2strongSwan'
> May 27 21:39:25 10[ENC] generating IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
> May 27 21:39:25 10[NET] sending packet: from 192.168.1.237[54739] to 185.48.56.74[4500] (76 bytes)
> May 27 21:39:25 07[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (76 bytes)
> May 27 21:39:25 07[ENC] parsed IKE_AUTH response 4 [ EAP/SUCC ]
> May 27 21:39:25 07[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
> May 27 21:39:25 07[IKE] authentication of 'alice' (myself) with EAP
> May 27 21:39:25 07[ENC] generating IKE_AUTH request 5 [ AUTH ]
> May 27 21:39:25 07[NET] sending packet: from 192.168.1.237[54739] to 185.48.56.74[4500] (92 bytes)
> May 27 21:39:25 11[NET] received packet: from 185.48.56.74[4500] to 192.168.1.237[54739] (236 bytes)
> May 27 21:39:25 11[ENC] parsed IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(NO_ADD_ADDR) ]
> May 27 21:39:25 11[IKE] authentication of 'vpn.armority.ru' with EAP successful
> May 27 21:39:25 11[CFG] constraint check failed: identity 'vpn.xorp.ru' required
Dear StrongSwan VPN client, you were supposed to notice this hostname
mismatch earlier.
> May 27 21:39:25 11[CFG] selected peer config 'android' inacceptable: constraint checking failed
> May 27 21:39:25 11[CFG] no alternative config found
> May 27 21:39:25 11[ENC] generating INFORMATIONAL request 6 [ N(AUTH_FAILED) ]
> May 27 21:39:25 11[NET] sending packet: from 192.168.1.237[54739] to 185.48.56.74[4500] (76 bytes)
--
Alexander E. Patrakov
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
