Eldon Sprickerhoff eSentire, Inc.

1. Eldon Sprickerhoff eSentire, Inc. An Examination of Edge Conditions of Wireless Intrusion Detection and Prevention Systems(Bitchslapping WIDS/WIPS)

2. A little background. • I've got a B.Math. in CS from the University of Waterloo but I'm a terrible programmer. • I'm a big fan of IDS systems (was in the audience of LISA 13 when Martin Roesch was working for Stanford Telecom and gave a short talk about “lightweight” intrusion detection). • Skeptical/cynical about marketing promises and hype. • I love the power and flexibility of wireless – am involved in the security aspects of an ongoing build and implementation. • I like to stress systems. There may be a few things discussed today that the FCC and Industry Canada won't necessarily appreciate. But we're examining the Edge Conditions, right? We're making omelettes.

3. What I won't do: • Break the confidentiality clause of any NDA. • So – I won't reveal the name of the client who asked us to test-drive various wireless IDS/IPS systems or even the names or number of the systems tested. • Won't bad-mouth specific vendors. • Not affiliated with any vendors.

4. RF Problems • I'm not a RF Engineer (nor do I play one on TV). • Three concerns: Reflection, Diffraction, Scattering • Large-scale indoors can be harder than outdoors. • Multi-path Reflections • Sharp Corner Diffraction • Surface Scattering (walls, ceilings, floors) • Ugly bags of mostly water (sorry). • Problems in deploying wireless are similar to those deploy WIDS.

5. RF Problems cont'd. • It's possible to find RF dead spots within 3D space mere inches from one another. • Sometimes it comes as a big surprise that 802.11 works as well as it does. • We'll come back to this later.

6. A Brief History • If we're going to get inside WIDS, we should try and take a look at their underpinnings. • Vendors are loathe to divulge their secret sauce, so we look for basic research on signal propagation. • RADAR: An In-Building RF-based User Location and Tracking System. V.N. Padmanabhan and P. Bahl (Microsoft Research, 2000) • Identifying and Tracking Unauthorized 802.11 Cards and Access Points. Robert Foust (;login – August 2002)

7. Basic Triangulation • Remember your trig from high school? • If you know the output power of the transmitter, the gain of the antennas, the power drop-off, and the received signal strength, the location can be obtained with only two samples.

8. Basic Triangulation (cont'd.) • But that's a big IF. • So – introduce a new variable – signal strength ratio. • You end up with a simultaneous equation with three unknowns. • To solve, you need a minimum of three well-placed data points to obtain one or two solutions to the equation.

9. A Little Heavy Lifting • Don't worry, I'll be done with this quickly.

10. Early Findings • Through empirical curve-fitting and sampling, they were able to track “users” (either people with badges or access points) to a median resolution in the range of 2 to 3 meters (about 6 to 9 feet). • Established that the basic theory is sound. • Best results when there is good distance between probes/samples, and a large number of data points is taken (a little contradictory).

11. Limitations • Cannot trace truly passive scanning. • Equipment could only trace one channel at a time (Foust suggested that all cards should stop scanning and pay attention to one particular channel if something “interesting” occurs until enough data is gathered to track down a location). • Acknowledged that methods could occasionally yield results with “extremely large errors” if the input set is not rational.

12. Extrapolate Findings to Today's WIDS/WIPS • Truly passive scanning will go unnoticed. • Not feasible to continually capture/analyse traffic from every single channel within 802.11a/b/g (mostly from a cost perspective). • The math is somewhat easier if you make some assumptions about power. • But... wonky inputs might yield unusual results.

13. Classic IDS/IPS • Choose a “chokepoint” (a channel, a tap in the network, inline). • Capture as much traffic that you can. • Identify a pattern in a discrete portion (or correlate a number of identifiers). • Provide evidence that a pattern was discovered. • Issue an alert and/or perform a pre-specified action.

14. And Pray... • that it's not a false positive. • and that your sensor didn't get overwhelmed. • and that your signature base didn't miss something (thus shattering your false sense of security).

15. As a consumer, what would we like (ideally)? • <grin> Protect me from everything! </grin> • Report obvious “ill intent” traffic. • Report and stop Rogue AP's and ad-hoc networks (even BT). • Stop unauthorized clients from trying to connect to valid AP's. • Perhaps connect to one, and establish a connection out to a server to help identify it, or perform an nmap, AD query, etc.

16. Ideally (cont'd.) • Identify problems within the corporate wireless network (act as a diagnostic tool). • Show a broad picture of the airspace (mapped onto a 3D picture of the environment) with time-delay (think weather radar). • Report use of sniffers.

17. Why perform these tests? • Corporate wireless acceptance is still not a fait accompli; perhaps this can help. • Wireless IDS/IPS is still an emerging technology. • There's no clear winner (and there is still room for a fair amount of market consolidation). • Every vendor has their own approach and philosophy. • Can the client's expectations match up?

18. If you didn't think it was cool to try and break things, you wouldn't be in the “Break It” session.

19. Putting together an attack kit. • Plenty of code available (of varying compile-ready quality). • How many Linux kernels do you want to compile today? • OpenBSD 3.7 incorporated a TON of 802.11g and USB cards. • Auditor CD (if you're lazy). • Gather hardware from around the office (from earlier gigs). • You needed an excuse to go shopping?

20. This slide left intentionally blank.

21. What do we want to discover? • How well can each appliance identify each attack? • Speed and Accuracy • How is the alert presented (clarity)? • Can the appliance link attack to intent? • Minimize operator exhaustion (remember what we've learned from wired IDS). • How well is the threat mitigated?

22. Vendors • We started off with independent appliances. • Later looked at added functionality in existing AP's.

23. Attack • Start off with the slow, easy pitches over the plate. (e.g. add an access point to the network, ad-hoc traffic). There's no reason that any of the appliances should miss these. • Throw a few curve balls (broadcast storms). • Throw a few simultaneous curve balls (blended broadcast storms). • All-out bad craziness. Fear and Loathing. Dogs and cats sleeping together.

24. Let's have a clean fight. • Sensors and supplemental equipment set up as recommended by vendors. • No tweaking or “souping up” of the equipment after the tests start. • Test suite was run in a consistent manner. • Always ran with another network capture probe (to verify that our test suite was actually sending out the traffic we expected).

25. What did we find? • Definitely an emerging technology. • High reliance on SSID's and MAC's. • Still dealing (mostly) at the packet level-alert stage. • Only capturing about 20%-40% of specific traffic (unless you lock a sensor to a channel). • Not consistent at identifying location. • Generally poor at aggregating and correlating events. • Acts as a supplement to your existing diagnostics/forensic wireless system.

26. Some Pretty Bad Things • One vendor's sensor completely froze after 5 minutes of a Disassociation storm. • Didn't alert us to this fact (ostensibly because it was still pingable by the main server). • Another vendor's back-end database became unstable and invalidated the tests. • One of the client's valid access points was turned into a brick halfway through the tests. Unlucky casualty of war or coincidence? • Hardware disruption silently kills most sensors.

27. Somewhat Surprising Things. • Plenty of traffic didn't raise a blip on some products (unless it's specifically in pure capture mode). • CTS, RTS • EAP (Failure, Logoff, Req-Failure, Resp-Failure) • Korek WEP, and plenty of just plain garbage packets.

28. False Positives • Also, discovered a fair amount of false positives (SoftAP alerts raised against some AP implementations, Hunter/Gatherer). • The appliances don't yet have a real feel for what your network is “typically” like.

29. On the plus side... • Nothing died from a full-bore Nessus scan. • Very good detection of rogue access points in the building. • Reasonable precautions taken so that you don't automatically take down a neighbour's access point. • Hand held scanners supplement proximity alerts.

30. Session Containment • Prevent unauthorized stations from connecting to authorized or rogue access points. • Basically a tiny, focused DoS. • But you really need to play nice with your neighbours – it's getting more congested out there. • “Weaknesses in Wireless LAN Session Containment” - Joshua Wright 2005 • Describes how different WIPS perform containment (detection through sequence numbers, signal power, disconnect notice, etc.)

31. Session Containment (cont'd.) • How to configure your MADWIFI driver to ignore deauthentication and disassociation frames. • Doesn't work when the WIPS uses unidirectional deauthentication (against the client only). • But – since the appliance is no longer passive, you can fingerprint it.

32. Edge Conditions - Power • Some of the appliances seemed to make assumptions about gain (antennas and power). • Action memo: Not every access point is 35mW with an omni-directional antenna. • Let's take this to its admittedly ridiculous conclusion – use the test rig like you would a spraygun for paint.

33. Let's Paint This Place!

34. Memories of DC10 • Make a smallish list of SSID's. Be creative. • Generate a random number of IP addresses within a single subnet. • Give your soft AP a vendor-valid yet otherwise random MAC address, and a random channel. • Fill your local ARP table with vendor-valid but otherwise random MAC's for these IP addresses. • Enable WEP (WHAT?) • Choose a random size of packet. • Let loose with a random amount of random UDP/ICMP traffic to each IP! • Lather, Rinse, Repeat with a new SSID/channel.

35. Memories of DC10 cont'd. • Give the sensor a little workout. • Paint the building and give all of the sensors a little workout. • What % of time does a sensor spend on capture versus disassociate? • What is the maximum number of rogue AP's that can be disconnected simultaneously? • Something's got to give!

36. Odds and Ends • Associate, communicate with the switch and shut down the port to which the AP was connected. • Anybody got the MAC address of the back-end database? Or the mail server? The mind reels at the possibilities. • Problems with jumping vlans. • About two months ago, at a conference, one specific vendor downplayed this automatic capability.

37. AP's with IDS functionality • It's a natural and necessary progression of the marketplace – differentiation of product. • Interrupt access point activity and briefly scan for rogue access points. • Sounds pretty good in theory. • In practice, can be be pretty disruptive – depending on the client side. • Older firmware. • Symbol devices. • SIP phones (and IEEE 802.11e Wireless Multimedia Extensions (WME))

38. How to use a rogue AP and not get caught. • Duplicate the (MAC, SSID, channel) of a regular AP on the other side of the building and get lost in the noise of typical wireless traffic (maybe – remember operator exhaustion). • And turn the power down as far as you can. • Find a Symbol Spectrum24 AP/Card combo with full Frequency Hopping. • Try Channel 14. • Covert channel within bad frames (Messieurs Butti et Veysset – session this morning). • Don't come crying to me if you lose your equipment or get fired.

39. Current State of the World • An emerging technology. • Shakedown in the marketplace. • Most still operate purely in “black box” mode. • They don't obviate the need for a handheld device (some vendors sell a “combo package” - supersize it). • Just like wired IDS, WIDS/WIPS operate better with ongoing care (profiling, categorization).

40. Ensuring A Happy Marriage • Reasonable expectations. • Healthy dose of skepticism. • Date first, then live together. • Just like you should test your backup strategy, test your implementation on a regular basis (warn your neighbours).

41. Post-Holiday Wish List • Consider breaking apart functionality (separate sniffers and snipers). • Consider steering away from per-packet alerts and more towards a “horizon” (like the RADAR weather alert) that represents your airspace a la Google Earth to combat operator exhaustion. • Consider wireless heartbeats between sensors. • Specific attacks against hardware and software (tip of the hat to Shmoo re Kismet vulnerability discovery). • Capture traffic flows from AP's for analysis. • BlueTooth? WirelessUSB?

42. Shouts Out! • Special thanks and kudos to Josh Wright – airjack, file2air, email conversations and supplementary material. • Fleeman Anderson & Bird (www.fab-corp.com) • Superpass (www.superpass.com)

50. HTTP Malformed Packets Vulnerability • Appliance is vulnerable to a Denial of Service (DoS) if the HTTP protocol is left enabled on the device. • A few (i.e. 40) specific HTTP packets directed at the affected device can cause the device and all active sessions to freeze and require a manual power cycle. • No authentication is necessary for the packet to be received by the affected device. • tcp/80 is enabled by default when this functionality is configured. • Solution: Disable HTTP redirect, use HTTPS only, wait for the forthcoming patch and advisory.