martes, 21 de septiembre de 2010

Discos en Windows con particiones Linux

Tengo un equipo que estaba funcionando como servidor. En éste guardaba cosas como imágenes de discos. Por ejemplo, alguna de Debian, BSD... Hace unas semanas que se estropeó y no he conseguido hacerlo funcionar de nuevo. Ya os contaré en otro momento las cosas que he hecho para averiguar qué le pasa.

El caso es que necesitaba recuperar algunos datos de ese disco. Así, que lo primero que hice fue quitar un disco duro... Que resultó ser el que no quería. Vamos. Murphy haciendo de las suyas. Así que pillo el segundo disco IDE que necesitaba y lo monto en un sistema conversor de IDE a USB Conceptronic (si no es este modelo, es uno con un aspecto idéntico).

Al conectarlo el sistema operativo indicaba que se había detectado el conversor. El conector IDE se iluminaba con un led rojo, y el adaptador a la corriente que había que ponerle al disco para alimentarlo también se iluminaba con un led azul. Como no salían las particiones que debían de salir, intento arrancar con distintos live-CDs pero tampoco consigo nada. Así que, se me ocurre mirar en el administrador de discos duros del Windows Vista que tengo instalado y... ¡ahí estaban! Las dos particiones que esperaba. Luego, cuando instalé el sistema del servidor, no puse NTFS ni FAT32 como sistemas de ficheros.

Lo primero que pienso es que lo instalé con un ext2 o ext3. Luego, busco en Google y encuentro un driver para poner sistemas ext? (donde ? es el numerito) y poder trabajar con ellos en Windows.

Me lo descargo, lo instalo (indicando, entre otras cosas, las letras que tendrán las particiones) y... ¡¡ahí están!! Las dos particiones. Pero, cuando intento acceder a ellas me da un mensaje como

Esta partición no tiene formato. ¿Desea formatearla ahora?

Evidentemente no quiero formatearla porque yo se que tiene formato. Luego, busco en la ayuda y sugiere que descarguemos mountdiag.exe. Es una aplicación de consola que hay que ejecutar como administrador. Así, al ejecutarlo nos devuelve:

MountDiag - Tu sistema posiblemente sea ReiserFS

Luego, había puesto el driver equipo. Una vez más, había que localizar el driver necesario para recuperar los datos. Como me dice que el sistema de ficheros es reiserFS, vuelvo a buscar. Y me encuentro con uno un poco antiguo, pero que me podía valer. Es el YAReg. Lo descargo y descomprimo:

Carpeta del YAReg

Las dos DLLs que hay ahí las copié de la carpeta rfstool-utils. porque según las instrucciones tenía que estar el YaReG.exe junto al resto de las cosas. 


Así, una vez lo tenemos preparado, sólo hay que ejecutarlo desde consola. He estado un rato preguntándome cómo conseguí que se accedieran a los datos. Si lo ejecutas con doble click, no te van a salir las particiones:

YaReG abierto

Sólo hay que seleccionar un fichero con el botón derecho, copiar y cuando se abra la ventana con el browse del árbol de directorios, seleccionar el destino.

¿Alguna otra cosa que hubierais hecho vosotros? 



jueves, 16 de septiembre de 2010

Virus y accesos directos

Un amigo me ha dicho que se le ha colado un bicho en varios ordenadores suyos y que después de eliminar alguno de los EXEs malignos, las carpetas del disco duro externo se le habían convertido en accesos directos. Me sonaba mucho el tema, pero no estaba muy seguro de cómo solucionarlo.

Bueno. Pues buscando, a la primera he encontrado una posible solución. Lo único, que creo que le falta algo más.

El caso es que este bicho parece que modifica las propiedades de los ficheros de los dispositivos infectados. Lo único que hay que hacer es ejecutar el comando attrib con una serie de parámetros.

attrib /d /s -r -h -s *.*

Si hacemos un

attrib /?

nos muestra la ayuda. En negrita pongo los parámetros que utilizamos:

ATTRIB [+R | -R] [+A | -A ] [+S | -S] [+H | -H] [+I | -I]

[unidad:][ruta][nombreDeArchivo] [/S [/D] [/L]]

+ Establece un atributo.
- Borra un atributo.
R Atributo de sólo lectura del archivo.
A Atributo de archivo de almacenamiento.
S Atributo de archivos del sistema.
H Atributo de archivo oculto.

I No atributo de archivo indizado de contenido.
[unidad:][ruta][nombreDeArchivo]
Especifica el archivo o archivos que serán afectados por ATTRIB
/S Procesa archivos que coinciden en la carpeta y todas las subcarpetas actuales.
/D También procesa carpetas.

/L Se trabaja en los atributos del vínculo simbólico en vez de en el destino del vínculo simbólico

También habla de utilizar unlocker para liberar los ficheros ejecutables que tienen el malware y así poderlos borrar. Lo único que se queda algo en el tintero. Cada vez que reinicies, el bicho, si está en tu sistema, se puede volver a cargar. Si lo borras del sistema, se renombrará, tal y como le ha pasado a mi amigo. Además, de las trazas que deja en el registro. Luego, lo suyo sería desinfectar el sistema por un lado, y borrar esos ficheros por otro (por ejemplo, en modo off-line o con un live-cd). 

Si no lo consigue, os lo contaré. Aún así, ¿a alguien le ha pasado esto? ¿Si es así, qué ha hecho? ¿Qué haríais vosotros en un caso como este?

miércoles, 1 de septiembre de 2010

Tarjetas de crédito y débito

Resulta que cuando estuve en el Asegur@IT 7 el pasado marzo, uno de los compas comentó la misma anterior al evento sobre un ataque muy curioso. El ataque que nos comentaba era un MITM relacionado con tarjetas de pago.

¿En qué consistía el ataque? Bueno. La verdad, no contó mucho porque simplemente fue un comentario que hizo al salir del local donde cenamos, tanto el equipo perteneciente al evento como algunos asistentes. La idea, en resumen, es engañar al terminal haciéndole creer que se ha introducido el PIN de la tarjeta correctamente, cuando no realmente no es así, y a la tarjeta se le dice que no hay que introducir ninguna contraseña. Bueno. ¿Y cuáles son los detalles? Los detalles los da la Universidad de Cambridge, en un documento que me tengo que leer.

También hay un vídeo de la BBC, un tanto sensacionalista, en el que entrevistan al equipo de la investigación y muestran una demo en la cafetería de la universidad.

Aún así, es importante remarcar que, mientras que buscaba datos sobre este tema en concreto, el mismo sitio donde he encontrado estos enlaces, hay otro en el que remarcan que hacen un poco de trampa.

Una de estas trampas es que parece ser que en fotograma de la demo de la BBC, se paga con una tarjeta VISA, pero, parece ser (que no lo acabo de ver), el ticket muestra que se ha usado una MasterCard (Según he visto en el primer comentario, de uno de los autores de la investigación, hicieron varias pruebas para distintas grabaciones en distintos ángulos. No tiene desperdicio leérselo).

El otro truco parece ser que radica en el protocolo que están usando. Según he podido entender, el protocolo que se emplea en estas transacciones, establece que los resultados relativos a la tarjeta se guardan en un dato llamado CVR, y es obligatorio enviarlo. El terminal indicará en su CVM que el PIN es correcto. el problema está en que el CVM no es obligatorio, es optativo. Si se enviaran los dos, al compararlos, habría algo que no cuadraría, y la transacción junto al ataque acabarían sin más.

Ya se. No he contado mucho al respecto. Sólo he contado lo que he llegado a entender de lo que he leído.

Pero, aún hay otra cosa que quisiera contar con respecto a las tarjetas de pago. Y es que, buscando información sobre lo comentado arriba, me he encontrado con otra cosa muy curiosa.

Ya sabemos que muchas veces, cuando se va a comprar algo por Internet, nos piden datos de la tarjeta. En principio, deberían de ser datos de tipo (o nivel) 2. Es decir, comúnmente lo que se dice como "algo que tenemos". Porque haría falta la tarjeta para saber los datos que nos piden, que suelen ser el número completo, la fecha de caducidad, y, últimamente, los dígitos de seguridad que están en la parte trasera de la tarjeta (algunos piden 4 números, otros piden 3). Pero, ¿realmente se necesita la tarjeta? Con tal de sabérselo de que alguien lo haya apuntado, ya la hemos liado.

Bueno, pues parece ser que se está ideando un sistema para convertir nuestra tarjeta en una especie de token. Así,