Arquivo de Março de 2010
Metagoofil – Google Hacking automatizado
Metagoofil é uma ferramenta para enumeração desenhada para extrair informações a partir do header de metadata de documentos públicos (pdf,doc,xls,ppt,odp,ods) disponíveis no site da rede alvo.
Após varrer o google a procura dos documentos específicados na command line ele irá gerar um html de saída com os resultados do metadata estraído, listando Potenciais Usernames que serão muito úteis para preparar um Brute-Force attack em serviços disponibilizados como por exemplo, pop3, ftp, web applications, vpn, etc. Além disto ele irá extrair também uma lista de PATHs que foram armazenados no Metada, com essa informação é possível o FingerPrint do sistema operacional alvo, nomes de redes, Shared Resources, etc.
Esta nova versão do metagoofil extrai também o MAC Address de documentos Microsoft Office. Agora você pode ter uma idéia do tipo de hardware que o OS alvo está utilizando.
Todas estas informações não deveriam estar disponíveis na internet, porém a grande maioria das empresas não tem políticas para Information Leaking (Vazamento de Informações), isso sem falar que dessa grande maioria, 90% nem sabe que este tipo de informação realmente existe 
. Com isto você pode mostrar a elas quanta informação um atacante pode obter com uma técnica muito simples.
Como Funciona?
1- Em primeiro lugar o Metagoofil irá procurar no google por documentos públicos sobre determinada empresa. Exemplo, arquivos .PDF (Abaixo segue a Query para Google Hacking).
2- Ele faz download de todos os documentos encontrados para o disco e extrai os Metadata de todos eles, aplicando um filtro para capturar somente as informações realmente interessantes.
3- Exemplo de resultados extraídos por uma sesão de Metagoofil:
Exemplo de lista de Paths disponíveis extraídos do Metadata pelo Metagoofil:
Portanto tenham cuidado com os documentos que você posta na internet, eles podem revelar muitas informações que podem ser utilizadas por atacantes e facilitar a vida deles
- Fornecendo usuários de sua rede,
- Fornecendo informações sobre os hosts que podem ser vítimas de ataque,
- Ajudando a colher dados durante o inicio de um ataque que podem ser utilizados para engenharia social.
26 de Março de 2010 às 13:16
TrustSign
De acordo com matéria publicada nesta última quarta-feira pelo portal IDGNOW, o presidente da corretora BroCo Investments, Valery Maltsev, entrou nas contas dos investidores depois de “hackear” seus nomes de usuários e senhas. Com essas informações, ele realizou transações não autorizadas e manipulou ações de 38 companhias presentes na Nasdaq e na bolsa de Nova York.
Dia 06 de novembro do ano passado postamos uma matéria sobre como elaborar senhas mais fortes para se proteger desse perigo que é cada vez mais constante em todo o mundo. A matéria sugeriu métodos para a escolha dos caracteres e ensinou como não esquecer da senha.
Veja um resumo:
Tomemos um exemplo, cadeados com segredos de 3 posições usados em maletas, malas, cabos de notebook e outros. Cada uma das posições vai de 0 a 9, o que nos dá 3 posições de 10 números cada, o que totaliza 1000 possibilidades, e se uma pessoa consegue testar 10 posições por minuto, em 1 hora e 40 minutos no máximo ela conseguirá abrir o cadeado. Da mesma forma ocorre com nossas senhas, quanto mais complexa for, mais difícil será de conseguir quebrá-la.
É importante lembrarmos que a complexidade é tão importante quanto o tamanho, já que computadores conseguem testar milhares de senhas por minuto, então segue UMA dica muito útil e importante sobre como fazer uma senha complexa e forte de forma fácil:
Sempre misture letras maiúsculas e minúsculas, números e caracteres especiais de preferência com mais de 14 dígitos.
E como fazer isso de forma a não esquecer a senha?
Crie frases, preferencialmente sem sentido, ou associadas a algo de sua vida.
Exemplo:
- Eu nasci dia 23 e tenho 23 anos
Traduzindo isso em uma senha teremos End23et@#A
Adotamos a primeira letra de cada palavra, sendo a primeira e última da senha em maiúsculo, os dois primeiros números foram usados sem alteração e os dois últimos foram usados com a tecla shift, o que os transformou em caracteres especiais.
E agora, o que não fazer:
Não use variações do login de rede, nomes e sobrenomes, apelidos, palavras de dicionário, nomes de animais, telefones, nomes de rua, números de casas, apenas números, apenas letras, datas ou combinações de datas, seqüencias de teclado, senhas mencionadas em livros e filmes, e claro em Blogs, e o mais importante sobre o que nunca fazer, NUNCA COMPARTILHE SENHAS!
Fonte: IDGNOW, março de 2010: http://idgnow.uol.com.br/
18 de Março de 2010 às 15:15
TrustSign
Mais um colega chegando na equipe. Flávio Bahlis entra na equipe comercial da TrustSign.
” Quando vislumbrei a possibilidade de mudar de ramo e iniciar uma nova carreira na TrustSign, fiquei inseguro. Estava em um bom momento profissional e uma mudança me parecia arriscado e desnecessário, mas ao mesmo tempo, eu não tinha mais perspectiva de crescimento pois havia chegado ao limite das possibilidades.
Pensei com carinho e resolvi tirar a dúvida na entrevista de emprego. Logo, o “frio na barriga” sumiu e levou toda a insegurança junto, pois conhecendo a gerência e os diretores da empresa, percebi que eu estava tratando com profissionais que respeitaram minha opinião, valorizaram meus planos de carreira, e me deram todo o crédito necessário para somar minha experiência à empresa.
Aceitei o emprego e não me arrependi. O momento não poderia ser melhor com a empresa em plena expansão, e a abertura de novos negócios que me motiva ainda mais. Saber que seus objetivos pessoais estão em sincronia com os da empresa é tudo que um profissional deseja para crescer. A recepção foi muito bacana por parte de toda a equipe, o que me faz pensar que este novo desafio será muito bacana de trilhar.” - Flávio Bahlis.
Mais uma vez, seja muito bem vindo à equipe!
16 de Março de 2010 às 11:13
TrustSign
O departamento comercial da TrustSign está crescendo!
Agora entra para somar na equipe a estudante de marketing, Leila Borges.
“Olá, pessoal… Ingressei na Trust no dia 04/02/10 , vim da concorrência… Achei a empresa bem acolhedora e aberta a novos desafios.
Espero poder crescer profissionalmente, e com isso fazer com que a empresa também alcance todas as suas metas e objetivos. E que o presente seja cada vez melhor , para que no futuro possamos colher todos os frutos plantados agora. Beijos pra todos e boa sorte nessa nossa caminhada!!” - Leila Borges
15 de Março de 2010 às 11:00
TrustSign
Prezados clientes, por indisponibilidade de serviços da Eletropaulo estamos sem energia elétrica desde 9h30. Urgências ligue para 11-7754.7533.
12 de Março de 2010 às 15:14
TrustSign
O Cross-Frame Scripting (XFS) é um ataque client-side variante do ja famoso Cross-Site Scripting (XSS). Em um ataque de XFS, o atacante explora um determinado cross-frame-scripting bug em um browser para acessar através dele dados privados em um web-site secundário. O atacante induz o browser do usuário à navegar para a página que o atacante controla; o atacante pode carregar uma página secundária em um frame HTML; executando um javascript o atacante pode conseguir dados de websites carregados em um frame secundário.
Principais Fatores de Risco
Os modelos de segurança padrão em browsers permitem que javascripts de uma determinada página possa acessar o conteúdo de outras páginas que sejam carregadas em diferentes janelas do browser ou frames – desde que as outras páginas tenham sido carregadas a partir da mesma origem. Entretanto, um bug específico neste modelo de segurança existe em browsers específicos, permitindo assim que um atacante acesse dados carregados a partir de páginas carregadas de origens/domínios diferentes.
O browser mais conhecido por conter este tipo de bug é o IE (internet explorer), que permite vazamento de keyboard events através de HTML framesets. Este bug pode permitir, por exemplo, que um atacante roube dados de login que o usuário está digitando em um determinado site carregador a partir do Frame-set malicioso.
Exemplos: XFS Attack em um Internet Explorer
Para conseguirmos explorar o bug no IE que permite que os Keyboard Events sejam roubados a partir de um frameset, um atacante deve criar uma página e hospedá-la em um servidor qualquer, em nosso exemplo ela estará hospedada em badsite.com. Esta página será controlada pelo atacante, e deverá incluir por exemplo um frame mostrando uma página de login do site goodsite.com.
O atacante pode esconder as bordas do frame e expandir o frame para cobrir a pagina toda, desta forma o usuário irá realmente acreditar que está acessando goodsite.com. O atacante registra alguns javascripts no index de badsite.com que irá obter todos os key events na página. Normalmente estes listeners serão notificados apenas pelos key events da janela principal do site badsite.com – mas devido o bug existente no browser, este listener irá receber todos os key events existentes no frame carregado com o login do goodsite.com.
Desta forma todas as teclas pressionadas no browser, dentro deste frame do goodsite.com, enquanto ele tenta logar-se, poderá ser capturada e depois enviada para badsite.com
Abaixo vamos ver um código que possibilita este ataque na prática.
_______________________ exemplo _________________________
_________________________EOF____________________________________
Foi-se o tempo em que um website era apenas um website. Devemos tomar o cuidado ao acessar sites desconhecidos, links recebidos por e-mail e etc. Um atacante pode tentar fazer um phishing scam utilizando uma técnica como esta, tentando ludibriar você e enviando falsos domínios como por exemplo:
www.bradseco.com.br
www.ltau.com.br
Veja que trocando o i por l na url do banco Itaú fica dificil perceber a diferença a primeira vista. Sendo assim muito cuiado com e-mails, links que acessa e com suas informações de login e senha que podem ser capturadas desta forma.
11 de Março de 2010 às 17:02
TrustSign
O ataque de Brute-force sempre foi muito comum em serviços disponibilizados remotamente tais quais, FTP, SMTP, POP e outros. Em geral, este ataque por si só não apresenta um risco muito grave, porém pode ser utilizado como vetor para ataques mais complexos que podem explorar falhas na infra-estrutura, desde políticas de permissões fracas ou mal configuradas, política de senhas ineficientes ou inexistentes, e outras.
Durante este tipo de ataque, o atacante tenta transpor mecanismos de segurança, por exemplo, sistemas de autenticação, proteção de diretórios por senha, etc, tendo como base um mínimo conhecimento sobre o alvo.
Existem basicamente 2 métodos que podem ser empregados neste tipo de ataque, o ataque de dicionário e o de força-bruta.
Dicionário: O atacante utiliza um catalogo pré-formatado onde são utilizadas strings que contém possíveis resultados, e que em geral utilizam senhas padrão comumente utilizadas assim como nomes de pastas, etc. Em geral este tipo de ataque tende a ser direcionado.
Força-Bruta: O atacante utiliza classes de caracteres, por exemplo, alfanumérica, caracteres especiais, case sensitive e etc. Neste caso específico este tipo de método demanda muito tempo e seu percentual de aproveitamento é muito baixo, assim como gera muito “alarde” durante o ataque fazendo com que possíveis mecanismos de segurança, como IDS, IPS e outros sejam acionados.
Em sua grande maioria os ataques de brute-force são utilizados objetivando conseguir senhas de usuários para controle de acesso de aplicações e sistemas. Entretanto, existem diversas ferramentas que utilizam esta técnica para examinar web services, procurar pastas contendo arquivos que possam conter senhas de banco de dados, assim como testar como a aplicação se comporta utilizando diferentes data forms (GET/POST), e ainda identificar session-IDs de usuários.
Especialmente em aplicações web o ataque de brute-force pode ser utilizado para:
- Conseguir cookies de acesso a sessões de usuários;
- Usuários e senhas de diretórios protegidos;
- SessionID de aplicações;
- Arquivos de include contendo dados sensíveis como senhas de banco de dados entre outras.
Veremos abaixo alguns exemplos de ferramentas que podem ajudar durante o teste de aplicações web e descobrir se estamos vulneraveis a este tipo de ataque.
Para testes em serviços web existem 2 ferramentas interesssantes:
- dirb (http://sourceforge.net/projects/dirb)
- webroot (http://www.cirt.dk/tools/webroot/WebRoot.txt)
A ferramenta dirb consiste em uma ferramenta com opções mais avançadas e pode ser utilizada para:
- setar diferentes cookies
- adicionar qualquer tipo de HTTP header desejado
- utilizar proxys para mascarar a conexão
- Utilizar catalogos ou arquivos utilizando dicionários definidos ou templates fazendo uma varredura direcionada.
Podemos fazer um teste simples utilizando-a:
[root@localhost /]$ ./dirb http://laboratorio.test/
—————–
DIRB v1.9
By The Dark Raver
—————–
START_TIME: Mon Jul 9 23:13:16 2007
URL_BASE: http://laboratorio.test/
WORDLIST_FILES: wordlists/common.txt
SERVER_BANNER: apache/3.2.2
NOT_EXISTANT_CODE: 404 [NOT FOUND]
(Location: ‘’ - Size: 345)
—————–
Generating Wordlist…
Generated Words: 839
—- Scanning URL: http://laboratorio.test/ —-
FOUND: http://laboratorio.test/phpmyadmin/
(***) DIRECTORY (*)
No output da ferramenta somos informados que a pasta phpmyadmin/ foi encontrada. Um atacante poderia agora efetuar um ataque direcionado para a aplicação PHPMyAdmin, como por exemplo tentar senhas de acesso default ou utilizar exploits para a versão em uso do PHPmyAdmin.
Um dos maiores problemas com ferramentas como o dirb é reconhecer se a mensagem de retorno do servidor é a esperada ou não. Em casos onde o servidor tem configurações avançadas (exemplo utilizando mod_rewrite) ferramentas automaticas não conseguem distinguir uma mensagem de resposta do servidor sobre um determinado erro ao acessar uma pasta ou arquivo.
A aplicação WebRoot.pl escrita pelo CIRT.DK, tem mecanismos embutidos para trabalhar as respostas do servidor, e baseado na frase especificada pelo atacante, consegue identificar se a resposta do servidor é a esperada ou não.
./WebRoot.pl -noupdate -host laboratorio.test -port 80 -verbose -match “senha” -url “/private/” -incremental lowercase -minimum 1 -maximum 1
oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00
o Webserver Bruteforcing 1.8 o
0 ************* !!! WARNING !!! ************ 0
0 ******* FOR PENETRATION USE ONLY ********* 0
0 ****************************************** 0
o (c)2007 by Dennis Rand - CIRT.DK o
oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00
[X] Checking for updates - NO CHECK
[X] Checking for False Positive Scan - OK
[X] Using Incremental - OK
[X] Starting Scan - OK
GET /private/b HTTP/1.1
GET /private/z HTTP/1.1
[X] Scan complete - OK
[X] Total attempts - 26
[X] Sucessfull attempts - 1
oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00
WebRoot.pl encontrou um arquivo /private/b no laboratorio.test, que contem a frase “senha: 123mudar”
Ferramentas para Identificar e proteger contra brute-forc e em aplicações Web.
Php-Brute-Force-Attack Detector
http://yehg.net/lab/pr0js/files.php/php_brute_force_detect.zip
Esta ferramenta detecta se seu servidor esta sendo scanniado por ferramentas de brute-force como WFuzz, Owasp DirBuster e scans e vulnerabilidades como Nessus, Nikto, Acunetix, etc. Ela pode ajudar a rapidamente identificar possíveis hosts utilizados por atacantes que ficam efetuando testes em sua aplicações para identificar brechas e possíveis falhas de segurança.
4 de Março de 2010 às 12:48
TrustSign
