Vejo que muitas pessoas não sabem a diferença de um para o outro. Por isso vou fazer uma série de posts explicando o que cada um faz, como faz, darei exemplos, etc.
Para começar, darei a definição de cada um. Nos próximos posts me aprofundarei no assunto (se assim Deus permitir) com técnicas de cada um, formas de proteção, etc.
Malware – O termo malware é referente a todo programa que tem fins maliciosos. Ou seja, vírus, trojans, worms e outros são malwares. Vem do inglês malicious software (software malicioso).
Vírus – Vírus é um software que infecta outros softwares, documentos, entre outros. Seu objetivo é se espalhar o máximo possível. Assim, o maior vetor de proliferação de um vírus puro é a troca de arquivos com outras pessoas.
Worms – Os worms são como vírus, mas eles não precisam de outros programas para se espalhar. O worm se espalha explorando vulnerabilidades (falhas de segurança) em sistemas. Assim, para um computador ser infectado por um worm, não precisa de nada além de deixá-lo ligado e com acesso à rede (seja internet, intranet ou qualquer outra). Worms são os mais rápidos em disseminação.
Trojan – Trojan é um software que tem por finalidade roubar dados. Para isto o trojan poderá usar de diversos artifícios. Alguns têm backdoors que permitem controlar a máquina remotamente.
Backdoor – São literalmente “portas dos fundos” que ficam abertas para permitir a invasão. Muitos malwares usam backdoors. Com isto, o hacker poderá ter acesso sempre que quiser à máquina da vítima.
Rootkit – Rootkits são softwares que dão acesso de sistema (ou ao menos administrador/root) ao invasor. Geralmente são device drivers instalados na máquina. Drivers tem o nível de permissão mais alta dentro de um sistema. Assim, o hacker cria um driver malicioso que dê permissão de sistema para ele mesmo.
Um rootkit também pode ser feito para esconder os rastros da invasão.
Existem alguns rootkits que resistem até mesmo à formatação da máquina.
Pessoal, é isso. Nos próximos posts falarei como os vírus agem, como se espalham e o que podem fazer.
Abraços
Friday, August 19, 2011
Monday, August 15, 2011
Kioptrix nível 2
Terminei o nível 2 da série de desafios do site Kioptrix. Este foi MUITO fácil. Muito mais fácil que o nível 1...
Eu só consegui usando injections. Olhando vídeos e walkthroughs pela pela internet, percebi que todos conseguiram seguindo a mesma linha que eu... Alguns usaram backdoors, metasploit, etc. Mas as técnicas foram as mesmas que eu usei. Será que alguém conseguiu de outra forma?
O vídeo mostra até o ponto que consegui me tornar root. Depois disso eu criei uma conta ssh para que eu entrasse sempre que quisesse... Mas isto é um detalhe.
Segue o vídeo da minha resolução.
Abraços a até a próxima
Eu só consegui usando injections. Olhando vídeos e walkthroughs pela pela internet, percebi que todos conseguiram seguindo a mesma linha que eu... Alguns usaram backdoors, metasploit, etc. Mas as técnicas foram as mesmas que eu usei. Será que alguém conseguiu de outra forma?
O vídeo mostra até o ponto que consegui me tornar root. Depois disso eu criei uma conta ssh para que eu entrasse sempre que quisesse... Mas isto é um detalhe.
Segue o vídeo da minha resolução.
Abraços a até a próxima
Thursday, August 11, 2011
Desafio Kioptrix Level 1
As VMs do site Kioptrix são desafios que "O objetivo do jogo é adquirir acesso root por qualquer meio possível (exceto hackeando o VM Player ou server). Existe mais de uma forma de completar os desafios".
O level 1 foi bem fácil. Consegui explorando vulnerabilidades no Samba e no OpenSSL. Seguem os vídeos das duas formas que consegui.
Quem quiser baixar esta máquina virtual para realizar o desafio também, o link é http://www.kioptrix.com/dlvm/Kioptrix_Level_1.rar
Abraços a todos e até a próxima
O level 1 foi bem fácil. Consegui explorando vulnerabilidades no Samba e no OpenSSL. Seguem os vídeos das duas formas que consegui.
Quem quiser baixar esta máquina virtual para realizar o desafio também, o link é http://www.kioptrix.com/dlvm/Kioptrix_Level_1.rar
Abraços a todos e até a próxima
Tuesday, August 9, 2011
Anonymous declara que atacará o Facebook!
Quem nunca ouviu falar do grupo Anonymous? Difícil encontrar alguém que acompanhe notícias e nunca tenha ouvido falar sobre este grupo...
O grupo Anonymous é famoso por derrubar diversos sites governamentais do mundo e conseguir diversos documentos e dados sigilosos. O governo brasileiro já teve problemas com este grupo (na operação #OpBrasil). Recentemente a Polícia Federal também teve dados roubados numa dessas operações.
Este grupo acaba de anunciar (09/08/2011) a operação #OpFacebook. Dizem que dia 05 de novembro, farão um ataque ao Facebook. Segundo eles, o Facebook deixará de existir.
O motivo alegado para isto, segundo eles, é que estão cansados do facebook vender dados das pessoas para outras grandes organizações como se fossem pedaços de papel...
Será que conseguirão? O Facebook não é um modelo de segurança... então eu realmente não acho difícil...
Vejam o comunidado oficial em http://www.anonwiki.org/2011/08/opfacebook-5-de-noviembre-comunicado.html
O grupo Anonymous é famoso por derrubar diversos sites governamentais do mundo e conseguir diversos documentos e dados sigilosos. O governo brasileiro já teve problemas com este grupo (na operação #OpBrasil). Recentemente a Polícia Federal também teve dados roubados numa dessas operações.
Este grupo acaba de anunciar (09/08/2011) a operação #OpFacebook. Dizem que dia 05 de novembro, farão um ataque ao Facebook. Segundo eles, o Facebook deixará de existir.
O motivo alegado para isto, segundo eles, é que estão cansados do facebook vender dados das pessoas para outras grandes organizações como se fossem pedaços de papel...
Será que conseguirão? O Facebook não é um modelo de segurança... então eu realmente não acho difícil...
Vejam o comunidado oficial em http://www.anonwiki.org/2011/08/opfacebook-5-de-noviembre-comunicado.html
Monday, August 8, 2011
Desafio divertido de segurança
Pessoal, conheci um desafio diferente e bem divertido: pWnOS.
Isto é um jogo em que você baixa uma VM do Ubuntu com diversas vulnerabilidades. Logo no início não se tem acesso a nenhum nome de usuário nem senha. Porém você percebe que diversos serviços como servidor web, ssh, etc. são inicializados. Sua meta é conseguir entrar no servidor e se tornar root. A VM com o sistema pode ser baixada em http://forums.heorot.net/viewtopic.php?f=21&t=149
Aqui posto o vídeo de como consegui isto.
Isto é um jogo em que você baixa uma VM do Ubuntu com diversas vulnerabilidades. Logo no início não se tem acesso a nenhum nome de usuário nem senha. Porém você percebe que diversos serviços como servidor web, ssh, etc. são inicializados. Sua meta é conseguir entrar no servidor e se tornar root. A VM com o sistema pode ser baixada em http://forums.heorot.net/viewtopic.php?f=21&t=149
Aqui posto o vídeo de como consegui isto.
Friday, July 29, 2011
Carders e hackers exploram falhas do OSCommerce
Quase diariamente eu visito sites que listam domínios de malwares. Visitando um destes sites vi que dos 50 domínios listados na primeira página, 47 eram sites legítimos que utilizam OSCommerce.
OSCommerce é um sistema para criação de lojas virtuais. É muito simples de usar e criar lojas inteiras. Por ter código aberto, é altamente customizável. Existem comunidades inteiras dedicadas a dar suporte e criar novos plugins para este sistema. Com certeza é um dos mais conhecidos e usados sistemas para lojas online.
Um sistema maravilhoso. Mas tudo que é muito usado fica visado. Com o OSCommerce não é diferente. De tempos em tempos alguém descobre uma nova vulnerabilidade no OSCommerce. Então hackers fazem a festa.
Quando eu comecei a estudar segurança da informação, eu tinha 14 anos. Na época o OSCommerce já era alvo de hackers e de tempos em tempos alguém postava no mail list do SecurityFocus uma nova vulnerabilidade deste sistema. E quem pensa que isso ficou no passado, se engana.
Há alguns dias atrás descobri, em uma página legítima que estava espalhando trojans bancários, um scanner de vulnerabilidades que recebia comandos por um canal de IRC. O scanner busca por sites, usando o google e comandos como inurl e intext, que atendam os requisitos. Quando encontra, verifica se o site é vulnerável e, se for, já instalava um shell para controle remoto do servidor. Um dos exploits deste scanner era para o OSCommerce.
O Oscommerce, ao que me parece, é o sistema de ecommerce preferido dos hackers pela facilidade que se pode quebrar toda a segurança do sistema. Ao longo da história do OSCommerce já houveram casos de Remote File Inclusion, SQL Injection, XSS, mas com certeza a que está sendo mais explorada atualmente é Arbitrary File Upload Vulnerability.
Esta vulnerabilidade é séria porque nos permite fazer o upload de qualquer coisa sem sequer ter permissão para tal. Sobre esta vulnerabilidade, veja http://www.securityfocus.com/bid/47855 e http://www.securityfocus.com/bid/44995
Peguei um dos links que estavam marcados com malware e tentei explorar o Arbitrary File Upload do OSCommerce. Vejam que após conseguir enviar um shell, vi que existiam vários bots na pasta, mailers para enviar e-mails em nome do bradesco, shells, etc.
Atualmente não existe correção para esta vulnerabilidade do OSCommerce. Por isso, caso você use este sistema, restrinja o acesso ao diretório admin (veja este exemplo: http://usedbooksnewgifts.com/admin )
Abraços e até a próxima
OSCommerce é um sistema para criação de lojas virtuais. É muito simples de usar e criar lojas inteiras. Por ter código aberto, é altamente customizável. Existem comunidades inteiras dedicadas a dar suporte e criar novos plugins para este sistema. Com certeza é um dos mais conhecidos e usados sistemas para lojas online.
Um sistema maravilhoso. Mas tudo que é muito usado fica visado. Com o OSCommerce não é diferente. De tempos em tempos alguém descobre uma nova vulnerabilidade no OSCommerce. Então hackers fazem a festa.
Quando eu comecei a estudar segurança da informação, eu tinha 14 anos. Na época o OSCommerce já era alvo de hackers e de tempos em tempos alguém postava no mail list do SecurityFocus uma nova vulnerabilidade deste sistema. E quem pensa que isso ficou no passado, se engana.
Há alguns dias atrás descobri, em uma página legítima que estava espalhando trojans bancários, um scanner de vulnerabilidades que recebia comandos por um canal de IRC. O scanner busca por sites, usando o google e comandos como inurl e intext, que atendam os requisitos. Quando encontra, verifica se o site é vulnerável e, se for, já instalava um shell para controle remoto do servidor. Um dos exploits deste scanner era para o OSCommerce.
O Oscommerce, ao que me parece, é o sistema de ecommerce preferido dos hackers pela facilidade que se pode quebrar toda a segurança do sistema. Ao longo da história do OSCommerce já houveram casos de Remote File Inclusion, SQL Injection, XSS, mas com certeza a que está sendo mais explorada atualmente é Arbitrary File Upload Vulnerability.
Esta vulnerabilidade é séria porque nos permite fazer o upload de qualquer coisa sem sequer ter permissão para tal. Sobre esta vulnerabilidade, veja http://www.securityfocus.com/bid/47855 e http://www.securityfocus.com/bid/44995
Peguei um dos links que estavam marcados com malware e tentei explorar o Arbitrary File Upload do OSCommerce. Vejam que após conseguir enviar um shell, vi que existiam vários bots na pasta, mailers para enviar e-mails em nome do bradesco, shells, etc.
Atualmente não existe correção para esta vulnerabilidade do OSCommerce. Por isso, caso você use este sistema, restrinja o acesso ao diretório admin (veja este exemplo: http://usedbooksnewgifts.com/admin )
Abraços e até a próxima
Wednesday, July 20, 2011
Local File Inclusion
Semana passada um colega me pediu para testar o sistema web que ele desenvolveu. Então testei e, entre as vulnerabilidades que encontrei, tinha uma chamada Local File Inclusion (ou LFI).
Local File Inclusion é uma vulnerabilidade que permite “incluir” arquivos que serão incorporados à página. Caso o arquivo incluído contenha algum código, este código será executado.
Então mostrei para ele que com esta falha eu poderia ler o arquivo de senha do sistema (/etc/passwd), saber os grupos do sistema (/etc/group), etc.
Este meu colega ignorou a vulnerabilidade e me disse o seguinte: Rafael, não considero esta vulnerabilidade grave porque o invasor não poderia escrever nada no sistema e nem executar comandos. Sobre o acesso ao passwd, nos sistemas unixes de hoje, as senhas estão no arquivo shadow. Este arquivo só pode ser visualizado pelo usuário root. Então para mim não é algo grave.
Eu concordo com ele em alguns pontos. Se você, leitor deste blog, buscar no google por Local File Inclusion, 90% dos exemplos exibirão o invasor visualizando o arquivo passwd. E a visualização deste arquivo só mostrará usuários existentes naquele sistema. Então o invasor poderia tentar um ataque de força bruta para descobrir a senha de algum dos usuários. Muitos administradores já tremeriam por expor o arquivo passwd. Mas como meu colega disse, o invasor não conseguiria visualizar nenhuma senha porque estas estão contidas no arquivo shadow, não passwd. Mas isto não é o perigoso desta vulnerabilidade. O perigo está na exploração avançada. Vou explicar como um verdadeiro hacker conseguiria acesso ao seu servidor somente usando esta vulnerabilidade.
Preparação
Para acompanhar este post, é necessário que se tenha o básico de conhecimentos de PHP, Apache e Linux.
1. Arquivos de teste
Para demonstrar como funciona esta vulnerabilidade, criei dois arquivos no diretório de arquivos públicos do meu apache (/var/www). O arquivo teste.php tem o seguinte código:
O outro arquivo, 1.php, contêm o seguinte código:
< ? php echo('teste'); ? >
2. Iniciei meu navegador e visualizei o conteúdo de teste.php?page=1.php. Com isto vemos que o código de 1.php é executado.
3. Para ver se a aplicação é vulnerável a LFI, testamos a seguinte URL: teste.php?page=../../../../../../../etc/passwd
Arquivos de logs e outros “controlados” pelo invasor.
O que muitos administradores ignoram é que existem arquivos do servidor que são parcialmente controlados pelo invasor. Como assim?
Por exemplo, o arquivos access.log do apache tem entradas com dados de cada requisição feita ao servidor. As seguintes informações estão neste log por default: IP de quem fez a requisição, dia e hora, arquivo solicitado (index.html, teste.php, favicon.ico, etc), User-Agent do usuário, etc.
Percebe que se o invasor fizer uma requisição chamando http://alvo/.php, o servidor retornará um erro 404 (página não encontrada), mas o código irá para o arquivo de log de qualquer forma? Se o usuário trocar o User-Agent dele por , o código novamente irá para o arquivo de log. Se o invasor usar funções como system, exec, passthru, etc, ele conseguira executar comandos diretamente no servidor!!!!
Existem diversos outros arquivos controlados parcialmente pelo invasor. Logs, /proc/self/environ, e qualquer outra coisa gerada pelo servidor com dados fornecidos (diretamente ou indiretamente) pelo atacante.
Finalizando
Para finalizar este post, deixo um vídeo de como seria um ataque completo de Local File Inclusion. Isto tudo foi feito no meu laboratório de testes caseiro. Nunca testei isto em websites e sistemas reais por aí sem a devida permissão. Então se você, leitor, quiser testar esta vulnerabilidade, virtualize um servidor para isso! ;)
Abraços a todos e até a próxima!
Local File Inclusion é uma vulnerabilidade que permite “incluir” arquivos que serão incorporados à página. Caso o arquivo incluído contenha algum código, este código será executado.
Então mostrei para ele que com esta falha eu poderia ler o arquivo de senha do sistema (/etc/passwd), saber os grupos do sistema (/etc/group), etc.
Este meu colega ignorou a vulnerabilidade e me disse o seguinte: Rafael, não considero esta vulnerabilidade grave porque o invasor não poderia escrever nada no sistema e nem executar comandos. Sobre o acesso ao passwd, nos sistemas unixes de hoje, as senhas estão no arquivo shadow. Este arquivo só pode ser visualizado pelo usuário root. Então para mim não é algo grave.
Eu concordo com ele em alguns pontos. Se você, leitor deste blog, buscar no google por Local File Inclusion, 90% dos exemplos exibirão o invasor visualizando o arquivo passwd. E a visualização deste arquivo só mostrará usuários existentes naquele sistema. Então o invasor poderia tentar um ataque de força bruta para descobrir a senha de algum dos usuários. Muitos administradores já tremeriam por expor o arquivo passwd. Mas como meu colega disse, o invasor não conseguiria visualizar nenhuma senha porque estas estão contidas no arquivo shadow, não passwd. Mas isto não é o perigoso desta vulnerabilidade. O perigo está na exploração avançada. Vou explicar como um verdadeiro hacker conseguiria acesso ao seu servidor somente usando esta vulnerabilidade.
Preparação
Para acompanhar este post, é necessário que se tenha o básico de conhecimentos de PHP, Apache e Linux.
1. Arquivos de teste
Para demonstrar como funciona esta vulnerabilidade, criei dois arquivos no diretório de arquivos públicos do meu apache (/var/www). O arquivo teste.php tem o seguinte código:
Este eh o conteudo de teste.php
< ? php if (isset($_GET['page'])){ echo(" Conteudo da pagina: ".$_GET['page']." "); include($_GET['page']); } else{ echo("Parametro 'page' nao foi passado"); } ?>O outro arquivo, 1.php, contêm o seguinte código:
< ? php echo('teste'); ? >
2. Iniciei meu navegador e visualizei o conteúdo de teste.php?page=1.php. Com isto vemos que o código de 1.php é executado.
3. Para ver se a aplicação é vulnerável a LFI, testamos a seguinte URL: teste.php?page=../../../../../../../etc/passwd
Arquivos de logs e outros “controlados” pelo invasor.
O que muitos administradores ignoram é que existem arquivos do servidor que são parcialmente controlados pelo invasor. Como assim?
Por exemplo, o arquivos access.log do apache tem entradas com dados de cada requisição feita ao servidor. As seguintes informações estão neste log por default: IP de quem fez a requisição, dia e hora, arquivo solicitado (index.html, teste.php, favicon.ico, etc), User-Agent do usuário, etc.
Percebe que se o invasor fizer uma requisição chamando http://alvo/.php, o servidor retornará um erro 404 (página não encontrada), mas o código irá para o arquivo de log de qualquer forma? Se o usuário trocar o User-Agent dele por , o código novamente irá para o arquivo de log. Se o invasor usar funções como system, exec, passthru, etc, ele conseguira executar comandos diretamente no servidor!!!!
Existem diversos outros arquivos controlados parcialmente pelo invasor. Logs, /proc/self/environ, e qualquer outra coisa gerada pelo servidor com dados fornecidos (diretamente ou indiretamente) pelo atacante.
Finalizando
Para finalizar este post, deixo um vídeo de como seria um ataque completo de Local File Inclusion. Isto tudo foi feito no meu laboratório de testes caseiro. Nunca testei isto em websites e sistemas reais por aí sem a devida permissão. Então se você, leitor, quiser testar esta vulnerabilidade, virtualize um servidor para isso! ;)
Abraços a todos e até a próxima!
Subscribe to:
Posts (Atom)