Segurança

Noções básicas sobre gerenciamento de senhas para contas compartilhadas

Chris Stoneff

Visão geral:

• Os riscos das senhas de contas compartilhadas e com privilégios
• Como as senhas são armazenadas
• Gerenciando e protegendo senhas compartilhadas
• Ficando em conformidade

Conteúdo

Entendendo o problema
Quanto maior, melhor
Violência de domínio
Desculpas, desculpas, desculpas
O que os reguladores desejam
Uma abordagem automatizada
Pense nisso

Uma questão comum com a qual os administradores precisam lidar cada vez mais é a alteração regular de senha para contas compartilhadas e com privilégios, como a conta interna de

administrador ou conta raiz, uma conta firecall ou talvez até mesmo uma conta de processo. Definindo rapidamente, a conta interna de administrador ou conta raiz é a conta que vem em toda versão do Windows®, Linux e UNIX, e tem sempre o mesmo SID (Identificador de segurança) ou UID (Identificador de usuário). As contas firecall são as outras contas que você cria para ajudar a facilitar o acesso de emergência em um sistema seguro. Essas contas firecall ou de administrador, às vezes, são usadas por usuários sem privilégios para obter acesso a sistemas importantes quando surgem problemas. Finalmente, as contas de processo são aquelas usadas para executar serviços, tarefas, aplicativos COM+ e itens incorporados, como scripts e outros arquivos binários que exigem logon.

Agora, você provavelmente implantou seus sistemas usando scripts ou imagens de instalação. Além disso, todas as suas estações de trabalho e seus servidores provavelmente têm o mesmo nome de conta de administrador e a mesma senha de 8 caracteres que, tenho certeza, não é alterada desde que os sistemas foram implantados. Por esse motivo, uso a palavra "senha" no singular, e não "senhas".

Um administrador pode ser compelido a alterar as senhas para seguir as práticas recomendadas ou atender aos requisitos de conformidade, como os estabelecidos por SOX (Sarbanes-Oxley), PCI DSS (Payment Card Industry Data Security Standard) e pela lei americana HIPAA (Health Insurance Portability and Accountability Act). Às vezes, um administrador se vê motivado quando um ex-administrador ou técnico com conhecimento dessas senhas deixa a empresa, por medo de uma quebra de segurança divulgada ou de perder a capacidade de processar cartões de crédito. Apesar desses fatores, na verdade, o administrador tem que alterar essas senhas por simples segurança e pelos dados que a empresa precisa proteger.

Entendendo o problema

Há alguns fatores que devem ser entendidos ao lidar com essas contas e suas senhas:

1. Quanto mais antiga uma senha, menos segura ela se torna.
2. Senhas mais longas, como regra geral, são mais difíceis de decifrar.
3. A forma como os computadores fazem a autenticação não é alterada só porque eles pertencem a um domínio. Em cada domínio se encontra a base de um grupo de trabalho.

"Quanto mais antiga uma senha, menos segura ela se torna" é uma declaração enganosa. Na verdade, isso significa que, para quem quer invadir um computador, é tudo uma questão de tempo. Se alguém me pergunta: "Quanto tempo se leva para decifrar uma senha?", costumo dizer que não existe uma resposta precisa e, em vez disso, dou algumas dicas que podem ajudar a determinar a resposta para um determinado sistema:

• Quantas pessoas conhecem a senha?
• Todas essas pessoas ainda trabalham na empresa?
• A pessoas que conhecem a senha da conta e não trabalham mais na empresa saíram amigavelmente?
• Você nega acesso à inicialização a partir da unidade de disquete, CD ou DVD, ou da rede?
• Os usuários dos computadores também são administradores locais?
• Todos os seus sistemas usam exatamente a mesma senha para suas contas com privilégios?

Começando pelo início dessa lista, é justo dizer que quanto mais pessoas conhecerem um segredo, maiores as chances de que ele se torne público. Lembro de trabalhar para empresas em que os administradores achavam mais conveniente definir a senha compartilhada com o mesmo valor e contar à equipe de TI e aos estagiários quais eram as senhas, em vez de digitá-las para eles conforme necessário. É claro que, com o tempo, a empresa começou a encontrar vários computadores com configurações não aprovadas e usuários comuns da rede que podiam acessar essas contas.

Se todas as pessoas que conhecem as senhas ainda trabalharem para a empresa e forem funcionários satisfeitos e responsáveis, esse risco de acesso será mais reduzido. Mas nunca se sabe. Um dia qualquer pode aparecer um usuário mal-intencionado. Se um desses usuários saiu da empresa em situação conflitante, você terá um elemento hostil à solta que sabe como invadir sua rede usando uma conta não rastreável.

Se você não negar acesso à inicialização de qualquer outro lugar que não seja o disco rígido, também permitirá que os usuários inicializem usando imagens não autorizadas, como as dos sistemas Windows PE e Linux que podem ser lidas diretamente do sistema de arquivos do computador e obter acesso ao armazenamento seguro. (Devo ressaltar que muitas violações ocorrem a partir de elementos internos. Mesmo que todos os membros e estagiários da equipe ainda sejam empregados da empresa, isso não é garantia de que as senhas e os sistemas sejam seguros.)

Conheço muitas pessoas que continuaram a se conectar a uma rede de um emprego anterior só porque podiam. É engraçado que elas estejam apenas ressaltando a má prática de não alterar senhas do sistema, mas também é assustador considerar o dano que poderiam causar se fossem mal-intencionadas.

Se você permitir a capacidade de inicializar a partir de um DVD ou da rede, talvez não possa auditar o que as pessoas estão fazendo. Quer dizer, um disco de inicialização do Linux ou uma imagem da rede pode muitas vezes obter acesso diretamente ao sistema de arquivos. Se os seus sistemas utilizam o mesmo nome de usuário e a mesma senha para suas contas com privilégios, então você os está configurando para uma grande falha. Mas falarei mais sobre esses itens depois.

O tempo de existência e o comprimento da senha são relevantes conforme o método usado para decifrá-la. Se você estiver lidando com um método de força bruta para determinar senhas, o tempo é realmente o que conta. Quanto menos uma senha for alterada, maior será o tempo que um cracker levará para obtê-la.

Da mesma forma, senhas mais longas exponencialmente têm mais variações de caracteres e portanto exigem mais tempo para serem decifradas. Por isso, é importante considerar se suas senhas terão menos do que 7 caracteres, de 8 a 14 caracteres ou 15 ou mais caracteres de comprimento. E se elas tiverem menos do que 15 caracteres e você usar o Windows, irá desabilitar os hashes do LM (LAN Manager) como parte da configuração do sistema ou pela Diretiva de Grupo?

Como o comprimento da senha afeta alguma coisa? No caso do Windows, a resposta é simples. Ao omitir o histórico dos processos de hash, a Microsoft implementa dois tipos de hash para as senhas: hashes LM e hashes MD4 (Message Digest 4). Por padrão, a Microsoft usa hashes LM, e os valores são armazenados para todas as senhas de até 14 caracteres, a menos que você desative explicitamente o armazenamento desses hashes. Essas senhas são divididas em dois valores de 7 caracteres: o primeiro valor para os 7 primeiros caracteres e o segundo para os outros 7, como mostra a Figura 1.

Figura 1 Tabela de hash de exemplo

Assim, se tiver apenas 7 caracteres, a sua senha deverá estar contida em um único hash LM. Durante anos, a Microsoft recomendou o uso de senhas com pelo menos 8 caracteres. O motivo para isso era que o 8º caractere faria com que a senha fosse dividida em dois valores de hash LM.

É importante observar, no entanto, que os hashes LM são amplamente entendidos e muito fáceis de contornar. A única finalidade para eles nas soluções atuais é ajudar a manter a compatibilidade com versões anteriores em sistemas de nível inferior, como o Windows NT® 4.0.

Atualmente, você deve usar senhas (senhas longas, na verdade) de pelo menos 15 caracteres ou, de preferência, maiores porque, por definição, elas não geram um hash LM. Se a imposição do uso de senhas de 15 caracteres não for uma opção viável no seu ambiente, você deverá desabilitar o armazenamento de hashes LM no processo de criação de imagem (usando diretiva local) e na sua Diretiva de Grupo no Active Directory®.

Essa diretiva pode ser encontrada em Configuração do Computador\Configurações do Windows\Configurações de Segurança\Diretivas Locais\Opções de Segurança. Apenas defina a diretiva "Segurança de rede: não armazenar o valor de hash do LAN Manager na próxima alteração de senha" como ATIVADA.

É importante lembrar que, embora uma boa diretiva imponha o uso de letras em caixa alta e baixa, bem como caracteres numéricos e especiais, uma diretiva ainda melhor impõe também um comprimento de 15 caracteres ou mais.

Quanto maior, melhor

Um dos métodos atuais usados para invadir computadores é chamado de Rainbow Tables e usa hashes LM como meio de exploração. Mas senhas mais longas podem anular a eficiência das Rainbow Tables.

Fico espantado ao ver a quantidade de administradores que usam métodos de segurança, mas não sabem muito (ou nada) sobre Rainbow Tables. Há várias maneiras de criar Rainbow Tables para lidar com algoritmos diferentes. Mas elas são apenas uma lista pré-calculada de todos os hashes LM que possuem de 0 a 14 caracteres.

A advertência das Rainbow Tables é que o invasor precisa obter os hashes LM primeiro. Isso nos leva de volta às questões anteriores sobre como o sistema pode ser inicializado (no CD ou DVD) ou se os seus usuários são ou não administradores locais. Por fim, os hashes LM podem ser extraídos em poucos segundos usando ferramentas gratuitas como pwdump. Com o uso de Rainbow Tables, os hashes são pesquisados para determinar a senha.

Para satisfazer a minha curiosidade, defini uma senha em uma conta de administrador interna do sistema. Eram 14 caracteres e continham várias letras em caixa alta e baixa, bem como caracteres e números especiais. Então, usei as Rainbow Tables que baixei gratuitamente da Internet e consegui extrair os hashes de senha de todas as contas do meu sistema, além de determinar a senha do administrador em menos de dois minutos.

Devo admitir que adorei ver o primeiro hash LM ser derrotado, seguido pelo segundo hash, e colocá-los juntos para conseguir a senha. Para reiterar a questão, se tivesse desabilitado meus hashes LM usando a diretiva que discuti anteriormente, esse vetor de ataque em particular seria extremamente limitado, se não totalmente bloqueado.

Violência de domínio

Estar em um domínio não resolve o problema. Os computadores em um domínio continuam a fazer a autenticação da mesma forma. E, como disse antes, em cada domínio se encontra a base de um grupo de trabalho. Essa declaração simples nem sempre é óbvia. Tive muitas conversas sobre esse assunto e sempre tenho de lembrar aos administradores sobre o que é necessário para acessar um computador: um nome de usuário e uma senha. Depois preciso explicar como o Windows funciona em um grupo de trabalho.

Se você tentar acessar um sistema, precisará fornecer um nome de usuário e uma senha ao sistema remoto. Pelo uso da autenticação integrada, o Windows tentará fazer isso para você. Isso significa que, se você acessar outro sistema do Windows, ele usará seu nome de usuário e sua senha de logon atuais. Portanto, se você tentar acessar outro sistema Windows, nunca será solicitado a fornecer esse nome de usuário e essa senha se o sistema remoto os tiver.

Isso também é chamado de autenticação de passagem. O processo funciona em grupos de trabalho, bem como entre domínios diferentes. Na pior das hipóteses, o sistema solicitará um nome de usuário e uma senha, o que significa simplesmente que você deve digitar as informações de logon novamente.

Agora, mesmo que você ingresse em uma estação de trabalho ou em um servidor de um domínio e o Active Directory se torne um repositório de contas central, todos os seus SAMs (Gerenciadores de Conta de Segurança) locais ou armazenamentos de conta locais desses sistemas não desaparecerão de repente. A única coisa que parece acontecer aos SAMs locais é que eles não são mais gerenciados e protegidos, e essa é a causa do problema. Qual foi a última vez em que você alterou a conta raiz ou de administrador interna dos seus sistemas? Melhor que isso, baixe qualquer utilitário de geração de relatórios que mostre o tempo de existência de uma senha para todas as contas e veja se os resultados são aprovados em uma auditoria.

Se não entendeu o que eu quero dizer, faça logon em uma de suas estações de trabalho de domínio com uma conta de domínio que tenha privilégios de administrador. Abra o gerenciamento do computador no seu sistema e crie um usuário local chamado ComoEuDisse. Atribua uma senha à conta e adicione-a ao grupo de administradores locais do seu sistema. Repita o processo em um segundo sistema de domínio.

Agora, em qualquer um desses sistemas, faça logon com a conta ComoEuDisse e tente acessar o segundo computador indo para \\nome_do_Sistema\c$. Você poderá acessar o compartilhamento administrativo e nem será solicitado a fornecer uma senha! Espero que este exemplo não seja uma novidade para você. Mas se for, aproveite para aprender com ele e permita-me reiterar: só porque o seu sistema pertence a um domínio, isso não muda o fato de que todos esses sistemas continuam a funcionar como se pertencessem a um grupo de trabalho.

A questão é que, se você raramente altera, se é que altera, as senhas para as contas compartilhadas e com privilégios, essas contas estão em perigo. É apenas uma questão de tempo para que sua rede inteira fique comprometida.

Desculpas, desculpas, desculpas

Quando converso com administradores e até mesmo CIOs, eles sempre me dão basicamente estes mesmos motivos para não alterar as senhas dessas contas:

• Temos milhares de sistemas e pouco tempo ou pessoal disponível para alterar essas contas.
• Não temos o orçamento necessário.
• Desabilitamos completamente as contas de administrador.
• Isso nunca nos comprometeu, então acho que não é um grande problema.
• Os auditores nem notaram.

Embora entenda os dois primeiros motivos, essas desculpas não são válidas. Fico de cabelo em pé só de imaginar minhas informações pessoais armazenadas em uma empresa que não trata desse problema por algum motivo.

Embora seja verdade que nem todo sistema da sua rede armazene informações confidenciais, como CPF, registros médicos ou dados financeiros, no mínimo, os usuários desses computadores podem acessá-las. Como administrador de um sistema, um usuário pode instalar key loggers e utilitários de captura de tela, interromper a aplicação da Diretiva de Grupo, introduzir correções em vários subsistemas para capturar e transmitir dados, etc. E, quando o usuário faz isso no nível do computador individual, sua capacidade de pegar esse usuário mal-intencionado é muito menor, já que ele é nomeado como Administrador.

Você sabia que desabilitar a conta de administrador interna no Windows não impede que alguém acesse essa conta? Experimente isto: reinicie o sistema no modo de segurança e faça logon com a conta de administrador interna. Você pode usar a senha emitida para a conta a partir da imagem original e provavelmente terá êxito. Para obter mais informações sobre esse comportamento, consulte o artigo da Base de Conhecimento da Microsoft® "Como acessar o computador depois de desabilitar a conta de administrador" (support.microsoft.com/kb/814777).

O que os reguladores desejam

Lidar com SOX, PCI, HIPAA e outros regulamentos pode deixar a gente meio confuso. Não é fácil entender seus requisitos, pois, além de serem abrangentes, não são muito claros. Em geral, os objetivos desses regulamentos podem ser resumidos conforme a seguir.

Primeiro, é preciso garantir que você sempre tenha acesso a todas as contas e informações com privilégios e forneça um método para que isso ocorra. Isto serve para qualquer cenário: uma conta com privilégios é aquela que tem direito de fazer qualquer coisa em qualquer sistema. É o administrador interno. É a conta firecall. Toda a equipe de assistência técnica e todos os administradores que trabalham para você provavelmente conhecem essas contas.

Quando opta por implementar uma solução para gerenciar as senhas dessas contas compartilhadas, você está criando uma trilha de auditoria para a conta de administrador interna na qual ainda não existe uma. Você está obtendo uma senha fluida. E, como a solução é automatizada, você não perderá semanas em tempo de produtividade com a alteração dessas senhas. Por fim, como a solução fornece recursos de auditoria, sua empresa terá mais chances de ser aprovada na auditoria.

Uma abordagem automatizada

A forma mais eficiente de lidar com contas como essas é alterá-las regularmente para que nenhuma delas compartilhe a mesma senha. Com senhas compartilhadas, se um sistema ficar comprometido, o outro também ficará. Em outras palavras, não deve existir contas locais ou de domínio comuns.

Ao lidar com soluções automatizadas que podem gerenciar e gerar aleatoriamente essas senhas, não faça apenas o mínimo exigido por seus auditores. Por exemplo, por que usar apenas 8 caracteres para suas senhas quando você pode usar 15, 20 ou 127, sem muito esforço (consulte a Figura 2)?

Figura 2 Use a automação para criar senhas bem longas (clique na imagem para ampliá-la)

Além disso, considere a geração aleatória de contas privilegiadas todos os dias, como mostra a Figura 3. Não há motivo para fazer isso a cada 90 dias apenas, quando você pode fazê-lo mensal, bimestral ou mesmo diariamente. Afinal, se o procedimento for automatizado, não criará nenhum trabalho extra para você. Inclusive, se você fizer isso regularmente, forçará os usuários a recuperar as senhas na interface de recuperação auditada da ferramenta, fornecendo outra trilha de auditoria que antes não existia. (Se atualmente você armazena as senhas escritas dentro de um envelope em um cofre no canto escondido do escritório de alguém, não terá nenhuma trilha de auditoria para as senhas como teria se usasse uma solução de gerenciamento de senhas.)

Figura 3 Gere aleatoriamente suas contas com privilégios todos os dias (clique na imagem para ampliá-la)

Finalmente, você deve garantir que, ao serem recuperadas, as senhas sejam geradas aleatoriamente mais uma vez depois de um período fixo. Não estou me referindo aos trabalhos agendados de geração aleatória que você criou, mas de criar senhas a serem usadas uma única vez que sejam válidas durante apenas algumas horas, e não meses. Este método também forçará os usuários a recuperar as senhas na interface de recuperação auditada da ferramenta, fornecendo uma trilha de auditoria.

Pense nisso

A questão do gerenciamento de senhas para contas compartilhadas deve ser resolvida. Isso significa que você deve obter um método para alterar suas senhas com freqüência de forma confiável. A solução deve ser escalonável e flexível. Ela também deve fornecer acesso seguro às senhas e precisa auditar cada ação tomada pela ferramenta, bem como pelo usuário da ferramenta. Além disso, as senhas geradas precisam ser exclusivas em cada sistema para evitar uma invasão devido às informações compartilhadas da conta.

Muitos fornecedores já tratam desse problema há alguns anos, mas outros só começaram a se aventurar nesse território recentemente. Faça a sua pesquisa e experimente todas as novas ferramentas antes de comprar para garantir que a solução escolhida seja a mais adequada ao seu ambiente.

Chris Stoneff é gerente de produtos da Lieberman Software (liebsoft.com), uma desenvolvedora de software de gerenciamento e segurança de sistemas. A sua principal motivação não é saber apenas como, mas por que as coisas funcionam de uma determinada maneira.