Tuesday 29 July 2008

Nuevo patrocinador Platinum de la Fundación Apache...

apacheLeo con asombro que Microsoft, se ha convertido en uno de los patrocinadores Platinum de la Fundación Apache, uniendose a Google y Yahoo, que ya lo eran anteriormente.
Extraño paso de esta compañía, que hace poco lanzaba FUDs contra el software libre. La fundación Apache, mantiene muchos proyectos de software libre destacados por su excelente calidad, entre los que se encuentra, su software estrella, el servidor web Apache, competidor del Internet Information Server de MS, y que además, tiene más couta de mercado.

Total, que son 100.000 $ al año que pagan... y ellos pensarán, bah, una miseria y quedamos bien... y qué bien queda el logo en su página!

patrocinadores_apache

Además de este paso, Sam Ramji (Director de estrategia para plataformas de Microsoft) ha publicado en su blog que están contribuyendo con Adodb (una capa de acceso a datos usada por muchas aplicaciones libres, con licencia LGPL y BSD), para incoporar un driver nativo de MS SQL Server en PHP.

Que será lo próximo?

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)

Thursday 24 July 2008

Otro más: Debian OpenSSH Remote SELinux Privilege Elevation Exploit

Hola,

Ya que saqué el tema comentando el otro día los amores y desamores de Debian y OpenSSL [1] y [2], en este caso os traigo otro bug en el paquete OpenSSH en conjunto con SELinux (Security-Enhanced Linux, proyecto de la NSA de EEUU) en Debian (y según publican posiblemente en otros derivados como Ubuntu, o quizá también Fedora/RHEL). Podeis estar tranquilos si usais la última versión de OpenSSH porque no está afectada.

El problema consiste en que es posible escalar privilegios remotamente, debido a que se puede setear arbitrareamente los roles SELinux cuando OpenSSH está compilado con --with-selinux introduciendolo después de una "/". El parche (diff) que introdujo Debian fue este:

+ authctxt->role = role ? xstrdup(role) : NULL;

La sintaxis de ssh queda de esta manera:

ssh -lusername:[style]/<arbritrary SELinux role> host

Aquí teneis los detalles técnicos

Saludos

Tuesday 22 July 2008

Guía de bolsillo de OpenSSL

opensslHablando de OpenSSL... una nota rápida, para dejaros una guía de bolsillo de Heise Security.
A pocket guide to OpenSSL contiene información actualizada sobre la vulnerabilidad de OpenSSL en Debian, riesgos, herramientas y pasos a seguir para comprobar el impacto en un sistema. (Hace uso del script en perl comentado en la entrada anterior).

Más sobre el caso Debian/OpenSSL

debianLuciano Bello, desarrollador argentino de Debian y descubridor del fallo del PRNG en el paquete OpenSSL de Debian ha desarrollado un parche para wireshark (antiguo ethereal) gracias al que podemos descifrar las conexiones SSL creadas con versiones vulnerables del paquete.

También ha dejado disponible una versión en español.

Para quien no esté al tanto, el fallo en OpenSSL consistía en que el generador de números aleatorios era predecible, con lo que producía una vulnerabilidad criptografica muy grave. Las claves afectaban iban desde SSH, OpenVPN, DNSSEC, hasta las usadas en los certificados X.509 y conexiones SSL/TLS. Por suerte, las claves generadas con GnuPG o GnuTLS no se vieron afectadas.

Desde este enlace podeis descargar un programa para comprobar si vuestras claves OpenSSH/OpenVPN son lo sufientemente débiles como para tener que reemplazarlas.

Después de este caso de OpenSSL en Debian y el comentado anteriormente sobre implementaciones de DNS, queda patente que tanto en el campo de la seguridad informática como de la criptografía nunca puedes dormirte en los laureles, y siempre tienes que estar mejorando y auditando los sistemas para un correcto funcionamiento.

Y ahora, os dejo con una viñeta graciosa sobre el tema...

randomness

La cual me recuerda (exceptuando lo de debian...) a cierto concurso en el salón de actos de la EPS... :P


P.D: podeis leer a Luciano Bello también desde Planeta Debian en español

Thursday 10 July 2008

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.

Sunday 6 July 2008

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.

openbsd logoHoy 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.

Tuesday 1 July 2008

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

apple-logoLa 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