New features for Latch website and new plugins

viernes, 30 de mayo de 2014

Latch website has been updated with some interesting news that make Latch reach more people and in many other ways. These are the most important::


Aside, new plugins for Ubuntu and  Open-xchange are available and PowerShell SDK. The OpenSSH plugin has been updated and improved.

All the information, here.

Novedades en la web de Latch y nuevos plugins

La web de Latch se ha actualizado con algunas novedades interesantes, que facilitan que Latch llegue a más gente, y de más formas. Las más destacadas son:

  • La web ya está disponible en portugués. Además, se da la posibilidad de seleccionar el idioma de la web desde el menú superior.
  • Nueva página con información sobre los modelos de suscripción de Latch.
  • Se ha actualizado el manual de usuario de Latch y también está disponible en inglés.
  • Se ha actualización de la sección de "Ayuda para usar Latch" con las últimas funcionalidades de la app.

Por otro lado, ya están disponibles nuevos plugins de Ubuntu y Open-xchange y el SDK de PowerShell. Se ha mejorado y actualizado el plugin de OpenSSH.

Toda la información, aquí.

Comparación de proyectos con Faast

miércoles, 28 de mayo de 2014

Una funcionalidad de Faast que quizá no sea muy conocida, pero que consideramos de gran utilidad, es la posibilidad de comparar los resultados de dos escaneos lanzados sobre el mismo dominio.

Faast nace con el propósito de ser el primer servicio de pen-testing persistente, revolucionando el concepto de auditoría de seguridad automatizada. En Internet, se debe estar siempre alerta y actualizado, así que la idea sobre la que se fundamenta Faast y, en definitiva su característica estrella, es el pen-testing by design, o pen-testing 24x7. En otras palabras, realizar un escaneo continuo en busca de nuevas vulnerabilidades. Con una revisión día a día que informe sobre el estado de la infraestructura de una compañía, Faast permite reducir considerablemente la desventaja con respecto a los atacantes. Se pretende, de esta forma, estar siempre en guardia.

Faast presenta los resultados al cliente de forma intuitiva y accesible, mostrando un informe de cada escaneo que incluye todas las vulnerabilidades encontradas gracias a la (cada vez más amplia) batería de plugins que se actualiza automáticamente cada vez que se desarrolla uno nuevo. Además, cada vulnerabilidad viene acompañada de su descripción, su calificación de criticidad y los recursos a los que afecta.


Selector de proyectos que van a ser comparados en Faast

Buscando mejorar y aprovechar el concepto de continuidad, comprobamos que era necesario proporcionar a nuestros clientes una manera de observar la evolución temporal de la seguridad en sus sistemas. Esto condujo al diseño y posterior desarrollo de una nueva funcionalidad: la comparativa de proyectos. Permite, dado un dominio base (dominio donde comienza un escaneo, a partir del que se van descubriendo activos), comparar los resultados de dos proyectos lanzados sobre él.

El proceso para comparar dos escaneos es muy sencillo. Tras acceder a la vista Comparación de escaneos se deben seguir los pasos que se indican a continuación:

Opciones disponibles en la vista de comparación

  • En primer lugar, en el desplegable superior se selecciona el dominio base.
  • En los desplegables primer proyecto y segundo proyecto se han de escoger dos proyectos que se hayan lanzado sobre dicho dominio. Obviamente el segundo proyecto debe de ser posterior al primero.
  • Por último, se debe escoger el filtro de resultados que queremos aplicar.

Por un lado, se pueden ver las vulnerabilidades resueltas. Es posible que se hayan tomado medidas para subsanar ciertas vulnerabilidades ya descubiertas en un escaneo. En escaneos posteriores ya no estarán presentes y esta opción permite visualizar estas vulnerabilidades que se han arreglado.

Por otra parte, es posible visualizar las vulnerabilidades nuevas. Existen muchos factores que pueden llevar a que un problema que se creía resuelto, vuelva a aparecer en forma de vulnerabilidad: No actualizar el software, un error de configuración o la aparición de malware con nuevas características pueden ser las causas. Con esta funcionalidad se puede descubrir al instante qué vulnerabilidades van apareciendo en un determinado sistema, y delimitar de este modo las áreas de impacto.

La visualización de resultados, que sigue la línea de toda la interfaz, muestra los resultados tabulados, incluyendo toda la información sobre cada vulnerabilidad y los recursos en los que se ha encontrado.

Resultados producidos por la comparación de escaneos

Por supuesto, estos datos no solo están disponibles en la interfaz web. Al igual que ocurre con todos los resultados que obtiene Faast, la API externa también permite la exportación de la comparativa de proyectos en formato xml o json para su posterior procesado con herramientas propias del cliente. Disponer de esta información en diferentes formatos y de forma continua, no solo es útil para los administradores, sino que constituye una buena base para evaluar el nivel de adecuación de un sistema de seguridad, su evolución continua en el tiempo y como fórmula para establecer unas políticas de seguridad eficaces.

Cristóbal Bordiú
cristobal.bordiu@11paths.com

Malware español en Google Play, nuevas técnicas: Análisis de Funtasy

lunes, 26 de mayo de 2014

Ya se ha hablado en alguna ocasión del tipo de malware alojado en Google Play que suscribe a la víctima automáticamente a servicios de SMS premium. Pero sigue ocurriendo más y mejor. Hemos detectado cómo las estafas han evolucionado y el malware utiliza nuevas técnicas interesantes para ser más efectivo.

Ya sabemos de estafadores que intentan hacer pagar 5 euros por un enlace a la descarga oficial de Flash para Android. También, de la estafa de la suscripción automática a los mensajes SMS premium. Se basa en eludir el hecho de que los mensajes premium necesitan confirmación por parte del usuario. Habitualmente, al enviar el ALTA al número correspondiente, el servicio debe devolver un PIN de verificación que el usuario devuelve por SMS. Esto demuestra que quiere realmente suscribirse al servicio y es consciente. El malware de este tipo, recibe ese SMS de confirmación, extrae automáticamente la cadena exacta del PIN de confirmación del SMS, y envía la suscripción a través de un sistema de alta web. Todo de forma transparente para el usuario.

Trozo de código que toma el PIN de confirmación de un SMS


Nuevas muestras

Las nuevas muestras de las que hablamos ahora han aparecido durante el mes de abril y en algunos casos se han mantenido hasta un mes en Google Play. Estas variantes no han sido cazadas por los motores antivirus hasta mediados de mayo, habitualmente con el nombre Funtasy. Durante este tiempo, el atacante ha adoptado varias personalidades diferentes pero ha  mantenido la temática de los programas falsos. Las apps con el código malicioso o bien son en realidad animaciones inútiles o ventanas de navegador a páginas web que, en formato especial para la pantalla del móvil o tableta, muestran texto. En segundo plano, su lógica realiza la suscripción automática.

Aunque en esta investigación se habla de algunas apps y developers, en realidad el atacante ha operado durante al menos dos meses bajo diferentes developers: AppMax, bestapps2014, Milapps101, Milapps102 y fun apps con muchas aplicaciones diferentes.


Diferentes apps y perfiles del atacante

¿Por qué Funtasy?

Es el nombre de la empresa y el dominio con el que comunica el troyano para enviar la suscripción sin consentimiento explícito. Ahí se observa que la empresa FUNTASY MOBILE S.L, fundada en febrero y con sede en el centro de Málaga bajo "Oscar Sánchez" como administrador único (también lo es de otras tantas compañías, algunas desaparecidas) es la responsable.

Ampliando horizontes y mejorando

En otras versiones de este tipo de programas, la estafa solo funcionaba con teléfonos Vodafone. Ahora se amplía a muchos otros operadores. Incluso australianos (aunque detecta que pertenezca a ese país, más tarde no tiene ningún efecto sobre un teléfono de allí). El troyano busca el código de operador, si coincide con el español o australiano, activa la estafa. Luego solo puede suscribirse a operadores españoles.

Otra mejora introducida es que oculta las cadenas de texto incrustadas en el código. Están ofuscadas en base64, intentando pasar desapercibidas. Los números de teléfono, términos de uso, etc., todo está codificado. Además, dependiendo de la muestra analizada, el código es de muy mala calidad. Hay zonas a las que nunca se llega, y todo parece estar en modo "debug" como pruebas realizadas por el programador.

Constantes del programa

Estrategias interesantes

Las apps no pueden acceder por política al número de la tarjeta SIM directamente, así que usan programas como whatsapp para averiguarlo. También se usa Telegram. Algo novedoso en este caso es que, si la víctima no dispone de esos programas, el troyano sigue intentándolo. Llama a getLine1Number(), busca en los logs de llamadas, luego en las apps mencionadas... y si aun así no lo consigue, muestra un diálogo amenazante para que sea la víctima la que introduzca su propio número de teléfono. El diálogo enseña la foto de perfil del usuario del teléfono (si no se tiene, muestra una imagen típica de Whatsapp) con el siguiente texto:

Verifica tu número de teléfono: Se ha intentado iniciar sesión desde otro terminal, por seguridad debes introducir tu número de teléfono asociado

Además lo hace en otros idiomas según la configuración del teléfono. Otra función interesante con la que el programador estaba experimentando, es supeditar la estafa a la presencia o no de ciertas apps legítimas relacionadas con SMS como Go Pro SMS, Handcent SMS, Secure SMS... Si la víctima usa estos programas (que también interceptan los SMS entrantes) la estrategia debía ser diferente. Pero la función está claramente mal programada. Aunque parece que en otras versiones, funciona correctamente.

Para evitar ser descubierto a través de los mensajes no solicitados, el malware realiza otro truco muy ingenioso. Intercepta los mensajes SMS antes de ser recibidos por el usuario, silencia el teléfono, y les cambia la fecha a 15 días antes. Así se hunde en la bandeja de entrada de SMS y la víctima tardará aún más en saber que le están llegando mensajes premium.

Código que modifica la fecha de los mensajes entrantes, retrasándola 15 días. También silencia la entrada de estos SMS

Todas las gestiones se realizan a través de esta web, evitando el envío directo a servicios premiun


Errores de bulto

Sin embargo también ha cometido errores. El autor de la aplicación ha usado su nombre real no solo para registrar los dominios de las URL, sino que también se deduce su nombre del correo para el registro de developer en Google Play. Incluso ha comentado positivamente sus propias apps con su cuenta real. También, en ocasiones el inglés utilizado para darle internacionalidad deja mucho que desear.

Comentaba con su nombre real sus apps con valoración positiva

En vez de "brean" debería decir "brand"

En la descripción de las apps, en ningún momento se advierte explícitamente que los programas no son más que animaciones o bromas y que no funcionan como se podría esperar. Tampoco que con su utilización se consiente la suscripción a servicios de este tipo. En este sentido, el programa muestra claramente un mensaje nada más ser arrancado:

Servicio de suscripción para usuarios Movistar, Vodafone, Orange, Yoigo, R y Simyo para mayores de edad o menores con capacidad legal para contratar, prestados por (FUNTASY MOBILE S.L., operador titular ARGATEL SOLUTIONS SL, n. atención al cliente 902 303 803 ó inf@argatel.com, apartado de correos 167, 17001 Girona. Coste por SMS recibido 1.46 euros/sms (IVA incluido) más el coste de navegación WAP, que dependerá del operador que tenga contratado. Máximo 10 sms/semana. El límite máximo de facturación del servicio puede variar en función de tu operador (18 a 30 euros/mes). Baja automática para cancelar el servicio: envía BAJA al 797977.

Pero no espera a aceptar estos los términos de uso (en realidad ya está funcionando cuando los enseña), los muestra durante muy poco tiempo y con letra pequeña.

Sergio de los Santos
ssantos@11paths.com

Ocho siglas relacionadas con las vulnerabilidades (IV): CWSS

viernes, 23 de mayo de 2014

Como el resto de métricas que estamos observando en esta serie, CWSS (Common Weakness Scoring System) también es un sistema de valoración que se encarga de parametrizar la criticidad de las debilidades de software. También fue creado por el MITRE como parte del proyecto CWE.

CWSS ofrece un mecanismo estandarizado que permite evaluar (de manera objetiva y a nivel de desarrollo) las posibles debilidades típicas que puedan estar presentes en el software por su naturaleza y pudieran convertirse en una vulnerabilidad con posibilidades de ser explotada. Por ejemplo, si una aplicación web que almacene información en una base de datos SQL no gestionara correctamente las entradas recibidas por la aplicación (esta sería la debilidad) sería posible aprovechar algún tipo de inyección SQL (vulnerabilidad) para obtener información sensible. Al tratarse de una vulnerabilidad "típica" en este tipo de sistemas, conviene parametrizarla para poder darle una prioridad a su estudio y en resumen, una mejor gestión.

Basándose en este sistema de valoración se pretende ayudar a la toma de decisiones relacionadas con las prioridades de estas debilidades. En la práctica, esto puede ser utilizado para alertar a los consumidores y empresas creadoras de software acerca de los fallos más típicos y críticos que existen en la actualidad, permitiendo que sean capaces de tener una referencia en cuanto a los requerimientos que debe cumplir el software que contraten o desarrollen según sea el caso. También, priorizar el desarrollo interno en un grupo de programadores.

Una diferencia con respecto a las iniciativas ya comentadas en entradas anteriores, es que no existe una web, servicio o aplicación conocida que en realidad utilice este sistema para valorar las debilidades públicamente, tal y como se hace comúnmente con, por ejemplo, el CVSS.

En sus inicios, este sistema se solía promover a través de publicaciones (como por ejemplo los documentos desarrollados entre el MITRE y SANS Institute del tipo Top 25 Most Dangerous Software Errors), sin embargo, en la actualidad es difícil encontrar información reciente asociada a debilidades de software. Puede deberse a que hoy por hoy la lista CWE (Common Weakness Enumeration) se actualiza muy poco. Además, las empresas de desarrollo de software protegen el código de sus aplicaciones y su estudio, valoración y resolución se suele gestionar de manera privada sin compartir la información.

Objetivos y funciones

Está patrocinado por el Software Assurance program de la oficina de ciberseguridad y comunicaciones del U.S. Department of Homeland Security (DHS). En la web de este proyecto, definen una serie funciones que pueden cumplir el CWSS, entre las que destacan:
  • Proporcionar un estándar que puede ser utilizado para priorizar errores descubiertos en el software que afecten a la seguridad de estos, y utilizados por desarrolladores para priorizar las soluciones que deben implementarse según la criticidad de estos fallos.
  • Proporcionar una medida cuantitativa de las debilidades no solucionadas que pueden encontrarse en el software.
  • Puede ser utilizado por los consumidores para identificar las debilidades más importantes que afectan a sus dominios de negocio, e informar acerca de las actividades de protección necesarios para garantizar la calidad del software que estos necesitan. 
Al igual que el CVSS, este sistema de valoración agrupa en tres grupos de métricas los distintos factores que estudia relacionados a las debilidades del software. En este caso son 18 factores los que se encargan de definir el valor de estas métricas.

Base Finding


Se encarga de estudiar el riesgo inherente a la debilidad, la fiabilidad del descubrimiento y fortaleza de los controles.

Como puede observarse en la imagen anterior, los factores en esta métrica van relacionados directamente con las características de la debilidad encontrada. Entre estas características se encuentran:
  • Technical Impact: Este es el posible impacto que pueda generar la debilidad en caso de que pueda ser aprovechada para explotar una vulnerabilidad. Al igual que en el CVSS estas se evalúan en base a cómo puede verse afectado el software en cuanto a confidencialidad, integridad y la disponibilidad se refiere.
  • Acquired Privilege: Este se refiere al tipo de privilegios que puede obtener un atacante que logre explotar la debilidad.
  • Acquired Privilege Layer: Se encarga de definir el entorno al que pudiera tener acceso un atacante en caso explotar la debilidad y de obtener los privilegios mencionados en el factor anterior.
  • Internal Control Effectiveness: Hace referencia a los posibles mecanismos de protección o mitigación implementados de forma explícita en el código para evitar que sea vulnerado el software a través de esta debilidad. Con esta característica se busca medir la efectividad que tienen estos mecanismos de controlar la debilidad para que un atacante no pueda explotarla.
  • Finding Confidence: Este determina el nivel de certidumbre que se tiene acerca de que lo reportado es una debilidad explotable, y si de verdad el atacante puede aprovecharla para explotar una vulnerabilidad. 

Attack Surface 

Como puede observarse en la imagen anterior, los factores de esta métrica guardan relación con las barreras que un atacante necesite atravesar para poder aprovechar el fallo y explotar una vulnerabilidad. Entre estas características se encuentran:
  • Required Privilege: Identifica el tipo de privilegio necesario que se debe tener para poder acceder a la funcionalidad que contiene la debilidad (usuario regular, invitado, ninguno, administrador, privilegios especiales, etc.).
  • Required Privilege Layer: Detalla la capa de operaciones (sistema, aplicación, red, etc.) que se debe acceder en caso de que la debilidad pueda ser explotada.
  • Access Vector (AV): Reseña el canal (Internet, Intranet, acceso local, etc.) a través del que se puede alcanzar la debilidad.
  • Authentication Strength: Este mide la fortaleza (alta, moderada, baja, ninguna, etc.) de la rutina de autenticación que protege la funcionalidad que contiene la debilidad.
  • Authentication Instances: Establece el número de autenticaciones que deben hacerse antes de poder acceder a la debilidad.
  • Level of Interaction: Determina el nivel de interacciones necesarias por parte de la víctima para que un ataque que se aproveche de la debilidad pueda tener lugar.
  • Deployment Scope: Identifica si la debilidad está presente en todas las versiones e instancias de despliegue del software, o si solo afecta a un subconjunto de plataformas o configuraciones específicas.

Environmental 

Contiene todos los factores que pueden ser específicos a un contexto operacional concreto como podría ser el impacto en el negocio, la probabilidad de explotación o la existencia de controles externos.
  • Business Impact: Describe el impacto potencial que puede sufrir el servicio si la debilidad fuera explotada.
  • Likelihood of Discovery: Establece la probabilidad (alta, media, baja, etc.) de que un atacante descubra la debilidad.
  • Likelihood of Exploit: Define la probabilidad de que un atacante con los privilegios y/o autenticación necesarios sea capaz d explotar la debilidad una vez la haya encontrado.
  • External Control Effectiveness: Hace referencia a la capacidad que tienen los controles o medidas de mitigación (externos a la aplicación) que eviten que una debilidad pueda ser aprovechada.
  • Remediation Effort: Es la cantidad de esfuerzo necesario para remediar la debilidad de manera que esta ya no comprometa la seguridad del software.
  • Prevalence: Identifica la frecuencia con que la debilidad se suele encontrar en el software en general. 

Aunque esta métrica no sea tan reconocida y utilizada como otras mencionadas, sí que son muy útiles entre grupos de desarrollo para la organización y priorización de tareas a lo largo del ciclo de vida de desarrollo del software.

En siguientes entradas hablaremos de otras dos siglas relacionadas con el ámbito de las debilidades y vulnerabilidades: CVRF y CWRAF.

* Ocho siglas relacionadas con las vulnerabilidades (I): CVE
Ocho siglas relacionadas con las vulnerabilidades (II): CWE y CAPEC
Ocho siglas relacionadas con las vulnerabilidades (III): CVSS

Umberto Schiavo
umberto.schiavo@11paths.com

Descubriendo los activos de una organización (I)

miércoles, 21 de mayo de 2014

El pentesting persistente que realiza Faast tiene como misión proporcionar un informe de status continuo de seguridad global de la organización que lo ejecuta, en contraposición a una instantánea en un momento concreto. El objetivo es monitorizar constantemente los posibles cambios en algún punto de la infraestructura de la compañía, errores humanos por parte del personal, fallos de configuración de un administrador, etcétera. Acciones del día a día que pueden llegar a mermar la seguridad global de la organización. En este artículo se explicará cómo han ido evolucionando las funcionalidades y los objetivos desde el nacimiento de la herramienta FOCA.

Durante el proceso de test de intrusión las posibilidades de éxito se incrementan si la fase de descubrimiento proporciona un gran número de elementos que auditar. Para ello, es importante disponer de una gran variedad de técnicas, desde las clásicas hasta las más avanzadas o modernas (que pueden depender y adaptarse a la tecnología concreta usada por la infraestructura estudiada)  que ayuden a conocer el entorno de la organización y su perímetro.

Todo elemento que se descubre debe ser analizado y se debe plantear su paso por un flujo de tipo DAE. El flujo de tipo DAE (Descubrimiento, Análisis y Explotación) es común a todo tipo de auditorías.

Esquema DAE

Actualmente la auditoria a través de los portales web es clave para encontrar vulnerabilidades que permitan obtener algún recurso de la empresa (que contenga información sensible o permita dañar su imagen), pero el análisis debe expandirse a máquinas que sirvan otro tipo de servicios. Por eso Faast realiza múltiples técnicas de descubrimiento que le permite recopilar la mayor cantidad de elementos para auditar. Algunas de estas técnicas han sido heredadas de FOCA, otras por el contrario son totalmente nuevas y proporcionan más versatilidad a la herramienta.

El primer objetivo es obtener una visión global de los servicios de red, dominios y direcciones IP accesibles desde Internet y que pertenezcan a la organización. Esto puede ser logrado a través de varias técnicas que se complementan y retroalimentan.

Búsqueda e identificación de servicios

La búsqueda de elementos y servicios (tanto web como de otro tipo) se realiza con la ayuda de diferentes motores de búsqueda (no solo buscadores web, sino también de tipo Shodan), escaneos a direcciones IP que van siendo descubiertas "al vuelo" en esta fase aprovechando técnicas de descubrimiento de puertos, identificación de productos, servicios y versiones.

La identificación de servicios es un punto importante, ya que permite al analista asociarlos a vulnerabilidades y poder crear o buscar ciertos exploits que puedan aprovecharse de versiones de software no actualizadas. Por ello resulta tan útil disponer de un plugin que compruebe qué CVEs existen para las versiones de software encontradas. Esto es algo que desde hace tiempo se demandaba como funcionalidad en FOCA pero que con Faast se ha completado. Una vez se obtiene un primer nivel básico de estructura de la organización sobre el dominio que se ha proporcionado, el servicio Faast amplía las acciones de FOCA con plugins que aportan nuevas opciones de descubrimiento. Técnicas clásicas como whois o recopilación de información a través de ficheros sitemap.xml o robots.txt (que no son indexadas en otros sitios) ayudan a completar el modelado a analizar y el inventario de activos.

Otra técnica fundamental es el crawling dado que es una de las primeras que se deben contemplar al realizar una auditoría en las aplicaciones web, leyendo y procesando el código fuente de los sitios web públicos con el objetivo de incorporar al análisis todos los enlaces o links que se van encontrando. Esta técnica se complementa para construir todo un mapa del sitio web. Aunque no todas las direcciones URL pueden quedar capturadas porque pueden existir rutas no enlazadas en el sitio web, en este punto entra en juego una conocida técnica basada en la realización de ataques por diccionario a directorios y archivos. El servicio FaasT incorpora componentes que evolucionan las técnicas utilizadas por FOCA con resultados muy positivos.

Los servidores DNS 

Los servidores DNS son elementos que pueden proporcionar mucha información sobre el entorno y ayudan a perfilar y ampliar el mapa de datos. El uso de ataques por diccionario sobre el DNS permite completar ciertos dominios que no han podido ser localizados a través de las otras vías. Consiste en lanzar un ataque de diccionario contra el servidor y consultar así sobre dominios conocidos que se concatenan con el dominio de la organización. Aunque existen más métodos. La evaluación de registros como SPF, DOMAINKEY, DKIM y DNSSec ayuda a la hora de evaluar cierta configuración de seguridad, por lo que es otro punto que la herramienta valora. No hay que olvidar los registros que, como FOCA hacía, ayudan a detectar servicios no tan comunes como son VoIP, WINS, LDAP, etcétera.

Gracias a DNS Caché Snooping se pueden descubrir sitios por los que empleados de la organización navegan y puede ayudar en otro tipo de pruebas. Aunque se trate de vulnerabilidades menores, toda información puede aportar conocimiento en un proceso de pentest, como es el caso del ataque Evilgrade. Otras más antiguas, como las transferencias de zona, siguen vigentes en el ámbito de Internet y ayudan a seguir completando el mapa de activos de una organización en Internet.

El primer objetivo, denominado internamente "visión global", permite conocer qué servicios de red están disponibles en Internet, qué direcciones IP pertenecientes a la organización o con las que se relaciona de algún modo y un árbol de dominios potencialmente creciente con la ejecución de cada plugin de descubrimiento.

Una vez completada la primera fase del descubrimiento se debe profundizar en lo particular evaluando cada dominio, dirección IP, servicio de red... en definitiva, cada tecnología. Esta evaluación permitirá completar el mapa de activos con elementos que no han podido ser detectados gracias a las vías anteriores y conocer las primeras fugas de información y los primeros errores de configuración.

* Descubriendo los activos de una organización (II)

Óscar Sánchez
oscar.sanchez@11paths.com

Perfect Forward Secrecy: ¿Existe el secreto perfecto y permanente?

lunes, 19 de mayo de 2014

El atacante se dedicaba a "esnifar" conversaciones en redes internas, a través de cualquier técnica que le permitiera obtener el tráfico de sus víctimas. Para el tráfico cifrado, no sustituía certificados ni usaba sslstrip o cualquier otro método que pudiera poner en guardia al espiado. Simplemente atrapaba y almacenaba el tráfico cifrado por SSL. "Algún día esto podría serme útil", pensó. Hasta que llegó el 7 de abril de 2014. Entonces desempolvó varios gigabytes de información y sonrió. ¿Tenía motivos?

Ese día se dio a conocer Heartbleed y se demostró que era posible obtener la clave privada TLS/SSL de los servidores. Si se daba prisa, podría obtener las claves de los lugares vulnerables más populares, y con ella, descifrar todo el tráfico esnifado días o años atrás. Solo tendría que arrancar Wireshark, indicar en la configuración la clave privada robada gracias a Heartbleed, y cargar el tráfico cifrado que obtuvo en su día... ¿O no?

No tan rápido. Las bases del cifrado

RSA es un algoritmo de firma digital, creación de claves... y también de criptografía asimétrica. Diffie-Hellman es solo un algoritmo de intercambio de claves secretas en un entorno en el que un atacante podría tener acceso al canal de comunicación. Pero con la criptografía asimétrica (RSA), en realidad, también es posible intercambiar información por un canal inseguro: basta calcular una clave aleatoria, cifrarla con la clave pública del receptor y este la descifraría con su clave privada. Así intercambian y comparten clave y con ella cifrarían de forma simétrica la conversación.

Con estas dos filosofías "presentes", SSL/TLS puede ser implementado de muchas formas, y todo depende de la suite de cifrado que utilice el servidor. Veamos: En una conversación SSL/TLS "típica con RSA", el servidor se autentica a sí mismo (muestra su certificado y el cliente lo valida) y luego ambos acuerdan cifrar la conversación. En resumen (aunque hay una master y una premaster) los servidores cifran una contraseña y se la intercambian. Si un atacante robase la clave privada del servidor, podría descifrar todas las conversaciones pasadas, porque podría obtener la premaster key, deducir de ella la master y tener el tráfico en claro.

En este esquema el fallo es que se usa la clave privada del servidor (que es permanente hasta que caduque el certificado) tanto para autenticarse como para cifrar. Por tanto, en este entorno donde se utiliza RSA y cifrado asimétrico, descifrar conversaciones retroactivamente sería posible una vez obtenida la clave privada (gracias a Heartbleed, por ejemplo). La ciphersuite usada en el servidor sería, por ejemplo RSA_WITH_AES_256_CBC_SHA y sus combinaciones (RSA_WITH_RC4, RSA_WITH_AES_128....)

Pero no todos los servidores funcionan así, todo depende de la suite de cifrado. La solución para evitar ese descifrado retroactivo es usar una clave permanente (en el certificado) para autenticar, y otras efímeras (calculada al vuelo) para cifrar. ¿Cómo?

Separar autenticación y cifrado

RSA se puede seguir usando para autenticar, pero el intercambio de claves para el cifrado puede hacerse con Diffie Hellman (DH), que para eso es un algoritmo de intercambio de claves. Como matemáticamente sus valores son aleatorios y se usan una sola vez, se llaman efímeros (DHE). A su vez hay dos formas de implementar Diffie Hellman.
Esquema de funcionamiento de Diffie-Hellman.
Fuente: Wikipedia.

  • Con número discretos. Con un rendimiento peor.
  • Con curvas elípticas (ECDHE). Se consigue una seguridad muy buena con números más pequeños, y por tanto el rendimiento no decae tanto. Lo malo es que no todos los navegadores lo soportan. Una idea de lo reciente que es, es que openSSL lo implementó en su versión 1.0.0. 
A este uso de intercambio de claves efímeras (normalmente con DH en el contexto de SSL), se llama Perfect Forward Secrecy (PFS). Las cipher suites usadas en los servidores, serían por ejemplo DHE_RSA_WITH_DES_CBC_SHA y sus múltiples variantes.

Nada impide usar claves RSA "efímeras" para intercambiar una clave maestra con la que cifrar la información. De hecho se hacía antes (con TLS 1.0). Pero es lento en comparación con DHE. Y tenía un problema adicional precisamente por ser lento... para ahorrar tiempo, se generaban al vuelo claves RSA muy cortas, de forma que con el tiempo podrían llegar a ser rotas por fuerza bruta.

¿Entonces se puede ser descifrar retrospectivamente o no?

Será más fácil o no dependiendo de la suite de cifrado usada en el servidor. Pero en realidad, lo más probable es que el atacante descrito arriba, pueda seguir sonriendo. Aunque el servidor hubiera tomado la precaución (y las molestias, porque no es muy soportado, requiere software moderno, etc) de utilizar PFS, todavía habría una oportunidad para el atacante. SSL cuenta con dos sistemas para "acortar" el tiempo de handshake cuando un cliente se conecta a un servidor. Memoriza sus estados y consigue así una conexión más rápida, facilita el single-sing-on, etc. Estos mecanismos son:

  • Sessions IDs: Tanto servidor como cliente recuerdan sus estados, y ambos se comunican con un ID que identifica ese estado. El cliente lo usa para indicarle al servidor que "busque" en memoria la conexión de ese cliente concreto. El problema es que si hay muchos front-ends, cada servidor puede haber ofrecido un ID diferente al cliente, y para solucionarlo se deben guardar en disco y compartirlo, cosa que no es buena idea. Si por el contrario estos IDs se mantienen en memoria, rotan a menudo.
  • Session tickets: Con este método (activo por defecto en OpenSSL), es el servidor el que firma y envía el estado cifrado al cliente, y "se olvida". Un cliente toma un ticket de sesión de un servidor, y una vez validado, le puede servir para otro front-end diferente (en un cluster, por ejemplo) y no tener que empezar de nuevo. Esos tickets son como una especie de pases temporales de sesión que ahorran tiempo a todos. Se generan y se cifran independientemente, y, por la forma que trabaja TLS, su fortaleza es menor (utiliza un cifrado más débil). Así que, en cierta medida, si se usan tickets de sesión, el secreto es tan fuerte como el del cifrado durante el intercambio de estos tickets, no el del cifrado de la información "real". Y lo que es peor, la información para cifrar los tickets no rota demasiado. Se suelen generar en memoria del servidor. Si es un solo servidor SSL el que maneja toda la información, este puede mantener el mismo ticket de sesión desde que arranca el servicio en memoria hasta que sea reiniciado.


RFC sobre session tickets. Fuente: tools.ietf.org/html/rfc5077

Por tanto, si con Heartbleed se obtuvo un ticket de sesión además de la clave privada, es posible que se pudiera obtener toda la información cifrada con los tickets, y con ella deducir las conversaciones durante la validez de ese ticket... que podrían haber sido días y días atrás.

Sergio de los Santos
ssantos@11paths.com

Cómo añadir Latch a la cuenta de servicios Movistar

jueves, 15 de mayo de 2014

Tras pasar un periodo de pruebas y de integrarse en Tuenti, el servicio Latch ya está disponible en la web de usuarios de Movistar, por supuesto, de forma totalmente gratuita. De momento está disponible para proteger el acceso web y su configuración es muy sencilla. La web de Movistar permite consultar facturas, ofertas, configurar los datos personales... tanto de fijo como de móvil. Estos son los pasos que se deben seguir para añadir un extra de seguridad.

Crear un usuario de Latch

Para ser usuario de Latch lo único que se necesita es descargar la app gratuita de Latch para Windows Phone, Android o iPhone y desde la misma app registrar un cuenta y activarla. Solo es necesario proporcionar un nombre, un correo electrónico para validar el registro y una contraseña. Todo será anónimo y no se mantendrá ningún dato personal de los usuarios de Latch.

Parear la cuenta con Movistar

Es necesario entrar en las preferencias de la cuenta de Movistar. Desde el enlace correspondiente, según el tipo de usuario (particular, autónomo o empresa) se debe acceder a la cuenta según el tipo de contrato. Movistar mostrará los servicios que ofrece y en la parte inferior se debe mostrar el correspondiente a Latch: "Seguridad adicional Latch".


Añadir la seguridad adicional Latch una vez en el panel de usuario de Movistar


El proceso de pareado 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" e introducirlo en la web que se quiere proteger.

Código de pareado generado. Se disponen de 60 segundos para introducirlo en la web

Una vez generado, se debe introducir en la opción de "Emparejar Mi Movistar con Latch" dentro de "Seguridad adicional Latch".

Zona en la que se debe añadir el código generado

Si el código caduca se puede volver a pedir otro código temporal. No es problema. Automáticamente aparecerá una alerta en la app de Latch informando de que el servicio Movistar se ha pareado con éxito. A partir de aquí se podrá configurar el funcionamiento y bloqueo.

Latch pareado con éxito con mi Movistar web

Configuración de bloqueos

A partir de este momento se puede utilizar Latch para que bloquee el acceso cuando no se vaya a utilizar la identidad digital de Movistar (cuando no vaya a utilizarse el servicio). Esto puede hacerse directamente desde el dashboard principal de servicios en la app, pulsando en el Latch de Movistar o entrando en sus preferencias, donde se podrá configurar también un autobloqueo o programar bloqueo.

Configurando el Latch de Movistar

Configuración de alertas (opcional)

La opción de avisar cuando se accede (aunque se tenga el acceso desbloqueado), permite comprobar cuando alguien ha accedido a la cuenta sin que se produzca un bloqueo. Esta es una opción cómoda que permitirá saber si alguien dispone de tu contraseña incluso sin cambiar la forma de conectarte al sistema.

También existe la alerta de despareado de cuenta. Si en algún momento el usuario legítimo (o cualquier otro) decidiera desparear la cuenta de Latch, esto sólo se puede hacer desde la web de Movistar.

Desperear la cuenta Latch

Al mismo tiempo, en la app de Latch se recibiría una alerta que avisaría al usuario del despareo.


Algunos detalles técnicos sobre el front-end de FaasT

miércoles, 14 de mayo de 2014

FaasT se ha convertido en un proyecto de gran magnitud, tanto en su back-end (bases de datos, servidores, procesos, informes, consumidores, hilos...) como en su interfaz web. Hablaremos de qué herramientas y librerías se están utilizando para implementarla y, además, un esbozo de cómo se está organizando el código.

Existen muchas guías de buenas prácticas y diferentes formas de organizar código, todas válidas y aceptadas. Para FaasT se ha utilizado una de ellas, que se ha considerado adecuada. No tiene por qué ser la mejor para todos los proyectos, pero sí que la estrategia adoptada está mostrándose útil en un entorno de un trabajo de gran magnitud donde colaboran diferentes programadores con perfiles dispares.

Reglas importantes

Un proyecto de front-end como FaasT no lo crea una sola persona. Es necesario pensar como equipo desde un primer momento y eso conlleva respetar algunas normas. Por ejemplo:

  • Código modular: Algo que aplica a cualquier proyecto de programación es que en la medida de lo posible hay que hacer el código tan modular como se pueda, para que a la hora de tener que hacer un cambio, se agilice la búsqueda de la zona afectada. Otra ventaja es que si se quiere añadir nueva funcionalidad siempre es más sencillo si todo está separado en bloques con funcionalidad específica.
  • Comentarios: En cualquier código con lógica debe haber comentarios explicando funciones o métodos que no sean muy obvios, tanto pensando en otras personas que puedan leer el código, como para el propio autor que no debe confiar en exceso en su propia memoria. Los comentarios en HTML son tan útiles como los de código "tradicional", sobre todo porque obliga al grupo de trabajo a mantener una estructura dentro de un archivo. No es necesario insertar comentarios de HTML con <!—Mi comentario -->... muchos back-end permiten guardar comentarios con etiquetas suyas, que luego no se muestran al cliente ni en el código fuente que se envía. Así, se mantienen los comentarios como algo interno para desarrollo.
  • Principio KISS: Un principio creado en la marina americana hace 50 años que significa: “Keep It Simple, Stupid”. El proyecto es muy grande. Tal vez, que una persona invierta tiempo en conseguir un trozo de código más simple, puede significar que otras personas del equipo luego puedan continuar el hilo sin perder mucho más tiempo en documentación. 
Las tres reglas tienen un obvio factor en común: si se es parte de un equipo, se ha de trabajar en equipo.  

Front-end

FaasT depende de muchas librerías, plugins de JavaScript, reglas de CSS, etc. Organizar todos estos archivos que componen la interfaz web en carpetas puede resultar complicado. Para solucionarlo, se ha usado HTML5 Boilerplate.

Se trata de una plantilla de front-end para hacer páginas web siguiendo los estándares de HTML5 y con una serie de plugins y archivos por defecto que, aunque obviamente pueden ser modificados, proporcionan una muy buena base para empezar el front-end de cualquier proyecto web.

Directorios

Cómo se estructuran los directorios es algo que no solo ayuda a llevar una buena organización del código que nos pueda ser útil, sino que también facilita la vida al resto de programadores. La estructura usada en FaasT está basada en la que ofrece HTML5 Boilerplate con unas pequeñas modificaciones (como la carpeta de archivos less).

Estructura de directorios en FaasT
Esta jerarquía de documentos es muy sencilla de entender a simple vista y salvo el cambio de directorio que almacena archivos .less que se explicará brevemente, el resto está todo en la documentación de HTML5 Boilerplate.

CSS y LESS

Los archivos CSS de un proyecto web no reciben quizás la misma atención que por ejemplo los archivos JavaScript. Sin embargo, no por ello se deben dejar de seguir algunas buenas prácticas:
  • Todas las reglas CSS deben encontrarse en archivos específicos. No es buena idea tener reglas CSS dentro de etiquetas en el propio HTML, o como reglas dentro del elemento al que se le aplica el estilo.
  • !important no se debe usar más que en caso de emergencia. Si se debe forzar una regla CSS, es que algo se está haciendo mal. 

JavaScript

Igual que con las reglas de CSS, la lógica que se le ponga al front-end no debe encontrarse ni en etiquetas de [script] ni como parte del elemento al que se refiere. Deben encontrarse en un archivo .js aparte. No respetar esta regla puede suponer un gran problema para depurar código JavaScript (cosa ya relativamente complicada de por sí). En FaasT, como en tantos otros proyectos, usamos librerías externas que se referencian vía CDN pero de las que también disponemos de un fallback local en caso de caída del CDN. Estas librerías están todas almacenadas separadas del resto de archivos .js en la carpeta "vendor", así no se mezclan archivos nuestros con librerías. Por ejemplo:


Usabilidad y diseño

Dicho lo anterior, en el proyecto se han elegido las siguientes librerías:

Para Javascript:
  • Jquery: fácil, versátil y con muchos plugins que se usan constantemente. 
  • Jquery UI, perfecto para extender la funcionalidad base y adaptarla a nuestras necesidades, para accordions, sliders y otros usos.
  • Normalize.js: para resetear CSS
  • Modernizr.js: para que navegadores antiguos puedan usar elementos de HTML5 y CSS3.
Para CSS:
  • Twitter Bootstrap: sobre todo por la comodidad de organizar los tamaños de los divs, también tiene un montón de elementos útiles como botones o glyphicons.
  • Para la gestión de nuestros propios CSS hemos usado LESS, un lenguaje de hoja de estilos dinámico que permite el uso de variables para usar en colores, por ejemplo, acelerando y simplificando el posible cambio de estilos. Así no hace falta escribir un color cientos de veces como #F5F5F5, sino que cambiando la variable podemos modificar las cientos de veces que se llama a ese color. También proporciona otras pequeñas ventajas como reglas anidadas o extender clases.
Todo esto luego se compila en archivos .less en .css que es lo que se le presenta al cliente.

Juan Luis Sanz
juanluis.sanz@11paths.com

Agenda de la semana de Eleven Paths

martes, 13 de mayo de 2014

El 13 de mayo, Chema Alonso participa en una conferencia abierta y gratuita con la organización RENATA de Bogotá. Organizada por Telefónica, Movistar, Eleven Paths y RENATA, la conferencia "La importancia de la seguridad digital" tendrá lugar el 13 de mayo de 2014 desde las 13:30 a las 15:00 horas. La retransmisión será en directo a través de RENATA en este enlace.



El viernes de 16 de mayo, tendrá lugar en Madrid el acto central del Día Mundial de Internet en el Senado de España. Se trata de un debate plenario sobre "La Gobernanza de Internet: ¿Quién y Cómo se controla la red?" con motivo del Día Mundial de Internet, con la participación de Chema Alonso, CEO de Eleven Paths. Más información en este enlace.




Por último, el sábado 17 de mayo se celebrarán en Madrid las jornadas X1REDMASSEGURA, cuyo objetivo es promover a través de un foro común el uso de Internet de una manera confiable y segura. Eleven Paths presentará la conferencia "Un pestillo a nuestra privacidad". Más información: http://www.x1redmassegura.com/



La leyenda del antivirus muerto

lunes, 12 de mayo de 2014

Brian Dye, vice presidente de Symantec, anunció hace unos días que los antivirus "estaban muertos" y "condenados al fracaso". Sus palabras han tenido una importante repercusión en la industria, pero no deja de ser una maniobra de marketing con una explicación algo menos simplista que esa frase.

Lo que ha dicho
Artículo en el Wall Street Journal 

Que los antivirus no sirven para hacer ya tanto dinero, que su empresa ya no apuesta de esta forma por el producto, y que por tanto, está muerto. Como lo ha declarado una de las mayores empresas comercializadoras de antivirus del mundo, sus palabras son tomadas como una forma de matar al antivirus como sistema de seguridad, no al antivirus de Symantec como producto o una de sus múltiples líneas de trabajo en seguridad. También ha dicho que los antivirus solo detienen el 45% de los ataques actuales.

Realmente, parece que se refería al motor de detección, puesto que los "antivirus" de usuario hoy en día, engloban toda una suite de seguridad con otras funcionalidades (sandboxes, antiphishing, gestores de identidades...). Esto sí merecería la pena comprarlo por ahora, decía Dye, como un todo. Después de estas declaraciones, anunciaba la nueva orientación de Symantec, concentrada en sus productos de seguridad como servicio, inteligencia, etc. Es un mercado donde parece que no tiene una fuerte presencia. Lógicamente, vender licencias de software es más rentable. Añadía que el mercado del malware "tradicional" se está reduciendo en favor de los ciberataques más sofisticados, denegaciones de servicio, ataques dirigidos, intrusión en redes...

Lo que quería decir

Un titular tan jugoso no se escapa. Se trata por tanto de una maniobra de marketing probablemente muy bien articulada que beneficia a la compañía. Quieren dar un volantazo hacia otros modelos de negocio. Un titular como este les ayuda a implantar en la conciencia colectiva (futuros clientes), que es necesario contratar otros servicios como los que justo ellos van a comercializar.

Las consecuencias

Sin embargo, el efecto colateral de esta declaración es que Symantec, desde su posición de "grande" en el mundo de los antivirus, perjudica al resto de actores que todavía quieren centrar sus esfuerzos en los motores antivirus. De hecho, entre otros, Kasperksy ha reaccionado alegando que a los antivirus les queda bastante recorrido.

Es cierto que en el escritorio, los antivirus no son solo motores y que la detección (por firmas, heurísticas o en cloud) es una tecnología cada vez con menor éxito, pero los antivirus hace tiempo que evitan llamarse así. Ya hace mucho que se "reinventaron" en forma de suites de seguridad. Y esto, para los usuarios finales, es una herramienta todavía muy útil. Si bien no la primera medida de seguridad que deberían tomar, sí que esta "suite de seguridad" puede ayudarles a mantener un sistema mejor protegido, una vez la amenaza ha saltado el resto de prevenciones que se deberían aplicar. Es decir, el antivirus no está muerto en el escritorio, para el usuario podría ser una medida de seguridad más (no la primera en eficacia, desde luego). Quizás sí esté más moribundo en el entorno empresarial, donde los ataques serán dirigidos, y ahí, ni ahora ni nunca, tuvo nada que hacer el motor antivirus por sí solo. Ya se dijo desde Trend Micro en ese sentido alguna vez, que la industria antivirus apestaba (cuando Trend Micro estaba intentando vender que se trasladaba a la nube en 2008, y dejaba más de lado el modelo "tradicional" de antivirus).

Artículo de Trend Micro en 2008. La industria AV apesta

La afirmación del antivirus muerto se está repitiendo en la industria desde mediados de la década pasada. Siempre han sido conscientes de sus limitaciones (cuando trabajaban con firmas, por la propia naturaleza de las "listas negras"; cuando se volcaron en la heurística, por la aparición de los crypters...). Solo que ahora, verbalizarlo en frases simples y viniendo de quien viene, se manda un mensaje simple y contundente... aunque erróneo sin el contexto necesario. Tan erróneo, por otro lado, como el que han mandado las empresas antivirus también durante muchos años y hasta aproximadamente mediados de la década pasada, donde se hablaba de 100% de protección con la mera presencia de un antivirus en el sistema.

Sergio de los Santos
ssantos@11paths.com

Metashield for IIS y las universidades españolas

viernes, 9 de mayo de 2014

No es difícil detectar metadatos en la mayoría de documentos listos para ser descargados en la web. Algunos metadatos serán más relevantes que otros, pero en conjunto, pueden llegar a suponer un problema. Hemos realizado un pequeño estudio sobre las universidades españolas para comprobar cuántas vuelcan metadatos en sus documentos, y proponemos una solución a nivel de servidor.

Como en otras ocasiones, hemos realizado un estudio a través de un pequeño experimento sobre los dominios de universidades españolas. Gracias a la herramienta FOCA, hemos extraído direcciones de correo, impresoras, programas que se han utilizado, etc, todo a partir de documentos públicos.

FOCA extrayendo metadatos de los principales dominios de universidades españolas.
Se puede observar el gran número de datos a la izquierda

Aunque se pueda pensar que esta información resulta inocua, el ENS (Esquema Nacional de Seguridad) en su artículo 5.7.6 referente a la limpieza de documentos, nos recuerda que: "Se retirará de estos toda la información adicional contenida en campos ocultos, metadatos, comentarios o revisiones anteriores, salvo cuando dicha información sea pertinente para el receptor del documento". Con los datos encontrados, la mayoría de información no resulta pertinente para el receptor, con lo que debería ser limpiada antes de hacerse pública. Para las universidades que utilicen el servidor IIS (internet information services) es posible usar Metashield Protector For IIS. Funciona como un módulo que trabaja sobre repositorios documentales en sitios web y realiza automáticamente una limpieza de metadatos cuando son servidos al usuario, sin alterar los que se encuentran en el servidor.

Ejemplo de configuración del módulo de Metashield Protector for IIS


Así, el receptor siempre obtiene una copia del documento "limpia" de metadatos si ha accedido a él a través del servidor web. Dispone además de una característica muy útil para configurar ciertos metadatos que ayuda a personalizar y homogeneizar la información incrustada en los documentos.

Gráfica de documentos y metadatos servidos por universidades con IIS

En el gráfico expuesto arriba, se muestran las universidades españolas que utilizan IIS como servidor web, y la cantidad de metadatos encontrados en relación con los documentos. Metashield Protector for IIS perseguiría tres claros objetivos:

  • Ayudar al correcto cumplimiento con el ENS y LOPD (ley orgánica de la protección de datos).
  • Generar confianza en el tratamiento de la información (relativos a la confidencialidad).
  • Evitar posible recopilación de datos por parte de atacantes que pudiesen derivar en otros más severos.


Metashield para IIS no interfiere en el desarrollo habitual de procesos y el consumo de recursos es mínimo, tanto en memoria como en disco. El software dispone de un informe estadístico que muestra los parámetros más relevantes y un log con información útil sobre las limpiezas realizadas.

Ejemplos de estadísticas que muestra Metashield Protector for IIS

El negocio de las "FakeApps" y el malware en Google Play (VII): Cómo llegan a las víctimas

miércoles, 7 de mayo de 2014

Seguimos observando las apps falsas en Google Play, cómo se comportan y cómo funciona este negocio. Si en la anterior entrada estudiamos qué estrategias manuales sigue Google Play para limpiar su store e intentar mitigar el problema, ahora veremos cómo llegan las FakeApps a los usuarios. 

Los atacantes necesitan posicionar las aplicaciones en Google Play "lo más alto posible" al igual que en en cualquier buscador. Por tanto, el SEO clásico y el menos convencional (el conocido como black SEO) también son técnicas válidas (aunque quizás menos estudiadas) en el market. Desde el punto de vista del atacante, es imprescindible aparecer en las búsquedas o apps relacionadas, para cazar al usuario despistado y ocasional. De esta forma las aplicaciones aparecerán muy cerca de la aplicación que desean suplantar, y los usuarios la descargarán más. Cada instalación, supone algunos céntimos en publicidad.

Para conseguirlo, existen varias técnicas, basadas principalmente en la experiencia de cada desarrollador, puesto que no está documentada ninguna técnica que ofrezca mejores resultados. La verdadera popularidad alcanzada a través del mérito de la aplicación es la mejor, pero los atacantes manejan tiempos de semanas en el mejor de los casos, y no pueden esperar a que una app de mala calidad o que no es más que adware, se posicione en ese tiempo. Lo más habitual es aprovechar el nombre de aplicación que se quiere suplantar o con la que se quiere confundir además del texto explicación. La descripción de cada aplicación (el lugar donde se expone en qué consiste la app y las mejoras que incluye) permiten introducir cualquier tipo de texto. En él, los atacantes escriben todas las palabras que creen oportunas para que las víctimas lleguen a ellas. En este sentido, es muy parecido a las técnicas usadas con las páginas HTML y las keywords.

Este es un ejemplo habitual que puede ocurrir en una descripción de Google Play. Una redacción llena de palabras sin sentido, que intenta que la app falsa aparezca cuando se buscan cualquiera de estas palabras.

Google permite este tipo de descripciones caóticas y sin sentido. Se ha dado la situación en las que la aplicación falsa aparece sospechosamente "cerca" de la real, invitando a la confusión. Mostramos con imágenes, a continuación, algunos ejemplos de resultados de búsquedas.


En esta imagen observamos hasta cuatro Minecraft falsos en las primeras posiciones de búsqueda

El falso Top Eleven aparece en cuarta posición

Si los grupos actúan a la vez, la búsqueda puede mostrar muchas apps falsas. Esta es una imagen tomada a principios de octubre de 2013 (un día especialmente complicado con muchas aplicaciones falsas), en el que una búsqueda del juego "Clash of clans" devolvía lo siguiente (las apps falsas están rodeadas con un círculo rojo).

En rojo, las apps con iconos idénticos a otras, pero totalmente falsas que contienen adware o malware

Desde diciembre de 2013, esta situación ya no se da de forma tan vistosa. Google Play modificó sus políticas, e impidió que dos aplicaciones compartiesen iconos sospechosamente parecidos. Igualmente, impedía el uso de un nombre exactamente igual a una app ya en el Store. Desde entonces, esta "contaminación" es mucho menos común, pero se han llegado a niveles preocupantes hasta al año pasado.

Esto no significa que desde 2014 no existan FakeApps, sino que los atacantes han modificado sus hábitos.  Ahora deben utilizar iconos de app más sutiles, o añadir palabras a los nombres originales para sortear las restricciones de Google.

FakeApp de Clumsy Ninja, cuando todavía no estaba disponible para Android

En resumen, la forma de llegar a las víctimas se basa en una buen parte de ingeniería social, y bastante de black SEO.

El negocio de las "FakeApps" y el malware en Google Play (I): Introducción 
El negocio de las "FakeApps" y el malware en Google Play (II): Tipos de "fakes"
El negocio de las "FakeApps" y el malware en Google Play (III): Estrategias
El negocio de las "FakeApps" y el malware en Google Play (IV): Política y rentabilidad
El negocio de las "FakeApps" y el malware en Google Play (V): Limpieza automática
El negocio de las "FakeApps" y el malware en Google Play (VI): Limpieza "manual"
El negocio de las "FakeApps" y el malware en Google Play (VII): Cómo llegan a las víctimas
* El negocio de las "FakeApps" y el malware en Google Play (VIII): Permisos en las apps
El negocio de las "FakeApps" y el malware en Google Play (IX): ¿Qué hacen y cómo se programan las apps?

Sergio de los Santos
ssantos@11paths.com

Internet se ha roto, otra vez (y II )

lunes, 5 de mayo de 2014

Poco se puede aportar ya al fallo de implementación criptográfica Heartbleed (en Eleven Paths ya tenemos disponibles plugins para FOCA Faast). Se trata de un grave problema que tendrá (y es posible que haya tenido) graves repercusiones. Sin embargo, no es la primera catástrofe (criptográfica o no) en la red. ¿Las ha habido peores? ¿Es realmente una catástrofe, o lo han sido sus "daños colaterales"?

Otros apocalipsis

En general, ya se han dado casos muy similares de catástrofes que afectarían a la red tal y como la conocemos, y de la que se han desprendido titulares dantescos. El primero fue el "efecto 2000", que aunque no contó con logotipo oficial desde el principio, sí que disfrutó de una marca propia (Y2K)... pero eran otros tiempos, no era propiamente criptográfico y quedó en una especie de decepción apocalíptica que se sació con mucha literatura y algunos telefilms. Pero recientemente ya hemos sufrido varias veces "el peor fallo de la historia de Internet". Veamos algunos:

  • El apocalipsis criptográfico de Debian. 2008. Se descubre que alguien (por error) del equipo de Debian eliminó en 2006 una línea de código en el paquete OpenSSL de Debian que ayudaba a generar la entropía al calcular el par de claves pública y privada. Esto hace que las claves generadas con él ya no sean realmente fiables o verdaderamente seguras. Se podía consultar en una tabla sus privadas correspondientes, conociendo las públicas. Miles de millones de claves, que no sabía muy bien qué protegían, eran ya una completa pantomima. Ninguna CA pareció verse afectada.
  • Kaminsky y los DNS: Julio de 2008. Se publica una actualización coordinada para la mayoría de los dispositivos en Internet que utilizan DNS. Un fallo incluso más grave que los mencionados, porque era inherente al protocolo, no un problema de implementación. Dan Kaminsky lo descubre sin ofrecer detalles, pero algún dato se escapa. Thomas Dullien se aventura semanas después a publicar en su blog su particular visión de lo que podía ser el problema descubierto por Kaminsky, sin tener conocimiento previo de los detalles. Y no se equivoca en su teoría: era posible falsificar (a través del envío continuo de cierto tráfico) las respuestas de los servidores autorizados de un dominio. Esto era también gravísimo, pero la actuación fue correcta y coordinada. Aun con Dullien publicando antes de tiempo el fallo, "sin querer". ¿Se usó antes por atacantes? Nunca se supo. Eso sí, años después, incluso después de esa catástrofe, DNSSEC sigue siendo "una rareza".
  • Espionaje a "gran escala" con BGP: En agosto también de 2008, se habla de nuevo de la mayor vulnerabilidad conocida en Internet. Tony Kapela y Alex Pilosov demostraron una nueva técnica (que se creía teórica) que permite interceptar el tráfico de Internet a una escala global. Se trataba de un fallo de diseño en el protocolo BGP (Border Gateway Protocol) que permitiría interceptar e incluso modificar todo el tráfico de Internet no cifrado. BGP es un protocolo que se utiliza para intercambiar tablas de enrutamiento entre sistemas autónomos (AS). El problema es que nunca se ha llegado a idear un sistema que realmente autentique a ambas partes, y los routers estén así seguros de que la información recibida desde un AS es legítima y viene del sitio adecuado.
  • Ese mismo año, se habló de la denegación de servicio "perfecta". La compañía sueca Outpost24 afirmó haber descubierto en el 2005 (aunque lo sacó a la luz en 2008) varias vulnerabilidades de base en el mismísimo protocolo TCP/IP que podrían permitir la caída de cualquier aparato con comunicación TCP en la red. Fue llamada "denegación de servicio de bajo ancho de banda". Decían no conocer una implementación de la pila que no fuese vulnerable. Aunque grave, se olvidó rápidamente y causó menos revuelo del esperado.
Página de heartbleed animando a utilizar el logotipo para ilustrar la noticia

El apocalipsis también hay que saber "venderlo"

Si nos distanciamos del aspecto técnico, lo que diferencia a Heartbleed con respecto a las ya mencionadas, es sin duda su perfecta campaña de marketing y difusión. Si el fallo en los DNS descubierto por Kaminsky era eso, "el fallo de Kamisnky", este ha contado por primera vez con un logotipo para anunciar una vulnerabilidad; se le ha dotado de un nombre muy adecuado e ingenioso; se ha reservado un dominio; orquestado una especie de campaña de comunicación; cuidado al detalle el diseño de la página; difundido notas de prensa con alto alcance que ha llegado a los telediarios; se han colado ligeras exageraciones para dar empaque (el 66% de Internet era vulnerable...); incluso se ha cuidado el "timing" (se alimentan teorías sobre si el día de la muerte de XP era o no adecuado para difundirlo)... en definitiva, una especie de espectáculo a gran escala perfectamente acompasado para dar a conocer un grave fallo de seguridad. Un paso que no se había dado hasta ahora al menos de forma tan consciente, incluso cuando se han descubierto problemas de seguridad a la altura. Esto tendrá una consecuencia directa: Las vulnerabilidades graves (no descubiertas como 0day) siempre han servido para dar a conocer a su autor, elevar su prestigio personal o de su empresa. Heartbleed (al margen de merecer la importancia técnicamente) les ha enseñado a todos que se puede hacer "mejor". De hecho, ya se han lanzado vulnerabilidades con un diseño similar: http://tetraph.com/covert_redirect/

Los fallos con perspectiva

¿Consecuencias de todo esto? Hasta el momento parece que nunca se han utilizado ninguna de estas vulnerabilidades como métodos de ataque masivo que colapsen Internet y "la rompan". ¿Han servido estas grandes catástrofes para poner contra las cuerdas a la Red? Tampoco. ¿Alguien se ha beneficiado de ellas? Seguro. Para poner de rodillas a la red, en realidad, se usan otras armas: malware común y sencillo, realizado por atacantes menos sofisticados, como Blaster, Sasser, CodeRed o Slammer (todos con más de 10 años), sí que consiguieron un impacto masivo en la Red. Incluso ciertos ataque DoS, en especial los realizados contra servidores DNS centrales usando simplemente la fuerza bruta, tuvieron más impacto "real"  (y menos mediático) desestabilizando Internet.

Quizás podría ser comparado a las catástrofes aéreas en contraste con los accidentes de tráfico. Una catástrofe aérea es, en un instante, un verdadero drama para cientos de pasajeros. El accidente aparecerá en los telediarios, se investigará y será recordado. Afortunadamente, ocurren ocasionalmente. Sin embargo, el problema con las muertes de tráfico en carretera, proporcionalmente, parece mucho mayor. Ocurren a diario, no aparecen en las noticias, y se dice que estadísticamente resulta mucho más inseguro viajar por carretera en turismo que tomar un avión. Sin embargo, ese goteo de víctimas en las autovías y carreteras secundarias, causa un daño mayor en conjunto, más "palpable".

Internet se ha roto, otra vez (I)
Sergio de los Santos
ssantos@11paths.com