Recientemente me topé con esta publicación: El cifrado XML está roto, es necesario corregir el estándar W3C
Esperaba encontrar mucha información en línea al respecto, pero en realidad no hay tantos detalles. Ya que estoy usando WCF con muchos SOAP de seguridad a nivel de mensajes, pensé que hice la pregunta.
¿Es la publicación mencionada la cosa real, o es algo exagerado basado en el éxito obtenido en un entorno controlado? ¿El cifrado XML está realmente roto?
Al investigar un poco, he encontrado evidencia de actividad reciente sobre este tema: Explicación funcional de los cambios en XML Encryption 1.1 (W3C Working Group Note 11 de abril de 2013) . Hay muchos cambios en XML Encryption 1.1, entre otros:
y entre los más relevantes para su pregunta, cambios en las consideraciones de seguridad:
Se agregó información de consideraciones de seguridad sobre los ataques de texto cifrado seleccionados, incluidos los ataques contra datos cifrados y claves cifradas. Proporcione notas específicas sobre la vulnerabilidad de CBC Block Encryption y el ataque de Bleichenbacher.
El artículo que estaba leyendo trata sobre la explotación de una debilidad en el modo CBC para el encadenamiento de diferentes bloques de texto cifrado. Si bien parece ser la cosa real , se aplica a los esquemas de encriptación antes de XML Encryption 1.1 :
“Pudimos descifrar datos enviando textos cifrados modificados a la servidor, mediante la recopilación de información de los mensajes de error recibidos ". El ataque fue probado contra una aplicación popular de código abierto de Cifrado XML, y contra las implementaciones de empresas que respondieron a la divulgación responsable - en todos los casos el resultado fue lo mismo: el ataque funciona, el cifrado XML no es seguro.
Aunque no veo esto como una exageración, y tampoco me sorprende (vea, por ejemplo, esto responda a la pregunta ¿Qué tan seguro es un cifrado si sabemos algo acerca de los datos originales? y Wiki sobre ataque de texto cifrado con adaptación adaptada ), debe mencionarse nuevamente que se aplica al modo de cifrado CBC disponible en XML Encryption 1.0 que fue manejado por un grupo de trabajo diferente de W3C ( XML Encryption WG activo por última vez en 2008).
Este trabajo ya se ha trasladado a Grupo de trabajo sobre seguridad XML cuyo bebé es XML Encryption 1.1 como respuesta directa A tales ataques como se describe en el artículo. De hecho, el XML Security Working Group menciona directamente estos ataques en XML Encryption 1.0 en la documentación de XML Encryption 1.1. / p>
Anexo : mientras leía algunos artículos de criptografía no relacionados, me topé con Matthew Green La publicación del blog en Ataque de la semana: cifrado XML se remonta a octubre de 2011. Matthew Green es criptógrafo y profesor de investigación en la Universidad Johns Hopkins, y escribe los textos más fabulosos sobre criptografía y temas relacionados. Su explicación de lo que trata este ataque a XML Encryption es la mejor que he leído hasta ahora, y por supuesto, una lectura recomendada para cualquier persona interesada para aprender más sobre ellos. Aquí hay un breve extracto:
Deje de usar el modo CBC no autenticado. Deja de usar cualquier cifrado estándar diseñado antes de 2003 que no ha sido analizado cuidadosamente y recientemente actualizado. Deje de usar cualquier cifrado no autenticado. Envuelve tus conexiones SOAP con TLS (¡una versión reciente!) Si puedes.
Creo que será útil si agrego un comentario a esta respuesta, incluido el estado actual.
Ataques de texto cifrado elegidos adaptativamente:
Los ataques aplicados en el cifrado XML son ataques adaptativos de texto cifrado. En el caso de un ataque adaptativo con texto cifrado elegido, el atacante toma el texto cifrado original, lo modifica y lo envía al servidor. Luego evalúa la respuesta del servidor, lo que le permite decidir si el texto simple subyacente era válido o no. Repite esto varias veces, lo que le permite descifrar todo el mensaje.
Estos ataques son, por ejemplo, aplicable a los esquemas CBC (modo de operación Cipher Block Chaining), que aún está estandarizado por XML Encryption o muchos otros estándares. CBC (AES-CBC o 3DES-CBC) permite modificar los textos en el texto cifrado, sin conocer la clave de cifrado. Más específicamente, el atacante puede voltear bits específicos en el texto simple (no voy a entrar en detalles, lea el documento o la publicación de blog de Matt Green que se menciona en la primera respuesta). Si se invierten ciertos bits en el texto sin formato, el atacante produce un mensaje, que no puede ser procesado por el analizador XML. Otros bits dan como resultado plaintexts válidos.
Requisitos previos de ataque: Hay dos requisitos previos para ejecutar el ataque. Primero, el atacante debe poder modificar los textos cifrados y forzar al servidor para que los procese. En segundo lugar, el atacante debe tener una información si el texto cifrado modificado descifrado era válido o no. Esto suele ser posible ya que el servidor responde con un mensaje de error diferente si el texto cifrado era válido y con un mensaje diferente si era inválido (también hay otras formas de distinguir los mensajes válidos o no válidos, por ejemplo, midiendo los tiempos de respuesta).
Bien, pero las firmas XML deberían garantizar la integridad ... Sí, tenemos el estándar de firma XML que permite asegurar la integridad de los mensajes XML. Esto mitiga teóricamente los ataques, ya que los textos cifrados se pueden firmar. Esto evita la modificación del texto cifrado (el primer requisito previo de ataque).
Sin embargo, en todos los marcos probados, fue posible aplicar este ataque incluso si se aplicaran firmas XML. En resumen, una firma XML típica protege solo una parte de un mensaje XML. Pudimos colocar los textos cifrados modificados en partes que no estaban firmadas. Incluso si no estaban firmados, los marcos los procesaron y los descifraron.
Esto no fue considerado por el estándar de cifrado XML y ahora se aborda en la versión más reciente, incluido un esquema de cifrado seguro AES-GCM: enlace
Marcos que analizamos: Analizamos algunos marcos y descubrimos que eran vulnerables a los ataques. Por ejemplo, Apache Axis2, JBossWS, Apache CXF o algunos marcos SAML. Los ataques funcionaron, incluso si se utilizaron las firmas XML.
Contramedidas: Como se mencionó en la primera respuesta, hay varias contramedidas enumeradas en la norma más reciente. Si diseña o usa Seguridad XML, su servidor debe verificar cuidadosamente si los textos cifrados fueron firmados. Si el mensaje contiene un texto cifrado sin firmar, el mensaje debe ser rechazado. Así es como se implementó ahora en Apache CXF. Otra posibilidad es usar AES-GCM ...
Para obtener más información, puede echar un vistazo a mi tesis, que resume todos los ataques (incluidos los ataques a RSA PKCS # 1 v1.5) y proporciona varias medidas de contrarrestación: enlace
Estado actual: Con las contramedidas presentadas, es posible implementar un sistema seguro contra ataques adaptativos de texto cifrado elegido. Hicimos varios pentests y vimos muchos sistemas, donde no pudimos aplicar estos ataques.
Creo que el cifrado XML (junto con la firma XML) es un gran estándar que soporta muchos escenarios de confidencialidad. Pero debe prestar atención a cómo configura su sistema (no estoy seguro de que los marcos estén seguros por defecto).
ACTUALIZAR
Lanzamos un complemento para nuestro marco WS-Attacker para probar las vulnerabilidades en los servicios web mediante el cifrado XML: enlace
Presentamos nuestro nuevo artículo: Cómo romper el cifrado XML - Automáticamente: enlace Allí, analizamos también el marco WCF.
Lea otras preguntas en las etiquetas encryption xml