logo       

Re: [Fwd: [WEB SECURITY] TJX pwned via wifi]: msg#00032

security.wireless

Subject: Re: [Fwd: [WEB SECURITY] TJX pwned via wifi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 1. Couldn't you do some things to VLAN the AP's away from the main network?
> 2. Wouldn't a combination of MAC-address filtering help?
> 3. Does turning off the broadcast beacon help at all against this newest
> hack?
> 4. What is the recommended next step for a small company where
> implementing LEAP is seen as "too cumbersome" and not supported by the
> barcode scanners?
> Conclusion: I suppose we have to get the vendor to support WPA2 or
> similar in the next firmware release? Right?

Everything you can do adds a little bit of security to a WEP network,
but the only real fix is migrating to WPA/2.

NB: I'm going to ignore the LEAP indication as the "desirable"
authentication protocol. If that wasn't a typo, we can move this
conversation to a new thread.

One practice I recommend to customers is to use WEP just for the devices
that can only support WEP (handheld scanners, VoIP phones and the like)
and profile what the traffic patterns are using Wireshark (just take a
big Wireshark capture of the traffic in monitor mode and specify the WEP
key with Wireshark to decrypt, or get a wired packet-capture).

Once you know exactly what the minimum traffic is for the WEP-only
devices, you can setup firewall rules to grant _only_ that access. This
may include DNS, DHCP, SIP and RTP for VoIP devices, but you get the
idea. In Wireshark, you can click on the packet representing traffic
you want to allow and click "Analyze --> Firewall ACL Rules", then
select your type of firewall device and Wireshark will create the rule
for you automatically (I think that's a cool feature).

This implements the Policy of Least Privilege, and ensures only the
permitted protocols are allowed on the network if the network is
compromised. However, we can take this one step further and blacklist
anyone who violates this policy. Since your handheld scanners/VoIP
phones shouldn't be doing anything outside of their defined policy, we
can blacklist any device that tries to access something not expressly
permitted (e.g. hacker compromised WEP, associates and accesses HTTP/80
or port-scans a device; they get blacklisted). The blacklisting itself
has little value since the attacker can select another MAC address and
try again, but it is a terrific WIDS indicator that someone is actively
breaking the network use policy (e.g. now your WIPS reaction is to find
a guy with a big stick and beat-down the attacker).

For legacy/fat Cisco networks, I've implemented this by adding a "deny
any any log" to the end of the ACL to generate logging notices any time
the policy is violated, and used a monitoring tool like SWATCH [1] on
the syslog server to execute a shell/perl/RUBY/Python script whenever
the logging message is observed. The script can do whatever you want,
from logging into a firewall and adding an ACL to blacklist a MAC, or
just notifying you that something fishy is going on.

With my employer's architecture (Aruba Networks), we call this a role
change event, and it's a very easy thing to setup without SWATCH,
scripting or any other hackery. Other transport providers may provide
similar features.

It's not that I don't recognize that there are legacy devices out there
that can't do WPA/2, but promoting something that will be easily (and
transparently) evaded by attackers while advocating that it makes
retailers PCI compliant is, well, it's just wrong.

Comments welcome, thanks!

- -Josh

[1] SWATCH; http://swatch.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQIVAwUBRkBS+jWX3FIa1TkuAQLavw//Smcn0pCIVGD+RhSiJypiLPFwcshU9/Fd
WkJfP8uGIuHY5EGaKXh3mCTfex5r4B0HDSlzUI37aQDzgt4d3tP0EIaDBblDGblS
4T7w4iKjwhD+G+yrIssh3jCGTLi+/lUfcCskIvuc1V5JKDcPBqScu0X6ua0hJkr0
DZpwiySom/XWd3znvJ8PJsmFn70sNA685kWeLXaCElkyg/GQz7QezXdf9RXvYWQb
d+VdJxEstbPCGcT09SyrAlT8lstkEqAQhz9rf9ZBpbnAuAX9iJ73NAcDEWL4vgU1
r9DW7twO6GBVBlVD3Xcr1oX50i8y34tEaHqFOmY2RKuSuQfzvLx6rlNBQ0nxqvWk
FBZ1rOyy7BKAVjvSB3ICmzZ4ofPJm7lNFrODkMnql9pHZS2qwpMgN3RBOuoGlftQ
9s7Cx7hiIPE31P4rpEpiN8C3xaEaPXLeEgPUhfiVD+Z7ecUwg4lJr/Y/iaqlCf0h
2TO2a1iypsiYIw2xvdY+PA0BhynhV1yTP3lr78+uN+fWCNwmp3kglwoG+ZYgTkkO
3hQ8vwS79caFzm3Bx11P1UPCm78c5QtrQPTNy6IONUj3Z7NQPq/iK+2Cg+zEKHEH
Q9vECc9FPsl8azo4xY5VcphLjhHlt9ZngR0TFVijgT+/+mzGJeqH8aRU42u8F6w8
yggp5ZuSr+c=
=e4oQ
-----END PGP SIGNATURE-----



<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise