C3Subtitles: rc3: Fuzzing the phone in the iPhone
back

Fuzzing the phone in the iPhone

D-d-d-di-di-d-d-di-d-di-d-di-d-dimm!

If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!

Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.

Video duration
00:55:11
Language
English
Abstract
How secure is the interface between baseband chips and iOS?
While this interface should protect against escalations from the baseband into operating system components, its implementation is
full of bugs. Fuzzing this interface is not only relevant to security, but also results in various funny effects, since the iPhone looses
information about its identity and location, and eventually ends up in a state with a few thousand unread SMS that can no longer be deleted.

The baseband chip is the phone within a smartphone. While users might disable Bluetooth or not join untrusted Wi-Fis to increase security, mobile data and phone calls are always on. Some baseband features remain enabled even without an active data pass or SIM card installed.
Thus, baseband chips are a popular target for Remote Code Execution (RCE) attacks. Launched over-the-air, they do not leave any trace on intermediate servers.

With recently published tools, emulating and fuzzing baseband firmware has become accessible and gained a lot of attention by security researchers.
Yet, a critical part of an exploit chain remains escalating from the baseband chip into the operating system. An attacker with code execution in the baseband chip could modify network traffic and escalate with a Web browser exploit. However, wireless communication is already susceptible to manipulation without a baseband exploit due to missing user data integrity protection, as shown by the IMP4GT attacks on LTE.
Moreover, network traffic manipulation still requires the attacker to wait until their target creates traffic in the context of a Web browser.

More stealthy attacks can be achieved via baseband activity that does not require any user interaction, such as retrieving information about nearby base stations. On an iPhone, the interface forwarding this information comes in two variants for Intel and Qualcomm baseband chips. Both interfaces interact with CommCenter, which is the phone component of the iPhone that parses and forwards phone calls, SMS, and more.

This talk demonstrates how to fuzz these interfaces as well as various challenges and solutions in fuzzing these. The baseband interface is such an integral part of iOS that fuzzing results are not limited to finding issues within CommCenter but also led to discovery of bugs in various daemons connecting to it. Some of these issues might also be triggered by a rouge base station, though, fuzzing the baseband interface locally results in higher performance and more control.

Fuzzing the baseband interface demonstrates fuzzing in a way that is easy to understand even for those who are not familiar with security research. The iPhone under test receives SMS so fast that it will not finish playingthe <i>Dimm</i> notification sound before the next SMS arrives, and, thus,
this actually sounds like <i>D-d-d-di-di-d-d-di-d-di-d-di-d-dimm!</i> The sound effect when the audio controller hangs up is also quite fun. Exposure notifications are no longer available due to the location change, since the iPhone uses baseband information to determine its region. And due to all the confusion about its identity, it regularly asks for activation.

Besides security analysis, understanding the baseband interface means that it can also be controlled on jailbroken iPhones. Moreover, passive observations are possible on non-jailbroken devices with a baseband debug profile. This opens up these devices for new wireless research opportunities.

Talk ID
11358
Event:
rc3
Day
2
Room
rC2
Start
1:40 p.m.
Duration
01:00:00
Track
IT-Security
Type of
lecture
Speaker
jiska

Talk & Speaker speed statistics

Very rough underestimation:
151.7 wpm
826.7 spm
100.0% Checking done100.0%
0.0% Syncing done0.0%
0.0% Transcribing done0.0%
0.0% Nothing done yet0.0%

Talk & Speaker speed statistics with word clouds

Whole talk:
151.7 wpm
826.7 spm