La tarjeta de coordenadas: una muerte anunciada

viernes, 28 de noviembre de 2014

Hoy en día, las entidades bancarias que ofrecen sus productos y servicios por internet usan diferentes técnicas de autenticación (para identificar a sus clientes) y autorización (para llevar a cabo distintas operaciones). Ya quedaron atrás modelos de autenticación de un único factor, dando paso al proceso de autenticación fuerte, que requiere de la combinación de dos o más elementos.

Estos elementos se suelen categorizar como:
  • Conocimiento: Algo que el usuario conoce, como una contraseña o un código PIN.
  • Posesión: Algo que el usuario tiene, como un token, smartcard, o teléfono móvil/SIM.
  • Inherencia: Algo que el usuario es, o sea, una característica biométrica como la huella digital.

Habitualmente el sector bancario utiliza un modelo de autenticación basado en riesgo, utilizando generalmente dos de estos niveles para permitir el acceso a sus servicios online:



Lamentablemente, la falta de usabilidad de algunos métodos de autenticación provoca malas prácticas, y bajo esas circunstancias, paradójicamente el aplicar mayor seguridad resulta ser contraproducente (por ejemplo, cuando por no disponer de la tarjeta de coordenadas del banco cuando se necesita, el usuario opta por escanearla o fotocopiarla).

Es curioso, pero el concepto de autenticación fuerte no ha tenido una definición oficial hasta que el European Forum on the Security of Retail Payments, SecuRe Pay, publicó en enero de 2013 una guía exhaustiva con recomendaciones para la lucha y prevención del fraude en medios de pago. En ella se definían, entre otros, los criterios mínimos que deben cumplirse en un proceso de autenticación fuerte. Su implementación debe llevarse a cabo antes del 1 de febrero de 2015, según indicaciones del Banco Central Europeo .

El Banco central Europeo resalta la necesidad de que el inicio de los pagos en internet así como el acceso a datos relativos al pago sean protegidos con autenticación fuerte. Analicemos si los mecanismos más habituales implementados por la banca y medios de pago cumplen los criterios mínimos establecidos:



A la vista de la gráfica comparativa anterior, podemos concluir que la tarjeta de coordenadas como elemento que prueba la autenticidad del usuario ha quedado obsoleta, y sin embargo, es uno de los más extendidos en la banca online. Teniendo en cuenta las indicaciones del Banco Central Europeo al respecto, las Entidades Financieras que actualmente trabajen con tarjeta de coordenadas deberán evolucionar a otros modelos.

¿Cuál es la mejor alternativa en este caso?


De entre las diferentes soluciones de OTP, el token software tiene mejor ratio coste-beneficio:

  • Cumple con las indicaciones del BCE.
  • Reduce el coste eliminando el pago de SMS o la necesidad de la compra de HW (tokens) así como de su mantenimiento
  • Tiene en cuenta la usabilidad, aprovechando la generalización del uso de los smartphones conectados a internet
  • Acelera la implementación al eliminar la necesidad de desplegar elementos físicos (tokens e infraestructura)
  • Ofrece mejores características de seguridad frente al SMS gracias a la implementación criptográfica y la posible utilización de contenedores seguros de los smartphones


Latch como alternativa a las tarjetas de coordenadas

Siguiendo con el análisis, y centrados ya en el OTP software como la mejor alternativa para sustituir a la tarjeta de coordenadas, la siguiente cuestión que se nos plantea es ¿qué solución OTP software debería escoger?

Para responder a esta pregunta proponemos hacer una comparativa de los diferentes tipos de soluciones OTP software con los ámbitos que el BCE identifica como claves a la hora de establecer mecanismos de autenticación fuerte:




Como vemos, Latch nos ofrece no sólo las capacidades de un segundo factor de autenticación token push sino que al mismo tiempo enriquece la seguridad actuando en los principales ámbitos destacados como clave por el BCE:

A) Latch como autenticación fuerte:
  • Latch no sólo limita la exposición de los procesos de autenticación, sino que además provee de protección con autenticación fuerte el inicio de cualquier proceso considerado crítico gracias al segundo factor de autenticación que incorpora Latch (token software).
  • Este token es generado por el servicio Latch, y enviado sobre SSL a la aplicación del usuario y banco o entidad financiera, haciendo uso así de un canal independiente (out-of-band). El token es recibido por el usuario a través de su aplicación móvil (token push), disponiendo así de un código de un solo uso de 6 caracteres cuya validez temporal será la definida por el banco (por ejemplo, 60 segundos) 

B) Latch para fijar límites temporales a la validez de la autenticación:

  • El servicio Latch ofrece también la posibilidad de fijar límites temporales al proceso de autorización, programando por ejemplo el bloqueo automático de ciertas operaciones transcurrido un tiempo desde su acceso, o bien fijando una franja horaria (por ejemplo, por la noche).

C) Latch para la detección temprana:

  • Las entidades financieras y medios de pago han sido pioneras en el uso de herramientas de análisis de fraude, trabajando en la identificación de patrones fraudulentos y en el análisis del contexto para identificar riesgos. Sin embargo, la incorporación de Latch como complemento a estos sistemas permite aportar una perspectiva única a la hora de llevar a cabo una detección temprana en los casos de suplantación de identidad como resultado del robo y uso de credenciales:
    • Detección: el usuario será alertado a través de la aplicación móvil en el proceso de autenticación/autorización en el que el banco haya implementado Latch, ya sea él quien haya iniciado el proceso o bien un tercero intentando suplantar su identidad.
    • Prevención: Latch posibilita el bloqueo de las cuentas digitales del usuario cuando no las esté utilizando, evitando así usos no autorizados.
    • Bloqueo: la aplicación móvil notificará al usuario de cualquier intento de acceso a los sistemas del banco utilizando su identidad, permitiendo así al banco realizar un bloqueo temprano en los casos en los que exista un uso fraudulento de las credenciales de sus usuarios.

D) Latch para la protección en múltiples capas:
  • La filosofía de Latch es simple: si mantenemos bloqueadas nuestras cuentas o servicios digitales mientras no los utilizamos reduciremos el riego de un uso fraudulento o no autorizado de los mismos. Por ejemplo, podríamos bloquear el inicio de sesión a la banca online, los pagos con tarjetas de crédito, o el proceso de autorización de transferencias bancarias (cualquier operación sobre la cual queramos aplicar este control). Latch ofrece por lo tanto una capa adicional para mejorar la seguridad global reduciendo el tiempo de exposición de las operaciones:
    • No supone una alternativa a los procesos y sistemas actuales de autorización que tenga el banco, y es totalmente independiente del esquema de autenticación que este emplee.
    • No necesita conocer información alguna sobre los usuarios del banco: durante el proceso de autenticación del usuario se utilizan las API y los SDKs de Latch para consultar el estado actual de la cuenta del usuario pero no se intercambia ninguna información sobre el usuario del servicio.
E) Latch como herramienta que ofrece control al usuario sobre su seguridad
  • Al proporcionar a los usuarios el control sobre sus servicios (pagos con tarjetas o transferencias bancarias), existe una clara mejora en su percepción de la seguridad:
    • Latch les informará de los intentos de acceso utilizando su identidad digital
    • Los propios usuarios podrán definir la disponibilidad de sus servicios, por ejemplo indicando que en ciertos intervalos temporales (como por ejemplo por la noche) el acceso debe estar bloqueado.

Por concluir, vemos como la sustitución de la tarjeta de coordenadas por el token de Latch ofrece múltiples beneficios:

  • Cumplimiento de normativa: ofreciendo un modelo de autenticación fuerte que cumple la nueva normativa del BCE.
  • Control del gasto: sin ser necesario realizar inversión en infraestructura y permitiendo el control del gasto desde el principio (licenciamiento por usuarios activos).
  • Concienciación: se mejora la experiencia de usuario a la vez que se le hace partícipe de la seguridad.
  • Seguridad adicional: además de autenticación fuerte, Latch ofrece una capa de seguridad adicional, monitorización ágil e involucración del usuario.
  • Dentro del plazo límite: la implantación de Latch es rápida y sencilla, lo cual permitiría a los Bancos cumplir con la normativa del BCE dentro del plazo límite (15 de febrero de 2015).

Irene Gómez
irene.gomez@11paths.com

Shuabang botnet: BlackHat App Store Optimization (BlackASO) in Google Play

martes, 25 de noviembre de 2014

ElevenPaths has detected malicious apps in Google Play (already removed by Google), aimed at performing Shuabang techniques, or BlackASO (Black Hat App Store Optimization). These malicious apps link fake accounts with the real device of the victim, getting very "real" accounts. With these accounts, the attacker sends tasks to the victims so they download apps (although not effective on the victim's device). The victim's account remains safe, but not the data about the phone. We describe in this report the details of this interesting attack.

Shuabang

Shuabang techniques, or BlackASO (Black Hat App Store Optimization). This is a real industry in China that has been active for years. The method consists in creating an infrastructure to score or artificially inflate the number of downloads of an app so they rise up their position on the markets. This infrastructure requires fundamentally Google or iOS accounts so they can distort actions, as if they were generated by real users. This "service" is usually sold to a third party intermediary (companies) that claim to enhance and optimize positions in any market but they do not really care about the methods to achieve it.

To carry out the fraudulent scheme, the attacker needs active Google accounts associated with real devices that do not appear suspicious to Google, which would quickly eliminate them otherwise. Different techniques are used for this purpose. The most usual is to manually hire users that will create accounts in the market and rate apps they are told to. On this particular occasion, they came up with a system that starting from a set of fake Google accounts, distributes and associates them to different devices, so they take full advantage of the number of phones associated with an account. Besides, it allows sending tasks to the device so it simulates downloading apps under fake accounts. The potential of these malicious apps spotted for Shuabang is above average, since it demonstrates in-depth knowledge of the specific operation of Google's authentication protocols. Before getting into the details, let's see how Google accounts work.

How Google accounts work

When a user creates a Google account, once the username and password are provided, he has access to dozens of Google services, as a Single Sign On.

Google account working schema

The user enters the account password in the device only once. From that point on, he is registered in a Google service (for example Google Play, sending user, password, device ID...) that will return a token. This master token is stored in the device account manager (that remains associated) and will be used from then on in the device  (that remains associated to it) so the password does not have to be entered again. Other temporary tokens are derived from this master token. It is common for users to have several devices registered with the same account. This, for example, allows users to choose where to install apps. For linking or associating a device to an account, the usual process is:

Registering and associating and account with a device

  • Either creating the account from the device itself. Google prevents automatic creation of fraudulent accounts by discarding accounts created on devices that are not "real", as well as inserting a CAPTCHA.
  • Or using an existing Google account and signing in with it on the device that it is to be associated with. This process only requires entering the username and password in the phone to add a new account.
What Google does, is associating a device identifier with the account. The Android phone or device will appear as a device associated with the account on the Google Play settings panel.

This low-level registration and association protocol has been studied by the community and specially by attackers who carry out fraudulent practices. Registration and association can currently be programmed with raw calls to Google services and providing the necessary information. This process isn't officially documented, though.

This kind of botnet is a sophisticated system by which attackers use apps with minimum privileges to associate accounts created by them to real devices. Thus, attackers obtain a number of fake accounts associated with "real" phones and therefore valid for Google services, allowing them to carry out a variety of fraudulent schemes. Specifically, artificially increase app downloads or fraudulent app rating.

The attack

The attacker had a pool of 12.500 Google accounts, created with valid username and passwords, but not registered with any device. The vast majority of accounts in this database were created by the attacker, and were delivered to the victims to register them with their devices.

Brief attack scheme


Fundamentally, the attacker gets the victim to make two actions:
  • Associate accounts to devices in an automatic way so he can get tokens.
  • Use these tokens in a distributed way, so downloads may be simulated.


Real example of a response to an infected device, getting an account that will be associated to the device

The applications turn the device into a zombie that collected these fake accounts from the central server every 10 minutes and associated them with the information on the victim's phone. The "original" Google account on the victim's device remains safe and the attacker cannot access it at any time. Each account was associated with between 10 and 30 physical phones of victims. The combinations between Google accounts and associated phones are countless. The image shows an example of an attacker account associated with 18 victim devices.


Example of an account associated with different victims' devices

The attacker published more than 300 applications on Google Play throughout the month of October. They were disguised as games, jokes, wallpapers and general entertainment. Of these, approximately 100 committed the fraud by associating these fake accounts to the device's settings and identifier. The remaining 200, although harmless in their first version, were usually later updated to commit the fraud. The permissions the apps requested are:


Permissions requested by the apps infecting the users

With this attack scheme, the attacker has obtained a database of  60,000 tokens. The attack was focused on victims in Brazil, India and Russia, although it was prepared to add any other country.

The complete attack scheme is this:


General scheme of the attack

Conclusions 

Although the attacker seems to have a known ultimate goal (black ASO), he achieved several interesting milestones by developing these malicious apps:
  • He created or bought 12,567 Google accounts, most of which were automatically created. Account creation requires breaking a CAPTCHA.
  • He achieved a low level understanding of the Google registration and device to account association process. He was able to program them to work automatically. This is not officially documented and there is very little documentation about this.
  • He was able to introduce some 100 malicious apps in Google Play with apparently harmless permissions.
  • He was able to manage a task system that fully optimized the activity of the infected network by distributing download and account association tasks, etc.
  • He was able to use the victims' devices features to associate them with accounts and thus perpetrate the fraud, as if a fake user was registered in the victim's device.
  • Although the victim's account data is not affected, these malicious apps imply taking advantage of resources and violating privacy.

Although the Shuabang technique has been known and developed for some time via a variety of apps, the attackers' target is usually Google Play as an area for privileged distribution. This is the market that poses the most problems for publishing, but once they get it, and thanks to this intelligent technique described, the success for the attacker is remarkable. These malicious apps seem to be in a development phase, and it seems they were experimenting with these techniques.

A complete report in PDF format is available from here.

ElevenPaths has been able to determine how, since when and by which methods the fraud was committed and also established links between this attacker and other groups of attackers aside from gathering a series of incriminating evidence. Based on these correlations, ElevenPaths was able to find Google Play developer accounts possibly belonging to the same group of attackers.

All of which was possible thanks to the use of Path5, a product developed by ElevenPaths, which allows early detection, investigation and correlation of any type of information about Android applications, among other functionalities.This report is a real-life example of the power and effectiveness of a product such as Path5 to investigate similar cases.

Sergio de los Santos
ssantos@11paths.com

Shuabang botnet: BlackHat App Store Optimization (BlackASO) en Google Play

ElevenPaths ha detectado apps maliciosas alojadas en Google Play (que ya han sido retiradas por la propia Google), destinadas en un principio posiblemente al Shuabang, o BlackASO (Black Hat App Store Optimization). Las apps maliciosas vinculaban cuentas falsas con el dispositivo real de la víctima, consiguiendo así cuentas muy creíbles. Con estas cuentas, el atacante enviaba tareas a las víctimas para que descargasen nuevas aplicaciones (aunque no se hacían efectivas en el dispositivo de la víctima). La cuenta del usuario permanece a salvo, no así sus datos personales sobre el teléfono. Describimos en el siguiente informe los detalles del curioso ataque.

Shuabang

El Shuabang o BlackASO (Black Hat App Store Optimization) es toda una industria en China, y desarrolla su actividad desde hace años. El objetivo del Shuabang es crear una infraestructura que permita valorar o inflar artificialmente las descargas de apps para posicionar mejor los programas en los mercados. La infraestructura precisa fundamentalmente cuentas de Google o iOS con las que falsear las acciones, de manera que parezcan que provienen de usuarios reales. Este "servicio" de posicionamiento se suele vender a terceros. En general, empresas que dicen dedicarse a mejorar el posicionamiento pero que se "abstraen" de los métodos empleados para conseguirlo.

Para realizar este fraude, el atacante necesita principalmente cuentas de Google activas, asociadas a dispositivos reales, y que no parezcan sospechosas para Google, pues de lo contrario las eliminará rápidamente. Para ello, utilizan diferentes técnicas. La más habitual es la contratación manual de usuarios, que crearán cuentas en el market y valorarán las apps que se les pida. Con estas apps maliciosas, sin embargo, han ideado un sistema por el que, a partir de un conjunto de cuentas falsas, las distribuye y asocia a diferentes dispositivos, de forma que se reaprovecha y automatiza al máximo el número de teléfonos distintos asociados a una cuenta. Además, permite enviar tareas a los dispositivos para que, bajo las cuentas falsas, simulen la descarga de apps y así las posicionen más alto en los mercados. Estas apps detectadas para realizar Shuabang tienen un potencial por encima de la media, puesto que demuestran un profundo conocimiento del funcionamiento concreto de los protocolos de autenticación con Google. Antes de entrar en detalle, veamos cómo funcionan las cuentas en Google.

Cómo funcionan las cuentas en Google

Cuando un usuario crea una cuenta de Google, una vez ha introducido su usuario y contraseña, tiene acceso con ella a decenas de servicios en Google, como un Single Sign On.

Esquema de funcionamiento de cuentas de Google

El usuario introduce la contraseña de la cuenta una sola vez en el dispositivo. A partir de ahí, se da de alta en un servicio de Google (por ejemplo en Google Play, enviándole usuario, contraseña, ID de dispositivo...), que le devolverá un token. Este token maestro se almacena en el manejador de cuentas del dispositivo (que queda asociado) y será el que se utilice el resto de tiempo para que no se tenga que introducir la contraseña de nuevo. De él, se deducirán otros tokens temporales. Habitualmente, un usuario puede tener varios dispositivos registrados en una misma cuenta. De esta forma puede elegir dónde instalar apps, por ejemplo. Para asociar un dispositivo a una cuenta, el proceso habitual es:

Registro de cuenta y asociación a dispositivo habitual


  • Bien crear la cuenta desde el mismo dispositivo. Con el fin de que no se creen cuentas fraudulentas de forma automática, Google descarta las cuentas creadas sobre dispositivos que no sean "reales", además de interponer un CAPTCHA.
  • O bien utilizar una cuenta de Google ya existente y presentarse en el mismo dispositivo con el que se quiere asociar. Para este proceso, tan solo es necesario introducir el usuario y contraseña de Google existente en el teléfono o añadir una nueva cuenta.
Con esto, realmente, lo que se hará es asociar un identificador del dispositivo a la cuenta. El teléfono o dispositivo Android aparecerá como dispositivo asociado a la cuenta en el panel de configuración de Google Play.

Este protocolo de registro y asociación a bajo nivel ha sido estudiado por la comunidad y en especial por los atacantes que realizan prácticas fraudulentas. Actualmente es posible conseguir el registro y la asociación programáticamente, realizando las llamadas a los servidores de Google y proporcionándole la información necesaria. El proceso no está documentado oficialmente.

Esta especie de botnet es un sofisticado sistema por el que un atacante es capaz de, a través del malware con mínimos privilegios, asociar a dispositivos reales cuentas creadas por el propio atacante. Dispone así de un conjunto de cuentas falsas asociadas a teléfonos "reales" y por tanto, válidas de cara a los servicios de Google, lo que les permitirá cometer diferentes tipos de fraude. En concreto la descarga artificial o valoración fraudulenta de apps.

El ataque

El atacante disponía de 12.500 cuentas de Google ya creadas con usuario y contraseña, pero no registradas a ningún dispositivo. La inmensa mayoría de las cuentas en esa base de datos han sido creadas por el propio atacante, y se las proporcionaba a las víctimas infectadas para que las registrasen en su teléfono.

Esquema de ataque resumido


Fundamentalmente, lo que ha conseguido es que sus víctimas realicen dos acciones:
  • Asociar cuentas a dispositivos de forma automática y así conseguir tokens.
  • Utilizar esos tokens de forma distribuida para simular descargas.


Ejemplo real de envío de una cuenta a un dispositivo infectado con el que será asociada

La aplicaciones convierten al dispositivo en un zombi, que cada 10 minutos recoge tareas que realizar, entre ellas, recoger esas cuentas falsas del servidor central y asociarlas a los datos del teléfono de la víctima. La cuenta de Google "original" en el dispositivo de la víctima permanece a salvo y el atacante no tiene acceso a ella en ningún momento. Cada cuenta es asociada a entre 10 y 30 dispositivos físicos de las víctimas. Las combinaciones entre cuentas de Google y asociación de dispositivos son innumerables. En la imagen se muestra un ejemplo de cuenta del atacante, asociada a 18 dispositivos reales en la India de las víctimas.


Ejemplo de cuenta asociada a diferentes dispositivos de víctimas

Desde principios de octubre hasta finales del mismo mes, el atacante ha subido a Google Play más de 300 aplicaciones disfrazadas de juegos, chistes, fondos de pantalla y entretenimiento en general. De ellas, aproximadamente 100, cometían el fraude asociando esas cuentas falsas a la configuración e identificador del dispositivo. Algunas de las 200 restantes, aunque inofensivas en una primera versión, eran más tarde actualizadas para cometer el fraude. Los permisos de las apps eran:


Permisos de las apps que infectan a los usuarios

Con este esquema de asociación de cuenta y dispositivo real, el atacante se ha podido hacer con una base de datos de 60.000 tokens. El ataque se ha centrado en víctimas de Brasil, India y Rusia, aunque está preparado para añadir cualquier país.

El esquema completo de ataque era el siguiente:


Esquema general del ataque

Conclusiones 

El atacante, aunque con un fin último conocido (posicionamiento fraudulento) ha conseguido varios hitos interesantes con el desarrollo de estas apps maliciosas:
  • Ha creado o comprado 12.567 cuentas de Google. La creación de cuentas requiere romper un CAPTCHA.
  • Ha conseguido comprender a bajo nivel, cómo funciona el sistema de registro y asociación de dispositivos a cuentas, y lo ha programado para que se realice automáticamente. Esto no está documentado oficialmente y existen muy poca documentación en Internet al respecto.
  • Ha conseguido introducir alrededor de 100 apps maliciosas en Google Play, con permisos aparentemente inocuos.
  • Ha conseguido gestionar un sistema de tareas que optimiza al máximo la actividad de la red de infectados, repartiendo tareas de descarga, asociación de cuentas, etc.
  • Ha conseguido que las características de teléfonos de las víctimas sirvan para que sean asociadas a cuentas, y así poder gestionar el fraude por clic de forma inteligente, como si un usuario falso se encontrara registrado en el teléfono de la víctima.
  • Aunque los datos relativos a la cuenta de la víctima queden a salvo, esta app maliciosa supone un aprovechamiento de los recursos y una vulneración de la privacidad.
Aunque es una técnica conocida y desarrollada desde hace tiempo a través de varias apps, los atacantes tienen como objetivo Google Play, como lugar de distribución privilegiado, pero con el que más problemas se encuentran a la hora de publicar. Una vez conseguido y gracias a lo inteligente de la técnica, el éxito es notable. La app se encuentra totalmente en desarrollo en estos momentos, y da la sensación de que ha experimentado con estas técnicas. 

Un informe completo de la amenaza en formato PDF está disponible desde esta dirección.

ElevenPaths ha podido determinar cómo, desde cuándo y con qué métodos se ha cometido el fraude, además de establecer enlaces entre el atacante y otros grupos de atacantes y recopilar evidencias incriminatorias. Basadas en estas correlaciones, ElevenPaths ha podido encontrar cuentas de desarrolladores de Google Play que posiblemente pertenecen al mismo grupo de atacantes. Todo esto ha sido posible gracias a Path5, un producto desarrollado por ElevenPaths que permite realizar una detección temprana, investigación y correlación de cualquier tipo de información relativa a aplicaciones de Android, entre otras funcionalidades. Este reporte supone un ejemplo real de la potencia y efectividad de un producto como Path5 para investigar casos similares.


Sergio de los Santos
ssantos@11paths.com

Bienvenido a Latch Talks

miércoles, 19 de noviembre de 2014

Te presentamos Latch Talks, nuestros seminarios de Integración de Latch en aplicaciones web.

Si eres desarrollador de aplicaciones, analista y/o técnico de seguridad informática, estás en el lugar correcto. Para todos los que queráis conocer cómo se puede integrar la tecnología Latch dentro de vuestras aplicaciones web, hemos creado estos tres seminarios online de una hora de duración, donde os contaremos cómo utilizar los SDK de Latch dentro de los lenguajes Java, .NET y PHP.



Sigue los Latch Talks estés donde estés:

  • 25 de noviembre de 2014. De 16:00 a 17:00 horas (UTC/GMT +1): Seminario "Integrar Latch en aplicaciones Java" por Javier Espinosa.
  • 26 de noviembre de 2014. De 16:00 a 17:00 horas (UTC/GMT +1): Seminario "Integrar Latch en aplicaciones .NET" por Ioseba Palop.
  • 27 de noviembre de 2014. De 16:00 a 17:00 horas (UTC/GMT +1): Seminario "Integrar Latch en aplicaciones PHP" por Alessandro Fanio.

Para participar en los seminarios (¡son gratuitos!), es necesario registrarse a través del siguiente formulario de registro. Después de estos seminarios ya estarás listo para llevar a cabo cualquier idea que tengas para usar Latch en estos entornos y podrás participar en nuestro concurso Latch Plugins Contest. Inscríbete y gana hasta 10.000 USD, y opta a una beca de trabajo en ElevenPaths.

Cybercamp: 5,6 y 7 de diciembre en Madrid

lunes, 17 de noviembre de 2014

El próximo mes de diciembre se celebra en Madrid el Cybercamp de Incibe, en el que se reunirán expertos en seguridad informática, tanto nacionales como internacionales, para compartir sus conocimientos. Además, los asistentes podrán asistir a diversos talleres con diferentes temáticas referentes a la seguridad informática, como por ejemplo el taller de hacking ético, el taller de hacking de aplicaciones web, taller de Metasploit, de criptografía, etcétera. Pero no todo son talleres técnicos, en el Cybercamp el asistente podrá encontrarse con talleres de gestión de proyectos, muy necesarios para coordinar adecuadamente cualquier ámbito productivo.

Eleven Paths impartirá un taller sobre protección de servicios y sistemas basada en la reducción del tiempo de exposición con Latch. El taller se estructura en tres bloques fundamentales. Un primer bloque diseñado para facilitar la compresión de los conceptos sobre los que se construye la idea de Latch. Un segundo bloque, eminentemente práctico, en el que se especificarán los pasos a seguir para interactuar con la API de Latch. Y por último, un tercer bloque en el que se orientará a los participantes en la realización de sus proyectos. A continuación se describen los puntos principales de la actividad:

  • Bloque I. ¿Qué debe saber un usuario de Latch?
    • Descripción de la solución
    • Entornos de integración
  • Bloque II. ¿Qué debe saber el desarrollador?
    • API de desarrolladores
    • Integradores
  • Bloque III. Proyectos

En el taller, se podrán tomar ideas para participar en el concurso de Eleven Paths de Plugins y ganar hasta 10.000 USD en premios.

Latch es una solución propuesta por Eleven Paths para elevar el nivel de protección de un sistema informático. Permite incorporar la forma en la que el usuario decide consumir un servicio o interactuar con un sistema a los mecanismos habilitados para realizar la autenticación o autorización en dichos entornos. Pero Latch es mucho más y esto se está demostrando a medida que se aprovechan las características inherentes de las plataformas donde va siendo integrado. Una de las alternativas que se están proponiendo para realizar esta integración, es la realización de plugins. El objetivo del taller es facilitar el desarrollo de plugins para Latch y propuesta de escenarios en los que la protección de Latch sea significativa.

Chema Alonso, CEO de Eleven Paths, ofrecerá una charla en el Cybercamp, acompañado de muchos conferenciantes internacionales como Fermín J. Serna de Google y creador de EMET; Jeff Moss fundador de Defcon y BlackHat; Richard Stallman, padre del software libre; o Stefano di Paola de OWASP.


Conferenciantes en Cybercamp

El Cybercamp es gratuito, pero tiene plazas limitadas, no dejes pasar la oportunidad y apúntate al evento cuanto antes. Además, compañeros nuestros de Eleven Paths también estarán en el evento impartiendo talleres, como por ejemplo el Dr. Alfonso Muñoz, que participa con el taller de criptografía para ejecutivos, taller de ocultación de comunicaciones digitales y un workshop para doctorandos. Por otro lado, nuestro compañero Pablo González impartirá el taller de Metasploit y dará una charla en el evento.

Será un fin de semana rodeado de buen ambiente, talleres técnicos, talleres de gestión, conocimiento, buenas charlas, los mejores conferenciantes internacionales, soluciones al hackatón, y un rincón para la familia, por lo que no dudes en llevarla.

Enumeración y explotación de recursos internos mediante Javascript/AJAX (y II)

viernes, 14 de noviembre de 2014

Veamos la segunda parte de la entrada anterior en la que se describirán nuevos escenarios de explotación y un escenario de ataque. En ella, observamos que es factible identificar recursos internos en una red corporativa o doméstica si un usuario visita una página web determinada. El navegador de la víctima enviará la información detectada al atacante, típicamente vía JavaScript/AJAX. En resumen, enumeramos recursos internos desde el exterior saltando las medidas de seguridad perimetral, toda la información se fuga vía protocolo HTTP desde un usuario legítimo de una organización.

Explotación y escenario de ataque

Esta técnica tiene un gran potencial, no solo por el hecho de permitir la enumeración, sino sobre todo, por aprovechar la propia enumeración para realizar ataques de explotación desde el exterior utilizando el navegador web de la víctima que visita la página web "maliciosa". Existen muchos tipos de ataques posibles. A continuación se expone un ataque diferente al expuesto en la NoConName y que muestra la flexibilidad a la hora de atacar sistemas.

Un usuario (víctima1) que utiliza navegador web Chrome (WebRTC) actualizado en su última versión, visita una página web (atacante). Este hecho desencadena la enumeración de direcciones IP vivas y la identificación de productos vulnerables a través de la identificación de rutas conocidas:

  • Wordpress: wp-admin/images/w-logo-blue.png
  • Moodle: /theme/standardwhite/favicon.ico

Se identificará en la red un CMS (víctima2) vulnerable a una inyección SQL. El atacante utilizará a la víctima1 para inyectar el "exploit" en la víctima2 y conseguir extraer las credenciales de la base de datos al exterior. La víctima2 comunicará la información a la víctima1 y esta al atacante (otras configuraciones son posibles).

Esquema de ataque
El exploit creado es muy sencillo. Consiste en la introducción en la página web visitada de un iframe con la inyección SQL y además una etiqueta HTML concreta que se concatenara con los resultados obtenidos de la base datos. Estos datos son leídos de la tabla "test" de una base de datos MySQL, que es accesible a través de una aplicación vulnerable a SQL y que simplificará la comunicación de estos datos al exterior.

Ejemplo de exploit


Nótese que se codifica en hexadecimal la etiqueta:


Una vez ejecutada la inyección en la víctima2, la víctima1 tendrá en su iframe una etiqueta de tipo img por cada credencial (name, passwd) extraída de la base de datos. La ejecución de estas etiquetas permitirá el envío de las credenciales al atacante.


Detalle del código JavaScript del exploit


Conclusiones

La técnica de enumeración basada en el comportamiento temporal o de carga de un navegador web cuando localiza recursos, puede ser utilizada en la actualidad con gran provecho. Especialmente reseñable es su funcionamiento en cualquier navegador actual en su última versión y la posibilidad de utilizar el propio navegador web como si de una herramienta más de pentesting se tratará, identificando recursos internos y facilitando la explotación de vulnerabilidades, como puede deducirse evitando medidas de seguridad perimetral clásicas.

Hoy, el único remedio contra estos ataques es buscar mitigaciones en la configuración de los navegadores web (por defecto deshabilitadas), limitando la ejecución de código JavaScript/AJAX o definiendo políticas que limiten la acción de contenido cargado desde Internet.

Enumeración y explotación de recursos internos mediante Javascript/AJAX (I)


Dr. Alfonso Muñoz
alfonso.munoz@11paths.com
@mindcrypt

Ricardo Martín

Enumeración y explotación de recursos internos mediante Javascript/AJAX (I)

jueves, 13 de noviembre de 2014

En 2006, el investigador Jeremiah Grossman presentó en la conferencia de seguridad informática BlackHat, un estudio sobre la posibilidad de utilizar los tiempos de respuesta de un navegador web, cuando busca un recurso concreto, para obtener información privada de una red corporativa. Un recurso no deja de ser algo tan sencillo como por ejemplo una ruta que apunta a una imagen de un servidor web. Lo interesante de este ataque es que un recurso puede ser cosas tan variadas como una dirección IP, un nombre de dominio, un recurso web compartido, etc. La utilización de este tipo de recursos permite enumerar servicios y tecnologías presentes en el entorno donde se ejecute la página web especialmente modificada.

La idea es sencilla, utilizando una o más etiquetas HTML (por ejemplo una etiqueta "IMG"), en una página web modificada, se podría apuntar a un "recurso" y mediante JavaScript se podría detectar si el recurso se ha encontrado (el navegador ha recibido respuesta rápida) o no (el temporizador del navegador expira para la búsqueda de ese recurso).


Desde 2006 se han publicado diversos resultados del potencial de esta técnica con ciertas variantes, por ejemplo, con HTML5 o CSS. Por desgracia, las investigaciones publicadas carecen de la suficiente información para evaluar si estos procedimientos funcionan en entornos reales (diferentes navegadores web, diferentes sistemas operativos, redes heterogéneas, etc.) y bajo qué condiciones.

Con el objetivo de evaluar la utilidad de esta técnica presentamos un estudio en la conferencia NoConName 2014 que se celebró en Barcelona del 31 al 1 de noviembre. En ella presentamos nuestras conclusiones sobre el potencial de este tipo de técnicas, cuál es su utilidad en entornos reales y lo más importante: cómo puede ser utilizada de múltiples formas para vulnerar recursos internos de una organización o red doméstica que no son visibles desde Internet.

La investigación "Network Profiling based on HTML tags injection" realizada por el Dr. Alfonso Muñoz y Ricardo Martín muestra algunos resultados destacables.

Idea

Una víctima visita una página web vulnerable (especialmente creada o que contiene un código JavaScript añadido) con su navegador web actualizado. Este hecho provocará fuga de información interna evitando cualquier protección de seguridad perimetral.

¿Qué podemos hacer?

Identificar sistemas operativos de una red, escaneo de red, puertos, enumeración de software/hardware de red, identificación de impresoras, routers, UPS, enumeración de dominios, etc.

Etiquetas HTML útiles y navegadores web actuales

Existen diversas etiquetas HTML que pueden ser utilizadas para apuntar a los recursos deseados. Las pruebas indican que este tipo de ataques son plenamente funcionales en los navegadores web actuales. Por ejemplo, para los navegadores actuales en Windows 8.1 se puede observar que:


 Tiempos en el acceso a recursos

La mayoría de navegadores web (en función del sistema operativo donde se ejecuten) tendrán un temporizador similar, es decir, definirán un tiempo máximo de espera a que el "recurso" conteste. Este tiempo viene fijado por el timeout de la conexión TCP establecido en el sistema operativo. En el caso de Windows 8.1 será de 21 segundos.


Si la máquina donde reside el recurso "emite" una respuesta, esta se producirá inmediatamente en unas pocas decenas o centenas de milisegundos (abre conexión o rechaza conexión). Si no se recibe respuesta del recurso, el navegador web esperará hasta que venza el timeout de 21 segundos o 7 segundos en el caso de IE. Este comportamiento es replicable, con otros valores de timeout, a otros sistemas operativos.

Indirectamente, estos timeouts, si se comunican desde la víctima al atacante, permitirían además obtener más información sobre el tipo de sistema operativo que utiliza la víctima que ha visitado la página web modificada.

Comparativa de timeouts entre dos sistemas operativos al visitar diferentes recursos

Enumeración de red. Equipos y topología

Con la técnica analizada se puede descubrir información privada de una red a través de nombres/urls/rutas conocidas o que se puedan predecir mediante un diccionario. Por ejemplo, software de red, impresoras, nombres de dominio, etc. Un caso especialmente interesante es la posibilidad de utilizar los navegadores web (en este caso el navegador web de la víctima) como si de una herramienta de pentesting se tratara. En concreto, demostrar cómo mediante una página especialmente modificada es posible generar un comportamiento similar a ejecutar la herramienta nmap en la red interna pero desde una página web que se carga desde Internet y que no tiene acceso a la red interna. Este comportamiento es especialmente significativo a la hora detectar IPs "vivas" y puertos abiertos.

A la izquierda los resultados con Chrome, a la derecha, con Zenmap

En general los tiempos de respuesta variarán en función del sistema operativo de la máquina a escanear y del puerto que analicemos:

  • Equipos Windows: es necesario lanzar contra puertos "abiertos" para saber si la IP está activa (se recibe respuesta rápida)
  • Equipos Linux (Ubuntu): si la IP existe el puerto responde rápido (esté abierto o no [RST])
  • Dispositivos móviles Android o Iphone: si IP existe el puerto responde rápido (esté abierto o no [RST])
  • Dispositivos móviles Windows Phone: es necesario lanzar peticiones contra puertos "abiertos" para saber si la IP está activa.

Actualmente es posible escanear con libertad puertos superiores al 1024. En función del navegador web, por debajo de este valor será más o menos difícil escanear ciertos puertos porque los navegadores introducen medidas de port banning. Cada navegador implementa diferentes políticas en este sentido. Internet Explorer es más laxo que Firefox o Chrome.

A la hora de detectar cuál es el rango de red interna de la víctima, es mucho más eficaz conocer el rango de la red de antemano. Si el navegador web utiliza WebRTC (Firefox y Chrome) será sencillo obtener su IP interna (en la red corporativa o doméstica) y por tanto afinar en el escaneo de su rango. Si no fuera así se deberían escanear los diferentes rangos de red con "fuerza bruta".

WebRTC (Web Real-Time Communication) es una API que está siendo elaborada por la World Wide Web Consortium (W3C) para permitir a las aplicaciones del navegador realizar llamadas de voz, chat de vídeo y uso compartido de archivos P2P sin plugins. WebRTC sufre un "leak" conocido que permite conseguir la IP local del sistema atacado. Para comprobarlo, basta con visitar esta dirección con la prueba de concepto: http://net.ipcalf.com/.

En la próxima entrada veremos la parte de explotación y escenarios de ataque.

* Enumeración y explotación de recursos internos mediante Javascript/AJAX (y II)

Dr. Alfonso Muñoz

HTTP response splitting

martes, 11 de noviembre de 2014

También conocido como CRLF Injection Attack, HTTP response splitting es la técnica en la que un atacante se vale de la inyección de retornos de carro y de línea para alterar una respuesta HTTP y separarla en dos (de ahí su nombre). De esta forma puede incluir cualquier contenido en la segunda petición y poner en riesgo la seguridad y privacidad de los usuarios que visitan la web, así como pudiendo alterar la página. Típicamente, permite inyectar JavaScript.

Funcionamiento de un HTTP response splitting

El flujo de petición y respuesta HTTP habitual se muestra en el diagrama:

Esquema simple de petición y respuesta HTTP

El navegador inicia una petición (sea GET, POST o cualquiera de los otros verbos que usa HTTP) que se envía al servidor web. Este a su vez responde con un código de estado (2XX para éxito, 3XX para redirección, 4XX para error etc…) y el contenido de la respuesta, que habitualmente incluye el HTML de una web que será interpretada por el navegador del cliente.

Las diferentes líneas de una petición GET, por ejemplo, se separan por un retorno de carro y otro de línea (%0d y %0a). Si se añaden artificialmente en la petición con la intención de añadir nuevos campos, o incluso una segunda petición construida desde cero por el atacante, se produce el ataque. Abajo se muestra un diagrama de este proceso, de un ejemplo lanzado contra un servidor vulnerable de prueba:


Esquema de ataque HTTP response splitting

En esta petición se ha modificado un parámetro GET y en él se ha introducido un retorno de carro (%0d) y uno de línea (%0a) seguidos de las nuevas líneas de cada campo (Un "Content-Type" y un código JavaScript) separadas a su vez por otro CRLF (%0d%0a).

La petición que recibe el servidor quedaría así:



 La respuesta del servidor podría ser esta:


Que es interpretada por el navegador del cliente de la siguiente forma:


Las consecuencias para el cliente pueden variar, pero podrían ser peligrosas. Al fin y al cabo, el servidor en el que el cliente confía, está pidiendo al cliente que ejecute acciones no deseadas que han sido creadas por un atacante (el cliente previamente tendría que ser inducido a pulsar en un enlace de este tipo). Las consecuencias claras son las mismas que en un Cross Site Scripting "típico" no persistente.

Faast incluye un plugin que evalúa, comprueba y alerta sobre la presencia de este tipo de vulnerabilidad.

Juan Luis Sanz 
juanluis.sanz@11paths.com

QA: Pruebas para asegurar la calidad del producto software (II)

jueves, 6 de noviembre de 2014

Para adentrarnos un poco más en las diferentes pruebas que tiene que (o debería) realizar un equipo de QA, vamos a clasificar las pruebas según determinados criterios y luego profundizaremos en su definición y características principales. La tarea de clasificar las distintas pruebas dependerá siempre de los diferentes enfoques que se pueden tener sobre el propósito del software desarrollado, así que vamos a presentar diferentes clasificaciones atendiendo a los criterios que se suelen tener en cuenta a la hora de realizar una evaluación de calidad.

Según la metodología utilizada para verificar y conocer a fondo el funcionamiento de la aplicación disponemos de dos casos:

  • Test basado en un guión de casos de prueba o comúnmente llamado Scripted Testing
  • Test basado en pruebas exploratorias también llamado Exploratory Testing
Según la accesibilidad que se tenga sobre los elementos del sistema a evaluar:
  • Pruebas de Caja Blanca
  • Pruebas de Caja Negra
  • Pruebas de Caja Gris
También podrían clasificarse según el nivel al que llega cada test, y en éste caso se hablaría de:
  • Pruebas unitarias
  • Pruebas de integración
  • Pruebas de sistema

Y por último y no menos importante, si la clasificación se basa en la ejecución del producto también existe la siguiente clasificación:

  • Pruebas funcionales: En estos casos se lanza la ejecución de la aplicación para evaluar las diferentes características del software. En estas pruebas se busca si la solución satisface las necesidades por la que fue creada, si es compatible entre versiones, si realiza el funcionamiento esperado para un grupo de personas, etc. Según las pruebas (más o menos ligeras), podríamos hablar de "pruebas de humo",  de regresión, pruebas de aceptación, de compatibilidad,  de uso a primer nivel o "Alpha testing", pruebas de uso en pre-producción o "Beta testing"..
  • Pruebas no funcionales: en este caso se tratan de pruebas totalmente complementarias a las anteriores, ya que no es necesario la evaluación del funcionamiento de la aplicación sino verificar diferentes aspectos de ella. En este conjunto entrarían pruebas de seguridad, de usabilidad, de rendimiento, de internacionalización y localización, pruebas de escalabilidad,  de mantenimiento, de instalación, de portabilidad...

Llegados a este punto vamos a ir definiendo uno a uno para que se puedan apreciar las similitudes y diferencias de cada tipo de test existente en la actualidad.



Scripted Testing

Cuando hablamos de un test basado en un guión de pruebas (Scripted Testing), nos referimos a un tipo de test cuyo enfoque puede ser entendido como "tradicional". En este escenario se realiza un proceso de creación de documentación relativo a las pruebas que se quieren realizar. El diseño de los casos de prueba se hace al inicio del proyecto, donde se tienen claramente definidos los aspectos que se desean alcanzar, y se van añadiendo casos de prueba en cada nueva fase de desarrollo, de forma que se utilizan los casos previamente definidos y se añaden otros nuevos según haya variado la aplicación con respecto a la fase anterior (nuevas características, soluciones a errores, optimización de recursos, etc.). Finalmente el guión de casos de prueba dará al tester los pasos a seguir para ejecutar la aplicación e interpretar los resultados obtenidos de las pruebas y completar un informe detallado que formará parte de la documentación para la siguiente fase.

Si hablamos del ciclo de vida de un Scripted Test, podemos definir dos fases si tomamos en cuenta una visión temporal del proyecto:
  • Diseño temprano de pruebas.
  • Ejecución de las pruebas (en muchos casos, muy posterior al diseño).
Sin embargo, tras esto se iniciaría un ciclo por cada fase de desarrollo del producto.
  • Refactorización del conjunto de casos de prueba.
  • Ejecución de las pruebas.
Una característica principal es que el Scripted Testing se adapta a contextos poco variables y a situaciones donde se tenga un control estricto sobre los diferentes aspectos del proceso. Nuevas variables que revisar y verificar, o cualquier cúmulo de cambios, harían el control sobre las pruebas de la aplicación se complicara considerablemente y en consecuencia supondría realizar muchos cambios en el guión de pruebas.

En la práctica, el equipo de QA elige un integrante al que llamaremos diseñador. Se encargará de crear los casos de prueba que debería dar como resultado un robusto conjunto. Otros integrantes (o solo uno, dependiendo del volumen de casos), realizarán la función de testers que serán los que busquen lo que el diseñador les diga bajo las condiciones de entorno que el diseñador les imponga.

Es importante que el diseñador no realice funciones de tester ya que su aportación a la búsqueda de errores sería prácticamente nula respecto a las pruebas que él mismo ha pasado por alto. O lo que es lo mismo: los demás pueden encontrar errores para los que el diseñador no ha generado casos de prueba.

Si pretendemos dar un ejemplo sobre esto, tendríamos que definir lo que es una Fábrica de Pruebas, puesto que en este entorno es el proyecto el que se adaptará al proceso de trabajo de la fábrica. En esta situación los proyectos se etiquetarán según sus características y se tratarán según la clasificación que les aplica. En este entorno existen plantillas con un conjunto de pruebas predefinidas y según el tipo de proyecto al que se le quiera aplicar, se aplica una plantilla u otra.

Para desarrollar estas plantillas se presta atención a aspectos generales como:
  • Los riesgos habituales en un determinado escenario.
  • Previsión de errores, así como su ubicación, su tipología, etc.
  • Posibilidad de aplicar la repetición de pruebas, que sería muy ventajoso.
  • Valorar el uso de scripts automatizados (programación de algoritmos de prueba)
Sobre esto, un aspecto que siempre debemos tener en cuenta es la capacidad de las personas a la hora de procesar información. Algunas personas pueden ver lo que otros no ven a simple vista, ya sea por falta de conocimientos o intereses. En contraposición, los ordenadores a su vez se centran únicamente en hacer lo que se les ha programado hacer, es decir, no posee suficiente inteligencia para descubrir errores que pueden estar en el mismo escenario en el que se está ejecutando, ya que solo observará lo que se ha diseñado que se observe.



Pruebas exploratorias

Las pruebas exploratorias o testing exploratorio es un estilo o enfoque a la hora de realizar una evaluación de calidad de un producto software en la que podríamos destacar su capacidad de retroalimentación. Donde aprender el funcionamiento de la aplicación, la labor de diseñar casos de prueba y ejecutarlas son etapas que van de forma conjunta durante casi toda la ejecución del test.

Si quisiéramos decirlo de otra manera, sería un estilo de testing donde se da especial prioridad a la libertad del tester de optimizar continuamente la calidad de su banco de pruebas y la responsabilidad asociada para mantenerlo y realimentarlo según vaya realizándose el diseño o la realización de pruebas. Es decir, no se espera a que se complete un ciclo de desarrollo para regenerar el conjunto de pruebas, sino que el número de pruebas irán incrementando en función de cómo se vaya explorando la aplicación. Cuanto más se use la aplicación más casos de uso se nos ocurrirán y de esta manera tendremos un guion más robusto y podremos realizar un informe mucho más completo que el que conseguiríamos con un Scripted Testing

Muchas personas que se dedican a las pruebas de calidad, consideran que el testing exploratorio tiene características comunes con la técnica de prueba de caja negra (hablaremos de ello más adelante), sin embargo, no queremos dar a entender el testing exploratorio como una técnica, sino más bien como una filosofía o enfoque donde la clave principal está en la responsabilidad y concentración del tester para gestionar tiempo y recursos en la búsqueda de mejorar constante y progresivamente su batería de pruebas sin necesidad de una nueva versión de la aplicación o características.

Y es que el objetivo principal que se persigue, es aprender cómo funciona realmente la aplicación y ser capaz de responder a preguntas sobre cómo se comporta en determinadas circunstancias. Es por esto que la calidad del testing exploratorio depende de las habilidades del tester para desarrollar los casos de prueba iniciales y generar nuevos a la hora de encontrar errores. El tester configura, opera, observa y evalúa el producto y su comportamiento, investigando de forma crítica el resultado y reportando la información de lo que parecen ser defectos (que amenazan el valor del producto) o problemas (que amenazan la continuidad y calidad de las pruebas).

En relación a la documentación, se puede decir que se puede ir desde registrar todas las pruebas realizadas, a documentar únicamente los defectos.

La tarea de documentar los errores no siempre depende del tester que los encuentre, ya que en situaciones comunes como las pruebas por parejas, dos personas crean los casos de pruebas y luego una los ejecuta y la otra documenta. Así se consigue un alto grado de rendimiento y concentración en la labor que se está realizando.

Las pruebas basadas en sesiones es un método específicamente diseñado para el testing exploratorio auditable y medible a gran escala. Es por esto que en algunas empresas, como complemento a la hora de realizar el testing exploratorio, hacen uso de herramientas, (capturas de pantalla o vídeo, por ejemplo), que se usan a modo de registro de la sesión.

Scripted Testing y Exploratory Testing

Combinación Scripted Testing y Exploratory Testing

En realidad, para realizar un test sobre aplicaciones no se tiene por qué optar a uno u otro enfoque. Una buena práctica de evaluación de calidad casi siempre es una combinación de testing exploratorio y testing basado en un guion de pruebas, aunque el equipo de QA siempre se va a tener tendencia hacia uno de los dos, dependiendo del tipo de proyecto, numero características e incremento de las mismas, etc.

* QA: Pruebas para asegurar la calidad del producto software (I)

Jhonattan Fiestas
jhonattan.fiestas@11paths.com

Principales leaks en las herramientas de control de código

martes, 4 de noviembre de 2014

Las herramientas de control de código son muy habituales durante el desarrollo de aplicaciones. Permiten una imprescindible gestión y control de versiones cuando se trabaja en un proceso de desarrollo de software de cierta envergadura. ¿Qué información pueden ofrecer a un atacante si se encuentran mal configuradas?

Herramientas como Git, Mercurial, Subversion y muchas otras resultan muy útiles pero también pueden comprometer la seguridad de la organización si quedan accesibles al exterior, no se configuran correctamente o se realizan malas prácticas durante el paso a producción. En esta entrada se recopilará brevemente la información más relevante que se puede extraer al encontrar un software de control de versiones desprotegido de alguna forma.

Git

Al crear un nuevo repositorio en local, el código usado por la aplicación se crea bajo la carpeta .Git, marcada como oculta. Puede que algún administrador copie esta carpeta a algún punto accesible por la red, y esto permitiría a un atacante obtener el código fuente de la aplicación con tan solo usar el comando

git clone [url del repositorio]. 

Dependiendo de la tecnología o el gestor de contenido que use, se podrán ubicar archivos de configuración con mayor facilidad. En el caso, por ejemplo, de un gestor de contenido Wordpress, se podría detectar fácilmente el fichero de configuración wp-config, donde se encuentran las cadenas de conexión a la base de datos.

Mercurial

Al igual que Git, Mercurial ubica todos los archivos en la carpeta .hg, donde en primera instancia se puede encontrar el archivo dirstate, que enumera los ficheros que han sido procesados por Mercurial. Este archivo es clave para recuperar los posibles ficheros que se ubiquen todavía en la aplicación web y que conserven la misma ruta de acceso y el mismo nombre. En caso de que no se encuentre el archivo dirstate, se puede consultar el archivo undo.dirstate, que contiene información similar. Se crea como copia del dirstate para permitir un rollback. Los archivos de código fuente se ubican en el directorio store/data, donde se guardarán codificados con un algoritmo usado por Mercurial. Para obtener el código fuente en plano, se pueden usar clientes como SourceTree para recuperar el repositorio de código y trabajar de forma local.

Bazaar

Aunque no tan popular como los anteriormente citados, el software de control de código Bazaar es una alternativa que nació en 2007. Como el resto, si no se configura correctamente, puede permitir a un atacante obtener mucha información sobre la aplicación web. Bazaar almacena toda la información en el directorio .bzr. La información más relevante estaría ubicada en branch y repository.

El directorio branch representa la rama en la que se está trabajando y por tanto en esta carpeta se ubican los archivos de configuración como branch.conf que muestran configuraciones para esa rama. Por otro lado, en la carpeta repository se ubican los archivos del repositorio, aunque para acceder a ellos se debe consultar primero el archivo pack-names y recuperar el nombre del archivo pack, que se encontrará a su vez en la carpeta packs. Aunque estos archivos son el "commit" completo, se deberá realizar una búsqueda a través de los índices ubicados en la carpeta "índices" para obtener el código fuente en texto plano.

De nuevo, utlilizando cualquier cliente de Bazaar como Bazaar explorer, se puede descargar el repositorio completo.

 Subversion

Finalmente y al igual que los demás programas de controles de código comentados previamente, la carpeta generada por Subversion es .svn, en la que se almacenará toda la información relativa al control de código. Dependiendo de la versión que se use, puede encontrarse el archivo entries, donde en texto plano se especificaran los archivos implicados, su tipo, permisos, la fecha de creación y el usuario.

Por otro lado, en versiones más recientes se implementa una base de datos SQLite para almacenar los datos: wc.db, ubicada en la carpeta .svn. La diferencia es que el archivo wc.db se usa de índice para acceder al código fuente almacenado en un directorio llamado pristine, donde se guarda una copia del código fuente totalmente en plano. Está organizado por carpetas con el primer octeto del inicio del hash y dentro de la carpeta el propio fichero con el nombre del hash.

Aplicaciones web que gestionan el código

De forma más visual y más intuitiva las aplicaciones web pueden ayudar mucho en el desarrollo de software, pero también hay que fortificarlas adecuadamente para que no accedan usuarios no autorizados. Un claro ejemplo es interfaz web del gestor de código ViewVC, que permite a los usuarios navegar a través de todo el árbol de archivos y recorrer las versiones realizadas sobre los archivos en un repositorio de código CVS o Subversion. Si el acceso a esta aplicación web no se restringe correctamente puede dar a un atacante una vía perfecta para obtener el código fuente de la aplicación de la organización.

Ejemplo de ViewVC


Al igual que existen aplicaciones web que permiten visualizar el código de la aplicación, también se deben controlar y proteger las aplicaciones web que permiten la ejecución del código como Buildbot o Jenkins que pueden ser de gran utilidad a los atacantes.

Este tipo de aplicaciones web, son detectadas por Faast y reportadas en forma de vulnerabilidad para alertar de la su existencia:


Evidencia de Faast

Faast y herramientas de control de código

En Faast se han implementado plugins que permiten la detección de repositorios de código abiertos y sin restricción. Permitiría identificar lo que un posible atacante sería capaz de obtener: desde el código fuente de la aplicación, hasta cadenas de conexión a máquinas, base de datos o servicios en general.


Potencial problema de seguridad reportada a través de la interfaz de Faast

Gracias a los plugins específicos, una vez detectado el repositorio de código, Faast analizará el resto de ficheros correspondientes a la tecnología concreta para aumentar la cantidad de activos disponibles. Así, reportaría archivos de configuración del propio repositorio de código y en caso de que estuviesen, los archivos del código fuente y su ruta accesible a través de la red.

Evidencia en el plugin de Faast sobre una debilidad en Mercurial



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