Recentemente, uma varredura PCI foi executada em um servidor web e o resultado foi uma falha. Alguns dos problemas poderiam ser corrigidos, mas outros simplesmente não fazem sentido para mim.
A máquina foi uma instalação limpa, há apenas duas coisas em execução, o site .NET 3.5 e o firewall do aplicativo web dotDefender.
No entanto, existem vários erros semelhantes a:
Vulnerabilidade do servidor Web Impacto: /servlet/SessionServlet: servlet padrão JRun ou Netware WebSphere encontrado. Todo o código padrão deve ser removido dos servidores. Fator de risco: Médio/ Pontuação base CVSS2: 6,4 CVE: CVE-2000-0539
Não tenho certeza do que é isso, mas não consigo encontrar nada no servidor que se pareça com isso.
Vulnerabilidade do servidor Web Impacto: /some.php?=PHPE9568F35- D428-11d2-A769-00AA001ACF42: PHP revela informações potencialmente confidenciais por meio de certas solicitações HTTP que contêm strings QUERY específicas. Fator de risco: Médio/Pontuação base CVSS2: 5,0
PHP não está instalado. Tentar adicionar essa string de consulta a qualquer página não faz nada porque o aplicativo a ignora. E fazer essa phpVersionverificação resulta em 404. Semelhante a isso, existem dezenas de erros relacionados a JSP e Oracle que também não estão instalados.
Vulnerabilidade do servidor Web Impacto: /admin/database/wwForum.mdb: Web Wiz Forums anteriores à versão 7.5 são vulneráveis a ataques de Cross-Site Scripting. O login/senha padrão é Administrador/letmein Fator de risco: Médio/ Pontuação base CVSS2: 4,0
Existem vários erros como este, me dizendo que Web Wiz Forums, Alan Ward A-Cart 2.0, IlohaMail, etc. são todos vulneráveis. Eles não estão instalados ou referenciados em nenhum lugar que eu possa encontrar.
Existem até referências a páginas que simplesmente não existem, como OpenAutoClassifieds.
Alguém pode me indicar a direção certa sobre por que esses erros estão aparecendo ou onde posso procurar para encontrar esses componentes, se eles estiverem de fato instalados?
Nota: Este site e servidor são para um subdomínio do site principal. O site principal é executado em um servidor que executa Apache/PHP, mas não tenho acesso a esse servidor. O relatório diz que o subdomínio era o site que estava sendo verificado, mas é possível que ele também tenha verificado o site principal?
Responder1
Resposta curta: não seria.
Resposta longa: uma de três coisas aconteceu:
Seu auditor escaneou a máquina errada, como disse @HopelessN00b.
(este é o cenário mais provável - você diz que o site PCI é um subdomínio e o site acima dele está em um site Apache/PHP, então é perfeitamente possível que eles tenham verificado esse site e encontrado as vulnerabilidades listadas)Sua máquina foi comprometida rapidamente.
(Sim, isso também acontece - embora se você verificou a máquina e descobriu que os resultados da auditoria são inválidos, acho que podemos descartar isso.)Seu auditor de segurança é um idiota
(Não contrate esse cara!)
Como o número 1 é o mais provável com base no que você nos contou, descubra qual máquina (nome do hosteendereço IP) que o auditor digitalizou, confirme se é a máquina correta e, se não for, faça a verificação novamente.
Verifique também essas vulnerabilidades no servidor principal (e se elas forem realmente válidas, faça com que as partes responsáveis as corrijam). Esses são problemas relativamente sérios, e mesmo que possam (e de fato pelos padrões PCIdeveSe houver separação entre o equipamento de dados do titular do cartão e seus outros locais, você continuará levantando sinais de alerta em sua auditoria se não os resolver.
(Se o seu site principal estiver em um provedor de hospedagem compartilhada que executa todas essas coisas, você pode considerar movê-lo para uma caixa dedicada ou VPS para sua tranquilidade.)