O2 VoLTE: Ein einziger Anruf reicht, um den Standort aller Kunden zu verfolgen

 (mastdatabase.co.uk)
2 Punkte von GN⁺ 2025-05-18 | 1 Kommentare | Auf WhatsApp teilen
  • In der Implementierung von 4G Calling/WiFi Calling bei O2 UK gab es ein Problem, durch das der Anrufer IMS/SIP-Header erhielt, die zur Abschätzung des Standorts des Angerufenen genutzt werden konnten; diese Offenlegung betraf über mehrere Monate hinweg alle O2-Kunden
  • IMS-Signalisierungsnachrichten enthielten zusammen mit dem IMS/SIP-Server von O2, Mavenir UAG, dessen Version, Debug-Informationen und Fehlermeldungen auch die IMSI und IMEI von Anrufer und Angerufenem sowie die Cellular-Network-Info des Angerufenen
  • Zerlegt man den utran-cell-id-3gpp-Wert in Cellular-Network-Info in PLMN, Location Area Code und Cell ID und gleicht ihn mit öffentlichen Mobilfunkmastdaten wie Cellmapper ab, lässt sich der ungefähre Standort des Angerufenen ermitteln
  • In Städten betreuen an Straßenlaternen installierte small cells oft nur sehr kleine Bereiche, wodurch die Standortschätzung deutlich präziser wird; selbst O2-Kunden im Auslandsroaming ließen sich so bis ins Zentrum von Kopenhagen eingrenzen
  • Das Deaktivieren von 4G Calling und WiFi Calling verhindert die Standortoffenlegung, aber die Offenlegung von IMEI und IMSI bleibt unabhängig vom IMS-Registrierungsstatus bestehen; O2 muss die betreffenden Header daher aus IMS/SIP-Nachrichten entfernen

Standort-Hinweise aus IMS-Anrufen

  • Voice over LTE (VoLTE) verwendet den Standard IP Multimedia Subsystem (IMS), um Sprachanrufe in Mobilfunknetzen über internetbasierte Protokolle abzuwickeln
  • IMS-Implementierungen sind komplex und stark geräteabhängig; früher benötigten manche Geräte sogar eine bestimmte Firmware, um VoLTE und WiFi Calling nutzen zu können
  • Mobilfunknetze entscheiden selbst, wie sie IMS-Dienste implementieren und welche Einstellungen sie verwenden; das Telefon kommuniziert direkt mit den entsprechenden Servern
  • In dieser Struktur liegt es in der Verantwortung des Mobilfunknetzes, die Server aktuell zu halten und sicherzustellen, dass Konfigurationen nicht zu unnötiger Datenoffenlegung führen

Überprüfung von O2 UK 4G Calling

  • O2 UK führte am 27. März 2017 mit 4G Calling seinen ersten IMS-Dienst ein
    • Der Dienst sollte die Sprachqualität verbessern und die Datennutzung während eines Gesprächs verbessern, da nicht auf 3G zurückgefallen werden musste
  • Nach dem Wechsel zu O2 wollte der Forscher prüfen, welche Sprach-Codecs bei 4G/WiFi Calling unterstützt werden
  • Auf einem gerooteten Google Pixel 8 wurde Network Signal Guru (NSG) verwendet, um ein anderes O2-Konto auf einem 4G-VoLTE-kompatiblen Gerät anzurufen
  • Wegen eines NSG-Bugs im Samsung-Modem aktueller Google-Pixel-Geräte wurde der aktuell verwendete Anruf-Codec im VoLTE-Bereich nicht automatisch angezeigt; stattdessen wurden die rohen IMS-Signalisierungsnachrichten zwischen Gerät und Netzwerk untersucht

Sensible Header in IMS/SIP-Nachrichten

  • Die Netzwerkantworten waren im Vergleich zu anderen beobachteten Netzen ungewöhnlich detailliert und lang
  • Die Nachrichten enthielten den von O2 verwendeten IMS/SIP-Server Mavenir UAG samt Versionsnummer
  • Außerdem wurden Fehlermeldungen aus dem C++-Dienst zur Verarbeitung von Anrufinformationen sowie weitere Debug-Informationen offengelegt
  • Besonders auffällig waren am Ende der Nachrichten Header dieses Typs
    • P-Mav-Extension-IMSI: zwei IMSIs
    • P-Mav-Extension-IMEI: zwei IMEIs
    • Cellular-Network-Info: Zellinformationen des Angerufenen
  • Der Abgleich von IMSI und IMEI mit den Geräteinformationen des Forschers zeigte, dass nicht nur die Daten des Anrufers, sondern auch die IMSI und IMEI des Angerufenen enthalten waren

So wird mit Cellular-Network-Info der Standort berechnet

  • Der Präfix 3GPP-E-UTRAN-FDD im Wert von Cellular-Network-Info zeigt an, dass sich die Zelldaten auf 4G beziehungsweise offiziell E-UTRAN FDD beziehen
  • Der nachfolgende Wert utran-cell-id-3gpp besteht aus drei Teilen
    • Die ersten 5–6 Zeichen sind das PLMN des Netzes des Angerufenen
    • Die nächsten 4 Zeichen sind der hexadezimale Location Area Code (LAC) des Angerufenen
    • Die letzten 7 Zeichen sind die hexadezimale Cell ID des Angerufenen
  • Der letzte Abschnitt gibt das Alter der Daten in Sekunden an
    • Er ist vorhanden, wenn das Gerät aktuell nicht mit dem Netz verbunden ist, keinen Empfang hat oder auf WiFi Calling angewiesen ist
  • Im Beispiel ließ sich daraus ableiten, dass der Angerufene im O2-Netz 234-10 eingebucht war, sich in LAC 0x1003 mit Cell ID 0x7a60773 befand und ein Google Pixel 9 mit O2-SIM nutzte

Standortschätzung mit öffentlichen Mobilfunkmastdaten

  • Die Cell ID kann in den cell ID calculator von Cellmapper eingegeben werden, um die zugehörige Site-ID zu berechnen
  • Anschließend lässt sich auf der Cellmapper-Karte die zugehörige Station finden und die zum Zeitpunkt des Anrufs genutzte Makrozelle bestimmen
  • Makrozellen decken vergleichsweise große Bereiche ab, doch in dicht bebauten Stadtgebieten werden viele kleine Zellen eingesetzt
    • small cells werden teils direkt an Straßenlaternen montiert
    • Jede Station kann einen Bereich von nur 100 m² abdecken
  • Derselbe Angriff wurde auch an einem anderen O2-Kunden im Auslandsroaming getestet und erlaubte eine Eingrenzung auf das Stadtzentrum von Kopenhagen in Dänemark
  • Das Gerät des Forschers führte dabei keine besonderen Aktionen gegenüber dem Netz aus, sondern machte lediglich die an das Gerät gesendeten Informationen sichtbar
  • Ein O2-Gerät, das per IMS, also über 4G Calling oder WiFi Calling, anruft, kann Informationen erhalten, die zur Abschätzung des geografischen Standorts des Gesprächsempfängers genutzt werden können

Header, die O2 entfernen muss, und mögliche Gegenmaßnahmen für Nutzer

  • O2 sollte die hervorgehobenen Header aus allen IMS/SIP-Nachrichten entfernen, um die Privatsphäre und Sicherheit seiner Kunden zu schützen
  • Es wäre auch logisch, die Debug-Header zu deaktivieren
    • Kein Gerät außerhalb des Netzwerkkerns sollte diese Header sehen können
    • Debug-Header könnten unbeabsichtigt zusätzliche Informationen preisgeben
  • Der Wettbewerber EE bietet einen Meldeweg über BT responsible disclosure an, bei O2 fehlt jedoch ein klarer Eskalationsweg, um solche potenziellen Angriffsvektoren zu melden
  • Am 26. und 27. März 2025 wurden E-Mails an O2-CEO Lutz Schüler und an securityincidents@virginmediao2.co.uk geschickt, um auf dieses Verhalten und das Datenschutzrisiko hinzuweisen, doch es gab weder eine Antwort noch eine Verhaltensänderung
  • Wer 4G Calling und WiFi Calling vollständig deaktiviert, kann den Teil der Standortoffenlegung wirksam verhindern
    • Der Header Cellular-Network-Info wird nur gesendet, wenn das Gerät des Angerufenen antwortet
    • Die Offenlegung von IMEI und IMSI tritt jedoch unabhängig vom IMS-Registrierungsstatus weiterhin auf
  • In einer Korrektur vom 27. Mai 2025 wurde ergänzt, dass ursprünglich keine Möglichkeit zur Abschwächung der Standortoffenlegung genannt wurde; nach weiterer Prüfung der IMS-Signalisierung und der Übertragung von Geräte-Headern wurde dies korrigiert: Das Deaktivieren von 4G Calling und WiFi Calling mindert den Teil der Standortoffenlegung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-18
Hacker-News-Kommentare

  • Dass man den O2-CEO und die E-Mail-Adresse für Sicherheitsvorfälle am 26.–27. März 2025 auf dieses Verhalten und das Datenschutzrisiko hingewiesen hat und es trotzdem weder eine Antwort noch eine Veränderung gab, ist wirklich miserabel
    Warum eine Virgin-Media-Adresse überhaupt noch am ehesten als bester Kontakt gilt, ist ebenfalls fragwürdig, und https://www.o2.co.uk/.well-known/security.txt sollte 200 statt 404 zurückgeben
    In so einer Situation halte ich eine Offenlegung für unproblematisch, aber vielleicht könnte das NCSC solche Fälle unter bestimmten Bedingungen übernehmen und auch besser mit der Organisation kommunizieren

    • Das war tatsächlich ein Fehler auf unserer Seite
      Die kontaktierte E-Mail war nicht @virginmedia.co.uk, sondern @virginmediao2.co.uk, und im Beitrag stand ein Tippfehler
      Wir werden das korrigieren und aktualisieren
    • In der Datenschutzerklärung stehen wegen der GDPR-Anforderungen mehrere E-Mail-Adressen
      Zum Beispiel könnte jemand DPO@o2.com tatsächlich überwachen
      https://www.o2.co.uk/termsandconditions/privacy-policy

  • O2 hatte früher einmal eine Adresse für Responsible Disclosure, hat sie aber vor einigen Jahren entfernt
    Als ich vor langer Zeit dort gearbeitet habe, war das Sicherheitsteam hervorragend, aber als ich letztes Jahr wegen eines Problems eine E-Mail geschickt habe, waren diese Leute alle verschwunden

    • Ich weiß, dass die zuständigen Teams innerhalb von O2 tatsächlich benachrichtigt wurden, aber am Ende scheint entweder nichts oder nicht genug passiert zu sein

  • Das wirklich Interessante an diesem Fall ist, dass das in den meisten Rechtsordnungen vermutlich nicht einmal als Hacking eingestuft würde
    Die Daten werden freiwillig während der normalen Nutzung über das Netzwerk übertragen
    Kein System wurde dazu gebracht, personenbezogene Daten preiszugeben, und gerade so etwas ist oft illegal, selbst wenn das Hacking nur geringfügig ist
    Schon etwas wie &reveal_privat_data=true an eine URL anzuhängen, kann als klare Absicht gelten, auf Daten ohne Zugriffsrecht zuzugreifen, und damit illegal sein, aber hier gibt es nicht einmal so etwas

    • Trotzdem ist das ein Datenleck, und wenn die Regulierung im Vereinigten Königreich greift, muss es sofort der Aufsichtsbehörde gemeldet werden; unterbleibt das, drohen Bußgelder und Ähnliches
    • Du scheinst nicht zu wissen, wie weit der britische Computer Misuse Act ausgelegt wird

  • Der beängstigende Teil ist, dass das kein theoretischer Bug ist
    Wie auch im Artikel steht, handelt es sich um Nachlässigkeit bei der Implementierung, die andere britische Mobilfunkanbieter bereits behoben haben, und das Leaken von ECI wird seit der Einführung von LTE kritisiert
    Es gibt Arbeiten wie https://arxiv.org/abs/2106.05007—and, und mit einer öffentlichen Datenbank für Funkzellen ist automatisches Mapping auf den Standort trivial

    • Es ist möglich, dass die Sicherheitsbehörden, die das verwendet haben, jetzt in Panik darauf warten, dass ihnen gesagt wird, was sie tun sollen

  • Ich frage mich auch sehr, wie der Anrufer die Anrufsteuerungsnachrichten, also SIP, überhaupt sehen konnte
    Solche Nachrichten laufen doch innerhalb eines verschlüsselten GRE-Tunnels zwischen Endgerät, Basisstation und MME, oder? Wenn man die Verschlüsselung des GRE-Tunnels aufbrechen könnte, wäre das eine gewaltige Lücke, aber vermutlich hat der Autor des Originalbeitrags einfach Analysen auf seinem eigenen Gerät durchgeführt
    Trotzdem ist es überraschend, dass der Payload vor der Verschlüsselung sichtbar ist

    • Ich bin der Redakteur des Artikels
      Viele Android-Geräte mit Qualcomm-Chip können per USB einen Modem-Diagnoseport bereitstellen, dafür braucht man nicht einmal ein gerootetes Gerät
      Allerdings ist ein gerootetes NSG auf dem Gerät viel einfacher, als mit einem Laptop herumzulaufen
      Wenn man den Modem-Diagnoseport aktiviert und Scat(https://github.com/fgsect/scat) benutzt, ist es einfach genug, um den gesamten Signalverkehr mit dem Netzwerk zu sehen
    • Ich benutze ein gerootetes Android-Telefon und eine App namens Network Signal Guru: https://play.google.com/store/apps/details?id=com.qtrun.Quic...
      Zumindest die kostenlose Version der App scheint nichts zu „entschlüsseln“, aber sie hat Root-Rechte und Zugriff auf das Modem und kann daher solche Logs lesen
      Man kann auch Bänder deaktivieren oder versuchen, sich auf eine bestimmte Funkzelle festzulegen, was nützlich ist, wenn man mobile Daten wie bei einem dedizierten 4G/5G-Router als primäre Internetverbindung nutzen will
    • Viele Mobilfunkanbieter konfigurieren die SIP-Signalisierung für VoLTE so, dass IPsec-Transport verwendet wird, der am P-CSCF terminiert, aber die meisten oder sogar alle konfigurieren IPsec nur für Integritätsschutz
    • Ich meinte wohl keinen GRE-, sondern einen GTP-Tunnel
      GTP-Tunnel liegen zwischen eNodeB und Kernnetz und sind nur geschützt, wenn sie innerhalb von IPsec laufen
    • Korrektur: GTP

  • O2 behauptet nun, dass das Problem behoben wurde: https://www.ispreview.co.uk/index.php/2025/05/o2-uk-fixes-vo...

    • Der eingereichte Artikel wurde heute Morgen aktualisiert
      Darin heißt es: „O2 hat uns per E-Mail kontaktiert und bestätigt, dass dieses Problem behoben wurde. Ich habe das selbst verifiziert, und die Schwachstelle scheint behoben zu sein“
    • In der Stellungnahme hieß es, „das Engineering-Team habe mehrere Wochen lang an einem Fix gearbeitet und ihn getestet“
      Man stelle sich vor, eine Datenbank mit derart sensiblen Daten wäre absichtlich über einen solchen Zeitraum hinweg schutzlos gelassen worden, offenbar ohne irgendjemanden darüber zu informieren
      Es wird interessant sein zu sehen, wie das ICO damit umgeht

  • Scheint ein ziemlich ernstes Problem zu sein
    Ein Handy zu rooten und dann NSG zu installieren, um diese Informationen einzusehen, ist nicht besonders schwer.
    O2 ist außerdem das größte Mobilfunknetz im Vereinigten Königreich und hat auch Verträge mit der Regierung.
    Dass sie nicht geantwortet haben, ist enttäuschend, aber nicht überraschend.
    Bei O2 scheint intern einiges chaotisch zu laufen, und alles, was nicht direkt im Laden behoben werden kann, dauert lange.
    Zum Beispiel Fehler bei der Rufnummernmitnahme.
    Die Systeme wirken veraltet, manche Nutzergruppen können immer noch kein VoLTE verwenden, das neue 5G SA unterstützt keine Sprache und scheint sich zu stark auf n28 zu stützen, wodurch es in vielen Fällen langsam ist.
    Der CTO schreibt im Blog, man müsse „sich von Vanity-Metriken lösen“, obwohl das Netz bei der Datenleistung meist das schlechteste ist.
    [0] https://news.virginmediao2.co.uk/leaving-the-vanity-metrics-...

    • Ich frage mich langsam, ob sie keine EU-Roaminggebühren verlangen, weil ihnen schlicht das System zum Abrechnen fehlt.

  • Ich verstehe nicht, wie O2 überhaupt noch am Markt ist.
    Mit Abstand das schlechteste Netz, und selbst Three mit seiner katastrophalen Backhaul-Situation ist noch besser.
    Der einzige Grund, warum ich neben einer EE-SIM auch eine O2-SIM habe, sind Priority-Tickets und das O2-Signal innerhalb von Veranstaltungsorten.

    • Wenn man Zugang zum 5G Standalone-Netz hat, ist es deutlich besser.
      Man braucht dafür allerdings eine neue SIM und ein kompatibles Smartphone, und der Unterschied im Alltag ist völlig anders.

  • giffgaff, das das O2-Netz nutzt, behauptet, nicht betroffen zu sein, weil es auf dem physischen O2-Netz eine eigene Service-Implementierung verwendet.
    Das mag stimmen, aber da es inzwischen derselben Firma gehört, wirkt eine Integration ziemlich wahrscheinlich, daher bin ich etwas skeptisch.
    Falls das jemand mit einer giffgaff-SIM nachstellen kann, würde ich das Ergebnis gerne wissen.

    • Es gehört schon seit langer Zeit Telefónica.
      Soweit ich mich erinnere, hat Telefónica O2 2006 übernommen und Giffgaff 2009 als neue Marke gestartet.
    • Ich habe es im giffgaff-Netz getestet, und es ist tatsächlich betroffen.
      Ich weiß nicht, wie sie zu einem anderen Ergebnis gekommen sind.

  • Würde das Abschalten von VoLTE das Problem abmildern? Für das iPhone 11 habe ich online Dokumentation gesehen, wie man es deaktiviert, aber auf meinem iPhone 15 gibt es diese Option nicht.

    • Dort steht, dass „das Deaktivieren von 4G Calling nicht verhindert, dass dieser Header offengelegt wird, und wenn das Gerät nicht erreichbar wird, geben die internen Header weiterhin die zuletzt verbundene Funkzelle und an, wie lange das her ist“.
      Daher scheint das nichts zu bringen.
    • Eines der nervigen Dinge an O2 UK ist, dass VoLTE für ältere Prepaid-Kunden nicht unterstützt wird, sondern nur für Vertragskunden; im Moment bin ich darüber fast ein wenig froh.