¿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.

Nueva edición del tutorial «Uniéndose a SIR2» durante las JT2015

Martes, 10 de noviembre de 2015 Comentarios desactivados

Tanto para aquellos que no pudieron asistir al tutorial «Uniéndose a SIR2» organizado la pasada primavera, como para aquellos que quieran avanzar en la instalación del que será su nuevo IdP SAML2int en SIR2, vamos a realizar una nueva edición de dicha sesión de formación, en la que contaremos de nuevo con la ayuda de compañeros de las universidades de Córdoba, Murcia, Málaga y Politécnica de Valencia.

La formación se desarrollará el lunes 23 de noviembre por la mañana, en la sala multiusos del Auditorio de Tenerife Adán Martín. Al día siguiente, 24 de noviembre, tendremos por la mañana la presentación sobre actualidad del Servicio de Identidad de RedIRIS, dentro de la sesión «Servicios de RedIRIS».

El contenido del tutorial no variará, si bien hemos corregido determinadas partes del mismo, y para la parte práctica queremos utilizar ya la infraestructura de SIR2, inclusive los SPs de pruebas de la misma. Repetimos de nuevo la lista de módulos del tutorial:

  1. Introducción a la federación de identidades
  2. El proveedor de identidad
  3. Proveedores de Servicio
  4. Atributos
  5. “Burocracia” para unirse a SIR2
  6. Interfederación: eduGAIN

Para la asistencia al tutorial se recomienda llevar:

  • Ordenador portátil
  • Navegador Firefox, con extensión SAMLTracer instalada
  • Cliente SSH

En esta ocasión disponemos de una sala grande, con sillas de tablero. Aunque se distribuirán enchufes por la sala, recomendamos a los asistentes que lleven su portátil con las baterías cargadas.

Si estás interesado en asistir al curso, la Persona de Enlace con RedIRIS (PER) que cursa tu inscripción a los Grupos de Trabajo y/o Jornadas Técnicas, debe marcar en el formulario de inscripción, que asistirás el lunes, 23 de noviembre.
Categories: SIR 2 Tags:

Fases de migración a SIR2

Lunes, 5 de octubre de 2015 Comentarios desactivados

SP de pruebas SAML2 en SIR2Dos preguntas recurrentes de cara a la migración a SIR2 de los Proveedores de Identidad actuales en la federación SIR (por diferenciar a la actual federación de la nueva, la llamaremos SIR1), son cuándo va a comenzar esta, y cuándo tendrá cada organización que actualizar su proveedor de identidad. En este breve artículo tratamos de describir el estado actual y explicar cómo será la migración.

Primero de todo quisiera aclarar en qué momento nos encontramos de la migración. Actualmente tenemos preparado un entorno que denominamos de validación, en el cual se encuentran probando, o están a punto de probar su conexión distintos grupos de organizaciones. La idea durante esta «pre-fase» o fase 0, es comprobar que la conexión de IdPs actuales PAPI al nuevo hub de SIR2 se realizará correctamente. Para esto hemos elegido diversos sabores del software instalado para realizar conexiones a los que serán los nuevos proveedores de servicio de pruebas en SIR2. También queremos comprobar en esta fase que además de estos proveedores de identidad PAPI, pueden convivir en el mismo hub y acceder de manera equivalente los proveedores de identidad con capacidad SAML2int existentes, que usan distintas implementaciones de SAML. Entre estos está el software de IdP de referencia, SimpleSAMLphp.

Dar fechas exactas del comienzo de la migración no es algo trivial, pues las pruebas a realizar son exhaustivas, y pudieran provocar retrasos adicionales, pero nuestra intención sería comenzar con la fase 1 de migración en las próximas semanas, o meses a lo sumo.

Respecto a la segunda pregunta que introducíamos al comienzo, hemos dividido el proceso de migración en 5 fases, donde las instituciones tendrán que implicarse en la migración de sus IdPs en las fases 1 a 3, especialmente durante la fase 3 que es la que implica actualizar el software de su IdP:
  • fase 1. Se conectarán todos los IdPs PAPI actuales de SIR1 al nuevo hub de SIR2 en su entorno de pruebas, sin perder en ningún momento la conexión existente a SIR1. El administrador de cada organización realizará pruebas de conexión al SP de pruebas PAPI en SIR2. Estas pruebas tienen como objetivo validar que los atributos que envía a dicho SP se corresponden con los que se envían actualmente en SIR1.
  • fase 2. Una vez realizadas las pruebas anteriores, el IdP PAPI en SIR1 se conecta con la entrada WAYFless del IdP PAPI en el entorno de producción de SIR2. De este modo, SIR2 comienza a funcionar, si bien inicialmente con los mismos IdPs PAPI que en SIR1, y utilizando el WAYF y pasarelas de SIR1, hacia SPs conectados también a SIR1.
  • fase 3. Seguidamente, las instituciones instalarán el software de IdP SAML2int, que sustituirá al componente PAPI que tenían desplegado hasta el momento. Todas las pruebas pertinentes se realizarán en el entorno de pruebas de SIR2, comprobando que el comportamiento del que será el nuevo IdP es equivalente al de su IdP PAPI.
  • fase 4. Los SPs conectados a SIR1 se irán migrando paulatinamente a SIR2. En el caso de todos los accesos de estos SPs, se utilizará al completo la federación SIR2. Esta fase puede solaparse sin problemas con la tercera en el tiempo.
  • fase 5. Por último, una vez se hayan desconectado todos los SPs de SIR1, se procederá al “apagado” de la antigua federación.

Aclarar que cada institución pasará por estas fases de manera independiente, por lo que en cada momento habrá instituciones en distintas fases. Indicar también que la fase 4, que implica la migración de SPs de SIR1 a SIR2, puede dar comienzo en paralelo a la fase 3.

Todas estas fases quedarán recogidas en una guía de migración de IdPs que estamos preparando, en la que se recogerá también una estimación del tiempo de duración de cada fase. Para la fase 3, estamos preparando también una guía de instalación del IdP de referencia, que anunciaremos en las próximas semanas.

En un próximo artículo, haré una comparación de los atributos en uso en SIR1, y los que se recomiendan en la nueva federación SIR2, incidiendo sobre cómo han de calcularse, su significado, y el uso dentro de la federación de los mismos.

Categories: Información general Tags:

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