Cómo borrar la caché de credenciales de Eclipse

Si trabajas con Eclipse y Subversion (plugin Subclipse) tal vez te haya pasado: has metido mal el login y/o password en la ventana de autenticación y quieres poner el correcto. O bien, has puesto el correcto pero al día siguiente te comunican que ha cambiado. Eclipse no te dejará cambiarlo, se acordará constantemente del viejo. ¿Cómo arreglarlo? Borrándole la memoria 🙂 Es decir, borrando el fichero caché de credenciales que en mi PC se guarda aquí:

~/.eclipse/org.eclipse.platform_3.3.0_1543616141/configuration/org.eclipse.core.runtime/.keyring

Espero que al menos os sirva para ahorraros el quebradero de cabeza que he sufrido (y a mí para recordarlo en el futuro…)

Hackit! Nivel 4: ingeniería inversa

Al igual que en el nivel 3, un pequeño formulario con login y password ocupa la pantalla. A diferencia del nivel 3, donde tuvimos que romper un applet Java, en esta ocasión se nos plantea romper un componente Flash. Es decir, podemos asumir que la lógica que valida un login y un password está en el propio componente Flash, y que por tanto, se intenta garantizar la seguridad por ocultación… lo cual no suele funcionar (como acabamos de comprobar). Bien, hay que averiguar cuál es el algoritmo de validación que oculta el fichero binario .swf (Flash). El procedimiento: igual que en 3, obtener un buen descompilador de Flash, estudiar el código que genere y averiguar el camino a seguir, es decir, un poquito de ingeniería inversa sobre .swf. Esta prueba no fue tan fácil como la anterior; a pesar de ello, la clave cayó bastante rápido gracias a que uno de los miembros del equipo se llevó la artillería preparada en una máquina Windows… Desvelaré el secreto más adelante, dejo el fin de semana para que os divirtáis y cojáis fuerza para el nivel 5, que se nos atragantó a unos cuantos grupos… pero eso… es otra historia que contaré la semana que viene 😉

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…

HackIt! Nivel 3: seguridad por ocultación

Lo primero que vemos al entrar en el nivel 3 es un applet Java (que en Firefox, le cuesta cargar lo suyo…). En dicho applet se nos pide que introduzcamos login y password. Si acertamos, pasamos de nivel. Ok, analicemos el código fuente de la página para ver qué podemos averiguar. Lo primero que veremos será información sobre la clase Java principal que usa este applet: secApplet.class. Esta clase usa también clases internas que podemos encontrar compiladas en secapplet.jar. Todo esto lo podemos saber tras analizar el código HTML del reto:

 <applet code="secApplet.class" archive="secapplet.jar" codebase="." WIDTH=343 HEIGHT=152>
			<param name=numusers value="1">
			<param name=basename value="jhtgh.spi">
			<param name=style value="1">
			<param name=numtries value="3">
			<param name=width value="343">
			<param name=height value="152">
			<param name=l2 value="8|38|53|13|">
			<param name=l3 value="10|76|49|13">
			<param name=t1 value="74|38|245|21">
			<param name=t2 value="74|76|245|21">
			<param name=b1 value="74|108|245|20">
			<param name=bkcolor value="1118566">
			<param name=txcolor value="16777215">
			<param name=alturl value="./level3-3m3d35.html">
			<param name=ltitle value="Enter your Username and Password">
			<param name=mtarget value="_self">
		 </applet>

Parece por tanto que todo lo que tenemos que hacer es descompilar el fichero .class  y analizar el código fuente del applet Java, para ver qué es lo que está ocurriendo internamente (y esperemos que: 1) se pueda descompilar  y 2) el código fuente que genere no sea complicado de entender)

Cómo activar el soporte de comentarios en un PDF

pantaila-argazkia-1.pngEl año pasado Iñigo Martínez (Fac. Informática Donostia) participó en el Google Summer of Code con el soporte de anotaciones PDF a Evince. Esta funcionalidad se espera que se incluya de forma inminente en la versión oficial de Evince (ahora que ha pasado por el proceso de aprobación de parches). Se supone que permitirá añadir anotaciones como la que se ve en la imagen que ilustra este post. Lo que no sé es si permitirá hacerlo sobre cualquier documento PDF o sólo sobre aquellos que tengan activado el bit de «Permitir anotaciones». No he visto ninguna aplicación de software libre que permita activar este bit sobre un fichero PDF. Y dentro de las aplicaciones propietarias sólo sé que es posible con el editor Adobe Acrobat (dado que acabo de comprobarlo 😉 . Lo curioso es que el visor Acrobat Reader 8.1.1 para Linux, en cuanto ve activo ese bit, activa la barra de herramientas de anotaciones (como ya analizamos en un post anterior). ¿Pero cómo demonios activo el dichoso bit si estoy en Linux? Bueno, que estemos en Linux no quiere decir que no podamos usar Adobe Acrobat :-O De hecho, desde Wine 0.9.54 es posible ejecutar la versión de evaluación (30 días) descargable desde la propia web de Adobe. Realmente el procedimiento es sencillo, aunque no trivial. Primero instalamos Wine (0.9.54 o posterior). A continuación, tras descargar el trial de Acrobat Pro 8, lo instalamos con wine nombre_del_trial.exe . Esta instalación sólo la he conseguido hacer funcionar en Fedora Core 8. En Ubuntu Gutsy no ha habido forma (lo cual me fastidia sobremanera, dado que es la distro con la que más trabajo a diario…)

En fin, una vez instalada, procedemos a ejecutarla:

$ wine ~/.wine/drive_c/Archivos de programa/Adobe/Acrobat 8.0/Acrobat/Acrobat.exe

Y aquí es donde hay un problema de compatibilidad con Wine. Nos saldrá una ventana para aceptar la EULA y dos botones (Aceptar/Cancelar). El problema es que no son pinchables O:-) Al principio te entran sudores fríos, porque después de este viaje que no puedas hacer nada por no poder pinchar en un botón es como para… en fin, cometer una locura. Pero para eso está la base de datos de compatibilidad Wine (concretamente, los comentarios de los usuarios en esa base de datos). Buscamos la entrada de Adobe Acrobat y encontramos lo siguiente: primero que en Fedora 8 va bastante bien (soporte «bronce») y que en Gentoo y Ubuntu el soporte es… ejem, «garbage», o sea, una basura. Lo siguiente: que alguien ha encontrado la forma de solucionar el «problemita» de no poder pinchar en el botón de Aceptar la EULA. Basta con ejecutar $ wine regedit y desde el editor de registro de Windows, buscar la rama:

HKCU/Software/Adobe/Adobe Acrobat/8.0/AdobeViewer

Crear ahí una nueva entrada de tipo REG_DWORD (botón derecho / REG_DWORD) y darle el nombre «EULA». A continuación asignarle el valor 1. Tiene que quedar tal y como se ve en la siguiente figura:

screenshot2.png

Vale. Ahora ya podemos lanzar de nuevo Adobe Acrobat desde Wine. Abrimos cualquier PDF al que queramos activar el bit de soporte de anotaciones y (ahora viene el detalle final): lo activamos pulsando Advanced / Enable Usage Rights in Adobe Reader.

izengabea.png

Guardad bien este post. Lo necesitaréis.