Security Art Work

No voy a hablar de la importancia de la I+D para el futuro de un país, ni de que los sectores que aportan más valor añadido y, por tanto, generan puestos de trabajo de mayor nivel son aquellos que requieren profesionales cualificados, formados en ambientes impregnados de ciencia (que no es otra cosa que curiosidad organizada con método), ni de que los sectores tradicionales que, por no ser sostenibles, han provocado que nuestra crisis sea peor que la de otros países de nuestro entorno, son, precisamente, los que absorben la mano de obra menos cualificada.

No hablaré tampoco de que, mientras nosotros estamos peleando por mantener puestos de trabajo en sectores de la segunda ola, hay países con empuje que nos van a adelantar por la derecha porque trabajan ya en la economía de la tercera ola.

No hablaré de que, cuando se dice que España es el noveno país en cuanto a aportación científica en el ranking mundial, medida en artículos científicos de alto nivel publicados, se están contando a todos los científicos que trabajan en universidades extranjeras (léase norteamericanas). Nosotros los formamos y ellos los aprovechan.

No diré todo esto, porque seguro que hoy, todos estos argumentos ya se han explicado en otros blogs. Y, ya que estamos en un entorno empresarial, diré por qué creo que los recortes en I+D son malos para las empresas españolas.

[Read more…]

La semana pasada, en la Conferencia Europea sobre Investigación en Seguridad que José Rosell les comentaba ayer, tuvo lugar una interesante sesión paralela con el título Citizens Security Needs vs Citizens Integrity, el conocido debate sobre el balance entre la seguridad y la pérdida de libertad. Dos de los ponentes defienden la necesidad de introducir consideraciones éticas (léase privacidad, respeto a la intimidad y a las libertades) en los proyectos de investigación, desde el principio, y no como una cuestión a posteriori.

En el turno de preguntas, una persona en la audiencia hace una observación que merece ser registrada: la disyuntiva entre ética y seguridad no se puede plantear como un balance, ya que aunque es indiscutible que todos queremos, como mínimo, algo de seguridad, ¿quién es capaz de decir que quiere menos del 100% de ética?

Sin embargo, en la práctica, sí que renunciamos a parte de nuestra libertad por algo más de seguridad (en realidad, muchas veces es más bien teatro de la seguridad) y si no, pensemos en lo que nos toca hacer en los aeropuerto; como dijo otro de los ponentes, cuando se encuentra con el cinturón y los zapatos en la mano, sujetándose los pantalones, le da la impresión de que, de alguna manera, los terroristas han ganado una batalla.

Para mí, el asunto se puede plantear en los siguientes términos: ¿Es la disyuntiva entre seguridad y libertades un juego de suma cero? En otras palabras, ¿un aumento de nuestra seguridad significa necesariamente un recorte de nuestras libertades? Yo creo que así nos lo quieren hacer creer muchas veces, pero también opino que eso es una falacia. Y con la que se nos viene encima, vamos a tener que prestar mucha atención a este tema.

“Por favor, quítese cualquier libertad civil que le quede y deposítela en la bandeja”

La semana pasada tuvo lugar en Estocolmo, la 4ª conferencia europea sobre investigación en seguridad, Security Research Conference (SRC’09).

El nivel de participación fue francamente alto, más de 500 inscripciones, lo que pone de manifiesto el interés generalizado que despiertan todos los temas relativos a la seguridad dentro y fuera de nuestras fronteras. La delegación española estaba compuesta por 49 personas de empresas, universidades y organismos públicos.
Aunque como es habitual en estos eventos el nivel de profundidad alcanzado en las exposiciones de los ponentes no puede ser mucho, sí nos permite hacernos una idea de los campos en los que se está investigando y desarrollando iniciativas a nivel europeo poniendo de manifiesto las áreas de interés de los distintos actores o stakeholders (ciudadanos, administración, empresas, etc…)

Siguiendo las recomendaciones que en su día realizó la ESRAB, “European Security Research Advisory Board“ en su informe “Meeting the Challenge: The European Security Research Agenda”, en esta cuarta edición de la conferencia tuvimos la oportunidad de asistir a la presentación de proyectos enmarcados en el ámbito de las cuatro principales áreas de trabajo o misiones que identificó el informe que les indicaba, y que son la base de la Call 3 de Seguridad del 7º Programa Marco:

• Seguridad de los ciudadanos
• Seguridad de las infraestructuras críticas y “utilities”
• Seguridad de las fronteras y vigilancia inteligente
• Gestión de crisis

Todos los avances presentados, como consecuencia de los proyectos de investigación y desarrollo apoyados por la Comisión, contribuyen, en definitiva, a mejorar y desarrollar capacidades que salvaguardan la seguridad a través del desarrollo de tecnologías y conocimiento en estas áreas.

Tuvimos también la oportunidad de conocer, de primera mano, las conclusiones del informe que va a publicar en las próximas semanas la entidad que recogió el testigo de ESRAB hace un par de años: la ESRIF, “European Security Research & Innovation Forum“, de las que ya existe un resumen ejecutivo y que podrán consultarse en su sitio web en breve. Asistimos además al anuncio de la creación de la ESRIA, “European Security Research and Innovation Agenda”, organizada en torno a cinco grandes clusters que abarcan desde el ciclo clásico de la seguridad (prevención, protección, detección, respuesta y recuperación) hasta la securización de identidades, accesos y movimientos de personas y mercancías, pasando por la seguridad de los activos críticos o la identificación de diferentes medios de ataque.

A las puertas del cierre de la Call 3 relativa a Seguridad del 7º Programa Marco, las conferencias fueron también punto de encuentro para el desarrollo de las propuestas. En definitiva, mucha información concentrada en poco tiempo, pero que nos permite analizar el pulso del mercado de la seguridad global en Europa, y conocer las líneas estratégicas hacia las que se van a dirigir los proyectos en los próximos años.

Vaya por delante que cualquier parecido de lo que les voy a contar con la realidad es pura coincidencia. Vamos, que se trata de una situación hipotética, que no se trata de un caso “tengo un amigo que”. Vamos con ello.

Imagine que usted descubre un día, por casualidad o mientras investigaba, un gran problema de seguridad en el software o hardware de uno de los grandes. Cuando digo grande, me refiero grande en ambos sentidos; uno de esos que hacen desplomarse las cotizaciones en bolsa del afectado: Microsoft, Sony, Dell, Google, Hewlett Packard, Oracle, Intel, etc. Vamos, un problema de los gordos para una compañía de las gordas.

Podemos asumir que el primer paso que muchos darían, excepto aquellos interesados por aprovechar el problema de seguridad in the wild —a los que vamos a dejar de lado en este hilo de suposiciones— sería ponerse en contacto con la compañía para comunicarle el hallazgo. Sin embargo, aunque es razonable esperar una respuesta positiva por parte de ésta, no podemos descartar que descubrir algo que puede suponerle una terrible migraña al fabricante ponga en acción a su equipo de abogados, y éste te llame a ti, amenazándote con una demanda y una posible indemnización millonaria por daños y perjuicios a la marca si el tema se hace público. Que tengan o no razón nos da lo mismo; meterse en algo así es un problema ganes o pierdas.

Así que, previniendo eso, la comunicación con el proveedor se hace de manera segura, y tomando todas las precauciones razonables para que éste no pueda averiguar la procedencia del mensaje, le hacemos llegar a la empresa en cuestión el problema. Pasan los días, pero nada pasa. No hay anuncios oficiales, no hay ningún tipo de parche de seguridad; como si nada hubiese pasado, un mes, dos meses, tres meses, y nada, absolutamente nada. Vacío.

Llegado este punto, usted ha hecho todo lo que es razonable, y dado que está totalmente en contra de que la seguridad pueda alcanzarse a través de la oscuridad (Security thru obscurity), se plantea hacer público su hallazgo. No hay nada peor que un problema de seguridad que el fabricante no ve la necesidad de parchear, porque no es público. Al final siempre habrá gente que lo conozca, dispuesta a aprovecharlo. Siempre.

Claro que aquí volvemos al problema del inicio: exponerse a una demanda millonaria, aparte de vayaustedasaber qué técnicas de desprestigio personal que pueden afectar seriamente a su vida profesional (entre otras cosas). La primera opción sería recurrir al anonimato; colgar la vulnerabilidad en cualquier foro, dando los detalles de la vulnerabilidad y la respuesta de la empresa, y poner todas las medidas posibles para ser virtualmente ilocalizable. Claro que eso tiene dos pegas: la primera, que renuncia usted a cualquier tipo de prestigio o reconocimiento por el descubrimiento, y la segunda, que siempre quedan huellas y por tanto la posibilidad de que den con usted.

Es obvio que se trata de una hipótesis, y que la empresa no tiene porqué comportarse de esa manera, pero eso es algo a lo que no vale la pena arriesgarse. A la vista de todo lo anterior, ¿renunciaría usted a la publicación de la vulnerabilidad, dejando que unas semanas, meses o años más tarde fuese otro quien se llevase los laureles… y los problemas? ¿Dejaría un problema de esta magnitud tapado?

¿Qué haría usted?

(La fotografía es del mayor agujero del mundo, una mina de diamantes en Mirna, en Siberia [Google maps])

—

(Hemos visto que la práctica totalidad de las cuentas de Hotmail suscritas al blog por e-mail no han sido verificadas. Si es su caso, por favor revise la carpeta de correo basura y verifique la suscripción. Pasen un buen fin de semana.)

Hace un tiempo solicitamos a nuestros lectores que respondieran a una cuestión aparentemente sencilla:

[Read more…]

En nuestro trabajo habitual, a menudo nos hemos encontrado con información muy útil sobre aplicaciones de backups, tales como problemas solucionados, scripts de uso, consejos de optimización, trucos, etc.

Para poder compartirla, nos gustaría saber cuales son los sistemas de backups más usados por nuestros lectores. Hemos incluido en la encuesta los más usados en entornos empresariales, aunque también nos pueden decir cual es el que usan ustedes. Si usan el xcopy de windows, o incluso no hacen copia….. ¡¡mejor pasen por aquí mas a menudo!!

(Mañana comentaremos el resultado de la anterior encuesta —la que tienen a la derecha— y pasaremos esta al lateral…)

No sé cómo se habrán sentido ustedes tras observar la polémica suscitada por la publicación de la famosa fotografía de las hijas del presidente del gobierno en el Metropolitan de Nueva York, y observar —cada vez me sorprende más lo desocupados y aburridos que pueden llegar a estar mis congéneres— esa especie de “variaciones sobre el mismo tema” en que se ha convertido la generación de fotografías de las menores cambiando el escenario, los rostros y los aderezos de los retratados.

No voy a entrar en la disquisición de dónde termina el círculo privado y empieza el ámbito público, tema más propio de uno de estos “programas” de “prensa” rosa/morbosa. Con independencia de lo que se piense (¿era o no era un viaje privado? ¿Un presidente de gobierno y su familia son o no son personajes públicos?), personalmente me parece preocupante la falta de respeto general observada al tratar el tema después de leer/oír los comentarios vertidos en los medios de comunicación, partiendo de la base de que se trata de menores de edad.

Sólo me remitiré a lo dicho por el artículo 4.3. de la Ley 1/1996 de Protección Jurídica del Menor:

Pero con independencia de esta ley, ¿demonizar a unas niñas en función de su manera de vestir? Pensaba que vivíamos en un país más avanzado, que no juzga la educación o la calidad humana de una persona por su manera de vestir, pero en fin, veo que sigo equivocado… En cualquier caso, aunque es un tema interesante no es esto de lo que quería hablarles.

Al hilo de un post de Javier Cao en su blog sobre la aparición de esta fotografía en Internet, quería proponerles el siguiente aspecto que, como no podía ser de otra manera, entronca con la gestión de la seguridad de la información.

Vayamos al origen de la situación. Al parecer —y corríjanme si estoy equivocado, porque no lo sé a ciencia cierta— la famosa foto fue publicada en la página web de la Casa Blanca y/o en la galería que el Departamento de Estado norteamericano tiene en flickr. Me da igual. En cualquiera de los dos casos, si vamos tirando del hilo, llegaremos al culpable de la publicación de la famosa foto, al responsable de todo esto… ¡Ya lo tenemos! ¡Que detengan al webmaster de la Casa Blanca! ¡O al “currito” que gestiona la galería de fotos del Departamento de Estado!… ¿O no?

Porque ¿quién decide si un usuario de una organización tiene o no tiene acceso a un determinado recurso? O yendo más lejos, ¿quién determina si una información es pública, restringida, confidencial, secreta? ¿El técnico que va a asignar los privilegios de acceso al directorio?

Porque un técnico no determina por su cuenta y riesgo si el documento de seguridad de una organización se publica en la zona pública de un servidor de ficheros o no, o a qué grupos de usuarios se les da permisos de acceso al directorio “Gerencia”… Lo lógico sería abordar un estudio de clasificación de la información, atendiendo a criterios organizativos y de negocio, ¿no? Evidentemente esta clasificación de la información provocará la creación de procedimientos que regulen su tratamiento, definiendo, entre otros aspectos, los permisos de acceso que los técnicos de sistemas tendrán que asignar a los recursos. Pero evidentemente éstos no serán los responsables de la asignación formal, de la definición de los permisos de acceso, serán responsables “solamente” de la asignación técnica. “Alguien” habrá definido previamente los mismos.

El caso concreto de la publicación de la famosa fotografía, además de poner encima de la mesa la necesidad de establecer normas o leyes supranacionales que protejan determinados derechos básicos de las personas, con independencia del país en el que nos encontremos (por ejemplo la protección de los datos personales en USA brilla por su ausencia…), en mi modesta opinión subraya el papel fundamental que deben jugar en la gestión de la seguridad de la información los responsables funcionales, responsables organizativos, encargados de definir el protocolo a seguir y de determinar/supervisar/otorgar las autorizaciones necesarias, ya sea para asignar los permisos de acceso a un estudiante en prácticas, para autorizar la restauración de la copia de seguridad de una determinada información, …. o para publicar una fotografía en Internet.

Tal como vimos en la entrada anterior, estamos intentando contrastar la información respecto a un fallo de seguridad en el FTP del IIS. Nos hemos dado cuenta de que tras ejecutar el exploit en todas sus versiones, no ha funcionado pese a ejecutarse sin fallos.

Revisando los logs del ftp, comprobando el tráfico con el tcpdump, y revisando el código del exploit seguíamos sin saber el motivo por el cual éste no funcionaba. La última opción que nos faltaba era usar el ollydbg con el inetinfo.exe, así como todo aquel programa que tenga relación con el FTP e intentar averiguar por qué el exploit fallaba. Pero lógicamente esto requería de un tiempo del que no disponíamos.

Analizando los motivos por el cual era posible que el exploit no funcionara decidimos realizar una maqueta lo más real posible. Instalamos un windows sobre una máquina física y conectamos a ésta otra máquina física que sería la máquina atacante. Pero el resultado fue el mismo: el exploit no funcionaba.

Analizando de nuevo el código, nos dimos cuenta que había direcciones estáticas, en concreto esta:

$retaddr = "\x9B\xB1\xF4\x77";

Esto nos hizo pensar que posiblemente esa dirección funcionara únicamente para la versión de Windows que tuviese el creador del exploit, la que resultó ser ni más ni menos que un windows 2000 pero en INGLÉS. Efectivamente, instalamos una versión en ingles sobre una máquina virtual para intentarlo de nuevo, y esta vez sí, el exploit funcionó concediendo una shell en el sistema atacado con permisos de usuario SYSTEM:

Esto confirmaba nuestras sospechas: el motivo del fallo en la ejecución del exploit era a causa de que éste toma las direcciones estáticas pensadas para funcionar sobre un windows en ingles. Lógicamente, si pensamos apilar la palabra “hello“, ésta requiere de 5 bytes mientras que la palabra “hola” requiere de 4 bytes, por lo que es muy posible que la dirección no fuera la misma en la versión en castellano.

Para terminar de confirmarlo pensamos en qué usuarios que no fueran de habla inglesa habrían buscado cual era la dirección correcta para ejecutar el exploit en sus sistemas. Me vinieron rápidamente a la cabeza los alemanes, así que me decidí a realizar búsquedas en foros alemanes que trataran el tema y por fin lo localice. Un usuario había publicado una variante del exploit para aquellas versiones de Windows en alemán, y tal como pensábamos, únicamente había que modificar la dirección del “retaddr”.

Por tanto, la vulnerabilidad existe, es un zero-day —ya que el creador del exploit no notificó al fabricante—, no hay todavía parche que la solucione y lo más importante, los sistemas en castellano si son vulnerables; lo único que el atacante debe hacer es modificar el retaddr del exploit por el que toca para entornos en castellano.

Entonces, ¿es una alerta grave? Si se cumplen los requisitos es gravísima, pero seamos sinceros, ¿qué administrador de sistemas concede permisos de escritura a usuarios anónimos o otros usuarios genéricos que no tengan contraseña? (alguno dirá que muchos, pero yo no llamaría a esos “administrador de sistemas”).

Donde reside realmente el problema de esta vulnerabilidad es en aquellos usuarios, que aunque protegidos con contraseñas, tengan permisos de escritura en el ftp. Si el atacante mediante diversos medios consigue obtener la contraseña del ftp del usuario podrá obtener una shell en el servidor. Teniendo en cuenta que las contraseñas del ftp se transmiten en texto plano, y que los usuarios por naturaleza no suelen tener excesivo cuidado en cuanto a la seguridad de sus máquinas personales, esta vulnerabilidad se convierte en un fallo de seguridad importante.

¿Solución? Pues hasta que salga el parche correspondiente para esta vulnerabilidad, la solución no es otra que revocar permisos de escritura a todos los usuarios, y emplear otros medios para subir los datos al ftp. De esta forma, todas las aplicaciones que dependan de la lectura de datos del ftp seguirán funcionando. Es algo “estricta”, pero si alguno de ustedes tiene una idea mejor, por favor que la indique en los comentarios.

Les voy a contar mi pequeña experiencia con un incidente ocurrido hace unas semanas atrás relacionado con una vulnerabilidad en el FTP del IIS. Ésta afecta tanto a la versión 5.0, 5.1, 6.0 y 7.0, provocando una denegación de servicios [Véase boletín de seguridad de Microsoft], pero es en la versión 5.0 donde la vulnerabilidad es más grave, debido a que hay suficiente espacio como para introducir código. Esto ha dado lugar a dos versiones adicionales del exploit: una permite crear usuarios en el sistemas y la otra la ejecución de una shell remota.

Era finales de agosto cuando comenzaron a llegar noticias de un zero-day en el ftp del IIS. Como todo lo que ocurre con vulnerabilidades de entornos Microsoft, siempre es difícil medir cuánto de toda la información que te llega es verdad. Lo primero es comprobar que realmente no es un bulo y efectivamente, no lo era; demasiadas fuentes apuntaban a este fallo de seguridad grave.

Nos pusimos manos a la obra, y obtuvimos los exploits, los nse del nmap para comprobar la vulnerabilidad, y preparamos una maqueta virtual de un entorno de pruebas que cumpliera todos los requisitos: un servidor FTP del IIS con un usuario con permisos de escritura. Pese a que algunas informaciones apuntaban a que no se requería permisos de escritura, todas las pruebas realizadas apuntan a que se requieren permisos de escritura en el FTP para poder ejecutar dicha vulnerabilidad.

Una vez preparada la maqueta, un Windows 2000 SP4 con el FTP IIS 5.0 habilitado con el usuario anónimo con permisos de escritura, ejecutamos el nse del nmap para comprobar si el sistema lo detectaba como vulnerable y de esta forma poder saber que máquinas eran vulnerables.

Al ejecutarlo nos llevamos el primer chasco: el nse que se ofrecía en las webs de seguridad nos decía que el servidor no era vulnerable. Mirando el código vimos que el nse comprobaba si las respuestas del servidor se correspondían con la firma típica del FTP IIS. Si esto era cierto, se intentaba conectar con usuario anónimo y escribir un directorio en el FTP, tras cuya escritura (y por tanto vulnerable el FTP) eliminaba el directorio creado y notificaba que el servidor es vulnerable. No obstante, en nuestro caso nos indicaba que no lo era:

# nmap -p 21 -sV 192.168.244.129 --script=IIS-FTP --script-trace

Starting Nmap 5.00 ( http://nmap.org ) at 2009-09-01 22:12 CEST
NSOCK (0.3340s) nsock_loop() started (timeout=50ms). 0 events pending
...
NSOCK (5.3400s) nsock_loop() started (timeout=50ms). 0 events pending
NSE: TCP 192.168.244.1:54540 > 192.168.244.129:21 | CLOSE
Interesting ports on 192.168.244.129:
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd 5.0

Mirando y analizando detenidamente paso por paso el código del nse, vemos que la negociación entre el nmap y el servidor FTP no coincide con los mensajes que está devolviendo el servidor FTP al iniciar la conexión. Esta es la razón de que indicase que no era vulnerable cuando realmente cumplía todos los requisitos. Además, hay que tener en cuenta que un servidor que respondiese con una firma modificada por el administrador no cumpliría con los requisitos del script y nos diría que no era vulnerable (de ahí la importancia de modificar la “imagen pública” de un servidor web). Por último, el script estaba preparado para entrar con cuenta anónima con permisos de escritura, pero lógicamente podría tratarse de un FTP con cuentas con permisos de escritura, pero que tuviera la cuenta anónima deshabilitada. Por todo ello el nse ofrecido no era una solución adecuada.

Analizando alternativas, llegamos a la conclusión de que con un simple bucle que usaras las marcas de la firma (-sV) cuya firma fuera “Microsoft ftpd” sería un servidor vulnerable a este fallo de seguridad. Un vez ejecutado y obtenido que servidores eran vulnerables podríamos notificar a los administradores que máquinas tenían el fallo de seguridad y estos comprobaran que usuarios tenían permisos de escritura para revocarlos temporalmente. El script empleado fue el siguiente:

#!/bin/sh 
[ $# -eq 1 ] || { echo "USAGE: $0 RED" && exit 1; } 
for i in `seq 1 254`; 
do 
        RES=`nmap -p 21 -sV $1.$i | grep -i 'Microsoft ftpd' 2> /dev/null` 
        [ "$RES" = "" ] || { echo "$1.$i" >> "vulnerable_FTP.txt"; } 
done

Su ejecución sobre la red virtual de pruebas fue la siguiente:

$ ./miscript.sh 192.168.244
$ cat vulnerable_FTP.txt
192.168.244.129

Una vez tenemos un mecanismo que nos permite detectar los servidores vulnerables, nos dedicamos a analizar cual era el funcionamiento del exploit. Tal como pensábamos, son necesarios permisos de escritura para ir sobrescribiendo la pila hasta tenerla justo donde el atacante quiere, y modificar entonces la dirección de vuelta. Como se ha comentado al principio del artículo existen tres versiones del exploit para el FTP IIS 5.0: una deniega el servicio, otra crea un usuario y la última obtiene una shell.

Así que nos ponemos manos a la obra y cogemos el exploit que permite crear una shell remota. Ejecutamos el exploit sobre nuestra máquina virtual, y en este caso parece que funciona ya que se ejecuta correctamente… pero no. Llega la segunda sorpresa del día: el exploit tampoco en este caso funciona, ni tampoco las otras versiones del exploit. Ni usuario, ni shell ni denegación de servicios… el exploit sencillamente no funciona. ¿Por qué?

Lo veremos mañana, en la siguiente entrada. Permanezcan atentos.