Como hackear não segura de aplicativo da web

neste artigo eu gostaria de demonstrar como é fácil obter informações confidenciais de um aplicativo web… bem, não presta muita atenção à segurança. O que vou trabalhar é um aplicativo Java de exemplo que criei no Spring Boot para fins de demonstração. Mas os ataques realizados são válidos para qualquer outra linguagem de programação ou estrutura. Algumas vulnerabilidades e problemas de segurança que serão demonstrados incluem:

  • injeção de SQL
  • exposição a dados sensíveis
  • registro insuficiente
  • autenticação quebrada

a configuração

estaremos trabalhando com um aplicativo da web fictício que permite fazer login como usuário, que faz parte de algum grupo. Com base na função do usuário, ele pode visualizar dados básicos ou confidenciais. Nesse caso, você verá uma lista de funcionários em uma empresa, seu status, etc.

visão geral da Página

Você pode encontrar as fontes para esse aplicativo no meu Github: https://github.com/rapasoft/hackme.

Ataque #1: Homem no ataque do meio

Imagine que você está sentado em um restaurante e gostaria de verificar algo no aplicativo acima. Você se conecta ao Wi-Fi do restaurante, abre a página de login, insere credenciais e obtém as informações desejadas (por exemplo, a lista de funcionários específicos). O que você pode não fazer agora é que suas credenciais foram comprometidas. Vamos examinar a página de login de perto:

página de Login

este aplicativo não usa SSL/TLS (por exemplo, não https:// conexão). Isso significa que qualquer informação enviada pode ser vista como texto simples por qualquer pessoa com acesso à comunicação entre o cliente e o servidor.

isso é exatamente o que está acontecendo no chamado Homem no ataque do meio. Mais especificamente, neste caso ARP spoofing tem sido usado como uma maneira de envenenar toda a rede para que o atacante está ciente de qualquer coisa que se passa e pode farejar em todos os pacotes. Eu não vou entrar em detalhes sobre como ARP spoofing funciona, mas irá demonstrá-lo neste vídeo:

vídeo do Youtube de ataque MITM

Você pode precisar para abrir este vídeo do Youtube em uma nova janela e tela cheia para ver mais detalhes

o Que você pode ver acima, é que eu comecei a Ettercap, que é uma suite completa de ataques MITM, e realizada ARP spoofing em meus locais de rede. Enquanto isso, quando o Usuário (me via iPad) insere as credenciais, elas são visíveis tanto no Ettercap quanto no Wireshark (ferramenta para análise de tráfego de rede).

Ataque #2: Injeção SQL

continuando nossa função como invasor deste aplicativo, agora temos as credenciais para o usuário hgraves com senha P4SSW0RD. Você pode ver que não apenas este aplicativo não usa TLS, ele tem uma política de senha muito fraca, permitindo que os usuários escolham senhas realmente horríveis.

fazemos login usando as credenciais acima e podemos ver um campo de entrada com a opção de pesquisar a lista de pessoas. Ao pressionar Search, obteremos a lista completa de pessoas. Se colocarmos “Fra”, por exemplo, obteremos resultados filtrados com base na pesquisa. E se colocarmos lá algum caráter ilegal? É óbvio que há algum banco de dados por trás deste aplicativo, então vamos tentar o caractere ' :

SQL Injection-logging

não apenas isso falhou, mas podemos ver que a solicitação POST falhou com uma mensagem de erro muito específica que expõe a estrutura de toda a instrução SQL. Podemos ver que WHERE P.NAME LIKE '%'%' é usado no final.

hacker habilidoso não precisa de mais. Ajustar a string de pesquisa pode, após algumas tentativas, produzir esses resultados:

 SQL Injection-resultados

a injeção, neste caso, criou a union para selecionar a instrução que busca nomes de usuário e senhas junto com sua função. Não só isso foi bem sucedido, conseguimos exibi-lo no aplicativo cliente original.

agora temos credenciais de todos os usuários e suas funções (exibidas pelo número inteiro na coluna “idade”). Se hframe tiver a função 1, rgraves deve, portanto, ser um usuário mais importante com a função 3.

Ataque # 3: Atacando senhas fracamente hash

aprendemos no primeiro ataque, que provavelmente não há nenhuma Política de senha definida para este aplicativo. Isso nos daria esperança de que rgraves também não preste muita atenção à segurança.

a maneira mais fácil de quebrar o hash da senha que usa algoritmo de hash insuficiente (como MD5 neste caso) é executar dicionário ou ataque de tabela arco-íris. Existem muitas possibilidades, mas a mais fácil é usar serviços de internet que já possuem um grande banco de dados de combinações de senha para hash:

hashes rachados

o primeiro é hframe, o segundo é rgraves. smorgan parece estar usando senhas mais fortes do que outras, já que não está no dicionário.

você pode ver que a senha para rgraves é swordfish, o que significa que ele não é agora o quão importante é escolher senha não-dicionário ;). Agora, nada nos impede de fazer login como este usuário e descobrir a seção “admin” e informações confidenciais:

seção Admin

não leia isso se você é alemão 🙂

como consertar isso?

você pode dizer que tudo isso pode ser facilmente evitado. Você pode dizer que esses foram erros de novato. Bem, isso pode ser verdade, mas o que também é verdade é que o projeto Open Web Application Security lista a injeção como vulnerabilidade nº 1 em aplicativos da web (e tem sido assim por vários anos).

então, se você se viu se perguntando como evitar tudo isso, vamos recapitular:

  • sempre use SSL/TLS ao enviar algo para o servidor. Não precisa ser credencial, atualmente é considerado uma boa prática em geral. Mesmo que você não tenha nenhuma entrada em sua página! A maneira mais fácil é fornecer certificado por meio de serviços como Let’s Encrypt.
  • lembre-se de que os certificados autoassinados podem mitigar o problema da exposição aos dados, mas não impedem que o invasor do MITM falsifique todo o site com seu próprio certificado autoassinado.
  • ao lidar com consultas SQL, sempre escape dos parâmetros obtidos do cliente. A maneira mais fácil de fazer isso é usar os recursos de sua estrutura, por exemplo, na primavera, você pode usar NamedParameterJdbcTemplate, o que também é bom para legibilidade.
  • seja paranóico. Valide qualquer entrada do Usuário. Novamente no mundo Java / Spring, você pode adicionar regras de validação usando JSR-380 implementação de validação de bean como o validador Hibernate e parâmetros de anotação, por exemplo, @Pattern(regexp = "*") String name evitaria entrar '.
  • Registre qualquer tentativa de passar entrada inválida no aplicativo. Além disso, em caso de erro, não exponha nenhuma informação específica de implementação ao cliente.
  • melhore sua autenticação.
    • se possível, use pelo menos autenticação de 2 fatores.
    • não implemente algoritmos personalizados de armazenamento de senhas ou criptografia. É extremamente difícil de fazer por conta própria e você definitivamente falhará. Existem soluções comprovadas como o BCrypt.
  • Leia e marque OWASP TOP 10. Comece com lá e, em seguida, passar por sua lista de melhores práticas.

Write a Comment

O seu endereço de email não será publicado.