En artículos anteriores de nuestro compañero José Vila, éste nos explicaba el funcionamiento y configuración de una nueva funcionalidad de Snort, los “Extra Data”. Tras un tiempo utilizándolo descubrí una característica de la que no me había dado cuenta hasta el momento y que quiero compartir con vosotros ya que se le puede sacar bastante partido.

Esta característica es realmente impresionante ya que te permite ver información que antes no era posible —o al menos no de forma tan directa—, facilitando la identificación de ataques. Al activar la opción log_uri, el preprocesador almacenará la URI para la sesión completa y, si la alerta está configurada con las opciones “flow:from_server, established”, cuando salte esta alerta proveniente de la respuesta de un servidor, aparecerá la petición del cliente que la ha provocado.

Para hoy jueves, Día de Internet, traemos una entrada de Cristina Martínez Garay, abogado de Derecho Tecnológico de la firma Rocabert & Grau Abogados, bufete que colabora con Security Art Work, en un ámbito un poco diferente a lo que solemos tratar en SAW, pero que seguro que interesa a muchos de los que nos leen.

Hoy, con motivo de la celebración del día de Internet, promovido desde 2005 por la Asociación de usuarios en Internet a las que se han ido sumando diferentes asociaciones españolas, me gustaría reflexionar sobre las virtudes y facilidades que los Servicios de la Sociedad de la Información han traído a las vidas de muchos ciudadanos y empresas internautas y qué mejor forma de hacerlo en los tiempos que corren que reflejarlo en la búsqueda de empleo.

Recopilando nuevas tendencias e investigaciones sobre detección de intrusos, existe lo que se denomina ABAIS o Sistemas Inmunes Basados en Agentes Artificiales. Este tipo de sistemas tratan de emular las defensas del cuerpo humano para ofrecer una solución técnica que permita no solo identificar posibles intrusos en un sistema sino incluso acabar con ellos. Existe numerosa bibliografía detrás de este concepto, que comenzó a principios de la pasada década con Harmer P.K.

Como concepto derivado de un BIS o Sistema Inmune Biológico, los trabajos han sido orientados al seguimiento básicamente de tres paradigmas:

• La Selección Negativa
• Clonación Selectiva
• La teoría de la señal de riesgo

(N.d.E. Entrada realizada por José Luis Villalón y Borja Merino)

Cisco Modular Policy Framework (MPF) es un conjunto de funcionalidades y reglas que nos proporciona Cisco para configurar de forma flexible sus firewalls, pudiendo realizar un filtrado más específico de las conexiones que atraviesan nuestra red.

Habitualmente, cuando configuramos un firewall, solemos centrarnos principalmente en las capas de red y transporte, filtrando únicamente por direcciones IP, puertos, o incluso flags, no obstante, no debemos olvidarnos de que esto no siempre es suficiente, por lo que debemos poder controlar también las capas superiores, pudiendo filtrar por parámetros concretos a nivel de aplicación.

Como ya vimos hace tiempo, Cisco ASA nos da la posibilidad de poder normalizar conexiones TCP, no obstante, es realmente MPF quien hace posible esta normalización, junto con otras funcionalidades avanzadas como comprobaciones a nivel de checksum de paquete, tcp windowing, filtrado de flags, gestión de ancho de banda, o incluso, la posibilidad de hacer un bypass del stateful inspection del sistema. No obstante, para este post usaremos el framework para llevar a cabo una inspeccionar tráfico a nivel de aplicación.

Recordando el post de Roberto sobre la identificación de accesos de logmein, podemos configurar nuestro ASA para filtrar determinados patrones de tráfico a nivel de aplicación; en nuestro caso y para mantener un ejemplo similar, bloquearemos las peticiones DNS a dominios de logmein.com, aunque también se podría inspeccionar el tráfico HTTP para evitar ciertas conexiones.

Un año más se ha celebrado en Madrid, organizado por Borrmart, Seg2, el congreso de seguridad ya clásico en el sector; y un año más hemos estado por allí, compartiendo con amigos y compañeros historias, anécdotas (incluida la de cuando era consultor en Villaconejos ;) y cafés.

El congreso comienza con una breve introducción de Javier Borredá, que da paso a las intervenciones de Ana Borredá (Directora de Seguritecnia) y Mercedes Oriol (Directora de Red Seguridad). Entre ambas hacen un repaso a las ediciones del congreso, destacando el papel de Mapfre y Prisa apoyando a éste desde sus inicios y, desde hace dos años, como padrinos de honor; también revisan el avance de la convergencia en este tiempo, en especial desde el punto de vista normativo (ENS, LPIC…) y en el ámbito nacional, así como la evolución en estos cuatro años de la figura del CSO.

Desde ENISA el día 07 de Marzo de 2011 se publicó el informe “Botnets: Detection, Measurement, Disinfection & Defence”, donde se describe de una manera muy extensa las medidas de detección, desinfección y defensa para luchar contra este tipo de amenaza tan presente hoy en día.

Como ya he comentado el informe es extenso y ofrece gran cantidad de ejemplos que ilustran cada una de las recomendaciones para que se entienda cómo puede ayudar a mitigar. No pretendo en esta entrada hacer un resumen del informe sino destacar algunos aspectos que me han llamado la atención del mismo.

En primer lugar destacaría como bien comenta el informe la necesidad de medir la eficacia de la medidas que adoptamos para mitigar las botnets. Es decir, responder a preguntas como, ¿Haber puesto un DNS sinkhole ha tenido un efecto positivo para mitigar esta amenaza? ¿La campaña de concienciación ha funcionado?, etcétera. Entonces, como no podía ser de otra manera para responder a esta pregunta deberemos definir una serie de indicadores relacionados con esta amenaza que nos determinen de manera clara y objetiva si las medidas están teniendo efecto. Ejemplo de estos indicadores podrían ser:

Hace unos días se hizo público una vulnerabilidad sobre PHP-CGI. Esta vulnerabilidad puede ser aprovechada para conseguir código fuente de sitios web vulnerables, lo que significa que el código php de la web vulnerable queda expuesto para que sea analizado por un atacante que explote dicha vulnerabilidad. Hay que tener en cuenta que en muchos casos se encuentran usuarios, passwords, rutas de ficheros, ips privadas de servidores, etc dentro del código php, por lo que en estos casos, la criticidad de esta vulnerabilidad es mayor.

Dicha vulnerabilidad puede ser explotada de un forma muy sencilla, añadiendo los caracteres ?-s al final de la URL, que es lo mismo que ejecutar php-cgi con la opción -s.

La semana pasada un conocido, propietario de una inmobiliaria, me comentaba que una persona de la Agencia Tributaria se había personado en su oficina para solicitarle mediante carta que le proporcionase los datos de personas que tenían en aquel momento una propiedad a la venta, concretamente el Nombre y apellidos y NIF, además de algunos datos sobre las propiedades a la venta. Ante esta situación, esta persona me preguntaba si debía, de acuerdo a la LOPD, entregar esos datos a la Agencia Tributaria o no.

En este sentido, aunque la cesión o comunicación de datos entre el Responsable del Tratamiento y una tercera parte requiere el consentimiento del afectado, la LOPD tiene varios supuestos que eximen de este consentimiento. En nuestro caso y como veremos después, es aplicable el artículo 11.2 a) de la LOPD o el 10.2 a) del RDLOPD, algo más detallado y que recogemos a continuación:

Hoy comienza el reto de criptografía organizado por la Escuela Técnica Superior de Ingeniería Informática de la Universidad Politécnica de Valencia y patrocinado por S2 Grupo.

La prueba en la que participan alumnos de Ingeniería Informática de esta Universidad, está enmarcada dentro de las actividades propuestas para del Año Turing. Las bases de la competición las podéis encontrar en el siguiente enlace; los alumnos deberán resolver doce criptogramas dentro de cuatro niveles de dificultad diferentes, donde todos ellos han sido cifrados mediante el algoritmo Vigenèrè. El cifrado de Vigenère es un cifrado de sustitución simple polialfabético, basado en el clásico Cesar y muy amigo de Friedrich Kasiski ;)

Para dar como válida cada solución, se deberá entregar tanto el texto en claro como la cadena de cifrado. Para aquellos crackeadores de códigos que aporten la solución en el menor tiempo posible, S2 Grupo como patrocinador, aportará los siguientes premios:

1º: iPad 2, WIFI 16GB
2º: iPod nano 8GB
3º: iPod shuffle

Los sufridos regalos serán entregados a finales de este mismo mes en las instalaciones de la ETSINF.

En la pasada Rooted, estuve hablando unos minutos con Sebastián Guerrero y le pregunté como hacía él para descifrar el tráfico cifrado que enviaban las aplicaciones. Me comentó que la forma más fácil para él, era modificar la aplicación para que mostrara las peticiones que se estaban enviando. Esta me parece una buena opción cuando se está analizando una aplicación en concreto, pero me parece un poco engorrosa si solo quieres curiosear que es lo que están enviando tus aplicaciones.

El problema en las aplicaciones de Android reside en que si intentas hacer un man-in-the-midle y el certificado no está firmado por una CA de confianza, no aparece ningún mensaje para que decidas confiar o no en ese certificado, sino que directamente no deja establecer la comunicación.