(Comenzamos la semana con la colaboración de un amigo al que muchas veces hemos invitado a escribir, pero hasta ahora no se había decidido. Nos ha pedido, no obstante, que desea firmar anónimamente y que su colaboración aparezca firmada con el pseudónimo Walt Kowalsky. Esperamos que les parezca interesante)
Llevo tiempo siguiendo este interesante blog, que se ha convertido en uno de mis favoritos y después de un tiempo queriendo aportar mi granito de arena, me he lanzado a la piscina y he preparado la siguiente colaboración que espero que les sea de agrado.
A pesar del título del post, no esperen un enfrentamiento a lo Quevedo-Gongora, puesto que por ahí no van los tiros. Voy a ponerles en situación comenzando con el recurso fácil de la pregunta retórica: ¿se han copiado de ustedes en algún examen? Seguramente contestarán que sí y si no me equivoco muchas veces habrá sido de mutuo acuerdo. Pero, ¿se han copiado de ustedes sin su permiso? Si ha sido así traten de recordar la sensación de aquel momento. Llevaban semanas preparando ese examen concienzudamente, noches sin dormir, cafeína recorriendo su torrente sanguíneo para al final tener la certeza de que el día del examen la cosa va a ir bien y que pasaremos la prueba con nota. Entran al examen y comprueban que a su lado se sienta aquel compañero que únicamente vieron el primer día de clase, aquel que se dedicó a salir todos los jueves y a llegar a laboratorio para que el compañero le haga las prácticas. Comienza el examen y todo marcha de acuerdo con su plan maestro, pero entonces se dan cuenta de que el compañero de al lado está copiando descaradamente nuestro examen… Se acaba el examen y unas semanas más tarde cuando salen las notas comprueban que aquel jeta ha sacado casi la misma nota que nosotros, pero sin asistir a clase, SIN DEDICARLE RECURSOS. En ese momento piensan en todo el tiempo y esfuerzo que han dedicado a prepararse para aprobar ese examen, y lo poco que ha invertido nuestro compañero en aprobar, y piensan que la vida no es justa.
Alguien les susurra C´est la vie….
Hace casi un año, el pasado 28 de Febrero de 2009 YouTube dejó de funcionar durante 2 horas. La incidencia —una incidencia de su conectividad— no se debió ni a la falta de redundancia de sus infraestructuras, ni a un fallo coordinado de todos sus proveedores, ni a un apagón simultáneo de todos sus centros de datos; ni siquiera al súbito interés simultáneo y mundial por el último vídeo de la Obama girl. YouTube dejó de funcionar debido al secuestro de parte de su direccionamiento IP por parte del operador Pakistan Telecom. ¿Secuestro? Sí, secuestro o suplantación del direccionamiento IP, algo tan antiguo como el propio protocolo BGP.
Hace poco tuvimos la necesidad de incluir unos certificados SSL firmados por VeriSign para la navegación HTTPS en un 
Comencemos profundizando un poco más en como Mifare realiza el proceso de autenticación. En primera instancia el lector le comunica a la tarjeta que quiere realizar una operación sobre un sector de datos determinado N. El tag o tarjeta en ese momento remite un número aleatorio Nc (Nonce del cliente) de 32 bits a modo de reto, para que sea cifrado con la clave privada compartida previamente. Como respuesta, el lector remite el reto cifrado y un número aleatorio Nr (Nonce del lector) para que el tag lo cifre con la clave privada, generando una trama de 64 bits. En última instancia la tarjeta le envía al lector su reto cifrado. En este momento ambos tienen la certeza de que los dispositivos son legítimos. Destacar que los dos últimos intercambios se realizan ya de forma cifrada, permaneciendo en claro tan solo el envío de la petición de lectura y Nc. La figura de la izquerda ilustra el proceso de handshake.
En este post y los siguientes de la serie vamos a ver cómo conseguir romper la seguridad de las tarjetas de proximidad RFID basadas en tecnología Mifare. Ello conllevará la lectura y modificación interna de sus datos e incluso el clonado de las mismas.
Como ya hicimos 
Aún recuerdo cuando empecé a introducirme en el mundo de la auditoría y seguridad allá por el año 2001, en una asignatura de la universidad, con un profesor que daba una asignatura enfocada a la gestión de empresas, y pensé este hombre habla de cosas interesantes y no de teoremas y algoritmos que probablemente no emplearé en esta vida. A partir de ese momento comencé a asistir a charlas en las que me dejaba impresionar por la corbata y la dialéctica de los ponentes y asistentes que disponían de sabiduría sobre todos los campos de la materia. Ya sabéis: corbatas, trajes, y retórica (nada nuevo bajo el sol).
(N.d.E. Durante el fin de semana hemos estado haciendo algunos cambios en el blog, para lo que tuvimos que desactivar algunas funcionalidades. En cualquier caso, ahora todo debería funcionar correctamente)
Otra cuestión a tomar en cuenta es la generación de snapshots sobre snapshots. Me explico con un ejemplo: antes de una intervención hemos generado un snapshot, todo ha ido bien, pero no lo borramos “por si acaso”. Al poco tiempo tenemos otra intervención en el mismo servidor, y generamos de nuevo otro snapshot. Esto es totalmente posible y se hace habitualmente, pero no creo que sea una práctica recomendable. El resultado es que se van generando “discos hijos”, cada uno con sus puntos de cambios, y al final el disco virtual inicial acaba siendo una segregación de ficheros, los cuales en caso de error son mucho más complicados de tratar. Personalmente, después de una intervención tras comprobar que todo ha ido bien siempre consolido los snapshots, con lo cual se vuelven a fundir los discos en uno sólo. Tal vez el gráfico que se muestra (fuente 