Análisis del CVSS de ShellShock

Una de las vulnerabilidades más importantes del año sin duda ha sido ShellShock. En el artículo de hoy vamos a explicaros cómo funciona el sistema de evaluación de vulnerabilidades más extendido, el CVSS (Common Vulnerability Scoring System), haciendo uso de dicha vulnerabilidad.

Como ya sabéis la vulnerabilidad de ShellShock corresponde a un bug en Bash que afecta a sistemas UNIX, Linux y OS X que incorporan esta herramienta en su sistema. Dentro de la métrica CVSS podemos encontrar este bug dividido en dos ocurrencias: CVE-2014-6271 y CVE-2014-7169.

¿Qué es CVSS?

CVSS es una métrica para evaluar vulnerabilidades que nos reporta un valor, o conjunto de valores, que nos dan una idea del peligro que conlleva una vulnerabilidad.

Si buscamos el CVSS Score de las vulnerabilidades nombradas en la National Vulnerability Database (NVD) veremos que su valor es 10.

¿Cómo se utiliza?

CVSS utiliza tres métricas básicas para medir el alcance que puede tener una vulnerabilidad. Podemos verlas en la siguiente imagen para la CVE-2014-6271

 1. Métrica Base

Dentro de la métrica base tenemos evaluados aquellos parámetros que son constantes en el tiempo y el entorno. Dicha métrica se suele expresar como un vector.

Esto es lo que se conoce con el nombre de vector base y sería el siguiente:

CVSS v2 Vector (AV:N/AC:L/Au:N/C:C/I:C/A:C)

    AV: Vector de Acceso, es decir, la manera a través de la cual podemos acceder a la vulnerabilidad. En nuestro caso para explotar la vulnerabilidad podemos acceder desde cualquier red, no sólo en local (N:Network).
    AC: Complejidad de Acceso, es decir, la complejidad que requiere el atacante una vez ha accedido al sistema, en nuestro caso complejidad baja (L: Low).
    Au: Autenticación, es decir, cuantas veces debe autenticarse el usuario para poder hacer uso de la vulnerabilidad, en nuestro caso ninguna (N:None).
    C: Impacto de Confidencialidad, es decir, como afecta esta vulnerabilidad en cuanto a la confidencialidad. En este caso el impacto es total, porque podemos ejecutar cualquier código en el sistema, lo que conlleva acceso a cualquier archivo, rompiendo de manera completa la confidencialidad del sistema (C: Complete).
    I: Impacto de Integridad, es decir, como afecta esta vulnerabilidad en cuanto a la integridad. Al igual que en el caso anterior, tenemos acceso completo a modificar cualquier archivo de tal forma que se rompe este principio completamente (C: Complete).
    A: Impacto a la Disponibilidad, más de lo mismo, si podemos ejecutar en el sistema cualquier comando podemos echar abajo servicios entre otras cosas. Por tanto afecta a la disponibilidad de manera completa (C: Complete)

Normalmente a la hora de evaluar una vulnerabilidad mediante el CVSS tan sólo se suele valorar la métrica base, ya que las dos siguientes son opcionales y cambiantes en el tiempo. En caso de la vulnerabilidad que tratamos aquí no han sido evaluadas, pero no obstante vamos a explicar cada uno de los campos.

2. Métrica Temporal

Esta métrica varía en el tiempo, en ella podemos evaluar varios parámetros como vemos a continuación:

Explotabilidad: se refiere a si existen exploits y si están disponibles, o sólo existen pruebas de concepto, si los exploit sólo existen en X sistemas o por el contrario existe código multiplataforma.
    Nivel de curación: hace referencia a la existencia o no de soluciones para corregir dicho bug, si estas provienen de fuentes oficiales o anónimas, o incluso si son soluciones temporales.
    Confianza del anuncio: trata de evaluar la veracidad en la existencia de dicha vulnerabilidad, si ha sido confirmada por fuentes oficiales (el responsable del software o sistema) o sólo por grupos independientes de seguridad.

A continuación os muestro la evaluación que podríamos hacer de esta métrica para la CVE-2014-6271.

Explicación: La explotabilidad es alta ya que existen numerosos exploits documentados, en cuanto a la cura también existen parches de fuentes oficiales para todas las plataformas afectadas y en cuanto a su confirmación, está más que confirmada su existencia.

3. Métrica del entorno

Esta métrica también varía en el tiempo, en ella podemos evaluar varios parámetros relacionados al entorno al cual afecta la vulnerabilidad. Los vemos a continuación:

Daño colateral potencial: hace referencia al daño que puede ocasionar a terceros, como a personas, bienes físicos, la productividad o beneficios.
    Distribución de objetivos: aquí medimos la proporción de sistemas vulnerables en el entorno, se suele dar valor numérico entre 0 y 10; y se expresa en intervalos de mínimo y máximo.
    Modificadores de las subpuntaciones de impacto: aquí se trata del grado de afectación dentro de los objetivos de la seguridad como son Confidencialidad, Integridad y Disponibilidad. Es decir, mediante estos valores podemos medir cuan importante es para esta vulnerabilidad cada uno de estos parámetros.

A continuación os muestro la evaluación que podríamos hacer de esta métrica para la CVE-2014-6271.

Explicación: El daño colateral es enorme, ya que si se puede explotar esta vulnerabilidad en un entorno de una empresa, por ejemplo, podríamos hacer lo que quisiéramos. Datos de clientes que provoquen pérdidas económicas, proyectos de investigación en manos inadecuadas que roben ideas, etc.

En cuanto al número de sistemas afectados, estaréis de acuerdo conmigo que entre el 76% y 100% de sistemas han tenido que parchear dicha vulnerabilidad, desde el smartphone Android que llevamos en el bolsillo hasta el servidor linux que se utiliza en el trabajo.

En referencia a los modificadores en cuanto a Confidencialidad, Integridad y Disponibilidad; podemos decir que cualquiera de los tres objetivos de la seguridad son importantes en esta vulnerabilidad, de ahí su valor High.

Conclución

Una vez evaluados todos los parámetros y explicados cada uno de ellos, podemos recalcular el CVSS de la CVE-2014-7169 usando el propio sistema de cálculo que nos facilita NVD (CVSS v2 Calculator), y obtendremos el siguiente resultado:

El vector completo para CVE-2014-7169 quedaría de la siguiente forma:

CVSS v2 Vector (AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:OF/RC:C/CDP:H/TD:H/CR:H/IR:H/AR:H)

Espero que a partir de ahora entendáis mejor este sistema de evaluación de vulnerabilidades.

dejando al desnudo a tu conexión

Los fallos de seguridad están que no paran desde que Heartbleed alcanzó nuestras conexiones, tenemos que enfrentarnos a otra vulnerabilidad en el SSL,  nos puede desnudar nuestra conexión rompiendo su seguridad.
El problema de Logjam reside en el protocolo criptográfico llamado Diffie-Hellman que permite negociar una clave compartida para generar una conexión segura, para cada conexión.

El ataque permite bajar el cifrado a 512-bits, haciendo que sea fácil de romper comparado a 2048-bits, por lo que se puede realizar un ataque MITM.

Los navegadores ya están trabajando en parchear el problema, pero también se tiene que poner las pilas los Sysadmin, para ellos tenemos que seguir los siguientes pasos:

Lo primero reconstruimos nuestro grupo único de Diffie-Hellman, los navegadores recomienda 1024-bits, los investigadores 2048-bits pues que nos ponemos yo los he pasado a 4096-bits, veremos quien rompe eso 😉
?
1
   
openssl dhparam -out dhparams.pem 4096

Una vez creado nuestro nuevo DH vamos a reconfigurar nuestros protocolos y cifrados.

Desactivando SSLv2 y SSLv3

Apache:
?
1
   
SSLProtocol             all -SSLv2 -SSLv3

Nginx:
?
1
   
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;



Y priorizando el orden de carga de los cifrados, cargando del mas robusto al menor.

Apache:
?
1
2
3
   
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Nginx:
?
1
2
3
   
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;



Ahora para acabar nos queda reconfigurar donde esta nuestro nuevo archivo HD
Apache:
?
1
   
SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"

Nginx:
?
1
   
ssl_dhparam {path to dhparams.pem}

Después de reconfigurar nuestro servidor, tenemos que reiniciar el servicio para cargar los nuevos parámetros y comprobar que ya somos seguros, para ello disponemos de esta web para realizar los test.

https://weakdh.org/sysadmin.html

Durante unos días hasta que todo el mundo realice el parche y actualice sus navegadores hay que extremar las precauciones con las conexiones que realizamos.

Y este problema nos vuelve a surgir por en Estados Unidos en la década de 1990 que como vemos en el informe original en la era Clinton, donde se limita el tamaño de DH a los primeros 512-bits primos para que fueran fáciles de romper para las agencias americanas.

    To comply with 1990s-era US export restrictions on cryptography, SSL 3.0 and TLS 1.0 supported reduced-strength DHE_EXPORT cipher suites that were restricted to primes no longer than 512 bits.

Lo grave es además de afectar a HTTPS, afecta también a SMTP+StartTLS, POP3S, IMAPS y de estos afecta al 8.4% según los investigadores de las páginas que están en el top 1 millón, no quiero saber cómo afectará a las medianas y pequeñas…

Así que ya sabes si no te fías de si la página a la que estás conectada ha corregido el problema primero compruébalo con este test y si no te queda otra que conectarte antes de que se repare el problema y no estas en una conexión que consideres segura es mejor que uses una VPN para poder salir por un sitio más seguro.

Creando un túnel SSH con Nessus

Muchas veces a la hora de hacer una auditoría externa y tener algún sistema de protección exterior (Firewall, IDS…), se nos habilitan diferentes mecanismos para poder acceder dentro de la red que queremos auditar sin que su seguridad exterior se vea comprometida. Es muy común habilitar un túnel SSH para acceder al interior de la red local.

Hoy vamos a ver cómo aprovechar ese túnel para correr Nessus como si estuviéramos ubicados dentro de la red. Como sabéis, la versión gratuita de Nessus tan sólo nos permite escaneos a direcciones IP locales, sin embargo mediante el túnel vamos a conseguir utilizar esta herramienta frente a una IP pública, como si estuviéramos dentro de la red a auditar aún estando fuera de la misma.

Vamos a utilizar para ello un túnel SSH y la herramienta Proxychains de la cual tenéis un artículo en el blog sobre cómo trabajar con ella y Tor.

En el siguiente diagrama vemos el entorno en el cual vamos a trabajar:

La idea es crear un túnel SSH y haciendo uso de Proxychains reenviaremos todas las peticiones de nuestro PC (Nodo A) a través del túnel, de tal forma que Nessus va a pensar que está corriendo el scanner en la máquina intermedia (Nodo B) que sí está en la misma red del servidor a auditar (Nodo C). Los pasos a seguir son los siguientes:

Creación del túnel SSH con el nodo B.

Para crear el túnel previamente tenemos que tener habilitado en el nodo B el servicio SSH con nuestro usuario correspondiente y una regla en el Firewall que permita las peticiones desde exterior hacia la máquina B (natearemos el puerto 22 mediante Port Fowarding a la máquina B).

Con todo preparado pondremos a la escucha un puerto en la máquina local A, de tal forma que todo lo que se envíe a ese puerto se reenviará a través del túnel que crearemos contra la máquina B. Usaremos el siguiente comando:

sudo ssh –p 22 –N –D 8081 user@direccionIP_B

Tras introducir las credenciales oportunas podemos ver desde otra terminal como ya tenemos el puerto 8081 a la escucha en la máquina local A:

Instalación y configuración de Proxychains.

Para la instalacción de Proxychains simplemente ponemos:

sudo apt-get install proxychains

y nos vamos a editar su fichero de configuración /etc/proxychains.conf. Pondremos que todas las peticiones de los programas/servicios abiertos con Proxychains vayan al puerto 8081 de autobucle (127.0.0.1) donde está el túnel.

Comprobación del funcionamiento del túnel.

Pasamos ahora a comprobar si funciona nuestro túnel, para ello vamos a solicitar desde nuestra máquina local A la IP pública que tenemos. Vemos como aparece nuestra IP 95.x.x.x.

Sin embargo cuando pasamos la petición a través del túnel mediante proxychains vemos que nos da la IP del nodo B, por tanto nuestro túnel funciona correctamente.

,

Iniciando Nessus a través del túnel.

Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:

/etc/init.d/nessus stop

y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.

Una vez que tenemos todo funcionando ya podemos arrancar Nessus y llevar a cabo el escaneo de la máquina C en cuestión, sin necesidad de desplazarnos a la ubicación del nodo

Dejar claro que todas las pruebas se han llevado a cabo sobre dos redes propietarias y que como comentábamos en la nota legal, se hace con fines educativos.

Iniciando Nessus a través del túnel.

Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:

/etc/init.d/nessus stop

y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.

- See more at: http://hacking-etico.com/2015/06/12/creando-un-tunel-ssh-con-nessus/#more-4509

Fuzzing a una aplicación con zzuf

Introducción: ¿por qué fuzzing?

Cuando nos encontramos haciendo tareas de ingeniería inversa a una aplicación, una de las tareas más monótonas es la de enviar stuff (“cosas“) a un punto de entrada de la aplicación para ver cómo responde. En función de nuestro objetivo (descubrir buffer overflow, format string…), el tipo de stuff que enviemos variará, no sólo en su contenido si no también en su cantidad, sobre todo si lo que buscamos es provocar un buffer overflow. Y cuando hablamos de cantidad, lo ideal es hacer fuzzing en lugar de hacerlo con peticiones manuales.

En el caso de los desbordamientos, más que el tipo de contenido lo que se busca es la cantidad, y aquí tenemos varias opciones de enviar “cosas” a la aplicación; de forma manual, mediante ejecución de instrucciones Python / Perl desde la consola, creándonos nuestro propio script o utilizar herramientas ya desarrolladas para este tipo de tareas; fuzzers.

En este artículo veremos distintas opciones, para finalmente presentar y ver algunos ejemplos de zzuf, el fuzzer del que vamos a hablar en este post.
Escenario

Para explicar el funcionamiento de un fuzzer, y de zzuf concretamente hemos preparado el siguiente escenario; una aplicación remota vulnerable a buffer overlflow (basado en stack), accesible a través del puerto TCP/9999.

Ese puerto a la escucha es nuestro único punto de entrada. Podríamos escanear el puerto, descubrir versión del servicio y buscar si hay alguna vulnerabilidad desconocida. En caso negativo, no nos queda otra que enviar cosas al puerto y ver cómo responde la aplicación.

En este caso, haciendo netcat al puerto conseguimos acceso a la aplicación, donde nos indica que podemos obtener ayuda escribiendo el comando HELP.
Peticiones manuales a la aplicación

Obviamente nuestra intención es otra, es encontrar qué tipo de información tenemos que enviarle y en qué cantidad. La explotación de la vulnerabilidad de buffer overflow no entra en el contexto de este artículo, lo explicaremos más adelante en otro, pero se puede ver marcado en amarillo una serie de comandos de la aplicación. Estos comandos son los usaremos para enviar nuestro stuff e intentar provocar el BO (buffer overflow).

Como decíamos en la introducción al artículo, podemos hacer peticiones manuales. En la imagen anterior al comando HELP le hemos añadido una serie de caracteres, primero dígitos y a continuación acompañados de varios caracteres “A“. La respuesta de la aplicación es que ese comando no está implementado. Podríamos seguir probando con más cantidad, con otros comandos, pero como os podéis imaginar esto llega a ser bastante tedioso y monótono si lo hacemos manualmente.
Más cantidad con Python / Perl

Para facilitar esta introducción de información a la aplicación, para forzar algún tipo de error que provoque por ejemplo en crash en la misma, podemos hacer uso de lenguajes como Python o Perl desde la propia consola. En nuestro caso estamos utilizando Kali como máquina “atacante”.

Así que una forma muy simple podemos mandar más cantidad de información al puerto TCP/9999 de la aplicación. Supongamos que queremos enviarle 200 caracteres “A”. En lugar de escribirlos, podemos hacer uso de Python para generar esos caracteres y la salida enviarla con netcat al puerto de la aplicación.

Con un simple comando “echo” podríamos enviar la salida de éste a “netcat”, pero tendríamos el mismo problema:

    echo “HELP 1234567890AAAAAAAA” | nc 192.168.10.145 9999

Sin embargo podemos concatenar la salida de una instrucción Python al comando “echo”.

Como se puede ver en la imagen, enviar una gran cantidad de datos a una aplicación remota con Python es realmente sencillo. En el último ejemplo hemos enviado 5000 caracteres “A” y podemos observar un comportamiento distinto, en cuanto a respuesta de la aplicación, que cuando se enviaron 50 o 500 caracteres “A”. Interesante.
Utilizando un fuzzer: zzuf

Por último, veamos cómo hacerlo con el protagonista real de este artículo, un fuzzer llamado zzuf, que nos va a ayudar en nuestra labor a la hora de hacer fuzzing a la aplicación y que además altera de forma aleatoria el contenido de lo que enviamos. Recordad que en ocasiones no es tan importante la cantidad si no la calidad de lo que se envía.

De hecho vamos a utilizar zzuf justo para eso, para alterar de forma aleatoria la información que vamos a enviar, ya que hemos visto que generar contenido es muy sencillo con Python o Perl.

Así que, de forma sencilla, vamos a generar un fichero txt con Python que contendrá el comando “HELP ” seguido de una gran cantidad de caracteres “A”, por ejemplo 500.

Ya tenemos un fichero llamado fuzz.txt.

Ahora con zzuf lo que vamos a hacer es alterar aleatoriamente el contenido del fichero, veamos un ejemplo:

En la imagen anterior, en la primera ejecución vemos cómo altera aleatoriamente la salida del “cat” del fichero. Pero atención, hay un problema y es que también ha alterado el tercer byte de nuestro fichero, dejando el comando “HELP” en “HENP“, lo cual no nos interesa.

Zzuf tiene esto en cuenta y permite con el parámetro -b indicar a partir de qué byte empieza a alterar. En la segunda ejecución de zzuf hemos indicado -b6- para que empiece a partir del sexto byte, para que no modifique la palabra HELP.

También podemos indicar el ratio de modificación del contenido. Por ejemplo, si queremos que modifique el 50% del contenido haremos uso del parámetro -r de la siguiente forma:

    zzuf -b6- -r0.5 cat fuzz.txt

Hasta aquí este artículo sobre fuzzing con zzuf. Espero que os haya resultado útil y entendáis la facilidad con la que se puede generar stuff para enviarla a una aplicación remota, siempre teniendo en cuenta en qué momento nos interesa cantidad o calidad (zzuf).

Investigación de ataque a un WordPress

Introducción de un ataque a un WordPress

Hoy he tenido el placer de participar, por tercer año consecutivo, como ponente en la V WordPress Meetup Córdoba y al igual que en años anteriores, he disfrutado mucho, no solo durante mi charla (Investigación de ataque a un WordPress) sino durante toda la jornada, con charlas muy interesantes en dos tracks diferentes. ¡Lástima haberme perdido algunas de las charlas! Pero en dos tracks a la vez no se podía estar.

En cuanto a mi charla, se trataba de explicar un caso real de un ataque a un WordPress y dar algunos consejos prácticos y sencillos para poder hacer algunas labores de investigación en caso de sufrir un ataque.

La Web investigada había sufrido un ataque mediante el cual los atacantes habían conseguido subir una puerta trasera, en forma de una C99 Shell, aprovechando una vulnerabilidad de tipo “Remote Arbitrary File Upload” en un plugin del WordPress.

Como consecuencia, el servidor comprometido pasó a formar parte de la StealRat Botnet enviando una gran cantidad de spam con contenido variado; venta de productos farmacéuticos, venta de viagra y pornografía. Este envío masivo de spam originó que el servidor entrara en listas negras de reputación IP así como en servicios de bloqueo por spam.

Tras analizar el sistema de ficheros se descubrieron varios ficheros php con código malicioso ofuscado que fueron limpiados. En la siguiente imagen podemos ver uno de los ficheros infectados con código ofuscado

 A continuación se pueden ver algunos de los archivos maliciosos e infectados.

 La importancia del fingerprinting

La finalidad de la charla, y de este artículo, es de poder aportar un par de consejos prácticos para la localización de evidencias tanto del ataque como de los accesos anteriores de los atacantes rastreando el sitio Web con la intención de hacer un fingerprint del CMS (WordPress) y plugins instalados, entre ellos el plugin vulnerable.

Para esta tarea de descubrimiento de CMS utilizado y plugins instalados, es necesario que el atacante ejecute una serie de tareas. Existen muchas herramientas automatizadas que tienen como objetivo el descubrimiento del CMS, su versión, plugins y versiones de éstos.

Son varias las técnicas usadas por estas herramientas, desde una simple consulta a cabeceras HTTP en la respuesta del servidor, una consulta a etiquetas HTML (<meta name=”generator”…>) o la existencia del famoso readme.html en la raíz del sitio, hasta realizar “dirbusting” (descubrimiento de URL mediante fuerza bruta) para comprobar la existencia de un plugin en el WordPress.

La técnica más efectiva es la de dirbusting, pero también la que genera más “ruido” desde el punto de vista de seguridad. Un WAF, IPS o plugin de seguridad de WordPress podría aplicar un lockout tras un número determinado de accesos a recursos no existentes (error 404, not found).
¡Los archivos logs (error_log y access_log) sí son útiles!

Si nos centramos en analizar esos accesos no legítimos que intentan identificar nuestro WordPress y sus plugins deberíamos de apoyarnos en los registros de los sistemas que componen nuestra infraestructura Web. Si tenemos acceso a los logs del WAF o IPS, genial, pero si se trata de un servidor Web compartido a lo máximo que podemos aspirar es a los logs del propio servidor Web. Salvo que se trate de una incidencia grave y podamos solicitarle a nuestro proveedor de servicio de hosting los logs de sus sistemas de seguridad.

El fichero error_log nos aporta menos información que el access_log

 Sin embargo del access_log sí podemos extraer información importante y para ello vamos a hacer echar mano de los códigos de respuesta HTTP (2xx, 3xx, 4xx, etc.). Como sabéis estos códigos son devueltos por el servidor en función de si la petición es correcta, es incorrecta, hay alguna redirección o el recurso no está disponible, entre otras opciones. Lo habitual es que en el access_log veamos sobre todo respuestas del tipo 200 (OK), sin embargo si estamos siendo víctimas de un ataque de descubrimiento de plugins tendremos muchas respuestas del tipo 404 (not found) indicando que el recurso no está disponible.

 En la imagen anterior se ha hecho una búsqueda específica para mostrar sólo las respuestas que NO son código 200 (OK). Se puede observar como la IP en cuestión ha realizado varias peticiones a recursos no existentes (404) o a los cuales no tiene permisos para acceder (403).

Identificando y bloqueando estos tipos de ataques a tiempo, dificultaría al atacante poder lanzar posteriores ataques ya que no tendría información suficiente acerca de los plugins instalados y sus versiones.

Para finalizar, también podríamos prestar atención a peticiones no habituales, como por ejemplo aquellas que no sean del tipo GET o POST. En la siguiente imagen podemos ver peticiones realizadas con el método HEAD.

Como habéis podido observar, los archivos logs de nuestros servidores Web sí nos pueden aportar mucha información relevante a la hora de investigar una incidencia de seguridad en nuestro sitio Web, así como los códigos de respuesta HTTP o los métodos usados en las peticiones a nuestra Web

Como consecuencia, el servidor comprometido pasó a formar parte de la StealRat Botnet enviando una gran cantidad de spam con contenido variado; venta de productos farmacéuticos, venta de viagra y pornografía. Este envío masivo de spam originó que el servidor entrara en listas negras de reputación IP así como en servicios de bloqueo por spam.

Tras analizar el sistema de ficheros se descubrieron varios ficheros php con código malicioso ofuscado que fueron limpiados. En la siguiente imagen podemos ver uno de los ficheros infectados con código ofuscado

- See more at: http://hacking-etico.com/2015/11/21/investigacion-ataque-wordpress/#more-4766

Usando Nmap para detectar Heartbleed

A estas alturas, pocas personas existirán que no hayan escuchado hablar de Heartbleed, considerado uno de los bug más críticos de la historia de internet.

No entraré en más explicaciones de Heartbleed, puesto que existen ya infinidad de sitios hablando de ello, aunque uno que explica todo muy claro lo tenéis en el blog Un Informático en el lado del mal.

En estos pasados días me ha tocado dedicarme exclusivamente a este bug en OpenSSL por lo que he debido informarme bien de en qué consistía exactamente hasta al mismo nivel del código fuente.

Una vez entendido ha tocado escanear una gran cantidad de IPs para comprobar qué hosts eran vulnerables. En esta ocasión me centro en servidores que pueden estar dando servicios que usan OpenSSL vulnerable, aunque no olvidéis que los clientes también pueden serlo.

Dado que la cantidad de IPs a escanear superaba los pocos miles, debía automatizar el scanning de alguna manera. Voy a explicar sin entrar en mucho detalle cómo fue el proceso.

Aclarar que he utilizado BackTrack 5 RC2 y Nmap 6.25.

1ª Situación

Cuando empecé el chequeo no existía exploit, tan sólo la web que todos conocemos para comprobar online si una aplicación bajo un dominio y puerto es vulnerable.

Por lo tanto el proceso sería usar nmap con fingerprinting de los servicios y una vez localizados aquellos servicios que podrían estar usando una versión vulnerable de OpenSSL comprobarlos en la web. Inviable dada la gran cantidad de IPs a comprobar.

2ª Situación

Sale el primer exploit en Python. Por lo tanto la idea cambia. Analizar qué servidores tiene esas servicios abiertos y crear un script para correr el exploit en esos servidores. Tedioso.

3ª Situación

Sale el primer script para nmap para comprobar Heartbleed. Suena perfecto. Tras unos cuantos escaneos me doy cuenta de que nmap me esta dando algunos falsos negativos, es decir, servidores que son de hecho vulneables, nmap los muestra como no vulnerables. Toca analizar a mano algunos de ellos aunque muchos otros ya son marcados correctamente gracias al script.

¿Situación final?

Sale una modificación del script para nmap que hace también Hearbeat request usando TLS 1.0, TLS 1.1 y TLS 1.2. En problema de los falsos negativos en la etapa anterior venía de que el script sólo comprobaba TLS 1.1.

El nuevo script podéis encontrarlo aquí . Se instala igual que cualquier otro script para nmap. En BackTrack (BT BT!!!) bajáis el fichero .nse y lo metéis en directorio usr/local/share/nmap/scripts/

En mi instalación de nmap por defecto el script me daba error ya necesita la librería tls para realizar conexiones “seguras” (si es que las hay hoy en día, un saludo  para la NSA por cierto). Para instalar esta librería debéis descargarla de aquí y alojar el fichero .lua en nselib de vuestro nmap.

Ya tenemos todo listo para escanear. Este es el comando que yo he usado:

 # nmap -iL ip_ranges -sV –top-ports 100 –script ssl-heartbleed -oA nmap_heartbleed_results

Breve explicación del comando:

-iL ip_ranges: ip_ranges es un fichero plano con todas las IPs a escanear. Muy útil cuando la cantidad es grande. Podemos incluir ahí IPs individuales, rangos de Ips, IPs de red con máscara… Se puede poder una en cada línea y mezclando formatos.

 –top-ports 100: Nmap escaneará sólo los 100 puertos más comunes. Esta clasificación está basada en el fichero nmap-services y cogerá aquellos 100 puertos con el ratio más alto. En mi caso era suficiente para cubrir los servicios más importantes que podrían utilizar OpenSSL.

–script ssl-heartbleed: Hacer uso del script para este bug.

-oA nmap_heartbleed_results: Cuando uso nmap, acostumbro a sacar los resultados en todos los formatos posibles, de modo que podremos grepearlos a nuestro antojo, exportar XML a otros formatos, etc.

No dudéis en reducir el scan sólo a los puertos que realmente queráis comprobar, ahorraréis tiempo.

Una vez tengáis los resultados, podréis exportarlos a un bonito HTML con la aplicación xsltproc.

Ahora a reportar y parchear, que la ocasión lo merece.PD: no tengo a mano los resultados por lo que no puedo publicar ninguna captura. Aún así, no os debe resultar difícil encontrar un servidor vulnerable o montar el vuestro propio para las pruebas.

Ataque BadUSB Man-In-The-Middle

Como ya habréis notado gracias a nuestro anterior artículo, en los últimos días en hacking-etico.com hemos estado probado la nueva maravilla que nos trae el equipo de Kali Linux: NetHunter. Aprovechando que yo también dispongo de un terminal Nexus 5 he decidido instalar y probarlo y las sensaciones son muy buenas.

Si aún no sabéis cómo descargarlo e instalarlo, os recomiendo nuevamente que leáis “NetHunter: Kali Linux en tu Android“, un estupendo artículo nos trae nuestro compañero Manuel Camacho en donde nos explica todo lo que necesitáis saber para tenerlo en vuestro dispositivo Nexus.

Uno de los ataques que más fácilmente nos permite hacer NetHunter es un curioso Man-In-The-Middle con el que me llevé una grata sorpresa. Vamos a centrar este artículo en explicar cómo funciona, por qué funciona, cómo explotarlo y cómo defendernos ante ello.

Este año tuve la suerte de asistir a la BackHat en Las Vegas, donde una de las más esperadas charlas era la de BadUSB y que a título personal me dejó maravillado. Ya se empiezan a ver las primeras implementaciones y vectores de ataque: Por parte de los chicos de NetHunter tenemos “BadUSB MITM Attack“. Ya podéis imaginar cual será el vector de ataque… con tan sólo conectar el móvil por USB a un ordenador con Windows conseguiremos redirigir todo el tráfico a nuestro móvil y hacer lo que queramos con él… guardarlo, modificarlo, bloquearlo… ¿interesante verdad? ¡A partir de ahora nos pensaremos dos veces cuando alguien nos pida que le carguemos el móvil en nuestro ordenador! Pero eso no es todo… seguid leyendo porque os cuento más adelante que la cosa es más grave aún.

Vamos al lío. Para ello voy a diferenciar tres secciones:

    Explotando Ataque BadUSB MITM: Mostrando cómo se explota y resultado en un escenario real.
    Entendiendo Ataque BadUSB MITM: Analizaremos en detalle cómo y por qué funciona el ataque.
    Defendiéndonos del Ataque BadUSB MITM: Una vez hemos analizado y entendido cómo funciona, podemos tomar un serie de acciones para evitar que este ataque sea efectivo en nuestras máquinas.


Explotando Ataque BadUSB MITM

Es momento de ver en acción cómo funciona el ataque. He escogido el vídeo oficial que la gente de NetHunter ha publicando donde se puede ver una demostración del ataque de una manera muy sencilla y directa. Si no entedéis bien inglés no os preocupéis puesto que en la siguiente sección lo veremos en detalle

¿Tiene buena pinta? Pues pasemos al a siguiente sección donde vamos a entender un poco mejor cómo funciona.


Entendiendo Ataque BadUSB MITM

A continación explicaré un poco más en profundidad cómo funciona la implementación de este ataque MITM. Para ello he grabado el siguiente vídeo (no olvidéis verlo en HD para ver todos los detalles sin problema) en el que veremos con detalle paso a paso todo lo que va sucediendo desde el principio hasta el final del ataque:

Como prueba de concepto y para comprobar que realmente se está capturando el tráfico, he filtrado tcpdump para capturar sólo el tráfico con destino al puerto 21 y guardarlo en el fichero mitm.pcap

Una vez hecho lo anterior, me conecto desde la máquina víctima a un servidor FTP insertando un usuario y contraseña de prueba sólo para ver si realmente se está capturando el tráfico. Al abrir el fichero pcap con Wireshark vemos que efectivamente el usuario y contraseña han sido capturados

,

 Varios puntos a aclarar:

El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.

Aunque no lo he probado, probablemente este ataque no funcione en máquinas UNIX debido a la manera en la que UNIX administra las puertas de enlace por defecto.

El ataque funciona aunque la sesión Windows del usuario esté bloqueada, es decir, nos encontremos ante la pantalla de inicio de sesión donde hay que meter la contraseña del usuario para acceder de nuevo a su sesión. Este escenario es muy común, puesto que en entornos de trabajo cuando el empleado se ausenta, una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así, el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos acceder a un puerto USB de una máquina importante (ufff se me ocurren tanto sítios públicos donde puertos USB son accesibles), es cuestión de enchufar el móvil, guardar el tráfico durante un tiempo y luego analizarlo en casa tranquilamente.
Defendiéndonos del Ataque BadUSB MITM

Como ha quedado demostrado, el principal problema es que Windows asigna a la métrica de la nueva ruta un valor menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces? Bueno se me ocurre algo bien sencillo como solución rápida y temporal: asignar un valor estático y menor a nuestra ruta por defecto y por lo tanto aunque se cree una nueva ruta para el tráfico por defecto, éste tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando por nuestra interfaz de red.

Para ello nos vamos Conexiones de red y entramos en las propiedades de la interfaz de red que conecte con internet (igualmente con otras interfaces importantes, por ejemplo aquellas para tráfico de intranet).

BadUSB MITM

A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:

Sin título3

De este modo, cuando Windows tenga dos rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al tener una métrica mejor que la creada por NetHunter.

Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.

Sólo una última nota: Ojo porque el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado, tráfico multicast actuaría del mismo modo. Desde luego este “parche” no soluciona el verdadero problema de raíz.

Varios puntos a aclarar:

El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.

Aunque no lo he probado, probablemente este ataque no funcione en máquinas UNIX debido a la manera en la que UNIX administra las puertas de enlace por defecto.

El ataque funciona aunque la sesión Windows del usuario esté bloqueada, es decir, nos encontremos ante la pantalla de inicio de sesión donde hay que meter la contraseña del usuario para acceder de nuevo a su sesión. Este escenario es muy común, puesto que en entornos de trabajo cuando el empleado se ausenta, una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así, el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos acceder a un puerto USB de una máquina importante (ufff se me ocurren tanto sítios públicos donde puertos USB son accesibles), es cuestión de enchufar el móvil, guardar el tráfico durante un tiempo y luego analizarlo en casa tranquilamente.

Defendiéndonos del Ataque BadUSB MITM

Como ha quedado demostrado, el principal problema es que Windows asigna a la métrica de la nueva ruta un valor menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces? Bueno se me ocurre algo bien sencillo como solución rápida y temporal: asignar un valor estático y menor a nuestra ruta por defecto y por lo tanto aunque se cree una nueva ruta para el tráfico por defecto, éste tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando por nuestra interfaz de red.

Para ello nos vamos Conexiones de red y entramos en las propiedades de la interfaz de red que conecte con internet (igualmente con otras interfaces importantes, por ejemplo aquellas para tráfico de intranet).

A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:

De este modo, cuando Windows tenga dos rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al tener una métrica mejor que la creada por NetHunter.

Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.

Sólo una última nota: Ojo porque el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado, tráfico multicast actuaría del mismo modo. Desde luego este “parche” no soluciona el verdadero problema de raíz.

- See more at: http://hacking-etico.com/2014/10/08/ataque-badusb-mitm/#more-3730

Cuando el pato teclea Cuack Cuack – Parte 2

Seguimos con la trilogía de pato. Ya vimos en la parte 1 qué era el pato (USB Rubber Ducky) y cómo protegernos, en este caso vamos a ver algunos ejemplos del pato en diferentes sistemas operativos, por lo que va a comenzar a hacer Cuack
Lo primero que necesitamos para poderlo usar es aprender su lenguaje de programación el cual veréis que es muy sencillo. Aquí realizaremos el Hola Mundo en Windows, Mac, Linux y Android. Lo que vamos a hacer es abrir un editor de texto y escribir la conocida frase con la que empezamos a programar todo el mundo. Primero veremos el código y cómo afecta, luego veremos las herramientas para compilarlo.

Comenzamos con nuestro amigo Windows de Bill Puertas.
?
1
2
3
4
5
6
7
8
   
DELAY 3000
GUI r
DELAY 200
STRING notepad
ENTER
DELAY 200
STRING Hola mundo!!!
ENTER

Comenzamos introduciendo el comando DELAY -dicho comando mide el tiempo en milisegundos- que nos hará esperar 3 segundos para que le dé tiempo a Windows a reconocer el “teclado”. A continuación, con GUI r lanzamos el ejecutar, GUI emula la tecla de Windows, Super-Key o Command según el sistema operativo, al combinarlo con la tecla r y se nos abrirá la ventana de ejecutar de Windows.

Volvemos a esperar 200 milisegundos para dar tiempo a Windows a abrirnos la pantalla y tecleamos, con el comandos STRING, notepad. Después presionamos ENTER.

n

Una vez dominado Windows seguimos con la versión para Mac OS X de Jobs que veréis que es muy similar.

   
DELAY 3000
GUI SPACE
STRING TextEdit
ENTER
DELAY 2000
GUI n
DELAY 750
STRING Hola Mundo!!
ENTER

Como observamos en el segundo caso, los comandos son similares a Windows la diferencia es que en lugar de usar GUI r usamos GUI SPACE que nos abre el lanzador de aplicaciones.

Abrimos el TextEdit, en el caso de MAC, tenemos que decirle que queremos uno nuevo fichero de texto antes de ponernos a escribir en él, por lo que ejecutamos GUI n.

Ahora ya solo nos queda escribir el hola mundo con STRING Hola Mundo!! como ya hicimos en Windows. - See more at: http://hacking-etico.com/2015/05/16/cuando-el-pato-teclea-cuack-cuack-parte-2/#sthash.ho96N1g1.dpuf

Ahora ya solo nos queda escribir el hola mundo con STRING Hola Mundo!! 😀 como ya hicimos en Windows.

Seguimos con el tercer caso. En este momento vamos con GNU/Linux del tito Richard y Linus en su versión Ubuntu + Gnome3.
   
DELAY 3000
ALT F2
DELAY 500
STRING gedit
DELAY 500
ENTER
DELAY 750
STRING Hola Mundo!!

Como podéis ver, aquí difiere un poco el código, ya que no usamos GUI sino ALT F2 porque es como se abre el lanzador de aplicaciones en Gnome3, pero el resto es igual que en los anteriores sistemas.

 Ahora introducimos una vez más el editor de texto con el comando STRING gedit y lo ejecutamos.

Ya tenemos listo nuestro gedit para escribir nuestra famosa frase Hola Mundo. 

Vamos con nuestro cuarto y ultimo caso ¿Sueñan los androides con ovejas eléctricas?

Pues si no lo hacen nosotros vamos a hacer que lo hagan 😉

Vamos a usar inkpad en Android, dado que lo tenia instalado en mi móvil de pruebas y así no busco otro editor de texto simple.

   
DELAY 3100
ESCAPE
ESCAPE
ESCAPE
ESCAPE
ESCAPE
ESCAPE
CTRL z
DELAY 1200
STRING inkpad
DELAY 1000
DOWN
DOWN
DOWN
DOWN
ENTER
DELAY 2000
ENTER
DELAY 200
STRING Hola mundo!

Como observamos en este último caso usamos algunos comandos más. El primero es ESCAPE que nos sirve para volver hacia detrás y salir si tenemos alguna aplicación ejecutándose en ese momento.

Una vez en el escritorio usamos CTRL z que nos permitirá usar el buscador de Android donde tecleamos el nombre del programa inkpad, le damos un segundo para que busque y bajamos cuatro posiciones con DOWN hasta la aplicación y presionamos ENTER.

.

Esperamos 2 segundos para que se abra la aplicación y pulsamos ENTER de nuevo y ya escribimos nuestra frase Hola mundo!

FIN

 

Esperamos 2 segundos para que se abra la aplicación y pulsamos ENTER de nuevo y ya escribimos nuestra frase Hola mundo! - See more at: http://hacking-etico.com/2015/05/16/cuando-el-pato-teclea-cuack-cuack-parte-2/#sthash.ho96N1g1.dpuf

Esperamos 200 milisegundos y tecleamos Hola Mundo!! que aparecerá escrito gracias al comando STRING - See more at: http://hacking-etico.com/2015/05/16/cuando-el-pato-teclea-cuack-cuack-parte-2/#sthash.ho96N1g1.dpuf

Cuando el pato teclea Cuack Cuack – Parte 1

el USB Rubber Ducky, vamos a ver una pequeña introducción y quien sabe que más

Para él que no sepa que es nuestro patito de goma, es un USB que utiliza el estándar HID (Human Interface Device) por lo que Windows, OS X, Linux y Android lo detectarán como un teclado, por lo que hacemos al final con este USB es teclear comandos como si lo estuviera realizando un usuario y hace que los antivirus no lo detecten.

Tiene un lenguaje de programación muy sencillo que nos permite automatizar nuestros propios payloads pudiendo realizar diferentes tareas como:

    Recoger información del sistema operativo
    Sustraer información importante de los navegadores
    Robar cookies de sesiones abiertas
    Obligar a la víctima a conectarse a una WiFi que queramos y ya tenemos un MITM.
    Mandar la información por correo electrónico

Esto es solo una pequeña muestra de lo que podéis hacer, ahora, el resto depende de vuestra imaginación.

Ahora viene la siguiente pregunta.

¿Nos podemos proteger?

La gente piensa que desactivando el autoplay de los USB se soluciona el problema, pero no es así dado que este USB trabaja como HID, por lo que no le afecta, dado que el autoplay solo es para los USB de almacenamiento.

Tenemos varias opciones para evitar este tipo de ataques, la primera y más radical es apagar los USBs desde la BIOS, de esta manera no funcionará ninguno y no hay posibilidades de ataque.

También podemos usar la aplicación USBDeview, que nos muestra a tiempo real toda la información de los dispositivos USB que se conectan, detectando de esta manera la conexión del “pato”.

Recordar bloquear la sesión cuando nos levantemos del ordenador para evitar que el pato pueda tener éxito, debido que lo que se suele hacer es usar los terminales de los sistemas para realizar las acciones.

Si somos de los que nos olvidamos de bloquear el ordenador al levantarnos de él, también tenemos shielducky de Alex Torrescrack que con presionar un botón ya quedaríamos protegidos  y dejaremos de hacer Cuack.

sí que ya sabéis, también hay que tener cuidado con la seguridad física y nuestros puertos USB no sea que nos pinchen un pato de goma y nos roben la cartera.

Como me gusta esto de ir haciendo las cosas por fascículos para que no se hagan muy largos los post y así dejar las cosas en el aire y la intriga… en el siguiente montaremos nuestro primer programa.

Explotando vulnerabilidad en Java 7 – PoC

A estas alturas creo que todo el mundo está ya al tanto acerca de la vulnerabilidad en Java 7, y de la cual Oracle aún no ha publicado una actualización de seguridad. Ayer mismo anunciábamos en este blog la criticidad de esta vulnerabilidad y de la gravedad de la misma.

La gravedad se acentúa cuando ya se ha publicado un exploit capaz de aprovecharse de esta vulnerabilidad y explotándola, permitiendo al atacante ejecutar código remoto en la máquina vulnerada.

Explotando vulnerabilidad en Java 7 – PoC

odo esto, y gracias a que en Metasploit ya tenemos disponible el exploit, me he decidido a hacer una PoC (Proof of Concepto, prueba de concepto) para comprobar realmente la criticidad de facilidad de explotación de la nombrada vulnerabilidad.

Para empezar, decir que he actualizado Metasploit hoy mismo para tener todos los módulos actualizados. También he vuelto a instalar y habilitar Java 7 en un Internet Explorer para realizar las pruebas, ya que lo tenía deshabilitado desde que salió la noticia de la vulnerabilidad.

Una vez actualizado MSF buscamos el exploit, en este caso podemos observar que es bastante reciente, data de ayer y su ranking es excelente. Perfecto!

Vamos a usar este exploit, ejecutamos los comandos necesarios y observamos que por defecto no hay que modificar ninguna opción del exploit.

Para el payload vamos a usar uno del tipo meterpreter:

Como se observa en la imagen, sólo hay que especificar la opción LHOST que hace referencia a la IP de nuestro equipo, el equipo atacante. Sólo falta lanzar el exploit y esperar que la víctima se conecte:

Copiamos la URL y la vamos a escribir en el navegador de la máquina víctima, en este caso con un Internet Explorer:

En esta caso mi antivirus Avira ha detectado el exploit, bueno ya que Oracle no lo ha solucionado, parece que las firmas AV sí lo detectan. Una vez más, la importancia de mantener actualizado nuestro antivirus. ¿Y si deshabilito el antivirus?

Bingo! Ya tenemos sesión Meterpreter, ya podemos “trastear” en la máquina víctima. Poder ver información del sistema u obtener una shell para acceder a su línea de comandos.

,

 Resumiendo, en primer lugar se aconseja deshabilitar Java, también mantened actualizados vuestros antivirus y comprobar que funcionan correctamente, como habéis podido comprobar, mi última actualización de la base de firmas de Avira (hoy) me lo ha detectado.

Resumiendo, en primer lugar se aconseja deshabilitar Java, también mantened actualizados vuestros antivirus y comprobar que funcionan correctamente, como habéis podido comprobar, mi última actualización de la base de firmas de Avira (hoy) me lo ha detectado. - See more at: http://hacking-etico.com/2013/01/12/explotando-vulnerabilidad-en-java-7-poc/#more-1393

Resumiendo, en primer lugar se aconseja deshabilitar Java, también mantened actualizados vuestros antivirus y comprobar que funcionan correctamente, como habéis podido comprobar, mi última actualización de la base de firmas de Avira (hoy) me lo ha detectado. - See more at: http://hacking-etico.com/2013/01/12/explotando-vulnerabilidad-en-java-7-poc/#more-1393