SearcharxivSearch

arXiv subjects

Jiska Classen

Publications and source records attributed to Jiska Classen.

At least 19 recordsLinked to original sources

Unlocking Apple's Private Cloud Compute: An Analysis of Privacy-Preserving Artificial Intelligence

Many existing Artificial Intelligence (AI) solutions on mobile devices rely on an extensive collection of sensitive data, raising privacy concerns and often requiring storage for both context and model improvement. Apple's Private Cloud Compute (PCC) aims to address this by emphasizing mobile device integration and a privacy-first design. The central claim of PCC is that it does not store any user data and that user input and user accounts are unlinkable. While most of the PCC system specifications are public, compiled binaries add a layer of opaqueness. There are no reproducible builds, and there are no symbols within those binaries, creating potential discrepancies between the specification and what is shipped to the user. Additionally, the underlying models and interfaces for querying PCC are not openly accessible, limiting academic evaluation of model properties, such as accuracy. This poses a challenge in assessing whether a privacy-preserving approach like PCC is actually trustworthy while also providing high-quality answers. We are the first to reverse-engineer the PCC implementation on mobile devices to evaluate privacy aspects and to open its non-public interfaces on local devices to support custom PCC queries. We demonstrate this level of access beyond Apple's intended use cases by independently benchmarking the PCC model. We enable future research by making our PCC benchmarking framework publicly available.

cs.CR

ARIstoteles -- Dissecting Apple's Baseband Interface

Wireless chips and interfaces expose a substantial remote attack surface. As of today, most cellular baseband security research is performed on the Android ecosystem, leaving a huge gap on Apple devices. With iOS jailbreaks, last-generation wireless chips become fairly accessible for performance and security research. Yet, iPhones were never intended to be used as a research platform, and chips and interfaces are undocumented. One protocol to interface with such chips is Apple Remote Invocation (ARI), which interacts with the central phone component CommCenter and multiple user-space daemons, thereby posing a Remote Code Execution (RCE) attack surface. We are the first to reverse-engineer and fuzz-test the ARI interface on iOS. Our Ghidra scripts automatically generate a Wireshark dissector, called ARIstoteles, by parsing closed-source iOS libraries for this undocumented protocol. Moreover, we compare the quality of the dissector to fully-automated approaches based on static trace analysis. Finally, we fuzz the ARI interface based on our reverse-engineering results. The fuzzing results indicate that ARI does not only lack public security research but also has not been well-tested by Apple. By releasing ARIstoteles open-source, we also aim to facilitate similar research in the future.

cs.CR

Modern iOS Security Features -- A Deep Dive into SPTM, TXM, and Exclaves

The XNU kernel is the basis of Apple's operating systems. Although labeled as a hybrid kernel, it is found to generally operate in a monolithic manner by defining a single privileged trust zone in which all system functionality resides. This has security implications, as a kernel compromise has immediate and significant effects on the entire system. Over the past few years, Apple has taken steps towards a more compartmentalized kernel architecture and a more microkernel-like design. To date, there has been no scientific discussion of SPTM and related security mechanisms. Therefore, the understanding of the system and the underlying security mechanisms is minimal. In this paper, we provide a comprehensive analysis of new security mechanisms and their interplay, and create the first conclusive writeup considering all current mitigations. SPTM acts as the sole authority regarding memory retyping. Our analysis reveals that, through SPTM domains based on frame retyping and memory mapping rule sets, SPTM introduces domains of trust into the system, effectively gapping different functionalities from one another. Gapped functionality includes the TXM, responsible for code signing and entitlement verification. We further demonstrate how this introduction lays the groundwork for the most recent security feature of Exclaves, and conduct an in-depth analysis of its communication mechanisms. We discover multifold ways of communication, most notably xnuproxy as a secure world request handler, and the Tightbeam IPC framework. The architecture changes are found to increase system security, with key and sensitive components being moved out of XNU's direct reach. This also provides additional security guarantees in the event of a kernel compromise, which is no longer an immediate threat at the highest trust level.

cs.CR

WatchWitch: Interoperability, Privacy, and Autonomy for the Apple Watch

Smartwatches such as the Apple Watch collect vast amounts of intimate health and fitness data as we wear them. Users have little choice regarding how this data is processed: The Apple Watch can only be used with Apple's iPhones, using their software and their cloud services. We are the first to publicly reverse-engineer the watch's wireless protocols, which led to discovering multiple security issues in Apple's proprietary implementation. With WatchWitch, our custom Android reimplementation, we break out of Apple's walled garden -- demonstrating practical interoperability with enhanced privacy controls and data autonomy. We thus pave the way for more consumer choice in the smartwatch ecosystem, offering users more control over their devices.

cs.CR

Evil Never Sleeps: When Wireless Malware Stays On After Turning Off iPhones

When an iPhone is turned off, most wireless chips stay on. For instance, upon user-initiated shutdown, the iPhone remains locatable via the Find My network. If the battery runs low, the iPhone shuts down automatically and enters a power reserve mode. Yet, users can still access credit cards, student passes, and other items in their Wallet. We analyze how Apple implements these standalone wireless features, working while iOS is not running, and determine their security boundaries. On recent iPhones, Bluetooth, Near Field Communication (NFC), and Ultra-wideband (UWB) keep running after power off, and all three wireless chips have direct access to the secure element. As a practical example what this means to security, we demonstrate the possibility to load malware onto a Bluetooth chip that is executed while the iPhone is off.

cs.CR

Very Pwnable Network: Cisco AnyConnect Security Analysis

Corporate Virtual Private Networks (VPNs) enable users to work from home or while traveling. At the same time, VPNs are tied to a company's network infrastructure, forcing users to install proprietary clients for network compatibility reasons. VPN clients run with high privileges to encrypt and reroute network traffic. Thus, bugs in VPN clients pose a substantial risk to their users and in turn the corporate network. Cisco, the dominating vendor of enterprise network hardware, offers VPN connectivity with their AnyConnect client for desktop and mobile devices. While past security research primarily focused on the AnyConnect Windows client, we show that Linux and iOS are based on different architectures and have distinct security issues. Our reverse engineering as well as the follow-up design analysis and fuzzing reveal 13 new vulnerabilities. Seven of these are located in the Linux client. The root cause for privilege escalations on Linux is anchored so deep in the client's architecture that it only got patched with a partial workaround. A similar analysis on iOS uncovers three AnyConnect-specific bugs as well as three general issues in iOS network extensions, which apply to all kinds of VPNs and are not restricted to AnyConnect.

cs.CR

Attacks on Wireless Coexistence: Exploiting Cross-Technology Performance Features for Inter-Chip Privilege Escalation

Modern mobile devices feature multiple wireless technologies, such as Bluetooth, Wi-Fi, and LTE. Each of them is implemented within a separate wireless chip, sometimes packaged as combo chips. However, these chips share components and resources, such as the same antenna or wireless spectrum. Wireless coexistence interfaces enable them to schedule packets without collisions despite shared resources, essential to maximizing networking performance. Today's hardwired coexistence interfaces hinder clear security boundaries and separation between chips and chip components. This paper shows practical coexistence attacks on Broadcom, Cypress, and Silicon Labs chips deployed in billions of devices. For example, we demonstrate that a Bluetooth chip can directly extract network passwords and manipulate traffic on a Wi-Fi chip. Coexistence attacks enable a novel type of lateral privilege escalation across chip boundaries. We responsibly disclosed the vulnerabilities to the vendors. Yet, only partial fixes were released for existing hardware since wireless chips would need to be redesigned from the ground up to prevent the presented attacks on coexistence.

cs.CR

Ghost Peak: Practical Distance Reduction Attacks Against HRP UWB Ranging

We present the first over-the-air attack on IEEE 802.15.4z High-Rate Pulse Repetition Frequency (HRP) Ultra-WideBand (UWB) distance measurement systems. Specifically, we demonstrate a practical distance reduction attack against pairs of Apple U1 chips (embedded in iPhones and AirTags), as well as against U1 chips inter-operating with NXP and Qorvo UWB chips. These chips have been deployed in a wide range of phones and cars to secure car entry and start and are projected for secure contactless payments, home locks, and contact tracing systems. Our attack operates without any knowledge of cryptographic material, results in distance reductions from 12m (actual distance) to 0m (spoofed distance) with attack success probabilities of up to 4%, and requires only an inexpensive (USD 65) off-the-shelf device. Access control can only tolerate sub-second latencies to not inconvenience the user, leaving little margin to perform time-consuming verifications. These distance reductions bring into question the use of UWB HRP in security-critical applications.

cs.CR

Happy MitM: Fun and Toys in Every Bluetooth Device

Bluetooth pairing establishes trust on first use between two devices by creating a shared key. Similar to certificate warnings in TLS, the Bluetooth specification requires warning users upon issues with this key, because this can indicate ongoing Machine-in-the-Middle (MitM) attacks. This paper uncovers that none of the major Bluetooth stacks warns users, which violates the specification. Clear warnings would protect users from recently published and potential future security issues in Bluetooth authentication and encryption.

cs.CR

Firmware Insider: Bluetooth Randomness is Mostly Random

Bluetooth chips must include a Random Number Generator (RNG). This RNG is used internally within cryptographic primitives but also exposed to the operating system for chip-external applications. In general, it is a black box with security-critical authentication and encryption mechanisms depending on it. In this paper, we evaluate the quality of RNGs in various Broadcom and Cypress Bluetooth chips. We find that the RNG implementation significantly changed over the last decade. Moreover, most devices implement an insecure Pseudo-Random Number Generator (PRNG) fallback. Multiple popular devices, such as the Samsung Galaxy S8 and its variants as well as an iPhone, rely on the weak fallback due to missing a Hardware Random Number Generator (HRNG). We statistically evaluate the output of various HRNGs in chips used by hundreds of millions of devices. While the Broadcom and Cypress HRNGs pass advanced tests, it remains indistinguishable for users if a Bluetooth chip implements a secure RNG without an extensive analysis as in this paper. We describe our measurement methods and publish our tools to enable further public testing.

cs.CR

Frankenstein: Advanced Wireless Fuzzing to Exploit New Bluetooth Escalation Targets

Wireless communication standards and implementations have a troubled history regarding security. Since most implementations and firmwares are closed-source, fuzzing remains one of the main methods to uncover Remote Code Execution (RCE) vulnerabilities in deployed systems. Generic over-the-air fuzzing suffers from several shortcomings, such as constrained speed, limited repeatability, and restricted ability to debug. In this paper, we present Frankenstein, a fuzzing framework based on advanced firmware emulation, which addresses these shortcomings. Frankenstein brings firmware dumps "back to life", and provides fuzzed input to the chip's virtual modem. The speed-up of our new fuzzing method is sufficient to maintain interoperability with the attached operating system, hence triggering realistic full-stack behavior. We demonstrate the potential of Frankenstein by finding three zero-click vulnerabilities in the Broadcom and Cypress Bluetooth stack, which is used in most Apple devices, many Samsung smartphones, the Raspberry Pis, and many others. Given RCE on a Bluetooth chip, attackers may escalate their privileges beyond the chip's boundary. We uncover a Wi-Fi/Bluetooth coexistence issue that crashes multiple operating system kernels and a design flaw in the Bluetooth 5.2 specification that allows link key extraction from the host. Turning off Bluetooth will not fully disable the chip, making it hard to defend against RCE attacks. Moreover, when testing our chip-based vulnerabilities on those devices, we find BlueFrag, a chip-independent Android RCE.

cs.CR

DEMO: Extracting Physical-Layer BLE Advertisement Information from Broadcom and Cypress Chips

Multiple initiatives propose utilizing Bluetooth Low Energy (BLE) advertisements for contact tracing and SARS-CoV-2 exposure notifications. This demo shows a research tool to analyze BLE advertisements; if universally enabled by the vendors, the uncovered features could improve exposure notifications for everyone. We reverse-engineer the firmware-internal implementation of BLE advertisements on Broadcom and Cypress chips and show how to extract further physical-layer information at the receiver. The analyzed firmware works on hundreds of millions of devices, such as all iPhones, the European Samsung Galaxy S series, and Raspberry Pis.

cs.CR

Acoustic Integrity Codes: Secure Device Pairing Using Short-Range Acoustic Communication

Secure Device Pairing (SDP) relies on an out-of-band channel to authenticate devices. This requires a common hardware interface, which limits the use of existing SDP systems. We propose to use short-range acoustic communication for the initial pairing. Audio hardware is commonly available on existing off-the-shelf devices and can be accessed from user space without requiring firmware or hardware modifications. We improve upon previous approaches by designing Acoustic Integrity Codes (AICs): a modulation scheme that provides message authentication on the acoustic physical layer. We analyze their security and demonstrate that we can defend against signal cancellation attacks by designing signals with low autocorrelation. Our system can detect overshadowing attacks using a ternary decision function with a threshold. In our evaluation of this SDP scheme's security and robustness, we achieve a bit error ratio below 0.1% for a net bit rate of 100 bps with a signal-to-noise ratio (SNR) of 14 dB. Using our open-source proof-of-concept implementation on Android smartphones, we demonstrate pairing between different smartphone models.

cs.CR

Lost and Found: Stopping Bluetooth Finders from Leaking Private Information

A Bluetooth finder is a small battery-powered device that can be attached to important items such as bags, keychains, or bikes. The finder maintains a Bluetooth connection with the user's phone, and the user is notified immediately on connection loss. We provide the first comprehensive security and privacy analysis of current commercial Bluetooth finders. Our analysis reveals several significant security vulnerabilities in those products concerning mobile applications and the corresponding backend services in the cloud. We also show that all analyzed cloud-based products leak more private data than required for their respective cloud services. Overall, there is a big market for Bluetooth finders, but none of the existing products is privacy-friendly. We close this gap by designing and implementing PrivateFind, which ensures locations of the user are never leaked to third parties. It is designed to run on similar hardware as existing finders, allowing vendors to update their systems using PrivateFind.

cs.CR

MagicPairing: Apple's Take on Securing Bluetooth Peripherals

Device pairing in large Internet of Things (IoT) deployments is a challenge for device manufacturers and users. Bluetooth offers a comparably smooth trust on first use pairing experience. Bluetooth, though, is well-known for security flaws in the pairing process. In this paper, we analyze how Apple improves the security of Bluetooth pairing while still maintaining its usability and specification compliance. The proprietary protocol that resides on top of Bluetooth is called MagicPairing. It enables the user to pair a device once with Apple's ecosystem and then seamlessly use it with all their other Apple devices. We analyze both, the security properties provided by this protocol, as well as its implementations. In general, MagicPairing could be adapted by other IoT vendors to improve Bluetooth security. Even though the overall protocol is well-designed, we identified multiple vulnerabilities within Apple's implementations with over-the-air and in-process fuzzing.

cs.CR

InternalBlue - Bluetooth Binary Patching and Experimentation Framework

Bluetooth is one of the most established technologies for short range digital wireless data transmission. With the advent of wearables and the Internet of Things (IoT), Bluetooth has again gained importance, which makes security research and protocol optimizations imperative. Surprisingly, there is a lack of openly available tools and experimental platforms to scrutinize Bluetooth. In particular, system aspects and close to hardware protocol layers are mostly uncovered. We reverse engineer multiple Broadcom Bluetooth chipsets that are widespread in off-the-shelf devices. Thus, we offer deep insights into the internal architecture of a popular commercial family of Bluetooth controllers used in smartphones, wearables, and IoT platforms. Reverse engineered functions can then be altered with our InternalBlue Python framework---outperforming evaluation kits, which are limited to documented and vendor-defined functions. The modified Bluetooth stack remains fully functional and high-performance. Hence, it provides a portable low-cost research platform. InternalBlue is a versatile framework and we demonstrate its abilities by implementing tests and demos for known Bluetooth vulnerabilities. Moreover, we discover a novel critical security issue affecting a large selection of Broadcom chipsets that allows executing code within the attacked Bluetooth firmware. We further show how to use our framework to fix bugs in chipsets out of vendor support and how to add new security features to Bluetooth firmware.

cs.CR

Inside Job: Diagnosing Bluetooth Lower Layers Using Off-the-Shelf Devices

Bluetooth is among the dominant standards for wireless short-range communication with multi-billion Bluetooth devices shipped each year. Basic Bluetooth analysis inside consumer hardware such as smartphones can be accomplished observing the Host Controller Interface (HCI) between the operating system's driver and the Bluetooth chip. However, the HCI does not provide insights to tasks running inside a Bluetooth chip or Link Layer (LL) packets exchanged over the air. As of today, consumer hardware internal behavior can only be observed with external, and often expensive tools, that need to be present during initial device pairing. In this paper, we leverage standard smartphones for on-device Bluetooth analysis and reverse engineer a diagnostic protocol that resides inside Broadcom chips. Diagnostic features include sniffing lower layers such as LL for Classic Bluetooth and Bluetooth Low Energy (BLE), transmission and reception statistics, test mode, and memory peek and poke.

cs.NI