Relatório Fícti

de 23

RELATÓRIO DE TESTE DE INVASÃO

DE:

PARA:

© DEXTERLAB CONSULTORIAS - Todos os direitos reservados 2014

Este documento contém informações confidenciais e proprietárias. É destinado somente para uso

exclusivo da rede JOÃOSUPERMERCADOS. A reprodução ou o uso não autorizado deste documento é

proibido.

Diversos testes foram conduzidos pelos profissionais de segurança da DEXTERLAB CONSULTORIA. A

DEXTERLAB garante que todos os pontos apresentados neste relatório são verdadeiros através de

provas de conceitos.

Estes Testes de Invasão identificou e explorou diversas vulnerabilidades que podem causar grandes

prejuízos ao negócio da empresa. Como sempre surgem novas vulnerabilidades, recomenda-se que

testes como esses sejam conduzidos a cada mudança realizada no ambiente de TI ou em intervalos de

3 a 6 meses.

de 23

DETALHES DO DOCUMENTO

Empresa Cliente JoãoSupermercados Título do

Documento Relatório dos Testes de Invasão

Referência DL-2014010

Classificação Confidencial Tipo de

documento Relatório

Responsável pelos testes Empresa Contratada Equipe de Pentesting DEXTERLAB CONSULTORIAS

HISTÓRICO DO DOCUMENTO

Data Versão Autor Comentários

10/11/2014 01.00 Vitor Melo Versão Inicial. 16/11/2014 01.01 Vitor Melo Revisão do documento.

CONTATO

Para mais informações sobre este documento e seu conteúdo, por favor, entrar em contato com os

serviços profissionais da DEXTERLAB CONSULTORIAS.

Nome DEXTERLAB CONSULTORIAS

Endereço R. Carlos Silveira Santos, 850 - Centro, João Pessoa - PB, 58040-390

Telefone (83) 3241-1989 E-mail [email protected]

de 23

CONTEÚDO

1. RESUMO EXECUTIVO ............................................................................................................ 4

2. ESCOPO ................................................................................................................................. 5

2.1 SISTEMAS ALVOS ........................................................................................................... 5

3. METODOLOGIA ......................................................................................................................... 6

3.1 FERRAMENTAS .................................................................................................................... 6

3.2 CLASSIFICAÇÃO DOS IMPACTOS DAS VULNERABILIDADES ................................................. 7

4.RELATÓRIO TÉCNICO ................................................................................................................. 8

4.1 INFRAESTRUTURA ............................................................................................................... 8

4.1.1 Ausência de senha no acesso remoto ao MySQL ......................................................... 9

4.1.2 Política de Senha fraca no VNC Server ....................................................................... 11

4.2 APLICAÇÕES WEB .............................................................................................................. 13

4.2.1 Injeção no formulário de upload ................................................................................ 13

4.2.2 Referência insegura e direta a objetos ...................................................................... 17

4.2.3 Exposição de dados sensíveis ..................................................................................... 19

4.2.4 Cross-Site-Scripting .................................................................................................... 20

4.2.5 Furo de Autenticação e Gerência de Sessão .............................................................. 21

5. CONCLUSÃO ............................................................................................................................ 23

de 23

1. RESUMO EXECUTIVO

Este relatório descreve detalhadamente os resultados encontrados dos Testes de

Invasão realizados no servidor e aplicações web da rede JOÃOSUPERMERCADOS. Estes testes

foram realizados por profissionais qualificados e certificados na área. O objetivo do

procedimento efetuado foi identificar e explorar vulnerabilidades de infraestrutura e

aplicações que podem impactar nos negócios da rede JOÃOSUPERMERCADOS, antes que um

usuário malicioso ou um ataque externo o faça.

Para avaliar a segurança da infraestrutura e das aplicações, a DEXTERLAB

CONSULTORIAS, durante o período de testes, do dia 10/11 à 14/11/2014, realizou acessos não

autorizados, obtenção de informações confidenciais e identificou e explorou outros tipos de

vulnerabilidades.

Inicialmente o reconhecimento da rede foi executado no endereço IP fornecido pela

rede JOÃOSUPERMERCADOS, entendendo entre ambas as partes que estes mesmos fazem

parte do escopo do acordo. Apesar da rede JOÃOSUPERMERCADOS ter uma presença externa

mínima, com apenas um domínio, pelas vulnerabilidades encontradas neste último, a

superfície de ataque para usuários com más intenções é muito grande.

Recomenda-se que o resultado destes testes sejam usados pela rede

JOÃOSUPERMERCADOS para tomar decisões de melhoria quanto ao seu programa de

segurança da informação. É importante enfatizar que todos os resultados transparecem o

estado de segurança do ambiente de TI somente no período acordado e por esta razão é

interessante que o cliente se submeta novamente aos testes a cada mudança realizada em seu

ambiente ou em intervalos de 3 a 6 meses.

de 23

2. ESCOPO

Assim como todo projeto de segurança da informação, as estratégias e táticas que

serão aplicadas nos testes de invasão devem ser muito bem planejadas. Por esta razão

juntamente com os diretores da JOÃOSUPERMERCADOS, diversas reuniões foram realizadas

para definir bem o escopo do serviço de Pentesting que foi realizado pela equipe de

profissionais da DEXTERLAB CONSULTORIAS.

A JOÃOSUPERMERCADOS se submeteu aos testes de invasão buscando alcançar os

seguintes objetivos:

Testar a efetividade das suas soluções tecnológicas implementadas;

Determinar as medidas que devem ser tomadas para melhor aliviar os riscos

provenientes das vulnerabilidades e ameaças detectadas;

E avaliar a habilidade de reação do departamento de TI em identificar e responder aos

ataques corretamente.

Preocupados com o impacto que os testes poderiam causar ao seu ambiente de TI, foi

solicitado à realização de um Pentesting menos agressivo, onde as explorações não causariam

a disponibilidade dos sistemas.

Por ter um ambiente relativamente pequeno, o prazo estipulado e acordado para os

dias, foi de uma semana, sem contar com os dois dias do final de semana, sábado e domingo.

Iniciando no dia 10/11/14 com término no dia 14/11/14. Sendo este prazo alterado, se

solicitado.

O tipo de teste executado foi o não anunciado e o Grey-box. Quando os testes não são

anunciados, significa que todos os funcionários não sabem que estão sendo auditados. E por

ser Grey-box, a Equipe de Pentesting da DEXTERLAB CONSULTORIAS teve acesso somente

algumas informações como endereços IPs, sendo eles responsáveis por descobrir as outras

informações.

A garantia das informações aqui reportadas foi assegurada por meio da assinatura de

um contrato formal, onde a DEXTERLAB CONSULTORIAS juntamente com o

JOÃOSUPERMERCADOS concordou em não divulgar as informações compreendidas pelo

acordo.

2.1 SISTEMAS ALVOS

Segue a lista das URLS e servidor definidos como alvo para os testes de invasão:

de 23

APLICAÇÕES

URL 1 vitor.physecure.com.br

URL2 192.168.56.102/dvwa

SERVIDOR (Metasploitable)

ENDEREÇO IP 192.168.56.102

3. METODOLOGIA

No ambiente da Tecnologia da Informação, diversas metodologias são usadas para

diferentes finalidades, compreendendo não só os níveis táticos, mas também o operacional da

organização.

Dessa forma, é fato concluir que a metodologia é parte fundamental no processo de

execução de um Pentesting, pois o mesmo consiste em um conjunto de procedimentos.

Apesar de existirem diferentes metodologias no mercado, como OSSTMM, OWASP, ISSAF,

NIST, que podem ser executadas para aplicar um Pentesting, a DEXTERLAB CONSULTORIAS

baseada na sua experiência de mercado prefere utilizar a sua própria, composta de quatro

fases:

Os tamanhos das caixas coloridas variam representando a jornada do amplo ao

específico ao longo do Pentesting. Por exemplo, a fase inicial de coleta de informações

recomenda-se que seja a mais duradora, pois quanto maior o conhecimento sobre o ambiente

alvo, mais fácil será invadi-lo. A duração de cada fase pode variar dependendo das

informações encontradas.

3.1 FERRAMENTAS

Várias ferramentas comerciais e de código aberto foram usadas durante os testes. São elas:

de 23

Port Scanning e FootPrinting Nmap, Google

Enumeração em Aplicações

Web

Nikto

Identificação de

Vulnerabilidades

Nessus

Teste de Invasão em Redes Metasploit Framework, Hashcat

Teste de Invasão em

Aplicações Web

Burp – Free Edition

Verificação e Pesquisa de

Vulnerabilidades

http://securityfocus.com, http://www.osvdb.org,

http://www.metasploit.com, www.exploit-db.com/

3.2 CLASSIFICAÇÃO DOS IMPACTOS DAS VULNERABILIDADES

Ao longo do documento, cada vulnerabilidade descrita foi classificada com níveis de

severidade. Esta classificação de severidade foi adotada de acordo com o impacto que as

mesmas podem causar se exploradas. As categorias são Baixo, Moderado e Alto:

Baixo: São condições identificadas que não resulta diretamente no comprometimento

de uma rede, sistema, aplicação ou informação. Mas pode ser usado em conjunto

com outras informações para ganhar o conhecimento para comprometer estes

recursos. Geralmente apresenta poucas informações sobre um ativo. Como por

exemplo, ao banner de algum serviço.

Moderado: Vulnerabilidades classificadas com este tipo de severidade incluem

sistemas, arquivos e serviços não protegidos que podem causar a negação dos

serviços de sistemas não críticos ou exposição de informações de configurações, que

podem fornecer detalhes que facilitaram uma futura exploração.

Alto: São condições identificadas que podem comprometer diretamente uma rede,

sistema, aplicação ou informação. Exemplos de vulnerabilidades altas, incluem buffer

overflows, senhas fracas ou a não utilizam delas, não criptografia, o que pode resultar

na negação de serviços ou sistemas críticos; acesso não autorizado; e a divulgação de

informações.

http://securityfocus.com/

http://www.osvdb.org/

http://www.metasploit.com/

de 23

4.RELATÓRIO TÉCNICO

4.1 INFRAESTRUTURA

Segundo o contrato acordado com a JOÃOSUPERMERCADOS, somente o servidor

Metasploitable de IP 192.168.56.102 poderia ser testado. Sabendo disso, inicialmente foi

realizado um mapeamento, para coleta de informações, do alvo com a ferramenta Nmap. Com

a ferramenta foi possível identificar as portas, serviços e sistema operacional em execução.

Os parâmetros foram combinados em um mesmo comando por questão de

praticidade. O parâmetro usado para mostrar as portas abertas na vítima foi o TCP SYN

Scan (-sS), pois apesar de ser mais lento do que o TCP Connect Scan (-sT), é mais difícil

de ser detectado. O “-sV” para informar as versões dos serviços que estavam

executando em cada porta aberta e o “-O”, para indicar o sistema operacional que o

Metasploitable estava rodando.

Dentre as vinte e três portas abertas, novecentos e setenta e sete portas foram

dadas como fechadas. E em relação à identificação do sistema operacional, ela não foi

exata, pois o Nmap indicou corretamente que é uma máquina GNU/LINUX, mas não

soube identificar especificamente a versão.

O fato das portas apresentadas no screenshot estarem abertas, não são

sinônimos da máquina estar vulnerável, mas apenas que há um serviço sendo

oferecido naquela porta. Por esta razão, uma análise mais a fundo de cada informação

apresentada no mapeamento, foi feita e para auxiliar a identificação de

vulnerabilidades, optou-se por usar a ferramenta Nessus.

de 23

4.1.1 Ausência de senha no acesso remoto ao MySQL

Nível de Severidade

Alto

Resumo

A varredura da ferramenta Nessus nos informou que o banco MySQL que está

execução no servidor Metasploitable, pode ser acessado remotamente sem a

necessidade de utilizar senhas, o que possibilita a um atacante ter acesso a todo o

banco de dados remotamente.

Prova de Conceito

Para comprovar a vulnerabilidade, foi realizada a tentativa de acesso ao banco,

com o usuário administrador, sem senha e de imediato o acesso foi obtido.

Estando dentro do banco de dados foi possível conhecer a organização do

mesmo. Como evidência, usamos o banco da aplicação dvwa e selecionamos a coluna

usuários:

de 23

Identificamos que esta base dvwa, as senhas estão sendo armazenadas com os

seus respectivos hashes. Como essa não é uma forma segura de armazená-las em um

banco, usamos a ferramenta hashcat para realizar um ataque de dicionário, passando

arquivos como parâmetros e assim quebramos a senha do administrador:

Na base da owasp10 obtivemos acesso a uma informação extremamente

confidencial e crítica que são as de cartão de crédito dos clientes:

E a senha de cada usuário que está armazenada em texto plano:

de 23

Recomendação

Como foi possível ter acesso ao banco com privilégios de administrador, a

primeira recomendação é criar uma senha forte, com no mínimo dez caracteres,

contendo letras maiúsculas e minúsculas, números e caracteres especiais para o

acesso remoto. Segunda recomendação é limitar o acesso ao banco através do

Firewall, por exemplo, para um IP específico, no caso o administrador do banco. A

terceira é atualizar a versão do banco para a mais nova, pois está executando uma

versão bastante vulnerável e última, é proteger os dados dos clientes criptografando-

os, garantindo uma proteção maior aos dados armazenados na base.

Referências

http://www.mysql.com/

http://dev.mysql.com/doc/refman/5.6/en/writing-password-validation-plugins.html

http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html

http://www.myquerybuilder.com/help/howtosetupaconnection

4.1.2 Política de Senha fraca no VNC Server


Alto

Resumo

A varredura da ferramenta Nessus nos informou que o servidor VNC, usado

para possibilitar interfaces gráficas remotas no Metasploitable, pode ser acessado

com uma senha fraca, ou seja, está utilizando uma Política de Senhas Fraca,

possibilitando a um atacante ter acesso e controle da máquina vulnerável com

facilidade.

http://www.mysql.com/

http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html

http://www.myquerybuilder.com/help/howtosetupaconnection

de 23

Prova de Conceito

Para comprovar a vulnerabilidade, tentamos e conseguimos acesso ao servidor

com a senha “password” apresentada pelo Nessus:

Estando dentro do servidor Metasploitable, foi possível navegar pelo sistema

de arquivos do sistema, encontrando usuários que possuem shell, os bancos e

aplicações hospedadas, entre outras coisas. Para garantir que este acesso não seria

perdido, a senha de root foi trocada, para possibilitar o acesso posterior à máquina por

meio de SSH e ainda outro usuário foi criado:

de 23

Recomendação

Como foi possível ter acesso ao servidor com privilégios de administrador, a

primeira recomendação é seguir a Política de Senhas fortes já comentadas na subseção

anterior para o acesso remoto. Substituir o uso do VNC no servidor por um tipo de

acesso mais seguro como o SSH, o qual garante que os dados trafegados entre cliente

e servidor são criptografados, limitando o acesso a determinadas máquinas por meio

de chaves criptográficas.

Referências

http://www.openssh.com/

https://www.realvnc.com/products/vnc/documentation/5.0/guides/user/aj1074738.h

tml

4.2 APLICAÇÕES WEB

DVWA

4.2.1 Injeção no formulário de upload


Alto

Resumo

A partir da exploração da vulnerabilidade já apresentada na subseção 4.1.1, obtivemos

as credenciais de acesso à aplicação dvwa. Nela exploramos o formulário de upload. Que por

falhas de programação não valida adequadamente o tipo de extensão que está sendo enviada

para o servidor, o que possibilita a um atacante inserir scripts para obtiver uma shell reversa

da máquina vulnerável.

Prova de conceito

Como não há uma validação apropriada, usando o “msfpayload” da ferramenta

Metasploit Framework, foi criado um arquivo com o nome “php_shell_reverso.php”,

responsável por montar o túnel reverso com a vítima e inserimos no campo:

https://www.realvnc.com/products/vnc/documentation/5.0/guides/user/aj1074738.html

https://www.realvnc.com/products/vnc/documentation/5.0/guides/user/aj1074738.html

de 23

Para ativar uma conexão reversa na porta 4444 com a nossa máquina, primeiramente

foi setado pelo “msfconsole” do Metasploit Framework um listener, o qual ficou esperando a

execução do código.

Execução do código php pelo navegador:

de 23

Após a execução do código, uma sessão “meterpreter” é retornada. Nela, há a

possibilidade de fazer o dump dos hashes de senhas do sistema, migrar para outro processo,

além de disponibilizar um shell interativo para que sejam escalados privilégios com a execução

de comandos específicos na máquina alvo.

Como evidência da exploração, um arquivo chamado “hackeado.html” foi criado e

hospedado no servidor, comprovando também que haveria a possibilidade de ser realizar um

deface das páginas hospedadas.

de 23

Recomendação

Para evitar que este tipo de vulnerabilidade exista na aplicação e ela seja explorada, é

recomendado que em nível de código, seja inserida uma validação das extensões dos arquivos,

de acordo com a função do campo, que pode variar desde aceitar documentos como imagens.

Referências

http://stackoverflow.com/questions/254184/filter-extensions-in-html-form-upload

http://stackoverflow.com/questions/310714/how-to-check-file-types-of-uploaded-files-in-php

PHYSECURE

Na aplicação physecure, disponibilizada no domínio vitor.physecure.com.br

(54.173.106.152), por não gerar tantas requisições, o que poderia comprometer a

disponibilidade da aplicação, o web server scanner Nikto foi o selecionado para coletar as

informações iniciais que auxiliaram a execução das etapas do processo de invasão. Com este

scanner open-source as configurações dos servidores foram checadas, foram verificados a

presença de diretórios ocultos, opções de HTTP usados, entre outras informações.

De fato os resultados do Nikto nos trouxe uma série de detalhes e recursos que são

considerados vulnerabilidades, alguns deles foram explorados por nós nas subseções a seguir.

http://stackoverflow.com/questions/254184/filter-extensions-in-html-form-upload

de 23

4.2.2 Referência insegura e direta a objetos


Moderado

Resumo

A referência direta ao objeto acontece quando um programador expõe a referência de

objetos que deveriam ser somente visualizados em ambientes de homologação, como

arquivos, diretórios ou chaves do banco. Quando não há uma verificação ou controle de acesso

sobre estes objetos, atacantes podem manipular estas referências para obter acesso não

autorizado a dados.

Prova de conceito

A fim de comprovar que de fato a vulnerabilidade da referência direta de objetos

apresenta pela ferramenta Nikto existe, a navegação pelos diretórios informados e outros foi

executada:

No decorrer da navegação o arquivo de backup do banco da aplicação foi encontrado.

O fato de não ter um controle de acesso apropriado para um tipo de arquivo tão crítico como

este, torna a vulnerabilidade, que tem o seu nível de severidade classificada como moderada,

em crítico.

de 23

Analisando detalhadamente o arquivo de backup, conhecemos a estrutura e organização do

banco da aplicação, como versão, base, tabelas, colunas, usuários e senhas.

Com todos os dados em mãos, um usuário da base da aplicação foi selecionado, no caso

Ramiro Santos e com suas credenciais, matrícula e senha, acessamos a aplicação:

de 23

A mesma vulnerabilidade existente na página principal da aplicação, anteriormente ao

processo de logon, que nos permitiu encontrar o arquivo de backup, também existe sobre a

perspectiva do usuário logado. Pois, o Ramiro Santos, que deveria visualizar somente os

chamados 106, 107 e 108, poderia através da manipulação da URL acessar outros incidentes

que não são de sua responsabilidade. Comprovamos este ponto manipulando o parâmetro

“seq” para o número 150 na URL:

Recomendação

Com o uso de boas práticas de desenvolvimento seguro esta vulnerabilidade pode ser

facilmente mitigada, bastando aplicar mapeamentos de referências e validações de acessos

por cada usuário.

Referências

https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

4.2.3 Exposição de dados sensíveis


Alto

Resumo

Muitas aplicações web não protegem devidamente os dados sensíveis, tais como

cartões de crédito, IDs e credenciais de acesso. Os atacantes podem explorar esta

vulnerabilidade para roubar ou modificar esses dados desprotegidos. Por esta razão, parada

dados sensíveis é recomendado sempre utilizar a criptografia tanto no armazenamento quanto

no trânsito de dados na rede (HTTPS).

Prova de conceito

Sabe-se que o protocolo HTTP permite a transferência de páginas web entre o cliente

web (browser) e o servidor web. Este protocolo deve ser usado somente quando informações

https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

de 23

confidenciais não estão sendo transmitidas entre eles. Neste caso, isso significa que por

aplicação physecure ter em backend um banco com as credenciais de acesso dos usuários,

deveria estar utilizando o protocolo HTTPS para garantir a confidencialidade e integridade dos

dados trafegados. Tendo o Burp Suite atuando como proxy, comprovou-se que os dados estão

trafegando em texto plano. Evidência coletada após inserir uma matrícula e senha qualquer:

Recomendação

A utilização do HTTPS como um HTTP com o SSL (Secure Socket Layer) ou, com TLS

(Transport Layer Security) adicionam camadas de segurança que fornecem a confidencialidade

e integridade das comunicações, por isso é importantíssimo que em aplicações como estas

onde são trafegadas informações sensíveis seja utilizado este protocolo.

Referências

https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure

4.2.4 Cross-Site-Scripting


Moderado

Resumo

Falhas de Cross-Site-Scripting, conhecidas como XSS, ocorrem sempre que uma

aplicação recebe dados não confiáveis e apresenta ao navegador sem realizar a validação

adequada. XSS permite aos atacantes executarem scripts no navegador da vítima,

possibilitando-os “sequestrar” sessões do usuário, bem como redirecionar o usuário para sites

maliciosos.

https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure

de 23

Prova de conceito

Para validar a existência desta vulnerabilidade, sobre a perspectiva do usuário logado

Ramiro Santos, o seguinte código foi inserido na URL: “

<script>alert(document,cookie)</script>”, instantaneamente o navegador trouxe o cookie do

usuário logado.

Este tipo de exploração é chamado de XSS Stored (XSS Persistente), pois o código

malicioso inserido pode ser permanentemente armazenado no servidor web, banco de dados,

fórum, campo de comentários e etc. Onde o usuário torna-se vítima ao acessar a área afetada

pelo armazenamento do código.

Recomendação

Deve-se levar em consideração que todas as entradas de dados do usuário não são

confiáveis. Por isso todos os dados fornecidos por eles, devem ser verificados para assegurar

que não causaram um mau comportamento da aplicação.

Referências

https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)

4.2.5 Furo de Autenticação e Gerência de Sessão


Alto

Resumo

Um dos mecanismos mais importantes para a segurança das aplicações web é a

Autenticação e Gerenciamento de Sessão. Mesmo assim, comumente é possível se deparar

com falhas nesses mecanismos, colocando em riscos as credenciais de acesso dos usuários.

https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)

de 23

Prova de conceito

Analisando o processo de autenticação (logon) e o logout da physecure, as

vulnerabilidades a seguir foram encontradas:

Para troca de senhas não é exigido nenhuma Política de Senhas robusta;

Na autenticação não é utilizado o CAPTCHA, sistema que impede que ferramentas

automatizadas realizem ataques de força bruta na senha;

As credenciais são enviadas para o servidor em texto plano;

Na troca de senhas, um link de uso único deveria ser enviado para o e-mail do

solicitante e este mesmo trocaria a senha, mas não deve existir a possibilidade de

repetição de credenciais já utilizadas;

Senha atual aparece em texto plano na própria aplicação;

Ao se deslogar, a sessão não é encerrada, apenas há um redirecionamento para a

página principal da aplicação.

Senha do usuário Ramiro Santos foi trocada para o número “1” sem envio de link por e-mail:

Captura da troca da senha pelo Burp Suite:

Recomendação

Diversos procedimentos de mitigação destas vulnerabilidades são sugeridos pela

OWASP, como por exemplo:

Não permitir que o processo de login comece em uma página não criptografada;

Impedir que o usuário possa utilizar senhas antigas;

Exigir uma Política de Senhas robustas;

Assegurar que todas as páginas tenham um link de logout;

de 23

Encerrar a sessão do usuário ao deslogar;

Entre outras que podem ser encontrados nos links de referências.

Referências

http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml

http://www.owasp.org/index.php/Guide_to_Authentication

http://www.owasp.org/index.php/Reviewing_Code_for_Authentication

http://www.owasp.org/index.php/Testing_for_authentication

5. CONCLUSÃO

Durante a execução dos Testes de Invasão, diversas vulnerabilidades foram

identificadas. As classificações variaram entre Moderadas e Altas. Onde foi comprovado que a

exploração delas, pode causar grandes prejuízos e impactos para o negócio da

JOÃOSUPERMERCADOS e seus clientes.

Os objetivos principais definidos no escopo como testar a efetividade suas soluções

tecnológicas implementadas e determinar as medidas que devem ser tomadas para melhor

aliviar os riscos provenientes das vulnerabilidades e ameaças detectadas foram alcançados.

Assumindo a identidade de um atacante com más intenções, comprovou-se que com o

auxílio de ferramentas comerciais e abertas e com o mínimo de conhecimento técnico sobre

elas, é possível comprometer as aplicações e oservidor, se caso boas práticas de segurança não

forem aplicadas nestes ativos.

Desta maneira a DEXTERLAB CONSULTORIAS sugere fortemente que todas as

recomendações sejam aplicadas ou adotadas pela equipe de TI da JOÃOSUPERMERCADOS,

pois são elas que irão mitigar riscos maiores ao negócio.

Relatório Fícti

Technology

Transcript of Relatório Fícti