SlideShare a Scribd company logo

WiFi Intrustion Detection from WireShark SharkFest

•
•
David Sweigert
David Sweigert

Kismet is an open source wireless intrusion detection system that can be used to monitor wireless networks passively. It detects common attacks like jamming, impersonation, and client hijacking. However, it has limitations in fully secured networks using WPA-EAP and cannot prevent misuse of open networks. Effective wireless security requires using encrypted protocols like WPA2 and educating users, as well as monitoring for threats using tools like Kismet.

1 of 109
Download to read offline
Wireless Intrusion Detection Mike Kershaw, Kismet Wireless 1
2
Wi-Fi & Security • Everything uses Wi-Fi now • EVERYTHING • “How do I get my IV pump on WEP?” • Set up properly, there's nothing wrong with Wi-Fi security • Doing it right is HARD and complicated 3
Why do we care? • You need to know something is going on • Are there rogue APs on your internal network? • Even if you can't do anything about a DoS attack, you need to know it's happening • Your LAN might be a WAN if you're not careful 4
Porous borders • Physical company networks used to be hard to penetrate • Not inside the building? Not on the LAN • No-one brought their own device • No-one was connecting their work computer to random networks at airport/starbucks/conference 5
Security goes both ways • As a user, you (should) care about your own security; credit card, personal information, general exposure • As a network admin, you (should) care about exfiltration of data / hidden devices on your network, and outside attacks 6
Users are wily • If you don't give them what they want, they'll probably do it themselves • If they do it themselves, they probably won't do a very good job on security • And you won't even know it's there 7 * Yes, that's Dr Wily from Megaman
Options? So what are your options? 8
Integrated WIDS • Integrated / Enterprise WIDS • Build into your AP infrastructure • Very effective, but usually very expensive, implies enterprise Wi-Fi infrastructure • Great if you have it, if you don't, or a customer does not, you'll need to find another way 9
Independent/Overlay WIDS • Passive monitors distributed throughout the physical area of the wireless network • Passively monitor wireless data independent of the network core • Multiple commercial offerings • Kismet can operate in distributed mode 10
Wi-Fi Architecture • Wi-Fi acts both as shared media and switched media, depending on the configuration! • When using a Open or WEP configuration, all traffic is visible to any user • When using WPA each user has a per-association key, so traffic isn't visible (usually) 11
Monitoring wireless • Multiple methods of monitoring, not all equal • “Scanning mode” - same mechanism a client uses to connect, asks “What access points are available” • “Monitor mode” - Requires support in the driver, such as Linux, or AirPCAP • “Promsic mode” - Doesn't mean much in WiFi 12
WIDS can be hard • Many vulnerabilities in Wi-Fi are not fingerprintable in traditional way • Protocol violations can often be completely legit packets, just used in a weird way • Have to be able to monitor trends over time not just single packet events 13
Who is coming after you • Lots of problems that may or may not be malicious attackers • Who is coming after to you? • Can you assume it's safe? 14
“oops” • Non-malicious accidental leakage from an employee bringing in an insecure AP • Not an attack per se • But can greatly enable an attacker near you if one is so inclined 15
General jackasses • Learned how to do a DoS and likes it • Prevalent in conferences, public venues, etc • Not necessarily too prevalent in corporate • Most interference in enterprise probably from misconfigured systems, noisy devices, congestion, etc 16
Indirect attacks in the wild • Looking to compromise users in the wild • Airports, conferences, etc • Might take advantage of your company, might just be looking for credit card payments 17
Targetted external attacks • Someone is trying to get into your company • Has funding, reasons, and tools • Is willing to tresspass & directly attack • Employees leaving the network and going to coffee shops, etc are excellent targets • You're probably screwed 18
Targetted internal attacks • Employee trying to sell secrets • Willing to bring hardware into the facility specifically to leak data • May be disguised as an “oops!” • You're probably screwed, but at least you can prosecute 19
What gets used? 20
Types of attacks • Wi-Fi is vulnerable to many types of attacks • RF denial of service • Protocol/L2 denial of service • Impersonation • Client Hijacking • Direct attacks against devices and drivers 21
RF Denial of Service • Wi-Fi operates in FCC ISM (Industrial, Scientific, and Medical) frequencies • Regulated, but not the same way commercially licensed bands are regulated • Easy to get transmitters • Lots of legit devices, too! 22
RF Jamming • Licensed “jammers”: Analog devices, security cameras, microwave ovens, baby monitors, cordless phones • Unlicensed jammers: Wavebubble, modified wireless cards, home-brew devices 23
Wavebubble jammer 24
Detecting jamming • Using hardware such as a Wi-Spy and the Kismet-Spectools plugin, or EyePA • No actions can be taken other than “look for the person and hit them with a brick” • Detecting jamming usually requires dedicated hardware 25
Detecting jamming 26
Protocol DoS • 802.11 is a very naïve protocol • Management frames have little to no protection • 802.11w, 802.11r, 802.11u are finally adding management protection, over a decade later. • Trivial to mess with 802.11 • Not much you can do about it 27
Fake saturation • 802.11 uses CSMC/CA – unlike shared Ethernet, actively tries to avoid collisions • “I'm going to transmit for 500ms, everyone else stay quiet” • Attacker can saturate with spoofed RTS packets • No-one will talk but channel will be idle! 28
In action 29
Detecting saturation attacks • Can look for absurdly long CTS/RTS durations • Can look for CTS/RTS without corresponding data • Both vulnerable to false positives, especially if your monitoring hardware can't see all data • 11g seeing 11n will see control frames but not data, for example 30
Get off my lawn: Deauth/disassoc • Network tells clients when they're allowed in, and when they're being disconnected • Of course this is unencrypted... • Deauthentiction or disassociation packets both cause the client to leave • All you need is the BSSID and client MAC 31
Detecting deauth/disassoc • Easy to detect broadcast attacks – AP will rarely send them legitimately • Can try to fingerprint based on deauth rates, some degree of false positive 32
WPS Reaver • WPS meant to make it “easy” to connect to “secure” networks • Supposed to protect settings with an 8-digit PIN • 10^8 = 100,000,000 possible PINs • Except... 33
When is 100m = 11k? • Handshake broken into 2 messages, one 4 digits and one 3... The last character is a checksum! • Each message validated independently • Errors reported for each half • So pin is really 10^4 + 10^3, or 11,000. • Ooooops. 34
What do you get? • WPS is meant to configure clients with the security settings of the network • Break WPS, get everything you need to join the network • … Or become the network 35
Detecting Reaver attacks • Legitimate WPS traffic should be very irregular • Only new users joining the network for the first time • 11,000 is still a lot of requests • Floods = suspicion • … But why are you using WPS!? • Many consumer routers can't turn it off! 36
Impersonation attacks • What identifies an access point? • The network name / SSID, and encryption options • What identifies an open access point? • The network name … that's it. 37
Extremely vulnerable • Roaming happens by looking for other networks with the same name • Clients will happily stick to the strongest AP • Only unique identification as far as Wi-Fi is concerned is SSID and encryption 38
Beacons • Network sends a beacon ~10 times a second • Beacon contains SSID • What prevents someone from bringing up a network with the same name? • Absolutely nothing 39
Two main ways to impersonate • Method 1: Bring up an another AP with the same network name – Noisy but effective • Method 2: Hijack clients as they try to connect via Karma attack – Less noisy, still effective 40
Client connection • Client sends probe request to access point asking to join network “SomeNet” • Access point responds with a probe response allowing or rejecting the client • Client now knows the MAC address of the AP and completes the association 41
Spoofing the network name • 802.11 roaming works by multiple networks with the same name, client picks the strongest one • It's “normal” to have multiple access points with the same SSID • Almost impossible for a user in the “connect to wireless” window to determine something is wrong 42
Karma attack • Client sends probe request for an existing AP • Karma device responds with probe response with its own MAC address • Client is now connected to hostile AP • But the hostile AP isn't beaconing and won't show up in normal scanning lists! 43
Strengthening the system • WPA-PSK is OK if you don't share the PSK and it's reasonably strong • As soon as you share the PSK, the two unique pieces of information, the SSID and the PSK, are public • No good solution for public networks 44
WPA-EAP • WPA-EAP methods provide secure TLS backed authentication • PEAP, TTLS about the only ones supported on a wide range of devices / operating systems • Require a SSL signing chain and populating every client system with them... a big pain 45
Impersonation impact • Once you control the clients view of the network, you ARE the network • I don't have to own the Internet, I just have to own your Internet 46
Impersonation impact • If you're the gateway, you control all traffic • DNS, HTTP, IP ranges • Monitor traffic, inject into streams • Block encryption and hope user falls back to open • Can't decode SSL/SSH but CAN present bogus certs if user is dumb 47
Stream hijacking • Unencrypted networks are basically 1980s style shared media Ethernet • All the old-school attacks are back again! • TCP stream hijacking trivially easy • Both clients and network infrastructure are vulnerable 48
TCP hijacking ● TCP streams secure from tampering only because sequence numbers unknown ● When you can see those and can race the remote host, can hijack the TCP stream ● Allows browser injection attacks, other application stream attacks ● Allows hijacking streams from clients into servers as well 49
Extremely pernicious ● Targets your users in the field ● No easy way to know it's happening ● Turns zero-threat actions (going to Twitter, CNN, whatever) into high-risk high-threat actions ● Exposes persistent attacks via browser cache ● Exposes DNS hijacking vulnerabilities 50
Detecting stream hijacking • Very difficult • Hijacker can use extremely low power antenna to target a specific user in an area • Requires more knowledge than most sniffers can have • May not trigger IP level IDS systems either 51
Direct attacks against drivers • Drivers have been better, lately, but still a vector of attack • Packets are complex and difficult to parse, and driver authors get it wrong • Vulnerability in driver can lead to kernel-level compromise, extremely bad 52
Example driver attacks • Prism2/Orinoco firmware vulnerable to a probe response with SSID length of 0 • Broadcom windows drivers vulnerable to buffer overflow • Dlink windows drivers vulnerable to support rates buffer overflow 53
Easy to detect... sort of • Driver attacks at least are easy to detect... • … If you're watching for them • … In the right place at the right time • … And you know about them 54
Client spoofing • Spoofing a client MAC is easy • Can duplicate an authenticated client • Bypasses login requirements on open networks 55
Detecting client spoofing • Different operating systems from the same MAC in DHCP requests • Different operating systems reported by browser traffic • Lots of weird tcp errors when different stacks get bogons 56
Application attacks • Ultimately Wi-Fi just carries data • Same attacks against systems on wired networks don't care if it's on wireless • Border IDS can still help – so long as the user is within your border 57
Application attacks • Border IDS can be placed where wireless bridges to wired network, treating wireless as a hostile external network • Overlay WIDS can feed data to traditional IDS • Kismet can feed Snort via virtual network interface (tun/tap in Linux) 58
How easy is it to perform attacks? • Aircrack-NG + Linux • Wi-Fi Pineapple • PwnPad • PwnPlug • Metasploit + LORCON + Linux 59
Wi-Fi Pineapple 60
Pineapple • Karma, Aircrack, Kismet • Small box, battery powered • Capable of 3G/LTE backhaul 61
PwnPlug 62 • Looks like power adapter • Would you notice it in your office?
Attack mitigation • DoS attacks are more or less impossible to defend against, even if we solve the protocol vulns • WPA2 CCMP (NOT WEP, NOT TKIP) • WPA2-PSK is only as secure as the PSK – know the PSK, can spoof the AP • WPA-EAP good, hard to set up and enforce 63
How bad is WEP, really? • HORRIBLE • So bad even slow-moving standards groups like PCI have finally said “Don't use WEP” • Trivially easy to crack a WEP network • In seconds. 64
WEP is so bad... • How bad is it? • It's so bad that thanks to AircrackNG code in a plugin, Kismet can try to automatically crack it • Every 5,000 packets • Just because it's there. 65
Where WIDS falls down • We can protect a single network pretty well • WPA+EAP is very secure but hard to config • Once users leave the secure network, all bets are off • You can't out-engineer stupid. “Free public wifi!?” • Users want Internet, not security 66
See no evil • If you can't see what's going on you can't do anything • 802.11n – harder to see multi-stream, increased data stream to process • 802.11ac – will be even harder • Super-fast tech pushing towards central AP WIDS 67
Things we can't currently fix • Open networks are insecureable • There is no way to maintain trust – no unique information in an open network • WPA-PSK only provides trust when the PSK is unknown, no good for public networks • WPA-EAP needs cert chain, difficult and dangerous 68
Active defense • Actively defend via injection of packets • Use the same attacks • Difficult to enforce in shared airspace, unless you're the only occupant in a building... • Kismet doesn't, but could with plugins 69
Corralling clients • Can attempt to fence clients in • Once you know they're legit try to keep them from connecting to illegitimate Aps • Can try to prevent specific clients from roaming or shut down hostile AP entirely • Requires very good overlay coverage 70
Things you CAN do • Policy enforcement on company hardware • “You can't plug that in, you can't use that work laptop at Starbucks” • Passive interference – cages, metal walls, etc • … Of course your users will hate you and try to find a way around you, and probably will 71
Things you CAN'T do • Run jammers – the FCC will get very mad, even on Part15 networks • Interfere with cell phones – again, the FCC will be mad • Try to hack-back – well, I guess you CAN, but it's a REALLY bad idea 72
Kismet stuff! 73
Kismet • Started as purely a network discovery tool • Evolved into trend tracking, WIDS, etc • Extensible via plugins and clients • Interfaces with existing IDS tools • Wireshark is concerned with packets, Kismet is concerned with devices and trends 74
Kismet basic operation • Places one or more WiFi cards into monitor mode • Listens to all the packets in the air • Infers wireless networks, clients, crypto settings, etc from raw packets • Discovers clients, hidden nodes, so on • Can measure data patterns, channel usage, etc 75
Kismet IDS • Both signature and trend based IDS • Can tie into traditional IDS like Snort via tun/tap • Can tie into other IDS/Alert systems via Kismet client protocol 76
Supported Kismet platforms • Linux is still the best supported platform • Some OSX support, but Apple likes to break drivers • Some Windows support, with AirPCAP • Some BSDs will work, depends on the variant and drivers 77
Getting the latest version • Your distribution probably lies to you • Latest release is 2013-03 • Debian and Ubuntu have been shipping a 2008 version. This is bad. • Website always has the latest 78
Selecting hardware • Nearly any wireless card can do monitor mode now (in Linux) • Generally “best” cards are Atheros based • External antenna jacks are almost always better • To capture on multiple channels simultaneous, you need multiple cards 79
Host hardware ● Kismet is not particularly CPU expensive ● … but it IS fairly RAM hungry ● The more RAM the better – for long-term capture in busy environments, 512M+ is best, more would be better ● Drones use nearly no CPU or RAM since they don't need to track devices 80
Simpler than before • Used to have to know what chipset & driver • Thanks to a unified driver architecture nearly everything on Linux can be auto-detected • Provide an interface (-c wlan0) and Kismet figures out the rest automatically • Out-of-kernel drivers still suck 81
WIDS to Syslog • Two ways to get from Kismet alerts to syslog • Syslog plugin directly logs from Kismet to the localhost syslog, can be directed from there to central • Syslog ruby example can be run on any system and connects to the Kismet server to get alerts and log 82
Kismet to Snort • Tuntap export allows virtual 802.11 device on Linux • Can be opened/closed repeatedly w/out disrupting Kismet • Can point TCPDump / Wireshark / Snort at the tuntap interface • Works just like a normal network interface 83
Expanding Kismet - Distributed Capture • Kismet supports remote capture via “Kismet Drones” • Remote capture can run on very limited hardware • Captures packets and shoves raw data through the pipe, no packet processing overhead beyond network transmit 84
Expanding Kismet - Clients • TCP Server/Client protocol • Kismet UI just a network client • Can talk to Kismet with Telnet if you're determined • Many tasks can be completed without a plugin – just write a client! • Example Ruby code for clients in < 100 lines 85
Kismet protocol • Similar to IMAP • Multiple sentences, can enable specific fields • Anything displayed in the Kismet UI can be gotten from the client • Raw packets not transmitted for sake of bandwidth 86
Kismet protocol 87
Expanding Kismet - Plugins • Plugins written in C++ • Directly interface with Kismet internals • Can be for the server or client • Harder to write but as powerful as Kismet itself • Internal architecture all basically statically compiled plugins 88
Server plugins • Able to define new capture source types • Able to define new PHY layers (ie Ubertooth, etc) • Able to create new log types • Able to create new network protocols, or entirely new network servers 89
Client plugins • Able to interface to server sentences • Able to create new ncurses widgets in the UI • Able to modify menus, etc to add preference options and such 90
Wi-Fi – One of Many 91
Going beyond Wi-Fi • What about other protocols? • Attackers can definitely use alternate networking standards once on your network • Do you know what devices are bridged to your network? • What about SCADA, inventory, etc systems? 92
Kismet Phy-Neutral • Significant rewrite of Kismet core tracker • Instead of being 802.11 centric, will be able to take plugins for any packetized PHY type • Will also be able to take plugins for non-packetized device detection (some SDR, etc) • Common device list across all phy types 93
Kismet Phy-Neutral 94
PHY-N Advantages • Much simpler plugins – tracking, logging, basic display handled by Kismet • Designed to produce usable consistent logs from any set of input types • Kismet becomes central data gatherer for any wireless data 95
PHY-N support in progress or planned • Ubertooth and Ubertooth BTLE – in progress, supported in Git • Kisbee – 802.15.4 capture, supported but hard to classify networks • RFCat / FSK – Planning classification still • SDR – HackRF, etc can in theory talk any protocol 96
Writing for PHY-N • Each device record has a common component • Additional information is attached as tagged blobs of data • Phy-N plugin can define any additional data for any device it needs 97
So what else do we care about? • Other protocols used for important things • “Internet of Things” is already here – it may be your inventory or factory control • “Active” inventory tags use things like Zigbee • Zigbee often used on sensor networks and physical devices 98
The value of data • Can you trust your sensor network? • What can go wrong if someone can spoof it? • Is it connected to your company Intranet? • Does it control security or safety responses? • Can it leak internal processes? (Bake @ 1500F for 20 minutes, then...) 99
Heist of the century • When used for inventory control, how is it checked? • Can someone spoof it and try to remove the original tagged item? • Place original tag in faraday cage, bridge to spoof tag over cell, replicate packets at original location • Silly? What if tag is on semi truck of components? 100
Loss of control • What does your sensor network control? • How much money would you lose if your factory crashed? • Can your network be seen from outside your perimeter? • If you're not looking, you can't know 101
Ninja-level problems • Attackers may not even need to be w/in wireless range • If a packet format is FF1245678 and someone sends a wired packet of FF123FF45678 • If something causes the beginning of the packet to corrupt... 102
Go away PIP nobody likes you • Then the second part of the packet may be detected as a complete frame and handled as if it was the original data! • Forge wireless from the wire! • Zigbee is especially vulnerable b/c of simplicity, see work by Travis Goodspeed 103
Different != better • Custom protocols haven't been exampled as closely • SDR is now really cheap • Simpler protocols may have less or no protection against injection/replay/packet in packet • Do you know every wireless device on your net? 104
Other thoughts on wireless data leakage • Do you still use pagers to communicate to staff? • Bridge your email directly to them? • Did you know those are unencrypted? • And you can pick them up w/ a $20 USB SDR? • Of course, that's illegal. • And a criminal would never break the law... 105
Things you probably send to pagers ● Router interface names ● Alarm system updates ● Webserver failures... with internal names ● Internal server names ● When someone is on duty ● What monitoring SW you run ● What email servers you run ● … Just sayin'... 106
Some folk'll never commit a felony to break into your company... ● … But then again, some folks'll ● Just because it's illegal to monitor or attack something doesn't mean someone won't do it ● They're a criminal, after all. ● Be aware of as many vectors as you can and try to be capable of monitoring, etc 107
Recap • If you don't know to look you can't know how bad it is • Look in unexpected places • Everything has security problems; arm yourself with more info • More wireless tech = more things to monitor 108
Q&A Questions? Anyone? Bueller? 109

More Related Content

WiFi Intrustion Detection from WireShark SharkFest

  • 1. Wireless Intrusion Detection Mike Kershaw, Kismet Wireless 1
  • 2. 2
  • 3. Wi-Fi & Security • Everything uses Wi-Fi now • EVERYTHING • “How do I get my IV pump on WEP?” • Set up properly, there's nothing wrong with Wi-Fi security • Doing it right is HARD and complicated 3
  • 4. Why do we care? • You need to know something is going on • Are there rogue APs on your internal network? • Even if you can't do anything about a DoS attack, you need to know it's happening • Your LAN might be a WAN if you're not careful 4
  • 5. Porous borders • Physical company networks used to be hard to penetrate • Not inside the building? Not on the LAN • No-one brought their own device • No-one was connecting their work computer to random networks at airport/starbucks/conference 5
  • 6. Security goes both ways • As a user, you (should) care about your own security; credit card, personal information, general exposure • As a network admin, you (should) care about exfiltration of data / hidden devices on your network, and outside attacks 6
  • 7. Users are wily • If you don't give them what they want, they'll probably do it themselves • If they do it themselves, they probably won't do a very good job on security • And you won't even know it's there 7 * Yes, that's Dr Wily from Megaman
  • 8. Options? So what are your options? 8
  • 9. Integrated WIDS • Integrated / Enterprise WIDS • Build into your AP infrastructure • Very effective, but usually very expensive, implies enterprise Wi-Fi infrastructure • Great if you have it, if you don't, or a customer does not, you'll need to find another way 9
  • 10. Independent/Overlay WIDS • Passive monitors distributed throughout the physical area of the wireless network • Passively monitor wireless data independent of the network core • Multiple commercial offerings • Kismet can operate in distributed mode 10
  • 11. Wi-Fi Architecture • Wi-Fi acts both as shared media and switched media, depending on the configuration! • When using a Open or WEP configuration, all traffic is visible to any user • When using WPA each user has a per-association key, so traffic isn't visible (usually) 11
  • 12. Monitoring wireless • Multiple methods of monitoring, not all equal • “Scanning mode” - same mechanism a client uses to connect, asks “What access points are available” • “Monitor mode” - Requires support in the driver, such as Linux, or AirPCAP • “Promsic mode” - Doesn't mean much in WiFi 12
  • 13. WIDS can be hard • Many vulnerabilities in Wi-Fi are not fingerprintable in traditional way • Protocol violations can often be completely legit packets, just used in a weird way • Have to be able to monitor trends over time not just single packet events 13
  • 14. Who is coming after you • Lots of problems that may or may not be malicious attackers • Who is coming after to you? • Can you assume it's safe? 14
  • 15. “oops” • Non-malicious accidental leakage from an employee bringing in an insecure AP • Not an attack per se • But can greatly enable an attacker near you if one is so inclined 15
  • 16. General jackasses • Learned how to do a DoS and likes it • Prevalent in conferences, public venues, etc • Not necessarily too prevalent in corporate • Most interference in enterprise probably from misconfigured systems, noisy devices, congestion, etc 16
  • 17. Indirect attacks in the wild • Looking to compromise users in the wild • Airports, conferences, etc • Might take advantage of your company, might just be looking for credit card payments 17
  • 18. Targetted external attacks • Someone is trying to get into your company • Has funding, reasons, and tools • Is willing to tresspass & directly attack • Employees leaving the network and going to coffee shops, etc are excellent targets • You're probably screwed 18
  • 19. Targetted internal attacks • Employee trying to sell secrets • Willing to bring hardware into the facility specifically to leak data • May be disguised as an “oops!” • You're probably screwed, but at least you can prosecute 19
  • 21. Types of attacks • Wi-Fi is vulnerable to many types of attacks • RF denial of service • Protocol/L2 denial of service • Impersonation • Client Hijacking • Direct attacks against devices and drivers 21
  • 22. RF Denial of Service • Wi-Fi operates in FCC ISM (Industrial, Scientific, and Medical) frequencies • Regulated, but not the same way commercially licensed bands are regulated • Easy to get transmitters • Lots of legit devices, too! 22
  • 23. RF Jamming • Licensed “jammers”: Analog devices, security cameras, microwave ovens, baby monitors, cordless phones • Unlicensed jammers: Wavebubble, modified wireless cards, home-brew devices 23
  • 25. Detecting jamming • Using hardware such as a Wi-Spy and the Kismet-Spectools plugin, or EyePA • No actions can be taken other than “look for the person and hit them with a brick” • Detecting jamming usually requires dedicated hardware 25
  • 27. Protocol DoS • 802.11 is a very naïve protocol • Management frames have little to no protection • 802.11w, 802.11r, 802.11u are finally adding management protection, over a decade later. • Trivial to mess with 802.11 • Not much you can do about it 27
  • 28. Fake saturation • 802.11 uses CSMC/CA – unlike shared Ethernet, actively tries to avoid collisions • “I'm going to transmit for 500ms, everyone else stay quiet” • Attacker can saturate with spoofed RTS packets • No-one will talk but channel will be idle! 28
  • 30. Detecting saturation attacks • Can look for absurdly long CTS/RTS durations • Can look for CTS/RTS without corresponding data • Both vulnerable to false positives, especially if your monitoring hardware can't see all data • 11g seeing 11n will see control frames but not data, for example 30
  • 31. Get off my lawn: Deauth/disassoc • Network tells clients when they're allowed in, and when they're being disconnected • Of course this is unencrypted... • Deauthentiction or disassociation packets both cause the client to leave • All you need is the BSSID and client MAC 31
  • 32. Detecting deauth/disassoc • Easy to detect broadcast attacks – AP will rarely send them legitimately • Can try to fingerprint based on deauth rates, some degree of false positive 32
  • 33. WPS Reaver • WPS meant to make it “easy” to connect to “secure” networks • Supposed to protect settings with an 8-digit PIN • 10^8 = 100,000,000 possible PINs • Except... 33
  • 34. When is 100m = 11k? • Handshake broken into 2 messages, one 4 digits and one 3... The last character is a checksum! • Each message validated independently • Errors reported for each half • So pin is really 10^4 + 10^3, or 11,000. • Ooooops. 34
  • 35. What do you get? • WPS is meant to configure clients with the security settings of the network • Break WPS, get everything you need to join the network • … Or become the network 35
  • 36. Detecting Reaver attacks • Legitimate WPS traffic should be very irregular • Only new users joining the network for the first time • 11,000 is still a lot of requests • Floods = suspicion • … But why are you using WPS!? • Many consumer routers can't turn it off! 36
  • 37. Impersonation attacks • What identifies an access point? • The network name / SSID, and encryption options • What identifies an open access point? • The network name … that's it. 37
  • 38. Extremely vulnerable • Roaming happens by looking for other networks with the same name • Clients will happily stick to the strongest AP • Only unique identification as far as Wi-Fi is concerned is SSID and encryption 38
  • 39. Beacons • Network sends a beacon ~10 times a second • Beacon contains SSID • What prevents someone from bringing up a network with the same name? • Absolutely nothing 39
  • 40. Two main ways to impersonate • Method 1: Bring up an another AP with the same network name – Noisy but effective • Method 2: Hijack clients as they try to connect via Karma attack – Less noisy, still effective 40
  • 41. Client connection • Client sends probe request to access point asking to join network “SomeNet” • Access point responds with a probe response allowing or rejecting the client • Client now knows the MAC address of the AP and completes the association 41
  • 42. Spoofing the network name • 802.11 roaming works by multiple networks with the same name, client picks the strongest one • It's “normal” to have multiple access points with the same SSID • Almost impossible for a user in the “connect to wireless” window to determine something is wrong 42
  • 43. Karma attack • Client sends probe request for an existing AP • Karma device responds with probe response with its own MAC address • Client is now connected to hostile AP • But the hostile AP isn't beaconing and won't show up in normal scanning lists! 43
  • 44. Strengthening the system • WPA-PSK is OK if you don't share the PSK and it's reasonably strong • As soon as you share the PSK, the two unique pieces of information, the SSID and the PSK, are public • No good solution for public networks 44
  • 45. WPA-EAP • WPA-EAP methods provide secure TLS backed authentication • PEAP, TTLS about the only ones supported on a wide range of devices / operating systems • Require a SSL signing chain and populating every client system with them... a big pain 45
  • 46. Impersonation impact • Once you control the clients view of the network, you ARE the network • I don't have to own the Internet, I just have to own your Internet 46
  • 47. Impersonation impact • If you're the gateway, you control all traffic • DNS, HTTP, IP ranges • Monitor traffic, inject into streams • Block encryption and hope user falls back to open • Can't decode SSL/SSH but CAN present bogus certs if user is dumb 47
  • 48. Stream hijacking • Unencrypted networks are basically 1980s style shared media Ethernet • All the old-school attacks are back again! • TCP stream hijacking trivially easy • Both clients and network infrastructure are vulnerable 48
  • 49. TCP hijacking ● TCP streams secure from tampering only because sequence numbers unknown ● When you can see those and can race the remote host, can hijack the TCP stream ● Allows browser injection attacks, other application stream attacks ● Allows hijacking streams from clients into servers as well 49
  • 50. Extremely pernicious ● Targets your users in the field ● No easy way to know it's happening ● Turns zero-threat actions (going to Twitter, CNN, whatever) into high-risk high-threat actions ● Exposes persistent attacks via browser cache ● Exposes DNS hijacking vulnerabilities 50
  • 51. Detecting stream hijacking • Very difficult • Hijacker can use extremely low power antenna to target a specific user in an area • Requires more knowledge than most sniffers can have • May not trigger IP level IDS systems either 51
  • 52. Direct attacks against drivers • Drivers have been better, lately, but still a vector of attack • Packets are complex and difficult to parse, and driver authors get it wrong • Vulnerability in driver can lead to kernel-level compromise, extremely bad 52
  • 53. Example driver attacks • Prism2/Orinoco firmware vulnerable to a probe response with SSID length of 0 • Broadcom windows drivers vulnerable to buffer overflow • Dlink windows drivers vulnerable to support rates buffer overflow 53
  • 54. Easy to detect... sort of • Driver attacks at least are easy to detect... • … If you're watching for them • … In the right place at the right time • … And you know about them 54
  • 55. Client spoofing • Spoofing a client MAC is easy • Can duplicate an authenticated client • Bypasses login requirements on open networks 55
  • 56. Detecting client spoofing • Different operating systems from the same MAC in DHCP requests • Different operating systems reported by browser traffic • Lots of weird tcp errors when different stacks get bogons 56
  • 57. Application attacks • Ultimately Wi-Fi just carries data • Same attacks against systems on wired networks don't care if it's on wireless • Border IDS can still help – so long as the user is within your border 57
  • 58. Application attacks • Border IDS can be placed where wireless bridges to wired network, treating wireless as a hostile external network • Overlay WIDS can feed data to traditional IDS • Kismet can feed Snort via virtual network interface (tun/tap in Linux) 58
  • 59. How easy is it to perform attacks? • Aircrack-NG + Linux • Wi-Fi Pineapple • PwnPad • PwnPlug • Metasploit + LORCON + Linux 59
  • 61. Pineapple • Karma, Aircrack, Kismet • Small box, battery powered • Capable of 3G/LTE backhaul 61
  • 62. PwnPlug 62 • Looks like power adapter • Would you notice it in your office?
  • 63. Attack mitigation • DoS attacks are more or less impossible to defend against, even if we solve the protocol vulns • WPA2 CCMP (NOT WEP, NOT TKIP) • WPA2-PSK is only as secure as the PSK – know the PSK, can spoof the AP • WPA-EAP good, hard to set up and enforce 63
  • 64. How bad is WEP, really? • HORRIBLE • So bad even slow-moving standards groups like PCI have finally said “Don't use WEP” • Trivially easy to crack a WEP network • In seconds. 64
  • 65. WEP is so bad... • How bad is it? • It's so bad that thanks to AircrackNG code in a plugin, Kismet can try to automatically crack it • Every 5,000 packets • Just because it's there. 65
  • 66. Where WIDS falls down • We can protect a single network pretty well • WPA+EAP is very secure but hard to config • Once users leave the secure network, all bets are off • You can't out-engineer stupid. “Free public wifi!?” • Users want Internet, not security 66
  • 67. See no evil • If you can't see what's going on you can't do anything • 802.11n – harder to see multi-stream, increased data stream to process • 802.11ac – will be even harder • Super-fast tech pushing towards central AP WIDS 67
  • 68. Things we can't currently fix • Open networks are insecureable • There is no way to maintain trust – no unique information in an open network • WPA-PSK only provides trust when the PSK is unknown, no good for public networks • WPA-EAP needs cert chain, difficult and dangerous 68
  • 69. Active defense • Actively defend via injection of packets • Use the same attacks • Difficult to enforce in shared airspace, unless you're the only occupant in a building... • Kismet doesn't, but could with plugins 69
  • 70. Corralling clients • Can attempt to fence clients in • Once you know they're legit try to keep them from connecting to illegitimate Aps • Can try to prevent specific clients from roaming or shut down hostile AP entirely • Requires very good overlay coverage 70
  • 71. Things you CAN do • Policy enforcement on company hardware • “You can't plug that in, you can't use that work laptop at Starbucks” • Passive interference – cages, metal walls, etc • … Of course your users will hate you and try to find a way around you, and probably will 71
  • 72. Things you CAN'T do • Run jammers – the FCC will get very mad, even on Part15 networks • Interfere with cell phones – again, the FCC will be mad • Try to hack-back – well, I guess you CAN, but it's a REALLY bad idea 72
  • 74. Kismet • Started as purely a network discovery tool • Evolved into trend tracking, WIDS, etc • Extensible via plugins and clients • Interfaces with existing IDS tools • Wireshark is concerned with packets, Kismet is concerned with devices and trends 74
  • 75. Kismet basic operation • Places one or more WiFi cards into monitor mode • Listens to all the packets in the air • Infers wireless networks, clients, crypto settings, etc from raw packets • Discovers clients, hidden nodes, so on • Can measure data patterns, channel usage, etc 75
  • 76. Kismet IDS • Both signature and trend based IDS • Can tie into traditional IDS like Snort via tun/tap • Can tie into other IDS/Alert systems via Kismet client protocol 76
  • 77. Supported Kismet platforms • Linux is still the best supported platform • Some OSX support, but Apple likes to break drivers • Some Windows support, with AirPCAP • Some BSDs will work, depends on the variant and drivers 77
  • 78. Getting the latest version • Your distribution probably lies to you • Latest release is 2013-03 • Debian and Ubuntu have been shipping a 2008 version. This is bad. • Website always has the latest 78
  • 79. Selecting hardware • Nearly any wireless card can do monitor mode now (in Linux) • Generally “best” cards are Atheros based • External antenna jacks are almost always better • To capture on multiple channels simultaneous, you need multiple cards 79
  • 80. Host hardware ● Kismet is not particularly CPU expensive ● … but it IS fairly RAM hungry ● The more RAM the better – for long-term capture in busy environments, 512M+ is best, more would be better ● Drones use nearly no CPU or RAM since they don't need to track devices 80
  • 81. Simpler than before • Used to have to know what chipset & driver • Thanks to a unified driver architecture nearly everything on Linux can be auto-detected • Provide an interface (-c wlan0) and Kismet figures out the rest automatically • Out-of-kernel drivers still suck 81
  • 82. WIDS to Syslog • Two ways to get from Kismet alerts to syslog • Syslog plugin directly logs from Kismet to the localhost syslog, can be directed from there to central • Syslog ruby example can be run on any system and connects to the Kismet server to get alerts and log 82
  • 83. Kismet to Snort • Tuntap export allows virtual 802.11 device on Linux • Can be opened/closed repeatedly w/out disrupting Kismet • Can point TCPDump / Wireshark / Snort at the tuntap interface • Works just like a normal network interface 83
  • 84. Expanding Kismet - Distributed Capture • Kismet supports remote capture via “Kismet Drones” • Remote capture can run on very limited hardware • Captures packets and shoves raw data through the pipe, no packet processing overhead beyond network transmit 84
  • 85. Expanding Kismet - Clients • TCP Server/Client protocol • Kismet UI just a network client • Can talk to Kismet with Telnet if you're determined • Many tasks can be completed without a plugin – just write a client! • Example Ruby code for clients in < 100 lines 85
  • 86. Kismet protocol • Similar to IMAP • Multiple sentences, can enable specific fields • Anything displayed in the Kismet UI can be gotten from the client • Raw packets not transmitted for sake of bandwidth 86
  • 88. Expanding Kismet - Plugins • Plugins written in C++ • Directly interface with Kismet internals • Can be for the server or client • Harder to write but as powerful as Kismet itself • Internal architecture all basically statically compiled plugins 88
  • 89. Server plugins • Able to define new capture source types • Able to define new PHY layers (ie Ubertooth, etc) • Able to create new log types • Able to create new network protocols, or entirely new network servers 89
  • 90. Client plugins • Able to interface to server sentences • Able to create new ncurses widgets in the UI • Able to modify menus, etc to add preference options and such 90
  • 91. Wi-Fi – One of Many 91
  • 92. Going beyond Wi-Fi • What about other protocols? • Attackers can definitely use alternate networking standards once on your network • Do you know what devices are bridged to your network? • What about SCADA, inventory, etc systems? 92
  • 93. Kismet Phy-Neutral • Significant rewrite of Kismet core tracker • Instead of being 802.11 centric, will be able to take plugins for any packetized PHY type • Will also be able to take plugins for non-packetized device detection (some SDR, etc) • Common device list across all phy types 93
  • 95. PHY-N Advantages • Much simpler plugins – tracking, logging, basic display handled by Kismet • Designed to produce usable consistent logs from any set of input types • Kismet becomes central data gatherer for any wireless data 95
  • 96. PHY-N support in progress or planned • Ubertooth and Ubertooth BTLE – in progress, supported in Git • Kisbee – 802.15.4 capture, supported but hard to classify networks • RFCat / FSK – Planning classification still • SDR – HackRF, etc can in theory talk any protocol 96
  • 97. Writing for PHY-N • Each device record has a common component • Additional information is attached as tagged blobs of data • Phy-N plugin can define any additional data for any device it needs 97
  • 98. So what else do we care about? • Other protocols used for important things • “Internet of Things” is already here – it may be your inventory or factory control • “Active” inventory tags use things like Zigbee • Zigbee often used on sensor networks and physical devices 98
  • 99. The value of data • Can you trust your sensor network? • What can go wrong if someone can spoof it? • Is it connected to your company Intranet? • Does it control security or safety responses? • Can it leak internal processes? (Bake @ 1500F for 20 minutes, then...) 99
  • 100. Heist of the century • When used for inventory control, how is it checked? • Can someone spoof it and try to remove the original tagged item? • Place original tag in faraday cage, bridge to spoof tag over cell, replicate packets at original location • Silly? What if tag is on semi truck of components? 100
  • 101. Loss of control • What does your sensor network control? • How much money would you lose if your factory crashed? • Can your network be seen from outside your perimeter? • If you're not looking, you can't know 101
  • 102. Ninja-level problems • Attackers may not even need to be w/in wireless range • If a packet format is FF1245678 and someone sends a wired packet of FF123FF45678 • If something causes the beginning of the packet to corrupt... 102
  • 103. Go away PIP nobody likes you • Then the second part of the packet may be detected as a complete frame and handled as if it was the original data! • Forge wireless from the wire! • Zigbee is especially vulnerable b/c of simplicity, see work by Travis Goodspeed 103
  • 104. Different != better • Custom protocols haven't been exampled as closely • SDR is now really cheap • Simpler protocols may have less or no protection against injection/replay/packet in packet • Do you know every wireless device on your net? 104
  • 105. Other thoughts on wireless data leakage • Do you still use pagers to communicate to staff? • Bridge your email directly to them? • Did you know those are unencrypted? • And you can pick them up w/ a $20 USB SDR? • Of course, that's illegal. • And a criminal would never break the law... 105
  • 106. Things you probably send to pagers ● Router interface names ● Alarm system updates ● Webserver failures... with internal names ● Internal server names ● When someone is on duty ● What monitoring SW you run ● What email servers you run ● … Just sayin'... 106
  • 107. Some folk'll never commit a felony to break into your company... ● … But then again, some folks'll ● Just because it's illegal to monitor or attack something doesn't mean someone won't do it ● They're a criminal, after all. ● Be aware of as many vectors as you can and try to be capable of monitoring, etc 107
  • 108. Recap • If you don't know to look you can't know how bad it is • Look in unexpected places • Everything has security problems; arm yourself with more info • More wireless tech = more things to monitor 108