💣osTicket
osTicket es un sistema de tickets de soporte de código abierto. Se puede comparar con sistemas como Jira, OTRS, Request Tracker y Spiceworks. osTicket puede integrar consultas de usuarios por correo electrónico, teléfono y formularios web en una interfaz web. osTicket está escrito en PHP y utiliza un backend MySQL. Se puede instalar en Windows o Linux. Aunque no hay una cantidad considerable de información de mercado disponible sobre osTicket, una rápida búsqueda en Google Helpdesk software - powered by osTicket arroja unos 44.000 resultados, muchos de los cuales parecen ser empresas, sistemas escolares, universidades, gobiernos locales, etc., que utilizan la aplicación. osTicket incluso se mostró brevemente en el programa Mr. Robot .
Además de aprender a enumerar y atacar osTicket, el propósito de esta sección también es presentarle el mundo de los sistemas de tickets de soporte y por qué no deben pasarse por alto durante nuestras evaluaciones.
Footprinting / Discovery /Enumeración
Al mirar nuevamente nuestro escaneo EyeWitness anterior, notamos una captura de pantalla de una instancia de osTicket que también muestra que se configuró una cookie llamada OSTSESSID al visitar la página.
Además, la mayoría de las instalaciones de osTicket mostrarán el logotipo de osTicket con la frase powered by delante en el pie de página de la página. El pie de página también puede contener las palabras Support Ticket System.
Un escaneo de Nmap sólo mostrará información sobre el servidor web, como Apache o IIS, y no nos ayudará a rastrear la aplicación.
osTicket es una aplicación web que recibe un alto nivel de mantenimiento y servicio. Si analizamos los CVE encontrados a lo largo de las décadas, no encontraremos muchas vulnerabilidades y exploits que osTicket podría tener. Este es un excelente ejemplo para demostrar lo importante que es comprender cómo funciona una aplicación web. Incluso si la aplicación no es vulnerable, aún puede usarse para nuestros fines. Aquí podemos desglosar las funciones principales en las capas:
1. Entrada del usuario
2. Procesamiento
3. Solución
Entrada del usuario
La función principal de osTicket es informar a los empleados de la empresa sobre un problema para que se pueda resolver con el servicio u otros componentes. Una ventaja importante que tenemos aquí es que la aplicación es de código abierto. Por lo tanto, tenemos muchos tutoriales y ejemplos disponibles para examinar más de cerca la aplicación. Por ejemplo, en la documentación de osTicket , podemos ver que solo el personal y los usuarios con privilegios de administrador pueden acceder al panel de administración. Por lo tanto, si nuestra empresa objetivo utiliza esta aplicación o una similar, podemos causar un problema y "hacernos los tontos" y contactar con el personal de la empresa. La "falta de" conocimiento simulada sobre los servicios ofrecidos por la empresa en combinación con un problema técnico es un enfoque de ingeniería social muy extendido para obtener más información de la empresa.
Procesamiento
Como personal o administradores, intentan reproducir errores significativos para encontrar el núcleo del problema. El procesamiento finalmente se realiza internamente en un entorno aislado que tendrá configuraciones muy similares a los sistemas en producción. Supongamos que el personal y los administradores sospechan que hay un error interno que puede estar afectando al negocio. En ese caso, analizarán más en detalle para descubrir posibles errores de código y abordar problemas más importantes.
Solución
Dependiendo de la profundidad del problema, es muy probable que otros miembros del personal de los departamentos técnicos estén involucrados en la correspondencia por correo electrónico. Esto nos proporcionará nuevas direcciones de correo electrónico para usar en el panel de administración de osTicket (en el peor de los casos) y posibles nombres de usuario con los que podemos realizar OSINT o intentar aplicar a otros servicios de la empresa.
Atacando a osTicket
Una búsqueda de osTicket en exploit-db muestra varios problemas, como inclusión remota de archivos, inyección SQL, carga arbitraria de archivos, XSS, etc. La versión 1.14.1 de osTicket presenta CVE-2020-24881 , que era una vulnerabilidad SSRF. Si se explota, este tipo de falla puede aprovecharse para obtener acceso a recursos internos o realizar escaneo de puertos internos.
Además de las vulnerabilidades relacionadas con las aplicaciones web, los portales de soporte a veces se pueden utilizar para obtener una dirección de correo electrónico para un dominio de la empresa, que se puede utilizar para registrarse en otras aplicaciones expuestas que requieren el envío de una verificación por correo electrónico. Como se mencionó anteriormente en el módulo, esto se ilustra en la caja de lanzamiento semanal de HTB con un tutorial en video aquí .
Veamos un ejemplo rápido, que está relacionado con esta excelente publicación de blog que @ippsec también mencionó que fue una inspiración para su caja Delivery, que recomiendo revisar después de leer esta sección.
Supongamos que encontramos un servicio expuesto, como el servidor Slack de una empresa o GitLab, que requiere una dirección de correo electrónico válida de la empresa para unirse. Muchas empresas tienen un correo electrónico de soporte como support@inlanefreight.local, y los correos electrónicos enviados a este están disponibles en portales de soporte en línea que pueden ir desde Zendesk hasta una herramienta personalizada interna. Además, un portal de soporte puede asignar una dirección de correo electrónico interna temporal a un nuevo ticket para que los usuarios puedan verificar rápidamente su estado.
Si encontramos un portal de atención al cliente durante nuestra evaluación y podemos enviar un nuevo ticket, es posible que podamos obtener una dirección de correo electrónico válida de la empresa.
Esta es una versión modificada de osTicket a modo de ejemplo, pero podemos ver que se proporcionó una dirección de correo electrónico.
Ahora, si iniciamos sesión, podemos ver información sobre el ticket y las formas de publicar una respuesta. Si la empresa configuró su software de soporte técnico para correlacionar los números de ticket con los correos electrónicos, entonces cualquier correo electrónico enviado al correo electrónico que recibimos al registrarnos, 940288@inlanefreight.local, se mostraría aquí. Con esta configuración, si podemos encontrar un portal externo como una Wiki, un servicio de chat (Slack, Mattermost, Rocket.chat) o un repositorio Git como GitLab o Bitbucket, es posible que podamos usar este correo electrónico para registrar una cuenta y el portal de soporte técnico para recibir un correo electrónico de confirmación de registro.
osTicket - Exposición de datos sensibles
Supongamos que estamos realizando una prueba de penetración externa. Durante la fase de OSINT y recopilación de información, descubrimos varias credenciales de usuario utilizando la herramienta Dehashed (para nuestros fines, los datos de muestra que aparecen a continuación son ficticios).
Este volcado muestra contraseñas en texto simple para dos usuarios diferentes: jclayton y kgrimes. En este punto, también hemos realizado una enumeración de subdominios y encontramos varios interesantes.
Exploramos cada subdominio y encontramos que muchos están inactivos, pero el support.inlanefreight.local y vpn.inlanefreight.local están activos y son muy prometedores. Support.inlanefreight.local está alojando una instancia de osTicket, y vpn.inlanefreight.local es un portal web Barracuda SSL VPN que no parece estar usando autenticación multifactor.
Probamos las credenciales para jclayton. No hubo suerte. Luego probamos las credenciales para kgrimes y no tuvimos éxito, pero notamos que la página de inicio de sesión también acepta una dirección de correo electrónico. ¡Intentamos con kevin@inlanefreight.local y conseguimos iniciar sesión correctamente!
El usuario kevin parece ser un agente de soporte, pero no tiene ningún ticket abierto. ¿Quizás ya no esté activo? En una empresa con mucho trabajo, esperaríamos ver algunos tickets abiertos. Investigando un poco, encontramos un ticket cerrado, una conversación entre un empleado remoto y el agente de soporte.
El empleado afirma que se le bloqueó el acceso a su cuenta VPN y le pide al agente que la restablezca. Luego, el agente le dice al usuario que la contraseña se restableció a la contraseña estándar para nuevos miembros. El usuario no tiene esta contraseña y le pide al agente que lo llame para que se la proporcione (¡una sólida conciencia de seguridad!). Luego, el agente comete un error y envía la contraseña al usuario directamente a través del portal. Desde aquí, podríamos probar esta contraseña en el portal VPN expuesto, ya que es posible que el usuario no la haya cambiado.
Además, el agente de soporte indica que esta es la contraseña estándar que se les da a los nuevos usuarios y establece la contraseña del usuario con este valor. Hemos estado en muchas organizaciones donde el servicio de asistencia técnica utiliza una contraseña estándar para los nuevos usuarios y los restablecimientos de contraseñas. A menudo, la política de contraseñas del dominio es laxa y no obliga al usuario a cambiarla en el siguiente inicio de sesión. Si este es el caso, puede funcionar para otros usuarios. Aunque está fuera del alcance de este módulo, en este escenario, valdría la pena utilizar herramientas como linkedin2username para crear una lista de usuarios de los empleados de la empresa e intentar un ataque de rociado de contraseñas contra el punto final de la VPN con esta contraseña estándar.
Muchas aplicaciones como osTicket también contienen una libreta de direcciones. También valdría la pena exportar todos los correos electrónicos y nombres de usuario de la libreta de direcciones como parte de nuestra enumeración, ya que también podrían resultar útiles en un ataque como el de robo de contraseñas.
Reflexiones finales
Aunque en esta sección se muestran algunos escenarios ficticios, se basan en situaciones que probablemente veremos en el mundo real. Cuando nos topamos con portales de soporte (especialmente externos), deberíamos probar la funcionalidad y ver si podemos hacer cosas como crear un ticket y que nos asignen una dirección de correo electrónico legítima de la empresa. Desde allí, es posible que podamos usar la dirección de correo electrónico para iniciar sesión en otros servicios de la empresa y obtener acceso a datos confidenciales.
En esta sección también se muestran los peligros de la reutilización de contraseñas y los tipos de datos que es muy probable que encontremos si logramos acceder a la cola de tickets de soporte de un agente de soporte técnico. Las organizaciones pueden evitar este tipo de fuga de información siguiendo unos pasos relativamente sencillos:
Limitar qué aplicaciones están expuestas externamente
Imponer la autenticación multifactor en todos los portales externos
Proporcionar capacitación sobre concientización sobre seguridad a todos los empleados y recomendarles que no utilicen sus correos electrónicos corporativos para registrarse en servicios de terceros.
Aplicar una política de contraseñas segura en Active Directory y en todas las aplicaciones, que no permita palabras comunes como variaciones de
welcome, ypassword, el nombre de la empresa, y estaciones y meses.Requerir que un usuario cambie su contraseña después de su inicio de sesión inicial y hacer caducar periódicamente las contraseñas del usuario
Caso práctico
Encuentra el camino hacia la instancia de osTicket y envía la contraseña enviada desde el agente de atención al cliente Charles Smithson.
Última actualización
