Mesmo que você tenha seguido vagamente os eventos dos grupos de hackers Anonymous e LulzSec, provavelmente já ouviu falar sobre sites e serviços sendo hackeados, como os infames hacks da Sony. Você já se perguntou como eles fazem isso?
Existem várias ferramentas e técnicas que esses grupos usam e, embora não estejamos tentando fornecer um manual para fazer isso sozinho, é útil entender o que está acontecendo. Dois dos ataques que você ouve constantemente sobre eles usarem são “Negação de Serviço (Distribuída)” (DDoS) e “Injeções de SQL” (SQLI). Veja como eles funcionam.
Imagem por xkcd
Índice
Ataque de negação de serviço
O que é isso?
Um ataque de “negação de serviço” (às vezes chamado de “negação de serviço distribuída” ou DDoS) ocorre quando um sistema, neste caso um servidor web, recebe tantos pedidos de uma só vez que os recursos do servidor ficam sobrecarregados e o sistema simplesmente trava e desliga. O objetivo e o resultado de um ataque DDoS bem-sucedido são os sites no servidor de destino indisponíveis para solicitações de tráfego legítimas.
Como funciona?
A logística de um ataque DDoS pode ser melhor explicada por um exemplo.
Imagine um milhão de pessoas (os invasores) se reunindo com o objetivo de prejudicar os negócios da Empresa X derrubando seu call center. Os atacantes se coordenam para que na terça-feira, às 9h, liguem para o número de telefone da Empresa X. Muito provavelmente, o sistema telefônico da Empresa X não será capaz de lidar com um milhão de chamadas de uma vez, então todas as linhas de entrada serão ocupadas pelos invasores. O resultado é que chamadas legítimas de clientes (ou seja, aqueles que não são os invasores) não são atendidas porque o sistema telefônico está ocupado com as chamadas dos invasores. Portanto, em essência, a Empresa X está potencialmente perdendo negócios devido à impossibilidade de atender às solicitações legítimas.
Um ataque DDoS em um servidor web funciona exatamente da mesma maneira. Como não há praticamente nenhuma maneira de saber qual tráfego é originado de solicitações legítimas versus invasores até que o servidor da Web esteja processando a solicitação, esse tipo de ataque é normalmente muito eficaz.
Executando o ataque
Devido à natureza de “força bruta” de um ataque DDoS, você precisa ter vários computadores coordenados para atacar ao mesmo tempo. Revisitando nosso exemplo de central de atendimento, isso exigiria que todos os invasores soubessem que ligariam às 9h e realmente ligassem naquele horário. Embora esse princípio certamente funcione quando se trata de atacar um servidor web, torna-se significativamente mais fácil quando computadores zumbis, em vez de computadores reais, são utilizados.
Como você provavelmente sabe, existem muitas variantes de malware e trojans que, uma vez em seu sistema, ficam dormentes e ocasionalmente “ligam para casa” para obter instruções. Uma dessas instruções poderia ser, por exemplo, enviar solicitações repetidas ao servidor da Web da Empresa X às 9h. Portanto, com uma única atualização do local inicial do respectivo malware, um único invasor pode coordenar instantaneamente centenas de milhares de computadores comprometidos para realizar um ataque DDoS massivo.
A beleza de utilizar computadores zumbis não está apenas em sua eficácia, mas também em seu anonimato, já que o invasor não precisa realmente usar seu computador para executar o ataque.
Ataque de injeção SQL
O que é isso?
Um ataque de “injeção de SQL” (SQLI) é uma exploração que tira proveito de técnicas inadequadas de desenvolvimento da web e, normalmente combinada com segurança de banco de dados defeituosa. O resultado de um ataque bem-sucedido pode variar desde a representação de uma conta de usuário até o comprometimento total do respectivo banco de dados ou servidor. Ao contrário de um ataque DDoS, um ataque SQLI é completa e facilmente evitável se um aplicativo da web for programado de forma adequada.
Executando o ataque
Sempre que você fizer login em um site e inserir seu nome de usuário e senha, para testar suas credenciais, o aplicativo da web pode executar uma consulta como a seguinte:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Nota: os valores de string em uma consulta SQL devem ser colocados entre aspas simples, por isso aparecem ao redor dos valores inseridos pelo usuário.
Portanto, a combinação do nome de usuário inserido (myuser) e senha (mypass) deve corresponder a uma entrada na tabela Usuários para que um ID de usuário seja retornado. Se não houver correspondência, nenhum ID de usuário será retornado, portanto, as credenciais de login são inválidas. Embora uma implementação específica possa ser diferente, a mecânica é bastante normal.
Então, agora vamos olhar para uma consulta de autenticação de modelo que podemos substituir os valores que o usuário insere no formulário da web:
SELECIONE A ID do usuário A PARTIR dos usuários ONDE Nome do usuário = ‘[usuário]’ E senha = ‘[senha]’
À primeira vista, isso pode parecer uma etapa simples e lógica para validar facilmente os usuários; no entanto, se uma substituição simples dos valores inseridos pelo usuário for realizada neste modelo, ele estará suscetível a um ataque SQLI.
Por exemplo, suponha que “myuser’–” seja inserido no campo de nome do usuário e “wrongpass” seja inserido na senha. Usando a substituição simples em nossa consulta de modelo, obteríamos isto:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Uma chave para esta afirmação é a inclusão dos dois travessões (--). Este é o token de comentário inicial para instruções SQL, portanto, qualquer coisa que apareça após os dois travessões (inclusive) será ignorado. Essencialmente, a consulta acima é executada pelo banco de dados como:
SELECT UserID FROM Users WHERE UserName='myuser'
A omissão gritante aqui é a falta de verificação de senha. Ao incluir os dois travessões como parte do campo do usuário, ignoramos completamente a condição de verificação de senha e pudemos fazer o login como “meu usuário” sem saber a respectiva senha. Este ato de manipular a consulta para produzir resultados indesejados é um ataque de injeção de SQL.
Que dano pode ser feito?
Um ataque de injeção de SQL é causado por uma codificação de aplicativo negligente e irresponsável e é completamente evitável (o que abordaremos em um momento), porém a extensão do dano que pode ser feito depende da configuração do banco de dados. Para que um aplicativo da web se comunique com o banco de dados de back-end, o aplicativo deve fornecer um login para o banco de dados (observe que isso é diferente de um login de usuário no próprio site). Dependendo de quais permissões o aplicativo da web requer, esta respectiva conta de banco de dados pode exigir qualquer coisa, desde permissão de leitura / gravação em tabelas existentes até acesso total ao banco de dados. Se isso não estiver claro agora, alguns exemplos devem ajudar a esclarecer.
Com base no exemplo acima, você pode ver que inserindo, por exemplo, "youruser'--", "admin'--"ou qualquer outro nome de usuário, podemos fazer login instantaneamente no site como esse usuário, sem saber a senha. Assim que entrarmos no sistema, não saberemos que não somos realmente esse usuário, então temos acesso total à respectiva conta. As permissões de banco de dados não fornecerão uma rede de segurança para isso porque, normalmente, um site deve ter pelo menos acesso de leitura / gravação ao seu respectivo banco de dados.
Agora, vamos supor que o site tenha controle total de seu respectivo banco de dados, o que permite excluir registros, adicionar / remover tabelas, adicionar novas contas de segurança, etc. É importante notar que alguns aplicativos da web podem precisar desse tipo de permissão. não é automaticamente uma coisa ruim que o controle total seja concedido.
Portanto, para ilustrar o dano que pode ser feito nesta situação, usaremos o exemplo fornecido na história em quadrinhos acima, inserindo o seguinte no campo de nome de usuário: "Robert'; DROP TABLE Users;--".Após a substituição simples, a consulta de autenticação torna-se:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Nota: o ponto-e-vírgula em uma consulta SQL é usado para significar o fim de uma instrução específica e o início de uma nova instrução.
Que é executado pelo banco de dados como:
SELECT UserID FROM Users WHERE UserName='Robert'Usuários DROP TABLE
Assim, usamos um ataque SQLI para excluir toda a tabela de usuários.
Claro, muito pior pode ser feito, pois, dependendo das permissões SQL permitidas, o invasor pode alterar valores, despejar tabelas (ou todo o banco de dados) em um arquivo de texto, criar novas contas de login ou até mesmo sequestrar a instalação inteira do banco de dados.
Prevenir um ataque de injeção de SQL
Como mencionamos várias vezes anteriormente, um ataque de injeção de SQL é facilmente evitável. Uma das regras principais do desenvolvimento da web é que você nunca confia cegamente na entrada do usuário, como fizemos quando executamos a substituição simples em nossa consulta de modelo acima.
Um ataque SQLI é facilmente frustrado pelo que é chamado de sanitização (ou escape) de suas entradas. O processo de sanitização é na verdade bastante trivial, pois tudo o que ele essencialmente faz é lidar com quaisquer caracteres de aspas simples (‘) in-line de forma apropriada, de modo que eles não possam ser usados para encerrar prematuramente uma string dentro de uma instrução SQL.
Por exemplo, se você quiser pesquisar “O’Neil” em um banco de dados, não poderá usar a substituição simples porque a aspa simples após o O faria com que a string terminasse prematuramente. Em vez disso, você o limpa usando o caractere de escape do respectivo banco de dados. Vamos supor que o caractere de escape para uma aspa simples embutida precede cada aspas com um símbolo \. Portanto, “O’neal” seria higienizado como “O \ ‘neil”.
Este simples ato de limpeza praticamente impede um ataque SQLI. Para ilustrar, vamos revisitar nossos exemplos anteriores e ver as consultas resultantes quando a entrada do usuário é limpa.
myuser'--/ wrongpass :
SELECT UserID FROM Users WHERE UserName='myuser\'--' AND Password='wrongpass'
Como a aspa simples após myuser é escapada (o que significa que é considerada parte do valor de destino), o banco de dados irá literalmente procurar pelo UserName de "myuser'--".Além disso, porque os travessões estão incluídos no valor da string e não na própria instrução SQL, eles serão considerado parte do valor de destino em vez de ser interpretado como um comentário SQL.
Robert'; DROP TABLE Users;--/ wrongpass :
SELECT UserID FROM Users WHERE UserName='Robert\'; DROP TABLE Users;--' AND Password='wrongpass'
Simplesmente escapando da aspa simples após Robert, o ponto-e-vírgula e os travessões estão contidos na string de pesquisa UserName, de modo que o banco de dados irá literalmente pesquisar em "Robert'; DROP TABLE Users;--"vez de executar a exclusão da tabela.
Em suma
Enquanto os ataques da web evoluem e se tornam mais sofisticados ou se concentram em um ponto de entrada diferente, é importante lembrar de se proteger contra ataques comprovados e verdadeiros que foram a inspiração de várias “ferramentas de hacker” disponíveis gratuitamente projetadas para explorá-los.
Certos tipos de ataques, como DDoS, não podem ser facilmente evitados, enquanto outros, como SQLI, podem. No entanto, os danos que podem ser causados por esses tipos de ataques podem variar de inconvenientes a catastróficos, dependendo das precauções tomadas.
