Unos vídeos de unas charlas para remolonear en sábado

Aprovechando que es sábado he recopilado algunos de los vídeos de algunas charlas que habían salido ya publicadas, así que aquí os las dejo todas. El primer vídeo es la grabación oficial de la charla de la Defcon 21 "Fear the Evil FOCA: IPv6 attacks in Internet connections. Ahí están las demos de hacking en IPv6 que he ido contando a lo largo de todo este año.

Figura 1: Fear the Evil FOCA: IPv6 Attacks in Internet Connection

La segunda es una charla que tuve con unos chavales de Formación Profesional en el centro CEPAL sobre en qué consiste el mundo del pentesting y la seguridad informática. No fue una presentación, sino una sesión de preguntas y respuestas en tono desenfadado.

Figura 2: Charla con Chema Alonso en Cepal

La tercera es la charla que tuve con Jordi Évole y que salió en el programa de Salvados "Nos Espían" que habían subido de forma independiente. Como muchos tuvieron problemas para verla, ahora en Youtube es más fácil.

Figura 3: Charla con Jordi Évole en el programa Salvados "Nos espían"

La última es la charla sobre 15 años de SQL Injection que di en la Codemotion de este año. Las diapos las he subido, pero por un nefasto problemilla con el equipo, las diapos del final se perdieron. No pasa nada, las tenéis en el vídeo siguiente.

Figura 4: Conferencia en Codemotion "Feliz 15 aniversario, SQL Injection"

Y eso es todo, que no es poco para un sábado en el que hace mucho frío y habría que estar durmiendo todo el día en la camita descansando y recuperando fuerzas, haciendo el bicho bola. Yo, como soy un poco "sádico", voy a traumatizar a mis alumnos del Máster de Seguridad con unas clases de Sniffing, Spoofing y Firewalling.

PD: He encontrado por casualidad este vídeo antiguo con la obra de teatro que me dedicó mi amigo @EloyArenas en la que Chema Alonso sufría las de Caín con ROM, su clon personal. Os lo dejo por si tenéis 20 minutos para verlo.

Figura 5: Entiéndeme tú a mí: Chema Alonso (Eloy Arenas) y Rom (Jorge Roelas)

Saludos Malignos! 

La historia de un carnicero agradecido con un "hacker"

Hace algún tiempo, cuando estaba recopilando información para escribir el artículo sobre la seguridad de los sistemas basados en PLCs que se llamó “Tu industria en mi manos”, creé una lista bastante extensa de equipos de automatización expuestos en Internet. Cuando el tiempo me lo permite - muy de tarde en tarde -, me dedico a volver a comprobar si los sistemas continúan “vivos y expuestos”. Los resultados son desalentadores.

¿Es que nadie leyó el artículo o es que a nadie le importa realmente la seguridad de sus automatizaciones? Lo más probable es que seguramente, salvo a los que estamos cerca del mundo de la tecnología y la seguridad, al resto de las personas no les llegan estas cosas.

Con las automatizaciones que me parecen más críticas hago un esfuerzo extra, las analizo y busco algún dato que me ayude a ponerme en contacto con el responsable de ellas de forma directa para poder ayudarle en la manera que me sea posible. Y es así, de esta forma, como comienza esta historia con un carnicero.

Entre la larga lista de automatismos expuestos sin seguridad alguna, una de las instalaciones que se encontraba desprotegida en Internet, parecía a simple vista la encargada de controlar la temperatura de alguna industria cárnica.

Figura 1:El PLC de la industria desprotegido en Internet 

Husmeando con cuidado de no romper nada en la memoria del PLC, se encuentra un comando AT para enviar mensajes SMS a un teléfono móvil con las alarmas del sistema. Esto es algo muy común en este tipo de sistemas de control que pretender avisar a los responsables en el mismo momento en que se detecte un problema que pueda afectar a su negocio.

Figura 2: Número de teléfono para el envío de alertas vía SMS

Descubierto esto, quise ponerme en contacto con el dueño de la plataforma para advertirle de la situación de inseguridad en la que se encontraba, así que decidí buscar información de esta persona haciendo un poco de trabajo de campo con los buscadores de Internet.

En este caso, simplemente poniendo el número de teléfono de que aparecía como contacto del sistema de alertas, Google devuelve - entre otros - un resultado la mar de interesante. Un fichero Excel con el número de teléfono buscado que estaba almacenado en algún servidor FTP.

Figura 3: Resultados de búsqueda del número de teléfono. Un XLS en un FTP

Pero claro, no todo iba a ser tan fácil, ya que al intentar acceder al fichero, el resultado que se obtiene no es el documento, sino que el servidor FTP solicita credenciales de acceso.

Figura 4: El servidor FTP autenticado

En este caso no dejó de ser curioso esto, ya que el documento está indexado en Google, lo que indica que en algún momento del pasado este servidor FTP estuvo abierto a todo Internet, y Google ya lo cacheó. Al abrirlo el documento arrojó un montón más de información de la que esperada en un inicio. Información que no debería ser pública según indica la LOPD. Vamos, que el dueño de ese fichero, al aplicar la LOPD se olvidó de borrar la URL de los buscadores el dueño del fichero tras ponerlo bajo acceso autenticado.

A partir de aquí, teniendo el nombre y los apellidos de alguien relacionado con el número de móvil que había sacado del PLC, y sabiendo que es una industria cárnica que se encontraba en una localidad donde estaba ubicada la dirección IP en la que se exponía el sistema, encontrarla fue coser y cantar.

Figura 5: Los datos de contacto del número de teléfono

Decidí ponerme en contacto mediante un mensaje de correo electrónico aunque he de decir que no me esperaba respuesta alguna. Os aseguro que la mayoría de veces que he intentado avisar a alguien de que tiene una brecha de seguridad he recibido como habitual el silencio por respuesta, cosa bastante frustrante, pero allá cada cual con sus instalaciones.

En este caso la respuesta fue totalmente diferente. La empresa responsable de la infraestructura informática de la planta hizo su trabajo buscándome por redes sociales hasta dar con la empresa donde trabajo y se puso en contacto conmigo, no sólo para que le facilitase la información completa de cómo los había encontrado, sino para agradecerme de parte de la industria cárnica que los avisase. Un sabotaje de éste sistema de automatización podía haber provocado la pérdida de productos cárnicos cuyo valor económico es una linda cifra de seis dígitos.

A día de hoy, he vuelto a comprobarlo y ésta gente ha hecho sus deberes, ya no tiene su PLC expuesto a cualquier desaprensivo con tiempo libre, además de haber cerrado algún otro puerto que tenían abierto. Es reconfortante, muy reconfortante ver que realmente sirve para algo este tiempo que dedicamos a buscar “problemas de otros”. He querido compartir esta experiencia porque, por cada una buena respuesta, sé que hay diez malas, pero aún así...¡no perdamos la esperanza!

Saludos,

Autor: Juan Luis Valverde Padilla
jl.valverde@jvalverde.es

PD: Ahora tendré que hablar con el dueño del servidor FTP para contarle cómo borrar las URLs indexadas en Google y recomendarle algún libro que le ayude aplicar la LOPD correctamente, aunque gracias a su fallo de seguridad, pude dar con la empresa y ayudarles a corregir su fallo de seguridad. Irónico. :)

El 12 de Diciembre Eleven Paths presenta su trabajo

Ha pasado ya más de medio año desde que Eleven Paths comenzó su andadura dentro de Telefónica Digital, y durante este tiempo hemos trabajado fuerte y rápido para que antes de que acabase el año pudierais ver todo lo que hemos estado realizando. Y ha llegado el día de hacerlo.

En principio pensamos en hacer un evento en solitario, pero al final hemos decidido trabajar con nuestros compañeros de las demás áreas de Telefónica para presentar juntos entre Telefónica de España, el Vertical de Seguridad de Telefónica Digital y nosotros, Eleven Paths, todos los productos y servicios en un acto que hemos llamado Innovation Day.

Será un evento de sesión de tarde, en el que se invitan a clientes, responsables de seguridad, profesionales de la seguridad y responsables de sistemas a participar en la jornada. Será después de comer, y habrá un café, luego unos conciertos de música y por último tendremos un "fiestorro" a lo grande gracias a la colaboración de todos los partners de seguridad que tenemos en Telefónica.

El registro está bastante limitado, así que hemos hecho una web de pre-registro donde te puedes inscribir. Una vez que te registres, al cabo de unos días, recibirás la confirmación de la plaza si aún es posible, así que no tardes en registrarte.

Figura 1: Preinscripción al evento Innovation Day

Entere las cosas de las que vamos a hablar están los servicios de CiberSeguridad de Teléfónica, de nuestro querido Faast, de toda la familia de MetaShield Protector, de Saqqara, de los servicios anti APT, de un proyecto que hemos llevado con bastante secreto en Eleven Paths desde el mes de Junio y al que internamente hemos llamado "Path 2" y alguna cosa más.

De "Path 2" os contaré mucha más información a partir del día 12 de Diciembre, pero he de decir que ha sido una experiencia para todos nosotros parir una tecnología, conseguir patentes a nivel mundial de ella, y ver en un tiempo tan corto que se integre en tantos sitios. Pero tendrás que esperar a ese día para que pueda hablarte de ella.

Si quieres venir ese día, y cumples con los requisitos de a quién va dirigido este evento, puedes pre-registrarte desde ya en esta web. Nos vemos el 12 de Diciembre en La Premiere de Eleven Paths.

Saludos Malignos!

Tú NO miras la SmartTV, ella te mira a tí

Ayer leía una interesante nota relacionada con los SmartTV de LG, donde un consultor del Reino Unido llamado Jason Huntley (@DoctorBeet) comentaba que había descubierto que su televisor registraba y enviaba los datos de los canales que estaba mirando a la empresa LG Electronics, incluso luego de haber desactivado la función “Collection of Watching Info”.

Es importante recordar que durante el 2012, LG lanzó al mercado una plataforma dirigida a los usuarios de sus SmartTV (LG Smart AD, que casualmente hoy se encuentra sin servicio) que les permitía a los anunciantes conocer detalles mas precisos de la audiencia activa en los distintos programas de televisión, y así seleccionar en qué programa colocar sus anuncios comerciales basándose en información como por ejemplo: Edad, Sexo, Ubicación Geográfica, etcétera, etcétera

Figura 1: Imagen del sitio LG Smart AD sin servicio hoy

Como el sitio actualmente se encuentra en mantenimiento, no es posible ver mucha información al respecto, sin embargo si utilizamos el querido sitio archive.org y buscando por http://lgsmartad.com/main/main.lge podemos encontrar estas dos definiciones:

Figura 2: Imágenes tomadas de https://web.archive.org/web/20130809105525/http://lgsmartad.com/main/main.lge

Por lo cual el objetivo de la plataforma es bien claro y nadie puede negarlo, aunque estaría interesante que la función de desactivar el envío de información, funcionara también... Básicamente el esquema es sencillo, el sistema LG Smart AD envía los datos a través de un mensaje Post a los servidores de la empresa cada vez que alguien cambia de canal, dándole a los anunciantes y a las empresas encuestadoras de rating, información al instante sobre lo que sucede con cada usuario (conocido en el mundo de la publicidad televisiva y radial como el “minuto a minuto”).

Sin embargo, lo que más llama la atención es en realidad, que además de esa información, también es capaz de enviar datos como por ejemplo los nombres de los archivos que son reproducidos por medio de un USB externo conectado al TV, asociados al identificador único del televisor. Como es de esperarse, en texto plano, tal como se puede ver en la captura hecha por el propio DoctorBeet en su post original:

Figura 3: Imagen de la captura realizada por el investigador donde se observa el ID del SmarTV

Como parte de su investigación, DoctorBeet creó un archivo de video con un nombre llamativo para ver si el mismo podía identificarse con un analizador de tráfico, y el resultado fue el esperado. Si tu red WiFi es insegura, todo el mundo podrá ver qué estás viendo en tu SmartTV.

Figura 4: Imagen de la captura realizada por el investigador donde se observa el nombre del archivo creado por él para la prueba

Aquellos que trabajan en tareas de investigación, este tipo de noticias les resulta más que interesante porque en lo primero que piensan es en la posibilidad de utilizar ingeniería social para identificar por medio de un archivo determinado reproducido en un SmartTV, quién lo compró o en qué casa lo están mirando a partir de los datos de la conexión IP (no todo el mundo usa una VPN para conectar su TV a Internet).

Claro está que desde otro punto de vista, y desde la presunción de “todos somos inocentes hasta que se demuestre lo contrario” utilizada en la legislación de varios países, la invasión a la privacidad es un detalle mucho más que sensible a considerar.

Toda esta noticia puede no ser sorprendente para muchos, y definitivamente esta claro que normalmente, aquellos que somos más paranoicos con todo, tengamos nuestras webcams de las notebooks, de las PC y hasta de SmartTV tapadas. Sin embargo, muchas personas ven como poco probable (o de película) un ataque realizado a través de una TV, o basado en el uso de ella como equipo zombie, o tal vez como pivote, sobre todo porque la gran mayoría de los ataques publicados hasta ahora contra los SmartTV, tienen que ver con noticias sobre denegaciones de servicio. Es así, que como pregunta de reflexión final para todos aquellos a los que ésta noticia no les sorprende:

¿Cuántas personas usan un USB exclusivo para reproducir contenido multimedia en sus dispositivos, y cuántas usan el mismo USB que utilizan en sus trabajos para transportar información confidencial?

Saludos a todos.

Claudio B. Caracciolo

CSA at Eleven Paths

@holesec

Una semana movida de eventos: Perú, Colombia y Málaga

Esta semana ha comenzado con la presentación de proyectos de Talentum Startups 2013, donde me lo he pasado mejor que bien deslumbrado ante lo mucho que han avanzado los proyectos de todos ellos. Ha sido divertido.

Figura 1: José María Álvarez Pallete saluda al robot de BitBrain

También aproveché el lunes para estar en mi sesión semanal del programa de La Mañana con Javi Nieves, para hacer una pequeña entrevista en la radio de la URJC, y para pasarme a ver Al Pirata y su Banda en Rock.FM. Un comienzo ajetreado de semana.

Figura 2: El Pirata haciendo el programa desde el estudio de Rock.FM

Por la noche estoy volando ahora a Perú, donde voy a participar en dos eventos en Lima. Uno es el evento CELAES, y otro es lo que en Telefónica Digital se ha llamado el CyberTour, donde hablaré de todos los productos de Eleven Paths.

Figura 3: Evento CELAES en Lima, Perú

Al día siguiente, es decir, el miércoles, estaré en Bogotá (Colombia) para estar en otro evento del CyberTour, pero esta vez solo durante la mañana, que al medio día emigraré definitivamente para España.

Llegaré el jueves a las 7 a.m. al aeropuerto de Barajas, con el tiempo justo de bajar al ISMS Forum que tendrá lugar en Málaga. Allí participaré en la sesión de tarde en una mesa de debate.

Figura 4: ISMS Forum en Málaga

Para terminar la semana, el viernes y el sábado iré a dar clase a mis chicos del Master de Seguridad de la UEM, completando una semana larga de trabajo. Si veis que durante este tiempo no me prodigo mucho twitteando, contestando correos electrónicos o atendiendo llamadas.... no me lo tengáis mucho en cuenta.

Saludos Malignos!

Credenciales de Facebook enviadas por HTTP y no HTTPs

Tras las demos del programa de televisión, lo que mucha gente preguntó fue eso de "¿No van las credenciales de Facebook siempre por HTTPs?". Eso les llevó incluso a pensar que la demostración que hice pudiera no funcionar o que fuera de cartón piedra. Con el objetivo de que entiendan mejor en que consiste el ataque, he hecho este artículo y un par de gráficos para que lo entiendan mejor, pero si quieres más, puedes leerte el libro de Ataques en redes de datos IPv4 & IPv6.

El primer punto que hay que conseguir es situarse entre medias de la comunicación. Esto se puede hacer de mil formas, desde configurarse como rogue-AP y router a nivel de red, hasta hacer un ataque de ARP-Spoofing, pasando por los ataques Stateless Adrees Auto Configuration en IPv6 o Web Proxy Auto Configuration en IPv4 o IPv6.  Estos tres últimos los puedes hacer con Evil FOCA.

Figura 1: Esquemas de la interconexión IPv6-IPv4 para hacer el man in the middle

Una vez que se está en medio, se tiene acceso al tráfico que se está enviando desde el cliente, y si se tiene acceso a él, existe la posibilidad de poder interceptarlo y manipularlo, que es lo que hacen herramientas como Cain, SSLStrip, SSLSniff, Ettercap en Kali o la Evil FOCA.

Un Fake CA

Según la herramienta para atacar la red que utilices, el comportamiento será uno u otro cuando hay que lidiar con conexiones HTTPs. En el caso de Cain, la herramienta hace una copia del certificado digital original para enviarle al cliente un Fake-CA. Algunas herramientas no validan que el certificado digital cumplan que el certificado esté emitido para ese sitio, que esté caducado o que esté emitido por una entidad certificadora válida en la que se confía, como por ejemplo publicamos con el cliente aMSN. Con el resto de ellas, o bien no funciona la conexión, o se obtiene una alerta de seguridad.

Figura 2: Certificado falso de passport.com creado por Cain

Si el usuario acepta ese certificado, a partir de ese momento estará enviando los datos cifrados al atacante, que los descifrará, leerá, manipulará y los volverá a enviar al servidor cifrados con una conexión HTTP-s hecha, esta vez sí, con el certificado original del servidor web.

El bug de las BasicConstraints

En el caso de SSLSniff, lo que se hace es algo similar, pero aprovechándose de un bug en los clientes que no verifican las BasicConstrains del certificado que reciben. La gracia es que se utiliza un certificado auténtico pero que no tiene validez para crear nuevos certificados. Es decir, supongamos que el atacante se saca un certificado digital para un servidor web llamado miserver.com en Verisign. La cadena de confianza es correcta, y no genera ninguna alerta de seguridad.

El ataque se basa en usar el certificado de miserver.com para crear certificados digitales falsos para sitios como www.facebook.com pero firmado por miserver.com. Si el cliente tiene el bug de BasicConstrains y no comprueba que el certificado de miserver.com no tiene autoridad para crear certificados, podría tomar el falso certificado de facebook.como como bueno. Esto le ha pasado a casi todos los navegadores, y al propio iOS de iPhone no hace mucho.

El Stripping de HTTPs

En el caso de herramientas como SSLSniff o Evil FOCA el ataque se basa en hacer que el cliente navegue entre él y el atacante con HTTP y luego las herramientas navegarán con HTTPs cuando se conecten al servidor oficial. Aquí tenéis la presentación original de Moxie Marlinspike en BlackHat 2009.

  Figura 3: 2009 BlackHat DC Presentation on SSL Stripping de Moxie Marlinspike
En el caso de que el servidor haga un re-direct a HTTPs, como sería por ejemplo cuando el cliente pida http://www.google.com y el servidor le intente llevar a https://www.google.com, será el atacante el que hará la redirección, manteniendo al cliente siempre en HTTP.

Figura 4: El Bridging HTTPs-HTTP con un redirect de por medio

Una vez que se obtenga la página de resultados, es importante que las cookies de sesión - que vendrán marcadas con el flag secure para no funcionen sobre HTTP - sean gestionadas por el atacante. Para ello se puede generar una cookie falsa que se envía al cliente sin dicho flag, permitiendo que él navegue, y que el servidor no note que ha habido una manipulación de la cookie.

Figura 5: La captura de las credenciales vía HTTP en el equipo que corre la Evil FOCA

Esto no es necesario siempre. Muchos servidores que hacen el envío de un mensaje de redirect a HTTPS, siguen escuchando por HTTP, así que aunque pidan que todo se le envíe por HTTPS se puede seguir enviando la información de login por HTTP y permiten la autenticación.

Para conseguir más peticiones de inicio desde el cliente con HTTP, Evil FOCA filtra los resultados de Google, es decir, que si te conectas a Google a través de una conexión atacada por Evil FOCA poniendo en la barra de navegación http://www.google.com, cuando el servidor devuelva un redirect a https://www.google.com, Evil FOCA lo interceptará, hará la navegación a HTTPs y le entregará la página de búsqueda al cliente bajo HTTP. Es decir, hace un Bridging HTTPs-HTTP a www.google.com

Figura 6: Evil FOCA haciendo el Bridging a WWW.GOOGLE.COM y a los resultados de búsqueda de Facebook

Después, cuando el usuario busque en Google algo como Facebook, todos los resultados que vengan apuntando a HTTPs serán sustituidos por HTTP y los redirect Javascript serán eliminados también, para que el engaño sea completo. El resto, será volver a hacer el Bridging HTTP-HTTPs otra vez, pero esta vez a Facebook. Esta es la demo que hice en DEFCON 21.

Figura 7: Política HSTS generada por Google para Gmail

Nota, hay que tener en cuenta que si el cliente ya se ha conectado una vez a Facebook y este le ha puesto un forzado de HTTPs mediante la etiqueta HSTS (HTTP Strict Trasnport Secuirty) entonces hay que hacer que caduque dicha protección con un ataque como el de Delorean.

Mitigaciones

Si estás en un esquema de man in the middle hay poco que hacer salvo cifrar contra un punto de conexión seguro con una VPN con L2TP o SSTP con Certificate Pinning - que PPTP es susceptible de ataques de man in the middle y se puede crackear por diccionario o atacando MS-Chap-v2 con brute-force tras reducción - , y si no es posible mejor que no se navegue nunca. Un plug-in que obligue a navegar siempre vía HTTPS, el uso de certificate pinning para evitar que te comas un bug de BasicConstrains en el futuro o un entidad intermedia maliciosa, además de intentar no entrar a los sitios haciendo clics en ningún sito o confiando en los redirects a HTTPS ayudarán mucho a detectar el ataque.

Saludos Malignos!

Cómo saber dónde está alguien por un chat de WhatsApp

No conocía esta característica, pero parece bastante peligroso que una persona pueda saber por qué dirección IP otra persona está conectándose a WhatsApp. Viendo el interés que el mundo tiene en la seguridad de WhatsApp y su privacidad tanto en cómo espiar WhatsApp, esta es una característica peligrosa que atenta contra la privacidad de las personas, así que lo mejor es que la deshabilites.

El estudio de este fallo lo publicaron Luis Delgado y Ferran Pichel en Security By Default, no solo para aprovechar esta característica con el fin de localizar la dirección IP de una persona, sino como fallo de seguridad que provocaba una Denegación de Servicio en la app, además de poder generar un consumo no controlado de recursos.

El problema de se seguridad radica en que por defecto en las nuevas versiones de WhtasApp para Android - en iPhone aún no se ha introducido esa característica -, la aplicación muestra una imagen de previsualización de cualquier URL que ha sido enviada como mensaje de chat en WhatsApp.

Figura 1: Mensaje de WhatsApp con URL que muestra previsualización de imágenes

La funcionalidad de mostrar una previsualización en miniatura de una imagen de la dirección web compartida es muy común en cualquier red social en la que se permite hacer una publicación de URLs, como por ejemplo Facebook o Google+, y por eso deben haberla introducida. El detalle sin embargo es sutil, y cambia por completo el escenario, ya que en Facebook o Google+ la imagen es descargada desde la red social cuando es visualizada por un cliente, pero al hacer que esto sea por defecto en un cliente móvil los riesgos de seguridad son equivalentes a cuando se permite descargar una imagen remota por defecto en un correo electrónico - algo que por ejemplo Mail para iOS hacía mal y corrigió por motivos de seguridad y privacidad -.

Figura 2: Página PHP en servidor web con img a servidor web que controla los accesos a la imagen

Enviando por mensaje una URL de un sitio web que tenga una imagen que sea incluida desde un servidor web controlado, fuerza al cliente de WhatsApp para Android a hacer una petición al servidor web para descargarse la imagen. En esa petición se puede ver la dirección IP desde la que el cliente de WhatsApp para Android, es decir, el móvil de la persona que está detrás de un número de teléfono, se está conectando.

La ubicación geográfica de las direcciones IP no funciona extremadamente bien y puede que salgan cosas dispares a veces, pero puede suponer un riesgo para la privacidad de una persona en muchos casos en los que sí que se puede geo-posicionar más o menos correctamente dicha dirección IP.

Figura 3: El servidor web registra la dirección IP desde donde se está conectando el cliente de WhatsApp

Además de eso, en la petición va también el USER-AGENT de la petición, donde se dan muchos detalles del software que está corriendo tras un determinado número de teléfono, que en un esquema de ataque dirigido puede ser importante, sobre todo hoy en día que se conocen bugs para los terminales Android no actualizados. No hay que olvidar que los usuarios de terminales con Android, debido a la dispersión de hardware, son los que menos actualizados tienen el sistema operativo, así que son los más expuestos a exploits conocidos.

Figura 4: Distribución de versiones de Android ofrecidas por Google

Como curiosidad extra, si además se quiere, esta utilidad podría utilizarse para realizar ataques desde Internet a los servidores de una red interna, enviando una URL con una imagen que apunte a http://ServidorInterno/app.asp?1; shutdown -- de forma similar a como contaba yo que por culpa de las opciones de carga de imagen en Mail para iOS el jefe se podría cargar la base de datos.

Si tienes WhatsApp para Android lo mejor es que desactives esta opción, que aporta más bien poco para tu seguridad y privacidad. Además, como precaución general procura no seguir enlaces que recibas por mensajes de WhatsApp, ya que aunque no se haga la carga automática de las imágenes, si haces clic en un enlace que recibes por WhatsApp y te lleva a un servidor web controlado, vas a hacer pública tu dirección IP, y sucederá lo mismo.

Figura 5: Ajustes de carga de imágenes en URLs en WhatsApp para Android

Como última recomendación, si quieres evitar problemas de privacidad extras, recuerda que en WhatsApp puedes quitar cosas como informar si estás online, la última vez que te conectaste, etcétera. Es decir, puedes poner un poco más de privacidad a su uso.

Saludos Malignos!

Cálico Electrónico T5x03: De DaddyChulos

Para la realización del segundo capítulo de la Temporada 5, titulado: "Cálico Electrónico contra la madre del topo", comenzamos un proceso de Crowdfunding para financiar parte de los gastos. Al poco tiempo ya se habían superado los 2.000 €, que era el dinero que solicitamos, así que Niko se puso manos a la obra para dar forma al capítulo. Ya está prácticamente acabado y en cuanto acabe el plazo de la campaña entregaremos todos los premios a los mecenas y lo publicaremos.

Figura 1: Crowdfunding para Capítulos 2 y 3 de la Temporada 5 de Cálico Electrónico

Esta vez, hemos podido conseguir los fondos suficientes como para sufragar el capítulo, por lo que habrá un nuevo capítulo de Cálico Electrónico para principios de Diciembre gracias a todos los que han colaborado en el mecenazgo. Gracias a vosotros el gordito seguirá dando guerra.

Figura 2: Temporada 5 Capítulo 3 "De DaddyChulos"

Pero como se habían superado los objetivos, hemos querido aprovechar para reutilizar los fondos de más en la creación del Capítulo 3 de la Temporada 5, al que se ha titulado "De DaddyChulos". En este capítulo participará como estrella invitada David Sainz, “El Negro” de la famosa serie de Internet que ha ganado tantos premios "MALVIVIENDO".

Figura 3: David Saiz "El Negro"

Para conseguir el objetivo final mínimo nos queda muy poco dinero - unos 1.500 € - y hemos ampliado los premios, con lo que hay nuevos dibujos dedicados para los mecenas que colaboren con 50 €, y nuevo espacio - Solo quedan 5 espacios - para que las empresas sponsors ocupen su sitio al inicio del capítulo y sean vistos por los millones de veces que se ve cada capítulo de Cálico Electrónico por un precio más que asequible.

Figura 4: Saca tu empresa como sponsor al principio del capítulo. Solo quedan 5 espacios

Si Cálico Electrónico consigue esa cantidad de dinero que falta, tendremos garantizadas, tiras de Deili Electrónico dos veces a la semana, y al menos dos capítulos más de la nueva Temporada 5 de Cálico Electrónico para que estas navidades pases por e-mail o WhatsApp los nuevos capítulos del gordito. Si no puedes colaborar o ya lo has hecho, nos ayudas con ayudarnos a difundir este mensaje. Nos quedan sólo 11 días...

Saludos Malignos!

Cómo ganar 100.000 € con el mundo del cibercrimen

El pasado domingo, el "chico-este-que-sabe-algo-de-seguridad-en-facebook", Javuto (@javutin), al que creo que deberían dar un merecido premio por el vídeo de presentación de la última LaCON 2013 - ya que superó cualquier otra cosa que hubiera visto antes en una conferencia - me envió este vídeo de cómo se puede ganar mucho dinero con el mundo del cibercrimen y el robo de dinero por medio de fraude online, el carding o el robo de credenciales.

Figura 1: Vídeo sobre cómo ganar 100.000 € con el cibercrimen

El vídeo dura unos 7 minutos, y muestra ejemplos de cómo consiguen muleros de forma rápida en la calle, cómo roban las tarjetas de crédito, como por medio de call-centers conseguir dar más veracidad al robo de dinero, etcétera... todo con una estética de película de ciber-criminal y con el objeto del deseo de un deportivo de cuidado.

Figura 2: Ofertas de empleo para cibercriminales

Tal y como lo pintan en ese vídeo, no es de extrañar que algunos quieran "probar suerte" en esa industria, que a día de hoy se ha convertido en un mercado tan competitivo que hasta se buscan los miembros del cibercrimen con ofertas de trabajo en periódicos y las bandas se atacan su malware unas a otras. Merece la pena el visionado.

Saludos Malingos!

Cuando hackean una base de datos te hackean a ti también

Muchas veces la gente que no trabaja en seguridad me pregunta porque esa obsesión mía de estar conectado todo el tiempo y alerta de lo que está pasando, actualizando el buzón de  correo electrónico cada poco tiempo y leyendo lista infinitas de noticias en RSS que vuelven a crecer cada semana con nuevos focos de información que ofrecen nuevos datos de interés.

La respuesta no es demasiado fácil de explicar a la gente que no trabaja en este area profesional, y a sus ojos acabamos pareciendo adictos a Internet, pero lo cierto es que tiene su explicación, ya que lo que sucede en Internet te puede afectar a ti también de forma directa, especialmente cuando hay un hackeo de un sitio y se publican bases de datos de usuarios y contraseñas.

El caso de las contraseñas de Adobe

Con la liberación de las contraseñas de la base de datos de usuarios de Abode, el mundo de la seguridad en la empresa está revuelto. Por supuesto, lo primero de todo ha sido comidilla que supone que una empresa como Adobe sufra una intrusión de esta índole, dejando claro que los algoritmos de almacenamiento de passwords no eran los más adecuados para garantizar una buena estrategia de Defensa en Profundidad que debería haber terminado con "Si acceden a los hashes que no las pueda crackear fácilmente".

Figura 1: Tira de XKCD sobre cómo usar las pistas de las passwords para hacer un juego de palabras cruzadas

Esto ha llevado al cachondeo en XKCD que decía que sería divertida una implementación de un juego de palabras cruzadas usando las pistas que los propios dueños de las credenciales han dejado junto a sus hashes, y ha terminado convirtiéndose en un juego real en Internet.

El análisis de los datos filtrados

Pero lo más importante no es la comidilla que pueda generarse alrededor de un determinado incidente de seguridad, sino lo que todos los equipos de seguridad de todas las empresas han tenido que hacer para contener el impacto de esta intrusión dentro de sus propios sistemas. Aquí es donde los equipos CERT de cada una de las organizaciones deben comenzar a trabajar, para saber cuánto les puede afectar este fallo de "otros".

Figura 2: Cuentas con dominios del IBEX 35 en la base de datos filtrada de Adobe

En Security By Default se alertaba de la cantidad de direcciones de correo corporativas utilizadas para la generación de cuentas de servicio en Adobe, lo que podría llevar, por una mala gestión de sus propias contraseñas, a que un usuario hubiera utilizado la misma password en Adobe que la que utiliza en su compañía.

Si el usuario de nuestra organización hubiera sido lo suficiente descuidado como para utilizar la misma contraseña en ese servicio de Internet para el que le han robado la password que en el sistema de la empresa, entonces tendríamos un problema. Por desgracia, la reutilización de passwords es un mal endémico demasiado difícil de erradicar, tratado también hace tiempo por xkcd.

Los datos de malware y botnets exfiltradas

Los equipos de seguridad de una empresa, cuentan con las políticas de contraseñas, que obligan a no repetir contraseñas, a cumplir grados de complejidad y a cambiarlas periódicamente, así, aunque un usuario repita una contraseña en un servicio perdido de Internet, las probabilidades de que sea la misma que la que se usa en la empresa son menores.

Figura 3: Datos de cuentas filtrados de una botnet con HCStealer

Esto mismo sucede cuando en algún almacén de un malware o una botnet de los amigos del Fraude Online aparecen datos de de cuentas de usuarios de cualquier servicio de Internet con direcciones de correo electrónico pertenecientes a dominios de una empresa. Solo hay que buscar un poco siguiendo las indicaciones que aparecen en el artículo de Enrique Rando para acabar dando con cuentas corporativas junto con la contraseña de algún servicio en Internet que ha acabado siendo robado por cualquier malware.

Imagen corporativa

Aunque se pueda mitigar el impacto de la re-utilización de contraseñas, sigue siendo malo para la compañía la fuga de nombres de direcciones de correo en servicios de Internet no es una buena cosa, por lo que es necesario contar con servicios de ciberseguridad que vigilen el mundo sin fin en que se ha convertido nuestro CPD.

Además de contratar esos servicios, una de las buenas prácticas es la de prohibir por política de uso la dirección de correo electrónico para darse de alta en servicios de Internet. En muchos servicios es posible conocer qué cuentas se han utilizado para registrar servicios por medio de pequeñas fugas de información en los procesos de alta de cuenta, de login o recuperación de contraseñas.

Esto hace que como medida de seguridad los servicios de ciberseguridad o las mismas empresas puedan monitorizar determinadas cuentas de correo electrónico para saber si están cumpliendo o no las políticas de seguridad corporativas.

Protección Personal

El que no se deban utilizar las cuentas de correo electrónico de la empresa para darse de alta en servicios de Internet de uso personal es algo que no deberían prohibir tan siquiera, ya que es de sentido común. Hay que tener en cuenta que una vez que la cuenta de correo ya no sea del empleado la empresa podrá recuperar todas los servicios asociados a ella.

Para uso en servicios al margen de la empresa, lo recomendable para una persona es utilizar una cuenta de correo electrónico de registro de servicios, pero que nunca sea la cuenta de correo que actúa como piedra de clave, para que nunca caiga esa cuenta cuando salgan los logins de cualquier base de datos de usuarios y contraseñas hackeada.

Tampoco deberían utilizarse cuentas de correo corporativas asociadas a personas concretas para darse de alta en servicios, sino que deberían utilizarse cuentas especiales de registro en servicios que además estuvieran inventariadas y controladas, ya que deben perdurar - o no - más allá que la vida profesional de un determinado empleado.

En definitiva, piénsate muy mucho qué identidad vas a dar de alta en un servicio en Internet antes de hacerlo, que si lo haces muy a la ligera puedes estar poniendo en riesgo a tu empresa o a ti mismo.

Saludos Malignos!

No necesitas subir el código fuente para que rule el Flash

En las auditorías de seguridad, cuando te topas con una web escrita en Adobe Flash, tienes que conseguir todos los ficheros .SWF. Al igual que haces con el código fuente de las páginas HTML servidas por el sitio web, tener un archivos .SWF significa que también tienes que el código fuente si realizas un proceso de decompilación para obtener su código fuente. Para ello se pueden usar múltiples herramientas, y hasta decompiladores .SWF o .NET online - también decompilan Applets Java -.

Esto está bien, pero si puedes conseguir el archivo .FLA original, mejor que mejor, solo por si hay comentarios o recursos que no aparecen durante el proceso de decompilación. Esto, en una web que tenga un proceso estricto de seguridad, no debería pasar nunca, y los ficheros .FLA no deberían estar nunca al alcance de todo el mundo.

Pero como os podéis imaginar, esto no siempre es así.

Hace tiempo, cuando publiqué el artículo que hablaba de analizar los ficheros .DS_Store subidos a los sitios web para descubrir otros ficheros escondidos en el mismo servidor, ya me pasó que encontré que en una carpeta estaban el fichero .SWF y el código fuente en fichero .FLA.

Figura 1: Al analizar el fichero .DS_Store aparecían principal.swf y principal.fla

Los ficheros .FLA no están protegidos en el servidor web por defecto, así que si lo encuentras, salvo que haya alguna regla añadida manualmente en el WAF - sería una buena recomendación añadirlo directamente a las reglas de fortificación de Mod_Security para evitar estas fugas - vas a poder disfrutar de toda la información.

Conocido esto, decidí probar el otro día que andaba con algo de tiempo, a buscar ficheros .SWF e intentar localizar los ficheros .FLA de los ficheros .SWF que me fuera escupiendo Google haciendo algo de hacking con buscadores, en plan "lotería random". Lo que esperaba es que no fueran muchos, y que cuando solicitará el fichero .FLA se obtuviera algún mensaje de error como este.

Figura 2: El fichero .fla no está en el servidor web

En algunos casos me topé con la grata sorpresa de que el servidor tenía el mod_negotiation activado, así que cuando pedía el fichero .FLA me proporcionaba la lista de ficheros con el .SWF de nuevo. Ya sabéis que si está activado este módulo se pueden listar casi todos los ficheros del servidor web.

Figura 3: Buscando un .fla acabé topando con un mod_negotiation activado

Pero lo más curioso fue que sobre más o menos unos 50 sitios que probé, acabé con 8 ficheros de código fuente .FLA. Como podéis suponer, primero empecé probando en sitios al azar, y luego fui dirigiendo el tiro a dominios que deberían tener una mayor seguridad - como cuando se prueban los análisis de metadatos con FOCA en sitios como la Missile Defense Agency, para probar años después que siguen teniendo fugas que pueden provocar ataques "desde el pasado" -. Y no hizo falta buscar mucho, enseguida apareció algún fichero .FLA en sitios .mil.

Figura 4: Un fichero .FLA en un dominio .mil

No había nada especial en ese código fuente. Tan solo el código para reproducir unos vídeos. Nada preocupante desde el punto de vista de seguridad, pero me extrañó que no tuvieran una medida global de protección contra este tipo de fugas de datos, con lo serios que se han puesto con esto.

En cualquier caso, nosotros con Faast buscamos y detectamos esto, y si tienes que hacer una auditoría, antes de buscar hacer probar las 20 técnicas para listar ficheros de un servidor web, prueba a pedir el código fuente, no vaya a ser que una vez más, los árboles no te dejen ver el bosque.

Saludos Malignos!

Crear hackers "from the scratch" o programando tortugas

Yo comencé a programar con doce años de edad, con el lenguaje BASIC. Como ya os he contado fue para mi toda una aventura de switches, acumuladores y contadores que me cambió la vida para siempre. En aquel entonces la gente no se preocupaba mucho de que los niños aprendieran a programar, pero lo cierto es que a mi me vino genial para ordenarme la cabeza. Así como el inglés lo aprendí de bastante mayor, y me tengo que concentrar mucho para poder sacar con cierta lógica las palabras, pensar en resolver problemas programando me resulta natural, porque lo aprendí desde niño y luego lo pude ir depurando en la Universidad.

Figura 1: Un ejemplo de código en BASIC

Sin saber que al final las cosas en la vida acaban conectándose, en mis años ya de profesional, acabé conociendo un día a Radia Perlman, con la que pasé un buen rato charlando y acabamos malignizados para siempre en esta foto que guardo con mucho cariño.

Figura 2: Con la Dra. Radia Perlman

Radia, además de ser conocida como la Madre de Internet por ser la creadora del Spanning-Tree Protocol, también fue la creadora de TORTIS (Toddler's Own Recursive Turtle Interpreter System), un sistema que permitía a niños preescolares aprender a programar mediante una serie de botones que dirigían los movimientos de una tortuga.

Figura 3: Tarjetas de programación para TORTIS

En ese trabajo inicial, Radia Perlman utilizaba en TORTIS un "artilugio" para que los niños programaran con una máquina en la que iban poniendo las tarjetas de lo que querían que hiciera la tortuga. Eso le permitía que el preescolar aprendiera a mandar a la tortuga hacer movimientos iterativos, alternativos o repetitivos. Bases para aprender los conceptos de la programación.

Figura 4: Niños programando con TORTIS

Cuando conocí este trabajo de Radia Perlman, yo no sabía que el LOGO, el lenguaje de programación por el que se aprende a hacer dibujos por medio de una tortuga, procedía de TORTIS. Yo ya había aprendido a programar en BASIC cuando LOGO llegó a mi vida, por lo que me parecía un poco raro todo él en sí, pero lo cierto es que lo usé e hice los trabajos de dibujo que me pidieron.

LOGO se basaba en unos comandos bastante sencillos, que permiten desplazar a la tortuga siguiendo diferentes trazadas y pintar o no pintar. Eso deja en manos de los developers preescolares la capacidad de pintar todo lo que quieran. En este vídeo se puede ver cómo los programas hechos en el intérprete, pueden ser llevados directamente al papel con la tortuga amarilla de LOGO.

Figura 5: La tortuga amarilla de LOGO dibujando lo programado

El LOGO volvió otra vez a mi vida cuando en un evento sobre emprendimiento me encontré con Pilar García de la empresa Exalta, como moderadora. A parte de intercambiar impresiones sobre lo que nos atenía, compartimos otras cosas de experiencias personales, y la suya tenía que ver con que cuando montaron su empresa, se dedicaron a hacer compiladores de LOGO. De hecho, el LOGO cuenta con un juego de instrucciones en Español, para poder facilitar el aprendizaje por igual a las jóvenes mentes de todo el mundo.

Figura 6: Instrucciones de LOGO en inglés y español sacadas de Wikipedia

La programación de la tortuga se parece mucho a la programación de robots, donde los jóvenes que ya dispongan de algunas habilidades en la programación pueden ver una evolución de hacer programas que permiten pintar a programas que permiten un universo de posibilidades aún mayor con un robot.

Hoy en día, para enseñar a programar a los jóvenes que ya están en el colegio, existen lenguajes de programación que han sabido sacar provecho de las ventajas multimedia que ofrecen las nuevas tecnologías. Quizá el más popular es Scratch, del MIT, un lenguaje que permite definir scripts de acciones - como moverse, repetir acciones, etcétera - pero utilizando elementos visuales muy atractivos para los más jóvenes, pero con una gran potencia.

Figura 7: Un Tetris programado en Scratch

No es el único lenguaje que sigue esos principios, si realizáis alguna búsqueda por Internet, encontraréis entornos como ToonTalk - basado en los mismos principios que Scratch - o el lenguaje de programación de juegos que Microsoft distribuye dentro de sus programas educativos, el Kodu Game Lab.

Figura 8: Entorno de programación en ToonTalk

Con Kodu Game Lab se pueden hacer juegos fantásticos mediante elementos de programación visual que pueden ser muy sencillos, o que pueden ser muy complejos dependiendo del nivel del creador de los programas. Ya os dejé algún vídeo de juegos hechos con Kodu, pero aquí os dejo un pequeño tutorial que muestra cómo es la forma en la que se programa en este sistema

Figura 9: Tutorial de programación en Kodu Game Studio

En el objetivo de ayudar con el programa Talentum a mejorar el entorno tecnológico del país, se ha incorporado una nueva iniciativa de educación tecnológica para niños y niñas en las propias tiendas de Movistar. Allí los tutores, también jóvenes procedentes del programa Talentum Startups, están enseñando a programar en Scratch y a programar Robots en cursos gratuitos que se dan a los niños y niñas que se apuntan. Todo a través de lo que han denominado Talentum Schools.

No obstante, para enseñar a programar en Scratch a los más jóvenes, para programar en Kodu Game Labs o incluso en LOGO, no necesitas mucho más que un sistema informático de gama media en casa.... y pasar tiempo con ellos.

Si puedes apuntar a los niños a cursos de Talentum Schools estaría genial, pero si eres docente en algún centro en el que hay niños entre 8 y 13 años, tal vez sea una buena opción proponer actividades de programación similares - ya sea como prácticas de asignaturas o como actividades extraescolares o culturales -.

Figura 10: Cursos de Talentum Scools para programar en Scratch

Lo mismo para ti, si eres padre, padrino, hermano o tío y sabes programar. Aprender estos lenguajes no te costará mucho, y podrás no solo pasar tiempo con tu gente, sino que además estarás ayudándole un montón para el futuro. Si no tienes tiempo, no eres docente, o no sabes programar, y te has quedado sin plazas de Talentum Schools esto es fácil. Busca a cualquier estudiante de informática que le guste la programación y la ciencia, y contrátale clases particulares para que enseñe a tu hijo a programar en Scratch o Kodu Game Labs o en el mismo LOGO. Seguro que lo hace genial.

Y sobre todo, que no te preocupe la edad, que de 8 años en adelante es un buen momento para que los niños aprendan a hacer cosas con las computadoras y descubran que pueden crear lo que ellos quieran si saben cómo programarlo. Conviértelo en un hacker ...from the scratch.

Saludos Malignos!