2.4 Execuc¸ ˜ao
14.4.4 Procedimentos de transporte
Esta subsec¸ ˜ao objetiva responder `as seguintes perguntas, algumas delas com escopo j ´a definido em t ´opicos anteriores, sob a perspectiva particular do sistema e-SAJ:
• Como s ˜ao tranferidos os Session IDs?
N ˜ao ´e poss´ıvel transferir os session ID’s atrav ´es de GET, de forma que eles n ˜ao ficam expostos em logs de firewalls ou proxys.
• Os Session IDs s ˜ao sempre, por padr ˜ao, enviados atrav ´es de transporte cifrado?
Codificados pelo CAS. Foram feitos testes de manipulac¸ ˜ao de cookies para logar em uma sess ˜ao ativa com os valores capturados dos JSESSIONID’s e n ˜ao foi obtido sucesso. • ´E poss´ıvel persuadir a aplicac¸ ˜ao a enviar Session IDs por canal inseguro?
Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)
Figura 14.2: Tela inicial de cadastro de novo usu ´ario do e-SAJ
Figura 14.3: Requisic¸ ˜ao HTTP POST original emitida pela aplicac¸ ˜ao S ´o ´e poss´ıvel visualizar os valores codificados pelo CAS.
Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)
Figura 14.4: Transformac¸ ˜ao de m ´etodo POST para GET
Figura 14.5: Alterac¸ ˜ao efetuada com sucesso, confirmada pela tela seguinte de cadastro os Session IDs?
Cap´ıtulo 14. Testing for Exposed Session Variables (OWASP-SM-004)
• Essas diretivas est ˜ao sempre presentes? Se n ˜ao, quais s ˜ao as excec¸ ˜oes? Cache-Control: max-age=0 sempre presente.
• Os Session IDs s ˜ao incorporados por requisic¸ ˜oes GET?
N ˜ao ´e poss´ıvel fazer a autenticac¸ ˜ao atrav ´es de m ´etodos GET. • O m ´etodo POST, quando utilizado, pode ser substitu´ıdo pelo GET?
Cap´ıtulo 15. Testing for Path Traversal (OWASP-AZ-001)
15 Testing for Path Traversal
(OWASP-AZ-001)
15.1
Objetivos
• Contornar permiss ˜oes de acesso a arquivo e diret ´orios
15.2
Pr ´e-requisitos
• Ferrementa de varredura de aplicac¸ ˜ao Web, Spider/Crawler • Ferramenta de proxy (WebScarab, BurpSuite, etc)
• UniScan (testes de falha de atravessamento de diret ´orios)
15.3
Metodologia
Tradicionalmente, servidores e aplicac¸ ˜oes web implementam mecanismos de autenticac¸ ˜ao para controlar o acesso a arquivos e recursos. Servidores Web tentam limitar os arquivos dos usu ´arios dentro de um ”diret ´orio raiz”ou ”raiz do documento web”, que representam um diret ´orio f´ısico no sistema de arquivos. Os usu ´arios t ˆem que considerar esse diret ´orio como o diret ´orio base para a estrutura hier ´arquica da aplicac¸ ˜ao web. A definic¸ ˜ao dos privil ´egios ´e feita atrav ´es de Access Control Lists (ACL), que identifica quais usu ´arios ou grupos ser ˜ao capazes de acessar, modificar ou executar um arquivo espec´ıfico no servidor. Estes mecanismos s ˜ao projetados para impedir o acesso a arquivos confidenciais por parte de usu ´arios mal-intencionados (por exemplo, o arquivo comum /etc/passwd em uma plataforma Unix), ou para evitar a execuc¸ ˜ao de comandos do sistema.
Com base nessas informac¸ ˜oes, a metodologia do ataque basicamente ´e enumerar/mapear todos os enderec¸os que o usu ´ario ´e capaz de acessar, para ent ˜ao inserir caracteres especiais com intuito de aproveitar-se de vulnerabilidades na validac¸ ˜ao server-side e ter acesso a arquivos proibidos para esse respectivo usu ´ario.
15.4
Execuc¸ ˜ao
O atravessamento de diret ´orios, ou Path Traversal, envolve essencialmente duas etapas. A primeira delas ´e a enumerac¸ ˜ao dos vetores de validac¸ ˜ao de entrada. S ˜ao vetores dessa categoria aqueles que permitem o envio de arquivos pelo usu ´ario, formul ´arios HTML, consultas HTTP GET
Cap´ıtulo 15. Testing for Path Traversal (OWASP-AZ-001)
e POST, etc. Especificamente para o sistema e-SAJ, um eventual vetor de validac¸ ˜ao de entrada seria a sec¸ ˜ao Push, que possibilita o envio de processos por um advogado.
A segunda etapa do teste se refere a tentativa de acesssar arquivos, e diret ´orios, partindo-se dos vetores elencados na primeira fase de teste. Esse processo de verificac¸ ˜ao realiza-se de forma manual – tarefa dispendiosa quando de uma aplicac¸ ˜ao web complexa ou de grande porte – ou, alternativamente, de modo autom ´atico – atrav ´es de ferramentas como o Uniscan, que anal- isam diferentes possibilidades de acesso a arquivos e diretorios, empregando, tamb ´em, variados modos de codificac¸ ˜ao que, em determinados casos, viabilizam contornar filtros existentes no lado servidor.
Um poss´ıvel vetor para o atravessamento, no contexto do sistema e-SAJ, seria a sec¸ ˜ao de Push. No entanto, a inclus ˜ao de um processo no sistema ´e intermediada por uma busca. Essa busca interp ˜oe-se entre a selec¸ ˜ao do processo e a inclus ˜ao do mesmo no e-SAJ. Dessa forma, um atacante ´e incapaz, nesta sec¸ ˜ao, de testar URLs ou caminhos relativos, verificac¸ ˜ao necess ´aria ao teste aqui discutido.
Ressalta-se, contudo, em relac¸ ˜ao a constatac¸ ˜ao manual desta catagoria de vulnerabilidade, a necessidade de se levar em considerac¸ ˜ao a maneira como ocorre o percorrimento de di- ret ´orios e arquivos, que est ´a associada intrinsicamente ao Sistema Operacional que executa a aplicac¸ ˜ao Web. N ˜ao confundir ’/’, caracter tipicamente utilizado em sistemas Linux, com ‘\\‘ ou ‘Letra:\caminho\para\arquivo‘, caracteres usualmente vistos em sistemas Windows.
Com vistas `a exemplificar a modalidade autom ´atica de teste, em 15.1 observa-se o Unis- can em ac¸ ˜ao. O Uniscan n ˜ao somente realiza testes acerca do ataque de atravessamento de diret ´orios, todavia tamb ´em ataques referentes `a inclus ˜ao de arquivos (LFI), dentre outros.
Cap´ıtulo 16. Testing for Bypassing Authorization Schema (OWASP-AZ-002)
16 Testing for Bypassing
Authorization Schema
(OWASP-AZ-002)
16.1
Objetivos
• Sobrepujar o esquema de autorizac¸ ˜ao, tentando-se acessar ar ´eas restritas ou de maior privil ´egio
16.2
Pr ´e-requisitos
• Ferramenta de proxy (WebScarab, BurpSuite, etc)
16.3
Metodologia
Este tipo de ataque concentra-se em verificar como o esquema de autorizac¸ ˜ao foi implemen- tado para cada func¸ ˜ao, os privil ´egios para se ter acesso a func¸ ˜oes reservadas e recursos para os quais determinadas credenciais n ˜ao possuem a autorizac¸ ˜ao necess ´aria.
16.4
Execuc¸ ˜ao
Para este teste ´e necess ´ario responder basicamente cinco perguntas (aqui respondidas de acordo com o sistema e-SAJ):
• ´E poss´ıvel acessar determinados recuros do sistema sem estar autenticado? N ˜ao. Foram realizados v ´arios testes nesse ataque e no ataque OWASP-AT-007. • ´E poss´ıvel acessar alguns recursos ap ´os o log-out?
N ˜ao. Foram realizados v ´arios testes nesse ataque e no ataque OWASP-AT-007. • ´E poss´ıvel acessar func¸ ˜oes e recursos autorizados apenas para alguns determinados pa-
peis?
N ˜ao. Foram realizados in ´umeros testes manuais. Foram testados, inclusive, a edic¸ ˜ao de requisic¸ ˜oes interceptadas com aux´ılio da ferramenta WebScarab. Todas as tentativas foram sem sucesso.
Cap´ıtulo 16. Testing for Bypassing Authorization Schema (OWASP-AZ-002)
• ´E poss´ıvel acessar as func¸ ˜oes administrativas tamb ´em se o testador ´e registrado como um usu ´ario com privil ´egios padr ˜ao?
N ˜ao. Pelos mesmos motivos supracitados.
• ´E poss´ıvel usar estas funcionalidades para um usu ´ario com um papel diferente e para quem a ac¸ ˜ao deve ser negada?
Cap´ıtulo 17. Testing for Privilege escalation (OWASP-AZ-003)
17 Testing for Privilege escalation
(OWASP-AZ-003)
17.1
Objetivos
• Sobrepujar o esquema de autorizac¸ ˜ao, tentando-se acessar ar ´eas restritas ou de maior privil ´egio
17.2
Objetivos
• Contornar permiss ˜oes de acesso a arquivo e diret ´orios
17.3
Pr ´e-requisitos
• Ferramenta de proxy (WebScarab, BurpSuite, etc)
17.4
Metodologia
Ataques desta natureza ocorrem quando um usu ´ario tem acesso a mais recursos ou fun- cionalidades que s ˜ao normalmente permitidos. Isso geralmente ´e causado por uma falha na aplicac¸ ˜ao. O resultado ´e que o usu ´ario pode executar ac¸ ˜oes com mais privil ´egios do que as que realmente poderiam ser acessadas por ele.
Portanto, a metodologia deste ataque ´e estudar como funciona o esquema de autorizac¸ ˜ao implementado nesse sistema e aproveitar-se de tal para conseguir acessar recursos n ˜ao permi- dos.
17.5
Execuc¸ ˜ao
A execuc¸ ˜ao deste teste depende das caracter´ısticas do esquema de autorizac¸ ˜ao da aplicac¸ ˜ao Web sendo testada. Para efeito do sistema e-SAJ, aplicou-se a metodologia, acima descrita, da seguinte maneira:
• Inicialmente, buscou-se mapear como comportam-se as requisic¸ ˜oes, interceptadas por in- term ´edio do software WebScarab, quando usu ´arios autorizados e n ˜ao autorizados tentam acessar determinadas funcionalidades. Concentrou-se na funcionalidade de “Push”, pois somente o usu ´ario advogado tem acesso a ela.
Cap´ıtulo 17. Testing for Privilege escalation (OWASP-AZ-003)
• Depois, foram verificadas as requisic¸ ˜oes interceptadas quando o usu ´ario autenticado era um advogado. Posteriormente, procedeu-se o mesmo quando o usu ´ario era um promotor. • Como n ˜ao foi poss´ıvel edit ´a-las para acessar a func¸ ˜ao “Push” com um usu ´ario de promotor,
a pr ´oxima tentativa, ent ˜ao, foi copiar uma requisic¸ ˜ao e uma resposta quando a funcional- idade era acessada com sucesso e colar quando a tentativa era advinda de um usu ´ario promotor. Tamb ´em n ˜ao obteve-se sucesso. Portanto, concluiu-se que o sistema n ˜ao est ´a suscet´ıvel ao escalonamento.
Cap´ıtulo 18. Testing for SQL Injection (OWASP-DV-005)
18 Testing for SQL Injection
(OWASP-DV-005)
18.1
Objetivos
• Enumerar pontos de entrada de dados do usu ´ario n ˜ao filtrados
• Executar comandos SQL maliciosos nos pontos de entrada enumerados • Explorar informac¸ ˜oes sens´ıveis alcanc¸ ´aveis pela injec¸ ˜ao
18.2
Pr ´e-requisitos
• Ferramentas de automatizac¸ ˜ao de injec¸ ˜ao (SQLmap, SqlDumper, etc)
18.3
Metodologia
Ataques de injec¸ ˜ao de SQL s ˜ao classificados em tr ˆes categorias, de acordo com o procedi- mento utilizado na injec¸ ˜ao e o comportamento exibido diante desta. Dessa forma, tem-se:
• Inband: o dado solicitado pelo atacante ´e retornado pelo mesmo canal de injec¸ ˜ao de c ´odigo. Para o caso de uma aplicac¸ ˜ao Web, o resultado ´e exibido na pr ´opria p ´agina de reposta da aplicac¸ ˜ao;
• Out-of-band: o dado requerido ´e devolvido por vias indiretas, alternativas, como, por ex- emplo, para o e-mail do atacante;
• Inferential: n ˜ao remete h ´a uma transfer ˆencia de dados, ou seja, a informac¸ ˜ao desejada ´e obtida, ou reconstruida, com base em padr ˜oes de infer ˆencias sobre as consultas efetuadas no banco de dados.
Conhecidas essas categorias, passamos, agora, a nos importar com a caracter´ıstica de re- torno de consulta oferecida pela aplicac¸ ˜ao. Um aplicac¸ ˜ao Web pode, quando de uma consulta de sintaxe errada, retornar ingenuamente o erro do pr ´oprio SGDB (fornecendo detalhes importantes e facilitadores ao atacante) ou, ao contr ´ario, apresentar uma p ´agina de erro gen ´erica, sobre a qual pouca, ou nenhuma, informac¸ ˜ao pode ser explicitamente determinada. Para o segundo caso, de ocultac¸ ˜ao de erro diante de uma consulta, cabe ao testador inferir acerca dos padr ˜oes estruturais das querys e dos resultados l ´ogicos provenientes das mesmas; este ´ultimo caso ´e comumente conhecido como Blind Injection.
Cap´ıtulo 18. Testing for SQL Injection (OWASP-DV-005)
A principal condic¸ ˜ao para injec¸ ˜ao de c ´odigo SQL ´e a n ˜ao filtragem de par ˆametros que t ˆem como origem o usu ´ario. Seja em consultas, ou mesmo em formul ´arios de autenticac¸ ˜ao, se preenchida essa condic¸ ˜ao, torna-se poss´ıvel testar variac¸ ˜oes de querys e, de acordo com elas, observar o comportamento da aplicac¸ ˜ao. Por conseguinte, a constatac¸ ˜ao da injec¸ ˜ao de SQL pode ser trabalhada manualmente, atentando-se a todas as consultas e par ˆametros envolvidos nas mesmas no contexto da aplicac¸ ˜ao, ou automaticamente – abordagem tradicionalmente empre- gada em situac¸ ˜oes de Blind Injection, cujo esforc¸o, em termos de n ´umero de querys necess ´arias, ´e muito alto.
18.4
Execuc¸ ˜ao
Para o teste nesta sec¸ ˜ao tratado, o primeiro passo ´e elencar os pontos de poss´ıvel injec¸ ˜ao de c ´odigo. No caso do sistema e-SAJ, s ˜ao fontes de dados de interesse do testador os formul ´arios de autenticac¸ ˜ao e de consulta de processos ou petic¸ ˜oes. Cabe, aqui, ser ressaltada a import ˆancia em se verificar formul ´ario por formul ´ario, campo por campo. Isso ´e necess ´ario porque uma ´unica vari ´avel n ˜ao filtrada pode representar o comprometimento de toda a infraestrutura existente em torno da aplicac¸ ˜ao Web.
Na figura 18.1, ilustra-se um tentativa de anexar conte ´udo SQL `a cla ´usula de busca, objetivando- se, com isso, averiguar um eventual processamento dessa query pelo SGBD. O sucesso dessa ac¸ ˜ao depende da filtragem ou n ˜ao existente na aplicac¸ ˜ao. Como pode-se perceber, o sistema e-SAJ exibe uma mensagem de erro personalizada quando o termo de busca cont ´em dados n ˜ao correspodentes aos que est ˜ao armazenados no banco, ou, adicionalmente, quando s ˜ao anex- ados comandos SQL ao termo de busca. Note-se a diferenc¸a de resultados entre as buscas realizadas em 18.1 e 18.2.
O insucesso de execuc¸ ˜ao, em um determinado formul ´ario, de comandos SQL n ˜ao implica na inexist ˆencia de pontos de injec¸ ˜ao em outros lugares da aplicac¸ ˜ao. Mesmo diante de uma p ´agina de erro personalizada, comportamento apresentado pelo e-SAJ, ainda pode ser poss´ıvel inferir logicamente sobre o processamento das consultas. Essa infer ˆencia, levada a cabo usando como vetor uma vari ´avel n ˜ao filtrada, remete a uma modalidade mais sofisticada de injec¸ ˜ao de SQL: Blind Injection. Para testar diversas categorias de ataque de injec¸ ˜ao SQL, recomanda-se o uso de ferramentas como o SQLmap. Vide figura 18.3.
Cap´ıtulo 18. Testing for SQL Injection (OWASP-DV-005)
Figura 18.1: Tentativa de injec¸ ˜ao de comando SQL em formul ´ario de consulta do e-SAJ
Cap´ıtulo 18. Testing for SQL Injection (OWASP-DV-005)
Figura 18.3: SQLmap testando injec¸ ˜ao de SQL em vari ´aveis da URL de consulta processual do e-SAJ
Cap´ıtulo 19. Testing for Buffer Overflow (OWASP-DV-014)
19 Testing for Buffer Overflow
(OWASP-DV-014)
19.1
Objetivos
• Pequisar por falhas de overflow conhecidas em componentes da aplicac¸ ˜ao (linguagem de programac¸ ˜ao, servidor de aplicac¸ ˜oes, bibliotecas de terceiros, etc)
• Sob posse do c ´odigo da aplicac¸ ˜ao, vasculh ´a-lho em busca de m ´a alocac¸ ˜ao e mal gerenci- amento de mem ´oria
19.2
Pr ´e-requisitos
• Acesso ao c ´odigo fruto da an ´alise
• Ferramentas de depurac¸ ˜ao (variam de acordo com a linguagem)
19.3
Metodologia
Consiste em explorar o c ´odigo da aplicac¸ ˜ao e verificar onde existem fragmentos de c ´odigo que possam ser utilizados de forma indevida para, assim, alcanc¸ar espac¸os mem ´oria de forma n ˜ao autorizada.
Como o E-SAJ ´e desenvolvido na linguagem Java, que ´e uma linguagem que possu´ı geren- ciamento de mem ´oria e aborta a execuc¸ ˜ao em caso de tentativas de acesso a ´areas mem ´oria indevidas, o teste consiste em analisar se n ˜ao h ´a erros poss´ıveis na tecnologia Java.
19.4
Execuc¸ ˜ao
Como j ´a mencionado na sec¸ ˜ao de ‘Metodologia‘, a busca por atalhos que permitem a circunvenc¸ ˜ao de regi ˜oes de mem ´oria reservadas, ou protegidas, requer que o testador tenha em m ˜aos o c ´odigo-fonte da aplicac¸ ˜ao. No entanto, como n ˜ao h ´a acesso ao c ´odigo fonte da aplicac¸ ˜ao, n ˜ao foram analisadas chamadas nativas JNI, poss´ıvel reduto de condic¸ ˜oes de buffer overflow. Por conseguinte, foram investigadas eventuais falhas na plataforma Java. Conforme o site da RNP, as seguintes vers ˜oes do Java s ˜ao suscet´ıveis a falhas de buffer overflow:
• Sun Java JDK 1.5.x • Sun Java JRE 1.3.x
Cap´ıtulo 19. Testing for Buffer Overflow (OWASP-DV-014)
• Sun Java JRE 1.4.x • Sun Java JRE 1.5.x / 5.x • Sun Java SDK 1.3.x • Sun Java SDK 1.4.x
H ´a de se sobressaltar, por ´em, que esses relatos s ˜ao de 2008 e se relacionam `a vulnerabili- dade ‘Sun Java JRE GIF Image Processing Buffer Overflow Vulnerability‘.
Durante o processo de pesquisa de falhas de buffer overflow, um testador, geralmente, procu- raria por exploits 0-day na tecnologia de desenvolvimento sendo utilizada. Exploits 0-day podem ser entendidos como ferramentas(seja um script ou procedimento de ataque mais amplo) que atacam falhas `as quais ainda n ˜ao foram reparadas. Trata-se de uma classe cr´ıtica de artefato de explorac¸ ˜ao de vulnerabilidade. Contextualizando para o cen ´ario trazido pelo sistema e-SAJ, por exemplo, onde n ˜ao h ´a, pelo testador, a posse do c ´odigo, esse tipo de exploit, neste par ´agrafo explicado, seria um item adicional a ser considerado durante o teste de intrus ˜ao.