Heartbleed plugin for FOCA

miércoles, 30 de abril de 2014

By now, everyone knows about Heartbleed. Just like we did for FaasT, we have created a plugin for FOCA (final version) one of our most downloaded tools. This plugin allows the tool to detect vulnerable servers and audit them, among all the other cool features FOCA counts with.


Loading the plugin in FOCA
To take advantage of the plugin, just download FOCA and create a project over the domain to be audited. Load the plugin from "Plugins" tab in the upper menu, and press on "Load/Unload plugins". Browse for HeartBreatPlugin.dll and load it. Once loaded, it will be accessible from the plugins menu.

There are two options: automatic analysis or manual analysis and exploitation. Checking on "Check all hosts that FOCA detects automatically for the HeartBleed vulnerability" will make FOCA to check for the vulnerability in all domains found for this project.


Automatically checking domains

Domains will go from the "Pending" box to "Checked" or "Vulnerable", depending on the results. All domains found by the usual way FOCA works, will be checked. For a manual analysis, a domain and port has to be specified. There is an option to repeat the attack every 5 seconds and generate a memory dump, that will be stored in a local file.


Manually checking domains

Ricardo Martín
ricardo.martin@11paths.com








DANE: una opción para mejorar el escenario de TLS (y sin hablar de HeartBleed)

lunes, 28 de abril de 2014


Después de la resaca de HeartBleed, ha existido una especie de "caza de brujas" buscando otros servicios (aparte de HTTPS) que pudieran estar comprometidos: servidores de correo, de IMAP, OpenVPN, entornos industriales, dispositivos embebidos, etc. Casi nadie se ha librado debido al uso masivo de OpenSSL. Una de las pocas aplicaciones que usa OpenSSL pero no está afectada (porque no usa la extensión Heartbeat) es DNSSEC, la eterna promesa del DNS. Sin embargo, sí que existe una iniciativa basada en DNSSEC que de alguna manera está afectada por HeartBleed: DANE.

Introducción

DANE (siglas de DNS-Based Authentication of Named Entities), especificado en el RFC 6698es una propuesta de intentar mejorar el escenario actual de uso de TLS y las autoridades certificadoras (CAs). Hoy en día utilizamos certificados para poder relacionar una clave con un nombre concreto (un dominio, un email, etc.), y este certificado combina la clave pública con otra información relevante para el uso de este certificado. Finalmente es firmado por otra clave (generalmente de una CA o subCA). La firma de este certificado sólo tiene sentido si confiamos en la clave que lo ha firmado, y esa es la razón por la que debemos confiar en una serie de CAs que mantenemos instaladas en nuestro sistema operativo o navegador.

De hecho, cuando hablamos del pinning de certificados ya se mencionó a DANE como alternativa, apuntando a los problemas que existen hoy en día con el modelo tradicional de las Certification Authorities (CA): hay una gran cantidad, nuestros sistemas operativos y navegadores confían por defecto en muchas de ellas y por desgracia algunas son comprometidas... además del modelo de negocio que existe detrás. Lógicamente, estas autoridades deben proteger con especial ahínco su clave privada puesto que el que la obtenga puede firmar certificados sin ningún tipo de control. Además de que generalmente no se comprueba si un certificado está firmado por una determinada CA o no (solo que esté firmado), lo que deriva en un gran problema en el caso de que una CA sea comprometida.

Por otro lado, las DNS Security Extensions (DNSSEC) son un modelo similar a las CAs donde claves en las que se confían firman digitalmente información de claves no confiables. Esto significa que para un dominio como www.elevenpaths.com, cada organización de la cadena de estructura DNS debe firmar la clave de la organización inmediatamente inferior. Por ejemplo, .com firma la clave de elevenpaths.com y los dominios raíz firman la clave de .com. Durante la validación, DNSSEC sigue esta cadena de confianza hasta la raíz automáticamente, tal y como ocurre con una validación "normal" de SSL/TLS, y donde los dominios raíz funcionan como CAs. Aunque DNSSEC ofrece varias mejoras: las claves están asociadas a nombres DNS, se pueden acceder a las claves firmadas con una simple petición DNSSEC, y lo más importante: que las claves de un dominio en concreto sólo pueden ser firmadas por las claves del dominio padre, y no por otros, como ocurre en el SSL "habitual" que varias CAs pueden firmar un mismo dominio.

DANE combina estos conceptos y aprovecha la infraestructura DNSSEC para almacenar y firmar las claves y certificados que se usan en cualquier servicio TLS.

Cómo funciona DANE

Su funcionamiento es muy sencillo. Cuando nos conectamos a cualquier servicio TLS, lo que hacemos es:
  • Por un lado, obtener la información del certificado que nos ofrece ese servicio (este es comportamiento normal)
  • Pero a la vez, se hace una petición DNS para ver si concuerda con un registro especial DNSSEC (tipo 52 o TLSA) donde se almacena la información de ese certificado. 
  • Si coincide, es que todo está bien.
Es decir, que para que el sistema funcione, sólo se tiene que modificar el registro DNS del dominio, añadiendo un campo. 
Registro DNSSEC

El formato del registro DNSSEC donde se indica la información de DANE se divide en cuatro campos principales (y sus posibles valores):
  • Uso del certificado: 
    • (0) CA Constraint, donde indicamos la CA autorizada a firmar el certificado, 
    • (1) Service Certificate Constraint donde indicamos un certificado que ser igual que en el servicio TLS, 
    • (2) Trust anchor assertion donde podemos indicar que CA vamos a usar y 
    • (3) Domain-issued certificate donde podemos indicar un certificado que será el válido (puede incluso ser uno auto-firmado)
  • Selector: la parte del certificado que se usará para comprobar con la información en el registro: 
    • (0) Todo el certificado, 
    • (1) sólo la clave pública
  • Tipo de comprobación
    • (0) exacta, 
    • (1) hash sha256, 
    • (2) hash sha512
  • Los datos concretos: generalmente el hash o bien del certificado o de la clave pública que se quieren comprobar.
El nombre del registro DNS tiene que ser de la forma _puerto._protocolo.dominio. Por ejemplo _443._tcp.torproject.org o _25._tcp.mail.ejemplo.com son nombres de registro válidos.

Ejemplo

En la página del proyecto TOR (que soporta DANE), se puede ver su registro relacionado con la página web del proyecto (para ello se solicita el registro TLSA que son el tipo 52 con este comando):

host -t TLSA _443._tcp.torproject.org

que devolverá:

_443._tcp.torproject.org has TLSA record 3 1 1 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10 D2A58DA5

donde se puede comprobar que torproject.org en el puerto 443/tcp tiene un servicio TLS donde existe un certificado cuyo hash256 (el tercer 1) de su clave pública (el segundo 1) es 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10

Para comprobar que coincide con el certificado que nos envía el servidor al acceder a la página web por HTTPS, se debe primero obtener su clave pública y calcular su hash.
  • Se obtiene el certificado de la web de torproject.org con el siguiente comando:
openssl s_client -connect torproject.org:443
** snip **
-----BEGIN CERTIFICATE-----
MIIFXTCCBEWgAwIBAgIQCUixqTslHQ2xBRBZ4sJoCjANBgkqhkiG9w0BAQsFADBwMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3dXJhbmNlIFNlcnZlciBDQTAeFw0xMzEwMjIxMjAwMDFaFw0xNjA1MDMxMjAwMDBad3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNzMHIxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHAoIBAQC3IzntyGiFJ+WBDpwADPriJSptB8h1Gkeq8FNJuWIXUlfA0RlAfNEOu85CEwdXYWxwb2xlMR4wHAYDVQQKExVUaGUgVG9yIFByb2plY3QsIEluYy4xGTAXBgNVBAMMECoudG9ycHJvamVjdC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKG7rUzGxJWvCqT0qrCvxUoUl4S1geh7+VFdo0evz88YvEGizDALi0+aBwpEeiZyxWqFhHheih24hWS1Uf6bh+uHG8kRfHAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBRRa1LT6udEZoWH4NeZMKLJhMz6i2tzQ3CubaU1+RePA7wU/tGgmUC53Shs1YYiSKRCXX03OvW9YuMRsoc6eAoVBQ7ZivTEWRUbwxZeGWlQXtoWsP/tZHphsIeVLmg/jw6kyZfscEHVAqylgYMJzlSySqq6dv2HNJpJExV6nVA9QUvsILwg4uuH+53csk0IG/CFaP+QrwIHdTzM2WVkYqISuFlyOzAdBgNVHQ4EFgQUgiYI8RMpVTQUtI+AHXG4YNpLc2hhMi1oYS1zZXJ2ZXItZzEuY3JsMEIGA1UdIAQ7MDkwNwYJYIZIAYb9bAEBMCowQcwwKwYDVR0RBCQwIoIQKi50b3Jwcm9qZWN0Lm9yZ4IOdG9ycHJvamVjdC5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc2hhMi1oYS1zZXJ2ZXItZzEuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2VydC5jb20vKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYMGCCsGUKvNlZ9ZI0C0b1vbsl6L6Mtb0GA15ejF5/BT6Q38sN84PmeWp5nbYJ0ZAKsrky/cAQUFBwEBBHcwdTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tME0GCCsGAQUFBzAChkFodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEySGlnaEFzc3VyYW5jZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQBvcHF+gBHQqmAJYTrpqUtCNI+rdGPQ1otYgx4E16qZhd9kUgwug9c+ygo9LsRqap9aBMSOKYKc5MbHX1a9qkEYFOwlDN24IyClAV+MPkCVTOS/XxK3E7FmHsr6i/OHiGhK1eWbHKPAd6pTg7TT3VDlqyss8E+t7dckuArEekVjmy8opy75N4xkzEhuRMdPq722uOnHsYxXvPOA96RKufTkFwJje/xVm/g7vlN23IEBeKm7UOp6ksIRGTo6b+yYr2fzVOVxpXnMNkbJ7WNS/ZtS
-----END CERTIFICATE-----
** snip **
  • Se almacena el certificado (incluyendo el BEGIN y el END CERTIFICATE) en un fichero. Por ejemplo cert.crt
  • Se extrae la clave pública del certificado (porque como hemos visto en el registro DNSSEC, hacen el hash256 de la clave pública)
openssl x509 -pubkey -noout -in cert.crt > pubkey.pem
  • Se calcula su hash sha256 (código rápido en python basado de las dnssec-tls-tools de Adam Langley)
import sys
import hashlib

def main(args):
  if len(args) != 2:
    print 'usage: %s ' % args[0]
    return

  base64_data = ''
  in_base64_data = False
  for line in [x[:-1] for x in file(args[1], 'r').readlines()]:
    if in_base64_data:
      if line == '-----END PUBLIC KEY-----':
        break
      base64_data += line
    elif line == '-----BEGIN PUBLIC KEY-----':
      in_base64_data = True

  spki = base64_data.decode('base64')

  tlsa = hashlib.sha256(spki).digest()
  print 'Hash256 is %s' % (tlsa.encode('hex'))
  
if __name__ == '__main__':
  main(sys.argv)
  • Y finalmente se comprueba que sean iguales
hash256.py pubkey.pem
Hash256 is 578582e6b4569a4627aef5dfe876eec0539388e605db170217838b10d2a58da5

que efectivamente coincide con el hash previamente calculado.
  • Se puede comprobar además que los datos del registro DNS están firmados de forma correcta. El comando: dig +nocomments +nostats +nocmd +noquestion -t dnskey . > trusted-key.key almacenará la clave de la raíz. Luego, el comando dig +topdown +sigchase +multiline -ta www.torproject.org devolverá si la operación de comprobación de todas las cadenas ha tenido éxito o no.
Ejemplo de comprobación con www.torproject.com, y el comando usado 
¿Qué aporta DANE?

DANE proporciona algunas ventajas a la hora de lidiar con TLS:
  • Es posible limitar por CA, es decir, que es posible especificar que sólo una CA concreta puede firmar los certificados de un servidor (lo que disminuye la probabilidad de que alguien lo suplante si se compromete la seguridad de una CA concreta). Por ejemplo, en el caso del incidente de DigiNotar se crearon certificados falsos de Gmail; si Google hubiera usado DANE y hubiera limitado que sus certificados sólo pueden ser firmados por la CA que utiliza (GeoTrust), este ataque no hubiera funcionado para los clientes que visitaran el sitio falso.
  • Permite definir libremente qué CA se quiere usar para un certificado (y puede ser una CA propia).
  • Permite utilizar un certificado auto-firmado. Según el observatorio de SSL de la EFF, un 46% de los certificados en Internet son auto-firmados.

Problemas

DANE no aporta la validación extendida que ofrecen las CAs, donde se comprueba realmente la organización detrás de un certificado. Es algo que todavía hoy tiene que ser un procedimiento manual. Se trata de comprobar ciertos datos para que por ejemplo alguien que quiera un certificado goog1e.com, debademostrar que es Google Inc, "burocráticamente".

Pero el principal problema es la falta de uso generalizado de DNSSEC, tanto a nivel de servidor como de los clientes. Todavía hoy incluso algunos routers en Internet bloquean las peticiones y respuestas DNSSEC por resultar paquetes demasiado grandes. Además, por compatibilidad con navegadores u otros clientes TLS antiguos se necesitan aún certificados firmados por CAs bajo algunos escenarios.

Pero independientemente de la solución, lo fundamental es que sea respaldada por los navegadores. Y aún los navegadores no lo soportan. De hecho, durante un tiempo estuvo implementado en navegadores como Chromium aunque parece ser que eliminaron la funcionalidad por "poco uso"; en Firefox se discute hace años el poder incluirlo (existen parches no oficiales) aunque por ahora no está priorizado. Por suerte, existe un plugin para todos los navegadores que funciona bastante bien llamado DNSSEC TLSA Validator.

Plugin DNSSEC TLS Validator para Firefox

Por si fuera poco, se suma un problema al aumentar la latencia. Se añaden varias peticiones más en cada conexión TLS, con lo que se agrega un retardo que puede llegar a ser significativo en protocolos que requieren inmediatez como SIP, XMPP, etc. Existe una opción para evitarlo y es que, por ejemplo, se almacenen datos del registro DNSSEC serializado en el propio certificado (esta es la opción que eligió Chromium en su implementación), pero a su vez tiene problemas relacionados con el corto tiempo de vida de las firmas de DNSSEC... lo que obligaría a su vez a renovar los certificados TLS de forma casi constante.

Todo esto es lo que ha llevado a que, a día de hoy, de los 10.000 "top domains" de Alexa, tan sólo 3 de ellos mantengan DANE habilitado: torproject.org, fedoraproject.org y freebsd.org.

Otros usos

DANE ya se puede utilizar en BIND desde la versión 9.9.1-P3 de diciembre 2012, y también está presente en servidores SMTP como Postfix, clientes de IRC, servidores de XMPP, SIP, etc.

También existen ideas para poder utilizar DANE como método seguro de recuperar el certificado SMIME de un usuario, donde si por ejemplo se quiere conocer la clave pública de chris@example.com, tan sólo tendría que solicitar el registro 3f51f4663b2b798560c5b9e16d6069a28727f62518c3a1b33f7f5214._smimecert.example.com donde 3f51f4663b2b798560c5b9e16d6069a28727f62518c3a1b33f7f5214 es el sha224 de 'chris' y de esta forma obtendría la clave pública de Chris. También podría funcionar para claves OpenPGP con el formato 3f51f4663b2b798560c5b9e16d6069a28727f62518c3a1b33f7f5214._openpgp.example.com e incluso para claves públicas OTR: nb2wo2a=._otrfp.example.com. donde nb2wo2a= es el Base32 del usuario, en este caso "hugh".

El futuro

Si se utilizara DANE de forma masiva, el horizonte apuntaría a eliminar CAs comerciales, puesto que se podrían usar certificados sin que estas CA los firmasen. Aunque siempre quedarán las CAs que ofrecen los certificaciones extendidos, que ahora mismo son las menos. Pero por supuesto, el lobby de las CA hará todo lo posible para que iniciativas como DANE no salgan adelante, puesto que puede hacer peligrar su negocio de venta y renovación de certificados.

Adicionalmente se estaría dando un rol de seguridad más importante a los administradores de DNS, puesto que serían los árbitros con el poder de decidir quién se puede autenticar bajo un nombre concreto. Su función, realmente sería parecida a las CAs actuales (lo que significa que si alguien compromete su seguridad, las consecuencias serán muy negativas). Esto podría llevar a nuevos problemas en grandes organizaciones puesto que, generalmente los equipos que gestionan el DNS son diferentes a los que gestionan los certificados. Y ante casos como HeartBleed podrían existir problemas de coordinación.

David Barroso
david.barroso@11paths.com

Eleven Path's first anniversary. Cakes and Labs

viernes, 25 de abril de 2014

Although our first post was created in May, Eleven Paths officially started a year ago, in April 2013. It has been a whole year of hard work, but with quite a lot of rewards. Much more than we expected. Anyhow, it is just a year. To be honest, that was "easy". We still have to grow old and create the innovation technology we want to.

Just a year ago, Latch was not even an idea. FaasT was a tiny little thing (right now, it's a monster), Metashield was basically a prototype... and much more (tools, conferences, white papers, patents...). But we still have new technology to show. And it's going to be great. We really think so.

For this special day, we took a break in London, Madrid and Málaga Labs. We stop typing for a while and share a moment with our coworkers. These are just a few pictures of the little party we all shared.

The tiny cake from London (we don't endorse Evian),



The big and customized cake for Málaga, with typos included, and hiding the workers identities (you are welcome)...


And from our headquarters in Madrid.


As far as we can tell, they were all delicious.

Ocho siglas relacionadas con las vulnerabilidades (III): CVSS

miércoles, 23 de abril de 2014

Uno de los factores críticos sobre el que gira el mundo de la seguridad es el estudio y control de vulnerabilidades. Para conseguirlo de manera objetiva, existen organizaciones como MITRE, FIRST e ICASI, encargadas de parametrizar y estandarizar. Veremos qué estándares utilizan y cómo aprovecharlos para entender mejor los problemas de seguridad. Si en la entrada anterior se cubrieron los CVE, CWA y CAPE, en esta se verá el CVSS.

¿Quién y cómo se valora la gravedad de una vulnerabilidad? ¿Qué es exactamente un riesgo "alto" o una "vulnerabilidad crítica"? ¿Es cierto que según quien describa el fallo, la gravedad parecerá más o menos grave? Resulta complejo valorar el peligro de forma objetiva. Por ejemplo, el fabricante siempre tenderá a hacer hincapié en la mitigación o restarle importancia al problema en su boletín de seguridad. Otros medios, clamarán que se trata de un fallo muy grave en función del titular que necesiten. Y los usuarios verán que arbitrariamente unas vulnerabilidades son "altas" y otras "medias"... pero no saben a qué atenerse. Para solucionar esto nació CVSS (Common Vulnerability Scoring System), un sistema de valoración de vulnerabilidades creado como un método estándar para determinar y clasificar la criticidad de las vulnerabilidades.

Este estándar pertenece a FIRST. Es una confederación internacional de equipos de respuesta a incidentes informáticos que gestionan problemas de seguridad y promueven programas de prevención. FIRST patrocina y apoya el CVSS-SIG, que a su vez es un grupo de profesionales de la seguridad cuyo enfoque se centra en las vulnerabilidades de seguridad y utilizan CVSS como fundamento de su trabajo diario. Este grupo se encarga de actualizar y promover el uso del CVSS y de proporcionar un repositorio central para la documentación de este sistema de valoración.

Para conseguir ser lo más objetivo posible, CVSS se encarga de estudiar las diversas propiedades de una vulnerabilidad y las agrupa en tres métricas diferentes. En la actualidad y desde 2007, se utiliza la segunda versión de este sistema (CVSSv2), aunque en mayo de 2012 ya fuese aprobado el desarrollo de una nueva versión, que se espera en breve. Las tres métricas que arroja este sistema de valoración se denominan Base, Temporal y Métricas dependientes del entorno (enviromental metrics). Se encargan de estudiar la criticidad de las vulnerabilidades desde distintos puntos de vista.

Base Metrics

La única que es común a cualquier vulnerabilidad. Siempre se puede calcular para una vulnerabilidad y así valorarla. Su resultado es común para cualquier caso en donde se presente esta vulnerabilidad.

Métricas de base. Fuente: http://www.first.org/cvss/cvss-guide

A su vez, el primer factor necesario para calcular esta métrica es el que viene asociado al impacto, definido por cómo afecta la vulnerabilidad al activo en cuanto a la confidencialidad, integridad y disponibilidad se refiere, entendiéndose por cada uno de ellos lo siguiente:
  • Confidentiality Impact: Nivel de afectación que pudiera sufrir el activo relacionado a la limitación de acceso a la información y a la comunicación para usuarios autorizados. Cuando la vulnerabilidad permite que se revele información sensible (tradicionalmente del tipo disclosure), este valor aumenta.
  • Integrity Impact: Nivel de afectación que pudiera sufrir el activo relacionado a la fiabilidad y a la veracidad de la información. Cuando la vulnerabilidad permite corromper información sensible o modificarla, este valor aumenta.
  • Availability Impact: Nivel de afectación que pudiera sufrir el activo relacionado a la accesibilidad de los recursos de la información. Si la vulnerabilidad permite agotar los recursos o reiniciar un servicio (cualquier tipo de DoS), este valor aumenta.
Los valores que pueden tomar son "bajo", "medio" y "alto" para cada uno de ellos. El segundo de los factores es el de la explotabilidad, que viene definido por el vector de acceso, la complejidad del proceso y la autenticación necesaria para llevar a cabo un ataque que aproveche la vulnerabilidad, entendiéndose por cada una estos factores lo siguiente:
  • Access Vector: este factor proporciona información sobre la ubicación del atacante en el instante de llevar a cabo la explotación de la vulnerabilidad. Normalmente, será remoto o local.
  • Access Complexity: este factor hace referencia a la complejidad del ataque del proceso que lleva a cabo el atacante para explotar la vulnerabilidad. Quizás el valor más subjetivo, valora la complejidad de que se acceda a los sistemas vulnerables.
  • Authentication: este factor suministra información relacionada al número de veces que un atacante debe autenticarse en un objetivo antes de poder explotar una vulnerabilidad. Por ejemplo, explotar la vulnerabilidad puede requerir que el usuario esté autenticado (elevación de privilegios, por ejemplo) o no (acceso anónimo por la web).
Temporal Metrics 

Una vulnerabilidad puede considerarse igual de grave si existe parche o si no, si está siendo explotada por atacantes o si se ha revelado de forma responsable... incluso, durante las primeras horas desde que se conoce la vulnerabilidad, el nivel de confirmación "oficial" es relevante para valorarla. Existen factores que pueden cambiar con el tiempo.

Métricas temporales. Fuente: http://www.first.org/cvss/cvss-guide


 Dentro de los factores para valorar la métrica temporal, se encuentran:
  • Exploitability: Este factor mide el nivel de información accesible acerca de la vulnerabilidad. Pretende valorar qué técnicas, informes, exploits funcionales están disponibles, etc.
  • Remediation Level: Este factor está relacionado con tipo de solución disponible para la vulnerabilidad que se está valorando. Puede que exista parche oficial (bajaría su gravedad), solo se conozca alguna contramedida... o no haya remedio más que no usar el producto o servicio.
  • Report Confidence: este factor establece el grado de confianza en la existencia de la vulnerabilidad y la credibilidad de los detalles técnicos conocidos y reportados sobre ella. Especialmente útil cuando se revelan vulnerabilidades en foros, sin ningún tipo de comprobación oficial sobre la veracidad o alcance de la información.

Enviroment Métric

Se encarga de estudiar las características que afectan al entorno en donde se encuentra la vulnerabilidad. Los factores de esta métrica dependen estrictamente del entorno que sufre el problema y su relación con los usuarios en él. En realidad, esta métrica resulta en un "ejercicio personal" de los afectados y sus circunstancias únicas. No existe un valor "universal" para esta métrica, como es el de la base, sino que cada administrador podrá calcular el suyo.

Métricas de entorno. Fuente: http://www.first.org/cvss/cvss-guide

  • Collateral Damage Potential: Mide el potencial de pérdidas de vidas o bienes materiales a través del daño o robo de los activos, además de la pérdida económica de la productividad o de los ingresos. ¿Cuánto daño me haría la explotación de esta vulnerabilidad?
  • Target Distribution: Mide la proporción de los sistemas vulnerables. Se encarga de expresar una aproximación del porcentaje de sistemas que podrían verse afectados por la vulnerabilidad.
  • Security Requirements: Permite personalizar el valor de la métrica de entorno dependiendo de la importancia del activo, medido en términos de confidencialidad, integridad y disponibilidad.

Cómo calcularlo

Entre las webs más conocidas que almacenan esta información se encuentran: National Vulnerability Database (NVD), Open Sourced Vulnerability Database (OSBDV), CVE Details o Qualys Security Alerts. Muchas de estas webs suelen almacenar además información general de las vulnerabilidades, incluyendo documentación, pruebas de concepto, soluciones, versiones a las que afecta, etc.

Ejemplo de CVE Details con clasificación de vulnerabilidad

Para calcular el valor CVSS de una vulnerabilidad, existen numerosas herramientas. Las disponibles vía web son, por ejemplo:
Además, los programas de análisis y catalogación de vulnerabilidades más reputados, deben usar estos estándares para ofrecer la información más completa y objetiva a sus clientes. Sin ir más lejos, FaasT utiliza estos estándares, y ofrece información adicional de cómo ha sido calculado y por qué.

Ejemplo en FaasT de vulnerabilidad con métricas estándar


* Ocho siglas relacionadas con las vulnerabilidades (I): CVE
Ocho siglas relacionadas con las vulnerabilidades (II): CWE y CAPEC
* Ocho siglas relacionadas con las vulnerabilidades (IV): CWSS
Umberto Francesco Schiavo
umberto.schiavo@11paths.com

El negocio de las "FakeApps" y el malware en Google Play (VI): Limpieza "manual"

lunes, 21 de abril 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 automáticas sigue Google Play para limpiar su store e intentar mitigar el problema, ahora veremos qué políticas y métodos "manuales" aplica.

Vamos a hablar de qué estrategias ha seguido Google Play para intentar detectar y eliminar las aplicaciones falsas. Puesto que (principalmente) la razón de ser de las "FakeApps" es instalar malware o sistemas de publicidad en el dispositivo del usuario, la política de la store con respecto a la publicidad está íntimamente relacionada con el este tipo de aplicaciones y sus restricciones les afectan directamente.

¿No más anuncios intrusivos?

Durante el verano de 2013, Google Play modificó sus condiciones para la publicidad añadida a las aplicaciones. Envió un correo a los desarrolladores avisando sobre cambios en su política. En él, entre otras notificaciones, se alertaba explícitamente sobre:
  • "Restringimos el uso de nombres e iconos que puedan confundir por lo similar con apps existentes en el sistema, para reducir la confusión."

Aunque habla explícitamente de nombres e iconos que puedan confundir por su similitud con apps existentes en el sistema, en realidad también han aplicado la política a otras apps ya alojadas en Google Play. Desde finales de año, es mucho más difícil subir apps con un icono idéntico a otra existente.

También durante el verano pasado, modificaron sus políticas de desarrollo, principalmente con la intención de acabar con los modelos de publicidad más molestos. Estos suelen ser los que vienen en forma de spam en la barra de notificaciones. AirPush (un SDK de desarrolladores para sindicar la publicidad) es la empresa que más utilizaba este molesto sistema de spam. Las políticas, ahora incluyen:
  • "Las aplicaciones y sus anuncios no deben añadir ni modificar marcadores ni opciones de configuración del navegador ni añadir accesos directos a la pantalla de inicio o iconos en el dispositivo del usuario como servicio a terceros o con fines publicitarios."
  • "Las aplicaciones y sus anuncios no deben mostrar anuncios mediante notificaciones del sistema en el dispositivo del usuario, a menos que dichas notificaciones provengan de una función integral proporcionada por la aplicación instalada (por ejemplo, la aplicación de una compañía aérea que notifica a sus usuarios ofertas especiales o un juego que informa a los usuarios de promociones integradas en el juego)."

Esto fue un golpe para las compañías de publicidad más agresivas como Moolah Media, Smaato, LeadBolt o StartApp. Prácticamente, todas ellas ofrecen formatos similares de publicidad, entre los que figuran la instalación de iconos, el mencionado envío de notificaciones, la creación de marcadores "favoritos" o páginas de inicio en los navegadores. Pero AirPush es de las más agresivas. Tanto, que existen varias herramientas en el propio Google Play para saber si una aplicación hace uso de este sistema de publicidad.

Google decidió retirar todas las aplicaciones que las incluyeran, y se dio de plazo hasta final de septiembre de 2013. Hoy siguen existiendo en Google Play apps anteriores a esa fecha que lo contenían, todavía disponibles. Igualmente, no resulta complicado encontrar apps recientes que incorporan esta fórmula de publicidad agresiva.

Patente "antipiratería"

Recientemente, Google desveló una patente que permitía saber si una aplicación "se parecía" a otra. En ella, aunque no se habla explícitamente de Google Play, se observa claramente cómo está destinada a evitar los clones en este market. Comprueba una serie de parámetros de apps que ya tiene registradas y se compara si un nuevo programa se "parece demasiado" a través de una puntuación que evalúa su similitud. Este movimiento está claramente destinado a evitar los "reempaquetamientos" que se hicieron populares en Google Play hace dos años: un atacante tomaba una app famosa, le incluía publicidad o malware, y la volvía a subir a Google Play. 

Retirada de aplicaciones

Google Play se está "limpiando a sí mismo" continuamente. Se eliminan actualmente de su market una media de entre 1000 a 1500 apps al día.  Dependiendo del día se puede llegar a las 3000. Las apps desaparecen porque las retiran los propios desarrolladores o porque Google detecta que alguna app está violando alguna regla establecida en su mercado. También porque suspenda cuentas de desarrolladores completas y con él se vayan todos sus programas. Sin embargo, el número de apps alojadas no para de crecer.

Imagen de app retirada en Google Play

Si atendemos a cuánto tiempo tarda Google en retirar algunas aplicaciones. Podemos observar, a grandes rasgos, tres "franjas" de actuación.
  • Entre 24 y 40 horas. Las aplicaciones más "llamativas" suelen mantenerse en Google Play entre 24 y 40 horas. Hace algunos meses, en Eleven Paths ya hablamos sobre un AdBlock Plus falso en Google Play. No era el primero, ni fue el último, pero llamó la atención el hecho de colar una copia exacta de un programa prohibido por la propia Google. El programa estuvo online entre 30 y 40 horas. Y luego fue sustituido por otro. Después, el atacante siguió actuando, subiendo a Google Play aplicaciones falsas y adware, pero no volvió a usar AdBlock como reclamo.
  • Más de 48 horas. Este es el tiempo que "aguantan" las aplicaciones menos llamativas, que "disimulan" ser malware no usando ni nombres ni imágenes exactas. Varios WhatsApp falsos durante final de 2013 pasaron más de 5 días online. Otros fakes populares como el juego Clumsy Ninja (disponible oficialmente para Android desde el 15 de abril) podían pasar entre 3 y 4 días online, con un gran número de descargas.

    Clumsy Ninja falso que contenía adware

  • Más de una semana. Otros fakes menos llamativos pueden durar mucho más tiempo en Google Play. Es el caso de este fake del juego Taxi Driver 2, se mantuvo hasta cinco meses online. Se trata de un programa "reempaquetado" con publicidad no tan agresiva como AirPush.
Este fake (a la derecha) consiguió mantenerse en Google Play durante 5 meses

Cómo se usa la aleatoriedad en la seguridad

martes, 15 de abril de 2014

La aleatoriedad es un factor importante en muchos elementos de la informática, sobre todo a la hora de generar claves criptográficas seguras para protocolos criptográficos. Un elemento criptográfico generado a partir de una semilla que no sea suficientemente aleatoria, puede convertirse en un blanco fácil para un criptoanálisis por comparación de frecuencias, por ejemplo. ¿Cómo se consigue aleatoriedad en un sistema?

Se han dado casos en los que, por diferentes razones, se han utilizado generadores vulnerables en diferentes plataformas. Fueron importantes problemas derivados de un mal uso de la aleatoriedad, que tuvieron graves consecuencias.

Malas experiencias
Mejor entropía, mejor seguridad

¿Qué significa que algo sea aleatorio? En teoría, que no hay forma de predecirlo. Pensando en números, es aleatorio el que no hay forma de averiguar su valor hasta que se genera. Algo parecido a la paradoja del gato de Schrödinger. Todos los sistemas operativos necesitan generar números aleatorios para diversos usos pero, generar aleatoriedad en algo tan determinista por definición como un ordenador, no es trivial.

Y este es uno de los problemas de los RNG (Random Number Generator), que en realidad son PRNG (Pseudo Random Number Generator) porque es imposible conseguir una aleatoriedad del 100%. El sistema debe conformarse con acumular cierta cantidad de entropía para poder simular la creación de algo aleatorio, aun sufriendo una componente determinista. Veamos esto con más detalle: La entropía (en este contexto) no es más que bytes de aleatoriedad añadidos de algunas fuentes pseudoaleatorias, como por ejemplo: drivers de dispositivos, algunos elementos en la secuencia de arranque de la máquina, audio o vídeo capturado desde el micrófono/cámara, movimientos del ratón, tiempo entre presionar una tecla u otra en el teclado... Existen otras formas de añadir más bytes pseudoaleatorios, por ejemplo con dispositivos que, midiendo el ruido que se genera en el salto de electrones en una unión PN, añaden mucha entropía al sistema. ¿Dónde se añade toda esta entropía y qué se hace con ella? Esto varía entre sistemas operativos, aunque muchos se basan en la implementación que usa el kernel de Linux, que funciona más o menos así:

/dev/random y /dev/urandom

/dev/random y /dev/urandom son dos archivos especiales en el Kernel de Linux cuya función es mantener una fuente de entropía (como una especie de almacén) que consigue de diferentes fuentes (como las mencionadas anteriormente). Desde esa fuente selecciona algunos bytes de entropía y genera un número aleatorio cuando se le llama. No se suele hacer una llamada directa de sistema a /dev/random y a /dev/urandom en busca de números aleatorios, sino que se consiguen una serie de bytes de cualquiera de las dos fuentes y se usan como semillas para métodos/funciones implementadas en el programa que las necesite, a modo de PRNG. Cada programa podrá tener su PRNG. Veámoslo con un pequeño diagrama:

Esquema básico de funcionamiento de /dev/random y /dev/urandom
En él se observa cómo se "rellenan" (de forma simplificada) /dev/random y /dev/urandom. Del colector de entropía (de las fuentes que hemos mencionado antes) se estima la cantidad útil y se suma al contador de entropía. A esta entropía se le quita parte del bias (eliminación de muestras no válidas por diversas razones)  y después de pasar por el generador de números pseudoaleatorios es añadido a la fuente de aleatoriedad.

La gran diferencia entre los dos es la comprobación de entropía: mientras una petición a /dev/urandom devolverá un valor aunque no quede mucha entropía en la fuente, /dev/random comprobará antes si la cantidad de entropía en el sistema es suficiente para llegar al mínimo especificado y bloqueará la petición hasta que ese mínimo se satisfaga, momento en el que se restará del contador de entropia.

Aquí podemos ver el resultado de pedir datos constantemente a /dev/random. Se puede observar que se genera muy poca información. Tras el primer "parón", se comienza a mover el ratón del sistema. Esto genera la entropía necesaria para que el proceso siga adelante.

Volcado directo de /dev/random

Por el contrario, en la siguiente animación, se comprueba que /dev/urandom devuelve tanto como se le pida, sin bloqueos, puesto que no espera a que la entropía sea suficiente.

Volcado directo de /dev/urandom
.
Esta diferencia ha llevado a problemas y discusiones a la hora de decidir cuál de los dos archivos usar para la generación de números pseudoaleatorios. En realidad, se resume en que:

  • /dev/random ofrece números con aleatoriedad “de mayor calidad”, pero el bloqueo puede ser un problema si se encuentra bajo gran demanda.
  • /dev/urandom ofrece números con aleatoriedad "menor" pero sin bloqueos ni "esperas". 

Existen muchos puntos de vista al respecto sobre cuál usar para qué, pero está relativamente establecido que para generar claves criptográficas que vayan a tener una larga duración, como las usadas en SSH o SSL se debe usar /dev/random. Para prácticamente todos los demás usos, es más rápido y menos "arriesgado" utilizar /dev/urandom.

Juan Luis Sanz
juanluis.sanz@11paths.com

Heartbleed plugin, ready for FaasT

jueves, 10 de abril de 2014

There is a lot of good information about Hearbleed out there, there is little more to add. It is a extremely serious vulnerability, that has shaken the internet from the bottom up. Known as HeartbleedCVE-2014-0160, affects different versions of OpenSSL, from 1.0.1 to 1.0.1f and 1.0.2-beta1. It is fixed in 1.0.1g version.

Although media talked about 66% of affected sites, actually that is the figure corresponding to Apache and nginx market. Not all of them will use OpenSSL and, not all of them using it would be vulnerable. The problem has already been fixed in our Latch servers. By the way, we have renewed our certificates for the API connection. If you as a costumers were doing a certificate check on your side, you must update it with the new ones released yesterday

What can happen to me?

If a vulnerable version of OpenSSL is used, potentially, any user could be able to access an OpenSSL memory chunk. This means that, whatever is in memory in that moment, may be extracted by an attacker in a "clean", easy and remote way. In other words, if this extracted memory chunk contains users, passwords or session cookies or even the private key for that server (something that depends on probability and on "brute force")... this information would be exposed. Since an attacker may connect as many times as necessary, it seems serious indeed. So, the one attacked is not only the server, but its users, accounts, etc. Even depending on how SSL is configured, conversations between server and client could be retrospectively decrypted.

There are lots of scripts with proof of concepts that allow to, with just a click, attack vulnerable servers and, as a collateral effect, its users.

FaasT and Heartbleed

The Faast team has been getting with it during the last two days to adapt and create the code that checks if webs are indeed vulnerable. We already have this feature in our tool, as a plugin. FaasT tests the vulnerability with any OpenSSL used, even if its version claims to be safe.


HeartBleed real time detection, shown in FaasT vulnerabilities list

Faast features includes a way to show, as a picture, the evidence of a vulnerability exploited in a target. The evidence is shown both in the scanning report (in PDF) and the web interface.


Example of an evidence with FaasT

Ya está disponible el plugin de Heartbleed para FaasT

Poco podemos aportar sobre este problema que no se haya dicho ya. Una vulnerabilidad gravísima por muchas razones y que agita algunos cimientos en Internet. Conocida como Heartbleed, CVE-2014-0160, afecta a distintas versiones de OpenSSL, desde la 1.0.1 hasta la 1.0.1f y 1.0.2-beta1. A partir de la versión 1.0.1g se corrige la vulnerabilidad.

Aunque en un principio los medios hablaron del 66% de sitios afectados, en realidad esa cifra corresponde a la cuota de uso de Apache y nginx, que entre ellos pueden (o no) usar OpenSSL y de entre ellos, a su vez pueden (o no) ser vulnerables. En futuras entradas esperamos hablar en detalle sobre la vulnerabilidad, y algunas curiosidades y repercusiones. Ya hemos corregido el problema en nuestros propios servidores de Latch. Por cierto, hemos renovado los certificados de nuestra API. Recomendamos por tanto a los clientes que, si realizan una comprobación del certificado durante sus consultas, descarguen el nuevo certificado y adapten sus sistemas.

¿Qué me pueden hacer?

Si se utiliza una versión vulnerable de OpenSSL en un sitio web, potencialmente cualquier usuario podrá acceder a una porción de memoria del proceso OpenSSL. Esto significa que lo que haya en ese instante en la memoria puede ser extraído por un atacante de manera "limpia", fácil y remota. En otras palabras: si en esa porción de memoria que se extrae, se encuentran usuarios y contraseñas, cookies de sesión, o incluso la clave privada del certificado (algo que depende de la probabilidad y de cuántas veces se realice la petición)... esta información quedará expuesta. Dado que se pueden realizar tantas peticiones como sea necesario, sí que parece grave. Por tanto el comprometido no es solo el servidor, sino sus usuarios, sus cuentas, etc. Incluso, dependiendo de cómo esté configurado SSL, podrían descifrarse conversaciones  cifradas retrospectivamente.

Existen ya numerosos scripts y pruebas de concepto que permiten, con un solo clic, atacar a los servidores vulnerables... y como efecto colateral, a sus usuarios.

FaasT y el Heartbleed

El equipo de Faast se ha puesto manos a la obra para adaptar y crear el código que compruebe si realmente los sitios web de los clientes son vulnerables a este grave problema. Ya se dispone de esta funcionalidad en la herramienta, en forma de plugin. Es importante que, si se utiliza OpenSSL en el servidor, se compruebe si se es vulnerable.

Detección en tiempo real de HeartBleed, en la lista de vulnerabildiades de FaasT

Faast dispone de una característica que permite mostrar, en forma de imagen, la evidencia por la que se ha detectado que efectivamente, la vulnerabilidad es aprovechable en el servidor objetivo. Esta evidencia se muestra en el informe del escaneo (en PDF), pero además se puede ver desde la interfaz web de usuario.

Ejemplo de evidencia generado por FaasT

How to implement Oauth protocol in Powershell (an example with Latch)

miércoles, 9 de abril de 2014


Latch already counts with lots of SDKs and plugins, so you can implement it with different languages or use it with your favorite CMS. There is an "unofficial" bash implementation, even. But you may want to experiment with Latch and some Powershell scripting. Since Latch uses some kind of Oauth technique to authenticate, you may use this code to implement any other Oauth protocol with Powershell, with minor changes to this code.

Different SDKs and plugins developed so far

The best way to deal with this is to create a Powershell module that will export some functions. Creating a module is easy. Just use your editor of choice and write down the functions you need. You will need a Latch account, remember this is just as easy as:
  • Register for free here to get a Latch account in a couple of minutes. Register as a developer.
  • Create your account so you get your Secret and AppId.
  • Download the app for your smartphone: It is available for Android, iOS, Windows Phone and Firefox OS.
Coding

We will create some funcions so we can interact with the official API. First of all, the constants:

Set-Variable API_HOST -option Constant -value "https://latch.elevenpaths.com";
Set-Variable API_CHECK_STATUS_URL -option Constant -value "/api/0.6/status";
Set-Variable API_PAIR_URL -option Constant -value "/api/0.6/pair";
Set-Variable API_UNPAIR_URL -option Constant -value "/api/0.6/unpair";

This will be the code function for the other ones. It will get an URL, the AppId and the Secret. Will return the result (code is simplified):

function AuthenticationHeaders{
    param(
        [string] $url,
        [string] $applicationId,
        [string] $secretkey
         )

   $requestSignature="GET`n"

   $date = Get-Date -format u
   $date = $date.Substring(0,$date.Length-1)

   $requestSignature+=$date+"`n`n"+$url
   $sha = new-object System.Security.Cryptography.HMACSHA1
   $sha.Key = [Text.Encoding]::ASCII.GetBytes($secretkey)
   $seedBytes = [Text.Encoding]::ASCII.GetBytes($requestSignature)
   $digest = $sha.ComputeHash($seedBytes)
   $base64Encoded = [Convert]::Tobase64String($digest)
   $wc = New-Object system.net.webclient
   $wc.Headers.Add("Authorization","11PATHS " + "$($applicationId) $($base64Encoded)")
   $wc.Headers.Add("X-11Paths-Date", $date)
   Try 
   {
     $result = $wc.DownloadString($API_HOST+$url)
   }
   Catch
   {
     $ErrorMessage = $_.Exception.Message
     $FailedItem = $_.Exception.ItemName
     Break
 }
   return $result
}


Now you have the basics, the functionality is easier to achieve. For example, pairing an account would be just this:

function Pair{
   param(
         $applicationId,
         $secretkey,
         $pairingCode
         )

   $url = "$($API_PAIR_URL)/$($pairingCode)"

   $result = AuthenticationHeaders $url $applicationId $secretkey
   return $result
}

That will just basically call AuthenticationHeaders with the right parameters.

To check the status of the account (one of the most important features) just use this, using again the main AuthenticationHeaders function.

function Status{
   param(
         $applicationId,
         $secretkey,
         $accountID
         )

   $url = "$($API_CHECK_STATUS_URL)/$($accountID)"

   $result = AuthenticationHeaders $url $applicationId $secretkey
   return $result
}

For unpairing:

function UnPair{

   param(
         $applicationId,
         $secretkey,
         $accountID
         )

   $url = "$($API_UNPAIR_URL)/$($accountID)"

   $result = AuthenticationHeaders $url $applicationId $secretkey
   return $result
}

How to use it

There is much more to do and functions to implement, that are left as an exercise to the reader. To use this code, insert a line in the module with the functions you want to export, like:

Export-ModuleMember -Function Pair,UnPair,Status

Now, you can install this module, (just copying it to %UserProfile%\Documents\WindowsPowerShell\Modules, for example) and use it like this,. If you named it Latch.ps1, it would be, for example:

$l = import-module Latch -ascustomobject
$applicationId="bqwRxYXXXXXXX"
$secretkey="6O6zi6PDPnLzfVZcXXXXXXXXXXXXXXX"
$accountID="543ac56903aee2bc7fa40c88ed274e1XXXXXXXXXXXXXXX"

$l.Pair($applicationId,$secretkey,$args[0])
$l.Status($applicationId,$secretkey,$accountID)
$l.UnPair($applicationId,$secretkey,$accountID)

This commands will return a JSON you can parse, just like the specifications in https://latch.elevenpaths.com suggest.

An example of using this scripts for pairing, getting the status and unparing
For another approach to this problem, the SDK for powershell may be used, that will be available soon.

El negocio de las "FakeApps" y el malware en Google Play (V): Limpieza automática

lunes, 7 de abril de 2014

Seguimos observando las apps falsas en Google Play. En esta entrada estudiaremos qué estrategias sigue Google Play para limpiar su store e intentar mitigar el problema. ¿Qué herramientas utiliza? ¿Cuánto tarda en retirar apps? ¿Cuántas retira?

Los esfuerzos de limpieza: Bouncer

En febrero de 2012, Google lanza Bouncer. Se trataba de una especie de filtro (sandbox) por la que pasarían las apps antes de ser publicadas. Pretendía, por un lado, detectar y eliminar las amenazas antes de subirlas al repositorio. Por otro, estudiar a los desarrolladores y denegar el acceso a posibles defraudadores. Aunque se trataba de una buena medida, parece que no ha conseguido completamente su objetivo por varias razones.

¿Han subido las cifras?

El malware sigue siendo un problema en Google Play. Para algunas compañías, incluso ha empeorado. Según RiskIQ, en 2011 existían 11.000 apps en Google Play que contenían malware capaz de robar información o hacer fraude. En 2013, se eleva a 42.000. Esto suena muy escandaloso, pero el número de apps almacenadas ha subido también considerablemente, por tanto es mejor acudir a  los términos relativos (que no aparecen en los titulares). Esto supone que según RiskIQ en Google Play había un 2.7% de apps maliciosas en 2011,  9.2% en 2012 y 12.7% en 2013. 

¿Son estos datos precisos o se exageran porque RiskIQ vende un producto que intenta luchar precisamente contra ese problema? No podemos estar al 100% seguros. Por ejemplo, no queda claro por qué en el informe se habla de 42.000 apps maliciosas y que esto supone un 12.7% de Google Play. Si es así, hablaríamos de poco más de 332.000 aplicaciones, cuando existen muchas (muchísimas) más apps en esa Store. También puede incluso que el dato sea peor, debido a (como siempre) el problema de clasificar el malware. ¿Se le escapa malware? Depende de sus técnicas. En concreto RiskIQ parece que huye de firmas, y que analiza el comportamiento directamente en el tráfico, con un sistema que emula usuarios reales. En principio no parece una mala aproximación. También especifica qué es malware para ellos. Literalmente dicen que "RiskIQ solo cuenta apps de Android en Google Play como maliciosas si son o contienen spyware y troyanos SMS que":

  • Recojan coordenadas GPS, lista de contactos, emails, etc. par terceros. 
  • Envíen mensajes premium.
  • Suscriban el teléfono a servicios premium.
  • Graben conversaciones y las envíen a atacantes.
  • Permitan tomar el control del teléfono infectado.
  • Descarguen otro malware a los teléfonos infectados.

Quizás el primer punto no quede claro. ¿Con solo recoger coordenadas GPS ya se considera malware? Entonces las cifras podrían estar muy distorsionadas.

RiskIQ pone la guinda añadiendo que además de existir más malware, es retirado más lentamente del Store. En 2011 se retiraban un 60% de las apps maliciosas, en 2012 un 40% y en 2013 un 23%. Aunque este dato requiere conocer cuánto tiempo de margen se da a Google Play para que retire una aplicación, y eso tampoco queda claro.


App retirada en Google Play

Bouncer ha sido eludido en varias ocasiones


Una sandbox, por simple diseño del programa, puede no detener malware.  Por ejemplo, unos meses después de su lanzamiento, en junio de 2012, Jon Oberheide y Charlie Miller descubrieron que Bounce utiliza un entorno virtual QEMU y que todas las solicitudes de Google procedían de un bloque de IPs específico. Los investigadores crearon y enviaron aplicaciones falsas a Google Play que se dedicaron a registrar los procesos del sistema y lanzar una conexión inversa a sus propios servidores cuando eran ejecutadas en Bouncer. Así demostraron varios puntos débiles, que pueden ser aprovechados fácilmente por los desarrolladores de código malicioso implementando aplicaciones que se comporten como legítimas cuando se detecten corriendo en ese entorno virtual específico.

Luis Delgado, como prueba de concepto, también fue capaz de subir una app con capacidades de control remoto a principios de 2012, disfrazada de programa que solo necesitaba acceso a la red.

Bloxor, creada en 2012 como prueba de concepto.
Trustwave explicó también en la conferencia de seguridad Black Hat 2012 en Las Vegas que es posible eludir el sistema Bouncer con una aplicación maliciosa, pero con otros métodos. Nicolas Percoco y Sean Schulte desarrollaron SMS Bloxor, una aplicación para bloquear los mensajes de texto procedentes de determinados números de teléfono... pero que además robaba datos personales tales como fotos, mensajes de texto, contactos, registros de llamadas, e incluso podía realizar ataques de denegación de servicio. Para conseguirlo, reprimían el comportamiento malicioso de la aplicación cada vez que detectaba que estaba siendo analizada por Bouncer. Además, idearon un puente JavaScript, una solución legítima que permitía a los desarrolladores añadir nuevas características maliciosas de forma remota a aplicaciones que ya habían sido aceptadas. Mantuvieron la app en Google Play durante semanas, cada vez añadiendo más comportamiento malicioso. Para evitar que fuese descargada, se puso a un precio desorbitado.

El problema de eludir las sandbox no es nuevo ni fácil de solucionar. Las casas antivirus desde siempre se han enfrentado a elusiones de sistemas de sandbox (las que utilizan para  la clasificación rápida y automática de malware) y al comportamiento de los programas como malware "en diferido", tras pasar por la sandbox como legítimos. Y aun hoy, siguen luchando contra estas técnicas que los atacantes ponen habitualmente en práctica.

Muchas de estas técnicas, actualmente ya no son posibles tal y como fueron descubiertas, gracias a mejoras introducidas en el sistema, pero no por ello imposibles de conseguir.

Atacantes reincidentes

No es del todo cierto que a los atacantes se les deniegue el acceso y se les suspenda la cuenta cuando suben apps fraudulentas y estas son detectadas. Hemos visto cómo Google Play retiraba apps de un developer fraudulento (con infracciones graves), sin retirarle la cuenta. El último ejemplo es bastante reciente con el malware que minaba criptomonedas.

En la próxima entrega incidiremos sobre cuánto tardan las apps en ser retiradas y en otros métodos de limpieza.

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

Curiosidades sobre el malware para Android que mina Litecoins

miércoles, 2 de abril de 2014

Hace ya algunos años que se intuyó lo que ocurriría en los ordenadores de sobremesa (y no solo en los PC): con la llegada del dinero (y las carteras) virtuales, el malware comenzaría a robarlo. Como no todos disponen de cartera, también aprovecharían la capacidad de cómputo para "minar" moneda. Y el paso natural es que el malware saltara al teléfono para minar bitcoins. Si bien ya existían muestras aisladas fuera del market oficial, ahora se han encontrado apps de este tipo en Google Play.

Qué se ha encontrado

Ya se conocían ciertos programas que, disfrazados bajo apps con otras supuestas utilidades, contenían código para minar Bitcoin, Litecoin, y Dogecoin. Lo cierto es que existen incluso apps legítimas para minar desde el teléfono. Los atacantes habían reempaquetado ciertas apps e introducido el código en su interior. Descargaban un fichero de configuración y minaban en segundo plano. Pero, hasta ahora, fuera de Google Play.

Una de las apps encontradas que minaban Litecoins
Trend Micro ha encontrado ahora otros programas en Google Play. Estas apps minaban solo Litecoins, y se activaban cuando el teléfono estaba cargando para no agotar tan rápido la batería. Trend Micro dice que el programa ha sido descargado por millones de usuarios y de ahí deduce que todos están infectados. No podemos saber si esto es del todo cierto. Por nuestra investigación, creemos que la aplicación no siempre contuvo ese código, sino que se introdujo más tarde. Por tanto no todas las descargas tienen que corresponder a la versión "contaminada". Aunque sí es cierto que se publicaron varias versiones y que, si no aumentaron los permisos, se podía haber actualizado de forma automática con el código malicioso. Por ejemplo, la app se llamaba en un principio "Songs" (y hacía lo que prometía) pero luego pasó a llamarse "Indian songs". Creemos que en algún momento introdujo el código.

Así se veía la app el 26 de marzo

Así se veía la app el 14 de marzo
De hecho, hemos encontrado versiones anteriores que no contienen el código minado. Al tratarse de dos aplicaciones creadas por "aparentemente" dos desarrolladores diferentes, podría también tratarse de un robo de cuentas en Google Play. Incluso, inexplicablemente, Google Play, aunque borró las apps contaminadas, mantiene otra aplicación del mismo programador (Da Xpert) todavía activa (aunque solo en algunos países).

App que se mantiene en Google Play, del mismo desarrollador
Cómo funcionaban y algunas curiosidades

El código era claro. Socialtokenmobile.android.miner contenía las instrucciones necesarias para minar y comunicarse con el pool. Las aplicaciones se mantuvieron al menos un mes en Google Play, aunque ya hemos mencionado que quizás no siempre infectadas. Fueron retiradas después de que Trend Micro las detectara. Los usuarios no notaron nada en ellas, ni siquiera se refleja en los comentarios, excepto cuando ya era tarde.

Código incrustado en las apps para minar litecoins

Según nuestras investigaciones, el atacante continúa subiendo aplicaciones a Google Play y mantiene al menos 25 activas bajo diferentes cuentas. Por ahora, hemos comprobado que ninguna contiene código para minar Litecoins, pero sí que, en cualquier momento y como ha hecho con estas, podría actualizarlas de forma transparente siempre que no añada permisos a la nueva versión. En cualquier caso, no sabemos el éxito de la operación. Quizás se trate de un caso anecdótico.

¿Tiene sentido minar en un teléfono?

Quizás sí. Litecoin dispone de programas específicos para Blackberry y Android. Aunque basada en el protocolo de Bitcoin, ha sido diseñada para no necesitar tanto hardware para minar. Litecoin puede minar ("crear monedas") de manera más rápida, con dos minutos de promedio frente a los 10 de bitcoin. También ha sido diseñada para que existan 84 millones de unidades, en vez de 21 como Bitcoin. Litecoin se considera más adecuada para las pequeñas transacciones diarias y habituales, mientras que Bitcoin tiene su mercado en las transacciones más voluminosas. Un Litecoin vale actualmente unos 13 dólares y existen 27 millones circulando.

Pero , ¿qué es minar?

A grandes rasgos, minar es validar transacciones, y a los usuarios que dedican sus recursos a validar, se les recompensa con monedas. Las transacciones criptográficas con moneda virtual necesitan de potentes cálculos para poder validarlas, y las realizan de forma horizontal los usuarios (no existe la figura de un banco ni nada parecido). Los usuarios, para validar transacciones y comprobar que no se hacen trampas utilizando el mismo material cirptográfico, (o sea, la misma moneda dos veces) deben validar intensamente y entre varias partes las cadenas utilizadas (el sistema está basados en criptografía simétrica y asimétrica). Para motivarlos, ese tiempo de validación (gastando recursos propios) se paga. Así que minar consiste en tomar un "pool" de un servidor (compartido, normalmente) de transacciones a validar. En el caso de los bitcoins, por cada bloque de transacciones se recibían 50 bitcoins. Ahora son ya 25, y dentro de unos años, 12.5. De ahí que cada vez cueste "más" minar.

Sergio de los Santos
ssantos@11paths.com