Ao longo da história, ocorreram inúmeros fracassos devido ao excesso de confiança dos planeadores na qualidade das suas soluções. Quer se trate do Titanic inafundável ou da inexpugnável linha Maginot da Segunda Guerra Mundial, depositar demasiada confiança numa única solução causou catástrofes terríveis vezes sem conta.
No mundo da cibersegurança, não é diferente. Se tiver uma defesa de cibersegurança de solução única, está a pedir problemas.
Os perigos de uma solução única para a segurança
Neste artigo, vamos analisar um caso particular em que isto ocorreu com um fornecedor de comércio eletrónico. Esta empresa criou uma nova API de início de sessão para a sua aplicação móvel. Reforçaram a sua segurança exigindo a encriptação RSA de 1024 bits da palavra-passe no payload de quaisquer pedidos de autenticação.
Esta é uma boa ideia. Afinal de contas, torna os ataques man-in-the-middle praticamente inúteis, uma vez que as informações de autenticação não seriam legíveis por humanos. Aparece como uma cadeia de caracteres codificada em base64 e encriptada em RSA. Como os pedidos de autenticação vinham da sua própria aplicação, esta foi uma boa abordagem. Parabéns.
Mas... há mais do que isso. O que não foi uma boa ideia foi pensar que esta medida de segurança era tudo o que precisavam. Em vez de continuarem a melhorar a segurança com medidas como a imposição de um número máximo de tentativas falhadas de palavras-passe, decidiram simplesmente enviá-la e depois passaram para outro trabalho de desenvolvimento.
Embora possa parecer que tudo estava bem, havia uma falha significativa na sua solução. A chave pública de 1024 bits era facilmente observável utilizando o JADX para descompilar a sua aplicação móvel.
Ao guardar a chave pública num ficheiro local, um atacante pode percorrer todas as palavras-passe que quiser, encriptando-as todas de acordo com a chave pública do alvo e desfazendo completamente o trabalho de segurança do ponto final de autenticação.
Uma vez que não havia um limite máximo de tentativas de palavras-passe falhadas neste ponto final, escrevi um script bash que automatizaria uma verificação de tantas palavras-passe quantas eu quisesse. Provei o problema a este fornecedor de comércio eletrónico com uma simples contagem decrescente para a minha palavra-passe que tinha definido para demonstrar o problema:
#!/bin/bash |
Aqui está o resultado do meu script:
Welcome 10 |
Vamos lá a explicar. Em um for Começo com uma mensagem de boas-vindas para anunciar o dígito que estou a inserir na minha tentativa de chegar à palavra-passe que defini para esta prova de conceito. Depois, vemos a palavra-passe e o valor encriptado subsequente que será enviado para a API. (Não pensavam que eu ia usar uma palavra-passe tão simples, quanto mais revelá-la aqui, pois não?)
Por fim, envio a resposta da API à minha verificação de palavra-passe. Nas primeiras seis tentativas, recebo uma resposta sem êxito, mas quando finalmente chego à minha palavra-passe hiper-segura (😉) de faster4wardA API permite-me entrar com o meu âmbito de autorização normal.
Lá se vão as cargas úteis de autenticação encriptadas por RSA...
Como pode evitar este mesmo tipo de erro
Agora que identificámos o problema, o que podemos fazer em vez disso? Bem, vamos começar com o erro fundamental no pensamento que nos trouxe aqui em primeiro lugar. Há muitas coisas a fazer para proteger com êxito qualquer aplicação Web, uma vez que não existe uma solução mágica para proteger uma aplicação! No caso do nosso exemplo específico acima, é necessário adotar outras medidas para além da encriptação RSA forte.
- Certifique-se de que as suas chaves de encriptação são seguras.
- Impor um número máximo de tentativas falhadas de verificação da palavra-passe, resultando no bloqueio da conta.
- Implementar a limitação da taxa de pedidos.
Qualquer segurança de um sistema exposto à Internet deve adotar o princípio da defesa em profundidade: Devem ser implementadas várias camadas de defesa em toda a área de superfície da sua presença na Web, e não apenas nos pontos que considera mais interessantes ou óbvios para defender.
Felizmente, a Linode oferece muitos recursos de segurança excelentes incorporados à nossa plataforma, e existem muitos padrões do setor para lidar com alguns vetores de ataque comuns. Algumas dessas soluções se aplicam à sua conta Linode e outras se aplicam diretamente aos seus Linodes. Vamos dar uma olhada nos dois tipos de proteção.
Proteger o acesso de administrador à sua conta Linode
Se alguém conseguir entrar na sua conta Linode, é fim de jogo. Entrar em seus Linodes torna-se trivial. É por isso que as contas Linode são construídas com a segurança em mente. Por padrão, toda conta Linode deve ser protegida com verificação por telefone. O Linode também exige a configuração de perguntas e respostas de segurança para fins de recuperação de conta.
Para além da verificação por telefone, também pode configurar a autenticação de dois factores utilizando um código de autenticação de palavra-passe única baseada no tempo (TOTP). Embora não seja obrigatório nas contas, é altamente recomendável ativar a 2FA, uma vez que é muito mais segura do que apenas uma palavra-passe 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 contornar completamente a necessidade de uma senha 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 suportados para 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 é a definição de utilizadores específicos que podem aceder a partes específicas da sua conta. Isto permite-lhe definir determinadas permissões relativamente ao que os sub-utilizadores podem fazer na sua conta, reduzindo assim ainda mais a possibilidade de um atacante causar danos não mitigados à sua conta.
Introduzir esta separação de preocupações entre os utilizadores que acedem às várias partes da sua infraestrutura é uma boa prática. Claro que, se for uma equipa de um só utilizador, isto pode não ser necessário. Ainda assim, se tiver uma verdadeira separação de preocupações, isto permitir-lhe-á certificar-se de que não são feitas alterações não autorizadas à sua conta ou infraestrutura.
Proteja seus Linodes
Proteger a sua conta é definitivamente importante, mas proteger os seus servidores e infra-estruturas pode ser ainda mais importante. Afinal, a maioria dos atacantes tentará entrar na sua infraestrutura através da infraestrutura e não através do seu provedor de hospedagem. Linode cobre-o aqui também.
Um dos melhores lugares para começar é o Linode App Marketplace. Quer necessite de implementar soluções de segurança como o Haltdos WAF para impedir o tráfego malicioso nos portões dos seus servidores ou pretenda ter uma instalação com um clique de uma pilha de monitorização, como uma configuraçãoPrometheus + Grafana , não é muito mais fácil proteger e monitorizar a sua pilha do que a Marketplace.
As aplicações de terceiros também não são as únicas soluções que tem à sua disposição. Linode Cloud Firewall é uma ótima solução que é facilmente configurada diretamente do Cloud Manager. Usar o Linode Cloud Firewall e um firewall no 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! Nem precisa de fazer nada para o configurar.
Conclusão
Há muito mais a dizer sobre segurança, mas isto é provavelmente suficiente por agora. Em suma, evite que a sua solução inteligente para um problema o faça esquecer-se de ter em conta os outros aspectos que podem estar em falta na sua abordagem de segurança.
Comentários