Upload
vitor-melo
View
124
Download
2
Embed Size (px)
Citation preview
Página 1 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.
Página 2 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]
Página 3 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
Página 4 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.
Página 5 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:
Página 6 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:
Página 7 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.
Página 8 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.
Página 9 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:
Página 10 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:
Página 11 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
Nível de Severidade
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.
Página 12 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:
Página 13 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
Nível de Severidade
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:
Página 14 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:
Página 15 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.
Página 16 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.
Página 17 de 23
4.2.2 Referência insegura e direta a objetos
Nível de Severidade
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.
Página 18 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:
Página 19 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
Nível de Severidade
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
Página 20 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
Nível de Severidade
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.
Página 21 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
Nível de Severidade
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.
Página 22 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;
Página 23 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.