domingo, noviembre 30, 2014

Ciberlunes en 0xWord: 10 % de descuento y nuevos Packs

Como ya se hiciera el año anterior, 0xWord se suma al Ciberlunes 2014 con un 10 % de descuento que estará disponible durante las 24 horas del lunes, es decir, desde las 00:00 de España que se alcancen esta noche, hasta las 12:00 del lunes. Para ello durante todas las compras, cuando se realice el proceso, hay que introducir el código descuento, que es el que tenéis aquí: CIBERLUNES2014

Figura 1: Código descuento en todas las compras para el Ciberlunes 2014 de 0xWord

Para que lo podáis aprovechar al máximo, hemos hecho un esfuerzo para que llegue a tiempo el libro de Una al día: 16 años de Seguridad Informática, que recoge lo acaecido año a año en el mundo de la seguridad desde 1998 a 2014. Como sabéis, este libro es un esfuerzo común entre Hispasec y 0xWord con una tirada muy limitada - solo para auténticos amantes de la seguridad que disfruten de la lectura de la historia de la seguridad en esos años en más de 300 páginas -, y aunque aún no ha llegado de la encuadernación, esperamos que esté a principios de semana en nuestras manos.

Figura 2: Una al día - 16 años de seguridad informática

Además de ello, se han actualizado los Packs, para que podáis seleccionar temáticamente el que más os interese. Los que hay disponibles actualmente son los siguientes:

Figura 3: Pack CSO
Figura 4: Pack Windows Security

Figura 5: Pack Mobile Security

Figura 6: Pack Security Lover

Figura 7: Pack Pentester 1

Figura 8: Pack Pentester 2

Figura 9: Pack Pentester 3

También está disponible un Pack con la Colección Completa que cuenta con los 30 títulos que están a día de hoy en stock, por lo que si quieres aprovisionar la biblioteca de un centro educativo o de una empresa, esta es la mejor opción y el mejor momento.

Figura 10: Pack Colección Completa

Por último, el Ciberlunes 2014 se aplica a todos los productos de 0xWord, así que el Pendrive de Cálico Electrónico está también sujeto a este código de descuento. Elige lo que más te guste y pídelo antes de que se acaben.

Saludos Malignos!

sábado, noviembre 29, 2014

Mis próximas charlas de aquí a fin de año

Esta semana que se avecina da comienzo ya el último mes del año 2014, al que una vez más y contra todo pronóstico sobrevivimos. Yo ya tengo el calendario de mis charlas totalmente cerrado y no creo que entre nada más por aquello de los problemas espacio-temporales. Por si te va bien y te apetece, esta es la lista de todos los eventos públicos en los que voy a estar este mes de Diciembre.

Figura 1: Orejas arriba si vas a venir a aluna de las charlas en diciembre

2 de Diciembre: La Mañana con Javi Nieves ... y con Fermín J. Serna

Este martes, a las 10:00 de la mañana, aprovechando que Fermín J. Serna (zhodiac) anda por España para estar en el CyberCamp y pasar unos días en su querida España, me lo llevo a la radio, que el equipo quiere charlar unos minutos con él.

Figura 2: Fermín J. Serna presentando en Black Hat USA 2012


4 de Diciembre: Escuela Politécnica Superior de la Universidad de Lleida

El próximo jueves, de camino a Barcelona, haré una parada en la Universidad de Lleida para dar una charla de una hora. Será e en el Auditorio del Centro de Culturas y Cooperación Transfronteriza del Campus de Cappont, sito en la Calle Jaume II número 67.

Figura 3: Conferencia en la EPS de Lleida

La charla es para los estudiantes de la Universidad, pero creo que está abierta a todo el público. Será a partir de les 12:00 y durará hasta las 13:00 horas. Tienes más información en este artículo que ha publicado la Escuela.

4 de Diciembre: 5 Talks

El mismo día, pero por la tarde, estaré en 5Talks, que tendrá lugar a las 19:30, en Barcelona, en el Mobile World Centre. Allí estará Elsa Punset, mi compañera en Telefónica I+D Nuria Oliver, Arancha Ruiz y Christian Rodríguez. Puedes conseguir tu entrada aquí.

Figura 4: 5Talks.org en Barcelona

Para interesados que no pueden asistir en directo, las charlas también serán retransmitidas por live stream.

5 de Diciembre: CyberCamp 2014

Al final, debido a incidencias de última hora, me va a tocar estar el Viernes por la tarde en la presentación del CyberCamp. Estaré en las charlas de las keynotes, y mis compañeros estarán en los talleres de Latch y dando alguna que otra charla.


Figura 5: Cálico Electrónico y su preocupación por el CyberCamp

Recuerda que el CyberCamp es gratuito, pero las plazas para las actividades son limitadas, así que apúntate cuanto antes si quieres venir a alguna de las cosas que tenemos preparadas.

10 de Diciembre: Sinfonier MeetUp

Los chicos del equipo de Sinfonier, además de tener también un taller en el CyberCamp al que te puedes apuntar, han preparado un encuentro para que la gente conozca las capacidades de este proyecto.

Figura 6: Sinfonier MeetUP en Madrid

Así que me han liado a mí para que lo use junto con nuestro proyecto de investigar en busca de ciber-malos Path 5 y el día 10 de diciembre en Madrid estaré en el Sinfonier MeetUp. Regístrate si quieres asistir, que el número de plazas es muy limitado. Estate atento al blog de Sinfonier para próximos anuncios.

Y esto es todo. El resto de los martes del mes estaré en la radio, como sucede desde hace tres años, y espero que todos los días escribiendo en El lado del mal

Saludos Malignos!

viernes, noviembre 28, 2014

Ataques de PHP Object Injection en aplicaciones web

Cuando se hace una auditoría de seguridad a una aplicación web construida en tecnologías PHP, uno de los tipos de ataques que se pueden realizar son los de PHP Object Injection. Este fallo se da solo en aplicaciones PHP desarrolladas bajo paradigmas de Programación Orientada a Objetos (POO) y se tienen que dar algunas circunstancias muy concretas para que se pueda dar la vulnerabilidad, pero si esto es así, se pueden hacer muchas cosas, como vamos a ver.

Figura 1: Ataques de PHP Object Injection en aplicaciones web

Para que se pueda dar la vulnerabilidad, la aplicación web - como ya se ha dicho -, debe estar construida bajo el paradigma de POO. Eso hace que la aplicación tenga definida una estructura de clases para representar todos los objetos de la aplicación, algo que ayuda a la programación de frameworks complejos y a la sostenibilidad del código a largo plazo.

Normalmente, los frameworks de Internet cumplen esta característica. Casi todos los CMS que dan soporte a aplicaciones webs, o los e-commerce, o plataformas de administración de sistemas mediante tecnologías web tienen su propia jerarquía de clases para instanciar los objetos necesarios en cada parte de la aplicación.

Magic Methods en aplicaciones PHP con POO

Cuando se definen las propiedades y funciones de una clase, existen lo que se denominan Magic Methods, que no son más que una serie de funciones que se ejecutan no por invocación explícita, sino de forma implícita cuando se da una serie de condicionantes. Por ejemplo, cuando un objeto es creado, eliminado o utilizado con una conversión de tipo de datos implícito, se producen llamadas automáticas a los Magic Methods.

En PHP hay una buena cantidad de estos que son llamados de forma automática y que el programador puede implementar para gestionar las acciones oportunas. A continuación se muestra la lista de los “Magic Methods” y sus condiciones de ejecución.
  • __construct() Las clases que tengan este método se invocarán en cada nuevo objeto creado.
  • __destruct() Será llamado cuando se liberen todas las referencias o cuando el script finalice.
  • __call() Es lanzado al invocar un método inaccesible en un contexto de objeto.
  • __callStatic() Es lanzado al invocar un método inaccesible en un contexto estático.
  • __get() Se utiliza para consultar datos a partir de propiedades inaccesibles.
  • __set() Se ejecuta al escribir datos sobre propiedades inaccesibles.
  • __isset() Se lanza al llamar a isset() o a empty() sobre propiedades inaccesibles.
  • __unset() Se invoca cuando se usa unset() sobre propiedades inaccesibles.
  • __sleep() Se ejecuta antes de cualquier serialización. Es el método serialize() el que comprueba si en la clase existe este método.
  • __wakeup() Puede reconstruir cualquier recurso que el objeto pueda tener. Es el método unserialize() el que comprueba si en la clase existe este método.
  • __toString() Permite a una clase decidir cómo comportarse cuando se la trata como a un string
  • __invoke() Es llamado cuando un script intenta llamar a un objeto como si fuera una función.
  • __set_state() Se llama en respuesta a una instancia de su objeto que se pasa a la función var_export.
  • __clone() Si se clona un objeto y este ha finalizado de clonarse, se llamará al método __clone() del nuevo objeto (si el método __clone() estuviera definido)
  • __debugInfo() Este método es invocado por var_dump() al volcar un objeto para obtener las propiedades que deberían mostrarse.
Por supuesto, estos métodos por sí mismos no suponen una vulnerabilidad en sí mismos, pero un atacante podrá forzar su llamada generando las circunstancias adecuadas para lograr que, implicitamente, sea invocado. Es decir, un atacante podría lograr aprovecharse del código que hay allí escrito - y de las vulnerabilidades que allí haya - generando los condicionantes adecuados para se ejecute y así tomar el control.

Para ello debe existir en la implementación que haya hecho el programador de uno de esos Magic Methods alguna función susceptible de ser explotada, como un eval, include, shell_exec, mysqli_query, etcétera, que utilice algún parámetro manipulable por el atacante. Es decir, el atacante podrán el valor adecuado en el parámetro que utiliza la función insegura dentro del Magic Method, y luego generará los condicionantes adecuados para que se ejecute ese método. Veamos cómo.

Serialización de Objetos

Antes de continuar es importante entender en qué consiste el concepto de ”Serializar un objeto”. La serialización nace de la necesidad que tienen muchos sistemas de descargar un objeto que se encuentra en memoria para poder ser transmitido entre distintos sistemas. Es decir, para que pueda ser almacenado en disco y/o enviado por red usando una estructura entendible por el destinatario para que pueda re-armar el objeto en memoria, es decir, para que puede "Deserializar el objeto".

Uno de los formatos más utilizados para este fin - aunque no el único - son los ficheros JSON, y en PHP se utiliza la función unserialized para manipular los ficheros JSON con el fin de recrear en memoria dicho objeto. Por ello, cuando una aplicación web recibe un fichero JSON con datos relativos a un objeto definido en su estructura de clases, llama a la función unserialized, que en nuestro caso será la puerta de entrada para forzar la ejecución del Magic Method, inyectando, como veremos, un objeto en PHP malicioso.

Un programador que recibe un JSON con información relativa a un objeto, debe sanitizar correctamente los datos antes de construir el objeto, ya que si no, estaría permitiendo la ejecución automática de los Magic Methods sin haber tomado ninguna precaución. Esto no es siempre así, y por lo general, los desarrolladores no tienden a validar las propiedades de las clases en las que no se establece un valor a través de una entrada de datos de un usuario. Es decir, valores que supuestamente ningún usuario debería haber podido manipular con el interfaz. Grave error.

Un ataque de PHP Object Injection

Como ya hemos dicho, visto todo lo anterior, un atacante podría enviar un objeto malicioso serializado en formato JSON a una aplicación web en PHP escrita bajo el paradigma de POO y en la que la clase del objeto que se envía tiene un Magic Method implementado con una función PHP insegura para la construcción o destrucción del objeto. Si la aplicación web hace uso de la  función unserialized sin sanitizar previamente los valores del objeto que viene por JSON antes de construir  o destruir el objeto, el atacante habrá podido inyectar código en el sistema para, por ejemplo, hacer un ataque de Remote Command Injection, RFI, etcétera..

En el siguiente ejemplo se puede ver una clase que tiene implementado el Magic Method para la destrucción del objeto. En la implementación se hace uso de la función de shell_exec() tomando como parámetros una de las propiedades del objeto.

Figura 2: Clase de ejemplo en PHP vulnerable a PHP Object Injection

La clase se llama “Example1”, implementa el Magic Method __destruct() y dentro del mismo se encuentra la función “shell_exec”, a la que se le pasa como parámetro la propiedad data del objeto invocado. Este código de ejemplo permite, a través de la inyección de un objeto PHP, ejecutar un comando en el sistema operativo. Esto es posible no por la inyección del objeto en sí, si no por no controlar el parámetro que se le está pasando a la función shell_exec.

Preparando el payload

Para explotar esta vulnerabilidad de forma sencilla lo primero que hay que hacer es preparar el payload. Para ello se ha de crear un objeto con la propiedad data maliciosa, es decir, con el comando que queremos inyectar dentro de shell_exec.

Figura 3: Objeto PHP malicioso para construir el Payload

A continuación se debe realizar un codificado de tipo URL del objeto PHP malicioso que se desea inyectar, por lo que tras este procesado ya se habrá generado el payload que se necesita para tomar control de esta aplicación web y será posible enviarlo a través de un parámetro una petición HTTP. En nuestro ejemplo, éste es el payload obtenido
O%3A8%3A%22Example1%22%3A1%3A%7Bs%3A4%3A%22data%22%3Bs%3A20%3A%22ipconfig+%7C+find+%22v4%22%22%3B%7D
Una vez inyectado el objeto PHP serializado en la aplicación vulnerable, el resultado devuelto es la salida del comando ejecutado en el sistema, en este caso las direcciones IP privadas del sistema.

Figura 4: Ejecución del comando a través del método __destruct()

Además, en nuestro ejemplo no solo se llamó al Magic Method __destruct, sino que también se invocaron los métodos __wakeup y __toString de forma automática, ya que el motor va utilizando de forma implícita a los métodos cuando los va necesitando.

Conclusión final de este ejemplo

Esta vulnerabilidad, a pesar de necesitar de una buena serie de condicionantes, ya se ha dado en muchos CMS y frameworks de Internet. A continuación tenéis una pequeña lista de vulnerabilidades de PHP Object Injection publicadas debido al mal uso de la función unserialized.
- Vanilla Forums 2.0 - 2.0.18.5 - PHP Object Injection Vulnerability
- Joomla! <= 3.0.3 - PHP Object Injection Vulnerability
- Joomla! <= 3.0.2 PHP Object Injection Vulnerability
- CubeCart 5.2.0 PHP Object Injection Vulnerability
- Invision Power Board <= 3.3.4 PHP Code Execution
- Tiki Wiki CMS Groupware <= 8.3 PHP Code Execution
- SugarCRM CE <= 6.3.1  PHP Code Execution
Para mitigar estos ataques es mejor no utilizar la función unserialized que construye directamente el objeto, y utilizar en su lugar la función PHP json_decode, con la que se consigue validar cada dato que se recibe para evitar la inyección de propiedades maliciosas que puedan acabar inyectadas en funciones inseguras.

Autor: Ricardo Martín (@ricardo090489)
Security QA Engineer en Eleven Paths

jueves, noviembre 27, 2014

WordPress: Si esta semana no te ocupaste de su seguridad... ha sido una mala idea

Si tienes instalado un WordPress, esta es una semana para preocuparse de verdad de la seguridad. Es probable que si no has tenido cuidado puede que alguien haya aprovechado alguna de las múltiples cosas que han salido publicadas, así que hoy toma un rato para preocuparte por él, ya que hay actualizaciones de seguridad, exploits publicados y pueden que te hayan hasta infectado algún blog.

Figura 1: Esta semana ha sido dura para la seguridad de WordPress

Exploit remoto para WordPress WP-Backup Plugin

Este ha sido quizá el fallo más peligroso que ha salido y desde luego se ha empezado a utilizar masivamente así que, si no has tenido cuidado, lo más probable es que te hayan robado la base de datos de tu WordPress y debas cambiar las contraseñas de todas tus cuentas y/o activar alguna protección extra como Latch para WordPress.

Figura 2: Sección del exploit escrito en Bash para robar el backup de WordPress WP-Backup Plugin

El problema es que ha salido publicado un Exploit para WP-Backup Plugin 2.2.4 escrito en Bash Script que está disponible en Full-Disclosure y que permite a un atacante remoto llevarse el backup completo de tu WordPress. Por supuesto nosotros hemos metido la detección de nuestro sistema de pentesting persistente Faast, pero debes comprobar si tienes esta versión vulnerable y si es así, actualizar y preparar un plan asumiendo que te han robado las contraseñas.

WordPress 4.0.1: Actualización Crítica de Seguridad

Desde WordPress se ha publicado una actualización de seguridad 4.0.1 que corrige un total de 23 CVEs de seguridad, es decir, una buena cantidad de ellos, incluido el siguiente que os pongo en este artículo. La actualización es crítica, ya que se puede explotar inyección de comandos remotamente, por lo que que deberías actualizar urgentemente. 

Figura 3: Actualización de seguridad crítica de WordPress 4.1

Si ya tienes instalado Latch en WordPress, nuestro equipo de QA ya comprobó la actualización y el sistema funciona perfectamente, así que cuanto antes migres mejor que mejor.

Figura 4: Confirmación de comprobación de Latch en WordPress 4.0.1


WordPress 3 Persistent Script Injection

El pasado 20 de Noviembre se publicó en la lista Full-Disclosure un bug de inyección de JavaScript en comentarios. Esto no afecta a la vista de administrador - ya que los comentarios son truncados - pero si se aprueban afectan a todos los usuarios. Esto puede utilizarse para ataques de BlackSEO, distribución de malware, etcétera.

Figura 5: Workaround propuesto para solucionar este bug

Afecta a todas las versiones desde WordPress 3.0 a WordPress 3.9.2. La respuesta de WordPress es pásate a la versión 4.0.1, pero si no quieres pasar a la versión 4.x tendrás que aplicar un workaround propuesto por los descubridores del bug.

Preocupación constante por la seguridad

Cada vez son más rápidamente explotados los bugs que se descubren, así que si tienes una superficie de servidores con cualquier framework expuestos a Internet, debes estar muy atento a todas las actualizaciones de seguridad que salen, pero debes tomártelo muy en serio.

El tiempo para "yo me ocupo de la seguridad una vez al mes" hace tiempo que pasó, así que fortifica desde la instalación, y asegúrate de que diariamente estás vigilando qué sucede. Tienes asumir que siempre habrá cosas de las que no te enterarás y es mejor poner todas las medidas de mitigación posibles, como cambio de contraseñas periódicas, autenticación de segundo factor, backups, revisión de seguridad periódica - o continua -, etcétera, etcétera.

Saludos Malignos!

miércoles, noviembre 26, 2014

ShuaBang Botnet: Red de terminales zombies Android creada vía Google Play para Black Hat App Store Optimization

Hace unos días que habíamos pasado el informe a los clientes de los servicios de Vigilancia Digital, pero ayer fue el día que publicamos los detalles de ShuaBang Botnet, una red de terminales Android Zombies que descubrimos hace quince días y que estaba orientada a hacer lo que se denomina BlackASO (BlackHat App Store Optimization), es decir, una especialización del BlackSEO pero orientado al posicionamiento de las apps en los store de Google Play o App Store.  

Figura 1: ShuaBang Botnet en Android

Para conseguir construir esta botnet, el creador había construido más de 300 apps fraudulentas que había publicado en Google Play con distintas cuentas de desarrollador. Estas apps no eran todas maliciosas en sus primeras versiones, pero sí que podrían ser actualizadas en versiones posteriores para no llamar la atención y pasar bajo el radar. Las apps, por supuesto, no eran de gran calidad y ofrecían wallpapers, tutoriales, y similares. Trucos muy habituales por los creadores de adware en el mundo de Google Play.



De todo el conjunto, unas 100 de ellas - que están disponibles en el informe de ShuaBANG Botnet  - también en versión en inglés - que hemos publicado desde Eleven Paths - infectaban a los que las instalaban. Revisando en nuestro Path 5 los permisos de las apps que utilizan para su funcionamiento, vimos que la lista que necesitan son lo siguientes.

Figura 3: Permisos utilizados por las apps maliciosas de esa botnet

Para conseguir su objetivo, desde el panel de control de la botnet, una vez que se conseguía infectar a un equipo, se proveía al dispositivo con una cuenta de Google que había sido creada por el master de la botnet.  Es decir, asociaba el dispositivo con una cuenta de Google que previamente había creado el atacante. Según pudimos averiguar, el creador de este esquema de botnet había sido capaz de crear 12.500 cuentas de Google que iba distribuyendo en las apps de los dispositivos para poder asociar el dispositivo con esa cuenta mediante un proceso de checkin que ejecuta desde el propio terminal infectado.

Figura 4: Esquema de entrega y registro de cuentas Google a los dispositivos infectados

Una vez que tiene una cuenta registrada desde un dispositivo el atacante utiliza los tokens de servicio que devuelve Google para realizar acciones de Click-Fraud - muy habitual en el mundo del fraude online - para posicionar información y realizar diferentes acciones. Con una cuenta Google registrada en un dispositivo Android es posible realizar muchas tareas que afectan al posicionamiento de apps en los markets, tanto de Google Play como otros para hacer BlackASO, pero también en otros sitios de Internet para hacer BlackSEO tradicional desde el dispositivo.

Figura 5: Control de acciones y renovación de tokens en los equipos infectados

El panel de control de la botnet es bastante sencillo y está pensado para ser bastante funcional. Por su aspecto y el código generado ha sido hecho a medida para esta botnet. En el se pueden ver los datos de las cuentas y terminales que controla.

Figura 6: Cuentas en el panel de control de la botnet

Curiosamente, en la base de datos hay un acceso privilegiado para una cuenta de una empresa de publicidad china que cuenta con sus propias credenciales de acceso a los datos desde una dirección muy concreta perteneciente a ellos.

Figura 7: Acceso privilegiado a la base de datos

Una de las cosas que más nos llamó la atención es que el sistema registraba, o intentaba hacerlo, apps utilizando el token de registro del dispositivo a la cuenta. Esto podría haber supuesto - de haber funcionado su sistema - que se hubieran podido forzar la descarga de nuevas apps en el dispositivo remotamente, pero viendo el código que empleaba parece que no lo había conseguido. Eso sí, nos quedó claro que ese era el camino que seguía.
Figura 8: ¿Intento de registro de apps en dispositivos remotos para generar su descarga automática?

Ahora las apps están caídas de Google Play pero el panel de control y muchos terminales infectados están aún disponibles - ninguno en España  por ahora - ya que su objetivo era India, Brasil y Rusia. En el informe publicado tienes los nombres y los hashes de las apps que podrás encontrar probablemente en otros markets.


Figura 9: Presentación de Path 5 - En busca de los cibercriminales

Para los que quieran saber cómo funciona nuestra plataforma de investigación Path 5, os dejo la conferencia del SID 2014 en la que David Barroso lo cuenta con un ejemplo detallado de cómo un analista puede realizar estas investigaciones, que es lo que hicimos nosotros para detectar ShuaBang Botnet. Si quieres más información de Path 5, ponte en contacto con nosotros.

Saludos Malignos!

martes, noviembre 25, 2014

CyberCamp is Coming: Get Ready!

Ya hay más de 1.000 personas registradas en el próximo CyberCamp que tendrá lugar los días 5, 6 y 7 de Diciembre en Madrid. Hackers y aficionados a la seguridad informática por doquier, en un evento organizado por Incibe - el antiguo Inteco - y en el que se darán cita ponentes de la talla de Fermín J. Serna a.k.a. "zhodiac", Jeff Moss - fundador de DEFCON y BlackHAT -, Richard Stallman, Stefano Di Paola - padre del HPP -, Alejandro Ramos a.k.a "Dab" co-autor del ya "mítico" Hacker Épico", Joanna Rutkowska, Raúl Siles, Alfonso Muñoz y Jorge Ramió - autores del libro de Criptografía: de la cifra clásica a RSA - o mi compañero de Eleven Paths y amigo Pablo González y su taller de Metasploit, entre otros muchos.

Figura 1: CyberCamp tendrá lugar el 5, 6 y 7 de Diciembre de 2014 en Madrid

El evento se va a llenar de conferencias, talleres, cursos, grupos de trabajo, tertulias, etcétera, para que ese fin de semana sea muy especial para mejorar los niveles de seguridad informática de todos los participantes. Lo mejor de todo es que es gratis para todos los asistentes - hasta que se acaben las plazas - , y que a pesar de lo que piense la RAE, los hackers que allí se junten van a hacer que mejore de forma exponencial la seguridad de nuestro país. Por eso, hemos hecho este vídeo de invitación con Cálico Electrónico.


Figura 2: Cálico Electrónico y el CyberCamp 2014

Yo estaré el día 6 de Diciembre dando una charla - aún no he decidido exactamente el tema pero creo que prepararé alguna cosa nueva - y además, para que los que quieran puedan participar en el concurso de Latch y llevarse los 10.000 USD, vamos a dar un Taller de Latch, así que reserva cuanto antes tu plaza para que no te la quiten.

Saludos Malignos!

PD: Hoy por la tarde comienzan las Latch Talks, así que si aún no te has apuntado date prisa para poder llegar a la sesión de hoy, de mañana y/o de pasado mañana.

lunes, noviembre 24, 2014

Cómo "cocinar" una aplicación web PHP con Latch

Este viernes di mi charla en {Codemotion 2014}. La charla, bajo el título de {Love Always Takes Care & Humility} estaba centrada en una demo paso a paso para que un programador pudiera integrar una aplicación PHP con Latch desde cero. Para darle un toque curioso a la charla, la presentación estaba ambientada en la serie Breaking Bad y en este artículo os recojo paso a paso la demo de la charla.

Figura 1: Cómo "cocinar" una aplicación web PHP con Latch

Las diapositivas que utilicé para esta sesión las he subido a mi canal SlideShare por si alguien las quiere ver, pero en ellas no se encuentra descrita la demostración que enseñé durante la charla, por lo que os la paso a describir por aquí.


Paso 1: Arquitectura de la aplicación PHP sin Latch

El sitio web, llamado Maligno.com, no estaba publicado a Internet, pero sí que tenía conexión a Internet para poder consultar en cualquier momento los servidores de Latch. El sitio solo cuenta con una página de inicio llamada index.php desde la que se puede acceder a un formulario de login que se publica desde login.php.

Figura 3: Arquitectura de la web sin usar Latch

El formulario de login es autenticado por loginController.php que se encarga de verificar incialmente que el usuario y la contraseña son correctas. Si son correctas las credenciales, el usuario accede a su página de perfil donde no hay nada más que un mensaje de bienvenida.

Figura 4: Tabla users en MySQL se ha habilitado una columna para guardar el Latch de cada usuario

Esa comprobación se realiza desde una función creada en latchHelpers.php, donde además de autenticar el usuario contra la base de datos, se ha creado otra función para saber si un usuario tiene puesto un Latch y cuál es su AccountID - en la base de datos LatchID -, que se ha llamado getLatchID().

Figura 5: Funciones authenticateUser() y getLatchID() en LatchHelpers.php

A partir de este punto, ya podemos comenzar a integar Latch en esta aplicación web en PHP en varios pasos, que fue lo que se hizo en la demo.

Paso 2: Creamos la aplicación Latch para esta web en PHP

Para comenzar la integración debemos crearnos una cuenta de desarrollador gratuita en Latch. Allí deberemos crear una aplicación Latch donde es necesario proporcionar información para mostrar en las alertas de usuario, como son el mensaje de texto, un logotipo para mostrar en la app, un correo electrónico y/o número de teléfono para casos de emergencia.

Figura 6: Pasos para crear la app de Latch para identificar la web en PHP

Una vez creada, la aplicación tendrá un Application ID y un Secret para autenticarse en el sistema y hacer uso del SDK de Latch. El SDK de Latch se puede descargar desde la web de Latch o en el caso de que utilices pear directamente con la herramienta de instalación de software.

Figura 7: Creación de la app de Latch. En este caso Pollos Hermanos.

El SDK de Latch para PHP son tres ficheros Latch.php, Errors.php y LatchResponse.php que se guardan dentro de la carpeta controllers/Latch/ para que puedan ser utilizados en la aplicación incluidos en aquellas partes donde será necesario hacer uso del API de Latch.

Figura 8: SDK de Latch, ficheros originales de la web
y Controladores de Integración con Latch

Los datos de ApplicationID y Secret se van a cargar en latchConfig.php, donde además se hace inclusión del SDK de Latch para PHP. A partir de este momento, cada vez que sea necesario utilizar el API de Latch bastará con incluir latchConfig.php que nos dará acceso directo a las funciones.

Figura 9: Configuración en latchConfig.php del SDK de Latch para PHP, el ApplicationID y el Secret

Paso 3: El pareado de la cuentas con Latch

Una vez que la aplicación web PHP está conectada con Latch, ya podemos pasar a la fase de parear las cuentas de usuario, para eso el proceso de integración será el siguiente descrito en el gráfico.

Figura 10: Proceso para parear cuentas de la web PHP con Latch

Lo primero es añadir en profile.php un formulario para solicitar el TTP (Token Temporal de Pareado) que da la app de Latch cuando se parea un servicio. Si no lo has hecho nunca, te recomiendo que sigas el tutorial con Tuenti, Nevele Bank o con OxWord para tener la experiencia de usuario clara. 

Figura 11: Formulario para solicitar el TTP dentro del perfil de usuario

El TTP es enviado a un controlador en latchController.php donde se va a recibir y solicitar el pareado. Para eso se hará uso de la función pair() del SDK de Latch para PHP que puede verse en Latch.php.

Figura 12: Funciones en Latch.php del SDK de Latch

Así, en latchController.php únicamente se carga latchConfig.php, se llama a la función pair() del API de Latch y el resultado se guarda haciendo un Update en la base de datos MySQL para que el AccounID (identificador único del Latch) quede asociado al usuario.

Figura 13: Código de LatchController.php para hacer el pareado de las cuentas

Como se puede ver, al final en la base de datos ya tendremos el id por el que preguntar el estado y al mismo tiempo al usuario le habrá salido - cuando realice el proceso completo de pareado - el Latch de nuestra app "Pollos Hermanos" en su aplicación.

Figura 14: Cuando el usuario hace el pareado, el resultado de la función pair() se almacena en la tabla users

Con esto habríamos acabado la parte del pareado de las cuentas y ya solo quedaría comprobar si el pestillo está abierto o cerrado en cada uno de los intentos de login en la web

Paso 4: Comprobación del estado del pestillo del usuario

Ahora, cada vez que se realice un proceso de login hay que comprobar cuál es el estado del AccountId asociado a esa cuenta de usuario. Para ello, el proceso que tendremos que hacer en la aplicación web PHP es el siguiente descrito en el gráfico.

Figura 15: Proceso para autenticar el estado del Latch de cada usuario

Como se puede ver, el proceso en la aplicación web PHP pasa por modificar el controlador de autenticación loginController.php para que además del usurario y la contraseña compruebe el estado que tiene ese AccountID. Para ello, el código necesario sería el siguiente.

Figura 16: Código de verificación del estado en LoginController.php

El resto del trabajo para un usuario es simplemente decidir desde su app de Latch si quiere tener un estado abierto o cerrado, como con el resto de las aplicaciones.

Figura 17: Aplicación de "Pollos Hermanos" en mi app de Latch

Paso 5: Finalización de la integración

Por supuesto, el resto del proceso aún está por terminar. Faltaría hacer un proceso de despareado, que podría ser de forma segura creando por ejemplo una operación que bloqueara si se puede realizar el unpair() o no, pero la parte principal del proceso ya estaría hecha. El objetivo de este ejemplo era que pudiera hacerse desde cero en 10 minutos dentro de la charla, para aprender a desarrollar mejor esta semana tenemos las formaciones gratuitas de Latch en Latch Talks. Mañana vía Internet de 16:00 a 17:00 horas para los desarrolladores de Java, el miércoles para los desarrolladores de .NET y el jueves para los desarrolladores en PHP.

Figura 18: Latch Talks para aprender a integrar apps Java, .NET y PHP con Latch

Por último, el fin de semana del CyberCamp tendrá lugar una serie de talleres gratuitos en los que se podrán hacer proyectos tutorizados, por lo que si quieres aprender bien es el lugar ideal. Después de esto, ya puedes llevarte los 10.000 USD del Latch Plugin Contest.

Saludos Malignos!

domingo, noviembre 23, 2014

Detekt: ¿Hay alguien espiándome en mi ordenador?

Ya hace mucho tiempo que salieron a la luz pública casos de espionaje de gobiernos a ciudadanos por medio de software especialmente creado para espionaje gubernamental. Ahora Amnistía Internacional, Electronic Frontier Foundation y otras organizaciones pro-derechos civiles ha lanzado Detekt, una herramienta creada por Claudio Guarnieri para ayudar a encontrar software de espionaje utilizado en equipos de personales.

Figura 1: ¿Hay alguien espiándome en mi ordenador?

Dentro del desarrollo de soluciones R.A.T. (Remote Administration Tools) existen algunas que son más del mundo underground hechas por hacktivistas para sus acciones de reivindicación, otras que son generadas por grupos de cibercrimen que pueden ir desde soluciones amateurs hasta bots profesionales que se comercialización, algunas hechas a medida para operaciones A.P.T. contra objetivos concretos - famosos son los ataques contra los grupos pro-Tibet y el Dalai Lama - y otras que se hacen para comercializar en gobiernos y cuerpos de seguridad del estado.

El software de espionaje comercial

Este último, el software de espionaje gubernamental es un sector en el que se posicionan algunas empresas para cubrir las necesidades que en algunos países tienen los gobiernos que han legalizado este tipo de técnicas, como por ejemplo en Holanda y Alemania donde los cuerpos de seguridad del estado puede utilizar estos programas baja la supervisión judicial. Por supuesto, como denunció Reporteros sin Fronteras, también acaban siendo utilizados por gobiernos totalitarios que persiguen a disidentes sin ningún control. De las empresas que hacen este tipo de software hay algunas que se han hecho muy populares por incidentes y filtraciones recientes.


Figura 2: Funcionamiento de FinFisher/FinSpy Mobile

El primero que saltó a los medios de comunicación masiva fue el caso de FinFisher y su software de monitorización móvil FinSpy que desarrolla la empresa Gamma International. Este software fue descubierto en las revueltas de la primavera árabe en Egipto, y desde entonces ha estado en el centro de la noticia. En un análisis posterior de la herramienta se descubrieron paneles de control en 25 países por todo el mundo, lo que dejaba al descubierto más o menos qué organizaciones y/o países estaban utilizando dichos programas.

Figura 3: Ubicaciones en las que se encontraron paneles de FinFisher

Por supuesto, en el mundo de la seguridad se le sigue la pista a FinFisher & FinSpy desde hace tiempo, ya que el truco de Masque utilizando provisioning profiles - no suplantando apps, pero si metiendo fake apps - para infectar terminales iPhone con software de espionaje ya lo usaban ellos hace tiempo, y en los equipos Windows llegaron a utilizar a Mozilla Firefox para colarse dentro de los sistemas.

Figura 4: Panel de análisis de Hacking Team RCS 9

Otro de los software comerciales posicionados como R.A.T.s gubernamentales es el famoso RCS de Hacking Team, que recientemente ha sufrido una filtración de su documentación permitiendo saber exactamente cómo funciona este software. Entre los trucos que usan este último están los ataques de fake AP en redes WiFi para infectar equipo o el último de hacer Jailbreak a los terminales iPhone desde un equipo Windows pareado para poder infectarlo con el bot de RCS.

Por supuesto estos no son los únicos programas espías que se venden, ni las únicas empresas que los desarrollan. Ya vimos hace tiempo cuando Anonymous hackeó la empresa HBGary como ellos desarrollaban herramientas como 12 Monkeys o Task.B para troyanizar equipos infectados.

¿Qué hace Detekt?

Detekt es un software desarrollado en Python para buscar los rastros de FinFisher/FinSpy & Hacking Team RCS dentro del equipo, además de algún otra R.A.T. popular como DarkComet, Por supuesto, después de toda la información que se ha hecho pública de ambas familias se conoce mucho de ellos ya que de FinFisher se filtró el código completo y de HackingTeam RCS toda la documentación, así que si se lanza en un equipo infectado, entonces es posible que sepa si hay alguno de ellos actualmente instalados en el equipo.

Figura 5: Funcionamiento de Detetk. Te recomienda hacerlo offline

La pregunta que mucha gente se hace es si es fiable o no. La respuesta es que no es 100% fiable, por supuesto. En primer lugar los creadores de los RATs que busca este software están acostumbrados a lidiar con software antimalware desde hace mucho tiempo, y está claro que harán los deberes para primero hacerse indetectables y segundo atacar e inutilizar este software en los equipos en los que se vaya a utilizar. 

No hay que olvidar que este software de espionaje tiene conexión directa con el panel de control y puede mutar a gusto, cambiar los binarios, modificarse en caliente, etcétera. Nada sencillo para detectarlo en un equipo vivo. De hecho, mi solución contra este tipo de casos es la que os propuse en en un artículo que decía que una buena política antimalware y antiAPTs debe mirar en el pasado, analizando instantáneas pasadas de los sistemas informáticos de una organización.

Figura 6: Propuesta de análisis de copias de seguridad para detectar bots mutados

Sea como fuere, esto es un juego del gato y el ratón, así que si tienes un equipo del que sospechas pueda haber sido infectado con FinFisher/FinSpy o Hacking Team RCS mejor que pases un antimalware actualizado y pruebes Detekt antes que no hacer nada, pero lo suyo sería que le hicieras un buen análisis forense a ver qué sale de ahí, y que antes de llegar a ese punto tengas fortificado al máximo tu Windows. A día de hoy Detekt sólo funciona en Windows en versiones anteriores a Windows 8.1.

Saludos Malignos!