Virus Social

Hola querido lector.

Este post va a tratar sobre el famoso virus que se ha extendido a través de las redes sociales Facebook y MySpace. Gusanos, troyanos, virus, malware en general sabemos que todos los días aparecen infinidad de ellos, y de sobra son conocidas las medidas de sentido común para evitar en lo posible ser infectado por ellos.

Lo novedoso, o no tanto, es cambiar la forma de expansión de este malware, por un lado todos conocemos la peligrosidad de ciertos adjuntos en el correo electrónico, ¿quién no recuerda el "I love you"?, también sabemos de lo peligroso que puede ser navegar por ciertas URL's sospechosas o comprometidas - sin conocimiento del propietario de los contenidos- y que aprovechan todas las vulnerabilidades posibles para infectar a usuarios, desde las del propio sistema hasta al desconocimiento del propio usuario.

Estos días se han utilizado las famosas redes sociales y su enorme repercusión y difusión, y aunque ya se ha escrito mucho sobre él, más vale comentarlo por si alguien no se había enterado todavía.

Un ejemplo de mensaje enviado es este (¡recordad, no seguir el enlace!!!!:)

Asunto: tua foto?!!

"es este tu foto?!

http://www.facebook.com/l/6ffa7;readinfo163178191351372640.sendzsafez.info/gp735tq/

Ten cuidado!!!"

Este malware es: Koobface, según comentan en esta fuente. Su funcionamiento es bastante sencillo:

1. El usuario pincha en el enlace del vídeo
2. Aparece un pop-up requiriendo que el usuario actualice el Adobe Flash player
3. El usuario acepta la instalación del malware y queda infectado.

Para solucionarlo se debería tener el antivirus actualizado, existen foros donde además de las explicaciones aparecen las trazas de un antivirus que ayudan a identificar qué ficheros y entradas de registro se han visto comprometidas, como este ejemplo extraído de este enlace:

Malwarebytes' Anti-Malware 1.40

Versión de la Base de Datos: 2551

Windows 5.1.2600 Service Pack 2 (Safe Mode)

03/09/2009 0:27:50

mbam-log-2009-09-03 (00-27-01).txt

Tipo de examen : Examen Completo (C:\|)

Objetos examinados: 158472

Tiempo transcurrido: 16 minute(s), 55 second(s)

Procesos en Memoria Infectados: 0

Módulos en Memoria Infectados: 0

Claves del Registro Infectadas: 5

Valores del Registro Infectados: 1

Elementos de Datos del Registro Infectados: 0

Carpetas Infectadas: 1

Ficheros Infectados: 10

Procesos en Memoria Infectados:

(No se han detectado elementos maliciosos)

Módulos en Memoria Infectados:

(No se han detectado elementos maliciosos)

Claves del Registro Infectadas:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{x9obc5c0-4fcb-11cf-aax5-81cx1c635612} (Generic.Bot.H) -> No action taken.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curre ntVersion\Ext\Stats\{76086c05-4d0a-4b92-9219-2e3fe8c553f9} (Trojan.BHO) -> No action taken.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer\Browser Helper Objects\{76086c05-4d0a-4b92-9219-2e3fe8c553f9} (Trojan.BHO) -> No action taken.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Bind (Malware.Trace) -> No action taken.

HKEY_CURRENT_USER\SOFTWARE\advantage (Adware.Vomba) -> No action taken.

Valores del Registro Infectados:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curre ntVersion\Run\advantage (Adware.Agent) -> No action taken.

Elementos de Datos del Registro Infectados:

(No se han detectado elementos maliciosos)

Carpetas Infectadas:

C:\Documents and Settings\-Carlos-\Datos de programa\advantage (Adware.Vomba) -> No action taken.

Ficheros Infectados:

C:\Documents and Settings\-Carlos-\Datos de programa\advantage\AdVantage.exe (Adware.Agent) -> No action taken.

C:\Documents and Settings\-Carlos-\Datos de programa\advantage\AdVUninst.exe (Adware.Agent) -> No action taken.

C:\Program Files\Lineage II\system\fire.dll (Malware.Packer.T) -> No action taken.

C:\Documents and Settings\-Carlos-\Datos de programa\advantage\about_AdVantage.mht (Adware.Vomba) -> No action taken.

C:\Documents and Settings\-Carlos-\Datos de programa\advantage\advantage.cfg (Adware.Vomba) -> No action taken.

C:\Documents and Settings\-Carlos-\Datos de programa\advantage\advantage.mht (Adware.Vomba) -> No action taken.

C:\WINDOWS\freddy61.exe (Worm.KoobFace) -> No action taken.

C:\Documents and Settings\-Carlos-\Menú Inicio\Programas\IE AntiVirus 3.3.lnk (Rogue.IEAntiVirus) -> No action taken.

C:\WINDOWS\pp11.exe (Worm.KoobFace) -> No action taken.

C:\WINDOWS\ld14.exe (Worm.KoobFace) -> No action taken.

En las redes sociales también se han hecho eco de la noticia y de la repercusión y se han creado grupos de alerta y concienciación (algunos más graciosos que otros) para que el usuario de estas redes no se vea perjudicado. Como ejemplo estos dos enlaces:

Grupo de facebook

Foro de Facebook

Como siempre, tened cuidado, sed cuidadosos y no confiéis en exceso, vamos, las normas de siempre, porque las mafias siempre buscarán nuevos métodos de propagar su malware al mayor número de usuarios.

José María Arce Guillén

S21sec e-crime

Segunda jornada S4 de Digital Bond

Siguiendo con el post de la semana pasada, el jueves 21 asistimos a la segunda jornada de la S4:

• Jake BRodsky de WSSC hizo una exposición sobre el uso de jammers para impedir las comunicaciones inalámbricas. El año pasado ya realizó una presentación sobre la vulnerabilidad de los dispositivos inalámbricos. Supuestamente, los nuevos dispositivos basados en ISA 100 no son vulnerables a los ataques que había presentado, así que para este año había repetido las pruebas contra equipos Nivis ISA 100, demostrando que ISA 100 no es la solución y que los problemas siguen ahí.
• Shailendra Fuloria de la Universidad de Cambridge presento los trabajos realizados por su grupo de investigación en el área de los mensajes multicast en la comunicación de subestaciones.
• A continuación se proponía un debate sobre si las tecnologías wireless pueden ser utilizadas con seguridad y confianza. Hubo una primera exposición de argumentos a favor (la tecnología es suficientemente conocida y probada y puede cumplir con los objetivos, aunque haya aspectos que mejorar) y en contra (limitar las tecnologías inalámbricas a tareas secundarias de monitorización)
• Bryan Singer de Kenexis presentó sus propuestas de supervisión del funcionamiento de los equipos que componen la red de control y la vinculación/análisis de la operación del sistema de supervisión con las condiciones del proceso a controlar.
• Ernest Rakaczky de Invensys Process System defendió la utilización de HIPS en sistemas de control distribuidos y explicó su propuesta de uso de ePO de MacAfee.
• La última presentación la realizó Jason Holcomb de Digital Bond, explicando una propuesta de medida de seguridad de softwares SCADA. El objetivo final es obtener una puntuación de cada software haciendo una suma ponderada de diferentes características (por ejemplo: puertos abiertos, servicios con privilegios, conexiones entre zona segura y no segura...). La pena fue que los datos de aplicación del método eran ficticios y entre la audiencia se esperaba ver alguna marca conocida. La gran amenaza que inquietaba en el chat del evento es si un fabricante se desarrollase su producto para obtener mejores puntuaciones de seguridad y perdiese funcionalidades para el integrador y el usuario final.

Al final, dos ideas resumen mis impresiones de la segunda jornada:

• hay mucho interés en utilizar tecnología inalámbrica, pero muchos no se lanzan hasta que no haya una base instalada que proporcione datos en casos reales
• se espera mucho más de los fabricantes de software, que la seguridad sea un elemento principal y que no se descargue la responsabilidad en el acceso a las redes y equipos y en software de terceros

Diego López
S21Sec Labs

Cuidado con los datos personales

Como ya es sabido y comentado numerosas veces en este blog, la principal motivación de los atacantes, hoy en día, es la captura de datos personales de todo tipo, desde datos sobre las aficiones y afinidades de una persona, hasta los datos bancarios mediante los cuales se puede realizar alguna que otra transferencia bancaria.

Respecto a los datos bancarios, es sabido por numerosas empresas de seguridad que estos aumentan año a año. Este aumento esta relacionado con el aumento en sofisticación de las técnicas malware, como puede ser el caso de las nuevas funcionalidades de las botnets para enviar spam, inyectar código HTML en el navegador de la víctima...

Aunque también esta relacionado con las vulnerabilidades surgidas en alguno de los algoritmos más usados para la generación de contraseñas, o en vulnerabilidades en la implantación de algún protocolo de transferencia de datos de carácter personal.

Es el caso del protocolo 3DS basado en la tecnología single sign-on. Este protocolo es muy usado por la banca para la realización de transferencias de dinero. Según el articulo titulado, “Verified by Visa and MasterCard SecureCode: or, How to Design Authentication” publicado por la Universidad de Cambridge (UK), la principal vulnerabilidad de dicho protocolo radica en la introducción de una contraseña para autenticarnos, la forma de activación del servicio vía on-line el uso de i-frames para preguntar por la contraseña, etc.

La mayoría de las trabas de dicho algoritmo están estrechamente relacionadas con el usuario y los datos que éste introduce en los navegadores. Por esta razón y como conclusión mencionar que para estar más seguros de no ser víctimas del fraude electrónico se debe mantener, por un lado la seguridad local activada y actualizada. Y, por otro lado, debemos estar seguros de que los datos de carácter personal introducidos en el navegador van a ser utilizadas por entidades de nuestra confianza pudiendo corroborar su identidad verificando su certificado.

Aitor Corchero Rodríguez

S21sec labs

Lo que mal empieza...

En el mundo de la seguridad, al igual que en todas las áreas, el hecho de "dar una pensada" a un tema antes de ponernos a programar como locos es muy importante. De hecho, en el ámbito de la seguridad es aún más importante, porque siempre hay alguien dispuesto a buscar las cosquillas a lo que hagas.

Cuando se trata de una aplicación crítica, comercial, o cualquier tema medianamente serio, esto pasa a ser muy importante, puesto que un error de diseño puede ser más grave que cualquier error "técnico" más complejo.

Veamos dos ejemplos ilustrativos:

• Una marca comercial (llamémosla X) quiere proteger sus aplicaciones por tiempo de ejecución, y para ello añade una capa de protección en forma de empaquetado con protección de tiempo. Para ello utiliza un programa base que llevará embebido el programa protegido, el cual desempaquetará en tiempo de ejecución, lanzará, matará y eliminará de disco al terminar la ejecución.

Sí, ¡lo elimina de disco! Todas estas aplicaciones eran vulnerables a un copy&paste mientras estaban siendo ejecutadas.

Ejemplo de la creación de un fichero temporal

• Otro ejemplo, un poco más sutil, nos lo encontramos en la banca electrónica, en la que utilizamos una tarjeta de coordenadas, de modo que un troyano debe poseer estas claves para poder operar. El ataque más común (la petición de las mismas) es demasiado llamativo. Ahora bien, ¿qué pasa si alguien introduce mal una coordenada? ¿se ha equivocado? ¿tal vez no es el cliente quien trata de operar? La solución más sencilla se trata de volver a pedirla, hasta un máximo de 3 veces para evitar un ataque de fuerza bruta.

Ante esto, nuestros amigos del troyano InfoStealer, muy avispados ellos, utilizan una técnica mucho más sutil, que se trata de obtener la coordenada, y de aquí en adelante mostrar un mensaje de error (sistema en mantenimiento, etc.) al usuario. De esta manera, ellos tienen una ventana de tiempo para entrar en al cuenta, y si ante un nuevo inicio de sesión se mantiene la petición de coordenada, habrán reducido la tarjeta de coordenadas a un simple PIN.

Lo dicho, a tomarse un café mirando al infinito antes de escribir una sola línea de código ;)

Mikel Gastesi

S21sec e-ecrime

CONFERENCIAS EN FEBRERO

El próximo mes vamos a participar en varios eventos de seguridad.

El 2 de febrero Leonardo Nve, Senior Securty Auditor, impartirá la ponencia "Playing in a Satellite Environment 1.2" en Black Hat DC 2010, en Arlington, Virginia, USA. Podéis consultar toda la información referente a las inscripciones aquí.

Una semana más tarde, estaremos en León, en el evento Trust in the Information Society, que se celebrará los días 10 y 11 de febrero. Aquí Daniel Brett, International Account Manager, participará en la sesión "International Cooperation on Trust and Security Research".

Además, el 18 y 19 de febrero, estaremos patrocinando el I Encuentro Internacional de Protección de Infraestructuras Críticas de Información, organizado por el CNPIC (Centro Nacional de Protección de Infraestructuras Críticas), del Ministerio del Interior, en el que moderaremos el panel "Visión de los Gestores IC".

Si tenéis pensado asistir a alguno de estos eventos, ¡no dudéis en saludarnos!

No solo de Webs vive un “Blind SQL Injection”

Antes de nada, aunque seguro que por todos es bien conocido… ¿Qué es un Blind SQL Injection?

http://es.wikipedia.org/wiki/Blind_SQL_injection

“Ataque a ciegas de inyección SQL, en inglés, Blind SQL injection es una técnica de ataque que utiliza inyección SQL cuando una página web por motivos de seguridad no muestra mensajes de error de la base de datos al no haber un resultado correcto mostrándose siempre el mismo contenido (solo habrá respuesta si el resultado es correcto).”

http://en.wikipedia.org/wiki/SQL_injection#Blind_SQL_injection

“Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. …“

Como se puede apreciar en las anteriores definiciones, este ataque es comúnmente asociado a aplicaciones Webs, y después de tantos años debería tenerse muy presente en cualquier desarrollo Web, o no:

h· http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

¿Pero que ocurre en las aplicaciones de escritorio? Técnicamente, nada evita que también afecte a este tipo de software, al fin y al cabo, muchas de estas aplicaciones también realizan consultas a bases de datos y contienen entradas de datos.

Y después de este preámbulo… Hace algún tiempo realizamos una auditoría a una aplicación cliente-servidor, uno de los fallos detectados fue un Blind SQL Injection. Para entrar un poco en materia os cuento a grandes rasgos como funcionaba la aplicación:

· Para iniciar sesión, la autenticación se realizaba contra un servidor remoto en un puerto X.

· Una vez dentro del aplicativo, este obtenía los datos desde el mismo servidor remoto pero en un puerto diferente.

· La comunicación en ambos casos era parcialmente cifrada. Y remarco parcialmente porque armados con un “sniffer” se observaba claramente que aunque la mayoría de los datos se intercambiaban de manera cifrada, sorprendentemente las consultas SQL aparecían en claro.

Como auditores curiosos que somos, la primera idea que nos vino a la mente fue modificar esa consulta a ver que ocurría, pero al permanecer todo el tráfico cifrado solo veíamos caracteres extraños y la aplicación, ya poco intuitiva de por si, tampoco experimentó ningún cambio significativo. La tentación fue ser expeditivos y escribir shutdown;-- a ver que ocurría. Y así fue, previo permiso con el interlocutor del proyecto por supuesto. Evidentemente, tiramos la base de datos, y nos quedamos sin aplicación. A pesar de las evidencias, el cliente o el administrador o el responsable de la aplicación negó los hechos y asocio la caída o otros sucesos paranormales argumentando que eso que le comentábamos era imposible.

De modo que, nos decidimos a obtener algún campo de la base de datos que hiciera imposible negar la evidencia. Después de varios intentos infructuosos inyectando UNIONs y demás con fin de observar datos en la propia aplicación, se nos ocurrió intentar lo que comúnmente hacemos en aplicaciones Web en estos casos, un Blind SQL injection.

En el análisis previo para realizar el Blind SQL nos surgieron las siguientes evidencias:

· El puerto de datos estaba abierto para cualquiera y la autenticación previa no se tenía presente en ningún caso.

· El cifrado era el mismo conexión tras conexión. De modo que, entre sucesivas consultas los paquetes de datos aunque cifrados eran los mismos para una inyección SQL positiva y negativa.

Armados con estas evidencias, solo quedaba modificar el habitual script de Blind SQL injection por otro que utilizara conexiones TCP en lugar de peticiones HTTP y obtener datos aleatorios de la base de datos. El video que hicimos para la presentación con las letras apareciendo poco a poco y mostrando varios datos de la BBDD fue todo un éxito. Aquí os dejo el código en python que nos sirvió para confirmar lo expuesto en al análisis inicial anterior:

#! /usr/bin/env python

import struct,os,sys

import time

from select import select

from socket import *

import string

srv_port = *

srv_ip = "*.*.*.*"

paquetes = [

"W1W1W1\xe9\x01\x00\x00\x00\x00\x00\x00CUSTOMSQL1Select field1, Field2, sum(Field3) / 100 as field4, sum(field5) / 100 as field6, sum(Field7) / 100 as field8, sum(field9) / 100 as earnsvaladj from table1.[dbo].[field10] where field1 = 'STRING1' and type <> 'I' and Type <> 'S' and Field2 between '19871031' and '20081031' and 1=1 group by field1, Field2, Field11 ",

"W1W1W1\xe9\x01\x00\x00\x00\x00\x00\x00CUSTOMSQL1Select field1, Field2, sum(Field3) / 100 as field4, sum(field5) / 100 as field6, sum(Field7) / 100 as field8, sum(field9) / 100 as earnsvaladj from table1.[dbo].[field10] where field1 = 'STRING1' and type <> 'I' and Type <> 'S' and Field2 between '19871031' and '20081031' and 1=2 group by field1, Field2, Field11 "

]

recibido_positivo = '\x57\x31\x5A\x31\x5A...’

recibido_negativo = 'W1Z1Z14\x00\x00\x00\x19…'

s = socket( )

s.connect((srv_ip,srv_port))

for q in paquetes:

print "Sending query...\n"

s.send(q)

l = s.recv(4096)

if l == recibido_negativo:

print "\tReceived response: False\n"

elif l == recibido_positivo:

print "\tReceived response: True\n"

else:

print "Unknown?\nn"

Una de las recomendaciones que hicimos al cliente, a parte de evidentemente solucionar la inyección SQL, fue cifrar todo el paquete de datos. Una vez corregidas las vulnerabilidades, en la revisión posterior verificamos que efectivamente en ese momento todo el paquete de datos se transmitía de forma cifrada lo que dificultaba en gran medida inyectar sentencias SQL a gusto del atacante.

Pero aún así, ejecutando de nuevo el anterior script sin cambio alguno, el Blind SQL injection seguía ahí. Suponemos que por temas de compatibilidad la parte servidora seguía aceptando el formato de datos anterior y lo de solucionar la inyección SQL quedo en saco roto.

Javier Mendez,

Depto. Auditoría, S21sec

Si no encuentras trabajo, es porque no quieres…

A causa de los tiempos de crisis que corren, más de uno, desgraciadamente, ha perdido su trabajo. Se trata de una situación difícil, y la necesidad de volver a encontrar una ocupación, muchas veces nos puede llevar a aceptar cualquier tipo de oferta.

Es dentro de este marco, donde últimamente se están produciendo campañas de spam masivas, en las que se ofertan puestos de trabajo un tanto peculiares.

El patrón, generalmente, es el mismo; se busca persona para trabajar desde casa unas 4 horas al día, con una gran remuneración. Su único cometido es realizar transacciones bancarias, y los ofertantes, suelen denominar al puesto vacante como “agente financiero”.

Pues bien, mucho de vosotros ya sabréis que este tipo de ofertas de trabajo son totalmente fraudulentas. En realidad, estas transferencias buscan blanquear dinero procedente del phishing, con lo que, la persona que ha aceptado el puesto de trabajo, está incurriendo en un grave delito. Así, cuando la persona a la que se está robando dinero se dé cuenta y denuncie a las autoridades el robo, la cuenta bancaria del “agente financiero” será bloqueada, y se le exigirá la devolución del capital supuestamente robado. Es en ese momento cuando el “agente financiero” será ascendido a “cabeza de turco” dentro de la organización, un puesto de gran responsabilidad.

Últimamente, la evolución de este tipo de correos electrónicos ha sido bastante notable. Si bien en un principio estos solían ser correos en texto plano, muchas veces muy mal traducidos al castellano, cada vez son mensajes mejor presentados, los cuales suplantan sitios web de búsqueda de empleo, o incluso organizaciones benéficas.

Para muestra, una supuesta oferta de trabajo del sitio web Monster (en el que ni si quiera estoy dado de alta) que me llegó el otro día :

 

 

Así que ya sabéis, cuidado con este tipo de correos, ¡pueden meteros en un lío muy gordo!

 

Asier Marruedo

S21sec e-crime

S4

Como todos sabéis, los días 20 y 21 de este mes se está celebrando la S4 de Digital Bond a la que el grupo SCADA asistimos. En esta conferencia se suelen tratar temas relacionados con la seguridad de los sistemas de control industrial (SCADA, DCS...), en la que investigadores y trabajadores de empresas muy punteras en el sector tratan aspectos de seguridad muy concretos.

Ayer presenciamos las siguientes 5 exposiciones:

1. La exposición de Daniel Peck de Digital Bond trataba sobre posibles vulnerabilidades en sistemas operativos usados en dispositivos de campo de los sistemas de control. Dió varios ejemplos muy sencillos sobre alguna vulnerabilidad en Windows y Unix, pero no ahondó demasiado en el tema (demasiadas generalidades).
2. Esta exposición de Andrew Ginter de Industrial Defender se centraba en el análisis de soluciones de seguridad de lista blanca y su aplicación en sistemas de control. Trataba la posibilidad de tener listas blancas, así como la de tener antivirus, y cuáles eran las ventajas y desventajas de cada uno y si te daban la posibilidad de no tener que parchear (se abordará en otro post).
3. Resultó curioso escuchar Pascal Sitbon de la EDF como contaba la posibilidad de intercambiar información de forma segura, desde una zona poco segura a un sistema de control en una infraestructura crítica. Consistía en un aparato que tenía una entrada y salida USB y que analizaba los ficheros de texto en busca de carácteres ASCII (pero había ciertos caracteres que no se aceptaban y los cambiaba como método de prevención para algún ejecutable) y los ficheros ejecutables directamente los filtraba.
4. La siguiente exposición de Hadeli Hadeli de ABB se trataba la detección de de anomalías avanzadas y una configuración de seguridad fiable debido al determinismo de los sistemas de control. Hablaba sobre un logger con funciones de firewall que tenía la capacidad de esperar cierta información que si no le llegaba hacía saltar una alerta.
5. Kun Sun de Intelligent Automation habló de métodos de mitigación de ataques de denegación de servicio en redes wireless (métodos matemáticos con polinomios un tanto complicados).

En el próximo post se comentará lo sucedido en el segundo día de la conferencia.


Iker Berriozabal
S21sec labs

BlackBerry y entornos BES: esos grandes desconocidos (parte I)

Atrás quedaron los tiempos en los que los teléfonos móviles se usaban únicamente para realizar y recibir llamadas/SMS’s. Hoy en día, nos basta con mirar a nuestro alrededor para ser conscientes de que nos encontramos en una sociedad totalmente vinculada a este tipo de dispositivos. Si nos fijamos bien, difícilmente podrás tener a algún amigo o conocido que no disponga de un teléfono móvil. Cada día proliferan más los móviles que permiten mantener conexión constante a Internet, mediante las tan aclamadas tarifas planas que ofertan todas las operadoras móviles. Dispositivos como la BlackBerry, los SmartPhones y el IPhone han marcado un antes y un después.

Centrándonos en el mundo empresarial, este tipo de dispositivos son de uso obligado. No encontraremos hoy en día un solo comercial que no lleve un móvil pegado a su bolsillo, así como tampoco encontraremos a ninguna empresa vinculada a las tecnologías de la información que no haga uso masivo del correo electrónico. Y como no hay dos sin tres, dentro de poco tiempo (prácticamente ya), nos encontraremos que la mayoría del mundo que hace uso del correo electrónico lo hará directamente desde su dispositivo móvil. Y eso, a día de hoy, y de forma mayoritariamente popular, apunta hacia un nombre: B.E.S (BlackBerry Enterprise Server).

Cada vez son más las empresas que implementan una solución de mensajería electrónica de este tipo. Ello les permite gestionar de forma interna y centralizada todo el correo y contenido que se envía a los distintos dispositivos móviles (en nuestro caso nos centraremos en las BlackBerry). Realmente este mismo servicio lo ofertan también la mayoría de operadores de telefonía móvil, haciéndose ellas cargo de todo el sistema de forma externa. Para nuestro caso, nos centraremos en aquellas instalaciones que se encuentran implementadas directamente dentro de las empresas.

La típica instalación de un sistema de este tipo, se basa en instalar un servidor intermedio BES que sea capaz de gestionar los dispositivos móviles, y actúe de enlace entre estos y el sistema de correo principal. Posteriormente, el servidor BES redireccionará todos los correos electrónicos a las cuentas que se hayan preestablecido para cada uno de los dispositivos.

Lo que la mayoría de gente desconoce, es que la instalación de estos sistemas conlleva una serie de riesgos inherentes a la propia plataforma, que son necesarios gestionar, para mantener un nivel de seguridad adecuado. El principal de estos riesgos, ( aparte de todo riesgo específico del propio terminal), es que cada BlackBerry pasa a ser un dispositivo integrado en la propia Red Corporativa de la empresa, tal y como lo pudiera ser un servidor interno, una estación de usuario normal, un servidor de BB.DD, etc.

A día de hoy, se conocen técnicas y métodos que permiten manipular el software del dispositivo móvil, para usar el servidor B.E.S al que se encuentra enlazado como proxy inverso, de manera que desde la propia terminal, se puedan establecer conexiones internas hacia los servicios de la LAN.

Por poner un ejemplo, desde un dispositivo BlackBerry que no disponga de un servidor BES adecuadamente configurado a nivel de políticas y restricciones de terminales, es posible acceder a los servidores Web de la Intranet de la empresa, así como a los servicios SSH, etc., que se encuentren publicados internamente. Y todo esto con la comodidad de poder estar realizándolo a cientos de kilómetros de distancia. Esta situación, genera un escenario totalmente nuevo y atípico, que un atacante que haya robado uno de estos dispositivos puede usar para realizar acciones no controladas sobre la red interna de la empresa a la que corresponda dicho dispositivo.

Si esta situación se combina con la posibilidad de usar el dispositivo conectado a un sistema portátil, se abre una ventana de posibilidades enorme, con la que se cuenta con una conexión directa a la red Interna de la empresa, mediante el uso de la red GPRS/3G. De aquí en adelante, todo depende de la habilidad del atacante y la combinación de políticas, procedimientos y mecanismos de seguridad que se hayan implementado en la empresa atacada, para poder acceder a los diversos sistemas internos de la red.

Desde el departamento de auditoría de S21sec, queremos lanzar un mensaje de alerta y concienciación a las organizaciones, debido principalmente, a que estas plataformas incorrectamente configuradas son una puerta de entrada directa al resto de las infraestructuras de la empresa.

En la segunda parte de este artículo, hablaremos de riesgos añadidos a los propios dispositivos BlackBerry, así como la importancia de mantener una política adecuada para estos y sus servicios.

Oscar Romero

S21sec, Dept. Auditoría

Ingeniería social en YouTube

Un día buscando el trailer de una pelí en YouTube, encontré resultados muy raros. La película justo acababa de llegar a los cines, pero aparentemente ya habían subido partes de la misma a YouTube. Esto me llamó la atención, así que siguiendo el enlace, en lugar de un vídeo aparecía una pantalla con el mensaje "No supe subir la película, la borran inmediatamente! Para verla sigue el enlace a la derecha!"


Eso era muy sospechoso. Tampoco había ningún comentario sobre la película, dado que el usuario que había subido el vídeo no los permitía. No hace falta decir que siguiendo el nuevo enlace parece un reproductor falso que instala un troyano en el equipo.


En el día de la investigación, el vídeo en cuestión tenía poco más de
10.000 visitantes. Por supuesto no todo el mundo picaría, pero
suponiendo que sólo una de cada veinte persona ejecute el troyano, ya puede resultar en 500 máquinas infectadas...

Jozsef Gegeny
S21sec e-crime

GPU vs CPU para análisis de contraseñas

El análisis de contraseñas es un proceso de los denominados “embarrassingly parallel workload (1)”, donde se puede dividir el problema inicial en subtareas totalmente independientes entre sí de forma trivial. En este caso, el análisis de una contraseña se puede dividir en tantos subprocesos como claves se quieran analizar.

La mayoría de los algoritmos de cifrado utilizados actualmente realizan operaciones simples para crear un hash a partir de una contraseña (operaciones sobre tipo de datos enteros que normalmente se ejecutan en la ALU (unidad aritmético lógica (2)) de los procesadores).

Además, las GPUs han pasado de sólo poder ejecutar tareas muy específicas a poder ejecutar tareas más generales. El cambio más notable se produjo con la introducción del hardware DX10 donde las unidades de geometría, procesado de píxeles y de vértices se cambiaron por los denominados “Unified Shaders (3)” y por un sistema de control de flujo más flexible.

Rendimiento teórico CPU

Los procesadores más rápidos disponibles actualmente en equipos de usuario son los Intel Core i7. Estos procesadores pueden ejecutar hasta 3 operaciones en la ALU por ciclo de reloj. Además, para maximizar el rendimiento es necesario utilizar las extensiones SSE y así poder utilizar los registros de 128bit divididos en 4 operandos de 32bit. De pico pueden ejecutar hasta 12 instrucciones / ciclo de reloj por core. En un quad core serían 48 instrucciones por ciclo.

Rendimiento teórico GPU

La GPU actual más rápida para análisis de contraseñas es el chip RV870 de las ATI 5970 (2 GPU) y ATI 5870 (1 GPU).

Esta GPU consta de 20 motores SIMD, cada motor tiene 16 procesadores y cada procesador tiene 5 stream cores. Cada stream core puede ejecutar una instrucción por ciclo de reloj con lo que el pico máximo teórico sería de 1600 instrucciones por ciclo de reloj (4).

Rendimiento en real life.

Existen muchos programas de análisis de contraseñas para CPU. Los hay que soportan muchos algoritmos diferentes (John the Ripper + Jumbo Patch, Cain, etc.), los hay que se especializan en algoritmos concretos programándolos de forma más eficiente (BarsWF (5) para MD5, Cacheebr para MSCache (6), etc).

Para la GPU RV870 el mejor programa actual que he visto es el IGHASHGPU (7). Soporta los algoritmos de cifrado siguientes:

• · MD4, MD5, SHA1
• · NTLM
• · MS Cache
• · MySQL5
• · MS SQL
• · vBulletin
• · Invision Power Board
• · Oracle 11g
• · Alguno más con MD5 anidados con salts

IGHASHGPU no tiene implementada la versión en CPU de los algoritmos de cifrado con lo que para poder comparar la velocidad de análisis hay que hacerlo contra programas diferentes.

Tests de rendimiento

El hardware utilizado para la comparativa de velocidad fue una ATI 5870 a 850MHz para las pruebas de GPU y un Intel Core 2 DUO a 2.0 GHz para las pruebas de CPU.

Rendimiento MD5

JTR 1.7.4 + jumbo patch	BarsWF CPU	IGHASHGPU v0.7bt
4.4M / sec (1 thread)	60M / sec (2 threads)	3245M / sec

Rendimiento SHA1

JTR 1.7.4 + jumbo patch	SHABR 0.2	IGHASHGPU v0.7bt
2903K / sec	25.28M / sec	1368M / sec

Rendimiento MS Cache

JTR 1.7.4 + jumbo patch	CACHEEBR 0.1	IGHASHGPU v0.7bt
4707k / sec	31.3M / sec	1511M / sec

Como puede apreciarse, aquellos algoritmos que pueden ejecutarse de forma eficiente en una GPU ofrecen un rendimiento varias decenas de veces superior al de una CPU debido a la cantidad de ALUs disponibles y que los algoritmos usados son simples, apenas acceden a memoria y no requieren de un sistema de predicción de saltos complejo.

Hay otros algoritmos de cifrado, como DES, que no se ejecutan de forma eficiente en las GPUs actuales con lo que su análisis habrá que seguir dejándolo, por ahora, para las CPUs.

Links relacionados

(1) http://en.wikipedia.org/wiki/Embarrassingly_paralle

(2) http://en.wikipedia.org/wiki/Arithmetic_logic_unit

(3) http://en.wikipedia.org/wiki/Unified_shader_model

(4) http://www.anandtech.com/video/showdoc.aspx?i=3643&p=5

(5) http://3.14.by/en/md5

(6) http://blog.distracted.nl/2009/05/cacheebr-ms-cache-password-brute-forcer.html

(7) http://www.golubev.com/hashgpu.htm

S21sec, Departamento de Auditorías

¡ALARMA! ¡ALARMA! ¡INCIDENTE!

La gestión de incidentes siempre es una tarea compleja, que depende del tipo de incidente que estamos tratando y del personal que se dispone en el momento de la aparición del incidente. Todos sabemos cómo se forman los grupos de gestión de incidentes, la teoría está muy bien, pero falla en un 90% de las veces. Casi siempre el grupo se forma con la gente presente, no es lo mismo detectar el incidente un sábado a las 4 de la mañana con solo el equipo de guardia trabajando, que un martes a las 12 de la mañana cuando está todo el personal operativo. Y lo mejor de todo es esa persona que simplemente pasaba por allí, pero que por circunstancias de la vida tiene que participar también en la resolución del mismo.

Ahora que ya tenemos formado el grupo toca atacar el problema. Un incidente en los sistemas de control no se puede tratar igual que en la red corporativa. En la red corporativa lo que prima es que el problema no se extienda por toda la empresa, por lo que lo usual es aislar el problema, como se consigue esto; muy fácil, desconectamos los equipos infectados de la red. Pero en la red de control lo más importante por encima de todo es la disponibilidad. No podemos desconectar un equipo y quedarnos tan contentos, a lo mejor es el equipo que controla el reactor (vamos a suponer un incidente en una central nuclear) y tenemos un nuevo Chernóbil. Los equipos tienen que seguir operativos realizando su cometido durante el mayor tiempo posible, al menos hasta que dé tiempo a parar otros sistemas que dependan del afectado. Por eso aquí es muy importante el tiempo, para que los daños sean mínimos, y el trabajo de preparación ante incidentes, esto es, equipos de respaldo, copias de seguridad, etc.

El plan de contingencia debe empezar desde el momento de la instalación/implantación. Puede ser tedioso y no utilizarse nunca, pero es importante documentar y registrar la instalación de los equipos (configuración del sistema operativo, instalación software, importación de aplicaciones…), controlando el tiempo que se tarda en tenerlo operativo, de esta forma siempre sabremos el tiempo máximo necesario para recuperarnos de un desastre total (si disponemos del hardware). Algo que parece tan trivial como las copias de seguridad no siempre se hace o se tiene correctamente documentado. Es muy importante tener un control de las copias de seguridad y de los cambios que se producen de unas a otras. Puede que el problema se deba a un cambio por una actualización y con regresar a la versión anterior ya estaría solucionado el incidente.

Tener equipos de respaldo para equipos críticos puede verse como algo inútil y un gasto exagerado (los equipos de control son caros), teniendo en cuenta que “nuestra empresa nunca tiene problemas”, pero todos sabemos que los incidentes aparecen tarde o temprano, y es mejor estar bien cubiertos. Si seguimos con el ejemplo anterior en la central nuclear, un fallo en el programa por una actualización que lo hace incompatible con alguna función se soluciona poniendo el equipo de respaldo con la copia de seguridad sin las actualizaciones, teniendo un tiempo de indisponibilidad mínimo o incluso nulo. Posteriormente ya nos encargaremos de volver a recuperar el equipo afectado por el problema. Si tenemos esto y copias periódicas de los datos, no debe ser mayor problema una caída de los sistemas de control.

Lo que siempre falla después de todo el proceso de resolución de un incidente es la documentación. Como el incidente ya se ha resuelto, el personal que ha estado trabajando en su resolución se vuelve a sus tareas ordinarias y se olvida de redactar los informes sobre la forma de trabajo que se ha llevado a cabo y los pasos que se han seguido para solucionar el problema. En los incidentes se aprende y se solucionan antes si todo queda documentado y se puede revisar, y no dependiendo de la idea brillante de alguna cabeza privilegiada del grupo. Puede que una vez la idea funcione estupendamente, pero puede que la siguiente vez no surja ninguna y se tenga un problema grave de verdad.

Siempre hemos de recordar que un incidente en una red de control puede tener efectos graves sobre el medio ambiente, las personas o las infraestructuras, y por tanto han de tenerse muy en cuenta y ser conscientes de su criticidad.

Jairo Alonso
S21sec Labs

Factorizado RSA-768

Hace tiempo que hablamos en un post anterior sobre claves criptográficas AES y RSA y el tiempo que llevaría romper diferentes claves. Con la llegada del nuevo año, también nos ha llegado una nueva noticia referente a este tema. Un equipo internacional de científicos del EPFL (Suiza), INRIA (Francia), NTT (Japón), CWI (Holanda) y la Universidad de Bonn (Alemania) han conseguido factorizar un número de 768 bits (232 dígitos), el conocido como RSA-768 del RSA Challenge. Pese a que este reto lleva años inactivo, se siguen dedicando esfuerzos de investigadores y medios de computación a estas tareas. El pasado récord se consiguió en Mayo de 2009 factorizando en RSA-663. Para la factorización del RSA-768 se han utilizado más de de dos años de cómputo en varios cientos de CPUs lo que equivale a más de 1500 años de un solo procesador.

El hecho que se haya factorizado el RSA-768 no quiere decir que las claves RSA no sirvan, sino que, si nosotros decidimos proteger una información con RSA-768, alguien podría acceder de manera ilícita a esa información en el plazo de tiempo que ha tardado el experimento (o incluso en menos si se cuenta con una mayor infraestructura de supercomputación). Por tanto, si queremos proteger adecuadamente la información sería aconsejable utilizar claves de cifrado más largas. De forma similar, los autores del artículo aventuran el factorizar una clave RSA-1024 es al rededor de mil veces más difícil que la RSA-768, pero seguramente estas claves RSA-1024 podrían ser factorizadas dentro de la próxima década si se dedican esfuerzos tales como los dedicados para romper RSA-768. Por tanto, si queremos proteger información relevante con RSA, sería lógico pensar en utilizar claves RSA-2048. Aunque, como hemos dicho otras veces, seguramente estas claves también serán comprometidas en algún momento, todo es cuestión de tiempo y de si el descubrir la información cifrada vale todos los esfuerzos a dedicar.

Guzmán Santafé
S21sec labs

Nuevas modas, viejos trucos: Google Nexus One

Que la gente dedicada al fraude online aproveche las modas que aparecen en Internet no es nuevo. Pero este caso es singular.

Recientemente Google ha lanzado "Nexus One", un teléfono creado por el propio Google y que solamente comercializa a través de su página Web. A día de hoy, solo es posible adquirir el teléfono móvil desde determinados países. Si accedemos a la Web del teléfono desde España nos encontramos el siguiente botón.



Pero si uno es un poco cabezota y no se conforma con la negativa como respuesta, puede intentar querer averiguar si es posible comprar el teléfono móvil de otro modo. Por ejemplo haciendo la búsqueda "buy nexus one".



La pequeña sorpresa viene cuando en una flamante quinta posición de tan fácil búsqueda, encontramos un enlace que nos lleva a lo siguiente.



Si analizamos en binario que nos manda con Virustotal nos encontramos que este ha sido subido hoy mismo por primera vez (12 de Enero de 2010) aproximadamente 2 horas antes de la redacción de este artículo. Así mismo, es detectado solamente por 8 de los 41 motores de antivirus como troyano, sospechoso o similar.

Esto nos debe hacer reflexionar acerca de la infraestructura que tiene el mundo del fraude online, que es capaz de colocar una página fraudulenta en la quinta posición del propio Google, usando como reclamo para el fraude el teléfono móvil del mismo Google. Incluso supera a la propia página oficial del teléfono en el ranking de esa búsqueda.



Update 13 de Enero de 2010, 16:49:

En este mismo momento, las cuatro primeras entradas de Google realizando la búsqueda "buy nexus one" son enlaces a copias de la misma página fraudulenta antes comentada.



Jose Alemán
S21sec labs

10 usos fraudulentos de twitter

Al hilo de la entrada top 10 de noticias de seguridad en 2009 de sitios sociales. Twitter, con más de 44 millones de usuarios únicos es un jugoso canal donde convive todo un ecosistema de individuos y organizaciones dedicadas al fraude online.

Creemos que es de interés resaltar algunos de los usos fraudulentos de twitter:

1) Phishing en twitter: El phishing no solo tiene como objetivo a los servicios de banca y de pago como paypal. Cualquier servicio popular es objeto de esta amenaza, no tanto por el objetivo mismo de la cuenta twitter, sino por la probabilidad de acceso a otros servicios accesibles desde el pérfil público. Consejo: Dar la misma importancia tanto a las credenciales de banca online como de cualquier otro servicio, no reutilizar contraseñas, y observar la URL de login.

URLs usadas como phishing en twitter (ya deshabilitadas):

hxxp://secure-login.twitter.verifiylogin.com/twitter/
hxxp://videos.twitter.secure-logins01.com/

2) Ingeniería social: Una de las mayores armas de los cibercriminales y de las que mejor resultado ofrecen. Koobface dió el salto a twitter en Julio de 2009. Aparecían tweets con cadenas aleatorias como: "WOW", "LOL", ":)" con enlaces para descargar una actualización del reproductor de flash para ver un vídeo. Por supuesto, esta actualización contendrá el malware que nos infectará. Esto se agrava con el acortamiento de URLs, que también sirve para enmascararlas. La vulnerabilidad clickjacking tambien hizo uso de este arma.

HaztePre, nueva campaña de concienciación ciudadana

El pasado 4 de diciembre de 2009 el Consejo Nacional Consultivo de Cyberseguridad (CNCCS), del cual S21sec es uno de los fundadores, junto al Instituto de Tecnologías de la Información y Comunicación (INTECO) y la Oficina de Seguridad del Internauta (OSI) pusieron en marcha la campaña de concienciación ciudadana “HaztePre”. La campaña, cuya web está alojada en http://www.haztepre.es/, está dirigida a un público de todas las edades con conocimientos básicos sobre Internet y encaminada al uso responsable y seguro de las nuevas tecnologías. Ofrece no sólo material educativo, sino consejos, guías y herramientas gratuitas. Su lema es: “En Internet, como en la vida, hay que SerPRE: ser precavido, estar prevenido y preparado”.

La campaña abarca los principales hábitos de utilización del ordenador de los internautas españoles y cómo mantenerse seguros o cómo actuar de forma prudente: contiene información detallada sobre las amenazas que circulan por Internet, guías sobre cómo navegar de forma segura por la Red (cómo comportarse de manera segura en las redes sociales, cómo hacer compras seguras en Internet…), teléfono de atención ciudadana de la Oficina de Seguridad del Internauta, herramientas de seguridad gratuitas y muchos otros recursos.

Esta campaña viene motivada por el déficit de seguridad a la hora de navegar que se ha observado en la sociedad española a través de distintos estudios. Una de las razones principales es que en nuestro país la difusión de Internet ha sido muy rápida. Actualmente siete de cada diez personas consume ya contenidos digitales. Esta rápida penetración de Internet entre los usuarios ha provocado, sin embargo, que muchas personas que navegan por la red no cuenten con los conocimientos sobre seguridad informática adecuados. Esto implica que el 56,2% de los equipos españoles estén infectados, lo que sitúa a nuestro país en el puesto número doce del mundo en cuanto a número de ordenadores infectados se refiere.

Gran parte de estas infecciones están causadas por la carencia de conocimiento de los usuarios sobre los peligros de la Red y sobre cómo pueden evitarlos. Así, por ejemplo, según una encuesta, aunque el 96% de los usuarios españoles están protegidos con un software de seguridad, apenas un 30% de ellos cuenta con una suite de seguridad y sólo un 34% cuenta con algo tan elemental como un firewall. Mientras, más de la mitad apuesta por tener instalado tan sólo un antivirus.

En lo que al comportamiento a la hora de navegar por la Red se refiere, los datos reflejan que éste tampoco es el más adecuado. Así, por ejemplo, el 64% de los españoles afirma realizar movimientos bancarios utilizando Internet, pero un 32% reconoce que no toma ninguna precaución especial a la hora de hacerlo, a pesar de que en lo que va de año se han registrado más de 1300 casos de phishing dirigidos a entidades financieras.

Esperemos que este tipo de campañas fomenten los entornos seguros y el ciudadano pueda estar cada vez más protegido en su relación diaria con Internet.

María Asín
S21sec