HackIt! Nivel 3: solución

El primer paso por tanto, será realizar ingeniería inversa sobre el binario .class. Para ello, tras buscar un buen descompilador de clases Java, nos encontramos con Jad, una aplicación gratuita (no-libre) multiplataforma.

Descargaremos la versión 1.5.8e compilada estáticamente para no tener problemas de dependencias con ninguna librería.
A continuación, descargaremos el fichero secApplet.class en el que se basa el reto 3.

$ wget http://hackit2.diariolinux.com/secApplet.class

Y procedemos a la descompilación:

./jad secApplet.class

Tras algunos warnings, obtendremos el fichero secApplet.jad, que al abrirlo, comprobaremos que se trata del
código fuente Java original de la clase secApplet. También veremos que la calidad del trabajo de descompilación realizado por Jad
es muy buena (probablemente debido también a que el autor del .class original no se preocupó de esconder su código).

Entre las funciones de interés del fichero .jad se encuentra el código del método decrypt()

String decrypt(String s)
{
String s1 = "";
StringBuffer stringbuffer = new StringBuffer(s);
for(int i = 0; i < stringbuffer.length(); i++)
switch(stringbuffer.charAt(i))
{
case 65: // 'A'
s1 = s1 + "L";
break;
case 66: // 'B'
s1 = s1 + "M";
break;
...

Si analizamos el flujo del programa veremos que se llama a ese método decrypt pasándole el parámetro basename (del código HTML del applet Java):

String s = getParameter("basename");
if(s != null)
s = decrypt(s);


Bien, preparemos una clase Java a la que daremos el nombre Hack, y que incluirá un método main() de prueba del método decrypt():


public class Hack {
public static void main(String[] args){
System.out.println( decrypt(args[0]) );
}
public static String decrypt(String s)
{
[incluír aquí el código de decrypt]
}
}
Compilamos nuestra clase de prueba:

$ javac Hack.java

Y la ejecutamos, pasándole como parámetro el valor de la variable «basename» que encontramos en el código HTML de la página:

$ java Hack jhtgh.spi
users.dat

Bueno, nos devuelve el nombre users.dat. Leyendo el código Java descompilado anteriormente, vemos que users.dat es el nombre del ficheroque se descarga desde getDocumentBase()+users.dat, es decir, desde http://hackit2.diariolinux.com/users.dat :

URL url = new URL(getDocumentBase(), s);
DataInputStream datainputstream = new DataInputStream(url.openStream());
String s1;
while((s1 = datainputstream.readLine()) != null){


Bien, vamos a ver qué se esconde en ese fichero:

$ wget http://hackit2.diariolinux.com/users.dat

Si hacemos un cat de users.dat vemos que es un string cifrado. Según el código Java descompilado, hay que descifrarlo, usando decrypt() otra vez:

$ java Hack `cat users.dat`
euskal|j4v4t0s|./level4-j4v4t0s.html|_self

Con lo que ya tenemos la clave del nivel 4.

Conclusiones: basar la seguridad de un procedimiento de autenticación en esconder el método de descifrado en un fichero binario es bastante ingenuo. Cualquier atacante con unos mínimos conocimientos de ingeniería inversa podrá saltarse cualquier método de seguridad por ocultación. Le costará más o menos tiempo hacerlo, pero podemos estar seguros de que podrá conseguirlo si se esfuerza lo suficiente…