Más vale una foto que un manojo de llaves

El uso de cerraduras y llaves ha sido y sigue siendo el sistema más utilizado de control de acceso. Pese a que las cerraduras pueden ser forzadas, el hecho de cerrar con llave una puerta y ser nosotros mismos los que custodiamos la llave nos da la sensación de seguridad. Para que alguien pudiera abrir la puerta (sin ser un avezado cerrajero o destrozar la cerradura) necesitaría hacerse con una copia de la llave, y para ello nos la tendría que quitar y duplicarla bien en una tienda especializada o mediante algún otro medio casero [1, 2] de dudosa funcionalidad. Pero claro, para esto nos tendrían que quitar nuestra llave y ... nos daríamos cuenta, ¿no?

Pues no, porque no hace falta. Es precisamente este paso (el acceso físico a la llave) el que se han saltado investigadores de la universidad de San Diego. En el artículo presentado estos días en la ACM's Conference on Communications and Computer Security, los autores describen un sistema que utiliza técnicas de tratamiento de imágenes para procesar fotografías de llaves. Estas fotografías pueden ser obtenidas, por ejemplo, mediante la cámara de un móvil, o a bastante distancia mediante una cámara de fotos con teleobjetivo.

El principal reto para el sistema de duplicado de llaves es el tratar con las diferentes orientaciones que pueden tener las llaves en la fotografía. Esto se puede resolver utilizando técnicas básicas de visión por computador mediante las que se crea un modelo 3D de referencia y se consigue obtener las medidas reales de los diferentes dientes de las llaves. Estos datos son posteriormente pasados a una máquina que hace los cortes correspondientes a una llave en blanco.

Al menos me consuela que la puerta de mi casa tiene una cerradura de seguridad. Este tipo de llaves, al incorporar una tercera dimensión (la profundidad de los diferentes pines) son mucho más complicadas de decodificar mediante una foto. Al menos por el momento, el sistema que proponen desde la universidad de San Diego no es capaz de copiar llaves de este tipo. No obstante, hay que tener en cuenta que en paises como Estados Unidos o Reino Unido, el uso de cerraduras de seguridad no está muy extendido en las casas donde predominan las cerraduras convencionales (las que se puden copiar mediante una foto) .

Guzmán Santafé
S21sec labs

Combatiendo el phishing desde su infraestructura básica

Recientemente, el grupo de trabajo Antiphishing (APWG) con la ayuda de la constitución de registradores del ICANN y varias empresas registradores de dominio, han publicado un documento de "recomendaciones de buenas prácticas Anti-Phishing" con el propósito de servir como firme referencia a los registradores de dominios y asegurar así sus sistemas contra los phishers.

Este documento se enfoca principalmente en tres áreas dentro de las cuales las políticas de los registradores puedan ayudar a neutralizar los abusos en los registros de dominios. Incluye:

1. Investigación proactiva del fraude: nuevos procesos en los registros de nuevos usuarios para limitar los phishers y la habilidad de completar registros de dominio fraudulento a gran escala.
2. Inhabilitación de dominios phishing: incluye una serie de buenas prácticas a partir de las cuales los registradores puedan eliminar peticiones de una manera optimizada y suspender eficazmente registros fraudulentos de dominios utilizados en campañas de phishing.
3. Preservación de evidencias para propósitos de investigación: Nuevas prácticas de retención de datos para guardar evidencias claves que puedan ser usadas posteriormente por la ley en la identificación de phishers.

Los ataques phishing sorprendentemente siguen incrementándose, ya lo mostramos en el último informe sobre el fraude online. Varias de las técnicas más potentes de estos ataques como fast-flux, o el infame grupo Rock-Pish son ejemplos donde aplicando las recomendaciones del documento publicado por el APWG puede ayudar a neutralizar el abusivo registro de dominios implicados en estos ataques. Hay pocas, si es que existe alguna, necesidades reales de cambiar el registro NS de un dominio unas cuantas veces al mes. Este debe ser un indicador para los registradores de dominios de actividad ilegal y motivo de posibles investigaciones.

Informe de buenas prácticas para registradores de dominios.

Sobre el APWG: El APWG (Anti-Phishing-Working-Group), fue fundado en 2003, es una coalición de empresas tecnológicas/CERTs , fuerzas del orden y gobiernos enfocada en la eliminación del robo de identidad y fraude resultantes del creciente problema del phishing, falsificación de correo y todo tipo de e-crime. El sitio web de APWG (www.antiphishing.org) ofrece al público e industria información sobre phishing y fraude del correo, incluyendo identificación y promoción de soluciones técnicas y buenas prácticas que proporcionan protección inmediata. Entre los sponsors corporativos del APWG se incluyen: 8e6 Technologies, AT&T (T), Able NV, Afilias Ltd., AhnLab, BillMeLater, BBN Technologies, BlueStreak, BrandMail, BrandProtect, Bsecure Technologies, Cisco (CSCO), Clear Search, Cloudmark, Cydelity, Cyveillance, DigiCert, DigitalEnvoy, DigitalResolve, Digital River, Earthlink (ELNK), eBay/PayPal (EBAY), Entrust (ENTU), Experian, eEye, Fortinet, FraudWatch International, FrontPorch, F-Secure, Goodmail Systems, Grisoft, GeoTrust, GlobalSign, GoDaddy, Goodmail Systems, GuardID Systems, HomeAway, IronPort, HitachiJoHo, ING Bank, Iconix, Internet Identity, Internet Security Systems, IOvation, IS3, IT Matrix, Kaspersky Labs, Lenos Software, LightSpeed Systems, MailFrontier, MailShell, MarkMonitor, McAfee (MFE), MasterCard, MessageLevel, Microsoft (MSFT), MicroWorld, Mirapoint, MySpace (NWS), MyPW, MX Logic, NameProtect, National Australia Bank (ASX: NAB) Netcraft, NetStar, Network Solutions, Panda Software, Phoenix Technologies Inc. (PTEC), Phorm, The Planet, SalesForce, Radialpoint, RSA Security (EMC), SecureBrain, Secure Computing (SCUR), S21sec, Sigaba, SoftForum, SOPHOS, SquareTrade, SurfControl, Symantec (SYMC), TDS Telecom, Telefonica (TEF), Trend Micro (TMIC), Tricerion, TriCipher, TrustedID, Tumbleweed Communications (TMWD), SurfControl (SRF.L), Vasco (VDSI), VeriSign (VRSN), Visa, Websense Inc. (WBSN) and Yahoo! (YHOO).

Emilio Casbas
S21sec labs

Protección del software (Parte V)

El día de hoy vamos a hablar sobre los packers/protectors.

Definimos packer/protector como un programa que toma como entrada un fichero ejecutable y devuelve otro fichero ejecutable con la misma funcionalidad pero con ciertas protecciones añadidas que dificultan su análisis. Existe también la posibilidad de proteger el programa partiendo desde el código fuente e indicando las zonas calientes.

Se puede decir que los primeros programas de este estilo únicamente pretendían reducir el tamaño del ejecutable, de ahí el nombre de packers, pero se fueron introduciendo técnicas de protección, dando el paso a los protectors. Nosotros utilizaremos el término packer indistintamente para ambos ejemplos.

¿Cómo funciona?

El packer debe cifrar al menos la sección ejecutable del fichero a proteger, y en el momento de ejecutarlo debe ser capaz de descifrarlo y ponerlo en memoria. Existen packers que cifran el fichero completo, pero la mayoría optan por introducir una nueva sección, escribir en ella su rutina de descifrado y redirigir el punto de entrada a la misma.

Por supuesto, existen diferente maneras de implementarlo, ya que nos podemos encontrar con cifrados manuales que cifran una sección con un XOR, introducen la rutina de descifrado en alguna parte del ejecutable no utilizada y modifican la cabecera PE para que apunte a dicha rutina.

Si vemos las secciones de un mismo programa con y sin upx, podemos ver como mientras uno tiene el punto de entrada en la sección de código el otro tiene las secciones renombradas y el punto de entrada no apunta a la primera sección. El código que se ejecute en este segundo caso es el encargado de poner en memoria el programa desempacado antes de ejecutarlo.

EP y secciones de un programa escrito en c.

EP y secciones de un programa con UPX

Una protección de este tipo tiene la ventaja de que el desarrollador se despreocupa de la protección del software, y alguien ducho en el tema es el encargado de protegerla.

Visto el funcionamiento del mismo, se nos ocurren dos formas diferentes de atacar esta protección:

1. Revertir el cifrado del packer.
2. Atacar el momento en que el programa queda limpio en memoria antes de ejecutarse, volcar el proceso al disco y reconstruir lo necesario para obtener una copia funcional del original.

Cabe destacar que hoy día también se utiliza la virtualización como protección, ya que añade un grado de complejidad al análisis del programa.

En vista de los dos ataques mencionados, el segundo resulta mucho más asequible, pero para cada fase tenemos algunas contramedidas.

• Para intentar evitar que se pueda llegar a detener la ejecución en el punto de entrada original del programa (OEP), se emplean "trucos" anti-debug
• Para evitar que del volcado se obtenga un fichero funcional, se emplean técnicas anti-dump.

En próximos post hablaremos de algunas de estas protecciones.

Mikel Gastesi
S21sec e-crime

Trojan Dropper

The last day the S21sec ecrime team came across a new version of the already known Trojan Dropper variant, which counts to one of the most common Trojans found on infected machines.

The trojan installs a keylogger to sniff; and a BHO (Browser Helper Object) for Internet Explorer to be able to inject content into web pages. This content is defined in a configuration file which has drastically changed since the last version we looked at.

Now, the configuration file does not contain any external links to phishing pages anymore. So to injecting content into a web page, the local configuration is used and no external domains need to be contacted.


The actual version creates different files which can mostly found in the %System% folder (c:\windows\system32 in WinXP). The current .dll used as BHO is called jetaccs.dll and can be seen with HijackThis from Trendmicro.

Sniffed data is stored in %System%\alog.txt. After restarting the browser this file is send to the c&c server and gets deleted afterward.

Currently, 142 affected sites can be found in the config file. Interesting are also the following entries:

<nolog>google</nolog>
<nolog>msn</nolog>
<nolog>myspace</nolog>

A fast test confirmed the first guess, accounts from gmail don't get sniffed, whereas account data from e.g. gmx.net (not found in the configuration file) gets collected. The reason for this exclusion is not clear until now.

To manually disinfect a computer, HijackThis can be used to disable the BHO. %System%\jetaccs.dll has to be renamed and can be deleted after a reboot.

Clemens Kurtenbach
S21sec e-crime

Comprobando limites

Muchas veces cuando estamos programando, nos cercioramos de que los valores con los que trabajamos no van a producir ningún resultado extraño. Por ejemplo, que el índice con el que recorremos un array no sobrepasa sus límites, que al hacer una división el denominador no sea 0, no calcular el logaritmo de un número negativo o que un puntero no sea null entre muchos otros.
En esta entrada me voy a centrar en la división, aunque también es aplicable a la multiplicación. La comprobación del denominador distinto de 0 es la "clásica" comprobación que todo el mundo realiza, pero no es el único problema que presenta la división de números enteros. Muchas veces se nos olvida que un ordenador no trabaja con una precisión infinita, está relegada a hacer sus cálculos en 8, 16, 32, 64 o más bits por lo que siempre hay un límite y una vez superado tenemos un error de overflow.
Si dividimos un numero entero A entre -1 obtenemos el mismo número A cambiado de signo. Aquí es donde hay que hacer la comprobación ya que esto no es cierto siempre. Si A es el menor número entero, al dividirlo por -1 obtenemos un 0. Veamos un ejemplo, si trabajamos con un procesador de 16 bits, los números enteros van desde -32768 a +32767, si dividimos -32768 entre -1 obtenemos +32768 que provoca un desbordamiento u overflow y nos da como resultado 0. Normalmente estos errores son detectados en tiempo de ejecución y dependiendo del lenguaje, el runtime y/o las opciones de compilación la ejecución del programa no se detiene sino que continúa ejecutándose con un dato erróneo. En java (Long.MIN_VALUE/-1) devuelve Long.MIN_VALUE mientras que en C (MININT/-1) da 0, en otros lenguajes no he comprobado pero los resultados serán similarmente dispares.
Esto puede llevar a resultados catastróficos si tenemos dos aplicaciones que deban compartir datos y cada una este escrita en un lenguaje distinto. Al calcular un hash de un valor, o un CRC de un fichero, arrojarán valores distintos en una y otra.
Además la expresión la podemos pasar como parámetro a un cgi, éste se parará si tiene activado el OverFlowChecking que en algunos lenguajes está activo por defecto.


Eduardo Morrás
S21sec e-crime

Nos vemos la semana que viene

La próxima semana viene cargada de eventos en los que participaremos y a los que no podéis faltar.
El lunes 27 David Barroso, Director de eCrime de S21sec dará una ponencia titulada “Botnets 2.0: adquiriendo el control de Internet (la amenaza silenciosa)” en Asegur@IT IV, que celebrará esta edición en Madrid y organizado por Informática 64.
Ese mismo día estaremos también en el evento Intellect Financial Services Group: Financial Crime Roundtable que tendrá lugar en Londres.
Por otra parte, Antonio Ramos participará en la mesa redonda sobre seguridad dentro de las I Jornadas de Auditoría y Sistemas de Información que van a celebrarse los días 27 y 28 de noviembre organizadas por la Asociación de Auditores y Auditoría y Control de Sistemas y Tecnología de la Información y Comunicaciones.
Además, David Barroso estará el día 29, miércoles, en La Coruña ofreciendo una ponencia titulada "Recursos de la (cyber)economía sumergida" en las Jornadas de Seguridad 2008 que tendrán lugar en la Facultad de Informática de A Coruña los días 29 y 30.
¡Nos vemos la semana que viene!

Marketing S21sec

Introducción fantástica a un problema real

Les presento al señor O.

El señor O. es un hombre siniestro y envidioso. También es el CEO de una compañía maligna que va directa a la ruina por no haberse sabido adaptar a las exigencias del mercado.

Las familias de sus empleados le importan poco al señor O., pero su yate, amigos, no se paga solo. Es necesario que la empresa proponga algún producto rompedor que oxigene sus cuentas.

Después de mucho pensar, decide utilizar la misma estrategia que le sirvió para aprobar sus exámenes de universidad: copiar. Es decir, robar información a compañías de la competencia.

Para conseguirlo su mano derecha, Shmoarl, un reptil humanoide en traje de armani le sisea tres alternativas:

A- Contratar a unos ninjas para que realicen una incursión en las centrales de la competencia.
B- Secuestrar a Theo de Raadt, obligarle a saltarse diezmil sistemas de seguridad, acceder a los repositorios de información super secreta de la competencia y pinchar-arrastrar al disco duro local.
C- Pagar a un becario mileurista su sueldo de tres meses para que saque esa información -a la que tiene acceso- en un deuvedé virgen (vírgen, pero con la marca de la bestia, está claro).

Shmoarl tiene guantes blancos y un nombre de sonoridad aviesa.

Después de consultar los presupuestos de cada una de las estrategias, se decide por la opción C. Con mucho, la más barata. Shmoarl protesta acaloradamente, aduciendo que "no esssh nadah difertidahh". Pero el señor O., que tiene mucha psicología reptiliana, le promete un campo de entrenamiento de ninjas mutantes en los sótanos de la corporación en cuanto dominen el mundo.

Para sorpresa de todos, el plan c también se aborta.

Algún despistado de la empresa rival les ha enviado por error un email en el que incluía información clasificada. Ya no es necesario utilizar ningún plan sofisticado para nada.

El señor O. ha vuelto a triunfar.


Para evitar que planes malignos, como los del señor O., tengan éxito en el futuro hay unas siglas que se han puesto bastante de moda en el mundo de la seguridad informática: DLP.

Detrás de ellas se encuentra el concepto: Data Loss Prevention. Una serie de tecnologías que pretenden evitar la fuga de datos desde el interior de las corporaciones tanto si es de manera malintencionada (A, B o C) como si es por un error humano.

Comentaremos más en detalle estas tecnologías en un futuro post.

...que se han creído Shmoarl y el señor O. que esto va a quedar así.


Luis Tarrafeta
S21sec labs

Seguridad informática en los medios

No, no me refiero a los de comunicación en masa como periódicos y telediarios, en donde ya sabemos con qué precisión relatan los hechos relacionados con la seguridad informática, cuando raramente lo hacen. Hoy me gustaría escribir sobre los medios de entretenimiento, como cine y televisión, que versan sobre el tema a nivel ficticio.

Primero repasemos qué hemos podido disfrutar en cartelera. A muchos de nosotros nos viene a la mente la nostálgica película Juegos de Guerra como una de las pioneras del género, en donde podíamos ver las argucias de un jóven adolescente que le permitieron entrar en la red de un complejo militar asesorado por la entrañable W.O.P.R., y cómo no, accediendo a él con un primitivo módem conectado a la línea mediante un acoplador acústico. En aquellos tiempos y a nuestra edad (soy de finales de la generación x), nos tragábamos todo de la pe a la pa, y es que realmente, y para los avances de la época, considero tenía un argumento bastante creíble que nos dejaba enganchados, y nos hacíamos (por lo menos yo :P) nuestros programillas en el Locomotive BASIC de nuestro CPC que simulaban una conversación con la WOPR (incluso pude ejecutar algún programa en código máquina que simulaba su sintetizador de voz). Claro, otros se emocionaban con esto de la telemática, y tras sendas horas de "navegación" por Ibertex, sus padres les propinaban una buena colleja por la factura recibida a fin de mes.


Pasaron unos años de relativo vacío (¿puede considerarse Jumping Jack Flash como perteneciente al género?) hasta que, en 1995, se produjo un pequeño boom, atreviéndose a llevar a la gran pantalla dos películas del género: Hackers y La Red. En esta época, ya habíamos pasado de las BBS (no todos ya lo se) a Compuserve o similares, que nos abrían la puerta a internet. Yahoo reinaba por aquellos tiempos por encima de otros buscadores como Altavista y, aunque parezca increíble, Google no había nacido. Lo cierto es que se daba el caldo de cultivo propicio (en USA nos llevaban la delantera en cuanto a accesibilidad a internet) para hacer cine, ya con mucha más inventiva que antes. Es en este momento donde los guionistas, en un alarde de creatividad y con escasísimos o nulos conocimientos de seguridad informática, se lanzaron de cabeza a llenar de frases "cool" los diálogos de los intrépidos actores y actrices, dando escasa importancia a la precisión de los términos empleados.

Claro, un público neófito en la materia no podría ni le interesaría distinguir si le hablaban de hackers, crackers o juankers, así que el entretenimiento estaba garantizado. Es en esta época donde se decide que los ordenadores necesitan su tiempo para dibujar en pantalla un texto en 80x25, mientras que aparecían complejísimos escritorios 4D de forma mágica en un abrir y cerrar de ojos. Este dibujo en pantalla producía pitidillos, y los ordenadores se podían apagar tan pronto terminabas de teclear.

Tras este prolífico año, se sucedieron algunas películas, pero sin duda no se nos borrará de la mente aquél 2003 en donde veíamos en The Matrix Reloaded aquel maravilloso fotograma con una ejecución de nmap con sus argumentos perfectamente puestos, y un exploit contra OpenSSH ejecutado bajo un entorno *NIX totalmente creíble (bueeeno, el pitidito de dibujar la pantalla le da dramatismo, como las cuerdas chillando en una escena de una película de miedo). Como podéis ver, Insecure se muestra orgullosa de la aparición de su herramienta en la gran pantalla.

Para acabar con el cine, no debemos pasar por alto Jungla de Cristal 4 , de la que ya hemos hablado en el blog. Aunque tiene muchos componentes fantasiosos (es decir, que si nos ceñimos a lo que vemos nos partimos de risa), tiene un trasfondo relativamente creible, aunque desgraciadamente no tuve, años ha, un Amiga para jugar al caos total.

Como avance de mi próximo post, y por recomendación de un compañero de trabajo (gracias Patxi), os dejo el link a una serie que trata sobre un equipo de "crackers" que tiene muy buena pinta: Tiger Team. Desgraciadamente sólo se emitieron episodios y no se ha seguido con ella, un experimento vamos.

Y ahora me gustaría que me recomendárais aquellas películas que os han dejado marcados, para bien o para mal. ¿Sóis analíticos al ver películas de este género? ¿Os pica la curiosidad de tragaros cualquier bodrio que salga al respecto? A mí sí, y la verdad, la última que ví me dejó con mal sabor de boca tras tan fantástica primera parte.

Álvaro Ramón
S21sec labs

Seguridad en dispositivos UMTS

Este post tratará sobre dispositivos inalámbricos que todos conocemos (o deberíamos si estamos en la era digital) y de los que casi todos disponemos de uno, un teléfono o un módem 3G.

El tema de la seguridad en este tipo de redes, puede verse desde diversos puntos de vista, y de los que se podrían escribir innumerables post. En este caso nos centraremos en cómo se realiza la autenticación en la red de un nuevo terminal de usuario (en resumidas cuentas, nuestro teléfono móvil).

Para ello interactúan dos nodos principalmente de la red UMTS el AUC (nodo autenticador, generalmente unido al nodo HLR) y el propio terminal a través la tarjeta que todos introducimos la SIM o USIM. Aunque potencialmente existen otra serie de nodos que intervienen lo hacen de forma más o menos transparente para este punto de comunicación. Para mayor claridad se puede observar el siguiente diagrama de arquitectura de red:

Como se puede apreciar para que un terminal de usuario (UE) pueda "hablar" con el nodo AUC debe atravesar multitud de nodos, aunque la mayoría de estos tienen otro tipo de funciones diferentes a la autenticación del usuario en la red.

Para realizar esta autenticación se realiza un sistema de reto y respuesta para proceder a la autenticación y verificación de las claves (AKA, Authentication and Key Agreement). Para ello en este tipo de redes se utiliza un vector que contiene 5 campos principales:
RAND: Número aleatorio para realizar la pregunta
CK: Clave de cifrado
IK: Clave de integridad
AUTN: Token de autenticación
XRES: Respuesta esperada.

A su vez el campo AUTN consta de los siguientes valores:
SQN: número de secuencia
AMF: Campo de gestión de autenticación
MAC-A: Código de autenticación del mensaje.

El proceso es el siguiente:

Primero el nodo de red se encarga de solicitar los datos al nodo de autenticación

1.- Una vez el nodo ha enviado la petición de acceso a la red, el nodo VLR (unido a la MSC o SGSN generalmente), se encarga de solicitar un vector de inicialización al nodo HLR/AUC (que es quien dispone junto a la USIM de la clave del usuario).
2.- El nodo HLR/AUC se encarga de calcular dichos valores basados en la clave única de usuario.
3.- Una vez terminado el cálculo responde al nodo VLR con el vector de inicialización (AV(1),..., AV(n)) correspondiente.

Posteriormente, el nodo de red (VLR) se encargará de verificar al usuario

1.- El nodo VLR se encarga de elegir un vector de inicialización (uno de los recibidos anteriormente), y envía al terminal únicamente el campo RAND y AUTN.
2.- El terminal móvil procesa los datos recibidos con la ayuda de su clave única y secreta (contenida únicamente en la USIM y en el nodo HLR/AUC). Con esta clave el terminal es capaz de verificar que quien le ha enviado la solicitud de autenticación también dispone de dicha clave. Además el terminal se encarga de validar que el vector utilizado (AV(i)) no ha expirado en el tiempo verificando el número de secuencia (campo SEQ). Así valida que el vector de autenticación es válido. Después el terminal se encarga de general la clave de cifrado (CK), la clave de integridad (IK) y la respuesta esperada al reto enviado por el nodo de red (RES).
3.- El terminal de usuario responde con el campo RES al nodo de red.
4.- El nodo de red verifica que la respuesta (campo RES enviado desde el móvil) es correcta comparándola con la respuesta esperada (XRES) del vector de inicialización utilizado (AV(i)).

Una vez terminado el proceso la autenticación mutua es efectuada. ya que tanto el terminal a través de la USIM y el nodo de red (VLR) se han autenticado mutuamente bajo dos condiciones: Primera la USIM ha verificado que el campo MAC en el AUTN es igual al calculado internamente utilizando la clave privada K. Y segundo el nodo de red VLR ha verificado al terminal (USIM) ya que el campo de respuesta RES es igual al campo esperado XRES.



Para más información se pueden consultar los siguientes enlaces:
1
2
3

José María Arce Guillén
S21sec labs

Protección del software (Parte IV)

En las partes anteriores hemos dado un repaso a las protecciones más comunes, por lo que ahora vamos a intentar dar algún consejo a la hora de proteger una aplicación.

Al igual que en las partes anteriores, vamos a tratar la parte lógica de la programación, en la que priorizaremos el no dar facilidades a quien pretende atacar nuestra aplicación, y volveremos a tomar como base de este post una aplicación protegida por contraseña.

En la siguiente parte comenzaremos con temás un poco más técnicos, tomando los packers como base, y tratando diferentes barreras que ponen para tratar de proteger la aplicación.

Volviendo al tema que nos conscierne, en primer lugar deberemos recapacitar sobre lo que un atacante necesita para ponerse manos a la obra. A la hora de atacar una protección, no se analiza el código del programa en su totalidad, sino que interesa ubicar la parte de código en que se encuentra la rutina de comprobación, por lo que la primera labor es encontrarla.

Para ello, muchas veces puede ser suficiente fijarte simplemente en los mensajes que se muestran para indicar que es una versión de prueba, ver qué se necesita para registrar el programa (si un número de serie, keyfile), y buscar en el programa en cuestión cadenas de texto sospechosas, llamadas a APIs relacionadas con la apertura de ficheros, lectura de registro...

Por tanto, un consejo muy importante consiste en no dar más información de la necesaria.

Para el profano en la materia, vamos a ver un pequeño ejemplo de una aplicación que muestre un mensaje "Hola Mundo!" en la que queremos encontrar la zona en la que imprime el mensaje, y vemos cómo existe una diferencia notable entre dos aplicaciones que realizan la misma función.

Hola mundo en MASM32:



Hola mundo en C:


Para empezar podemos ver que la versión en C ocupa el séxtuple que la programada en ensamblador.


Veamos el código que se ejecuta en primera instancia, las cadenas de texto y las APIs importadas en cada uno.

Ensamblador:


C:



En la versión asm el código es muy parecido al escrito más arriba, y tanto las cadenas de texto referenciadas como la llamada a apis se corresponden con las utilizadas en el código fuente. Por el contrario, el compilador de C modfiica el código, y vemos cómo aparecen más cadenas de texto y se importan muchas más APIs.

Con esto comprobamos cómo los compiladores de alto nivel realizan modificaciones en el código, por lo que al analizar un programa, rescatar la idea del programador se convierte en una tarea un poco más complicada. Por supuesto, no se puede confiar en esto como protección. Se puede aconsejar la optimización de código porque puede tener como efecto lateral una pequeña ofuscación del código pero, al ser una transformación de código que no controlamos, ¿no podría afectar negativamente?

Por otra parte, si se debe dar información sobre un evento y no se para a pensar en ello, se puede dar por hecho que la información del evento (¿un registro fallido?) se encontrará cercana a la comprobación, y si se puede seguir la ejecución del programa, vendrá justo detrás de ésta. Es aconsejable separar la comprobación de la decisión y de la información devuelta al usuario (en forma de continuación con la versión de ejecución, por ejemplo).

Un mal hábito que se puede encontrar en más de una ocasión consiste en no mostrar una NAG (ventana de aviso) en caso de fallar el registro, pero a cambio cerrar el programa. Este hecho permite que el atacante pueda detener la ejecución cuando se llama a la API encargada de termina con la aplicación y solamente mirando desde donde es llamada se acercará a tu rutina de comprobación.

Personalmente considero mucho más razonable que una aplicación ante un intento de registro continue una ejecución normal, pero la funcionalidad que se quiere dar a la versión registrada dependa de la clave introducida.

Resumiendo un poco este post, digamos que si no queremos que nuestra protección sea presa fácil, por lo menos no colaboremos a ello ;)

Mikel Gastesi
S21sec e-crime

Cómo (no) funciona WEP II

En un post anterior hemos visto cuál es el funcionamiento básico de WEP y cómo los errores en su diseño han tenido como consecuencia la existencia de algunas vulnerabilidades. En este post vamos a seguir explicando más vulnerabilidades.

Además del problema de las colisiones de los vectores de inicialización que pueden usarse para analizar las tramas y deducir partes del flujo RC4, hay otras técnicas más efectivas y eficientes de hacerlo.
Por ejemplo, un punto de acceso puede servir de oráculo en ciertas condiciones. Si desde una dirección IP que está en una LAN cableada podemos enviar datos a uno en una red wifi, el punto de acceso se encargará de cifrar los datos (lógicamente conocidos) para nosotros. De esta manera tenemos los flujos RC4 de los vectores de inicialización que use el AP.


Como ya hemos dicho anteriormente, muchos paquetes contienen cabeceras que son conocidas y que en muchas ocasiones tienen bytes cuyos valores podemos presuponer . De hecho, los 7 primeros bytes de los paquetes de datos son conocidos en prácticamente el 100% de los paquetes y corresponden a la cabecera LLC/SNAP. Por lo tanto asumimos que los primeros 7 bytes son 0xAA, 0xAA, 0x03, 0x00, 0x00, 0x00, 0x08. Haciendo XOR ya tenemos los 7 primeros bytes de un flujo RC4, con los que podemos generar una trama con 3 bytes de datos, ya que hay que incluir 4 bytes del CRC-32. No es mucho, la verdad, pero podemos aprovecharnos de la fragmentación. Efectivamente, podemos enviar, por ejemplo, una petición ARP enviándola de 3 en 3 bytes. El punto de acceso los unirá por nosotros y lo transmitirá. Capturamos esa trama y como ya conocemos el texto en claro (lo hemos generado nosotros), resulta que tenemos un flujo RC4 más largo que el anterior. Si repetimos la operación añadiendo datos sin valor después de la petición ARP, podemos llegar a tener un flujo RC4 de 1500 bytes sin ningún esfuerzo.


Otra vulnerabilidad relacionada con las propiedades de CRC-32 permite descifrar un paquete. Este ataque es conocido como chopchop y fue descubierto por un hacker que se hace llamar KoreK. Si capturamos un paquete cifrado y eliminamos su último byte, el CRC-32 deja de ser válido. Sin embargo, si calculamos cómo cambia este valor, descubrimos que la diferencia entre el original y el modificado solo depende del valor del byte que hemos eliminado. Eso es un dato que desconocemos, pero al fin y al cabo un byte solo puede tener 256 valores diferentes. Podemos presuponer que el valor eliminado era 0. Calculamos el CRC-32 correspondiente, inyectamos el paquete y si el punto de acceso lo retransmite nuestra presunción era correcta. Simplemente probamos todos los valores hasta que encontramos el que es. Hemos descifrado un byte. Repitiendo el proceso recuperamos uno a uno todos los bytes del mensaje original. No solo eso, de paso también tenemos un flujo RC4.

Y por fin llegamos a los ataques más conocidos, los que permiten obtener la clave WEP a partir de tramas cifradas. Era conocido que los primeros bytes de un flujo RC4 estaban sesgados, pero en 2001 Fluhrer, Mantin y Shamir publicaron un paper en el que exponían como ciertos vectores de inicialización son “débiles” y pueden usarse para inferir bytes de la clave secreta usada en el algoritmo RC4. Más en concreto, cuando los 3 bytes del vector de inicialización tiene la forma (3,255,x), donde x es un valor cualquiera, el primer byte del flujo resultante puede puede usarse para calcular el primer byte de la clave WEP. Este cálculo acierta el 5% de las veces aproximadamente, mientras que el 95% restante devuelve un valor aleatorio. Si capturamos 60 tramas con un vector de inicialización de ese tipo, tenemos un 50% de posibilidades de estimar correctamente el primer byte de la clave. Esta probabilidad crece con el número de tramas capturadas. Si el vector de inicialización es (4,255,x) sucede lo mismo con el 2º byte de la clave WEP, lo mismo con (5,255,x) y el tercer byte y así sucesivamente.
Para que este ataque tenga éxito hay que capturar mucho tráfico, hasta reunir el número suficiente de tramas con los vectores débiles necesarios. Aunque esto puede llevar bastante tiempo, el ataque es perfectamente posible y es en lo que se basaban las primeras herramientas que rompían claves WEP.
Más adelante, Klein publicó un trabajo en el que exponía como la correlación entre un flujo RC4 y los primeros bytes de la clave era más fuerte de lo que se pensaba. Para que este ataque tenga éxito, solo es necesario conocer tantos bytes del flujo como la longitud de la clave menos uno. Con esta información es posible hacer estimaciones de los bytes de la clave. Al igual que en el caso anterior, la probabilidad de que esta sea correcta es baja, pero suficiente como para diferenciar el valor entre el resto, que aparecen de una manera mucho más aleatoria. Capturando entre 40000 y 50000 tramas se tiene un 50% de probabilidades de estimar correctamente la clave y con 750000 tramas o más, la probabilidad crece por encima del 90%.
Como ya hemos visto, los primeros 7 bytes de cada trama son conocidos prácticamente en el 100% de los casos. Sin embargo para utilizar la vulnerabilidad descubierta por Klein, necesitamos conocer los 15 primeros. Por suerte, las peticiones ARP tienen el siguiente aspecto:



Los primeros 16 bytes son conocidos, ya que las peticiones se envían a la dirección MAC de broadcast, mientras que las respuesta se dirige a una dirección MAC concreta. Capturando este tipo de tramas podemos obtener los 15 bytes del flujo RC4 que necesitamos inmediatamente. Estas tramas son fácilmente reconocibles porque tienen un tamaño fijo y además son bastante frecuentes (en algunos casos incluso se pueden forzar si es necesario). Además, con las técnicas vistas anteriormente, podemos crear nuestra petición ARP para reinyectarla en la red wifi y hacer que se genere más tráfico con la respuesta, de esta manera se captura el número de tramas necesario en pocos minutos.

En general, las decisiones que se tomaron al crear WEP no son muy acertadas. Especialmente el uso de CRC-32 para comprobar la integridad de los datos, y la forma en que se usa RC4. El análisis de un sistema de cifrado es una tarea ardua que puede durar varios años. Hay que ser muy cuidadoso para evitar llevarse "sorpresas".

Patxi Astiz
S21sec labs

Introducción al Portable Document Format (PDF)

Hace ya unos meses, en la Black Hat europea de este año, se hizo una charla que hablaba de las capacidades y funcionalidades del formato PDF. En ella se advertía que gracias a algunas de sus funciones, un simple PDF podría convertirse en un malware en toda regla que podría realizar las acciones que especificara el atacante. Además, recientemente se ha puesto de moda la explotación de vulnerabilidades a través de documentos en este formato. Es por eso que hoy os voy a contar lo básico sobre la estructura de un PDF y cómo trabaja internamente. Puede que resulte un poco pesado, pero os prometo que en los próximos posts sobre el mismo tema habrá más parte práctica;) Para hacerlo más ameno podéis abrir un PDF en un editor de texto o en un editor hexadecimal e ir viendo todo lo que voy comentando.

Un PDF está formado internamente por multitud de objetos que se relacionan entre sí. Estos objetos pueden ser de ocho tipos diferentes: booleanos, números enteros y reales, cadenas de texto, nombres, arrays, diccionarios, streams y nulos. Dejando aparte los tipos “conocidos”, los nombres son una especie de etiquetas de los distintos elementos que definen un objeto, los diccionarios, delimitados por los caracteres "<<" y ">>", son un conjunto de parejas clave-valor, y los streams, delimitados por las palabras "stream" y "endstream", son secuencias de bytes, un flujo de información que los lectores PDF pueden leer incrementalmente, al contrario que las cadenas de texto normales. Todos los objetos se pueden declarar como objetos indirectos, de forma que se les asigna un identificador para poder ser referenciados en cualquier otra parte del archivo. Esta clase de objetos están delimitados por las palabras "obj" y "endobj".

La estructura física de un archivo PDF se divide en cabecera, cuerpo, tabla de referencias cruzadas y trailer:

• Cabecera: es la primera línea del archivo y se indica la versión de la especificación PDF que se aplica en el documento precedida de la cadena "%PDF-".

• Cuerpo: se trata de una secuencia de objetos indirectos que conforman el contenido del PDF.

• Tabla de referencias cruzadas: comienza con la palabra "xref" y recoge la ubicación en el archivo de los objetos indirectos, a través de un offset de bytes, de forma que se pueda acceder a ellos sin necesidad de leer el documento completo.

• Trailer: se encuentra al final del archivo y permite la lectura rápida del documento por parte de las aplicaciones; es por ello que éstas deberían empezar a leer el archivo desde el final. En el trailer se incluye un diccionario que comienza con la palabra "trailer" que contiene diversa información importante para la interpretación del documento. También se incluye, después de la palabra "startxref", los bytes desde el comienzo del fichero hasta la tabla de referencias cruzadas, terminando con la cadena "%%EOF".

Es importante señalar que el bloque "cuerpo-tabla de referencias cruzadas-trailer" se puede repetir más de una vez si se han realizado modificaciones del documento original. Es decir, en un archivo PDF se guarda el original y todos los cambios realizados sobre él, de ahí el despiste de las tropas americanas en Iraq al desclasificar la información de un informe, dejando a la luz más de lo que deseaban.

Para terminar, comentar brevemente la estructura lógica de un documento PDF. Ésta sigue una jerarquía donde el "catálogo" se encuentra como raíz de los demás nodos (se accede a él a través de la entrada /Root del trailer). En él se encuentran referencias a otros objetos que definen el contenido del documento y la forma de presentarlo, entre muchas otras cosas. Por ejemplo, el nodo /Pages es un árbol de todas las páginas que conforman el documento, definiéndose a su vez en otros nodos su contenido y demás atributos. Ésta sería la estructura aproximadamente:


Si queréis ampliar la información no tenéis más que descargar la especificación del formato desde la página oficial, aunque os aviso que no es para nada ameno:)

Jose Miguel Esparza
S21sec e-crime

Malware en dispositivos móviles: situación actual

En un post anterior hablamos sobre los orígenes del malware en el mundo de los dispositivos móviles. Hoy trataremos el mismo tema, malware en dispositivos móviles, pero desde una perspectiva un poco más actual, con el objetivo de determinar si la amenaza es real o no.

Con la aparición en el mercado de los últimos modelos de dispositivos móviles, actividades como la navegación web o recibir correo en el dispositivo móvil son algo cada vez más habitual. Las amenazas descritas en el post anterior se propagaban usando bluetooth, sms, y en la mayoría de los casos, a través de ingeniería social (se engañaba al usuario para que él mismo se instalara el malware). Ahora bien, las capacidades que ofrecen los nuevos dispositivos móviles abren todo un abanico de nuevas posibilidades para el creador de malware. Los dispositivos actuales son prácticamente ordenadores en miniatura, luego, ¿por qué no es habitual ver u oír noticias relacionadas con ataques a este tipo de dispositivos?. La mayoría de la gente ya se ha concienciado de que debe usar un antivirus en su equipo de sobremesa, ¿por qué no ocurre lo mismo con los móviles?. Es más, el mercado de software antivirus para ordenadores convencionales está repleto de productos (McFee,Panda,Norton y un largo etc.), ¿por qué no ocurre lo mismo con el software antivirus para móviles?

He aquí algunas de las razones:

• La cantidad de desarrolladores de aplicaciones móviles es, sin duda, mucho menor que en el entorno de los PCs. Así pues, por pura estadística, la cantidad de autores de malware es menor para dispositivos móviles que para PCs.
  

• El uso de dispositivos móviles para realizar transacciones bancarias electrónicas todavía no es muy popular, es por esto que los creadores de malware no se sienten muy atraídos por este tipo de dispositivos (no es ningún noticia nueva que el propósito del malware, en la mayoría de los casos, es robar dinero de las cuentas bancarias de usuarios poco precavidos).
  

• El número de plataformas existentes todavía es demasiado diverso (Android de Google, Windows Mobile, Symbian de Nokia, BlackBerry, iPhone etc.), haciendo que una vulnerabilidad descubierta solo afecte una una población concreta de dispositivos móviles.
  

Bueno, visto lo visto, parece que el malware en los dispositivos móviles no debería preocuparnos mucho, ¿no?. Desde mi punto de vista, no es un tema muy preocupante, todavía. Porque...

• Si bien, como antes he comentado, todavía no es muy habitual hacer transacciones bancarias o compras a través de estos dispositivos, con la irrupción de dispositivos tipo iPhone, los Nokia n-series etc., todos ellos con capacidades web y multimedia muy avanzadas, tarde o temprano esto será algo habitual (de la misma manera que hoy día ya empieza a ser habitual comprar cosas por internet desde el PC de nuestra casa). De hecho instituciones financieras tales como el Bank of America ya están añadiendo las características necesarias a sus páginas web para poder facilitar la navegación usando el móvil.

• En cuanto a la diversidad de plataformas, puede que en un futuro no muy lejano, alguna de ellas gane la suficiente popularidad como para que merezca la pena crear malware especifico. Así como ocurrió con Windows a nivel de PC , algo parecido podría ocurrir en el mundo móvil (no os penséis que Linux y Mac está libres de malware porque son geniales, es simplemente que la mayoría del malware se crea para el sistema operativo más popular, Windows; lo mismo puede ocurrir en el mundo de los móviles).

• Finalmente, el campo del malware en el mundo de los PCs está bastante "vigilado"; muchas compañías dedicadas a la seguridad invierten mucho dinero al año en buscar medidas de protección ante este tipo de amenazas. No es descabellado pensar que los autores de malware decidan migrar al "coto" de los dispositivos móviles, mucho menos "vigilado".
  

Yo soy de la opinión de que, tarde o temprano, el malware será un problema en este tipo de dispositivos, muy parecido al que padecen hoy día los ordenadores de sobremesa. Me atrevería a puntualizar que, en el momento en que estos dispositivos se empiecen a usar para realizar compras por Internet, transacciones bancarias y actividades similares de forma masiva, se convertirá en un problema tan popular como el de sus hermanos mayores los PCs de sobremesa.

¿Qué opináis vosotros?

Asier Marruedo

S21sec e-crime

Reto 6

Volvemos a la carga con un nuevo reto.

Esta vez el premio se trata del libro "The IDA Pro Book: The unofficial guide to the world's most popular disassembler". Podéis ver una crítica aquí.

Como siempre, espero que sirva para divertiros un rato y, si se tercia, haceros con un libro interesante. Las soluciones, por favor, a labs@s21sec.com

Mikel Gastesi
S21sec e-crime

Sistemas de pago ingeniosamente comprometidos

Varias veces se ha hablado aquí de seguridad en el hardware, y de cómo la fabricación globalizada de hardware se está convirtiendo en una nueva fuente de problemas de seguridad. Hace meses vimos la noticia de un caballo de troya en los equipos de los militares de EE.UU. Esta vez el objetivo era la población civil. Y demuestra la cada vez más compleja sofisticación del fraude electrónico más alla de Internet.

Se trata de uno de los ataques tecnológicos más avanzados que se han visto, y ha ocurrido en Europa, a través de una serie de bien orquestadas operaciones realizadas en los datáfonos que la mayoría de comercios disponen para el pago con tarjeta de crédito. Estos dispositivos contenían 'hardware añadido' en fábricas de China que se encargaban de copiar la información de los clientes antes de que ésta fuera cifrada, para almacenarla, cifrarla con sus propios medios, y enviarla entonces a través de una conexión 3G a un servidor de Lahore, Pakistán, donde era descifrada y utilizada para clonar tarjetas de crédito.

Lo verdaderamente relevante de este fraude era la capacidad de decisión de robo provista en estos datáfonos, adaptándose al establecimiento donde operaban para complicar así su presencia. Si se trataba de un pequeño comercio, robaban poco dinero a la semana y realizaban un envío semanal al servidor remoto, si por el contrario estaban situados en grandes superficies, las cantidades robadas aumentaban así como la frecuencia de envíos al servidor remoto.
Esta capacidad de decisión, era descargada cada vez que subían los datos robados al servidor de Pakistan. Hemos robado X datos de clientes en este periodo de tiempo, ¿cuánto robamos la próxima vez?

La cantidad de dinero que se ha conseguido estafar a través de este fraude es presumiblemente de entre 50 y 100 millones de dolares.

No ha tardado ni 1 mes en cumplirse dos de las predicciones que David mostraba en el post Tendencias en el fraude online:

• Código malicioso cada vez más complejo.
• Amenaza de países emergentes (China).

Los requisitos que marca PCI para el manejo de tarjetas de crédito, no hubieran servido de nada en este caso. El aviso de un guardia de un establecimiento víctima alertado por algunas interferencias que nunca se materializaban en mensajes o llamadas y una auditoría de caja blanca tras sospechas de Mastercard desvelaron el fraude.

Emilio Casbas

S21sec labs

Triquiñuelas a nivel de red

Últimamente me ha tocado hacer alguna que otra auditoría de caja negra de nivel de red y, aprovechando la coyuntura, se me ha ocurrido que podría ser interesante dedicar este post a explicar algunas de las técnicas que suelen utilizarse particularmente en la auditoría de routers. Si bien, es necesario aclarar antes de nada que estas técnicas no siempre funcionarán. Hoy en día existe una mayor conciencia de seguridad y es habitual seguir guías y plantillas de configuración que mejoran mucho este aspecto. Ahora sí, al tajo!

Aunque pueda parecer extraño, es bastante habitual aprovechar que algunas de las tarjetas de red del router no realizan correctamente el relleno (“padding”) durante el proceso de generación de tramas. Para comprobarlo, se puede enviar a la interfaz del router un paquete "icmp echo request" con un tamaño anormalmente pequeño. De esta manera, es posible que al generarse la estructura de datos que representará la trama que encapsula el "icmp echo reply", se reserve una cantidad de memoria mayor que la necesaria. La parte sobrante, si no se realiza un adecuado relleno (p.e. “padding” con ceros), contendrá probablemente datos que operaciones anteriores hayan podido dejar en la memoria del router. Para entender un poco más en detalle el potencial de este ataque se ilustra con el siguiente ejemplo, en el que se hace uso de la herramienta ping de Linux (ping -s 0 IP_ROUTER) y se captura el tráfico de respuesta con tcpdump.

10:15:44.928354 router > station: icmp: echo reply
0x0000 4500 001c 8ae3 0000 fe01 aea9 c0a8 0101       E...............
0x0010 c0a8 0102 0000 17f0 e80c 0003 6377 437a       ............cwCz
0x0020 5010 0400 434a 0000 0204 0200 c0a8            P...CJ........

10:15:45.938513 router > station: icmp: echo reply
0x0000 4500 001c 8ae4 0000 fe01 aea8 c0a8 0101       E...............
0x0010 c0a8 0102 0000 17ef e80c 0004 5061 7373       ............Pass
0x0020 776f 7264 3a20 0000 02ac 3c93 c0a8            word:.....<...

10:15:46.948675 router > station: icmp: echo reply
0x0000 4500 001c 8ae5 0000 fe01 aea7 c0a8 0101       E...............
0x0010 c0a8 0102 0000 17ee e80c 0005 6377 437c       ............cwC|
0x0020 5010 03fe 4349 0000 0204 0200 c0a8            P...CI........

Sí, veis bien, ¡una de las contraseñas del router!

Por otra parte, muchas veces puede venir bien conocer información relativa a la máscara de red que se emplea en una interfaz de un router concreto. Esto ayuda a confeccionar un mapa del segmento de red al que se encuentra conectada dicha interfaz y así obtener nuevos hosts potencialmente vulnerables y que deberemos auditar. Para ello bastaría realizar un escaneo de pings con Nmap al segmento definido por la máscara de subred averiguada. La manera de obtener esta máscara de red se basa en dos de los mensajes de control del protocolo ICMP encontramos. Estos son, "address mask request" y "address mask reply", cuyos correspondientes valores para el campo tipo de la cabecera ICMP son 17 y 18 respectivamente, ambos con valor 0 en el campo de código (véase figura).

Una manera de generar paquetes icmp de este tipo es utilizando Sing, una excelente herramienta para generar paquetes icmp y además creada por uno de nuestros compañeros de S21sec. Basta con pasarle la opción correcta y el host de destino:

sing –mask IP_ROUTER

Por otro lado, para poder descubrir la máscara que tiene configurada una interfaz tendremos que saber antes qué interfaces tiene un router. Existen distintas maneras de lograr esto. Así, podríamos utilizar traceroute contra distintos hosts conocidos, ya sean internos o públicos en Internet. Los hosts conocidos podrían ser los servidores de DNS, algún servidor de base de datos que nos resulte familiar, etc. Según la tabla de rutas del router, los datagramas IP saldrán por una u otra interfaz logrando así nuestro objetivo. Sin embargo, existe otra alternativa a traceroute y que nos ayudará a afinar más. Si recordáis, cuando estudiasteis el protocolo IP habríais visto que en su cabecera existe un campo de opciones. De entre las opciones posibles, existen dos que permiten especificar la ruta que el datagrama IP deberá seguir de manera explícita, es decir, sin hacer caso de las tablas de rutas de los routers intermedios entre el origen y el destino. Si el router que estamos auditando acepta source routing, que es como se le conoce a esta característica del protocolo IP, podremos aprovecharlo para identificar nuevos interfaces y segmentos de red. Una manera de hacer source routing es utilizando Sing, como en el siguiente caso:

sing -tstamp cisco@10.13.1.1@wakeup.man@www.hicks.org

Eso sí, recordad que sólo nos permitirá hacerlo con paquetes icmp.

Pero la utilidad del source routing no termina aquí. Imagínese por ejemplo que alguien con malas intenciones, al que llamaremos Mallory, no logra atacar la red A porque está bien protegida por un firewall. Supongamos ahora que Mallory descubre que la red B tiene comunicación directa con la red A. ¿Qué le impide intentar utilizar source routing para lograr el objetivo de penetrar y atacar la red A pero en este caso a través de la red B?

Elyoenai Egozcue,
S21sec labs

Protección del software (Parte III)

Seguimos esta ligerísima introducción a la protección del software mencionando diferentes tipos de protección que nos podemos encontrar hoy día en las aplicaciones, tal y como comentamos en el post anterior.

Protección por keyfile.

En este caso, el programa necesita un fichero que cumpla ciertos requisitos para poder registrarse. Se puede considerar que es un caso concreto dentro de una protección por número de serie, pero la entrada de datos es un fichero en lugar del teclado, lo cual permite utilizar claves mucho más complejas.

Periodo de prueba de X días

Esto no se puede considerar una técnica de protección por sí sola, ya que siempre va asociada a alguno de las dos anteriores o asociado a un bloqueo de funcionalidades.

Como caso más genérico y fácil de entender podemos ver los casos en los que el programa suele anotar la fecha en que es instalado y, a medida que pasan los días, comprueba cuantos días han pasado, de tal manera que si han transcurrido los X días permitidos, caduca.

Como muchos habréis pensado, tan sólo cambiar la hora del sistema puede hacer que un programa muy muy mal implementado (desde el punto de vista de la seguridad) no caduque.

Versión limitada (Demo)

Esta vez a la aplicación se le han deshabilitado funcionalidades, y necesitamos tener la versión registrada para poder utilizar todo el potencial del programa.
Muchas de estas versiones de demostración se pueden registrar mediante un número de serie, y es muy común encontrar que el código que implementa la funcionalidad deshabilitada se encuentra en la aplicación pero, por ejemplo, las opciones del menú no se encuentran operativos..

Realmente me resulta curioso que si no pretendes dar una funcionalidad, la distribuyas con la aplicación pero desactivada. ¿No sería mucho más lógico no distribuirla y que cuando el usuario se registre pueda obtener una versión nueva totalmente funcional? Si por el motivo que sea te interesa ser pirateado, eso ya es otra cosa...

Necesidad de otro dispositivo (CD-ROM, USB stick...)

Estas protecciones generalmente tienen un objetivo distinto, que consiste en evitar la copia de un software completo, algo que queda fuera del enfoque de este artículo, pero también les echaremos un vistazo superficial.

En este caso nos encontramos que diferentes aplicaciones, como son los juegos, algunos programas de CAD, etc, que utilizan una técnica de protección mixta, parte software y parte hardware, ya que solicitan la introducción de, por ejemplo, un CD-ROM original, de un stick USB o una mochila conectada al puerto paralelo.

Estas protecciones pueden ser más fuertes que las basadas solamente en software, pero pueden no serlo si no están debidamente implementadas. Si se dispone de un dongle original, se puede intentar emularlo, o se puede intentar engañar a la aplicación para que crea que el dongle está conectado.

Si se va a proteger una aplicación mediante un dongle, es aconsejable que éste ejecute cierta lógica compleja y necesaria para la correcta ejecución de la aplicación. De esta manera evitaremos que el atacante tenga que lidiar únicamente con una comprobación de la conexión de un dispositivo.

En el siguiente post veremos algunas ideas muy genéricas que se deberían respetar al proteger una aplicación, siguiendo con la misma idea del programa que requiere contraseña para su registro.


Mikel Gastesi
S21sec e-crime

¡Si bebes no navegues!

Como bien sabéis, cualquier dispositivo que usemos tiene que estar protegido contra las amenazas del exterior, pero también contra las amenazas más próximas, en nuestra propia red. Estas amenazas internas son en muchos casos las más peligrosas, por tener casi todos los accesos abiertos y tener que adentrarse solamente en el último eslabón.

Pero, pensando un poco... algo que me llama mucho la atención es cómo nosotros mismos, el eslabón más débil, somos muchas veces los más peligrosos. Y ahora hablemos de los problemas asociados al alcohol, ¡y no hablo del software para grabar discos! (- ¿qué dice este? -).



Riesgos de la seguridad informática asociados al alcohol:

Primera situación (malware en el ordenador): típic@ que llega a casa sin haber pillado y ebrio hasta el gaznate. ¿Qué hace? Pues si se junta no tener demasiada concienciación acerca de la seguridad informática y tampoco tiene mucha conciencia por la ingesta de alcohol... aumenta el riesgo de acceder a sitios o correos inseguros en los que se descargará malware que le hará la vida imposible. Hay que saber controlarse incluso cuando la cabeza está descontrolada.

Segunda situación (spam): asociado a la situación anterior. No solamente llegas a casa bebido y con las hormonas alteradas para descargarte rápidamente un vídeo de naturaleza "poco ética", sino que mientras este se descarga te metes en 200 webs del mismo tipo, dando tu email a diestro y siniestro. Al día siguiente te despiertas, accedes a tu cuenta para ver quién te ha escrito y te das cuenta de que tienes 350 correos spam, phishing, ... y con los malignos esperando con los ojos como platos a que metas la pata.

Tercera situación (pérdida de datos personales): ¿cómo te puede haber pasado? Ahh, saliste del trabajo y directamente al bar con los amigos, ¿no? Y qué te dejaste, ¿el portátil? ¿la blackberry? ¿la memoria USB? Ya, te lo robaron, ¿no? ¿Lo tenías cifrado al menos? No me lo puedo creer. ¿En qué mundo vives? Sí, a todo el mundo le ha pasado, que te tomas una de más y te dejas algo, pero nos dejamos un jersey o, más habitualmente, nos dejamos las copas sin pagar.

Cuarta situación (redes sociales): ¿has pensado cuánto has bebido hoy? ¿Qué estás haciendo dándote de alta en todas las redes sociales que encuentras? Anda, ¿que ya te habías dado de alta la última vez que saliste de fiesta? ¿Y ahora qué haces? Claro, claro, alguien con fotos de modelo te ha escrito en Facebook porque le has gustado y quiere que os conectéis por webcam. ¡Vaya suerte, yo quiero algo así! Y como no tienes alteradas las hormonas ni nada vas a ir directo al grano. Primero la webcam (tranquil@, seguramente no te grabe y te extorsione con publicarlo en cualquier sitio), luego te manda un ejecutable (no te preocupes, es un juego superchulo...), y seguramente al final de la noche te acabes casando con él/ella. ¿O directamente te la cuelan? O puede que alguien use la webcam para hacer pública tu cara mientras crees que estás viendo a la persona con la que chateas (mediante software como este) y que luego las empresas te busquen por las redes sociales y sitios web y no te contraten por pestuzo.

Quinta situación (metedura de pata): llegas a casa con una mona de narices, entras por la puerta y vas de rodillas hasta la habitación cual creyente pidiendo un milagro, y no se sabe cómo eres capaz de encender el ordenador y conectarte a tu correo de gmail. Y, ¿cómo no? Mandas un email a tu novi@, ex-novi@, amig@, amante, lo que sea... ¡el típico mensaje que no enviarías en la vida si no hubieras bebido!

Por suerte, en este último caso hay una solución! Los chicos de google han sacado un plug-in para gmail con el que existe un bloqueo de la cuenta activando una pantalla que te obliga a resolver unas operaciones matemáticas sencillas en un tiempo limitado si quieres enviar tus mensajes a altas horas de la mañana. Es el primer paso, pero quizás sean necesarios otros pasos más para evitar estas meteduras de pata.

Por cierto, a ver si alguno se pone y saca algo parecido para Android y Symbian, que seguro que hay muchas peticiones para el móvil ;-)

Mucho cuidado con el alcohol, ¡y no solo en la carretera! Y que conste que esto a mi no me ha pasado, ha sido a un amigo...



Miguel López-Negrete
S21sec labs

Otra amenaza a la navegación web ... el clickjacking

Hace unos días se celebró en Nueva York la world OWASP conference, y en ella, los investigadores Jeremiah Grossman y Robert "RSnake" Hansen iban a presentar un trabajo en el que exponían las particularidades y los peligros de una técnica denominada clickjacking. Días antes del inicio de la conferencia decidieron cancelar la presentación a petición de Adobe, ya que la vulnerabilidad afectaba software de esta compañía y a la mayor parte de los navegadores web del mercado, y posponer los detalles hasta contar con una solución al problema.

Obviamente, aunque no se han revelado en profundidad los detalles de la vulnerabilidad, durante este tiempo han ido surgiendo continuas especulaciones, pruebas y opiniones de todo tipo. El clickjacking consiste en que los atacantes ocultan elementos maliciosos dentro del contenido de una página web legítima posibilitando el 'robarle' los clicks al usuario permitiendo así ejecutar código malicioso o realizando acciones en nombre del usuario. Realmente, más que una vulnerabilidad propiamente dicha de los navegadores o de otro tipo de software, parece una peligrosa técnica de ingeniería social que se puede llevar a cabo sin que el usuario final sea consciente de ello. Giorgio, el creador del add-on noScript para Firefox ofrece algo de información sobre el tema en su blog, y parece ser que precisamente el add-on noScript es, hoy por hoy, una de las formas más eficaces de intentar evitar el clickjacking. Aunque la vulnerabilidad por clickjacking no tiene porque estar basada en javascript, si que el uso de scripts hace que el 'robo' de clicks sea mas sencillo y eficaz. Por otra parte, la última versión de noScript, la v 1.8.1.9, que aún está en versión de desarrollo, permite bloquear los iframes y también los elementos embebidos tipo OBJECT, con lo cual se obtiene una mayor protección contra el clickjacking. Eso si, más de la mitad de sitios web que habitualmente visitamos contiene javascript y alrededor del 10-20% contienen iframes, con lo cual, protegiéndonos con noScript no veremos la mayoría de sitios web que visitemos como, en principio, han sido diseñados para que los veamos, o incluso puede que algunos no los podamos ver. Siempre nos queda la posibilidad de permitir los scripts y los iframes en sitios que queramos visualizar correctamente pero ... ¿podemos estar 100% seguros de que los sitios que permitimos no están comprometidos?.

Guzmán Santafé
S21sec labs

Ampliando la colección: 3alupko

Dentro de la "colección" de especímenes de Paneles de Control que encontramos en el departamento de eCrime, el otro día dimos con un elemento poco habitual: el panel conocido como Zaplupko (o 3alupko). Aunque se trata de un panel de control que ya hemos encontrado en otras ocasiones, vamos a aprovechar la ocasión para presentarlo en el blog.

En este caso la localización del panel fue gracias a una alerta de MSS que saltó en uno de nuestros clientes apuntando a una dirección IP supuestamente sospechosa. Al acceder a la misma, los directorios del servidor web eran públicamente listables, mostrando toda la estructura de directorios. Navegando por el mismo detectamos varios paneles de tipo AdPack, varios binarios (algunos de ellos detectados como el malware "XP Antivirus 2008"), y el panel protagonista de este post: 3alupko.



Las principales características del malware que acompaña a este panel son:

• Captura de tráfico FTP
  
  
• Captura de tráfico HTTP
  
  
• Captura de tráfico POP/SMTP
  
  
• Captura de formularios (POST/GET)
  
  
• Captura de tráfico certificados
  
  
• Socks Proxy 4/5
  
  
• MiniAV, borra BHO’s y archivos de otro malware presente en la máquina infectada (como wsnpoem)
  
  
• Inyección de código
  
  
• Tareas (ejecutadas por los bots)
  
  
• Builder (nuevas versiones de malware)
  
  
• Estadísticas de Bots
  

Existe un sitio "oficial" para el panel de control: http://zalupko.info

Comparando el archivo de ayuda que se encuentra en el panel de control detectado con el que se encuentra en el sitio "oficial", parece que el texto es exactamente el mismo. Sin embargo, el documento del "oficial" tiene capturas de pantalla que parecen del panel de control "snake" . De este modo, se establece una relación entre ambos.

Y no sólo eso, sino que el número de contacto de ICQ del autor del malware y su alias (‘shshsh’ o ‘_sh_’) también se ha detectado en foros relacionado con la venta de "snake" (o load.cc).



En definitiva, una muestra más de la interrelación entre este tipo de grupos.

Para finalizar la historia, se pasó la información para la implementación de reglas que eviten la infección en los clientes de MSS y tomamos buena nota del caso para reutilizar el conocimiento obtenido en el servicio de análisis remoto.

Como apunte final, el nombre del panel ya da algunas pistas acerca de su posible origen. En este caso, parece ruso y realizado por algún "script kiddie":

3alupKo = Zalupko = palabra rusa para denominar "pene" vulgarmente

Vicente Díaz
S21sec eCrime

Trojan Sinowal

Recently we did some research about the Trojan Sinowal (also known as Torpig). These days it is one of the most famous and common malware variants with the main objective to steel bank account information. A big difference to other Trojans is that the main infection is made into the MBR - thus making it more difficult for AV's to detect it. More information about the history and the way of infection can be found at the GMER website.

The main purpose is to steal bank account information in a professional manner. The config file which can be found in 'c:\windows\temp' showed that more than 1000 banks are affected.

Recent versions of the Sinowal Trojan hook functions in advapi32.dll, wininet.dll and crypt32.dll used by the Internet Explorer. Thus external code can be injected into the web content which is then presented to the user. In general the Sinowal Trojan checks for the requested pages in the browser, and depending on a match (e.g. a URL of a bank defined in the config) it loads additional content to inject from its own malware servers. The communication with these servers is made with encrypted POST/GET request to receive the content to inject. The collected and stolen account information is sent using SSL.

In order to find its servers the malware requests domain names based on a special algorithm. Thus an infected machine requests different domain names to find a host which is alive and can provide the requested data.

For a fast check and for disinfection of the Sinowal Trojan also GMER can be used.

Clemens Kurtenbach
S21sec labs

Y otro más...

Otro uso fraudulento de información, esta vez en Japón contra una web de subastas online. Al parecer los hechos ocurrían desde el mes de mayo en la página de subastas de Yahoo! Japón. Consiguieron las identidades de usuarios japoneses y vendieron productos de lujo falsos en su nombre, quedándose el dinero de dichas ventas... y los dueños de las cuentas las correspondientes facturas por la mediación en la subasta.

[1]
[2]

Eduardo Morrás
S21seclabs