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
Friday, July 29, 2011
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!
Thursday, July 14, 2011
Microsoft.com.br hackeada
Uma notícia que caiu como uma bomba para todos os entusiastas de segurança da informação: o domínio principal da Microsoft Brasil foi hackeada.
O grupo que conseguiu este feito? TurkGuvenligi
Este grupo tem em seu curriculum uma grande lista de sites famosos. Alguns sites que eles hackearam foram: www.microsoft.com.br, brasil.microsoft.com.br, www.bancopopolare.it, www.secunia.com (site de segurança reconhecido mundialmente), www.victoriabeckham.com, etc.
Para a lista completa de sites que este grupo hackeou, acesse http://www.zone-h.org/archive/notifier=turkguvenligi.info
Mas uma pergunta que muitos tem feito é: Como eles conseguiram isto?
O Zone-h.com.br entrou em contato com o grupo e fez este questionamento a eles. A resposta é a seguinte:
"Entramos em contato com um dos membros do grupo para obter maiores informações sobre qual tipo de falha foi explorada e para nossa surpresa foi um simples “upload”.
Isto mesmo, deixaram a área do site www.microsoft.com.br/vitrinevisio/ “aberta” para envio de arquivos." (fonte: http://www.zone-h.com.br/news/id/599 )
Desta forma, o grupo simplesmente fez o upload de um shell e teve total controle sobre o servidor.
É... que vacilo Microsoft...
Abraços e até o próximo post
O grupo que conseguiu este feito? TurkGuvenligi
Este grupo tem em seu curriculum uma grande lista de sites famosos. Alguns sites que eles hackearam foram: www.microsoft.com.br, brasil.microsoft.com.br, www.bancopopolare.it, www.secunia.com (site de segurança reconhecido mundialmente), www.victoriabeckham.com, etc.
Para a lista completa de sites que este grupo hackeou, acesse http://www.zone-h.org/archive/notifier=turkguvenligi.info
Mas uma pergunta que muitos tem feito é: Como eles conseguiram isto?
O Zone-h.com.br entrou em contato com o grupo e fez este questionamento a eles. A resposta é a seguinte:
"Entramos em contato com um dos membros do grupo para obter maiores informações sobre qual tipo de falha foi explorada e para nossa surpresa foi um simples “upload”.
Isto mesmo, deixaram a área do site www.microsoft.com.br/vitrinevisio/ “aberta” para envio de arquivos." (fonte: http://www.zone-h.com.br/news/id/599 )
Desta forma, o grupo simplesmente fez o upload de um shell e teve total controle sobre o servidor.
É... que vacilo Microsoft...
Abraços e até o próximo post
Wednesday, July 13, 2011
Bem vindos
Olá. Sejam bem vindos ao meu blog.
Meu nome é Rafael Santana de Sousa e sempre amei a área de segurança exatamente por envolver muita inteligência e perspicácia. Já prestei diversas consultorias, realizei pentests e fiz alguns trabalhos de engenharia reversa também.
Tentarei atualizar este blog com notícias de segurança, técnicas, explicações de vulnerabilidades novas e velhas e alguma coisa de engenharia reversa.
Até o próximo post.
Rafael Sousa
Meu nome é Rafael Santana de Sousa e sempre amei a área de segurança exatamente por envolver muita inteligência e perspicácia. Já prestei diversas consultorias, realizei pentests e fiz alguns trabalhos de engenharia reversa também.
Tentarei atualizar este blog com notícias de segurança, técnicas, explicações de vulnerabilidades novas e velhas e alguma coisa de engenharia reversa.
Até o próximo post.
Rafael Sousa
Subscribe to:
Posts (Atom)