Devido ao grande número de perguntas referente a este assunto resolvi escrever este artigo, pois notei que muitas vezes as respostas foram enviadas sem antes terem sido testadas. Esse artigo ensinará a quebrar a senha de root usando uma live distro ou alguma outra instalação que você possua a senha de root, portanto servirá para qualquer distribuição.
[2] Comentário enviado por intelitec em 02/12/2004 - 09:59h
mto show a dica..... mto util tb.... c vc n kizer q ng mude sua senha d root, coloque uma senha na bios e deixe o boot pelo hd, no caso d serum servidor, mantenha-o em um lugar seguro....
PoPo
[6] Comentário enviado por removido em 02/12/2004 - 10:46h
O marcon falou algo muito sério: é uma VULNERABILIDADE DE SEGURANÇA NO LINUX ADVINDA DA CRIAÇÃO DIOS LIVE CDS...
tEMOS DE DESENVOLVER UMA "DEFESA" PARA ISSO...
[8] Comentário enviado por morvan em 02/12/2004 - 12:05h
Jonatas, sugiriria apenas, ao invés de usar o "$ df", utilizar "fdisk -l /dev/hd?", pois o fdisk mostrará todas as partições em hd?, ao contrário do df, que mostrará só os FileSystems montados.
veja o extrato de um man df:
" df - report filesystem disk space usage
SYNOPSIS
df [OPTION]... [FILE]...
DESCRIPTION
This manual page documents the GNU version of df. df displays the
amount of disk space available on the filesystem containing each file
name argument. If no file name is given, the space available on all
currently mounted filesystems is shown. Disk space is shown in 1K
blocks by default, unless the environment variable POSIXLY_CORRECT is
set, in which case 512-byte blocks are used.
If an argument is the absolute file name of a disk device node contain-
ing a mounted filesystem, df shows the space available on that filesys-
tem rather than on the filesystem containing the device node (which is
always the root filesystem). This version of df cannot show the space
available on unmounted filesystems, because on most kinds of systems
doing so requires very nonportable intimate knowledge of filesystem
structures".
um abraço e parabéns pelo artigo.
[9] Comentário enviado por mundoguero em 02/12/2004 - 13:02h
Caros
Não se trata de brexa de seguança nem nada disso. A segurança de um servidor não é só lógica, não adianta escolher uma senha forte, instalar e configurar um superfirewall se alguém for lá arrancar o micro da tomada! A segurança física é muitas vezes mais importante que a lógica, principalmente em grandes empresas. Tudo tem que ser pensado como um conjunto de normas a fim de se evitar o pior.
[10] Comentário enviado por mundoguero em 02/12/2004 - 13:18h
Morvan
Escrevi este artigo sem muito tempo, obrigado pelo complemento. Faltou também explicar o comando
#chroot / vi /mnt/hdx/etc/shadow
Ele apenas faz com que o sistema adote outro ponto qualquer do file system como sendo o raíz e interpreta o comando que vier a seguir.
Assim se apenas montassemos a partição e tentassemos apagar a senha de root da partição /mnt/hdx/etc/shadow ele iria retornar um erro de falta de permissão, pois somente o root daquele file system poderia fazê-lo.
[12] Comentário enviado por fabio em 02/12/2004 - 14:16h
Anderson,
O LIDS está na imagem do kernel, mas se você bootar a partir do live CD, o LIDS não estará carregado, não vai adiantar.
Antonio, isso não é falha de segurança do Linux, com acesso físico a máquina, é praticamente impossível deter os invasores. Por exemplo, tenho aqui em casa uma distro de 5MB usada pra trocar senha de usuários Windows.
Não sei se já existe, mas uma possível solução seria criptografar os arquivos do HD. Alguém sabe se existe algo nesse tipo?
[13] Comentário enviado por removido em 02/12/2004 - 14:32h
Essa dica é muito boa partindo do pressuposto que o acesso ao computador seja esclusivamente via senha do root.
Se isso não for necessário e somente no caso de vc ter acesso à máquina, bastaria o comando:
$ sudo passwd
Enter new unix password: *********
Retype new unix password:*********
Passwd: Password updated succesfully
[14] Comentário enviado por morvan em 02/12/2004 - 15:40h
Jonatas, o meu comentário não visou - jamais o farei - a enxovalhar o seu artigo, apenas, como você mesmo comentou, um complemento. com relação à questão suscitada (segurança), estão felizes os que não vêem a segurança como algo meramente em nível da caixa; de fato, em empresas que lidam com segurança - no sentido mais rigoroso - após a sessão de "boot" o sistema de IO (principalmente teclado e mouse) é travado e ao sair do trabalho a 'galera' leva consigo os mesmos. senha no bios, também, só resolve se se constranger o acesso à caixa, pois um simples RESET do bios poria tudo abaixo. lembrem-se também dos "Bioses Erasers". qualquer 'minino' conhecedor do Debug (MsDos) ou do Dbg, com poucas linhas ASM faria o 'trabalho sujo'.
um abraço.
[16] Comentário enviado por FMC em 03/12/2004 - 10:45h
Para ter controle total da distro que está no HD a forma mais simples é bootar pelo liveCD, abrir terminal, logar como root e depois usar o chroot da seguinte forma:
#chroot <ponto de montagem> /bin/bash
depois basta
#passwd
senha
confirma
Pronto! :-)
Existem formas de criptografar o HD, saiu uma matéria sobre isso na segunda edição da Linux Magazine, da trabalho, mas acho que vale a pena!
[17] Comentário enviado por mundoguero em 03/12/2004 - 14:30h
Galera! Este foi justamente o motivo pelo qual me levou a escrever este artigo! Eu tentei todas essas manhas que foram postadas aqui, nenhuma funciona efetivamente, a não ser a do sudo, mas ele tem que estar instalado e o usuário previamente cadastrado para poder fazer isso. Se tentar dar o comando
"#chroot / /mnt/hda3 /bin/bash" ou
"#chroot /mnt/hda3
# mount /proc
# passwd"
Teoricamene deveria funcionar, mas o que temos?:
passwd: Authentication token manipulation error
O porquê eu não sei ainda,seria uma boa coisa para se pesquisar, mas no meu raciocínio tem algo relacionado ao processo de hash da senha de root, tipo o sistema que cria a senha é o único capaz de entendê-lá e portanto alterá-la, lembre-se, o processo de criptografia é uni-direcional. Um sistema não seria capaz de alterar a senha criada por um outro.
Portanto foi necessário eliminá-la para que então pudessemos recriar no sistema de origem.
Por favor corrijam-me se estiver falando besteira.
Todos os complementos a este artigo são bem vindos!
[22] Comentário enviado por hra em 04/05/2005 - 17:26h
Ótima dica, é uma coisa que passa despercebida pela maioria das pessoas:
O acesso fisico ao computador significa o mesmo que ACESSO TOTAL.
Colocar senha na BIOS não resolve, pois basta abrir a cpu, resetar a bios (demora 2 minutos, ou menos, pra fazer isso) e lá se vai a senha.
A solução definitiva é criptografar o disco rígido. Tem um artigo recente no VOL que ensina a fazer isso. Aí além da senha do root terá uma outra senha a ser digitada no momento do boot, e essa senha não está gravada em lugar nenhum, nem é possível "limpa-la" com um LiveCd.
A questão de não ser possível usar um passwd é por causa da hash de criptografia mesmo, esta é carregada pelo kernel no momento do boot e como o boot é do LiveCd então não combina com a hash do hd montado.
Isso é outro ponto interessante, uma vez que todos os LiveCds são cópias, em todos eles está gravada a mesma hash de criptografia, que foi gerada no momento da instalação do linux original, que foi usado como base para o LiveCd. Isso quer dizer que qualquer um que tenha um cd do kurumin pode [hipotéticamente] decriptografar o arquivo de senhas de outro kurumin. Mas isso é teoria e assunto pra um artigo inteiro, e não é tão simples como parece.
O linux não é inviolável, só é mais seguro que o windows.
Parabém ao autor, e lembrando, exise também uma possibilidade extra para limpar a senha do root que é mandar o lilo entrar em modo mono-usuário, daí não pede senha nenhuma.
[24] Comentário enviado por miltonb em 23/12/2005 - 10:36h
Achei todos os comentários válidos... Mas, esqueceram de uma questão básica de que vale uma segurança de alto nível um sistema operacional se a segurança de acesso fisíco do servidor não existe... Onde "qualquer um" pode chegar no servidor e ao invés de quebra senha de root levar peças ou micro todo.
Portanto e bom ficar claro que nenhuma segurança de software é eficaz se alguém tem acesso físico. então para 99 % das dicas acima a segurança física do servidor resolve.
[25] Comentário enviado por Bruno Faria em 15/02/2006 - 20:36h
Colocar senha na BIOS adianta de nada se o acesso físico está disponível. Sabe-se que em segundos é possível resetar a BIOS para seu estado original de tal forma que a senha simplesmente desaparece. Ai vc coloca um live cd e o servidor estará vulnerável.
[29] Comentário enviado por Bruno Faria em 07/12/2006 - 20:45h
Amigo, pegue 15 reais, vah a banca mais proxima e compre uma revista com um livecd. Ou dependendo da hora na lan house ai na sua cidade, compre algumas horas e queime uma midia ;)
[33] Comentário enviado por dill_tche em 23/08/2007 - 17:05h
acesso fisico é uma questão tratada a tempo e nao tem o que ver... se nao fosse necessario ter uma sala com acesso restrito, todos os servidores estariam nas recepções das empresas. Camera, crachá, senha de porta.... Isso é segurança... A sala de Ti nunca é o corredor da empresa, nao foi feita para pessoas de outros setores estarem circulando e sala dos servidores nem se fala, qualquer sistema com um live cd já era...
[34] Comentário enviado por fabioarnoni em 03/01/2008 - 21:34h
Parabéns, muito bom o artigo !!! Estou passando por um problema sério aqui onde trabalho, algumas pessoas sabem desse macete mas para windows XP... Já coloquei senha na BIOS das maquinas e tirei os drives de boot mas quando ligam, elas tem aquela maldita opção de ficar apertando F8 e ai aparecem todos os drives e você escolhe um para bootar, ou seja, a senha não adianta nada e nada se resolve e o pior de tudo é que não existe uma opção no BIOS que desabilite essa opção na inicialização ... Essa questão de poder tirar senha de admins via live CDs é muito séria pois usuarios comuns tem cada vez mais acesso à essas coisas e como se proteger em uma escola com 80 computadores onde não há como mudar o BIOS ????
[35] Comentário enviado por LeoWalker em 23/01/2008 - 15:16h
Senhores.... pode-se montar um live sem esquentar a cabeça num simples pen-drive. o que pega mais ainda ... ou seja, o cara vai la e arranca o drive de CD mas ai temos um coleguinha esperto e cópia o live num pendrive, vai la e f@#*@ tudo.....E uma questão complicada, o correto é um NOC ou CPD e responsabilizar alguem pelas maquinas. " detalhe a sala deve sempre ficar trancada ... rsrsrs "
[36] Comentário enviado por dill_tche em 03/06/2009 - 16:47h
Valeu pela dica Jonatas, hoje precisei fazer isso. No Suse 11.1 tirei entre os dois pontos e quando fui entrar deu um erro, como se eu tivesse já tentando as 3 chances da senha. Então voltei como o LIVE CD do OpenSUSE mesmo, e coloquei entre os dois pontos a mesma senha criptografada do meu usuario restrito e na hora de entrar deu certo. Aos que pensam que o linux com isso não é seguro, estudem um pouco de segurança de informação, tem algo falando sobre segurança física. ZZZzzzZZZzzzzZzz
[37] Comentário enviado por brites2012 em 23/09/2012 - 22:59h
Oi pessoal,
Desculpa a ignorância, mas sou iniciante em linux.
Tentei reproduzir essa alteração em um Suse, que não uso mais.
Fiz todo o procedimento, alterei o arquivo shadow como deveria ser.
Mas como o Suse está habilitado para sempre iniciar com o meu usuário pessoal, que não é o root, não estou conseguindo alterar a senha do root novamente.
Como faço para foçar a inicialização direto pelo root ?
[38] Comentário enviado por brites2012 em 24/09/2012 - 01:03h
Oi pessoal,
Recoloquei a senha no shadow, rebutei a máquina, mudei o inittab para 3 e tornei a limpar a senha do root novamente.
Dae quando vou informar o usuário root, o sistema nem pede a senha, me retorna que a senha está incorreta.
Alguém tem alguma dica para essa situação ?
[39] Comentário enviado por Morvan em 24/09/2012 - 12:00h
Bom dia.
Respondendo a brites2012 (e, eventualmente, a outrem!):
Brites, acesse a partição (monte-a) com um CD de recuperação e, dentro da partição do Sistema, altere o arquivo /etc/sudoers, colocando o seu usuário na relação de SUDOS.
Há uma linha com esta sintaxe (ou algo próximo disso):
root ALL (ALL) (ALL).
Replique-a, colocando, ao invés do nome do root, o seu usuário. Quando você autenticar (em modo texto, de preferência) digite: sudo passwd root e entre a sua senha e, em seguida, a nova senha do root.