Exemplo da (in)segurança de um site sem HTTPS
Nos dias que correm, é importante que todos os dados sensíveis transaccionados entre um cliente e um servidor sejam cifrados de modo a que estes não possam ser entendidos por terceiros. Na prática, quando acedemos a um serviço online que nos solicita dados pessoais ou credenciais de acesso (ex. sites de bancos) é importante que a toda a informação passada seja cifrada de modo a tornar-se ilegível. No caso dos servidor Web (entre outros serviços de uma rede), uma das formas de proceder a cifra dos dados é recorrendo ao protocolo SSL.
Mas como passam os dados na rede se o servidor não tiver o protocolo SSL configurado?
O que é o SSL?
O SSL é um protocolo criptográfico baseado em cifras assimétricas (chave privada + chave pública) que tem como principal objectivo providenciar segurança e integridade dos dados transmitidos em redes inseguras como é o caso da Internet. Quando um utilizador acede a um site que recorre ao SSL, o servidor envia ao cliente a chave pública para que esta possa cifrar a informação que vai ser passada ao servidor. Quando o servidor recebe essa informação, usa a sua chave privada para decifrar a informação transmitida pelo cliente. Existem várias aplicações para este protocolo, como por exemplo o comércio electrónico, servidores Web, servidores FTP, etc. Para identificar facilmente se estão a visualizar um site seguro basta verificar no URL que em vez de estar o normal http:// se encontra https://. Saber mais aqui.
Chave pública vs Chave privada
A chave pública, que está presente no certificado digital, é usada para cifrar os dados a serem enviados ao para o servidor. Já a chave privada, que só o dono do certificado conhece, serve para decifrar a informação que foi cifrada com a sua chave pública.
Certificado Digital
Um certificado é um documento digital que contém informação acerca de quem o possui, nome, morada, localidade, e-mail, duração do certificado, domínio (Common Name) e nome da entidade que assina o certificado. Contém ainda uma chave pública e um hash que permite verificar a integridade do próprio certificado (i.e se um certificado foi alterado). Um certificado assenta numa estrutura hierárquica de confiança, cujo topo é pertença de uma Entidade Certificadora (CA Root Certificate). Esta entidade certificadora confirma que o possuidor do certificado é quem afirma ser, e assina o certificado, impossibilitando desta forma a sua modificação. Em Portugal, como entidade certificadora temos como exemplo a multicert.
SSL
O protocolo SSL – Secure Socket Layer é um protocolo que foi desenvolvido pela Netscape com o objectivo de garantir transacções seguras entre um servidor web e um browser. O protocolo utiliza uma entidade certificadora para identificar o servidor ou o servidor e o cliente.
Openssl
O OpenSSL é uma implementação em código aberto dos protocolos SSL e TLS. Uma das funcionalidades consiste na criação de certificados X.509 que permitem confidencialidade em ligações com SSL (HTTPS) entre outros serviços. Os certificados digitais X.509 representam para o utilizador, o mecanismo de segurança mais visível no âmbito da certificação digital. …em resumo: Caso o seu servidor tenha SSL configurado, os dados passam cifrados na rede (entre o cliente e o servidor) garantindo assim a confidencialidade dos dados.
E o seu o servidor não tem SSL?
Bem, se o servidor não tem SSL configurado então a informação passa na rede conforme a introduzimos “em claro”. Para demonstrar tal cenário, criamos um pequeno formulário que envia os dados para o servidor através do método POST (os dados são passados no corpo da mensagem e não no URL) Na mesma máquina corremos o Wireshark (ferramenta de analise protocolar, que permite a captação, em tempo real, de pacotes de dados) para “snifar” todo o tráfego que passa na interface de rede. Para mais facilmente descobrir o que queremos no meio de tantas entradas, podemos aplicar um filtro. Neste caso, como queremos filtrar um pedido HTTP que usa o método Post, podemos usar o filtro http.request.method == “POST” Em seguida fazemos um trace à ligação, carregando no botão do lado direito do rato e escolhemos a opção Follow TCP Stream Como podemos ver, a opção Follow TCP Stream apresenta-nos o conteúdo do stream e nele podemos ver facilmente as credenciais introduzidas (sem qualquer cifra).
O SSL é um requisito obrigatório em sites que implementem funcionalidades de autenticação ou introdução de dados sensíveis. Como utilizadores, é importante que verifiquem se um site possui SSL (HTTPS) e se os certificados foram criados por uma entidade certificadora. Alguma questão ou dúvida, estamos cá para ajudar a esclarecer. Naveguem…seguros!
Este artigo tem mais de um ano
muito muito bom post!
desconhecia essa opcao Follow TCP Stream
Pedro Pinto, desculpa lá o reparo: “…em resumo: Caso o seu servidor tens(tenha?) SSL”
Isto é sem dúvida um excelente abre olhos! Um óptimo post, agora vamos lá a ver quantos é que vão andar a usar isto para brincar um bocado hehe
Ainda bem que a Google, Facebook e afins andaram anos e anos sem SSL… E não foi à muito tempo que passaram a ter SSL.
Não, a Google sempre teve ssl, o mesmo para o facebook.
A diferença, é que antigamente, estes serviços só utilizavam ssl para a autenticação.
Agora, já usam sempre ssl, mesmo para uma simples pesquisa, ou para ver uma página.
Tal adveio da massificação das redes wifi, se for tráfego não ssl, é possível ver as páginas que as outras pessoas estão a ver (mas não as credenciais, claro), e executar comandos (exemplo posts) em nome de outrem…
Isso era possível em qualquer rede cabalada ou não, mas o wifi veio agravar o problema.
Além disso, o tráfego ssl usa muito mais CPU, com os avanços nos processadores, isso tornou-se mais secundário…
Nas redes cabladas não é bem assim….
A era dos HUBs já passou há muito tempo. Com os switches só recebes o que é pra ti, ao contrário do wifi.
Obviamente que se podia fazer arp poising, mas dá muito nas vistas.
Exacto. Nas redes cabladas, era possível, mas mais dificil.
Nas redes sem fios, é fácil…
ARP Spoofing/Poisoning funciona em qualquer tipo de rede (switched) seja esta cablada ou Wifi, salvo estejam implementados alguns mecanismos de protecção (ex: dhcp snopping) no switch ou no AP/Controladora Wifi e também os hosts (aka windows e/ou *nix) tenha entradas estáticas na tabela de ARP.
Fica a dica para todos se estiverem na Univ. ou numa rede qualquer se souberem o MAC Address do gateway da rede, insiram na vossa tabela de ARP uma entrada estática do MAC do Gateway para evitarem ataques ARP Spoofing/MITM.
Para quem quiser aprender mais um pouco sobre o assunto fica o link: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_603839.html
SSLStrip anyone?….
http://www.securitytube.net/video/193
http://www.usatoday.com/story/cybertruth/2013/11/12/hackers-probe-https-weaknesses/3507815/
Excelente artigo, mais uma vez Pllware.
Obrigado
Isso não é assim tão linear.
Há a possibilidade de se fazer a cifra no computador antes de se enviar para o site. Isso faz com que a password não circule em “clear text”. E é isso que uma pessoa que saiba o que está a fazer vai fazer.
Isto é um exemplo de uma aplicação mal construída e serve, quando muito, para mostrar o que acontece quando se atribuem projectos sensíveis a pessoas menos “atentas” ao que estão a fazer e eventualmente menos conhecedoras das bases.
Não me parece, no entanto, boa politica fazer parecer que em tudo que é site (que não seja HTTPS) se está sempre a uns cliques de se descobrir passwords transferidas na rede porque isso não é verdade em todos os casos!
P.S.:Quando muito estejam atentos a avisos do tipo “Esta a sair de uma ligação segura e a partir de agora os seus dados circularam em clear text” ou uma coisa do genero que o velhinho IE produzia.
Boas Claudio,
Claro que podes cifrar antes..mas como descodificas do outro lado?
Isto é um simples formulário que usa o método POST. Quando ao HTTPS, se é solicitado dados sensíveis ao utilizador…HTTPS é requisito minimo
Pode descodificar com um valor que está guardado na variável de sessão de cada utilizador. Mas concordo contigo, HTTPS é o mínimo…..
Não é boa prática guardar a chave do utilizador na sessão!
Simples, não descodificas!
Ou sites nunca devem guardar as pass’s em plaintext.
Logo, comparas a hash com a hash enviada. Ou fazes a hash no servidor.
PS: porém, se fizeres a hash nos clientes, não ganhas nada, e perdes a possibilidade de adicional “sal” (sim, é esse o termo).
Não interessa se a senha é cifrada no servidor, ou no cliente para um ataque “man in the middle”, só interests a se não quiseres que o serviço fique com a tua pass em clear text…
Boas
Que livros sobre segurança em web apps recomendam?
em inglês
HACKING EXPOSED WEB APPLICATIONS, 3rd Edition
http://www.amazon.com/HACKING-EXPOSED-WEB-APPLICATIONS-Edition/dp/0071740643/ref=pd_sim_b_7
Mas existem bem mais recursos (actualizados) online
William Stallings, CRYPTOGRAPHY AND NETWORK SECURITY PRINCIPLES AND PRACTICE
Este não é um livro “como fazer hacking para totós” ou “como fazer para não lhe deitarem abaixo o servidor”, é um livro para aprender o que toda a gente precisa de saber sobre segurança em redes.
Julgo o pedido era para Webapp Security e não para infrastructure security e crypto 😛
Anyways that is a very good book.
O livro serve para web-app security, serve para tudo.
A diferença é que é um livro para realmente aprender, e não para caso-a-caso. 😉
William Stallings, CRYPTOGRAPHY AND NETWORK SECURITY PRINCIPLES AND PRACTICE
http://faculty.mu.edu.sa/public/uploads/1360993259.0858Cryptography%20and%20Network%20Security%20Principles%20and%20Practice,%205th%20Edition.pdf
Obgdo!! Estou a tentar “aprender” mais sobre segurança e criptografia
🙂
Permitam-me apenas uma pequena correção ao explicado inicialmente.
A chave pública fornecida ao cliente pelo servidor não é usada para enviar informação propriamente dita, mas mais corretamente para cifrar uma chave simétrica acordada entre ambos, que será usada daí em diante nessa sessão, aí sim para cifrar a informação.
Usam uma chave simétrica, porque esta forma de encriptação necessita de muito menos poder de processamento para encriptar/desencriptar.
Bem observado, Bruno! A cifra é acordada com recurso à chave pública, e tem de ser uma cifra conhecida por cliente e servidor. Tipicamente cada um dispõe de uma lista delas e é acordada qual deve ser usada para a comunicação segura cliente/servidor. Esta fase é conhecida como fase de handshake.
Boas, só uma dúvida, caso o nosso servidor suporte HTTPS mas não tenha o certificado, a cifra é feita na mesma certo?
Apenas dá o alerta no browser por não ter o certificado SSL.
Faltava era mostrarem o mesmo exemplo mas recorrendo agora ao envia de dados através de um formulário web que corra sobre https. Era interessante mostrar o que ficaria registado no wireshark 😉
Exemplo1
Qual? 🙂
Fiquei com a conta bancária a zeros só de ler este sh*tpost.