Problema:
Esse tipo de ataque tem um número grande de coincidencias que apontão para a mesma fonte.
Com essa informação em mãos, a resolução deveria ser simples.
Com o seu site atacado por SQL-Injection como você pode identificar, analizar, recuperar e resolver o problema? E o que você pode aprender com isso?

Solução:
Como ponto de referencia, SQL-Injection é um exploit onde comandos SQL são passados para o servidor de SQL de uma forma maliciosa.
Analisando a situação, podemos chegar em 4 componentes básicos:
1º Identificação do Problema;
2º Análise da situação para determinar a causa raiz tão como opções de saída para recuperação e solução, que é seguido por recuperar os dados e prevenir por um problema futuro.
3º Plano de comunicação
4º Como resolver o incidente caso ocorra novamente.

Vamos por partes…

Identificar:

Usualmente os usuários ou clientes reportão o caso para o time de TI.
Com o problema detectado a análise precisa ser conduzida nesses passos:
– Logs do Firewall
– logs do IIS
– Páginas Web
– Tabelas do SQL Server

Em termos de exemplificação de código, strings são passadas para o SQL Server. Após ver o código, um simples cursor para atualizar colunas varchar, nvarchar, text ou ntext pode ser inserido através da URL ou através da própria página.

Algumas referencias:

* Http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx#attack-description
* http://www.theregister.co.uk/2008/08/07/new_sql_attacks/
* http://isc.sans.org/diary.html?storyid=4840

Analise

Após rever os Logs do IIS é possível traduzir o código, mas se você tiver uma ferramenta de Performance Monitor, ela pode capturar longos tempos de execução de SQL que podem prover grande ajuda para identificar apartir de qual página foi feita a invasão.
Se você não possuir, terá que gastar um bom tempo para identificar por onde veio a invasão.
Uma vez que a string foi determinada esses 2 scripts podem lhe oferecer um grande auxilio para identificar as colunas que foram alteradas e/ou recuperar:

sp_LocalizaTexto

sp_TrocaTexto

Um método simples para identificar se seu site foi infectado é usando o google para rodar a seguinte query:
* Esse método foi passado pela SANs (http://isc.sans.org/diary.html?storyid=4840)

site:seu_site “script scr=http://*/””ngg.js”|”js.js”|”b.js”

Recuperando:

Existem algumas formas de recuperar os dados alterados
– Backup\Restore
Pro: Se você possui um método de recuperar os dados rapidamente e você sabe exatamente quando os dados foram infectados, pode ser uma forma rápida e simples para recuperar a integridade do site.
Con: Se você não sabe quando os dados foram alterados, você não saberá se o backup foi feito com as informações alteradas ou a janela de perda de dados poderá ser grande.

– Através de análise
Pro: Com o script “sp_TrocaTexto para SQL 2005, a informação maliciosa pode ser identificada e corrigida com confidencialidade.
Con: É interessante efetuar um backup da base de dados antes de executar as alterações para garantir integridade de informações e posterior análise.

Em ambas opções, o problema com o SQL-Injection já deverá ter sido resolvidor.

Resolução:
Possíveis passos para ajudar na solução:
– Desenvolvimento\DBA
– Validar os comandos SQL passados pelo front-end (IIS)
– Validar os dados e os tipos de dados passados
– Converter SQL dinâmico em Stored Procedures com parâmetros
– Remover páginas ou diretórios antigos que pode ser usados como pontos de partida para a invasão
– Prevenir que qualquer comando seja executado em conjunto com os seguintes comandos: ponto e virgura. EXEC, CAST, SET, dois pontos, apostrofe, etc..
– Baseado na linguagem de programação do seu front-end, determinar quais os caracteres especiais podem ser removidos antes de qualquer comando passado para o SQL Server

– Administradores de Rede
– Prevenir trafego de alguns IP´s em particular ou domínios
– Verificar se nas configurações de firewall existe algum item para prevenir quanto a SQL-Injection
– Procurar por produtos ou serviços para analisar seu código e site em busca de erros e prevenção
* http://www.acunetix.com/vulnerability-scanner/
* http://www.rapid7.com/nexpose/web-application-va.jsp
* http://www.fortify.com/products/detect/
* http://www.mcafeesecure.com/us/
* http://www.onlinehackscan.com/default.asp

Plano de comunicação:
O plano de comunicação deve ser atual, claro e importante.
Mantenha isso em mente.
Para muitas pessoas, não saber o que está acontecendo gera desconforto, anciedade, e achar que a equipe de TI não está fazendo seu trabalho.
Comunique sobre a descoberta do ocorrido, informe que o time está trabalhando para determinar a causa e solução do problema e que uma atualização desse status será repassada em até 4 horas;
Comunique o ocorrido, os passos tomados pela equipe de TI para resolver o problema e que a solução estará implantada em até 30 minutos;
e por final comunique que o incidente foi sanado, os passos para resolver o incidente e os passos futuros para prevenir novos problemas.

Recuperação Rápida:

Uma forma de recuperação rápida seria:
– Parar os serviços de Web
– Rever os logs do IIS para determinar os comandos utilizados para lozalizar a vulnerabilidade
– Converter o código para determinar quais tabelas foram alteradas
– Localizar e alterar as strings nas tabelas
– Corrigir as páginas/comandos que possuiam as vulnerabilidades
– Testar para identificar se não existem novos problemas
– Atualizar as páginas/ comandos nos servidores de produção
– Iniciar os serviços de web