Analizar malware con Anubis

En la última semana hemos recibido en nuestro laboratorio unos binarios provenientes de campañas de phishing y envío de malware, que hemos procedido a analizar de una forma muy práctica y bastante efectiva por el resultado de dicho análisis, que nos permite rápidamente extraer unas primeras contramedidas por si ha habido alguna infección. Vamos a analizar malware con Anubis.

El último de los ficheros lo hemos recibido esta misma mañana y es el que usaremos en este artículo.

Concretamente se trata de un fichero adjunto en este mensaje que “generosamente” Bobby nos envía y que se le había olvidado adjuntar en un correo anterior. Todo un detalle.

Analizar malware con Anubis

Un primer paso era analizar el fichero con el antivirus instalado en uno de los equipos usados como sandbox, con antivirus Avira actualizado hasta el día. En ese primer análisis no salió ninguna detección. Acto seguido, decidimos probar con los 57 motores de análisis de VirusTotal (donde pudimos comprobar que el motor de Avira no lo detectaba), obteniendo en un primer análisis sólo 7 detecciones de los 57 motores, y al cabo de 2 horas un resultado de 12 detecciones.

Analizar malware con Anubis

Aunque nuestro antivirus Avira no lo había detectado, gracias a VirusTotal pudimos comprobar que efectivamente se trata de malware, concretamente el troyano Trojan.Upatre.Gen.3.

Como desconocemos lo que este troyano es capaz de hacer, y queremos saber posibles contramedidas por si ha habido alguna infección, procedemos a subir el archivo a Anubis, donde además de un análisis del binario, lo desplegará y ejecutará en una máquina Windows propia, nos indicará las modificaciones en el sistema de ficheros, posibles entradas de registro y lo que es muy interesante también, nos facilitará una captura del tráfico generado por este malware tras su ejecución.

Analizar malware con Anubis

Como podemos ver en la imagen anterior, tras subir el fichero a Anubis y ser analizado, tenemos a nuestra disposición el informe del análisis en varios formatos, y en la parte inferior un enlace al fichero pcap resultante de la captura de tráfico realizada.

Veamos qué tiene ese fichero si lo abrimos con Wireshark:

Analizar malware con Anubis

Si filtramos los paquetes por tráfico http podemos ver algunas cosas interesantes. Por ejemplo que hace una petición a la IP 91.198.22.70. ¿Qué habrá en ese recurso?

Analizar malware con Anubis

¡Anda qué curioso! Es para saber desde qué IP pública nos hemos infectado. Sigamos. Podemos ver también varias peticiones para descarga de supuestos ficheros PDF, que seguro que no lo son y a su vez realizarán otro tipo de acciones maliciosas como descarga de otros binarios necesarios para lanzar su ataque, que tiene toda la pinta de CryptoLocker.

Como podéis ver, haciendo uso de servicios online totalmente gratuitos podemos de forma rápida y sencilla hacer un análisis del malware y sacar unas primeras conclusiones, y lo que es más importante, aplicar unas contramedidas que mitiguen o reduzcan el riesgo que esta amenaza pueda suponer para los sistemas de información de cualquier organización.

¿Contramedidas? Obviamente en primer lugar realizar un análisis de los posibles equipos infectados, concienciar al usuario de no abrir archivos adjuntos en correos de remitentes desconocidos y aplicar algunas reglas en la seguridad perimetral, por ejemplo, denegar el tráfico desde / hacia las direcciones IP observadas en la captura de tráfico. Se ha comprobado que están reportadas como servidores maliciosos.

Por cierto, en una de esas direcciones IP nos espera un bonito RouterOS de MikroTik. ;)

Analizar malware con AnubisComo siempre, espero que sea de vuestro interés, y nos leemos en siguientes artículos.

¡Saludos!

Parando Metasploit con Snort

Hoy vamos a ver como podemos detectar cualquier tipo de ataque a una aplicación vulnerable de nuestro servidor, simplemente analizando aquellos posibles exploit que puedan ser lanzados contra este y añadiendo una regla en nuestro IDS para detectarlos y pararlos, en nuestro caso utilizaremos Snort. El escenario sería el siguiente:

escenarioPC-Metasplit

La idea es identificar una característica única del exploit a detectar con el IDS y crear una regla con Snort para detectarlo. Para ello previamente lo que hacemos es lanzar el exploit para explotar la vulnerabilidad y capturar el tráfico para analizarlo.

meterpreter

En este momento tenemos que identificar una característica única/particular de este exploit. Debemos ser capaces de obtener la máxima información de como funciona el exploit, para ello podemos analizar el código del propio exploit así como examinar su documentación.

Exploit –> http://www.exploit-db.com/exploits/28681/

Concretamente hemos usado un exploit bajo metasploit para explotar el puerto 21 de un FreeFTPd con una vulnerabilidad que lleva a cabo un PASS Command Buffer Overflow, es decir, introducir una contraseña no esperada para provocar un desbordamiento de buffer. Lanzamos el exploit varias veces y obtenemos varios ficheros .pcap que nos disponemos a analizar exhaustivamente:

wireshark1

wireshark2

Una vez que somos capaces de sacar información que identifique al exploit unívocamente nos disponemos a generar una regla en Snort. Las reglas en Snort constan de dos partes: la cabecera y las opciones. El objetivo de este artículo no es explicar el funcionamiento de Snort, ni tampoco el de como crear una regla, para ello podéis consultar su manual en http://manual.snort.org/.

Si analizamos cada uno de los paquetes que lanza el exploit veremos que se están inyectando operaciones tipo NOPs (No-Operation, instrucciones que no hacen nada, como por ejemplo sumarle 0 a un registro) para rellenar instrucciones además del Payload inyectado. Esto se suele hacer por muchos tipos de malware para reconducir la ejecución del programa, caso de caer en una posición de memoria donde haya una NOP, se ejecutarán todas las instrucciones que no hacen nada hasta llegar al trozo de código malicioso que realmente quiere ejecutar el atacante. Vemos con Wireshark las NOPs y lo que realmente inyecta el Payload.

nops

user_pass

Con toda esta información ya podemos crear un regla en nuestro IDS Snort para detectar este exploit. A continuación mostramos la regla creada según las peculiaridades encontradas en el exploit:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;

Hemos visto que el exploit va dirigido al puerto 21, que hace uso del usuario anónimo y que introduce varios caracteres raros en la parte de la PASS, por tanto esas serán nuestras características concretas para nuestra regla.

Analicemos pues la parte de la cabecera:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21

Se aplicará la regla de eliminación de paquete (drop) a todos aquellos paquetes que vengan vía tcp desde una red exterior ($EXTERNAL_NET es una variable que identifica cualquier IP externa) desde cualquier puerto de comunicación en el origen (any); y cuya petición vaya destinada a una IP interna ($HOME_NET idem IP interna) sobre el puerto 21.

 Dentro de la parte de las opciones:

(msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;

En este apartado determinaremos que características tienen los paquetes que deben ser eliminados. Dejaremos constancia del bloqueo de paquetes en el log de Snort con el mensaje que aparece en msg.

El paquete debe ser una petición de usuario anónimo y que la clave contenga alguno de los datos contenidos en la expresión regular (pcre). Dicha expresión regular debe estar escrita en perl, podéis encontrar diferentes expresiones regulares y reglas en el fichero policy.rules de Snort. El resto de las opciones determinan la clase de paquete (classtype), el identificador de la regla local (sid) y revisión (rev); y por último añadimos la palabra nocase para indicar al motor de Snort que la aplicación de la regla no sea “case-sentitive“.

La regla se añadirá al final del fichero de configuración de snort (snort.conf). Una vez añadida se comprueba su funcionamiento con los .pcap capturados del ataque para ver si es efectiva en caso de producirse nuevo ataque.

snort -A fast -c /ruta/snort.conf –pcap-dir=”/ruta/pcaps/” -l .

-A modo de la alerta, rápida en este caso (fast)

-c fichero de reglas, en este caso el snort.conf que hace referencia a todos los ficheros de reglas de que se encuentra en la carpeta de snort (/rutaSnort/rules) y además contiene al final nuestra regla. Debe ponerse todo en una sola línea.

–pcap-dir indicamos la carpeta donde están los pcap para comprobar.

-l indicamos la carpeta de salida del log (se creará un fichero llamado alert)

Una vez comprobado el funcionamiento de las reglas con los pcaps que contienen la captura del exploit, obtenemos el siguiente resultado:

alert

 Vemos como además de nuestra regla, hay otras reglas dentro de snort que detectan el uso del usuario anonymous o el overflow en la PASS. Ahora sólo tendremos que coger un exploit de un 0day y analizarlo para crear una regla de Snort y que no afecte a nuestro servidor hasta que podamos parchear la vulnerabilidad en cuestión. También se suele analizar el tráfico que genera ciertos malware y crear reglas en función de las peticiones que realicen.

Bueno ahora sólo queda que os pongáis a jugar con algunos exploits y los analicéis para poder detectarlos.

Un handshake

@eduSatoe

“Si caminas solo andarás más rápido, si caminas acompañado llegarás más lejos”

PrivacyFix: Tu privacidad depende de la privacidad de los demás

¿Crees que eres dueño de tu privacidad? Redes sociales, portales de Internet, grupos de Whatsapp, aplicaciones móviles que solicitan muchos permisos… hoy día es muy difícil proteger nuestra privacidad, pues nuestra vida virtual está conectada con nuestra vida real.

¿Realmente controlas las fotografías que aparecen tuyas en las redes sociales, conoces aspectos tan importantes como la geolocalización, sabes qué aplicaciones móviles requieren los datos de tu teléfono…? En definitiva, ¿sabes qué información se publica de ti en Internet?

A día de hoy es imposible controlar nuestra privacidad al completo ya que nuestra privacidad depende de la privacidad de los demás, una foto en el teléfono de un amigo, un perfil de Twitter con geolocalización activada donde se te etiqueta en una foto, un perfil de Facebook público donde aparecen fotos de menores… Son algunos ejemplos de que no somos dueños de nuestra privacidad.

A continuación vemos algunos ejemplos de información sensible:

twitter

  • Geolocalización que guarda Gmail desde nuestra cuenta configurada en nuestro teléfono Android (¿Está tu cuenta de gmal entre los 5 millones de cuentas vulneradas hace unos meses? Ver aquí)

gmail

  • Perfiles públicos en Facebook con información sensible u obtenidos a partir de un número de teléfono móvil publicado en Internet (MilAnuncios, BlaBlaCar, etc).

facebook

Además de estos ejemplos, tenemos también un caso muy importante a tratar sobre la privacidad, concretamente de las fotografías que otras personas suben de nosotros a Internet, bien por redes sociales o chats. A continuación podéis ver un video donde se aclara perfectamente:

Como complemento a esta información podéis ver un artículo sobre El peligro de las Redes Sociales que publicamos hace unos meses.

Algunas de estas fugas de información se pueden evitar para proteger nuestra privacidad, tan sólo hay que configurar de manera correcta nuestras redes sociales, cuentas de correo u otros perfiles de usuario utilizados en Internet. Ahora esto es muy sencillo haciendo uso de la herramienta Privacy Fix de AVG.

¿Qué es PrivacyFix?

Privacy Fix es su panel de privacidad en línea. Este complemento para navegadores y app para dispositivos móviles realiza un análisis para detectar problemas de privacidad y te ayuda a configurar los ajustes para corregirlos.

Concretamente podemos llevar a cabo el fixeo de la configuración de los siguientes apartados:

  1. El seguimiento de navegación del usuario.
  2. Cuenta de Gmail.
  3. Perfiles de Twitter, Facebook y LinkedIn.

1. En la siguiente imagen vemos cómo podemos corregir fallos de privacidad respecto al seguimiento de cookies o widgets que rompan nuestra privacidad en Internet.

00privacyfix

A medida que vamos corrigiendo los diferentes ajustes veremos como la barra de proceso va avanzando.

2. El seguimiento que Google hace de nosotros conlleva entre otras cosas el almacenamiento del historial de búsqueda, cosa que podemos corregir. También el seguimiento de cookies por parte de anunciantes para poder ofrecernos sus productos independientemente de la Web que visitemos.

01google

3. Por último vamos a corregir nuestra configuración de seguridad/privacidad de nuestras redes sociales.

Dentro de Twitter podemos corregir varios aspectos que vemos a continuación.

02twitter

En la siguiente imagen vemos como PrivacyFix nos asiste para desactivar de manera correcta la geolocalización en los tweets.

02_1twitter

Dentro de Facebook podemos corregir varios aspectos que vemos a continuación.

03facebook

Dentro de LinkedIn podemos corregir varios aspectos que vemos a continuación.

04Likedin

Una vez que tenemos todos los puntos corregidos veremos la barra de proceso al 100%, lo cual quiere decir que los aspectos de privacidad de nuestras redes sociales y cuentas están bien configurados.

A medida que naveguemos por Internet podemos ver en la barra de navegación el complemento de PrivacyFix y consultar aspectos de privacidad sobre la Web que visitamos en ese momento.

panel

Espero que seáis conscientes de la importancia que tiene preservar nuestra privacidad en la red y lo que nos puede ayudar esta herramienta a ello. Para finalizar os dejo un video que puede darnos que pensar sobre el camino que lleva nuestra sociedad en relación al uso de las redes sociales y la importancia de las mismas:

Hasta la próxima y cuidar de vuestra privacidad porque de ella depende también la privacidad de los demás.

¡Un handshake!

@eduSatoe

“Antes de cambiar el mundo, da tres vueltas por tu casa”

Proverbio chino

¿Cuál es tu contraseña? ¡Por favor, no hagáis esto!

Hola, me llamo Rafael y hace una semana empecé a trabajar con los Cracks de Miguel y Manuel, los cuales, ya que nos poníamos, me engañaron para ir escribiendo en el blog, cosas sobre seguridad web y de servidores que es mi especialidad :)

En realidad soy un programador pero, en uno de los proyectos en la Universidad, me insistieron mucho en los temas de seguridad y al final me acabé volviendo un poco de más “quisquilloso” con ello :D

Para mi primera entrada quiero que os riáis un poco y veáis lo que no se debe hacer nunca con tu contraseña, que es compartirla con la gente y menos como hacen en este vídeo, que con un poco de ingeniera social todo el mundo la dice :P

Así que ya sabéis, no deis pistas, ni cómo generáis vuestras contraseñas, para que no vulneren vuestra privacidad digital.

Un saludo.

Alerta!Malware en mi Web! – Linux Malware Detect

Hace muy pocos días, una importante empresa que aloja infinidad páginas webs de todo tipo, contactó con nuestro departamento ya que habían recibido un “abuse” desde el servidor/es dónde están alojadas las páginas de sus clientes.

La búsqueda de malware en un sitio Web es una tarea ardua y tediosa a la par de lenta aunque con las herramientas adecuadas puedes ahorrar mucho tiempo. Esto no quita el pertinente análisis “a mano” para revisar ficheros que contengan código ofuscado, scripts maliciosos, etcétera.

Existen herramientas online para escanear sitios Webs en busca de pharmahack, defacements, malware, etcétera… Como he comentado, utilizar estas herramientas puede acortar el tiempo de detección y corrección del problema.

Herramientas de este tipo no es que existan multitud pero sí que existen las suficientes y con calidad. Podéis encontraros aplicaciones que pretendan ayudaros a encontrar “el bichito” en vuestro sitio pero realmente, las más famosas en este caso, son las más efectivas y más reales.

Read more

iOS Hacking: Comprobando ASLR con otool

Continuando esta serie de artículos sobre iOS Hacking, veremos en este post qué protecciones en tiempo de ejecución podemos implementar a nuestra aplicación iOS para que sea más segura. Algunas de estas medidas son usadas también en otros tipos de aplicaciones de diferentes arquitecturas, como el que vamos a tratar en este artículo, ASLR.

Antes de empezar destacaremos la herramienta otool que nos permite extraer información importante de un binario en iOS. Los binarios en iOS usan el formato Mach-O, que a su vez se divide en cabeceras, comandos de carga y datos (segmentos y secciones). Con la herramienta otool podremos visualizar detalles de la compilación, para qué arquitectura se ha compilado, cabeceras, comandos y lo que nos ocupa en esta ocasión, parámetros de algunas de las medidas de protección en tiempo de ejecución que podemos utilizar.

iOS Hacking - Mach-O

ASLR (Address Space Layout Randomization): al igual que en otras arquitecturas, esta técnica dificulta la explotación de alguna vulnerabilidad asignando localizaciones aleatorias de los objetos en memoria. Para usar la protección completa ASLR, y no de forma limitada como lo hacen las aplicaciones iOS por defecto, hay que compilar desde Xcode con el flag PIE activado.

Con otool podremos verificar si una aplicación está protegida completamente con ASLR ejecutando el comando con la siguiente sintaxis:

otool -Vh binario_de_la_app

iOS Hacking - otoolPodemos ver en la imagen anterior cómo la aplicación que hemos tomado como ejemplo, Messenger de Facebook, ha sido compilada con el flag PIE, por lo tanto está protegida totalmente con ASLR, y aunque se conocen técnicas para hacer “bypass” a estas protecciones, nunca viene de más poner obstáculos a posibles atacantes.

En siguientes artículos veremos qué otras protecciones podemos implementar y qué técnicas y herramientas utilizar durante el pentesting de una App iOS para verificar si la aplicación implemente o no estas protecciones.

¡Hasta la próxima!

iOS Hacking: credenciales Google Analytics sin cifrar

Revisando la seguridad de algunas aplicaciones iOS me he encontrado con una sorpresa, que no esperaba, al menos en uno servicio como el de Google Analytics, y es que revisando la seguridad y privacidad en Local Storage del dispositivo Apple he encontrado que mis credenciales de Google Analytics estaban almacenadas en claro, sin ningún tipo de cifrado.

A nivel de almacenamiento local, tal y como veremos en próximos artículos de la serie “iOS Hacking” en este blog, destacar que existen varias localizaciones donde poder encontrar información sensible de las aplicaciones o del propio sistema. Ficheros de configuración, temporales, cookies, bases de datos, capturas, logs del sistema o aplicación, etc. Entre estas localizaciones nos encontramos también un contenedor cifrado que almacena algunos datos sensibles como pueden ser nombres de usuarios, contraseñas, o certificados, se trata del Keychain de iOS.

Ha sido en este contenedor donde he encontrado mis credenciales sin cifrar.

Google Analytics - iOS

Un acceso físico al dispositivo, a causa de un descuido, robo o pérdida, fuga de información debido a un malware, o acceso a una copia de seguridad del dispositivo, permitiría extraer esta información del usuario.

Permaneced atentos que próximamente iremos publicando más artículos relacionados con la seguridad en aplicaciones y dispositivos iOS dentro de la serie de posts que ya hemos comenzado y nombrado como “iOS Hacking“.

¡Hasta pronto!

Felices Fiestas

Desde el equipo de www.hacking-etico.com queremos felicitar estas fiestas a todos los visitantes que diaramente visitan nuestro sitio.

Ha sido otro año de un incremento de visitas que no preveíamos pero que obviamente estamos muy contentos. Así lo dice igualmente el 5º puesto en los Premios Bitácoras al mejor Blog de Seguridad Informática.

Esto no sería posible sin vosotros y nos da un extra de confianza para seguir “al pie del cañón”.

Feliz Navidad y Próspero Año Nuevo.

El equipo de hacking-etico.com

hefeliz

Exploit para SugarCRM y sus demos

En este artículo os hablaré sobre cómo detecté y corregí un pequeño “error” en un exploit para SugarCRM que no funcionaba correctamente. Mi charla en el pasado Hack&Beers de Tamarite (Huesca), trató precisamente sobre esto. Supongo que algo habrá cambiado en el tratamiento de URLs y Cookies de este CRM desde que se publicó su vulnerabilidad y exploit, exactamente el 25 de Junio de 2012, que a día de hoy cause el error en un exploit que se publicó al día siguiente de la publicación de la vulnerabilidad.

Enlace a información de la vulnerabilidad: http://www.securityfocus.com/bid/54169

Enlace al exploit: http://www.exploit-db.com/exploits/19403

SugarCRM es un sistema para la administración de la relación con los clientes (CRM) basado en LAMP (Linux-Apache-MySQL-PHP), desarrollado por la empresa SugarCRM, Inc. ubicada en Cupertino, California.

SugarCRM: Vulnerabilidad y Exploit

La vulnerabilidad que estamos tratando permite la ejecución de código remoto.

SugarCRM: Vulnerabilidad y Exploit

Para esta prueba de concepto, tenemos preparado un SugarCRM con una versión vulnerable, con un usuario creado con las siguientes credenciales: sugarcrm/sugarcrm.

Se requiere saber las credenciales de un usuario de SugarCRM para explotar esta vulnerabilidad. Esto puede hacer pensar que el número de exposición de sitios Web con SugarCRM vulnerables es muy limitado, sin embargo, hay que tener en cuenta que son muchos (muchísimos) los sitios Web que ofrecen probar SugarCRM en una demo, facilitando el usuario y contraseña para probar el CRM.

SugarCRM: Vulnerabilidad y Exploit

En la imagen anterior podemos ver una captura de una búsqueda en Google que muestra resultados de sitios Web con SugarCRM que ofrecen una demo y además facilitando un usuario y contraseña. Justo lo que nos requiere el exploit que vamos a usar.

El exploit para SugarCRM que vamos a utilizar es de Metasploit: sugarcrm_unserialize_exec.

SugarCRM: Vulnerabilidad y Exploit

Después de poner en uso el exploit, lo configuramos con las opciones requeridas: USERNAME (sugarcrm), PASSWORD (sugarcrm) y RHOST (192.168.1.39, dirección IP del servidor con SugarCRM). Los valores son los correctos para el sitio SugarCRM que tenemos preparado para la prueba de concepto. Como payload hemos seleccionado una sesión meterpreter vía PHP, mediante conexión inversa (reverse_tcp).

SugarCRM: Vulnerabilidad y Exploit

Al ejecutar el exploit, obtenemos un mensaje de error durante el “Login“, aún habiendo introducido las credenciales correctas (sugarcrm/sugarcrm). No se obtiene una ID de sesión. Procedemos a repasar el código del exploit y localizamos que el mensaje de error lo muestra cuando no se cumple una condición.

SugarCRM: Vulnerabilidad y ExploitPor alguna razón, con las credenciales correctas, la variable res.get.cookies no contiene la expresión regular que el código del exploit propone, para descubrir si se ha obtenido una sesión (PHP).

En primer lugar, con un proxy Web local como ZAP, comprobamos el formato de la cookie que se genera cuando hacemos “Login” en SugarCRM a través del navegador.

SugarCRM: Vulnerabilidad y Exploit

En principio, tal y como nos muestra ZAP Proxy, el formato de la Cookie generada cumple exactamente lo que la expresión regular del código intenta “matchear“. Falta comprobar cuál es el valor que recoge la variable. Para ello incluiremos una línea nueva en el código para hacer un “print” del contenido de la variable. Read more

Premios Bitácoras 2014. Mejor Blog de Seguridad Informática. Finalistas.

Ya han salido los finalistas de los Premios Bitácoras 2014 alMejor Blog de Seguridad Informática en el que nuestro blog ha sido clasificado en 5º Posición.

Desde el equipo de hacking-etico.com queremos agradecer de corazón a todos los que han votado nuestro blog.

Nos ayuda, sin duda, a continuar con esta labor desinteresada, exponiendo, siempre desde la humildad, artículos sobre seguridad informática para hacer llegar al máximo número de personas esta parte de la informática, tan fascinante y compleja a su vez.

Darle la enhorabuena a todos los participantes, y a los tres finalistas que recibirán el premio Underc0de, El Lado del Mal y Oficina de Seguridad del Internauta primer, segundo y tercer premio respectivamente.

Sin olvidarnos la calidad indudable de los demás clasificados, referencias en este mundo.

Os dejamos la clasificación final.

Read more