Imagine se a própria ferramenta de segurança que você colocou para impedir que intrusos entrem em sua casa, fosse usada de repente como porta de entrada. Esse pesadelo é uma realidade para um número cada vez maior de vítimas.
Infelizmente, este caso não foi o único. Os cibercriminosos que desejam explorar recursos de segurança fracos vão tentar abrir as possíveis portas dos produtos de consumo, como câmeras de segurança, sempre que for possível. Além disso, com uma técnica chamada “credential stuffing”, a invasão se tornou fácil, mesmo para um cibercriminoso novato.
A segurança instalada nas câmeras de segurança da marca Nest e outros dispositivos da Internet das Coisas (IoT) podem criar o que os usuários do Vale do Silício chamam de “atrito”: obstáculos que dificultam uma experiência tranquila e bem-sucedida com o produto. Exemplos de atrito incluem: muitas telas para passar, instruções de montagem muito complicadas, procedimentos de segurança muito inconvenientes e assim por diante. Quanto menos atrito um produto tiver, mais atraente ele se torna.
Como a tecnologia da IoT pode intimidar todos que não tenham um alto nível de conhecimento digital, os novos produtos precisam ser fáceis de configurar e usar. Para atrair mais clientes, alguns desenvolvedores da IoT optam por não adicionar recursos básicos de segurança, como solicitar uma alteração de senha padrão ou autenticação de dois fatores (2FA). Esse tipo de segurança fraca deixa sua rede doméstica vulnerável a ataques cibernéticos, incluindo uma técnica muito popular nos dias de hoje: o “credential stuffing”.
“Credential stuffing” é uma das formas mais simples e prediletas de invasão usada pelos cibercriminosos. Usando essa técnica, o criminoso coleta suas credenciais vazadas (geralmente roubadas em um vazamento de dados) e as usa em várias outras contas, esperando conseguir acesso. Resumindo: coletar e reutilizar credenciais de login (nome de usuário e senha).
Por exemplo, digamos que você faz compras online na Netshoes e cibercriminosos invadem o banco de dados da empresa. Com suas credenciais roubadas, eles podem usar o “credential stuffing” para tentar acessar sites de bancos, sites de redes sociais, servidores de e-mail, etc. Se você for como a maioria dos usuários, você reutiliza credenciais. Os cibercriminosos contam com isso.
Avanços na tecnologia tornaram mais fácil do que nunca fazer uma invasão via “credential stuffing”. Como relata o The Washington Post:
Você pode impossibilitar o “credential stuffing” se assumir o controle de suas credenciais. Não deixe que nenhum deles funcione como uma chave universal para suas outras contas online. Além disso, memorize estes três pontos:
E então, vamos agora para mais um dos riscos de OWASP, o “A2:2017 – Broken Authentication” (autenticação quebrada).
[00:04] Então eu vou tentar fazer agora um dos hobbys recentes que eu tenho, que é o de brincar com algumas mágicas. Eu vou tentar fazer um processo de mentalismo, onde eu adivinho uma coisa e eu tento adivinhar a senha. A sua senha! E a sua senha é “senha”, acertei?
[00:28] Eu espero não ter acertado. Por quê? Porque se você está fazendo um curso de segurança na web, eu espero que você não esteja utilizando a senha “senha” em qualquer sistema que você utiliza. Porém, a palavra “senha”, “amor” e o seu próprio nome etc. têm muitas palavras. Às vezes palavras fixas como “senha”, “amor”, “senha123”, “123456”, “qwerty”, são senhas muito comuns.
[00:54] Por quê? Porque é fácil de lembrar, então a pessoa pega e usa essa senha - e óbvio, se eu uso porque ela é comum, porque ela é fácil de lembrar, muita gente também utiliza essa senha.
[01:03] E nós abrimos um buraco, se nós permitimos que o nosso sistema aceite essas senhas, nós temos um buraco extra, que é pessoas usando essas senhas terem facilidade de serem hackeadas por outros usuários.
[01:16] Lembrando: não teste isso em sistemas externos, teste isso onde você tem o direito, onde você conversou com a equipe e você pode fazer esse teste. Então você entra no seu sistema e testa. Deixe-me testar localmente, na minha máquina local, rodando em banco de dados local; se eu consigo utilizar uma senha comum.
[01:33] Então existem sim sites que têm as senhas mais comuns, você pode procurar por “most common passwords owasp” e você vai ter lá as senhas. Esse daqui não sei se é do OWASP especificamente, mas tem aqui Wikipedia etc. e adivinha? A primeira é, em inglês, “password”, depois “123456” e depois o quê? “12345678”. Por quê? Porque tem site que pede no mínimo 8 dígitos e por aí vai. Está vendo? Senhas muito comuns!
[02:02] Então, qual é um dos problemas? É no momento que você aceita senhas comuns, usuários vão usar senhas comuns, aí você tem um buraquinho. Você pode falar: “não, mas a culpa não é minha!”
[02:13] Claro, não necessariamente é sua, mas não é questão de culpa. É questão de: você quer tapar o máximo de buraco possíveis de uma maneira ainda confortável para os seus usuários? Então nós podemos criar uma lista, que é essa lista aqui, que é a lista que nós rejeitamos de senhas! Nós não aceitamos essas senhas.
[02:29] Mas tem outras maneiras, então essa é uma das maneiras que a sua aplicação pode estar vulnerável. Aqui, por exemplo, senhas muito comuns. Se o seu site permite senhas muito comuns, complicado! Como “password1” ou usuário e senha “admin” e “admin”. Senhas muito comuns, complicado! Mas tem vários outros tipos ou de ataques que as pessoas podem fazer ou de testes etc.
[02:53] Lembrando: não faça isso em sites que você não tenha o direito!
[02:58] Então na hora que você for testar, você pode olhar o código dinamicamente, estaticamente ou rodar o código e analisar dinamicamente comportamento na sua máquina dos seus sistemas e verificar outros tipos de ataque. Tem vários outros que o pessoal usa e que está ligado com autenticação, com uma quebra em um processo de autenticação. Alguns bem simples mesmo, muito simples de nós imaginarmos e discutirmos.
[03:23] Como é que eu percebo então, se está vulnerável? Alguns exemplos. Primeiro: permitir credencial “stuffing”. O que acontece? Você fala assim: “o meu site é superseguro, ninguém nunca vai entrar no servidor para pegar usuários e senhas no banco, porque eu tenho 15000 processos e não sei o quê, não sei o quê...”
[03:38] Pode até ser verdade, mas a autenticação quebrada não é só alguém entrar no seu banco e pegar usuário e senha das pessoas, não é só isso. É o seguinte: muitos anos atrás vazaram os usuários e senhas de um site “X”, por exemplo. Sei lá, vazou de um monte de sites, tem um monte de sites que já vazou na história. Então vazou de site grande, site muito grande, sei lá, top 100 do mundo. Tem um site grande que vazou usuário e senha.
[04:05] E esse usuário e senha, a senha provavelmente está criptografada, mas ela está na internet. Tem alguns bancos de dados de senhas vazadas que são vendidos por hackers e ela está lá em algum lugar e alguém em algum momento descobriu que a senha daquele usuário, por exemplo, era “guilhermesilveira@caelum.com.br” ou era “guilherme171734”, sei lá, descobriu! Fez o “match” e percebeu que era “guilherme171734”.
[04:33] O que ele faz? Aquele usuário e senha eram daquele site famoso, de um site famoso que tinha sido hackeado. Muito famoso e muito grande, tem diversos, como eu citei. O que acontece? Não precisa hackear o seu site, só precisa tentar “guilhermesilveira@caelum.com.br” e a senha “guilherme171734”!
[04:54] Então a pessoa não precisa acessar o seu banco de dados para ela conseguir obter acesso ao seu sistema, seja com um usuário de nível mais baixo de acesso ou nível mais alto de acesso. Se ele pega a senha de outro lugar – então, “stuffing” é de pegar de outro lugar.
[05:14] Você pode clicar aqui no link, tem a definição da OWASP. Então você pega o usuário e senha da internet de algum “breach”, de algum vazamento anterior, ou de sites de “dump” de senha etc. e usa isso para verificar.
[05:28] E é claro, eles já usam isso! Olhe, já tem meio que automatizado, sai usando em vários sites de uma vez só. Então, imagine: se ele conseguiu usuário e senha seu de um site qualquer, pequeninho que você usou a mesma senha que os seus maketplaces, para que o seu e-mail, para que o seu não sei o quê; na hora que ele hackeou aquele site pequenininho ou aquele site grandão e descobriu tua senha, ele tentou aquele usuário e senha em todos os cantos.
[05:51] Então, qual é o problema aqui? O problema é o “stuffing”. Se você tem uma lista de usuários e de senhas válidas, ele vai lá e tenta. Então é isso, de usuários e senhas que já foram utilizados em outros lugares.
[06:04] Então nós também vamos ter que, de alguma maneira, incentivar as pessoas a usarem uma senha única, mas você não tem como saber que a pessoa usou uma senha única em todos os sites que ela usa senha, certo? Nós não temos o controle sobre a pessoa nisso.
[06:16] Então vai ter outras regrinhas para nós tentarmos facilitar isso para as pessoas, para facilitarmos que ela use uma senha única no nosso site e não esqueça essa senha. Nós vamos ter algumas regrinhas que vão aparecer aqui.
[06:27] Permitir força bruta ou outros ataques automatizados. Força bruta meio que testa tudo, então vai em um site e testa: “guilherme.silveira@caelum.com.br”, senha “A”, senha “B”, senha “D”, senha “C”, esqueci o “C”, senha “E”, senha “F”, senha “G” e vai tentando um monte de coisas. Não precisa ser tão burro quanto isso, quanto essa força bruta que eu estou dizendo.
[06:45] Poderia ser tentar as 10 mil, está aqui, “top 10.000 worst password”. É aquele link? Acho que é outro, era outro! Está vendo? Têm aqui as senhas, senhas muito comuns etc. ele descreve várias.
[06:58] Então você pode pegar daqui os 10 mil e bloquear, porque senão ele vai tentar força bruta. Ele pega um usuário específico e tenta um ataque para aquele usuário com 10 mil senhas.
[07:07] De novo: não faça isso ao vivo, em sites diferentes! Faça somente no seu próprio site interno, dentro da sua máquina, sem o banco de dados de produção etc. Para testar se você permite, então quer dizer, se permite, se pessoa consegue fazer 1 mil tentativas de login por segundo, você pode ter um espaço que você gostaria de tampar.
[07:27] Permitir senhas padrões. Então tem muitos sistemas que você instala - “instalei Wordpress, instalei o MySQL, instalei não sei o quê” - e ele já vem com usuário e senha padrão. Como por exemplo: “admin” e “admin”. Não pode ter usuário e senha padrão, porque se tiver usuário e senha padrão, o que acontece? A pessoa tenta imediatamente um usuário e senha padrão.
[07:47] Senhas muito comuns ou senhas fracas. Fracas são um desafio, nós vamos discutir mais a fundo quando nós formos falar de validações, como nós podemos testar a força etc. de uma senha.
[07:58] Mas não é necessariamente “use 500 caracteres e códigos e barras” e não sei o quê. Porque, se você colocar senhas muito complexas - e no OWASP vai discutir isso, mas não vai ser aqui, vai ser mais para frente.
[08:09] Se você obrigar senhas muito complexas, o que a pessoa faz? Ela usa a mesma senha dos outros sites. Porque ela não vai decorar, então ela usa a mesma senha dos outros sites. E o que acontece? Nós permitimos o “stuffing” de novo, nós estamos favorecendo o “stuffing”.
[08:24] Então a regra não pode ser idiota, não pode ser só uma regrinha boba, mas você não quer também uma regra complexa demais e que faça com que a pessoa use “copy and paste”. Claro, se possível, nós vamos incentivar as pessoas a usarem gerenciadores de senha que geram senhas complexas ou algo do gênero. Vai aparecer.
[08:43] Se você usa processos de recuperação de senha que são inefetivos ou fracos. Por exemplo: aqueles processos de senha que você, por exemplo, pergunta alguma coisa. “Qual foi o nome do seu primeiro cachorro da vida? Onde você nasceu?” Perguntas do gênero, que não são perguntas seguras. Outras pessoas podem saber isso.
[09:07] Então nós estamos falando isso aqui. A senha como eu estou descrevendo até agora é um código que você sabe, é uma coisa que você sabe e isso é fundamental. Aqui também são coisas que você sabe, só que na senha nós esperamos que só a pessoa saiba. Mas nessas perguntas nós esperamos que outras pessoas ao redor dela também saibam, o que é pior. Então nós não queremos ir para esse lado. Não queremos ir!
[09:32] O que mais? Se você usar senha texto plana, gravado no banco... Espere um pouco! Se a pessoa digitou a senha dela, “guilherme171734” e no banco você gravou a palavra “guilherme171734”. Qualquer pessoa com acesso ao banco tem a senha facilmente.
[09:49] Então, o que nós temos que fazer? Criptografar essa senha. Eu vou falar em criptografar, é o “encrypted”. É nisso que ele está falando de “encrypted”. Então você vai ver de “sensitive data exposure” que aparece aqui no próximo.
[09:58] Então, o que nós queremos? Sempre deixarmos, de uma forma, criptografada a senha, todas as suas ferramentas, todas as suas linguagens etc. vão ter Bcrypt e outros algoritmos de criptografia. Vão ter para você encriptar a senha do usuário e não ficar com aquela senha do usuário gravada em algum lugar em texto plano.
[10:19] Ter “multi-factor authentication” (autentificação multifator), quer dizer, mais de um fator. Então os fatores são: algo que você é, algo que você tem e algo que você sabe. Então algo que você é, por exemplo: a minha íris. Por exemplo: a minha impressão digital. Então são coisas que eu sou, então é um fator de autenticação.
[10:42] Um outro fator de autenticação pode ser uma coisa que eu tenho. Então o meu tenho o meu celular, se você mandar um código para o meu celular, eu tenho o meu celular e eu sei esse código agora. Poderia ser! Antigamente você tinha aqueles cartões do banco com vários códigos. Então eu tenho aquele cartão, se você não tem o cartão, você não tem esse fator e você não consegue se logar.
[11:06] E tem... Então tinha o que eu sou, o que eu tenho e o que eu sei. Eu sei um código, eu sei uma senha, eu sei um código, eu sei alguma coisa do gênero. Então o que eu tenho, o que eu sou e o que eu sei. Se você usar dois desses você tem “multi-factor authenticator”, então “multi-factor authentication” diminui a chance de alguém se logar por outra pessoa, se autenticar como outra pessoa.
[11:30] Tem outras coisas: expor IDs de seção na URL. Então a URL que nós estamos acessando, quando nós estamos nos comunicando com o servidor, o servidor de alguma maneira coloca, às vezes, um cookie, um ID de seção ou alguma coisa para nos identificar.
[11:45] Só que esse ID aparece aqui e é comum aparecer, por exemplo: “J “SESSION ID”” ou qualquer outro tipo de ID aparecer aqui. Esse parâmetro aqui pode estar visível em certos lugares, em diversos locais de “log”, por exemplo. Em sistemas de “log” podem aparecer e se aparecem em sistema de “log”, vazou um número que identifica o meu usuário.
[12:05] E alguém pode pegar essa URI e fazer o quê? Fingir que sou eu. Imagine que esse “ “session ID”” aqui indica que sou o usuário “Guilherme” logado nesse instante. Se eu pego esse link e mando para outra pessoa, quando a pessoa clicar, ela estará logada como se fosse eu.
[12:23] Mas o buraco mesmo, o outro buraco, é: se apareceu no “log” de algum sistema ali no meio essa requisição, se alguém clicar nessa linha, o que acontece? A pessoa está logada com o meu usuário!
[12:37] Isso eu estou fazendo interpretação pura só do “session ID”. Então, por isso nós não vamos colocar “session ID” assim na URL. Não vamos expor. O mesmo “session ID”, quando você loga, nós vamos ficar gerando um “session ID” novo. Por quê? Porque o antigo para de valer. De alguma maneira vai fazer isso.
[12:54] Você vai ver que tem lugares que usam variações disso, que permite que você logue duas máquinas ao mesmo tempo. Três vezes, uma em um lugar, outro em outro. Tem variações.
[13:04] Invalidar, certo? Se a pessoa desloga, não quer dizer que é só para ela passar de usar o parâmetro aqui em cima, ou parâmetro não vai ser em cima, parar de utilizar o cookie. Não! Você tem que falar que se algum lugar tiver aquele cookie e alguém clicar naquele link de novo, não vai ser mais o “Guilherme”, aquela pessoa.
[13:20] Então, quando a pessoa se loga no site, ela manda um cookie, o servidor manda um cookie para o cliente. Esse cookie é sempre enviado para o servidor, para dizer: “olhe, sou eu sou eu sou eu!” Meio que dizendo isso. Não está dizendo “sou eu”, está dizendo: “eu sou esse cookie” e o servidor olha e fala: “esse cookie é essa pessoa, então tudo bem!”
[13:37] Só que, o que nós temos que fazer? Quando você desloga, você tem que remover o cookie do cliente. Mas isso não é suficiente, no servidor você tem que falar: “esse cookie não identifica mais o “Guilherme”. Por quê? Porque se alguém tivesse acesso a esse cookie, o que que essa pessoa poderia fazer? Ela poderia fingir que ela ainda era essa pessoa e acessar o servidor, que o servidor iria acreditar que era essa pessoa.
[14:00] Então você tem que... Lembra? Nunca confiar no cliente, nunca! Nunca confiar no cliente! Não importa se é o navegador, você não confia, você invalida no servidor. Então aqui também está dizendo isso. Alguns exemplos de ataque, como eu citei, o exemplo de credencial “stuffing”, ou usar uma lista de senhas comuns.
[14:17] Aqui, de novo, ele dá um link. Aqui já é o mesmo início, mas aqui não está no “master”, aqui está uma descrição geral. Você pode baixar esse arquivo, vários arquivos também, várias outras coisas que são explicadas. Ou “credential stuffing”, que é de pegar de outro lugar. Então, é tentar, de alguma maneira, controlar isso.
[14:34] Antigamente era recomendado que tivesse a reciclagem de senha. “Depois de dois meses, por favor, mude sua senha! Você é obrigado a mudar sua senha”. Tudo bem! Depois de dois meses você muda sua senha. O que acontece?
[14:46] Na terceira vez que você recebe isso, você fica o quê? Não fica feliz! E o que você faz? Você usa a mesma senha, você usa uma senha fácil de lembrar, porque você não vai querer ficar lembrando uma senha difícil a cada dois meses. Você não quer, ainda mais se todos os sites te pedem isso!
[15:00] Então antigamente era considerado uma boa prática fazer a rotação de senha, mas perceberam que encorajava os usuários a utilizarem senhas fracas e reutilizarem senhas - o que nós acabamos de falar que era ruim. Então em vez de usar isso, use “multi-factor authentication”. Essa é a recomendação.
[15:18] E timeouts de seções, você tem que ter um timeout. A seção, mesmo por padrão, você tem que colocar: “olhe, depois de tanto tempo sem a pessoa acessar, aquela pessoa deixa de ser ela. Aquele cliente deixa de ser identificado como “Guilherme”, ele tem que se logar novamente”.
[15:34] Claro, depende do quão perigoso seria uma pessoa acessar aqueles dados que ela está logada. Porque a conveniência de nós ficarmos logado em um sistema é não termos que ficar nos logando a toda hora.
[15:47] Então se é trabalhoso, você fala: “maravilha! Quero dar essa facilidade para o usuário final!” Mas se ela esquece, só fecha a aba navegador e quando abre de novo, ela está logada, pode ser que outra pessoa utilize e isso vai ser uma quebra de segurança. Você tem que ver o quão grave isso é para você.
.svg){kind=logo}
Comentários
Postar um comentário