Upgrade to Pro — share decks privately, control downloads, hide ads and more …

FIRST 2005 - Mitigating Rogue Access Points in ...

FIRST 2005 - Mitigating Rogue Access Points in Corporate Environments

Laurent Butti

June 29, 2005
Tweet

More Decks by Laurent Butti

Other Decks in Technology

Transcript

  1. D1 - June 29, 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. Mitigating Rogue Access Points in Corporate Environments (Design, Implementation and Deployment of a Wireless IDS) FIRST Singapore – June 29, 2005 Laurent BUTTI – France Telecom Division R&D firstname.lastname AT francetelecom dot com
  2. D2 - June 29, 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. Introduction
  3. D3 - June 29, 2005 Context 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 shipped by default on most laptops today s These facts fatally lead to several weaknesses QInformation leaking about your wireless infrastructure and laptops QError-prone configurations and uncontrolled experimental networks QUncontrolled adhoc networks that may represent a critical hole (double-attachment) s New security mechanisms (WPA/IEEE 802.11i) can not address and will not these issues!
  4. D4 - June 29, 2005 Wireless Intrusion Detection System? s

    Combine it with attacker‟s panoply QAccess point mode available with most *nix drivers and firmwares QLightweight access points to be plugged in corporate networks QWardriving tools (obvious process to a more intrusive attack) QFrame injection attacks that may be disrupting s Difficulties to know the status of wireless networks QJust ask your sysadmin to tell you about this! QAttacks in action? Wardriving and man-in-the-middle attacks are impossible to detect without any specific tools! QIs there any legitimate or illegitimate access points? s Your wireless environment may be vulnerable… QYou should observe it carrefully thanks to a wireless IDS!
  5. D5 - June 29, 2005 Preliminary Choices s Wireless networks

    were already deployed QEmployee corporate access thanks to IPsec w/ IKE and certificates QEmployee corporate access thanks to WPA w/ EAP-TLS QGuest access thanks to captive portals w/ temporary logins s So, overlay wireless IDS solution is straightforward QSpecialized IDS software and dedicated sensors s We decided to design a new tool from scratch QFit our needs and the low-cost requirement QImprove our skills in wireless security area s This presentation will expose our feedbacks on QDesign, Implementation and Deployment of a Wireless IDS QMitigating Rogue Access Points in Corporate Environments
  6. D6 - June 29, 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. Wireless IDS Design and Implementation
  7. D7 - June 29, 2005 Requirements: Overlay Wireless IDS (1/2)

    s Portable QIndependent of lower layers (any IEEE a/b/g/? monitor capable wireless card) QShould run on any *nix operating system s Flexible and lightweight QCode should not be modified when adding a new event pattern QShould run on embedded devices (e.g. WRT54G) with low memory and CPU constraints s Channel hopping compliant QShould not trigger false positives s Enhanced features QEfficient aggregation and correlation QNew MAC spoofing detection engines QNew equipment tracking capabilities
  8. D8 - June 29, 2005 Requirements: Overlay Wireless IDS (2/2)

    s Low-cost QAs overlay solutions may be expensive, low-cost wireless probes and backend tools are mandatory s Ease of use QMust be managed thanks to a WEB interface (log readability, administration…)
  9. D9 - June 29, 2005 Architecture Overview s Architecture is

    divided in several technical parts QSeveral wireless 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 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
  10. D10 - June 29, 2005 Architecture Overview AP Internal Network

    AP Probe Probe HTTPS SYSLOG SSH/SCP Aggregation and Correlation Presentation and Administration SQL
  11. D11 - June 29, 2005 (Wireless Probe) Technical Choices s

    Language and capture library QC and libpcap s Hardware QPrism2/2.5/3 (hostap), Prism54 (prism54.org), Atheros (madwifi) and WRT54G (wl) 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 binary)
  12. D12 - June 29, 2005 (Wireless Probe) Some Features s

    Rules can be designed to trigger any event, e.g. QRoque access point: packet with a BSSID not in a MAC address whitelist QSTA association to a rogue access point: association success packet with a BSSID not in a MAC address whitelist QWEP injection: several WEP encrypted packets with a same MAC_STA address and same IV s Ruleset is about 60 signatures ranging from detection of QRogue access point: unauthorized BSSIDs, ESSIDs QMAC spoofing: several techniques QDoS: deauth/disasso, EAP-logoff/failure floods, … QEAP bruteforcing: load of EAP-Response Identity requests, … QWardriving: Netstumbler, Wellenreiter, … QInjection attacks: load of WEP packets with same IVs QMisconfiguration: default ESSIDs, …
  13. D13 - June 29, 2005 (Wireless Probe) WRT54G Port s

    Linksys WRT54G (802.11b/g access point) 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 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
  14. D14 - June 29, 2005 (Backend) Technical Choices 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 for administration purposes Qsyslog for event reporting
  15. D15 - June 29, 2005 (Backend) Some Features s On-the-fly

    aggregation reduces up to 98% generated logs QMost logs are recurrent (Scans, Rogue APs…) within a timeframe s On-the-fly correlation QCorrelation of a logic combination of alerts (new signature) – e.g. STA changing to AP s Offline correlation QEquipment tracking and geolocation – Is the rogue access point interconnected with internal networks? s Update the database with a new correlated event QBetter efficiency as false alarms are reduced thanks to correlation s Aggregation and correlation processes are mandatory!
  16. D16 - June 29, 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. Detection and Mitigation
  17. D17 - June 29, 2005 Case Study: Rogue Access Points

    s Processing steps QDetection: Detect rogue access points QEvaluation: Determine if rogue access points are interconnected with internal networks and if possible their physical location QMitigation: Mitigate the risks of rogue access points interconnected with internal networks s Of course, you must know all BSSIDs of your legitimate access points… 
  18. D18 - June 29, 2005 Rogue Access Points: Detection s

    Rogue access points not spoofing a legitimate BSSID QDetected thanks to a MAC addresses white list (BSSID mismatch) s Rogue access points spoofing a legitimate BSSID QDetected thanks to a correlation of several MAC spoofing techniques – “Layer 2” sequence numbers variations (thanks to Joshua Wright) – “Layer 2” signal strength variations – “Layer 2” timestamp inconsistencies – “Layer 2” tagged parameters inconsistencies s But, these techniques cannot determine if rogue access points are interconnected to internal networks!
  19. D19 - June 29, 2005 Rogue Access Points: Evaluation s

    Evaluation will help us to determine QIf rogue access points are interconnected to internal networks QThe exact location of rogue access points QThe approximate physical location of rogue access points s „Automatic‟ association with a wireless probe to a rogue access point QRetrieve the ESSID thanks to the syslog event QAssociation, act as a DHCP client and send a packet to the internal network and/or to the Internet QIf resultcode == success, this is a critical vulnerability!!! QOf course, this must be used with caution – Do not connect to (millions of) fake APs! – De-activate bridge, put firewall rules on your wireless interface…
  20. D20 - June 29, 2005 Rogue Access Points: Evaluation s

    Seek in switches MAC tables QBSSID +1/–1 MAC addresses QSource and destination MAC addresses of data frames QPerformed thanks to Netdisco an Open Source network management tool s Equipment geolocation thanks to signal strength analysis QUse the RSSI (Received Signal Strength Index) QAvailable in PRISM Monitoring Header in monitor mode QHard to develop an efficient technique (calibration, propagation model, attenuation model, interferences…) QBut will help to define whether an access point is within corporate physical perimeter or not s But these techniques cannot mitigate rogue access points!
  21. D21 - June 29, 2005 Rogue Access Points: Mitigation s

    Switch port shutdown thanks to evaluation 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 could be developed (seeking some clues for wl driver injection!) QDEAUTH/DISASSOC frames may be 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!
  22. D22 - June 29, 2005 Example: Rogue AP Location s

    Associates to rogue AP (bridge, 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 ?
  23. D23 - June 29, 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!!!
  24. D24 - June 29, 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!!!
  25. D25 - June 29, 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!!!
  26. D26 - June 29, 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. Feedbacks and Guidelines
  27. D27 - June 29, 2005 Mitigating Rogue AP Guidelines s

    Have a physical security policy especially for RJ45 plugs in meeting rooms! s Consider IEEE 802.1X network access control on your RJ45s s Know the configuration of your wireless infrastructure (BSSIDs, ESSIDs, cryptoprotocols…) s Harden laptops‟ configuration (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
  28. D28 - June 29, 2005 Wireless IDS Deployment Guidelines s

    Cost-effective solution fitting your environment s Must have minimal impacts on your architecture s Should have equipment tracking and location s Tune your ruleset for performance and effectiveness s Deploy enough wireless probes at edge of your physical perimeter s Evaluate packet losses on your wireless probes s Do not trust anything! Audit your deployment! (are attacks really detected?)
  29. D29 - June 29, 2005 Feedbacks s Developping a robust

    wireless IDS is not trivial QYou must deal with load of events (hundreds per second) s Building an efficient GUI for sysadmins is not trivial QThat’s the challenge! s Difficulties to identify all interfering access points QWhat about neighbours, hot spots, … QYou must be sure! s False positive rate is a classic issue for IDS technologies QMinimize this rate thanks to enhanced correlation s Performance issues QLightweight wireless probe may have packet losses QSQL table may become huge
  30. D32 - June 29, 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
  31. D33 - June 29, 2005 (Specific) Issues s Difficulties to

    provide a complete solution Q Automatic installation, configuration and remote administration of the wireless probes (Linksys WRT54G): lot of work needed to achieve an efficient process Q Must improve look’n feel s NetDisco‟s reminiscence values must be tuned Q A 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 Q Lot 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 Q AP in router mode Q AP not broadcasting ESSID and preventing anonymous associations (ACLs, WPA-PSK authentication, TKIP/CCMP encryption) Q Should be detected with MAC ACLs or MAC spoofing detection
  32. D34 - June 29, 2005 Conclusions s Development and deployment

    of a fully-featured Wireless IDS QWireless probes, aggregation, correlation, presentation, administration, supervision and equipment tracking s Technical choices seem to fulfill our initial requirements QLightweight probe on an embedded device QFlexible thanks to a rules syntax QChannel hopping compliant QAggregation and correlation QPresentation GUI s Low-cost constraints are fulfilled QBased on Open Source tools QWireless probe (~ 60 €) and a standard PC (~ 1000 €) s Still a lot of work to achieve a commercial-grade tool QSupervision and administration must be click and launch… and