Archivo

Archivo del autor

Protegido: Seminario Práctico de gestión de crisis en Redes Académicas

Miércoles, 19 de Julio de 2017 Comentarios desactivados

Este contenido está protegido por contraseña. Para verlo introduce tu contraseña a continuación:

Categories: Información general Tags:

¿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: ,