O que é um ataque de injeção de SQL?
Talvez você não saiba o que é um ataque de injeção de SQL (SQLI) ou como ele funciona, mas com certeza conhece as vítimas. Target, Yahoo, Zappos, Equifax, Epic Games, TalkTalk, LinkedIn e Sony Pictures - todas essas empresas foram invadidas por criminosos cibernéticos usando injeções de SQL.
Um SQLI é um tipo de ataque pelo qual os criminosos cibernéticos exploram vulnerabilidades de software em aplicativos da Web com o objetivo de roubar, excluir ou modificar dados ou obter controle administrativo sobre os sistemas que executam os aplicativos afetados.
Os pesquisadores de segurança cibernética consideram o SQLI como uma das ameaças cibernéticas menos sofisticadas e fáceis de defender. O site Malwarebytes Labs classificou o SQLI como o número três na lista das 5 ameaças cibernéticas mais idiotas que funcionam de qualquer forma, citando o fato de que o SQLI é um ataque conhecido e previsível com contramedidas facilmente implementadas.
Os ataques de SQLI são tão fáceis que, de fato, os invasores podem encontrar sites vulneráveis usando pesquisas avançadas do Google, chamadas de Google Dorking. Depois de encontrar um alvo adequado, os atacantes de SQLI podem usar programas automatizados para realizar o ataque de forma eficaz para eles. Tudo o que eles precisam fazer é inserir o URL do site-alvo e ver os dados roubados chegarem.
No entanto, os ataques de SQLI são comuns e acontecem todos os dias. Na verdade, se você tem um site ou um negócio on-line, é provável que os criminosos cibernéticos já tenham tentado usar a SQLI para tentar invadir seu site. Um estudo do Ponemon Institute sobre The SQL Injection Threat & Recent Retail Breaches descobriu que 65% das empresas pesquisadas foram vítimas de um ataque baseado em SQLI.
Os aplicativos da Web frequentemente visados incluem: sites de mídia social, varejistas on-line e universidades. As empresas de pequeno e médio porte são especialmente vulneráveis, pois geralmente não estão familiarizadas com as técnicas que os criminosos cibernéticos usam em um ataque SQLI e, da mesma forma, não sabem como se defender contra esse tipo de ataque.
Com isso, vamos dar o primeiro passo para nos defendermos de uma injeção de SQL, instruindo-nos sobre o assunto. Esta é a sua cartilha sobre injeções de SQL.
Como funciona uma injeção de SQL?
Desenvolvida no início dos anos 70, a SQL (abreviação de structured query language, linguagem de consulta estruturada) é uma das linguagens de programação mais antigas ainda em uso para o gerenciamento de bancos de dados on-line. Esses bancos de dados contêm informações como preços e níveis de estoque para sites de compras on-line. Quando um usuário precisa acessar as informações do banco de dados, o SQL é usado para acessar e apresentar esses dados ao usuário. Mas esses bancos de dados também podem conter dados mais confidenciais e valiosos, como nomes de usuário e senhas, informações de cartão de crédito e números de previdência social. É nesse ponto que as injeções de SQL entram em ação.
Simplificando, uma injeção de SQL é quando hackers criminosos inserem comandos maliciosos em formulários da Web, como o campo de pesquisa, o campo de login ou o URL de um site não seguro, para obter acesso não autorizado a dados confidenciais e valiosos.
Aqui está um exemplo. Imagine ir ao seu site de roupas on-line favorito. Você está comprando meias e vê um mundo Technicolor de meias coloridas, todas disponíveis com um clique do mouse. As maravilhas da tecnologia! Cada meia que você vê existe em um banco de dados em algum servidor em algum lugar. Quando você encontra uma meia de que gosta e clica nela, está enviando uma solicitação ao banco de dados de meias, e o site de compras responde com as informações sobre a meia em que você clicou. Agora imagine que seu site de compras on-line favorito tenha sido construído de maneira descuidada, repleto de vulnerabilidades de SQL exploráveis.
Um criminoso cibernético pode manipular as consultas ao banco de dados de tal forma que uma solicitação de informações sobre um par de meias retorne o número do cartão de crédito de algum cliente infeliz. Repetindo esse processo várias vezes, um criminoso cibernético pode explorar as profundezas do banco de dados e roubar informações confidenciais de todos os clientes que já compraram em seu site de roupas on-line favorito, inclusive você. Levando o experimento mental ainda mais longe, imagine que você é o proprietário desse site de roupas. Você tem uma enorme violação de dados em suas mãos.
Um ataque de SQLI pode render aos criminosos cibernéticos informações pessoais, e-mails, logins, números de cartão de crédito e números de previdência social de milhões de consumidores. Os criminosos cibernéticos podem, então, dar a volta por cima e vender essas informações pessoais nos cantos mais sombrios da dark web, para serem usadas para todos os tipos de fins ilegais.
Os e-mails roubados podem ser usados para ataques de phishing e malspam. Os ataques de malspam, por sua vez, podem ser usados para infectar as vítimas com todos os tipos de malware destrutivo, como ransomware, adware, cryptojackers e cavalos de Troia (por exemplo, Emotet), para citar alguns. Números telefônicos roubados para Android e iOS podem ser alvo de robocalls e spam de mensagens de texto.
Os logins roubados de sites de redes sociais podem até ser usados para enviar spam de mensagens e roubar ainda mais logins de outros sites. Malwarebytes Labs Um relatório anterior relatou que contas hackeadas do LinkedIn foram usadas para enviar spam a outros usuários com mensagens InMail contendo URLs ruins falsificados para parecer uma página de login do Google Docs, por meio da qual os criminosos cibernéticos poderiam coletar nomes de usuário e senhas do Google.
Qual é o histórico das injeções de SQL?
A exploração da injeção de SQL foi documentada pela primeira vez em 1998 pelo pesquisador de segurança cibernética e hacker Jeff Forristal. Suas descobertas foram publicadas no Phrack, um zine de hackers de longa data. Escrevendo sob o pseudônimo de Rain Forest Puppy, Forristal explicou como alguém com habilidades básicas de codificação poderia pegar carona em comandos SQL não autorizados em comandos SQL legítimos e extrair informações confidenciais do banco de dados de um site não seguro.
Quando Forristal notificou a Microsoft sobre como a vulnerabilidade afetava seu popular produto SQL Server, eles não viram isso como um problema. Como disse Forristal: "De acordo com eles [Microsoft], o que você está prestes a ler não é um problema, portanto, não se preocupe em fazer nada para impedi-lo".
O que torna a resposta indiferente da Microsoft tão chocante é que muitos setores e instituições dependiam seriamente (naquela época e agora) da tecnologia de gerenciamento de banco de dados da empresa para manter suas operações em funcionamento, incluindo varejo, educação, saúde, bancos e recursos humanos. Isso nos leva ao próximo evento na linha do tempo da história da SQLI: o primeiro grande ataque da SQLI.
Em 2007, a maior cadeia de lojas de conveniência dos Estados Unidos, a 7-Eleven, foi vítima de um ataque SQLI. Os hackers russos usaram injeções de SQL para invadir o site da 7-Eleven e usá-lo como um trampolim para o banco de dados de cartões de débito dos clientes da loja de conveniência. Isso permitiu que os hackers sacassem dinheiro em casa, na Rússia. No total, os culpados fugiram com dois milhões de dólares, conforme relatado pela revista Wired.
Nem todos os ataques de SQLI são motivados por ganância. Em outro exemplo notável de 2007, os criminosos cibernéticos usaram a SQLI para obter controle administrativo sobre dois sites relacionados ao Exército dos EUA e redirecionar os visitantes para sites com propaganda antiamericana e antiisraelense.
A violação de dados do MySpace em 2008 foi considerada um dos maiores ataques a um site de consumidores. Os criminosos cibernéticos roubaram e-mails, nomes e senhas parciais de quase 360 milhões de contas. E é por isso que não reutilizamos senhas de um site para outro.
O título de falta de segurança mais flagrante vai para a Equifax. A violação de dados da Equifax em 2017 forneceu informações extremamente pessoais (ou seja, nomes, números de previdência social, datas de nascimento e endereços) de 143 milhões de consumidores. Para uma organização que atua como guardiã das informações de todos os americanos, exceto daqueles que vivem fora da rede, seria de se esperar que ela tomasse precauções contra um ataque básico de SQLI. Antes de ocorrer a violação de dados, uma empresa de pesquisa de segurança cibernética chegou a avisar a Equifax que ela era suscetível a um ataque SQLI, mas a agência de crédito não tomou nenhuma providência até que fosse tarde demais.
No que foi considerado o hack mais assustador da história, um ataque da SQLI em 2015 ao fabricante de brinquedos Vtech levou a uma violação de quase cinco milhões de pais e 200.000 crianças. Em conversa com a Motherboard, a publicação multimídia on-line, o hacker responsável afirmou que não tinha planos para os dados e não os publicou em nenhum lugar on-line. Por outro lado, o hacker também explicou que os dados eram muito fáceis de serem roubados e que outra pessoa poderia tê-los obtido primeiro. De fato, um consolo frio.
Hoje em dia, o ataque SQLI ainda é uma realidade. A cada três anos, o Open Web Application Security Project (OWASP) classifica os 10 principais riscos mais críticos do aplicativo Web Security . Na edição mais recente de 2017, o ataque SQLI foi classificado como o número um.
Além da longevidade do ataque SQLI, o que é interessante é que os ataques SQLI não mudaram nem evoluíram de forma alguma. Os ataques SQLI funcionam e continuarão a funcionar até que as pessoas mudem suas atitudes em relação à segurança cibernética. Seja essa mudança.
Notícias sobre injeções de SQL
- O que é um honeypot? Como eles são usados na segurança cibernética
- Entrevista com um caçador de recompensas de insetos: Youssef Sammouda
- Um guia de dia zero para 2020: Ataques recentes e técnicas preventivas avançadas
- Vulnerabilidades em aplicativos móveis financeiros colocam consumidores e empresas em risco
- Como proteger seu sistema de gerenciamento de conteúdo
- Explicação: Injeção de SQL
- OWASP top ten - Segurança chata que compensa
- As 5 principais ameaças cibernéticas mais idiotas que funcionam de qualquer maneira
Como as injeções de SQL afetam minha empresa?
Conforme relatado em nosso relatório Táticas e técnicas de crimes cibernéticos, os ataques cibernéticos (de todos os tipos) a empresas aumentaram 55% no segundo semestre de 2018, enquanto os ataques a consumidores individuais aumentaram apenas 4%. As estatísticas não são surpreendentes. As empresas com segurança deficiente apresentam aos criminosos um alvo fácil, com um tesouro de dados valiosos que valem milhões.
Por outro lado, uma empresa no centro de uma violação de dados pode esperar pagar milhões. Um estudo da IBM descobriu que o custo médio de uma violação de dados, incluindo remediação e penalidades, é de US$ 3,86 milhões. A violação de dados do LinkedIn mencionada anteriormente acabou custando ao site de rede de negócios US$ 1,25 milhão em um acordo extrajudicial.
Após a violação de dados, a Target foi forçada a pagar a maior quantia já registrada - US$ 18,5 milhões - para resolver investigações realizadas por vários estados. Isso se somou aos US$ 10 milhões que a Target pagou para resolver uma ação coletiva movida por consumidores.
É verdade que essas violações de dados são enormes e afetam milhões de consumidores. Entretanto, as empresas de pequeno e médio porte ainda podem esperar pagar US$ 148 por cada registro de consumidor roubado.
A moral da história? Leve sua segurança a sério e evite ser um "alvo" para os criminosos cibernéticos.
Como posso me proteger contra injeções de SQL?
Deixando de lado toda essa enrolação, você está aqui porque sabe que as injeções de SQL são uma ameaça séria. Agora, vamos fazer algo a respeito. Aqui estão algumas dicas para proteger sua empresa contra ataques de injeção de SQL.
Atualize seu software de gerenciamento de banco de dados. Seu software tem falhas quando vem do fabricante. Isso é um fato. Não existe software livre de bugs. Os criminosos cibernéticos podem tirar proveito dessas vulnerabilidades de software, ou exploits, com um SQLI. Você pode se proteger apenas aplicando patches e atualizando seu software de gerenciamento de banco de dados.
Aplique o princípio do menor privilégio (PoLP). PoLP significa que cada conta só tem acesso suficiente para fazer seu trabalho e nada mais. Por exemplo, uma conta da Web que precisa apenas de acesso de leitura a um determinado banco de dados não deve ter a capacidade de gravar, editar ou alterar dados de forma alguma.
Use instruções preparadas ou procedimentos armazenados. Ao contrário do SQL dinâmico, as instruções preparadas limitam as variáveis nos comandos SQL recebidos. Dessa forma, os criminosos cibernéticos não podem usar injeções de SQL mal-intencionadas em instruções SQL legítimas. Os procedimentos armazenados limitam de forma semelhante o que os criminosos cibernéticos podem fazer ao armazenar instruções SQL no banco de dados, que são executadas pelo usuário a partir do aplicativo Web.
Contrate desenvolvedores competentes e experientes. Os ataques SQLI geralmente resultam de codificação desleixada. Informe antecipadamente aos desenvolvedores de software o que você espera em termos de segurança.
E se minhas informações pessoais forem roubadas em uma violação de dados? Você deve dar uma olhada em nossa lista de verificação de violação de dados. Lá você aprenderá tudo sobre como limpar e manter-se seguro depois que uma violação de dados por ataque da SQLI afetar você.
Visite o OWASP. O Open Web Application Security Project, abreviado como OWASP, é a maior autoridade em aplicativos da Web e tem muitas leituras adicionais sobre como evitar injeções de SQL.
E se você não se cansa de injeção de SQL em sua vida, visite o blogMalwarebytes Labs para saber de todos os acontecimentos mais recentes no mundo das ameaças cibernéticas e da segurança cibernética.