26Aug
Mesmo se você apenas seguisse vagamente os eventos dos grupos 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 enquanto não estamos tentando lhe dar um manual para fazer isso você mesmo, é útil entender o que está acontecendo. Dois dos ataques que você constantemente ouviu sobre eles usando são "(Distributed) Denial of Service"( DDoS) e "SQL Injections"( SQLI).Veja como eles funcionam.
Imagem por xkcd
Ataque de Negação de Serviço
O que é isso?
Uma "negação de serviço"( às vezes chamado de "denegação distribuída de serviço" ou DDoS) ocorre quando um sistema, neste caso um servidor web, recebe tantos pedidos ao mesmo tempo em que os recursos do servidor estão sobrecarregados, o sistema simplesmente bloqueiae desliga-se. O objetivo e o resultado de um ataque DDoS bem-sucedido são os sites no servidor de destino não estão disponíveis para pedidos de tráfego legítimos.
Como funciona?
A logística de um ataque DDoS pode ser melhor explicada por um exemplo.
Imagine que um milhão de pessoas( os atacantes) se juntem com o objetivo de dificultar o negócio da Empresa X, tirando o call center. Os atacantes coordenam para que na terça-feira às 9 da manhã todos liguem para o número de telefone da Empresa X.Muito provavelmente, o sistema de telefone da Empresa X não poderá lidar com um milhão de chamadas ao mesmo tempo, de modo que todas as linhas recebidas serão amarradas pelos atacantes. O resultado é que as chamadas legítimas dos clientes( ou seja, aqueles que não são os atacantes) não passam porque o sistema telefônico está vinculado ao tratamento das chamadas dos atacantes. Então, em essência, a Empresa X está potencialmente perdendo negócios devido aos pedidos legítimos que não podem ser realizados.
Um ataque DDoS em um servidor web funciona exatamente da mesma maneira. Como praticamente não existe nenhuma maneira de saber de que tráfego é proveniente de pedidos legítimos versus atacantes até o servidor web processar o pedido, esse tipo de ataque geralmente é muito eficaz.
Executando o ataque
Devido à natureza "força bruta" de um ataque DDoS, você precisa ter muitos computadores todos coordenados para atacar ao mesmo tempo. Revisitando nosso exemplo de call center, isso exigiria que todos os atacantes que ambos conhecessem ligassem às 9 da manhã e realmente liguem nesse momento. Embora este princípio certamente funcionará quando se trata de atacar um servidor web, torna-se significativamente mais fácil quando computadores zumbis, em vez de computadores atuais, são utilizados.
Como você provavelmente sabe, há muitas variantes de malware e trojans que, uma vez em seu sistema, ficam dormentes e ocasionalmente "telefone em casa" para obter instruções. Uma dessas instruções poderia, por exemplo, ser enviar pedidos repetidos ao servidor web da Empresa X às 9 horas. Assim, com uma única atualização para o local de origem do respectivo malware, um único atacante pode coordenar instantaneamente centenas de milhares de computadores comprometidos para realizar um enorme ataque DDoS.
A beleza da utilização de computadores zumbis não é apenas a sua eficácia, mas também o seu anonimato, já que o invasor não precisa usar seu computador para executar o ataque.
SQL Injection Attack
O que é isso?
Um ataque de "Injeção SQL"( SQLI) é uma exploração que tira proveito de técnicas de desenvolvimento da Web pobres e, normalmente, de uma segurança de banco de dados defeituosa. O resultado de um ataque bem sucedido pode variar de representar uma conta de usuário para um compromisso 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 apropriadamente 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 pode executar uma consulta como a seguinte:
SELECIONAR ID de usuário DOS usuários WHERE UserName = 'myuser' E senha= 'mypass';
Nota: os valores de seqüência de caracteres em uma consulta SQL devem ser incluídos em citações simples e é por isso que elas aparecem em torno dos valores inseridos pelo usuário.
Assim, a combinação do nome de usuário( myuser) e senha fornecidos( mypass) deve coincidir com 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 é retornado para que as credenciais de login sejam inválidas. Embora uma implementação específica possa ser diferente, a mecânica é bastante padrão.
Então, vejamos agora uma consulta de autenticação de modelo que podemos substituir os valores que o usuário insere no formulário da Web:
SELECIONE o ID de usuário dos usuários WHERE UserName = '[user]' AND Password = '[pass]'
À primeira vista, issopode parecer um passo direto e lógico para validar facilmente os usuários, no entanto, se uma simples substituição dos valores inseridos pelo usuário for executada neste modelo, é suscetível a um ataque SQLI.
Por exemplo, suponha que "myuser'-" seja inserido no campo de nome de usuário e "wrongpass" seja digitado na senha. Usando a substituição simples em nossa consulta de modelo, obtivemos isso:
SELECIONE o ID de usuário dos usuários WHERE UserName = 'myuser' - 'AND Password =' wrongpass '
Uma chave para esta declaração é a inclusão dos dois traços( -).Este é o token de comentário de início para instruções SQL, então 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 ID de usuário dos usuários WHERE UserName = 'myuser'
A omissão flagrante aqui é a falta de verificação de senha. Ao incluir os dois guinchos como parte do campo do usuário, ignoramos completamente a condição de verificação da senha e conseguimos fazer o login como "myuser" sem conhecer a respectiva senha. Este ato de manipular a consulta para produzir resultados não desejados é um ataque de injeção SQL.
Que dano pode ser feito?
Um ataque de injeção SQL é causado por uma codificação de aplicação negligente e irresponsável e é completamente evitável( o que vamos abranger 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 web se comunique com o banco de dados do backend, o aplicativo deve fornecer um login para o banco de dados( nota, isso é diferente de um login do usuário no próprio site).Dependendo das permissões que o aplicativo web requer, esta conta de banco de dados pode requerer qualquer coisa, desde a permissão de leitura / gravação em tabelas existentes somente para acesso completo 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 que, ao inserir, por exemplo, "seu usuário", "administrador" - ou qualquer outro nome de usuário, podemos entrar instantaneamente no site como usuário sem saber a senha. Uma vez que estamos no sistema, não sabemos 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 assumir que o site tem controle total de seu respectivo banco de dados, que permite apagar registros, adicionar / remover tabelas, adicionar novas contas de segurança, etc. É importante notar que alguns aplicativos da web podem precisar deste tipo de permissão paraNão é automaticamente uma coisa ruim que o controle total é concedido.
Então, para ilustrar o dano que pode ser feito nesta situação, usaremos o exemplo fornecido no quadrinho acima, digitando o seguinte no campo de nome de usuário: "Robert"; Usuários da DROP TABLE; - ".Após a substituição simples, a consulta de autenticação se torna:
SELECT ID de usuário dos usuários WHERE UserName = 'Robert';DROP TABLE Users; - 'AND Password =' wrongpass '
Nota: o ponto-e-vírgula está em uma consulta SQL é usado para significar o fim de uma instrução específica e o início de uma nova declaração.
O que é executado pelo banco de dados como:
SELECIONAR ID de usuário dos usuários WHERE Usuário = 'Robert'
DROP TABLE Usuários
Então, assim, usamos um ataque SQLI para excluir a tabela de Usuários inteira.
Claro, muito pior pode ser feito, dependendo das permissões SQL permitidas, o invasor pode alterar valores, despejar tabelas( ou todo o banco de dados em si) para um arquivo de texto, criar novas contas de login ou mesmo seqüestrar toda a instalação do banco de dados.
Prevenção de um ataque de injeção SQL
Como mencionamos várias vezes anteriormente, um ataque de injeção SQL é facilmente evitável. Uma das regras cardinais do desenvolvimento web é que você nunca confia cegamente na entrada do usuário como fizemos quando realizamos uma substituição simples na nossa consulta de modelo acima.
Um ataque SQLI é facilmente frustrado pelo que é chamado de higienização( ou escapa) de suas entradas. O processo de desinfecção é realmente bastante trivial, pois tudo o que ele essencialmente faz é lidar com quaisquer caracteres de citações únicas em linha( ') de forma adequada, de modo que não possam ser usados para finalizar prematuramente uma string dentro de uma instrução SQL.
Por exemplo, se você quisesse pesquisar "O'neil" em um banco de dados, você não poderia usar uma substituição simples porque a citação única após o O faria com que a cadeia terminasse prematuramente. Em vez disso, você o desinfecta usando o caractere de escape do banco de dados respectivo. Vamos assumir que o caráter de escape para uma citação única em linha está prefaciando cada citação com um símbolo \.Então "O'neal" seria sanitizado como "O \ 'neil".
Este simples ato de saneamento evita bastante um ataque SQLI.Para ilustrar, revele nossos exemplos anteriores e veja as consultas resultantes quando a entrada do usuário é sanitizada.
myuser '- / errada :
SELECIONAR ID de usuário dos usuários WHERE UserName =' myuser \ '-' AND Password = 'wrongpass'
Porque a citação única após o meu usuário é escapada( o que significa que é considerado parte do alvovalor), o banco de dados buscará literalmente o UserName de "myuser" - ".Além disso, porque os traços estão incluídos dentro do valor da seqüência de caracteres e não a instrução SQL, eles serão considerados parte do valor do destino em vez de serem interpretados como um comentário SQL.
Robert ';Usuários da DROP TABLE: / errada :
SELECT ID de usuário dos usuários WHERE UserName = 'Robert \';DROP TABLE Usuários; - 'AND Password =' wrongpass '
Ao simplesmente escapar da citação única após Robert, tanto o ponto-e-vírgula como os traços estão contidos na seqüência de pesquisa UserName, então o banco de dados buscará literalmente "Robert"; DROP TABLE Users;- "em vez de executar a exclusão da tabela.
Em Resumo
Enquanto os ataques na web evoluem e se tornam mais sofisticados ou se concentram em um ponto de entrada diferente, é importante lembrar-se de proteger contra ataques provados e verdadeiros, que foram a inspiração de várias "ferramentas de hackers" livremente disponíveis para explorá-los.
Alguns tipos de ataques, como DDoS, não podem ser facilmente evitados, enquanto outros, como o SQLI, podem. No entanto, o dano que pode ser feito por esses tipos de ataques pode variar desde qualquer inconveniente até catastrófico, dependendo das precauções tomadas.
