Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Exploring the MediaTek Baseband

Marco Grassi
February 14, 2020

Exploring the MediaTek Baseband

Marco Grassi

February 14, 2020
Tweet

More Decks by Marco Grassi

Other Decks in Research

Transcript

  1. Exploring the MediaTek Baseband
    Marco Grassi (@marcograss) – Kira (@0xKira233)

    View full-size slide

  2. About Us
    • Members of Tencent KEEN Security Lab (formerly known as KeenTeam)
    • Marco (@marcograss):
    • My main focus is iOS/Android/macOS and sandboxes. But now shifted to hypervisors, basebands, firmwares etc.
    • pwn2own 2016 Mac OS X Team
    • Mobile pwn2own 2016 iOS team
    • pwn2own 2017 VMWare escape team
    • Mobile pwn2own 2017 iOS Wi-Fi + baseband team
    • Kira (@0xKira233):
    • Security researcher at Tencent KeenLab
    • Interested in hypervisors, basebands etc.
    • CTF player in AAA / A*0*E, DEFCON 25 & 26

    View full-size slide

  3. About Tencent Keen Security Lab
    • Previously known as KeenTeam
    • White Hat Security Researchers
    • Several times pwn2own winners
    • We are based in Shanghai, China
    • Our blog is
    https://keenlab.tencent.com/en/
    • Twitter @keen_lab

    View full-size slide

  4. Agenda
    • Previous Research
    • Networks (2G-5G)
    • 5G
    • Baseband Overview
    • The MTK Baseband
    • Conclusions

    View full-size slide

  5. Previous Research on MediaTek
    • “Understanding, Debugging and Attacking the MediaTek
    communication processor” - Charles Muiruri , Nitay Artenstein, Anna
    Dorfman
    • Introduces the MediaTek modem, where it’s popular and internal structure
    • “Path of Least Resistance: Cellular Baseband to Application Processor
    Escalation on MediaTek Devices” – Comsecuris, György Miru
    • Examine the attack surface from the modem to the application processor in
    order to escape the modem and compromise the phone, with a bug.
    • Not much public research

    View full-size slide

  6. Previous Research on Basebands
    • Exploitation of a Modern Smartphone Baseband (Huawei modem) –
    Keen Lab
    • A Walk With Shannon (Samsung modem) – Amat Cama
    • Comsecuris Blogpost (Intel Baseband)

    View full-size slide

  7. How this research started
    • In 2019 we got a contract with a vendor to improve the security of
    their modem
    • Recently we are working on a 5G project with another vendor
    • We previously worked on basebands and also a little bit on the
    MediaTek modem
    • We disclosed to the vendor a bunch of bugs in the modem and they
    were fixed
    • This talk covers some of our work, and how to bootstrap your own
    research on this modem.

    View full-size slide

  8. Why researching the MediaTek platform is
    relevant
    • “According to research company Statista, Qualcomm had 45%
    overall market share in 2018, followed by Apple with 17%, Samsung
    with 14%, MediaTek with 11% and Huawei with 8%.Aug 25, 2019”
    • MediaTek has a significant market share, especially on budget-mid
    price devices
    • They implement a lot of components, the SoC, the modem, etc
    • In Europe also there are several popular devices using the MediaTek
    SoC and Modem.

    View full-size slide

  9. Networks Overview
    • A modem (or “baseband”) is a
    set of hardware component that
    implements a set of
    specifications to communicate
    with a cellular network.
    • Several “generations”
    implemented, 2G to 5G usually
    Source: ResearchGate

    View full-size slide

  10. Networks overview (cont)
    • Old generations, 2G 2.5G
    for example, the phone
    don’t authenticate the
    base station
    • Possible to setup a fake
    base station and
    impersonate
    • Send malicious data
    (exploit)
    • Some newer stacks starting
    from 3G the phone
    authenticate the BTS
    • Not all layers and
    components are protected

    View full-size slide

  11. Network Overview (cont)
    • Like most well known network
    stacks, mobile stacks are also
    “layered”
    • Complexity often progressively
    higher the higher you go on the
    stack
    • (think like the difference TCP/IP
    vs full blown HTTP web app
    running on top of it)

    View full-size slide

  12. 5G, Why 5G?
    • 2G/3G/4G the goal was to have cheap phones and cheap call/data
    plans, to get everyone connected.
    • 4G, high bandwidth, rich media, HD videos, content.
    • Now everyone has a smartphone with a data plan, how the carriers
    can make more money? There are no more people to sell a
    smartphone and a data plan.

    View full-size slide

  13. 5G, Why 5G?
    • 5G => cheap radios, lot of capacity.
    • How carrier can make money?
    • Connect everything! Devices, cars, sensors.
    • People already connected, now the only way to expand the market is
    to connect “THINGS”

    View full-size slide

  14. 5G, The big players
    • Huawei
    • Qualcomm
    • Intel
    • ZTE
    • Ericsson
    • Nokia
    • Samsung
    • …

    View full-size slide

  15. 5G, critical infrastructure
    • Expected capacity: 1 million connected objects for 1 km2
    • In a 4G and lower network, most of the consumer are end users
    • In a 5G network?
    • Private deployments (in a factory for example, instead of using wires)
    • Connect industrial robots
    • Fleet of shared cars in a network slice
    • Medical equipment/ personal health equipment
    • Semaphores/ road traffic management network.
    • In a 4g network, reliability is important, but not TOO critical
    • In a 5g one, it might be, if you control critical infrastructure.
    • Also the connected devices are different in nature.

    View full-size slide

  16. 5G, not only smartphones
    • This talk is mostly focused on
    smartphones because now they are
    the main consumers of baseband
    devices.
    • But this is rapidly changes, it can be
    readily applied to other areas such as
    smart cars, which have a modem of
    course.
    • Also, the “endpoints” are not the only
    attackable target .. Also base stations

    View full-size slide

  17. 5G not only smartphones, use cases
    • Enhanced Mobile Broadband (eMBB): richer and faster data
    consumption for humans, high definition videos, downloads etc.
    • Ultra-Reliable Low-Latency Communications (URLLC): MISSION
    CRITICAL applications, that cannot afford delays and unreliabilities.
    • Massive Machine-Type Communications (mMTC): Big networks of
    potentially low power devices. It must support low power consumtion
    and high capacity and low cost.

    View full-size slide

  18. 5G devices we are currently researching on
    • Huawei, recent models, mate30
    pro, and portable wifi 5g router
    • Samsung Note 10 5g
    • Qualcomm devices

    View full-size slide

  19. Opensource 5G base station
    • There is no completely ready solution yet
    • Eurecom is working on the OpenAir5G and
    created a consortium to foster the
    development of a opensource 5G stack
    • Possible to use it with a SDR such as a USRP
    B210
    • Still work in progress
    • We are actively tracking the progress and we
    hope we can use it (and maybe contribute to
    it) in the future for our 5G testing, without
    having to use closed source testing
    equipment

    View full-size slide

  20. Setting up a BTS software, TIPS and TRICKS
    • The best solution in our opinion
    for now is to use docker on linux
    • Can proxy the USB directly
    without the overhead of a
    virtualized USB 3.0 controller
    (latencies are bad for SDR)
    • The BTS software expects all kind
    of weird requirements, from
    linux version, to dependencies,
    to the most exotic ones: kernel
    changes or modules
    docker run -t -i --privileged -v /dev/bus/usb:/dev/bus/usb
    ubuntu bash

    View full-size slide

  21. Attacking the baseband in one slide
    + =
    Modified Base station software stack
    to trigger the exploit
    OpenBSC
    OpenBTS
    srsLTE

    Software defined Radio, or
    equivalent hardware
    USRP
    BladeRF
    CMU200 (Testing
    hardware)
    Over the air
    exploit RCE inside the
    phone
    baseband

    View full-size slide

  22. A Modern Smartphone Architecture
    • A modern smartphone is not a single CPU
    executing an OS anymore.
    • Several other processors involved in the radio
    area:
    • Baseband processor
    • Wi-Fi and Bluetooth SoC
    • The baseband handles the radio
    communication with many types of
    networks: 2G, 3G, 4G, 5G etc.
    • Those radio components can be attacked
    remotely Source:
    https://googleprojectzero.blogspot.com/2017/04/over-air-
    exploiting-broadcoms-wi-fi_4.html

    View full-size slide

  23. A Modern Smartphone Architecture 2
    • The AP runs your OS and apps
    (Android for example)
    • The Baseband runs a RTOS
    • They communicate with
    • USB
    • PCI-e
    • Shared Memory
    • SDIO
    • …
    • Separate systems. If you get RCE you
    run code on the Baseband, not the AP.
    • The Basebands lag behind in terms of
    mitigations compared to the AP
    • This lack of mitigations is widespread
    between all manufacturers.
    Source : https://www.evelta.com/introduction-smartphone-
    architecture

    View full-size slide

  24. The Baseband
    • Necessary components
    • RTOS
    • TEEOS handlers
    • Kernel modules
    • Usermode binary / library (RILD) / application
    • …
    • Most of them are attackable which depends on your target.

    View full-size slide

  25. How to start your research
    • Read the previous work, mentioned before
    • Download what you can download from the network.
    • Leaked source code if any
    • Reverse scripts
    • Vendor specific code
    • …
    • Extract the firmware from phone
    • Reverse engineering and bug hunting
    • 3GPP TS

    View full-size slide

  26. Leaks online
    • There is a widely available old version leaked on github, of some
    source code, and object files
    • Old ARM version
    • Might be still useful for bug hunting
    • You still need the firmware of the target though
    • The object files can be recompiled and linked together to fuzz in a
    binary instrumentation environment such as QEMU

    View full-size slide

  27. Architecture of MTK Baseband
    • Lots of functional tasks took over by RTOS
    • CM / MM / RR / SM / CC , etc
    • AT commands to communicate
    • Shared memory between AP and CP
    • CCCI (Cross Core Communication Interface)
    • IPC channel
    • /dev/tty[s]
    • CCCI FS
    • IOCTL

    View full-size slide

  28. Extract the firmware
    • Assume you have a rooted device
    • Available at /dev/block/by-name/*
    • For kernel
    • /dev/block/by-name/boot
    • Great tool: https://github.com/nforest/droidimg
    • For modem
    • /dev/block/by-name/md1img
    • No encryption at all

    View full-size slide

  29. Extract modem firmware
    • Format can be found in the source
    • 010 editor template to visualize
    • Code named md1rom
    • MIPS16e2
    • 52.4 MB
    • Debug symbol named md1_dbginfo
    Source: https://www.mips.com/press/mediatek-selects-mips-for-lte-modems/

    View full-size slide

  30. What is MIPS16e2
    • IDA pro failes to disassemble new instructions
    • We wrote tools to help reverse
    Source: https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD01172-2B-MIPS16e2-AFP-01.00.pdf

    View full-size slide

  31. Start to reverse
    • Load symbols from dbg file
    • Found in the image and sdcard.
    • Format can be guessed
    • Or explained in detail:
    tools/DebuggingSuite/convertAddr2FuncAndFile.pl
    • Fix the segments in IDA
    • Guess the base? No!
    • https://github.com/sgayou/rbasefind
    • Find some entrances to audit
    • Important functions’ handlers

    View full-size slide

  32. Task example
    • MM (Mobility Management) task
    • Main function, typical of RTOS
    system and modem, endless
    while loop, waiting and
    dequeuing messages and
    handling them.
    • It receives messages from other
    tasks and invokes mm_main

    View full-size slide

  33. Task example (cont)
    • Huge switch cases
    depending on the
    message ID
    • It’s not hard to find
    message handlers,
    although they are
    sometimes deep into
    the state machine
    • With the
    specifications you can
    search for the method
    names as well

    View full-size slide

  34. Fuzzing the binary
    • Target requirements
    • Complex enough to fuzz
    • No / Very few IPC calls
    • Decode / unpack functions catch our attention
    • mcd_unpack
    • errc_asn1_decoder
    • …
    • Write a C wrapper to call the target
    • Link what we need and compile provided APIs
    • AFL QEMU mode to do the fuzzing

    View full-size slide

  35. Crash log
    • Log shows in demsg
    • Log files store in the sdcard
    • Built-in log tool: *#800# --> Logkit
    • MTK makes its own format
    • Logged by dhl_trace and other similar functions
    • Reverse to get more information

    View full-size slide

  36. mcd_unpack
    • General message unpack function
    • Every message is handled by it first
    • BER encoding / TLV, bit stream like processing

    View full-size slide

  37. mcd_unpack
    • Crashes collected and reported
    • Each msgid has its sequence of
    opcodes
    • Works like a CPU
    • mcd_unpack_MAXBYTES kills
    most of memory corruption in
    advance
    • Restrict the length at the first stage

    View full-size slide

  38. Vulnerability cases
    • CEmmNMSrv::decodeEmergencyNumberList
    • EMM ATTACH ACCEPT message
    • No check on the index
    • No check whether the source msg is big enough
    • Heap overflow / OOB read
    Source: 3GPP TS 24.008 g20

    View full-size slide

  39. Vulnerability cases
    • sm_unpack_config_option
    • ACTIVATE PDP CONTEXT ACCEPT message
    • config_len_arr is an array on the stack
    • No check on the length from our message
    • Stack overflow
    Source: 3GPP TS 24.008 g20

    View full-size slide

  40. Writing POC
    • Our environment
    • Ubuntu 18.04 docker
    • OpenBTS
    • USRP B210
    • Find the corresponding class
    • Modify the WriteBody method
    • OpenBTS will do the rest

    View full-size slide

  41. Mitigations (or lack of)
    • Lag behind the modern expected baseline
    • No stack cookies in functions performing copies with stack
    destinations.

    View full-size slide

  42. Thanks
    • We would like to thank the vendor we cooperated with and MediaTek
    for fast response and friendly atmosphere
    • Open to discussion and feedback
    • Very positive experience

    View full-size slide