Actualización 22-01-2020

Ahora existe una herramienta de FireEye que ayudará a escanear estos elementos a continuación. La clave es que necesitas tener suficientes registros para retroceder hasta el 09-01-2020 para tener la oportunidad de ver qué se hizo más allá de que se ejecutó el exploit. Si encuentra archivos de carga útil .XML, entonces debes usar la información a continuación para tomar una decisión sobre qué acción tomar. https://www.fireeye.com/blog/products-and-services/2020/01/fireeye-and-citrix-tool-scans-for-iocs-related-to-vulnerability.html

Descarga de la Herramienta

https://github.com/citrix/ioc-scanner-CVE-2019-19781 https://github.com/fireeye/ioc-scanner-CVE-2019-19781/

Detección de Explotación

No hay una manera fácil en este momento de probar lo que alguien ha hecho. Con 4 exploits públicos, cada uno deja un artefacto/firma diferente, lo cual es útil para la detección, pero no es 100%. La clave es recordar que estos son los exploits públicos que fueron privados hasta el día 10 y eso tampoco significa que aún existan otros por ahí que la gente no comparte para su propio beneficio. Los exploits son editables en la mayoría de los casos, donde alguien puede cambiar el nombre del archivo que se colocará, el nombre de la cuenta de usuario, el nombre del proceso, la ruta de la consulta y muchas otras opciones, lo que significa que las posibilidades aumentan exponencialmente de que alguien haya explotado el sistema. También hay atacantes avanzados y atacantes básicos; uno limpiará después de sí mismo y encontrará formas muy inteligentes de desaparecer en el sistema para ocultarse de la detección.

Si ejecutas Nessus, entonces puedes usar este archivo .YAR a continuación para realizar un escaneo privilegiado en busca de los métodos de detección comunes. https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar

Auditoría de Exploits

Excelentes enlaces sobre este proceso de auditoría. https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

Descargo de responsabilidad: como se dijo antes, esto no detectará todos los exploits, pero puede ayudar a detectar algunas anomalías si el atacante no modificó los exploits públicos y/o no limpió después de sí mismo. La mayoría de los atacantes usarán el exploit predeterminado, y estos son algunos de los artefactos documentados que podrían quedar atrás. Esta lista de comandos fue tomada de muchas fuentes y será muy dinámica a medida que surjan otras variantes, soluciones alternativas y nuevos desarrollos. Podemos contar con que esto cambiará constantemente a medida que ocurran más infecciones y se complete una investigación forense adicional con un conjunto de muestras más grande.

Mira esto primero para cosas que no hiciste. Si normalmente no haces mucho en tu ADC, estos deberían estar muy silenciosos, aunque pueden tener entradas de semanas, meses o años atrás de la última vez que estuviste. Hay consultas más precisas justo abajo. También entiende que esto es un juego del gato y el ratón incluso en este blog. A medida que revelamos lo que hemos visto y cómo detectar a los atacantes, ellos están usando esta información en nuestra contra cambiando sus tácticas para evitar la detección.

Lista Rápida de Verificación de Explotación v1

• 1. Revisa tu Licencia, he oído de algunos que reiniciaron sus dispositivos y en realidad tenían una licencia vencida.
• 2. Obtén un Archivo de Soporte, es decir, Backup del Sistema -> Diagnóstico -> Obtener Archivo de Soporte y guarda ese archivo.
• 3. Todos los comandos a continuación están en NSCLI y si te conectas por SSH al equipo y usas Shell, entonces puedes omitir el prefijo Shell.
• 4. Verifica la fecha en el equipo para ayudar a correlacionar los hallazgos de los registros
  • a. shell date
• 5. Verifica la fecha de cambio de tu configuración
  • a. Shell ls -l /netscaler/ | grep netscaler
  • b. Shell ls -l /nsconfig | grep netscaler
    • i. ¿Cuál es la fecha de tu netscaler.conf?
    • ii. ¿Eso parece correcto? Busca enlaces de archivos a otros lugares.
• 6. Verifica el archivo de contraseñas de cuentas locales
  • a. Shell ls -lh /etc/passwd
    • i. Verifica cuándo se modificó el archivo. Si fue después del exploit y no fuiste tú, entonces necesitas cambiar esa contraseña lo antes posible.
    • ii. Recomiendo cambiar la contraseña de nsroot o de cualquier cuenta local si se detecta algún exploit. En muchos casos
  • b. Shell cat /etc/passwd
    • i. Mira qué cuentas hay allí.
    • ii. Root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor son las predeterminadas.
• 7. Revisa tus Registros
  • a. shell ls -lh /var/logfile
    • i. ¿Están los archivos ahí? ¿Son realmente pequeños?
    • ii. https://support.citrix.com/article/CTX121898
• 8. Verificación de Archivos Maliciosos
  • a. Si alguno de estos archivos tiene un nombre de más o menos de 8-9 caracteres y un nombre de archivo aleatorio, entonces esto es una señal de un atacante más avanzado que cambió el exploit estándar. Si ves esto, debes ajustar tu remediación en consecuencia. Pwnpzi1337.xml es el nombre de archivo para el exploit de Project India
  • b. shell ls /netscaler/portal/templates/*.xml
    • i. No debería haber archivos XML aquí.
    • ii. Si está infectado, mira las fechas de los archivos aquí.
    • iii.shell ls -lh /netscaler/portal/templates/

Si Fue Explotado

Tu experiencia siempre variará en cuanto a lo que necesitas hacer según tu panorama de amenazas. Aquí hay algunas ideas que he estado diciendo a los clientes que han encontrado evidencia de un exploit ejecutado.

¿Qué cuerpos de cumplimiento normativo cubren tu negocio? Finanzas/Banca, SOX, PCI, HIPAA, Leyes Estatales/Locales y Gubernamentales.

Si estás bajo uno de estos marcos, entonces debes seguir esos procedimientos para esos cuerpos de cumplimiento. También hay consideraciones éticas basadas en las certificaciones y grupos profesionales de los que formes parte que tienen disposiciones para la respuesta a incidentes y la divulgación.

Aquí hay enlaces a dos guías bien conocidas de procesos de respuesta a incidentes: https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

Una cosa que sabemos hasta ahora es que alrededor del 10-01-2020 se lanzó el primer exploit público y hay algunos informes de infecciones el día 9, justo cuando salió. En la mayoría de los casos, el riesgo es mucho menor si parcheaste tu sistema antes de 2020 versus más tarde este mes.

CVE-2019-19781 Escalada Estimada de Riesgo de Amenaza

17 de diciembre - 31 de diciembre Riesgo más bajo de explotación 1 al 8 de enero Riesgo más bajo de explotación 9 al 13 de enero – Riesgo más alto de explotación 14 de enero al presente – Riesgo más alto de explotación

Esto debería integrarse en tu proceso para tus próximos pasos.

He encontrado rastros de una explotación, ¿y ahora qué? Esto aún depende; una cosa que la mayoría de las implementaciones de Citrix ADC no configuran es un buen registro SNMP y SYSLOG y es posible que no tengan una buena manera de buscar, filtrar o alertar si se encuentran artefactos. Si tienes un registro absoluto y estás seguro de que no hicieron nada, entonces quizás puedas seguir adelante. Luego, si encontraste algo y pudiste eliminar con confianza su acceso remoto, entonces podrías seguir adelante.

Pero la mayoría encontrará que encuentran algunos rastros y es posible que no puedan conectar los puntos sobre lo que se hizo y a dónde pudieron haber ido, y podría ser más fácil después de la detección simplemente restablecer los dispositivos.

Mi próximo consejo cambiará en las próximas 2 semanas.

Rutas de Muestra de Respuesta a Incidentes

No hay una respuesta correcta y perfecta que pueda dar que se adapte a la situación de todos; estos son mis pensamientos hasta ahora al 19-01-20 y pueden cambiar después de esto a medida que aprenda más sobre los próximos pasos y a medida que se publiquen cosas en el lado de la defensa o el ataque relacionadas con esta vulnerabilidad. No hay una respuesta correcta; la seguridad informática es la tierra como la mayoría de las tierras que se rige por "depende". Recomiendo encarecidamente que si encuentras algo más que solo estos archivos en esos 3 directorios, consideres el equipo comprometido y sigas el camino más cauteloso. En algunos de estos, sugiero tomar el camino más cauteloso, especialmente cuando no hay registros para confirmar lo que hicieron o no hicieron. Debes trabajar con tu equipo para decidir el mejor curso de acción según tu situación porque esto es un deporte de equipo. Siempre puede haber una mejor manera de arreglar cosas como esta, pero según la evidencia que tengas en el dispositivo y alrededor del dispositivo (Objetivos de Nivel 1), entonces podría estar bien reduciendo tu riesgo y continuando desde allí.

• Mitigar: Esto es por donde debes comenzar sin importar qué. Con el nuevo firmware o la política de respondedor.
• Exploits Detectados Durante tu Auditoría. - Inicia tu proceso de respuesta a incidentes.
• Con Buen Registro del Dispositivo
  • Señales de Ataques Avanzados o Persistencia
    • Construir Nuevo y Migrar
  • Sin Señales de Ataques Avanzados o Persistencia
    • Remediar y Mantener en Funcionamiento
• Sin Registro del Dispositivo
  • Señales de Ataques Avanzados o Persistencia
    • Construir Nuevo y Migrar
    • Restablecimiento de Fábrica
  • Sin Señales de Ataques Avanzados o Persistencia
    • Construir Nuevo y Migrar
    • Restablecimiento de Fábrica
• Con Buen Registro de Objetivos de Nivel 1
  • Señales de Ataques Avanzados o Persistencia
    • Construir Nuevo y Migrar
    • Restablecimiento de Fábrica
  • Sin Señales de Ataques Avanzados o Persistencia
    • Remediar y Mantener en Funcionamiento
• Sin Registro de Objetivos de Nivel 1
  • Señales de Ataques Avanzados o Persistencia
    • Construir Nuevo y Migrar
    • Restablecimiento de Fábrica
  • Sin Señales de Ataques Avanzados o Persistencia
    • Construir Nuevo y Migrar
    • Restablecimiento de Fábrica

Definición de Respuesta y Pensamientos

• Construir Nuevo y Migrar – Inicia tu proceso de respuesta a incidentes, luego puedes iniciar este proceso https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html. Esto es relativamente fácil para clientes VPX y SDX debido a la naturaleza virtual y la flexibilidad de la plataforma de configuración. Las Migraciones MPX son una historia diferente debido a cómo funciona el restablecimiento de fábrica y se mantiene la imagen base; podría haber un riesgo muy bajo si fue un atacante avanzado para persistir a través de una actualización de firmware o restablecimiento de fábrica. La probabilidad puede ser menor, pero aún es posible (como cualquier cosa en el mundo cibernético).
• Restablecimiento de Fábrica – Inicia tu proceso de respuesta a incidentes y elimina los archivos .xml y cualquier otra cosa detectada, reinicia y verifica nuevamente la persistencia. Luego comienza el proceso para hacer el restablecimiento de fábrica. Hay scripts que se pueden obtener de Citrix que guiarán el proceso. Esto limpiará el sistema al nivel más bajo antes de recargar el sistema operativo, pero todos confiarán en este método hasta ahora según su panorama de amenazas y pueden querer más.
  • El método más drástico sería RMA los dispositivos para recargar las unidades y esto puede ser una buena o mala idea según tu ciclo de vida, plataforma y plan de redundancia también. Solo lo sugeriría si viste técnicas avanzadas utilizadas y has confirmado movimiento lateral basado en sus técnicas para posiblemente seguir ese camino. Sé que Citrix está trabajando en opciones de "qué pasaría si" y
• Remediar – Inicia el proceso de respuesta a incidentes y elimina los archivos .xml y cualquier otra cosa detectada, reinicia y verifica nuevamente la persistencia. Si tienes buenos registros, entonces sabrás si se hizo algo; si no, entonces miraría tu panorama de amenazas y si tienes registros en Objetivos de Nivel 1 o cualquier otra cosa para saber si necesitas considerar que necesita un restablecimiento de fábrica y/o si necesitas construir nuevo y migrar.

Niveles de Registro

• Buen Registro Local
  • Estás en la mejor posición para ver lo que sucedió localmente y saber si hubo intentos de movimiento lateral o si el exploit simplemente se ejecutó como la mayoría.
• Buen Registro de Objetivos de Nivel 1
  • Estás en la mejor posición para ver si ocurrió o se intentó movimiento lateral. Estos deberían ser lo primero que podría ser objetivo y si viste movimiento lateral exitoso, entonces deberías estar más preocupado y proceder con más precaución en tu camino de remediación. Si no, entonces puedes reducir el riesgo de la amenaza y simplemente tomar el camino de remediación.
• Sin Registro Local
  • Estás en la peor posición para ver lo que sucedió localmente y saber si hubo intentos de movimiento lateral o si el exploit simplemente se ejecutó como la mayoría. Debes proceder con más precaución en tu camino de remediación.
• Sin Registro de Objetivos de Nivel 1
  • Estás en la peor posición para ver si ocurrió o se intentó movimiento lateral. Estos deberían ser lo primero que podría ser objetivo y si viste movimiento lateral exitoso, entonces deberías estar más preocupado y proceder con más precaución en tu camino de remediación.

Espero que las personas puedan eliminar la infección y tener registros suficientemente buenos para sentirse seguros de que ya no están dentro y poder reanudar sus actividades normales sin algunos de estos pasos.

Otros Buenos Pasos de Seguimiento

Hay dos cosas principales sobre las que debes tomar una decisión si hay rastros de explotación.

• 1. Cambiar la Contraseña de NSROOT
  • a. Recomiendo hacer esto sin importar lo que encuentres o qué registros tengas. Esta es una oportunidad para poner nsroot en rotación para cambios de contraseña. La Gestión de ADC debería estar vinculada a LDAP y NSROOT solo debería usarse para emergencias.
• 2. Cambiar la Cuenta de Servicio LDAP (u otro servicio de autenticación)
  • a. Cambia esta contraseña junto con recomendar cambiar a otra cuenta si es posible para que también tengas un SID diferente. Esto puede ser un cambio pasivo sin que nadie lo note si se prueba antes del despliegue.
• 3. Cambiar las Claves SSL
  • a. Buen Registro
    • i. Quizás estés bien si estás 100% seguro de que es bueno.
    • ii. Todavía hay una parte de mí que quiere decir renueva todo, pero sé cuánto trabajo puede ser eso en un entorno grande.
  • b. Sin Registro
    • i. Creo que tienes que renovar todo allí. Hay protección PEM y PFX, pero he visto muchos lugares que usan contraseñas muy simples para esos y podrían ser forzadas por fuerza bruta fuera de línea. Como no sabemos, debemos proteger la empresa.

Pensamientos sobre Contraseñas

Recomiendo cambiar tus contraseñas para todas las cuentas locales en el equipo si hay algún indicio de un exploit exitoso. Adelante, cámbiala porque en muchas implementaciones puede que nunca se haya cambiado después de su implementación original hace 4-7 años. Si ves señales de acceso a la línea de comandos y/o manipulación, lo más probable es que el atacante haya podido descifrar la contraseña. En firmware pre-11.0 era AES256 y en construcciones posteriores usa AES512, que también puede ser susceptible a descifrado. Asegúrate de que esté vinculado a LDAP de forma segura y que tengas alertas configuradas para inicios de sesión de NSROOT.

Pensamientos sobre LDAP

Si has visto algunos niveles de explotación, también asegúrate de cambiar cualquier cuenta de servicio que estuviera definida dentro de la configuración de Citrix ADC. La más común es la cuenta de enlace LDAP/Kerberos. Que alguien ejecute un exploit en un Citrix ADC no significa que sean Administradores de Dominio, pero puede que no tome mucho tiempo dependiendo de tus controles y registros. Este es un cambio muy fácil que, si se prueba, puede ser transparente para los usuarios.

Pensamientos sobre Certificados

Dependiendo de lo que hayas encontrado en tu auditoría, esto ayudará a resolverlo. Si tenías buenos registros y puedes ver que se solicitó acceso a este archivo, entonces debes renovar. Si no tienes buenos registros, entonces también debes renovar. Si tienes un certificado comodín, entonces ese es también otro gran problema y cuantos más sitios esté vinculado, mayor será tu riesgo y exposición. Lo peor que puede pasar es que asumas que está bien y alguien esté levantando un sitio de phishing con tu certificado que toda tu capacitación no evitará los clics. Esto puede llevar a problemas mucho mayores si alguien tiene acceso a tus certificados y sugeriría proceder con precaución y hacer una renovación. Este podría ser un buen momento según la fecha de vencimiento del certificado actual. He visto a algunos cambiar a otro registrador de certificados en este proceso solo para cambiar las cosas, pero tenían registros de que el archivo fue accedido y descargado junto con otras técnicas avanzadas que fueron detectadas.

Créditos ###Por último, pero no menos importante, algunos créditos para algunas de las personas que han estado trabajando en este problema desde que apareció por primera vez. Hay muchas más personas que no están en esta lista porque están entre bastidores y que no he visto.

• Citrix Team – Trabajando para difundir la información junto con el desarrollo de estos nuevos firmware. Tienen que trabajar en 5 parches a la vez según las diferencias entre las familias de código, lo que lo hace mucho más difícil.
• Daniel Weppeler @_DanielWe – Política de registro de Responder para detectar sondeos/ataques
• Florian Roth @cyb3rops – Archivo YAR de Nessus para detección de explotación
• CTP Anton van Pelt @AntonvanPelt y CTA Mads Petersen @mbp_netscaler y Jan Tytgat @jantytgat – Trabajo constante con los equipos CTP/CTA y Citrix en muchos frentes.
• KevTheHermit @KevTheHermit – Divulgación de vulnerabilidad de contraseña de instancia de AWS además del CVE
• Bad Packets Report @bad_packets – Todo el equipo de Bad Packets https://badpackets.net
• Kevin Beaumont @GossiTheDog – Mucha promoción de los problemas observados junto con algunos detalles sobre su honeypot y lo que ha visto.
• Mpgn @mpgn_x64 – Detalles sobre el exploit y variaciones del exploit
• Nick Carr @ItsReallyNick – Detalles sobre el exploit y consejos de respuesta a incidentes.
• Digi Cat u/digicat – Usuario de Reddit, increíble blog de noticias en funcionamiento.
• Ben Sadeghipour @NahamSec – Video de YouTube de DFIR y otras contribuciones
• SANs Team – Artículos y videos de DFIR y análisis en profundidad
• Craig Dods @0xCraig – Implicaciones e investigación de contraseñas
• Manuel Kolloff @manuelkolloff – Guías de explotación post-explotación.
• FireEye y Mandiant Team – Gracias a Rick Cole por crear nuestra cobertura de detección más temprana y al equipo de respondedores de incidentes de Mandiant por sus aportes para este blog, especialmente a Austin Baker, Brandan Schondorfer y John Prieto, y a todos los consultores que están respondiendo o asegurando los entornos de sus clientes contra esta vulnerabilidad. Gracias también a Nicholas Luedtke de nuestro equipo de Inteligencia de Vulnerabilidades por su ayuda para refinar el cronograma de divulgación y herramientas de este blog.