Cатсн²² (in)sесuяitу / ChrisJohnRiley

All your baseband are belong to us Ralf Philipp Weinmann

Talk covers baseband (in)security and the process used to find bugs, as well as possible exploitation and what it means to people.

PART I

MS (Mobile Station) => BTS Base Transceiver Station

Layers of the GSM Um interface

• Layer 3
  • Connection Management (MM)
  • Mobility Management (MM)
  • Radio Resource (RR)
• LAPDm (Layer 2)
• Layer 1

Why smartphones?

Somewhere in the late 20th century, PDAs and cellular phones merged

Result: Smartphones

Have driven PDAs into extinction

Usually multi-CPU architecture: application processor (APP) and baseband (BB) processor

In 99% of all cases, ARM CPUs used for both

Trend: single-chip APP/BB (for cost saving)

Type 1

Application Processor (with isolated RAM)

Digital Baseband Processor (with isolated RAM)

Type 2

Application Processor

Digital Baseband Processor

Shared RAM

PART II: Baseband (in)security

Codebase created in the 90’s

This shows in the attitude to security

Network elements are considered trusted (BTS)

Both GSM and UMTS protocols have many, many length fields

(Almost) no exploit mitigations (iPhone4 now has hardware DEP)

Demo = > Heap overflow in the iPhone (patched this week by Apple)

Layer 1: not fruit

Layer 2: messages too short

Layer 3: Specified in GSM 04.08

• Allows for variable length messages
• Max length: 255 octets

ASN.1 used as well (e.g. RRLP)

GPRS Layer: very fruitful

• GPRS not supported by openBTS
• Layer 1 is different

Initial targets: iPhone (Infineon) and HTC G1 (Qualcomm)

Fuzzing didn’t help much… no way to track the crash to a source

The best plan seemed to be static source-code analysis

Not easy to get… No public sources

Conclusion: Reverse Engineering of binaries

How to start

Firmware updates often contain baseband firmware as well

Packed multiple times

Tools exist for iPhone and HTC

Qualcomm firmware: ELF files

Infineon needs custom loaders

Later: Ability to dump memory/MMU config

Reverse-engineering

Bootstrap: use BinDiff to port symbols from known libraries (i.e. compiler runtimes)

Identify functions that do memory transfers using REIL and BinNavi

Lots of strings and assertions (!) in firmware

Often: Clean-out regions for RR/MM/AT command parser in binary

HexRays ARM Decompiler: potential to speed up work greatly

Identified functions handling GSM frames

• Problem: apparently different tasks
• Assertions/logging

Types of bugs found

Lots of unchecked memory copies (memcpy())

Object/structure life-cycle issues (use after free, uninitialized variables,…)

Protocol foo-bars (code paths used by UMTS/CMDA can be triggered using GSM frames)

An example (in ICE basebands)

TMSI reallocation

• TMSI always, always, always is 32 bits
• nonetheless encoded as tLV

Infineon stack uses length in L3 packet

Result: heap overflow

Somewhat tricky to exploit in a stable fashion

iPhone 2/3G/3GS vs iPhone 4: different RTOS

• old phones nucleus
• new phones ThreadX

An example (in QCOM codebase)

GSM & UMTS uses challenge-response auth

Always 128bits

Result: heap overflow (with 73 bytes of code)

Easier to exploit that the previous exploit

QCOM have fixed this bug, but it may not be at the end-user yet!

Allows complete remote code exec, pre auth

AT+S0=n feature

Hayes command to turn on auto-answer

Present in some software stacks (verified in Infineon and QCOM)

Enable with *5005*AANS# on the iPhone

Disable with #5005*AANS#

Auto-answer can be made completely silent

Why should we care

New base stations are getting cheaper

Hardware is sold of cheap on eBay

Open-source projects to work with these hardware

Hardware:

nanoBTS

Ettus USRPv1 (change the clock)

Part III: Common failures in exploitation

Lacking lock precision

Misinterpreting stack traces

Triggering the bug (there may be more than 1 in a function)

Overlooking code is placed in non-exec page

Part IIII: Baseband Apocalypse

Place fake BTS in crowded/sensitive area

Stealth room monitor (audio bug)

Shared memory architecture (compromise APP CPU as well to backdoor the smartphone)

Ping-pong games (infect a phone and continue on to infect further systems)

Brick phones permanently

No easy forensics possible here (everything in RAM)

The scary bit

How do we defend ourselves

Can you even be sure your iPhone is off and not just with a blank screen?

Is there still hope?

Sure… OsmocomBB

Open-source GSM baseband stack

Implements layer 1-3

Target platform: Calypso chipsets

Present in openMoko

Work in progress!

Disclosure and Reactions

QCOM have been fantastic

Apple fixed TMSI bug this week

Vendor outreach by Microsoft

ST-Ericsson: Seem to misunderstand some things!

Outlook

Will see the same problems for 3GPP/UMTS

3GPP uses mutual auth…

Implementation is complex (lots of documentation, easy to get things wrong)

Femto cells as cheap attack platforms in the future

Conclusions

Memory corruptions over the Um interface are practical even with cheap hardware

Vulnerabilities are plentiful

Small number of baseband vendors

Exploitation gives complete access

…

Links:

• Talk synopsis –> HERE
• https://cryptolux.org
• Talk Slides –> Hack.lu Version –> HERE
• Osmocombb –> HERE