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
3 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
Infelizmente, vivemos em uma sociedade individual muito mais preocupada consigo mesmo do que com o próximo. É até uma questão filosófica do ponto de vista da integridade de pessoas/processo/tecnologia do brasileiro.
Mesmo com esses ” escândalos”, como também aconteceu com o Speedy, o brasileiro prefere pagar pra ver, ou achar que sabe fazer do que investir em soluções adequadas.
Durante meus projetos, já vi “n” casos de empresas detalhando dentro do robots.txt áreas privilegiadas do site e também sistemas, inclusive com endereços internos, mesmo quando essa área do site é não-indexável por qq questão.
Esses fatos mostram que as pessoas acabam utilizando a tecnologia de forma inadequada, por conta de um processo/procedimento mal definido. E onde está o problema??
Falando do apagão: supondo que a distribuição de energia pela Itaipu fosse acionada por um sistema Web, exposto na Internet e esse sistema não tivesse qualquer controle de acesso de origem como podemos observar que é possível acessar, e outros controles de segurança da aplicação (autenticação, autorização, etc) sem o devido nível de segurança, concordo que teríamos um problema!…
Voltando pro mundo real, fica claro perceber a ausência não só de controles, mas principalmente de CULTURA e CONSCIÊNCIA sobre Segurança da Informação. E quanto ao apagão, infelizmente acho que não precisamos muito para deduzir que:
Sim, temos um BIG problema!
E se colocássemos ao invés de uma simples aspas simples um valor como ‘ — e em vez do erro resultar na mensagem “Usuário inválido”? Com isto é possível considerar que existe uma falha?
Não tem como baseado no “Usuário Invalido” falar se existe algo ou não. Com certeza técnicas de fuzzing numa aplicação que possivelmente foi protegida com blacklist você poderá ou não encontrar algo mas como salientei se você faz os testes, confirma algo será considerado culpado . Infelizmente não temos permissão pra executar testes na ONS.