SIM Swap

Golpe do SIM Swap

Uma técnica de golpe em que o criminoso ativa o número de telefone (MSISDN) da vítima em outro cartão SIM (IMSI) para acessar suas contas e dados pessoais, o conhecido SIM Swap, é um problema grave, real e extremamente preocupante no cenário atual, ao passo que muitos serviços, como bancos, e-mails, redes sociais, estão vinculados ao número de celular, aliado à ampla adoção da autenticação via SMS.

No Brasil, essa problemática se torna ainda mais crítica ao se verificar que o país ocupa a sétima posição no ranking mundial de vazamentos de dados, de acordo com dados de 2024 divulgados pela empresa global de cibersegurança e privacidade digital Surfshark.

De fato, o SIM Swap ocorre, principalmente, por meio do golpe de engenharia social, em que o criminoso, de posse de dados pessoais coletados da pessoa-alvo, seja por maneiras como phishing ou vazamento, entra em contato com a operadora de serviço móvel do usuário, solicitando a portabilidade ou ativação do número da vítima em um novo SIM. Com base na persuasão ao atendente e/ou na cooptação de funcionários internos corruptos, o criminoso consegue obter sucesso em sua tentativa.

Assim, a operadora desativa o SIM antigo legítimo e ativa o novo SIM controlado pelo golpista, o qual solicita o reset ou recuperação de senhas em diversos serviços. Com isso, os códigos de verificação, enviados por SMS ou ligação de voz, chegam ao chip do criminoso, que os utiliza para acessar as contas da vítima, assumindo o controle delas e causando prejuízos significativos, que, muitas vezes, incluem perdas financeiras diretas.

Solução: SIM Swap API

Dada essa problemática exposta, como parte do projeto de código aberto, conhecido como Open Gateway, liderado pela Global System for Mobile Communications Association (GSMA), foi desenvolvida a API Sim Swap, uma interface programática criada para monitorar e detectar alterações no cartão SIM conectado a um telefone móvel.

Trata-se de uma API encarregada de identificar se um SIM card foi recentemente trocado, fornecendo informações para provedores de serviços e outras entidades que consomem suas capacidades, como a data da última troca de SIM (timestamp) ou indicar se uma troca ocorreu dentro de um período definido. Além disso, a API pode ser utilizada para proteger ações não automatizadas, como a confirmação de operações sensíveis por um especialista de call center.

Casos de Uso

Dentre seus casos de uso e benefícios, a API Sim Swap atende:

• Aprimoramento da two-factor authentication (2FA) para prevenção de fraudes: permite verificação mais aprimorada do usuário durante os processos de registro, de tal forma que, em casos de suspeita de SIM Swap, as aplicações que utilizam a API conseguem, de maneira proativa, identificar e prevenir potenciais atividades fraudulentas.
  • Reforço dos procedimentos TAN nas operações bancárias: confere uma camada de verificação adicional por meio do SIM Swap API, evitando com que o Transaction Authentication Number (TAN) seja enviado diretamente ao usuário, em caso de trocas de SIM recentes, podendo, portanto, ser suspenso o envio de TANs via SMS ou ser exigido formas extras de verificação para garantir que a transação realizada é, de fato, autorizada pelo titular da conta.

• Aumento da segurança nas contas de usuário: fortalece o acesso legítimo dos usuários em suas contas via verificação SMS, ao observar atividades recentes de troca de SIM, promovendo, portanto, um crescimento na confiança e lealdade do cliente na segurança do serviço.
  • Proteção contra sequestro de contas das redes sociais: a API permite com que as redes sociais identifiquem proativamente atividades suspeitas de trocas de SIM, as quais são vinculadas às contas dos usuários, fortalecendo a segurança geral da plataforma e evitando, significativamente, o roubo de identidade.

Operações da API

A API Sim Swap do Camara Project oferece duas operações principais.

POST /retrieve-date

Esta operação retorna o timestamp da última troca de SIM, caso tenha ocorrido, para um número de telefone determinado.

Processo de Requisição

A requisição é do tipo POST e a identificação do número de telefone depende do tipo de token de acesso utilizado:

* Sem “3-legged access token”: O número de telefone DEVE ser fornecido explicitamente no corpo da requisição através do identificador phoneNumber.

* Com “3-legged access token”: O número de telefone NÃO DEVE ser fornecido. Ele é identificado a partir das informações associadas ao próprio token.

Exemplo de Requisição (com phoneNumber caso não tenha “3-legged access token”)

<syntaxhighlight lang="json"> {

 "phoneNumber": "+5511999998888"

} </syntaxhighlight>

Processo de Resposta

Uma resposta bem-sucedida (código 200 OK) fornecerá o timestamp do último SIM swap conforme os seguintes cenários:

* SIM swap ocorrido: Retorna o timestamp exato do evento.

* Nenhum SIM swap (monitoramento ilimitado): Retorna a data de ativação do SIM (primeira conexão à rede).

* Informação não disponível: Retorna um valor null, geralmente devido a políticas de privacidade. Opcionalmente, um monitoredPeriod (em dias) pode ser incluído, indicando que não houve trocas no período informado (apesar de ser opcional, é recomendado oferecê-lo nas implementações do SimSwap

Exemplo de Resposta (SIM swap ocorrido)

<syntaxhighlight lang="json"> {

 "latestSimSwap": "2024-07-15T10:30:00Z"

} </syntaxhighlight>

Exemplo de Resposta (Nenhum SIM swap, retorna data de ativação)

<syntaxhighlight lang="json"> {

 "latestSimSwap": "2023-01-01T00:00:00Z"

} </syntaxhighlight>

Exemplo de Resposta (Informação não disponível)

<syntaxhighlight lang="json"> {

 "latestSimSwap": null,
 "monitoredPeriod": 90

} </syntaxhighlight>

Tratamento de Erros Comuns

Além dos erros de identificação, outros códigos de status HTTP podem ser retornados:

* 400 Bad Request: Requisição mal formatada ou inválida.

* 401 Unauthorized: Falha na autenticação do cliente (ex: token inválido ou expirado).

* 403 Forbidden: O cliente está autenticado, mas não tem permissão para acessar o recurso.

* 422 Unprocessable Entity: A requisição está bem formada, mas contém erros semânticos.

MISSING_IDENTIFIER: Ocorre se o phoneNumber é necessário (sem 3-legged access token) mas não foi fornecido.

UNNECESSARY_IDENTIFIER: Ocorre se o phoneNumber é fornecido quando não deveria ser ("3-legged access token").

* 500 Internal Server Error: Erro inesperado no servidor.

* 503 Service Unavailable: O serviço não está disponível no momento.

POST /check

Esta operação verifica se um SIM swap ocorreu para um número de telefone dentro de um período de tempo específico.

Processo de Requisição

A requisição é do tipo POST e, além da identificação do número de telefone (que segue as mesmas regras da operação retrieve-date no que tange a ausência ou presença do "3-legged access token"), DEVE incluir o atributo maxAge, que define o período em horas a ser verificado (valor entre 1 e 2400).

Exemplo de Requisição (com phoneNumber e maxAge' caso não tenha “3-legged access token”'):

<syntaxhighlight lang="json"> {

 "phoneNumber": "+5511999998888",
 "maxAge": 24

} </syntaxhighlight>

Processo de Resposta

Uma resposta bem-sucedida (código 200 OK) é um objeto JSON contendo um campo booleano swapped:

* "swapped": true Indica que um SIM swap foi detectado no período.

* "swapped": false Indica que nenhum SIM swap foi detectado no período.

Exemplo de Resposta (SIM swap detectado)

<syntaxhighlight lang="json"> {

 "swapped": true

} </syntaxhighlight>

Exemplo de Resposta (Nenhum SIM swap detectado)

<syntaxhighlight lang="json"> {

 "swapped": false

} </syntaxhighlight>

Tratamento de Erros Comuns

Os erros de identificação são os mesmos da operação retrieve-date. Outros códigos de status HTTP podem ser retornados:

* 400 Bad Request: Requisição mal formatada (ex: maxAge fora do intervalo permitido ou com tipo de dado inválido).

* 401 Unauthorized: Falha na autenticação do cliente.

* 403 Forbidden: Sem permissão para acessar o recurso.

* 422 Unprocessable Entity: Erros semânticos na requisição, como MISSING_IDENTIFIER ou UNNECESSARY_IDENTIFIER.

* 500 Internal Server Error: Erro interno do servidor.

* 503 Service Unavailable: Serviço indisponível.

Variáveis

phoneNumber

• Tipo: string
• Padrão: ^\+[1-9][0-9]{4,14}$
  • Exemplo: +346661113334
    • Descrição: Um identificador público que endereça uma assinatura telefônica. Em redes móveis, corresponde ao MSISDN (Mobile Station International Subscriber Directory Number). Para ser globalmente único, deve ser formatado no formato internacional, de acordo com o padrão E.164, prefixado com '+'.

maxAge

• Tipo: inteiro (int32)
• Mínimo: 1
• Máximo: 2400
• Padrão: 240
  • Exemplo: 243
    • Descrição: Período em horas a ser verificado para troca de SIM.

latestSimChange

• Tipo: string (data-hora)
• Nullable: verdadeiro
  • Exemplo: 2023-07-03T14:27:08.312+02:00
    • Descrição: Carimbo de data/hora da última troca de SIM realizada. Deve seguir o RFC 3339 e incluir fuso horário. O formato recomendado é yyyy-MM-dd'T'HH:mm:ss.SSSZ (por exemplo, 2023-07-03T14:27:08.312+02:00 ou 2023-07-03T12:27:08.312Z ).

monitoredPeriod (opcional)

• Tipo: inteiro
  • Exemplo: 120
    • Descrição: Período em dias para a supervisão de troca de cartão SIM para o número de telefone. Pode ser valorado na resposta se a última troca de SIM ocorreu antes deste período monitorado.

swapped

• Tipo: booleano
• Descrição: Indica se o cartão SIM foi trocado durante o período dentro da idade fornecida.