AVISO: Nos hemos integrado con Facebook y Twitter. Ahora, podrás decir si te gusta o no uno de nuestros artículos con tu usuario de la red social. También podrás difundir los artículos que más te gusten a través de cualquier medio. Ayúdanos a que los artículos sean más interesantes dándonos tu opinión. Gracias.

miércoles, 29 de septiembre de 2010

El malware surfea los adelantos tecnológicos.

Siempre se ha comentado que los cambios tecnológicos afectan a la sociedad: televisión, teléfonos, internet. etc. Todos y cada uno de ellos han variado nuestra forma de percibir nuestro entorno y la manera de comunicarnos con este. Con cada cambio, siempre viene asociado una adaptación de los elementos existentes a los nuevos medios de los que se dispone y estos cambios a veces no se realizan tan rápido como la tecnología avanza. Seguro que os estáis preguntando a que viene esta disertación de los cambios. Viene a cuento de la implementación de medidas de seguridad.
Uno de los entornos que más ha apostado por su incorporación a Internet es el entorno bancario. Atrás quedan sus inicios donde su seguridad se basaba en SSL y autenticación por usuario y contraseña. Eso si, para no molestar mucho a sus clientes, una contraseña de 4 dígitos como en las tarjetas de crédito de los cajeros. Con el tiempo, se fueron dando cuenta que los "malos" no eran tan tontos como para no averiguar por fuerza bruta esos dígitos, así que empezaron a poner elementos que dificultasen los ataques. Bloqueo de cuentas, tarjetas de coordenadas para operaciones sensibles, teclados virtuales para introducir la contraseña, etc. Y bueno, los malos, como deben disponer de mucho tiempo e ideas, iban reaccionando a las medidas de seguridad implantadas: Phising para evitar el bloqueo de cuentas y conseguir las tarjetas de coordenadas, troyanos instalados en los equipos de los clientes para capturar las pulsaciones del teclado y del ratón, etc. Y bueno, el ciclo se volvió a repetir. 
Las cabezas pensantes del entorno bancario empezaron a pensar en utilizar algo que el usuario no conociese hasta el momento de utilizarlo. Y, ¿cómo conseguir eso?. Con un dispositivo que el usuario disponga y que pueda recibir comunicaciones para poder obtener el código aleatorio generado por el propio banco. La solución es simple y elegante, y permitía tener un elemento fuera del alcance de los "malos". Pero aquí es donde la tecnología muchas veces avanza sin contar con las implicaciones de seguridad de los sistemas que las utilizan. Es decir, todos ya hemos oido que los teléfonos móviles empiezan a tener los primeros virus. Si bien esto puede parecer que carezca de importancia más allá de mandar SMS o robar la lista de contactos, puede tener un riesgo mayor del esperado.
Los nuevos terminales con sistemas operativos como Android o las propias Blackberrys, permiten la instalación de aplicaciones desde internet. Imaginemos por un momento el siguiente ataque:
  1. El usuario se infecta con un troyano especializado en Banca. (las causas o motivos pueden ser muchos)
  2. El usuario accede a su página de banca oline.
  3. Al usuario se le pide el usuario y contraseña.
  4. Una vez introducidos, se le pide el modelo y el número de teléfono (cualquier excusa es válida)
  5. El usuario que no ve ningún problema en ello, los proporciona, y acto seguido recibe un SMS de parte del "banco impostor" que le pide que descargue una aplicación para firma electrónica. Esta aplicación es un malware.
  6. Una vez que el atacante tiene controlado el ordenador y el móvil, las protecciones basadas en el envío de un SMS para realizar operaciones ya no tienen efecto. El malware del teléfono es capaz de interceptar los SMS que recibe con los códigos del banco, reenviarlos a sitio del atacante y utilizarlos sin que el usuario se percate de la recepción de esta información.
Si le ha costado un poco imaginarse este ataque, quizás prefiera ver una prueba documentada en la siguiente web (pinche aquí - Está en Inglés). Volvemos otra vez a comenzar el ciclo de protección.
Finalmente, aparecerán los teléfonos que lean las huellas dactilares o utilicen mecanismos biométricos para validación de datos o descifrado de los mismos. Pero, ¿qué fallos podrán inventar los "malos" para seguir en el juego?
Este post espero que nos haga reflexionar sobre la inversión que se realiza en mecanismos de seguridad. Esta inversión no solo debe ser inicial, sino mantenida a lo largo del tiempo.

martes, 14 de septiembre de 2010

Perl y Kinosearch

Tras muchos artículos alejados del mundo técnico estricto, volvamos a la programación en Perl. Me he visto envuelto en el desarrollo de una utilidad que me permitiese realizar migraciones de datos de unos repositorios a otros. Si bien puede parecer algo sencillo, la cosa se empieza a complicar cuando los datos no son del mismo tipo, hay que hacer transformaciones e incluso hay tablas destino que se componen de varias tablas origen.
Si bien las consultas SQL pueden realizar gran parte de las selecciones y agrupamientos, acaba siendo poco versatil para todas las transformaciones necesarias.
Al final, la solución más sencilla es procesar ficheros CSV y transformarlos en otros CSV o en sentencias SQL que permitan introducir los datos directamente en la base de datos destino. Pues bien, en esta herramienta que al final creo que ha salido bastante completa, incorporé la comprobación de una serie de condiciones. Para una de esas condiciones, la de unicidad, requería saber si un mismo dato había sido ya procesado (por ejemplo un DNI). Que si, que se podría haber utilizado un select distinct para evitar la duplicidad de DNIs, pero que sucede cuando los DNI no tienen un formato estanda y pueden estar como xx.ddd.sss-v o xxdddsssv o xxdddsss-v, etc. Al final la cosa comienza a complicarse tanto que una solución a base de SQL sin tener una calidad de datos decente se hace imposible.
Como he comentado, al final, para dar solución la utilidad acaba limpiando los datos y transformándolos de acuerdo a unos patrones lo que permitía después poder consultar las condiciones sobre los datos ya estandarizados. Y que manera se me ocurrió para hacer las consultas teniendo en cuenta que podría llegar a procesar ficheros de varios miles de líneas? Mantener tal cantidad de información en memoria es algo inviable, así que opté por el uso de una "BBDD" o lo que más se pareciese. Después de valorar usar DBF o incluso un fichero Access, me decanté por la solución Lucene. 
En Perl, hay un par de proyectos que implementan la portabilidad de Lucene. Estos son Plucene y Kinosearch. Si bien Plucene es una portabilidad puramente en Perl, Kinosearch es más rápido que su hermano Plucene. Si buscas en Internet hay algún estudio de benchmark con la librería de Java, Plucene y Kinosearch. 
La única pena de utilizar Kinosearch es que el indice no es compatible con Lucene, pero bueno, para el uso que se le debía dar era suficiente. Si tuviese otros requerimientos quizás la solución escogida hubiese sido otra.
Una de las cosas que hubiese estado bien que incorporase las librerías de Kinosearch es que detectase la existencia del indice para crearlo o añadir más campos al mismo. Si bien es fácil de implementar una función que lo haga, es algo que debería haber estado incluido.
Al final, tube que generar mi propio generador del indice con la sigiuente función:
sub get_indice ()
{
      my ($nombre) = @_;  
      $create = (-d './index/'.$nombre)?0:1;
       my $invindexer = KinoSearch1::InvIndexer->new(
        invindex => './index/'.$nombre,
        create   => $create,
        analyzer => &get_analizador(),
    );
    return $invindexer;
}

En conclusión, las búsquedas teniendo un índice de 8000 registros y 14 campos cada registro no tardan más de 0,2 segundos, cosa que es de agradecer cuando procesas miles de registros. Además, la herramienta funciona tanto en Windows como en Linux, consiguendo una portabilidad más que suficiente.
Posiblemente, en un post futuro exponga la arquitectura de la herramienta por si puede ser de interés a alguien.