Con noticias de última hora: Log4Shell (CVE-2021-44228) y los intentos de explotación se generalizaron, los MSP y los equipos de TI trabajaron sin parar para evaluar la exposición, buscar posibles IoC, aplicar mitigaciones y parchear.
El problema es que, dado que esta vulnerabilidad afecta a tantas aplicaciones, y que no todos los proveedores pueden brindar un asesoramiento claro sobre si los productos se ven afectados o no (nota: NinjaOne no lo es): determinar qué sistemas son potencialmente vulnerables es un gran desafío.
Ese problema ha llevado a bastantes investigadores de seguridad y miembros de la comunidad a crear scripts y herramientas que se pueden usar para escanear entornos en busca de archivos Log4j potencialmente vulnerables y señales de IoC.
Entre los ejemplos se incluyen:
- Probador de vulnerabilidades Huntress Log4Shell
- Detección de script de archivos Log4j de Kelvin Tegelaar
- Escáner Ninja-Log4shell de Jan Scholte
- get-log4jrcevulnerability.ps1 por Prejay Shah
- Herramienta de detección de ataques, mitigación y enumeración Log4Shell de Datto
- Log4j/Log4Shell PowerShell Scan diseñado para usar con Ninja de AshtonSolutions
- CVE-2021-44228-Log4Shell-Hashes de Rob Fuller
- Log4shell-detector de Florian Roth (que detecta intentos de explotación NO aplicaciones vulnerables
La decisión de utilizar alguno de los scripts disponibles depende completamente de usted (siempre pruebe y realice primero la diligencia debida adecuada, por supuesto), pero si encuentra un script que desea probar, esta publicación lo guiará a través de un ejemplo de cómo desplegarlo en la red aprovechando los campos personalizados en NinjaOne.
Antes de sumergirnos, si busca ponerse al día con Log4Shell, los siguientes son excelentes recursos:
- Fantástica explicación de Log4Shell por John Strand en Black Hills Information Security
- Buena descripción general de Log4Shell con actualizaciones periódicas de Huntress
- Guía de vulnerabilidad Log4j desde CISA
Ejemplo de cómo monitorear archivos Log4j con el uso de NinjaOne
Para configurar un monitor personalizado que detecte la presencia de archivos de la biblioteca Log4J en endpoints en Ninja, necesitará:
- Un campo personalizado
- Un script para recopilar y almacenar los datos (ejemplo a continuación, o consulte otros ejemplos citados anteriormente)
- Una condición personalizada para crear una alerta
- Un método para desplegar el script de detección
Configuración del campo personalizado
El campo personalizado se utilizará para almacenar los datos devueltos por el script de detección.
1) Agregar un nuevo campo personalizado. Como monitoreamos el resultado del script en todos los endpoints, crearemos un campo personalizado global.
2) El campo personalizado se llamará log4j y se configurará para escribir Multilínea. Usamos varias líneas ya que es posible que cada endpoint tenga varios archivos con vulnerabilidades. Las líneas múltiples harán que la información sea más legible.
3) Luego necesitamos configurar el campo personalizado. Estableceremos el script Script Access en Leer / Escribir.
Nota: Si el acceso a la secuencia de comandos no está configurado en “Escribir” o “Leer/Escribir”, no podrá escribir en el campo desde una secuencia de comandos.
A continuación, se presenta todo lo que se requiere para configurar el campo personalizado si configuramos un campo personalizado global.
Creación de un script para extraer datos
Para fines ilustrativos, usaremos un script de ejemplo a continuación creado a partir del script de Kelvin Tegelaar provisto en CyberDrain y en NinjaOne Community Dojo. La diferencia principal con el script de Kelvin es que utiliza una herramienta externa llamada “todo” que acelera la ejecución.
Tenga en cuenta que circulan scripts adicionales que también puede consultar y personalizar , que incluyen:
Es posible que provean resultados más rápidos y eficientes.
*** Aviso legal: El uso de alguno de los scripts en Ninja se realiza bajo propia discreción y riesgo. ***
$array = @() $Drives = Get-PSDrive -PSProvider 'FileSystem' foreach($Drive in $Drives) { $drivePath = $Drive.name + ":" $array += gci $drivePath -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path } Si ($array -ne $null) { $array += “Posible amenaza detectada”} Ninja-Property-Set log4j $array
*Nota: Para dispositivos con Windows 8, es posible que deba eliminar el comando “-force” en el comando Get-ChildItem (gci).
Ninja-Property-Set Es el comando Powershell de Ninja para establecer un campo personalizado en un valor específico. La sintaxis es:
Ninja-Property-Set fieldName Value
En este caso, configuramos el campo log4j en el valor almacenado en la variable $array.
Agregar el script a Ninja es sencillo.
1) Navegue a “Configuración” -> “Scripting”
2) Haga clic en “Agregar un nuevo script”
3) Copie el código anterior en el IDE
- Si el campo personalizado no se llama “log4j, actualice el nombre del campo junto a Ninja-Property-Set
4) Establezca los parámetros del script en
- Nombre: Detección Log4J
- Idioma PowerShell
- Sistema operativo: Windows
- Arquitectura Todo
5) Guarde el script
Configuración del monitor
Las condiciones en Ninja se utilizan para monitorear los cambios de estado en un endpoint. Ninja incluye la capacidad de monitorear campos personalizados. Configuraremos un monitor para alertar en función de los resultados devueltos al campo Log4J.
1) En la política de elección, vaya a las condiciones y haga clic en “Agregar una condición”.
2) Seleccione el tipo de condición “Campos personalizados”
3) En “El valor del campo personalizado debe cumplir alguna condición”, seleccione “Agregar” y busque “Log4J”.
4) Establezca el selector en “contiene” y agregue “Posible amenaza detectada”
5) Establezca alguna configuración de gravedad, prioridad, canal de notificación y emisión de tickets según preferencias y haga clic en “Agregar”.
6) Si integró la PSA o utiliza Ninja Ticketing, también puede crear un ticket a través de la condición
Desplegar el script
El paso final en el proceso es ejecutar el script. Ejecutar el script:
- Ad-hoc en dispositivos individuales a través de la biblioteca de scripts
- Ad-hoc en múltiples dispositivos en línea a través de la función de búsqueda
- De manera automática a través de tareas programadas
- De manera automática a través de políticas
Vea qué más se logra con el uso de campos personalizados en NinjaOne
Es solo un ejemplo de cómo el uso de campos personalizados en NinjaOne lo ayuda a desplegar un monitoreo personalizado y una automatización poderosa. Comenzamos una nueva serie dedicada a compartir otros ejemplos, y puede ver la primera publicación aquí.