Mas como muitas maneiras são desconhecidas para as pessoas, exceto hackers, esses métodos são usados com frequência. Um desses métodos é hackear um telefone usando SMS. Pesquisadores de segurança cibernética revelaram uma vulnerabilidade crítica e não detectada em cartões SIM que pode permitir que hackers acessem um smartphone apenas enviando um SMS.
Reconhecida como “ SIMJacker ”, a vulnerabilidade está em uma área específica do software, chamada “S@T Browser”. Esse navegador está conectado à maioria dos cartões SIM usados por operadoras de celular em pelo menos 31 países. Independentemente do tipo de telefone que a vítima esteja usando, qualquer pessoa pode hackear o smartphone por meio de um SMS.
S@T Browser significa SIMalliance Toolbox Browser, que é um aplicativo instalado em quase todos os cartões SM como parte do SIM Tool Kit. Geralmente, oferece aos usuários serviços básicos, serviços de valor e assinaturas para os clientes. O navegador contém uma série de instruções, como a chamada de configuração, fornecer dados locais, executar um comando, enviar uma mensagem curta, iniciar o navegador e enviar dados. O software pode ser explorado para enviar um SMS, que também pode executar comandos prejudiciais no telefone.
É assim que funciona
Precisamos primeiro entender os conceitos básicos de SIMs e mensagens SMS. Um Módulo de Identidade do Assinante (ou SIM) é usado principalmente para identificar o usuário em uma rede móvel específica, você pode pensar nele como um pequeno computador independente que você conecta ao seu telefone que permite usar os serviços do provedor de rede móvel (como fazer chamadas e enviar mensagens curtas).
O Serviço de Mensagens Curtas (ou SMS) é usado principalmente para, bem, enviar mensagens curtas de texto de um assinante para outro através do SMS Center (SMSC); que é a parte da infraestrutura do provedor que retransmite mensagens de/para assinantes.
Existem dois tipos de mensagens SMS:
1. Mensagens curtas baseadas em texto
Estas são as mensagens de texto usuais que são enviadas de um assinante para outro, por exemplo, quando você usa o aplicativo de mensagem de texto padrão em seu telefone para enviar uma mensagem de texto SMS para um amigo.
2. Mensagens APDU
As mensagens de Application Protocol Data Unit (ou APDU), por outro lado, são muito mais atraentes, pois podem ser usadas para construir pequenas mensagens de texto simples ou grandes mensagens binárias complexas - essas são as que nos interessam para explorar o SIM Jacker .
As mensagens APDU são codificadas em formato hexadecimal e podem ser enviadas a um assinante, por exemplo, por meio de um modem USB. O processo de envio dessas mensagens, em um nível muito alto, se parece com o seguinte:
De fato, com o propósito de reproduzir a vulnerabilidade do SIM Jacker, usaremos um modem USB para enviar mensagens APDU para um cartão SIM vulnerável dentro de um dispositivo móvel, no entanto, antes de mergulhar nisso, precisamos entender os conceitos de SMS- Enviar e enviar SMS (como mostrado na imagem anterior).
Enviando SMS
O SMS-Submit é usado para transmitir (submeter) uma mensagem do dispositivo de envio (modem USB neste caso) para o SMS Center ( SMSC ). No modelo acima, o SMS-Submit é enviado através do modem USB seguindo o seguinte formato:
Endereço do Centro de Serviços (SCA): Contém o comprimento, tipo e endereço do Endereço do Centro de Serviços, se configurado para 0x00 , será utilizado o SCA padrão.
Primeiro Octeto (FO): Os bits do primeiro octeto são codificados da seguinte forma:
Referência de mensagem (MR): Usado para envio de mensagens instantâneas, pode ser definido como 0x00 .
Endereço de destino (DA): O endereço para o qual a mensagem será enviada. Ele contém o comprimento, tipo e endereço do endereço do destinatário.
Protocol Identifier (PID): O protocolo no qual os dados são enviados, 0x00 é o valor padrão para mensagens de texto.
Esquema de Codificação de Dados (DCS): Indica a codificação dos dados enviados na mensagem, 0x00 é uma codificação de caracteres de 7 bits ( Classe 0 = Mensagem de Texto ).
Comprimento dos dados do usuário (UDL): O comprimento dos dados do usuário.
Dados do usuário (UD): Os dados reais do usuário.
Enviando de SMS
O SMS-Deliver é usado para transmitir (entregar) uma mensagem do SMSC para o dispositivo móvel receptor. O SMS-Deliver é criado a partir da mensagem SMS-Submit e segue o seguinte formato (os campos em negrito na imagem abaixo são copiados no SMS-Deliver diretamente do SMS-Submit )
Endereço do Centro de Serviços (SCA): O endereço do Centro de Serviços. Copiado como é de SMS-Submit .
Primeiro Octeto (FO): Os bits do primeiro octeto são codificados da seguinte forma:
Endereço do originador (OA): O endereço do remetente da mensagem.
Protocol Identifier (PID): O protocolo no qual os dados são enviados. Copiado como é de SMS-Submit .
Esquema de Codificação de Dados (DCS): Indica a codificação dos dados enviados na mensagem. Copiado como é de SMS-Submit .
Service Center Time Stamp (SCTS): carimbo de data/hora exclusivo da mensagem definida pelo Service Center.
Comprimento dos dados do usuário (UDL): O comprimento dos dados do usuário. Copiado como é de SMS-Submit .
Dados do usuário (UD): Os dados reais do usuário. Copiado como é de SMS-Submit .
Enviando uma mensagem APDU
Vamos ter como exemplo a seguinte mensagem APDU:
0001000B910516325476F800000BE8329BFD06DDDF723619
O que significa:
Conectando o Modem USB
Como mencionado anteriormente, para enviar a mensagem APDU, usaremos um modem USB (com um cartão SIM inserido) como o seguinte:
Mudando para o modo de modem HSDPA
Após conectar o Modem USB, você pode notar que ele é reconhecido como um dispositivo de armazenamento em massa , isso pode ser verificado executando o comando lsusb:
Modem USB no modo de armazenamento em massa.
Para alternar para o modo HSDPA , execute o seguinte comando usb_modeswitch :
usb_modeswitch -W -I -v 12d1 -p 1f01 -M 5553424312345678000000000000011063000000100010000000000000000
Dê alguns segundos e execute o comando lsusb novamente para ver a diferença:
Conecte-se ao modem
Para interagir com o modem precisamos primeiro nos conectar a ele, para isso você pode usar o comando screen da seguinte forma (observe que a porta serial pode variar):
tela /dev/ttyUSB0
Estaremos usando comandos AT para interagir com o modem, portanto, se você digitar AT na tela do console e pressionar a tecla ENTER , receberá uma mensagem de OK se tudo estiver funcionando conforme o esperado.
AT (ENTER)
OK
Ative a função de eco
Se você digitou AT mas não viu a string real “ AT ” na tela do console, significa que a função echo não foi habilitada, para isso digite o comando ATE1 e pressione ENTER :
ATE1 (ENTER)
OK
Mudar para o modo PDU
Para enviar uma mensagem APDU, precisamos alternar o modem para o modo PDU , para isso, execute o comando AT+CMGF=0 e pressione ENTER :
AT+CMGF=0 (ENTER)
OK
Envie a mensagem APDU
Para enviar a mensagem APDU execute o comando AT+CMGS=XX (onde XX é o comprimento de toda a mensagem em bytes menos os bytes SCA , XX= 23 neste caso) e pressione ENTER :
AT+CMGS=23 (ENTER)
Um símbolo maior que ( ) aparecerá; isso significa que o modem espera que a seguinte entrada seja a mensagem APDU, digite a mensagem, mas NÃO pressione enter, em vez disso, use a combinação de teclas CTRL+Z para enviar a mensagem.
0001000B910516325476F800000BE8329BFD06DDDF723619 (CTRL+Z)
OK
Verifique a mensagem
Após o envio da mensagem APDU, o destinatário receberá a mensagem de texto SMS com os dados do usuário
Capítulo 2, mensagens OTA,
As mensagens OTA, também conhecidas como mensagens binárias , são mensagens APDU específicas que contêm um conjunto de comandos (U)SIM Application Toolkit (USAT), são mensagens direcionadas a aplicativos específicos dentro do cartão SIM que, por sua vez, executam os comandos USAT fornecidos na própria mensagem, esses comandos incluem, por exemplo: configurar chamadas, enviar mensagens curtas, atualizar informações do SIM, editar arquivos do SIM, etc.
As mensagens OTA geralmente são projetadas para serem enviadas da operadora para o assinante ; um provedor de serviços pode introduzir novos serviços SIM, modificar o conteúdo do SIM, realizar atualizações de software, definições de configuração e até mesmo atualizar as chaves de criptografia para dispositivos móveis.
As mensagens OTA são essenciais para explorar a vulnerabilidade do SIM Jacker , pois é uma dessas mensagens binárias que precisamos criar para poder explorá-la. É claro que também é um requisito que a infraestrutura do provedor permita que esse tipo de mensagem seja retransmitido pela Central de SMS .
Uma mensagem OTA (mensagem binária com configuração específica) pode ser construída em um Download de Dados SMS-PP a partir de um SMS-Deliver que, por sua vez, é construído a partir de um SMS-Submit (enviado de um Modem USB por exemplo). discutirá o Download de Dados SMS-PP em profundidade, mas o processo, em um nível muito alto, é mostrado na próxima imagem:
Um SMS-Submit é enviado do modem USB para o SMS Center , que o transforma em um SMS-Deliver . Se a mensagem estiver em conformidade com determinadas configurações específicas de Identificador de Protocolo (PID) e Esquema de Codificação de Dados (DCS) (como veremos a seguir), o SMS-Deliver será transformado em um Download de Dados SMS-PP .
Um exemplo de envio de SMS para uma mensagem OTA é mostrado na imagem abaixo:
Além do PID e DCS , um campo muito importante é o Security Parameter Indicator (SPI) , que define quais proteções são aplicadas para mensagens de entrada enviadas para um aplicativo SIM e essas proteções são definidas pelo Ciphering Key Identifier (KIc) e Key Identifier (KID). ) campos.
O TAR é a Referência do Aplicativo de Destino ; um identificador que determina para qual aplicativo SIM a mensagem é direcionada. O CNTR e o PCNTR são contadores de nível de protocolo que podem ser configurados para zero .
Os Dados Protegidos contêm os comandos que devem ser executados, esses comandos são construídos usando o USAT e, de acordo com a especificação técnica: “ O USAT fornece mecanismos que permitem que aplicativos, existentes no UICC, interajam e operem com qualquer ME o(s) mecanismo(s) específico(s) exigido(s) pela aplicação “, onde UICC é Placa de Circuito Integrado Universal e ME significa Equipamento Móvel .
Existem 11 mecanismos diferentes definidos para o USAT que dependem dos comandos e protocolos relevantes para ele, esses mecanismos são:
Download do perfil.
UICC proativo.
Download de dados para UICC.
Seleção de Menus.
E mais 7…
Dos quais, estamos interessados principalmente em 2 deles: UICC proativo e download de dados para UICC :
UICC proativo
O UICC proativo fornece um mecanismo pelo qual o UICC pode iniciar algumas ações a serem tomadas pelo equipamento móvel , essas ações incluem: exibir texto para o equipamento móvel, enviar mensagens curtas, configurar uma chamada de voz, executar comandos AT e muito mais.
Esse mecanismo ( Proactive UICC ) é usado em conjunto com o mecanismo Data Download to UICC ao explorar a vulnerabilidade do SIM Jacker e, para fins de demonstração, configurar uma chamada por meio de um comando proativo será uma boa prova de conceito para determinar se o vulnerabilidade foi explorada ou não.
Download de dados para UICC
O Download de Dados faz parte dos Comandos de Envelope e existem 2 tipos diferentes: o Download de Dados SMS-PP e o Download de Dados de Transmissão Celular , estaremos focando no primeiro; com base na especificação técnica, caso o serviço Download de Dados via Ponto-a-Ponto seja alocado e ativado na Tabela de Serviços UICC , o equipamento móvel deverá seguir o seguinte procedimento:
Quando o equipamento móvel recebe uma mensagem curta com:
Identificador de protocolo = Download de dados do SIM e
Esquema de Codificação de Dados = Classe 2
Em seguida, o equipamento móvel deve passar a mensagem de forma transparente para o UICC usando o ENVELOPE (SMS-PP DOWNLOAD) e o equipamento móvel não deve exibir a mensagem ou alertar o usuário de uma mensagem curta em espera.
O formato em um SMS-PP Data Download Envelope é mostrado abaixo (observe que a notação Tag-Length-Value é muito usada para construir esse tipo de mensagem, por exemplo, na imagem abaixo para Device Identities : Tag=0x82 , Comprimento=0x2 e Valor=0x8381 ):
A PDU de SMS Recebida (no canto inferior direito da imagem acima) é construída a partir do SMS-Deliver e, portanto, também do SMS-Submit inicial . O SMS-Submit inicial é construído de forma que o SMS-PP Data Download Envelope seja gerado a partir dele, ou seja, com um Protocol Identifier (PID) e Data Coding Scheme (DCS) específicos . Esses valores precisam ser definidos da seguinte forma:
Identificador de protocolo = 0x7F (Download de dados do SIM)
Esquema de Codificação de Dados = 0xF6 (Classe 2)
Conforme claramente indicado na especificação técnica ( e isso é muito importante ), o Download de Dados SMS-PP é transmitido de forma transparente para o UICC e o equipamento móvel não exibe um alerta para o usuário , isso é muito útil do ponto de vista do invasor , pois o usuário não perceberá que recebeu a mensagem SMS binária.
Navegador S@T
Cada aplicação dentro do cartão SIM usa os campos SPI , KIc e KID para definir um Nível de Segurança Mínimo (MSL) , que especifica o nível de segurança que é aplicado às mensagens enviadas para cada aplicação específica.
A tecnologia USAT particular explorada pelo SIM Jacker é conhecida como S@T Browser e a segurança para suas mensagens recebidas é definida na especificação técnica 3GPP TS 23.048 , existem 2 níveis de segurança suportados:
Por padrão, o navegador S@T é configurado com o primeiro MSL , que é Sem segurança aplicada ( SPI=0x0000 , KIc=0x00 e KID=0x00 ), o que significa que não requer autenticação ou criptografia, o que também significa que um o invasor seria capaz de executar a funcionalidade no cartão SIM através do navegador S@T vulnerável sem que o usuário percebesse (funcionalidade como fazer uma chamada ou enviar uma mensagem de texto SMS). Na verdade, o S@T Browser é o aplicativo de cartão SIM visado pelo SIM Jacker.
Referência de aplicativos
A Referência de Aplicativo de Destino ( TAR ) indica o protocolo ou aplicativo de destino para o qual a mensagem é direcionada. Para os protocolos S@T , os seguintes TARs são definidos (observe que o TAR visado pelo SIM Jacker é o Low Priority Push 0x505348 ):
Capítulo 3, SIM Tester
SIMTester é uma ferramenta escrita em Java pelo pessoal do Security Research Labs e é usada para avaliar a segurança de cartões SIM em 2 dimensões: Superfície de Ataque Criptanalítica coletando assinaturas criptográficas e criptografias de textos simples conhecidos e superfície de ataque de aplicativos gerando uma lista de todos os identificadores de aplicativos (TAR) e encontre aplicativos “desprotegidos” ( MSL =0) .
Com base no wiki do projeto, os requisitos para executar o SIM Tester são os seguintes:
Java 1.7+
Leitor PC/SC (via daemon pcsc) –ou–
Telefone Osmocom (via libosmosim)
Neste caso estaremos usando um leitor de smart card habilitado para PCSC, PCSC é um padrão para comunicação entre um Computador Pessoal e um Smart Card . Embora esta especificação tenha sido inicialmente criada para computadores Windows, atualmente existem implementações disponíveis para Linux e MacOS também, existe uma implementação gratuita conhecida como PCSC Lite e é essa que vamos usar aqui.
Antes de passar para a instalação de todos os softwares necessários, precisamos colocar as mãos em um leitor de cartão inteligente com suporte para o padrão PCSC , para isso usaremos um leitor como o mostrado abaixo (pode ser encontrado facilmente na Internet em sites para importação):
Instalando o software necessário
Se você estiver usando Linux (Ubuntu neste caso), já existem pacotes disponíveis com os softwares e bibliotecas necessários, então, primeiro vamos instalar o daemon pcsc ( pcscd ) e o pcsc-tools :
apt-get install pcscd
apt-get install pcsc-tools
Além de instalar as bibliotecas necessárias ( libpcsclite1 e libpcsclite-dev ):
apt-get install libpcsclite1
apt-get install libpcsclite-dev
E finalmente o driver CCID ( libccid ):
apt-get instala libccid
Testando o leitor
Uma vez que o software necessário esteja instalado, precisamos verificar se o leitor de smart card está funcionando corretamente, para isso, primeiro iniciamos o pcscd :
pccd
Em seguida, inserimos o cartão SIM no leitor de cartão inteligente e conectamos o leitor de cartão inteligente em uma porta USB do seu computador:
Agora executamos o pcsc_scan (parte do pcsc-tools ) para ter certeza de que o smart card foi detectado e está funcionando conforme o esperado:
pcc_scan
Você verá um resultado como o seguinte:
Executando o testador de SIM
Baixe o zip binário pré-compilado do repositório e descompacte-o:
descompacte SIMTester_v1.9.zip
Após descompactar, você pode executar o SIM Tester da seguinte forma:
java -jar SIMTester.jar
Observe que, caso o Java tenha problemas para encontrar o objeto compartilhado libpcsclite , você precisará especificar o caminho manualmente da seguinte maneira:
java -Dsun.security.smartcardio.library=/usr/lib/x86_64-linux-gnu/libpcsclite.so -jar SIMTester.jar
Caso haja alguma vulnerabilidades os resultados serão mostrados em vermelhos
Capítulo 4, Explorando as vulnerabilidades do cartão SIM
Existem 3 condições principais que precisam ser atendidas para poder explorar essa vulnerabilidade e conseguir hackear com sucesso o smartphone do seu alvo: 1. o SMS Center aceita e retransmite mensagens binárias 2. a capacidade do dispositivo de destino de receber mensagens binárias SMS que contém o (U)SIM Application Toolkit comandos e 3. que a tecnologia S@T Browser esteja implantada no cartão SIM e que o Nível Mínimo de Segurança esteja definido como Sem Segurança aplicada.
Outras condições para que o ataque seja bem-sucedido é que o próprio SIM Card tenha 2 capacidades ou serviços habilitados, são eles: Comandos UICC proativos e Download de dados para UICC , esses serviços geralmente são habilitados por padrão nos SIM Cards e por isso não fazem parte das principais condições.
Como vimos na parte 3, as mensagens Over The Air são essenciais para explorar a vulnerabilidade, de fato, o ataque é executado enviando um tipo específico de mensagem OTA para a vítima. Vamos lembrar o formato de uma mensagem SMS-Submit que funcionará como um OTA:
Este é o formato de uma mensagem SMS-Submit , ou seja, a mensagem que se origina do invasor e é enviada através do Modem USB , então vamos por partes:
Endereço do Centro de Serviços (SCA)
A primeira parte é o Endereço da Central de Atendimento , este é o endereço da Central de SMS, ou seja, a parte da infraestrutura do provedor que retransmite as mensagens. Como mencionamos em um artigo anterior, este campo pode ser definido para seu valor padrão (ou seja, o valor já definido no cartão SIM) usando 0x00 , portanto, a primeira parte é:
SCA = 0x00
Primeiro Octeto (FO)
A segunda parte é o First Octet , de um artigo anterior aprendemos que a codificação do primeiro octeto para um SMS-Submit é a seguinte:
Como este é um SMS-Submit , começamos por definir os bits número 0 e 1 para “ 01″ , este é o MTI ( Message Type Identifier ), outros bits podem ser definidos como zero, exceto o bit número 6 que precisa ser definido para “ 1 ”, este é UDHI ( User Data Header Indicator ), portanto, a codificação binária para o primeiro octeto será:
01000001 = 41 em hex.
Então, nosso segunda passo é:
FO = 0x41
Referência de mensagem (MR)
A terceira parte é a referência da mensagem e isso pode ser definido da seguinte forma:
RM = 0x00
Endereço de destino (DA)
O Endereço de Destino é o endereço do destino, este valor é codificado da seguinte forma:
Comprimento do endereço = 0x0B
Tipo de endereço = 0x91 (internacional)
Endereço = 50612345678F = 0x0516325476F8
Assim:
DA = 0x0B910516325476F8
Identificador de protocolo (PID)
O Identificador de Protocolo deve ser definido como Download de Dados do SIM , ou seja:
PID = 0x7F
Esquema de Codificação de Dados (DCS)
O Esquema de Codificação de Dados deve ser definido como Classe 2 , ou seja:
PID = 0xF6
Comprimento dos dados do usuário (UDL)
O comprimento dos dados do usuário é o comprimento em bytes dos dados do usuário, ou seja, o número de bytes que compõem os dados do usuário:
UDL = XX
Dados do usuário (UD)
O User Data contém o User Data Header e o Command Packet , se você se lembrar, no Primeiro Octeto definimos o UDHI ( User Data Header Indicator ) para indicar que o User Data conterá um User Data Header .
Comprimento do cabeçalho de dados do usuário (UDHL)
O comprimento do cabeçalho de dados do usuário é o comprimento em bytes do cabeçalho de dados do usuário e é definido da seguinte forma:
UDHL = 0x02
Cabeçalho de dados do usuário (UDH)
O cabeçalho de dados do usuário é definido de forma a indicar que o pacote de comandos conterá cabeçalhos de segurança , ou seja:
UDH = 0x7000
Pacote de Comando (CP)
O Pacote de Comandos contém informações muito importantes sobre a segurança da mensagem, para qual aplicativo a mensagem é direcionada e quais são os comandos reais que queremos executar.
Comprimento do pacote de comando (CPL)
O Comprimento do Pacote de Comandos é o comprimento em bytes de todo o Pacote de Comandos :
CPL = AAAA
Comprimento do cabeçalho do comando (CHL)
O comprimento do cabeçalho do comando é o comprimento em bytes do cabeçalho do comando :
CHL = 0x0D
O Cabeçalho do Comando é composto por 6 valores diferentes:
Indicador de parâmetro de segurança (SPI)
O Security Parameter Indicator especifica se alguma segurança será ou não aplicada à mensagem, neste caso definimos o SPI da seguinte forma:
SPI = 0x0000
Identificador de Chave de Cifragem (KIc)
O Ciphering Key Identifier identifica o tipo de codificação usado, definimos isso para:
KI = 0x00
Identificador de Chave (KID)
O Identificador de Chave especifica a chave que será usada para criptografia, definimos como:
KID = 0x00
Referência de aplicativo de destino (TAR)
A Referência do Aplicativo de Destino identifica o aplicativo no cartão SIM para o qual enviaremos a mensagem, nós o configuramos para o S@T Browser :
TAR = 0x505348
Contador e contador de preenchimento (CNTR e PCNTR)
Esses valores são definidos da seguinte forma:
CNTR = 0x0000000000
PCNTR= 0x00
Dados Protegidos (Comandos S@T/STK)
Esta é a parte mais importante da carga útil, ela contém os comandos que queremos que o aplicativo S@T Browser execute em nosso nome. Esses comandos são construídos usando STK Bytecode e podem ser usados, por exemplo, para configurar uma chamada e enviar mensagens curtas .
Os comandos S@T/STK são definidos da seguinte forma:
Comandos S@T/STK = 0x42230121…2D0C100383…2B00
Por motivos de segurança, não fornecerei toda a representação hexadecimal desses comandos, pois isso pode ser usado para abusar dessa vulnerabilidade em estado selvagem.
Prova teórica
Para nossa prova de conceito abaixo, usaremos comandos de bytecode que configuram uma chamada no dispositivo de nossa vítima para outro dispositivo controlado pelo invasor.
A vítima não percebe que recebeu a mensagem, mas um prompt é mostrado ao usuário para aceitar a chamada. Usando comandos de bytecode, por exemplo, também podemos fazer com que a vítima envie mensagens curtas com informações confidenciais sem que o usuário perceba.
Enviar SMS
Portanto, nossa mensagem de envio por SMS se parece com isso:
Que é o mesmo mostrado abaixo (onde XX e YYYY são apenas os comprimentos dos bytes posteriores):
0041000B910516325476F87FF6XX027000AAAA0D0000000050534800000000000042230121…2D0C100383…2B00
Enviando a mensagem
Como vimos na parte 1 desta série, usaremos um modem USB para enviar nossa mensagem de ataque , para isso, nos conectamos ao modem com tela :
screen /dev/ttyUSB0
Agora habilitamos o modo PDU:
AT+CMGF=0 (ENTER)
OK
E, finalmente, envie a mensagem (consulte o final deste artigo para obter uma atualização sobre a carga útil completa):
AT+CMGS=69 (ENTER)
0041000B910516325476F87FF6XX027000YYYY0D0000000050534800000000000042230121…2D0C100383…2B00 (CTRL + Z)
A vítima
A vítima recebe a mensagem como um SMS-Deliver que, por sua vez, é transformado em um SMS-PP Data Download . Essa mensagem transformada é tratada pelo SIM Card (já que é uma mensagem binária) e o aplicativo do SIM Card ( S@T Browser ) executa os comandos S@T/STK especificados na própria mensagem, neste caso, isso significa configurar uma chamada .
Observe que a vítima não percebe que recebeu um SMS , no entanto, para esta prova de conceito específica, a vítima recebe um prompt para aceitar a chamada (para um dispositivo controlado pelo invasor), portanto, a vítima verá algo como o mostrado abaixo (observe que o invasor também pode executar outras ações, como enviar uma mensagem SMS com informações confidenciais):
Se o alvo aceitar a chamada, ela ligará para o número controlado pelo hacker que configuramos nos Dados Seguros ( Comandos S@T/STK ).
Observe que o alvo do ataque é especificado como a primeira instância de 2143658709F0 e a segunda instância é o número de telefone que o SIM alvo ligará (já que estamos lidando com um comando STK para configurar a chamada).
O valor 2143658709F0 significa que o número de telefone é (123) 45678900.
