É isso mesmo que você leu: hackers usam “simples” pesquisas do Google para encontrar sites vulneráveis e invadir sistemas inteiros. Isso já acontece há um bom tempo e é, de certa forma, bem simples – ainda assim, não é difícil encontrarmos casos de vítimas atingidas por descuido.
Como os hackers usam o Google
O esquema todo inicia com uma simples pesquisa no Google. Usando os chamados dorks, que são os artifícios da pesquisa refinada do site de buscas, eles conseguem ver quais sites possuem os campos mais visíveis.
Um exemplo de pesquisa desse tipo é:
Nesse campo, podemos encontrar as páginas que têm o tipo de arquivo php (que é uma das linguagens de programação usadas no desenvolvimento de sites) e, ao mesmo tempo, as palavras “produto” e “id” no campo da URL. A partir daí, já dá pra saber o que acontece, né? Um site que deixa esses tipos de dados visíveis pode dar brechas para que outras informações importantes sejam encontradas.
Mas como os hackers invadem os sites encontrados?
Após essa aparentemente inocente pesquisa no Google, os hackers invadem os sites vulneráveis com o auxílio de um programa específico. Que, aliás, é também muito simples de ser encontrado (nós borramos e colocamos tarjas, é claro) e possui até mesmo diversos tutoriais no YouTube:
SQL Injection é o nome dado à técnica de intrusão usada no golpe. Aquele programa de que falamos acima aplica uma “injeção” de SQL (que é uma linguagem de pesquisa em bases de dados): de forma automática, são feitas várias análises combinatórias nos campos da URL (como aqueles da pesquisa do Google) até que as páginas de erro vão dando mais informações sobre o banco de dados do site.
Tudo funciona, então, por brechas e vulnerabilidades que dão acesso ao banco de dados do site. Não é como se o hacker entrasse no painel de configurações a que o desenvolvedor tem acesso, mas sim, em um lugar onde todas as informações são armazenadas.
No exemplo abaixo, que é uma imagem mostrando programa em utilização, podemos identificar que Target é a URL em que serão feitos os testes. Já o campo à esquerda, com as checkboxes (⃞), é o menu de tabelas (ou listas de informações) a que o hacker vai tendo acesso. Os resultados vão aparecendo de forma gradual na caixa à direita. É onde o “ouro” dá as caras: e-mails, logins, senhas e até mesmo números de cartão de crédito.
Quanto mais antigo o site, maiores as chances de serem encontradas falhas, pois faltam atualizações de segurança. É preciso estar constantemente alerta e prevenir problemas de desenvolvimento.
Empresas menores de e-commerce são atacadas por terem desenvolvimento incorreto ou insuficiente. Muitas vezes, desenvolvedores ruins são contratados pela pouca preocupação com segurança – o que leva, obviamente, a descuidos na hora de prevenir problemas.
Um outro descuido comum é aquele “Desenvolvido por…” no rodapé das páginas. Após uma invasão, não é difícil que o hacker encontre o site do desenvolvedor, por exemplo, e chegue a um verdadeiro cardápio de outros sites desenvolvidos com as mesmas falhas.
Muitos sites armazenam as senhas de maneira clara, como em uma planilha de Excel mesmo. Isso é um erro terrível! O jeito correto é utilizar hashes, que são dados embaralhados de forma a dificultar sua identificação.
Toda senha pode ter mais de um tipo de hash, que pode ser de inúmeros tamanhos. É dessa forma que se dificulta a visualização delas. Isso não impede que os queridos hackers também tenham acesso a bases de traduções dos hashes. Por isso, não fique com raiva daquele site que pede diversos tipos de caracteres na hora de criar uma senha.
Uma outra forma interessante de observar se o armazenamento de senhas de um site é precário é o “Esqueci minha senha”. Se o site enviar um e-mail com a senha pura e simples, significa que não existe o mínimo uso de hashes por lá.
São aqueles sites que não utilizam PagSeguro, Mercado Pago ou outros métodos de recepção de pagamentos que são seguros. Ou seja: acabam salvando os dados de cartão de crédito dos clientes na base de dados.
O que os hackers fazem com os dados de cartões de crédito já é óbvio: compras e/ou vendas dos números (geralmente em listas) para roubar o que for possível das vítimas. Mas com as senhas, existem mais truques: elas podem ser testadas em outros serviços além do site em que foram encontradas.
Se foram obtidas credenciais de um site de e-commerce pequeno, por exemplo, os hackers partem do princípio de que muitas pessoas usam a mesma senha em vários lugares. Dessa forma, eles podem conseguir acessar até sistemas internos de empresas a partir da senha de um funcionário que usou o mesmo código no site invadido.
Os seus dados ou de seus funcionários podem estar vulneráveis sem aquilo que é mais adequado em qualquer problema de segurança: consciência. São dicas básicas e que você pode já ter visto antes, mas são justamente elas que protegem contra golpes como o SQL Injection:
Sempre trocar! Dessa forma, se você for atingido por uma exposição (mesmo usando sua melhor e maior senha), só terá perdido uma única credencial.
Separe o que é pessoal do que é profissional. E sempre alerte seus funcionários e colegas a isso! Os dados das empresas são, afinal de contas, um dos bem mais visados dos cibercriminosos.
A Axur repudia o uso fraudulento de SQL Injection e qualquer tipo de ação criminosa on-line. A intenção das informações aqui expostas é mostrar a necessidade do correto desenvolvimento de sites e da consciência por segurança. A Lei Geral de Proteção de Dados (LGPD) já nos mostra que é responsabilidade das empresas prezarem pela segurança das senhas de seus consumidores.
Eventualmente, temos acesso a esse tipo de invasões em nosso monitoramento de deep e dark web, feito por nossa equipe de Threat Intelligence, ou mesmo em sites da web superficial.