
Ein Sicherheitsforschungs-Tool, das die Schwachstelle CVE-2025-36911: Fast Pair Pairing Mode Bypass identifiziert und demonstriert.
Ein tiefer Einblick in CVE-2025-36911 und die Sicherheitslücken im Google-Fast-Pair-Ökosystem
Google Fast Pair wurde entwickelt, um das Bluetooth-Koppeln nahtlos zu gestalten: Ein Tipp auf eine Benachrichtigung und man ist verbunden. Doch was passiert, wenn diese nahtlose Erfahrung zu einem Sicherheitsrisiko wird? WhisperPair-PoC-Tool ist ein Sicherheitsforschungs-Tool, das zwei kritische Schwachstellenklassen aufdeckt, von denen Millionen von Bluetooth-Zubehörgeräten betroffen sind: die unbefugte Kopplungsumgehung und die Ausnutzung der Verfolgung über das Find-My-Device-Netzwerk.
Dieser Beitrag erläutert die technischen Interna von WhisperPair-PoC-Tool, die Protokollschwächen, die es ausnutzt, und was dies für das Ökosystem der Bluetooth-Zubehörgeräte bedeutet.
Die Google-Fast-Pair-Spezifikation besagt ausdrücklich:
„Wenn das optionale Public-Key-Feld vorhanden ist: Wenn sich das Gerät nicht im Kopplungsmodus befindet, den Schreibvorgang ignorieren und beenden."
Dies ist die kritische Sicherheitsprüfung. Geräte sollten nur dann auf Key-Based-Pairing-Anfragen reagieren, wenn der Benutzer das Gerät ausdrücklich in den Kopplungsmodus versetzt hat (in der Regel durch Gedrückthalten einer Taste). Dadurch wird die Benutzerabsicht sichergestellt, sodass man sich nicht mit den Ohrhörern einer Person koppeln kann, während diese sie trägt.
Das Problem: Viele Hersteller überspringen diese Prüfung vollständig. Sie verarbeiten Kopplungsanfragen unabhängig vom Zustand des Kopplungsmodus, was Folgendes ermöglicht:
Das Find-My-Device-Netzwerk (FMDN) von Google ermöglicht die Verfolgung von Bluetooth-Zubehör über das per Crowdsourcing betriebene Netzwerk von Android-Geräten. Dies erfordert einen Account Key, einen 16-Byte-symmetrischen Schlüssel, der das Gerät mit einem Google-Konto verknüpft.
Das Problem: Die Account-Key-Charakteristik akzeptiert häufig Schreibvorgänge ohne Authentifizierung:
Bevor wir in die Ausnutzung eintauchen, wollen wir den legitimen Fast-Pair-Ablauf verstehen:
┌─────────────────────────────────────────────────────────────┐
│ BLE Advertisement │
├─────────────────────────────────────────────────────────────┤
│ Service UUID: 0xFE2C (Fast Pair) │
│ Service Data: │
│ [Pairing Mode] → 3 bytes: Model ID only │
│ [Not Pairing] → 4+ bytes: 0x00 + Account Key Filter │
└─────────────────────────────────────────────────────────────┘
Das Advertisement-Format offenbart den Kopplungsstatus:
Seeker (Phone) Provider (Accessory)
│ │
│───── GATT Connect ──────────────────────────>│
│ │
│───── Discover Services ─────────────────────>│
│<──── Service: 0xFE2C ────────────────────────│
│ │
│───── Enable Notifications (0xFE2C1234) ─────>│
│ │
│───── Write Key-Based Pairing Request ───────>│
│ [16-byte encrypted block] │
│ [64-byte ECDH Public Key] (optional) │
│ │
│ ┌────────────────────────────────────┐ │
│ │ SECURITY CHECK: │ │
│ │ If Public Key present AND │ │
│ │ device NOT in pairing mode: │ │
│ │ → IGNORE and EXIT │ │
│ │ Else: │ │
│ │ → Process request │ │
│ └────────────────────────────────────┘ │
│ │
│<──── Notification: Encrypted Response ───────│
│ [Provider's BR/EDR Address] │
│ │
│═══════ Bluetooth Classic Pairing ═══════════>│
Die Schwachstelle tritt auf, wenn Geräte das Feld „SECURITY CHECK" vollständig überspringen.
WhisperPair-PoC-Tool ist ein auf Python basierendes Sicherheitsforschungs-Tool, das auf der Bleak-BLE-Bibliothek aufbaut. Es arbeitet in mehreren Phasen:
┌────────────────────────────────────────────────────────────────┐
│ WhisperPair-PoC-Tool │
├────────────────────────────────────────────────────────────────┤
│ CLI Layer │
│ ├── Argument parsing (--target-name, --scan-duration) │
│ ├── TargetPolicy construction │
│ └── REPL initialization │
├────────────────────────────────────────────────────────────────┤
│ Discovery Engine │
│ ├── BLE scanning via Bleak │
│ ├── Advertisement parsing │
│ ├── Protocol detection (Fast Pair, FMDN, Swift Pair) │
│ └── Device fingerprinting (Model ID, OUI lookup) │
├────────────────────────────────────────────────────────────────┤
│ Check Engines │
│ ├── FastPairCheckEngine (passive advertisement analysis) │
│ ├── FastPairBypass (active CVE-2025-36911 testing) │
│ ├── FindHubCheckEngine (Account Key status detection) │
│ └── RiskScorer (composite vulnerability assessment) │
├────────────────────────────────────────────────────────────────┤
│ Connection Manager │
│ ├── GATT connect with MTU negotiation │
│ ├── Service/characteristic discovery │
│ ├── Read/Write/Notify operations │
│ └── Error handling and retry logic │
├────────────────────────────────────────────────────────────────┤
│ Exploitation Modules │
│ ├── ring_device() - Trigger locator sound │
│ ├── set_account_key() - Write Account Key │
│ └── Response parsing (BR/EDR address extraction) │
└────────────────────────────────────────────────────────────────┘
discovery.py)Der Scanner verwendet Bleaks Erkennungs-Callbacks, um BLE-Advertisements zu erfassen:
async def _detection_callback(
self, device: BLEDevice, advertisement_data: AdvertisementData
) -> None:
"""Process each detected BLE advertisement."""
discovered = DiscoveredDevice(
address=device.address,
name=device.name or advertisement_data.local_name,
rssi=advertisement_data.rssi,
advertisement=self._convert_advertisement(advertisement_data),
first_seen=datetime.now(UTC),
last_seen=datetime.now(UTC),
)
self._devices[device.address] = discovered
Für jedes Gerät extrahiert das Tool:
0xFE2C, FMDN 0xFD44, usw.)0x00E0, Apple 0x004C)fastpair.py)Der Kopplungsmodus wird durch die Analyse der Advertisement-Daten des Geräts bestimmt:
def _analyze_service_data(self, evidence: FastPairEvidence) -> None:
"""Analyze Fast Pair service data to infer pairing mode."""
data = evidence.service_data_bytes
# 3 bytes = Model ID only = Pairing Mode (discoverable)
if len(data) == 3:
evidence.inferred_pairing_mode = PairingModeState.IN_PAIRING_MODE
return
# 4+ bytes with version 0x00 = Not in pairing mode
if data[0] == 0x00:
akd_byte = data[1]
akd_type = akd_byte & 0x0F # Lower 4 bits
# Type 0x00 = Show UI, Type 0x02 = Hide UI
# Both indicate NOT in pairing mode
evidence.inferred_pairing_mode = PairingModeState.NOT_IN_PAIRING_MODE
Dies ist entscheidend: Wenn festgestellt wird, dass sich ein Gerät nicht im Kopplungsmodus befindet und es dennoch auf die Kopplungsanfrage antwortet, ist es verwundbar.
fastpair_attack.py)Der zentrale Schwachstellentest sendet Key-Based-Pairing-Anfragen und überwacht auf Antworten:
async def check_vulnerability(self, device: DiscoveredDevice) -> BypassCheckResult:
"""Test if device responds to pairing requests when not in pairing mode."""
# Enable notifications to receive response
await self.connection_manager.start_notify(
KEY_BASED_PAIRING_CHAR,
self._notification_handler,
)
# Build and send request (multiple strategies)
for strategy in self.strategies:
request, flags = self._build_strategy_request(device.address, strategy)
await self.connection_manager.write_characteristic(
KEY_BASED_PAIRING_CHAR,
request,
)
# Wait for response
try:
await asyncio.wait_for(
self._response_received.wait(),
timeout=self.response_timeout,
)
# Response received = VULNERABLE
return BypassCheckResult(result=BypassResult.VULNERABLE, ...)
except asyncio.TimeoutError:
# No response = Device correctly ignored request
continue
return BypassCheckResult(result=BypassResult.NOT_VULNERABLE, ...)
Das Tool implementiert mehrere Anfragestrategien, da verschiedene Geräte auf unterschiedliche Flag-Kombinationen reagieren:
Wenn ein verwundbares Gerät antwortet, extrahiert das Tool die BR/EDR-Adresse (Bluetooth Classic):
def _parse_response(self, response_data: bytes) -> str | None:
"""Extract provider's BR/EDR address from response."""
# Strategy 1: Standard response (type 0x01)
if response_data[0] == 0x01:
return self._extract_address(response_data, offset=1)
# Strategy 2: Extended response (type 0x02)
if response_data[0] == 0x02:
addr_count = response_data[2]
return self._extract_address(response_data, offset=3)
# Strategy 3: Brute force pattern matching
for offset in range(len(response_data) - 5):
addr = self._extract_address(response_data, offset)
if self._is_valid_mac(addr):
return addr
Diese BR/EDR-Adresse könnte verwendet werden, um eine Bluetooth-Classic-Kopplung einzuleiten (WhisperPair-PoC-Tool bleibt jedoch bei der Erkennung stehen).
Die Forschung identifizierte häufige Implementierungsfehler:
Das häufigste Problem: Hersteller implementieren die Prüfung schlicht nicht:
// VULNERABLE: No pairing mode check
void handle_kbp_write(uint8_t* data, size_t len) {
if (len >= 80 && has_public_key(data)) {
// Should check: if (!is_in_pairing_mode()) return;
process_pairing_request(data); // Processes regardless
}
}
Die Account-Key-Charakteristik sollte eine Authentifizierung erfordern:
// VULNERABLE: No authentication required
void handle_account_key_write(uint8_t* key, size_t len) {
if (len == 16) {
store_account_key(key); // Accepts any key from anyone
}
}
// SECURE: Verify caller knows existing key
void handle_account_key_write_secure(uint8_t* encrypted_key, size_t len) {
if (!verify_encrypted_with_existing_key(encrypted_key)) {
return; // Reject unauthorized writes
}
store_account_key(decrypt(encrypted_key));
}
Geräte, die Fast-Pair-Servicedaten ausstrahlen, obwohl sie nicht im Kopplungsmodus sind, geben Folgendes preis:
WhisperPair-PoC-Tool verwendet einen mehrschichtigen Erkennungsansatz:
Keine Verbindung erforderlich. Das Tool analysiert, was das Gerät ausstrahlt:
┌─────────────────────────────────────────────────────────────┐
│ Passive Checks │
├─────────────────────────────────────────────────────────────┤
│ ✓ Fast Pair service UUID present (0xFE2C) │
│ ✓ FMDN service UUID present (0xFD44) │
│ ✓ Pairing mode inferred from service data length │
│ ✓ Model ID extracted (when in pairing mode) │
│ ✓ Account Key Filter detected (when not in pairing mode) │
│ ✓ Address type analysis (static vs. random) │
└─────────────────────────────────────────────────────────────┘
Result: "Device advertising Fast Pair data while NOT in pairing mode"
→ Potential gating violation (needs active test to confirm)
Erfordert eine Verbindung. Das Tool interagiert mit den GATT-Diensten:
┌─────────────────────────────────────────────────────────────┐
│ Active Checks │
├─────────────────────────────────────────────────────────────┤
│ 1. Connect to device via BLE │
│ 2. Discover Fast Pair service (0xFE2C) │
│ 3. Locate Key-Based Pairing characteristic (0xFE2C1234) │
│ 4. Enable notifications │
│ 5. Write Key-Based Pairing request │
│ 6. Wait for response (with timeout) │
│ 7. Response received → VULNERABLE │
│ Timeout/Rejected → NOT VULNERABLE │
└─────────────────────────────────────────────────────────────┘
Es wird ein zusammengesetzter Risikowert berechnet:
Risikostufen:
WhisperPair-PoC-Tool enthält kontrollierte Ausnutzungsfunktionen, um die Auswirkungen zu demonstrieren:
ring-Befehl)Löst die FMDN-Beacon-Actions-Charakteristik aus, um den Ortungston abzuspielen:
FÜR DIE VERÖFFENTLICHUNG GESCHWÄRZT
Auswirkung: Der Angreifer kann das Opfer belästigen, indem er den Ton wiederholt auslöst, oder ihn nutzen, um ein Gerät zu orten, das er stehlen möchte.
set account-key-Befehl)Schreibt einen neuen Account Key auf das Gerät:
FÜR DIE VERÖFFENTLICHUNG GESCHWÄRZT
Auswirkung:
WhisperPair-PoC-Tool bleibt bewusst hinter einer vollständigen Ausnutzung zurück:
if (has_public_key(request) && !is_in_pairing_mode()) {
return; // Ignore request per spec
}
Authentifizierung für Account-Key-Schreibvorgänge verlangen:
Die Werbe-Exposition minimieren:
Firmware-Update-Mechanismus:
Dieses Tool ist bestimmt für:
WhisperPair-PoC-Tool zeigt, dass die „nahtlose" Fast-Pair-Erfahrung mit Sicherheitskompromissen einhergeht, die viele Hersteller nicht angehen. Die Prüfung des Kopplungsmodus ist eine einzige Bedingung, die ein sicheres Gerät von einem verwundbaren trennt, und dennoch wird sie häufig weggelassen.
Das Vertrauensmodell von Fast Pair geht davon aus, dass Geräte die Benutzerabsicht durchsetzen. Tun sie das nicht, erhalten Angreifer stille Kopplung, Verfolgungsmöglichkeiten und Denial-of-Service-Vektoren gegen die Geräte der Opfer.
Dieses Tool soll dem Ökosystem helfen, diese Probleme zu erkennen und zu beheben, um Bluetooth-Zubehör für alle sicherer zu machen.
WhisperPair-PoC-Tool wird ausschließlich für autorisierte Sicherheitsforschung veröffentlicht. Für Missbrauch dieses Tools wird keine Haftung übernommen.
| Strategie | Flags | Beschreibung |
|---|
RAW_KBP | 0x11 | INITIATE_BONDING | EXTENDED_RESPONSE |
WITH_PUBLIC_KEY | 0x11 | 80-Byte-Anfrage mit ECDH-öffentlichem Schlüssel |
RETROACTIVE | 0x0A | Umgeht einige Herstellerprüfungen |
EXTENDED | 0x10 | Für neuere Geräte-Firmware |
| Signal | Score | Bedeutung |
|---|
| Gating-Verletzung (passiv) | +2 | Strahlt FP aus, wenn nicht im Kopplungsmodus |
| Bypass bestätigt (aktiv) | +2 | Antwortete auf KBP, wenn nicht im Kopplungsmodus |
| FMDN ohne Account Key | +2 | Über das Find-My-Netzwerk verfolgbar |
| Statische BLE-Adresse | +1 | Gerät ist dauerhaft verfolgbar |
| Adressrotation beobachtet | -1 | Datenschutzfreundliches Verhalten |
| Fähigkeit | Implementiert | Grund |
|---|
| Schwachstellenerkennung | ✅ Ja | Kernzweck |
| BR/EDR-Adressextraktion | ✅ Ja | Beweissammlung |
| Bluetooth-Classic-Kopplung | ❌ Nein | Erfordert plattformspezifischen Code |
| HFP-Audio-Übernahme | ❌ Nein | Liegt außerhalb des Umfangs des BLE-Tools |
| Dauerhafte Implantation | ❌ Nein | Schadfunktion |