ShmooCon 2005 - Design and Implementation of a Wi-Fi IDS

Transcript

1. D1 - February, 2005 The present document contains information that remains the property of France Telecom. The recipient’s acceptance of this document implies his or her acknowledgement of the confidential nature of its contents and his or her obligation not to reproduce, transmit to a third party, disclose or use for commercial purposes any of its contents whatsoever without France Telecom’s prior written agreement. Design and Implementation of a Wireless IDS (Mitigating rogue AP in corp. environments) ShmooCon2005, Washington – February 4-6, 2005 Laurent BUTTI & Franck VEYSSET – France Telecom Division R&D {laurent.butti;franck.veysset} AT francetelecom.com
2. D2 - February, 2005 Agenda s Introduction QContext and Motivation QOverview of Available Tools s Design and Implementation of a Wireless IDS QArchitecture Overview and Technical Choices QFeatures and Current Status QRules Syntax and Log Example QEvent Aggregation and Correlation QLinksys WRTR54G Port s Mitigating Rogue Access Points in Corporate Environments QDetection, Location, and Mitigation QGuidelines for a Successful Wireless IDS Deployment s Conclusions QIssues, Pros and Cons, Future Work
3. D3 - February, 2005 Context (1/3) s Wireless networks are widely available in corporate environments QWireless infrastructures for employee access (IPsec or WPA/WPA2) QWireless infrastructures for guest access (captive portal) QWireless chipsets are shipped by default on most laptops today s These facts fatally lead to several weaknesses QInformation leaking about your wireless infrastructure and laptops QComplex configurations and experimental networks that are error-prone QUncontrolled adhoc networks that can be a serious hole (double- attachment)
4. D4 - February, 2005 Context (2/3) s Combined with the attacker’s panoply QAccess point mode available with some *nix drivers and firmwares QLightweight access points to be plugged in corporate networks QWardriving tools (which are a clear preliminary process to a more intrusive attack) s Your wireless environment is susceptible to be attacked… You should observe it carefully! QA wireless IDS seems to become a mandatory tool s Corporate env. are (potentially) vulnerable to QRogue access points interconnected with their internal networks! QDouble attachment (ethernet and wireless interfaces both activated) QLaptops associating to rogue access points
5. D5 - February, 2005 Context (3/3) s Some facts QRobust wireless access (IPsec, WPA/WPA2) can not prevent these vulnerabilities QNon wireless-ready environments are also vulnerable to rogue AP interconnections s Wild Wild Wireless! QSeems to be hard to have an exact view of wireless networks status –Attacks in action? Wardriving and man-in-the-middle attacks are impossible to detect without any specific tools! s Goals of this presentation QProvide the audience with an overview of our technical choices and ideas during the development of a wireless IDS QDescribe issues and provide guidelines for a successful deployment
6. D6 - February, 2005 Motivation s (Another?) wireless IDS engine in Open Source world QOne of the first initiative was launched by Abaddon in 2001 (AirIDS) QOther initiatives exists QWe wanted a solution satisfying our requirements… QThat would be released as Open Source soon… (work in progress) s Provide a complete solution for QEvent detection QEvent aggregation and correlation QEvent presentation QSupervision and administration interface s Fun! ;) QImprove our skills in wireless security area!
7. D7 - February, 2005 Wi-Fi IDS solutions s Many solutions already available s Commercial offers: new companies on the market s 2 different categories QIntegrated equipments –Monitoring software integrated to dedicated appliance –Inside the Wlan infrastructure QStand-alone (overlay) solutions –Specialized IDS software and dedicated sensors –Known as “overlay monitors”
8. D8 - February, 2005 Integrated equipment s Examples QAirEspace QAruba QCisco QNortel… s Pros QAll in one solution: simple, cost effective (?) QSet of security and management solutions, one administration console s Cons QAll your eggs in the same basket: rely on one vendor QUsually, lack of advanced IDS capabilities (no or few correlation)
9. D9 - February, 2005 Stand-alone (overlay) solutions s Examples QAirDefense QAirMagnet QNetwork Chemistry QNetwork Intruments QWildpackets… s Pros QCan be deployed over an existing solution QProvide advanced IDS capabilities: Products are REAL security solution s Cons QConfiguration may be difficult QLack of IPS capabilities (reaction on threat) QNeed to deploy a separate network (wlan and WiFi IDS net)
10. D10 - February, 2005 s Some open source products are also available s One of the first initiative was launched by Abaddon in 2001 (AirIDS) QRuns on linux QCan fool wep crack tools and stumblers (inject frames) QProject no longer active? s WlanDetect (as a Prelude-NIDS plugin’) QAct as a plugin for Prelude-IDS network s WIDZ Q2 modules, AP monitor, and traffic monitor QFew functionalities s Garuda QDifficult to find documentation… s Snort-Wireless QAdd WiFi IDS features to snort, preprocessor (RogueAP, Antistumbler), new rule set and functionalities Open source products
11. D11 - February, 2005 More information: links s AirIDS Qhttp://www.internetcomealive.com/clients/airids/index.php s WIDZ Qhttp://www.loud-fat-bloke.co.uk/w80211.html s WlanDetect Qhttp://www.security-labs.org/wlandetect/ s Garuda Qhttp://garuda.sourceforge.net/ s Snort-Wireless Qhttp://snort-wireless.org/
12. D12 - February, 2005 Requirements: Overlay Wireless IDS s Portable QIndependent of lower layers –Any monitor capable wireless card –Any IEEE 802.11 technology: IEEE 802.11 a/b/g… QShould run on any *nix operating system s Flexibility QCode should not be modified when adding a new event pattern –Pattern definition thanks to a rules syntax s Lightweight and low-cost QShould run on cheap embedded devices –E.g. Linksys WRT54G s Channel hopping compliant QShould have no (or minimal) impacts on false positives QState independent, i.e. packet loss must have no impacts on alerts s Ease of use QShould be managed by a Web interface (log readability, administration…)
13. D13 - February, 2005 Architecture Overview s Architecture is divided in several technical parts QWireless probes: detecting and sending events QA central collector: event aggregation and correlation QA database: aggregated and correlated events storage QA GUI: presentation and supervision/administration s The wireless probe is fully functional in a standalone mode QBut, you just need to store and read lot of SYSLOG events! Wireless Probe Wireless Probe Aggregation and Correlation SYSLOG SYSLOG Events Database SQL Presentation and Administration SQL SSH/SCP Site Administrator HTTPS
14. D14 - February, 2005 Architecture Overview AP Internal Network AP Probe Probe HTTPS SYSLOG SSH/SCP Aggregation and Correlation Presentation and Administration SQL
15. D15 - February, 2005 Technical Choices – Wireless Probe s Language QC s Capture library QLibpcap s Hardware QExtensively tested with Prism (HostAP/Prism54), Atheros (MadWifi) cards and Linksys WRT54G (wl driver) s Rules definition QLexical and syntaxical parsers s Optimized for speed and size QRules tree is stored in memory, minimize mallocs QSmall memory footprint for embedded devices (~ 85 Kb for the binary) s State of wireless stations and access points is not managed QState independent engine, as state can be managed at backend (i.e. passing directly from unauthenticated to associated state is unexpected) –Reduces drastically false positive, as packet losses are a classic issue in wireless networks! –Moreover, managing state for each MAC address can be memory extensive…
16. D16 - February, 2005 Technical Choices – Backend s Aggregation and correlation QSimple Event Correlator (SEC) processing SYSLOG logs s Event storage QSQL database (e.g. mySQL) s HTTP(S) interface QApache and PHP driven s Supervision and administration QSSH/SCP s Some (classic) features QAlert sorting/seeking by category, @MAC… QGraph representation of alerts –Current active threats –Evolution of alerts QSave and restore databases QAlert sending by mail s HTTP(S), SYSLOG and SSH/SCP protocols were elected because they are usually accepted in network security policies (through filtering devices)
17. D17 - February, 2005 Features s Rules can be designed to trigger any event, e.g. QAP sending a packet with @MAC not present in a WHITELIST: Rogue AP QSTA association to a Rogue AP QWEP injection: several WEP encrypted packets with a same @MAC_STA and same IV (should be also correlated with MAC spoofing detection) s MAC spoofing detection thanks to sequence number analysis (Joshua Wright) and other techniques… QPacket storage in a buffer for sequence number analysis s The buffer can be useful for complex rules QA count() function is able to return the number of packet matching a specified expression in the buffer –E.g. several WEP encrypted packets with a same @MAC_STA and same IV than the current packet QBut it is time consuming, as count() is performed for each packet reception –Should be used only when necessary
18. D18 - February, 2005 Current Status s Most IEEE 802.11 fields are supported QPrism header (useful if supported by the monitoring device) QIEEE 802.11 header QManagement frames (fixed and tagged parameters) QControl frames QData frames (LLC, WEP and IEEE 802.1X/EAP headers) s Our current rules definition: ~ 60 logging events Q15 informational Q13 level 2 (Default SSID, Signal Variations, Unauthorized SSID…) Q15 level 3 (WEP injection, SSID changed…) Q9 level 4 (RogueAP, White-listed AP MAC Spoofing…) Q6 level 5 (RogueAP Intranet Interconnected…) s Of course, rules must be tuned regarding your wireless environment…
19. D19 - February, 2005 Rules Syntax and Log Example s Rules definition supports QA listen directive to specify the listen interface (pcap file, wlan) QA from directive to specify a list of rules QA when directive to specify a rule QA forwardto directive to forward to another list of rules QA do directive to activate an action (e.g. log) QOperators like "< , > , = , !=" #RULES EXAMPLE listen CAP device=wlan0 buffer=10s from CAP when packet.type = management do forwardto(MANAGEMENT) and break From MANAGEMENT when packet.subtype = beacon and packet.mac2 not in list("ap_whitelist") do log("packet.mac2 | packet.mac1 | Unauthorized AP | 4 | RogueAP | packet.tags[ssid]. content", 4) #SYSLOG OUTPUT EXAMPLE: Aug 23 13:00:00 debian probe1: 01:23:45:67:89:0A | BC:DE:F0:12:34:56 | Unauthorized AP | 4 | RogueAP | test
20. D20 - February, 2005 Aggregation and Correlation s This process is mandatory to have a usable tool! QAggregation and correlation are performed with Simple Event Correlator (SEC) thanks to regexp –Suits perfectly for text messages analysis (via SYSLOG) s Storage of aggregated events in a SQL table QWhen a new alert is received via SYSLOG, SEC aggregates it in a SQL table if possible (i.e. context activated) –i.e. during a certain timer, the context remains active at each reception of a same alert (updating hits, last time received…) QWhen a logic combination of alerts is received via SYSLOG, SEC correlates it in a SQL table if possible QStorage on-the-fly in a SQL database s Aggregation reduces up to 98% of generated logs QMost logs are recurrent (SCANS, BROADCASTED SSIDS…) within a period of time
21. D21 - February, 2005 Aggregation reduces up to 98% of logs s Aggregates identical alerts in a 65 seconds timeframe s Relying on SEC (Simple Event Correlator) 98%
22. D22 - February, 2005 Correlation Example s Strong correlation between several alerts on a same category (e.g. MAC Spoofing) QSignal Variations (if available) –Two MAC address are at different places QSequence Number Analysis –Changes could be a sign of an active attack QTagged Parameters Analysis – Changes could be a sign of an active attack QTimestamp Parameters Analysis –Changes could be a sign of an active attack s All these techniques are susceptible to false alarms: correlate them in an unique alert (Correlated AP Spoofing) to reduce false positive rate!
23. D23 - February, 2005 Linksys WRT54G Port (1/3) s Linksys WRT54G is a 802.11g access point with following capabilities QHardware (v1.0) –RAM: 16 MB, Flash: 4MB –CPU: BCM94702 (125MHz MIPS) –Ethernet: ADMtek ADM6996 5 port 10/100 switch QOthers –WPA compliant –Wireless driver is proprietary –Firmware source code is released under the GPL license –Hacked firmwares paradise!
24. D24 - February, 2005 Linksys WRT54G Port (2/3) s We used OpenWRT’s firmware QUpgrading new firmware by HTTP (Linksys’s) or TFTP with "nvram set boot_wait=on" QCross-compilation of new binaries (mips) QPackage construction with ipkg QMust configure starting scripts s By default, Linksys WRT54G is in client mode searching for "linksys" ESSID (with OpenWRT firmware) QKeep client mode and deactivate scan –"wl scansuppress 1" QPassive scanning is possible for channel hopping, but we preferred to use a simple script to do channel hopping (by executing "wl channel x") QMonitor mode must be activated with "wl monitor 1"
25. D25 - February, 2005 Linksys WRT54G Port (3/3) s Theoretically, it is possible to switch to AP mode and keep IDS functions on! QBut channel hopping is no more possible! ;) –With IEEE 802.11b overlapping channels, you are still able to detect some events next to your active IEEE 802.11b channel… QAnother option is to execute a command to activate channel hopping only when no clients are connected to the AP during a certain period of time and come back to normal operation s To address performance issues when huge packet load, we tried to develop a bridge mode QBridge all wireless packets (truncated) to a central packet collector where the packet analysis is processed –All frames are captured and sent to a powerful (better processing unit than a 125MHz MIPS) packet collector: save CPU on WRT54G QOnly layer 2 encapsulation is supported, must still be improved…
26. D26 - February, 2005 Case Study: Rogue AP sDifferent goals… QDetect rogue access points QDetermine if rogue AP are interconnected with internal networks QMitigate the risks of rogue AP interconnected with internal networks
27. D27 - February, 2005 Rogue Access Points: Detection s Some rogue access points do not spoof the MAC address of a legitimate access point (same ESSID) QDetected thanks to a MAC addresses whitelist (BSSID mismatch) s Some rogue access points spoof the MAC address of a legitimate access point (same ESSID and MAC) QDetected thanks to a correlation of several MAC spoofing techniques –“Layer 2” sequence numbers variations –“Layer 2” signal variations –“Layer 2” timestamp incoherencies –“Layer 2” tagged parameters incoherencies s But, these techniques can not determine if rogue access points are interconnected to internal networks
28. D28 - February, 2005 Rogue Access Points: Location s Equipment geolocation helps to decide whether an access point is within corporate physical perimeter or not QReceived Signal Strength Index (RSSI) triangulation with several wireless probes (if Prism Header available) s Equipment tracking gives precise information like the exact location of the rogue access point: switch,port QWireless MAC addresses can be seek in switches MAC tables QBSSID +1, BSSID –1 MAC addresses can be seek in switches MAC tables QDestination MAC addresses (Data frames) can be seek in switches MAC tables QPerformed with Netdisco, an Open Source network management tool
29. D29 - February, 2005 Rogue Access Points: Location s Automatic association with a wireless probe ensures that a rogue access point is interconnected with internal networks QAssociation, act as a DHCP client and send a packet to the internal network (if possible, i.e. if ESSID is retrieved and if the rogue access point is Open) –Critical vulnerability!!! s But these techniques can not mitigate rogue access points
30. D30 - February, 2005 Rogue Access Points: Mitigation s Switch port shutdown thanks to equipment tracking results QAs false alarms are always possible, switch port shutdown is up to the decision of the site administrator: our tool provides necessary information to take an action QYou must be sure! De-activating legitimate access points is not an option! s Radio containment capabilities (preventing associations to rogue access points) are currently being developed QDEAUTH/DISASSOC frames sent to prevent clients from associating to rogue access points QYou must be sure! DoSing neighbors is not an option! s These techniques are effective, but must be activated with caution!
31. D31 - February, 2005 Example: Rogue AP Location s Associates to rogue AP (bridge or router mode) to determine if QAn IP address is given thanks to DHCP QAn internal IP address is reachable thanks to a PING request s Determines if rogue AP is interconnected to internal networks or not Probe ?
32. D32 - February, 2005 Example: Rogue AP Location s Search for destination MAC address of a “TO_DS DATA frame” through a rogue AP (in bridge mode) QThanks to MAC switches tables s Determines if rogue AP is interconnected to internal networks or not Probe ? ? ? Internal Mac Address? YES!!!
33. D33 - February, 2005 Example: Rogue AP Location s Search for the wireless client MAC address through a rogue AP (in bridge mode) QThanks to MAC switches tables s Determines the exact location of the rogue AP Probe ? ? Wireless @MAC client search in switches MAC tables Switch XXX.XXX.XXX.XXX, Port Y.Z!!!
34. D34 - February, 2005 Example: Rogue AP Location s Search for the BSSID +1/-1 MAC address (sometimes ) QThanks to MAC switches tables s Determines the exact location of the rogue AP Probe ? BSSID +1/-1 @MAC search in switches MAC tables Switch XXX.XXX.XXX.XXX, Port Y.Z!!!
35. D35 - February, 2005 Screenshots DRAFT – M ore to com e Geolocation example To be added… GUI Overview English translation exists ;-) Tracking example
36. D36 - February, 2005 Mitigating Rogue AP Guidelines s Implement strong network access policy, especially for meeting rooms (RJ45 plugs should not be activated by default, or why not consider 802.1X access control with a Guest VLAN?) s You must know about the configuration of your deployed access points (MAC addresses, broadcasted ESSIDs, …) s Laptop configuration must be hardened (prevent from associating to interfering or rogue access points, avoid double-attachment and information leaking) s Deploy a Wireless IDS to achieve observation at radio level
37. D37 - February, 2005 Mitigating Rogue AP Guidelines s Choose the best cost-effective solution that fit your environment s Prefer solutions that have minimal impacts on your architecture s Prefer solutions that give you equipment tracking and location s Deploy enough wireless probes at edge of your physical perimeter s Tune your ruleset to improve performances and effectiveness s Evaluate packet losses on your wireless probes s Do not trust anything: audit your deployment! (are attacks really detected?)
38. D38 - February, 2005 (Classic) Issues s False positives are a big issue for every IDS QEven a 0,01% false positive rate is sufficient to consider a tool as unreliable QMinimize as possible this rate, especially for events based on thresholds –Ruleset tuning according to your wireless environment s Identifying all interfering APs QYou must be sure! QA greylist can be used to prevent un-useful analysis and alerts –Can be managed at wireless probe or backend s Performance issues QHuge traffic load (especially 54Mb/s like a/g) is hard to analyze with lightweight embedded devices: packet losses –But as most attacks are not based on an unique packet they are still detected QStoring alerts during several days may have performance impacts on SQL requests as the SQL tables can become huge –Save and restore tables is a solution (per day, week…)
39. D39 - February, 2005 (Specific) Issues s Difficulties to provide a complete solution QAutomatic installation, configuration and remote administration of the wireless probes (Linksys WRT54G): lot of work needed to achieve an efficient process QMust improve look’n feel s NetDisco’s reminiscence values must be tuned QA wireless client can roam between access points –An AP is then located on several switches/ports values s Still an issue to manage a « Fake AP » kind of attack QLot of erroneous information: hard to analyze! s Still an issue with a specific configuration: a motivated attacker putting an rogue access point somewhere in your network QAP in router mode QAP not broadcasting ESSID and preventing anonymous associations (ACLs, WPA-PSK authentication, TKIP/CCMP encryption) QShould be detected with MAC ACLs or MAC spoofing detection QBut can not be easily located (only geolocation is effective in this case)
40. D40 - February, 2005 Future Work s Implementation of radio containment capabilities (IPS) QInitial implementation of DEAUTH/DISASSOC frames to STAs trying to connect to Rogue APs –Prism cards are OK, but WRT54G NOK QOf course, this should be used with caution (avoiding trivial DoS) s Improvement of distributed architecture QWill encapsulate in a layer 3 protocol with a defined header (like PROBE, DATA LENGTH…) contrary to a trivial layer 2 encapsulation (Ethertype)
41. D41 - February, 2005 Conclusions s Development of a fully featured Wireless IDS QWireless probes, aggregation, correlation, and presentation s Technical choices seem to fulfill our initial requirements QLightweight probe on an embedded device QFlexible with a rules syntax QChannel hopping independent QAggregation and correlation QAlert presentation s Still a lot of work to achieve a commercial-grade tool QSupervision / administration must be click and drop… and not vi-compliant! QContainment capabilities must be finished QRogue AP location services must be finished
42. D42 - February, 2005 The present document contains information that remains the property of France Telecom. The recipient’s acceptance of this document implies his or her acknowledgement of the confidential nature of its contents and his or her obligation not to reproduce, transmit to a third party, disclose or use for commercial purposes any of its contents whatsoever without France Telecom’s prior written agreement. Questions? Thanks for your attention