Saltar al contenido
Cacharreros de la Web

20 años siendo vulnerables: Las firmas electrónicas en 22 visores de PDF

Vulnerabilidad en lectores pdf
20 años siendo vulnerables: Las firmas electrónicas en 22 visores de PDF
5 (100%) 1 vote

Seguramente en algún momento haz firmado un documento con tu firma digital. Y eso es genial. Pues al parecer estas son muy seguras y son casi imposibles de hackear. Sin embargo, investigadores de Alemania, exactamente de la Universidad Ruhr de Bochum hallaron una vulnerabilidad en lectores pdf.

Esta vulnerabilidad llevaba más de 20 años en 22 visores de PDF. La documentación de esta fallo nos muestra cómo se puede explotar. Pero tranquilo, el fallo para la gran mayoría de lectores ya fue corregido.

Para saber si tu lector de PDF fue afectado puede mirar la lista completa. Estos fueron los visores de PDF afectados: Foxit Reader, LibreOffice Draw, Nitro, Adobe Acrobat Reader DC, Perfect PDF Reader, Soda PDF.

Vulnerabilidad en lectores pdf: 3 tipos de ataques usados

Para hallar este tipo de vulnerabilidad en lectores PDF, los investigadores usaron 3 tipos de ataques.

Ataque 1: falsificación de firma universal (USF)

La idea principal de USF es deshabilitar la verificación proporcionando contenido no válido dentro del objeto de firma o eliminando las referencias al objeto de firma.

Por lo tanto, a pesar del hecho de que se proporciona el objeto de firma, la lógica de validación no puede aplicar las operaciones criptográficas correctas. Sin embargo, podría ser posible que un espectador muestre cierta información de firmas a pesar de que se omita la verificación.

Técnicamente, cada firma de PDF se define en un objeto de firma de PDF, por ejemplo, 5 0 obj . Sin entrar en demasiados detalles, este objeto contiene toda la información necesaria para validar la firma.

Lo más importante para los ataques de salida, el objeto de firma contiene una entrada / ByteRange , que define las compensaciones de los bytes utilizados para calcular el hash de la firma. La firma se almacena en una entrada / Contenido como un blob PKCS7 (en la mayoría de los casos).

El ataque de USF manipula esas entradas en el objeto de firma para confundir la lógica de validación de la firma, como se muestra en la siguiente imagen.

Si el ataque es exitoso, la aplicación de vista (o la lógica de validación en línea) mostrará un panel que la firma en el PDF contenido es válida y pertenece a una persona o entidad específica.

Ataque 2: Ataque de ahorro incremental (ISA)

Esta clase de ataque se basa en el ahorro incremental de la característica PDF (actualización incremental) . La idea del ataque es hacer un ahorro incremental en el documento redefiniendo la estructura del documento.

En un caso de uso legítimo, el ahorro incremental se utiliza, por ejemplo, para agregar anotaciones a un PDF. Las anotaciones se guardan incrementalmente después del contenido original del PDF como un nuevo cuerpo de PDF .

El ahorro incremental también se utiliza para firmar un PDF: el objeto de la firma se adjunta simplemente al contenido del archivo original.

La idea de ISA es la siguiente:

El atacante toma un PDF firmado. Agrega nuevo contenido (páginas, anotaciones, etc.) y los almacena al final del archivo mediante el ahorro incremental. Básicamente, esto no es un ataque, sino una característica de PDF.

Aparece una vulnerabilidad una vez que la lógica de validación de la firma no se da cuenta de que el contenido del archivo se ha actualizado, es decir, que se ha agregado contenido nuevo sin firmar al archivo.

Para lograr este comportamiento, identificamos múltiples variantes de los ataques como se muestra a continuación:

Tenga en cuenta que la Variante 1 en sí no es un vector de ataque real. Es la estructura de archivo deseada de un PDF firmado que se ha actualizado utilizando el ahorro incremental. Las variantes 2-4 no son compatibles con la especificación de PDF, por ejemplo, no definen una nueva referencia externa o un tráiler, pero las aplicaciones de PDF toleran los errores y muestran el contenido de todos modos.

En total, el ataque ISA tiene éxito si:

  • Se muestra el nuevo Contenido ( Actualizaciones del cuerpo ) y
  • La aplicación no nota que el documento ha sido modificado o actualizado.

Ataque 3: Envoltura de firma (SWA)

El SWA introduce una técnica novedosa para eludir la protección de firmas sin usar el ahorro incremental.

La idea principal es mover la segunda parte del Signed / ByteRange firmado al final del documento mientras se reutiliza el puntero de referencia externa dentro del trailer firmado a una referencia externa manipulada por el atacante .

Para evitar cualquier procesamiento de la segunda parte reubicada, se puede envolver opcionalmente utilizando un objeto de flujo o un diccionario. En la imagen de abajo, se muestran dos documentos.

En el lado izquierdo, se muestra un archivo PDF firmado correctamente. En el lado derecho, un archivo PDF manipulado se genera utilizando SWA.

El ataque funciona de la siguiente manera:

  1. (opcional): el atacante elimina los bytes rellenados en cero dentro del parámetro Contenido para aumentar el espacio disponible para inyectar objetos manipulados.
  2. El atacante define un nuevo / ByteRange [a, b, c , d] * manipulando el valor c , que ahora apunta a la segunda parte firmada colocada en una posición diferente dentro del documento.
  3. El atacante crea una nueva referencia externa que apunta a los nuevos objetos. Es esencial que el offset de bytes de la referencia externa recién insertada tenga el mismo desplazamiento de bytes que la referencia externa anterior. La posición no se puede cambiar ya que el remolque firmado hace referencia a este propósito. Para este propósito, el atacante puede agregar un bloque de relleno (por ejemplo, usar espacios en blanco) antes de la nueva referencia externa para llenar el espacio no utilizado.
  4. El atacante inyecta objetos maliciosos que no están protegidos por la firma. Hay diferentes puntos de inyección para estos objetos. % Si se ejecuta el Paso 1, podemos colocar el objeto malicioso antes de la referencia externa maliciosa. Se pueden colocar antes o después de la referencia externa maliciosa. Si el Paso 1 no se ejecuta, solo es posible colocarlos \ emph {después} de la referencia externa maliciosa.
  5. Algunos visores de PDF necesitan un tráiler después de la referencia externa manipulada ; de lo contrario, no pueden abrir el archivo PDF o detectar la manipulación y mostrar un mensaje de advertencia. Copiar el último tráiler es suficiente para evitar esta limitación.
  6. El atacante se mueve el contenido firmado definido por c y d en el offset de byte c *. Opcionalmente, el contenido movido se puede encapsular dentro de un objeto de flujo.

Si deseas conocer de manera más comprensible y sencilla toda esta información, te dejo con el siguiente sitio web. Ver más.

Entradas relacionadas

Déjanos tu Aportes