Vulnerability Analysis of Mobile and Wireless Protocols
-
Upload
zelda-pierce -
Category
Documents
-
view
25 -
download
0
description
Transcript of Vulnerability Analysis of Mobile and Wireless Protocols
Vulnerability Analysis of Mobile and Wireless Protocols
Outline
• Vulnerability Analysis Method
• Message Spoofing
• Mobile IPv4
• WiMAX
• EAP– EAP-FAST
• Future work
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)
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
MIPv4 – Phases
1. Agent Discovery
2. Registration
3. Data Exchange
MIPv4 - Messages
Message Channel Protected
Agent Advertisement
FA MN No
Agent Solicitation
MN FA No
Registration Request
MN FA No
Registration Response
FA MN Yes
Vulnerability Analysis
• No new vulnerabilities found
WiMAX
• Studied the IEEE 802.16 (2004) spec
• Focused on Network Entry and Initialization before SS authorization step
Network Entry and Initialization
Network Entry and Initialization
Work Done
Network Entry and Initialization
Future work
WiMAX – 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
Vulnerabilities found
• 0-Authorization vulnerability– Using SBC-REQ and SBC-RSP messages
• Ranging synchronization vulnerability– Using RNG-REQ and RNG-RSP messages
• UCD vulnerability
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
0-Authorization vulnerability
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
Syntax Size Notes
SBC-REQ/RSP message format() {
Message Type 8 bits
TLV encoded information
variable TLV specific
}
SBC-REQ / SBC-RSP message format
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
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
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
Ranging Sync vulnerability
Ranging Sync vulnerability
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
WiMAX Analysis
• Found 3 potential vulnerabilities
• But, they are hard to instigate as they require:– Considerable hardware to spoof the
messages– Correct timing
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
EAP and associated layers
PPP802.3
Ethernet
802.5
Token Ring
802.11
WLAN
802.11
Serial Link
EAP-FASTPEAP EAP-SIM EAP-AKAEAP-TLS
EAP Over LAN (EAPOL)
Extensible Authentication Protocol (EAP)
EAP Layer
Data Link Layer
Authentication method layer
EAP Message Exchange Framework
(EAP-Response Identity)
EAP-Response Identity
EAP-Success
APPeer
(EAP-Request Identity)
Method specific EAP Request
Method specific EAP Response
Repeat until success or fail
Server
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
Inner method Server
Peer
EAP-FAST Start [A-ID]
EAP-FAST [TLS Client Hello[Client_Random,PAC-Opaque]]
Authentication with a inner Authentication method
Optional PAC Refresh
EAP Success
AP EAP-FAST server
PAC Provisioning
EAP Request/Identity
EAP Response/Identity (anonymous@realm)
EAP-FAST [TLS Server Hello[Server_Random]]
TLS change Cipher Spec
TLS Finished
TLS change Cipher Spec
TLS Finished
Phase 2
Phase 1
Phase 0
Establish Secure Channel
Establish Secure Channel
Establish connection
(for example, TCP)
TLS Tunnel established
TLS Tunnel torn down
EAP-FAST choreography overview
Messages within EAP-FAST
Message Channel Protected?
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
Authentication with a inner Authentication method, protected by TLS tunnel
EAP-Success AP- to-MS NO
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
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.
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]
EAP-FAST Analysis
• No vulnerability was found wihin EAP-FAST!
Future work
• Study internal attacks– Till now the focus was on external attacks
• Resource Depletion attacks