Colaboramos con el Gobierno de Reino Unido en su apuesta por la Ciberseguridad

miércoles, 30 de noviembre de 2016

Últimamente hemos leído en la prensa que el Gobierno del Reino Unido va a invertir más de 2.000 millones de euros a lo largo de los próximos cinco años para mejorar la Ciberseguridad del país, lo cual se suma a la apuesta equivalente de la Unión Europea, la cual anunció la liberación de 450 millones de euros en los próximos tres años dentro de un programa que generaría inversión por valor de 2.000 millones. En clara tendencia dentro del contexto global, en el que las inversiones en Ciberseguridad a nivel mundial van a crecer desde los 75.000 millones del año 2015 hasta los 170.000 millones de dólares estimados por los analistas de mercado para 2020.

Una de las iniciativas del programa aprobado en Reino Unido consiste en la creación de dos nuevos centros de incubación de ideas innovadoras, que sean capaces de desarrollar nuevas soluciones aplicables al tratamiento inteligente de los datos, herramientas que refuercen la seguridad de los dispositivos y aplicaciones que los ciudadanos utilizan ya masivamente online, y que minimicen las posibilidades de sufrir ataques cibernéticos a todos los niveles.

El GCHQ (Government Communications Headquarters), quien ya a través de su página web busca y recluta de forma activa nuevos talentos para luchar contra los ciber-delincuentes, recientemente seleccionó a Telefónica para poner en marcha el primero de los centros de innovación e incubación de startups. Este proyecto reconoce y avala la gran experiencia que Telefónica tiene en crear estos centros de innovación a través de su programa Open Future – Wayra y también en el ámbito de la seguridad a través de ElevenPaths, la unidad de Ciberseguridad del Grupo Telefónica, quien ya viene colaborando estrechamente desde hace mucho tiempo con otras entidades como INCIBE y OEA, o siendo miembro de grupos y organizaciones sin ánimo de lucro como la ECSO, desde donde la industria complementa y acompaña a las instituciones públicas en el desarrollo de la seguridad en el ciberespacio.

Sede GCHQ en Reino Unido

Otra buena noticia es que ya se empiezan a seleccionar candidatos, y una de las primeras empresas que van a formar parte de este programa será CounterCraft, cuya innovadora filosofía se basa en contrarrestar a los ciberdelicuentes no sólo repeliendo sus ataques, sino aprovechando de manera inteligente la información que tenemos sobre su ataque para confundirlos y controlarlos. Es decir, se trata de una empresa que desarrolla herramientas y métodos para contrarrestar los ataques cibernéticos a través de la contra-inteligencia.




Me reconforta saber, como ciudadano europeo, que los gobiernos de este continente se empiezan a preocupar seriamente por la Ciberseguridad y creo que esta iniciativa contribuirá a posicionarnos posiblemente como un referente de innovación comparable a los Estados Unidos, Rusia o Israel. Además posibilitando que emprendedores de nuestros países puedan desarrollar sus ideas, impulsar su negocio y contribuir a la seguridad general del país, protegiendo a empresas y ciudadanos en el nuevo entorno digital. A día de hoy, sin duda EEUU lidera todos los rankings de inversión, con un foco claro en el área de Silicon Valley que se complementa con Nueva York, Boston y Austin. Fuera de los Estados Unidos, las ciudades con mayor crecimiento en inversión de Ciberseguridad son Londres y Tel Aviv, tal y como nos confirma Zach Cutler en uno de sus artículos.

Espero que esta iniciativa además de contribuir a mejorar la seguridad informática en nuestro entorno profesional y personal sea también un aliciente para que Telefónica consiga posicionarse en el Reino Unido como un actor relevante en este campo y alcanzar el nivel de desarrollo de negocio en Ciberseguridad que ya tiene en España y en muchos de los países latinoamericanos.

Pedro Pablo Pérez
CEO de ElevenPaths
@ppperez


*También te puede interesar:
Wayra UK impulsará el desarrollo de tecnología de ciberseguridad en el Reino Unido
Telefónica se integra como la única telco en los órganos de decisión de la Organización Europea de Ciberseguridad

ElevenPaths Talks: Inseguridad en dispositivos móviles iOS

martes, 29 de noviembre de 2016




El próximo jueves 1 de diciembre nuestro compañero Diego Espitia y un invitado especial impartirán una charla sobre Inseguridad en dispositivos móviles iOS en la que explicarán la arquitectura de iOS para conocer y comprender mejor qué precauciones y consideraciones tomar tanto si eres usuario de esta tecnología, como si eres desarrollador de apps.

La duración de la charla de Diego será de unos 30 minutos, divididos entre 20 y 25 minutos de exposición y de 5 a 10 minutos de preguntas y respuestas. El horario de la charla será a las 15.30h (Madrid) y estará disponible al termina ésta en nuestro canal de YouTube. La ponencia se llevará a cabo por Hangouts y se impartirá en castellano.

Si quieres saber más acerca del tema, no dudes en pasarte por nuestra Comunidad, donde nuestros compañeros hablan sobre éste y otros temas de interés en el mundo de la Seguridad. Puedes consultar el calendario de talks para ver los webcasts que aún quedan por celebrarse. Recuerda, tienes una cita el próximo 1 de diciembre a las 15.30h (Madrid)Para registrarte debes usar el siguiente formulario de ElevenPaths Talks.


Más información en:
talks.elevenpaths.com

Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (III)

lunes, 28 de noviembre de 2016


En esta serie de artículos se realizará un repaso a la literatura académica en la que se mezclan estos dos conceptos: malware y algoritmos evolutivos. Analizaremos de forma crítica qué trabajos y artículos se han presentado en orden cronológico durante los últimos años, para comprobar si realmente tiene sentido utilizar los algoritmos genéticos para mejorar cualquier aspecto de la lucha contra el malware, ya sea en detección, análisis, predicción… Veremos un buen montón de experimentos basado en la algoritmia evolutiva, que a su vez también resulta apasionante.

Desde la última recopilación de 2009, se han vuelto a realizar diferentes experimentos que mezclan algoritmos evolutivos como herramienta para mejorar de algún modo la detección y clasificación de malware. Mostramos a continuación un resumen con espíritu crítico de nueve artículos académicos relativos a la materia, publicados todos de 2010 en adelante y en orden cronológico.

Malware Detection based on Dependency Graph using Hybrid Genetic Algorithm

Keehyung Kim y Byung-Ro Moon presentan en 2010 un mecanismo de detección de malware de script analizando los grafos de dependencia. La idea es modelizar el grafo de dependencia del malware (fundamentalmente creado en Visual Basic Script), y transformar el problema de detección en el de encontrar isomorfismos entre subgrafos de distintas variantes. Así, aunque el malware mute (modifique código con el fin específico de eludir una firma concreta), si mantiene la esencia de su estructura (algo necesario para garantizar su funcionalidad), podría ser detectado aunque el creador se esfuerce en eliminar su "firma". 

Lo interesante del experimento es resolver el problema de máximo isomorfismo entre grafos. Dos grafos lo son si se encuentra una biyección entre vértices que preserva la adyacencia entre nodos. Se desconoce un algoritmo éptimo (sin recurrir a la fuerza bruta de comprobar las n! biyecciones de nodos). Así que se recurre a algoritmos genéticos para solucionarlo en tiempo razonable.



La elección de malware de script permite disponer de su código tal y como fue escrito por el atacante. En el estudio se trata, calcula y reduce el grafo de cada script (en el que cada nodo es una línea de código). Este se compara entre un candidato a malware, calculando su máximo isomorfismo. Si sobrepasa un umbral, se pasa a un algoritmo genético que intentará clasificarlo como malware o no. El algoritmo utiliza una representación lineal de los vértices para trabajar. Como función de fitness, se evalúa la diferencia entre aristas. Una diferencia de cero, denotaría que un grafo es un completo subgrafo de otro, y por tanto a menor diferencia, mejor fitness (se ha encontrado un programa que, aunque "disfrazado" sigue el mismo flujo). Para elegir a candidatos se utiliza la ruleta y para la mutación, se muta con probabilidad 0.2 el intercambiando genes (que representan la posición de la arista en la disposición). Al margen del algoritmo genético, se utilizan dos aproximaciones heurísticas para optimización local. La primera intercambia aristas al azar. La segunda simplemente reorganiza un vértice insertándolo en otra posición.

En los experimentos usan la heurística (más rápida) como parapeto antes del algoritmo genético, obteniendo un buen resultado con ella simplemente. Para contrastar la eficacia de su sistema, la habitual comparación contra los antivirus sugiere que el algoritmo mejora el ratio de detección con respecto a la mayoría de motores. 

El estudio no resulta demasiado interesante desde el punto de vista de la detección del malware en sí, tal y como está enfocado. Por diversas razones:

  • Para que los resultados de uso de simple heurística sean alcanzados por el algoritmo genético, se utilizan 2000 generaciones como criterio de parada, lo que supone un coste computacional mucho mayor. No se ofrecen comparativas de tiempo al respecto en el artículo, pero se menciona que el coste de GA puede ser prohibitivo para sistemas que demanden una rápida respuesta. De hecho, en las propias conclusiones menciona que quizás podría utilizarse este mecanismo más lento para situaciones que no demanden una respuesta tan rápida, como la detección de copia de software en general. 
  • El uso en malware de script resulta en cierta manera ingenuo. Las muestras recogidas son muy simples (5 muestras), con cambios muy sencillos en su poliformismo (18 variantes en total). Más allá de los resultados, lo más interesante del estudio resulta la adaptación del software de script a grafos, el trabajo de su reducción y comparación buscando el isomorfismo.

Optimizing Decision Tree in Malware Classification System by using Genetic Algorithm

En este artículo, se utiliza un algoritmo genético como sistema de aprendizaje. En el estudio se intenta no tanto detectar malware, sino clasificar dentro de cuatro clases: Si la muestra estudiada ataca a los datos, aplicaciones, sistema o red. Lo llaman "Anti-Malware System Classifier".

Se utilizan tanto árboles de decisión como un algoritmo genético para comparar resultados. La metodología consiste en clasificar las muestras aleatoriamente dentro de los cuatro grupos y calcular el fitness con la media de los pesos de cada individuo en el grupo. Se usan técnicas estándar para la mutación y cruce. De un total de mil ejemplos, se intentan clasificar 200, tomando 20 comportamientos sospechosos (analizados tras la ejecución en una máquina virtual) como base de características para su clasificación. Los resultados globales mejoran (tras pasar por el algoritmo genético de clasificación) los resultados del árbol de decisión.

Este documento se complementa con la descripción del framework creado para poner en práctica los experimentos, y descrito (aunque de manera muy somera) en "A Framework for Optimizing Malware Classification by Using Genetic Algorithm" de 2011. El artículo resulta pobre en la descripción de detalles. La clasificación mejora con respecto a los árboles de decisión, pero solo para cuatro grupos y muy levemente. En el mejor de los casos se llega al 97% de precisión, con una tasa de falsos positivos excesivamente alta. 



Además, la clasificación del malware de esta forma (basada en qué ataca) no resulta tan interesante como la detección en sí misma.

Adaptive rule-based malware detection employing learning classifier systems

Se trata de una tesis en la que se analizan y experimenta con diferentes técnicas para la detección de malware basadas en árboles de decisión (usando el algoritmo C4.5) y LCS (Learning classifiying system) basados en algoritmos evolutivos (usando a su vez una variante de XCS para definir su fitness). En los algoritmos LCS las reglas son la población del algoritmo, y se centra en definir el mejor clasificador en ese conjunto de reglas. En cierta manera, un trabajo mucho más elaborado que los anteriores por su extensión, complejidad, minuciosidad, número de muestras empelados e intención específica de mejora. Compara el rendimiento del LCS (una adaptación propia de XCS) con diferentes métodos de inicialización, población, etc. La caracterización de las muestras (como es habitual) viene del estudio estático de funcionalidades propias de los archivos ejecutables. Aquí, son interesantes las siguientes conclusiones:
  • LCS mejora la generalización con respecto a C4.5, y detecta mejor malware previamente no visto.
  • LCS no sufre tanto del problema de límite de dimensionalidad que afecta a C4.5

Para los diferentes experimentos, LCS se inicializa con tres métodos diferentes: aleatorio, "covering" (se van creando reglas por cada fichero que llega y no queda clasificado) y la inicialización con C4.5, que parte de un conjunto de reglas ya generadas con ese algoritmo y mejoradas usando la función específica. Luego se usa C4.5 de nuevo como base comparativa.




Sin embargo, el estudio parece basarse en unos datos muy pobres y por tanto no puede tomarse como representativo: todo el malware usado proviene de la familia Poison Ivy. Esto es el cliente de un conocido troyano y por tanto sin diversidad. Sería comparable a crear distinto malware (en el sentido de un fichero con hash diferente) desde un mismo programa. Posee la capacidad de mutar, pero su funcionalidad es fundamentalmente la misma con unas características concretas que lo definen y que por tanto, ya usan los motores antivirus como firmas de los antivirus para detectarlo eficazmente. Aunque no se compara específicamente contra sistemas antivirus, es más que probable que los motores consiguieran resultados más que aceptables ya con sus sistemas de firmas. Además, en el estudio no se habla del tiempo necesario para la creación de reglas, que puede ser de nuevo un impedimento para su uso en tiempo real.

* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (I)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (II)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (III)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (IV)

Sergio de los Santos
ssantos@11paths.com

ElevenPaths participamos en el F5 Fórum Madrid

viernes, 25 de noviembre de 2016

Los últimos meses del año suelen concentrar mucha actividad en el mundo de los eventos y conferencias de seguridad. El próximo 30 de noviembre se celebra en Madrid el evento F5 Fórum Iberia, una jornada que desde ElevenPaths compartiremos junto con los principales socios tecnológicos de F5, como Cisco, FireEye, Gemalto, Microsoft, y Splunk.


Durante el evento participaremos en las distintas sesiones tecnológicas con el fin de mostrar nuestras soluciones de seguridad. La alianza de ElevenPaths con F5 amplia la integración de nuestra tecnología Vamps con sistemas WAF que permite el parcheo en caliente de vulnerabilidades. Esta integración proporciona la capacidad de aplicar una técnica de Virtual Patching sobre su infraestructura. De este modo las vulnerabilidades detectadas por Vamps se mitigan automáticamente con la tecnología F5 BIG-IP ASM, lo que evita los ataques que emplean estas vulnerabilidades como vía de entrada. Esta integración automática consigue reducir el tiempo de exposición de las vulnerabilidades drásticamente, pasando de emplear días o semanas para solucionar una vulnerabilidad a horas o minutos.

ElevenPaths participamos también con un stand donde puedes conocer nuestra tecnología para la gestión de vulnerabilidades, con una mesa redonda con nuestro experto Víctor Mundilla, una demo de soluciones de seguridad F5 y la integración con soluciones líderes de mercado así como la presentación de soluciones con la aplicación de un caso de uso.

Si estás en Madrid, ¡no puedes faltar! Aquí puedes registrarte.

¡Nos vemos allí!

Take part in Latch Plugins Contest with such hacks as Paper Key. Are you game?

jueves, 24 de noviembre de 2016

At Elevenpaths there is a tradition of developing innovation and training the ability to transform an idea into something tangible, as you might know that in development process, projects often have “asymptotic” completion times

Every six months we are challenged to develop an idea for 24 hours in a row, put it into practice and then present it in public. It can be anything, but the important thing is that it works. We call it Equinox.

In the Equinox of Fall of 2016, a group of colleagues (Jorge Rivera, Pedro Martínez, Alberto Sánchez and Félix Gómez) wanted to unite the abstract, the logical security, with the specific, something that you could touch. And we thought that, at the same time, we could use the technology of Latch and the new API developed this year (the “operation instances”- Latch SDK).

From there, the Paper Key project was created, with which we wanted to unite different technological pieces, prioritizing the security of the whole process, and abstracting the technology, so that the use is simple and intuitive.

The idea is to be able to issue a token that gives access to a service or device. This token is printed on paper (which I have) and is only valid when the token Issuer authorizes its use from the Latch application (second authorization factor).


In our real example, a person can print a ticket with an associated amount of money, and after authorizing the operation in Latch from their mobile, a second person exchanges the ticket in an automatic wallet, which will deliver the indicated amount of coins.

The whole process involves two people (the Issuer and the Recipient) and four technology blocks: the web application, the ticket printer, the API Python server, and the ticket reader + wallet.

The Issuer, from a web application, generates a ticket with an operation identifier and an amount of money. The operation is associated with the Issuer’s Latch account, and the ticket is sent to the Recipient by physical means, or with the printer that is in their environment.


When the Recipient wants to consume the ticket (in this case, get an amount of euros from an automated wallet), they approach a ticket reader, which will check the status of the authorization in Latch. As long as the ticket Issuer does not authorize the operation, the service cannot be accessed or consumed, and a notification will also be sent to their Latch app that someone is attempting to use the ticket (which is the standard behavior).

The architecture used in this proof of concept could be optimized, but since we had to finish all developments in 24 hours, we needed to share the work among the four of us. (This approach also allows the server, printer and ticket reader to be distributed in different locations, since they communicate with each other via the Internet).

Taking into account the premises of Equinox (24 hours, that it works and that it can be explained!), we describe the different components in more detail.

The WebApp
It is a simple application in PHP with an interface in liquid HTML that allows to adapt the forms to the different sizes or orientations of the screen of mobile telephones.

The application runs on a WAMP server and communicates with an API in Python to interface with the printer and the ticket reader. It is a standard PHP application, where users are authenticated by user and password against a MySQL generating a session token. You can find a lot of examples on how to do this on the website.

The WebApp allows the user to browse, and after being validated, to select an amount of money and write a free text to identify the operation. This information is sent via a POST to a Python server, which will generate a request for the printer.

The response of the server with the API in Python is a JSON that we parse in the PHP server to return the response to the WebApp:
{
status: [Ok/NOK]
money: [amount of money – to inform the WebApp]
id: [Identifier returned by the server – for the WebApp]
}


In the response of the POST we receive the status of the operation and the ID generated to enter it on the screen of the Issuer’s phone.

The ticket printer
This subsystem consists of a Raspberry Pi and a thermal ticket printer. The printer (Brother QL-570) was kindly lent to us by the Secretariat team, and we got the Raspberry from the IoT Security lab, which has enough hardware to play with.


The Raspberry is connected to the Internet via Wi-Fi, and it waits in a port for a REST request with the contents it has to print ( “generateID” operation.)

{
instanceId: [Latch instance ID]
money: [amount of money in Euros]
}


A two-dimensional QR code is generated with the libqrencode library, and with the Image Magic’s libraries, the code is superimposed over a pre-established background with the “Equinox” logo. Then, the text is added to the request, in this case the value of the generated ticket.


The final ticket will be printed with the Raspberry PI thanks to the printing pseudo-driver for this printer, available in Git-Hub.

The QR code is an operation identifier encoded in Base32, and will allow the QR code reader to check the authorization status of the operation before providing money (1 Internet Point goes to the one that tells us why we had to use Base32 instead of Base64).

The Python API server
On this server we can find the API in Python for Latch (interface between the WebApp, the printer, the ticket reader and the Latch server) and the WAMP server.

The server is invoked by the WebApp, using a POST to port 1338, with the fields:

{
money: [amount of money in euros]
text: [string of text that will appear in the Latch app]
}


Two operations are now executed sequentially:
1. The server creates a request via the API to request the “operation instance” to the Latch system of Elevenpaths, so that in the Latch app associated with the user, a new line will appear with the text identifier of the operation. This operation is now subject to the authorization of the user, is “latched”.


And in the interface of the phone app ... we find, within the PaperKey service, a new “operation instance” with the entered text “Equinox Demo 2016”.

2. The server invokes the ticket printer (IP and port of the Raspberry associated with the printer) so that the ticket is printed with the QR code associated with the operation. At this moment, the Issuer has generated an operation in Latch, and also has printed a paper ticket with a QR code that identifies said operation.

If the Recipient of the operation (that person who physically takes the ticket) would like to use it, they must wait for the Issuer to authorize such operation.

Ticket reader + money bank This system is composed of another Raspberry Pi (in the cardboard box), a laser QR code reader, like those in supermarkets and a colorful coin dispenser (we told you they have a lot of toys).

The laser reader is presented by USB as a standard HID keyboard, so that to transmit information to the operating system it simulates keystrokes corresponding to the scanned code (digits or characters).

This posed an interesting problem with the terminal. In order to be able to capture keystrokes without the STDIN of the process - since this would be in its console, not being available from a process launched in a pseudo terminal - we used a wrapper programmed in C that intercepts the events of the device that presents the Linux kernel in user space /dev/input/event5.

And this caused us a second problem, since the operation identifier we use has alphanumeric characters with uppercase and lowercase, and the keyboard emulation of the scanner is always with characters that do not require simultaneous keystrokes (e.g. [SHIFT] + Letter.) So we had to do a code conversion to Base32 (which collaterally increases the size of the string, so the density of the QR code must be increased as well.) If you have read this, we will not give you that Internet Point. After all the twists and bumps, we have an operation identifier. From the Raspberry, we build a JSON request, and launch it against the API Python server as operation “checkID.”

{
Id: [Operation identifier]
}


The server sends a query to Latch, providing the operation ID associated with the user. If the operation is “latched” (“Latch ON”), the system will return an error.

If the operation has been unlatched (“Latch OFF”), the system will consider the operation as authorized and will proceed to provide the amount of money indicated in the automatic wallet. The wallet is connected to the Raspberry Pi by USB, and it receives the amount of coins to dispense with a code of 4 digits.

Taking part in Latch Plugin Contest
Paper Key, as proof of concept, allowed us to prove that it is simple (we did it in 23.5 hours!) to integrate different technologies to achieve a secure and user friendly system with many use cases, depending on the imagination of each person.

For example, lockers containing a product provided by the Issuer and that can only be opened by the Recipient, upon confirmation of payment received by the Issuer via their Latch. Or one could issue tickets for a free bar: only when the party responsible (to pay) decides so via their Latch, the tickets can be validated in exchange for drinks. One can also give one-time access (OTA) to a facility, for example, give free trial days of access to a gym.

As you can see, a lot of things can be done with relatively simple integrations.

We would like to take this opportunity to remind you that a few weeks ago ElevenPaths convened a new edition of the competition Latch Plugins Contest. In this contest you can win up to $ 5,000; remember that what is rewarded is the imagination, talent, creativity and solution provided. If you want to know all the steps to follow to register, visit our Community, where we explain how to participate and where you can find tricks, tips, and also join the conversation about the Latch Plugins Contest. In addition, if you want to know all the mechanics of the contest, you will also be able to check the legal terms and conditions.

Remember that the deadline of the contest is December 12, 2016, show your hack side and participate now!

*Related content:
Latch Plugins Contest: the plugins and hacks contest in which you can win up to 5,000 USD
Latch Plugins Contest: Remember the story!

Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (II)

miércoles, 23 de noviembre de 2016

En esta serie de artículos se realizará un repaso a la literatura académica en la que se mezclan estos dos conceptos: malware y algoritmos evolutivos. Analizaremos de forma crítica qué trabajos y artículos se han presentado en orden cronológico durante los últimos años, para comprobar si realmente tiene sentido utilizar los algoritmos genéticos para mejorar cualquier aspecto de la lucha contra el malware, ya sea en detección, análisis, predicción… Veremos un buen montón de experimentos basado en la algoritmia evolutiva, que a su vez también resulta apasionante.

A finales de 2009, se realiza un trabajo similar recopilando hasta esa fecha los artículos presentados que reunían estas características. En él, se analizan fundamentalmente cuatro trabajos que a su vez pasamos a describir brevemente, enfoncándolos con un carácter más crítico.

A retrovirus inspired algorithm for virus detection & optimization

Este estudio de 2006 juega con la idea de hacer evolucionar las firmas del malware para crear "anticuerpos". El concepto es el de usar algoritmos genéticos no tanto para afinar el clasificador (que como veremos más adelante sería el uso habitual) sino para hacer que el clasificador elija mejor las reglas que afinen su funcionamiento.

Al margen de su utilidad real para detectar malware, lo interesante es cómo se evita que el algoritmo genético quede atascado en óptimos locales, añadiendo "memoria", esto es, añadiendo a los registros del algoritmo cierta información previa. El fitness se calcula midiendo la distancia entre las cadenas que representan las firmas, lo que supone ser muy optimista con respecto la fórmula con la que el malware se clasifica con firmas en general... No se ofrecen estadísticas reales de mejora o uso comparable con otros sistemas de firmas o sistemas de detección, lo que ofrece una idea de su utilidad real.

De alguna manera, este artículo se complementaría en 2012 con un estudio y un programa creado por Carlos Nasillo específicamente para evolucionar firmas concretas de malware a través de algoritmos evolutivos y comparando literalmente las cadenas binarias de firmas de malware. Por el tipo de muestras utilizadas, los resultados obtenidos, el coste computacional, el enfoque utilizado y como el propio autor reconoce en el artículo que acompaña al software, no se obtiene mejora concreta o apreciable en la detección con este método. Algo que se intuye desde el planteamiento con el uso de firmas.

In-execution Malware Analysis and Detection scheme (IMAD)

En este estudio de 2009 se presenta la herramienta In-execution Malware Analysis and Detection scheme (IMAD). Se trata de una herramienta que pretende clasificar si un archivo binario para sistemas UNIX es malware o no. Las características de cada fichero se calculan extrayendo las llamadas a funciones de los binarios y agrupándolos en "n-grams". En resumen, los n-grams (que se usarán en estudios sucesivos) son subsecuencias de n "ítems" (en este caso conjuntos de llamadas a sistema) que se sobreponen unos a otros. Esta técnica es habitual en el estudio del malware, pues permite conocer qué conjunto de cadenas es lo suficientemente representativo como para suponer una “marca" que defina otros archivos similares y por tanto, permite clasificar.

El papel de los algoritmos evolutivos aquí es de apoyo cuando el resto de clasificadores no se pronuncia, y conocer así qué "peso" tiene cada parámetro (n-gram) para definir el malware y "detectar" así el conjunto de llamadas que lo hace sospechoso.

En los experimentos, se utilizan 100 muestras de malware y 180 de "goodware". A todas luces, una muestra insuficiente que invalidaría las conclusiones de cualquier análisis. La clasificación se compara con algoritmos de clasificación como Support Vector Machine, C4.5, Bayesianos y RIPPER. IMAD, apoyándose en algoritmos genéticos, obtiene unos resultados de éxito interesantes (no llegan al 90% de "accuracy"), aunque llama la atención que la optimización introducida con los algoritmos genéticos permite reducir la tasa de falsos positivos al 0% en algunos casos frente al resto. Aunque reducir los falsos positivos resulta especialmente atractivo, como se ha mencionado, con 100 muestras de malware los resultados de este informe en concreto no son relevantes.



Evolvable malware

En este artículo se utilizan algoritmos genéticos para "evolucionar el malware", representado como una serie de características de comportamiento. Una vez "evolucionado" (modificando o alterando parámetros, como por ejemplo el conjunto de acciones maliciosas que realiza) se genera el código máquina que lo representa y se comprueba de nuevo contra los motores antivirus. Durante la evolución (intercambiando funcionalidades), cuanto más se parecían los hijos al conjunto de malware test, mejor era su fitness.

Dadas las restricciones intrínsecas del experimento (que busca funcionalidades concretas dentro del malware), se redujo al uso de una variante de Beagle. Se trata de un malware de 2004 muy polifacético (realizaba muchas acciones nocivas diferentes sobre el sistema) y del que se produjeron infinidad de variantes. Se convirtió en paradigma de la nueva ola de malware con fines económicos nacida en 2004, creada de forma profesional y muy modular. En este estudio se utilizan los algoritmos genéticos para generar de una manera controlada nuevos individuos, representados como un conjunto de funcionalidades. El concepto resulta interesante.

On the Appropriateness of Evolutionary Rule Learning Algorithms for Malware Detection

Uno de los trabajos más representativos quizás, se encuentra en este documento donde se experimenta con el uso de algoritmos evolutivos y no evolutivos de aprendizaje de reglas para la detección de malware. Se comparan los clasificadores evolutivos XCS, UCS, GAssist-ADI, GAssist-Intervalar y SLAVE contra los no evolutivos RIPPER, SLIPPER, PART, C4.5 y RIONA (todos presentes en el software KEEL.

No solo se evalúa su "accuracy", sino también el número de reglas generadas, la comprensibilidad de las reglas (aunque resulte subjetivo, se pretende evaluar qué reglas resultarían útiles para un humano) y sobre todo, el tiempo necesario para los cálculos. La conclusión es muy interesante. Si bien todos los algoritmos se mueven en entornos aceptables por encima del 99% de precisión, es clara la diferencia: los no evolutivos son más precisos. De entre los evolutivos, GAssist-ADI y SLAVE tienen la mejor puntuación (que no supera a los no evolutivos), pero su tiempo de proceso los hace inutilizables para ofrecer una respuesta en tiempo real. UCS es el único que funciona con mejores tiempos, pero a costa de una precisión menor. En este estudio destaca el uso de 11.786 ejecutables para las pruebas de los que se extraen estáticamente 189 funcionalidades propias de los ejecutables (desde la versión del compilador, pasando por su timestamp a su tamaño). La conclusión final es que los algoritmos de aprendizaje evolutivos no mejoran la detección ni son usables en tiempo real.



Veremos en la siguiente entrega, qué ha ocurrido desde 2009 en este campo, y qué otras investigaciones se han publicado en la literatura académica.


* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (I)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (II)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (III)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (IV)


Sergio de los Santos
ssantos@11paths.com

ElevenPaths Talks: Conceptos Generales de TOTP

martes, 22 de noviembre de 2016




El próximo jueves 24 de noviembre nuestro compañero Claudio Caracciolo impartirá la charla Conceptos Generales de TOTP, en la que repasará todos los sistemas relacionados con un segundo factor de autenticación y comprenderás sus ventajas y desventajas para cada caso o situación.

La duración de la charla de Claudio será de unos 30 minutos, divididos entre 20 y 25 minutos de exposición y de 5 a 10 minutos de preguntas y respuestas. El horario de la charla será a las 15.30h (Madrid) y estará disponible al termina ésta en nuestro canal de YouTube. La ponencia se llevará a cabo por Hangouts y se impartirá en castellano.

Si quieres saber más acerca del tema, no dudes en pasarte por nuestra Comunidad, donde nuestros compañeros hablan sobre éste y otros temas de interés en el mundo de la Seguridad. Puedes consultar el calendario de talks para ver los webcasts que aún quedan por celebrarse. Recuerda, tienes una cita el próximo 24 de noviembre a las 15.30h (Madrid). Para registrarte debes usar el siguiente formulario de ElevenPaths Talks.

Más información en:
talks.elevenpaths.com

ElevenPaths y Etisalat Digital anunciamos nuestra colaboración en el área I+D de Seguridad Móvil

lunes, 21 de noviembre de 2016


Madrid, 21 de noviembre de 2016.- ElevenPaths, la unidad de Ciberseguridad de Telefónica, y Etisalat Digital, dos de los principales proveedores mundiales de soluciones y servicios de comunicaciones, hemos anunciado hoy nuestra colaboración en el área de I+D sobre seguridad móvil para realizar estudios completos sobre control y análisis de amenazas para aplicaciones y dispositivos móviles. Esta colaboración se anunció en la reciente conferencia RSA de 2016 que se celebró en Abu Dhabi. Se trata de una colaboración que amplía la cartera de productos de Servicios de Ciberseguridad y Seguridad gestionada que comparten actualmente. El acuerdo sobre Servicios de Seguridad forma parte de una cooperación más amplia entre ambas empresas en múltiples ámbitos, bajo el marco del Contrato de colaboración estratégica firmado originalmente en junio de 2011.

En palabras de Francisco Salcedo, Vicepresidente de Etisalat Digital, “el anuncio de hoy es muy importante porque la movilidad ha traspasado el ámbito de los dispositivos, las aplicaciones y las transacciones en línea para dar lugar a un ecosistema conectado. Como resultado de esta transformación, las plataformas móviles se han vuelto vulnerables y se han convertido en un objetivo fácil para los ciberdelincuentes. La colaboración y la implementación en los Centros operativos de Ciberseguridad de Etisalat Digital permitirá a ambas empresas ofrecer soluciones para que las compañías controlen las actividades fraudulentas que afectan directamente a sus servicios, su marca o su reputación”.

Las herramientas y los conocimientos que se usan para evitar el malware en los PC son completamente diferentes a los empleados contra el malware en dispositivos móviles. Los ecosistemas móviles son increíblemente dinámicos y los ciberdelincuentes actualizan constantemente las herramientas y técnicas que utilizan para sus actividades. Buscan modelos de negocio sostenibles y ampliables que generen ingresos mediante el fraude, al tiempo que evitan las mejoras de seguridad que introducen los mercados de aplicaciones móviles de forma regular.

Las dos empresas trabajarán con Tacyt, una herramienta de ciberinteligencia desarrollada por ElevenPaths para controlar y analizar las amenazas en el entorno móvil. Tacyt emplea un planteamiento de "Big Data" para el estudio del entorno de aplicaciones móviles y un servicio de nivel empresarial para realizar investigaciones completas que incluyen clasificación, atribución, categorización y control del malware en dispositivos móviles, además de un análisis detallado sobre los distintos enfoques para el malware:
  • El ecosistema móvil es increíblemente dinámico y los ciberdelincuentes buscan modelos de negocio sostenibles y ampliables que generen ingresos mediante el fraude, al tiempo que evitan las mejoras de seguridad que introducen los mercados de aplicaciones móviles. 
  • La categorización de las familias de malware y la atribución revelan tendencias en la comunidad de ciberdelincuentes. 
  • La categorización de los riesgos del malware es fundamental para la protección contra las amenazas en los entornos BYOD ( bring your own device - traiga su propio dispositivo -) . Si un empleado instala adware agresivo en un dispositivo, ¿sería suficiente por sí solo para bloquear el acceso a los correos electrónicos corporativos? ¿Qué pasa si el adware se consolida e introduce un backdoor? En tales casos, la categorización será de gran ayuda.
Pedro Pablo Pérez, Director Global de Seguridad de Telefónica y CEO de ElevenPaths, ha comentado “estamos encantados de colaborar con Etisalat Digital para realizar este análisis y estudio detallados sobre las amenazas en el entorno móvil. Los ciberanalistas pueden usar Tacyt para la búsqueda, manual o automatizada, la correspondencia y la investigación de distintos parámetros (metadatos) en aplicaciones iOS y Android. Esto permite la identificación de "singularidades" potenciales, un concepto que se refiere a cualquier tipo de datos (fechas, tamaño, imágenes, certificados digitales), técnicos o circunstanciales, que convierten a la aplicación o a su desarrollador, como persona, en algo único o singular”.


ElevenPaths and Etisalat Digital announce their collaboration for Mobile Security R&D


Madrid, November 21 2016.- ElevenPaths, Telefónica Cyber Security Unit, and Etisalat Digital, two of the world’s leading providers of communications services and solutions, announced today their collaboration in the field Mobile Security research & development (R&D) to conduct extensive research in monitoring and analysing mobile threats for applications and devices. The collaboration was announced at the recent RSA Conference 2016 held at Abu Dhabi. This is an expansion of their alliance beyond their existing shared portfolio of Managed Security and Cyber Security Services. The agreement in Security Services is part of the broader collaboration existing between both companies in multiple areas, under the framework of the Strategic Partnership Agreement originally signed in June 2011.

Francisco Salcedo, Senior Vice President Etisalat Digital said “today’s announcement is significant as mobility has moved beyond devices, apps and online transactions to a connected ecosystem. This transformation has made mobile platforms vulnerable and an easy target for cybercriminals. The collaboration and the deployment at Etisalat Digital’s Cyber Security Operating Centres will enable both partners to provide a solution for enterprises to control fraudulent activity which directly impacts its services, brand or reputation.”

The tools and knowledge used for prevention of PC malware is completely different to mobile malware. A mobile ecosystem is extremely dynamic and cybercriminals are constantly evolving the tools and techniques used for such activities. They look for sustainable, scalable business models that generate revenue through fraud while defeating security enhancements introduced by Mobile App Markets on a regular basis.

Both companies will work with Tacyt, a cyber intelligence mobile threat tool developed by ElevenPaths for mobile threats monitoring and analysis. Tacyt uses a big data approach for mobile app environment research and an enterprise-grade service to conduct full investigations, including mobile malware classification, attribution, categorization, monitoring and in-depth analysis of mobile malware need multiple approaches:

  • Mobile ecosystem is extremely dynamic and cybercriminals look for sustainable, scalable business models that generate revenue through fraud while defeating security enhancements introduced by Mobile App Markets. 
  • Attribution and malware family categorization reveals trends in the cybercriminal community. 
  • Malware risk categorization is vital for mobile threat defense in Bring Your Own Device (BYOD) deployments. If an employee installs aggressive adware on a device, would that be enough to block access to corporate email on its own? What if the adware roots and places a backdoor? Categorization will help in such deployments.

Pedro Pablo Pérez, ElevenPaths CEO and Telefónica Global Security Managing Director, said “we are pleased to collaborate with Etisalat Digital to conduct this in-depth research and analysis on mobile threats. Cyber analysts can use Tacyt for manual or automated search, matching, and investigation of different parameters (metadata) within iOS and Android apps. This allows the identification of potential ‘singularities’, a concept which refers to whatever data (dates, size, images, digital certificates) – technical or circumstantial –makes the app or its developer – as a person – singular or unique from others.”

Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (I)

sábado, 19 de noviembre de 2016

En esta serie de artículos se realizará un repaso a la literatura académica en la que se mezclan estos dos conceptos: malware y algoritmos evolutivos. Analizaremos de forma crítica qué trabajos y artículos se han presentado en orden cronológico durante los últimos años, para comprobar si realmente tiene sentido utilizar los algoritmos genéticos para mejorar cualquier aspecto de la lucha contra el malware, ya sea en detección, análisis, predicción… Veremos un buen montón de experimentos basado en la algoritmia evolutiva, que a su vez también resulta apasionante.

Desde la década pasada, los algoritmos evolutivos y la programación genética han irrumpido con fuerza en la ingeniería informática. En una frase, los algoritmos evolutivos pretenden encontrar soluciones aplicando técnicas de cambio y mutación en una serie de planteamientos y comprobar si estos satisfacen mejor el problema. Si es así, estos mejores candidatos siguen modificándose de forma inteligente o aleatoria para dar con el candidato ideal que soluciona el problema. Pensemos en candidatos como vectores, por ejemplo. Esto permitiría solucionar problemas de forma rápida en vez de tener que usar la fuerza bruta recorriendo todas las posibilidades de un vector. Es una explicación burda, pero lo cierto es que los algoritmos genéticos tienen gran potencial. Tanto, que cuando se popularizaron hubo un momento de euforia en el que muchos pensaron que resolverían ciertos problemas intratables hasta el momento, hasta que se demostró que al final no había "free lunch" y que realmente no podían llegar a batir en todas las circunstancias a la búsqueda ciega.

Estructura típica de un algoritmo evolutivo.
Fuente: http://www.scielo.org.ve/scielo.php?script=sci_arttext&pid=S1316-48212006000400002


Por su versatilidad son usados en un amplio rango de campos pero quizás el análisis del malware podría prestarse especialmente a ser mejorado con este tipo de algoritmos, por varias razones:

  • Clasificar y detectar el malware de forma eficiente es un grave problema de la informática en general. Desde mediados de la década pasada, ya no solo en entornos de escritorio sino también en dispositivos móviles, entornos industriales y como arma de la llamada "ciberguerra" en el que instituciones gubernamentales lo utilizan como método de espionaje o control.
  • Los modelos tradicionalmente utilizados para detectar y catalogar malware han sido las "firmas" creadas por motores antivirus. Aunque efectivas en cierto grado con el malware común, resultan hoy en día eludibles por los atacantes desde el punto de vista técnico. El malware con fines económicos o logísticos pasa fácilmente desapercibido para los motores, puesto que sus creadores disponen de las herramientas necesarias (entre ellas el propio antivirus) para modificarlos y realizar diferentes versiones que no sean detectadas.
  • La creación de malware ha crecido sustancialmente, tanto en número como en sofisticación y presencia, por lo que se manejan ya cientos millones de registros y muestras que catalogar y detectar. Esto dificulta el trabajo de los propios motores, que crean firmas más genéricas (y menos efectivas) para poder abarcar el máximo malware común.
En un principio, el malware (tradicionalmente denominado "virus"), parece especialmente propenso a ser estudiado por algoritmos evolutivos, debido a que tradicionalmente se ha mostrado como una especie de organismo parasitario capaz de reproducirse y evolucionar, aunque ese modelo de malware no se utilice desde mediados de la década pasada. Estos factores hacen pensar que los algoritmos evolutivos en particular (especializados en resolver problemas muy complejos, con gran cantidad de datos y características) y el "machine learning" en general pueden dar la posibilidad de ofrecer una solución interesante en el campo del malware, bien detectando, evaluando, clasificando o incluso prediciendo sus capacidades y evoluciones. Pero... ¿es cierto?

Conceptos previos

En el mundo del malware, el sistema de firmas tradicional se utiliza para la clasificación y detección en general, y se basa en características concretas del binario que permitan identificarlo. Con ellas, si son extrapolables y significativas, se podría detectar más malware (y nuevas versiones) e intentar así clasificar muestras previamente desconocidas de forma más eficaz. El sistema de firmas se ve lastrado por depender de los recursos del laboratorio responsable del motor antivirus, que las genera de forma más o menos automatizada (a veces con intervención humana) y de manera reactiva (ante nuevas muestras que las eluden, se necesita estudiar cómo lo han conseguido para poder recrear las nuevas firmas). Pero si se eligen los atributos correctos al margen de las firmas más estáticas (una clasificación atendiendo a características más adecuadas), se podría realizar la clasificación de forma automática y (en teoría) más eficaz que las firmas (que habitualmente se restringen a cadenas concretas o combinación de código único encontrados en los binarios). Además, si bien las firmas suelen ser eludidas por los creadores de malware variando el código concreto que detecta el motor antivirus pero manteniendo la funcionalidad del malware, al tomar otras características basadas en funcionalidad u otros parámetros como referencia, se hace más complejo para un atacante poder evitarlas y pasar así inadvertido.

En los artículos y experimentos que vamos a analizar se tratan varios casos de clasificación de binarios en malware o goodware. En ellos, el éxito se suele medir por el "accuracy" alcanzado en la clasificación. Es un dato que refleja el éxito de la clasificación (malware o goodware) pero que además aglutina los falsos positivos (goodware erróneamente clasificado como malware), falsos negativos (malware erróneamente clasificado como goodware), verdaderos negativos (goodware clasificado satisfactoriamente como goodware), y verdaderos positivos (malware clasificado satisfactoriamente como malware). Habitualmente se comparan los resultados contra la detección de motores antivirus u otros clasificadores para comprobar su eficacia.

Debido a la existencia de un trabajo de recopilación previo similar realizado en 2009 por Christie Williams (aunque no con carácter crítico), a partir del siguiente artículo nos centraremos principalmente en cómo ha evolucionado el área desde entonces, con un exhaustivo repaso a la literatura académica.


* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (I)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (II)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (III)
* Algoritmos evolutivos y malware, ¿evolucionan los "virus"? (IV)
Sergio de los Santos
ssantos@11paths.com

Atrévete a participar en Latch Plugins Contest con hacks como Paper Key

viernes, 18 de noviembre de 2016

En Elevenpaths tenemos una sana tradición que persigue desarrollar la innovación y entrenar la capacidad de acabar las cosas. Ya sabéis que en desarrollo muchas veces los proyectos tienen tiempos de finalización “asintóticos”.

Cada seis meses tenemos el reto de desarrollar durante 24 horas seguidas una idea, llevarla a la práctica y después presentarla en público. Puede ser cualquier cosa, pero lo importante es que funcione. Lo llamamos Equinox.

En el Equinox de Otoño de 2016, un grupo de compañeros (Jorge Rivera, Pedro Martínez, Alberto Sánchez y Félix Gómez) quisimos unir lo abstracto, la seguridad lógica, con lo concreto, algo que pudieras tocar. Y pensamos que de paso podríamos utilizar la tecnología de Latch y la nueva API desarrollada este año (las “instancias de operación”- SDK de Latch).

De ahí surgió el proyecto Paper Key, con el que quisimos unir diversas piezas tecnológicas, primando la seguridad de todo el proceso, y abstrayendo la tecnología, para que el uso fuera sencillo e intuitivo.

La idea es poder emitir un token que da acceso a un servicio o dispositivo. Este token lo imprimimos en papel (algo que tengo) y sólo es válido cuando el Emisor del token autoriza su uso desde la aplicación Latch (segundo factor de autorización).


En nuestro ejemplo real, una persona puede imprimir un ticket con una cantidad de dinero asociada, y tras autorizar la operación en Latch desde su móvil, una segunda persona, canjea el ticket en un monedero automático, que entregará la cantidad indicada de monedas.

En todo el proceso participan dos personas (el Emisor y el Destinatario) y cuatro bloques de tecnología: la aplicación web, la impresora de tickets, el servidor API Python, y el lector de tickets+monedero.

El Emisor, desde una aplicación web, genera un ticket con un identificador de operación y una cantidad de dinero. La operación queda asociada a la cuenta de Latch del Emisor, y el ticket se hace llegar al Destinatario por medios físicos, o bien porque la impresora está en su entorno.


Cuando el Destinatario quiere consumir el ticket (en este caso, obtener una cantidad de euros de un monedero automatizado) se acerca a un lector de tickets, que comprobará el estado de la autorización en Latch. Mientras el Emisor del ticket no autorice la operación, el servicio no podrá ser accedido o consumido, y además se enviará una notificación a su app de Latch de que se está intentando utilizar el ticket (que es el comportamiento estándar).


La arquitectura utilizada en esta prueba de concepto podría optimizarse, pero dado que teníamos que realizar todos los desarrollos en 24 horas necesitábamos poder repartirnos el trabajo entre los cuatro. (Esta aproximación también permite que el servidor, la impresora y el lector de tickets pueden encontrarse distribuidos en distintas ubicaciones, puesto que se comunican entre ellos a través de Internet. Teniendo en cuenta las premisas de Equinox (24 horas, que funcione y ¡que se pueda explicar!), os describimos los distintos componentes con más detalle.

La WebApp 
Es una sencilla aplicación en PHP con un interfaz en HTML líquido que permite adaptar los formularios a distintos tamaños u orientaciones de la pantalla de los teléfonos móviles.


La aplicación corre en un servidor WAMP y se comunica con una API en Python para hacer el interfaz con la impresora y el lector de tickets. Es una aplicación en PHP estándar, donde se autentica a los usuarios mediante usuario y password contra un MySQL generando un token de sesión. Podéis encontrar en la web un montón de ejemplos sobre cómo hacer esto.

La WebApp permite al usuario Emisor navegar, y después de validarse, seleccionar una cantidad de dinero y escribir un texto libre para identificar la transacción. Esta información es remitida mediante un POST a un servidor en Python, que generará una petición para la impresora.


La respuesta del servidor con la API en Python es un JSON que parseamos en el servidor PHP para devolver la respuesta a la WebApp:
{
status: [Ok/NOK]
money: [cantidad de dinero – para informar a la WebApp]
id: [Identificador devuelto por el servidor – para la WebApp]
}


En el response del POST recibimos el estatus de la operación y el ID generado para presentarlo en la pantalla del teléfono del Emisor.

La impresora de tickets
Este subsistema se compone de una Raspberry Pi y una impresora térmica de tickets. La impresora (Brother QL-570) nos la prestó amablemente el equipo de Secretaría, y la Raspberry la conseguimos del laboratorio de Seguridad IoT, que tiene bastante hardware para jugar.


La Raspberry está conectada a Internet a través de wifi, y espera en un puerto una petición REST con los contenidos que tiene que imprimir (operación “generateID”).
{
instanceId: [ID de instancia Latch]
money: [cantidad de dinero en Euros]
}


Se genera un código QR bidimensional con la librería libqrencode, y mediante las librerías de Image Magic, se superpone sobre un fondo preestablecido con el logo “Equinox”.

Luego, se añade el texto en la petición, en este caso el valor del ticket generado.


El ticket final será imprimido desde la Raspberry PI gracias al pseudo-driver de impresión para esta impresora, disponible en Git-Hub.

El código QR es un identificador de operación codificado en Base32, y permitirá al lector de códigos QR comprobar el estado de autorización de la operación antes de proporcionar dinero (1 Internet Point al que nos diga por qué tuvimos que usar Base32 en lugar de Base64).

El servidor API Python
En este servidor se encuentran la API en Python para Latch (interfaz entre la WebApp, la impresora, el lector de tickets y el servidor de Latch) y el servidor WAMP. El servidor es invocado por la WebApp , mediante un POST al puerto 1338, con los campos:
{
money: [cantidad de dinero en euros]
text: [string de texto que aparecerá en la aplicación Latch]
}



Ahora se ejecutan dos operaciones secuencialmente:
1. El servidor construye una solicitud mediante la API para solicitar la “instancia de operación” al sistema Latch de Elevenpaths, de manera que en la app Latch asociada al usuario, aparecerá una nueva línea, con el texto identificador de la operación. Esta operación está ahora por tanto sujeta a la autorización del usuario, está “latcheada”.


Y en el interfaz de la app del teléfono… vemos aparecer, dentro del servicio PaperKey, una nueva “instancia de operación” con el texto introducido “Equinox Demo 2016”.

2. El servidor invoca a la impresora de tickets (IP y puerto de la Raspberry asociada a la impresora) de manera que se imprime el ticket con el código QR asociado a la operación.

En este momento, el Emisor ha generado una operación en Latch, y además ha imprimido un ticket en papel, con un código QR que identifica dicha operación.

Si el Destinatario de la operación (aquella persona que coge físicamente el ticket) quisiera utilizarlo, deberá esperar a que el Emisor autorice dicha operación.

Lector de tickets+hucha
Este sistema está compuesto por otra Raspberry Pi (en la caja de cartón), un lector láser de códigos QR, como los de los supermercados y un colorido dispensador de monedas (ya dijimos que tienen muchos juguetes).

El lector láser se presenta por USB como un teclado estándar HID, de manera que para transmitir información al sistema operativo simula pulsaciones de teclado correspondientes al código escaneado (dígitos o caracteres).

Esto planteaba un problema interesante con el terminal. Para poder realizar la captura de pulsaciones del teclado sin disponer del STDIN del proceso - ya que este estaría en su consola, no estando disponible desde un proceso lanzado en un pseudo terminal - utilizamos un wrapper programado en C que intercepta los eventos del dispositivo que presenta el kernel de Linux en espacio de usuario /dev/input/event5.


Y esto nos provocó un segundo problema, ya que el identificador de operación que utilizamos tiene caracteres alfanuméricos con mayúsculas y minúsculas. Y la emulación de teclado del escáner es siempre de caracteres que no requieren pulsaciones simultáneas (p.ej [SHIFT] + Letra). Por ello hubo que realizar una conversión de código a Base32 (que colateralmente aumenta el tamaño del string, por lo que hay que incrementar la densidad del código QR). Si has leído esto ya no te damos un Internet Point.

Después de todas las curvas y baches, tenemos un identificador de operación. Desde la Raspberry construimos una petición JSON, y la lanzamos contra el servidor API Python, como operación “checkID”.
{
Id: [Identificador de operación]
}

El servidor realizará una consulta a Latch, proporcionando el Id de operación asociado al usuario. Si la operación está “latcheada” (“Latch ON”), el sistema devolverá un error.


Si la operación ha sido des-latcheada (“Latch OFF”), el sistema considerará la operación como autorizada y pasará a proporcionar la cantidad de dinero indicada en el monedero automático. El monedero está conectado a la Raspberry Pi por USB, y recibe la cantidad de monedas a dispensar con un código de 4 dígitos.

Atrévete a participar en Latch Plugin Contest
Paper Key, como prueba de concepto, nos permitió demostrar que es sencillo (¡Lo conseguimos en 23 horas y media!) integrar distintas tecnologías para conseguir un sistema fácil de utilizar, seguro, y con multitud de casos de uso, según la imaginación de cada uno.

Por ejemplo, se podrían utilizar taquillas que contienen un producto proporcionado por el Emisor, y que sólo pueden ser abiertas por el Destinatario al confirmar el Emisor, mediante su Latch, que ha recibido el pago. O se podrían emitir tickets para una barra libre: sólo cuando el responsable (de pagar) lo decide mediante su Latch empiezan a poder validarse los tickets a cambio de bebidas. También puedo dar acceso de un solo uso (OTA) a unas instalaciones, por ejemplo, dar días de prueba gratis de acceso a las instalaciones de un gimnasio. Como veis, un montón de cosas se pueden hacer con integraciones relativamente simples.

Aprovechamos para recordaros que hace unas semanas desde ElevenPaths convocamos una nueva edición del concurso Latch Plugins Contest. En este concurso podéis ganar hasta 5.000 dólares; recordad que lo que se premia es la imaginación, talento, creatividad y solución aportada.

Si queréis conocer todos los pasos a seguir para inscribirse, visitad nuestra Comunidad donde explicamos cómo participar y donde podéis encontrar trucos, consejos, así como uniros a la conversación sobre Latch Plugins Contest. Además, si deseáis conocer toda la mecánica del concurso allí podéis consultar las bases legales.

Recuerda que el plazo del concurso acaba el día 12 de diciembre de 2016, ¡saca tu lado más hack y participa ya!

Todo lo que presentamos en Security Innovation Day 2016 (V): Aumenta la seguridad de tu firma digital

jueves, 17 de noviembre de 2016

Imagina que vas a Hacienda para aclarar algún tema de la declaración de la renta de 2016. Cuando estas allí y después de hacer las consultas que necesitabas, el funcionario te indica que firmes un documento donde se incluyen las hipotecas pendientes de pago en las nuevas tablets de la Administración. Al firmar un documento digitalmente, Hacienda podría verificar la firma para evitar algún tipo de fraude. Pero no queda todo ahí.



A este documento digital confidencial que ha sido guardado, nosotros para aumentar la seguridad de la firma digital, añadimos la tecnología Shadow, con una marca de agua única para identificar al funcionario como la persona que ha tratado este documento. A la mañana siguiente, este documento aparece publicado en los periódicos donde tus hipotecas son conocidas por todo el mundo con todo lo que esto conlleva.

La Administración Pública decide averiguar de dónde ha procedido esa fuga de información que daña su imagen por carecer de seguridad y no proteger la confidencialidad de los documentos de sus clientes. Gracias a esta marca de agua que hemos insertado en el documento con Shadow, descubrimos que el funcionario había cogido este documento y además de guardarlo, había hecho una copia impresa y la había filtrado. De esta forma, la Administración sabe quién ha impreso el documento y reconoce de dónde proviene la fuga de información.

Con nuestra solución de firma biométrica manuscrita SealSign podemos incluir la firma digital en cualquier tipo de documento, como por ejemplo firmar contratos de trabajo, consentimientos informados o cualquier documento en la Administración Pública. Desde ElevenPaths hemos querido ir más allá ofreciendo soluciones completas que aúnen la potencia de las distintas tecnologías con las que trabajamos. Por eso, si en esos documentos firmados integramos la tecnología Shadowque permite insertar una marca de agua invisible en documentos de texto, para ser identificada más tarde, de forma que, aun pareciendo que el documento no ha sido modificado, es posible extraerla y validarla incluso cuando el documento ha sido impreso o escaneado. Gracias a la combinación de ambas tecnologías conseguimos:
  • Aumentar la seguridad de los documentos de manera totalmente transparente
  • Identificar a los autores de las fugas de información
  • Mejorar la experiencia de usuario a la hora de firmar documentos, ya sea con tu firma manuscrita biométrica o con tu firma con certificado 
  • Verificar la identidad del firmante

Echa un vistazo al vídeo y conoce más sobre la compra de la tecnología Shadow de Gradiant, una solución para la seguridad y trazabilidad de documentos que anunciamos en Security Innovation Day 2016.




Arsenio Pérez Gavira, ElevenPaths Product Manager
Daniel Ramos, Gradiant International Business Development Manager


No te pierdas el resto de la serie "Todo lo que vimos en Security Innovation Day 2016":

Wordpress in Paranoid Mode: Cómo fortificar tu BBDD de Wordpress con Latch

miércoles, 16 de noviembre de 2016

En ElevenPaths no hemos dejado de investigar e intentar diferentes soluciones y posibilidades para hacer el mundo digital más seguro. Chema Alonso y Pablo González realizaron una investigación sobre la fortificación de la base de datos de Wordpress utilizando un segundo factor de autorización como Latch que queremos compartir con vosotros.



Además, en el estudio se puede ver otra técnica interesante como es la división de cadenas de conexión a la base de datos en función del rol del usuario en el CMS. Esta es una forma muy interesante de minimizar la exposición de los recursos en la cadena de conexión y mitigar el impacto que tiene la explotación de algunas vulnerabilidades.


Descárgate los papers desde el Slideshare de ElevenPaths y aprende más sobre el modo paranoico en Wordpress. Os animamos a que paséis por la Comunidad de ElevenPaths para que consultéis más temas y dejéis vuestras dudas.



Os dejamos una serie de artículos dónde podéis ver el modo paranoico en funcionamiento:
Wordpress in Paranoid Mode.
SQL Server in Paranoid Mode.
Github y WPM.