Resultados de pesquisa para: "deface"

Defaces podem causar danos maiores

Defaces podem causar danos maiores

Muitos responsáveis por sites portugueses e brasileiros ignoram alertas que o site está desfigurado (defaced) ou a propagar malware. Isto é uma situação que tenho reparado nestes últimos anos.
Por vezes simplesmente repõem ou colocam novamente a página original e esquecem-se de analisar e corrigir a vulnerabilidade que originou o deface. Alguns por pouco conhecimento técnico, outros por puro comodismo.
De fato, maioria dos defacers apenas querem aumentar o seu rank em tabelas ou propagar mensagens políticas.
Mas esta situação está a mudar… para pior.

Alguns defacers de topo (presentes no TOP 20 do ranking do Zone-H.org), estão a começar a colocar backdoors no site. Adicionam exploit kits para infetar utilizadores e roubar informação confidencial.
Após monitorizar algumas contas Twitter e canais de conversação no IRC destes defacers foi possível concluir que, estes grupos trocam acessos de servidores e, dependendo da vítima, vendem informação.

Defaces podem causar danos maiores

Defaces podem causar danos maiores

Defaces podem causar danos maiores

Entre os alvos favoritos, encontram-se diversos sites governamentais e outros de grande tráfego.

Outros grupos de utilizadores maliciosos preferem seguir listas de mirroring de defaces, não para re-deface mas sim para colocar malware. Escolhem principalmente sites Joomla 1.5 vulneráveis e fazem o upload de shells. Alguns ainda tentam correr exploits locais para conseguir obter o acesso root ou admin dos servidores.

Um dos utilizadores do WebSegura.net teve recentemente o seu site comprometido e requisitou a minha colaboração para averiguar qual foi a falha que permitiu a entrada dos defacers. No public_html foi possível encontrar diversos ficheiros index com defaces de grupos diferentes. Ou seja, foi alvo de deface por diversas vezes.
Numa breve análise nos logs, e após verificação de um scan automático a componentes vulneráveis do Joomla, foi possível verificar que a vulnerabilidade estava presente num componente nativo do Joomla 1.5! que permitia o upload de ficheiros remotamente. Trata-se de uma falha pública e com exploit disponível para o público em geral.
Este ataque permite aos utilizadores maliciosos fazer o upload de um PHP shell e explorar a conta local no servidor alheio.

O backdoor é colocado em diversos locais. No COPYRIGHT.PHP (porque é um ficheiro que pode passar por despercebido porque faz parte dos Joomla) e nos ficheiros index.php|html.
Alguns dos backdoors encontrados foram:

  • Web Shell By Black-ID ,based On Php,Ajax Posts,Css3 (que após descodificação fica assim)
  • WeBaCoo (um backdoor que tem uma baixa taxa de detecção por parte dos antivirus, NIDS, IDS, WAF, etc.)

Em algumas referências nas redes sociais é possível também concluir que muitos defacers apoiam causas como os Anonymous e Wikileaks, e fornecem alguma informação comprometida para essas entidades. Como referi acima, a criação de botnets também permite disponibilizar armas para lançar ataques DDoS - um dos ataques típicos dos Anonymous.

O que de fato parece ser um inofensivo deface, pode ser o inicio de um grande ataque que pode infectar milhões de utilizadores.

É uma prioridade, em caso de deface de site ou site comprometido, analisar exaustivamente a segurança do mesmo. Imaginem a informação confidencial em mãos erradas…

Programas responsáveis de divulgação de vulnerabilidades - A continuação…

hammer

Dando continuidade ao tema referido no artigo sobre a possibilidade de um programa de divulgação de vulnerabilidades em Portugal, questionei Sérgio Silva, do Conselho Superior da Magistratura, sobre a opinião e o seu ponto de vista legal destes programas.

Que funções desempenha atualmente no Conselho Superior da Magistratura?

Coordenador da Unidade de Informática do Conselho Superior da Magistratura.

Qual é a sua opinião em relação aos programas responsáveis de divulgação de vulnerabilidades em Portugal?

Tendo em conta o panorama actual da segurança informática em Portugal associado à fraca consciencialização para esta temática este tipo de programas serão muito complicados de implementar . As empresas/entidades não reagem bem a possíveis alertas sobre falhas nos seus sistemas e muitas vezes quem faz o aviso fica com uma serie de problemas.

Numa conversa anterior, referiu que, mesmo que a empresa com estes programas, contratualizar quem testa as vulnerabilidades, é difícil diferenciar o que entra no programa e um possível ataque real. Existem soluções para este tipo de problema?

É uma questão muito complicada dado que quem testa pode sempre tornar-se num atacante real. A solução passaria por uma credenciação de quem poderia aderir a esse programa, ou seja a criação de uma comunidade portuguesa devidamente identificada que estaria autorizada a fazer os testes de vulnerabilidades das empresas que tivessem integradas em programas responsáveis de divulgação de vulnerabilidades em Portugal.

A atual lei portuguesa não prejudica a comunidade infosec?

A legislação Portuguesa, Lei n.º 109/2009 de 15 de Setembro, em matéria de Cibercrime é das mais completas e avançadas a nível europeu, basicamente todos as técnicas usadas pela comunidade infosec podem ser tipificadas nos vários artigos da referida lei .
O simples facto de alterar uma url de forma a produzir um erro, como por exemplo uma falha de SQL , pode ser considerada como tentativa de acesso ilegítimo e punida com pena de prisão até 1 ano ou com pena de multa até 120 dias.
No entanto e como é referido no nº6 no artigo 6.º da Lei n.º 109/2009 o procedimento penal depende de queixa, ou seja quando alguém da comunidade infosec descobre uma vulnerabilidade e a reporta corre o risco de que a entidade a quem reporta o erro fazer queixa.
A lei Portuguesa não prejudica em nada a comunidade infosec, o que prejudica é mais uma vez a falta de consciencialização dos “donos dos sistemas”, o investimento em segurança informática é muito diminuto e muitas vezes nulo, Portugal ainda não despertou em termos de Ciber Segurança e isso sim prejudica a comunidade infosec.

Para terminar, qual a sua opinião em relação à segurança dos sites governamentais. São constantes os sites desfigurados a várias entidades do governo. Será que não estamos todos em risco?

Penso que não existe uma grande diferença entre sites desfigurados governamentais e empresariais, o que difere é que um defacement num site governamental tem sempre mais impacto nos media do que num site empresarial.
Do meu ponto de visa as razões que levam a que este tipo de ataque tenha sucesso prende-se com o facto de que pura e simplesmente as plataformas são postas online e depois não existem procedimentos de monitorização ou de actualizações dos sistemas, quase nunca estão previstas nos contratos.
Actualmente é possível ver sites com vulnerabilidades que foram descobertas à mais de 3 anos e que já deviam ter sido corrigidas.
Outra questão é que quando se usam plataformas de CMS e é aplicado um template nem sempre se verifica a origem desse template ou se existe algo que possa comprometer o site no código do template.
Respondendo se estamos todos em risco a resposta é sim .
No entanto não tem a ver com sites governamentais onde são feitos defacement, tem sim a ver com a falta de estratégia a nível nacional na área da segurança informática e de um ecossistema de desenvolvimento de sistemas de informação em que a segurança informática não é a base mas sim um acessório.
Basicamente estamos a construir castelos e só no fim é que nos lembramos que deveríamos ter um fosso para impedir o ataque dos inimigos quando na lógica da estratégia defensiva o fosso deveria ser a primeira coisa a ser construída.

Agradeço ao Sérgio a disponibilidade que teve em responder ao WebSegura.net e a esclarecer algumas dúvidas que existiam na comunidade infosec.

Plataforma da Direcção Geral do Ensino Superior comprometida

cet_dges_mctes

O defacer indonésio d3b~X - - continua a fazer das suas em Portugal. Desta vez comprometeu a Plataforma do DGES [Direção Geral do Ensino Superior] - http://www.cet.dges.mctes.pt
Tal como em casos anteriores, o defacer colocou uma imagem gif na raiz do domínio.

http://www.cet.dges.mctes.pt/nyet.gif [Ainda online na altura da publicação deste artigo]

O mirror deste ataque informático já foi indexado pelo Zone-H .

De referir que este site está alojado na FCCN e segundo os dados do site Netcraft, corre o servidor web da Microsoft IIS 6.0.
Apenas verificando o código fonte é também possível verificar que o site foi implementado com o Microsoft Visual Studio .NET.

Sendo uma plataforma privada, apenas acedida via password, fica por saber se o defacer obteve informação confidencial.

Investiguei um pouco mais, baseando-me em alguns registos de sites comprometidos, e reparei que o d3b~X tem um modus operandis muito habitual. Pesquisa por servidores mal configurados que aceitam o método PUT sem qualquer tipo de proteção. Ou seja, a ferramenta deste defacer pesquisa por servidores vulneráveis e faz o seguinte pedido:

PUT /nyet.gif HTTP/1.1″ 200 473 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)”

Se retornar o código HTTP 200, ele faz um novo pedido, mas neste caso GET que é para validar se conseguiu ou não enviar a imagem GIF. Em caso de sucesso, envia provavelmente automaticamente o deface para o Zone-H.

GET /nyet.gif HTTP/1.1″ 200 2357 “-” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)”

Caso o pedido PUT dê erro HTTP 404, um scan automático é utilizado para procurar outras vulnerabilidades, na maior parte, plugins vulneráveis do CMS Joomla!.

Atualização:
No mês de janeiro, ainda não terminado, o PUT /nyet.gif apareceu nos logs de um site Joomla! de um cliente cerca de 41 vezes com 38 endereços de IP diferentes [máquinas comprometidas ou proxies].
A última entrada, dia 29 de janeiro, é possível verificar que a ferramenta automática tenta encontrar vulnerabilidades conhecidas no Joomla! [exemplo: com_jce] e só depois é que tenta verificar se é possível usar o método PUT.

87.230.19.16 - - [29/Jan/2015:12:33:19 +0000] “GET /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form
&action=upload HTTP/1.1″ 200 22 “-” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)”
87.230.19.16 - - [29/Jan/2015:12:33:19 +0000] “GET /index.php?option=com_media&view=images&tmpl=component&e_name=jform_articletext&
asset=com_content&author= HTTP/1.1″ 404 - “-” “curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3″
87.230.19.16 - - [29/Jan/2015:12:33:19 +0000] “POST /index.php?option=com_jdownloads&Itemid=0&view=upload HTTP/1.1″ 404 - “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)”
87.230.19.16 - - [29/Jan/2015:12:33:19 +0000] “GET /images/jdownloads/screenshots/nyet.gif HTTP/1.1″ 404 - “-” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)”
87.230.19.16 - - [29/Jan/2015:12:33:19 +0000] “PUT /nyet.gif HTTP/1.1″ 404 - “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)”
87.230.19.16 - - [29/Jan/2015:12:33:22 +0000] “GET /nyet.gif HTTP/1.1″ 404 - “-” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)”
87.230.19.16 - - [29/Jan/2015:12:33:22 +0000] “GET /oipm//index.php HTTP/1.1″ 404 1437 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko)”
87.230.19.16 - - [29/Jan/2015:12:33:22 +0000] “PUT /nyet.gif HTTP/1.1″ 404 - “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)”
87.230.19.16 - - [29/Jan/2015:12:33:25 +0000] “GET /nyet.gif HTTP/1.1″ 404 - “-” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)”

Um ponto curioso, é que posteriormente a estes varrimentos nos sites, muitos outros utilizadores maliciosos poderão utilizar a mesma falha para proveito próprio e ter acesso a informação confidencial. É bastante comum haver este tipo de atividade.

Desconheço se foi este o método utilizado para atacar este site governamental mas quem sabe…

Site da União Geral de Trabalhadores comprometido

hacked cover

Como já havia sido publicado no blogue, alguns sites portugueses são alvos de ataques informáticos por parte de um pirata, desta vez foi o site da União Geral de Trabalhadores (http://www.ugt.pt) que sofreu não um deface na pagina inicial mas uma assinatura na forma de imagem pelo hacker d3b~X.
Pode ser visto no mirror do zone-h (http://zone-h.org/mirror/id/23551669)

A imagem e a respectiva mensagem:

d3bx logo

Até a data deste artigo a imagem ainda permanece alojada no site, ainda não houve qualquer informação do sucedido nem a forma de como foi possível o upload por parte da gestão do site.

Relembro mais uma vez a importância de investir na segurança informática, de forma a preservar a integridade dos sistemas e dos dados que neles estão alojados.

Ars Technica comprometida

arstechnica

Quem é subscritor deste portal noticioso - Ars Technica - deverá mudar a sua password assim que possível.

Aparentemente um intruso conseguiu aceder a um dos servidores web da Ars e durante uma hora tentou aceder a outras máquinas. Segundo nota oficial, o intruso conseguiu acesso à informação confidencial graças a um ficheiro backup disponível num dos servidores. No dia seguinte, o utilizador malicioso fez o deface da página da Ars Technica.

Durou apenas 15 minutos até a equipa técnica da Ars conseguir tomar as medidas necessárias para prevenir que tal situação ocorra novamente. Mudaram passwords internas, certificados e melhoraram o infra-estrutura de segurança.

Os registos de acesso mostram que o intruso poderá ter copiado a base de dados dos utilizadores. Essa base de dados contêm emails e passwords. Não contém qualquer informação de pagamentos. Convém referir também que essas passwords estão cifradas. No entanto, é sempre recomendado a mudança dos dados de autenticação.