miércoles, 30 de marzo de 2016

Por necesidades acabe desarrollando un código ...

Por necesidades acabe desarrollando un código en bash cuyo objetivo es, siempre y cuando no tengamos una base de datos con los activos de nuestra empresa, buscar un determinado servicio en las redes que nosotros queramos.

El código se basa en la presencia de la herramienta "Nmap" en nuestro sistema, y de la catalogación de los servicios del mismo.

NOTA: El código es funcional y, obviamente, mejorable.

#!/bin/bash
#
#----- NOTA INFORMATIVA -----
#
#Desarrollado por 4null0
#
#Con el siguiente código se buscan direcciones IP que tengan el puerto indicando (segundo parámetro) abierto.
#
#NOTA: Las redes donde buscar vienen definidas en el archivo indicado como parámetro.
#
#El tercer parámetro, que es opcional, indicaría el servicio a buscar.
#
# Ejemplo del uso del tercer parámetro:
#              ./BusquedaServicio.sh Listado.txt 80 IIS  (Buscaría IPs con el puerto 80 abierto y que el servicio se base en IIS de Microsoft)

if [ $# = 0 ] || [ $# = 1 ] || [ $# -gt 3 ]; then
                echo "Este script sólo admite dos parámetros, que se corresponde con el archivo con:\n"
                echo "1.- Archivo con IPs"
                echo "2.- Puerto"
                echo "3.- Nombre del servicio a encontrar"
                exit
else
                #---VARIABLE QUE CONTIENEN EL NOMBRE DEL DIRECTORIO A CREAR       
                directorio=Puerto-$2

                #---SI EXISTE EL DIRECTORIO, PASAMOS A MOSTRAR LOS DATOS SEGÚN NOS INDIQUEN EL RESTO DE PARÁMETROS, SI NO, CREAMOS EL DIRECTORIO Y CONTINUAMOS CON
                #---NORMALIDAD
                if [ -d $directorio ]; then
                               echo "El directorio existe ... se pasara a mostrar los datos ya obtenidos según el resto de parámetros"
                               echo " "
                              
                               if [ -a $directorio/InformeFinal ]; then

                                               echo "Borramos el archivo: InformeFinal"
                                               echo " "
                                               rm $directorio/InformeFinal
                               fi
                else
                               mkdir $directorio
               
                               #----- ESCANEO DE PUERTOS PARA CADA UNA DE LAS IPs ENCONTRADAS -----
                               for IP in $(cat $1)
                               do
                                               red=$(echo $IP | awk -F "/" '{print $1}')
                                               echo "Escaneando: "$IP
                                               $(nmap -Pn -n -open --host-timeout 10m -p $2 -sV $IP -oN $directorio/$red.txt  1> /dev/null)
                               done
                fi

                #---EXISTE UN TERCER PARÁMETRO, POR LO QUE BUSCAMOS UN SERVICIO EN CONCRETO
                if [ $# = 3 ]; then
                               grep -e "$2/tcp" $directorio/*.txt | awk -F "    " '{print $2}' | sort -u | grep "$3" >> $directorio/Servicios
                else
                               grep -e "$2/tcp" $directorio/*.txt | awk -F "    " '{print $2}' | sort -u >> $directorio/Servicios                    
                              
                fi

                #---OBTENEMOS LAS DIRECCIONES IPs POR CADA SERVICIO ENCONTRADO
                while read i
                do
                               echo $i >> $directorio/InformeFinal
                               echo "-----" >> $directorio/InformeFinal
                               grep -e "$i$" -e "report for" Puerto-$2/*.txt | grep -e "$i$" -B 1 | awk -F "txt:" '{print $2}' | sed 's/Nmap scan report for //;s/open//g' | grep -v "$i$"  | sort -u >> $directorio/InformeFinal
                               echo " " >> $directorio/InformeFinal

                done < $directorio/Servicios

                cat $directorio/InformeFinal
               
                #---ELIMINAMOS EL ARCHIVO TEMPORAL: Servicios
                rm $directorio/Servicios
               
fi

Un saludo Mario






lunes, 14 de marzo de 2016

Vulnerabilidad en VirusScan de McAfee

Tras el conocimiento de la vulnerabilidad que afecta a VirusScan de McAfee se pasaron a realizar pruebas.

Antes de nada se procede a realizar una descripción somera de la vulnerabilidad:

Objetivo: La vulnerabilidad consiste en deshabilitar la clave que bloquea las modificaciones del susodicho VirusScan.

Permisos: Para llevar a cabo la explotación de la vulnerabilidad se necesita realizar el ataque utilizando un usuario con permisos de Administrador sobre la máquina.


Para dichas pruebas se han utilizado dos sistemas, un Windows 7 y un Windows XP.
Las pruebas se han realizado de manera manual y mediante un exploit.

NOTA:    Para realizar la prueba manual se ha tenido en cuenta la siguiente noticia:
NOTA:    Exploit: https://lab.mediaservice.net/code/mcafee_unprotector.c

                El código ha tenido que ser modificado en parte debido a errores en la compilación.

                Habría que cambiar las siguientes líneas marcadas en rojo:


Primer conjunto de líneas


Segundo conjunto de líneas

                Por la siguiente línea:

SOFTWARE\\Wow6432Node\\McAfee\\DesktopProtection

La versión de VirusScan utilizada para las pruebas ha sido la: 8.8.0 (Parche 6), que es la más actual sin tener en cuenta el nuevo parche de McAfee (parche 7)


Versión de VirusSCan .

Windows XP - Manualmente

Para este propósito se buscan los procesos que utilicen la clave de registro “HKEY_LOCAL_MACHINE\SOFTWARE \Mcafee\DesktopProtection”



Búsqueda de los procesos que utilizan la clave de registro “HKEY_LOCAL_MACHINE\SOFTWARE \Mcafee\DesktopProtection”

El siguiente paso es parar los procesos:

1.- mfeann.exe
2.- VsTskMgr.exe
3.- McTray.exe

En esta tarea nuestro intento de explotación se detiene debido a que no tenemos permisos para parar todos los procesos anteriormente indicados.


Intento de parar el proceso: mfeann.exe



Intento de parar el proceso: mfeann.exe



Intento de parar el proceso: VsTskMgr.exe



Intento de parar el proceso: VsTskMgr.exe


Los procesos anteriores no se pueden detener debído a que, incluso siendo administrador de la máquina, no se tienen permisos para ello. Para poder pararlos se necesitaría tener los permisos del usuario: “system”.

NOTA: El usuario System es el utilizado por el propio sistema operativo.


Usuario que lanza el proceso: mfeann.exe




Usuario que lanza el proceso: VsTskMgr.exe

Windows XP – Automático

Para este proceso se ha utilizado un exploit publicado recientemente, tal y como se ha comentado anteriormente.

Por este método se ha conseguido explotar la vulnerabilidad y conseguir eliminar la necesidad de utilizar una contraseña para poder modificar las características de VirusScan



Antes del uso del exploit


Después del uso del exploit.
Podemos parar el analizador en tiempo real sin necesidad de credenciales

Windows 7 - Manualmente

Se van a seguir la misma operativa que la utilizada en el sistema Windows XP.

Lo primero que se ve es la inexistencia de procesos que utilicen la clave de registro “HKEY_LOCAL_MACHINE\SOFTWARE \Mcafee\DesktopProtection” o parecida.


Resultados de la búsqueda comentada anteriormente


Aún así se pasa a comprobar si es posible parar los mismos procesos vistos en la máquina con Windows XP. Pero ni siquiera se puede ver el usuario que los ha lanzado, por lo que se puede decir que este método de explotación tampoco funciona


Proceso padre y propiedades del proceso: mfeann.exe



Windows 7 – Automático


Para este proceso se ha utilizado un exploit publicado recientemente.

NOTA: El código ha tenido que ser modificado en parte debido a errores en la compilación.

Por este método NO se ha conseguido explotar la vulnerabilidad y conseguir eliminar la necesidad de utilizar una contraseña para poder modificar las características de VirusScan


Resultado de lanzar el exploit en sistemas Windows 7

CONCLUSIONES

Por lo que se ha podido comprobar la explotación de la vulnerabilidad depende enteramente del sistema operativo que se utilice y de que el usuario que lo lance sea administrador de la máquina.

Se sugiere crear una regla que evite, en sistemas Windows XP, cambiar el valor de la siguiente clave de registro:

“HKEY_LOCAL_MACHINE\SOFTWARE\Mcafee\DesktopProtection\UIPMode”
“HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mcafee\DesktopProtection\UIPMode”

Como comentario final indicara que las pruebas no se han realizado sobre sistemas Windows 8 ni sistemas Windows 10.

lunes, 7 de marzo de 2016

Analizando "S4T4n B0tn3t" - Parte 2

Continuamos con el análisis.

En el trozo de código que se muestra a continuación se define una variable de tipo "Shell" que permite recuperar el acceso al contenido de las siguientes carpetas y archivos, por parte del administrador:

%systemdrive%\kernel - c:\kernel
%systemdrive%\security- c:\security
%alluserprofiler%\ - c:\ProgramData\
%systemRoot%\System32\wscript.exe - c:\Windows\System32\wscript.exe
%systemRoot%\System32\drivers - c:\Windows\System32\drivers
%systemRoot%\System32\drivers\flopydisk.sys - c:\Windows\System32\drivers\flopydisk.sys
""%systemdrive%\system Volume Information - c:\system Volume Information

Así como definir los permisos para las anteriores carpetas o archivos.

Modificación de permisos

En el trozo de código que se muestra a continuación se modifican los valores de las siguiente claves de registro, colocando en ambos casos el valor "0":

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System\disabletaskmgr = 0

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools  = 0


Modificación del registro de Windows

En el trozo de código que se muestra a continuación se crea un archivo en la carpeta "Temp" del usuario con el que se ejecuta este código, con el nombre: tmp.bat. Posteriormente el archivo por lotes se ejecutará y se eliminará.

Contenido del archivo tmp.bat

Para ser más legible, se muestra una imagen del archivo por lotes: tmp.bat


Imagen del archivo: tmp.bat


Este archivo comprueba la existencia dentro del archivo "C:\security\blood.dat" de los delimitadores definidos por el sistema, si la cantidad encontrada supera los 18, entonces no se realizada nada. Por el contrario, se pasa a:

1.- Establecer un icono para los archivo de tipo ".vbe", mediante:

HKCR\VBEFile\DefaultIcon=%SystemRoot%\system32\shell32.dll,1

2.- Copia a la carpeta temporal del usuario todos los archivos con extensión ".vbe" ubicados en:

                A.- c:/kernel
                B.- El propio archivo ejecutado por el usuario.

3.- Se camufla el archivo ejecutado ubicado en la carpeta temporal mediante la ocultación y la declaración del archivo como archivo del sistema.

4.- Se comprueba que realmente existe el archivo anterior en la carpeta temporal. Si no existe se finaliza la ejecución del archivo por lotes.

5.- Se elimina de todas las unidades detectas en el sistema el archivo "config.dat"

6.- Se crean los siguiente directorios:

                A.- c:\security
                B.- c:\security\lpt1
                C.- c:\kernel
                D.- c:\kernel\lpt1

7.- Se camufla los directorios creados anteriormente mediante la ocultación y la declaración del archivo como archivo del sistema.

8.- Se elimina el contenido de los directorios: "c:\kernel" y "c:\security"
9.- Se copia en los dos directorios anteriores el archivo que ha sido lanzado por el usuario
10.- Se elimina de la carpeta temporal el archivo cuyo nombre es igual al nombre del archivo que ha ejecutado el usuario.
11.- Se renombrar los archivos copiados en el punto 9, por los nombres: r00t3r y blood.dat. Siendo el primero de ellos camuflado mediante los procedimientos vistos anteriormente (ocultando el archivo y declarándolo del sistema)
12.- Se procede a registrar todos las librerías y ejecutables ubicados en la carpeta "c:\windows\wbem"
13.- Se procede a configurar el servicio "TermService" para que se inicie de manera automática


En el trozo de código que se muestra a continuación se crea un archivo en la carpeta "Temp" del usuario con el que se ejecuta este código, con el nombre: tmp.vbs. Posteriormente el archivo por lotes se ejecutará y se eliminará.

Contenido del archivo tmp.vbs - 1º parte

Contenido del archivo tmp.vbs - 2º parte

Para ser más legible, se muestra una imagen del archivo tal y como quedaría: tmp.vbe

Contenido del archivo tmp.vbe

Este realizará lo siguiente:

1.- Crea en la carpeta temporal del usuario un archivo denominado: b.bat

2.- Comprueba la existencia de carpetas compartidas en el host, y por cada una de ellas se almacena en el archivo creado anteriormente las cadenas mostradas a continuación.

Es decir, por cada recurso compartido, elimina cualquier vestigio de archivos con extensión ".vbe", copia el archivo; "blood.dat", ubicado en la carpeta: "C:\security" en el recurso compartido, y renombrar el archivo como: "Update.dat", ocultándolo y dándole atributos del sistema

NOTA: Dicho archivo se ejecutará como última tarea del archivo: tmp.vbe


Recursos compartidos del host

Contenido del archivo b.bat


3.- Tras la inserción de las líneas de código, se procede a eliminar todo tipo de archivo: "de acceso directo"

4.-  Se pasa a crear un acceso directo bajo el nombre: "Mariage.lnk", que ejecutará el archivo: "update.dat" almacenado en el recurso compartido.

Conclusión: Este último archivo: tmp.vbe, es el encargado de propagar la infección de manera transversal, mediante el uso de unidades compartidas ( través de la red).


lunes, 22 de febrero de 2016

Minimizar exposición a las infecciones por malware

NOTA INICIAL:

No creo que vaya a hacer el descubrimiento del siglo pero si me gustaría exponer la solución que de manera inconsciente, a mi juicio, permite minimizar la exposición a una infección de malware y que con toda seguridad se encuentre implantada en múltiples empresas.

ENTORNO INICIAL

Existen varios vectores de infección, pero yo voy a exponer una solución para el vector de infección a través de archivos lanzadores que intentan descargarse ejecutables de la red.

Normalmente estos lanzadores se basan en archivos ofimáticos que contienen macros que se ejecutan nada más abrir el archivo, y que su objetivo es descargarse un archivo, normalmente un ejecutable, que será renombrado y ejecutado nada más haberlo descargado.

Habitualmente, los recursos solicitados a Internet vienen configurados de dos maneras:

1.  <dominio>/<uri>
2 . <ip>/<uri>

En el primero de los casos, antes de realizar la petición de descargar, se produce una petición de resolución DNS a través de los servidores configurados en nuestro NIC (tarjeta de red), que normalmente suelen ser servidores DNS públicos en Internet (los propios de Telefónica o de cualquier otro ISP o gran corporación - 8.8.8.8 ;-))

Tras la resolución se produce la solicitud de descarga.

Descargado el recurso, el nombre y la ubicación donde se almacena, suelen ser modificados para dificultar un posible análisis. Tras lo cual, se produce la ejecución del mismo infectando nuestro hosts, y como es lo normal en los tiempos que corren, dicho malware reportará información hacia su C&C (Command and Control).

En el segundo de los casos, se realiza todo lo comentado anterior salvo por una excepción. NO se produce la solicitud de resolución DNS.


Flujo del vector de infección analizado.


Las características que son importantes para nuestra investigación y que se dan en ambos casos son:

1.- El "lanzador" utiliza los recursos del propio sistema.
2.- Se utiliza un socket para tramitar la solicitud de descarga.
3.- El socket levantado es un proceso hijo del proceso que abre el documento.

SOLUCIÓN

La solución a este problema mediante el uso de recursos de red pasa por la utilización de:

1.- Un servidor DNS que solo gestione el dominio interno de nuestra red.

NOTA: No realizaría peticiones de resolución de dominios hacía el exterior, de eso ya se encargaría el siguiente elemento.

2.- Un proxy-web, que sea  el único que realice peticiones HTTP/S, SSH, FTP.

NOTAS: 
                A. Por supuesto, la salida a Internet debe de estar controlada, como mínimo por una tupla de usuario/contraseña, que además sea distinta a la utiliza para acceder a la máquina local (este conectada o no a un dominio).

                B. También hay que "adiestrar" a nuestros queridos usuarios para que no almacenen las credenciales para su uso automático, es decir, preferiblemente usar dobles autenticaciones.

3.- Bloquear la salida hacia Internet por cualquier otra medio que no sea uno controlado, vamos, sólo debe salir el proxy-web.

NOTA: Para entornos caseros, este último paso puede ser obviado, y en su defecto, NO definir servidores DNS a utilizar.
Solución con servidor DNS que gestionan, sólo, nuestro dominio interno.


Solución sin servidor DNS interno, enfocado al despliegue en hogares.

EXPLICACIÓN

Si implementamos un servidor DNS que gestiona solamente nuestro dominio interno, las peticiones que realice el lanzador para resolver el dominio del cual quiere descargarse el "malware" no serán atendidas, por lo que la descarga NO se realizará.

Si NO configuramos ningún servidor DNS que gestione las resoluciones DNS, las peticiones que realice el lanzador para resolver el dominio del cual quiere descargarse el "malware" no serán atendidas, por lo que la descarga NO se realizará.

En definitiva, en nuestro sistema permanecerá el "lanzador" pero no se habrá descargado ni ejecutado el verdadero malware.

Si nuestro lanzador no utiliza resoluciones DNS, sino que de manera directa solicita la solicitud de descarga del malware a una dirección IP. Este socket se encaminará hacía nuestra puerta de enlace (Gateway), y no a través de nuestro proxy-web -que es el único que tramita peticiones hacía Internet-, por lo que la conexión contra el servidor solicitado, NUNCA se llevará a cabo.

EFECTOS COLATERALES

Con la solución propuesta tenemos "efectos colaterales", cuales son:

1.- Los archivos que llevan embebidos los códigos malware, se ejecutarán con total normalidad, infectándonos, PERO ... cuando se realicen las conexiones contra el C&C, nuestro entorno bloqueará la salida de las comunicaciones.

2.- Ante los ransomware, esta solución evitará el cifrado de la información o evitará que la clave de cifrado llegue al "C&C". ¿Por qué?.

Todo depende de la versión de ransomware con la que nos encontremos, de las existentes hasta la fecha.

Existe la posibilidad de encontrarnos con versiones que solicitan las claves de cifrado a Internet, en cuyo caso, esta solución bloquearía la salida de la petición, por lo que NO se cifrarían los archivos. Si nos encontramos con versiones que ya poseen la clave de cifrado o la "fábrica" en el momento del cifrado, los archivos será cifrados pero la comunicación que realicen dicho ransomware para distribuir la clave utilizada NO serán entregados.

Esto último supone un inconveniente, incluso el hecho de perder las peticiones que hemos considerado maliciosas, es un inconveniente.

Todo lo comentado con anterioridad puede ayudarnos a alimentar la inteligencia de nuestros elementos de seguridad, si los tuviéramos, ¿cómo?.

Añadamos un "honeypot" a nuestra solución que reciba y responda, si fuera necesario, a todas aquellas peticiones que no pertenezcan a nuestra red interna. Es decir, cuando nuestro servidor DNS interno, reciba una petición de resolución de un dominio que no es el nuestro, dicha petición será enviada a nuestro "honeypot". Si nuestro default gateway recibe un paquete dirigido a una IP que no pertenece a nuestro rango interno, dicha petición será enviada a nuestro "honeypot".

Todas estas peticiones serán recolectadas por los logs de nuestro honeypot, que pueden ser enviadas a su vez a un sistema de correlación, que nos ayude a analizar las peticiones recibidas.

Solución con Honeypot incorporado en nuestra red.


EVOLUCIÓN

Una de las posibles evoluciones consistiría en utilizar el proxy-web, bien, levantando un proceso vinculado con uno de los navegadores existentes en el hosts o bien, configurando un socket que utilice la salida a través de proxy-web.

 En cualquiera de los casos, tal y como se ha comentado antes, habría que:

1.- Adiestrar a nuestros queridos usuarios para que no almacenen las credenciales para su uso automático.

2.- Que las credenciales a utilizar en el proxy-web fueran distintas a la utilizadas frente al dominio o frente a la "base de datos" para el acceso al host de manera local.

3.-  Y para evitarlo,  sería preferible usar dobles autenticaciones.

U otras medidas ...