miércoles, 27 de agosto de 2008

HTTPS vulnerable por ataques "Surf jacking"

Original: http://blogs.techrepublic.com.com/networking/?p=634

Un buen consejo si se va a usar https es no usar el mismo navegador para consultar sitios web normales con http. En redes donde un posible atacante pueda interceptar la conexión es posible el ataque "surf jacking". Consiste en:

  • Navegador de la victima abre sesión https con sitio web (pongamos un banco para hacerlo interesante).
  • Navegador de la victima abre a continuación una página web normal (hace un GET con HTTP).
  • El atacante observa los paquetes anteriores y falsifica la respuesta de un sitio normal. A la segunda petición (un GET HTTP) el atacante crea un paquete de respuesta con código 302 que redirija a cualquier URL del banco y se lo manda a la víctima.
  • El navegador de la victima al recibir el redirect hace un nuevo GET con la URL que ha introducido el atacante. La clave es que en ese segundo GET se incluyen las cookies de sesión no cifradas de la conexión con el sitio HTTPS (es decir, el banco). Si las cookies tienen información privilegiada el ataque ha triunfado.

Las soluciones son dos:
  • Si desconfía de los desarrolladores web, sea paranóico y cuando abra una sesión https no reutilice el navegador web para otras cosas (nada de abrir pestañas o nuevas ventanas). Arranque un segundo navegador para navegar por otros sitios.
  • El desarrollador web debe usar cookies con flag secure activado (un navegador nunca las debería transmitir por un protocolo distinto a https).

El hecho de usar estas cookies es una buena práctica que los desarrolladores deberían usar; pero antes de mentar a la madre de los que no las usan se ha de saber que para sitios como google es muy difícil hacerlo. Al compartir la sesión https entre múltiples dominios (gmail, googleloquesea) es muy difícil usarlas y escalar a millones de usuarios. ¿Será esa la razón por la que existen quejas de gente que ha perdido sus cuentas en gmail?

martes, 26 de agosto de 2008

Como solucionar vulnerabilidad Kaminsky en Bind

Original: http://www.howtoforge.com/how-to-patch-bind-to-avoid-cache-poisoning-fedora-centos.

Una de las vulnerabilidades más graves de Internet de los últimos tiempos ha sido la que ha afectado a todos los servidores DNS. El problema consistía en que conociendo alguna consulta del servidor DNS se podían enviar respuestas falsificadas ya que tanto el número de puerto como el id de las siguientes consultas se hacían predecibles. Una vez que alguna de esas respuestas falsificadas entraba en el servidor se corrompía su cache con registros introducidos por el atacante.

La actualización consiste simplemente en realizar yum update bind. En el enlace recomiendan además activar dnssec. Ningún problema con Centos 5 y 4; aunque en este último caso la opción dnssec-enable on no es aplicable (bind 9.2).

Un detalle muy curioso es que si nuestro DNS está detrás de un NAT el parche no resuelve mucho debido a que las implementaciones habituales de NAT (por ejemplo, iptables) no sólo traducen las ips sino que también los puertos (alguno de los libres en la ip pública). Esto hace que vuelva a ser predecible. Habrá que pensar que los servidores de DNS también se merecen su ip pública.

Se pueden testear los servidores DNS en las siguientes direcciones:

Bug en perl (redhat)

Original: http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/

Un fallo en los paquetes perl Red Hat 5 (Centos, Fedora) hace que la llamada para crear objetos sea muy costosa. Un código como:

#!/usr/bin/perl
use overload q(<) => sub {};
my %h;
for (my $i=0; $i<50000; $i++) {
$h{$i} = bless [ ] => 'main';
print STDERR '.' if $i % 1000 == 0;
}


Ejecutado en una de nuestras máquinas Centos 4 tarda 0.2 s, en las nuevas Centos 5 pasa a 12-14 s.