lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <DB5PR0401MB192650B419078EF7577DD6A8F48B0@DB5PR0401MB1926.eurprd04.prod.outlook.com>
Date: Thu, 17 Mar 2016 12:16:21 +0000
From: Georg Lukas <lukas@...solutions.de>
To: "'bugtraq@...urityfocus.com'" <bugtraq@...urityfocus.com>
Subject: CVE-2016-1519: GrandStream Android VoIP App TLS MitM Vulnerability

CVE-2016-1519: GrandStream Android VoIP App TLS MitM Vulnerability
==================================================================

Affected app: [Grandstream Wave][GSWAVE] version 1.0.1.26 (and probably
earlier)

Classification: [CWE-295 Improper Certificate Validation][CWE295]

## Summary

The Grandstream VoIP products deploy a remote provisioning mechanism that
allows to automatically set configuration elements on app startup. By
default, an insecure connection to `fm.grandstream.com` is used to obtain
the
provisioning profile ([CVE-2016-1518][CVE-2016-1518]). However, even if an
HTTPS URL is
configured, the certificate is not validated, allowing an active attacker to
successfully impersonate the provisioning server with an invalid,
mismatching
or outdated certificate. Based on that, the attacker can elevate
[CVE-2016-1518][CVE-2016-1518]
to redirect phone calls through a malicious server, or turn the phone into a
bug. The changes are stored locally, so a single successful
attack is sufficient to gain permanent control of the app.

## Details

When accessing HTTP/HTTPS URLs, the Grandstream Wave app is using a custom
HTTP connection manager in the `com.softphone.common` package. That class is
deploying both a custom [TrustManager][TM] and a custom
[HostnameVerifier][HV]
(the depicted variable and class names have been changed as part of the
deobfuscation):

	private static TrustManager[] tm = new TrustManager[]{ new TM(null)
};
	private static HostnameVerifier hv = new HV();

	...

	SSLContext sc = SSLContext.getInstance("SSL");
	sc.init(null, tm, new SecureRandom());
	
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
	HttpsURLConnection.setDefaultHostnameVerifier(hv);

The custom TrustManager skips all verification, essentially accepting any
certificate for any connection:

	class TM implements X509TrustManager {
		public void checkClientTrusted(X509Certificate[] c, String
at) {}
		public void checkServerTrusted(X509Certificate[] c, String
at) {}
		public X509Certificate[] getAcceptedIssuers() {
			return new X509Certificate[0];
		}
	}

The custom HostnameVerifier does not verify if the server certificate
corresponds to the hostname the connection was made to, allowing to present
the client with a certificate issued for a different hostname:

	class HV implements HostnameVerifier {
		public boolean verify(String hostname, SSLSession session) {
			/* skipped log output */
			return true;
		}
	}

Each of these two issues individually allow an active MitM attacker (e.g. in
a
public WiFi network) to hijack the connection, either by presenting a
self-signed certificate or by presenting a valid certificate issued to an
attacker-controlled domain.

## Impact

Even if the app is configured to use HTTPS for the provisioning server, an
active attacker can trick it into obtaining a provisioning file from an
attacker-controlled sserver, and thus to leverage
[CVE-2016-1518][CVE-2016-1518]:

 * Adding or replacing VoIP accounts / servers
 * Turning the phone into a bug by setting a "silent" ringtone and enabling
auto-answer
 * Changing the Config Server Path URL to a server controlled by the
attacker,
   allowing to push new configuration after the initial Man-in-the-Middle
attack

## Mitigation

On the Wave app, the only way to close the issue is by disabling remote
provisioning. This can be achieved by entering an empty URL:

1. Open "GSWave"
2. Switch to the "Settings" tab
3. Open "Advanced Settings" menu
4. Set "Config Server Path" to an empty string

After disabling / securing the auto-provisioning, **all configuration
elements** should be checked for prior manipulation, e.g. by exporting and
inspecting the configuration file.

## Timeline

 * 2015-11-24 Discovery of the issue
 * 2015-11-25 Requested CVE number
 * 2015-12-01 Notification of vendor
 * 2016-01-20 CVE number assigned
 * 2016-03-16 Public disclosure

## Contact

Please contact Dr. Georg Lukas with any further questions regarding this
vulnerability.

PDF version:
http://rt-solutions.de/images/PDFs/Veroeffentlichungen/CVE-2016-1519-gswave-
tls-mitm.pdf
[CVE-2016-1518]:
http://rt-solutions.de/images/PDFs/Veroeffentlichungen/CVE-2016-1518-insecur
e-provisioning.pdf
[GSWAVE]: https://play.google.com/store/apps/details?id=com.softphone
[TM]:
http://developer.android.com/reference/javax/net/ssl/X509TrustManager.html
[HV]:
http://developer.android.com/reference/javax/net/ssl/HostnameVerifier.html
[CWE295]: https://cwe.mitre.org/data/definitions/295.html

-- 
Dr.-Ing. Georg Lukas
rt-solutions.de GmbH
Oberländer Ufer 190a
D-50968 Köln

Tel. : (+49)221 93724 16
Fax : (+49)221 93724 50
Mobil: (+49)179 4176591
Web : www.rt-solutions.de
rt-solutions.de
experts you can trust.

Sitz der Gesellschaft: Köln
Eingetragen beim Amtsgericht Köln: HRB 52645
Geschäftsführer: Prof. Dr. Ralf Schumann, Dr. Stefan Schemmer



Download attachment "smime.p7s" of type "application/pkcs7-signature" (4809 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ