Apple's secret "wispr" request(erratasec.blogspot.com)
erratasec.blogspot.com
Apple's secret "wispr" request
http://erratasec.blogspot.com/2010/09/apples-secret-wispr-request.html
7 comments
There are some other things that are reasonably likely to cause buffer overflows in the XML-parser-user even if the XML parser is perfect, mostly involving very large numbers of elements (<b><b><b><b><b><b>... etc), a tag with thousands of attributes, tags with very large attributes, etc. XML really does have some characteristics attack vectors. However, I am not aware of anything that doesn't; JSON has very similar vectors, as does any recursively-specified serialization format, and of course we all know the joys of binary specifications and screwing with length headers.
As you quoted, "Programmers tend to use XML poorly", but then, "Programmers tend to use serialization poorly" would work just as well. I've only recently really started internalizing just how much of a minefield serialization is in general and I'm 12 years into my career.
As you quoted, "Programmers tend to use XML poorly", but then, "Programmers tend to use serialization poorly" would work just as well. I've only recently really started internalizing just how much of a minefield serialization is in general and I'm 12 years into my career.
this really isn't secret. the only thing that is "secret" is the wispr specs, because the god damn thing floats in and out of IETF. almost everybody who does hotspots deals with it, but that's it.
couple of things: - "wispr" is a configurable keyword. thats not how wispr works or is detected. - the probeurl (i.e. the url that a captive network checks for) changes with a wide variety of hotspots. when I last looked, ATT provisioning had 5. - there is no security issues here as far as xml or wispr is concerned. the cached credentials on ATT, for example, are global to all ATT users. not to mention, there's a whole whackload of certificates and whitelists in there to keep you from sending a wispr request to fake access point
couple of things: - "wispr" is a configurable keyword. thats not how wispr works or is detected. - the probeurl (i.e. the url that a captive network checks for) changes with a wide variety of hotspots. when I last looked, ATT provisioning had 5. - there is no security issues here as far as xml or wispr is concerned. the cached credentials on ATT, for example, are global to all ATT users. not to mention, there's a whole whackload of certificates and whitelists in there to keep you from sending a wispr request to fake access point
> "You can probably configure your machine to emulate this request, and get free WiFi that is intended for iPhones."
Gentlemen, start your engines!
Gentlemen, start your engines!
Reminds me: on in-flight WiFi, you can set your computer's user agent to be that of an iPhone, and you get to purchase less expensive WiFi. ($5.95 versus $9.95 on my most recent flight)
I thought they also thought they checked that the MAC address of the phone corresponds to a plausible iPhone MAC address. So, you might have to change that on your wifi card first (kind of a bother.)
Boingo caches the user agent of the first HTTP request made via each MAC address and uses that to determine what type of device it is. They also offer (or perhaps offered, I haven't been to an airport in awhile) 1 free hour per iPhone MAC address ;)
Relevant: once I signed up for Boingo. Never again. The only way to unsubscribe is to pick up a phone and call them.
Just change your user agent and send out any request to any page...
This brings back ugly flashbacks... Apple's WISPr implementation also breaks any apps that try to provide WISPr functionality since it gets in the middle of the handshake.
You can't disable that unless you get on some magic whitelist that Boingo got into but it's pretty much off-limits for the rest of the crowd.
You can't disable that unless you get on some magic whitelist that Boingo got into but it's pretty much off-limits for the rest of the crowd.
a. WISPr is publicly documented. You can read about how it works in the document. As for user creds, I would suspect that maybe the ATT client is using a form of EAP-SIM over WISPr but thats just my guess. It could also be something much simpler that doesn't even bother to verify "credentials" in the normal sense. Whatever is going on - its built in "under the hood".
b. The author of the article is speculating when worrying about buffer overflows and javascript execution. I doubt most wispr parsers even use traditional XML parsers. Besides, its much easier to spoof an AP or execute a man-in-the-middle attack than anything else.
c. The magic whitelist as you call it, is publicly documented and is called "Captive Networks". You can read about it in the iOS documentation. But I suppose its more fun to try to bash without any knowledge.
b. The author of the article is speculating when worrying about buffer overflows and javascript execution. I doubt most wispr parsers even use traditional XML parsers. Besides, its much easier to spoof an AP or execute a man-in-the-middle attack than anything else.
c. The magic whitelist as you call it, is publicly documented and is called "Captive Networks". You can read about it in the iOS documentation. But I suppose its more fun to try to bash without any knowledge.
You are so off-base it's not even funny. I can't believe 3 people upvoted you.
I'm talking about native iPhone apps that try to provide some WISPr-related functionality -- the kind of apps ATT would pay somebody to do if WISPr wouldn't be "build in", OR, if they actually wanted to provide more features than just the basic login.
And the "magic whitelist" is a whitelist on the iPhone itself, that disables the iOS "built in" WISPr support so that native apps work. One of these apps is Boingo.
But you are right about one thing: sometimes I also feel that it seems easier for people to bash on the internet without any knowledge.
I'm talking about native iPhone apps that try to provide some WISPr-related functionality -- the kind of apps ATT would pay somebody to do if WISPr wouldn't be "build in", OR, if they actually wanted to provide more features than just the basic login.
And the "magic whitelist" is a whitelist on the iPhone itself, that disables the iOS "built in" WISPr support so that native apps work. One of these apps is Boingo.
But you are right about one thing: sometimes I also feel that it seems easier for people to bash on the internet without any knowledge.
it's not a magic white list. it's actually an explicit list on the iphone. you can apply to have your app exempted.
Sure, you can apply.
That doesn't make it easier to explain to customers why they can't even test the app properly on their test devices.
This fact was also basically undocumented which made things... interesting.
That doesn't make it easier to explain to customers why they can't even test the app properly on their test devices.
This fact was also basically undocumented which made things... interesting.
I don't really understand what your second sentence means. what customers? what app? why can't you test it on the device?
I'm not defending apple on this, at all. but from the time I've spent working with these devices, there is just so much going on in so many levels, you can't possibly cover everything with public facing documentation. and you probably shouldn't anyway.
I'm not defending apple on this, at all. but from the time I've spent working with these devices, there is just so much going on in so many levels, you can't possibly cover everything with public facing documentation. and you probably shouldn't anyway.
I'm taking about apps that provide WISPr functionality.
The customer is the one paying for said app and they can't test it since the built-in WISPr gets in the way.
I think everything should be in public documentation. I don't like knowing that if I can visit Cupertino I might find out about some API I just really-really need, but not if I search the documentation.
The customer is the one paying for said app and they can't test it since the built-in WISPr gets in the way.
I think everything should be in public documentation. I don't like knowing that if I can visit Cupertino I might find out about some API I just really-really need, but not if I search the documentation.
ah, I get it.
from apple's perspective: they dont have to document everything. they covered the majority of stuff that the majority of developers/users care about. this is pretty much affecting almost nobody.
from my perspective: god dammit I wish they documented the goddamn provisioning system. I know the only people that need to care are carriers, but that would make my job a lot easier.
from apple's perspective: they dont have to document everything. they covered the majority of stuff that the majority of developers/users care about. this is pretty much affecting almost nobody.
from my perspective: god dammit I wish they documented the goddamn provisioning system. I know the only people that need to care are carriers, but that would make my job a lot easier.
How does Windows 7 do it, then? I know W7 detects a login portal page too.
Starbucks is not detecting iOS wispr URLs. It's detecting the user agent. Change your browser user agent to anything else and try it again.
It's the same way I get on my University's network without logging into the awful SafeConnect.
It's the same way I get on my University's network without logging into the awful SafeConnect.
Does that get annoying when you browser to sites that detect iPhone for example and give you a "mobile" version of the page? or can you change the user agent back after your first request?
Perhaps you can craft a UA string that will match the regex for both cases, maybe try concatenating the iPhone and your proper UA string?
On SafeConnect, it caches the MAC Address as exempted for a period of time. When SafeConnect pops up, I fire up my Chrome shortcut that makes my user agent "Wii". After I send a single request and it redirects me to 'unl.edu', I close the browser, and reopen Chrome with my normal shortcut (so back to normal UA).
I have to do it once every few days. I could craft a wget/curl request to run every few hours I suppose so I wouldn't have to close out of Chrome and reopen it, but what can I say, I'm lazy.
I have to do it once every few days. I could craft a wget/curl request to run every few hours I suppose so I wouldn't have to close out of Chrome and reopen it, but what can I say, I'm lazy.
Eh? I've so far not seen an XML parser (or any library) that runs JavaScript. And while buffer overflows are always a possibility in C based software, using a well tested XML parser is probably a better safeguard than hacking your own parsing code, and comparable to using any other parsing library.
Not that there aren't any problems with XML default parser configurations (system entities, the billion laughs), but this is just bogus.