lunes, 23 de diciembre de 2013

Descifrando la configuración de un troyano PiceBOT 2.0

A diario, en el laboratorio de Hispasec, analizamos una gran cantidad de muestras de diferentes familias. Entre ellas, este año hemos añadido un nuevo integrante a la familia de "Hosts Modifier", concretamente PiceBOT en su versión 2.0. PiceBOT es una familia de troyanos orientados al robo de credenciales bancarias. La versión 1.5 de PiceBOT hizo su aparición a principios de año, concretamente fue Kaspersky quien lo reportó.

Las distintas familias de malware que englobamos dentro de "Hosts Modifier" utilizan una técnica sencilla cuando infectan un sistema, simplemente cambian el archivo host del equipo para redirigir las resoluciones DNS de ciertos dominios hacia un servidor controlado por el atacante. Un envenenamiento de la caché local del equipo.

Adicionalmente, los PiceBOT "zombifican" el sistema añadiéndolo a una botnet y quedando el equipo a la espera de órdenes enviadas desde el centro de control (C&C). Sin embargo, una información de tanto valor como la URL del C&C, no se encuentra en claro en el binario. En este articulo, veremos cómo automatizar su análisis de manera estática, es decir cómo extraer los C&C sin necesidad de ejecutar el PiceBOT. Esto proceso es sumamente importante de cara a automatizar el estudio y análisis de esta familia.

En primer lugar, vamos a ver cómo extraer las cadenas cifradas automáticamente dentro del binario. Una vez extraídas, vamos a diseñar una rutina para descifrarlas. Finalmente veremos cómo automatizar el proceso de descifrado con un script en python para extraer las cadenas sin necesidad de ejecutar el troyano.

Para obtener las cadenas del programa, usaremos el comando "strings -a -e l" que nos permite de extraer todas las cadenas del programa codificadas en formato Unicode. Podemos ver que las cadenas en formato hexadecimal aparecen cifradas, por eso nos interesan especialmente, porque seguramente incluyan información importante para su estudio, como la URL del C&C, entradas del registro, nombres de ficheros, etc.

51934B4E6E534C311AB35512
53914B5D254417730B984A43
53915140274F17730B984A43
539E49572D515C2F55D242432C
61935141055B41220F
66C67A78096D600E72AF7A6D096C77174C8E525A214F
6895455D2F504B2751D27E620C6B701575
6C92524A3255452D4AD6419E095A324F7B224898085B3857
6D95424A164A572851D6
6DB763761F6F6B0264B0796201606C086BB9
708C424E34460E
739555463409
7688495F164A572851
769E4F4A044F486F41904A
798B4F412C4C43320B995E4A
79AF49493454453340A0

Para identificar la rutina que encargada de descifrar estas cadenas, va a ser necesario utilizar técnicas de ingeniería inversa. Concretamente vamos a ayudarnos de la herramienta VB decompiler. Analizando el código desensamblado encontramos el siguiente:

Código que nos permitió localizar la rutina de descifrado

Podemos ver que cada una de las cadenas cifradas en hexadecimal se encuentra seguida por la función llamada Proc_1_0_4074DC que toma como parámetro la cadena a descifrar. Esta fue la pista definitiva para cerciorarnos de que nos encontrábamos ante el código que buscábamos. Una vez dentro de la función encontraremos el siguiente código:

Rutina de descifrado

Para automatizar el descifrado de manera estática, es decir sin ejecutar el binario, hemos decidido traducir el código anterior a Python. A continuación podemos ver el programa equivalente implementado en Python para descifrar las cadenas del troyano:

def decode(ciphered_string, key):
       deciphered_string = ""
       key_length = len(key)

       j = 1
       for i in range(0, len(ciphered_string), 2):
            key_offset = (j -1) % key_length
                     
            #Get the key character corresponding to the character to decipher
            key_character_value = ord(key[key_offset: key_offset + 1])

            #Get the character to decipher
            ciphered_character_value = int("0x%s" % ciphered_string[i:i+2], 16)

            #Decipher the character
            deciphered_character = chr(key_character_value ^ ciphered_character_value)

            #Add the deciphered character to the deciphered string
            deciphered_string = "%s%s" % (deciphered_string, deciphered_character)
            j += 1

            return deciphered_string

def main():
       key = chr(37) + chr(252) + "&/@#$A"
       string_to_decipher = “66C67A78096D600E72AF7A6D096C77174C8E525A214F”
       print(decode(string_to_decipher, key))


Podemos observar que entre las cadenas ocultas de la muestra, se encontraban las direcciones del C&C (C&C1 y C&C2) y varias rutas y nombres de ficheros que nos indican que el troyano comprueba si es  ejecutado en un entorno virtual (Comprueba1, Comprueba2, Comprueba3, Comprueba4, y Comprueba5).

[.exe
open
http://www.americansoftwoodsmexico.com/~izqoder/admin/ (C&C1)
http://www.romney.com.br/~acsegura/Admin/ (C&C2)
toma.php?Os=
vmmreg32.dll (Comprueba1)
vmwogl32.dll (Comprueba2)
vboxmrxnp.dll (Comprueba3)
DownExec*
C:\WINDOWS\BIOSVirtual (Comprueba4)
Microsoft.XMLHTTP
Intervalo
HideVisit*
HKEY_LOCAL_MACHINE
Update*
Visit*
StopVisit
SbieDll.dll (Comprueba5)
\winlogs.exe
\Software\] 

Por último, os dejamos una cadena hexadecimal cifrada para que vosotros mismos probéis a descifrarla:

63994a463a036a205395424e24031e7c0c
  
Más informacion:

SHA-256 del PiceBOT analizado:
064c6fe2c42aa974041c78b049091015d2079392dd048754e75dd07484447391

Kaspersky:


Laurent Delosières


lunes, 16 de diciembre de 2013

Hispasec participa en las VII Jornadas STIC del CCN-CERT

Nuestro compañero Javier Rascón, responsable del departamento de Malware de Hispasec, ha tenido el placer de participar en las séptimas jornadas STIC del CCN-CERT. El evento tuvo lugar en Madrid los días 10 y 11 de diciembre en las instalaciones de la Fabrica Nacional de Moneda y Timbre.

Javier ofreció una charla titulada "Malware, evadiendo al vigilante" en la cual tuvo la oportunidad de mostrar al público las diferentes técnicas que emplea la industria del malware para evitar la detección por los antivirus y aumentar la persistencia del código malicioso en el sistema.





Cabe destacar el éxito de concurrencia y la calidad observada en las charlas. La temática general versaba sobre una materia que cada vez cobra mayor importancia en el plano estratégico de la defensa nacional: la ciberseguridad y que igualmente, debido sobre todo a la complejidad creciente de las infraestructuras tecnológicas, puede ampliarse al ámbito privado.

Nos resultó especialmente interesante el proyecto LUCIA del propio CCN-CERT para el tratamiento de gestión de incidentes.

Nuestro agradecimiento y felicitaciones a los organizadores por la gran labor y trabajo que han realizado durante estas jornadas.


El equipo de Hispasec.



viernes, 22 de noviembre de 2013

Mejorando los resultados sobre descubrimiento de recursos web ocultos

Una de las fases dentro de la auditoría web es la exploración de recursos. Esto es un proceso iterativo: Exploración, detección, pruebas, análisis de resultados y si encuentras nuevos puntos de ataque otra vez de vuelta al principio. Existen multitud de herramientas para hacerlo: Golismero, BurpSuite, o el venerable DirBuster, sin actualizar desde 2009, lo hacen entre otras muchas funcionalidades.

El funcionamiento de este tipo de herramientas es simple. Recorren el sitio web como una araña web, recolectan enlaces a recursos y generan un bucle hasta que terminan en algún punto. Lo ideal es que recorran toda la jerarquía de directorios y páginas que formarán un árbol jerárquico. Con esto tienes una foto de todos los recursos públicos de una aplicación web y ya puedes comenzar con la siguiente fase, pero...eso solo es el comienzo.

Casi la gran mayoría de aplicaciones web tienen ciertos recursos ocultos o más bien no publicados, recursos que no están ni indexados por el todopoderoso GoogleBot, sencillamente porque ninguna de las rutas lleva hacia allí.

¿Cómo encuentras algo que se supone no debería estar ahí?

Existen multitud de técnicas. La más ingenua es mirar en el robots.txt, donde se supone que no quieres que indexen cierto contenido. Curiosamente, a los ojos humanos o de un bot que no respete el estándar de facto, el robots.txt termina ofreciendo la funcionalidad inversa a la supuesta. Anunciar recursos.

La técnica más común es tener un diccionario de recursos comunes y emplearlo a base de peticiones contra la aplicación. En teoría si el recurso está obtendrás un código 200 Ok de lo contrario un 404 Not Found, si el recurso se encuentra en otra dirección un 30x y si su acceso está restringido un 403 Forbidden

Esto naturalmente se da en un mundo ideal. Vamos a hablar de un caso particular.

En determinadas ocasiones, sabes que un recurso se encuentra en un lugar porque recibes un código 200:

carpeta1/carpeta2/recurso.php

Pero en "carpeta1" y en "carpeta2" pueden existir algunos más que no estén publicados. El problema para las herramientas viene al pedir, por ejemplo:

carpeta1/carpeta2/

Dará un 404 aunque sepamos que "carpeta2" es un recurso que existe. Así, si intentamos efectuar un descubrimiento de carpetas comunes por diccionario para posteriormente explorarlo con nombre.extensión nos dará una ristra interminable (tan larga como el diccionario) de respuestas 404 donde seremos incapaces de distinguir cuales existen y cuales no.

Sin embargo, gracias a ciertas configuraciones, pidiendo ciertos tipos de archivos nos dará un código diferente al 404, revelando así la existencia de nuevos recursos procedente de nuestro diccionario.

Uno de los ejemplos es la regla que impide el acceso al archivo .htaccess de Apache:

<Files ~"^\.ht">
     Order allow,deny
     Deny from all
     Satisfy all
</Files>

Esto genera un código de respuesta 403 al pedir un archivo .ht****

Lo curioso es que si la ruta es la adecuada recibiremos el 403 y nos indicará que hemos dado con algo que existe. Por contra si obtenemos un 404 ya podemos descartar esa entrada.

Esto no nos va a valer en todos los casos. Al igual que en una inyección ciega de código SQL tienes que estudiar como responde el servidor ante un grupo de peticiones estrategicamente construidas para observar las respuestas.

Haciendo una prueba con una pequeña herramienta que estamos desarrollando de manera informal para probar nuevas técnicas y que nos complementa las que ya tenemos nos da resultados interesantes:

El primer pase es sin la terminación '.ht' donde cualquier recurso, aun existente, dará un 404:


 Solo dos resultados y estos son debido a que piden autenticación, código 401.

El siguiente pase es adaptando las peticiones a la técnica descrita:



Hemos triplicado los resultados. Esto es sobre un directorio previo donde se supone no debería haber muchos recursos y usando un diccionario con un número de entradas relativamente pequeño.

Sobre la herramienta: Hispasec no da soporte oficial ni es responsable de un uso inadecuado. No la podemos considerar preparada para su uso profesional, al menos en ese ámbito, se recomienda usar alternativas, como las ya comentadas arriba, que van a proporcionarnos un mejor resultado.

lunes, 4 de noviembre de 2013

Caducado el certificado en checkout.payments.ebay.es

En Hispasec andamos desarrollando una herramienta que permita monitorizar distintos parámetros relacionados con la seguridad de las webs de nuestros clientes, uno de los aspectos que tiene en cuenta es la correcta configuración de los certificados, así como que no esté cerca la fecha en la cual expira.

De este modo decidimos incluir a modo de prueba algunas empresas en las que este factor fuera especialmente delicado, como por ejemplo, sitios utilizados para llevar a cabo transacciones online.

Pues bien, hace unas 8 horas ha caducado el certificado de una de las dos ip que resuelven al dominio checkout.payments.ebay.es.



Este dominio es utilizado en el proceso de validación de compra de ebay, un lugar muy poco recomendable para que aparezca una crucecita roja junto al candadito, indicando a todos tus clientes que están a punto de comprar algo, que existe un problema con el certificado.



Para este tipo de webs, que tienen miles de transacciones diarias, además de una pérdida de imagen supone un importante agravio económico que va aumentando cada minuto que tardan en solucionarlo.

lunes, 7 de octubre de 2013

De vuelta de la tercera edición de las Navajas Negras

La semana pasada se celebró en tierras manchegas, concretamente en la ciudad de Albacete, la tercera edición de las conferencias de seguridad informática Navajas Negras, a la que Hispasec asistió representada por Jorge Carballo, José Mesa, Daniel Vaca y el que os escribe, Fernando Ramírez.

Lo primero de todo, agradecer a los organizadores el trabajo tan maravilloso que han llevado a cabo, para que unos cuantos hayamos podido disfrutar del lujo de asistir a las charlas y el poder relacionarnos con amigos de profesión, además de haber conocido una ciudad que nos ha sorprendido por lo acogedora que la hace la calidad de sus gentes.

También agradecer que 3 de los 9 libros sorteados entre los 300 participantes hayan ido a parar a Hispasec, cumpliéndose una probabilidad mayor a 1 entre 10.000.

Todo esto siempre y cuando cr0hn, no revele algún error en su script para generar los ganadores de los nueve libros, el cálculo de la probabilidad sería el siguiente:

La probabilidad de que a Hispasec le toque un libro es P=4/300.

Entonces la probabilidad de que le toque 3 libros a Hispasec en 9 intentos (los nueve libros que se sortean) es una distribución binomial que viene a ser la siguiente:








Donde n es el numero de intentos (9) y m es el número de éxitos (3) y la probabilidad es la de antes, por lo que quedaría:







Aunque la estadística nos dice que sería una probabilidad lógica si hubiésemos asistido a 10.000 sorteos, no estamos ante una posibilidad tan remota, cosas más improbables se han visto o se ven, en cada sorteo de lotería.


* No se contempla el caso de que a una persona le toquen dos o más libros, puesto que el script que asignaba los ganadores no lo contemplaba y no se dio el caso. :D

Más información sobre las conferencias y el evento en:
http://unaaldia.hispasec.com/2013/10/iii-conferencias-de-seguridad-navaja.html


jueves, 19 de septiembre de 2013

Empleando técnicas Rookit para ocultar VirtualBox

'Hand of the Thief' es un troyano "comercial" que se ha estado moviendo por foros rusos. Este troyano está dirigido a sistemas Linux y su función principal es el robo de credenciales bancarias, aunque no se limita a este tipo de webs. Dicha función permite al troyano captar las credenciales a través de form grabbing. Curiosamente, a pesar de ser un troyano orientado a sistemas Linux, posee un sistema de manipulación de registros DNS en memoria. Es decir, el troyano no toca los archivos para modificar la resolución de nombres local.

El troyano ha sido probado con éxito en diversas distribuciones: Fedora, Arch Linux, Gentoo, Debian entre otras.

Una de las técnicas tradicionales para evitar su análisis por parte de las compañías antivirus es la detección de máquinas virtuales, esto es, cuando el troyano se está ejecutando en un entorno virtualizado su comportamiento pasa a ser inocuo o directamente finaliza su ejecución de manera prematura. 'Hand of the Thief' detecta máquinas virtuales VirtualBox, VMware, Power VM, IBM/S390, QEMU y Xen.

No vamos a describir aquí el comportamiento de este troyano, ya que esto daría para otro post y además existe un excelente análisis aquí. Lo que vamos a ver son técnicas concretas que podemos usar para esconder el entorno de virtualización, en concreto VirtualBox. Primero introduciremos los términos que vamos a usar y posteriormente veremos como el troyano intenta detectar la virtualización y como podemos evadir dicha funcionalidad.


Definiciones

Las técnicas rootkit permiten ocultar la presencia de un malware, explotar vulnerabilidades y escalar privilegios en un sistema (cuanto más altos, mayor control sobre el sistema). Un rootkit puede cargarse tanto en espacio de usuario como en el espacio del kernel (donde siempre tendrá más control).

Una llamada al sistema o system call, es una función que se efectúa en el espacio de usuario para transferir momentaneamente el control al kernel a través de una interrupción. Podemos ver una lista de las llamadas al sistema realizadas por un proceso a través del programa strace. El funcionamiento de una llamada al sistema es sencillo: Un proceso en espacio de usuario necesita ejecutar una llamada al sistema, mete en la pila su índice, parámetros y ejecuta una interrupción a través del código ensamblador INT 0x80. En ese momento el kernel recoge dicha petición, busca en el índice la función correspondiente, la ejecuta con los parámetros provistos por el usuario y retorna el resultado y el control de ejecución al proceso del usuario.

Un driver es un módulo del kernel. Un programa inyectado en el espacio del kernel teniendo acceso tanto a dicho espacio como al espacio del usuario. Dispone de una variedad de instrucciones más amplia que un proceso de usuario debido a los privilegios que dispone. Un módulo se carga en el kernel con el comando insmod o modprobe y se desinstala con rmmod.


Evitando la detección

Para detectar la máquina virtual VirtualBox, el troyano prueba la presencia de la cadena “VBOX” dentro del archivo “/proc/scsi/scsi” que lista los discos SCSI usados (disco duro, disco de DVD, etc.). Si lo encuentra, el troyano termina su ejecución. Como dijo P. Kalni, podemos evitar esta prueba quitando el modo lectura de este archivo para que el troyano no pueda leerlo. Sin embargo, este método es limitado y no puede generalizarse a otro troyano ya que éste podría probar si el archivo esta en modo lectura. Nuestra solución implica el uso de un rootkit para modificar el contenido del archivo leído. Es decir, que cuando el troyano lea el archivo, el rootkit va a buscar la cadena VBOX y la reemplazará por otra cadena. De esta manera, modificamos el contenido leído al vuelo y no el archivo. En este ejemplo, modificamos la cadena VBOX por “____”.

Cuando un programa lee un archivo, llama a la system call “read” de la biblioteca libc que ejecuta la función del kernel “sys_read” a través de la interrupción 0x80. En otras palabras, para modificar el contenido al vuelo de un archivo leído se necesita hookear la función del espacio de usuario “read” o del espacio del kernel “sys_read”. Hemos elegido hookear la función del kernel porque el programa podría escapar del hook de la función “read” llamando a la función “sys_read” directamente. Además, hookear la función “read” supone que el malware use la biblioteca libc para leer un archivo.

Hookear la función "sys_read" significa cambiar el modo lectura de la tabla de llamadas al sistema para poder escribir y cambiar el index en dicha tabla de la función “sys_read” para redireccionarla a nuestra función “new_sys_read”. Hemos creado un driver para hookear la función “sys_read” y crear la nueva función “sys_new_read”. Cuando la función “new_sys_read” sea llamada, ella va a (1) llamar a la función original “sys_read” para recoger una parte del archivo o la totalidad del archivo en un búfer,  (2) reemplazará cada cadena VBOX por “____” del búfer y (4) devolverá el búfer modificado.

Sin embargo, necesitamos conocer la dirección de la función “sys_read” para llamarla desde "new_sys_read", conocer la dirección de la tabla de llamadas al sistema para modificar la entrada “sys_read”, y también la dirección de la función “lookup_address” que nos permite obtener la página correspondiente a la tabla de llamadas al sistema para cambiarla del modo lectura y escritura. Estas direcciones variarán de un sistema a otro. Se pueden encontrar en el archivo /boot/System.map.

Una parte del código fuente:

//Nueva función sys_read

asmlinkage long
 new_sys_read(unsigned int fd, char __user *buf, size_t count)
{
//Llama a la funcion sys_read original
nread = (*ptr_original_sys_read)(fd, buf, count);


//Quita el límite para leer la memoria del user space

fs = get_fs();
            set_fs(get_ds());
//Oculta la cadena VBOX
ptr = buf;
while ( (ptr = strstr(ptr, "VBOX")) != NULL) 
{
strncpy(ptr, "____", 4);
}
//Pone de nuevo el limite de memoria
            set_fs(fs);


return nread;
}

//Pone en lectura y escritura la página correspondiente a la dirección “addr”

void
 _set_addr_rw(unsigned long addr)
{
unsigned int level;
pte_t *pte = (*ptr_lookup_address)(addr, &level);
pte->pte |= 0x002;
}

//Primera función ejecutada cuando el driver esté cargado

int
 init_module(void)
{
unsigned long long ret;

//Consigue el index de la tabla de llamadas al sistema correspondiente a la función original 

sys_read
NR_sys_read = get_index_syscall((unsigned long *)ptr_original_sys_read);

//Cambia en lectura y escritura la tabla syscall

set_addr_rw((unsigned long)(sys_call_table + 1*NR_sys_read));

//Hookea la función sys_read
*(sys_call_table + 1*NR_sys_read) = new_sys_read;

return 0;
}

El código compilaría un módulo del kernel que podemos instalar con insmod.

Antes de hookear la función “sys_read” del kernel:

Salida del comando cat /proc/scsi/scsi:

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: VBOX HARDDISK model Rev: 1.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: VBOX Model: CD-ROM    Rev: 1.0
  Type:   CD-ROM                           ANSI  SCSI revision: 05

Después de hookear la función “sys_read” del kernel

Salida del comando cat /proc/scsi/scsi:

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: ____ HARDDISK model Rev: 1.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: ____ Model: CD-ROM    Rev: 1.0
  Type:   CD-ROM                           ANSI  SCSI revision: 05


Esto es solo una de las múltiples técnicas que podemos emplear para evadir este tipo de detecciones. Por supuesto, ni es la única técnica que emplean los troyanos para evadir la ejecución sobre una plataforma virtualizada, ni es la única contramedida de las que disponemos.

miércoles, 11 de septiembre de 2013

Crónica de los cursos de seguridad para empresas organizados por Hispasec

Los pasados días 6 y 7 de septiembre se impartieron los cursos ofertados por Hispasec en la primera edición de las jornadas de formación en seguridad informática para empresas. Durante los dos días tuvimos la oportunidad de compartir con los asistentes conocimientos y experiencias que estamos seguros nos enriquecieron personal y profesionalmente a todos. 


Durante el almuerzo de ambos días se propició un interesante diálogo abierto que puso en común los puntos de vista entre el personal de administración de sistemas y profesionales del desarrollo y aquellos que trabajamos día a día en seguridad. Desde Hispasec, tomamos nota de las preocupaciones y carencias que diferentes sectores profesionales tienen en materia de seguridad de sus infraestructuras y desarrollos.



En esta ocasión organizamos dos cursos. "Protección contra el malware en estaciones de trabajo Windows" e "Introducción a la auditoría web". El primero de ellos fue impartido por Sergio de los Santos, profesional que no necesita presentación, antiguo compañero nuestro que recientemente fue nombrado MVP en seguridad. Nombramiento otorgado por Microsoft a unos pocos profesionales que han demostrado una trayectoria profesional digna de reconocimiento y mención.

Dicho curso nació con la meta de proveer de conocimientos sobre el ciclo de vida de malware que afecta a sistemas Windows y lo que es más importante: cómo defenderse eficazmente de él. Durante la jornada, los asistentes y asistentas tuvieron la oportunidad de ver y experimentar los ataques que despliega el malware, su impacto y como exprimir al máximo las capacidades defensivas de los sistemas para evitar o mitigar este tipo de amenazas.

El segundo curso "Introducción a la auditoría web" acercó a nuestros asistentes a la metodología y fases en la búsqueda y explotación de vulnerabilidades en arquitecturas web. El ecosistema de la web, cada vez más nutrido de diversas tecnologías, crece a un ritmo que añade complejidad constantemente a las arquitecturas empleadas para funcionar. La formación en seguridad web constituye un capitulo inevitable y de difícil abordaje debido sobre todo a la comentada diversidad y amplitud de la materia. Dicho curso fue impartido por nuestro manager del departamento de auditoría, David García, al que nos costó esfuerzo sacar del laboratorio de Hispasec donde, junto con su equipo, consiguen exprimir hasta el límite cualquier producto o sistema que caiga en sus manos. 

Desde el equipo de Hispasec queremos agradecer profundamente a todos los asistentes a los cursos su presencia, el habernos enriquecido con sus experiencias, el interés ofrecido y la disposición a compartir conocimiento. Especiales gracias a aquellos que hicieron el grandísimo esfuerzo de viajar hasta Málaga.




Esperamos que los cursos hayan sido del provecho y utilidad para los cuales fueron inspirados, nos consta que ha sido así. Tomamos muy buena nota de todo aquello que nuestros ahora amigos y amigas nos han hecho el favor de comentar para las siguientes ediciones que esperamos volver a organizar.
  

¡Muchas gracias a todos y todas!




El equipo de Hispasec


miércoles, 29 de mayo de 2013

¿Necesitas listas de *?

Seguro que si haces auditorías de seguridad una de las colecciones más preciadas de tu arsenal es la lista de dorks, RFIs, localizaciones del panel de administración, o esos chorizos para hacer escalado de directorios o la de inyecciones SQL. También no faltan listas de combinaciones usuario/password que como dijo Ken Thompson: Cuando dudes, ¡usa la fuerza bruta!

Estas listas son muy útiles para pasarlas a herramientas tipo Burp, Cansina o WFuzz. Incluso un simple (muy simple) script ad-hoc nos puede ayudar para lanzar peticiones y comprobar su resultado:


import sys
import requests

site, payload = (sys.argv[1], sys.argv[2])

slap = ''
try:
    slap = sys.argv[3]
except:
    pass

with open(payload, 'r') as payload:
    for i in payload.readlines():
        req = requests.get(site + i + slap)
        print "%s %s %s" % (req.status_code, len(req.text), req.url)



Una fuente bastante nutrida de este tipo de listas es la base de datos de dorks de exploit-db o las listas del proyecto fuzzdb, aunque este último lleva tiempo sin ser actualizado. Otra fuente de conocimiento son los sitios tipo pastebin. Nunca dejará de sorprender la cantidad de información curiosa (a veces rozando lo bizarro) que la gente deja colgada.


Por ejemplo, sin salirnos de pastebin, una lista para comprobar posibles scripts que pudieran contener una SQLi. Otra por aquí para el mismo cometido. RFIs en formato dorks para Googleo como no, "etc/passwd" que continen nombres de usuario para nuestro diccionario de usernames. Como no, tampoco faltan las lista de passwords procedentes de los ataques, algunos ya históricos.



Es evidente que se trata de información bastante heterogénea y tendríamos que hacerla pasar por un filtro para acoplarla a nuestras listas, el más básico es que las entradas no estén repetidas o que estén ordenadas por porcentaje de éxito encontrado en sucesivos usos. De esta forma no machacamos un objetivo y optimizamos el tiempo de auditoría.

viernes, 24 de mayo de 2013

¿Te estás promocionado en una web porno?


Una de las formas más comunes de conocer de dónde viene el tráfico, es a través de la etiqueta referer en el tráfico HTTP. Este campo muestra cuál fue la página que contenía el enlace hacia la web, y queda registrado en los logs del servidor para poder ser estudiado. 

El estudio de la etiqueta referer puede permitir conocer cuándo se hace "hotlinking" de imágenes o recursos ajenos, o detectar casos de phishing, ataques, etc. Esto es lo que hacemos con uno de nuestros servicios (LSI, Log Security Inspector). Aunque el servicio no se limita al estudio de los referer para detectar casos de phishing, sino que también puede llegar a darnos información de qué clientes de las entidades bancarias están infectados, sin necesidad de instalar nada en ellos, solo estudiando sus logs.

El caso es que durante el estudio rutinario de nuestro servicio, observamos en un referer una (conocida) página de vídeos pornográficos, que llevaba a la raíz de la web del banco. Esto inmediatamente lleva a pensar a que en esa página había un enlace al banco y que alguien llegó a él a través del vídeo de la señorita desnuda.

Habitualmente los bancos se preocupan de dónde aparece su publicidad y qué páginas usan sus servicios, por tanto, podrían pensar que de alguna manera, un enlace a la web principal de su banco se ha alojado en el sitio pornográficos y un usuario ha pinchado en él. Sin embargo, al visitar la página del vídeo, aparecen muchas cosas... pero ninguna referencia en su código por ningún sitio.





La explicación, sin embargo, es sencilla. El referer es falso, y debe haber sido manipulado mientras se ha visitado el frontal del banco. Esta técnica se utiliza para promocionar la web a cualquier precio. Un robot visita páginas con el referer apuntando a la página que se desea promocionar. La esperanza es que los logs acaben indexados por Google de alguna forma, y así aumentar su pagerank. Las páginas que abiertamente publican sus logs, son más apreciadas, pero realmente lo intentan con cualquiera. Es más, la web en concreto, es conocida por explotar vulnerabilides en Java y ejecutar el virus de la policía a través de sus anuncios... por lo que puede ser usado el referer no solo para alzar la web en buscadores, sino para además hacer que algún administrador de logs "pinche" por curiosidad buscando el enlace a su web (que no encontrará). Por tanto, no, la web no necesariamente se está anunciando en páginas porno.

viernes, 19 de abril de 2013

Nuevos juguetes para auditorías WiFi


Acabamos de recibir en nuestro laboratorio un paquetón de juguetes para usar en las auditorías WiFi. Una Pineapple acompañada de una bolsa llena de gadgets. Pineapple es un punto de acceso wifi "militarizado" especializado para su uso en test de penetración, detección de puntos de acceso y valoración de la seguridad de redes inalámbricas.



Está basada en OpenWRT y viene repleta de herramientas como Aircrack-NG, SSL Strip, etc. Además es extensible a través de módulos y tiene una comunidad que va aportando nuevos añadidos o mejoras.

Como referencia en español no deberías perderte la serie de post que Jaime Andrés Restrepo de DragonJar ha escrito sobre "La Piña" donde podrás conocer más sobre este proyecto y la comunidad hispana que se ha creado a su alrededor.

De momento trasladaremos esta nueva joya al arsenal de Hispasec donde la pondremos a prueba en nuestras redes de entrenamiento a ver si le sacamos el jugo. Por cierto, si las combinamos con las Rasperry Pi...

Be seeing you!

lunes, 25 de marzo de 2013

Detalles técnicos que debes contemplar antes de ir a Cuba

Supongo que todos conocemos más o menos cómo es la situación en Cuba. Estados Unidos no permite por ley que ningún ciudadano o empresa gaste un solo dólar en la isla. Ellos lo llaman "embargo", pero en Cuba, se habla de "bloqueo". Además existe cierta carencia de infraestructuras, que se siente muy directamente en el día a día. Después de pasar unos días en la XV Convención Informática 2013 en Cuba, en cuyo contexto se celebró el XI Seminario Iberoamericano de Seguridad en las Tecnologías de la Información, voy a dar algunos consejos personales que he "sufrido" (por no planificar o informarme a tiempo, claro está) para quien se pase por allí. Quizás puedan ser útiles.

Pero sobre todo, quiero dar las gracias a Segurmática. El servicio antivirus cubano, además de por el trato personal, porque aunque dispone de unos recursos limitados, su personal está extremadamente cualificado y me han enseñado mucho. Mi experiencia intercambiando información con ellos ha sido muy enriquecedora, y me ha permitido conocer cómo funcionan y qué técnicas utilizan. Espectacular. Además, no se nos olvide que en Cuba deben implementar herramientas muy sofisticadas en contra de ataques muy directos a sus empresas e instituciones, que en la mayoría de los casos, solo ellos conocen, detectan y remedian.

Como decía, los consejos son:

* La conexión a Internet es, en la mayoría de los casos, muy lenta para nuestros estándares. Es muy extraño que un usuario disponga de Internet en su casa (ni siquiera los profesionales). En las grandes empresas, quizás cuenten con conexiones de 128 kbs para todo el personal. La empresa del país con una de las mejores conexiones, dispone de 2 megas de ancho de banda para todos sus usuarios.

* En los hoteles no es mucho mejor. Debe ser un hotel muy caro para que ofrezca WiFi. La mayoría dan Internet en la habitación por cable, y a una velocidad desesperantemente lenta (y con alta latencia) para lo que podemos estar acostumbrados. Además cara. Unos 8 euros por 24 horas.


* Los enchufes son de 110V. Mira si tu transformador (de cargador de móvil o portátil) acepta el rango 100-220. Si solo es 220, no funcionará. Por supuesto, lleva también adaptador.

* Goolge Apps no funciona en el país. Esto quiere decir que si tu correo usa su infraestructura por detrás, no podrás verlo. Si tienes una cuenta "normal" en Gmail, sí puedes consultar tu email. Seguro que otros muchos servicios tampoco funcionan, pero no los sufrí tan directamente.


* Las tarjetas de crédito americanas no van a ser aceptadas. Olvídate de American Express, Citibank... Sin embargo ING, o bancos españoles sí. Pero suelen pedir una compra alta en las tiendas para poder pagar con tarjeta.

* Virtualmente, no existe 3G en Cuba. Si haces roaming, prepárate para un buen susto en la factura. Recibir llamadas suele costarte a ti (el que las recibes) unos 3 euros el minuto. Enviarlas, entre 50 céntimos y un euro el minuto. El SMS un euro, y los datos... sobre 12 euros el megabyte.

Otros consejos menos técnicos:

* Reserva 25 CUC en metálico (peso cubano convertible, la moneda para el turista que comparten junto con el peso "normal" para los propios cubanos) para pagar si quieres salir del aeropuerto. También deberás pagar una visa (que cuesta unos 40-50 euros) en España antes de ir, y un seguro médico (aunque parece ser obligatorio, no me pidieron los papeles en ningún momento) de unos 10-20 euros.

* No bebas agua del grifo bajo ningún concepto.

* El cambio puedes hacerlo en cualquier parte, apenas hay diferencias entre los precios. 1 euro = 1,25 CUC, sin comisiones.

* Las bebidas en bares son a precios europeos. Sin embargo, el ron puede estar en unos 6 euros la botella que aquí no baja de 17. También hay poca diferencia de precio, aunque sea en sitios muy turísticos. Igualmente el tabaco en general es muy barato en comparación.

* En el aeropuerto de Cuba, no dejan pasar mecheros a la zona de embarque (!).

Son solo algunos consejos muy personales de mi estancia allí. Es un sitio que realmente merece la pena y donde me han tratado muy bien. Si tienes la amarga sensación de que, allá donde viajes, todo el paisaje urbano está contaminado con una homogeneidad "globalizada" donde nunca falta el McDonalds, la tienda Zara, y el Apple Store... en Cuba encontrarás algo diferente. Y la gente no va mirando su smartphone por la calle o en reuniones de más de dos. Hablan entre ellos y se miran a la cara. Y luego bailan. Todos bailan y cantan de maravilla. Muy recomendable.