Existem várias ferramentas e técnicas que esses grupos usam e, embora não tentemos fornecer um manual para você mesmo, é útil entender o que está acontecendo. Dois dos ataques que você ouviu consistentemente sobre eles usando “Negação de serviço (distribuída)” (DDoS) e “SQL Injections” (SQLI). Veja como eles funcionam.
Imagem por xkcd
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 tantas solicitações de uma só vez que os recursos do servidor estão sobrecarregados que o sistema simplesmente bloqueia e desliga. A meta e o resultado de um ataque DDoS bem-sucedido é que os sites no servidor de destino não estão disponíveis para legitimar solicitações de tráfego.
Como funciona?
A logística de um ataque DDoS pode ser melhor explicada por um exemplo.
Imagine que um milhão de pessoas (os invasores) se juntam com o objetivo de prejudicar os negócios da empresa X derrubando o call center. Os invasores coordenam para que, na terça-feira, às 9 horas, todos eles liguem para o número de telefone da empresa X. Provavelmente, o sistema telefônico da Empresa X não conseguirá lidar com um milhão de chamadas de uma só vez, então todas as linhas de entrada serão amarradas pelos invasores. O resultado é que chamadas de clientes legítimas (ou seja, aquelas que não são os invasores) não passam porque o sistema de telefonia está preso ao tratamento das chamadas dos invasores. Portanto, em essência, a empresa X está potencialmente perdendo negócios devido a solicitações legítimas não serem atendidas.
Um ataque DDoS em um servidor da Web funciona exatamente da mesma maneira. Como praticamente não há como saber qual tráfego é originado de solicitações legítimas vs. invasores até que o servidor da Web esteja processando a solicitação, esse tipo de ataque é geralmente muito eficaz.
Executando o ataque
Devido à natureza de “força bruta” de um ataque DDoS, você precisa ter muitos computadores todos coordenados para atacar ao mesmo tempo. Revisitando o nosso exemplo de call center, isso exigiria que todos os invasores saibam ligar às 9h e realmente liguem naquele momento. Embora este 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 tripulados, são utilizados.
Como você provavelmente sabe, existem muitas variantes de malware e trojans que, uma vez em seu sistema, ficam inativos e ocasionalmente "telefonam para casa" para obter instruções. Uma dessas instruções poderia, por exemplo, enviar solicitações repetidas para o servidor da Web da Empresa X às 9h. Assim, com uma única atualização para o local de origem do respectivo malware, um único invasor pode coordenar instantaneamente centenas de milhares de computadores comprometidos para executar um ataque DDoS em massa.
A beleza de utilizar computadores zumbis não é apenas sua eficácia, mas também seu anonimato, pois o invasor não precisa realmente usar o computador para executar o ataque.
Ataque de injeção de SQL
O que é isso?
Um ataque de “injeção de SQL” (SQLI) é uma exploração que tira proveito de técnicas de desenvolvimento da Web insatisfatórias e, normalmente combinadas com a segurança de banco de dados defeituosa. O resultado de um ataque bem-sucedido pode variar de representar uma conta de usuário a um comprometimento completo do respectivo banco de dados ou servidor. Ao contrário de um ataque DDoS, um ataque SQLI é completamente e facilmente evitável se um aplicativo da Web for adequadamente programado.
Executando o ataque
Sempre que você fizer login em um site e digitar seu nome de usuário e senha, para testar suas credenciais, o aplicativo da Web poderá executar uma consulta como a seguinte:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Nota: os valores da cadeia de caracteres em uma consulta SQL devem estar entre aspas simples, e é por isso que eles aparecem em torno dos valores inseridos pelo usuário.
Portanto, a combinação do nome de usuário (myuser) e senha (mypass) deve corresponder a uma entrada na tabela Usuários para que um UserID seja retornado. Se não houver correspondência, nenhum UserID será retornado, portanto, as credenciais de login serão inválidas. Embora uma implementação específica possa diferir, a mecânica é bastante normal.
Agora, vamos ver uma consulta de autenticação de modelo, na qual podemos substituir os valores inseridos pelo usuário no formulário da web:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
À primeira vista, isso pode parecer um passo direto e lógico para validar facilmente os usuários, no entanto, se uma substituição simples dos valores inseridos pelo usuário for realizada nesse modelo, ele será suscetível a um ataque de SQLI.
Por exemplo, suponha que “myuser’–” seja inserido no campo de nome de usuário e que “wrongpass” seja inserido na senha. Usando a substituição simples em nossa consulta de modelo, obteríamos isso:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Uma chave para essa afirmação é a inclusão dos dois traços
(--)
. Este é o token de comentário inicial para instruções SQL, portanto, qualquer coisa que apareça após os dois traços (inclusive) será ignorada. Essencialmente, a consulta acima é executada pelo banco de dados como:
SELECT UserID FROM Users WHERE UserName='myuser'
A omissão gritante aqui é a falta da verificação de senha.Ao incluir os dois traços como parte do campo do usuário, ignoramos completamente a condição de verificação de senha e conseguimos fazer o login como "myuser" sem saber a respectiva senha. Esse ato de manipular a consulta para produzir resultados não intencionais é um ataque de injeção de SQL.
Que danos podem ser causados?
Um ataque de injeção de SQL é causado por codificação de aplicativo negligente e irresponsável e é completamente evitável (o que abordaremos em breve), no entanto, 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 ao banco de dados (observe que isso é diferente de um login de usuário no próprio site). Dependendo das permissões que o aplicativo da Web requer, essa conta do banco de dados pode exigir qualquer coisa, desde a permissão de leitura / gravação em tabelas existentes, até o acesso total ao banco de dados. Se isso não estiver claro agora, alguns exemplos devem ajudar a fornecer alguma clareza.
Com base no exemplo acima, você pode ver isso 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. Quando estamos no sistema, não sabemos que, na verdade, não somos esse usuário, por isso, 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 respectivo banco de dados.
Agora, vamos supor que o site tenha controle total de seu respectivo banco de dados, que permite excluir registros, adicionar / remover tabelas, adicionar novas contas de segurança, etc. É importante observar que alguns aplicativos da Web podem precisar desse tipo de permissão. Não é automaticamente uma coisa ruim que o controle total seja concedido.
Então, para ilustrar o dano que pode ser feito nessa 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 simples substituição, a consulta de autenticação se torna:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Nota: o ponto-e-vírgula está em uma consulta SQL é usado para indicar o final de uma instrução específica e o início de uma nova instrução.
Qual é executado pelo banco de dados como:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Users
Então, assim, usamos um ataque SQLI para excluir toda a tabela Usuários.
Naturalmente, muito pior pode ser feito pois, dependendo das permissões SQL permitidas, o invasor pode alterar valores, despejar tabelas (ou o próprio banco de dados inteiro) em um arquivo de texto, criar novas contas de login ou até seqüestrar toda a instalação do banco de dados.
Prevenindo 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 web é que você nunca confia cegamente na entrada do usuário como fizemos quando fizemos uma substituição simples em nossa consulta de modelo acima.
Um ataque SQLI é facilmente frustrado pelo que é chamado de saneamento (ou escape) de suas entradas. O processo de limpeza é, na verdade, bastante trivial, pois tudo o que ele faz essencialmente é manipular apropriadamente qualquer caractere de aspas simples (‘) embutido, de forma que eles não possam ser usados para encerrar prematuramente uma cadeia dentro de uma instrução SQL.
Por exemplo, se você quisesse pesquisar "O’neil" em um banco de dados, não poderia usar a substituição simples porque a aspa simples após o O causaria o encerramento prematuro da string. Em vez disso, você limpa usando o caractere de escape do respectivo banco de dados. Suponhamos que o caractere de escape para uma aspa simples embutida esteja precedendo cada frase com um símbolo. Então, "O'neal" seria higienizado como "O 'neil".
Esse simples ato de saneamento praticamente impede um ataque de SQLI. Para ilustrar, vamos rever nossos exemplos anteriores e ver as consultas resultantes quando a entrada do usuário for higienizada.
myuser'--
/ passagem errada:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Como a cota única após myuser é escapada (significando que é considerada parte do valor de destino), o banco de dados literalmente procurará pelo Nome de Usuário de
'myuser'--'.
Além disso, como os traços são incluídos no valor da string e não na própria instrução SQL, eles serão considerados parte do valor de destino, em vez de serem interpretados como um comentário SQL.
Robert'; DROP TABLE Users;--
/ passagem errada:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Ao simplesmente escapar da aspa simples depois de Robert, tanto o ponto-e-vírgula quanto os travessões estão contidos na string de pesquisa UserName para que o banco de dados procure literalmente
'Robert'; DROP TABLE Users;--'
em vez de executar a exclusão da tabela.
Em suma
Embora os ataques na Web evoluam e se tornem mais sofisticados ou se concentrem em um ponto de entrada diferente, é importante lembrar-se de proteger contra ataques testados e verdadeiros que inspiraram várias “ferramentas de hackers” disponíveis gratuitamente para explorá-los.
Certos tipos de ataques, como o DDoS, não podem ser facilmente evitados, enquanto outros, como o SQLI, podem ser evitados. 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.
