Apple iCloud Credential Stealing

In August 2019 I found a vulnerability in Apples iOS (CVE-2020-3841) during a Red Team Assessment. We were trying to lure users into entering their credentials in a Wi-Fi Phishing Attack. In this case iOS/Safari (macOS was also affected) helped us with it's AutoFill features. It turned out to be somewhat buggy, but let's have a quick look how and why it worked, and how we exploited it.

The Captive Portal

A captive portal is often used, for example, to make you acknowledge free Wi-Fi terms and conditions. It usually pops up as soon as you join the wireless network. But that is only how it evolved - before it used to pop up, the portal was just shown on the first site you visit (or you were redirected to the portal IP).

This works via DNS redirect, HTTP redirect/interception layer 3 redirect (ICMP). In any case - as soon as you visited a website, you were redirected to the portal site/ip. This changed since the widespread deployment of TLS, in the case of a TLS-protected site, the browser will just (hopefully) abort the request and show a warning, because the handshake would fail.

That's why Microsoft, Google (Android/Chrome), Apple, Mozilla & Co. found a way to determine if you need to "Log-In" via a web-interface to that network. In the case of Apple for example, the iOS devices sends a HTTP Get request to http://captive.apple.com to verify if it retrieves the Text "Success".

In case of Firefox this URI is detectportal.firefox.com:

In both cases the browser knows that there isn't a captive portal. If something different is returned, the browser/OS knows that it need to visit that site because the traffic is clearly intercepted.

The problem

But here is the first problem: Those URIs must always be available via HTTP (unprotected) - or at least they are available. One can design this differently, but it is designed like that at the moment. And here comes the next problem: All major vendors use at least in some cases their Main-Domain:

• Google: clients3.google.com
• Apple: captive.apple.com
• Microsoft: teredo.ipv6.microsoft.com
• Firefox: detectportal.firefox.com

Why is that a problem? Well:

• It means that those corporation's cannot fully protect their domain with HSTS on Sub-domains because the captive portal detection won't work anymore
• All vendors automatically open the captive portal domain or IP to make it easier for the user - this also makes phishing easier.

At this point I want to recommend a blog post from Troy Hunt:

The Attack

We also noticed in the Red Team that while Apple & Co usually tries to open the IP, you can redirect from there to "captive.apple.com". Instead of "Success" we deliver our phishing portal on this domain, since it is not protected by HSTS.

The Confusion

And here we had another surprise: A domain confusion by Apple. While I do have "apple.com" credentials, some (most?) users do not have apple.com credentials, but icloud.com credentials. But guess what? Apple did a confusion, and even if you don't have "apple.com" credentials stored, Safari suggested credentials from "icloud.com"!

Investigating further, Safari seems in this case try to use credentials stored for "com.apple...." which is the classical Namespace convention.

iCloud credentials! Now we needed to optimize this - from a classical phishing with login to something more smooth - and Apple like ;-). So we designed a new Login-Page with a "Sign in with Apple" Button - and some hidden fields:

We put two hidden fields in it - not focused. As soon as a user clicks on "Sign in with Apple", the Username-Field gets focused - for a smoother experience ;-).

As soon as the user field gets the focus, Safari AutoFill jumps in and suggests your iCloud.com Credentials - how cool is that?

The next trick is rather easy: Once you clicked the Button (which is a Div actually) displays "Logging you in..". When the user now selects his credentials in the gray AutoFill Bar, the site automatically transmits the filled credentials.

The "pros" on this attack from attackers point of view:

• "Sign In" Web Frame open automatically
• Safari suggests to send the icloud Credentials
• You can send them to icloud.com and use NecroBrowser/Muarena to bypass 2-FA
• One-Click with FaceId, Two with TouchID
• Credentials are phished befor user hits enter
• Process seems "seamless" / "smooth"

The "cons":

• One/Two-Click
• In a Red Team you must(!) do a client-side filter on domain to not target people outside your scope!

Still, Apple thought this is "low risk" - or at least, it sounds much less exciting:

But they fixed it. Safari no longer suggests credentials in the captive-login frame that pops up. So what are the root causes?

• No HSTS on main domain possible with Subdomains due to captive... portal detection site
• Domain confusion with package identifier
• Show/suggest cerdentials for icloud.com in a autoamtically shown web frame for captive.apple.com

I am still researching other browsers and OS's in case I find the similar issues.