Wednesday, November 10, 2010

PSK doesn't mean Public Shared Key

It's recently been suggested that free hot-spots should switch to WPA with a known passphrase to help protect against attacks like Fire Sheep, a clever tool which integrates sniffing auth credentials from the air with your browser.

Short version: This won't work.

Long version:

There's a bunch of ways this reasoning is flawed:

  1. WPA-PSK offers no validation of the access point other than the PSK.

    What does this really mean?  As soon as you give out the PSK, you've got zero protection from "evil twin" impersonation attacks.

    When you are the AP, you already know all the magic.  The traffic is decrypted and shows up on a local interface.  Sure, this makes running Firesheep marginally more difficult, since it requires setting up an AP, but... it's not all that more difficult.

    It does require the attacker take an active role.
  2. Slightly more esoteric, but fundamentally the same: The PSK is meant to be private.

    When the PSK is known, the PMK (Primary Master Key) is known.  When the PMK is known, the PTK (Temporal Key, which actually encryptes the users traffic) can be snooped, and when the PTK is known, the traffic can be decoded directly, yielding the same problem.
  3. [Edit] As pointed out by Zero_Chaos on IRC... "free" isn't even a valid PSK since it isn't at least 8 characters!
So what's the solution?

I don't know.  We have no (current) mechanism of mutual authentication with the access point which precludes users subverting themselves.

WPA-EAP?  Sounds good, you get per user keys where the exchange is encrypted via TLS, so even using the same user/password doesn't lead to snoopable keys...

Except we need to protect the radius exchange with a SSL certificate.  How many users (who we have already established don't know how to use https) are going to be able to authenticate a certificate fingerprint?

"Ah" you say, "I'll just use a cert signed by a public certificate authority".  Sure.  And then either:
  1. Every cert signed by that authority is accepted as a valid chain, and I can just go get one myself for $n
  2. The user is prompted to accept this specific certificate, leading right back to the same problem with "can a user be expected to validate a certificate themselves"
Ultimately, sites will have to protect their users by forcing SSL logins, but even this is still vulnerable to an attack like MSF::AirPwn on the http page which redirects to https, which would allow the attacker to redirect the user at will - including to a proxy server with a self-signed certificate (or even just an iframe proxy) which leads back to the mutual trust problem.

I need a drink.  Again.

Tuesday, September 21, 2010

Your smart phone... can beat up my smart phone...

So, fair's fair:  Know that sexy flash exploit that's hit Windows, OSX, and Linux?  Yup.  Word is that it affects Android, too though I haven't seen any claims of exploits in the wild yet.

What does this have to do with wireless?  The same trick that we can use to do horrible things to an iPhone (MSF-Airpwn or a Karma AP) could do content replacement and push a malicious flash file to the phone for any website viewed.

The Android security model is slightly different and this vulnerability doesn't appear to give any direct path to root, however since many Android phones have vulnerabilities which allow root escalation from a local user (beloved of jailbreakers everywhere, just like the bugs in iOS) it's not implausible to be concerned about the risks here.

Once the exploit is in your browser, all your cached credentials are at risk, anyhow.

Adobe has just today released a Flash update for Android which fixes this flaw, but I think we'll be seeing vulnerable versions in the wild for some time to come:  It appears anything which shipped with Flash pre-installed (such as the Droid 2) doesn't have the apk marked as a market download, which means the market app doesn't look for updates.  Only manually searching for Flash and installing it from the market will get you a non-vulnerable version.  Users where Flash was a mandatory market download (Droid 1 2.2, Nexus One) should get an update alert, fortunately.

Related, the Y5 Battery Saver App is intended to conserve battery by turning off wireless, but has interesting security implications too, especially if you are forced to use a cloaked wireless network.  Instead of probing for previously saved networks when you are nowhere near them, Y5 will use the "free" (as in "your phone is always computing it") rough geolocation derived from cell tower location to determine if wifi should be enabled or not. 

It won't save you from getting owned on an open, compromised, or duped network, but it will keep your phone from connecting to random wifi with the same name or falling victim to Karma or similar spoofing attacks when you're away from home.  And maybe it will save some battery in the long run.

Wednesday, August 25, 2010

Google, Wifi, Android, and Too Much Data [repost]

[Repost from old blog software]

By now, I expect everyone is pretty well sick of hearing about Google
capturing wifi data (though I'm still amused on some level watching
each news report come in).

This is not, per se, about Google capturing wifi data.  This is about what
happens when a gigantic company with multiple business sections suddenly
amasses a truly frightening combination of data points.

What we know about the Google wifi snooping:

1.  They set out to collect BSSIDs, SSIDs, and locations (standard
skyhook-style stuff, not scary at all really).

2.  They also logged packet payloads.  Ignoring the spin on legality,
deliberate actions, and the like, what we've got is a company holding an
unknown quantity of data.

What we don't know:

1.  What payloads were captured?  The reports indicate "unencrypted
packets", but is this only because encrypted packets aren't interesting to
the news agencies?

2.  What will happen to this data?  Will it be kept if it's determined that
no laws were broken?

3.  How will this data be treated by agencies issuing subpoenas to examine
it?  Will it be destroyed after the case is concluded, or like genetic data,
will it be kept for future data trawling / evidence?

Where it gets really interesting (read: Dangerous):

Recently I had some bizarre errors with my android phone, solved by doing a
factory reset.  The first thing that happened after the reset was that the
phone connected to my wifi network again.

Wait... what?

"Back up my settings -- Your settings (such as your bookmarks and Wi-Fi
passwords) can be backed up..."

So now Google knows where I am, where the Network is,
and what the password is?  Uh oh.

What this all means:

I don't actually propose that Google is using stored password data -- I'm
fairly certain that, under the scrutiny they're experiencing, they wouldn't
be that foolish.  It's highly unlikely that the two departments even

What this does allow for, however, is end-runs around network
security, world-wide.  Some governments have already introduced measures for
secret warrants when issuing wiretap orders.  When your network password is
stored outside of your control, you (obviously) no longer control exclusive
access to it.

This can affect you even if you don't have an Android phone - ever given
your WPA passphrase to a visiting friend?

This again raises the question:  What happens to all the packets captured from
streetview?  Who may have access to correlate stored passwords with captured
data already obtained from a subpoena?

Sunday, August 22, 2010

Moving blog code

I decided if I'm going to try to make more regular posts I ought to use something better than some cobbled up scripts and a directory of files.

I'll move over some of the more recent posts and then kick over the link on the Kismet site.

Trust me, I'm a cell tower

While chatting with Nick DePetrillo we came up with a few more highly unpleasant things to do using the new Iphone vuln.

Using Chris Pagets work demoed at Blackhat this year, for $1500 (a totally reasonable price point for an attacker looking to make money with spy/ad/fraud ware on an iphone) it's possible to build a custom cell tower / IMSI catcher.

What does that get you?  The ability to masquerade as AT&T.

And to send SMS messages directly to the phone.

A man-portable microcell carried around a major metropolitan area may be able to catch a significant number of Iphones, immediately sending a spoofed SMS ("iOS update, click here"?  "More porn"?  "bank alert"?  "look at this funny cat"?)

IMSI catching: Not just for spying and phone sniffing, now you can use it as a direct attack.

Since the current USRP code doesn't support data, the phone is forced into
voice only mode, preferring wifi for data.  Not only can an attacker
directly spoof a URL in a message, but by forcing wifi (and bringing, for
example, an access point running karmetasploit which redirects all URLs via
MITM attacks) along with the USRP, users which do NOT respond to the URL are
still grabbed via the next website they visit.

Once inside the phone, what horrible stuff is on the menu?  Sending a worm-style SMS to everyone in the contacts list to then own their phones?  Installing trojans to dial high-rate numbers (already a problem with advertising services and a few apps)?  Snooping logins and personal data?  Targetted tracking via hidden apps?

Pass me a guinness.

My smart phone can beat up your smart phone

Or, Why this Iphone web attack really really matters.

So there's another jailbreakable vulnerability on the Iphone.

Much hilarity and glee ensues - who wouldn't want to go into Apples stores and jailbreak their own demo models?

This all gets a lot less funny when you consider some of the fundamental flaws in wireless networks (most recently hilighted by Renderman and I at The Last Hope, slides here.  Short version:  Airpwn isn't dead, and hijacking HTTP traffic can be extremely nasty.

What do we get when we combine Metasploit, MSF-Airpwn, a browser/content vulnerability, and a browser environment running as root?

The best case scenario is drive-by jailbreaking.  "You're welcome, Iphone users.  Here's cydia."

The worst case?  I don't know.  Maybe MSF-Ipwn?  (msf/data/ipwn/ipwn in the MSF tree).  Arbitrary spyware or adware on the phone that can't be killed by normal user access?  Tracking software?

What do we need to do this?  Any device capable of running MSF, MSF-Airpwn,
and which has inject-capable drivers.  Like say href="">the Nokia
N900?.  My smartphone beat up your smartphone on the playground.

All from browsing with an insecure device in public.