Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
whisperpair-poc-tool — Ein Sicherheitsforschungs-Tool, das die Schwachstelle CVE-2025-36911: Fast Pair Pairing Mode Bypass identifiziert und demonstriert. | Kitploit
Tools/GitHubGitHub/aalex954/whisperpair-poc-tool
AufklärungBluetooth-SicherheitSchwachstellenanalyseExploitationInformationsbeschaffungDrahtlose SicherheitPenetrationstestsHardware-SicherheitRed Teaming
GitHubaalex954/whisperpair-poc-tool

whisperpair-poc-tool

Ein Sicherheitsforschungs-Tool, das die Schwachstelle CVE-2025-36911: Fast Pair Pairing Mode Bypass identifiziert und demonstriert.

7vor 6 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Repository anzeigen
Teilen

WhisperPair-PoC-Tool und Forschung

Ein tiefer Einblick in CVE-2025-36911 und die Sicherheitslücken im Google-Fast-Pair-Ökosystem

Blogbeitrag

demo

Zusammenfassung

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.


Inhaltsverzeichnis

  1. Die Schwachstellen
  2. Grundlagen des Fast-Pair-Protokolls
  3. Wie WhisperPair-PoC-Tool funktioniert
  4. Die Angriffsfläche
  5. Erkennungsmethodik
  6. Ausnutzungsmöglichkeiten
  7. Behebungsempfehlungen
  8. Ethische Überlegungen

Die Schwachstellen

CVE-2025-36911: Umgehung des Fast-Pair-Kopplungsmodus

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."

  • Google-Fast-Pair-GATT-Verfahrensspezifikation

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:

  • Stille Kopplung ohne Benutzerinteraktion
  • Übernahme des Zubehörs bei Nahbereichsangriffen
  • Datenschutzverletzungen durch Verbindung mit den Geräten der Opfer

Offenlegung des Find-Hub-Account-Keys

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:

  • Der Angreifer kann einen vorhandenen Account Key überschreiben
  • Die Find-My-Device-Integration des Opfers bricht
  • Der Angreifer kann das Gerät mit seinem eigenen Schlüssel verfolgen
  • Dies bleibt bis zum Werksreset bestehen

Grundlagen des Fast-Pair-Protokolls

Bevor wir in die Ausnutzung eintauchen, wollen wir den legitimen Fast-Pair-Ablauf verstehen:

Advertisement-Phase

root@kitploit:~
┌─────────────────────────────────────────────────────────────┐
│                    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:

  • 3 Bytes = nur Modell-ID = Gerät ist auffindbar (Kopplungsmodus)
  • 4+ Bytes = Versionsbyte + Account-Key-Daten = Nicht im Kopplungsmodus

Key-Based-Pairing-Handshake

root@kitploit:~
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.


Wie WhisperPair-PoC-Tool funktioniert

WhisperPair-PoC-Tool ist ein auf Python basierendes Sicherheitsforschungs-Tool, das auf der Bleak-BLE-Bibliothek aufbaut. Es arbeitet in mehreren Phasen:

Architekturübersicht

root@kitploit:~
┌────────────────────────────────────────────────────────────────┐
│                        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)              │
└────────────────────────────────────────────────────────────────┘

Kernkomponenten

1. Discovery-Engine (discovery.py)

Der Scanner verwendet Bleaks Erkennungs-Callbacks, um BLE-Advertisements zu erfassen:

root@kitploit:~
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:

  • Service-UUIDs (Erkennung von Fast Pair 0xFE2C, FMDN 0xFD44, usw.)
  • Herstellerdaten (Google 0x00E0, Apple 0x004C)
  • Servicedaten (auf Modell-ID und Kopplungsstatus geparst)

2. Bestimmung des Kopplungsmodus (fastpair.py)

Der Kopplungsmodus wird durch die Analyse der Advertisement-Daten des Geräts bestimmt:

root@kitploit:~
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.

3. Schwachstellenerkennung (fastpair_attack.py)

Der zentrale Schwachstellentest sendet Key-Based-Pairing-Anfragen und überwacht auf Antworten:

root@kitploit:~
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:

4. Antwort-Parsing

Wenn ein verwundbares Gerät antwortet, extrahiert das Tool die BR/EDR-Adresse (Bluetooth Classic):

root@kitploit:~
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 Angriffsfläche

Was macht Geräte verwundbar?

Die Forschung identifizierte häufige Implementierungsfehler:

1. Fehlende Prüfung des Kopplungsmodus

Das häufigste Problem: Hersteller implementieren die Prüfung schlicht nicht:

root@kitploit:~
// 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
    }
}

2. Ungeschützte Account-Key-Schreibvorgänge

Die Account-Key-Charakteristik sollte eine Authentifizierung erfordern:

root@kitploit:~
// 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));
}

3. Informationslecks in Advertisement-Daten

Geräte, die Fast-Pair-Servicedaten ausstrahlen, obwohl sie nicht im Kopplungsmodus sind, geben Folgendes preis:

  • Dass sie Fast Pair unterstützen (Identifizierung der Angriffsfläche)
  • Account-Key-Filter (kann für Geräte-Fingerprinting verwendet werden)
  • Möglicherweise ihre Modell-ID (identifiziert das genaue Gerätemodell)

Erkennungsmethodik

WhisperPair-PoC-Tool verwendet einen mehrschichtigen Erkennungsansatz:

Ebene 1: Passive Advertisement-Analyse

Keine Verbindung erforderlich. Das Tool analysiert, was das Gerät ausstrahlt:

root@kitploit:~
┌─────────────────────────────────────────────────────────────┐
│  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)

Ebene 2: Aktive GATT-Untersuchung

Erfordert eine Verbindung. Das Tool interagiert mit den GATT-Diensten:

root@kitploit:~
┌─────────────────────────────────────────────────────────────┐
│  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                       │
└─────────────────────────────────────────────────────────────┘

Ebene 3: Risikobewertung

Es wird ein zusammengesetzter Risikowert berechnet:

Risikostufen:

  • NIEDRIG (≤0): Keine signifikanten Probleme erkannt
  • MITTEL (1-2): Einige bedenkliche Signale
  • HOCH (≥3): Mehrere Schwachstellen bestätigt

Ausnutzungsmöglichkeiten

WhisperPair-PoC-Tool enthält kontrollierte Ausnutzungsfunktionen, um die Auswirkungen zu demonstrieren:

1. Gerät klingeln lassen (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.

2. Manipulation des Account Keys (set account-key-Befehl)

Schreibt einen neuen Account Key auf das Gerät:

FÜR DIE VERÖFFENTLICHUNG GESCHWÄRZT

Auswirkung:

  • Zerstört die Find-My-Device-Integration des Opfers
  • Der Angreifer kann das Gerät mit seinem bekannten Schlüssel verfolgen
  • Nur durch einen Werksreset wiederherstellbar

Was nicht implementiert ist

WhisperPair-PoC-Tool bleibt bewusst hinter einer vollständigen Ausnutzung zurück:


Behebungsempfehlungen

Für Gerätehersteller

  1. Die Prüfung des Kopplungsmodus implementieren:
root@kitploit:~
if (has_public_key(request) && !is_in_pairing_mode()) {
    return;  // Ignore request per spec
}
  1. Authentifizierung für Account-Key-Schreibvorgänge verlangen:

    • Neuen Schlüssel mit vorhandenem Schlüssel verschlüsseln
    • Vor dem Speichern verifizieren
  2. Die Werbe-Exposition minimieren:

    • Fast-Pair-UUID nur im Kopplungsmodus ausstrahlen
    • Wenn möglich rotierende Adressen verwenden
  3. Firmware-Update-Mechanismus:

    • Korrekturen an betroffene Geräte im Feld ausliefern

Für Endbenutzer

  1. Firmware aktuell halten bei Bluetooth-Zubehör
  2. Werksreset durchführen, wenn eine Kompromittierung vermutet wird
  3. Vorsichtig sein bei Geräten, die sich ohne Tastendruck automatisch koppeln
  4. Find-My-Device-Einstellungen regelmäßig prüfen

Verwendungszweck

Dieses Tool ist bestimmt für:

  • ✅ Sicherheitsforscher, die Zubehör-Implementierungen bewerten
  • ✅ QA-Ingenieure, die die Produkte ihres Unternehmens testen
  • ✅ Gerätebesitzer, die ihr eigenes Zubehör prüfen
  • ❌ NICHT für unbefugten Zugriff auf die Geräte anderer

Fazit

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.


Referenzen

  • WhisperPair Originalforschung
  • Google-Fast-Pair-Spezifikation
  • CVE-2025-36911
  • Find-My-Device-Netzwerkprotokoll
  • Bluetooth-Kernspezifikation
  • Bleak-BLE-Bibliothek

WhisperPair-PoC-Tool wird ausschließlich für autorisierte Sicherheitsforschung veröffentlicht. Für Missbrauch dieses Tools wird keine Haftung übernommen.

Tool herunterladen
StrategieFlagsBeschreibung
RAW_KBP0x11INITIATE_BONDING | EXTENDED_RESPONSE
WITH_PUBLIC_KEY0x1180-Byte-Anfrage mit ECDH-öffentlichem Schlüssel
RETROACTIVE0x0AUmgeht einige Herstellerprüfungen
EXTENDED0x10Für neuere Geräte-Firmware
SignalScoreBedeutung
Gating-Verletzung (passiv)+2Strahlt FP aus, wenn nicht im Kopplungsmodus
Bypass bestätigt (aktiv)+2Antwortete auf KBP, wenn nicht im Kopplungsmodus
FMDN ohne Account Key+2Über das Find-My-Netzwerk verfolgbar
Statische BLE-Adresse+1Gerät ist dauerhaft verfolgbar
Adressrotation beobachtet-1Datenschutzfreundliches Verhalten
FähigkeitImplementiertGrund
Schwachstellenerkennung✅ JaKernzweck
BR/EDR-Adressextraktion✅ JaBeweissammlung
Bluetooth-Classic-Kopplung❌ NeinErfordert plattformspezifischen Code
HFP-Audio-Übernahme❌ NeinLiegt außerhalb des Umfangs des BLE-Tools
Dauerhafte Implantation❌ NeinSchadfunktion