5 ms·

Excellent write up. That’s why we need SSL/TLS with HSTS. Pure HTTP, specially in public WiFi, is dead.

dx034 9y ago
Since we won't get https everywhere soon, is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM?
- pnutjam 9y ago
  If you control the AP, you should disallow client to client communication. Most AP's and routers allow this and it would mitigate this risk.
  - rocky1138 9y ago
    Is there any way to mitigate this without limiting abilities of people on the network? It kind of destroys the point of a LAN.
    - toolz 9y ago
      don't take my word for it, but I'd bet you could disallow LAN comms on port 80 and prevent this. Typically a toxic client would flood the arp table until the router believed the toxic client should receive all communications and then the toxic client would mitm and forward traffic on the expected port to other normal clients...if the toxic client can't send stuff on port 80 to a normal client they can't easily mitm them
      - pnutjam 9y ago
        Yeah, but it would still redirect, since that's a different layer of the IP stack. You could prevent wifi clients from communicating arp packets, I think that would allow most things to work. If you have a corporate wifi system, you should be watching for arp poisoning anyway. If it's a public system, most people aren't using it to communicate between wifi devices. Most android devices that communicate via wifi will generate their own wifi network for the duration of the communication.
    - dx034 9y ago
      Did you ever use LAN functionalities in public Wifi (e.g. Starbucks)?
      - reaperducer 9y ago
        I did once at a hotel. Someone on the LAN kept what appeared to be his entire MP3 collection in his Shared folder. So I downloaded the whole thing. Turned out he had crap taste in music and I ended up deleting my copy.
  - lsaferite 9y ago
    CoffeeMiner mixed with a WiFi Pineapple seems like the way to go.
    - pnutjam 9y ago
      Pineapple is overkill. You can use any open-wrt device or Linux laptop with a card supporting hostap. Just give it the ssid 'xfinitywifi'.
  - gpm 9y ago
    But... this doesn't use client to client communication. As far as the AP is concerned there is one client (the attacked). The victim is connected to the attacked believing the attacker is the AP.
    - pnutjam 9y ago
      To the AP, they are both clients. The attacker (MITM) computer can be accessed by the victim. This would mitigate the attack. It's possible that the arp spoofing would prevent the victim from accessing the internet, but that depends on how the AP institutes it's blocks.
- IgorPartola 9y ago
  I think we will get it everywhere soon. And no, that's not a solution. Well at least not everywhere. If the clients aren't completely isolated I can for example poison your DNS and redirect example.com to my computer's web server.
- gruez 9y ago
  >is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM? AFAIK that wouldn't help because at the very least you can MITM the handshake.
- thinkythought 9y ago
  Honestly any decent public wifi setup even if it isn't going to limit client to client communication, if that's needed for some reason, should be restricting based on protocol/port/etc. It should be a whitelist, not a blacklist. There's no reason a client should be able to touch HTTP traffic towards anything but the gateway. This is trivial to set up with for example, even a cheap sonicwall.
- willstrafach 9y ago
  > is WPA2 on a public Wifi with a publicly known key a workaround? You're thinking of packet injection (or data intercept) by any nearby individual, which WPA2 with known PSK would mitigate. However, as an attacker would know the PSK, they could simply join the network to side-step this.
- RKearney 9y ago
  I've heard of, although never implemented, using WPA2 Enterprise authentication for public access points, and then just have your RADIUS server reply with a success regardless of username and password combination. At first I thought this was a terrific idea, but never tried it since I figured having a non-standard workflow for users to connect may cause too much confusion in the end.

Since we won't get https everywhere soon, is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM?

pnutjam 9y ago
If you control the AP, you should disallow client to client communication. Most AP's and routers allow this and it would mitigate this risk.
- rocky1138 9y ago
  Is there any way to mitigate this without limiting abilities of people on the network? It kind of destroys the point of a LAN.
  - toolz 9y ago
    don't take my word for it, but I'd bet you could disallow LAN comms on port 80 and prevent this. Typically a toxic client would flood the arp table until the router believed the toxic client should receive all communications and then the toxic client would mitm and forward traffic on the expected port to other normal clients...if the toxic client can't send stuff on port 80 to a normal client they can't easily mitm them
    - pnutjam 9y ago
      Yeah, but it would still redirect, since that's a different layer of the IP stack. You could prevent wifi clients from communicating arp packets, I think that would allow most things to work. If you have a corporate wifi system, you should be watching for arp poisoning anyway. If it's a public system, most people aren't using it to communicate between wifi devices. Most android devices that communicate via wifi will generate their own wifi network for the duration of the communication.
  - dx034 9y ago
    Did you ever use LAN functionalities in public Wifi (e.g. Starbucks)?
    - reaperducer 9y ago
      I did once at a hotel. Someone on the LAN kept what appeared to be his entire MP3 collection in his Shared folder. So I downloaded the whole thing. Turned out he had crap taste in music and I ended up deleting my copy.
- lsaferite 9y ago
  CoffeeMiner mixed with a WiFi Pineapple seems like the way to go.
  - pnutjam 9y ago
    Pineapple is overkill. You can use any open-wrt device or Linux laptop with a card supporting hostap. Just give it the ssid 'xfinitywifi'.
- gpm 9y ago
  But... this doesn't use client to client communication. As far as the AP is concerned there is one client (the attacked). The victim is connected to the attacked believing the attacker is the AP.
  - pnutjam 9y ago
    To the AP, they are both clients. The attacker (MITM) computer can be accessed by the victim. This would mitigate the attack. It's possible that the arp spoofing would prevent the victim from accessing the internet, but that depends on how the AP institutes it's blocks.
IgorPartola 9y ago
I think we will get it everywhere soon. And no, that's not a solution. Well at least not everywhere. If the clients aren't completely isolated I can for example poison your DNS and redirect example.com to my computer's web server.
gruez 9y ago
>is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM? AFAIK that wouldn't help because at the very least you can MITM the handshake.
thinkythought 9y ago
Honestly any decent public wifi setup even if it isn't going to limit client to client communication, if that's needed for some reason, should be restricting based on protocol/port/etc. It should be a whitelist, not a blacklist. There's no reason a client should be able to touch HTTP traffic towards anything but the gateway. This is trivial to set up with for example, even a cheap sonicwall.
willstrafach 9y ago
> is WPA2 on a public Wifi with a publicly known key a workaround? You're thinking of packet injection (or data intercept) by any nearby individual, which WPA2 with known PSK would mitigate. However, as an attacker would know the PSK, they could simply join the network to side-step this.
RKearney 9y ago
I've heard of, although never implemented, using WPA2 Enterprise authentication for public access points, and then just have your RADIUS server reply with a success regardless of username and password combination. At first I thought this was a terrific idea, but never tried it since I figured having a non-standard workflow for users to connect may cause too much confusion in the end.