Hoje a gente vai se aprofundar um pouco no tema de técnicas de invasão de softwares. Eu comentei há alguns dias sobre as possíveis falhas de segurança que poderiam acontecer dentro de uma urna eletrônica, então eu resolvi fazer esse post explicando as técnicas mais comuns e com maior ocorrência que a gente vê por aí. Eu vou explicar essas falhas acontecem e por que elas acontecem.
Existem centenas de técnicas de invasão diferentes, das mais simples às mais aprimoradas, que requerem acesso físico. Mas vamos começar focando em técnicas que utilizam a internet como meio de acesso e, para isso, eu vou utilizar o ranking da OWASP [Open Web Application Security Project ou Projeto Aberto de Segurança em Aplicações Web]. A OWASP é uma entidade que reúne uma comunidade de segurança da informação e eles possuem um ranking, um top 10, das técnicas de invasão mais utilizadas na internet. Esse ranking já existe há muito anos, eu lembro que no custo de TechNet que eu fiz em 2009 já existia o ranking. Frequentemente essas técnicas vão mudando de posição, de acordo com a quantidade de dispositivos que contém falhas. Na minha época era muito comum, por exemplo, o SQL Injection, que era uma técnica muito conhecida, o próprio inject de sessão, o session hijacking era muito utilizado, o cross-site scripting [XSS], também. A gente vai entender quais são os impactos que cada uma delas tem e eu fazer um overview sobre o que tem hoje na lista da OWASP.
A gente tem que entender o seguinte: Para um sistema ter vulnerabilidade, de uma maneira geral, ele precisa ter algum tipo de input, ou seja, alguma forma do usuário conseguir enviar informação para o sistema. Quando a gente está falando de internet, existem vários tipos possíveis de input além dos campos de textos dos formulários, que seriam o óbvio. Nós temos, por exemplo, o header da requisição do HTTP, é possível adicionar headeres específicos e utilizá-los para validar alguma coisa por dentro do sistema, inclusive os novos modelos de autenticação que utilizam JWT utilizam header authorization para enviar informações de sessão. Os próprios cookies que existem nas máquinas são inputs, são formas de trafegar dados que podem ser manipulados e causar algum tipo de problema se não houver uma boa parsing dessas informações do outro lado. Os parâmetros e as query dentro de URL também são formas de input, são parâmetros utilizados internamente dentro dos sistemas de WebService para verificar qual diretório ou qual informação ele precisa processar. Nas APIs mais modernas isso geralmente vai chamar uma função ou um controller específico para executar a informação e esse parâmetro também pode ter algum tipo de vulnerabilidade se não for tratando da forma correta. Query é tudo que vai depois do ponto de interrogação na URL, inclusive o XSS utilizava justamente as query strings para manipular e injetar códigos JavaScript que, no caso desse erro em específico, até não tem um impacto tão grande, você conseguia executar comandos em JavaScript ou importar scripts em JavaScript através de query builder. O impacto depende de outra técnica, que a gente pode falar no futuro também, que são os phishing, para poder ter um dano real.
De uma forma geral, você precisa ter um cuidado com os inputs porque sem eles o hacker não tem como enviar informações diretamente para o sistema, seja ela indevida ou idônea, e até mesmo fazer testes de vulnerabilidade. Hoje em dia existem várias ferramentas para fazer testes das técnicas mais comuns. Em 2009, quando eu fiz o curso de TechNet, o SQL Injection era uma das técnicas mais usadas. Outra informação importante é que normalmente técnicas de invasão são classificadas por níveis de periculosidade, a depender de se elas têm um alto impacto ou um baixo impacto, de acordo com o seu uso. O SQL Injection tinha um dos mais altos níveis de periculosidade porque, por meio de um input, ele consegue enviar um comando para o banco de dados SQL e, através desse injection, injetar um JavaScript que vai ser replicado por um formato de lista ou qualquer output que tenha na página. Então vamos pensar no caso de um blog, por exemplo, se eu tenho o acesso ao banco de dados por meio de SQL Injection dentro da imagem da postagem que está sendo adicionada, que vai aparecer para todo mundo que entrar no blog, e eu injeto um JavaScript malicioso que vai coletar informação, impactando uma grande quantidade de pessoas. Aqui a gente está correlacionando um injection de JavaScript com um SQL Injection, são duas técnicas somadas para dar esse problema. Alguns bancos de dados, eu lembro especificamente do SQL Server, que tinha uma falha, porque o SQL tinha a capacidade de executar comandos no terminal, então a gente podia, através de um comando, por exemplo, fazer um backup do banco de dados. Isso era executado com um comando chamado exec, através desse comando praticamente você tinha o controle da máquina que estava hospedando aquele banco de dados, então a gente já começa a ver um problema muito maior do que simplesmente você fazer um injection de JavaScript.
Falando sobre cross-site scripting e injection de JavaScript, a gente vai esbarrar nas limitações do que o JavaScript pode fazer. Ele pode monitorar campos, pegar informações que estão sendo digitadas ou vistas na tela e mandar para um servidor externo, pode fazer uma série de coisas. Onde eu vejo o maior problema de injection de JavaScript? É quando a gente fala de captura de informações de acesso, fazer um session hijacking ou até mesmo salvar user e senha que o usuário está digitando. Por isso muitas empresas optaram por fazer mudança do login para um magic link ou direcionar para um sistema específico de login, um IAM ou até mesmo utilizar um two factor authentication com JWT. Nos anos 2000 era muito mais comum você ter usuário e senha em sessões via cookies, não que isso não exista até hoje, mas é muito menos utilizado porque, pelo menos em teoria, o JWT tem uma segurança maior. Você pode validar o hash token sem uma chave privada, usando uma criptografia de chave assimétrica, mas, mesmo assim, ainda tem os problemas de session hijacking, que é quando você injeta um JavaScript dentro de uma página para pegar o token de autorização de um usuário e logar no sistema como se fosse aquele usuário. Isso funciona em vários sistemas, por isso normalmente Facebook e Google, por exemplo, utilizam outros parâmetros para validação de autenticidade que não o token: eles vão verificar o IP e normalmente quando o IP do token é diferente do IP da máquina que está fazendo a requisição, ele pede para revalidar o login com o segundo fator de autenticidade. Esse two factor é justamente para combater o session hijacking, que dá acesso a um sistema sem necessariamente ter usuário e senha, fazendo uma injeção de sessão. Então essas eram as mais comuns técnicas de invasão da minha época. Obviamente existem outras técnicas que são voltadas a sistemas desktop, como sniffer, man-in-the-middle, entre outros, mas eu estou focando nesse post em técnicas web, principalmente de browser. Embora não precise obrigatoriamente de um browser para usar essas técnicas, você pode utilizar um sistema que tenha um HTTP Cliente e realizar essas técnicas sem precisar de um navegador.
Dando uma olhada no site da OWASP, em https://owasp.org/www-project-top-ten/ você encontra mais informações, além do gráfico que mostra as top 10 técnicas mais comuns de invasão de 2017 e como é que elas mudaram de posição em 2021.
Então em 2017 nós tínhamos injection em primeiro ligar, e aí injection ficou um termo mais generalista para qualquer tipo de injeção de dados, SQL Injection é um dos tipos. Depois o Broken Authentication, que é mais ou menos parecido com um hijacking, seguindo de Sensitive Data Exposure, dados sensíveis expostos é mais uma falha de quem está fazendo a API liberando informações demais no output. Aí nós temos o XML External Entities (XXE), antigamente você podia incorporar uma entidade por cima do XML para fazer sites, que caiu em desuso e não tem mais tanta força assim, mas era uma técnica também utilizada. Seguindo a lista vem Broken Access Control, que é uma técnica de hijacking para pegar a sessão do usuário e ter controle do sistema, mesmo não tendo autorização. Depois nós temos o Security Misconfiguration, que eu honestamente não sei o que faz, o Cross-Site Scripting (XSS), que eu tinha comentado, que injeta um código malicioso em JavaScript dentro de uma URL ou de um input qualquer e consegue coletar informações, inclusive o XSS, quando utilizado com phishing, pode coletar dados de cartão de crédito. Imagine, você está num site de e-commerce que tem falha de XSS, o hacker injeta um script dentro do seu computador e consegue monitorar tudo que você está digitando. Principalmente depois da criação dos service works, é possível injetar scripts via JavaScript persistentes, então a primeira vez que você clica no link, ele injeta dentro do CSWork uma função, que vai ficar reinjetando o código malicioso dentro do contents, independente de você já estar partindo de um link normal, então parece que nada vai acontecer, mas no futuro ele coleta algum dado de cartão de crédito ou coisa do tipo. A oitava técnica, Insecure Deserialization, que é não botar uma criptografia na hora de serializar uma informação, usando um base 64 simples para armazenar informações dentro de um cookie ou de uma sessão, e qualquer um que saiba um pouquinho sobre criptografia e hashing consegue ver essas informações. Com o tempo você olha determinados tipos de hashing e determinados tipos de padrões de informação, e sabe se aquilo é um base 64, um Md5, um SHA256, então quem mexe com isso com frequência tem o tato apurado para saber que tipo de hashing está sendo utilizado para fazer as validações e para serializar as informações. Pode acontecer de você pegar dentro da sessão e injetar nos cookies informações importantes, eu já vi casos surreais de desenvolvedores que colocam o escopo de acesso dentro de um base 64, o hacker consegue simplesmente mudar e botar o base 64 de novo e ter acesso a coisas que não deveria.
Em seguida a gente tem Using Components with Known Vulnerabilities, ele era o nono lugar e passou para sexto e aí eu vou falar de duas linguagens específicas que eu vi recentemente que apresentaram vulnerabilidades sérias em subcomponentes. Até por volta de 2017, nós utilizávamos para web muito dotnet e PHP, que são linguagens que vêm com um framework interno delas, e era muito raro utilizar dependências externas. Eu lembro que na época que eu programava em PHP, em meados de 2013, eu utilizava meia dúzia de componentes externos para poder mandar um email ou coisa do tipo, mas era muito difícil sair daquele escopo que o PHP tinha. Com a entrada do NodeJS no mercado, esse conceito de plugins e modes ficou muito comum. Essa forma de trabalhar utilizando submódulos é interessante porque você não perde tempo codificando determinados tipos de features. O Node se popularizou e cresceu tanto por causa do NPM, que é um gerenciador de dependências, que também é utilizado por outras empresas, por exemplo, a Unity. Hoje a gente tem uma infinidade de módulos dentro do NPM e isso abriu brecha para vulnerabilidades no sistema. Mesmo que você feche todos os inputs, mesmo que você faça o parsing das informações e tudo mais, você pode ter algum módulo dentro da sua aplicação com algum tipo de vulnerabilidade. A gente precisa sempre tomar muito cuidado com o bota para dentro do projeto, porque pode ter algum módulo com vulnerabilidade acessando nosso system, e qualquer módulo que está em operação dentro de um sistema tem acesso a todas as funcionalidades do node, então ele consegue acessar arquivos, bancos de dados, ele consegue ter controle total da máquina, inclusive consegue adicionar uma chave de acesso SSH dentro do servidor que está hospedado aquela aplicação.
E aí falando do Log4J, que é um componente muito utilizado do Java há mais de 10 anos e é usado por milhares de desenvolvedores no mundo inteiro. Algum tempo atrás foi encontrada uma vulnerabilidade dentro do Log4J da mais alta classificação de risco. Pelo que eu fiquei sabendo, um cara queria invadir um servidor de Minecraft (e sim, o Minecraft é feito em Java), e descobriu que, através do Log4J, ele conseguia acesso remoto completo do servidor. Quando a comunidade de Java viu esse negócio foi um alvoroço absurdo, a Oracle, que é dona do Java, soltou uma nota recomendando a todos os desenvolvedores atualizar a versão do Log4J porque essa vulnerabilidade deixava o sistema inteiro em risco de ser invadido e de perder o controle do servidor da aplicação. O mais incrível: era uma linha de comando, uma linhazinha de código, que o Log4J executava uma chamada no shell, e isso passou à vista de centenas de desenvolvedores, tanto do Java quanto do Log4J. Eu tenho vários amigos que utilizam Java, e lembro que todo mundo começou a correr para poder atualizar as aplicações, para não correr o risco de ser invadido.
Ainda tem várias outras técnicas aqui de invasão, algumas que eu nunca ouvi falar, por exemplo, Broken Access Control. Uma coisa importante falar é que eu me especializei em segurança da informação nos anos 2000, mas faz muitos anos que eu não exerço efetivamente o trabalho de pentest e afins. Para mim foi muito importante para os meus softwares ficarem mais seguros, mas eu não atuo na área, eu fui mais para o lado de backend e depois eu virei empresário, mas eu consigo entender com certa facilidade o que cada coisa faz. Esses Broken Access eu nunca ouvi falar, é uma técnica que já era utilizada ali em 2017 e agora está em primeiro lugar, eu vou até procurar saber melhor como funciona, mas parece que é uma forma de alterar o access control. Normalmente, num sistema web pode ter usuários com níveis de permissionamento diferentes, ter roles diferentes, por exemplo, eu utilizo um sistema chamado Keycloak para fazer IAM nos meus sistemas e eu consigo atribuir escopos e roles para cada usuário, então tem partes do sistema que só o admin vai ver. Isso também é bem comum para quem gerencia páginas de Facebook, que tem diferentes níveis de permissionamento. Olhando por cima, me parece que o Broken Access Control é mais ou menos uma forma de burlar esse sistema de gestão de escopos e acessar áreas que o usuário não tem permissão e obviamente isso é um risco muito alto, já que esses permissionamentos são justamente para que poucas pessoas tenham acesso às determinadas informação.
Esse post está ficando bem grande, obviamente é muita informação, são muitas técnicas que eu poderia ficar horas falado sobre. Eu vou fazer uma segunda parte, vou dar uma lida nessas novas técnicas aqui que eu não conheço e que aparecem no ranking de 2021, e volto falando sobre cada uma delas. Também pretendo fazer um post ou vídeo no futuro, falando sobre técnicas de invasão utilizadas para softwares desktop, não só para Windows e Linux, mas também para Android e iOS porque, sim, existem formas de se invadir esses sistemas operacionais móbile, que também são muito arriscadas e fazem um estrago muito grande. A gente vai aperfeiçoando esses conhecimentos sobre técnicas de invasão, que é um tema muito complicado, tanto que a máxima do mercado de segurança é que nenhum sistema é 100% seguro, porque, por mais que a gente previna contra as técnicas mais comuns, hora ou outra aparece uma técnica nova, uma falha nova, que pode estar passando na nossa vista e a gente não estar vendo. Eu já sofri alguns ataques, hackers já tiraram o meu blog do ar, já invadiram meus sites, utilizando técnicas diferentes dessas, tem outras técnicas sendo criadas todo dia, que a gente nunca viu, e é preciso entender o que está acontecendo para prevenir ataques futuro. O mais importante disso tudo é ter boa equipe de DevOps na empresa, que vai estar monitorando os sistema e servidores, para ver se está acontecendo algum tipo de movimentação atípica dentro dessas aplicações e conseguir contornar isso o mais rápido possível, porque isso pode causar uma destruição dentro da empresa. Se a sua empresa está dentro da internet e ela tem falhas de segurança, você pode ficar semana com seu site off-line, como aconteceu recentemente com algumas varejistas, que foram hackeadas e ficaram semanas fora do ar, perdendo bilhões de Reais na bolsa de valores por causa da invasão, então é fundamental uma boa equipe para se proteger de ataques hackers.
Vou deixar aqui o post que me inspirou a começar essa conversa:
O conteúdo deste post foi retirado do vídeo “Técnicas de Invasão de Software”:
