Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] comcast wifi question



Edward Ned Harvey (blu) wrote:
>Eric Chadbourne wrote:
>> Using unencrypted wifi just seems insane.
> 
> Oh.  THAT is what you're concerned about?  That's a little bit
> insane, because nevermind the wifi near you, your traffic goes across
> the whole internet. ... if you're connecting to insecure services,
> your traffic is insecure on the whole internet, not just your local
> wifi hop.

True in principle, but not in practice.

To sniff someones connection on open WiFi you need:
-laptop
-physical proximity
-readily available software
-intelligence of a script kiddie

To sniff someones connection at some point out in the cloud you need:
-a breached router, end point, or machine on an Ethernet segment that
falls along the path
-various hacking tools
-typically > intelligence of a script kiddie

In the first scenario the only thing stopping there from being thousands
of hackers sniffing your connection is the physical proximity
requirement. Other than that, there are basically no barriers.

Sniffing in the cloud has the advantage that hacker can be located
anywhere, but the the first problem is that they have to actually hack
into something, and on average that's going to be a moderate to high
threshold to overcome, as the targeted machines should be designed to
resist intrusion. (The exception being a malicious ISP or government
that has positioned themselves along the route.)

This also comes down to a game of chance. With cloud services, there are
millions of them, so what are the chances that something is breached
along the path to the one you are connecting to.

This should give you some comfort when accessing some low-security
unencrypted service over the Internet. But of course all this is
irrelevant when you are accessing a service where a breach of your
credentials matters, like your bank or Amazon. Obviously use SSL.

The biggest argument for using a VPN to cure open WiFi is to apply a
band aid to the legacy sites (and apps) that haven't adopted SSL.


> So you're concerned about people near you sniffing your wifi traffic.
> You think wifi encryption will help.  You're wrong, because #1
> everyone near you knows the password anyway.  So even with wifi
> encryption, they can still sniff your traffic.

With WPA2 it isn't quite as simple as saying just because the hacker and
victim both have access to the encrypted wireless network, that the
hacker can see all of the victim's packets. WPA2 uses client-specific
session keys. This explains what is involved in getting around that:

http://superuser.com/questions/156869/can-other-people-on-an-encrypted-wi-fi-ap-see-what-youre-doing/156969#156969

  WPA-PSK and WPA2-PSK encrypt everything with per-client, per-session
  keys, but those keys are derived from the Pre-Shared Key (the PSK; the
  key you have to know to get on the network) plus some information
  exchanged in the clear when the client joins or re-joins the network.
  So if you know the PSK for the network, and your sniffer catches the
  "4-way handshake" another client does with the AP as it joins, you can
  decrypt all of that client's traffic. If you didn't happen to capture
  that client's 4-way handshake, you can send a spoofed de-authenticate
  packet to the target client (spoofing it to make it look like it came
  from the AP's MAC address), forcing the client to fall off the network
  and get back on, so you can capture its 4-way handshake this time, and
  decrypt all further traffic to/from that client.


> [unlikely] you're using wifi encryption with 256 bit randomly
> generated keys (EAP,etc) that are strong enough to keep out any
> hackers.  Because it's not an enterprise secure network.

Right... (continuing to quote the above superuser.com answer):

  With WPA-Enterprise and WPA2-Enterprise (that is, with 802.1X
  authentication instead of using a Pre-Shared Key), all the per-client
  per-session keys are derived completely independently, so there's no
  possibility of decoding each others' traffic.


And answering the question that kicked off this thread, if Comcast used
WPA2-Enterprise, then your mobile device could validate its certificate
to insure it was connecting to a legit AP:

  An attacker would either have to...set up a rogue AP in the hope that
  you'll ignore the bogus server-side certificate the rogue AP would
  send, and join the rogue AP anyway.


More on WPA2-Enterprise from a company that sells a RADIUS
authentication server cloud service (so small time users can employ
WPA2-Enterprise without running their own RADIUS server):
http://www.nowiressecurity.com/articles/move_to_wpa-enterprise_wi-fi_encryption.htm

(I can't say I'd be willing to put my network credentials on a cloud
server, but the site has a bunch of articles listing the benefits of
WPA2-Enterprise.)

Searches didn't turn up which flavor of WPA Xfinity's hotspots use, but
the lack of matches on anything with "enterprise", or the specific
protocols covered by it, suggests they aren't using it. Although it
might still be something they support, for those security conscious
users who care to take extra configuration steps.

So it seems that yes, someone could set up a rogue access point with an
Xfinity SSID, and your mobile devices will hand over their credentials
to it. In fact:

http://arstechnica.com/security/2014/06/free-wi-fi-from-xfinity-and-att-also-frees-you-to-be-hacked/

  Ars tests how easy it is to spoof big broadband providers to grab
  data.

  ...AT&T sets smartphones to recognize and connect to "attwifi"
  hotspots automatically. ...  To demonstrate this, I set up my laptop
  as a Wi-Fi hotspot broadcasting the network name (SSID) "attwifi"
  (after alerting my neighbors, of course). After killing off the
  settings for my preferred networks on my iPhone, I turned on the
  Wi-Fi, and it connected to the fake "attwifi" hotspot without
  prompting.
  ...
  Comcast's Xfinity wireless hotspots present a Web page for login that
  requests a customer's account ID and password, and each time you
  connect to a new hotspot it re-authenticates you. But if you've
  connected once during the day, the hotspot remembers your device and
  reconnects you without prompting.

  That means that if someone were to set up a malicious Wi-Fi access
  point called "xfinitywifi," devices that have connected to Xfinity's
  network before could automatically connect without alerting the user
  or asking for the password. Alternatively, using a "honeypot" tool
  such as PwnStar, an attacker could spoof both the "xfinitywifi" SSID
  and the Xfinity login page--stealing their Xfinity credentials in the
  process.

Ah, so it is not relying on WPA at all. I gather PwnStar gets around the
need for spoofing the SSL cert on the Xfinity login page by having the
fake page be HTTP.

So this is not so horrible, then. In the legit scenario, you connect to
Xfinity's AP, get redirected to the captive portal, then you
authenticate over HTTPs. On subsequent connections, the AP looks at some
identifying information, like your MAC and bypasses the captive portal.
Therefore to avoid getting in trouble with a rogue AP, just make sure
you have a legit HTTPS connection (and the expected URL) on the login page.

And instructions on how to create your own portable spoofed Xfinity AP:

http://blog.logrhythm.com/uncategorized/xfinity-pineapple/

  To help illustrate this risk, I'll be using the WiFi Pineapple - a
  great little device by the folks at Hak5 that most security
  professionals are familiar with. The Pineapple comes equipped with a
  myriad of tools to help trick clients into passing their traffic
  through this access point so that it can be sniffed, altered,
  modified, or worse. For our specific attack, we'll be imitating an
  Xfinity WiFi access point and using this to steal users Comcast
  account credentials among other nefarious activities.
  ...
  [Enable the] captive portal. This allows you to pass the users through
  a splash page that you configure and force them to 'authenticate'
  before accessing the internet.
  ...
  Now sit back and watch as users join your access point and enter their
  Xfinity account credentials, which will be stored in the auth.log
  file. With these credentials, someone of lesser morals could use these
  to conduct illegal activities and have them traced back to the owner
  of the Comcast account.
  ...
  ...users should take steps to protect themselves and be cautious when
  using these networks.
  -If you have connected to an Xfinity access point in the past, you
  will pre-authenticate to any Xfinity access point going forward, this
  includes a masquerading Pineapple. This will not expose your
  credentials, but all your traffic will be passed through a potentially
  hostile access point.
  -Real Xfinity access points will redirect you to
  https://wifilogin.comcast.net to authenticate, though this could also
  be fudged by an attacker using DNS Spoofing so it is not a dead
  giveaway. The real identifier here is that the legitimate landing page
  is using SSL and has a valid certificate. This can be spoofed as
  well, but is much harder.


OK, so how about in the case where WPA is used. If you use
non-Enterprise WPA at home or work, and someone sets up a rogue AP with
the same SSID, will your mobile devices gladly hand over their WPA
shared key (password) to those devices? If so, that seems like a pretty
glaringly large hole in the security model.

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org