Em resumo: pentest ou análise de vulnerabilidades não é uma questão de uma coisa ou outra, mas de sequência. Uma análise de vulnerabilidades encontra de forma automatizada vulnerabilidades conhecidas e configurações erradas, depressa e a baixo custo, mas com falsos alarmes e pontos cegos. Um teste de intrusão verifica de forma direcionada o que um atacante poderia efetivamente alcançar. Um programa de bug bounty abre a verificação a investigadores externos e só compensa quando análises e pentests fazem parte da rotina. Para a maioria das PME, a sequência é: analisar com regularidade, corrigir as constatações, mandar testar de forma direcionada, criar um ponto de contacto para vulnerabilidades.
Porque é que a pergunta se coloca de novo depois do PHP2Shell
Quem, depois do PHP2Shell, verifica o seu site com um analisador online pode obter resultados confusos. Um analisador comunica talvez uma vulnerabilidade crítica, embora o fornecedor de alojamento tenha confirmado o patch. Outro não comunica nada, embora o servidor ainda use uma versão antiga do PHP, porque a indicação de versão está oculta.
A razão está no modo de trabalho. Muitos analisadores deduzem a vulnerabilidade da versão apresentada. As distribuições instalam, porém, backports sem alterar o número de versão; segundo relatórios, o Ubuntu 24.04, por exemplo, continua a mostrar 8.3.6 depois da atualização. Porque é assim, explica-o Porque é que o php -v mostra o mesmo número depois da atualização. A prova fiável fornece-a o changelog do pacote, veja Verificar corretamente a versão do PHP e o estado dos patches.
Isto não é um argumento contra os analisadores, mas a favor de conhecer os seus limites e de os combinar com outros métodos.
Pentest ou análise de vulnerabilidades: os três métodos comparados
| Critério | Análise de vulnerabilidades | Teste de intrusão | Bug bounty |
|---|---|---|---|
| Quem verifica? | Ferramenta automatizada | Especialistas contratados | Investigadores externos, muitas vezes através de uma plataforma |
| O que se encontra? | Vulnerabilidades conhecidas, versões desatualizadas, configurações erradas | Vulnerabilidades exploráveis, falhas de lógica, encadeamentos | O que os investigadores encontram e comunicam, muitas vezes o invulgar |
| Profundidade | Ampla, mas superficial | Profunda no âmbito acordado | Variável, depende dos participantes |
| Falsos alarmes | Frequentes | Raros, as constatações são comprovadas | Muitas comunicações, que têm de ser avaliadas |
| Planeabilidade | Elevada, repetível à vontade | Elevada, período e âmbito fixos | Baixa, as comunicações chegam continuamente |
| Pré-requisitos na empresa | Alguém que avalie os resultados | Âmbito acordado, ambiente de teste ou janela de manutenção | Processo maduro de avaliação, correção e recompensa |
| Utilização típica | Continuamente, por exemplo mensal ou após alterações | Antes do arranque, após alterações importantes, com regularidade | Como complemento em aplicações maduras e expostas |
Nenhum dos métodos substitui os outros. A análise mostra muito em pouco tempo, o pentest mostra o que realmente conta, e o bug bounty encontra aquilo em que ninguém pensou.
Nos analisadores, vale ainda a pena um segundo olhar ao tipo de análise. Uma análise a partir do exterior só vê o que qualquer visitante vê e tem muitas vezes de adivinhar as versões a partir das respostas do servidor. Uma análise autenticada, em que a ferramenta lê com credenciais próprias os pacotes instalados no servidor, dá resultados claramente mais fiáveis, precisamente quanto ao estado efetivo do pacote do PHP. Pressupõe, porém, que configure para isso um acesso restrito e o proteja bem. Para as dependências de aplicações PHP próprias existem, por sua vez, ferramentas de verificação próprias, por exemplo composer audit para pacotes do Composer.
A sequência sensata para PME
- Inventário e análise: primeiro saber que sites e servidores existem, depois analisar com regularidade. Não aceitar as constatações sem verificar, mas avaliá-las.
- Corrigir o essencial: eliminar software desatualizado, atualizações em falta e configurações erradas evidentes. Aplicar um pentest a sistemas sem patch desperdiça orçamento.
- Teste de intrusão direcionado: para as aplicações mais importantes, por exemplo a loja, o portal de clientes ou as interfaces, com âmbito claramente acordado e reteste.
- Revisão do código em desenvolvimentos próprios: quem opera aplicações PHP próprias complementa o teste com uma revisão do código-fonte. Como decorre, descreve-o Revisão de código de segurança para projetos PHP.
- Ponto de contacto para vulnerabilidades: uma política sobre como externos podem comunicar vulnerabilidades e um ficheiro security.txt nos termos da RFC 9116 em
/.well-known/security.txt, com contacto e data de validade. - Bug bounty, quando as bases estiverem assentes: só quando as comunicações são avaliadas de forma fiável e as vulnerabilidades corrigidas com rapidez.
Para que daí resulte um procedimento duradouro, vale a pena ver Gestão de vulnerabilidades para PME.
O que nenhum dos métodos consegue
Nenhum método de verificação prova que um sistema é seguro. Mostra apenas o que foi encontrado num determinado momento com determinados métodos. Um relatório de pentest limpo da primavera nada diz sobre uma vulnerabilidade como o PHP2Shell, que se torna conhecida em outubro.
Do mesmo modo, nem a análise nem o pentest respondem à pergunta de saber se um servidor já está comprometido. Para isso é preciso uma busca de vestígios no próprio sistema: processos, ficheiros, cronjobs, contas, ligações. É uma tarefa própria, com métodos próprios.
Mande verificar apenas sistemas para os quais está autorizado e esclareça de antemão, nos sistemas alojados, as regras do fornecedor. Um teste de intrusão exige uma contratação escrita com âmbito, período e interlocutores.
Quando não precisa de um teste externo
Para um site de empresa simples, sem formulários com dados sensíveis, num fornecedor de alojamento que instala as atualizações de forma fiável, basta muitas vezes uma análise regular com avaliação crítica dos resultados. Um teste de intrusão seria aqui, em regra, desproporcionado. Mais importantes são software atualizado, acessos fortes e cópias de segurança.
Um teste externo compensa em lojas, portais, desenvolvimentos próprios, interfaces para sistemas internos e em todo o lado onde clientes ou normas exijam um comprovativo independente.
Como ajuda concretamente a PHP SOS?
- Configuramos análises regulares e avaliamos os resultados, incluindo os falsos alarmes causados por backports.
- Ajudamos a corrigir o essencial antes de se investir dinheiro num pentest.
- Em conjunto com parceiros especializados, realizamos auditorias de segurança e testes de intrusão com âmbito acordado e reteste.
- Apoiamos a criação de um ponto de contacto para vulnerabilidades e de um security.txt.
Conclusão
Análise, pentest e bug bounty são degraus, não concorrentes. Quem começa com análises regulares, corrige o essencial e depois manda testar de forma direcionada obtém a maior segurança para o seu orçamento. O bug bounty é o extra para organizações cuja obrigação já está cumprida.
Perguntas frequentes
Qual é a diferença entre pentest e análise de vulnerabilidades?
Uma análise de vulnerabilidades verifica de forma automatizada se vulnerabilidades conhecidas ou configurações erradas são reconhecíveis. Um teste de intrusão vai mais longe: especialistas tentam, num âmbito acordado, explorar de facto as vulnerabilidades e encadeá-las, e avaliam as consequências.
Um analisador descobre se o meu servidor tem o patch do PHP2Shell?
Só de forma limitada. Muitos analisadores leem a versão do PHP apresentada. Se a distribuição instala um backport, o número mantém-se muitas vezes igual e o analisador comunica uma vulnerabilidade há muito fechada. Inversamente, pode ser apresentado um número novo enquanto processos antigos ainda correm.
Um programa de bug bounty é para pequenas empresas?
Em regra, ainda não. O bug bounty pressupõe que as comunicações são avaliadas depressa e as vulnerabilidades corrigidas com rapidez. Um bom início é uma política simples para comunicar vulnerabilidades, com um ficheiro security.txt.
Posso verificar o meu próprio site com um analisador?
Os seus próprios sistemas, em regra sim, se estiver autorizado para isso. Se o site está num fornecedor de alojamento, esclareça antes se as análises são permitidas ou se têm de ser anunciadas. Sistemas alheios só os verifica com autorização escrita do operador.
Com que frequência deve realizar-se um pentest?
Não há uma regra fixa. É habitual um teste antes do arranque de uma nova aplicação, após alterações importantes e a intervalos regulares, determinados pelo seu risco e, se for o caso, por exigências de clientes ou normas.