Análise da “redefinição” do USIM da SKT – o que muda e se ela realmente equivale à troca
(blog.quendi.moe)🔍 Visão geral da redefinição do USIM
Contexto da adoção: A SK Telecom introduziu recentemente a função de 'redefinição do USIM' para reforçar a segurança após surgirem preocupações com vazamento de informações do USIM devido a um incidente de invasão, permitindo alterar algumas informações sem a necessidade de substituir fisicamente o chip.
Explicação da função: A 'redefinição do USIM' funciona alterando para novos valores as informações de identificação e autenticação do usuário dentro do USIM, bloqueando o acesso às informações anteriores.
🧪 Análise técnica e verificação
Objetivo da verificação: Buscou-se confirmar se a 'redefinição do USIM' realmente altera os principais parâmetros de segurança internos do USIM para garantir a segurança.
Parâmetros analisados:
IMSI: número de identificação do assinante
K: chave de autenticação usada desde a era GSM
OPc: chave de autenticação da operadora introduzida desde a era UMTS
Constantes do algoritmo MILENAGE: `c_i`, `r_i` etc.
Método de verificação:
Foram realizadas solicitações de autenticação no USIM antes e depois da 'redefinição do USIM', observando-se as mudanças nos valores de resposta retornados.
Em especial, inferiu-se se houve alteração dos parâmetros internos por meio de mensagens de erro de autenticação ou de falha de sincronização.
Resultado da verificação:
IMSI: foi alterado.
K e OPc: não foram alterados.
Constantes do algoritmo MILENAGE: não foram alteradas.
Ou seja, os principais parâmetros de segurança internos do USIM não foram alterados por meio da 'redefinição do USIM'.
⚠️ Conclusão e recomendações
Conclusão: Como a 'redefinição do USIM' não altera os principais parâmetros de segurança internos do USIM, ela não oferece o mesmo efeito de segurança que a troca física do chip.
Recomendação: Para reforçar a segurança, recomenda-se a troca física do USIM em vez da 'redefinição do USIM'.
15 comentários
Não entendo muito bem, então pergunto:
Mesmo que o modo de desenvolvedor não esteja habilitado, isso ainda é arriscado?
A esmagadora maioria dos usuários provavelmente nem sabe o que é isso, muito menos deve estar com isso ativado.
O lado que precisa do modo de desenvolvedor é o "telefone usado pelo hacker", e não "o celular alvo do ataque". Como a invasão é feita com as credenciais de autenticação vazadas, isso não é necessário.
Sim. Abrir o QCDIAG é uma etapa necessária, do ponto de vista do invasor, para alterar “alguma coisa” no UE.
> (porque a SKT não faz de verdade algo como 5G SA)
Se você tivesse usado 5G SA, a dificuldade provavelmente teria aumentado bastante graças ao SUPI.
Tenho uma dúvida.
UE com acesso à interface de depuração (imagine bem o que seria preciso mudar. Dica: ao contrário do que a imprensa afirma, até quem passou uma semana só acompanhando o XDA sabe que mudar esse valor é fácil.) <- dizem que isso é fácil (que até dá para saber só lendo o XDA...) alguém por acaso conhece algum link onde eu possa acompanhar isso..?
Por enquanto, no meu caso, sou usuário da SKT, faz só alguns meses que fiz portabilidade, e o esforço para trocar o USIM parece grande demais... então, por enquanto, estou só observando a situação com algo como o serviço de proteção de USIM. Por isso, na verdade, fiquei curioso sobre o tamanho real do risco... As premissas abaixo apresentadas no post linkado
.... eu achava que seria muito difícil para um atacante reunir todas essas condições, e especialmente a última eu pensava que, por si só, também não seria nada fácil. Mas como estão dizendo que é fácil, fiquei curioso... então deixo a pergunta.
"UE com acesso à interface de depuração"
-> Um exemplo representativo é a linha Samsung Galaxy. Entre eles, basta comprar um que permita configurar o modo de depuração da Qualcomm.
"Imagine bem o que precisa ser alterado."
-> Se você pensar no que é usado no procedimento de autenticação, dá para chegar imediatamente à resposta sobre o que precisa ser alterado sem nem precisar ir ao xda.
O que está no xda deve ser o método de como alterar isso.
A minha pergunta não era o que precisa ser mudado, mas sim como é que mudam para que isso seja fácil... era isso. (Acho que causei um mal-entendido por ter colado o texto original como estava.)
Isso é só clicar e alterar com uma ferramenta de editor. É para isso que existe a função de depuração..
O programa exato, procure você mesmo. Se souber apenas o que muda, dá para encontrar na primeira página do Google/GitHub.
Não dá para explicar em detalhes uma técnica de ataque inteira em um fórum público.
Ao ler o texto original, está escrito que "apenas o IMSI foi alterado", mas no resumo do GeekNews consta que nem o IMSI foi alterado. Parece que houve um erro na hora de escrever o resumo.
Agora, então a ideia era simplesmente mudar só o IMSI e, mesmo assim, afirmar que de algum jeito estava tudo seguro? Isso é realmente inacreditável.
Ah, obrigado pelo apontamento. Eu deveria ter revisado melhor depois de gerar o resumo, mas deixei passar, peço desculpas.
Quero corrigir o resumo errado, mas não sei como fazer a edição.
Eu vi esta parte tarde. Corrigi para "O IMSI foi alterado".
Mesmo que sirva de exemplo, eu gostaria que houvesse uma punição do nível de desmantelamento. As três se revezando... já está ficando bem cansativo esse problema de segurança. E parece que a forma como lidam com isso está cada vez mais descarada.
Uau... isso não é uma fraude em massa contra a população? Acho que você deveria denunciar à imprensa