Talks about baseband vulnerabilities are certainly in fashion these days. However, most publications so far omit the step of escaping the baseband runtime. With the novelty of baseband-only vulns wearing off, we decided to look at some popular targets (Samsung and MediaTek smartphones) with full chain exploitation in mind.
Over the last year, our research has resulted in a dozen+ CVEs, including both remote code execution vulnerabilities and baseband-to-Android pivot vulnerabilities. I will be presenting the details of our work at the upcoming Hardwear.io conference, where we’ll also deliver a training on the subject. Full vulnerability details will be held back until the conference at vendor request.
nanoMIPS: (na)noPROBLEM
In our last published Mediatek baseband research we explored the unique MIPS16e2 architecture of Helio chipset basebands. However, starting in 2021, with Dimensity chipsets, Mediatek made a switch to nanoMIPS. This is a new challenge as basically all tool support was lacking for this ISA.
Public work so far hasn’t really covered this change - apart from recurring reminders from the research community about the missing tooling :)
To deal with static analysis, we developed our own decompiler as a new Ghidra extension for the nanoMIPS architecture. We already talked about the flexiblity of Ghidra when it comes to writing new decompiler targets when we published our work on Helio last Spring. This time we were able to achieve the same result for nanoMIPS.
To augment static analysis, we also implemented our own baseband debugger for Dimensity chipsets…
… and we added nanoMIPS support for some popular dynamic analysis tools like qemu, gdb, and libAFL, where support was either incomplete or missing entirely.
Re-breaking Band
After MediaTek’s Dimensity, I also took a fresh look at Samsung Exynos and Shannon.
In contrast to MediaTek basebands built on the Nucleus RTOS, Samsung’s Shannon baseband has been explored publicly a lot more in the time since Breaking Band. Returning to this target for public research for the first time after many years, I found that architectural changes since that 2015 work have been quite a lot smaller compared to changes observed over the same timespan in the cases of other basebands.
Certainly, some runtime changes have been introduced since early Exynos SoC basebands - most notably a switch to A-series ARM cores and with it the change from MPU to MMU. Eventually Samsung also added some exploit mitigations, as it has been already documented by others, like introducing stack cookies or removing gaps in the N^X configurations.
By and large, firmware image formatting and the runtime has remained constant. As such, image loaders, reverse engineering helper auto-labeling scripts, or the on-demand memory ramdumping feature continue to work as they used to.
All told, with changes not too significant and all manners of tools and reverse engineering details made available by publications over the years (FirmWire, BaseSAFE, and Grant’s Ghidra scripts in particular, in addition to the OG scripts from Breaking Band), the Shannon runtime could be considered a commodity target nowadays. For a vulnerability hunter this is good news in terms of the ability to jump into a target more easily.
On the other hand, the increased scrutiny also means that certain attack surfaces have become a lot more mined nowadays. Samsung implemented some notable code refactoring over the years as well, like the switch from one 3rd party ASN1 decoder library to another or the gradual introduction of centralized sanity checking of NAS IE formats in the decoding pipelines. At the same time, driven of course by the evolution of radio access technologies, the Shannon RTOS also got enriched with brand new technologies like the VoLTE and NR stacks.
New code often proves a boon for the bug hunter, and others have already presented powerful demonstrations of how successful some of these efforts have been from an attack surface reduction standpoint. Nonetheless, we were still able to find some bugs in places where others didn’t yet look at the time - or perhaps did ;)
Same, Same, But Different
For remote vulnerabilities, we once again hoped to find something new by looking for bug patterns at least a little bit different from classic “unchecked length” BOFs and integer overflows in NAS parsing or ASN1 decoding. At Hardwear.io we’ll be able to expand on the security bulletins with additional details on how this bug hunting turned out!
After finding and reporting some bugs in Mediatek and Samsung basebands, we were also interested in the changes that the OEMs made in response to reports. In particular, we looked into what Mediatek has changed since our last disclosures on this topic, in which we described some heap exploitation techniques.
We were glad to see new heap hardening mitigations added that aimed to address our previous techniques. Naturally, we set out to identify some new techniques instead. We’ll describe our findings in the talk. Spoiler alert: it wasn’t a total failure 😅
Last but not least, we explored different attack surfaces in the Linux kernel and Android, looking for baseband-to-AP pivot vulnerabilities in both MediaTek and Samsung. We have talked about these kinds of bugs before (e.g. in our Black Hat talk in 2021) but this time we applied the ideas to new targets.
The results were a handful of vulnerabilities (10 CVEs published so far) that may result in memory corruption, information leaks, and eventually code execution.
From the MediaTek Security Bulletin, July 2022:
From the Samsung Security Bulletin, July 2023:
For more information, make sure to join us at Hardwear.io for the talk!
One More Thingraining
Of course I won’t be able to include every detail in just 45 minutes. However, there’s more good news for those interested in baseband vulnerability research: at Hardwear.io this year we will also present a baseband hacking training!
Bug bounty hunters, vendors, and academia are not the only ones to have put increasing focus on baseband security over the last decade-plus. Offensive security companies have turned their attention to the baseband as a binary exploitation attack vector as well.
Unsurprisingly, just like with other targets, there are differences between making something work for a publication and building out an actual offensive capability. Alas, the training’s focus will be bridging the gap between the challenges addressed by baseband research demonstrations and operational use.
The training will be hands-on from start to finish: each participant will be able to work with SDR equipment directly and gain hands-on experience in installing and running networks, attaching to phones, and delivering payloads.
Seats are filling up fast, but there are still a couple left. Grab yourself a ticket before they are gone! :)