Title: Vulnerability Analysis of Mobile and Wireless Protocols
1- Vulnerability Analysis of Mobile and Wireless
Protocols
2Outline
- Vulnerability Analysis Method
- Message Spoofing
- Mobile IPv4
- WiMAX
- EAP
- EAP-FAST
- Future work
3Vulnerability 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)
4Message 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
5MIPv4 Phases
- Agent Discovery
- Registration
- Data Exchange
6MIPv4 - Messages
Message Channel Protected
Agent Advertisement FA ?MN No
Agent Solicitation MN ? FA No
Registration Request MN ? FA No
Registration Response FA ? MN Yes
7Vulnerability Analysis
- No new vulnerabilities found
8WiMAX
- Studied the IEEE 802.16 (2004) spec
- Focused on Network Entry and Initialization
before SS authorization step
9Network Entry and Initialization
10Network Entry and Initialization
Work Done
11Network Entry and Initialization
Future work
12WiMAX Unprotected messages
Message Channel Description
DL-MAP BS ? SS Downlink Access Definition
UL-MAP BS ? SS Uplink Access Definition
UCD BS ? SS Uplink Channel Descriptor
RNG-REQ SS ? BS Ranging Request
RNG-RSP BS ? SS Ranging Response
SBC-REQ SS ? BS SS Basic Capability Request
SBC-RSP BS ? SS SS Basic Capability Response
13Vulnerabilities found
- 0-Authorization vulnerability
- Using SBC-REQ and SBC-RSP messages
- Ranging synchronization vulnerability
- Using RNG-REQ and RNG-RSP messages
- UCD vulnerability
140-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
150-Authorization vulnerability
Syntax Size Notes
SBC-REQ/RSP message format()
Message Type 8 bits
TLV encoded information variable TLV specific
SBC-REQ / SBC-RSP message format
Type Length Value
16 1 byte Bit 0 IEEE 802.16 privacy supported Bits 1-7 Reserved shall be set to zero
Authorization Policy Support bits
160-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
17Ranging 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
18Ranging 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
19Ranging Sync vulnerability
20Ranging Sync vulnerability
21UCD 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
22WiMAX Analysis
- Found 3 potential vulnerabilities
- But, they are hard to instigate as they require
- Considerable hardware to spoof the messages
- Correct timing
23EAP
- 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
24EAP and associated layers
25EAP Message Exchange Framework
Peer
AP
26EAP-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
27Establish Secure Channel
Establish Secure Channel
Establish connection (for example, TCP)
Inner method Server
Peer
AP
EAP-FAST server
TLS Tunnel established
TLS Tunnel torn down
EAP-FAST choreography overview
28Messages within EAP-FAST
Message Channel Protected?
Provisining ( this phrase itself is an EAP-TLS Exchange) Provisining ( this phrase itself is an EAP-TLS Exchange) Provisining ( this phrase itself is an EAP-TLS Exchange)
EAP- Request /Identity AP- to-MS NO
EAP-Response/ Identity MS- to-AP NO
Identity Response AP- to-Radius YES, secure channel
EAP-FAST start Radius - to- AP YES, secure channel
EAP-FAST start AP- to-MS NO
TLS tunnel establishment TLS tunnel establishment TLS tunnel establishment
Authentication with a inner Authentication method, protected by TLS tunnel Authentication with a inner Authentication method, protected by TLS tunnel Authentication with a inner Authentication method, protected by TLS tunnel
EAP-Success AP- to-MS NO
29Explaination 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
30Explaination 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.
31Explaination for unprotected message(3)
- What will happen if a clear text indication is
spoofed? - It dosent 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
32EAP-FAST Analysis
- No vulnerability was found wihin EAP-FAST!
33Future work
- Study internal attacks
- Till now the focus was on external attacks
- Resource Depletion attacks