Yo solo quería alquilar un piso

Hace un año decidí alquilar una vivienda y como el resto de gente de a pie, decidí publicarlo en una web de venta y alquiler de inmuebles. Para ello procedí a registrarme introduciendo información básica como nombre, DNI, dirección, teléfono, etc. Adicionalmente tuve que emplear mis datos bancarios para pagar mejoras como “siempre visible / destacado”, publicar vídeos, imágenes de mayor resolución, primero en la búsqueda, etc.

Después de estar un buen rato entre subir fotos, ordenarlas y redactar la descripción de la vivienda me di cuenta que me habían enviado un correo de la web en donde había dado de alta el inmueble. Era el típico correo de bienvenida donde se me indicaba entre otra información mi usuario y mi contraseña, en texto en claro por supuesto.

Entonces tuve una idea fugaz: si me han mandado la contraseña en texto en claro… ¿no será porque la están almacenando en texto en claro? Y que mejor forma que confirmarlo que emplear los métodos de recuperación de contraseña ante una pérdida de la misma, así que me da por recordar la contraseña donde se indica literalmente “enviadme mi contraseña!”. ¡Sorpresa! Me envían al correo mi contraseña en texto en claro.

Lanzado como soy yo, me pongo en contacto con la web mediante correo electrónico y amablemente les indico que por favor cifren las contraseñas en la base de datos, a lo que recibo una contestación donde se me agradece la información proporcionada y que lo tendrán en mente como mejora.

Un año después he vuelto hacer la prueba y como supondrán todo sigue exactamente igual:

la contraseña de acceso en lala.com para el usuario correo@dom.es es En_Claro

Lo siguiente era consultar con el Departamento de Consultoria de nuestra empresa, para preguntarles si era obligatorio cifrar las contraseñas, ya que aunque yo desde el punto de vista técnico lo tenía clarísimo, desde el punto de vista de la LOPD no lo tenía tan claro. La contestación fue que ese tipo de aspectos estaban regulados por el siguiente artículo:

[RDLOPD] Artículo 93. Identificación y autenticación.

1. El responsable del fichero o tratamiento deberá adoptar las medidas que garanticen la correcta identificación y autenticación de los usuarios.

2. El responsable del fichero o tratamiento establecerá un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado.

3. Cuando el mecanismo de autenticación se base en la existencia de contraseñas existirá un procedimiento de asignación, distribución y almacenamiento que garantice su confidencialidad e integridad.

4. El documento de seguridad establecerá la periodicidad, que en ningún caso será superior a un año, con la que tienen que ser cambiadas las contraseñas que, mientras estén vigentes, se almacenarán de forma ininteligible.

Mi pregunta ahora es para ustedes. En calidad de usuario preocupado por la seguridad de sus datos, ¿debería informar a la Agencia Española de Protección de Datos o les envío un segundo correo para que me vuelvan a indicar que lo introducirán en sus mejoras próximamente? De momento ya les he mandado un segundo correo haciendo alusión al artículo 93, al que estoy esperando respuesta.

Les tendré informados.

Defensas contra nmap

En anteriores post ya hemos hablado sobre la tremenda utilidad que tiene la herramienta nmap. Se ha comentado funcionalidades, optimizaciones y demás investigaciones. Sin embargo, esta herramienta puede ser peligrosa si alguien malintencionado quisiera usarla contra nuestra red. Recordemos que nmap se usa principalmente para descubrir host activos en una red, mostrar sus servicios disponibles, versión de servicio, de sistema operativo, etc. En definitiva, información muy útil para alguien que pretenda hacer maldades.

Por tanto, continuando con la manía que tenemos los que nos preocupa la seguridad de nuestros equipos, vamos a conocer qué medidas se pueden aplicar para ponérselo un poco más difícil a los chicos malos.

1. Conócete a ti mismo

A pesar de ser una frase muy recurrente, tanto en la seguridad informática, filosofía griega o como frase típica de Sun Tzu, la mejor manera de despreocuparte de los escaneos de nmap es teniendo pleno conocimiento de lo que pueden averiguar de tu red, haciendo una serie de análisis de visibilidad externos e internos. Lanza escaneos, desde diferentes subredes, tanto fuera como dentro del perímetro. Comprobarás además si los firewalls están correctamente configurados o ha habido una regla olvidada que haya podido suponer un riesgo. Podrás descubrir servicios vulnerables, si usamos nmap además como herramienta de fingerprinting. Una vez hecha la valoración de la visibilidad, estaremos en condiciones de bloquear servicios, cerrar puertos, parchear vulnerabilidades, etcetc.

Esta práctica, convirtiéndola en periódica, convierte a nmap en una poderosa herramienta de servicios sospechosos. La utilidad Ndiff incluida en la suite de nmap, permite comparar resultados de escaneos, avisando de nuevos puertos descubiertos. Así se podría identificar posibles puertas traseras, o servicios que no deberían estar iniciados. Por ejemplo, si esta herramienta detecta que ha detectado el puerto 7777 como nuevo en un servidor de DMZ, es para preocuparse, ¿verdad?

2. Política por defecto DROP

Esta recomendación no se debería implantar únicamente para dificultar el escaneo al atacante, sino porque protege la red de forma más precisa. Básicamente, en una política por defecto ACCEPT DROP (gracias a ignaciopollo por darse cuenta de la errata) de un firewall, permites pasar tráfico hacia cualquier puerto excepto los definidos en una lista negra. En la política por defecto DROP, se filtra todo el tráfico excepto el definido por una lista blanca.

Explicaré esta consecuencia con un ejemplo: nmap lanza una sonda hacia un puerto concreto de una máquina al que se está auditando. Si hay un firewall en medio con política ACCEPT, dejará pasar esa sonda salvo que se haya configurado que ese puerto debe estar filtrado. Por tanto, el firewall dejará pasar todas las sondas que envíe nmap durante el escaneo, excepto las pocas sondas que se haya filtrado. Ocurre entonces que cuando llega un intento de conexión a un puerto cerrado de un equipo, éste responde de forma activa que el puerto está cerrado. Nmap recibe este dato y comprende que debe continuar su escaneo con el siguiente puerto.

Teniendo un firewall con política DROP, todas las sondas que envíe nmap quedarán filtradas, exceptuando las que estén definidas en la lista blanca. Por tanto, cada vez que se envíe una sonda hacia un puerto no alcanzable, el paquete se descartará. Entonces nmap esperará un tiempo hasta dar por perdida la sonda y la reenviará otra vez, hasta un número máximo de intentos para darse por vencido y pasar al siguiente puerto.

Haciendo números, el escaneo del primer ejemplo tardará únicamente el tiempo que se tarde en enviar las sondas hacia el objetivo, y recoger sus respuestas, obviando las retransmisiones por paquetes perdidos. En el segundo ejemplo, nmap se esperará un tiempo en recibir la respuesta hasta dar por perdido el paquete, multiplicado por el número de reintentos, y a su vez multiplicado por el número de puertos filtrados. En total, es una cantidad de tiempo considerable, desperdiciado en esperas y más esperas. Un escaneo con timings agresivos y bien optimizados, hacia los 64K puertos, puede variar de un par de minutos a cerca de una hora, dependiendo la configuración de los cortafuegos que hayan por medio.

3. Esconde servicios

Nmap tiene una lista de los puertos más usuales. Un escaneo por defecto, sin especificar qué rango de puertos se quiere auditar, tira de esa lista, escoge los 1000 puertos más utilizados para intentar encontrar alguno abierto. Esta lista usualmente está en /usr/share/nmap/nmap-services por si queréis consultarla. Es interesante en algunos casos cambiar el puerto a la escucha de un servicio por un puerto “oscuro” que no sea muy usual. A pesar del típico dicho de “seguridad por oscuridad” no es una buena opción, esta práctica puede ser útil, librándote de un escaneo rápido, y además, de bastante malware que busca servicios típicos para lanzarles ataques por fuerza bruta.

4. Confundir la detección de SSOO

Este “tweak” lo vi hace poco y me resultó curioso. Nmap tiene un fichero de 2MB con huellas de una gran cantidad de dispositivos. Cuando activamos la opción de OS fingerprinting, nmap hace más de 30 pruebas, determinando con bastante acierto el dispositivo y sistema operativo, en función de los resultados obtenidos. Una de esas pruebas es determinar el TTL por defecto. Dependendiendo del sistema operativo, el valor varía bastante. En el caso de Linux, es 64. No obstante, es un parámetro bastante sencillo de modificar. Veamos un ejemplo:

~# nmap -O 192.168.1.100
[...]
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:kernel:2.6
OS details: Linux 2.6.17  2.6.36

Observamos como en este ejemplo acierta bastante con el sistema operativo de la máquina auditada. Modificando el valor del TTL por defecto:

~# echo 83 > /proc/sys/net/ipv4/ip_default_ttl

por un valor inusual, obtendríamos ahora este resultado:

No exact OS matches for host (If you know what OS is running on it, see
http://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=5.61TEST2%E=4%D=4/18%OT=22%CT=1%CU=42601%PV=Y%DS=1%DC=D%G=Y%M=080
OS:027%TM=4F8EAFE6%P=x86_64¬unknown¬linux¬gnu)SEQ(SP=C8%GCD=1%ISR=C9%TI=Z%C
OS:I=Z%II=I%TS=8)OPS(O1=M5B4ST11NW5%O2=M5B4ST11NW5%O3=M5B4NNT11NW5%O4=M5B4S
OS:T11NW5%O5=M5B4ST11NW5%O6=M5B4ST11)WIN(W1=16A0%W2=16A0%W3=16A0%W4=16A0%W5
OS:=16A0%W6=16A0)ECN(R=Y%DF=Y%T=54%W=16D0%O=M5B4NNSNW5%CC=Y%Q=)T1(R=Y%DF=Y%
OS:T=54%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=54%W=16A0%S=O%A=S+%F=AS%
OS:O=M5B4ST11NW5%RD=0%Q=)T4(R=Y%DF=Y%T=54%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y
OS:%DF=Y%T=54%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=54%W=0%S=A%A=Z%F=R
OS:%O=%RD=0%Q=)T7(R=Y%DF=Y%T=54%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=
OS:54%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=54%CD=S
OS:)

Nos indica que no ha podido encontrar equivalencia con la huella obtenida. A pesar de que si que se puede leer “linux” entre los valores recogidos, no es capaz de afinar tanto como con el ejemplo anterior.

No obstante, en la práctica esto no suele ser tan bonito. Además de estos parámetros, nmap utiliza otros indicios para averiguar el tipo de sistema, como los banners de servicios. SSHd suele ser bastante chivato y por desgracia no hay ninguna opción para cambiar o silenciar este banner:

# nmap -sV -p22 192.168.1.100

PORT   	STATE 	SERVICE 	VERSION
22/tcp 	open  	ssh 		OpenSSH 5.9p1 Debian 5 (protocol 2.0)

Otro indicio es encontrar una aplicación que es específica de un sistema operativo concreto. Por ejemplo, un servidor web IIS, con bastante probabilidad estará ejecutándose en una máquina Windows, salvo que sea una honey, claro ;)

5. Otras “recomendaciones no recomendables”

Hay que tener mucho cuidado con la protección activa ante escaneos. En el caso de disponer de un IPS, debemos estar muy seguros de que la parametrización está bien afinada y que lo que se está detectando no hay falsos positivos. En determinados escenarios, es muy difícil hacer esto posible. Más peligroso todavía es añadir las IPs atacantes a cuarentena, o filtrado automático al firewall. Si un atacante detecta este comportamiento, podría lanzar un nmap con IPs spoofeadas, pudiendo forzar al sistema a filtrar IPs arbitrarias.

Otra medida más discutible es si añadir reglas al IDS para detectar escaneos. El hecho de que nuestra red está siendo escaneada probablemente no sea muy relevante como para preocuparse. Si nuestra red es grande, y el sistema de detección de intrusos está integrado con un SIEM, podrían llegar un gran número de alertas a lo largo del día, generando ruido innecesario. No obstante, si contamos con un sistema de correlación de alertas, que utilice este dato para contrastarlo con otros eventos, si que puede ser realmente útil recopilar esta información. Por ejemplo, un nmap desde una IP, por sí solo no es muy relevante, pero si hemos registrado un acceso por SSH un tiempo después de un escaneo desde esa misma IP, como hechos aislados no parece relevante, pero si se correla esta información, podríamos estar ante un potencial acceso no autorizado al sistema.

Uso eficiente de Metasploit: resource scripts

Cuando empecé a utilizar Metasploit —hace ya unos cuantos años— era bastante caótico para mi auditar una red en busca de vulnerabilidades o información relevante. No seguía una metodología determinada para llevar a cabo las fases de discovering, reconnaissance, exploitation, etc., si no que me dejaba llevar un poco por la intuición. A la larga, esto significa pérdida de tiempo y muchas veces grandes dolores de cabeza por haber obviado algún paso, olvidado algún servicio, ignorado cierta información, etc., con la que podría haber encontrado alguna vulnerabilidad mucho antes.

Metasploit es una maravilla para hacer auditorias, pero también una locura (debido al elevado número de módulos) si no sigues unas pautas en cierto orden y dedicas gran tiempo a la fase de information gathering.

La idea de esta entrada es mostrar cómo es posible automatizar algunas de estas tareas ahorrándonos mucho tiempo y garantizando seguir siempre una misma metodología sin olvidar ningún paso.

[Read more…]

Snort: la URI en la alerta ante una respuesta

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.

Es decir, podremos ver la petición, por poner un ejemplo, que ha originado un error 500 en un servidor Tomcat. Con un ejemplo se verá más claro:

Gracias al campo Full URI podemos ver cómo la respuesta 500 del servidor se debió a una petición un tanto ‘extraña’. Si vemos la URI, se trata de una conocida webshell que han subido al servidor a la que se le pueden enviar comandos a través de la variable comment. En este caso, pretendían descargar el fichero 9.txt desde un servidor a través del comando wget. Afortunadamente, al no poder ejecutar el comando, el servidor devuelve un error 500, lo que ha hecho saltar la alerta.

Gracias a poder ver la URI que ha provocado el error se ha podido detectar este incidente que de otra forma no habría sido posible, ya que sólo se trataría de un error 500 que podríamos achacar a un error puntual del servidor.

Esta es sólo una muestra de la información que podemos sacar de ese campo en determinadas situaciones, lo que facilita la gestión de incidentes de seguridad, al menos en su fase de identificación.

Actualización 16/07/2012.

A petición de un lector, adjuntamos un pequeño parche que realizamos para mostrar las cabeceras extra en la vista detallada de BASE, como podéis ver en la imagen que acompaña este post. El parche se aplica en directorio de base con la siguiente orden (es necesario quitarle la extensión .txt antes):

patch -p1 -i base_1.4.5.1.patch

El parche únicamente permite visualizar las cabeceras extra en la vista detallada de una alerta. No se puede buscar por estas cabeceras, ni se visualiza nada en los listados de alertas. El parche se entrega tal cual está, no nos hacemos responsables del impacto que pueda suponer su uso en vuestros sistemas. A pesar de ello, nos gustaría que comentarais vuestras impresiones sobre el mismo, si os decidís a probarlo.

La búsqueda de empleo en las redes sociales

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.

En España el 48% de la población utiliza Internet para buscar empleo, según la reciente encuesta realizada por la consultora Ipsos siendo la referida tasa superior a la de otros países, como Italia (36%), Alemania (30%) o Francia( 25%). Para más datos, según el último informe publicado por el Instituto Nacional de Estadística (INE) en fecha 5 de octubre de 2011, el índice de personas en situación de desempleo que usaron Internet en sus hogares asciende al 86,6 % y aunque desconocemos los usos de este porcentaje, qué duda cabe que Internet es una herramienta útil para la búsqueda de empleo.

[Read more…]

Sistemas Inmunes Basados en Agentes Artificiales

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

[Read more…]

Cisco Modular Policy Framework (I)

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

[Read more…]

Seg2

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.

Tras la charla de presentación entra en juego MAPFRE hablando del análisis y gestión integral de riesgos, con una charla dividida en tres partes diferenciadas. En la primera, teórica y en la que se llega a echar en falta algo práctico (algo que, dicho sea de paso, se corrige perfectamente más tarde), se habla, entre otras cosas, del mapa de riesgos globales del World Economic Forum en el que, en 2012, aparece ya el riesgo asociado a la ciberseguridad, además de las interrelaciones entre los diferentes tipos de riesgos; a continuación José María Cortés, Subdirector de Análisis de Riesgos de la DISMA muestra sólo dos transparencias, de las más claras y directas que he visto en mi vida, en las que sin darle vueltas al asunto nos dispara los problemas reales del análisis de riesgos tradicional; ahí van:

  • Caos conceptual. Conceptos que no están muy bien definidos (riesgo tecnológico, vulnerabilidad…).
  • Modelos de análisis poco ajustados a la práctica y a la realidad.
  • Métodos muy específicos o demasiado generalistas que no descienden al detalle.
  • Problemas con los pretendidos análisis matemáticos.
  • Expresión tradicional del riesgo como fórmula matemática (esperanza matemática de que suceda un hecho indeseable).
  • Cuantificación de la probabilidad y del impacto.
  • Identificación y valoración de activos.
  • BBDD estadísticas sobre incidentes.
  • Correlaciones entre riesgos.
  • Gran volumen de información.
  • Ausencia de cultura de gestión integral de riesgos.

No puedo estar más de acuerdo; la problemática asociada al análisis de riesgos y sus supermetodologías ya la comentamos hace tiempo en este mismo blog y vemos que no somos los únicos que la sufren (¿cómo era aquello de “Mal de muchos…“? ;). Finalmente, para acabar la presentación y para que no sea todo poner problemas encima de la mesa, MAPFRE nos cuenta cómo tratan de solventar estos problemas comentados previamente.

Después de MAPFRE José García (Vodafone España) nos cuenta la evolución del Departamento de Seguridad de la compañía con un ejemplo muy gráfico sobre evolución de TI vs. evolución de seguridad. Destacar, cambios de nomenclatura aparte, que en 2012 aparece la figura del CTSO para “colgarse de la chepa” de TI y poder gestionar en primera persona los riesgos asociados a la tecnología.

A continuación llega la charla de EULEN hablando de convergencia; Ricardo Cañizares nos cuenta que en 2008 empezaron con el tema (vaya, esto me suena ;) y a partir de ahí diseñaron servicios que contemplaban la convergencia, ya que siempre la han considerado el futuro y explicando a continuación, desde un punto de vista comercial, los servicios que en este sentido ofrecen.

Tras el café, Miguel Rego habla de convergencia de nuevo desde un punto de vista muy práctico, citando por ejemplo los dispositivos de seguridad física ya conectados por IP, como cámaras, con los riesgos que esto implica: nuevos vectores de ataque, nuevos riesgos ya no sobre la seguridad de la información en exclusiva, sino también sobre la seguridad física, etc. Tras la introducción de Miguel, se muestra una demostración práctica de ataque a un sistema de videograbación, con búsqueda en shodan y tokens predecibles incluidos en la que se hace un acceso “en vivo” a una cámara de seguridad de un determinado modelo. Llama la atención que esta parte de la demostración, el control de una cámara de seguridad vía IP, a buena parte del público le parece algo muy novedoso y aparentemente no eran conscientes de que cosas así se pueden hacer. No comments.

La siguiente charla es de Manuel Rodríguez, Jefe de la Unidad de Gestión de Riesgos del Parlamento Europeo, hablando de seguridad en este Parlamento, primero poniendo cara (seguridad física) a cada una de las tres sedes que tienen que proteger y luego hablando de sus preocupaciones en materia de seguridad, que incluyen los ataques IT o el espionaje, así como de su organización interna y sus objetivos de seguridad. Un buen orador que nos presenta una ponencia curiosa e interesante, no puedo decir más.

A continuación se pasa a hablar sobre internacionalización de la seguridad en un formato de mesa redonda con MAPFRE, Acciona, Ferrovial… donde una de las palabras más repetida es “inteligencia”, tratando cuatro asuntos principales:

  • Problemas en el extranjero, en delegaciones, filiales, operaciones…
  • Proveedores que estén capacitados para prestar seguridad global (física, electrónica, tecnológica, normativa y operativa). ¿Son españoles?
  • Papel de la inteligencia en la presencia exterior.
  • Marco internacional de capacitación para seguridad.

Como siempre, Guillermo Llorente hablando claro en la mesa y metiendo el dedo en la llaga: no hay que saber de todo, sino tener el teléfono del que sabe, y de proveedores globales nada, porque no existen.

Tras la comida, una nueva mesa redonda, esta vez sobre protección de infraestructuras críticas desde un punto de vista “convergente”, en la que participan FFCCSE, operadores de tales infraestructuras y proveedores de servicios, con varias preguntas en la agenda:

  • Situación estimada de seguridad en el ciberespacio.
  • Condición de España tanto en ataques como en defensa.
  • Qué falta en España para poder abordar la seguridad desde un punto de vista global.
  • Qué organismo debe liderar la futura Estrategia Española de Ciberseguridad.
  • Cómo conjugar todos los actores implicados en la ciberdefensa española.

Me interesa mucho más la opinión de organismos públicos, como el CNPIC, que la de entes privados o semipúblicos (éstos velaran lógicamente por sus intereses particulares, mientras que los primeros confío en que velen por el interés general). Óscar de la Cruz (GDT-GC) define muy bien un problema: la legislación del siglo pasado (o del anterior) que afecta a la seguridad de hoy en día; no podemos combatir un ciberataque con un marco legal que habla de serenos, por poner un ejemplo. De esta mesa, comentarios interesantes aparte, me llama mucho la atención que nadie responde a las dos últimas cuestiones de la agenda, salvo a la de liderar la estrategia nacional de ciberseguridad y muy de pasada (y a raíz de una pregunta de Mercedes). ¿Casualidad?

Finalmente la jornada acaba con una última mesa redonda en la que se debate la seguridad global en la futura LSP, con las siguientes cuestiones sobre la mesa:

  • Qué perfil debe tener el responsable de seguridad de los activos de una organización.
  • Debería incorporarse una visión global de la seguridad en una nueva LSP?
  • Formación y capacitación de un directivo de seguridad (vaya, esta me suena ;)
  • Qué están haciendo las asociaciones profesionales al respecto de la seguridad integral.

Dos bloques de participantes (los de seguridad “lógica” y los de seguridad “física”) no enfrentados entre sí, pero con opiniones para todos los gustos. En definitiva, una jornada muy interesante en la que si algo queda claro es que en convergencia aún queda mucho trabajo por hacer y en muchos sentidos. Felicitar, como no podía ser de otra forma, a los compañeros de Borrmart por el éxito de la convocatoria, que si siempre es difícil, lo es más aún en estos tiempos.

Como siempre, pasen un buen fin de semana.

Botnets: Detection, Measurement, Disinfection & Defence

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:

[Read more…]

Vulnerabilidad en PHP-CGI

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.

Imagen 1 de http://blog.spiderlabs.com/

[Read more…]