Universidade Estadual de Adams. Como invadir sites. Parte 1Vamos falar sobre o nosso próximo ataque. Vou lhe dizer como os servidores o identificam. Para fazer isso, o protocolo HTTP é usado entre o navegador e o servidor sem salvar o estado, quando a comunicação com o servidor ocorre por pares independentes de solicitação-resposta. Portanto, o servidor o esquece assim que a conexão é estabelecida e, na próxima sessão, não se lembra mais de quem você é.
No entanto, ele lembra de você enquanto você usa o aplicativo da Web, porque quando você coloca as coisas na cesta que deseja comprar, pode continuar comprando e voltar novamente para exibir o conteúdo da sua cesta. A implementação de "lembrar" ocorre usando cookies de identificação de sessão. Assim que você se conecta ao servidor, ele gera um cookie, que é uma sequência única de letras e números, e o envia ao seu navegador, que armazena esse cookie localmente no seu computador. Depois disso, o navegador retorna cookies para o servidor com cada uma de suas solicitações para uma única sessão. Ao receber esses cookies, o servidor entende que tipo de usuário está acessando com esta solicitação. Essa é a maneira mais comum de identificar o usuário que usa o aplicativo Web.
O próximo tipo de ataque é chamado de script entre sites, XSS. A idéia por trás desse ataque é que um invasor obriga um site a exibir código malicioso, geralmente na forma de JavaScript, que é então executado no navegador do usuário. Esse ataque pode ter qualquer finalidade, mas é mais frequentemente usado para obter o identificador da sessão da vítima. O valor do ID da sessão é que ele pode ser considerado uma senha, pois o identifica. Ao capturar o identificador da sessão, um invasor pode se disfarçar usando um servidor proxy para se comunicar com o servidor de destino. Os objetivos desse ataque podem ser o desejo de falar em seu nome, automatizar algumas ações, por exemplo, enviar spam em seu nome ou introduzir um vírus.
Ao procurar uma vulnerabilidade de script entre sites XSS em um aplicativo Web, você está procurando um campo de entrada onde pode colocar algumas informações, enviá-las ao servidor e ver qual resultado será exibido na janela do navegador.
Entro incorretamente no local do prédio, indicando Plachy Hall, o endereço do salão do time de basquete da nossa universidade. O servidor da Web recebe essas informações e entende que o professor de ciência da computação é um “nerd” que não pode morar no local de uma equipe esportiva e envia uma mensagem de erro: “Plachy Hall está errado”!
As caixas de pesquisa são as mais vulneráveis a esse respeito, onde é possível inserir alguns termos bastante obscuros e ver o que você recebe em troca. Na maioria das vezes, você recebe uma dica listando as possíveis opções corretas das quais um invasor pode se beneficiar.
A próxima coisa que você precisa fazer é verificar se você pode injetar seu código malicioso e, em seguida, executá-lo. Vamos tentar organizar um ataque XSS usando JavaScript.
O código JavaScript sempre se diferencia ao abrir e fechar a tag de script, bem como o operador OR. Os desenvolvedores de aplicativos não são completamente estúpidos, então eles criaram um mecanismo de filtragem chamado "desinfecção". Ele se integra ao código, verifica se há caracteres perigosos e os remove sempre que possível. O teste mais simples de desinfecção do JavaScript é semelhante a este:
<script>alert(“Testing”)</script>
Mas os hackers são um pouco mais inteligentes, então eles têm o
ha.ckers.org/xss.html . Não tenho tempo para mostrar a você este site, mas você pode encontrar as maneiras mais sofisticadas de ignorar os controles que os desenvolvedores de aplicativos tentaram inserir em seus programas para remover caracteres perigosos. Portanto, existem algumas maneiras bem inteligentes que permitem que um hacker entre no aplicativo.
Então, vamos falar sobre como será o ataque XSS. Temos um servidor web para as "Páginas da faculdade", onde vamos inserir o código malicioso. Temos Eva, que vai invadir, mas perdemos algo neste slide - esquecemos a vítima. O bom de um ataque XSS é que você não precisa contratar ninguém para fazer isso. Quero dizer, desta vez não serei vítima, porque Eva tem minha senha e ela pode fazer o que quiser com minha conta. Portanto, Eva deixa o grande jogo e não persegue mais os meninos. Vamos levar nossa vítima ao palco (risadas da platéia, porque uma fotografia de um dos professores aparece no slide).
Agora que a vítima tomou seu lugar, vamos ver como o ataque se desenvolve. Suponha que Eve tenha conseguido hospedar o código JavaScript malicioso no servidor em que a vítima entrará usando sua conta.
Isso é importante, porque assim que a vítima fizer logon no servidor, ela receberá um identificador de sessão que Eva tentará interceptar, essa é uma parte muito importante do ataque. Portanto, a vítima solicita uma página da web que contenha código JavaScript malicioso, esse código será executado no navegador da vítima e enviará a Eva o identificador da sessão.
Após receber o identificador da sessão, Eve pode usar seu servidor proxy e fazer o que quiser, disfarçando-se de vítima. A única parte que falta do mosaico é o próprio JavaScript malicioso, que o hacker deve inserir na página e capturar o ID da sessão da vítima e passá-lo ao invasor.
É muito simples Temos o código JavaScript que começa e termina com a abertura e o fechamento da tag:
<script>
A primeira linha de código cria uma imagem da mesma maneira que no JavaScript, uma imagem é criada dinamicamente para qualquer página. Você sabe que, no centro de qualquer imagem, há um arquivo que contém a imagem; portanto, precisamos informar ao navegador para onde obter essa imagem. Isso é indicado na segunda linha, onde o link para o site do hacker está localizado, no entanto, o navegador pensa que este é exatamente o local onde a imagem desejada está localizada. Ele irá ao site de Eve e solicitará document.cookie, porque acredita que este é o arquivo de imagem de que ele precisa.
Mas este não é um arquivo de imagem, mas um identificador de sessão que estamos tentando capturar usando JavaScript. Como você pode ver, obter um ID da sessão é bastante simples. A terceira linha, que não é usada no código para realizar um ataque XSS, contém um alarme que aciona uma janela pop-up no navegador com uma mensagem de ataque. Isso é feito especificamente para o nosso exemplo, porque um ataque XSS real ocorre completamente despercebido pela vítima.
Então, vamos convidar Eve e ver como ela irá atacar scripts entre sites.
Eve Hacker: Obrigado, Dr. Loveland! A primeira coisa que preciso fazer é fechar algumas coisas que não precisamos. Não precisamos mais do proxy Burp Suit, então estou fechando-o. Em segundo lugar, preciso reconfigurar o navegador da Web e alterná-lo para usar as configurações padrão do sistema proxy.
Agora vamos para a página de login do site da Dra. Loveland, porque, se você se lembra, eu tenho a senha dela e posso entrar no site a qualquer momento, em vez dela. Como mencionei, a Dra. Loveland é muito preguiçosa, ela usa um certificado SSL expirado, então tenho que confirmar as exceções de segurança para acessar a página de login. Como sei a senha, posso editar a página dela. Como já sabemos, na página para editar informações pessoais, há uma vulnerabilidade na linha Localização da construção, "Localização da construção", e é aqui que vou inserir meu JavaScript malicioso.
Simplifiquei esse ataque, portanto, na realidade, não enviarei o código ao servidor, mas chamarei uma janela pop-up com a mensagem de que alguém está tentando me atacar. Agora que preparei o cenário para o ataque, retornarei à página de autorização e efetuarei logout. Agora você só precisa esperar até que a vítima apareça e deseje usar este aplicativo.
(Eve coloca um boné de beisebol, posando como professor Stephen Eldridge)
Acabei de voltar de uma reunião fascinante, em que fora do horário de expediente discutimos qual carro deveria receber prioridade no estacionamento - um Subaru ou um jipe, e então ocorreu-nos que a diferença poderia ser um teto solar no carro. Portanto, agora preciso fazer login e verificar meus detalhes de contato, porque não gostaria de perder a próxima reunião "fora da classe" porque meus dados não estavam disponíveis. Portanto, faço login no meu aplicativo da Web sob o saldrich de login e minha senha.
Então, tudo parece normal, não vejo nada de ruim na minha página como professor de matemática, todas as informações de contato estão em ordem.
Meu Deus, meu relógio mostra que faltam apenas 2 minutos para a próxima reunião! Agora vou conhecer a Dra. Loveland, então preciso ir à página dela e ver se consigo desenterrar um pouco de sujeira nela para mencioná-lo na reunião. Então, clico no link Susan Loveland, chego à página dela e ... Dr. Eldridge, sua página está hackeada!
(Professor Eldridge tira o boné de beisebol, transformando-se em Eve)
Agora que tenho o seu ID de sessão, posso usar meu servidor proxy e disfarçar-se como você, Dr. Eldridge, fazendo o que quiser em seu nome. Dou-lhe a palavra, Dr. Loveland!
Susan Loveland: obrigada, Eve! Eu queria mencionar que nosso aplicativo de página do corpo docente foi desenvolvido com base em uma das mais recentes estruturas da Web - o Python Django Web Framework, que possui um excelente sistema de desinfecção de dados de entrada que remove caracteres perigosos do código JavaScript. Portanto, para que Eve realizasse seu ataque, excluí a verificação do valor do campo Local da construção quanto à presença de tais caracteres.
Qual o êxito dos ataques de script entre sites? Aproximadamente 80-90% dos sites têm um mecanismo de gerenciamento de vulnerabilidades no lado do cliente. A falha em resistir a ataques XSS é a vulnerabilidade mais comum dos aplicativos Web 2.0 que interagem mais com os usuários finais.
Você provavelmente já ouviu falar sobre um dos mais famosos scripts de "site" Samy "worms", cujo autor Sami Kamkar surgiu em 2005, como ignorar a filtragem de entrada da rede social MySpase. Ele colocou o JavaScript em sua página, assim como Eve fez com a minha página. Esse script fez duas coisas: adicionou Samy como amigo à vítima e se copiou para a página de perfil da vítima. No início, esse ataque ocorreu muito lentamente, porque apenas algumas pessoas foram à página de Samy e se tornaram amigos, mas gradualmente o vírus se espalhou cada vez mais e a infecção começou a crescer como uma avalanche. Este exemplo foi ilustrativo em termos dos recursos do ataque XSS, pois mais de um milhão de solicitações de amigos em poucas horas "travaram" o site MySpase. Assim, as consequências desses ataques podem ser bastante graves.
O último tipo de ataque sobre o qual quero falar hoje é sobre ataques de controle de acesso ou ataques de acesso. Com esse ataque, o hacker deseja obter informações às quais não tem acesso. Existem várias vulnerabilidades direcionadas pelo vetor de ataque de acesso.
Freqüentemente, os desenvolvedores de aplicativos esquecem que deixaram arquivos no diretório raiz de um documento em um servidor Web e, se você puder detectar a existência deles, poderá visualizar esses arquivos, que geralmente contêm informações confidenciais.
Outra maneira de encontrar a vulnerabilidade é olhar com muito cuidado a URL. Por exemplo, se você
vir um endereço desse tipo
app.com/ViewDoc.php?docid=1280149120 , poderá pesquisar os números no final do link para obter um documento que não se destina a seus olhos.
Muitos aplicativos são projetados para diferentes níveis de usuários e eles têm um mecanismo de acesso
interno que geralmente é baseado em solicitações com os seguintes parâmetros
app.com/login/home.jsp?admin=false , para que você possa tentar entrar no site usando a substituição de endereço na linha para admin = true.
De fato, a vulnerabilidade de controle de acesso mais comum é a implementação incorreta da função de autorização. Agora Eva demonstrará isso.
Eve Hacker: Obrigado, Dr. Loveland. Para realizar o último ataque, basta olhar com muito cuidado a URL do nosso aplicativo da web. Agora vou expandir a janela do aplicativo para que a linha com o endereço na página do Dr. Loveland caiba completamente na tela. Eu tenho que me livrar desse JavaScript irritante que eu instalei.
Vemos que o endereço da página do Dr. Loveland é
localhost / SampleSite / Faculty / index-1.html , e se mudarmos para a página Dr. Eldridge, o endereço será
localhost / SampleSite / Faculty / index-2.html .
Você não acha que o mesmo modelo é usado aqui? No entanto, não estou interessado nessas linhas de endereço, porque elas não têm a capacidade de inserir informações. Quero acessar o formulário de login do Dr. Loveland. Se eu entrar com o nome dela, posso editar suas informações pessoais. Mas vejamos a URL da página, no final da qual existe o IndexForm-1, e você pode adivinhar que talvez haja uma oportunidade de acessar o formulário de dados do Dr. Eldridge.
Portanto, a questão é se podemos chegar ao formulário dele sem fazer login em seu nome. Vamos tentar.
Altero a unidade para dois para que o endereço assuma o formato
localhost / SampleSite / Faculty / indexForm-2.html ,
pressione Enter e uma página com as informações pessoais do Dr. Eldridge aparecerá.
Diante de nós, existe um bug que os alunos do Dr. Loveland se esqueceram de corrigir - o aplicativo tem uma vulnerabilidade que permite penetrar na página de outra pessoa sem entrar no login da vítima.
O Dr. Eldridge é uma pessoa muito legal, eu não gostaria de incomodá-lo, não tenho nada contra ele, mas, por uma gargalhada, deixarei algo na página dele. Deixe-me distorcer o nome e o sobrenome dele e, ao mesmo tempo, corrigir a posição de "professor" para "professor júnior".
Agora enviarei as informações pessoais corrigidas para o servidor e, se agora entrar na página Eldridge, você poderá ver as correções feitas por mim.
Então, Dr. Loveland, se você tiver problemas com o Dr. Eldridge quando ele decidir detê-lo após as palestras, diga-me e eu apagarei todas as informações dele!
Susan Loveland: Obrigado pelo apoio, Eve! Eu quero falar sobre a vulnerabilidade de controle de acesso por apenas mais um segundo. Para pessoas que, como eu, gostam de se aprofundar no código, explicarei o que aconteceu durante esse ataque.
Este slide mostra como preencher um formulário com informações pessoais. A última linha é exatamente o que interessou Eve. Essa classe protege form_index das funções rápidas @ login-required e @authUser e verifica se quem deseja alterar os valores nos campos do formulário deve efetuar login no sistema para isso. No entanto, os desenvolvedores se esqueceram disso e não adicionaram a menção obrigatória dessas funções rápidas no contexto do preenchimento do formulário.
O código mostrado verifica se o formulário solicitado corresponde à pessoa que efetuou login no sistema, mas como não foi usado corretamente, o Eve conseguiu detectar esta vulnerabilidade no aplicativo.
Observo que 78% de todos os sites têm vulnerabilidades de acesso. Em abril passado, alguns hackers descobriram uma vulnerabilidade no campus da universidade de Berkeley - esses eram arquivos ocultos que os desenvolvedores deixaram no servidor de documentos do servidor da web. Os hackers conseguiram visualizar esses arquivos e obter números de previdência social e informações médicas confidenciais para mais de 160 mil pessoas. Então você vê o quão sérias as consequências de um ataque de controle de acesso podem ser.
Gostaria de mencionar mais alguns fatos interessantes no contexto do tópico de nossa conversa hoje. Recentemente, a atenção do governo à segurança cibernética aumentou bastante. Assim, somente em 2008, o Ministério da Defesa registrou mais de 360 milhões de tentativas de hackers. Prevê-se que cerca de US $ 75,8 bilhões sejam gastos na melhoria do sistema de segurança cibernética no campo das tecnologias da informação em 2010, que é 7,2% a mais do que foi gasto com essas metas em 2009. Segundo a CNN Money Magazine, em 2009 nos Estados Unidos, os especialistas em segurança da Internet estavam no topo das profissões mais procuradas. A renda média anual de consultores na área de segurança de computadores era de 99,7 mil dólares, o máximo - 152 mil dólares. Segundo as previsões, a necessidade de tais especialistas de 2006 a 2016 aumentará em 27%.
Quero dizer que a Faculdade de Ciência da Computação teve recentemente a oportunidade de obter um diploma de associado em Computação na Internet e Segurança de Rede, portanto, este é um ótimo ponto de partida para iniciar uma carreira nessa área.
(coloca um chapéu preto)
Eve Hacker: Quero interrompê-lo por um momento, Dr. Loveland! Para futuros professores presentes nessa audiência, observo que se você dominar esta especialidade e algum dia se encontrar em uma situação em que não recebe o aumento salarial prometido, poderá sempre recorrer à máfia e fazer um contrato por eles. Este será um excelente aumento no salário de um professor de ciência da computação.
(tira o chapéu)
Susan Loveland: Quero agradecer às pessoas que deram uma contribuição séria à criação da apresentação de hoje, aos desenvolvedores das “Páginas da Faculdade”. Penso que, graças ao seu trabalho árduo, poderei deixar esse público sem as algemas e a escolta da polícia do campus. O único membro "sobrevivente" deste grupo é Ryan Goldsworthy, que desempenhou um papel importante no desenvolvimento dessas páginas. Quero agradecer ao Dr. Stephen Eldridge por seu senso de humor e por enviar uma página pessoal para demonstrar os ataques, agradecer aos chefes de departamento que contribuíram generosamente para o meu projeto de Páginas da Faculdade e também agradecer ao Serviço de Computação do campus por nos proteger de tais ameaças. pessoas como Eva.
Obrigado pela atenção.
Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um
desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD de 1 Gbps até a mola gratuitamente, ao pagar por um período de seis meses, você pode fazer o pedido
aqui .
Dell R730xd 2 vezes mais barato? Somente nós temos
2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre
Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?