Já alguma vez tentou aceder a um site e o mesmo estava bloqueado? Se tentou dar a volta recorrendo a um proxy “anónimo”, então, é muito importante que leia este artigo para saber os perigos que corre.
É verdade que para ser um “utilizador anónimo” na Internet basta que se ligue via proxy! Mas há riscos!
Antes de passarmos ao tema propriamente dito é importante que se perceba o funcionamento básico de um proxy. Uma máquina que se ligue através de um servidor proxy, “obedece” às regras definidas por este e todos os pedidos (ex. páginas web, ficheiros, etc) são também feito pelo proxy que posteriormente os devolve ao cliente. Desta forma é fácil filtrar os conteúdos que pretendemos através do proxy, uma vez que todos os pedidos passam por ele.
Funcionamento básico de um proxy
O computador cliente começa por fazer um pedido GET ao proxy para uma página (por exemplo: www.wikipedia.com). O proxy faz exactamente o mesmo pedido mas ao servidor real. Neste caso o www.wikipedia.com tem associado o IP 91.198.174.192.
Como o web server corre vhosts é possível separar vários websites dependendo do domínio que se pretende. Depois o web server responde ao proxy com a página em HTML, normalmente index.html ou index.php (ou outra página definida). Como normalmente os sites têm imagens, código javascript, HTML5, iframes, toda esta informação será depois passada pelo proxy ao cliente.
Quando o computador cliente vê que existem referencias externas este mesmo irá pedir ao proxy para lhe dar o ficheiro, neste caso o javascript puro. Considerem então:
- PC do cliente pede a página
- Proxy pede a página ao domínio real
- O domínio real devolve a página
- O Proxy devolve a página ao cliente.
- O cliente vê código javascript que é preciso buscar externamente. Por exemplo uma API jquery hospedado no Google.
- O cliente pede o ficheiro desta forma “GET http://www.wikipedia.com/umaapiqualquer.js”
- O proxy filtra este GET e vê que é um pedido de um ficheiro javascript. Por isso antes de ir buscá-lo ao computador realmente irá proceder assim:
- Descarrega o ficheiro .js real numa pasta temporária no sistema.
- Concatena código javascript malicioso ao ficheiro real.
- Substitui o link do umaapiqualquer.js pelo .js temporário com o código real+malicioso.
- Devolve o ficheiro temporário com o código malicioso ao PC.
Como é código javascript o browser do PC irá “executá-lo”.
Então qual é o problema? É simples. Quando o computador pede a API do jquery, ele irá mantê-la em cache durante um tempo determinado pelo servidor.
Se infectamos um ficheiro, que irá só expirar da cache daqui a 3000 dias, significa que este mesmo ficheiro, depois de ser pedido mesmo noutro website irá correr o nosso código malicioso. Este é o principio de cache poisoning.
Este mesmo código pode estar a descarregar toda a informação possível que o browser faz no website. Formulários de login, links, formulários de comentários, tudo é possível. Como é que este código manda os dados?
O mesmo servidor proxy malicioso pode estar a correr um serviço escondido onde irá buscar dados destes clientes pelo URL que pedem ou através de um pedido POST que são activados por eventos nos objectos da página.
Depois de muito código e desenhar a base de dados e um painel podemos ver resultados
Clientes a aceder a páginas da internet
Cliente a navegar pelas páginas
Quem é que procura estes serviços “anónimos”?
Bem, numa análise bastante superficial podemos ver clientes:
- Ligarem-se a sites de encontros online para tentar burlar gente a pagar por fotos nuas.
- Enviar e-mails para várias pessoas com falsas promessas de trabalho e pedir documentos de identificação. Estes tipos de documentos podem ser usados para roubar a identidade das vítimas. Lembrem-se a quem dão o vosso documento de identificação.
- Visitas a sites de pornografia. É talvez a categoria mais visitada.
- Visitas a sites de comunicação social por exemplo: BBC news. Normalmente quem visita este tipo de sites são normalmente IPs da China e Turquia.
- Visitas a sites de pirataria e hacking. Bastante irónicos “hackers” que estão a “hackear e serem hackeados” porque tentaram esconder a sua identidade num proxy “anónimo” que encontraram pela internet.
Os sites que usam HTTPS também funciona?
Teoricamente sim. Se for um proxy por SOCKS é mais difícil. Isto porque SOCKS faz uma transferência dos dados dos sockets, entre o cliente <-> proxy e proxy <-> site. Ver mais aqui.
Por isso os dados passam numa sessão TLS/SSL e quem faz o handshake desta ligação é o PC e o site e nunca o proxy. Já HTTPS sobre o proxy é ligeiramente diferente. É possível usar SSLBump para modificar os certificados (chaves). Só que há um problema e são os warnings que o browser mostra ao utilizador.
Quem é a pessoa que quando tenta aceder a um website e encontra este erro, simplesmente o ignora?
A questão aqui é sempre comportamental. A Maior parte das pessoas iriam simplesmente continuar ou ainda pior seria adicionar o certificado como confiável.