
Apple's secret "wispr" request - bensummers
http://erratasec.blogspot.com/2010/09/apples-secret-wispr-request.html
======
Nitramp
_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._

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.

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

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

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

Gentlemen, start your engines!

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

~~~
ryanpetrich
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 ;)

~~~
alanh
Relevant: once I signed up for Boingo. Never again. The only way to
unsubscribe is to pick up a phone and call them.

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

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

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

------
DaemonXI
How does Windows 7 do it, then? I know W7 detects a login portal page too.

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

~~~
pmorici
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?

~~~
pbhjpbhj
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?

~~~
alanh
Please don't use spouted user agent strings on third party sites if you can
avoid it. Reported UAs affect which browsers they support.

~~~
pbhjpbhj
Isn't that like saying "please walk on the dangerously iced pavements, if
accidents aren't reported they don't get gritted"?

