Breaking cryptographic trust in iOS and beyond

by Jerry Decime


What happened?

Mistakes were made in the implementation of proxy authentication. This in turn resulted in numerous vulnerabilities with the implementations of the "HTTP/1.0 407 Proxy Authentication Required" response to CONNECT requests across a broad range of operating systems, applications, and browsers for any device configured to use a proxy and even some that weren’t with auto-proxy support enabled by default in Windows.

In part one I’ll be covering the worst of these vulnerabilities impacting Apple, which until the release of the iOS 9.3.3 update manifested as a complete failure of HTTPS trust in iOS, all versions since at least iOS 5.1.1 for OS trust components, Safari, Opera, and applications utilizing WebKit when using proxies.

The FalseCONNECT vulnerability further extended to OS X, resulting in HTTPS trust failures when proxies were used with Safari and applications utilizing the WebKit engine including iTunes, and the AppStore. Like iOS this also impacted non-Apple solutions including Google Drive which rely on WebKit. The vulnerability was remediated in the 10.11.6 update for El Capitan.

FalseCONNECT similarly impacted tvOS and was remediated in the 9.2.2 update.

This loss in HTTPS trust for iOS and OS X happened before the browser even had a chance to properly establish it, rendering HSTS and any other certificate pinning solution useless.

This wasn’t an attack against TLS and it wasn’t a traditional downgrade attack like Moxie Marlinspikes SSLStrip where it’s possible to spot the attack because of browser warnings or a move from https:// to http:// in the address bar. This vector maintained all trust cues including the lock.

I'll try to spare you the bulk of the technical details on protocol implementation here but it may be helpful to the technical community so if you want to geek-out with HTTP 407 check out RFC 7235. To do the same for the CONNECT method, check out RFC 7230.

In part one I’m covering the worst of the impacts of the FalseCONNECT vulnerability to iOS and OSX which results in a complete compromise of HTTPS trust. However, without fully compromising HTTPS, elements of the FalseCONNECT vulnerability impact all operating systems or software supporting proxy use in ways which resulted in some loss of trust. These issues will be covered in part two as patches are issued by vendors.

How do I know if I was impacted?

If you are using proxies you may be impacted by this vulnerability. Does your company require the use of proxies to connect to the Internet? How about your school or your library? Are you a government employee or police officer? Many government agencies and corporations utilize proxies for network optimization and as a layer of protection for their users. You might not even know you're vulnerable if you've installed a proxy auto configuration (PAC) file from a WiFi hotspot or have employer controlled device management software on your iPhone, iPad, Android device, Chromebook, Mac, or PC which configures a proxy for you. Do you use Windows? It looks like Microsoft enabled automatic proxy configuration by default. At BlackHat 2016 in Las Vegas, Maxim Goncharov disclosed research indicating it has even been possible to exploit certain autoproxy configurations remotely.

Are you a human rights, political, or privacy advocate, or someone who choose to use a VPN provider in conjunction with a privacy proxy for that added bit of safety? You might be impacted.

Your secure communications could have been intercepted or tampered with by anyone exploiting this vulnerability via a WiFi evil-twin network or OpenLTE based cellular communications interception solution. Nation state actors with access to Stingray devices and nation level networking gateways could have exploited the FalseCONNECT vulnerabilities.

In a twist of irony, those who took steps to guard their privacy and security through the use of a proxy were potentially the ones most exposed by this vulnerability.

I do use a proxy but it doesn't require authentication so I'm safe, right?

Nope. When an HTTP CONNECT request is sent by your browser to the proxy it is sent in clear-text. The response from the proxy will then also be in clear-text until the point that secure communication can be established. This gives a bad guy on the network an opportunity to replace the initial 200 OK CONNECT response from the proxy server with an "HTTP/1.0 407 Proxy Authentication Required" response of their choosing to exploit the FalseCONNECT vulnerability.

Maybe you are thinking: "I'm using an auto proxy, so secure communications from my device are only at risk at work, right?" Nope. Autoproxy requests are made by your device on any network once configured and all an attacker needs to do is respond with their own WPAD facilitated PAC file. This is easily done via controlling DNS on a local network, running a transparent proxy which responds to any HTTP query with a response of choice, or using any other vector which can intercept and modify network traffic.

The FalseCONNECT vulnerabilities are exploited in the area marked with the yellow box at steps one and two with everything in red representing what would normally happen in an HTTP CONNECT transaction with a proxy but doesn't in a FalseCONNECT attack:

FalseCONNECT happens here

Even if certificate pinning was in use by a browser or an application, because this vector takes advantage of the CONNECT before an HTTPS handshake, certificate pinning techniques and even client x.509 authentication controls would be of no use in preventing exploitation against the client. This vector happens before the server public key can be provided to the client as shown in step five, but not before a trust relationship has already been established or maintained by the browser or application as shown in step one. Unfortunately this implementation resulted in false trust situations whereby untrusted code delivered in the response body of the CONNECT could execute within trusted browser and application states.

Middling HTTPS on iOS

Take a look at the following screen capture. There is a lock indicating that this is a "secure" browser session, however, as shown by the presence of an alert displaying the HTTPS cookie, the HTTPS browsing session has been hijacked. Markup of choice including JavaScript can be rendered and executed within the security origin of the site being targeted:

iOS HTTPS Middled with FalseCONNECT

Now lets look at this simple attack example. When a request was made to https://www.wellsfargo.com, the following clear-text CONNECT request was sent by the browser, waiting to be intercepted:

CONNECT www.wellsfargo.com:443 HTTP/1.1
Host: www.wellsfargo.com
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 9_2_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13D15 Safari/601.1
Connection: keep-alive
Proxy-Connection: keep-alive

Ordinarily this would have gone to the proxy server configured by the host; however, on this network a transparent intercepting proxy is capturing select CONNECT requests and instead of starting the handshake, responds with a 407 proxy authentication required:

HTTP/1.0 407 Proxy Authentication Required
Content-Type: text/html
Connection: keep-alive

<!-- attack payload of choice
executed within the security realm
of the site I'm targeting

Anything goes so I'll just show the
user their cookie and a picture of
my cat-->
<script>alert('Here is your HTTPS cookie: '+document.cookie)</script>
<img src="http://pwnprinter.com/storage/cache/images/000/016/DSC02535,medium_large.1438139480.jpg" height=800 width=1200>

Now if you read RFC 7235 you'll notice there's something missing in the response above, the proxy-authenticate header which typically looks something like this:

Proxy-Authenticate: Basic realm="Some Proxy"

Removing the header is done to avoid displaying an authentication dialog to the user which could tip them off that something is seriously wrong. As you've likely figured out by now, the contents of "407 Proxy Authentication Required" responses must never be rendered by the browser, especially within the secure same origin of an HTTPS site but that's exactly what happened here.

If you were paying attention above you'll note I mentioned that the intercepting proxy was looking for select CONNECTs to a particular server. This is to ensure that a trust relationship is already established by the browser so that the lock is displayed to the user in Safari, Opera, or any other browser in iOS using WebKit. If trust is not previously established the address bar will show HTTPS:// but no lock. Any markup and JavaScript payload of choice will then be executed within the security context of the HTTPS site the user is visiting with full rights to DOM security for that site. As an example, a user might visit https://www.wellsfargo.com and the attacker targets the second CONNECT request to wwww.wellsfargo.com knowing it will be for a bit of JavaScript which they replace with their own payload in the body of the 407 response. An attacker may also target responses for advertising or metrics scripts so that they don't need any previous knowledge of site delivered assets.

Why would this possibly work?

On iOS, WebKit renders the markup provided in a "407 Proxy Authentication Required." This allows a proxy server that requires authentication to give the user a soft-error after a certain number of failed authentication attempts, but because the contents of the HTTP response are rendered within a trust realm, it can be used to attack cryptography trust in WebKit.

How bad could this be?

This represents a complete failure in trust before a secure handshake and connection can even be established. As can be seen by the document.cookie alert, the attacker has full access to the target site trust in the DOM. At this point it becomes easy to steal sessions not protected with the HTTPOnly flag and in fact proxy the entire contents of a site through this vector so that the victim believes they are browsing the site they intended to visit, unknowingly having all of what they believed to be secure communication intercepted all with the lock and https:// still in the address bar. Imagine visiting your bank over HTTPS where you are asked to enter your credit-card information to validate your account. Not only would an attacker be able to steal your authentication credentials and session cookie for your bank so they can access your account, but they could further lever their attack to get your credit-card details. If leveraged against a political activist this attack could reveal their identity and be used in combination with other attacks to compromise their device.

How can this be tested?

It is relatively simple to test for this vulnerability using an intercepting proxy like The Fiddler which supports CONNECT interception. A bit of FiddlerScript after the OnBeforeResponse function is all that is needed:

if (oSession.HTTPMethodIs("CONNECT") && (oSession.PathAndQuery == "target.site.com:443")) {
var oBody = "payload of choice goes here";

oSession.oResponse.headers.HTTPResponseCode = 407;
oSession.oResponse.headers.HTTPResponseStatus = "407 Proxy Authentication Required";}

It impacts more than Safari

Because this vulnerability impacts WebKit on iOS, any application which uses WebKit is also vulnerable when presenting web views. This can allow an attacker to hijack the application, spoofing the entire user experience if desired without any way for the user to tell. Here are examples of the Facebook and WellsFargo apps being exploited via the FalseCONNECT vector:

iOS apps HTTPS middled with FalseCONNECT

Other browsers like Opera which are also based on WebKit are also vulnerable. In this example I'm demonstrating that it's possible to render user interactive markup of choice within the DOM even with the lock present, accomplished by replacing select CONNECT responses with my own. Any data entered by the user would go to the attacker:

iOS Opera HTTPS middled with FalseCONNECT

Middling HTTPS on OS X

This flaw extends to OS X, impacting Safari and any application using WebKit. The following screenshot is an example of Safari in El Capitan falling to the FalseCONNECT vector:

OS X Safari HTTPS middled with FalseCONNECT

Just like in iOS, many Apple applications that utilize WebKit are also vulnerable including iTunes:

OS X iTunes HTTPS middled with FalseCONNECT

Similarly, this vector also extends to third-party applications using WebKit like Google Drive:

OS X Google Drive HTTPS middled with FalseCONNECT

A little bit of history repeating

I know what you are thinking: "what did Bill Gates say about this?"

We have had various tools over the years to try and verify the security of protocols and their implementation. I wonder if any of those tools could have spotted these problems. I guess most of those models didn't model cross-site scripting attacks.

The problems described here seem quite serious and we should certainly improve our products—both server and client. These error handling cases are often a source of security problems.

- Bill Gates

Bill Gates didn't exactly say that about FalseCONNECT. He was referencing work done by Microsoft in 2007. Shuo Chen, Ziqing Mao, Yi-Min Wang, and Ming Zhang from Microsoft Research discovered that a number of browsers including IE, Safari, Firefox, Opera, and Chrome were vulnerable to roughly this same vector as a result of rendering markup from server error response codes from CONNECT requests. By 2009 they had named it Pretty Bad Proxy and published. From there they presented at the IEEE S&P 2009 conference and spread the word. Browser manufacturers fixed their software, removing the rendering of anything coming back in an error response to a CONNECT.

Unfortunately the Pretty Bad Proxy research didn't result in the full exploration of what could go wrong for other HTTP response codes such as HTTP/1.0 407 Proxy Authentication Required which were not covered by the research and thus the reason for the FalseCONNECT related disclosures in 2016.

Some serious cleanup is required

Ultimately, exploitation of this client side vulnerability can be difficult to identify for users who move between networks. An organization utilizing an IDS or IPS may watch for malicious HTTP 407 responses to a CONNECT request on their network to attempt and detect an attack but this does no good if the user impacted is not on a network being monitored. For organizations that have placed IDS or IPS on exit nodes as an example, they may miss the exploitation of users on local subnets.

FalseCONNECT spray cleaner

Apple remediated the HTTPS middling flaw in iOS and OS X quite quickly, within the 45-day public disclosure window set by CERT. The public release of this bug was delayed due to additional vendor patching which will be covered in part two of this write-up with an ETA still pending for embargo release. Ultimately this was a very shallow bug. It was sitting just under the surface in an area of browser interaction which was not thoroughly evaluated. For the security community this is yet another wake-up call that we still have shallow bugs in some of our most trusted solutions. While ensuring that we have strong cryptographic protocols and algorithms must continue to be a priority, it is equally important to validate implementations.

This is part one of the FalseCONNECT story and there is more to come as vendors issue patches. Stay tuned for part two and in the mean-time consider that HTTPS communications through proxies could be subject to tampering which could compromise trust. Watch for vendor patches.

Where's the HTTPS for this site?

It is conspicuously absent for a reason. If HTTPS can't be trusted...