miércoles, 30 de mayo de 2018

Cuando se pesca hay que tener paciencia, y a veces, ni con esas


En relación con el post: Otro malware a la cesta de peces , hoy se comentará el proceso de vigilancia que se ha llevado a cabo durante el período de tiempo entre el mencionado post y este mismo post.

Sigamos los procesos cerebrales ...

Al estudiar el código se vio la variable: AskFmProfile.

Definición de contenido para la variable: AskFmProfile

La variable AskFmProfile contiene un valor en base64 -como se puede apreciar-, que si se decodifica, se corresponde con la cadena: http://ask.fm/GenLorren

Decodificación de la cadena en base64 contenida en la variable AskFmProfile

Pero, ¿cuándo se usa esa dirección web?, ¿qué contiene?

Si se busca por el código dicha variable se puede ver que se encuentra en dos funciones:

1.- En la función: "getCommand"

Uso de la variable AskFmProfile en la función: getCommand

2.- En la función: sendTaskReturnCode

Uso de la variable AskFmProfile en la función: sendTaskReturnCode

En ambos casos, se puede observar que el contenido de la variable es decodificado y pasado a una función de nombre: LoadHosts.

La programación de dicha función, se puede ver a continuación en la siguiente imagen.

Código de la función: loadHosts

En la función se puede apreciar que tras llamar a la función: getpageSource(), que hace una llamada a la URL decodificada para obtener la página solicita (el código de la misma), tal y como se puede ver en la siguiente imagen:

Código de la función: getPageSource()

Se procede a extraer el contenido existente entre las cadenas: "#__h__s__#" y "#__h__e__#".

Dicho contenido, como se aprecia en las siguientes líneas del código, viene en formato base64 que el programa se encarga de decodificar.

En ese momento, se comprueba si en la cadena decodificada existe al menos un carácter "@". Si es así, se reemplaza en mismo por el carácter "." y se procede a trocear la cadena en base al separador: "|".
Por lo tanto, se puede imaginar que el contenido de la cadena codificada en base64 se trata de una o de varias URLs.

Con toda la información obtenida, se puede decir que esté es el medio que sigue nuestro "amigo mal intencionado" para distribuir las urls de sus C2C.

En vista de esto, se ha procedido a realizar un seguimiento de la actividad del contenido de la URL: http://ask.fm/GenLorren. Todo ello, mediante un pequeño script en bash, un servidor de correo y un trigger en cron.

El código es muy simple, consiste al igual que el malware analizado en:
               
                1.- Descargar el contenido de la URL: http://ask.fm/GenLorren.

                2.- Buscar la cadena en base64 entre los patrones: "#__h__s__#" y "#__h__e__#"

                3.- Comparar la cadena en base64 con la cadena/s almacenadas en un archivo que       funciona a modo de base de datos de cadenas en base64 utilizada por nuestro "amigo          mal intencionado"
               
                4.- Si la cadena no se encuentra entre las cadenas almacenadas en el archivo "bbdd",                 se procede a informar mediante un correo electrónico.
               
                                4.1.- Tras la recepción del correo, el analista decodificará la cadena en base64                                 y seguirá con la diversión.
                              
                               4.2.- La nueva cadena se almacena en el archivo "bbdd", para posteriores                                         comprobaciones.
               
                4.- Si la cadena ya se encuentra entre las cadenas almacenadas, entonces no se realizan otras acciones de interés.

Código desarrollado.

Por último añadir que a día de hoy, 30/05/2018, la actividad de nuestro "amigo mal intencionado" ha sido nula, es decir, no se han detectado nuevas C2C.

¡Pero nunca hay que perder la esperanza!

Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia

jueves, 10 de mayo de 2018

A quien afecta el CVE-2018-9995????


Me hago eco del aviso lanzado en un grupo de Telegram al cual pertenezco, de hace una semana, en referencia a la publicación del exploit desarrollado por el descubridor de la: CVE-2018-9995.

El exploit es realmente sencillo, consiste en realizar la siguiente petición al servidor web de la cámara web.


El fallo, por el cual se pueden conseguir todos los usuarios de la cámara web reside en el uso del valor: uid=admin, en la cookie que se pasa el servidor web.

En la web de además se da información sobre los distintos  "modelos" afectados.


A partir de aquí, expongo mi aportación ...

Realicé una petición de búsqueda a través de la API de Shodan, tal y como el propio descubridor comenta en su publicación, extrayendo, básicamente, dos campos:

                1.- IP posiblemente afectada.
                2.- Puerto de servido web.


NOTA: Los datos obtenidos se corresponden, solamente, con 101 resultados, aunque se saben que existen 9664 resultados.

Número total de resultados obtenidos.


Para cada resultado obtenido y almacenado en el fichero: PPPP, se procedío a la lanzar un escaneo sobre la IP y del puerto obtenido, solicitando un descubrimiento del servicio que se encuentra detrás (opción -sV de nmap).

Para lo cual y como se puede ver en la siguiente imagen se creó un pequeño código en bash.

Código bash lanzando para escanear las IPs y puertos obtenidos.

De los datos obtenidos, se buscaron aquellos resultados donde el  puerto estaba abierto. Y de estos, se obtuvieron el/los servicio/s catalogado/s por Nmap.

Procesos "nmap" en pleno funcionamiento
.
Al final, de los datos procesados, se obtuvo un único  servicio catalogado como:

thttpd 2.25b 29dec2003

Resultados obtenidos.

Con esto podemos saber qué servicio buscar con tu "nmap" sin hacer mucho ruido, en cualquier intranet que te encuentres.

En Internet ya sabemos cuántas existen ...

Yo ya he creado mi propia herramienta de búsqueda y explotación, pero eso ya es otra historia.

Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia