For those unfamiliar, Duo Security provides a 2 factor authentication system known for its implementation of push notifications to approve login requests. It is found in numerous applications, ranging from personal use to large enterprises
The vulnerability, identified as DUO-PSA-2015-002, allows attackers to use a Man in the Middle attack to see all of the network data. This was caused by a bug in a 3rd party library they used, and the announcement came along with an update to the App Store.
Duo says that due to the nature of their client-server communications, there was little risk an attacker could activate a push request as there is a client key. The PSA has not been posted to their blog at the time of this writing, but it is reproduced below.
The advisory is signed with the Duo Security PSIRT firstname.lastname@example.org PGP key which is available from their security contact page.
-----BEGIN PGP SIGNED MESSAGE-----
Duo Product Security Advisory
Advisory ID: DUO-PSA-2015-002
Publication Date: 2015-04-06
Revision Date: 2015-04-13
Document Revision: 2
Duo Security has identified an issue in recent versions of Duo Mobile for iOS that could allow attackers to perform a successful Man-in-the-Middle (MITM) attack against the app's TLS connections, if they can otherwise manipulate the network traffic exchanged between the mobile app and Duo's cloud service.
This issue has been fixed in Duo Mobile 3.7.1; all iOS users should update as soon as possible.
On the iOS platform, Duo Mobile leverages AFNetworking — a widely-used third-party HTTP client library — to communicate with Duo's cloud service. Recently, it was determined that AFNetworking did not validate digital certificates against server hostnames by default. As a result, Duo Mobile would e.g. consider a digital certificate for "www.example.com" as valid for "api-XXXXXXXX.duosecurity.com" when establishing a TLS tunnel.
This behavior makes it possible for an attacker to perform a successful Man-in-the-Middle (MITM) attack against TLS connections from affected versions of Duo Mobile, if he can otherwise manipulate the network traffic exchanged between the mobile app and Duo's cloud service. This might be a risk, for example, when using Duo Mobile while connected to untrusted wi-fi networks.
However, in addition to TLS, Duo Mobile uses application-level signatures to ensure the integrity and authenticity of requests sent from Duo Mobile to Duo's service. Becauses of this mechanism, a MITM attack would still not generally allow an attacker to e.g. approve a fraudulent Duo Push authentication request.
Note: A different vulnerability was introduced into AFNetworking in version 2.5.1, and recently gained widespread attention (http://blog.mindedsecurity.com/2015/03/ssl-mitm-attack-in-afnetworking-251-do.html). Duo Mobile currently uses AFNetworking version 2.3.1, and was therefore not affected by that particular vulnerability. This is a separate — if very similar — issue.
An attacker can perform a successful Man-in-the-Middle (MITM) attack against Duo Mobile's TLS connections if he can otherwise manipulate the network traffic exchanged between the mobile app and Duo's cloud service. Duo's application-level signing mechanism still generally prevents the attacker from e.g. approving fraudulent Duo Push authentication requests. However, there are some limitations to this technique:
* Duo Mobile cannot use application-level signatures when setting up a new account, because — at this point — the app has not yet negotiated a key-pair with Duo's service. If an attacker intercepted traffic from Duo Mobile during this process, he could gain the ability to generate valid one-time passcodes and exert full control over subsequent Duo Push authentication requests intended for the targeted device.
* Requests from Duo Mobile to Duo's service have application-level signatures, but responses from the service do not. It may therefore be feasible for an attacker to manipulate details of a fraudulent authentication request such that it appears legitimate, thereby tricking a user into approving it.
* Duo Mobile for iOS, versions 3.4 — 3.7
Duo Mobile 3.7.1 was published to the iTunes App Store on April 6, 2015. This version ensures that certificate domain-name validation is performed for all TLS connections.
Users should upgrade to this version immediately to prevent the issues described above. Note that administrators can audit their users' Duo Mobile app versions in the "phones" section of the Duo administrative interface.
As noted above, there is a small risk that users' Duo Mobile credentials could be compromised, if an attacker captured network traffic from Duo Mobile during account setup. After users have upgraded, administrators may choose to forcibly invalidate any existing credentials by re-activating users' Duo Mobile accounts in the administrative interface.
Vulnerability Class: Improper Certificate Validation (CWE-295)
Remotely Exploitable: Yes
Authentication Required: No
CVSSv2 Overall Score: 5.8
CVSSv2 Group Scores: Base: 6.8, Temporal: 5.9, Environmental: 5.8
CVSSv2 Vector: (AV:A/AC:L/Au:N/C:C/I:P/A:N/E:H/RL:OF/RC:C/CDP:MH/TD:M/CR:M/IR:H/AR:M)
* CWE-295: Improper Certificate Validation — https://cwe.mitre.org/data/def...
* AFNetworking issue #2619 — https://github.com/AFNetworkin...
* Heartbleed Defense-in-Depth Part #2: Don't Trust SSL — https://www.duosecurity.com/bl...
* Engineers at Duo internally discover that Duo Mobile for iOS does not correctly validate server certificates.
* Duo develops a fix and submits an updated Duo Mobile 3.7.1 to the iTunes App Store.
* Duo Mobile for iOS version 3.7.1 is approved by Apple
* Duo completes testing on Duo Mobile for iOS 3.7.1 and releases it to end users.
* Duo drafts advisory and shares it with affected Enterprise and Business customers.
* Duo updates advisory and shares it with all remaining customers.
Technical questions regarding this issue should be sent to email@example.com and reference "DUO-PSA-2015-002" in the subject.
Other feedback regarding this issue can be sent to firstname.lastname@example.org.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----