Los piratas informáticos utilizaron una característica del protocolo OpenPGP que se conoce desde hace más de diez años.
Te contamos cuál es el punto y por qué no pueden cerrarlo.
/Unsplash/
Problemas de red
A mediados de junio, desconocido a una red de servidores de claves criptográficas , construido sobre el protocolo OpenPGP. Este es un estándar IETF (), que se utiliza para cifrar correos electrónicos y otros mensajes. La red SKS se creó hace treinta años para distribuir certificados públicos. Incluye herramientas como para cifrar datos y crear firmas digitales electrónicas.
Los piratas informáticos comprometieron los certificados de dos mantenedores del proyecto GnuPG, Robert Hansen y Daniel Gillmor. Cargar un certificado dañado desde el servidor hace que GnuPG falle: el sistema simplemente se congela. Hay motivos para creer que los atacantes no se detendrán ahí y que el número de certificados comprometidos no hará más que aumentar. Por el momento, se desconoce el alcance del problema.
La esencia del ataque.
Los piratas informáticos aprovecharon una vulnerabilidad en el protocolo OpenPGP. La comunidad la conoce desde hace décadas. Incluso en GitHub hazañas correspondientes. Pero hasta ahora nadie se ha responsabilizado de cerrar el “agujero” (hablaremos de las razones con más detalle más adelante).
Un par de selecciones de nuestro blog sobre Habré:
Según la especificación OpenPGP, cualquiera puede agregar firmas digitales a los certificados para verificar su propietario. Además, el número máximo de firmas no está regulado de ninguna manera. Y aquí surge un problema: la red SKS le permite colocar hasta 150 mil firmas en un certificado, pero GnuPG no admite ese número. Por lo tanto, al cargar el certificado, GnuPG (así como otras implementaciones de OpenPGP) se congela.
Uno de los usuarios — importar el certificado le llevó unos 10 minutos. El certificado tenía más de 54 mil firmas y su peso era de 17 MB:
$ gpg --homedir=$PWD --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
gpg: key F20691179038E5C6: 4 duplicate signatures removed
gpg: key F20691179038E5C6: 54614 signatures not checked due to missing keys
gpg: key F20691179038E5C6: 4 signatures reordered
gpg: key F20691179038E5C6: public key "Daniel Kahn Gillmor <[email protected]>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
$ ls -lh pubring.gpg
-rw-r--r-- 1 filippo staff 17M 2 Jul 16:30 pubring.gpg
Para empeorar las cosas, los servidores de claves OpenPGP no eliminan la información del certificado. Esto se hace para poder rastrear la cadena de todas las acciones con certificados y evitar su sustitución. Por tanto, es imposible eliminar los elementos comprometidos.
Básicamente, la red SKS es un gran "servidor de archivos" en el que cualquiera puede escribir datos. Para ilustrar el problema, el año pasado residente de GitHub , que almacena documentos en una red de servidores de claves criptográficas.
¿Por qué no se cerró la vulnerabilidad?
No había ninguna razón para cerrar la vulnerabilidad. Anteriormente, no se utilizaba para ataques de piratas informáticos. Aunque la comunidad de TI Los desarrolladores de SKS y OpenPGP deberían prestar atención al problema.
Para ser justos, cabe señalar que en junio todavía servidor de claves experimental . Proporciona protección contra este tipo de ataques. Sin embargo, su base de datos se completa desde cero y el servidor en sí no forma parte de SKS. Por lo tanto, pasará algún tiempo antes de que pueda utilizarse.
/Unsplash/
En cuanto al error en el sistema original, un complejo mecanismo de sincronización impide que se solucione. La red de servidores clave se escribió originalmente como prueba de concepto para la tesis doctoral de Yaron Minsky. Además, se eligió un lenguaje bastante específico, OCaml, para el trabajo. Por Mantenedor Robert Hansen, el código es difícil de entender, por lo que sólo se le hacen correcciones menores. Para modificar la arquitectura SKS, será necesario reescribirla desde cero.
En cualquier caso, GnuPG no cree que la red vaya a ser reparada alguna vez. En una publicación en GitHub, los desarrolladores incluso escribieron que no recomiendan trabajar con SKS Keyserver. En realidad, esta es una de las principales razones por las que iniciaron la transición al nuevo servicio llaves.openpgp.org. Sólo podemos observar el desarrollo ulterior de los acontecimientos.
Un par de materiales de nuestro blog corporativo:
Fuente: habr.com