Dozens of Popular iOS Apps Vulnerable To Intercept of TLS-Protected Data (arstechnica.com) 53
Researchers at Sudo Security Group Inc. discovered seventy-six popular applications in Apple's iOS App Store that had implemented encrypted communications with their back-end services in such a way that user information could be intercepted by a man-in-the-middle attack. According to Ars Technica, the applications could be fooled by a forged certificate sent back by a proxy, allowing their Transport Layer Security to be unencrypted and examined as it is passed over the internet. From their report: The discovery was initially the result of bulk analysis done by Sudo's verify.ly, a service that performs bulk static analysis of application binaries from Apple's App Store. Will Strafach, president of Sudo, verified the applications discovered by the system were vulnerable in the lab, using a network proxy configured with its own Secure Socket Layer certificate. In the post about his findings being published today, Strafach wrote: "During the testing process, I was able to confirm 76 popular iOS applications allow a silent man-in-the-middle attack to be performed on connections which should be protected by TLS (HTTPS), allowing interception and/or manipulation of data in motion. According to Apptopia estimates, there has been a combined total of more than 18,000,000 (Eighteen Million) downloads of app versions which are confirmed to be affected by this vulnerability."
The data exposed by the vulnerability in each of the applications varied in sensitivity. For just less than half -- 33 of the applications -- the risk was relatively low, as most of the data was "partially sensitive analytics data," Strafach said. These apps included a number of third-party "uploader" apps for Snapchat (which exposed Snapchat usernames and passwords) and the Vice News app, among others. In 24 cases, the exposed data included login credentials or session tokens that would allow an attacker to hijack the account associated with the application, though those accounts were not tied to highly sensitive data. However, the remaining 19 applications left sensitive data exposed to attack. In these cases, Strafach "confirmed ability to intercept financial or medical service login credentials and/or session authentication tokens for logged in users."
The data exposed by the vulnerability in each of the applications varied in sensitivity. For just less than half -- 33 of the applications -- the risk was relatively low, as most of the data was "partially sensitive analytics data," Strafach said. These apps included a number of third-party "uploader" apps for Snapchat (which exposed Snapchat usernames and passwords) and the Vice News app, among others. In 24 cases, the exposed data included login credentials or session tokens that would allow an attacker to hijack the account associated with the application, though those accounts were not tied to highly sensitive data. However, the remaining 19 applications left sensitive data exposed to attack. In these cases, Strafach "confirmed ability to intercept financial or medical service login credentials and/or session authentication tokens for logged in users."
Re: As an app developer... (Score:5, Informative)
Re: As an app developer... (Score:4, Insightful)
Re: (Score:2)
connecting to user-owned devices with self signed certs
Now that Let's Encrypt exists, why are "user-owned devices" even using "self signed certs" anyway, as opposed to buying a domain and using an ACME client to obtain a certificate that's trusted by default? Though the Certbot client requires a device to run a web server reachable from the Internet because it uses the HTTP challenge, the Dehydrated client also supports the DNS challenge, which requires only the domain's DNS server to be reachable.
The only case I can see where LE wouldn't work is Sandstorm, whi
Re: (Score:2)
Because that requires me to trust an external agency. Anytime you trust an external agency you introduce some element of risk, however small.
Establish your own CA and issue internal certificate for devices that you don't expose to the Internet. Trust the CA internally.
Re: (Score:2)
Establish your own CA and issue internal certificate for devices that you don't expose to the Internet. Trust the CA internally.
How well does that work for friends and family who bring their own devices to view documents, photos, and videos that you're sharing through a NAS on your home LAN?
Re: (Score:2)
Really well, your friends/family tell their client to trust your CA by installing the root certificate you provide and boom you are good to go.
Sure you need to paranoid to the extreme to establish a CA for use on your home network but then self-signed certificate on a home network shouldn't really be an issue either. Again with a self-signed certificate on your home LAN you don't need to trust an outside agency at all. Trusting a self-signed certificate the first time you encounter it is no more dangerous
Re: (Score:2)
>Sure you need to paranoid to the extreme to establish a CA for use on your home network
Not really. Just
A) Know how to do it (Not a problem, I've coded and set up real CAs in my job)
B) Be happy to not pay outrageous fees for certs from a commercial CA.
C) Have a use case where it makes sense.
Re: (Score:2)
Trusting a self-signed certificate the first time you encounter it is no more dangerous than trusting a signature the first time you SSH into a device.
Prudent users of a shell account verify the server's key fingerprint out of band, such as by inspecting it manually (if physical access is available) or on the hosting provider's control panel (which in turn is secured by a TLS certificate from a well-known CA). The same is possible for a TLS certificate from an internal CA, provided you control all devices that shall access the server. But visitors to your home are unlikely to take the same care.
Re: (Score:2)
Really well, your friends/family tell their client to trust your CA by installing the root certificate you provide and boom you are good to go.
Good luck explaining how to download and install your home CA's root certificate to all visitors, particularly across six different operating systems (macOS, Windows 7, Windows 10, X11/Linux, iOS, Windows Phone/Windows 10 Mobile, Android) plus web browsers that have their own certificate stores instead of using that of the operating system (such as Firefox).
Re: As an app developer... (Score:4, Interesting)
Yes, but then the story is going to be "76 apps vulnerable to SSL interception if running jailbreakable versions of iOS", because the attacker can trick the user into jailbreaking their device, installing SSLKillSwitch https://github.com/iSECPartner... [github.com] before tricking them into installing and trusting a new cert. I find this scenario about as likely as the "install a fake cert and trust it, then please re-direct all your traffic to my nice little mitm proxy" scenario.
Re: (Score:2)
Via ADB one can use a custom hosts file on a droid that's rooted, easily (Apple devs get "GodMode" rooted phones they SSH into to alter hosts, you don't & yes, jail breaking is possible (iirc, go up > 1024 folders & it's useless)).
What's Apple Desktop Bus got to do with this?
And oh, look! ANOTHER Unverifiable, specious Apple-Hating comment from yet ANOTHER Anonymous Coward!
Amazing!
Initialisms with more than one meaning (Score:2)
Android Debugging Bridge [...] Via ADB one can use a custom hosts file
What's Apple Desktop Bus got to do with this?
Nothing, which is why he spelled it out. What's next, a claim that the fellow's initials can only stand for Android Package?
Re: (Score:2)
Android Debugging Bridge [...] Via ADB one can use a custom hosts file
What's Apple Desktop Bus got to do with this?
Nothing, which is why he spelled it out. What's next, a claim that the fellow's initials can only stand for Android Package?
It was a joke, son... ;-)
Re: (Score:2)
>What's Apple Desktop Bus got to do with this?
That's what my brain parses ADB to every time.
It must be a function of age.
Re: (Score:2)
>What's Apple Desktop Bus got to do with this?
That's what my brain parses ADB to every time.
It must be a function of age.
Glad I'm not the only one... ;-)
Re: (Score:3)
So only 76 third party applications use HTTPS on iOS? I don't think so. Rather, I think the blame lies with developers using self signed certs on their test servers, and tweaking the SSL options in their app so that works for them.
To be fair, TFS did sort of lay the blame where it belonged. But it sure as HELL didn't make a point of it.
Re: (Score:2)
I'm fairly certain of it. Just a couple of days ago, I was helping somebody out on Stack Overflow who couldn't get self-signed certs to work. I posted a full code snippet that did proper validation before accepting the provided cert, and the person asking the question then asked if a different snippet would work that didn't check a
Re: (Score:2)
It's not entirely the app developers' fault. They're not bypassing the PKI wank just out of spite, they're doing it because after having spent hours, possibly days, beating their heads against the wall of PKI they've given up and just want their app to work. The same occurs on an even larger scale in Android, with endless NullTrustFactories and equivalent created out of frustration by developers who just want the damn thing to work without requiring a PhD in computer security as a prerequisite.
So there'd
Re: (Score:2)
Probably 98% of the people trying to do these hacks are trying to use self-signed certs for testing purposes and then accidentally leave it in there. Adding letsencrypt support as a UI configuration setting in OS X Server would go a long way towards eliminating this problem, at least of iOS developers.
For the remaining 2%—the people who need to do something particularly unusual involving devices generating their own certs—the problem is caused by iOS lacking the same UI that OS X has for allow
Re: (Score:2)
We wanted to verify that the certificate we get from our service is issued by the CA we actually get our certificate from (sometimes called certificate pinning), but Apple only allows this for their own apps. Us third-party, second-class developers have to trust whatever bogus certificate comes over the network. Blame Apple.
Another Apple Hater comment, from a (wait for it) Anonymous Coward.
There is nearly a 100% correlation between the two. Wonder why...?
Re: (Score:2)
We wanted to verify that the certificate we get from our service is issued by the CA we actually get our certificate from (sometimes called certificate pinning), but Apple only allows this for their own apps. Us third-party, second-class developers have to trust whatever bogus certificate comes over the network. Blame Apple.
Is it just me, or is this the PKI version of "the dog ate my homework", and about as credible? Apple puts a gun to your head and forces you to accept any arbitrary cert that turns up?
Whats the fix? (Score:3)
A totally new network to Apple, the user and back to the app server/services?
Make apps buy any trusted certificate they want and then be required use it?
Anyone have any news on the cellular interception side in the wild? Thanks.
Can a desktop computer do better? Has this all been fixed on most desktop OS?
Re: Whats the fix? (Score:1)
Re: Whats the fix? (Score:1)
Or any network with terms of service or employment that authorize monitoring of network traffic.
Re: (Score:3)
Can a desktop computer do better? Has this all been fixed on most desktop OS?
The article is sparse on details, but yes it sounds like an issue with not validating the certificate. From reading it looks like the apps are just connecting and accepting whatever certificate is presented.
Assuming that's the case, the MitM takes place because the app doesn't verify the entire chain of trust back to the CA. The operation of going back through each link in the chain can take a (relatively) long time across a network, and can be quite slow on mobile networks. It may have been an intentiona
Only recently has DNSSEC moved on from 1024 bits (Score:2)
I thought the security of DANE relied on that of DNSSEC, and the security of DNSSEC was limited by the 1024-bit RSA zone signing key on the root zone until October of last year [verisign.com]. The deprecation of 1024-bit RSA is why, for example, web browser publishers haven't added support for DANE.
Re: (Score:2)
The deprecation of 1024-bit RSA is why, for example, web browser publishers haven't added support for DANE.
Trust me, that's about the least of the reasons why browsers are ignoring DANE.
Re: (Score:2)
They should use something like DANE to prevent man the middle
We've already spent thirty years waiting for PKI to start working, why should we now wait another thirty for DNSSEC and DANE to magically solve all our problems?
who cares? (Score:4, Interesting)
So the attack is this then:
1) Find user with non-certpinning app installed
2) Trick user into installing a cert
3) Trick the user into trusting the newly installed cert
4) Modify the network settings on the users device to re-direct traffic via mitm proxy, or attack network such that traffic is re-directed via mitm proxy.
5) How is this a story worth posting?
I have no problems using apps without certpinning, any successfully attack requires, at the very least, two stupid decisions on part of the user.
Also, not using certpinning != vulnerability.
Re:who cares? (Score:4, Funny)
Because it's a excuse to talk shit about Apple, that's why it's Slashdot News worthy.
Re: (Score:2)
Because it's a excuse to talk shit about Apple, that's why it's Slashdot News worthy.
EXACTLY!
Re: who cares? (Score:2, Interesting)
The issue is not about cert pinning. This is about no TLS validation occurring, the apps use TLS to ensure ATS stays happy but you can use even a fresh self-signed certificate to perform the intercept.
Re: (Score:2)
I thought "a legit CA cert" could be issued only for a hostname within a purchased domain, not within an internal TLD such as .local or .internal or for an IP reserved for private use (10/8, 172.16/12, or 192.168/16). How do you test before you buy a domain for production?
Re: (Score:2)
Establish your own CA on the internal TLD, trust your own CA on the test network and use certificates issued by that CA for testing. Eliminates self-signed certificates.
Re: (Score:2)
Because it'd be redundant. Windows Phone (excuse me, Windows 10 Mobile) is already trashed.
Re: (Score:2)
Sucks to be a faggat or a hispter.
WOW!
TWO Spelling errors in EIGHT words! That has to be some kind of record!
Well done, you illiterate, homophobic, luddite moron!
Incorrect spelling is for luddites (Score:2)
Does this luddite need an appboard app to app his spelling?
Are you sure about that? (Score:1)
Are you sure about that? You can definitely pin certificates in iOS. The trustkit library provides an implementation, for example.
poÅYet baskı [baskiliposetmerkezi.com]
Re: (Score:2)
Are you sure about that? You can definitely pin certificates in iOS. The trustkit library provides an implementation, for example. [baskiliposetmerkezi.com]
You're expecting me to download security advice from a site called basiliskpostmerkelnazi.com? Why not link to this site [virusbucket.ru] instead?