Hackeando as senhas do Windows e do Linux
Por incrível que possa paracer, a senha de administrador não é algo "tão" poderoso assim no Windows, nem a de root na maioria das distribuições Linux. Serve mais como uma trava básica de proteção, nada além disso. Sem muito sufoco, é possível alterar a senha sem saber a anterior e mais, é possível fazer isso em poucos minutos e com ferramentas básicas. Vamos então descobrir como redefinir as senhas de administrador.Marcos Elias Picão
01/10/2007
Usuários comuns normalmente instalam o sistema às pressas e não anotam as senhas definidas para a conta de administrador. Isso quando eles instalam, porque muitos chamam os amigos mais experientes para essa tarefa. Administradores ficam de cabelos em pé na hora de configurar determinado recurso porque o responsável que tem a senha faltou no dia, ou pior, está de férias. Técnicos pegam os computadores e depois têm que ligar para os clientes, "cadê a senha do administrador?". Espertinhos querem obter acesso no PC bloqueado que encontraram na escola ou em casa. Seja qual for a sua situação, mesmo que ela esteja longe de estar listada aqui, quase todo mundo gostaria de saber como "recuperar" ou "redefinir" as senhas de administração dos sistemas operacionais.Por incrível que possa paracer, a senha de administrador não é algo "tão" poderoso assim no Windows, nem a de root na maioria das distribuições Linux. Serve mais como uma trava básica de proteção, nada além disso. Sem muito sufoco, é possível alterar a senha sem saber a anterior e mais, é possível fazer isso em poucos minutos e com ferramentas básicas. Mostrarei como redefinir as senhas de administrador (e conseqüentemente, todas as outras) de vários sistemas, várias versões do Windows (incluindo o XP e o "robusto" Windows Server 2003) e até mesmo do Linux, quando nenhuma outra medida de segurança impedir.
Antes, destaco que esses métodos são para as senha locais, e não de rede. Claro, se você "aplicar o golpe" no servidor da rede, poderá alterar a configuração e trocar as senhas desejadas ou o método de autenticação nas estações, mas invadir um servidor foge bem aos objetivos desse texto, que visa ser uma luz a administradores, técnicos ou mesmo usuários que precisam redefinir suas senhas por qualquer motivo. Assim como um martelo serve para construir uma casa ou matar alguém, é o conhecimento. Use de acordo com os seus princípios e sob sua inteira responsabilidade.
Um pouco sobre as senhas
A senhas normalmente são gravadas usando alguma codificação, e não como texto puro. Descobrir uma senha fuçando dentro de um arquivo atrás da "senha" diretamente é tempo perdido. Mesmo simples programas raramente gravam as senhas como texto puro. Quando não criptografadada, são gravados hashes, "sombras" das senhas. Por exemplo, ao cadastrar a senha, o sistema embaralha os caracteres e faz um cálculo com base neles, na quantidade de caracteres, na posição das letras e números, etc. E grava apenas o resultado dessa conta. Quando o usuário insere a senha, o sistema validador faz exatamente os mesmos cálculos e operações com a senha entrada, e caso o resultado seja igual ao armazenado, o acesso é liberado; caso contrário, não. A senha da pessoa, então, nunca ficaria gravada. Seria impossível recuperá-la (saber qual era) por meio do cálculo resultante. A possibilidade de ser impossível ou não a recuperação vai do algoritmo usado, normalmente se usam técnicas avançadas e já amplamente testadas. Descobrir senhas é uma tarefa difícil, especialmente quando não há erros conhecidos no algoritmo ou nos sistemas usados.
O método que não falha, digamos, é o da força bruta, onde são testadas todas as possibilidades de senhas.É uma loucura e dispenda grande tempo, pois brincando, a cada caractere que você adiciona numa senha aumenta radicalmente a quantidade de possibilidades. Com a velocidade do hardware atual, fica inviável descobrir senhas testando todas as possibilides para uma senha de 14 caracteres, por exemplo, incluindo letras, números, caracteres especiais e diferenciando maiúsculas de minúsculas. Seriam necessárias várias máquinas (um cluster cheio de máquinas, trabalhando em conjunto) e mesmo assim poderia demorar muito. Como o teste envolveria todas as possibilidades, uma hora ou outra a senha seria descoberta. Se com os PCs atuais já é demorado, manualmente então, nem pensar! Além disso, os sistemas normalmente bloqueiam o acesso por um tempo ao perceber que a senha foi inserida incorretamente muitas vezes. Você deve vasculhar diretamente na "fonte".
Um software que faz isso no Windows (exceto no 9x/Me) é o shareware Proactive Password Auditor (
http://www.elcomsoft.com/ppa.html). Ele é um software legal e de auditoria, desde que usado com a permissão do dono do computador (ou pelo próprio dono). Ele testa todas as possibilidades de senhas e exibe os resultados, e quanto tempo levou para encontrá-las. Isso permite testar a vunlerabilidade das senhas, como senhas curtas, com menos de 6 caracteres (que são descobertas rapidinho), que usam palavras conhecidas, etc. Para tal, ele pega diretamente o arquivo do banco de dados dos hashes das senhas do Windows. Humanamente isso seria impossível. Entenda por "humanamente" você tentar fuçar com um editor de textos ou mesmo hexadecimal; afinal o Proactive Password Auditor foi feito por homens, pessoas também, claro.
Outra forma de conseguir acesso a sistemas protegidos por senhas é a geração de uma nova senha, e não a "descoberta" da anterior. Com algumas "brechas", digamos, dos sistemas, é possível redefinir facilmente as senhas de vários sistemas operacionais. Vamos ver aqui idéias práticas de como redefinir as senhas em várias versões do Windows e na maioria das distribuições Linux.
style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-7847091248852948"
data-ad-slot="6687788651">
No Windows 95/98/Me
A senha desses sistemas é uma piada. Ela não serve para nada, literalmente. As contas de usuário das versões 9x/Me do Windows apenas servem para diferenciar os usuários, separando as configurações da área de trabalho e dos programas, e as pastas de arquivos pessoais. Mas não existe sistema de proteção, como controle de acesso em nível de conta, como há no Windows NT ou no Linux. Qualquer conta pode alterar qualquer arquivo ou conta de outra. A senha fica como um "complemento" para as pessoas fazerem "logon". Claro, sem a senha certa, uma pessoa não poderá se logar como outra, mas isso não impede, nessas versões do Windows, que ela tenha acesso aos arquivos das outras pessoas.
Os hashes das senhas do Windows 9x/Me ficam em arquivos de extensão ".pwd", na pasta do Windows (normalmente C:windows). Eles têm o mesmo nome do usuário. Por exemplo, "Marcos.pwd". Eis que basta apagar esse arquivo para que a conta fique "sem senha". No próximo logon, digitando o nome do usuário e uma senha qualquer, a nova senha será aplicada.
Fazer isso com quem desconheça o sistema nesse nível, fará com que a pessoa perca o acesso, pois a senha será "trocada".
No Windows NT/2000
A segurança do Windows NT 4.0 e 2000 (que vem a ser o NT 5.0) se mostra bastante frágil nesse aspecto. As informações das contas de usuários do sistema ficam no registro, salvas em arquivos criptografados no disco. Você talvez pense que o registro do Windows seja um único e grande arquivo, mas não. O registro das configurações, aquele que pode ser editado pelo "regedit" e por diversas ferramentas de terceios, é formado por vários arquivos espalhados em vários locais do sistema. Claro que não é desordenado, a maioria das configurações ficam em arquivos dentro da pasta do Windows ou de sistema, normalmente a C:winntsystem32. As configurações dos usuários (notadamente o conteúdo da chave HKEY_CURRENT_USER) ficam na pasta do perfil do usuário, que no Windows NT era C:winntprofiles, passando para C:Documents and settings, no 2000 e XP. Então, voltando na questão das senhas, o arquivo que contém as informações das contas dos usuários é o SAM, e fica na pasta C:winntsystem32config. Junto com ele normalmente há um SAM.log, além de uma cópia do SAM na pasta C:winntrepair.
A "falha" é que se esse arquivo for apagado, todas as informações das contas dos usuários são perdidas. Ou seja, se existiam os usuários "Maria" e "João", após apagar esses arquivos, eles não existirão mais. Os arquivos deles continuam, nas pastas dentro da pasta dos perfis dos usuários, apenas a conta será excluída.
A conta de administrador é especial, o sistema não fica sem ela; ou seja, ela não é "excluída" ao se apagar esses arquivos. Mas ficará sem senha. Bastará logar-se como administrador deixando o campo da senha em branco, e depois pode-se definir uma nova, cadastrar novos usuários, literalmente fazer o que quiser no sistema.
Entra aí uma pequena questão: como apagar esses arquivos? O NTFS não permite que usuários restritos apaguem ou modifiquem arquivos das pastas globais do sistema. E mesmo que a partição do sistema esteja formatada em FAT/FAT32, não daria. Esses arquivos do registro ficam bloqueados enquanto o Windows está em execução: não podem ser excluídos nem renomeados. Sabe-se lá se é para proteção sobre as senhas ou não, mas provavelmente não. Eles ficam bloqueados por serem arquivos binários abertos de forma especial pelo sistema, assim como uma DLL carregada em memória que não pode ser apagada, ou um executável ou mesmo arquivo de log qualquer aberto.
Para remover estes arquivos, a única saída é acessar com direito de escrita e leitura a partição do Windows, localizá-los e deletá-los,
sem o Windows estar em execução. Isso deve ser feito por um sistema externo. Seja um disquete de boot do bom e velho DOS (caso a partição esteja em FAT, ou do MS-DOS do Windows 98/Me, caso esteja em FAT32), um outro sistema em dual boot (pode ser até mesmo o Windows, inclusive a mesma versão, desde que seja uma outra instalação - em outra pasta), ou um sistema externo rodando do CD. Hoje em dia quase todos os liveCDs de Linux oferecem suporte à escrita em partições NTFS, o que não vem a ser um problema. Basta dar boot com o CD, montar as partições, ativar o suporte a escrita, se necessário (no Kurumin, por exemplo, vem desativado por padrão, por questões de segurança aos seus dados), e mandar ver. Pode até mesmo ser um liveCD do Windows. O Windows que roda do CD não existe oficialmente, mas é possível gerar um liveCD com o BartPE, uma vez escrevi sobre ele para o GdH:
http://www.guiadohardware.net/artigos/windows-roda-cd/No Windows XP/Server 2003
Baseado no Windows 2000 como foi, poderia valer o mesmo método, visto que os arquivos de configuração são os mesmos. Mas a "falha" foi corrigida, digamos: apagando o SAM, o Windows XP ou o Server 2003 não inicia. Na tela de logon, aparece uma mensagem dizendo que não foi possível acessar o banco de dados de contas, e o sistema é reiniciado - reiniciando novamente ao chegar na tela de logon, entrando num "loop". Infelizmente, digamos, apesar de ter sido detectado e corrigido no Windows XP, isso não foi corrigido no Windows 2000, pelo menos não até o Service Pack 4.
Mas não desanime, pode ser mais fácil do que você espera. Aproveitando-se de uma outra brecha deixada pelo sistema, é fácil redefinir as senhas das contas locais do Windows XP e até mesmo do Windows Server 2003, que tem boa parte do código baseado no XP.
Eles têm o assistente de acessibilidade, recurso que traz algumas facilidades para uma leve compatibilidade com usuários deficientes, que possuam leves deficiências motoras ou audiovisuais. Além do gerenciador de utilitários, acessível pelo atalho Win + U, há as opções de acessibilidade, que são abertas ao ficar segurando SHIFT direita por 8 segundos. Isso vale também durante a tela de logon, para permitir que usuários com necessidades especiais alterem as opções de acessibilidade também durante o logon, sem precisar de outras pessoas.
A "brecha", digamos, é que a conta usada no Windows XP/2003 para o programa configurador das opções de acessibilidade, possui direitos administrativos. Rodando outro programa no lugar das opções de acessibilidade, esse programa será rodado como administrador, e poderá fazer tudo o que um administrador poderia. Entre as coisas, pode trocar a senha de administrador, excluir e criar novas contas, enfim, fazer a festa no sistema.
A idéia é trocar o arquivo chamado ao segurar SHIFT por 8 segundos. Poderia ser mais difícil, por exemplo, trocando o "utilman.exe" (o que é aberto ao teclar Win + U) não funciona. Ele deve ser chamado com alguma função ou parâmetro especial, que o programa trocado obviamente não possui. Mas o arquivo chamado ao segurar SHIFT direita por 8 segundos é aberto diretamente, e vem a ser o "sethc.exe", que fica na pasta C:windowssystem32.
Idéia básica: entrar na pasta system32, excluir o arquivo "sethc.exe"e copiar um outro, dando o nome de "sethc.exe" à cópia. Um bem visado é o prompt de comando, o "cmd.exe". Assim, ao segurar SHIFT por 8 segundos, em vez das opções de acessibilidade, será aberto o prompt de comando, e com direitos administrativos! Aí bastará rodar "control userpasswords2" para redefinir as senhas de qualquer conta. Uma falha imperdoável no Windows Server 2003, que é voltado a empresas, mas perfeitamente possível. Pelos meus testes, não sei nas versões recentes, pelo menos o Windows XP SP2 e o Windows Server 2003 sem service pack possuem essa falha.
Nota: na tela de logon que lista os usuários, o prompt de comando (ou o arquivo "sethc.exe", mais precisamente) poderá ficar oculto, por trás dela. Para não se atrapalhar e exibi-lo corretamente, alterne para o logon clássico, teclando duas vezes CTRL + ALT + DEL. (No Windows NT, teclar duas vezes CTRL + ALT + DEL não faz com que o sistema seja reiniciado; se você não acompanhou o Windows 2000/XP e só conhece o 9x/Me, é bom saber disso :)
O arquivo pode ser substituído facilmente se o usuário possuir uma conta local, mesmo que restrita, e se o HD estiver formatado em FAT/FAT32. Usando o próprio Explorer pode-se trocar o arquivo, já que ele não fica aberto o tempo todo. Se o HD estiver formatado em NTFS, onde os usuários limitados não têm permissão de escrita nas pastas de sistema do Windows, e/ou se o usuário for um intruso que não possui sequer conta local, basta usar um sistema alternativo, que rode do CD. O mais comum é o Linux, diversas distros, como o Kurumin :) Isso considerando que o sistema possa ler e escrever em NTFS, o que é o caso do Kurumin 7.
Nota: se você trocar o arquivo com o Windows em execução, ele poderá tentar recuperar imediatamente o arquivo a partir do cache dos arquivos do sistema. Um excelente recurso incluído no Windows 2000 ou superior, para evitar que arquivos do sistema sejam indevidamente alterados, o que causava um caos tremendo na época do Windows 98 (tudo bem que nada é perfeito, mas ajuda). Para driblar essa proteção, limpe a pasta dllcache (da pasta C:windowssystem32), não apague ela, mas apague tudo o que estiver dentro dela. Não se preocupe, pois são apenas cópias dos arquivos do Windows. Não deixe também o CD do Windows na unidade, e se houver uma pasta i386 no seu HD com os arquivos de instalação do Windows, renomeia-a temporariamente (pois ele poderá recuperar os arquivos a partir dela; essa pasta contém o conteúdo do CD de instalação, e normalmente existe em sistemas OEM, que vêm com o Windows pré-instalado). Sem fazer isso, o sethc.exe poderá ser restaurado imediatamente quando você exclui-lo. Usando um sistema externo para fazer a substituição, não há esse risco.
Rodando o prompt de comando como administrador, você pode chamar programas, que serão executados com privilégios de administrador. Rode "
control userpasswords2" para criar novos usuários ou redefinir a senha de qualquer conta de usuário, incluindo, é claro, do administrador.
Se preferir, use o console de gerenciamento do computador (
compmgmt.msc), e clique em "Usuários e grupos locais". Eu me surpreendi, pois foi possível rodar até o Explorer! Veja alguns screenshots. Para decepção dos usuários que confiam tanto na segurança do Windows, saiba que estas imagens não foram montadas num programa gráfico, foram todas obtidas com o famoso "Print Screen", salvas originariamente no Paint, também rodando sem fazer logon:
style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-7847091248852948"
data-ad-slot="6687788651">
Ao dar o comando "explorer.exe" no prompt, o Explorer foi aberto. Na primeira vez, definiu o papel de parede "Alegria", que é padrão, e ainda ofereceu o "Tour do Windows". Observe a tela de logon arrastada para o topo. Nenhuma senha foi necessária.
Criação de uma nova conta de usuário, com o comando control userpasswords2.
Ao dar CTRL+ALT+DEL, abriu-se o Gerenciador deTarefas. Pelo visto, ele ficou instável :( Isso ocorreu com alguns outros programas também. No entanto, após criar uma conta e se logar com ela, o acesso ao sistema ficava "normal".
Clicando com o direito na área de trabalho e em "Propriedades", pode-se alterar os temas. Veja, deixei o prateado para a tela de logon! Até que esta dica pode ser útil para mera personalização, você altera as opções visuais da tela de logon sem precisar tocar no registro.
Percebi alguns problemas de estabilidade ao rodar programas deste modo, como no gerenciador de tarefas, o copiar/colar arquivos pelo Explorer não funcionava, etc. Depois de uns 5 minutos o Explorer era fechado sozinho, não sei se isso foi programado ou se é devido algum erro não esperado. Afinal não é esperado "fazer logon sem fazer logon", com a conta de usuário SYSTEM. Mas ele podia ser aberto a qualquer momento, digitando-se "explorer" no prompt de comando novamente.
E como se proteger no XP/Server 2003?
Uma dica para proteção, caso você tenha computadores com Windows XP na empresa (ou em qualquer lugar que seja), e queira se prevenir, é usar o "syskey". Ele é um programinha não documentado que vem com o Windows, e permite alterar a forma de criptografia das contas de usuários locais. Você pode configurar o Windows para solicitar uma senha especial, independentemente de qualquer conta de usuário, a toda inicialização. Se quiser mais proteção, pode requerer um disquete obrigatório. Sem ele, não se usa o Windows. Para isso basta abrir o SysKey, digitando syskey no "Executar".
Tela do SysKey. Clique em "Atualizar" para alterar a proteção do sistema das contas de usuários. Não perca a senha nem o disquete, se for o caso, senão, adeus contas de usuários (mas os arquivos permanecem em C:Documents and settings). Você poderá instalar o Windows do zero em outra pasta, mas perderá acesso a qualquer arquivo criptografado em partições NTFS (se você possuir arquivos protegidos desta forma, é claro).
Pelo menos em teoria, ao ativar a criptografia do banco de dados de contas de usuários dessa forma, o Windows não tem como permitir o logon de ninguém, simplesmente porque não tem as informações das contas, que estariam codificadas com base na senha especial ou no arquivo do disquete. Pelo que testei, o atalho de segurar SHIFT por 8 segundos não funcionou na tela que pede a senha especial (do syskey).
No Linux
Muitos usuários fãs do Linux podem até me criticar por escrever este texto... Mas falei de como fazer isso no Windows, e se dá, porque não também no pingüim?! Segurança zero! Isso é bom para incentivar as empresas e o pessoal de TI (ou até mesmo em casa) a aplicarem medidas físicas de segurança, pois não basta via software.
O Linux tem uma ferramenta que pode ser um perigo nas mãos erradas:
chroot. Incluso em praticamente todas as distribuições (pelo menos, em todas as distribuições sérias e que visem uma boa administração), ele permite obter acesso como root em um sistema Linux, desde que o usuário já possua acesso como root em outro sistema Linux. Em outras palavras, ele monta a pasta raíz "/" numa partição onde outro Linux esteja instalado, e dá poder de root ao operador. Isso pode ser utilizado em manutenção, para editar e/ou recuperar arquivos, e inclusive alterar qualquer senha, configurar permissões de arquivos, etc. Como o Carlos E. Morimoto citou no seu livro "Redes e Servidores Linux",
em outras palavras: "Se um usuário der boot com um live-CD no seu servidor, o servidor não será mais seu; será dele". Pois bem...
Basta dar boot com um liveCD do Linux, como o Kurumin e uma infinidade de outros. A única exigência base é que o sistema reconheça o sistema de arquivos onde o Linux a ser "invadido" esteja instalado; em se tratando de Linux, este sistema não será NTFS e a preocupação com isso (acesso em NTFS) não existe. Dado o boot, você deve obter acesso de root no "seu" sistema, enquanto ele está rodando do CD. Em boa parte das distribuições liveCD, não dá para trocar a senha padrão, e ninguém normalmente sabe qual é ela :P Com o Kurumin Linux, dá e é fácil. Ele possui um script "Definir senhas", localizado na área de trabalho. Basta abri-lo para trocar a senha, tanto do usuário "Kurumin" que é usado no live-CD, como o do root. Há também no menu "Configurações do sistema", um item para alterar a senha de root. Isso é muito útil para instalar programas rodando do CD, ou alterar algumas configurações que exijam o reinício do X (onde para se logar depois, será preciso digitar a senha). Se você não estiver usando o Kurumin, pode tentar isso: algumas distros deixam outros consoles logados como root, tecle CTRL + ALT + F1 a F6, e veja se em algum aparece o prompt #. Se tiver, estará logado já como root, aí fica bem fácil e nem precisará usar a interface gráfica (podendo também trocar a senha do liveCD digitando
passwd).
Tendo acesso como root rodando do CD, você é praticamente dono do computador :)
Agora você precisa abrir um terminal, montar a partição que contém o sistema a ser "atacado", e mandar ver. A montagem da partição deve incluir o tipo do sistema de arquivos utilizado, montá-la manualmente não será algo tão simples para quem não é usuário do Linux. Para facilitar, você pode abrir o "Meu computador" do Linux (estou dando como exemplo, o Kurumin), e montar a partição a partir dali, clicando nela com o direito e escolhendo "Ação > Montar".
Com a partição montada, abra um terminal (pode ser o Konsole, XTerm ou qualquer outro que você queira). Como o usuário padrão do liveCD provavelmente estará logado, e não o root, você precisa alternar para o root. Use o comando
su. Digite su, tecle [enter], e ele pedirá a senha de root. Use a senha que você definiu para o sistema rodando do CD. Ao acessar como root, o símbolo do prompt mudará de $ para #, indicando que os comandos são executados com poder de superusuário (equivale ao "Administrador", no Windows). No Ubuntu ou em outras onde o root vem desativado, você pode usar o sudo.
Dica: em algumas distros com o sudo ativado, você pode digitar sudo passwd com o login de usuário, para definir a senha de root do sistema rodando do CD. Com ela, você acessa um terminal como root e então usa o chroot, comentado a seguir.
Agora digite o comando
chroot, passando como primeiro parâmetro o ponto de montagem da partição do sistema no HD que será atacado. Como falei, a partição já deverá estar montada. Por exemplo,
chroot /mnt/hda3.
Se tudo estiver ok, o sistema dentro do prompt não será mais o seu do CD, mas sim o que estiver na partição montada :) Aí é só sair fazendo a festa.
Para alterar a senha de root, digite
passwd e tecle [enter]. Ele exibirá um prompt "Enter new UNIX Password:", então digite a senha desejada e tecle [enter]. Ele pede para confirmar a senha, afinal é uma medida importante para evitar erros de digitação.
Para alterar a senha de um usuário do sistema no HD, digite passwd seguido pelo nome do usuário. Por exemplo,
passwd mah.
Veja um prompt onde troquei a senha do usuário kurumin e de root, de uma instalação do Kurumin no HD, usando um liveCD do Kubuntu:
Nesse caso precisei apenas usar o sudo para realizar ações como root, visto que no Ubuntu a conta de root vem desativada.
O chroot é uma ferramenta muito poderosa usada em recuperação e administração, use com responsabilidade. Ele foi projetado para rodar apenas comandos em modo texto. Mas, com certos artifícios, é até possível rodar programas gráficos do outro sistema; mas isso foge aos objetivos desse texto.
Algumas distribuições talvez implementem outros sistemas para segurança das senhas, inviabilizando este método. Mas pode crer, funciona na grande esmagadora maioria.
A responsabilidade é de cada um
Algumas pessoas particularmente me criticam por escrever "dicas" com este teor. Não é bem por aí. Quanto mais esta informação for divulgada, mais gente se cuidará e, de certa forma, pressionará a empresa produtora do Windows a rever algumas coisas nos seus sistemas antes de soltá-los. Vai dizer que o Tio Bill não sabia que durante a tela de logon a conta usada possui privilégios administrativos? Tudo bem, errar é humano. Antes divulgar esta informação de forma clara e técnica e permitir que mais técnicos e profissionais de TI se mexam para proteger os sistemas dos seus clientes, do que não divulgá-la, ocultá-la. Ela não ficará oculta, um passa para o outro, e se nada for feio para tentar proteger os sistemas, muitos espertinhos se aproveitarão desse mole que o Windows dá. Alunos em escolas e bibliotecas, clientes em lan houses, funcionários em empresas, e até mesmo - porque não? - o seu filho, no seu computador.
Além dessa questão, é uma mão na roda para quem precisa recuperar a senha pessoal, ou criar uma nova conta de usuário, se perder acesso por qualquer motivo às configurações do computador. Uma dica que deve fazer parte da mala de ferramentas de qualquer técnico Windows que se preze. Engraçado que um bom técnico Windows deve ter um live-CD do Linux, não é?
style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-7847091248852948"
data-ad-slot="6687788651">
Concluindo
Isso mostra que a senha de administrador no Windows e a de root no Linux podem não valer nada. A idéia é de que a conta de administrador/root é segura, potente, de que realmente o sistema está protegido. Mas não é isso que ocorre. O acesso local, quando possível, é uma das formas mais fáceis de invadir um computador alheio. Portanto, pense em soluções físicas de proteção. Gabinetes com cadeado, câmeras de segurança onde tiver computadores importantes, boot via CD/DVD e USB desativado... Só para não falar da segurança paranóica aplicada em data-centers (paranóica, mas essencial!). Enfim, cuide-se.
Créditos:
http://www.guiadohardware.net/tutoriais/hackeando-senhas-windows-linux/ 
