Havex no es el nuevo Stuxnet (y la falta de profesionalidad)

lunes, 30 de junio de 2014

Desde que Stuxnet apareció (hace ya cuatro años) parece que se espera un sucesor. Al menos en el campo del espionaje industrial y ámbitos SCADA. Desde entonces, se han descubierto varios "hijos", "primos" y familiares en general, pero ninguno parecía estar a la altura. Havex tampoco, ni mucho menos. De hecho, a pesar de los titulares, no tiene mucho que ver.

Havex suena en los medios porque se ha descubierto atacando a sistemas industriales. Lo cierto es que Havex no es nuevo. Se trata de una herramienta de control remoto (RAT) genérica que quizás se esté usando desde 2011. Crowdstrike lleva ya tiempo asociando esta herramienta a ataques a grandes empresas energéticas europeas (una buena parte en España).

Este gráfico es de 2013, en realidad, cuando Havex fue usado para otros fines
Lo que ha ocurrido ahora es que el interés de esos atacantes parece haberse centrado en compañías industriales y sistemas SCADA, adaptando su "herramienta" a las nuevas necesidades.

Infraestructura y finalidad

Usaron sistemas legítimos comprometidos como C&C (servidores de control para el troyano). No es la mejor manera de conseguirlo puesto que vuelve "frágil" la infraestructura. Comprometer servidores de terceros eleva las posibilidades de que los legítimos dueños puedan recuperar el acceso a sus servidores (con la información robada en ellos) o que los atacantes lo pierdan en cualquier momento. Bastante poco profesional por parte de los atacantes.

En el código, se observan funciones específicas para obtener y recolectar información concreta de sistemas SCADA, además de la capacidad habitual de tomar el control de los sistemas infectados.

Métodos de infección

Esta es la parte interesante. Al parecer usaron métodos tradicionales de infección (exploits o correos) junto con ataques de tipo "watering-hole" más que curiosos.

Comprometieron al menos tres empresas, todas ellas involucradas en el negocio de sistemas industriales. Estas compañías (con sede en Suiza, Bélgica y Alemania) proporcionaban software y sistemas de control remoto para sistemas ICS, cámaras de alta precisión, etc., y permitían la descarga (como muchas otras) de drivers, instaladores y software. Los atacantes tuvieron acceso a estos repositorios (al parecer por fallos en su infraestructura web) y alteraron los programas legítimos para instalar un "troyano" a la vieja usanza, donde el programa troyanizado funciona correctamente pero permite también el control remoto a los atacantes entre bambalinas.

¿Quién descargaría y usaría ese software? Solo técnicos específicos de sistemas industriales. Así que el objetivo era muy específico para los atacantes. Uno de los archivos detectados en este ataque fue enviado a Virustotal en marzo. Ningún motor lo detectaba por firmas. El resto de DLLs utilizadas, no habían sido enviadas antes del 23 de junio de 2014, pero tampoco eran detectadas ese día. En pocas horas, la mayoría de los antivirus eran ya capaces de detectarla.

Tanto los proveedores de software como los que lo consumían, han cometido una serie de errores graves durante el proceso de infección.

  • Las páginas que proporcionan estos sistemas industriales han sido comprometidas y sus programas sustituidos sin que sus legítimos dueños lo hayan advertido a tiempo. Los errores de estas empresas, tanto reactivos como preventivos, son innumerables. No se han dado los nombres concretos de las compañías, pero no resulta muy difícil poder reducir el círculo de candidatas.
  • Los operarios o administradores han descargado este software y no han comprobado las firmas o integridad (si es que las compañías firmaban todo su software u ofrecían algún método de comprobación). Esto es quizás lo más preocupante. En entornos de este tipo, instalar un programa debe ser un proceso compuesto por varias fases, aunque haya sido descargado de una página oficial. En concreto comprobar firmas e integridad debería ser obligatorio en el procedimiento. También la ejecución en sandboxes que desvelen el comportamiento exacto del programa antes de pasar a producción. Por ejemplo, esta línea en un sistema de debug hubiera podido delatar el comportamiento anómalo.

Ejecución de una DLL en un programa legítimo de control SCADA. Fuente: F-Secure

  • Los sistemas en producción disponían de conexión directa a internet. Se deduce porque, tras instalar los componentes troyanizados, el malware concreto era descargado y actualizado sin contratiempos. Además de enviar la información robada. Parece que los sistemas industriales afectados no contaban con listas blancas de conexión a internet, IDS o cortafuegos... en definitiva, las nociones básicas de seguridad. 

No es Stuxnet

Los medios de comunicación tampoco se han mostrado muy certeros con esta comparación. Stuxnet estaba específicamente diseñado para atacar el producto SCADA WinCC de Siemens. Y hasta aquí las similitudes. Esta variedad de Havex, aunque con un objetivo claro, no parecía estar tan específicamente programada. Stuxnet contenía vulnerabilidades completamente desconocidas, operaba de forma mucho más inteligente, utilizaba certificados válidos... era una verdadera arma muy pensada y diseñada con un objetivo concreto (parece que las centrales nucleares iraníes).

Nadie duda de que esta operación con Havex se considere un ataque relevante, pero Stuxnet fue mucho más allá, y se podría decir que fue diseñada por un equipo muy potente y poderoso que desarrollaron su "producto" durante años. Con Havex lo que se ha realizado es un ataque concreto a sistemas SCADA, pero no se ha diseñado específicamente un arma contra ellos. Aunque resulte preocupante y haya causado en una infección alta, se queda casi en la anécdota si lo comparamos con Stuxnet, al menos por ahora sin más datos.

Las infecciones han sido variadas, sobre todo en Europa. Se diría que Havex ha infectado a compañías más modestas, aunque no por ello pequeñas. Por tanto no caben demasiadas comparaciones. Pero sí sirve para recordar, una vez más, que para realizar una campaña de infección medianamente eficaz a muchos sistemas críticos, quizás no haga falta una inversión tan alta.

Sergio de los Santos
ssantos@11paths.com

Ocho siglas relacionadas con las vulnerabilidades (V): CVRF

viernes, 27 de junio de 2014

Evidentemente, uno de los factores críticos sobre el que gira el mundo de la seguridad es el estudio y control de vulnerabilidades. Organizaciones como MITRE, FIRST e ICASI se encargan de gestionar y estandarizar este importante aspecto. Otra de las iniciativas de estas organizaciones para cubrir este ámbito es CVRF o Common Vulnerability Reporting Framework.

Estas siglas pertenecen a ICASI (The Industry Consortium for Advancement of Security on the Internet), una organización sin ánimo de lucro que intenta solucionar desafíos de seguridad, con la finalidad de proteger mejor las infraestructuras que ofrecen servicios a empresas, gobiernos y ciudadanos de todo el mundo. En concreto, el formato CVRF intenta afrontar el problema que surge a la hora de comunicar vulnerabilidades tanto entre profesionales de diferentes compañías como entre sistemas automáticos. ¿Qué información debe contener la descripción de una vulnerabilidad? ¿Qué campos se deben comunicar? ¿En qué formato? CVRF es la fórmula estándar para resolver estas cuestiones.

CVRF se trata de un lenguaje basado en XML que permite compartir información crítica relacionada con la seguridad en un formato único, permitiendo así un rápido intercambio y gestión de la información. En realidad este lenguaje no solo es utilizado para compartir información relacionada con las vulnerabilidades, sino que también ha sido desarrollado para poder transmitir cualquier tipo de información concerniente a la seguridad. Su primera versión fue publicada en mayo de 2011, sin embargo, la versión actual es la 1.1 y fue creada en mayo de 2012.

La siguiente imagen resume esquemáticamente cuánta información puede contener y comunicarse con este lenguaje, a la vez que desvela cómo se organizan los datos. Se cubren los aspectos más importantes relacionados con temas de seguridad y requerimientos a la hora de difundir esta información.

Mapa lógico del formato CVRF 1.1

La siguiente leyenda es necesaria para comprender los distintos elementos y atributos contenidos en este lenguaje.

Leyenda para comprender el mapa lógico de CVRF


Dentro del lenguaje, en caso de que sea aplicable, se incluyen algunas de las iniciativas del MITRE como lo son CVE, CWE y CPE (Common Platform Enumeration), que permiten afinar la información y estandarizar todo lo posible los diferentes campos que definen una vulnerabilidad.

En la actualidad, el CVE ha adoptado el formato CVFR para publicar el contenido de la información registrada en cada una de sus entradas. Con esto, el CVRF permite que la información sobre vulnerabilidades pueda ser compartida en un formato estandarizado, y que además sea fácilmente interpretado por sistemas o herramientas de proveedores y consumidores.

Compañías como Red Hat, Microsoft, Cisco Systems u Oracle utilizan este lenguaje propuesto tanto con sus consumidores como con otros proveedores de información (como es el caso del CVE). A su vez, el CVE alimenta con esta información distintas bases de datos de vulnerabilidades que son constantemente utilizadas por muchas de las herramientas de diagnóstico de vulnerabilidades. Algunas de estas bases de datos que colaboran con la difusión de la información relacionada con las vulnerabilidades son OSVDB, NVD o CVE Details. Por tanto, la difusión de la información con estándares de este tipo garantiza una homogeneidad en los datos mostrados sin importar la fuente y disponer de fuentes tan completas como sea posible.

Las listas de CVEs correspondientes a cada año se pueden descargar en este formato desde la web de oficial de CVE. En su contenido puede verse la estructura de este lenguaje basado en XML donde cada CVE contiene una serie de propiedades y cada una de ellas contiene la información correspondiente a la vulnerabilidad.

Lista CVRF del año 2012


* 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 (VI): CWRAF
Umberto Schiavo
umberto.schiavo@11paths.com

Errores de configuración y malas prácticas: PHP Info

miércoles, 25 de junio de 2014

Cada día se configuran cientos de servicios, se actualizan y quedan expuestos a olvidos y fallos de configuración. La tecnología PHP se encuentra muy distribuida en Internet y la configuración de manera desatendida o por defecto puede provocar que se exponga más información de la se desea. En esta entrada nos centramos en las características de la función de "phpinfo" y cómo aprovecharlas para obtener el máximo beneficio.

Con simples búsquedas en Google y mediante parámetros avanzados se podrían encontrar gran cantidad de archivos del tipo phpinfo.php. En la imagen se puede observar cómo quedan al alcance de la mano alrededor de 22.500 resultados. Muchos de ellos serán archivos de este tipo.


Archivos phpinfo disponibles públicamente

¿Por qué estos resultados son importantes en un pentesting? La primera fase del pentest es el descubrimiento o "discovery". Es importante conocer el objetivo marcado todo lo que se pueda. Internet es un lugar donde buena parte de lo que se haga, configure y publique queda expuesto y por esta razón, recopilar y conocer todos los detalles de lo que dispone una organización es fundamental para progresar en el pentest.

¿Es posible obtener información jugosa? La cierto es que sí. A continuación vamos a enumerar los elementos de interés que es posible obtener de estos archivos:
  • Usuarios del sistema.
  • Rutas internas que ayuden a conocer cómo se estructura el sistema de archivos y qué aplicaciones se ejecutan. Siguiendo un ejemplo real sobre el que se han realizado pruebas, en el caso del servidor de correo si se analiza la directiva sendmail_path es posible deducir que se realiza a través de la ruta C:\xampp\mailtodisk\mailtodisk.exe. Las rutas internas provocan fugas de información que puede ayudar al pentester a modelar su siguiente paso.
  • Direcciones de correo. Este documento puede aportar información sobre correos. Evidentemente no es la mejor vía en un pentesting para encontrar correos electrónicos pues para ello tenemos otras vías como son las de The harvester, Maltego o el propio Faast, pero sí puede resultar complementaria.
  • Módulos habilitados que posibiliten otros ataques. Esto es una característica que un pentester debe observar a conciencia. Este tipo de descubrimientos puede hacer que un pequeño descuido en la configuración de un servidor acabe convirtiéndose en el punto de inflexión por el que se accedió a datos relevantes de la organización.
  • El sistema operativo y versión que corre la máquina. Esto es importante para saber rápidamente si existen vulnerabilidades que puedan comprometer la seguridad del servidor.
  • Versiones de aplicaciones y servicios. La información que se puede obtener con este archivo es importante. Por ejemplo en las siguientes imágenes podemos comprobar que existe un MySQL en el puerto 3306 (detalle que se puede conocer también con un nmap sin demasiado esfuerzo); que la versión de OpenSSL es posible que sea vulnerable a HeartBleed (CVE-2014-0160); o que la versión de Python es la 2.7.

Ejemplo de información extraíble en un archivo phpinfo

En el caso de las directivas comentadas anteriormente, se puede concluir también que, por ejemplo, si safe_mode está deshabilitado podría llegarse a la ejecución de comandos desde un archivo php. Por otro lado la directiva display_errors en modo "on" significa que los mensajes de error de php se volcarían para cualquier usuario, por lo que el pentester puede así provocar fallos en busca de "leaks". Existen diversas directivas que, por ejemplo, son analizadas por Faast en busca de estos fallos, una vez descubierto un archivo PHP info. Un pequeño error en la configuración puede abrir cientos de puertas o vectores de ataque a un pentester.

Utilizando el servicio Faast y haciendo pruebas sobre nuestro sitio de pruebas demofaast se obtuvo la siguiente evidencia:

Ejemplo de conversación HTTP

Se puede ver una petición al servidor, una respuesta y parte del contenido que es la evidencia de que se está ante un PHP Info que provocará la fuga de información. Además, la herramienta se nutre de toda la información para seguir explorando las posibilidades que este tipo de fuga ha provocado.

Como curiosidad, recordar que Faast, además de detectar este archivo y "destriparlo" para avanzar en la investigación,  permite alertar sobre cualquier otro fichero sospechoso que pueda suponer un peligro para el servidor, como pueden ser la mayoría de shells documentadas que, por sus características, resultan identificables.

Pablo González
pablo.gonzalez@11paths.com

News: Nuevas versiones y características en las apps de Latch

martes, 24 de junio de 2014

De cara al verano y las vacaciones para muchos, en Eleven Paths hemos querido que los usuarios de Latch, dispongan de una significativa actualización de la app para Latch. Se ha creado una nueva versión para Android, iOS y Windows Phone, con diversas mejoras y novedades respecto a la anterior.

En esta entrada vamos a indicar las principales novedades y mejoras incorporadas en la app de Android, iOs, y Windows Phone, orientadas a seguir protegiendo los servicios de los usuarios con eficacia y mayor comodidad.

Novedades generales

La novedad más llamativa para el usuario que actualice su versión es la incorporación de un elemento deslizable que nosotros coloquialmente hemos llamamos "latchón". Este elemento viene a sustituir al botón "Bloquear todo", que existía en la versión anterior.

"Latchón" en un dispositivo Android

Otra novedad es que cuando se bloquea un servicio o una operación con este elemento, todas las operaciones que existan por debajo quedan bloqueadas. Pero además quedan deshabilitadas desde la app, de tal forma que no se pueda modificar el estado de ninguna de ellas.

Bloqueo de todos los servicios pareados al activar el "Latchón"
y servicios deshabilitados

Bloqueo de operaciones internas al activar el "Latchón"
de un servicio

El desbloqueo del "latchon" mantiene el estado anterior de cada servicio u operación. Los botones de tipo interruptor (a los que coloquialmente llamamos "latchitos") ahora incorporan un texto indicando el estado del servicio ("BLOQ." para bloqueado y "DESBLOQ." para desbloqueado), estos mismos textos con su correspondiente traducción se indican en los cuatro idiomas de la app (español, inglés, portugués y alemán).
"Latchito" de un servicio bloqueado


Pantalla intermedia al generar el pareado

Ahora, cuando se quiere generar el pareado, aparece una pantalla intermedia desde la que se puede acceder al manual de explicación acerca del pareado o se puede pulsar el botón que genera el código directamente. Esto ofrece un tiempo al usuario para posicionarse en la sección exacta de la página web o consola donde le están pidiendo este código.

Pantalla previa a la generación de un código de pareado

Bloqueo programado y autobloqueo

Ahora es más fácil establecer un "Bloqueo programado". En la anterior versión se hacía con un botón con forma de reloj junto a los botones de bloqueado y desbloqueado. Esto confundía a algunos usuarios. Ahora simplemente hay que configurarlo desde el apartado "Programar bloqueo", y Latch automáticamente establecerá el estado actual del servicio según el horario indicado.

Además el "Bloqueo programado" y el "Autobloqueo" son ahora autoexcluyentes para evitar cualquier confusión sobre el estado de un servicio u operación en un momento determinado. Cuando se establece uno, el otro queda deshabilitado.

"Bloqueo programado" establecido y "Autobloqueo" deshabilitado

Otra novedad es que los servicios u operaciones que tengan un "Bloqueo programado", mostrarán un icono con forma de reloj en su "latchito".

Reloj en el "latchito" indicando que se ha establecido un "Bloqueo programado"

El tiempo de "Autobloqueo" ahora es global para todos los servicios u operaciones, y se establece desde el menú de "Configuración".

Aviso de desbloqueos de operaciones padre

Al realizar un desbloqueo de una operación desde una notificación, si esta operación está bloqueada porque se ha establecido un bloqueo en una operación superior o padre, se recibirá un aviso indicando el listado de operaciones que se desbloquearán también.

Esto es debido a que si se ha establecido un bloqueo en una operación o servicio todos los elementos que estén por debajo estarán a su vez bloqueados. Gracias a esta opción el usuario puede elegir si desea o no desbloquear la operación y estará informado de los servicios u operaciones que se desbloquearán a su vez.


Aviso de desbloqueo de operaciones padre

Mejoras en los dispositivos

Además de estas múltiples mejoras, Android y Windows Phone han incorporado algunas mejoras propias:
  • En Android ahora la app está optimizada para dispositivos de densidad media (mdpi). 
  • La versión de Latch en dispositivos Windows Phone ha sido la que más modificaciones ha incorporado. Entre otras, ahora se reciben notificaciones cuando se desparean servicios, y se pueden configurar para recibirlas cuando se accede a un servicio desbloqueado. Otra mejora es que si el proveedor del servicio realiza una modificación en el estado del servicio, se mostrará en la app con un llamativo color naranja. Además de todo esto ahora incorpora soporte para Windows Phone 8.1.

Recursos




News: New versions and features in Latch apps

Facing the summer and holidays for most of you, in Eleven Paths we have created a new important update for Latch app, We have a new version for Android, iOS and Windows Phone, with several improvements and new features.

In this post we're going to specify the most important new features and improvements you can get with the new app for Android, iOS, and Windows Phone, so you can keep protecting services more effectively and easily.

Main improvements

The most flashy improvement for the user updating to the newer version is this new big sliding element that we call here in the office "latchón" as in "big latch". This slider replaces the "Lock Everithing" button in the previous version.

"Latchón" in Android


Another new thing is that when a service is locked with this element, every operation existing below will be locked too. But besides, they will be disabled from the app, so you can't modify the status of any of them.

Locking all the paired services when "Latchon"
is activated.

Locking internal operations when activating the
big Latch of a service
Unlocking the big latch keeps the latest status of any service or operation. The usual slide buttons (that we call "little latches" or "latchitos") now come with text indicating the service status ("LOCK" for locked and "UNLOCK" for unlocked), these texts are translated into Spanish, English, Portuguese and German.
"Latchito" of a locked service

A new intermediate screen when generating the pairing token

Now, when generating a new token, a new intermediate screen appears from where you may access the guide explaining the pairing process or directly generate the token. This offers time for the user to click on the exact form field in the website where the token is being required.

Step before generating the pairing token


Scheduled lock and autolock


Now it's easier to schedule a lock. In previous versions it was done with a clock shaped button next to the lock and unlock buttons. This resulted confusing for some users. Now it's configured from a separate "Schedule lock" field and Latch will automatically set the status depending on the configured time span.

Besides, "Scheduled lock" and "Autolock" are now self-exclusive to avoid confusion between the status of a service or operation at a given time. When one is set, the other is disabled.
"Scheduled lock" set and "Autolock" disabled

Another new feature is that the services or operations with a "Scheduled lock" will show a clock shaped icon inside their "latchitos" (little latches).
A little clock in the latch indicates a "Scheduled lock"


The autolock time is now global for all services or operations, and is set from the "Settings" menu.

Notifications about unlocking parent operations


When unlocking an operation from a notification, if this operation is locked because a lock is set in a "parent" operation, a message indicating the operations that will be unlocked will be received too.

This is because if a lock is set for a service, all the elements below will be locked too. Thanks to this feature the user may choose if he wants to unlock or not the operation and will be informed about the services or operations that will be unlocked too.
Notification about unlocking parent operations
Improvements on devices

Beside theses common features, Android and Windows Phone have integrated some improvements:
  • For Android the app is now optimized for MDPI resolution. 
  • Latch for Windows Phone is the one that has been modified the most. Now, notifications are received when upairing services, and may be configured to be received when accessing an unlocked service. Another improvement: if the service provider modifies the status of the service, the app will show an orange notification. Windows Phone 8.1 is now supported.
Resources



El negocio de las "FakeApps" y el malware en Google Play (IX): ¿Qué hacen y cómo se programan las apps?

lunes, 23 de junio de 2014

Durante este estudio de las apps falsas que simulan ser otras más populares, hemos hablado de varios aspectos relativos a este negocio. Sin embargo, ¿qué ocurre exactamente cuando un usuario se instala una de estas apps? ¿Cómo crean tantas y tan rápido los atacantes? Veamos qué hacen y cómo lo hacen.


Las apps falsas "puras", que simulan ser algún otro juego popular, suelen pesar poco (entre 200 y 500 kbs) y estar destinadas directamente a la publicidad invasiva. Pueden realizar varias funciones en el dispositivo de su "víctima", entre otras:
  • Como se ha mencionado, y la razón de todo esto, es bombardear al usuario con ventanas emergentes, banners y todo tipo de publicidad, hasta el punto de que (si los programas se inician con el teléfono) sea complicado utilizar el dispositivo.


    Ejemplo de publicidad superpuesta a cualquier otra app
  • Obligar al usuario a valorar otras aplicaciones (normalmente también falsas) con 5 estrellas. Así consiguen dar veracidad a otras apps que han subido previamente, y pueden mejorar su ingeniería social. Normalmente avisan que hasta que no se vote, no se puede jugar. Este es el modelo clásico y permite posicionar bien la app en el market, al tiempo que "invalida" en cierta forma este método de reputación.

    Ejemplo de Minecraft falso que solo busca que se le
    puntúe con 5 estrellas y mostrar publicidad


  • Obligar al usuario a descargar otras aplicaciones falsas o modificadas. También aumenta así el número de descargas. Igualmente, esto hace que el usuario que confíe en el número de descargas como parámetro de la popularidad o fiabilidad de un programa, pueda equivocar su evaluación. Como regla general, hay que tener en cuenta que el número de descargas no significa nada en números relativamente pequeños.

    Ejemplo típico de app que instala markets alternativos, y busca una descarga y una puntuación

  • Modificar el market o instalar nuevos markets. Las búsquedas de apps se realizan así sobre otro servidor de descarga, donde no se ejerce ningún control de la calidad de las apps.


Ejemplo de anuncio de market alternativo

¿Pero las apps falsas contienen juegos o no?

Muchos no son más que el adware o malware en sí, pero otros sí que contienen alguna función. Durante 2012 y 2013, sí fue muy habitual el "reempaquetamiento" de apps y juegos a los que se añadía "funcionalidades extra". Sin embargo esto ya no es tan habitual debido a los controles actuales de Google Play. 

Pero no por eso existen "FakeApps" que no contengan funcionalidad. Aunque esto emparenta con actividades completamente legítimas, también lo aprovechan los creadores de adware y malware en Google Play. Son las llamadas "plantillas" para juegos y utilidades, que se comercializan y subastan. Han favorecido la aparición de empresas que gestionan este intercambio y que permiten que, sin saber programar una sola línea, sea posible crear apps populares (incluso para otras plataformas diferentes a Android). Empresas como Binpress, Apptopia, Chupamobile, CodeCanyon o españolas como Mobincube ofrecen maneras de crear y personalizar apps con solo pulsar algunos botones. Las "plantillas" proporcionan la funcionalidad básica. Por ejemplo, del juego de moda del momento. Son compañías y actividades completamente legítimas, pero cuyos servicios son aprovechados por atacantes.

La razón es que en realidad, en el mundo móvil los juegos o apps de moda suelen ser muy parecidas en su funcionalidad. Lo único que suele cambiar es el diseño. Por tanto, los "motores" (puzles, fondos de pantalla, plataformas, cortadores de fruta, estilo flappy birds...) pueden reutilizarse. Se añaden algunos gráficos propios, y ya se dispone de un juego que se puede monetizar partiendo de una mínima inversión en dinero y tiempo. También ocurre con pequeñas funcionalidades como linternas, bromas, frases... que tanto abundan en Google Play.


Venta legítima de plantillas para aplicaciones para Android


Algunas de estas compañías, dejan preparada la app para introducir la publicidad configurada directamente y así generar beneficio al autor. De esta forma, el programador (o atacante, en el caso de que introduzca adware demasiado agresivo o malware) solo debe entender la "tendencia" de descarga del momento que existe en Google Play, que fundamentalmente se basa en:
  • Conocer los juegos o funcionalidades de moda, que suele coincidir con las palabras clave que le proporcionarán descargas.
  • Estar al tanto de apps muy codiciadas que vayan a aparecer de manera inminente en Google Play, y simular que se trata de esa app para cazar a los usuarios que la buscan activamente incluso cuando no se encuentra oficialmente disponible para esa plataforma.

Empresa de creación de apps de forma sencilla

Con esta información, el creador de adware solo tendrá que adquirir la plantilla correspondiente, incrustar su publicidad, y subirla a Google Play. Normalmente Google Play lo retirará después de algunos días (o no), pero lo más probable es que el negocio le sea rentable durante el tiempo que se mantenga online.

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

Sergio de los Santos
ssantos@11paths.com

Proteger servidores OpenSSH y OpenVPN (también con Latch) (y II)

viernes, 20 de junio de 2014

OpenVPN es el software multiplataforma que permite crear redes privadas virtuales y punto a punto de forma remota y segura. Imiplementar una buena seguridad en OpenVPN es fundamental para evitar accesos no deseados, debido a que se utiliza principalmente en entornos profesionales para acceder desde cualquier punto a la red corporativa, el control de un atacante podría resultar fatal.

Algunas recomendaciones para asegurar un servidor OpenVPN pasan por:

  • Crear claves criptográficamente robustas. Para ello es importante usar los algoritmos más recientes de cifrado. Para establecer TLSv1.2 (sólo en versiones OpenVPN a partir de 2.3.3) se debe utilizar la siguiente directiva en el archivo de configuración: 
Tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

Gracias a esta directiva, el servidor utilizará Diffie-Hellmann Ephemeral, de tal forma que si en algún momento un atacante captura la clave privada, las comunicaciones anteriores no podrán descifrarse por usar Perfect Forward Secrecy. También se utilizan las claves RSA para la autenticación, un cifrado simétrico robusto como AES-256 en modo GCM y un algoritmo de hash como SHA2.

  • Incorporar TLS-AUTH para que todos los paquetes que no posean la firma HMAC se bloqueen. Esta característica proporciona un nivel de seguridad adicional a la que proporciona TLSv1.2 porque mitiga posibles ataques DoS. El mecanismo consiste en cerrar la comunicación sin esperar a comprobar los certificados y así la carga de CPU es mucho menor.

  • Algunas recomendaciones adicionales de seguridad pasan por autenticar a cada cliente OpenVPN contra la PAM del servidor al que se conecta, utilizando su usuario y contraseña de acceso al sistema. 

Pero una vez más, estas medidas de seguridad se ven empañadas si un atacante consigue credenciales de acceso. Latch soluciona este problema de forma elegante. Permite controlar permanentemente los accesos al servidor OpenVPN, avisando de los intentos de acceso cuando el "pestillo" digital está cerrado. La instalación y configuración de Latch con OpenVPN es realmente fácil.

La única modificación necesaria en el servidor OpenVPN es habilitar la autenticación PAM (si no lo está ya) añadiendo la siguiente línea al archivo de configuración (ejemplo para Ubuntu 14.04 LTS):

plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so openvpn

Al intentar iniciar una conexión con el Latch cerrado, se generará el siguiente log en el servidor:

Logs de OpenVPN con Latch

Con el correspondiente aviso de la aplicación advirtiendo que se ha intentado acceder con el "pestillo" cerrado.

El proceso de instalación de Latch en este tipo de servidores es realmente rápida y sencilla, puesto que el proceso se encuentra perfectamente documentado. El uso de esta herramienta es recomendable tanto para los usuarios que se conectan al servidor como para los administradores que podrán proteger sus accesos de forma sencilla.

Conclusiones

Hace un tiempo perdí el smartphone, con todas las claves privadas en su interior. Quien encontrase el terminal podría haberlas extraído y usarlos para conectarse al servidor. La primera medida que tomé fue acceder vía SSH para detener el servidor OpenVPN, porque en ese momento no disponía ni de las herramientas ni del tiempo necesario para revocar los certificados. De esta forma evité que el potencial atacante se pudiera conectar, pero aun así hubo un tiempo de exposición que supuso un riesgo. Si Latch hubiera existido entonces, la ventana de exposición y por tanto el problema hubiera sido menor (o incluso nulo), puesto que el "pestillo" habría estado cerrado y aunque tuviera los certificados no podría haberse conectado.

Aunque Latch por sí solo no proporcione mayor seguridad, sí permitirá tener todos los accesos bajo control. Desde el punto de vista del usuario, le será útil para disfrutar de una mayor seguridad en banca o en el correo electrónico, pero para los administradores de sistemas podría suponer un elemento fundamental en entornos donde un acceso no autorizado tendría graves consecuencias.

Proteger servidores OpenSSH y OpenVPN (también con Latch) (I)

Sergio de Luz
sergio.deluz@redeszone.net

La seguridad en los métodos HTTP

miércoles, 18 de junio de 2014

Según describe el estándar HTTP 1.1, existen 28 métodos (o verbos) para la comunicación mediante el protocolo HTTP. Aunque muchos son desconocidos para la mayoría de usuarios (y administradores de sistemas) por no ser de uso habitual, existe un riesgo potencial si el administrador del servidor web no los tiene controlados. Veamos algunas técnicas comunes.

Entre los métodos más comunes, definidos en el RFC 2616, se encuentran:

  • GET: El método más común en la navegación web. Devuelve un código de respuesta y las cabeceras asociadas. Incluye el documento solicitado (habitualmente una página) en el cuerpo del mensaje.
  • HEAD: Idéntico al anterior, con la salvedad de que no devuelve el documento en el cuerpo de la respuesta. Se utiliza para extraer información sobre el documento solicitado o comprobar si existe sin necesidad de enviar y recibir el documento como tal.
  • POST: Pensado para publicar la información contenida en el cuerpo de la petición en el recurso donde se envía esa petición. La información que se publica y la forma de hacerlo depende completamente del servidor y el recurso. Hoy, el uso que se le da a este método es el de paso de parámetros de cliente a servidor (en muchas ocasiones para ficheros). La respuesta por parte del servidor es la misma que para una petición GET.
  • TRACE: Implementa la función de eco para los mensajes HTTP. El servidor responde en el cuerpo del mensaje con la misma petición que el cliente ha realizado. Se utiliza para comprobar que las peticiones son recibidas correctamente. Su finalidad es la de depuración.
  • OPTIONS: Este método presenta las opciones que el recurso o servidor dispone o requiere. De esto se puede obtener información como por ejemplo los métodos permitidos (en la cabecera ALLOW). 
  • CONNECT: Utilizado para crear la comunicación con un proxy HTTP (SSL).
  • PUT: Mediante este método es posible almacenar el documento que se envía como cuerpo de la petición en el propio servidor (físicamente en disco). Si el recurso al que se hace referencia en la petición no existe se creará y si existe se sobrescribirá.
  • DELETE: Al igual que el método PUT, este verbo afecta directamente al recurso al que se hace la petición. Tiene la capacidad de eliminar el elemento y dejar al servidor sin ese recurso. 

El resto de verbos (menos usados) son PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK (RFC 2518), VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY (RFC 3253), ORDERPATCH (RFC 3648) y ACL (RFC 3744).

PUT y DELETE

A primera vista, dos de estos métodos pueden resultar críticos en el entorno web donde se encuentren habilitados. Tanto PUT como DELETE permiten interactuar directamente con recursos legítimos del sistema. El primero para crearlos (por ejemplo una web shell para controlar el servidor, o fichero modificado para conseguir desfigurar alguna web legítima) y el segundo para eliminar archivos o activos de, por ejemplo, una compañía. Encontrarse este tipo de configuración en servidores en producción no es demasiado común, pero aun hoy no es extraño localizarlos. Para demostrarlo, basta con hacer consultas avanzadas sobre los motores de búsqueda, o basarse en las respuestas a las peticiones OPTIONS.

Ejemplo de petición y respuesta OPTIONS usando el complemento RestClient de Firefox

Este método devuelve información del servidor, pero esta información no tiene que ser ni completa, ni veraz. En ocasiones se mostrará una cabecera ALLOW con métodos HTTP permitidos, lo que no quiere decir que estos métodos estén implementados. Es decir, a pesar de que el verbo OPTIONS indique que se admite un método concreto, al utilizar este método es muy posible que retorne un código de error, ya sea de no implementado (501), no encontrado (404), etcétera.


Ejemplo de volcado del paquete de petición y respuesta con verbo OPTIONS

Y en otras ocasiones ocurrirá lo contrario, la cabecera ALLOW de la petición OPTIONS no mostrará métodos que realmente están permitidos e implementados... aunque luego es posible su ejecución. En resumen, no se deben descartar los métodos que no estén reflejados en esa cabecera.

TRACE y ataques XST

Además de PUT y DELETE (peligrosos si no se tienen completamente controlados) no hay que olvidar el método TRACE, en principio "inofensivo".

Ejemplo de volcado del paquete de envío y respuesta con verbo TRACE

Como ya se observa en la imagen, este método devuelve como cuerpo las cabeceras de la petición del cliente, incluyendo la cabecera Cookie que (según entornos) puede resultar crítica si existe una sesión establecida con el servidor. La combinación de este verbo HTTP con un fallo "Cross Site Scripting" en la aplicación web puede acabar en un robo de sesión de usuario, incluso si las Cookies han sido establecidas como HttpOnly. Este ataque es conocido como "Cross Site Tracing" o XST.

El ataque consiste en, cuando se inyecta código JavaScript explotando la vulnerabilidad XSS, realizar una petición con el método TRACE al propio servidor y enviar el cuerpo de esta respuesta al propio atacante por la vía que sea más cómoda. El contenido devuelto incluirá la cabecera Cookie con sus valores, tenga el flag que tenga. Un ejemplo de código JavaScript que es posible inyectar se muestra en la imagen siguiente, aunque en vez de enviar la respuesta a un servidor propiedad del atacante, se muestra en un mensaje "alert" como prueba de concepto.


Ejemplo de código JavaScript para inyectar y explotar un fallo XST


Aunque lo cierto es que hoy los navegadores más modernos ya bloquean este tipo de peticiones para evitar específicamente este ataque. Pero tampoco hay que olvidar que existen otras alternativas a JavaScript para realizar peticiones TRACE como Flash, Applets Java, etcétera. Con ellos se puede llegar a conseguir el mismo resultado eludiendo los bloqueos del navegador.

Desde el punto de vista del servidor, la manera obvia de evitar estos problemas es, cómo no, reducir la superficie de ataque deshabilitando aquellos métodos que no sean útiles para el entorno concreto, y controlar exhaustivamente los que sí se estén utilizando. Faast, el servicio de pentesting persistente, monitoriza este tipo de configuraciones en los servidores web y analiza cualquier método HTTP inseguro que pueda estar habilitado o implementado.

Ioseba Palop
ioseba.palop@11paths.com

Para qué sirve el Attack Surface Reduction en EMET

lunes, 16 de junio de 2014

Durante 2013, fue necesario "detener" la locura de exploits y problemas de seguridad que aparecían en el plugin Java que utilizan la mayoría de los navegadores. Casi todos acabaron desactivándolo por defecto. Pero Java no es el único culpable de las vulnerabilidades a través del navegador. EMET incorpora ahora una interesante funcionalidad llamada Attack Surface Reduction (ASR) que puede suponer una importante mejora para la seguridad de, no solo Internet Explorer en particular, sino de cualquier programa en general.

El origen de la idea

Hoy por hoy, el problema con los exploits no se encuentra tanto en los navegadores como en los plugins que utilizan. Suelen ser los culpables de los graves problemas de ejecución de código arbitrario con solo visitar una web. Es cierto que cada cierto tiempo, se encuentran nuevas vulnerabilidades que permiten ejecutar código en el sistema por culpa del navegador en sí, pero incluso para llegar a esta fase, deben eludir ciertas medidas de seguridad. Y para eludirlas se apoyan en los plugins. Por ejemplo, para conseguir eludir ASLR es común utilizar librerías de plugins comunes (Flash, por ejemplo) para "orientarse" en memoria y ejecutar un exploit de forma eficaz en el sistema. O a veces, ocurre que se actualiza el navegador, pero no los plugins asociados. La exposición del usuario sigue existiendo entonces.

Pero, por mucho que se aconseje su desactivación, no se puede pretender vivir sin algunos plugins. Las páginas legítimas los necesitan. Así que es necesario utilizar herramientas que permitan crear listas blancas o negras. Y ni aun así se estaría bien protegido. Algún atacante podría perpetrar ataques de tipo watering hole, esperando intentar explotar una vulnerabilidad en una web de uso habitual pero comprometida.

¿Pero no se podía ya evitar los plugins desde las zonas de internet Explorer? No era fácil. En varias ocasiones se demostró que las opciones que parecían lógicas para evitar la ejecución de Java en el navegador, no conseguían de verdad deshabilitarlo en todas las circunstancias.

También estaban los kill bits... pero eran difíciles de activar, y no dejaban de estar pensados como sistemas de mitigación. Aunque en los últimos tiempos, muchas de las actualizaciones de seguridad de Microsoft se dedicaban activamente a activar los kill bits de plugins para el navegador permanentemente.

Sentadas estas bases, aparece Attack Surface Reduction en EMET para intentar evitar que cualquier programa sea capaz de cargar cualquier plugin, desde sus fundamentos: impidiendo las llamadas a librerías DLL.

EMET al rescate

Attack Surface Reduction es una nueva funcionalidad de EMET, introducida en su versión 5. Si EMET comenzó como un proyecto para detener los "trucos" usados por atacantes para hacer que funcionasen los exploits, (bloquear los intentos de eludir DEP, ASLR, y otros métodos comunes de explotación) desde hace algún tiempo ha crecido en funcionalidad y potencia:

  • Ya es también una herramienta de certificate pinning para Internet Explorer
  • Es además un sistema de bloqueo selectivo de plugins y DLLs para programas... aunque todavía le queda mucho que mejorar, esto es el ASR. 

Cómo funciona

Visualmente, se debe marcar la opción en el panel de EMET para un programa concreto. Hay que pensar en ASR como un sistema que impide que un proceso cargue ciertas DLL, OCX o cualquier complemento, lo que pueda dar más juego del que en principio se piensa.


En esta pantalla se le indica a EMET que vigile un proceso con ASR


Luego será necesario ir al registro, y configurar a mano los módulos que se quieren bloquear. La organización habitual de EMET consiste en asignar un CLSID aleatorio a una aplicación. Dentro de ella, la rama contendrá la configuración específica. Se encuentra en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET\_settings_\. Ahí se creará una rama con el nombre del programa y su CLSID. Más arriba (por encontrarse en orden alfabético) se podrá comprobar que existe otra rama con ese mismo CLSID y la configuración correspondiente al programa en su interior. Por ejemplo la de Internet Explorer será:

Configuración interna de ASR para Internet Explorer en EMET

Ahí se encuentran la cadena "ASR" (con valor 1 si se ha activado en el panel gráfico de EMET) y "asr_modules". Esta puede contener, separados por ";", los módulos que no se quieren cargar cuando se ejecute el programa. EMET ya viene configurado de forma predeterminada con la opción de impedir que Internet Explorer cargue npjpi*.dll, jp2iexp.dll, vgx.dll y flash*.ocx. Pero solo en las zonas 1, y 2, que se corresponden con Local (0), Intranet (1), Sitios de confianza (2), Internet (3), Sitios no confiables (4). O sea, el valor "asr_modules" mantiene una lista de librerías que están prohibidas para ese proceso, mientras que para Internet Explorer, existe el valor "asr_zones" que marca las excepciones según las zonas. Es mejor ver la imagen para entenderlo. Las librerías prohibidas de forma predeterminada son:

  • npjpi*.dll y jp2iexp.dll: Relacionadas con Java. 
  • vgx.dll: El procesador de gráficos de vectores VML
  • flash*.ocx: Flash.

Así, la configuración por defecto permitiría estas tres tecnologías en las zonas de confianza e internet y las bloquearía en el resto. Sería posible eliminar o añadir tecnologías bloqueadas y hacerlo más granular añadiendo dominios a las zonas tradicionales.

Para Office (o cualquier otro programa), es más sencillo aún, porque no se ofrece el concepto de zonas de bloqueo ("asr_zones"). Así, por ejemplo solo se indica que a Word se le prohíbe cargar Flash en su interior (con "asr_modules"). Esta es la configuración por defecto:

Configuración interna de ASR para Word en EMET


Cuando el navegador intente activar una web con  un plugin (Flash en el ejemplo) que cae sobre la zona correspondiente y bloqueada, aparecerá un mensaje de este tipo en EMET.


Pero esto puede llevarse a cabo con cualquier programa. Lo que abre la posibilidad de bloquear selectivamente la carga de DLLs en cualquier proceso. 


Sergio de los Santos
ssantos@11paths.com
@ssantosv

Proteger servidores OpenSSH y OpenVPN (también con Latch) (I)

viernes, 13 de junio de 2014

Latch nació de la idea de evitar que posibles atacantes pudieran acceder a nuestros servicios aunque dispusieran de las credenciales de inicio de sesión. De esta forma, es posible controlar cuándo se puede acceder a los diferentes servicios como banca online, correo electrónico, redes sociales y blogs incluso si un atacante conociera la contraseña. ¿En qué mejora Latch la seguridad de servicios con OpenSSH y OpenVPN? En esta entrada se cuenta la experiencia de cómo se protegen los servidores OpenSSH y por qué Latch podría resultar útil.

Protegiendo OpenSSH

OpenSSH es el servidor SSH más utilizado en el mundo. Proporciona acceso a través de terminal un equipo para administrarlo de forma remota y segura. Además permite hacer "SSH Tunneling" para cifrar cualquier protocolo desde el equipo cliente hasta el servidor.

Al trabajar con OpenSSH, algunas opciones fundamentales de seguridad para proteger el servidor pasan por: elegir la versión dos del protocolo, cambiar el puerto por defecto, deshabilitar el login como "root" del sistema, crear una lista blanca con sólo determinados usuarios, elegir un número máximo de autenticaciones antes de desconectar la sesión y reducir el tiempo de introducción de la contraseña...

Por ejemplo, para reducir el número de intentos de conexión se debe usar el módulo recent del cortafuegos iptables. Con esta característica, es posible bloquear los intentos de conexión desde una determinada IP que ha intentado conectarse varias veces de forma fallida. Una mejora de seguridad muy importante es autenticarse a través de una pareja de claves RSA. Cuando se obliga a autenticar a los usuarios mediante RSA, el acceso estará protegido contra ataques de diccionario o fuerza bruta.

Sin embargo, todas estas medidas de seguridad se vienen abajo si, por algún motivo, un atacante conoce las credenciales o tiene en su poder la clave RSA. No es difícil imaginar un escenario en el que el usuario pierde las contraseñas, o un dispositivo donde se almacenan las claves privadas. Hasta ahora, una posible solución a este problema pasaba por el conocido "port knocking". Gracias al "golpeo de puertos" podríamos abrir el cortafuegos a los accesos SSH a través de una determinada secuencia preestablecida de intentos de conexión a puertos. Aunque eficaz, en la práctica es bastante incómodo puesto que se debe utilizar knock para golpear los puertos y que se abra el utilizado por SSH, después utilizar el servicio SSH, y por último realizar otro golpeo para dejarlo en su estado original. Otros puntos débiles de "port knocking" es "recordar" la secuencia de puertos a utilizar. Acceder desde un terminal móvil al servidor SSH, podría resultar poco práctico.

¿Qué ofrece Latch?

Mensaje de bloqueo cuando se intenta acceder con el pestillo cerrado
Una solución para añadir seguridad en servidores SSH es Latch.roporciona una forma elegante de solucionar los accesos no legítimos a un servidor. Esta herramienta simplifica al máximo el intento de evitar que un atacante con las credenciales pueda acceder al servicio protegido. Con el "pestillo" digital cerrado, aunque un atacante conozca nuestras credenciales, no podrá acceder. Además, es posible pedir de forma obligatoria una clave de un solo uso (One Time Password) cada vez que se acceda. De esta forma el atacante no solo tendrá que conocer o tener en su poder las credenciales, sino que también tendrá que conocer la clave generada aleatoriamente por Latch para iniciar sesión.

La instalación y configuración de Latch para OpenSSH es muy sencilla, ni siquiera se debe modificar el archivo de configuración de OpenSSH. Cuando un usuario intenta entrar en el servicio con el "pestillo" cerrado, se enviará un aviso al terminal móvil indicando que alguien ha intentado acceder. Además, desde el panel de control de Latch se podrá comprobar el intento de intrusión. Otra característica con la que cuenta este panel de control es la posibilidad de ver el número de claves OTP que se han generado para acceder al servicio.

Panel de administrador desde donde se pueden controlar los intentos de acceso


La facilidad con la que se puede bloquear y desbloquear el servicio es realmente simple: basta con arrastrar un interruptor disponible en la app para cerrar el servicio. Todo ello con una instalación rápida y fácil. Latch se ha convertido en una herramienta fundamental para proteger los accesos a servidores en Redes Zone, sin necesidad de configuraciones complejas con iptables y además con un uso muy intuitivo.


Proteger servidores OpenSSH y OpenVPN (también con Latch) (y II)


Sergio de Luz
sergio.deluz@redeszone.net

Orientando el pentesting hacia un ataque APT: Correos electrónicos

miércoles, 11 de junio de 2014

La seguridad de las empresas depende de muchos factores y ya se sabe que el eslabón más débil suele ser no tanto el servidor como el usuario. Con este enfoque, el pentesting debería evolucionar y llegar a combinar el proceso de intrusión "habitual" con la información recopilada sobre los usuarios. ¿Por qué no añadir a un proceso de hacking ético pruebas que simularían un ataque del tipo APT, (Advanced Persistent Threat) contra el objetivo con la idea de retroalimentar las dos vertientes del proceso? El resultado podría ser mucho más provechoso.

Un test de intrusión "tradicional", ofrece la posibilidad de realizar ataques controlados a sistemas expuestos, pero lo cierto es que si un atacante real quiere vulnerar una organización, quizá el camino más corto consista en el ataque a los empleados. Y para que este camino más corto sea aún más efectivo, debe recopilar información sobre ellos, obteniendo una visión global que aumente las posibilidades de éxito. Así, el concepto de pentest se expande, ya no solo a todo lo que se exponga en la red, sino además a la necesidad de concienciar y poner controles para que los datos "filtrados" sobre empleados no estropeen la inversión en seguridad.

Cuando en un proceso de hacking ético se han realizado pruebas de pentesting externo a la organización, los resultados han podido ser utilizados para pruebas de APT o ingeniería social y viceversa. En realidad, ambos procesos se encuentran unidos de alguna manera y no deberían ser tomados como independientes. Un atacante no lo hará en el mundo real.

Un APT es un concepto complejo que puede que se haya desvirtuado, pero en general, es un conjunto de ataques informáticos que suceden de una manera continua sobre una persona o un conjunto de personas de interés. El fin es conseguir la información de valor de las que esta persona o conjunto de personas disponen por sí mismas o en su entorno. Existen tres vertientes en un APT:
  • Es un proceso avanzado. Aunque no siempre se utilizan técnicas avanzadas para lograr los objetivos, en muchas ocasiones se necesitan varios desencadenantes o condiciones para que el ataque tenga éxito.
  • Es un proceso persistente. Se hace un seguimiento del objetivo, intentando monitorizar acciones, clasificar comportamientos en el mundo digital, incluso fuera de él, y realizando un profiling de la persona.
  • Es un proceso basado en las amenazas del mundo digital. Un usuario está expuesto a más amenazas cada día y los empleados de una organización no son una excepción.
Atendiendo a esta definición, el resultado de un pentesting podría considerarse como una entrada muy útil para un proceso de ataque tipo APT: metadatos, tipos de software que se utiliza en una organización, correos electrónicos de usuarios, correos electrónicos personales, direcciones IP, números de teléfono, etcétera... Por sí solos pueden no suponer un gran descubrimiento para el informe de un test de intrusión, pero es información valiosa para potenciar un APT.

Ejemplos del mundo real

En un pentest clásico, es habitual conseguir cuentas de correo para aplicar fuerza bruta o ataques de diccionario contra un servicio. Esta prueba suele hacerse usando un diccionario de contraseñas no seguras, para asegurar que no se protegen las cuentas con contraseñas débiles. Para conseguir correos electrónicos en Internet se pueden utilizar diversos medios: el primero son buscadores como Google, Bing o Exalead. Para facilitar la tarea existen varias herramientas como TheHarvester o Maltego.

Ejemplo de salida de TheHarvester

Aunque en la imagen no se pueda visualizar se han obtenido más de 30 resultados. Esta puede ser una buena manera de comenzar con la recolección de cuentas de usuario. Pero es que, además, esta es información muy valiosa para un profiling de empresa orientándolo a un ataque del tipo APT.

Otra de las vías para la recolección de correos electrónicos y cuentas de usuario es la búsqueda a través de los servidores de claves PGP. Esta plataforma proporciona mucha información interesante para poder utilizar y personalizar a los usuarios. Por ejemplo, realizando una simple búsqueda por dominio se obtiene lo siguiente:

Ejemplo de información sobre claves PGP

Donde se concluyen varios datos interesantes:
  • El usuario y el correo electrónico.
  • El nombre completo de la persona. En este caso, el nombre será real la mayoría de las veces, puesto que un usuario configura su clave pública con su nombre verdadero para que pueda ser encontrado en estos servidores.
  • Puesto de trabajo en la organización. Algunos usuarios así lo hacen.
  • Correo alternativo. En algunas ocasiones los usuarios utilizan la misma clave PGP para varios correos, por lo que será posible encontrar cuentas genéricas de Gmail, Hotmail, o el ISP contratado. Esto permitirá relacionar a una persona entre su correo profesional y su correo personal. De ahí se puede saltar hacia las redes sociales y otros entornos de interés. 
Si se elige una búsqueda avanzada en un servidor de claves, es posible extraer más información aun. Por ejemplo, obtener información sobre si la clave está revocada o si la confirman otros usuarios. Este es un punto interesante: conocer con quién se relaciona una persona es importante puesto que, para la preparación de un ataque más sofisticado del tipo APT, permite disponer de diferentes caminos alternativos para poder llegar al objetivo final.

Ejemplo de "círculo de confianza" en claves PGP

En Eleven Paths estamos realizando un plugin para obtener este tipo de información en nuestra herramienta de pentesting persistente Faast. El objetivo es que nuestra visión global de la seguridad de una organización no se quede simplemente en el estado de los servicios expuestos, malas configuraciones, vulnerabilidades en aplicaciones, etcétera. Nuestra idea es ofrecer un informe de todo lo que puede afectar a una organización además de los elementos que un atacante pueda utilizar para dañar la imagen de una empresa. El ejemplo expuesto, centrado en el correo electrónico, es una muestra de cómo ampliar el campo de acción de un pentest y enriquecerlo con datos personales "descuidados" en la red.

Plugin de Faast

En la imagen se puede visualizar un ejemplo de salida de nuestro plugin en desarrollo. Nuestro sistema Faast pronto proporcionará esta información, pero lo más importante es que Faast es capaz de brindar más información utilizable en estos procesos. En las pruebas que vamos realizando en entornos controlados se encuentran nombres de personas, DNI, usuarios, software asociados a máquinas de ciertos usuarios, sistemas operativos, etcétera. Esta información resulta muy valiosa como punto de partida para un ataque de tipo un APT.

Pablo González
pablo.gonzalez@11paths.com

The weakest hand (on security)

martes, 10 de junio de 2014

Users have much more at stake in the digital world than ever before. Arguably as much or more, even, than our employers: our personal and professional reputations, livelihood, assets, family, friendships and homes. Yet, most of us use little more than an antivirus, desktop firewall, and whatever has been built into our routers and implemented for us by our local ISPs to safeguard all of this. Meanwhile, the businesses we work for have hired experts to monitor the organization, its systems, applications, and devices around the clock. They invest in layered defenses, analytics, forensics, intelligence and so forth. But, they do little to protect users when we leave the office.

The weakest link

Finding Nemo. Source: imdb.com
Whether or not they realize it, organizations depend on us, also around the clock, to defend both personal and enterprise interests. Attackers can leverage vulnerabilities in our personal digital lives to get at our employers, and vice versa; and often, this is precisely what they do. Users are an easy mark. We are the weakest link, "the fish" as they say at the poker table susceptible to phishing, watering hole, and social engineering. We are error prone, willing to sacrifice security for productivity gains, often lazy, or resistant to security policy. To make matters worse, when we leave the office we haven’t got the resources our employers have; and so, we don’t take the precautions that might otherwise help our organizations minimize the risks associated with attacker-leap-frogging from the personal to the professional.

Just as with businesses, the overall level of risk to which we, the fish, are exposed is increasing, and we ought to dedicate more care and awareness to safeguard our personal digital lives, the same way our employers do to protect their assets. But, we don’t (at least not the majority of us) and so long as we don’t do enough to protect ourselves we will continue to be fish.

Long live the antivirus?

There´s a paternalistic aspect to securing users and consumers that, though well intentioned, may ultimately have caused this problem. I am referring to the very global security policies and measures to which our organizations subject us. Take the antivirus as an example. The antivirus is practically ubiquitous in desktop systems of all large and medium enterprises, and its presence is enforced; sometimes even on visitors and contractors, through policy, and complex and expensive network admission control systems. Enterprises have been singing the praises of antivirus in this way, both explicitly and implicitly, even when "fake-av" aka "rogue antivirus" came along in 2008 to sound the death knell on the venerated, but tired bluff of recursive decompression, signatures, heuristics, and so forth.


Virustotal statistics

Enterprises and households could have saved themselves numerous headaches, by focusing their time and budgets on alternatives to the antivirus, years ago. At least since 2007, when studies began to demonstrate that the trusted software was only effective 20-30% of the time. Instead, we all soldiered on, long after the tool was rendered more or less useless. It survived, thanks in no small part to organizations that insisted on playing this losing game, throwing good money after bad on a losing hand. The thing is, antiviruses have become largely irrelevant to attackers, who now avail themselves of novel vectors of entry inaugurated by the mobile-cloud-social era in which we all live.

But, let’s set aside the irrelevance of antiviruses, and their technical limitations. (Antivirus technology has always imposed significant system performance issues, the risk of false positives, and even an additional attack target due to its kernel level access). Their ineffectiveness is not just limited to the underlying technology, but also due to the lack of user involvement and understanding. How many users know, or even bother to tune the software to their system? How many are aware that it does not adequately address zero day threats, or most malware on websites, phishing, advanced malware and Trojans, and so on? Is it any wonder that users continue to download free and purchased antivirus software? Is it any wonder they think themselves secure once it’s installed?

Recently, Symantec officially proclaimed the death of the antivirus through a Wall Street Journal interview. For large manufacturers antiviruses continue to generate a lot of revenue, but the business proposition is no longer acceptable. It is a saturated market, in which top firms compete against cost free alternatives, including Windows Essentials, fight to displace competitors for miniscule changes in enterprise B2B market share, and depend largely on renewals. For such companies the shift to a replacement technology could not have come soon enough. Enter sandboxing and automated malware analysis engines, which overcome many of the shortcomings of the antivirus, including performance and detection of advanced threats.

Involve the user

What such technology does not address, however, is the fundamental need to involve the user in securing their digital identity. Sandboxing may be a solid step forward in detection. But, it is also a toolset which promotes continued reliance on a hackneyed, cat-and-mouse updating model. Similar to antivirus technology, this new technical approach to defeating malware lulls users into the belief that they are supremely protected, even against zero day threats. Sandboxing combined with malware analysis may be big business. However, it may also be, that security technologies which do not engage and motivate users to take an active role in their own defense are of limited benefit.

Excessive attention focused on new, advanced detection and mitigation technologies will likely result in the same blowback of unprepared, ignorant, and vulnerable user populations, as traditional antivirus. We are still the "weakest link". Sandboxing doesn’t change that. But, times have changed; and like the skin of an expanding balloon our vulnerabilities are spreading out across an ever-widening attack surface: mobile, cloud and social. Systems, applications, and users are becoming increasingly difficult to secure; and global security policies and measures imposed across these surfaces are stretched thin.

Perhaps it is not the technology, but our focus which must shift, from global policies, toolsets, and procedures, to one that leverages the user’s help. After all, we bring our own advanced, mobile computing devices to work; we subscribe to cloud based storage systems, and upload and share company documents; we use professional and personal social networks, and leverage them to the benefit of ourselves and our employers, spin up new systems and servers, for trials, training and our own curiosity. It doesn’t require much imagination to see how our public and private lives have never been so intricately interwoven.

Data Leakage Worldwide: Common Risks and Mistakes Employees Make:
Shows the frequency with which corporate computers are used for personal use
Source: http://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/data-loss-prevention/white_paper_c11-499060.html

A quick review of some statistics show this intermingling is likely to deepen, that there are business incentives for it to happen, as well as significant business risks. According to Citrix, organizations predict that the percentage of BYO desktops and laptops will grow from 18-25%; Gartner says that by 2017, 50% of businesses will not supply employee computing devices; Deloitte adds that 69% of polled companies experience no technical support problems after implementing BYOD; despite the finding by Acronis that 80% of businesses do not provide education or training on BYOD.  In a 2012 survey, commissioned by Check Point, of 768 IT professionals in the US, Canada, UK, Germany and Japan 78% said there were more than twice as many personal devices connecting to corporate networks than there were two years before; and 47% reported that customer data was stored on mobile devices; 90% of which, according to Forbes, are used for email, calendar, shopping, banking and social.

Source: http://dreamscashtrue.com
The new digital polis involves a fusion of the private with the public, the personal with the professional, and requires organizations to change their perspective on securing systems, applications, users and other assets. This new view opens unprecedented opportunities to engage with us users (whether we are employees, partners or consumers). Organizations can become protagonists in our active involvement both within and without the workplace to secure ourselves, and thereby protect the enterprise. Currently, few security solutions help in this way. Most strive to do precisely the opposite: to minimize users’ roles in the security process. Rather than encouraging us to secure ourselves, these solutions lead us into taking foolish risks, shortcuts, and workarounds, making erroneous judgments and mistakes. In sum, we end up behaving like the weakest player at the poker table, the mark for all of our adversaries, the fish who, no matter what, always has the weakest hand.

Christopher Adelman 
christopher.adelman@11paths.com