BZPEERReading, trust and collaboration for research
Menu

Discover

GraphFollow connections around a paper, topic or saved view.

Workspaces

HomePick up where your research flow left off.InboxHandle requests, replies and notifications from one place.CollectionsCurate reading lists, evidence sets and shareable dossiers.ResearchSee your private provenance graph, trail and imports.CollaborationMove from discovery into focused discussion rooms.PublishDraft, preview and publish full-text research articles.

Network

ExpertsFind specialists worth following or asking for help.CommunitiesJoin research circles organized around shared work.PartnersSee external organizations active around the same topics.

Opportunities

ListingsBrowse roles, calls and collaborations with clearer fit signals.

Account

Log inReturn to your reading and collaboration workspace.Create accountStart saving work, following people and joining teams.
Log inCreate account

Researcher profile

Jiska Classen

Jiska Classen contributes to research discovery and scholarly infrastructure.

ResearcherAffiliation not importedOpen to collaborate
Cryptography and SecurityNetworking and Internet ArchitectureHardware Architecture

Trust snapshot

Quick read

Trust 21 - EmergingVerification L1Unclaimed author
8works
0followers
3topics
4close collaborators

Actions

Decide how to stay connected

Follow researcher0

Identity and collaboration

How to connect with this researcher

Claiming links this public author record to a researcher profile and unlocks direct collaboration workflows.

Log in to claim

Direct collaboration

Open a focused conversation when the fit is right

Claim this author entity first to unlock direct invitations.

Research graph

See the researcher in context

Open full explorer

Inspect adjacent work, topics, institutions and collaborators without jumping out to a separate graph page.

Building this graph slice

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

8 published item(s)

preprint2022arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2022arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

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.

0 citations0 reviewsNo code linkedOpen access