El pasado viernes, estuvimos participando en una sesión sobre “ITIL y Seguridad en la práctica”, organizada por nuestros amigos de Tecnofor en Madrid. Asistieron más de cincuenta directivos de entidades públicas y privadas de prestigio. Nos acompañó Manuel Mata, director de TI de Ciudad de las Artes y las Ciencias de Valencia, a quien desde aquí queremos agradecer el favor de su participación y su interés y esfuerzo.

Tras una introducción de Marlon Molina (Tecnofor), José Antonio Espinal (Tecnofor) presentó los referenciales de base de ITIL y los SGSI, preparando el terreno para los casos prácticos presentados a continuación por José Rosell (S2 Grupo) y Manuel Mata (CAC).

(Para hoy miércoles, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, elaborada conjuntamente con Manuel Benet)

La suplantación de identidad podría definirse según la RAE como una combinación de suplantar e identidad. Veamos qué dice la RAE al respecto:

Cuando comencé mi carrera profesional como técnico de Sistemas hace algo más de nueve años (hay que ver cómo pasa el tiempo), una de las primeras responsabilidades que me “cayó” encima en mi anterior empresa fue la gestión del sistema de monitorización de la infraestructura TIC propia y de clientes. La situación entonces era muy diferente de la actual. Nagios acababa de nacer a partir de NetSaint, y la madurez de este tipo de software distaba mucho de ser la actual; el sistema que utilizábamos (Big Brother) no era el colmo de la usabilidad, aunque su interfaz era extremadamente intuitivo. Los monitores eran bastante más rudimentarios que hoy en día, pero aun así, conseguíamos saber si las cosas funcionaban, por la cuenta que nos traía; teniendo en cuenta que por aquel entonces alojábamos la web de varios clientes importantes, una caída solía ser la antesala de problemas, así que si además no la detectábamos, imagínense. En definitiva, puede decirse que durante un buen puñado de años, tanto en aquella empresa como en la actual, mis andanzas como informático han estado ligadas entre otras cosas a gestionar sistemas de monitorización.

Aunque hoy en día aún es posible encontrar alguna empresa sin ningún sistema de monitorización TIC básico o uno que “ahí está” pero nadie mantiene ni “escucha”, las cosas han cambiado mucho. Ha habido una mejora significativa al menos en el primer paso: la detección de las incidencias. Ahora ya nadie se extraña de que sea necesario un sistema de monitorización TIC que al menos nos avise de cuándo el servidor de correo ha dejado de funcionar y así evitar los gritos de la alta dirección. Podría decirse que casi nos felicitamos por ello, como si eso fuese un gran logro. Vamos a dejar de lado aspectos de monitorización más complejos y todo el capítulo de gestión, tratamiento de las incidencias y análisis histórico; aunque debería ser inseparable de lo anterior, seguramente eso es demasiado.

(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….

(Para acabar la semana en que hemos superado los 1000 suscriptores al feed, hoy tenemos una colaboración de Rafael García, amigo, antiguo colaborador de S2 Grupo y con extensos conocimientos y experiencia en la gestión de centros de proceso de datos, como muestra en su blog. Esperamos que les guste la entrada tanto como a nosotros; por lo demás, pasen un buen fin de semana, nosotros nos vamos hasta el lunes, aunque esporádicamente puede que aparezcamos por “el” Twitter)

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.

BGP4 (RFC 1771 y RFC 1772) es el protocolo que se utiliza para intercambiar tráfico entre los proveedores de servicios de Internet. Sus funciones son bastante simples: básicamente permite que los sistemas autónomos (AS) —las subdivisones organizativas que gestionan los prefijos de enrutamiento en Internet, habitualmente un ISP— comuniquen a otros sistemas autónomos cómo alcanzar redes en Internet. Específicamente BGPv4 intercambia prefijos de direcciones de Internet seguidas de los identificadores de los sistemas autónomos a través de los cuales se alcanza dicho direccionamiento. Todos los ASs intercambian esta información entre ellos asumiendo que es correcta. BGP, aunque permite implementar políticas sobre los prefijos que anuncia o deja de anunciar, no tiene ningún mecanismo para saber si la información de sus tablas de enrutamiento es válida y si realmente se la está suministrando quien debe suministrársela. Este funcionamiento se denomina confianza transitiva, vamos, que si me creo lo que me dices me estoy creyendo lo que a tí te dicen todos tus vecinos y los míos te creerán. Transitive faith podrían haberle puesto.

Hace poco tuvimos la necesidad de incluir unos certificados SSL firmados por VeriSign para la navegación HTTPS en un proxy inverso Squid. El problema fue el hecho de que el cliente que lo requería había gestionado personalmente la creación y firma del certificado con una entidad certificadora internacional, la cual realizó todo el proceso con una herramienta propietaria basada en JAVA. Esto hizo que nosotros recibiéramos un fichero binario ilegible por OpenSSL, y sobre todo, por Squid.

Tras indagar un poco y averiguar que la aplicación del cliente había hecho uso de la herramienta keytool de JAVA respiré aliviado, pues suponía que seria trivial obtener los datos. Primeramente, pensando que en 20 minutos podría estar almorzando inspeccione el contenedor mediante el comando:

# keytool -list -v -keystore server_keystore

Tras introducir el pasado viernes algunos aspectos teóricos relevantes de RFID, en esta segunda parte entraremos en cuestiones prácticas que nos darán resultados muy interesantes.

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.

Este proceso de saludo a 4 bandas es importante ya que de él extraeremos la información necesaria para inferir la clave privada del sector.

Procedamos ahora a realizar una prueba de concepto que nos permitirá, a partir de la captura de la información anterior, inferir la clave privada. Pero, ¿cómo podemos capturar una comunicación real entre un tag y un lector? Aquí es donde juega un papel importante el PROXMARK III. Este dispositivo desarrollado por Jonathan Westhues permite realizar sniffing de varias tecnologías RFID desde baja frecuencia (LF 125 Khz) a alta frecuencia HF (13.56 Mhz) y entre ellas la que nos interesa ISO14443 tipo A sobre la que se basa Mifare. En un principio el PROXMARK III supondría el Hardware sobre el cual se pueden implementar diversas capas físicas y de enlace, de diferentes protocolos, simplemente programando sus integrados con la especificación que se requiera.

¿Quién vigila a los vigilantes?, Juvenal, Satiras VI, 347

Ayer leí un interesante post de Microsiervos en el que se resumen las ideas principales expuestas por Fernando Rueda en el programa radiofónico La rosa de los vientos, de Onda Cero, sobre el uso y capacidades del sistema SITEL. Hace tiempo que quería preparar un resumen similar, pero, ya que se me han adelantado, me basta con referenciarlo. Básicamente, aunque está claro que sólo se pueden grabar conversaciones telefónicas de aquellas líneas que se han “pinchado” previamente, sí se puede tener información de las llamadas que cualquier línea ha hecho y de los SMS intercambiados y del geoposicionamiento de los móviles, aunque no se haya decidido previamente espiarlos. Es una cuestión de espacio de almacenamiento. Aunque, ya saben, como consecuencia de la ley de Moore y visto la evolución de Google, YouTube, etc. está claro que esto es un impedimento pasajero, ya que el almacenamiento tiene un coste residual cercano a cero, en la práctica.

En resumen, que dentro de poco, quien controle SITEL (y los otros sistemas similares que hay por el mundo) podrá escuchar cualquier conversación telefónica que desee, aunque no se le haya ocurrido con anterioridad que sería interesante grabarlas.

(Esta semana la empezamos con una colaboración de D. Jorge Bermúdez, fiscal especialista en cibercrimen de la Fiscalía Provincial de Guipúzcoa, y miembro del Servicio de Criminalidad Informática de la Fiscalía General del Estado, relacionada con la entrada que publicamos hace algún tiempo sobre posesión o distribución de pornografía infantil. Más allá de agradecer a su autor el esfuerzo de escribirla y de intentar acercar dos mundos en principio tan diferentes como es el de la Judicatura y el de las Tecnologías de la Información, estoy seguro de que la encontrarán interesante y muy ilustrativa.)

El pasado 27 de octubre de 2009 di una ponencia en el III ENISE, en León, que pareció ser del agrado de uno de los autores de su blog, José Rosell. Como Google Reader ha tenido a bien recomendarme su blog, y he leído una entrada sobre la posición del Tribunal Supremo en cuestiones de distribución de pornografía infantil a través de redes P2P, he considerado oportuno escribir unas líneas, algo un poco más extenso que un mero comentario, y dar mi opinión como jurista.

Una cuestión esencial al analizar estos delitos es la aparición de un término extraño para los ajenos al mundo del Derecho. Se trata de la palabra “dolo”. En derecho penal, dolo es la voluntad de cometer un delito, y se contrapone a la imprudencia, el mero descuido. Si no hay dolo ni imprudencia, estaríamos en el caso fortuito, que no es sancionable. La imprudencia que da lugar a un delito sólo se castiga cuando ese delito incluye formas imprudentes. Por ejemplo, el homicidio lleva una pena si es doloso, artículo 138, y otra si es imprudente, artículo 142.