miércoles, 20 de julio de 2016

Threat Intelligence. Yara Rules webshell hashes export OTX and other

Estimados amigos de Inseguros !!!

Hoy por ser miércoles el día que es voy a escribir un pequeño artículo para apuntar una chuleta y agradecer el trabajo de la gente de Yara RUles.


En el github oficial del proyecto han publicado un fichero yara con la identificación de las webshells más conocidas y usadas por los ciber-malosos, auditores y demás perlas del panorama :-)

El archivo es lo podéis descargar aquí.

Para los que no sepáis que es Yara Rules, mejor leer este artículo de Root Against The Machine o mal informaros con mi descripción: Un motor de detección de malware, o ficheros... basados en expresiones regulares. Es decir lo que podría ser un "motor de antivirus" en el que nosotros creamos las firmas, por ejemplo, detectar ficheros ejecutables que contengan el string "banco". El ejemplo de la documentación:

rule ExampleRule
{
    strings:
        $my_text_string = "text here"
        $my_hex_string = { E2 34 A1 C8 23 FB }

    condition:
        $my_text_string or $my_hex_string
}

El ejemplo de una webshell del fichero que han publicado sería este:

rule lamashell_php {
meta:
description = "Semi-Auto-generated - file lamashell.php.txt"
author = "Neo23x0 Yara BRG + customization by Stefan -dfate- Molls"
hash = "de9abc2e38420cad729648e93dfc6687"
strings:
$s0 = "lama's'hell" fullword
$s1 = "if($_POST['king'] == \"\") {"
$s2 = "if (move_uploaded_file($_FILES['fila']['tmp_name'], $curdir.\"/\".$_FILES['f"
condition:
1 of them
}

Si pasas un proceso en un servidor que ejecute Yara con esta regla, nos mostraría el fichero en el caso de que tuviéramos esa shell instalada en el servidor. Imagino que se usará mas en Respuesta a Incidentes para detectar servidores comprometidos que para la parte defensiva que es la que me interesa a mi.
Recorrer el servidor, un webserver grande buscando este fichero cada 5 minutos puede consumirnos el sistema entero, y yo ya cuento con otro sistema de FIM (FIle Integrity Monitor) que me monitoriza "cosas". Pero me gustaría meter una regla en un sistema defensivo que me detecte la subida de estos ficheros, pongamos por ejemplo un mod_security.
Lo que pretendo es extraer simplemente el hash de la shell y volcarlo en un fichero para poder cargarlo en mis firmas. También lo voy a subir a la base de datos OTX de AlienVault por si le sirve a alguien, y por supuesto, lo voy a incorporar a mi sistema de Threat Intelligence que tenemos en Eset España.
Muy sencillo el comando, le pasamos el fichero de yara rules y le pasamos una salida, sencillo:
grep -n "hash = " /sitio/yara_shells.txt | awk -F  "=" '{print $2}' | tr -d '"' > /sitio/hashes.txt
Como he dicho, es solo un pequeño truco que quiero documentar y agradecer el trabajo desinteresado de la comunidad que escribe yara rules públicas y la gente de OTX.
Gracias por leerme.


martes, 12 de julio de 2016

OSSIM 27. Mamá, he roto OSSIM... Backups

Estimados amigos de Inseguros !!!

Vamos a escribir el vigésimo séptimo artículo de la serie dedicada a OSSIM (todos los artículos).


En esta ocasión vamos a trabajar un poco con las opciones de configuración y backups.

El producto OSSIM en la versión de software libre, no se en la de pago, suele ser algo "inestable" por no decir otra cosa con algunas situaciones. Bien sea porque nos quedamos sin disco, o por un corte de corriente, mala actualización, y demás situaciones no-friendly para el sysdamin, la base de datos se suele corromper, o se puede corromper, tampoco voy a criticar este producto GRATUITO.

Lo que si sabéis todos los que lo estáis usando, es que antes de hacer algún cambio importante o update, mejor hacer un snapshot o copia de seguridad potente.

El sistema hasta la versión 5.2.4 realizaba una copia de seguridad automática de la configuración del sistema, desde las políticas, assets, configuración de openvas, usuarios, TODO. La ubicación de las copias de seguridad se solía hacer en /var/alienvault/backup/ 

Si actualizaste a la versión 5.2.5, sin leer, como suele ser el caso :-) habrás notado que ya no se están realizando backups automáticos y el sistema nos invita amablemente a introducir una clave de seguridad para los backups, un punto más de seguridad en nuestros despliegues.

El procedimiento es tan sencillo como este.

Si alguna vez se nos va la base de datos, tenemos que tener en cuenta una cuestión. Si actualizamos el servidor OSSIM no podemos restaurar la configuración de una versión previa.

El otro día me paso eso, que me petó la BBDD, pensé que actualizando se arreglaría, y me vi en la situación de no poder restaurar la configuración por ser de una versión anterior. Todo el OSSIM de años perdido...

Me puse a pensar como loco, porque ya no fumo :-) y pensé: si en en /etc/ossim/ossim_setup.conf tengo la clave de la BBDD mysql de OSSIM y tengo los ficheros .sql, por qué no los lanzó a ver si la actualización no ha tocado mucha definición de tablas, y salgo del paso? Correcto, ejecute el dump de mysql de todos los ficheros .sql y volví a respirar.

Si vas a hacerlo uno a uno (son muchos) me parece bien, yo pensé en hacer un cat *.sql   | mysql -u adasd..... y funcionó.

Aprovecha también para introducir estos ficheros en tu sistema de backups de disco general. Si exportas la configuración a otro servidor salvarás los "muebles" en caso de que se rompa el disco y no puedas acceder localmente a la copia de seguridad...

Espero que sea estable la solución, aunque imagino que en la próxima actualización me tocará lidiar con las tablas del mysql... De momento tengo SIEM. Realmente tengo copias de seguridad de la máquina, pero quería probar estas pequeñas historias para cuando todo falla.

Espero que os sirva de ayuda, tanto lo de los backups, como la ubicación del fichero de configuración de mysql, como simplemente echar un rato simpático leyendo Inseguros :-)

Un saludo !! gracias por leerme !!!