Carlos A. Castillo L.

Han pasado más de 50 años desde la invención de la banda magnética y aún hoy en día es el mecanismo más usado a nivel mundial en las tarjetas de crédito y débito bancarias para almacenar de forma “segura” la información requerida para realizar una transacción electrónica. Sin embargo, actualmente es evidente que este mecanismo no proporciona la seguridad adecuada teniendo en cuenta la gran cantidad de fraude electrónico que ocurre día a día con los llamados “skimmers”; dispositivos electrónicos escondidos en los cajeros automáticos  diseñados para copiar la información almacenada en la banda magnética. Dicha información, junto con el PIN, el cual puede ser capturado con mini cámaras o teclados falsos, permiten la clonación de tarjetas con las cuales posteriormente se realiza fraude electrónico. Con el fin de proporcionar más seguridad a los datos de las tarjetas, hace aproximadamente 15 años se empezó a implementar las llamadas “Tarjetas Chip”. Claramente dichas tarjetas proporcionan un grado de seguridad mayor que las tradicionales de banda magnética (aunque desde luego es vulnerable), sin embargo, su adopción ha sido bastante lenta debido a todos los cambios de infraestructura, hardware y software que se deben realizar a nivel mundial para asegurar compatibilidad.

En paralelo al lento desarrollo de la seguridad de las tarjetas de crédito, la creciente popularidad de los dispositivos móviles en los últimos años ha empezado a generar interés en utilizar el dispositivo como único medio de pago con el fin de eliminar por completo las tarjetas de crédito físicas. Una de las empresas interesadas en este tipo de sistemas de pago móvil es Google la cual lanzó al mercado a finales de 2011 Google Wallet: Una aplicación para su plataforma Android que permite el almacenamiento de información bancaria de tarjetas de crédito con el fin de realizar transacciones bancarias con el dispositivo mediante el uso de la tecnología de comunicación de corto alcance NFC (Near Field Communication) para transmitir de forma segura los datos bancarios entre el dispositivo y el punto de pago.

El sistema en general cumple con su objetivo, sin embargo, el pasado 8 de febrero de 2012 Joshua Rubin publicó en el blog de la empresa zvelo detalles sobre una vulnerabilidad en la última versión de Google Wallet que permite obtener el PIN (número de 4 dígitos), utilizado para autorizar las transacciones, en cuestión de segundos. Una vez se tiene el PIN, es posible realizar transacciones bancarias con el dispositivo físico (en caso de que sea perdido o robado) o incluso es posible utilizarlo para acceder a los datos bancarios de las tarjetas cifrados y almacenados en un chip (separado del hardware del dispositivo) llamado Secure Element (SE).  La vulnerabilidad reside en el hecho de que el PIN no es almacenado dentro del SE sino codificado (SHA256) en una base de datos SQLite dentro del dispositivo mismo. Junto al hash del PIN se encuentra el “salt” que puede ser utilizado para realizar un ataque de fuerza bruta el cual no tardaría demasiado teniendo en cuenta que el PIN es de tan sólo 4 dígitos numéricos por lo que el número de posibilidades para obtener un hash igual es de máximo 10.000. Joshua diseñó una prueba de concepto, Google Wallet Cracker, para demostrar el ataque:

La base de datos accedida está protegida únicamente por el “sandbox” de la aplicación por lo que es necesario permisos de administrador para acceder a la información desde otra aplicación. Sin embargo, poco después de que la vulnerabilidad del PIN fuera anunciada, un nuevo fallo de Google Wallet salió a la luz pública; esta vez no eran necesarios conocimientos técnicos avanzados ni permisos de administrador en el dispositivo. El nuevo fallo permite obtener acceso a los fondos existentes en la tarjeta prepagada de Google con tan solo ir a la configuración de la aplicación y borrar toda la información de Google Wallet. Luego de realizar este procedimiento, al iniciar de nuevo la aplicación, Google Wallet solicitará un nuevo PIN y, debido a que la tarjeta prepagada de Google está atada al dispositivo y no a la cuenta de Google, al añadir una nueva tarjeta quedará agregada la antigua que estaba en el dispositivo. En otras palabras, a pesar de borrar los datos de la aplicación, la información de la tarjeta prepagada no fue borrada del dispositivo por lo que al ingresar el nuevo PIN, la tarjeta será reconocida por Google Wallet. Al respecto, el sitio web The Smartphone Champ publicó el siguiente video donde se demuestra la vulnerabilidad:

El fallo es realmente grave teniendo en cuenta que la única protección que tiene el usuario frente a este ataque es bloquear el dispositivo. Sin embargo, ante cualquier descuido, alguien podría robar el teléfono celular, cambiar el PIN y realizar transacciones con los fondos disponibles en la tarjeta prepagada de Google. La reacción de Google fue suspender temporalmente el uso de las tarjetas prepagadas como medida de precaución mientras se busca una solución permanente.

Personalmente pienso que los sistemas de pago móviles están apenas en un estado primitivo y Google Wallet es un ejemplo de que incluso el software pensado para ser extremadamente seguro puede ser también vulnerable, utilizando métodos tanto avanzados como simples. De todas formas pienso que estas tecnologías seguirán evolucionando y de a poco irán cambiando la forma en que realizamos las transacciones bancarias para así ir eliminando de a poco las obsoletas tarjetas plásticas de banda magnética y reemplazarlas por el cada vez inseparable compañero diario: nuestro teléfono celular.

Fuente: Microsoft

El 16 de junio la compañía de seguridad informática VirusBlokAda descubrió un ejemplar de código malicioso bastante particular debido a las siguientes características:

• Se aprovecha de una vulnerabilidad en Windows de la que hasta ese momento no se tenía conocimiento: La falla reside en la posibilidad de ejecución de código con el solo hecho de ver iconos de “acceso directo” por lo que el usuario, con solo abrir una carpeta que contenga accesos directos (una compartida en la red, una memoria USB o hasta una página web), puede ejecutar sin darse cuenta el código malicioso.

• Malware firmado digitalmente: Existen dos variantes del malware que usan certificados digitales de empresas legítimas (Realtek Semiconductor y JMicron Technology). Lo anterior podría hacer pensar al usuario, erróneamente, que el malware es software válido perteneciente a alguna de las dos empresas mencionadas.

• Afecta casi todas las versiones de Windows: Según el descripción publicada por CVE, la vulnerabilidad afecta Windows XP SP3, Server 2003 SP2, Vista SP1 y SP2, Server 2008 SP2 y R2, y Windows 7. Desde luego en la lista no se encuentra Windows XP SP2 debido a que el soporte fue descontinuado por Microsoft.

• Orientado a sistemas SCADA: La primera muestra de malware estaba orientado a atacar sistemas de propósito específico del fabricante Siemens los cuales son usados para controlar y administrar procesos industriales críticos como por ejemplo la infraestructura de energía eléctrica.

Hasta este punto, la amenaza parecía ser muy puntual que no afectada masivamente a las personas aunque quedaba descubierta la vulnerabilidad esperando por una solución. Sin embargo, el 18 de julio la vulnerabilidad fue publicada en Internet. Lo anterior provocó que el SANS cambiara su indicador de amenaza de verde a amarillo debido a que aún no se contaba con la solución y, por el contrario, la forma de explotar la vulnerabilidad había sido publicada. Incluso, el famoso software Metasploit implementó un módulo con el exploit lo cual incrementaba las posibilidades de un despliegue de ataques aprovechando dicha vulnerabilidad.

Como consecuencia de lo anterior, conocidas familias de malware han aparecido empleando como vector de ataque la vulnerabilidad utilizada inicialmente por Stuxnet. Ejemplos de esto son el Zombie Infection Pack, el virus polimórfico Sality y hasta el famoso troyano bancario Zeus.

Es de esta forma que un código malicioso diseñado con un objetivo y un alcance limitado se convierte en una amenaza de talla mundial del estilo Conficker. Es en este punto en donde se da la respuesta al titulo de este post: Si no quiere ser infectado por todas las variantes de malware que existen y muy seguramente aparecerán en un  futuro, que se aprovechan de esta vulnerabilidad de Windows, instale el parche, fuera de ciclo, que Microsoft que publicó el día de hoy: MS10-046.

PD: En caso de haber seguido el procedimiento propuesto por Microsoft en donde se deshabilitan los iconos en Windows, en éste enlace se encuentra la herramienta para reversar la modificación realizada.

PD2: Un ejemplo del uso del módulo de Metasploit

Windows LNK vulnerability (CVE-2010-2568) in action from hardez on Vimeo.