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