Analyse der SKT-SIM-„Zurücksetzung“ – Was ändert sich, und ist sie wirklich gleichwertig mit einem Austausch?
(blog.quendi.moe)🔍 Überblick über die SIM-Zurücksetzung
Hintergrund der Einführung: SK Telecom hat nach dem jüngsten Hackerangriff, bei dem ein Abfluss von SIM-Informationen befürchtet wurde, die Funktion „SIM-Zurücksetzung“ eingeführt, um die Sicherheit zu erhöhen, indem einige Informationen ohne physischen SIM-Austausch geändert werden.
Funktionsweise: Die „SIM-Zurücksetzung“ ändert die Benutzeridentifikations- und Authentifizierungsinformationen innerhalb der SIM auf neue Werte und blockiert so den Zugriff mit den bisherigen Informationen.
🧪 Technische Analyse und Verifizierung
Ziel der Verifizierung: Es sollte geprüft werden, ob die „SIM-Zurücksetzung“ tatsächlich die zentralen Sicherheitsparameter innerhalb der SIM verändert und damit Sicherheit gewährleistet.
Analysierte Parameter:
IMSI: Teilnehmer-Identifikationsnummer
K: Authentifizierungsschlüssel, der seit der GSM-Ära verwendet wird
OPc: Betreiber-Authentifizierungsschlüssel, der seit der UMTS-Ära eingeführt wurde
Konstanten des MILENAGE-Algorithmus: `c_i`, `r_i` usw.
Verifizierungsmethode:
Vor und nach der „SIM-Zurücksetzung“ wurden Authentifizierungsanfragen an die SIM durchgeführt, um Änderungen der zurückgegebenen Antwortwerte zu beobachten.
Insbesondere wurde anhand von Authentifizierungs-Fehlermeldungen oder Synchronisierungsfehlern auf Änderungen der internen Parameter geschlossen.
Ergebnis der Verifizierung:
IMSI: wurde geändert.
K und OPc: wurden nicht geändert.
Konstanten des MILENAGE-Algorithmus: wurden nicht geändert.
Das heißt, die zentralen Sicherheitsparameter innerhalb der SIM wurden durch die „SIM-Zurücksetzung“ nicht verändert.
⚠️ Fazit und Empfehlungen
Fazit: Da die „SIM-Zurücksetzung“ die zentralen Sicherheitsparameter innerhalb der SIM nicht verändert, bietet sie nicht den gleichen Sicherheitseffekt wie ein physischer SIM-Austausch.
Empfehlung: Zur Stärkung der Sicherheit wird eher ein physischer SIM-Austausch als eine „SIM-Zurücksetzung“ empfohlen.
15 Kommentare
Ich kenne mich damit nicht gut aus, aber
ist es auch dann riskant, wenn der Entwicklermodus nicht geöffnet werden kann?
Die absolute Mehrheit der Nutzer weiß vermutlich gar nicht, was das ist, und dürfte ihn wohl auch nicht aktiviert haben.
Der Entwicklermodus wird auf der Seite benötigt, die das „von Hackern genutzte Handy“ ist, nicht das „Mobiltelefon des Angriffsziels“. Der Angriff erfolgt mit den offengelegten Authentifizierungsinformationen, daher ist er nicht nötig.
Ja. Das Öffnen von QCDIAG ist aus Sicht eines Angreifers ein notwendiger Schritt, um am UE „irgendetwas“ zu verändern.
> (Weil SKT so etwas wie echtes 5G SA ja sowieso nicht macht)
Wenn 5G SA aktiviert war, dürfte die Hürde dank der SUPI deutlich höher gewesen sein.
Ich habe da eine Frage.
UEs mit zugänglicher Debug-Schnittstelle (stellen Sie sich einfach vor, was geändert werden müsste. Hinweis: Anders als von den Medien behauptet, weiß selbst jemand, der eine Woche lang nur bei XDA mitgelesen hat, dass sich dieser Wert leicht ändern lässt.) <- Es heißt, das sei einfach (man könne es schon verstehen, wenn man nur bei XDA mitliest ...). Weiß jemand zufällig einen Link, den man dazu lesen könnte..?
Ich bin jedenfalls SKT-Kunde, erst vor ein paar Monaten per Rufnummernmitnahme gewechselt, und der Aufwand für einen USIM-Tausch erscheint mir ziemlich groß ... Daher beobachte ich die Lage vorerst nur mit einem USIM-Schutzdienst. Mich interessiert deshalb eher, wie groß das Risiko tatsächlich ist ... und zwar bei den folgenden Annahmen aus dem verlinkten Beitrag:
.... Ich dachte, es wäre für einen Angreifer sehr schwierig, all diese Voraussetzungen zu erfüllen, und besonders der letzte Punkt sei schon für sich genommen nicht einfach. Aber weil gesagt wird, dass es leicht sei, frage ich aus Neugier ... daher diese Frage.
„UE mit zugänglicher Debug-Schnittstelle“
-> Ein typisches Beispiel ist die Samsung-Galaxy-Serie. Darunter reicht es, ein Modell zu kaufen, bei dem sich der Qualcomm-Debug-Modus einstellen lässt.
„Stellen Sie sich einfach gut vor, was geändert werden muss.“
-> Wenn Sie darüber nachdenken, was im Authentifizierungsverfahren verwendet wird, kommen Sie auch ohne einen Blick auf xda sofort darauf, was geändert werden muss.
Was auf xda steht, ist dann wohl die Methode, wie man genau das ändert.
Meine Frage war nicht, was geändert werden muss, sondern wie man es ändert, sodass es als einfach gilt ... (Ich habe wohl Missverständnisse verursacht, weil ich den Originaltext unverändert eingefügt habe.)
Das wird einfach im Editor-Tool mit einem Klick geändert. Dafür gibt es ja die Debug-Funktion..
Das genaue Programm sollten Sie bitte selbst suchen. Wenn man nur weiß, was geändert wird, findet man es auf der ersten Seite von Google/GitHub.
Man kann in einem öffentlichen Forum die Angriffsmethode schließlich nicht komplett offenlegen und erklären.
Im Originalartikel steht, dass „nur die IMSI geändert wurde“, aber in der Zusammenfassung von GeekNews heißt es, dass auch die IMSI nicht geändert worden sei. Das war beim Verfassen der Zusammenfassung offenbar ein Fehler.
Mal ganz abgesehen davon: Sie wollten also ernsthaft nur die IMSI ändern und dann einfach behaupten, damit sei alles sicher? Das ist wirklich absurd.
Ah, danke für den Hinweis. Ich hätte die Zusammenfassung nach dem Zurücksetzen gründlich prüfen sollen, aber das habe ich übersehen – entschuldigen Sie bitte.
Ich würde die fehlerhafte Zusammenfassung gern korrigieren, weiß aber nicht, wie das geht.
Ich habe diesen Teil erst spät überprüft. Er wurde zu „IMSI wurde geändert“ korrigiert.
Ich hoffe, dass es wenigstens exemplarisch eine Strafe in der Größenordnung einer Zerschlagung gibt. Die drei Anbieter dann reihum ... ich habe diese Sicherheitsprobleme langsam wirklich satt. Und auch die Reaktion wirkt von Tag zu Tag schamloser.
Wow … ist das nicht ein Betrug an der ganzen Bevölkerung? Sie sollten das wohl einer Medienredaktion melden.