nccgroup/berserkoExtensão do Burp Suite para realizar autenticação Kerberos
Disponibilizado como código aberto pela NCC Group Plc - http://www.nccgroup.trust/
Desenvolvido por Richard Turnbull, richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
Distribuído sob a AGPL, consulte o LICENSE para mais informações
O desenvolvimento adicional do Berserko terá lugar em https://github.com/rteatea/Berserko
O Berserko é uma extensão do Burp para adicionar suporte à autenticação Kerberos. Isto é útil para testar num domínio Windows quando a autenticação NTLM não é suportada (o Burp já trata do NTLM). O Berserko não exige que a máquina onde o Burp está a ser executado esteja associada ao domínio (nem sequer que esteja a executar Windows).
A única solução existente de que temos conhecimento atualmente para testar aplicações Kerberos usando o Burp é encadear através do Fiddler, com a autenticação configurada de acordo com estas instruções. Mas o Fiddler é apenas para Windows, e encadear proxies acrescenta complexidade e prejudica o desempenho, por isso é bom ter capacidade Kerberos dentro do próprio Burp.
Obtenha o ficheiro jar do Berserko mais recente a partir do separador Releases, ou a partir da pasta berserko\releases
Vá ao separador Extender no Burp, selecione Add, certifique-se de que Java está selecionado como Extension type, e depois aponte para o ficheiro jar. Se tudo correr bem, o separador Berserko deverá ser adicionado à interface do Burp.
Existem vários controlos no separador Berserko no Burp.
A caixa de verificação Do Kerberos authentication é um interruptor principal. Enquanto não estiver ativada, o Berserko não fará absolutamente nada.
O botão Restore defaults repõe a configuração padrão do Berserko (na qual não estão presentes detalhes de domínio nem credenciais de utilizador).
O botão Clear Kerberos state limpa todos os tickets Kerberos e outro estado no cliente. A única razão pela qual poderá precisar de o utilizar seria se tivessem sido feitas alterações à configuração Kerberos no lado do servidor e quisesse começar a partir de um estado limpo.
O botão Write tickets to log escreverá informações sobre os seus tickets Kerberos atuais no fluxo de registo do Berserko - isto pode ser útil para depuração/resolução de problemas. Para ver os registos, vá ao separador Extender do Burp, selecione Berserko e consulte o separador Output abaixo. Pode fazer sentido usar a opção Save to file aqui, porque os dados dos tickets podem facilmente encher o buffer de registo na interface gráfica.
Alguns controlos têm um botão de ajuda que mostra mais informações.
Especifique o Domain DNS Name e o KDC Host usando os controlos desta secção. As caixas de texto não podem ser editadas diretamente; tem de usar o botão 'Change' para as modificar.
O Domain DNS Name deve ser o nome DNS do domínio contra o qual pretende autenticar (para ser preciso, isto é na verdade o realm Kerberos). Deve ser algo como mydomain.acme.local. Não deve ser o nome NETBIOS do domínio (que seria algo como MYDOMAIN).
O KDC Host deve ser o nome de host (ou endereço IP) de um KDC Kerberos (Key Distribution Center). Num domínio Windows, um KDC é simplesmente um controlador de domínio.
Depois de fornecer o Domain DNS Name, pode usar o botão Auto para tentar localizar automaticamente um KDC. Para isso, envia uma consulta DNS SRV para o serviço Kerberos. Se um dos seus servidores DNS for um controlador de domínio para o domínio correto, isto deverá funcionar. Caso contrário, não funcionará. ❗Esta funcionalidade não funcionará em versões recentes do Burp, porque as bibliotecas DNS necessárias não estão a ser incluídas no JRE empacotado. Pode contornar isto iniciando com um JRE completo, conforme descrito no topo deste README.❗
Quando o Domain DNS Name e o KDC Host tiverem sido introduzidos, use o botão Test domain settings para testar a conectividade. Se tudo correr bem, obterá uma resposta Successfully contacted Kerberos service.
Consulte este ficheiro para obter muito mais informações sobre como obter os valores corretos para estas Definições de Domínio.
Especifique o Username e a Password para uma conta de domínio usando os controlos desta secção. As caixas de texto não podem ser editadas diretamente; tem de usar o botão 'Change' para as modificar.
O Username deve ser apenas o nome de utilizador simples. Deve ser algo como bob. Não deve ser MYDOMAIN\bob nem [email protected] nem semelhante.
Depois de fornecer as credenciais, pode usar o botão Test credentials. Isto tentará adquirir um ticket-granting ticket (TGT) Kerberos para o utilizador especificado. Se for bem-sucedido, obterá uma resposta TGT successfully acquired. Se não for bem-sucedido, note que isto é uma tentativa de autenticação de domínio, por isso tenha cuidado para não bloquear a sua conta.
A palavra-passe não será guardada na configuração do Berserko para a próxima vez, a menos que a caixa Save password in Burp config? esteja marcada. No entanto, todas as outras definições serão guardadas.
Algumas aplicações usam delegação Kerberos no lado do servidor para encaminhar a identidade do cliente para outros servidores (mas não há uma forma fácil de determinar a partir do lado do cliente se isto está em uso).
O Berserko suporta isto, mas há um senão. A delegação só funciona se o utilizador tiver um TGT forwardable (ticket-granting ticket). A implementação Java do Kerberos, infelizmente, não fornece uma forma de especificar programaticamente que deve ser adquirido um ticket forwardable. Isto só pode ser feito adicionando uma entrada apropriada ao ficheiro de configuração krb5.conf.
Assim, para que a delegação funcione, o Berserko tem de apontar para um ficheiro krb5.conf adequado, e há duas abordagens possíveis.
A coisa mais fácil a fazer, e a abordagem recomendada, é usar o botão Create krb5.conf file. Isto criará um ficheiro adequado para si num local à sua escolha. Pode colocá-lo num diretório temporário, no diretório do seu projeto, ou onde quiser. Mas o mesmo ficheiro pode ser reutilizado indefinidamente, por isso pode fazer sentido colocá-lo num local mais permanente. O botão Change permite-lhe selecionar um ficheiro diferente para ser usado.
Se estiver interessado, o ficheiro krb5.conf criado é muito simples e terá o seguinte conteúdo:
[libdefaults]
forwardable = true
Em alternativa, pode usar o botão Change para apontar para um ficheiro krb5.conf existente no sistema. A única razão pela qual poderá querer fazer isto seria se houvesse outras definições Kerberos importantes neste ficheiro que quisesse que o Berserko apanhasse (o que, em teoria, deveria funcionar bem, mas não foi testado na prática). Note que a localização predefinida deste ficheiro no Linux é /etc/krb5.conf - outros sistemas operativos têm menos probabilidade de ter um. Se estiver a apontar para um ficheiro krb5.conf existente, certifique-se de que o edita para ativar o encaminhamento (forwarding) - adicione forwardable = true à secção [libdefaults] (ou individualmente para cada realm). Mas tenha cuidado. Pedir ao Berserko para criar o ficheiro por si será a melhor opção 99% das vezes.
Se quiser saber se a sua configuração de delegação foi bem-sucedida, use o botão Check current config. Isto dir-lhe-á se o ficheiro krb5.conf foi localizado e se a definição forwardable está correta. Note também que o Berserko lhe dirá se adquiriu ou não com sucesso um TGT forwardable quando usar o botão Test credentials.
É uma boa ideia certificar-se de que tem um ticket forwardable antes de começar a usar uma aplicação. Parece que o IIS pode colocar em cache o estado de autenticação de um utilizador no lado do servidor de uma forma que mudar de um ticket não forwardable para um forwardable não funcionará.
As definições nesta secção controlam se o Berserko tenta a autenticação Kerberos de forma 'reativa' (ou seja, espera receber uma resposta 401 do servidor e depois reenvia o pedido com um cabeçalho de autenticação Kerberos adicionado) ou 'proativa' (ou seja, adiciona o cabeçalho de autenticação Kerberos ao pedido de saída).
A vantagem da autenticação proativa é que requer apenas uma viagem de ida e volta HTTP, enquanto a autenticação reativa requer duas. A desvantagem da autenticação proativa é a possibilidade de serem enviados cabeçalhos de autenticação Kerberos para hosts que não os esperam. O Berserko também está mais apto a diagnosticar erros de autenticação quando usa a estratégia reativa.
A opção Proactive Kerberos authentication, only after initial 401 received é um híbrido destas duas abordagens, em que o Berserko autentica reativamente no primeiro pedido a um host, mas a partir daí será proativo.
Nesta secção, pode definir quais os hosts que são considerados no âmbito para a autenticação Kerberos.
Por predefinição, a caixa All hosts in this Kerberos domain in scope for Kerberos estará marcada. Isto significa que o Berserko tentará a autenticação Kerberos apenas a servidores web cujo nome de host termina com o nome DNS do domínio. Em muitas situações, isto será suficiente. No entanto, é possível ter aplicações web com Kerberos ativado cujo nome de host não assume esta forma (assumindo que o administrador configurou um Service Principal Name adequado). Para ter isso em conta, pode adicionar hosts adicionais a considerar no âmbito usando a lista à direita. Note que podem ser usados caracteres curinga (* corresponde a zero ou mais caracteres, ? corresponde a qualquer caractere exceto um ponto).
Em alternativa, pode marcar a caixa All hosts in scope for Kerberos authentication. Obviamente, isto tem a vantagem de não precisar de se preocupar em especificar o âmbito manualmente. A potencial desvantagem desta configuração é que pode levar o Berserko a enviar pedidos Kerberos ao KDC para obter tickets de serviço para hosts que não estão no domínio. Isto pode causar problemas de desempenho e problemas de privacidade (se não quiser que esta informação seja divulgada ao KDC). Isto provavelmente será um problema particular com a estratégia Proactive Kerberos authentication, caso em que o Berserko tentará adicionar um cabeçalho de autenticação Kerberos a todos os pedidos que passam pelo Burp. Esta combinação de opções não é recomendada, e o Berserko avisá-lo-á se for selecionada (mas não o impedirá efetivamente).
Se nem All hosts in this Kerberos domain in scope for Kerberos nem All hosts in scope for Kerberos authentication estiverem selecionadas, os únicos hosts no âmbito serão os que forem adicionados à lista.
A opção Plain hostnames considered part of domain, se selecionada, significa que 'nomes de host simples' (ou seja, nomes de host que consistem apenas num único componente) serão considerados parte do domínio (e, portanto, automaticamente no âmbito se All hosts in this Kerberos domain in scope for Kerberos estiver selecionada). A principal razão pela qual poderá querer desativar isto seria se a sua máquina estivesse associada a um domínio diferente daquele contra o qual está a autenticar usando o Berserko (nesse caso, os nomes de host simples provavelmente referem-se a hosts no domínio ao qual está associado).
Se selecionada, a opção Do not perform Kerberos authentication to servers which support NTLM instruirá o Berserko a não tentar autenticação Kerberos contra hosts que suportam NTLM para além de Kerberos (ou seja, hosts que devolvem tanto os cabeçalhos WWW-Authenticate: NTLM como WWW-Authenticate: Negotiate).
O Alert Level e o Logging Level podem ser configurados aqui, para NONE, NORMAL ou VERBOSE.
O Alert Level controla a quantidade de informação enviada para o separador Alerts do Burp.
O Logging Level controla a quantidade de informação enviada para a saída padrão do Berserko (isto pode ser visto no separador Extender). Note que aumentar o Logging Level para VERBOSE fará com que seja fornecida mais informação sobre quaisquer erros ou exceções que possam ocorrer.
Se as relações de confiança de domínio Kerberos estiverem em uso no seu ambiente, pode encontrar algumas orientações aqui.
Por predefinição, o Berserko realiza todas as interações Kerberos com o KDC através de UDP (porta 88). Se quiser usar TCP em vez disso, é possível. A razão mais comum para o fazer é provavelmente quando está em uso um encaminhamento de porta SSH para a porta TCP 88. Basta adicionar udp_preference_limit = 1 ao seu ficheiro krb5.conf, para que fique assim:
[libdefaults]
forwardable = true
udp_preference_limit = 1
É possível configurar o SPN que será usado para um determinado host, incluindo uma secção [berserko_spn_hints] no ficheiro krb5.conf (ver acima). A sintaxe é apresentada abaixo.
[berserko_spn_hints]
[email protected]
server2.bar.org=app.domain2.local
O servidor de destino está no lado esquerdo do sinal de igual, e o SPN a usar está no lado direito. O realm para o SPN pode ser opcionalmente especificado (se não for, o Berserko tentará determinar o realm correto como normalmente). Não inclua aqui a parte HTTP/ do SPN.
O Berserko não é compatível com versões do Burp v2 anteriores à v2020.5.1. Não há problemas com o Burp v1.
Isto é causado pelo facto de a versão do OpenJDK que acompanha as versões anteriores do Burp 2 não incluir parte da funcionalidade Kerberos usada pelo Berserko. Isto causará um erro java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContext ao tentar usar o Berserko.
A solução óbvia é atualizar para a v2020.5.1 ou posterior. Em alternativa, o Berserko deverá funcionar com qualquer versão do Burp v2 se o iniciar usando uma versão completa do ambiente de execução Java (ou seja, não a que vem empacotada com o Burp).
Assumindo que tem java no seu path:
java -jar burpsuite_pro.jar
Consulte a documentação do Burp sobre como iniciar a partir da linha de comandos.