Palestrante:
Ao longo do curso, aprendemos vários métodos
para descobrir bugs e vulnerabilidades em diferentes
tipos de software e infraestrutura.
Normalmente, no final do pentest, você
precisará informar ao cliente todas
as vulnerabilidades que você encontrou ou
com todas as descobertas,
isso é feito usando um relatório pentest.
Então, basicamente, o que queremos dizer com relatório
pentest, é apenas um documento que inclui tudo o que
você encontrou por meio de seu contrato,
para que o cliente ou o
administrador possa ir em frente e corrigir todas as
vulnerabilidades e fraquezas que você encontrou.
Esses relatórios também são lidos por executivos muitas vezes, portanto,
você precisaria levar isso em
consideração, então um bom relatório deve
ser fácil, mas também é fácil de entender.
Agora, se você estiver trabalhando como pentester,
a empresa para a qual você
está trabalhando provavelmente terá seu próprio modelo e
seus próprios padrões que você deve seguir ao
escrever um relatório.
E, em muitos
casos, você nem mesmo
fará isso, simplesmente encaminhará suas descobertas para outro membro de
sua própria
equipe, e eles preencherão os espaços em branco corretamente no relatório.
Portanto, você provavelmente não precisará escrever um
do zero
e, em muitos casos, nem mesmo escreverá o relatório real que
o cliente vê.
Com isso dito, ainda quero mostrar
como isso é feito apenas para dar uma
ideia de como é um relatório pentest.
Antes de mais nada, antes de mostrar
a amostra que tenho,
vou incluir este repositório que basicamente contém um grande número de relatórios pentest.
Portanto, você pode realmente olhar para eles em busca de inspiração
e apenas para ver os diferentes
estilos que diferentes empresas
seguem ao fazer um relatório de teste.
Então você pode clicar em qualquer um deles e você
encontrará o relatório, e
você pode realmente percorrê-lo para aprender como essa empresa específica redige
seus relatórios, e talvez você encontre algo
de que goste e comece a incluir em seus próprios relatórios .
Então, vou incluir isso nos recursos da palestra para que
você possa voltar a ela para se inspirar.
Mas o que
eu realmente quero fazer é mostrar
um relatório de amostra que usamos aqui
no ZSecurity apenas para dar uma ideia das seções
principais que a maioria dos relatórios tem.
Eu também irei incluir isso nos recursos, então
fique à vontade para modificá-lo e
usá-lo, ou pegar alguns elementos se quiser.
Portanto, você observará no repositório
aqui, cada empresa tem seu próprio estilo de escrever
relatórios, mas, em geral, sempre há algumas seções principais
que você encontrará em cada relatório.
Então, começando com a primeira página bem aqui,
temos a página de rosto.
Então, novamente, você pode vender
isso como quiser, geralmente você terá o
logotipo da empresa,
o título e a data do relatório e a
versão, isso é muito importante.
E aí a gente tem a empresa, a informação da nossa empresa, então
esse relatório feito por nós, essa é
a informação da nossa empresa.
E então você tem no campo for, você
tem a empresa para a qual você está escrevendo este relatório.
Então você teria o nome
da empresa, você teria um ID específico para esta empresa.
Este é o ID com o qual você identifica esta
empresa em seus próprios registros.
Novamente, isso provavelmente não é
algo que você
mesmo fará, você receberá esse ID de sua própria empresa.
E então temos as informações de contato de ambas as empresas.
Então você pode ver nesta empresa, nós temos
pentester 1 e pentester 2 com seus endereços de
e-mail, esta poderia ser obviamente uma
lista maior com toda a equipe que está fazendo
o pentest, e
semelhante à empresa que você está
fazendo o pentest pois, novamente, você
tem seus nomes, sua posição na empresa e suas informações de contato.
Agora, novamente, tenha em
mente que você nem sempre precisa estilizar a primeira página assim,
mas mais ou menos, geralmente na primeira página,
você terá o título, a data, a versão
e as informações de contato
, é
assim que fazemos, mas, novamente, você
pode fazer da maneira que quiser
e pode se inspirar no recurso que irei incluir aqui.
Em seguida, geralmente temos o índice analítico.
Novamente, como
você pode ver, coisas simples, normalmente teremos em qualquer tipo de documento.
Isso o ajudará a navegar por todo o documento.
E como eu disse,
aqui, podemos ver as principais seções de qualquer relatório Pentest.
Portanto, é muito importante ter um resumo executivo, este é
um resumo de todo o engajamento
que é projetado para pessoas menos técnicas.
Portanto, deve dar a eles uma ideia de
suas descobertas, sem se aprofundar muito nos detalhes técnicos.
Em seguida, temos um resumo de
engajamento onde detalhamos
o escopo, isto é o que
você testou, quais partes do sistema deles você
testou, as classificações de risco que você
usou e uma visão geral de tudo o que você encontrou.
Então, novamente, até agora não estamos mergulhando
fundo ou simplesmente, este é apenas um resumo de todo o envolvimento.
Você terá uma ideia melhor de
tudo isso à medida que eu ler o relatório.
E então, na seção de detalhes técnicos, é aqui
que você mergulha muito fundo em
tudo o que encontrou.
Portanto, basicamente temos uma seção para cada descoberta.
Como você pode ver,
esta é apenas uma amostra, então
eu fiz apenas três descobertas, temos uma injeção de SQL,
um Cross-Site Request Forgery, um CSRF e uma divulgação de informações.
Como você pode ver
na primeira seção, basicamente temos
apenas
o resumo de tudo
o que encontramos, enquanto nos detalhes técnicos, basicamente
analisamos cada descoberta e falaremos sobre como
a encontramos em
detalhes, como replicá-la, você vai incluir
capturas de tela, se puder, para que a equipe
técnica possa entender exatamente a gravidade desta vulnerabilidade
e como corrigi-la.
Você notará que outras empresas incluirão
um
apêndice no final, incluindo recomendações onde
dirão exatamente como corrigir vulnerabilidades.
Como eu disse, realmente depende da empresa,
cada empresa tem seu próprio
estilo e cada empresa tem seu próprio formato.
Então, o que estou
mostrando aqui é apenas uma amostra de como
fazemos isso, você pode se inspirar nos recursos e,
em muitos casos, você
apenas terá que seguir o modelo que
sua empresa tem, porque eles não quero que você faça do seu
próprio jeito.
Então, vamos para a próxima página,
e você verá nesta
página, nós temos as informações legais.
E é por isso que
eu realmente disse, você provavelmente
não fará isso sozinho, você nunca
precisará fazer isso porque você terá partes do relatório como esta
que você nunca terá que
modificar, e elas realmente serão redigido pela equipe jurídica
de sua empresa.
Portanto, eles serão responsáveis por qualquer coisa que possa sair
do controle para garantir
que você não seja processado se
algo der errado. Isso conterá itens como isenções de responsabilidade, GDPR,
privacidade, questões legais e todas
as outras coisas que nós usamos não conheço muito
bem como pentesters e pessoas legais costumam escrever.
E então temos o log de alterações do documento.
Então, toda vez que uma alteração é feita no documento, você
pode ver, nós temos a data,
temos a versão e temos um comentário, por que
fizemos essa alteração?
Ou o que há de tão significativo nessa mudança?
Portanto, este foi o relatório inicial quando o
fizemos no dia 1º de janeiro,
e então no dia 10
de janeiro, fizemos
a segunda versão onde terminamos o Recon Stage.
Novamente, são apenas exemplos, mas
apenas para dar a você uma ideia de que
manter um registro de todas as alterações pelas quais
este documento passa é muito, muito importante.
Nem todas as empresas
fazem isso, mas, novamente, é apenas nossa
escolha adicioná-lo em nosso relatório.
Eu continuo dizendo isso apenas para dar a você
uma ideia de que não existem
regras definidas para fazer esse tipo de documento.
Você pode adicionar ou remover o
que quiser, mas as partes principais seriam a
parte jurídica, o sumário executivo, e depois a
parte técnica, essas seriam as partes principais do relatório.
Portanto, agora temos o resumo executivo e
você pode lê-lo.
Isso não deveria ser longo,
então, na
minha opinião, precisa ser uma página, no máximo duas
páginas se você realmente precisar.
E basicamente diz
apenas que fomos instruídos a testar o sistema X,
explicará como este documento está organizado, onde a
primeira seção é menos detalhada,
apenas para dar uma ideia do
risco, e a segunda é detalhada para
o pessoal técnico para entender esses riscos e corrigi-los.
E então recebemos a
classificação de risco, portanto, presumimos
que seja de alto risco com base
nas vulnerabilidades que encontramos. Ela detalha a metodologia que seguimos.
E então, temos alguns gráficos aqui.
Lembre-se, essa parte foi lida pelos executivos, são
pessoas que na maioria das
vezes não são muito técnicas e também não têm muito tempo.
Então, estamos incluindo gráficos aqui
para mostrar a quantidade de vulnerabilidades que encontramos.
Portanto, podemos ver, temos cinco vulnerabilidades que são
altas, temos 10 que são médias e oito são baixas.
Portanto, isso lhes dará uma boa
compreensão das ameaças que enfrentam.
E então vamos entrar no resumo.
Novamente, isso ainda será lido por pessoas menos técnicas.
Então, em primeiro lugar, estamos detalhando o escopo
para ter certeza de que contaremos a eles o
que testamos, mesmo que eles já nos tenham
dito o que testar, apenas para que
caso, no futuro, algo seja descoberto fora do nosso
escopo e
eles voltam para nós, podemos dizer, bem, isso estava fora
do escopo, não testamos isso.
Em seguida, estamos incluindo as classificações de risco.
Portanto, você terá isso em
todos os documentos que
deseja que eu modifique. Basicamente, estamos apenas dizendo
como classificaríamos uma determinada vulnerabilidade como baixa, média, alta ou crítica.
E estamos dizendo, em nossa opinião,
como você deve lidar com as vulnerabilidades
baixa, média, alta e crítica.
Você pode ver o que
é crítico, estamos dizendo que você precisa consertar
imediatamente, enquanto que para o baixo, você
precisa consertar no próximo ciclo de atualização.
Novamente, esta é apenas nossa opinião.
A seguir, temos a visão geral das descobertas.
Ainda estamos na
seção um, ainda é para
os executivos, não precisamos mergulhar muito.
Então, acabamos de receber a identificação de vulnerabilidade.
E você pode ver, para a primeira vulnerabilidade, é crítica,
é uma injeção de SQL.
E, em muitos casos, em muitos
relatórios, eles param por dizer que é apenas uma injeção de SQL.
Gostamos de realmente mostrar o impacto nesta seção, porque como eu
disse, esses caras não são técnicos, então
se eles lerem injeção de
SQL, eles podem não saber o que é injeção
de SQL, o que importa para eles é o impacto dessa vulnerabilidade.
Novamente, eles não têm muito tempo,
então você precisa ir direto ao ponto, então
o que estamos fazendo é dizer que é uma injeção de
SQL que pode levar a um acesso autorizado ao banco de dados.
Então agora eles sabem que com esta
vulnerabilidade, um hacker pode acessar
seu banco de dados, isso provavelmente é muito ruim.
Outra vulnerabilidade que encontramos é média, e o
CSRF novamente, muitos relatórios vão parar por aqui, realmente não
explica nada para pessoas não técnicas.
Portanto, estamos dizendo que os clientes podem ser forçados
a enviar certas solicitações não críticas, é por isso que
é um meio, não são solicitações
não críticas, mas eles podem ser forçados a enviar coisas.
E então temos uma vulnerabilidade
baixa onde a versão do PHP é
divulgada, então isso não é realmente
muito crítico porque não é
uma vulnerabilidade real que pode ser explorada para obter acesso ou expor dados do
usuário, mas esta informação pode ser útil para hackers
lidar com outros ataques
ou descobrir vulnerabilidades para esta versão específica do PHP, e é
por isso
que é permitido, é por isso que
não precisa ser atendido com muita
urgência como os críticos como mencionamos acima aqui.
E fique à vontade para ler o
texto aqui, você verá que muito dele é basicamente apenas para limpar nossos
bugs e ter certeza de que eles entenderam tudo o
que está no relatório.
E isso seria o fim do resumo, e
agora estamos nos detalhes técnicos.
Portanto, nesta seção, basicamente temos, como eu disse, uma
subseção para cada descoberta que temos, e
estamos mergulhando muito fundo nos
detalhes dessa descoberta.
Então você pode ver que esta
é a injeção de SQL que mencionamos
anteriormente no resumo, mas desta vez estamos dando
a eles
a URL que é vulnerável, estamos dando a eles
o parâmetro vulnerável, estamos dando a
eles referências para entender o que A injeção de SQL, caso eles
não entendam, estamos dando a
eles a solicitação exata e a resposta exata que
obtivemos, o que nos fez determinar que essa página em particular
é vulnerável a uma injeção de SQL.
Então estamos dando a eles o impacto aqui em detalhes,
não apenas dizendo que eles podem acessar o banco de
dados, então estamos dizendo que eles podem
acessar o banco de dados, eles
podem recuperar dados, nós temos acesso à tabela
do usuário, então você
vou mergulhar em detalhes e você deve até incluir capturas de
tela aqui se você acha que vai ser útil.
Na seção
de mitigação, estamos apenas dando
uma recomendação rápida, como eu disse, algumas empresas dão recomendações
detalhadas, isso realmente depende do engajamento também.
Portanto, neste exemplo, estamos basicamente
dizendo, use instruções preparadas com consultas parametrizadas e estamos
dando a eles uma referência para aprender
como fazer isso ou entender como funciona.
E é basicamente isso.
Então, você vai repetir isso para
cada vulnerabilidade que encontrar,
estou deixando o resto vazio, pois isso é apenas uma amostra, mas
você entendeu.
Então, você terá uma subseção para cada descoberta que
tiver, explicar tudo em detalhes para que eles entendam
a vulnerabilidade e então eles
possam ir em frente e consertá-la.
No final, muitas empresas teriam um apêndice e poderiam
ter uma seção de recomendações maior, como eu disse, esse
é o nosso estilo de redação de relatórios,
mas cada empresa tem seu próprio estilo.
Se você gosta disso, talvez passe
algum tempo examinando os relatórios
de amostra que temos neste repositório.
Obviamente, incluirei os dois links para meu exemplo e
para os outros exemplos nos recursos, para
que você possa examiná-los sozinho
e ter uma ideia de como são os relatórios pentest.
Mas, como eu disse, em muitos
casos, você simplesmente preencherá uma amostra semelhante
à que temos aqui,
de modo que nunca será solicitado a criar uma do zero.