Monday, September 06, 2010

Apple's secret "wispr" request

When an Apple iOS device (iPhone, iPad, iPod) connects to a WiFi network, the first thing it does is make a request to the URL http://www.apple.com/library/test/success.html. Some twitters (like Adam Shostack) were commenting on this. I thought I'd explain what I've found out about it.

The purpose of this request is to discover if there is a "captive portal" in the way. A captive portal is when, after connecting to the WiFi, any web request you makes gets redirected to a login/ToS page. In order to continue, you must either login with a username/password (or sign up, then login), and/or access the Terms of Service.

The reason Apple does this is because you may be using an app other than the web browser. For example, the only thing you might be doing is syncing your e-mail. In such situations, you would never see the portal page, and your app will mysteriously fail to connect to the Internet.

Therefore, before your app has a chance to access the network, Apple does this for you. It sends out a request to the above URL. If the request gets redirected, then Apple knows there is a portal. It then launches a dialog box, containing Safari, to give you a chance to login.

The following is the sniffed version of the HTTP request:

GET /library/test/success.html HTTP/1.0
Host: www.apple.com
User-Agent: CaptiveNetworkSupport/1.0 wispr
Connection: close

One of the questions people had was whether this was a privacy issue. the answer is "largely no". It sends no personally identifiable information. In particular, it doesn't send any cookies. The request is made from the WiFi software, not Safari. Therefore, any cookies you have in Safari will not be sent via this request. I verified this myself, by accessing Apple.com via Safari and watching cookies being sent, but verifying this did not send cookies.

Another question is whether this is an attack vector. The answer is "probably yes". There is more to the functionality than a simple HTTP request. If you look up the keyword "wispr" from the User-Agent string, you'll find out why.

The idea is that smart WiFi portals will detect that this is a WISPr-supporting device, and send back a WISPr message in XML. This allows the iPhone to then login with cached credentials via another XML message. This means, for example, you might be able to grab somebody's credentials with a properly configured WiFi access-point.

I've seen the iPhone deal with such an intelligent WiFi access-point, but at the time, I did not have the presence of mind to sniff the exchange, so I'm not sure what happened.

Just the fact that XML is used opens this up to a lot of attacks. Programmers tend to use XML poorly. Depending on how they've configured the XML library, it may be possible to do something like run JavaScript within the context of the response message. Or, fuzzing responses might find a buffer overflow on the iPhone.

Another odd bit of behavior was loging onto an "attwifi" access-point at Starbucks. As you might have heard, using the iPhone on their network is free. The way this works is that the iPhone sends out a request to "http://attwifi.apple.com/library/test/success.html: the same URL as before, but with the "attwifi" in front.

At my local Starbucks, all web surfing is free. But, Windows presents a captive logon page where you must accept the Terms of Service, but the iPhone doesn't. I assume the portal detects this URL, and automatically opens up the access-point without doing a redirection. I need to test witha Linux distro in order to figure out what's going on.

Summary

No personally identifiable information is sent, so there isn't much of a privacy breach.

There is more complexity to this feature than the simple HTTP request; there is probably a way to attack it.

You can probably configure your machine to emulate this request, and get free WiFi that is intended for iPhones.

UPDATE 2012-Sep-19: On the day of iPhone 5 release, this webpage went down, breaking everyone's WiFi.

10 comments:

James M. Leddy said...

> You can probably configure your machine to emulate this request, and get free WiFi that is intended for iPhones.

I'm extremely interested in this. At one of the clients that I visit, so many people have iPhones that ATT volunteered to install an attwifi network in the building. Yet, I'm still stuck with TMobile tethering to get to my internet access since the client doesn't allow any unapproved hosts joining their network.

Adi said...

> Just the fact that XML is used opens this up to a lot of attacks. Programmers tend to use XML poorly. Depending on how they've configured the XML library, it may be possible to do something like run JavaScript within the context of the response message. Or, fuzzing responses might find a buffer overflow on the iPhone.

Actually, just because it's XML that doesn't say anything about security. Because the request is done by the OS itself and not by Safari means that there is probably no way to run any Javascript. As for the buffer overflow, the chance of that happening isn't any greater than anywhere else in the OS

Oren Mazor said...

I've spent some time working with this recently. don't rely on "wispr". that's configurable.

Joel Esler said...

Probably also gives Apple a good handle on how many devices of what version and what operating system version are currently out there.

Unknown said...

@Joel: It does? How? I don't see anything in that request that would indicated what version it's running.

Paul Winkeler said...

You can see how the Mac decides which wispr URL to probe for by perusing /Library/Preferences/SystemConfiguration/CaptiveNetworkSupport/Settings.plist

DeadDuck said...

Recently my ISP's cache server developed some issues and since then I'm not able to access www.apple.com on my net connection. This didn't pose much of an issue on my iDevices as store and other apple services continued to work fine. However, ever since iOS 6 my iDevices cannot keep connection to my WiFi active. After connecting these try to access this "wispr" url of Apple and keep failing.

Luckily I have alternate net connection for my VoIP line. I tried switching my main router with this connection and all my iDevices work fine. But if I switch back to my regular net connection, the same problem starts occurring. This never happened to under iOS 5.x, only with iOS 6.

So my question is, does apple/iDevices need to access this URL always or just once for saved WiFi connection?

Ravi said...

This so called feature is a problem at Wi-Fi HotSpots, wherein the user receives username and password via sms after registering themselves at captive portal. Once you switch the App from Safari to Messages to view your username and password the Wi-Fi gets disconnected and you again have to connect to the Wi-Fi. The Safari opened captive portal should have been retained while switching to Messages.

jj said...

UPDATED URLs for WISPr target with Apple iOS 7.
http://www.cadinc.com/why-your-apple-ios-7-device-wont-connect-to-the-wifi-network

jj said...

Updated URLs for WISPr on Apple iOS 7 - http://www.cadinc.com/why-your-apple-ios-7-device-wont-connect-to-the-wifi-network