Redes Sociales

miércoles, 26 de marzo de 2014

Revisiting Winrar "0-day"

Tras leer este blog, me decidi a probar esta "vulnerabilidad" en el winrar que tenía en casa (que resultó ser la v5.01 y que es la descarga recomendada a día de hoy).

Lo primero que comprobé es que es cierto que aparecen dos veces los nombres de los ficheros, uno de ellos (el "primer nombre") al principio del fichero y otro (el "segundo nombre") justo al final. Sin embargo en la versión 5.01 el comportamiento es diferente al explicado en el blog antes mencionado.

En el caso de la version 5.01 de Winrar el "primer nombre" del que se habla en an7isec no se utiliza para nada, hasta el punto de que si se borra por completo, el fichero ZIP sigue siendo perfectamente válido.

Esto quiere decir que tanto para la previsualización como para la extracción final del fichero se utiliza el "segundo nombre".

Se puede modificar este segundo nombre, por supuesto, pero si por ejemplo a un ejecutable le ponemos una extensión PNG, el sistema operativo intentará abrir el ejecutable con el visor de imágenes resultando inútil el cambio realizado. Es igual que si le cambiáramos la extensión o el nombre ANTES de comprimir el fichero.

Y como muestra, un botón:

Como no tenía un malware a mano, hice la prueba con el socorrido putty.exe. Tras crear un fichero ZIP con Winrar de dicho ejecutable, al abrirlo con un editor hexadecimal vemos que, ciertamente tiene un primer nombre:

...y un segundo nombre:

Comprobamos que, si eliminamos por completo el primer nombre:

...no pasa nada:

...y si le cambiamos la extensión al ejecutable "malicioso":

...nos lo intentará abrir con el visualizador por defecto para esa extensión:

Con lo cual podemos sugerir que con las versiones actuales de Winrar podemos estar tranquilos.

martes, 25 de marzo de 2014

Vulnerabilidad 0-day en Microsoft Word

Microsoft publicó hoy un comunicado avisando de una vulnerabilidad 0-day que afecta a Microsoft Word. El problema podría comprometer a todas las versiones de Microsoft Word 2003 a Microsoft Word 2010. La vulnerabilidad parece no existir en Microsoft Word 2013 debido a que en esta versión se fuerza el uso de ASLR.

La vulnerabilidad se puede propagar (y de hecho ya se esta aprovechando) mediante correo electrónico utilizando un fichero RTF modificado que incluye un payload que descarga un troyano desde un sitio remoto de forma inadvertida para el usuario. No es necesario siquiera abrir dicho documento RTF y bastaría con previsualizarlo con Microsoft Outlook, ya que éste usa Microsoft Word como visor de correo.

Microsoft proporciona un Fix-It para resolver de forma temporal el problema. Este Fix-It se puede instalar desde aquí.

Por otra parte, se ha visto que el tener instalado EMET evita la ejecución del payload del RTF.

Aparentemente la funcionalidad de descarga del troyano dejará de funcionar el 8 de Abril de 2014. El troyano descargado es un fichero llamado svchost.exe que aloja un malware genérico escrito en Visual BASIC que se conecta por https con la IP 185.12.44.51 (alojado en Suiza) para descargarse scripts VBS y ficheros MSI que instalará en el equipo comprometido.

Para mas información se pueden leer estas noticias:

viernes, 14 de marzo de 2014

Probando el DVWA (Parte I)

Hoy me decidí a instalar DVWA para hacer pruebas de conocimientos de sql injection y demás. DVWA es la Damn Vulnerable Web Application y su nombre lo dice todo. Básicamente se trata de una XAMPP con PHP y MySQL.

Tras instalarla, el primer problema que encuentro (aparte de un error de MySQL que habia que cambiar la contraseña del usuario root) es que me aparece la página de login y no tengo ni idea de qué usuario y contraseña utilizar:

Por suerte lo tengo instalado en local y puedo ver el fuente de login.php, que tira de la base de datos de MySQL 'dvwa' y dentro, de la tabla 'users'. Dicha tabla es algo asi:

Esas contraseñas parecen un MD5... vamos a intentar descifrarlas. Vamos a alguna de las multiples páginas que hacen resolucion inversa de MD5, por ejemplo gromweb y le damos:

Ok, pues para el usuario admin, la contraseña es password. Vamos a ver el resto.... Para el usuario gordonb es abc123, para el usuario 1337 es charley y para el usuario pablo es letmein.

Una vez dentro me sale esta página principal:

Command Execution

Pruebo a comenzar con la ejecución de comandos. Me sale esta pantalla donde se supone que introduciendo una IP, me hará ping a dicha IP. De hecho funciona. Pero hay algo más, seguro. Tras unas cuantas pruebas:

...me empiezo a escamar y miro el código fuente... hasta que me doy cuenta de que estoy en modo NO-VULNERABLE, opción que se puede modificar en el fichero config.inc.php:

Según la documentación, el modo de seguridad 'high' es seguro contra contra todas las vulnerabilidades y además nos muestra buenas prácticas de programación.

En este modo la herramienta del ping "con vulnerabilidad de ejecución de comandos" esta escrita asi:

Es decir, se "explota" la IP por el simbolo punto y luego se comprueba si cada parte es numerica con la funcion is_numeric de PHP. Tras investigar un poco, no hay forma de saltarse esta comprobación.

Así pues, pasemos al modo 'medium' (Tampoco es plan de ir a lo facil).

Ahora si. Simplemente poniendo un simbolo "pipe" nos permite ejecutar cualquier comando linux:

En este modo, se filtran los codigos '&&' y ';', pero todo lo demás, lo deja ejecutar.

File Upload

Pruebo a continuación la opción de subida de ficheros (Upload). Para ello voy a escribir un script PHP que me haga un simple ls. Algo así:

Al subirlo me da un error muy explicativo:

Your image was not uploaded. O sea que esta esperando una imagen. ¿Y si le ponemos una extension jpg al php?. A ver... ¡¡Vaya, y nos pone la ruta completa!!:

Entiendo que ahora solo hay que ejecutar ese jpg... Vaya... ¡pues no!:

Ah! pero para eso tenemos la ejecución de comandos que probamos antes. Si vamos a Command Execution y le pedimos que nos haga ping a:

8.8.8.8|mv ../../hackable/uploads/prueba.jpg ../../hackable/uploads/prueba.php

...ahora ya podremos ejecutar dicho PHP:

Y hasta aquí por ahora. Esta wapo este DVWA, permite probar conceptos y aprender como se debe programar en PHP de forma segura.

jueves, 27 de febrero de 2014

Pasos seguidos para la limpieza de las VMs del curso de INTECO "Ingeniería social y analisis de sospechas"

En el último curso impartido por INTECO desde el pasado Martes hasta hoy hemos hablado de ingeniería y "analisis de sospechas", curioso nombre cuando de lo que se trata es de detección y limpieza de troyanos.

Como parte práctica nos han dado cuatro máquinas virtuales infectadas que había que limpiar "a mano", sin herramientas de limpieza automática (léase cualquier tipo de antimalware). En esta entrada describiré los pasos que seguimos (los de mi grupo) para la limpieza de dichas máquinas virtuales.

Resolución maquina virtual VM02

Se arranca la maquina y se comprueba el problema:

No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD

cd HD

Se busca el listado de fichero creados los días 20 y 21 de Febrero (Sabemos que es cuando se infectaron las máquinas). No se encuentra ningun exe, ningun lnk ni nada interesante.

Encontramos dos ficheros interesantes:

  • Una carpeta setup
  • Un fichero llamado At1.job, que es una tarea programada.
  • LockScren.AO.lnk

La carpeta setup resulta ser c:\windows\system32\oobe\setup\setup.exe

Al mirar los contenidos del fichero At1.job vemos que se ejecuta el fichero setup.exe de la ruta anterior.

Probamos a mover ese fichero setup.exe a otra ruta. Rearrancamos Windows, y ya no aparece el Ransomware.

Restauramos una versión anterior de Windows.

Buscamos las entradas del registro que llamen a este setup.exe y aparecen las siguientes:

HKCU/Software/Microsoft/Windows/ShellNoRoam/MUICache=”C:\windows\system32\oobe\setup\setup.exe”
HKU/1-5-21..../Software/Microsoft/Windows NT/CurrentVersion/Winlogon/Shell=”C:\windows\system32\oobe\setup\setup.exe”

Las borramos. También borramos el fichero setup.exe.

El fichero lnk es un enlace al ejecutable que infectó la máquina, por lo que sabemos de que virus se trata (con enviar el fichero setup.exe también nos habria valido).

Buscamos por internet LockScren.AO y encontramos esta página:

http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan:Win32/LockScreen.AO#tab=2

Resolucion VM03

Al arrancar la máquina, aparece este error de la ejecución de “other.res”:

Se busca ese fichero y aparece en

c:\Documents and Settings/aula2/Application Data/other.res

La pantalla de error tiene un icono muy pixelado que claramente pretende engañar.

El other.res también aparece en el administrador de tareas.

Se arranca la maquina y se comprueba el problema. No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados los días 21 de Febrero (sabemos que las maquinas fueron infectadas en esa fecha).

Se encuentra un fichero Flash7.ocx.exe que suena raro:

En los momentos después de la ejecución del troyano se ven ficheros temporales de internet y la instalacion de Flash.

Volvemos a Windows.

Vemos que el Flash7.ocx (realmente Flash7.ocx.exe) tiene exactamente el mismo icono que el error. Lo mandamos a Virustotal.

Virustotal nos dice que es un virus y lo detectan 38 de 47 antivirus y que se llama urausy.

Mientras tanto se busca other.res en el registro de Windows:

Tambien se encuentra esta entrada:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell=explorer.exe, C:\Documents and Settings\aula2\Application Data\Other.res

Lo borramos y matamos el proceso. Tambien borramos el fichero.

Buscamos Flash7.ocx.exe en el registro. Aparece la siguiente entrada:

La ruta es HKCU/Software/Microsoft/Windows/ShellNoRoam/MUICache/

La borramos.

Borramos la carpeta completa Flash. No deja borrarla. Rearrancamos Windows en modo a prueba de fallos, tampoco la conseguimos borrar, por lo que entramos desde Linux y nos la cargamos.

Se borra tambien BRNDLOG.BAK en %UserProfile%/aula2/AppData/Microsoft/Iexplorer



Resolución maquina virtual VM04

Se arranca la maquina y se comprueba el problema.

No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados el día 21 de Febrero (Sabemos que el bicho se instaló ese día en la máquina). No se encuentra ningun exe, ningun lnk ni nada interesante.

Buscamos por internet y encontramos un virus parecido llamado gpcode.ak, y una entrada de un blog( http://www.securelist.com/en/weblog?weblogid=208187531) donde indica que la única solucion es recuperar los ficheros usando photorec, ya que despues de encriptarlos, el virus los borra y los ficheros borrados, si no se a tocado demasiado el sistema, se pueden recuperar.

Nos ponemos a ello y recuperamos un montón de ficheros:

Eliminamos el fichero Bliss.bmp, que es el fondo de pantalla con la calavera.

Este es el resultado:



Resolución VM05

Se arranca la máquina y se comprueba el problema. No se encuentra ningún ejecutable en las carpetas de arranque. Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reincia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados el día 21 de Febrero (Fecha de instalación del troyano). Encontramos tres ficheros interesantes:

  • Un fichero setup.exe
  • Un fichero sdrive64.exe
  • Un fichero Skomaz.lnk

Buscamos dicho Skomaz en internet y encontramos esta páginas http://www.spywarelib.com/remove--Trojan-spy-skomaz.html.

...donde habla del fichero sdrive64.exe. Y esta:

https://www.virustotal.com/es/file/e7fa7e304b3ab56c695a51d8caf832b79563969465b388420381ac13ac8b550b/analysis/

Donde habla de que el virus tiene 1165824 bytes.

Buscamos ficheros de ese tamaño y casualmente encontramos que hay uno llamado setup.exe (el de antes).

Los borramos y arrancamos. Ya no aparece la pantalla de rescate pero Windows no funciona.

Es porque en vez de lanzar explorer.exe en alguna entrada del registro esta lanzando sdrive64.exe

Lo encontramos en HKCU/Microsoft/Windows NT/Winlogon/Shell=C:\Documents and settings\aula2\Local Settings\Temp\sdrive64.exe

Voila!

jueves, 20 de febrero de 2014

Cifrado de correos electrónicos con GPG (1/2)

Voy a aprovechar un trozo del tema 9 del curso de seguridad de la Hacker High School, de la que soy traductor, para poner en contexto lo que es PGP, las claves públicas y privadas, MIME y S/MIME, de cara a luego a hacer la práctica del funcionamiento de todos estos conceptos. Lo hago por que la verdad, me ha parecido una explicación muy amena, sencilla e interesante y creo que todos deberíamos SIEMPRE enviar nuestros correos cifrados y firmados y evitar así que ocurran cosas como lo de la NSA. Ahí va:

PGP viene de Pretty Good Privacy (En castellano, Bastante Buena Privacidad) y fue desarrollado por Phil Zimmermann. Es posible que buscando por internet nos encontremos con la versión de código abierto llamada GPG (GNU Privacy Guard). GPG esta disponible gratis para muchas plataformas, y solo usa algoritmos abiertos y públicamente evaluados.

GPG trabaja sobre el principio de gestión de claves públicas y privadas, lo que significa que las claves tienen una parte PÚBLICA que se la puedes dar a cualquiera que quieras que te envíe un correo cifrado, y una parte PRIVADA que debes mantener en secreto, y que es la única forma de descifrar el mensaje que has recibido. Al conjunto de clave pública y privada se le llama par de claves, y generalmente es lo primero que generas cuando instalas GPG en una máquina. El par de claves está protegido por una contraseña de manera que puede no ser modificado por nadie más que por el dueño. Puede ser necesario alterar el par de claves cuando quieras cambiar las direcciones de correo que el par de claves soporta, o por si quieres hacer uso de otras funciones.

Dado que necesitas la clave pública de alguien a quien quieras enviar un mensaje cifrado, existen servidores como pgp.mit.edu donde puedes descargar la clave o claves públicas asociadas con una dirección de correo en concreto, así como subir tu propia clave pública. Es posible que las claves hayan expirado o que se pierdan las contraseñas privadas, de manera que siempre usa la última clave o incluso mejor, pide al destinatario de tu correo que te mande la suya y confirma y confirma el fingerprint (una especie de más corto).

MIME (Multi-Purpose Internet Mail Extensions) es un conjunto de extensiones del protocolo de correo SMTP (Simple Mail Transfer Protocol). MIME permite enviar como adjuntos diferentes tipos de contenidos tanto de datos como multimedia, audio, video, imágenes, ficheros comprimidos, y aplicaciones. La cabecera MIME se inserta al principio del correo electrónico y el cliente de correo del receptor usa esta información para determinar qué programa está asociado con el fichero adjunto. MIME por sí mismo no proporciona ningún tipo de seguridad a los correos o a los adjuntos.

S/MIME (Secure/Multipurpose Internet Mail Extensions) es un protocolo que añade las características de firma digital y cifrado a los ficheros adjuntados al mensaje mediante MIME. Usando firma digital, S/MIME consigue garantizar la autenticidad, integridad y no repudio del mensaje (“no repudio” significa que no puedes negar que lo hayas mandado tu). S/MIME proporciona privacidad y seguridad (usando el cifrado) a los correos que usen este protocolo.

Cuando consultas un servidor de claves, ¿Cómo puedes estar segur@ de que una clave pública de un destinatario de correo electrónico es realmente la suya y no ha sido subida por cualquier otra persona?. La solución a este problema es que estas claves pueden ser firmadas por terceras personas. Imagina que ya tienes la clave (pública) de alguien en quien confías, y que sabe quien es la persona a la que quieres mandar un correo electrónico. Esa otra persona puede firmar la clave pública, lo que significa que le añade un poco más de confianza a esa clave, dado que tu ya conoces a esta otra persona. Esto es conocido como confianza heredada. Por supuesto, también puedes encontrar otra forma de ponerte en contacto con el destinatario y pedirle que te mande su clave pública, o recibir la “huella” de la clave – la huella es un checksum de la clave que es fácil y rápida de verificar. En un servidor de claves, cada clave también tendrá un ID o identificador – que es otro checksum con el mismo objetivo.

Enviar un correo cifrado usando GPG. La mayor parte de los clientes de correo soportan extensiones que facilitan el manejo de claves y el cifrado de mensajes. Los mejor es comprobar de antemano si el destinatario de tu mensaje tiene una clave pública y obtenerla, ya sea de un servidor de claves, o del propio receptor del mensaje.

A continuación, escribe el correo electrónico como haces habitualmente (de nuevo recomendamos usar texto plano en vez de formato HTML), añade cualquier fichero adjunto que necesites y dile a tu cliente de correo que lo cifre y lo mande. Si decidiste firmar el correo, el cliente de correo habrá usado tu clave privada para firmar el mensaje primero, y a continuación habrá usado la clave pública de tu destinatario para cifrar el correo y todos los ficheros adjuntos. Si proteges tu par de claves con una contraseña(¡deberías!), tu cliente de correo te pedirá esa contraseña.

Recibir un correo cifrado usando GPG. Los correos cifrados con PGP contienen o bien un fichero adjunto marcado como GPG, o tienen un bloque de texto con una cabecera que le dice al cliente de correo que acaba de recibir un correo cifrado. El cliente de correo ahora accede a tu clave privada (posiblemente pidiéndote antes una contraseña) y descifra el mensaje y todos los adjuntos. Si el mensaje no fue cifrado con tu clave pública este descifrado simplemente fallará. Si el mensaje fue firmado por el emisor, la extensión (o plugin) GPG del cliente de correo usará la correspondiente clave pública para verificar la firma también. El plugin de GPG que utilices te alertará de cualquier problema que encuentre con las firmas o ficheros adjuntos, pero en general, una vez instalado, el uso de GPG es bastante fácil.

miércoles, 12 de febrero de 2014

La aventura sigue siendo usar el DNIe

El proceso de firmado con el DNI electrónico sigue siendo una pequeña pesadilla y por lo que veo, la web http://www.dnielectronico.es sigue pecando de poca claridad. Se explica, de primeras, todo el proceso de validación de los certificados, cuando lo que quiere el usuario de a pie es utilizarlo.

Esta muy bien intentar convencernos de que el DNIe es buenísimo y segurísimo pero lo que necesita el usuario es un "guia burros" que le indique paso a paso como utilizarlo.

Con un DNIe con los certificados recién renovados y un portátil con Windows 8 recién instalado, me propuse hacer funcionar el DNIe y poder así firmar documentos electrónicamente. Accedí a la página que recomendaba mi lector, un LTC31 de C3PO, la antes mencionada http://www.dnielectronico.es.

Me gustó que en la página de inicio hubiera una opción "Compruebe su DNI"... que por desgracia te lleva una página con mucho texto y muchas explicaciones pero nada clara a la hora de comprobar el funcionamiento del DNI. El enlace para la comprobación se encuentra al pie de la página y en mi caso, me llevó a una página de error del navegador:

Pues vaya... si que empezamos bien. Será entonces necesario instalar los drivers del lector. ¿Pero no venían ya incluidos en Windows 7 y 8?. No tardo mucho en encontrar que, ciertamente en Windows 7 y Windows 8 no hay que instalar los drivers del DNI electrónico... pero los certificados sí. Tras un rato de lectura por el portal, instalotodos los certificados habidos y por haber, y esto sigue sin funcionar. Hasta que leo un comentario "Instalar en su navegador el Certificado Raíz de la FNMT clase2 CA. Este paso es especialmente importante en el navegador Mozilla Firefox ya que no lo incorpora por defecto en el almacén de Autoridades". Leches, estoy usando Mozilla Firefox. Me paso a Internet Explorer y la página carga como la seda:

Bueno, ahora queremos firmar digitalmente un documento. Vamos a empezar haciendo la prueba de firma que nos recomienda el propio portal del DNI: https://av-dnie.cert.fnmt.es/compruebacert/firmar.action. Lo primero que nos avisan es que es necesario tener instalado Oracle Java. Vaya tan seguro como es el DNIe, es necesario tener instalado Java, el sumidero de seguridad más grande que tenemos hoy en día...

Una vez accedemos a este sitio ya con Java instalado, nos aparece un aviso indicándonos que se va a ejecutar un applet "de origen desconocido". Pues vaya... Y cuanto más lees, mejor: "esta aplicación se ejecutará con acceso restringido, lo que puede poner en peligro su computadora e información personal". Eso sí: "Active la casilla (de que acepta los riesgos) y haga clic en Ejecutar para iniciar la aplicación".

En fin, from lost to the river, hacemos clic y le damos a ejecutar. Nos sale otro aviso y le decimos que sí, que permitimos la ejecución del Applet de Java. Y por fin nos carga la aplicación de prueba. Nos sale una página bastante simple donde podemos poner un texto en la parte superior (y ojo, no poner nada en la parte inferior porque si no, fallará la firma).

Al darle al botón "Firmar Texto" se inicia una cadena de hasta 6 solicitudes de permiso a las cuales vamos respondiendo que si, que firmar, poniendo la contraseña (el PIN), dándole a permitir, que si, que lo que quiera:

Finalmente, si lo hemos hecho rápido (el Timeout parece muy corto en la aplicación), nos aparece nuestro texto firmado.

Que bien... ¿y tanto trabajo para esto?. Bueno, hasta ahora sólo hemos comprobado que funciona. Una vez que tenemos el DNIe activado, funcionar con él no debería ser muy difícil.

En el portal de www.usatudni.es nos muestran una lista de servicios on-line que se pueden (en teoría) hacer con el DNIe.

Por ejemplo voy a comprobar mi saldo de puntos del carnet de conducir y mis antecedentes (OMG) en https://sede.dgt.gob.es/es/tramites-y-multas/permiso-por-puntos/consulta-de-puntos/. Vamos a esa página y luego hacemos clic en "consulta de puntos con certificado". Automáticamente nos salta el DNIe:

Al darle a "Aceptar" no tenemos que hacer nada más. Ahí está soy un crack y tengo todos los puntos!. Me lo imaginaba pero no estaba nada seguro!.

Bueno, voy a poner un resumen de pasos para hacer funcionar el DNI electrónico en un Windows 8:

  1. Renovar la contraseña y los certificados del DNI tal y como se explica en esta página.
  2. Conectar el lector del DNI electrónico en el ordenador y meter el DNI en el lector.
  3. Windows 8 debería detectar el DNI automáticamente, le damos a "Aceptar".
  4. La luz del lector se pone verde, parpadea y al final se pone roja... lo cual da bastante mala espina.
  5. USAR EL INTERNET EXPLORER. Para otras cosas no lo recomendaría y de hecho, importante, quitarle antes cualquier rastro de spyware o adware que tenga, no queremos que nuestro PIN o contraseña del DNI se lo lleven los rusos...
  6. Vamos a ésta página y seguimos lo pasos que he explicado antes.

En próximas entradas explicaré como acceder a otros servicios y veremos que otros muchos que deberían funcionar, lo cierto es que no van.

Saludos!

viernes, 7 de febrero de 2014

Sabadell Security

El pasado mes de Junio recibí completamente por sorpresa una tarjeta de débito del Banco Sabadell, con el que tengo una cuenta abierta desde hace años. WTF...!! (En español: que coj...!!) - pensé. Pero si mi tarjeta es válida hasta Marzo de 2014!!. Al llamar una amable señorita que intento convencer que mi vida dependía de que activara esa tarjeta: Que es mucho mas segura, que tiene tecnología Contactless, que es mucho mas bonita... y azul!!... En fin.

Por supuesto que no he activado la tarjeta hasta hoy, porque se acerca el mes de Marzo y empiezo a temer por mi vida.

El caso es que al activarla (desde mi ordenador) me he llevado la sorpresa de que el nuevo número PIN, asignado a la nueva tarjeta... es el mismo que el antiguo PIN!!!

Como podemos ver en la imagen, el último paso antes de activar la tarjeta es mostrar, bajo esos asteriscos tan coloridos el nuevo PIN:

¿Que por qué no quiero usar mi antiguo PIN?. Pero si es lo más fácil, cómodo y seguro!!!. Si así no me tengo que aprender engorrosos números de 4 cifras sin ningún sentido!!.

Pues la cosa es muy simple. Es igual que cuando se nos olvida una contraseña y pedimos recordarla, nunca nos deberían mandar la antigua, ya que esto significa que esta contraseña se encuentra almacenada en algún fichero sin "hashear". En este caso mi PIN se encuentra en alguna base de datos del banco sin cifrar o con un cifrado reversible.

Eso en sí no tiene por que ser malo. Al fin y al cabo, el sistema tiene que poder comparar que el PIN introducido en el cajero es el mismo que el de la tarjeta (cosa que no se realiza en el cajero, que no es más que un terminal tonto, que lo único que hace es enviar los números de la tarjeta y el PIN a los servidores del banco, que es donde realmente se hace el "macheo").

El problema es que igual que el sistema ha obtenido los dígitos de la tarjeta de un sistema y el PIN de otra y los ha comparado con lo que le llega del cajero, una persona con acceso al sistema (y conocimientos) podría hacer lo mismo. Y no mola. No me mola que alguien pueda conocer todos los datos de mi tarjeta incluido el código PIN.

El problema que si en vez de almacenar el pin en claro (o con un cifrado reversible) se almacenaran los hashes SHA-512 del PIN de la tarjeta, como se hace en el /etc/shadow de UNIX/Linux, daría igual. La debilidad del sistema es que hay 10.000 pines y solo 10.000, del 0000 al 9999 y no hay más. Cada uno con un hash único. Por tanto, conociendo esos 10.000 hashes estamos en las mismas.

Así que estamos en las mismas. Hasta que no aumentemos la longitud del PIN hasta por lo menos 12 números (aún así "solo" habría un billón de combinaciones). Lo ideal sería que los cajeros tuvieran un teclado alfanumérico y cada uno tuviera su contraseña alfanumérica de longitud variable de acceso a la tarjeta. ¿Demasiado dificil para el común de los mortales?. Yo creo que no.

Mientras tanto, deberemos seguir confiando en la seguridad física, electrónica y profesional de los bancos.