Malware, Vírus e Hacking. Estamos seguros usando Linux?

A pergunta que ainda não se cala entre veteranos e novatos no GNU/Linux será respondida neste artigo, existe vírus para o Linux? Neste artigo eu descrevo quais são as verdadeiras ameaças para usuários do GNU/Linux e o que é só especulação da mídia e como se defender.

[ Hits: 43.523 ]

Por: M4iir1c10 em 11/08/2015 | Blog: https://github.com/mauricioph


Invadindo o seu próprio Linux



Antes de escrever sobre isso me deixe esclarecer um detalhe: tudo que eu explico é para os fins educativos e de proteção, você não deve usar esses métodos para tirar proveito de sistemas alheios. Nem eu ou o VOL se responsabiliza por como você vai usar esse conhecimento, hacking pode levar a cadeia, é um ato ilegal. E como fins educativos, se você quiser testar os métodos que eu descrevo aqui faça em seu próprio sistema ou em uma máquina virtual. Se o computador que você usa é compartilhado com outros membros da família, não execute esses métodos se você não é o principal dono do computador.
Não é por erro que o texto acima foi copiado da página anterior e está nessa página, eu sei que alguns vão pular direto para esse tópico, assim sendo você não é inocente, você foi avisado. Leia as outras páginas também e tire proveito completo desse artigo.

O Linux como foi dito tem mais segurança que os demais sistemas, porém existe algo chamado de backdoor ou portas dos fundos, as backdoors não são falhas mas são facilidades criadas pelos desenvolvedores para recuperar o sistema caso algo dê errado, o Linux tem 3 backdoors para restituir o acesso ao sistema. Eu não aconselho você a fechar esses backdoors mas deixar eles mais seguros. Alguns sistemas tem diferenças de como tirar proveito do backdoor porém leve em consideração que um erro cometido pode deixar você sem acesso ao seu próprio sistema, por esse motivo procure primeiro entender o que está sendo explicado e depois coloque em prática se te convém (já leu o aviso acima né?). Eu tenho acesso a 3 tipos de Linux no momento e me baseando nestes eu vou explicar a diferença entre um e outro, os sistemas são Ubuntu, CentOS e Debian. Porém esses métodos são aplicados a todas as distros, como eu disse as diferenças são pequenas.

O objetivo aqui é conseguir o acesso à conta do root, uma vez logado como root você pode trocar a senha dele ou de qualquer outro usuário para garantir o seu acesso mais tarde, ou você pode simplesmente destruir o sistema por completo, o root tem poder absoluto no Linux, lembre-se disso.

Primeiro método: Single User Mode

O Single User Mode ou modo de usuário único é o modo no qual apenas um usuário é permitido fazer o login, esse usuário é o root para fazer tarefas administrativas, por exemplo você estava iniciando o sistema mas um update quebrou o driver de vídeo. Para você ter a opção de recuperar o sistema você deve iniciar o computador no modo de usuário único, também conhecido como modo de recuperação (Recovery Mode).

O Ubuntu e a maioria dos baseados em Debian tem no próprio GRUB a opção para modo de recuperação, já no CentOS você deve modificar o GRUB antes de iniciar o sistema, caso o seu Debian ou Ubuntu não tem a opção de recuperação você pode seguir o mesmo raciocínio aqui...

Assim que o seu sistema estiver iniciando aperte a tecla "e" para editar a entrada do GRUB correspondente ao sistema que você quer invadir, no Ubuntu por padrão o GRUB é escondido então antes do logo do Ubuntu aparecer você já deve digitar a letra "e" até o GRUB aparecer, cuidado para não exagerar e modificar o GRUB acrescentando "e" no início do menu, o GRUB deve iniciar com a palavra set e não eeeset :). Se o logo do Ubuntu aparecer você não conseguiu, reinicie e tente de novo.

Encontre a linha que carrega as opções do kernel, no CentOS essa linha começa com a palavra kernel, no Ubuntu e derivados do Debian começa com a palavra Linux.

Um exemplo no Linux Mint e essa linha:

linux /boot/vmlinuz-3.11.0-12-generic root=UUID=8d535868-a72d-4b53-93da-9e83e1d8b7f3 ro quiet splash vt.handoff=7

No final onde você vê "vt.handoff=7" apague o "vt.handoff" e escreva o número 1 assim a mesma linha fica assim:

linux /boot/vmlinuz-3.0.0-12-generic root=UUID=8d535868-a72d-4b53-93da-9e83e1d8b7f3 ro quiet splash 1

No CentOS não tem esse "vt.handoff" então você não precisa apagar nada, só adicionar o número 1 ao final da linha.

Depois de feito essa edição leia na parte inferior do GRUB as instruções, algumas versões você deve apertar F10 para reiniciar aplicando a edição, outras versões você deve apertar a tecla "b".

Ao reiniciar o sistema você tem o prompt já logado como root, agora digite:

# passwd

Entre e confirme a nova senha do root. No CentOS escreva "init 5", no Debian escreva gdm3 e alguns como o Lubuntu ou uma das distros leves digite LightDM. Depois de escrever isso aperte o enter e pronto agora você tem o poder do mestre root...
  • Meu Deus como é fácil invadir o Linux, estamos super inseguros, é o fim do mundo... AAAAHHHHH.

Calma, antes de se desesperar, isso não funciona remotamente... A pessoa tem que estar presente com o computador na mão para isso funcionar. Esse método é um backdoor para você fazer ajustes no sistema quando tudo está dando errado. O problema dessa configuração é que você não precisa digitar senha nenhuma para o root. Então vamos consertar isso.

Solução para o Ubuntu e derivados:

Edite o arquivo /etc/default/GRUB e retire o # da linha:

GRUB_DISABLE_RECOVERY="true"

Depois:

# update-grub

Ou dependendo de qual versão e qual sistema você tem:

# grub-update

Fazendo isso a opção de recuperação não vai aparecer no GRUB, porém ainda existe a possibilidade de alguém editar o GRUB antes da inicialização.

Para evitar isso, troque a senha do usuário root, digite no terminal:

sudo -i

Entre a senha do usuário comum.

# passwd

Crie e confirme a nova senha do root.

# reboot

Feito isso o seu computador vai reiniciar, tente mais uma vez hackear no Single User Mode.
Linux: Malware, Vírus e Hacking. Estamos seguros usando Linux?
Se você tentar invadir o seu sistema em vez de entrar direto no prompt do root você deve digitar a senha ou apertar Ctrl + d para continuar com a inicialização normal.

Solução para CentOS e derivados:

Faca o hack no GRUB para invadir o seu CentOS, modifique a senha do root. Caso você não tenha permissão para modificar a senha (mais seguro que o Ubuntu, mas nem tanto), o SELinux está em modo forcado, desative com o comando:

# setenforce 0

Agora sim modifique a senha do root, edite o arquivo /etc/rc1.d/S99single. Procure a linha com o comando:

exec init -t1 s

E adicione logo acima dessa linha:

exec /sbin/sulogin

Linux: Malware, Vírus e Hacking. Estamos seguros usando Linux?

Segundo método

Esse segundo método é mais obsoleto porém ainda em uso, no método anterior usamos o single user mode. Nesse segundo tipo de ataque vamos modificar novamente a linha do kernel, só que em vez de adicionar o 1 vamos adicionar ao fim da linha init=/bin/bash e iniciando com a tecla b.

Depois de iniciado você vai ter um prompt com o seguinte formato:

bash-4.1#

Isso significa que você já é root, agora vamos modificar a senha, só que antes temos que montar o sistema de arquivos com permissão de escrita, já que nesse método estamos com permissão de leitura somente:

# mount -o remount,rw /

Agora é só mudar a senha como descrito acima.

Esse método no Ubuntu não funciona se você manter as opções "ro quiet splash $vt.handoff", porém se você apagar essas opções e escrever "init=/bin/bash" aí sim você vai ter o acesso como root, porém nem todas as opções do sistema estarão presentes e você não consegue desligar o sistema, shutdown, init N, reboot, halt etc. nenhum desses comandos funcionam, acredito que existe uma implementação de segurança no Ubuntu para esse hack que eu ainda não conheço, agradeço se alguém sabe se tem como reverter isso, e se tiver como proteger desse método de reversão.

Para se proteger desse tipo de ataque em todas as distros, temos que abrir mão de uma coisa chamada, conveniência. Temos que adicionar senha ao GRUB para evitar que alguém possa alterar o mesmo durante a inicialização. Um dos problemas que isso traz é que toda vez que você precisar reiniciar o computador você ou alguém que sabe a senha do GRUB tem que estar presente.

Cuidado ao adicionar uma senha ao GRUB você pode ficar com um sistema que não inicia se você esquecer a senha, não haverá opções de recuperação de senha, se você perder a senha só hackeando com um Live CD.

CentOS

Primeiro temos que encriptar a senha, esse método de encriptação é segura porque não depende somente de MD5 mas inclui um salt para fazer a encriptação suja... Se você não entendeu esse último parágrafo saiba que é um método seguro e pronto. Acredite na minha palavra, é seguro.

# grub-md5-crypt

Esse comando vai gerar um hash estranho, tipo assim: $1$t8JvC1$8buXiBsfANd79/X3elp9G1

Essa é a sua senha encriptada, agora copie essa senha e cole no arquivo /boot/GRUB/GRUB.conf logo abaixo da linha de timeout no seguinte formato:

password --md5 $1$t8JvC1$8buXiBsfANd79/X3elp9G1

Troque $1$t8JvC1$8buXiBsfANd79/X3elp9G1 pela sua senha encriptada.

Agora toda vez que você iniciar o sistema antes de aparecer o GRUB você deve entrar a senha para o GRUB.

Esse método descrito acima não é para o Ubuntu e sim para o CentOS, eu acredito que se a sua distro usa o kernel 2.6.xx você pode usar esse método, em distros com um kernel mais atual por favor verifique a documentação da sua distro e procure por senha no GRUB.

O GRUB 2 nos dá a opção de colocar senha em entradas do GRUB individualmente que é muito melhor já que você pode deixar a entrada padrão para iniciar automaticamente e se necessário descer ao modo de recuperação aí sim você tem que entrar com a senha. Pesquise sobre isso, eu não vou explicar aqui como faz no GRUB 2 porque vai ficar um artigo muito extenso.

Terceiro método

O terceiro método é o mais malicioso de todos já que não depende do seu sistema... Invasão por live CD. Qualquer um que tenha conhecimento de usar um live CD para invadir o seu sistema fisicamente pode realizar isso sem importar qual senha você tem no seu GRUB ou qual método de proteção está ativo no seu sistema.

O método eu não vou descrever com detalhes, mas a ideia é montar o HD em /mnt do live CD em modo de leitura, ir até o arquivo /etc/password e na conta que você quer hackear delete o campo onde a senha está escondida. Reinicie o computador desta vez pelo próprio HD e não pelo live CD e logue na conta que você hackeou sem senha.

Existe 3 maneiras de você se defender desse método. Esse método não depende do Linux e sim do seu computador.

Não tem como eu dizer passo a passo como fazer isso, porque existem várias formas e dependendo da plataforma uma BIOS é completamente diferente de outra. Mas aqui vão os meus pensamentos.

Para evitar que alguém entre no seu sistema usando um live CD entre na BIOS do seu computador, procure por opções de segurança, crie uma senha para o acesso a BIOS, modifique a ordem de boot para que o HD venha sempre primeiro e USB ou CD depois do HD.

Assim sempre o seu sistema será iniciado e quem quiser usar um live CD ou USB tem que saber a senha da BIOS para modificar a ordem de boot. Não perca a senha da BIOS ou você não vai mais conseguir fazer a instalação de outro sistema se um dia você quiser trocar de distro, se você perder a senha da BIOS você tem que hackear a BIOS...

Se o seu computador é de 2012 em diante e 64 bits, ao invés de BIOS você tem UEFI que é o sistema que está no lugar da BIOS nos computadores mais recentes. Eu não sei se todos os Linux já suportam UEFI, os mais conhecidos suportam.

Você pode usar o secure boot, com ele só o sistema que está "cadastrado" a database do UEFI e o que é permitido iniciar, ao colocar um live CD o UEFI vai se recusar a rodar esse sistema. Agora é só colocar uma senha no UEFI para que ninguém tente cadastrar um novo sistema.

Se o seu UEFI foi um dos primeiros a ser lançados e você só pode iniciar o seu sistema em legacy mode então siga as instruções acima para BIOS.

E outra maneira de se defender disso é criar um script que faz um backup do /etc/password em um local que só você sabe, criar um hash de MD5 para esse arquivo e implementar essa hash como uma variável do script. Toda vez que o sistema iniciar esse script vai rodar antes da tela de login, se o MD5 não bate então o arquivo modificado é deletado e o arquivo backup entra no lugar do modificado, assim não haverá problemas... só se o hacker descobrir que você fez isso, só que até provar que focinho de porco não é tomada ... :)

Esse é o script que eu uso. NÃO COPIE, ENTENDA COMO FUNCIONA E FAÇA UM SEMELHANTE:

#!/bin/bash

hash="$(expr 3173b1c4548185950fd234a414ec5eb3)"
check="$(cat /etc/passwd | md5sum | cut -d " " -f 1)"

if [ ${hash} != ${check} ]
then 
	notify-send "checksum don't match"
	cp /opt/secure-etc/passwd /etc/passwd
else 
	notify-send "checked!"
fi

A variável hash foi determinada antes de escrever o script usando o comando:

cat /etc/passwd | md5sum | cut -d " " -f 1

E antes de testar o comando pela primeira vez eu fiz uma cópia do arquivo /etc/passwd para /opt/secure-etc/passwd.

Assim se alguém modificar alguma coisa no meu HD assim que eu inicio o computador esse script conserta o erro. Vale apenas fazer o mesmo para /etc/shadow e /etc/passwd.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Entendendo os nomes
   3. Vírus e Worms
   4. Trojans e Spyware
   5. Adware, Ransomware e Scareware
   6. Drive-by-Download
   7. Android, SUSE e Canonical
   8. Invasão remota e física
   9. Invadindo o seu próprio Linux
   10. Referências e conclusão
Outros artigos deste autor

MEncoder - Criando Programa Gráfico Para Conversão

Como controlar todas as mídias da sua casa somente com 1 controle remoto e 1 Linux

Raios de luz explodindo atrás do texto

Áudio Profissional no GNU/Linux

Proteja seu website ou página html com encriptaçâo

Leitura recomendada

Soluções para Acesso Remoto Seguro com SSH

Solução de backup para servidores Windows, Linux & BSD’s

PFSense com Snort

Backup gerenciável usando tar

Computação Forense - Entendendo uma perícia

  
Comentários
[1] Comentário enviado por Lwkas em 11/08/2015 - 21:03h

Muito bom. O melhor artigo sobre o assunto que li. Parabéns.

[2] Comentário enviado por removido em 12/08/2015 - 01:17h

Excelente artigo que merece ser lido calmamente linha a linha, dado o tamanho e a qualidade.
Prefiro pensar que o cara que clicou unlike errou o botãozinho por bobeira.

Tenho algumas coisas a dizer sobre o excelente artigo:

- Se eu não me engano, um vírus (de MSDOS) copiava seu código para dentro de um executável num certo ponto do código binário. Daí quando o executável rodava, ele se replicava e executava outras coisas para as quais ele foi programado. Lembrando que existiam dois tipos de programas em DOS os de extensão .COM e os de extensão .EXE e não me lembro agora a diferença.

- WINE é acrônimo de WINE Is Not Emulator.

O artigo me deixou com uma profunda impressão e com algumas dúvidas quanto ao tema segurança:

- Se eu quiser reforçar meu sistema com criptografia, se não me engano chama-se sistema LUKS, eu posso, não é. Mas o que poderia criptografar além do /home?

- Posso criptografar a /var? a /usr? Ou até mesmo a / (raiz)? Certamente jamais a /boot poderia ser criptografada por causa do kernel.

- Daria certo essas criptografias em partições físicas ou lógicas com LVM?

- Eu colocar o usuário root no /etc/securetty dá alguma diferença nos truques com o GRUB?

- Se eu alterar manualmente o /etc/passwd trocando shell do usuário root por /bin/false também afeta em algo nos truques com o root?

Eu penso que é só.

--
http://s.glbimg.com/po/tt/f/original/2011/10/20/a97264_w8.jpg

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. — Edward Snowden

[3] Comentário enviado por juniorlucio em 12/08/2015 - 11:58h

Cara, que artigo incrível. Muito didático e ao mesmo tempo muito avançado. Gostei demais! Parabéns! Abraços

[4] Comentário enviado por sacioz em 12/08/2015 - 14:43h


Muito obrigado . Muito bom ...espero mais e maiores . Abragendo tudo , como eu disse ao Elgio uma vez. Sua resposta ? Não existe um que abranja tudo ! Rsrsrs

Obrigado .

[5] Comentário enviado por removido em 12/08/2015 - 17:20h

Boa tarde,

Artigo bem explicado. Gostei, parabéns!!

Att,
Jbaf 2015
Mageia 5(KDE), Fedora 21(GNOME)
http://www.mageia.org/pt-br/5/

[6] Comentário enviado por M4iir1c10 em 13/08/2015 - 19:49h

Obrigado por todos os comentarios e perguntas, sempre e bom ter a participacao de voces... aprendemos juntos.

[2] Comentário enviado por listeiro_037 em 12/08/2015 - 01:17h
...O artigo me deixou com uma profunda impressão e com algumas dúvidas quanto ao tema segurança:

- Se eu quiser reforçar meu sistema com criptografia, se não me engano chama-se sistema LUKS, eu posso, não é?

Sim

Mas o que poderia criptografar além do /home?

- Posso criptografar a /var? a /usr? Ou até mesmo a / (raiz)? Certamente jamais a /boot poderia ser criptografada por causa do kernel.

Sim, voce esta correto. Com excessao do /boot qualquer pasta pode ser criptografada.

- Daria certo essas criptografias em partições físicas ou lógicas com LVM?

Sim, tanto fisica como logica.

- Eu colocar o usuário root no /etc/securetty dá alguma diferença nos truques com o GRUB?

Nao, colocando em /etc/securetty nao afeta nada. O arquivo securetty e consultado por login e no single user mode o sulogin ignora completamente o securetty. Outro ponto que vc deve levar em consideracao e que se vc quer controlar o login do root pelo securetty somente os programas que sao controlados por PAM serao afetados e ssh e um dos que nao sao afetados, para impedir o root logando no ssh edite o /etc/ssh/sshd_conf


- Se eu alterar manualmente o /etc/passwd trocando shell do usuário root por /bin/false também afeta em algo nos truques com o root?

Nao...NAO, NAO, se voce fizer isso voce nao vai conseguir mais logar como root... Nao faca isso...

Eu penso que é só.

--
http://s.glbimg.com/po/tt/f/original/2011/10/20/a97264_w8.jpg

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. — Edward Snowden

I totally agree with that statement from Snowden.

Meu contato? anote ai :)
51.562532 -0.109389
51° 33' 45.1152'' N, 0° 6' 33.8004'' W

[7] Comentário enviado por removido em 13/08/2015 - 21:00h

Valeu pela paciência em me responder.
Obrigado novamente!
--
http://s.glbimg.com/po/tt/f/original/2011/10/20/a97264_w8.jpg

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. — Edward Snowden

[8] Comentário enviado por jpfo em 14/08/2015 - 10:10h

Parabéns ao autor. Este foi, sem qualquer dúvida, um dos melhores artigos, senão o melhor, que li relativamente a Linux.
De resto, apesar de já acompanhar este site à algum tempo, registei-me agora especificamente para comentar este artigo.
Mais uma vez, parabéns ao autor e ao VOL por ter aqui rapaziada tão qualificada a fazer excelentes artigos.

[9] Comentário enviado por geioper em 14/08/2015 - 16:07h


Muito Legal

[10] Comentário enviado por clodoaldops em 19/08/2015 - 10:44h

Como sempre a culpa é do cara com a mão no teclado seja no Linux ou no Windows.

[11] Comentário enviado por bleckout em 19/08/2015 - 22:40h

Caramba que belo tópico, ajudou bastante. Parabéns.

Só não encontrei o código que você ia mostrar no final do post daquele e-mail que você recebeu. Fiquei curioso ;)

Vide: "Na última pagina desse artigo eu vou mostrar um código que poderia destruir um computador..."
___________________________________________________________________
[i]"Vivemos todos sob o mesmo céu, mas nem todos temos o mesmo horizonte." - Konrad Adenauer
Ubuntu 14.04 LTS amd64 - Core i7 3770K, 8GB RAM - NVIDIA GTX 760 Windforce[/i]

[12] Comentário enviado por M4iir1c10 em 25/08/2015 - 17:13h


[11] Comentário enviado por bleckout em 19/08/2015 - 22:40h

Caramba que belo tópico, ajudou bastante. Parabéns.

Só não encontrei o código que você ia mostrar no final do post daquele e-mail que você recebeu. Fiquei curioso ;)

Vide: "Na última pagina desse artigo eu vou mostrar um código que poderia destruir um computador..."
___________________________________________________________________
[i]"Vivemos todos sob o mesmo céu, mas nem todos temos o mesmo horizonte." - Konrad Adenauer
Ubuntu 14.04 LTS amd64 - Core i7 3770K, 8GB RAM - NVIDIA GTX 760 Windforce[/i]


Oque eu recebi no email e um e o que eu falei nesse paragrafo que voce mencionou e outro.
O recebido no email esta no screenshots que eu postei e me baseando naquele eu escrevi o codigo que voce mencionou ele esta na pagina 10 na parte das referencias eu o chamo de bash malicioso.

[13] Comentário enviado por pekman em 05/05/2017 - 01:02h

Linux agora virou sistema Operacional?

[14] Comentário enviado por patrickcampos em 03/07/2017 - 15:25h

Muito top o Artigo, um dos melhores que já li aqui no VOL.

Legal!

[15] Comentário enviado por codgolivre em 23/09/2017 - 21:54h

muito bom amigo... esta de parabens , completamente claro e especifico dificilmente alguem fala com essa clareza...artigo de primeira...

valew.

[16] Comentário enviado por cizordj em 09/09/2020 - 12:49h


[13] Comentário enviado por pekman em 05/05/2017 - 01:02h

Linux agora virou sistema Operacional?


Sim e sempre foi


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts