Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Slashdot Deals: Prep for the CompTIA A+ certification exam. Save 95% on the CompTIA IT Certification Bundle ×

Submission + - Duo Security iOS App Vulnerability

dajjhman writes: Duo Security put out a PSA today informing users that their iOS application has not been checking the validity of SSL certificate domain names.
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 security@duosecurity.com PGP key which is available from their security contact page.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Duo Product Security Advisory
=============================

Advisory ID: DUO-PSA-2015-002
Publication Date: 2015-04-06
Revision Date: 2015-04-13
Status: Fixed
Document Revision: 2

Overview
========

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.

Description
===========

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.

Impact
======

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.

Affected Product(s)
===================

* Duo Mobile for iOS, versions 3.4 — 3.7

Solution
========

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 Metrics
=====================

Vulnerability Class: Improper Certificate Validation (CWE-295)
Remotely Exploitable: Yes
Authentication Required: No
Severity: High
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)

References
==========

* 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...

Timeline
========

2015-04-02
* 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.

2015-04-03
* Duo Mobile for iOS version 3.7.1 is approved by Apple

2015-04-06
* 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.

2015-04-13
* Duo updates advisory and shares it with all remaining customers.

Credits/Contact
===============

Technical questions regarding this issue should be sent to support@duosecurity.com and reference "DUO-PSA-2015-002" in the subject.

Other feedback regarding this issue can be sent to security@duosecurity.com.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJVJD/IAAoJEEcOFkS+z+1x0q4QAIsyyybXIUV5/kui63aSzPrY
AT1GcSK0WGQzaH2T8gSBwMZl7QUPBJQERLm65F7hFXzDgzbFUrb9rnMvMPOdqYFK
mc0EIfwsoWH8M02JfHZvS476Yi56MAvY+DEOtVI/z23481ScT+fK5AyHvAyjfb2M
NFJJGjTfF6JOTdufY3D22RpCbpK68ITL8wVS+eCC9CR2xf6MlgITBRqdzyo3Qc34
1nRxnRc7xqPnkjSrtcT/lf8D5Q7j/yNv0qryRokY9neYxrogLXqqIkP/JhdhzFvH
DN8TPOMrRDfEPCdUDAdWBaGY0+gpVBIV+2gBzG+8/d+fEh5inTiEkBmjE11M722W
X3JGorP7DJ9TNoQM+TP1Y/r7khr/X5trk/X6RDeDKVLEaCx9KPTr7tSzy83/F2MI
c+kUwEsnrhxNPuLGWb38Exb0DQ7SmQJ6xvTx6EFcBcQDssDvfKPc6tIADSvMqw3t
ZxXkcqXJncq+M6Cvyxm+A6kb0FBcUAbmdyL6lhBhUTIimhg+i4QLBqkO42RaHogn
nY9WQhVZYAKCdGXcteSlez/2HFtE9+OoP23NK1UK+OoHJjCVg/qBKuBwyzY1JA2y
lBz1VGdWIVNqD3bEdHNLSnSa0hqXJ/mLgffogK/hj4COSI0f5CZaiSaZwCgpMPC+
kP6aGmqdITXzdgag6VHy
=16Yr
-----END PGP SIGNATURE-----

Submission + - Duo Security iOS App Vulnerability

dajjhman writes: Duo Security put out a PSA today informing users that their iOS application has not been checking the validity of SSL certificate domain names.
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 security@duosecurity.com PGP key, available from their website's security contact page.
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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Duo Product Security Advisory
=============================

Advisory ID: DUO-PSA-2015-002
Publication Date: 2015-04-06
Revision Date: 2015-04-13
Status: Fixed
Document Revision: 2

Overview
========

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.

Description
===========

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.

Impact
======

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.

Affected Product(s)
===================

* Duo Mobile for iOS, versions 3.4 — 3.7

Solution
========

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 Metrics
=====================

Vulnerability Class: Improper Certificate Validation (CWE-295)
Remotely Exploitable: Yes
Authentication Required: No
Severity: High
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)

References
==========

* 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...

Timeline
========

2015-04-02
* 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.

2015-04-03
* Duo Mobile for iOS version 3.7.1 is approved by Apple

2015-04-06
* 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.

2015-04-13
* Duo updates advisory and shares it with all remaining customers.

Credits/Contact
===============

Technical questions regarding this issue should be sent to support@duosecurity.com and reference "DUO-PSA-2015-002" in the subject.

Other feedback regarding this issue can be sent to security@duosecurity.com.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJVJD/IAAoJEEcOFkS+z+1x0q4QAIsyyybXIUV5/kui63aSzPrY
AT1GcSK0WGQzaH2T8gSBwMZl7QUPBJQERLm65F7hFXzDgzbFUrb9rnMvMPOdqYFK
mc0EIfwsoWH8M02JfHZvS476Yi56MAvY+DEOtVI/z23481ScT+fK5AyHvAyjfb2M
NFJJGjTfF6JOTdufY3D22RpCbpK68ITL8wVS+eCC9CR2xf6MlgITBRqdzyo3Qc34
1nRxnRc7xqPnkjSrtcT/lf8D5Q7j/yNv0qryRokY9neYxrogLXqqIkP/JhdhzFvH
DN8TPOMrRDfEPCdUDAdWBaGY0+gpVBIV+2gBzG+8/d+fEh5inTiEkBmjE11M722W
X3JGorP7DJ9TNoQM+TP1Y/r7khr/X5trk/X6RDeDKVLEaCx9KPTr7tSzy83/F2MI
c+kUwEsnrhxNPuLGWb38Exb0DQ7SmQJ6xvTx6EFcBcQDssDvfKPc6tIADSvMqw3t
ZxXkcqXJncq+M6Cvyxm+A6kb0FBcUAbmdyL6lhBhUTIimhg+i4QLBqkO42RaHogn
nY9WQhVZYAKCdGXcteSlez/2HFtE9+OoP23NK1UK+OoHJjCVg/qBKuBwyzY1JA2y
lBz1VGdWIVNqD3bEdHNLSnSa0hqXJ/mLgffogK/hj4COSI0f5CZaiSaZwCgpMPC+
kP6aGmqdITXzdgag6VHy
=16Yr
-----END PGP SIGNATURE-----

Comment Re:No issue here, Read the Patent! (Score 1) 333

The IBM systems have policies for managing shared resources and files yes, but for an entire file or resource. The Google patent is specifically for handling the individual chunks of a distributed file. ex) a user has their profile stored in a file, let's call it user.xml. Each individual user.xml file is comprised of chunks (like , , , etc). let's say that the portion of the file gets updated more often than the portion. Rather than setting a policy for the entire file to have a shorter TTL in cache, you set only the TTL of the block to be very short while having a longer TTL for the chunk. I've yet to find a reference to an IBM system doing this on such a low level. If anyone can share a link to prove otherwise please do.

Comment Re:No issue here, Read the Patent! (Score 1) 333

After doing a quick reading up on Sysplex and the 360 systems, they seem to have managing shared temporary resources down but I can't find any reference to handling multiple chunks of distributed data per file being handled differently. Is there a more detailed resource I can find online? I am rather interested in looking deeper into it. Most reference I can find regarding their management of multiple systems is access to shared resources, not handling of individual distributed chunks of a file rather than the file as a whole. As for zOS it looks like a distributed file system, but again need more information to see how it handles the individual chunks of data rather than the files as a whole. The clarification is that the Google patent is for deletion of chunks of a file, such as a user profile, rather than the file as a whole.

Comment No issue here, Read the Patent! (Score 5, Informative) 333

If you actually read the patent, it is specifically for a similar method, but designed for Distributed File Systems. This is different from just a single file being names a certain way. It is an algorithm based on the location of other related files, each different file's modified and Time to Live (TTL) dates, and the factors determined by the, keywords here, plurality of servers. If they tried to patent a regular temporary file that would be different, but this is a distributed system specifically for a file that is distributed in different parts on different systems. If you still think this has been done before, I would love to see the source for that information and gladly would recant myself given that.

Comment mis-information (Score 1) 269

slashdot excerpt states it sends the developer the user's address, when the article states it only sends the "suburb" (or ZIP code for us in the US and such). I see no problem with this, it's no more than basic demographics information and email/name for customers of all digital goods. Digital purchases have always had information like this sent to the party who manages Support/Problems. This is not like going into a grocery store and buying ketchup. If that ketchup bottle was already opened/expired, you complain to the store and get a new one without involving the manufacturer. If an Android app doesn't work, you don't complain to Google, you complain to the developer. If they gave the developer an actual address to your front door, that would be different. But ZIP codes and suburbs have been standard information in demographics for years (as a merchant using both in-person credit card transactions, and online transactions via other services, this is nothing new). Even my phone credit card processor gives basic information, and even can link it to their contact information in my phone if I ever shared correspondence.

Comment Re:How long does it take to get a cert? (Score 3, Insightful) 92

Actually, without SSL Man in the Middle Attacks are very problematic. As a security researcher, I can tell you that it is very easy to cause mayhem with http-based traffic for facebook. We'd launch a proxy on the network, and funnel traffic through it. With no security, we could, for example, change the destination and content of messages, and see everything.

Comment Re:Never trust security through obscurity (Score 1) 133

your second reply never made it to my feed, allow me to clarify my first reply having seen this one now: If the program is implemented wrong, and they are banking on people having the impression it is fully secure without having actually analyzed the system, then it is security through obscurity. Now, if they had opened it up to auditors and this implementation was genuinely missed, it would have simply been an implementation error.

Comment Re:Never trust security through obscurity (Score 1) 133

Full specifications are available. There is no security through obscurity here.

Actually, it is obscurity. The specification you linked to was NOT followed by the device manufacturer, they just assumed since they didn't tell anyone they violated a proper practice that no one would notice. The specifications listed by you requires devices to adhere to the random number generating requirements outlined in ISO 18031, which the machines did not. This standard mandates a unpredictable entropy source be used as the seed for any random number generating function. The devices were implementing the use of date and time as a seed. This is what a lot of kids are taught in school for computer class, but any cryptographer is supposed to avoid.

Comment Never trust security through obscurity (Score 4, Informative) 133

Lots of these systems use proprietary protocols and have pushed out 3rd party verification by researchers. the random number being generated by time? Any serious security auditor would have caught that if the banks allowed them in, one of the golden rules of cryptography is to have a proper random number generator. The contact-less systems in the US came under similar fire this past year, after years of assurances by card issuers that it couldn't happen. http://www.forbes.com/sites/andygreenberg/2012/01/30/hackers-demo-shows-how-easily-credit-cards-can-be-read-through-clothes-and-wallets/

Comment Re:Use caution with any and all data (Score 2) 320

forgot to add these notes: install an anti-virus that does boot-time scans, like Avast. It will put itself BEFORE the bootloader for Windows, ergo scan files before they could be loaded into memory and hide themselves easier. Of course, if the AV gets compromised it wouldn't help, but keeping it updated should make it much less likely. A FULLY patched Windows 7 machine is a tough freaking nut to crack (coming again from that experience with the DoD in the above post). Of course, get one update behind and it can be devastating. It is not likely that some ordinary scammers will have serious 0day exploits. But then you're in God's hands if that happens. Also regular backups help, but I know that can be difficult with non-technical people. If he's willing, get him an external drive for backups and tell him to just plug it in at a scheduled time (like saturday mornings?) and to unplug it at the end of the day. Unless it gets infected while the backup drive is attached, could help save a lot of trouble. The Win7 backup feature is pretty good. Not the best, but good. Last item: I realize I've been talking about Win7 a lot, but the same applies to pretty much all OSs. However, if he is on XP then I'd get him off of it, as it has reached end of life support for consumers unless they purchased an extended contract with microsoft (which I don't even know if they sell to non-businesses). NOTE: the above post is mine, I wasn't thinking to log in when I made it as it is early morning here and I need some coffee. It was supposed to be a day off from this kind of stuff haha

Comment As a web business owner, I hereby sever GoDaddy (Score 2) 353

I have hung onto GoDaddy because of how cheap they are, and that I've so far never had a problem. But this just goes too far for a mediocre service. The service works, and is cheap, but I'd rather pay more for a better service, even if I don't need it, than support them anymore. As soon as the holidays are over, I am moving over EVERYTHING from them. I also will no longer advise any of my clients from using them (though they were never really "recommended" except for how cheap things can be with them thanks to promos).

When the bosses talk about improving productivity, they are never talking about themselves.

Working...