Slashdot Mirror


Dozens of Popular iOS Apps Vulnerable To Intercept of TLS-Protected Data (arstechnica.com)

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

53 comments

  1. As an app developer... by Anonymous Coward · · Score: 0

    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.

    1. Re: As an app developer... by Marcpek · · Score: 5, Informative

      Are you sure about that? You can definitely pin certificates in iOS. The trustkit library provides an implementation, for example.

    2. Re: As an app developer... by JaredOfEuropa · · Score: 3, Insightful

      In addition it is fairly easy to implement pinning yourself. You can do this in case you don't want to include the certificate in the app bundle, or in cases where you don't know the certificate or even the issuing authority up front (like connecting to user-owned devices with self signed certs).

      --
      If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
    3. Re: As an app developer... by muffen · · Score: 3, Interesting

      Are you sure about that? You can definitely pin certificates in iOS. The trustkit library provides an implementation, for example.

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

    4. Re:As an app developer... by Anonymous Coward · · Score: 0

      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.

    5. Re:As an app developer... by Anonymous Coward · · Score: 0

      See my subject (speaking from myself only though I've family who controls iOS builds @ Apple): Like how Apple CLAIM iOS not having a tool for "the masses" (or devs that aren't apple's) like ADB for droid = 'security'!

      It's BS!

      Why?

      Via ADB one can do custom hosts files rooted droids (Apple devs get "GodMode" rooted phones they SSH into to alter hosts, you don't & yes, jailbreak's possible (iirc, go up > 1024 folders & it's useless)).

      Hosts = GOOD security (experts whom I have proven wrong on false positives on apps of mine agreed https://it.slashdot.org/comments.pl?sid=10205115&cid=53815959/ hosts = good security)

      * Truth hit a nerve (usually does):

      My original post was downmodded (/.'s shills downmod hide truth https://apple.slashdot.org/comments.pl?sid=10211743&cid=53817331/)

      APK

      P.S.=> They frame things from 1 "pov" only - limited weak one when TRUE objective is one Apple never wavers in 4 both software/hardware - CONTROL vs. competition, even small ware makers

    6. Re: As an app developer... by Anonymous Coward · · Score: 0

      Exactly, this is the issue.

    7. Re:As an app developer... by TheFakeTimCook · · Score: 1

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

    8. Re:As an app developer... by TheFakeTimCook · · Score: 2

      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.

    9. Re: As an app developer... by tepples · · Score: 1

      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, which requires a wildcard certificate because it uses a different subdomain for each user session. Using LE with Sandstorm would hit LE's rate limit very quickly.

    10. Re: As an app developer... by AF_Cheddar_Head · · Score: 1

      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.

    11. Re: As an app developer... by tepples · · Score: 1

      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?

    12. Re: As an app developer... by AF_Cheddar_Head · · Score: 1

      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 than trusting a signature the first time you SSH into a device. You initiate the connection to a known device.

    13. Re: As an app developer... by TechyImmigrant · · Score: 1

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

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    14. Re: As an app developer... by tepples · · Score: 1

      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.

    15. Re: As an app developer... by tepples · · Score: 1

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

    16. Re:As an app developer... by dgatwood · · Score: 1

      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.

      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 anything from the cert other than ensuring that the hostname matched. And I see that same defective code snippet over and over in people's comments, so I can only assume that somewhere on the Internet, somebody has posted that horrible travesty as an example of how to handle self-signed certificates.

      That's why I wrote documentation to explain how to do it correctly back when I worked at Apple. Unfortunately, Apple has not bothered to keep it up-to-date since then with relevant NSURLSession-based examples, but the concepts are still valid, and it should be straightforward enough for anyone who bothers to read the chapter in question to convert it to use NSURLSession. Instead, developers search the Internet for pre-written code snippets that are almost invariably wrong—usually in dangerous ways—and use them, resulting in this mess.

      So even though the developers should take some of the blame, Apple deserves a lot of the blame for not updating the NSURLSession Programming Guide with new Objective-C code based on the current API, not providing Swift versions of those snippets, etc. And Apple's efforts to make programming easier, along with the efforts of sites like Stack Overflow, also deserve some of the blame, because at some point, there needs to be a bar that says, "You must be this tall to ride the ride." Encouraging developers to not take the time to learn how to write software properly can only lead to software quality that gets progressively worse until the wheels fall off the bus.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    17. Re:As an app developer... by arglebargle_xiv · · Score: 1

      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?

    18. Re:As an app developer... by arglebargle_xiv · · Score: 1

      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 be a lot less of this if the tools that developers were given weren't such a massive pain to use. And by "tools" I don't mean slightly less godawful PKI, I mean alternative, far more effective and functional mechanisms that stay as far away from PKI as possible.

    19. Re:As an app developer... by dgatwood · · Score: 1

      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 allowing the user to trust a cert. OS X made it pretty easy to add trust. Unfortunately, iOS lacks that mechanism almost entirely, and requires cumbersome workarounds at the app level to get the functionality back.

      If that counts as "staying away from PKI", then yeah.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

  2. Whats the fix? by AHuxley · · Score: 2

    Something new and internal to iOS between the user and app seller?
    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?

    --
    Domestic spying is now "Benign Information Gathering"
    1. Re: Whats the fix? by Marcpek · · Score: 1

      This hack requires the victim to be connected to an usecure (or spoofed) wifi network (+ a vulnerable app).

    2. Re: Whats the fix? by Anonymous Coward · · Score: 1

      Or any network with terms of service or employment that authorize monitoring of network traffic.

    3. Re:Whats the fix? by Frobnicator · · Score: 2

      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 intentional choice to make things faster, or an accident of not validating it.

      Desktop computers and any other systems that implement the protocols can suffer from the same defect or design flaw, and it is quite likely that many desktop programs have the same issue.

      --
      //TODO: Think of witty sig statement
    4. Re:Whats the fix? by Anonymous Coward · · Score: 0

      Increase the price of the apps. Beyond that, do nothing.

  3. Not a good option by Anonymous Coward · · Score: 0

    They should use something like DANE to prevent man the middle

    https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

    I wish apple libraries supported this transparently it would solve a lot of MITM issues

    1. Re:Not a good option by arglebargle_xiv · · Score: 1

      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?

  4. who cares? by muffen · · Score: 3, Interesting

    76 apps missing cert pinning, how is that a story?
    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.

    1. Re:who cares? by Anonymous Coward · · Score: 4, Funny

      Because it's a excuse to talk shit about Apple, that's why it's Slashdot News worthy.

    2. Re: who cares? by Anonymous Coward · · 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.

    3. Re:who cares? by TheFakeTimCook · · Score: 1

      Because it's a excuse to talk shit about Apple, that's why it's Slashdot News worthy.

      EXACTLY!

  5. Re:Market competition control (that's Apple) by Anonymous Coward · · Score: 0

    I saw your post, as well as your subject. What utter incomprehensible nonsense. Have a nice day now.

  6. Probably stems from lazy dev environments by Anonymous Coward · · Score: 0

    It bugs me that at every place I've worked at, dev environments always use self signed certs.

    This may be OK for pure web stacks but not if you have your own clients like phone apps or IOT devices.

    Developers will immediately code for trusting any cert. If they are aware of the issue, they then add conditional code to check the environment and if it's not test then enable validation.

    So, you devops need to install proper certs in all environments.

     

    1. Re:Probably stems from lazy dev environments by Anonymous Coward · · Score: 0

      So, you devops need to install proper certs in all environments.

      Sorry, the company was only willing to spend $35,000 to hire a Full Stack Engineer. He's busy being the network admin, system admin, database admin, doing desktop support, and fixing printers in addition to developing the apps. 6 people's jobs for less than 1 person's salary - no time for security, we have the Bottom Line(TM) to consider. Welcome to Corporate America!

  7. arstechnica by Anonymous Coward · · Score: 0

    Why does arstechnica always publish articles trashing android, apple or linux, but never microsoft?

    1. Re:arstechnica by tepples · · Score: 1

      Because it'd be redundant. Windows Phone (excuse me, Windows 10 Mobile) is already trashed.

  8. I Don't by Anonymous Coward · · Score: 0

    I always test against a server that I've set up with a legit CA cert, and NEVER (even for testing) allow self-signed.

    It makes testing a bit more annoying; but only a bit.

    In fact, I'm working on an app right now that does this.

    1. Re:I Don't by tepples · · Score: 1

      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?

    2. Re:I Don't by AF_Cheddar_Head · · Score: 1

      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.

  9. Re:Market competition control (that's Apple) by TheFakeTimCook · · Score: 1

    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!

  10. Re:LOL by TheFakeTimCook · · Score: 1

    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!

  11. Only recently has DNSSEC moved on from 1024 bits by tepples · · Score: 1

    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. The deprecation of 1024-bit RSA is why, for example, web browser publishers haven't added support for DANE.

  12. Incorrect spelling is for luddites by tepples · · Score: 1

    Does this luddite need an appboard app to app his spelling?

  13. Initialisms with more than one meaning by tepples · · Score: 1

    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?

    1. Re:Initialisms with more than one meaning by TheFakeTimCook · · Score: 1

      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... ;-)

  14. Thanks again tepples... apk by Anonymous Coward · · Score: 0

    See my subject: The fool you replied to is some butthurt jackass sockpuppeteer/multiple acct user w/ 'assburger brain' who I've torn up before is all, obviously!

    * So he makes fake accounts/sockpuppets & trolls me all day long vs. doing anything constructive of worth...

    (I pity dolts like him - I truly honestly do - they're wasting their lives (but when their life IS a waste of time, oxygen & food? Perhaps I don't blame them but I DO blame them for letting it become that, trolling others spreading their own misery they project...))

    APK

    P.S.=> They do it to themselves... apk

  15. Re:Market competition control (that's Apple) by TechyImmigrant · · Score: 1

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

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  16. Are you sure about that? by Anonymous Coward · · 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ı

    1. Re:Are you sure about that? by arglebargle_xiv · · Score: 1

      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 instead?

  17. Re:Only recently has DNSSEC moved on from 1024 bit by arglebargle_xiv · · Score: 1

    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.

  18. Re:Market competition control (that's Apple) by TheFakeTimCook · · Score: 1

    >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... ;-)