Presentation PowerPoint


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • NAV: network allocation vector
  • NAV: network allocation vector
  • - Media Requirements: The attacker can sniff and spoof packets. - Protocol Requirements: Existence of fatal error condition to stop the protocol before the protocol is protected by strong cryptographic algorithms. - Timing Requirements: Considerable time window exists between normal protocol communication, allowing attacks to inject packets at right place.
  • We actually start w/ such model checking approach, but found it too expensive. Intentionally use the error/misleading input, we are able to identify all such vulnerabilities much faster. Unlike most model checking work which focus on one particular protocols and try to find as many vulnerabilities as possible, we focus …
  • NAV: network allocation vector
  • “ Hello request” is a simple notification that the client should begin the negotiation process by sending a client hello message. Hello request will be ignored by the client if the client is currently negotiating a session.
  • Auc challenges mobile station with RAND Both sides derive keys based on Ki and RAND NAI: network access identifier RAND: random number; AUTN: authentication token, to authenticate the server MAC: message authentication code
  • Broadcast Beacon every 50ms
  • NAV: network allocation vector
  • Begins when the MN sends HoTI message to CN through HA and CoTI message directly to CN. Upon the receipt of the Binding Update, CN adds an entry for the MN in its Binding Cache and optionally sends Binding Acknowledgement. Once this happens, MN and CN will be capable of communicating over a direct route. This way, the route between MN and CN is optimized.
  • Mobile node SHOULD cease the attempt to use route optimization if the status field is set to 2 (unrecognized Mobility header) in Binding Error message.
  • NAV: network allocation vector
  • NAV: network allocation vector
  • Extensible Authentication Protocol (EAP) is a PPP extension Provides support for additional authentication methods within PPP. AuC: the authentication center
  • NAV: network allocation vector
  • Interestingly, we see the authentication success rate goes up first and then drop to 0. When the number of clients is small ( e.g., less than 10), the TLS server delay plays an important role. The attack packet usually gets into channel during the 10ms delay. But as the number of clients increase, the attacker may have to wait more than 10ms to get the channel when other nodes, by chance, occupy the channel to send packets. So the 10ms advantage of the attacker over the AP is mitigated. However, as the number of clients keeps increasing, the AP has more and more packets in its queue. Thus the TLS server response may be delayed for quite a long time at AP. On the other hand, the attacker packets usually are not queued, because attacker has much less packets to send than the AP.
  • 136 - Expired home nonce index 137- Expired care-of nonce index 138- Expired nonces
  • NAV: network allocation vector
  • Presentation PowerPoint

    1. 1. Exception Triggered DoS Attacks on Wireless Networks Yao Zhao, Sagar Vemuri, Jiazhen Chen, Yan Chen , Hai Zhou Lab for Internet and Security Technology (LIST), Northwestern Univ., USA Judy (Zhi) Fu Motorola Labs, USA
    2. 2. Motivation and Contributions <ul><li>Proactively search for vulnerabilities in emerging wireless network protocols </li></ul><ul><li>Model checking of protocols ? </li></ul><ul><ul><li>Found an initial ranging vulnerability in WiMAX [NPSec 06] </li></ul></ul><ul><ul><li>However, many challenges encountered, e.g., protocol ambiguity, hard to test all possible inputs (state explosion) </li></ul></ul><ul><li>Our contributions </li></ul><ul><ul><li>Reveal a family of exception triggered DoS attacks across many protocols (fast and easy!) </li></ul></ul><ul><ul><li>Demonstrate feasibility by real experiments </li></ul></ul><ul><ul><li>Propose countermeasures </li></ul></ul>
    3. 3. Basic Idea <ul><li>Processing error messages imprudently </li></ul><ul><ul><li>Error messages before authentication in clear text </li></ul></ul><ul><ul><li>Messages are trusted without integrity check </li></ul></ul><ul><li>Vulnerabilities received little attention </li></ul><ul><ul><li>Not practical in wired network (e.g. TCP reset) </li></ul></ul><ul><ul><li>Wireless links encrypted at layer 2 </li></ul></ul>
    4. 4. Attack Framework <ul><li>Attack Requirements </li></ul><ul><ul><li>Media: sniff and spoof packets </li></ul></ul><ul><ul><li>Protocol: existence of fatal error conditions before encryption starts </li></ul></ul><ul><ul><li>Timing: existence of time window to allow injection of faked packets b4 normal packets </li></ul></ul><ul><li>Attack Methodology </li></ul><ul><li>Spoof and inject: </li></ul><ul><ul><li>error messages that directly trigger exception handler </li></ul></ul><ul><ul><li>misleading messages that indirectly trigger exception handler </li></ul></ul>
    5. 5. Attack Properties <ul><li>Easy to Launch: No need to change MAC </li></ul><ul><ul><li>Only commodity hardware needed </li></ul></ul><ul><li>Efficient and Scalable: </li></ul><ul><ul><li>Small attack traffic, attack large # of clients </li></ul></ul><ul><li>Stealthy </li></ul><ul><ul><li>Can’t be detected w/ current IDS </li></ul></ul><ul><li>Widely Applicable to Many Protocols </li></ul>
    6. 6. Outline <ul><li>Motivation </li></ul><ul><li>Attack Framework </li></ul><ul><li>Attack Case Studies </li></ul><ul><ul><li>TLS based EAP protocols </li></ul></ul><ul><ul><li>Mobile IPv6 routing optimization protocol </li></ul></ul><ul><li>Countermeasures </li></ul><ul><li>Conclusions </li></ul>
    7. 7. EAP Authentication on Wireless EAP-FAST PEAP EAP-TTLS EAP Over LAN (EAPOL) Extensible Authentication Protocol (EAP) EAP Layer Data Link Layer 802.11 WLAN EAP-TLS Authentication method layer TLS Authentication primitive GSM UMTS/ CDMA2000 EAP-AKA EAP-SIM Challenge/Response
    8. 8. TLS Authentication Procedure <ul><li>TLS Handshake Protocol </li></ul><ul><li>Client and Server negotiate a stateful connection </li></ul><ul><li>Mutual authentication </li></ul><ul><li>Integrity-protected cipher suite negotiation </li></ul><ul><li>Key exchange </li></ul>
    9. 9. TLS-based Vulnerability <ul><li>Sniff to get the client MAC addr and IDs </li></ul><ul><ul><li>Packet in clear text before authentication </li></ul></ul><ul><li>Immediately send spoofed error/misleading messages </li></ul><ul><ul><li>E.g., attacker spoofs an alert message of level ‘fatal‘, followed by a close notify alert. </li></ul></ul><ul><ul><li>Then the handshake protocol fails and needs to be tried again. </li></ul></ul><ul><li>Complete DoS attack </li></ul><ul><ul><li>Repeats the previous steps to stop all the retries </li></ul></ul><ul><li>When this attack happens, WPA2 and WPA are all in clear text. </li></ul>
    10. 10. Error Message Attack on TLS: Attacker Spoofing as Server .Failure. .Failure
    11. 11. Error Message Attack on TLS: Attacker Spoofing as Client Hello Request Server Hello Server Certificate Server Key-exchange message Certificate Request Server Hello Done Client Hello Certificate Client Key-exchange message Certificate Verify Finished Error msg Failure Error msg Failure Client Attacker Server Attack Point-1 Attack Point-2
    12. 12. Misleading Message Attack on TLS Hello Request Server Hello Server Certificate Server Key-exchange message Certificate Request Server Hello Done Client Hello Certificate Client Key-exchange message Certificate Verify Finished Error msg Failure Client Attacker Server Spoofed Server Hello w/ misleading info Trigger Attack Point
    13. 13. DoS Attack on Challenge/Response over EAP-AKA <ul><li>Authentication in UMTS/CDMA2000 </li></ul><ul><li>Pre-shared key (Ki) in SIM and AuC </li></ul><ul><ul><li>Send Error Rejection or Notification message </li></ul></ul>Client End Server End EAP-Request/Identity EAP-Response/Identity (NAI) AKA-Challenge (RAND, AUTN, MAC) AKA-Response (RES, MAC) EAP-Success AKA-Authentication-Reject AKA-Notification
    14. 14. Experiments on PEAP WiFi Networks <ul><li>Feasibility test on net management utilities </li></ul><ul><ul><li>Windows native client (XP and Vista) </li></ul></ul><ul><ul><li>Dell utility - Proxim Utility, </li></ul></ul><ul><ul><li>the Linux Network Manager of Ubuntu </li></ul></ul><ul><li>Attacker Hardware </li></ul><ul><ul><li>Wifi cards with Atheros chipsets (e.g. Proxim Orinoco Gold wireless adapter) </li></ul></ul><ul><li>Attacker Software </li></ul><ul><ul><li>Libraries : Libpcap (sniffing) & Lorcon (spoofing) </li></ul></ul><ul><ul><li>MADWifi driver to configure CWMin </li></ul></ul><ul><ul><li>Attacking code: 1200 lines in C++ on Ubuntu Linux </li></ul></ul>
    15. 15. Field Test Results <ul><li>Conducted EAP-TLS attacks at a major university cafeteria </li></ul><ul><ul><li>2 Channels, 7 Client Hosts in all, and 1 Attacker </li></ul></ul><ul><ul><li>Successfully attacked all of them in one channel </li></ul></ul>
    16. 16. Attack Efficiency Evaluation <ul><li>For example, when attack happens at the second point </li></ul><ul><ul><li>Just need to send 156 bytes of message to screw the whole 1049 bytes authentication messages. </li></ul></ul>Attack Point 1 Ratio by # of Messages 25.00% [1/4] Ratio by Bytes 15.89% [78/491 ] Attack Point 2 Ratio by # of Messages 28.57% [2/7] Ratio by Bytes 14.87% [156/1049]
    17. 17. Attack Scalability Evaluation <ul><li>NS2 Simulation Methodology </li></ul><ul><ul><li>One TLS-Server and one base station </li></ul></ul><ul><ul><ul><li>100MBps duplex-link between BS and TLS-Server with various delay </li></ul></ul></ul><ul><ul><li>1~50 TLS-Clients </li></ul></ul><ul><ul><ul><li>Poisson inter-arrival (avg 0.5s) </li></ul></ul></ul><ul><ul><ul><li>Retry at most 18 times with the interval of 1s </li></ul></ul></ul><ul><ul><li>One TLS-Attacker </li></ul></ul><ul><ul><li>All results are based on an average of 20 runs </li></ul></ul><ul><li>Simulation Results </li></ul><ul><ul><li>Attackers can reduce CWMin to be aggressive </li></ul></ul><ul><ul><li>Attacks very scalable: all clients fail authentications </li></ul></ul>
    18. 18. Time Window Sensitivity w/ Various Server Delay <ul><li>Attack succeed even with very small time window </li></ul><ul><li>The larger the server delay, the larger chance for attack messages to reach victim client before legitimate message. </li></ul>
    19. 19. Outline <ul><li>Motivation </li></ul><ul><li>Attack Framework </li></ul><ul><li>Attack Case Studies </li></ul><ul><ul><li>TLS based EAP protocols </li></ul></ul><ul><ul><li>Mobile IPv6 routing optimization protocol </li></ul></ul><ul><li>Countermeasures </li></ul><ul><li>Conclusions </li></ul>
    20. 20. Mobile IPv6 Protocol <ul><li>Allows a mobile node (MN) to remain reachable while moving in the IPv6 Internet. </li></ul><ul><ul><li>A MN is always identified by its home address , regardless of its current point of attachment </li></ul></ul><ul><ul><li>IPv6 packets addressed to a MN's home address are transparently routed to its care-of address. </li></ul></ul><ul><ul><li>The protocol enables IPv6 nodes to cache the binding and thus to send any packets destined for the MN directly to it. </li></ul></ul>
    21. 21. Return Routability Procedure
    22. 22. Bind Error Vulnerability <ul><ul><li>The Binding Error message is not protected. </li></ul></ul>
    23. 23. Bind Acknowledgement Vulnerability <ul><ul><li>Binding Acknowledgement is not protected either </li></ul></ul>
    24. 24. Attack Power and Evaluations <ul><li>The attack can also disrupt on-going sessions </li></ul><ul><ul><li>RR procedure repeats every few minutes </li></ul></ul><ul><li>Emulation experiments </li></ul><ul><ul><li>Build the mobile IPv6 network using the Mobile IPv6 Implementation for Linux (MIPL v2.0). </li></ul></ul><ul><ul><li>GRE-based (Generic Routing Encapsulation) interfaces tunnel IPv6 over IPv4 </li></ul></ul><ul><ul><li>Conducted 100 times. </li></ul></ul><ul><ul><li>All RR request failed – performance degradation attack </li></ul></ul>
    25. 25. Outline <ul><li>Motivation </li></ul><ul><li>Attack Framework </li></ul><ul><li>Attack Case Studies </li></ul><ul><ul><li>TLS based EAP protocols </li></ul></ul><ul><ul><li>Mobile IPv6 routing optimization protocol </li></ul></ul><ul><li>Countermeasures </li></ul><ul><li>Conclusions </li></ul>
    26. 26. Countermeasures <ul><li>Detection: Based on Two Symptoms </li></ul><ul><ul><li>Conflict messages and abnormal protocol end </li></ul></ul><ul><li>Protocol Improvement (band-aid fix) </li></ul><ul><ul><li>Wait for a short time for a success message (if any) to arrive </li></ul></ul><ul><ul><li>Accept success messages over errors/failures </li></ul></ul><ul><ul><li>Start multiple session for multiple responses (for misleading message attack) </li></ul></ul><ul><ul><li>Implemented and repeated attack experiments: all attacks failed. </li></ul></ul><ul><li>Design of Robust Security Protocols </li></ul><ul><ul><li>Get packets encrypted and authenticated as early as possible. </li></ul></ul>
    27. 27. Conclusions <ul><li>Propose exception triggered denial-of-service attacks on wireless sec protocols </li></ul><ul><ul><li>Explore the vulnerabilities in the exception handling process </li></ul></ul><ul><li>Demonstrate attack effects </li></ul><ul><ul><li>TLS based EAP protocols </li></ul></ul><ul><ul><ul><li>Real-world experiments and simulations </li></ul></ul></ul><ul><ul><li>The Return Routability procedure of Mobile IPv6 protocol </li></ul></ul><ul><ul><ul><li>Testbed emulations </li></ul></ul></ul><ul><li>Propose detection scheme and protocol improvement principle </li></ul><ul><ul><ul><li>Real implementation and experiments </li></ul></ul></ul><ul><li>Working with IETF on improving protocol standards </li></ul>
    28. 28. Backup Slides
    29. 29. Case Study 1: Attack on TLS based EAP Protocols in Wireless Networks
    30. 30. EAP and TLS Authentication <ul><li>Transport Layer Security (TLS) </li></ul><ul><ul><li>Mutual authentication </li></ul></ul><ul><ul><li>Integrity-protected cipher suite negotiation </li></ul></ul><ul><ul><li>Key exchange </li></ul></ul><ul><li>Challenge/Response authentication in GSM/UMTS/CDMA2000 </li></ul><ul><ul><li>Pre-shared key (Ki) in SIM and AuC </li></ul></ul><ul><ul><li>Auc challenges mobile station with RAND </li></ul></ul><ul><ul><li>Both sides derive keys based on Ki and RAND </li></ul></ul>
    31. 31. Other Related Work <ul><li>Many DoS Attacks on Wireless Net </li></ul><ul><ul><li>Jamming, Rogue AP, ARP spoofing </li></ul></ul><ul><ul><li>More recent: deauthentication and virtual carrier sense attacks [Usenix Sec 03] </li></ul></ul>
    32. 32. Practical Experiment <ul><li>For the 33 different tries </li></ul><ul><ul><li>All suffered an attack at Attack Point-1 </li></ul></ul><ul><ul><li>21% survive from the first attack but failed at the 2 nd Attack Point. </li></ul></ul>
    33. 33. Attack Scalability <ul><li>The lower CWMin of the attacker, the higher attack success ratio. </li></ul><ul><li>Attack is scalable: very few clients are able to authenticate successfully. </li></ul>
    34. 34. Vulnerabilities of RR Procedure <ul><li>Binding Error Vulnerability </li></ul><ul><ul><li>Mobile node SHOULD cease the attempt to use route optimization if the status field is set to 2 (unrecognized Mobility header) in Binding Error message. </li></ul></ul><ul><ul><li>The Binding Error message is not protected. </li></ul></ul><ul><li>Bind Acknowledgement Vulnerability </li></ul><ul><ul><li>Binding Acknowledgement with status 136, 137 and 138 is used to indicate an error </li></ul></ul><ul><ul><li>Binding Acknowledgement is not protected either </li></ul></ul>
    35. 35. PEAP Enhancement <ul><li>Original WPA supplicant v0.5.10 </li></ul><ul><ul><li>Generate TLS ALERT on unexpected messages </li></ul></ul><ul><ul><li>Stop authentication on TLS ALERT </li></ul></ul><ul><li>Delayed response implementation </li></ul><ul><ul><li>Drop unexpected message silently </li></ul></ul><ul><ul><li>Wait for 1 second when receiving TLS ALERT to allow multiple responses, and ignore TLS ALERT response if good responses received </li></ul></ul><ul><ul><li>Multiple sessions against misleading messages </li></ul></ul><ul><li>Verification </li></ul><ul><ul><li>Repeated the WiFi attack experiments </li></ul></ul><ul><ul><li>All attacks failed </li></ul></ul>
    36. 36. Design of Robust Security Protocol Server Client Server certificate (including server’s public key K s + ) K s + ( Random string S, Identity ) Hello No useful info Cannot be spoofed Server ignore error msg. New session with secret S and ID
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.