Vulnerability Analysis of Mobile and Wireless Protocols

1. Vulnerability Analysis of Mobile and Wireless Protocols

2. Outline • Vulnerability Analysis Method • Message Spoofing • Mobile IPv4 • WiMAX • EAP • EAP-FAST • Future work

3. Vulnerability Analysis Method • Study the protocol specifications • Find Unprotected messages • Concentrate on the unprotected messages to find security vulnerabilities • If practical, simulation of the vulnerabilities • Proposal of solution(s)

4. Message spoofing • Can be achieved using debug ports left open by hardware vendors • Standard – IEEE 1149.1 – Joint Test Action Group (JTAG) • Intel and Fujitsu WiMAX implementations leave their debug ports open • Motorola JTAG ports are closed in production boxes

5. MIPv4 – Phases • Agent Discovery • Registration • Data Exchange

6. MIPv4 - Messages

7. Vulnerability Analysis • No new vulnerabilities found

8. WiMAX • Studied the IEEE 802.16 (2004) spec • Focused on Network Entry and Initialization before SS authorization step

9. Network Entry and Initialization

10. Network Entry and Initialization Work Done

11. Network Entry and Initialization Future work

12. WiMAX – Unprotected messages

13. Vulnerabilities found • 0-Authorization vulnerability • Using SBC-REQ and SBC-RSP messages • Ranging synchronization vulnerability • Using RNG-REQ and RNG-RSP messages • UCD vulnerability

14. 0-Authorization vulnerability • Authorization Policy Support is one of the many capabilities • Authorization and key exchange steps will be skipped if the Auth Policy Support bits are set to 0 • Vulnerability also exists if ‘bitwise and’ of auth bits of SBC-REQ and SBC-RSP is 0

15. 0-Authorization vulnerability SBC-REQ / SBC-RSP message format Authorization Policy Support bits

16. 0-Authorization vulnerability • Motorola implementations allow 0-authorization only for debugging purposes and E911 with limited access • Spoofed SBC-REQ with 0-authorization • Network will most likely reject it • Spoofed SBC-RSP with 0-authorization • MS will not permit it for not being able to trust the service provider

17. Ranging Sync vulnerability • Ranging adjusts SS's timing offset such that it appears to be co-located with BS • RNG-REQ message is sent by the SS with power level and timing offset corrections • If the status in spoofed RSG-RSP is continue, • SS keeps on trying until successful • Aborts and re-ranges after a fixed number of tries

18. Ranging Sync vulnerability • If the status in spoofed RNG-RSP is either Abort or Re-range • Starts the network entry process again from the beginning • Correct timing is essential for this attack to work • Spoofed messages should be sent before the legitimate RNG-RSP reaches SS

19. Ranging Sync vulnerability

20. Ranging Sync vulnerability

21. UCD vulnerability • After channel synchronization, SS waits for UCD msg from BS to retrieve a set of transmission parameters for uplink chanel • A spoofed UCD message with unsuitable channel parameters will make the SS start over from the first step of downlink channel scanning

22. WiMAX Analysis • Found 3 potential vulnerabilities • But, they are hard to instigate as they require: • Considerable hardware to spoof the messages • Correct timing

23. EAP • Used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks • Support currently about 40 different EAP methods • Commonly used modern methods capable of operating in wireless networks include EAP-TLS, EAP-SIM, EAP-AKA, PEAP, LEAP and EAP-TTLS

24. EAP and associated layers Authentication method layer EAP-TLS PEAP EAP-SIM EAP-AKA EAP-FAST Extensible Authentication Protocol (EAP) EAP Layer EAP Over LAN (EAPOL) Data Link Layer PPP 802.3 Ethernet 802.5 Token Ring 802.11 WLAN 802.11 Serial Link

25. EAP Message Exchange Framework Server (EAP-Request Identity) (EAP-Response Identity) EAP-Response Identity Method specific EAP Request Repeat until success or fail Method specific EAP Response EAP-Success Peer AP

26. EAP-FAST (Flexible Authentication via Secure Tunneling) • Most Comprehensive and secure WLAN method • Use of a protected access credential (PAC) • Three phase • Phase 0 : PAC provisioning • Phase 1 : Establish TLS tunnel. • Phase 2 : Authentication

27. Phase 0 EAP Request/Identity EAP Response/Identity (anonymous@realm) EAP-FAST [TLS Client Hello[Client_Random,PAC-Opaque]] PAC Provisioning EAP-FAST Start [A-ID] EAP-FAST [TLS Server Hello[Server_Random]] Phase 1 TLS change Cipher Spec TLS Finished TLS change Cipher Spec TLS Finished Authentication with a inner Authentication method Optional PAC Refresh Phase 2 EAP Success Establish Secure Channel Establish Secure Channel Establish connection (for example, TCP) Peer AP Inner method Server EAP-FAST server TLS Tunnel established TLS Tunnel torn down EAP-FAST choreography overview

28. Messages within EAP-FAST

29. Explaination for unprotected message Initial Request-response Messages • Sent in cleartext • Just contain realm information • Used to route the authentication requests to the right eap server

30. Explaination for unprotected message(2) Clear text success /failure packet • The success/failure decisions within the tunnel indicate the final decision of the EAP-FAST authentication conversation. • To abide by [RFC3748], the server must send a clear text EAP Success or EAP Failure packet to terminate the EAP conversation.

31. Explaination for unprotected message(3) • What will happen if a clear text indication is spoofed? It dosen’t matter because the clear text indication is only used to terminate the authentication conversation, not for other use. • What will happen if the final cleartext success/failure packet in an EAP-FAST is lost? It is up to the basic EAP policy. In the event that neither a success nor a failure packet is received, the peer SHOULD termiate the conversation to avoid lengthy timeout in case of the lost packet was an EAP failure.[RFC3748, 4.2]

32. EAP-FAST Analysis • No vulnerability was found wihin EAP-FAST!

33. Future work • Study internal attacks • Till now the focus was on external attacks • Resource Depletion attacks