MFA: Desvio do Fluxo de Autenticação MFA.

A implementação da solução de autenticação MFA pode estar comprometida de forma a permitir a um invasor simplesmente realizar um desvio do fluxo de autenticação e obter acesso aos recursos desejados.

Uma formas de realizar esse ataque é explorar uma má implementação do sistema de autenticação.

Um cenário comum consiste em encontrar sistemas externos não protegidos por MFA como, por exemplo, um ambiente que utilize o mesmo sistema SSO ( Single-Sign On ) no qual um dos sites exija MFA e o outro não.  Numa situação como essa, um invasor poderia simplesmente logar no site que não exige a MFA como uma forma de acessar a conta de um usuário apenas desviando da MFA.

Por exemplo, o perímetro externo de uma organização pode impor MFA no Microsoft365 e em sua VPN SSL. No entanto, um antigo portal Citrix não usado mais pelos funcionários foi esquecido durante a implantação da MFA. Este sistema seria um alvo de escolha para um invasor com credenciais comprometidas para conseguir um ponto de apoio na rede interna.

A existência de erros na lógica na aplicação é outra vulnerabilidade que permite o desvio do fluxo de autenticação MFA .

Às vezes, os invasores podem derrotar a MFA simplesmente explorando os erros de lógica do aplicativo no processo de autenticação. Um erro lógico comum que compromete o MFA é a a existência de uma etapa de autenticação que possa ser ignorada, o que poderia permitir aos usuários pular uma etapa no processo de autenticação.

Tomemos como exemplo a seguinte situação de MFA em três etapas:

Passo 1 (verificação da Senha) -> Passo 2 (código em hardware) -> Passo 3 (pergunta de segurança)

Sendo que a aplicação deveria funcionar da seguinte forma:

1. Pagina_de_acesso/ login (solicita a senha do usuário -> Passo 1)

2. Caso as credenciais estejam corretas, envia a página MFA_HWC

3. Pagina_de_acesso/MFA_HWC (solicita o envio do código de hardware armazenado pelo usuário - > Passo 2)

4. Caso o código de hardware seja válido, envia a pergunta de segurança

5. Pagina_de_acesso/MFA_perguntadeseguranca (solicita o envio da resposta à pergunta de segurança -> Passo 3)

6. Caso a pergunta de segurança seja respondida corretamente, autoriza a solicitação de login

Aparentemente, o processo parece estar correto. No entanto, veja que o passo 6 “autoriza a solicitação de login ” CASO a pergunta de segurança seja respondida corretamente. Ou seja, a lógica adotada foi a de que o usuário obrigatoriamente realizará todos os passos a fim de obter a autorização de login , desconsiderando a possibilidade de que um ator seja capaz de pular o passo 2 do processo de MFA.

Na prática, com essa lógica adotada, seria possível a um invasor, após informar o login e senha do usuário (que, como já foi visto, é trivial de ser obtido), enviar um request diretamente para Pagina_de_acesso/MFA_perguntadeseguranca com a resposta correta (pois é bem mais fácil descobrir a resposta de uma pergunta de segurança do que falsificar um código de hardware de posse do usuário). Nesse caso, o invasor evitaria o redirecionamento MFA_HWC e teria sua solicitação de login autorizada.

A correção desse erro de lógica seria simples, pois bastaria alterar o item 6. para:

6. Caso MFA_HWC E MFA_pergunta_de_seguranca estejam corretos, autoriza a solicitação de login.

Textos: João Alberto Muniz Gaspar

Produção: Secretaria de Segurança da Informação e Cibernética