Como recuperar a senha de root usando uma live distro

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.

[ Hits: 323.783 ]

Por: Jonatas Almeida Brisotti em 02/12/2004


Requisitos



  • Uma instalação Linux que você não possui a senha de root.
  • Uma live distro (distribuições que rodam direto do CD ou do disquete) ou uma outra instalação que você possua a senha de root.
  • Micro com drive de CD ROM ou disquete, ou disposição para instalar o HD em outra máquina.

    Próxima página

Páginas do artigo
   1. Requisitos
   2. Mãos a obra
   3. Mudando a senha
   4. Logando como root novamente
Outros artigos deste autor

Instalando o VMware no Conectiva 10

Implementando prioridade nos serviços com TOS no Iptables

Leitura recomendada

Recuperação do arquivo sudoers - comandos su e sudo não funcionam mais [Resolvido]

Diminua os vetores de exploração, conheça o DOAS

Backup/Restore de uma cópia fiel de um HD utilizando o DD

OpenBSD IDS - Solução Snort e BASE

Aquisição Estática de Dados em Computação Forense

  
Comentários
[1] Comentário enviado por gustavo_marcon em 02/12/2004 - 09:14h

Ótima dica pra quando se perde a senha, mas qualquer pessoa poderá alterar a senha root da máquina desde que tenha um live cd então.

Sabe como configurar o linux de alguma forma onde seja "impossível" de alterar a senha root (ou de qualquer outro user) ou quase isso??

Pois pude entender isso como uma "brecha de segurança"!

[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

[3] Comentário enviado por gustavo_marcon em 02/12/2004 - 10:03h

Será que essa é realmente a única solução pra ñ alterarem a senha ??

[4] Comentário enviado por y2h4ck em 02/12/2004 - 10:30h

gustavo_marcon...
deixe o seu linux com o LIDS instalado... e coloque o seu /etc/shadow como DENY
assim ninguem pode altera-lo ;)

[5] Comentário enviado por gustavo_marcon em 02/12/2004 - 10:35h

legal vou dar uma olhada nisso, valeu pela dica...

[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...

[7] Comentário enviado por felipebalbi em 02/12/2004 - 11:45h

Mto bom.
Tendo acesso físico à máquina, a senha do root não importa mais.

O jeito agora é por senha na BIOS e configurar pra dar boot direto do HD.

=P

[]'s
Felipe Balbi

[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.

[11] Comentário enviado por jllucca em 02/12/2004 - 13:33h

Oi,

apenas uma duvida. Não daria pra usar o chroot pra "entrar" no HD e partir dai alterar a senha?

Depois de montar o HD, algo parecido com:

# chroot /mnt/hda3
# mount /proc
# passwd -
# logout

O que me impede de "entrar" no HD e usar "passwd" pra alterar a senha???

[]'s

[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?

[]'s

[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

Fim do problema. Acesse com a nova senha criada.

[]s!

[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.

[15] Comentário enviado por streetlinux em 02/12/2004 - 22:42h

Parabéns pelo artigo. Muito bom.

[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!

Flw!

[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!

[18] Comentário enviado por schatten em 04/12/2004 - 12:48h

Eu já aprendi isto num curso que fiz, porém com alguma variações...

[19] Comentário enviado por schatten em 04/12/2004 - 12:49h

Poir isto roost e admins em geral, coloquem senha na bios e nunca deixem os boots via cd habilitados nos servidores...

[20] Comentário enviado por leo_mxs em 05/12/2004 - 12:07h

Essa falha de segurança pode ser usada pra invadirem o meu pc ou mesmo para que um virus, altere minha configurações ???

E alguém pode explicar melhor esse lance de colocar o boot na BiOS ???

[21] Comentário enviado por lucassaqua em 15/01/2005 - 20:08h

aqui não funcionou!!!...eu mudo td certinho no arquivo shadow...mas quando vo logar da a msm coisa...login incorrect...uso lilo 2.22

[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.

HRA

[23] Comentário enviado por ysnapfabiano em 17/11/2005 - 12:21h

Todo mundo esta se preocupando com o boot do micro no setup. Devemos nos lembrar que os gerenciadores de partida tambem tem as suas vulnerabilidades.

[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.

[26] Comentário enviado por feraf em 30/04/2006 - 23:15h

Artigos como esses devem sempre ser guardos. Me salvou um bocado de trabalho de reinstalar tudo só por que perdi a senha do root. Valeu cara!!

[27] Comentário enviado por badfly em 12/09/2006 - 13:36h

Blz digamos que eu tenha acesso a root, mais naum saiba a senha tem como de alguma maneire eu ver qual e a senha.

[28] Comentário enviado por danilopalhano em 06/12/2006 - 13:27h

Muito boa essa dica. Mas não tenho uma distro para eu realizar o procedimento. E agora, o que eu faço?

[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 ;)

[30] Comentário enviado por K1LL -9 em 09/12/2006 - 15:16h

Pensando com meus botões ...

O camarada que se prestar pra criptografar um hd e e ter uma política de gerenciamento de senhas .... do tipo:

"Putz .... qual é a senha mesmo ?"

É um verdadeiro ol$%# *? C$@ e tem mais que se F$%#!! mesmo.

Será que terá ambientes corporativos onde se aventurem a isso, só um saberá a senha e não tenha guardado em nenhum outro lugar ?


[31] Comentário enviado por K1LL -9 em 09/12/2006 - 15:22h

Mas hra , creio que se o kernel for recompilado, em vez de usar uma imagem de kernel fornecida na instalação, o hash não irá ser diferente ?

Aí não adiantará usar o "mesmo kurumin" slack ou debian.


[32] Comentário enviado por leloguitar em 13/07/2007 - 15:03h

ah fala sério meu..
nada v issu de criptografar dados do hd
tem alguma coisa de valro la???
issu só serve pra kem tem algo q vale mto dentro do hd

pra kem tem arkivos comun nao precisa...

agora essa dica eh mto precisa... aiahuiau
abraços...

[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.

Abraços,

Morvan, Usuário Linux #433640.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts