Muito se falou nessa semana sobre os motivos do apagão ocorrido no dia 10 de novembro de 2009. O governo comentou sobre problemas atmosféricos, mas foi muita coincidência o apagão e a matéria do programa 60 minutes da CBS falando que o sistema elétrico brasileiro estaria vulnerável a ataques de hackers.

Para tumultuar ainda mais o assunto, Maycon Vitali, pesquisador de segurança e professor na UVV em Vilha Velha no Espírito Santo, fez um post em seu blog (http://blog.hacknroll.com/2009/11/12/a-verdade-sobre-o-apagao/) demonstrando falhas de segurança web no site do ONS – Operador Nacional do Sistema.

O post obteve dezena de milhares de acessos, sendo muito comentado pela comunidade, postado em grandes mídias como InfoExame, G1, eBand e diversas referências ao post em blogs pessoais e perfis do twitter .

Acreditamos que muitos fizeram análise errada do post bem como um alarde muito grande e desnecessário. Abaixo faremos os comentários sobre o post e sobre algumas interpretações errôneas.

Primeiramente foi comentado do robots.txt no site da ONS.

O que é o robots.txt ?

Como o próprio nome já diz, é um arquivo no formato txt que funciona como um filtro para os Crawlers, fazendo com que webmasters possam controlar permissões de acesso a determinados pontos dos sites. O robots.txt controla qual informação de um site deve ou não deve ser indexado pelos sites de busca. A sintaxe do arquivo é bem simples, e deve ser colocada pelo webmaster responsável pelo site na raíz da hospedagem.

No caso do robots.txt citado ele bloqueia qualquer user-agent que façam crawlers e em dois diretórios

User-agent: *
Disallow: /agentes/agentes.aspx
Disallow: /download/agentes/

Acessando esses diretórios que não deveriam ser indexados pelos buscadores, reparamos nos links para algumas aplicações, tais como Citrix.

Baseado no post o autor diz que tentou acessar uma das aplicações listadas e digitou nos campos de usuário e senha o caractere de aspas simples (‘) que resultou no seguinte:

“[IfxException: ERROR [HY000] [Informix .NET provider]General error.] IBM.Data.Informix.IfxConnection.HandleError(IntPtr hHandle, SQL_HANDLE hType, RETCODE retcode) +27 IBM.Data.Informix.IfxCommand.ExecuteReaderObject(CommandBehavior behavior, String method) +739 IBM.Data.Informix.IfxCommand.ExecuteReader(CommandBehavior behavior) +104 IBM.Data.Informix.IfxCommand.ExecuteReader() +48 OnsClasses.OnsData.OnsCommand.ExecuteReader() IntUnica.Menu.btnOk_Click(Object sender, ImageClickEventArgs e) System.Web.UI.WebControls.ImageButton.OnClick(ImageClickEventArgs e) +109 System.Web.UI.WebControls.ImageButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +69 System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +18 System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33 System.Web.UI.Page.ProcessRequestMain() +1292”

Conforme citei em listas de distribuição e em comentários com amigos; baseado no post e na mensagem de erro NÃO se pode afirmar que existe um SQL Injection na aplicação visto que foi somente um exception que foi impressa na tela, o que caracteriza a seguinte vulnerabilidade de acordo com o Guia TOP 10 do OWASP: A6 – Vazamento de Informações e Tratamento de erros inapropriado. Logicamente se pegarmos estatísticas desse tipo de erro a maioria leva a encontrar SQL Injection, levando em conta que o problema se manifestou num banco de dados Informix. Para descobrir a vulnerabilidade de SQL Injection teriam que ser feitos testes, o que é ilegal visto que não temos autorização para isso.

O que seria uma falha “A6 – Vazamento de Informações e Tratamento de erros inapropriado” ?

Diversas aplicações podem sem intenção vazar informações sobre suas configurações, funcionamento interno, ou violar privacidade através de diversos problemas. Aplicações podem vazar o funcionamento interno via tempo de resposta para executar determinados processos ou respostas diferentes para entradas diversas, como exibindo mesma mensagem de erro mas com código de erros diferentes. Aplicações Web freqüentemente vazarão informações sobre seu duncionamento interno através de mensagens de erros detalhadas ou debug. Freqüentemente, essa informação pode ser o caminho para lançar ataques ou ferramentas automáticas mais poderosas.

Conclusões:

– O acesso ao diretório escondido /agentes não pode ser considerado uma falha, pois o arquivo robots.txt é globalmente utilizado para informações não serem indexadas nos buscadores. Porém, como se trata de aplicações web críticas seria uma melhor prática colocar senha de acesso ao diretório /agentes, e qualquer outro diretório que contenha links para aplicações críticas.

– Um erro de stack ou manipulação inapropriada de erro não quer dizer que o site possui alguma vulnerabilidade de SQL Injection na aplicação, porém nota-se que a mesma não faz sanitização de entrada e saída de dados.

– Não sabemos exatamente o que se encontra dentro das aplicações ou o que ela executa, portanto mesmo se um SQL Injection fosse confirmado, não teríamos certeza qual a relação desse ataque com o apagão.

– Internamente deve existir segmentação, ferramentas de defesa de perímetro, mecanismos mais fortes de autenticação, mas como citado essas informações são baseadas em deduções.

– O governo brasileiro deveria investir mais em segurança web em seus ambientes e logicamente, além de utilizar ferramentas de análise de vulnerabilidades web, também fazer uso de WAF – Web Application Firewall e desenvolver internamente um SDLC – Software Development Life Cycle, com elementos de segurança que envolvam todo o ciclo.

Referências

http://www.seomarketing.com.br/robots.txt.html
http://info.abril.com.br/noticias/seguranca/hacker-aponta-falhas-no-sistema-de-energia-13112009-6.shl
http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf
http://blog.hacknroll.com/2009/11/12/a-verdade-sobre-o-apagao/

N-Stalker Team