Qué decirles de las claves apuntadas en esos maravillosos POSSITs (cada día tengo mas claro que nacieron principalmente para eso, para apuntar claves de acceso a dónde sea); ya hemos narrado alguna divertida (en tanto que ajena) historia sobre “puesto7″ o “puesto8″. Esos pueden considerarse ejemplos de usuarios digamos que poco avezados en menesteres de seguridad. Pero de seguridad básica, todos sabemos que nuestro PIN de la tarjeta no se apunta EN la tarjeta.

Otro ejemplo de falta de decoro con la información me ocurrió hace unas semanas en un centro comercial, conocido donde los haya. Mostrador sin dependiente (raro la verdad) y…. cuatro contratos firmados por sus futuros clientes de telefonía móvil; cantidades, DNI, direcciones, teléfonos y demás datos de carácter personal que toda empresa nos pide cuando financiamos algo, nos subscribimos a algún servicio de pago mensual o similar.

[N.d.E. Como pueden ver, ya hemos vuelto de vacaciones, lo que significa que estamos en período de aclimatación, comúnmente conocido en el mundo de los psicólogos y telediarios estivales como síndrome post-vacacional. Sean considerados y tómenlo con calma.]

Los orígenes de la investigación en Internet dentro del Cuerpo Nacional de Policía se remontan al año 1995, cuando dentro de la Brigada de Delincuencia Económica y Financiera se crea un grupo para investigar los delitos relacionados con este medio, que estaban apareciendo en Estados Unidos pero que aún muy pocos conocían en España. Pero no es hasta el año 2001 cuando, dentro de la Comisaría General de Policía Judicial, y adscrita a la Unidad de Delincuencia Especializada y Violenta (UDEV), nace la Brigada de Investigación Tecnológica (BIT, como se le conoce en el mundo de la seguridad), equivalente al GDT de la Guardia Civil que hemos descrito en un post anterior.

Aunque la semana pasada les dije que un servidor —editor del blog— estaba de vacaciones, puesto a actualizar mi blog personal, he pensado darme una vuelta por aquí y actualizarlo también. No les puedo prometer que de aquí al 25 de marzo habrán más entradas, dado el abundante número de días festivos, pero en cualquier caso, de momento esto es lo que hay. La entrada de hoy, que estrena la sección de colaboraciones, procede de una colaboradora habitual de S2 Grupo en temas de índole legal: Ana Marzo, de Equipo Marzo.

Como presentación formal, y más allá de lo que puedan encontrar en su página web, e-marzo es una entidad con oficinas en Madrid, Barcelona y Valencia, que se dedica a la prestación de servicios jurídicos, de consultoría y auditoría. Integrada por un equipo de abogados, consultores, auditores y técnicos, presta sus servicios en diversas áreas: protección de datos, contratación informática, seguridad de datos, propiedad intelectual, comercio electrónico y servicios de la sociedad de la información. Y no me enrollo más, así que vamos con la entrada de Ana.

A pesar de que hoy ya hemos publicado una entrada bastante extensa e interesante sobre VoIP, que recomiendo que no se pierdan, José Miguel me pasa el enlace a un informe publicado por la European Network and Information Security Agency (ENISA), que no quería dejar pasar. Sus autores son Ross Anderson, Rainer Böhme, Richard Clayton, y Tyler Moore, y el informe en cuestión lleva como título “Security Economics and the Internal Market” [pdf], con una longitud total de 114 páginas. Imaginarán que poco más les puedo contar hasta que tenga tiempo de analizar un poco su contenido, aunque por supuesto pueden echarle un vistazo ustedes mismos (que es la razón de esta entrada).

Por otro lado, y dejando de lado el tema de la seguridad, como probablemente saben, estamos en vísperas de las fallas valencianas, por lo que el próximo 19 de marzo es fiesta en Valencia (festividad de San José), que felizmente continúa con las festividades de Jueves Santo, Viernes Santo y Lunes de Pascua. Eso significa que en la capital del Turia únicamente es laborable el próximo lunes y martes, días en los que un servidor (editor y coordinador del blog, de ahí esta matización) está de vacaciones. Aunque intentaré habilitar un sustituto para la publicación de una entrada a principios de la semana que viene, no les puedo prometer nada ahora que las elecciones han acabado, así que si no lo consigo, pasen unas buenas vacaciones, aquellos que las tengan, y nos vemos aquí el próximo 25 de marzo.

Sean buenos. Ya saben que siempre hay gente mirando.

Como vimos en el anterior post, uno de los problemas de seguridad al que se enfrentan las redes VoIP actualmente, al igual que las redes de datos, es a lo que se conoce habitualmente como eavesdropping, es decir, escuchar secretamente los datos transmitidos entre dos o más puntos, sin ser participe directo de ello; en términos de VoIP, como eavesdropping podemos considerar la escucha, sin ser participe, de una conversación entre varias personas. Concretamente, debemos interceptar los mensajes de señalización y los streams de audio de la propia conversación.

Actualmente, muchas implantaciones de VoIP no están correctamente planificadas, y por tanto, comparten el mismo medio físico para transmitir voz y datos; no existe una red paralela independiente ni, en muchos casos, independencia lógica de redes basadas en Vlans, por lo que es habitual encontrar conectados a un mismo switch, tanto teléfonos IP, como equipos de usuarios.

Soy de la sincera opinión de que las entidades bancarias tienen un verdadero compromiso con la seguridad, tanto a nivel técnico, organizativo, físico, como en cualquier otro ámbito que quieran imaginarse, y tengo la certeza de que invierten una cantidad de dinero nada despreciable para mantenerse a la altura que les corresponde, teniendo en cuenta lo que gestionan y lo que se juegan. Como diría aquel, más les vale. Pero, y aquí llega el esperado pero, este tipo de organizaciones, que aparte de una matriz central tienen una nada despreciable cantidad de sucursales (unas más, otras menos), son el ejemplo paradigmático de lo complicado que resulta aplicar políticas realmente seguras —y justificadamente restrictivas— a entornos “distribuidos”, y asegurar que éstas se cumplen siempre.

Digamos que tengo un amigo. Y digamos que por circunstancias que no vienen al caso, ayer éste necesitaba disponer de una copia de la escritura de su hipoteca. Puesto que trabaja, vamos a suponer, en el centro de Valencia, y pensando en evitar el desplazamiento a su oficina, llamó a su sucursal y preguntó si le podían enviar dicha documentación por fax o correo electrónico. La persona que le atendió, después de escuchar el problema, le indicó que podía enviarla por valija interna a una oficina próxima a su trabajo; eso parecía una solución razonable en ese momento, así que tras verificar telefónicamente el nombre y DNI, quedaron en eso.

La Guardia Civil, encargada del orden público y de la represión del delito, ha visto la necesidad de especializar a sus agentes para dar respuestas a la incipiente demanda social contra la delincuencia informática. Así, en 1996 se crea el Grupo de Delitos Informáticos, encuadrado en la Unidad Central Operativa de la Guardia Civil; este grupo inicial ha ido cambiando su denominación y ampliando su plantilla, pasando por Departamento de Delitos de Alta Tecnología (1999), Departamento de Delitos Telemáticos (2000), y finalmente, en 2003, Grupo de Delitos Telemáticos (GDT). Está compuesto por agentes especializados en la persecución de la delincuencia informática y los fraudes en el sector de las telecomunicaciones, cubriendo los cuatro delitos tipificados en el Convenio de Ciberdelincuencia del Consejo de Europa.

Desde finales del año 2002, desbordado el GDT por la enorme demanda (incremento de delitos tecnológicos, apoyos solicitados desde otras unidades…), se inició un proceso de descentralización de las investigaciones, formando el GDT a personal de las Unidades Orgánicas de la Policía Judicial (UOPJ) de cada una de las Comandancias de la geografía española, para constituir Equipos de Investigación Tecnológica (EDITE) provinciales capaces de llevar a cabo las investigaciones básicas en esta materia y de dar una adecuada respuesta al ciudadano en el lugar en que se produce el delito o se encuentra la víctima.

Una vez descrito el funcionamiento básico del protocolo, y centrándonos en su seguridad, vamos a describir brevemente el funcionamiento de la autenticación SIP y un ataque de cracking de contraseñas.

Entrando ya de lleno en el campo de la seguridad, el protocolo SIP proporciona un mecanismo desafío-respuesta para realizar la autenticación, el cual esta basado en la autenticación HTTP. El esquema, conocido como Digest Authentication, evita el envío de la contraseña de los usuarios en texto plano puesto que hace uso de una función hash MD5 y de un secreto compartido por ambas partes: la contraseña.

Su funcionamiento es el siguiente: cuando un cliente intenta establecer una llamada con el servidor, éste responde con un mensaje que incluye un valor aleatorio (nonce) junto al dominio contra el que se va a autenticar (realm). Entonces, el cliente debe enviar una respuesta cifrada al servidor en un mensaje de tipo response, indicando el nonce, el realm junto con el nombre de usuario, el uri y la contraseña. Una vez recibidos estos datos, el servidor compara el valor de la respuesta del cliente con el resultado de cifrar él por su cuenta los mismos datos, con la contraseña que tiene del cliente.

Hace unos meses, como parte del trabajo en seguridad que habitualmente realizamos, nos vimos en la obligación/necesidad de desarrollar el esquema gráfico que les muestro en la imagen inferior, cuya versión es la 1.0. Como pueden ver, en éste se relacionan entre ellos, de una manera temporal, y desde el punto de vista de la seguridad, la aparición de reglamentos y leyes, la creación de nuevos organismos y entidades, incidentes, amenazas de seguridad, y el surgimiento de avances tecnológicos. Sin duda faltará alguno, y quizá disientan en algún punto (¿Windows Vista, como amenaza o avance tecnológico?), pero lo considero una buena aproximación a la evolución del estado del arte en materia de seguridad. Tengan en cuenta, a la hora de estudiar el documento, que la escala temporal no es aritmética, y que a medida que nos movemos hacia el futuro, buena parte de los activos pasan de ser tangibles a intangibles por lo que las amenazas e incidentes varían.

Aunque en un principio pensé en incluir una marca de agua en el documento, no me gustaría que eso disuadiese a ninguno de ustedes de utilizar el documento en algún informe o presentación (por pretencioso que eso pueda sonar); de hecho, como verán las referencias a la fuente son suficientemente pequeñas para no resultar agresivas en un entorno corporativo “ajeno”. En cualquier caso, confío en que, teniendo en cuenta la licencia bajo la que se distribuye, si lo utilizan y lo modifican tendrán la cortesía de mencionar la fuente.

Por último, se agradecerán todas aquellas sugerencias y modificaciones que se les ocurran, y por mi parte, me comprometo a publicar de manera periódica (¿cada dos meses?) una actualización del documento, siempre que hayan habido cambios. Pueden descargarse el fichero, en formato PDF, de este enlace o pinchando en la imagen.

Actualización 06/03: El fichero (y parte de este post) ha cambiado ligeramente, incluyendo una leyenda con la versión y fecha del documento (1.0, 06/03/08).

Como se vió en posts anteriores, SIP (Session Initiation Protocol) es un protocolo de control desarrollado por el IETF, basado en arquitectura cliente/servidor similar al HTTP, legible por humanos, con el que comparte muchos códigos de estado y sigue una estructura de petición-respuesta; estas peticiones son generadas por un cliente y enviadas a un servidor, que las procesa y devuelve la respuesta al cliente. El par petición-respuesta recibe el nombre de transacción. Al igual que el protocolo HTTP, SIP proporciona un conjunto de solicitudes y respuestas basadas en códigos.

El protocolo SIP define principalmente seis tipos de solicitudes: