Philips investiga possível ataque cracker

Amsterdã – A Philips afirmou nesta terça-feira que desligou um de seus servidores na segunda-feira por causa de uma possível invasão e que estava investigando a natureza e a extensão da informação que teria sido acessada.

O porta-voz da Philips, Steve Klink, não pôde confirmar se qualquer informação pessoal de clientes ou dados sensíveis da companhia foram colocados em risco.

“Não é prudente fazer qualquer comentário até que nós cheguemos ao fundo deste assunto e completemos a investigação”, disse Klink.

O grupo holandês de bens de consumo, iluminação e de produtos de saúde divulgou um curto comunicado em sua página na Internet, afirmando que alguns de seus sites usados para marketing teriam sido atacados na segunda-feira.

A Philips disse que uma hora depois de ter ciência do evento, o servidor comprometido foi desligado.

Fonte.

Série Ataques: Saiba mais sobre os ataques de Injeção de SQL

Sumário: Afinal, o que são ataques de injeção de SQL?

Hoje em dia a maioria das aplicações web corporativas utilizam banco de dados relacionais para  manter dados da empresa e de seus clientes, incluindo informações sensíveis como:

  • Credenciais de acesso e informações pessoais;
  • Catálogo de produtos e serviços;
  • Pedidos, extratos de conta e informações sobre pagamento;
  • Lista de clientes e contatos de fornecedores.

O formato utilizado pela maioria dos aplicativos web para acesso a estes bancos de dados é uma linguagem de consulta desenvolvida nos anos 70 pelos laboratórios da IBM, a linguagem estruturada de consulta ou, structured query language, conhecida pelo acrônimo SQL. Normalmente, os aplicativos incorporam dados fornecidos pelo usuário à linguagem SQL, com o objetivo de construir interações específicas à funcionalidades do sistema e o seu banco de dados.

Se as instruções forem formuladas de maneira insegura, permitindo que o usuário modifique a estrutura geral do pedido de consulta, o aplicativo pode ser vulnerável ao que comumente chamamos de injeção de SQL (SQL injection), ou seja, uma falha que permite que um usuário mal intencionado reprograme a comunicação entre o aplicativo e o banco de dados e, desta forma, obtenha como resultado a manipulação ou extração arbitrária de dados.

Da forma como os aplicativos web se sustentam de maneira exclusiva aos bancos de dados, este tipo de vulnerabilidade pode produzir reflexos em todo o sistema corporativo, facilitando o roubo de credenciais de acesso e informações confidenciais, modificação de processos vitais e até mesmo o comprometimento da operação de negócios.

Tecnicamente, o ataque explora a sintaxe do interpretador do banco de dados SQL, independente da tecnologia, e é normalmente encontrado em todos os tipos de aplicações desenvolvidas para web.

Algumas linguagens de programação como PHP e ASP são mais suscetíveis a este tipo de ataque, contudo, isso não significa que outras linguagens e arcabouços também não possam ser explorados igualmente.

Meu aplicativo está vulnerável ao ataque de SQL Injection ?

Para entender melhor se o seu aplicativo está vulnerável às falhas de injeção SQL, vamos seguir descrevendo a maneira como uma aplicação pode ser explorada a partir da utilização de uma interação com um código que esteja aparentemente funcionado corretamente.

Um atacante inicia seu “trabalho” a partir da análise de alguns pontos específicos do aplicativo:

  • Realização inspeção nos formulários e pontos de entrada de dados do aplicativo que aparentemente não estejam filtrando o uso de meta-caracteres (códigos de erro e mensagem de falha);
  • Realiza testes para construção de pedidos SQL de maneira a contornar eventuais mecanismos de proteção de uso de meta-caracteres;
  • Combina o ataque com a utilização de stored procedures para esconder a injeção de meta-caracters;

Exemplo de ataque:

Inicialmente usaremos uma consulta abaixo para exemplificar a vulnerabilidade. Quando um usuário utiliza o campo de pesquisa para procurar por todos os livros do editor CRAFT, a aplicação executa a seguinte consulta no banco :

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ AND 
publicado=1

Essa consulta obriga o banco de dados verificar cada linha dentro da tabela livros, extrair cada registro em que a coluna editor tenha o conteúdo CRAFT e publicado com o valor 1, e ao término, retornar o conjunto de todos esses registros, publicando o resultado em uma página HTML. Agora o usuário quer fazer uma busca por todos os livros produzidos pela L’CRAFT, isso faz a aplicação executar a seguinte consulta:

 SELECT autor, titulo, ano FROM livros WHERE editor = ‘L'CRAFT’ and publicado=1

O interpretador executa a consulta analisando o que está dentro de aspas simpes, e obtem o valor L, em seguida ele encontra a expressão CRAFT que não é uma sintaxe SQL válida e acaba gerando um erro:

Incorrect syntax near 'CRAFT'.
Server: Msg 105, Level 15, State 1, Line 1
Unclosed quotation mark before the character string '

Esta mensagem de erro indica que a aplicação produziu um comportamento inesperado, ou seja, a estrutura geral do pedido de consulta ao banco de dados, que antes produzia resultados corretos, foi alterada de maneira arbitrária e não pode ser concluída com sucesso.

Se o atacante puder realizar modificações estruturais ao pedido de consulta ao banco de dados para permitir a reprogramação de suas funcionalidades inicial, o aplicativo está vulnerável à injeção de SQL. Um exemplo seria modificar a pesquisa para listar todos os livros disponíveis através do seguinte termo:

CRAFT' OR 1=1--

Portanto, este pedido seria executado desta maneira no banco de dados:

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ OR 1=1--’ and publicado =1

A condição CRAFT’ OR 1=1– faz com que a cláusula WHERE sempre seja avaliado como verdadeiro e ignora o restante da consulta, essa consulta permite ao invasor ignorar a exigência de que a consulta retorne apenas itens de propriedade do usuário autenticado, o banco de dados verifica cada linha na tabela e extrai cada registro onde a coluna publisher tem o valor “CRAFT” ou onde 1 é igual a 1, fazendo com que a consulta agora retorne para aplicação todas as entradas armazenadas na tabela, independentemente do seu proprietário.

A utilização de meta-caracteres que sejam interpretados como comentários, como é o caso da sequência “–“, é frequentemente empregada nos ataques de injeção SQL, pois permite que você ignore o restante da consulta criado pelo desenvolvedor do aplicativo.

Uma forma alternativa é a utilização de aspas sem usar o símbolo de comentário e terminar a injeção inserindo o termo de pesquisa:

CRAFT' OR 'a' = 'a

O resultado produzido seria:

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ OR 'a'='a and publicado=1

Isto é perfeitamente válido e atinge o mesmo resultado que o ataque 1 = 1  que retorna todos os livros  escritos pelo CRAFT.

Sofisticando o ataque

Para coletar informação o atacante pode extrair a versão do banco de dados, que pode ser feito em qualquer DBMS, pode-se extrair a versão do banco de dados injetando a seguinte consulta no MS-SQL e MySQL:

' UNION SELECT @@version,NULL,NULL--

Qual o impacto e as principais consequências do ataque?

Os exemplos acima mostram como um atacante pode contornar a lógica da aplicação e acessar todos os dados do banco, por essa razão, deve ser considerado um ataque de severidade alta. O impacto causado por um ataque bem sucedido de injeção de SQL pode acarretar sérios problemas como:

  • Exposição de dados sensíveis do banco de dados;
  • Exposição da base de dados da empresa para concorrentes;
  • Modificação da base de dados(Insert/Update/Delete);
  • Ganhar acesso arbitrário ao sistema operacional;
  • Ganhar acesso arbitrário à rede;

De maneira prática, as principais consequências constatadas pelos ataques mais recentes de injeção de SQL estão relacionados à reputação da empresa em meio a exposição pela mídia dos acessos não autorizados a dados internos e no valor dos dados afetados, roubados, modificados ou apagados.

Correção de códigos vulneráveis

Uma abordagem tradicional para a prevenção de ataques de injeção é lidar com eles como um problema de validação de entrada e aceitar apenas caracteres (whitelist) de valores seguros ou identificar e escapar (blacklist) de valores potencialmente maliciosos.

Opte sempre por instruções SQL parametrizadas, exigem menos manutenção e pode oferecer mais garantias no que diz respeito à segurança, contramedidas, tais como limitações de privilégio para o servidor de banco de dados e assim por diante. Outros pontos para se verificar são:

  • Inspecionar todos os pontos de entrada para não permitir o uso de meta-caracteres;
  • Caso necessite utilizar meta-caracteres, utilize de mecanismos para protegê-los de maneira correta. Existem diversas funções que realizam o procedimento de escapar caracteres para evitar que eles sejam interpretados de maneira não apropriada pelo aplicativo web.
  • Utilize, quando possível, funções específicas de banco como stored procedures, que apesar de também serem vulneráveis à ataques de injeção de SQL possuem a condição de evitar exposição exagerada da lógica da aplicação e limitar os tipos de parâmetros recebidos do usuário.

Stored procedures podem prevenir alguns tipos de injeção SQL, contudo, não é uma solução definitiva para o problema. Por exemplo, o seguinte trecho de um stored procedure é vulnerável ataque de injeção de SQL:

procedure get_item (
 itm_cv IN OUT ItmCurTyp,
 usr in varchar2,
 itm in varchar2)
 is
 open itm_cv for ' SELECT * FROM items WHERE ' ||
 'owner = '''|| usr ||
 ' AND itemname = ''' || itm || '''';
 end get_item;

Geralmente problemas de injeção de SQL podem ser detectadas de maneira mais eficiente por um profissional de segurança da informação, entretanto, esta atividade também pode ser automatizada por meio de ferramentas que realizem a análise do código-fonte (whitebox) e daquelas que analisam a interface em tempo de execução (blackbox), tais como o N-Stalker.

Exemplo de vídeos de ataque

  • SQL Injection Explained

  • WordPress under SQL Injection Attack!

Como a RedeSegura pode te ajudar?

A RedeSegura possui uma solução completa para gestão de vulnerabilidades em aplicativos web, seja qual for o seu tipo de indústria e tamanho do seu aplicativo. Saiba mais detalhes sobre nossa metodologia:

Contate-nos ainda hoje para obter mais detalhes da nossa solução e como podemos ajudá-lo na missão de manter seus aplicativos web seguros.