Análisis del “restablecimiento” de la SIM de SKT: qué cambia y si realmente es equivalente a un reemplazo
(blog.quendi.moe)🔍 Resumen del restablecimiento de la SIM
Antecedentes de su implementación: SK Telecom introdujo recientemente la función de "restablecimiento de la SIM" para reforzar la seguridad ante la preocupación por una posible filtración de información de la SIM tras un incidente de hackeo, permitiendo cambiar parte de la información sin reemplazar físicamente la SIM.
Descripción de la función: el "restablecimiento de la SIM" cambia a nuevos valores cierta información de identificación y autenticación del usuario dentro de la SIM, bloqueando así el acceso basado en la información anterior.
🧪 Análisis técnico y verificación
Objetivo de la verificación: se buscó confirmar si el "restablecimiento de la SIM" realmente modifica los parámetros centrales de seguridad dentro de la SIM para garantizar la seguridad.
Parámetros analizados:
IMSI: número de identificación del abonado
K: clave de autenticación usada desde la era de GSM
OPc: clave de autenticación del operador introducida desde la era de UMTS
Constantes del algoritmo MILENAGE: `c_i`, `r_i`, etc.
Método de verificación:
Se realizaron solicitudes de autenticación en la SIM antes y después del "restablecimiento de la SIM" y se observaron los cambios en los valores de respuesta devueltos.
En particular, se infirió si hubo cambios en los parámetros internos a través de mensajes de error de autenticación o de fallo de sincronización.
Resultados de la verificación:
IMSI: sí cambió.
K y OPc: no cambiaron.
Constantes del algoritmo MILENAGE: no cambiaron.
Es decir, los parámetros centrales de seguridad dentro de la SIM no cambiaron mediante el "restablecimiento de la SIM".
⚠️ Conclusión y recomendaciones
Conclusión: como el "restablecimiento de la SIM" no modifica los parámetros centrales de seguridad dentro de la SIM, no ofrece el mismo efecto de seguridad que un reemplazo físico de la SIM.
Recomendación: para reforzar la seguridad, se recomienda el reemplazo físico de la SIM por encima del "restablecimiento de la SIM".
15 comentarios
No lo tengo muy claro, pero
¿es peligroso incluso si el modo desarrollador no se puede abrir?
A la gran mayoría de los usuarios ni siquiera les sonará qué es eso, y no parece probable que lo tengan activado.
El lado que necesita el modo de desarrollador es el "teléfono que usa el hacker", no el "teléfono de la víctima del hackeo". Se aprovecha la intrusión con la información de autenticación filtrada, así que no hace falta.
Sí. Abrir QCDIAG es una tarea necesaria desde la perspectiva del atacante para modificar “algo” del UE.
> (porque SKT en realidad no hace cosas como 5G SA)
Si habías usado 5G SA, la dificultad probablemente habría aumentado bastante gracias al SUPI.
Tengo una duda.
UE con acceso a la interfaz de depuración (imaginen bien qué habría que cambiar. Pista: a diferencia de lo que afirman los medios, hasta alguien que solo haya estado una semana leyendo XDA sabrá que cambiar este valor es fácil.) <- Dicen que esto es fácil (que con solo leer XDA ya se puede saber...), ¿alguien de casualidad conoce algún enlace donde pueda leer sobre eso..?
Por ahora, yo soy usuario de SKT, y como no hace muchos meses que hice la portabilidad, además de que siento que cambiar la USIM requiere demasiado esfuerzo... por el momento estoy observando la situación usando algo como el servicio de protección de USIM. Así que más bien me da curiosidad qué tan grande es realmente el riesgo... Las siguientes suposiciones que se presentan en la publicación enlazada:
.... Yo había pensado que sería muy difícil que un atacante reuniera todas estas condiciones, y en especial que la última, por sí sola, tampoco sería algo fácil. Pero como dicen que es fácil, me dio curiosidad... así que dejo la pregunta.
"UE con acceso a la interfaz de depuración"
-> Un ejemplo representativo es la serie Galaxy de Samsung. De esas, basta con comprar una que permita configurar el modo de depuración de Qualcomm.
"Imaginen bien qué es lo que habría que cambiar."
-> Si piensan en qué se usa en el proceso de autenticación, la respuesta de qué hay que cambiar sale de inmediato, sin necesidad de ir hasta xda.
Lo que aparece en xda sería el método para cambiar eso.
Mi pregunta no era qué había que cambiar, sino cómo lo cambian para que sea algo fácil... eso era. (Parece que causé un malentendido por haber pegado el texto original tal cual.)
Eso simplemente se cambia con un clic en una herramienta de editor. Para eso existe la función de depuración..
Por favor, busquen ustedes mismos el programa exacto. Con solo saber qué cambia, pueden encontrarlo en la primera página de Google/GitHub.
No se puede explicar de principio a fin una técnica de ataque en un foro público.
Viendo el texto original, dice que "solo cambió el IMSI", pero en el resumen de GeekNews aparece que tampoco cambió el IMSI. Parece que fue un error al redactar el resumen.
Pero bueno, ¿de verdad pensaban cambiar únicamente el IMSI y aun así afirmar que de todos modos era seguro? Esto sí que está de locos.
Ah, gracias por la observación. Debí haber revisado bien después de restaurar el resumen, pero se me pasó; una disculpa.
Quiero corregir el resumen equivocado, pero no sé cómo hacerlo.
Revisé esta parte tarde. Lo corregí a "El IMSI fue modificado".
Ojalá hubiera aunque fuera un castigo ejemplar, de nivel desmantelamiento. Que les toque por turnos a las tres compañías... ya es bastante agotador este tema de la seguridad. Y parece que su forma de responder se vuelve cada día más descarada.
Vaya... ¿no es esto un fraude masivo al público? Parece que debería denunciarlo a un medio de comunicación.