Ao longo da história, inúmeros fracassos ocorreram devido ao excesso de confiança dos planejadores na qualidade de suas soluções. Seja no Titanic que não afundou ou na inexpugnável linha Maginot da Segunda Guerra Mundial, confiar demais em uma única solução causou catástrofes terríveis repetidas vezes.
No mundo da segurança cibernética, isso não é diferente. Se você tem uma defesa de segurança cibernética de solução única, está pedindo por problemas.
Os perigos de uma solução única para a segurança
Neste artigo, analisaremos um caso específico em que isso ocorreu com um provedor de comércio eletrônico. Essa empresa criou uma nova API de login para seu aplicativo móvel. Ela reforçou a segurança exigindo a criptografia RSA de 1024 bits da senha no payload de todas as solicitações de autenticação.
Essa é uma boa ideia. Afinal, ela torna os ataques man-in-the-middle praticamente inúteis, pois as informações de autenticação não seriam legíveis por humanos. Elas aparecem como uma cadeia de caracteres codificada em base64 e criptografada por RSA. Como as solicitações de autenticação vinham de seu próprio aplicativo, essa foi uma abordagem muito boa. Parabéns.
Mas... há mais do que isso. O que não foi uma boa ideia foi pensar que essa medida de segurança era tudo o que eles precisavam. Em vez de continuar a aprimorar a segurança com medidas como a imposição de um número máximo de tentativas de senhas com falha, eles decidiram simplesmente enviá-la e, em seguida, passaram para outro trabalho de desenvolvimento.
Embora possa parecer que tudo estava bem, havia uma falha significativa em sua solução. A chave pública de 1024 bits era facilmente observável ao usar o JADX para descompilar o aplicativo móvel.
Ao salvar a chave pública em um arquivo local, um invasor pode passar por todas as senhas que desejar, criptografando-as de acordo com a chave pública do alvo e desfazendo completamente o trabalho de proteger o endpoint de autenticação em primeiro lugar.
Como não havia limite máximo de tentativas de senha com falha nesse endpoint, escrevi um script bash que automatizaria a verificação de quantas senhas eu quisesse. Comprovei o problema para esse provedor de comércio eletrônico com uma simples contagem regressiva para a minha senha que eu havia definido para demonstrar o problema:
#!/bin/bash |
Aqui está o resultado do meu script:
Welcome 10 |
Vamos explicar isso. Em um for No loop, começo com uma mensagem de boas-vindas para anunciar qual dígito estou inserindo na minha tentativa de chegar à senha que defini para essa prova de conceito. Em seguida, vemos a senha e o valor criptografado subsequente que será enviado à API. (Você realmente não achou que eu usaria uma senha tão simples, muito menos que a revelaria aqui, achou?)
Por fim, envio a resposta da API à minha verificação de senha. Nas primeiras seis tentativas, recebo uma resposta sem sucesso, mas quando finalmente chego à minha senha hipersegura (😉) de faster4wardSe eu não tiver acesso à API, a API me permite entrar com meu escopo de autorização normal.
Não há muito para cargas úteis de autenticação criptografadas por RSA...
Como você pode evitar esse mesmo tipo de erro
Agora que identificamos o problema, o que podemos fazer em vez disso? Bem, vamos começar com o erro fundamental no pensamento que nos trouxe até aqui em primeiro lugar. Há muitas coisas a serem feitas para proteger com êxito qualquer aplicativo da Web, pois não há solução mágica para proteger um aplicativo! Para o nosso exemplo específico acima, é necessário adotar outras medidas além da criptografia RSA forte.
- Certifique-se de que suas chaves de criptografia estejam seguras.
- Impor um número máximo de tentativas de verificação de senha com falha, resultando em bloqueio da conta.
- Implementar limitação de taxa de solicitação.
Qualquer segurança de um sistema exposto à Internet deve adotar o princípio da defesa em profundidade: Várias camadas de defesa devem ser implantadas em toda a área de superfície de sua presença na Web, e não apenas nos pontos que você considera mais interessantes ou óbvios para defender.
Felizmente, a Linode oferece muitos recursos de segurança excelentes incorporados diretamente em nossa plataforma, e há muitos padrões do setor para lidar com alguns vetores de ataque comuns. Algumas dessas soluções se aplicam à sua conta da Linode e outras se aplicam diretamente aos seus Linodes. Vamos dar uma olhada nos dois tipos de proteção.
Proteção do acesso de administrador à sua conta Linode
Se alguém conseguir entrar em sua conta Linode, o jogo acaba. Entrar em seus Linodes se torna trivial. É por isso que as contas da Linode são criadas com a segurança em mente. Por padrão, toda conta da Linode deve ser protegida com verificação telefônica. A Linode também exige a configuração de perguntas e respostas de segurança para fins de recuperação de conta.
Além da verificação por telefone, você também pode configurar a autenticação de dois fatores usando um código de autenticação de senha única baseada em tempo (TOTP). Embora não seja obrigatório nas contas, é altamente recomendável ativar a 2FA, pois ela é muito mais segura do que apenas uma senha e perguntas de segurança, e ainda mais segura do que os códigos de verificação por telefone.
Outro nível de segurança está disponível para ignorar completamente a necessidade de uma senha do Linode. Você pode usar uma fonte de autenticação de terceiros (TPA). Ao usar esse método, você pode configurar métodos seguros de login na fonte de terceiros de sua escolha (no momento, o Google e o GitHub são compatíveis com isso). Isso reduz as chances de uma senha vazada fazer com que você perca o acesso à sua conta Linode.
Um método final de proteção da sua conta é configurar usuários específicos que possam acessar partes específicas da sua conta. Isso permitirá que você defina determinadas permissões em relação ao que os subusuários podem fazer na sua conta, reduzindo ainda mais a possibilidade de um invasor causar danos incontestáveis à sua conta.
Introduzir essa separação de preocupações entre os usuários que acessam as várias partes da sua infraestrutura é uma boa prática. É claro que, se você for uma equipe de uma pessoa só, talvez isso não seja necessário. Ainda assim, se você tiver uma verdadeira separação de preocupações, isso permitirá que você se certifique de que não sejam feitas alterações não autorizadas em sua conta ou infraestrutura.
Proteja seus Linodes
Proteger sua conta é definitivamente importante, mas proteger seus servidores e sua infraestrutura pode ser ainda mais importante. Afinal de contas, a maioria dos invasores tentará entrar em sua infraestrutura por meio dela, e não por meio do provedor de hospedagem. A Linode também cobre você aqui.
Um dos melhores lugares para começar é o Linode App Marketplace. Se você precisa implantar soluções de segurança como o Haltdos WAF para interromper o tráfego mal-intencionado nos portões de seus servidores ou se deseja ter uma instalação com um clique de uma pilha de monitoramento, como uma configuraçãoPrometheus + Grafana , não é muito mais fácil proteger e monitorar sua pilha do que o Marketplace.
Os aplicativos de terceiros também não são as únicas soluções que você tem à sua disposição. O Linode Cloud Firewall é uma ótima solução que pode ser facilmente configurada diretamente no Cloud Manager. Usar o Linode Cloud Firewall e um firewall em seu Linode também é uma ótima ideia.
Outra boa prática é garantir que seus servidores estejam protegidos contra ataques DDoS. Com a Linode, você defende toda a sua infraestrutura contra esses ataques por padrão - sem nenhum custo! Você nem precisa fazer nada para configurá-la.
Conclusão
Há muito mais a dizer sobre segurança, mas isso provavelmente é suficiente por enquanto. Em suma, evite que sua solução inteligente para um problema faça com que você se esqueça de cuidar de outros aspectos que podem estar faltando em sua abordagem de segurança.
Comentários