PCF-3

Questões comentadas, artigos e notícias

Prova de 2002: Cenário Ataque Unicode – Questões 36-38

Posted by papacharliefox3 em 22/02/2009

Mais um cenário da prova de 2002. Desta vez trata-se de um ataque a um servidor web utilizando uma técnica que ficou bastante conhecida na comunidade de Segurança em meados de 2001: Unicode Attack. Neste, o atacante utiliza-se de falhas de tradução do endereço (URI) de modo que recursos (arquivos, diretórios, comandos) antes inalcansáveis, tornam-se ferramentas para o ataque.

O hacker – pra quem ainda não sabe o que significa a palavra, veja aqui – conhecido como Rain Forest Puppy (RFP), explica de maneira bem simples o problema:

As cadeias de caracteres %c0%af e %c1%9c são as representações UNICODE para os caracteres ‘/’ e ‘\’. O servidor web da Microsoft (IIS) decodifica essas representações após a verificação do caminho (path checking), o que possibilita a execução arbitrária de comandos no servidor web. (RFP)

Um pouco de história (motivação). Naquela época, após a publicação da falha, muitos grupos de defacers e script-kiddies lançaram mão de ferramentas ou exploits públicos para realizarem o que ficou conhecido como mass hack ou mass defacement, nestes vários websites eram pichados em curto intervalo de tempo, utilizando-se de simples scripts que automatizam o disparo do ataque. Até este que vos fala, divertiu-se um pouco, veja aqui.

Obs.: a imagem (cenário) da questão é uma adaptação da qual consta na prova. Fiz isso a fim de facilitar a visualização e entendimento dos comentários. As únicas mudanças realizadas no conteúdo foram a troca do texto, onde estava  ‘atacker.nowhere.com’ (sic) tornou-se ‘evil’; e a adição de letras, para facilitar a apontamentos. Clique na imagem para visualizá-la em tamanho original (abrirá em nova janela).

Texto CE – questões de 36 a 38

Os trechos abaixo foram retirados de um arquivo de log referente a acessos a um servidor http.

Cenário - Logs do servidor web

Cenário - Logs do servidor web

QUESTÃO 36
Com base no texto CE, julgue os itens abaixo, referentes aos ataques ao servidor http mencionado nesse texto.

1 As tentativas exploratórias começaram a ter sucesso a partir de 23/1/2001.
2 Verifica-se ataque de defacement (pichação) a página Web.
3 A vulnerabilidade explorada nos ataques é a do parsing das requisições de arquivo em servidores Web, também conhecida como ataque de unicode, presente no MS IIS versão 5.0.
4 Os logs foram gerados pelo MS IIS.
5 O atacante fez uma cópia de backup da página original.

QUESTÃO 37
Novamente com base no texto CE e acerca dos ataques ao servidor http referido, julgue os itens a seguir.

1 Nos probes exploratórios, o atacante vasculhou diversos diretórios, procurando o arquivo “cmd.exe”, que é um interpretador de comandos.
2 “Atacker” copiou “cmd.exe” em outro arquivo, que posteriormente foi usado no ataque.
3 A página inicial do servidor Web atacado residia em “Default.htm”.
4 O servidor utiliza uma forma elementar de defesa, mantendo a página de index em “myweb.dll”.
5 “Atacker6” teve sucesso no ataque.

QUESTÃO 38
Ainda com base no texto CE, julgue os itens subseqüentes, relativos ao servidor http e aos ataques ocorridos.

1 A página vulnerada se apresentou em branco com os dizeres “H4ck3d by Gund3R0th thanks Gund3R1th Grup WebQu33R”.
2 Os ataques não poderiam ser evitados utilizando-se um proxy que restringisse os acessos à página inicial.
3 Não há patch disponível, atualmente, para corrigir a vulnerabilidade em questão, que seja fornecido pelo autor/fornecedor do servidor Web.
4 Um dos elementos dos ataques está no fato de o diretório “system32” ter seu acesso liberado, na configuração default do sistema operacional.
5 Os ataques poderiam ter sido evitados por meio de filtragem de pacotes em um firewall convencional.

Vamos aos (humildes) comentários:

36.1 As tentativas exploratórias começaram a ter sucesso a partir de 23/1/2001.

Aqui cabe o questionamento: o sucesso ocorre quando ocorre o evento (ataque) ou quando ocorre a exploração? Apostei na segunda opção. Para identificar o sucesso, utilizando-se apenas do que foi exposto (logs), não resta dúvida que a informação que precisamos está no código de resposta do servidor HTTP, ou seja, temos que verificar o valor do penúltimo campo do log. Encontra-se 4 tipos distintos nos logs, a saber:

200 -> OK

404 -> Not Found

500 -> Internal Server Error

502 -> Bad Gateway

Para mais detalhes sobre os códigos de erro, deve-se acessar o link para o documento RFC específico (ver em referências ao final do post).

Após verificar os logs, percebe-se que até a linha ‘i’, todas as requisições receberam código 404, diferentemente da linha posterior (j), na qual se encontra o código 200. Dessa forma, a sentença está ERRADA visto que a data constante na linha ‘j’ é “22/Jan/2001:21:19:27”, data em que os ataques começaram a ter sucesso.

36.2 Verifica-se ataque de defacement (pichação) a página Web.

Esse fato pode ser comprovado ao analisar-se as linhas ‘t’ e ‘u’, cujo conteúdo é idêntico. O comando executado por tais linhas é o seguinte:

echo H4ck3d by Gund3R0th thanks Gund3R1th Grup WebQu33R >c:\inetpub\wwwroot\Default.htm

Cabe aqui algumas observações:

  • Para efetuar um defacement, não há necessidade de alterar a página inicial do website, mas conteúdo qualquer, acessível publicamente;
  • O caminho c:\inetpub\wwwroot\ existe, conforme visto na linha ‘p’ dos logs;
  • O arquivo Default.htm tem seu conteúdo alterado para ‘H4ck3d by Gund3R0th thanks Gund3R1th Grup WebQu33R’. Apesar de o código HTTP ser 500 (erro interno), o comando foi executado com sucesso. Tal comportamento acontece em razão do servidor web não entender o valor do código de retorno da shell (cmd.exe); ‘1’ neste caso.

Assim, a sentença está CERTA.

36.3 A vulnerabilidade explorada nos ataques é a do parsing das requisições de arquivo em servidores Web, também conhecida como ataque de unicode, presente no MS IIS versão 5.0.

Não há o que se comentar em face do que já foi exposto. Sentença CERTA.

36.4 Os logs foram gerados pelo MS IIS.

Nesta sentença o candidato pára e pensa: “É óbvio que o log é da Microsoft, afinal o ataque é contra o servidor IIS! Mas, o CESPE não faria assim!”. É isto mesmo, o examinador não só ‘mata’ os mais afoitos como também deixa ‘em cima do muro’ os mais atentos e conservadores.  Existem dois pontos-chave para responder esta sentença:

Código HTTP 502: o código de nome “Bad Gateway” significa servidor mau uma maneira simples para se referir ao comportamento do servidor web, quando este age como um gateway ou proxy da requisição feita pelo cliente (browser). Para facilitar o entendimento, o cenário preparado pelo examinador deve ser o seguinte:

Apache servindo como proxy para IIS

Apache servindo como proxy para IIS

Formato do Log: o formato de log do servidor IIS obedece ao padrão estendido do W3C, este difere bastante do que foi mostrado (quem lida com Apache deve ter reconhecido). Segue abaixo um exemplo (ver referências):

#Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status sc-bytes cs-bytes time-taken cs(User-Agent) cs(Referrer)
2002-05-24 20:18:01 172.224.24.114 - 206.73.118.24 80 GET /Default.htm - 200 7930 248 31 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+2000+Server) http://64.224.24.114/

Assim, a sentença está ERRADA visto que o log não foi gerado pelo MS IIS, mas por outro servidor web como o Apache ou outro cujo log possua o mesmo formato.

36.5 O atacante fez uma cópia de backup da página original.

Para fazer uma cópia, o comando copy ou procedimento similar (comando type com pipes, etc.) deve estar explícito nos logs. Não obstante a existência desses comandos nas linhas ‘q’, ‘r’ e ‘s’, nenhum desses realiza cópia da página original (supõe-se que seja default.htm). Sentença ERRADA.

37.1 Nos probes exploratórios, o atacante vasculhou diversos diretórios, procurando o arquivo “cmd.exe”, que é um interpretador de comandos.

Considerando as 9 primeiras requisições, excluindo-se o primeiro código 200(linha ‘j’), realmente verifica-se a tentativa de acesso a vários diretórios, todas com destino ao arquivo cmd.exe (que acaba agindo como um CGI). Questão CERTA.

37.2 “Atacker” copiou “cmd.exe” em outro arquivo, que posteriormente foi usado no ataque.

Novamente, para haver cópia, o comando copy deverá ser usado. Assim, as 3 linhas que contém este comando são: q, r e s. Nesta ocorre a cópia com sucesso:

copy+c:\winnt\system32\cmd.exe+c:\winnt\s3.exe (símbolo ‘+’ significa espaço)

Assim, a primeira parte da sentença está certa. Resta verificarmos se o arquivo copiado foi executado durante o ataque, fato que se confirma ao verificarmos as linhas ‘w’, ‘x’, ‘y’ e ‘aa’. Assim, a sentença está CERTA. Mas, espere! A questão foi anulada pela banca! :) Acredito que um dos argumentos utilizados para prova do contrário foi a inexistência de códigos HTTP com valor 200 em requisições ao comando “s3.exe”, diferentemente do que ocorreu com o requisições ao comando “cmd.exe” (linha ‘j’).

37.3 A página inicial do servidor Web atacado residia em “Default.htm”.

No IIS, por padrão, realmente o arquivo Default.htm abriga a página inicial do servidor web, entretanto, não há como se afirmar isso sem [1] acessar a página inicial do site, [2] sem verificar a configuração atual do IIS, [3] sem ter certeza de que trata-se de uma instalação padrão. Sentença ERRADA.

37.4 O servidor utiliza uma forma elementar de defesa, mantendo a página de index em “myweb.dll”.

Baseando-se nas explicações da sentença anterior faz-se suficiente para afimar que a sentença está errada, no entanto o gabarito consta como CERTA. Se você possui uma justificativa – plausível – dessa, manda por e-mail ou deixa um comentário no blog. Eu realmente não consegui identificar uma maneira de afirmar isso, baseando-se apenas nos logs.

37.5 “Atacker6” teve sucesso no ataque.

A sentença está CERTA, a justificativa encontra-se nos comentários da sentença 36.2.

38.1 A página vulnerada se apresentou em branco com os dizeres “H4ck3d by Gund3R0th thanks Gund3R1th Grup WebQu33R”.

A sentença está CERTA, a justificativa encontra-se nos comentários da sentença 36.2.

38.2 Os ataques não poderiam ser evitados utilizando-se um proxy que restringisse os acessos à página inicial.

Tornando os acessos limitados (restritos) à página inicial, ataques realizados a diretórios ou caminhos diferentes da página inicial se tornariam inócuos. Essas restrições podem ser feitas em um proxy (no cenário suposto, seria feito no servidor Apache). Sentença ERRADA.

38.3 Não há patch disponível, atualmente, para corrigir a vulnerabilidade em questão, que seja fornecido pelo autor/fornecedor do servidor Web.

A vulnerabilidade fora exposta – ao público – em 2001; à época da prova, a Microsoft já havia disponibilizado correções de segurança as quais corrigiam tal falha. Clique aqui para mais detalhes.

38.4 Um dos elementos dos ataques está no fato de o diretório “system32” ter seu acesso liberado, na configuração default do sistema operacional.

Sem dúvida. Dentre outras ações (aplicação de controles, hardening), o administrador pode restringir o acesso do usuário que executa o serviço do servidor web (contexto), o que não é aplicado por padrão. Sentença CERTA.

38.5 Os ataques poderiam ter sido evitados por meio de filtragem de pacotes em um firewall convencional.

Por meio da filtragem convencional, haveria apenas a possibilidade de bloqueio da porta em que o serviço web ‘escuta’, neste caso, o bloqueio de acesso à porta 80 simplementa faria com que nenhuma aplicação web pudesse ser acessada. Sentença ERRADA.

Gabarito definitivo:

36: 1-E  2-C  3-C  4-E  5-E
37: 1-C  2-X  3-E  4-C  5-C
38: 1-C  2-E  3-E  4-C  5-E

Referências:

– Hyper Text Protocol 1.1  RFC, http://www.ietf.org/rfc/rfc2616.txt
– Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes, http://support.microsoft.com/kb/318380
W3C Extended Log File Examples
– Microsoft IIS 4.0 / 5.0 vulnerable to directory traversal via extended unicode in url (MS00-078), US-CERT

Uma resposta to “Prova de 2002: Cenário Ataque Unicode – Questões 36-38”

  1. Abel said

    What a stuff of un-ambiguity and preserveness of valuable knowledge concerning unpredicted emotions.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

 
%d blogueiros gostam disto: