nccgroup/berserkoExtensión de Burp Suite para realizar autenticación Kerberos
Publicado como código abierto por NCC Group Plc - http://www.nccgroup.trust/
Desarrollado por Richard Turnbull, richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
Publicado bajo AGPL, consulte LICENSE para obtener más información
El desarrollo adicional de Berserko tendrá lugar en https://github.com/rteatea/Berserko
Berserko es una extensión de Burp que añade soporte para realizar autenticación Kerberos. Esto es útil para realizar pruebas en un dominio de Windows cuando no se admite la autenticación NTLM (Burp ya gestiona NTLM). Berserko no requiere que la máquina que ejecuta Burp esté unida al dominio (ni siquiera que esté ejecutando Windows).
La única solución existente que conocemos actualmente para probar aplicaciones Kerberos con Burp es encadenar a través de Fiddler, con la autenticación configurada según estas instrucciones. Pero Fiddler es solo para Windows, y encadenar proxies añade complejidad y perjudica el rendimiento, por lo que es bueno tener capacidad Kerberos dentro del propio Burp.
Obtenga el último archivo jar de Berserko desde la pestaña Releases, o desde la carpeta berserko\releases
Vaya a la pestaña Extender en Burp, seleccione Add, asegúrese de que Java está seleccionado como Extension type, y entonces indíquele el archivo jar. Si todo va bien, la pestaña Berserko debería añadirse a la interfaz de Burp.
La casilla Do Kerberos authentication es un interruptor general. Hasta que se active, Berserko no hará nada en absoluto.
El botón Restore defaults devolverá Berserko a la configuración predeterminada (en la que no hay detalles de dominio ni credenciales de usuario).
El botón Clear Kerberos state borrará todos los tickets Kerberos y cualquier otro estado en el cliente. La única razón por la que podría necesitar usar esto sería si se hubieran realizado cambios en la configuración de Kerberos en el lado del servidor y quisiera comenzar desde un estado limpio.
El botón Write tickets to log escribirá información sobre sus tickets Kerberos actuales en el flujo de registro de Berserko; esto puede ser útil para depurar y solucionar problemas. Para ver los registros, vaya a la pestaña Extender de Burp, seleccione Berserko y mire la pestaña Output de abajo. Puede tener sentido usar la opción Save to file aquí, porque los datos de los tickets pueden llenar fácilmente el búfer de registro en la interfaz gráfica.
Algunos controles tienen un botón de ayuda que mostrará más información.
Especifique el Domain DNS Name y el KDC Host utilizando los controles de esta sección. Los cuadros de texto no se pueden editar directamente; tiene que usar el botón 'Change' para modificarlos.
El Domain DNS Name debe ser el nombre DNS del dominio contra el que desea autenticarse (para ser precisos, en realidad es el realm de Kerberos). Debería ser algo como mydomain.acme.local. No debe ser el nombre NETBIOS del dominio (que sería algo como MYDOMAIN).
El KDC Host debe ser el nombre de host (o dirección IP) de un KDC de Kerberos (Key Distribution Center). En un dominio de Windows, un KDC es simplemente un controlador de dominio.
Una vez proporcionado el Domain DNS Name, puede usar el botón Auto para intentar localizar automáticamente un KDC. Lo hace enviando una consulta DNS SRV para el servicio Kerberos. Si uno de sus servidores DNS es un controlador de dominio para el dominio correcto, esto debería funcionar. Si no, no funcionará. ❗Esta funcionalidad no funcionará en versiones recientes de Burp, ya que las bibliotecas DNS necesarias no se incluyen como parte del JRE empaquetado. Puede solucionarlo ejecutando con un JRE completo como se describe al principio de este README.❗
Cuando se hayan introducido el Domain DNS Name y el KDC Host, use el botón Test domain settings para probar la conectividad. Si todo va bien, obtendrá una respuesta Successfully contacted Kerberos service.
Consulte este archivo para obtener mucha más información sobre cómo obtener los valores correctos para estos ajustes de dominio.
Especifique el Username y la Password para una cuenta de dominio utilizando los controles de esta sección. Los cuadros de texto no se pueden editar directamente; tiene que usar el botón 'Change' para modificarlos.
El Username debe ser simplemente el nombre de usuario simple. Debería ser algo como bob. No debe ser MYDOMAIN\bob ni [email protected] ni algo similar.
Una vez proporcionadas las credenciales, puede usar el botón Test credentials. Esto intentará adquirir un ticket de concesión de tickets (ticket-granting ticket) de Kerberos para el usuario especificado. Si tiene éxito, obtendrá una respuesta TGT successfully acquired. Si no tiene éxito, tenga en cuenta que se trata de un intento de autenticación de dominio, así que tenga cuidado de no bloquear su cuenta.
La contraseña no se guardará en la configuración de Berserko para la próxima vez a menos que se marque la casilla Save password in Burp config?. Sin embargo, el resto de ajustes sí se guardarán.
Algunas aplicaciones usan la delegación Kerberos en el lado del servidor para reenviar la identidad del cliente a otros servidores (pero no hay una forma fácil de determinar desde el lado del cliente si esto está en uso).
Berserko sí lo admite, pero hay una pega. La delegación solo funciona si el usuario tiene un TGT (ticket-granting ticket) forwardable (reenviable). La implementación de Kerberos en Java, lamentablemente, no proporciona una forma de especificar mediante programación que se debe adquirir un ticket reenviable. Esto solo se puede hacer añadiendo una entrada apropiada al archivo de configuración krb5.conf.
Por lo tanto, para que la delegación funcione, hay que indicar a Berserko un archivo krb5.conf adecuado, y hay dos enfoques posibles.
Lo más fácil, y el enfoque recomendado, es usar el botón Create krb5.conf file. Esto creará un archivo adecuado en la ubicación que elija. Puede ponerlo en un directorio temporal, en el directorio de su proyecto, o donde sea. Pero el mismo archivo se puede reutilizar indefinidamente, por lo que puede tener sentido ponerlo en un lugar más permanente. El botón Change le permite seleccionar un archivo diferente para usar.
Si le interesa, el archivo krb5.conf que se crea es muy simple y tendrá el siguiente contenido:
[libdefaults]
forwardable = true
Alternativamente, podría usar el botón Change para apuntar a un archivo krb5.conf existente en el sistema. La única razón por la que podría querer hacer esto sería si hubiera otros ajustes importantes de Kerberos en ese archivo que quisiera que Berserko tuviera en cuenta (lo que en teoría debería funcionar bien, pero no se ha probado en la práctica). Tenga en cuenta que la ubicación predeterminada de este archivo en Linux es /etc/krb5.conf - otros sistemas operativos tienen menos probabilidades de tener uno. Si va a apuntar a un archivo krb5.conf existente, asegúrese de editarlo para habilitar el reenvío: añada forwardable = true a la sección [libdefaults] (o individualmente para cada realm). Pero tenga cuidado. Pedir a Berserko que cree el archivo por usted será la mejor opción el 99% de las veces.
Si quiere saber si su configuración de delegación es correcta, use el botón Check current config. Esto le dirá si se ha localizado el archivo krb5.conf y si el ajuste forwardable es correcto. Tenga en cuenta también que Berserko le dirá si adquirió o no correctamente un TGT reenviable cuando use el botón Test credentials.
Es una buena idea asegurarse de tener un ticket reenviable antes de empezar a usar una aplicación. Parece que IIS puede almacenar en caché el estado de autenticación de un usuario en el lado del servidor de tal manera que cambiar de un ticket no reenviable a uno reenviable no funcionará.
Los ajustes de esta sección controlan si Berserko intenta la autenticación Kerberos 'reactivamente' (es decir, esperar a recibir una respuesta 401 del servidor y luego reenviar la solicitud con una cabecera de autenticación Kerberos añadida) o 'proactivamente' (es decir, añadir la cabecera de autenticación Kerberos a la solicitud saliente).
La ventaja de la autenticación proactiva es que solo requiere un viaje de ida y vuelta HTTP, mientras que la autenticación reactiva requiere dos. La desventaja de la autenticación proactiva es que es posible que se envíen cabeceras de autenticación Kerberos a hosts que no las esperan. Berserko también es más capaz de diagnosticar errores de autenticación cuando se usa la estrategia reactiva.
La opción Proactive Kerberos authentication, only after initial 401 received es un híbrido de estos dos enfoques, donde Berserko autenticará reactivamente en la primera solicitud a un host, pero a partir de entonces será proactivo.
En esta sección, puede definir qué hosts se consideran dentro del alcance para la autenticación Kerberos.
Por defecto, la casilla All hosts in this Kerberos domain in scope for Kerberos estará marcada. Esto significa que Berserko intentará la autenticación Kerberos solo contra servidores web cuyo nombre de host termine con el nombre DNS del dominio. En muchas situaciones esto será suficiente. Sin embargo, es posible tener aplicaciones web habilitadas para Kerberos con un nombre de host que no tenga esta forma (asumiendo que el administrador haya configurado un Service Principal Name adecuado). Para tener esto en cuenta, puede añadir hosts adicionales para que se consideren dentro del alcance usando la lista de la derecha. Tenga en cuenta que se pueden usar comodines (* coincide con cero o más caracteres, ? coincide con cualquier carácter excepto un punto).
Alternativamente, puede marcar la casilla All hosts in scope for Kerberos authentication. Obviamente, esto tiene la ventaja de que no necesita molestarse en especificar el alcance manualmente. La posible desventaja de esta configuración es que podría llevar a Berserko a enviar solicitudes Kerberos al KDC para adquirir tickets de servicio para hosts que no están en el dominio. Esto podría causar problemas de rendimiento y podría causar problemas de privacidad (si no quiere que esta información se filtre al KDC). Esto es probablemente un problema particular con la estrategia Proactive Kerberos authentication, en cuyo caso Berserko intentará añadir una cabecera de autenticación Kerberos a cada solicitud que pase por Burp. Esta combinación de opciones no se recomienda, y Berserko le advertirá si se selecciona (pero no lo impedirá realmente).
Si no se seleccionan ni All hosts in this Kerberos domain in scope for Kerberos ni All hosts in scope for Kerberos authentication, los únicos hosts dentro del alcance serán los añadidos a la lista.
La opción Plain hostnames considered part of domain, si se selecciona, significa que los 'nombres de host simples' (es decir, nombres de host que consisten solo en un único componente) se considerarán parte del dominio (y por tanto automáticamente dentro del alcance si All hosts in this Kerberos domain in scope for Kerberos está seleccionada). La razón principal por la que podría querer deshabilitar esto sería si su máquina estuviera unida a un dominio diferente de aquel contra el que se está autenticando con Berserko (en cuyo caso, los nombres de host simples probablemente se refieren a hosts del dominio al que está unido).
Si se selecciona, la opción Do not perform Kerberos authentication to servers which support NTLM indicará a Berserko que no intente la autenticación Kerberos contra hosts que admiten NTLM además de Kerberos (es decir, hosts que devuelven tanto cabeceras WWW-Authenticate: NTLM como WWW-Authenticate: Negotiate).
El Alert Level y el Logging Level se pueden configurar aquí, con los valores NONE, NORMAL o VERBOSE.
El Alert Level controla la cantidad de información enviada a la pestaña Alerts de Burp.
El Logging Level controla la cantidad de información enviada a la salida estándar de Berserko (esto se puede ver en la pestaña Extender). Tenga en cuenta que aumentar el Logging Level a VERBOSE hará que se proporcione más información sobre cualquier error o excepción que pueda ocurrir.
Si se utilizan confianzas de dominio Kerberos en su entorno, puede encontrar orientación aquí.
Por defecto, Berserko realiza todas las interacciones Kerberos con el KDC sobre UDP (puerto 88). Si quiere usar TCP en su lugar, es posible. La razón más común para hacer esto es probablemente cuando se usa un reenvío de puertos SSH para el puerto TCP 88. Simplemente añada udp_preference_limit = 1 a su archivo krb5.conf, de modo que quede así:
[libdefaults]
forwardable = true
udp_preference_limit = 1
Es posible configurar el SPN que se utilizará para un host concreto, incluyendo una sección [berserko_spn_hints] en el archivo krb5.conf (ver arriba). La sintaxis se muestra a continuación.
[berserko_spn_hints]
[email protected]
server2.bar.org=app.domain2.local
El servidor de destino está en el lado izquierdo del signo igual, y el SPN a utilizar está en el derecho. El realm para el SPN se puede especificar opcionalmente (si no se hace, Berserko intentará determinar el realm correcto como de costumbre). No incluya la parte HTTP/ del SPN aquí.
Berserko no es compatible con Burp v2 anterior a v2020.5.1. No hay problemas con Burp v1.
Esto se debe a que la versión de OpenJDK que se incluye con las versiones anteriores de Burp 2 no incluye parte de la funcionalidad Kerberos utilizada por Berserko. Esto provocará un error java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContext al intentar usar Berserko.
La solución obvia es actualizar a v2020.5.1 o posterior. Alternativamente, Berserko debería funcionar con cualquier versión de Burp v2 si lo ejecuta usando una versión completa del entorno de ejecución de Java (es decir, no la que viene incluida con Burp).
Asumiendo que tiene java en su path:
java -jar burpsuite_pro.jar
Consulte la documentación de Burp sobre cómo ejecutar desde la línea de comandos.