CKEditor 4

https://checkmarx.com/blog/cve-2021-33829-stored-xss-vulnerability-discovered-in-ckeditor4-affects-widely-used-cms/

Potenciales rutas de ckeditor:

https://ip/bundles/utilities/ckeditorOffice/samples/uilanguages.html
https://ip/bundles/utilities/ckeditorOffice/samples/x.html
https://ip/Script/ckeditor/samples/old
https://ip/Script/ckeditor/samples/

RESUMEN DE IMPACTO

CKEditor 4 se usa comúnmente y puede afectar una variedad de entornos, como blogs, sistemas de administración de contenido y otros sitios web que aceptan contenido de texto enriquecido de los usuarios. La explotación exitosa de la vulnerabilidad conduce a la inyección de secuencias de comandos web arbitrarias. El impacto depende de dónde se use el complemento. Puede conducir a la apropiación de cuentas, robo de credenciales, exposición de datos confidenciales, etc. Cuando encontramos la vulnerabilidad en CKEditor 4, informamos a los mantenedores. Inicialmente, no consideraron nuestro hallazgo como un problema de seguridad, pero lanzaron una nueva versión con la corrección (4.16.1). Continuamos nuestra investigación y descubrimos que Drupal y django-ckeditor son vulnerables a XSS debido al problema que encontramos. Informamos a ambos y sacaron la versión 4.16.1 de CKEditor 4. Desde aquí, le pedimos a MITRE que emita un CVE porque nos esforzamos por informar a todos los dependientes de CKEditor 4 para que obtengan la última versión de CKEditor 4. Más tarde, CKEditor 4 se dio cuenta de la importancia de nuestro hallazgo y asumió la responsabilidad de emitir CVE-2021-33829.

PUNTAJE CVSS

CVSS: 3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N Puntaje: 6.1 (Medio)

DESCRIPCIÓN

En junio de 2020, se publicó CVE-2020-9281 debido a una secuencia de comandos entre sitios de CKEditor 4. La causa de este problema está en el procesador de datos HTML que no desinfecta una carga útil que contiene la palabra clave reservada ck_protected. Los desarrolladores de CKEditor 4 utilizan internamente la palabra clave reservada "cke_protected". Es un comentario HTML cuyo contenido está codificado. Para simplificar, usaremos el término 'comentario' protegido en este blog. La solución de los desarrolladores de CKEditor 4era asegurarse de que no haya comentarios protegidos inyectados externamente antes del análisis mediante la eliminación de instancias del comentario protegido. Dado que la palabra clave solo se elimina una vez, al anidar la palabra clave se obtiene la palabra clave (p. ej., palabra clavepalabra clave -> palabra clave). Esto permite a un atacante eludir este mecanismo de protección y explotar la vulnerabilidad XSS, que se suponía que estaba solucionada.

PRUEBA DE CONCEPTO ORIGINAL PARA CVE-2020-9281

  1. Haga clic en el botón de fuente en CKEditor 4

  2. Pegue la siguiente carga útil:

Xss<!--{cke_protected} --!><img src=1 onerror=alert(`XSS`)> -->Attack

  1. Haga clic en el botón fuente nuevamente para volver al editor normal.

CORRECCIÓN DE CVE-2020-9281 CON LA CARGA ÚTIL ANTERIOR

  1. Haga clic en el botón de fuente en CKEditor 4

  2. Pegue la siguiente carga útil:

Xss<!--{cke_protected} --!><img src=1 onerror=alert(`XSS`)>-->Attack

  1. Haga clic en el botón fuente nuevamente para volver al editor normal

PRUEBA DE CONCEPTO DE LA CORRECCIÓN DEFECTUOSA DE CVE-2020-9281

  1. Haga clic en el botón de fuente en CKEditor 4

  2. Pegue la siguiente carga útil:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

  1. Haga clic en el botón fuente nuevamente para volver al editor normal.

PRUEBA DE CONCEPTO DE LA CORRECCIÓN DEFECTUOSA DE CVE-2020-9281 EN DRUPAL

  1. Editar una página básica

  2. Haga clic en el botón de fuente en CKEditor4

  3. Pegue la siguiente carga útil:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

  1. guardar la página

  2. El siguiente usuario que edita la misma página está expuesto, como se muestra en la siguiente captura de pantalla:

PRUEBA DE CONCEPTO DE LA CORRECCIÓN DEFECTUOSA DE CVE-2020-9281 EN DJANGO-CKEDITOR

  1. Haga clic en el botón de fuente en CKEditor4

  2. Pegue la siguiente carga útil:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

  1. Haga clic en el botón fuente nuevamente para volver al editor normal o haga clic en el botón Guardar

ANÁLISIS DE VULNERABILIDAD

La función removeReserveKeywords del procesador de datos html tiene como objetivo garantizar que no haya palabras clave de comentario protegidas inyectadas externamente antes del análisis. Sin embargo, no elimina las instancias del comentario protegido de forma recursiva.

  1. removeReserveKeywords elimina instancias de la palabra clave de comentario protegida.

  2. El método parse divide en una matriz de elementos lo que queda de la carga útil mediante una expresión regular.

  3. La expresión regular identifica comentarios con la siguiente estructura

<!--Comment -->. Si la entrada contiene un comentario con un signo de exclamación adicional, como este, <!--comment --!>, la expresión regular no considera el sufijo – -!> como una etiqueta de cierre del comentario y trata el resto de la entrada como un comentario hasta que aparece un sufijo de cierre adecuado. así “- ->”.

  1. El tercer elemento de la matriz que resultó del procesamiento de expresiones regulares es un comentario .

  2. protectRealComments codifica el tercer elemento de la matriz si lo considera como un comentario real. En el caso de un comentario protegido anidado, la entrada protectedRealComments contiene un comentario protegido. Por esa razón, protectedRealComments no lo codifica.

  3. El navegador identifica el sufijo de la siguiente entrada <- -comentario – -!> como un error y transforma la entrada en un comentario html adecuado: <!- -comentario – ->. El resto de la carga útil permanece fuera del comentario html sin codificar.

Cuando el algoritmo procesa la nueva prueba de concepto, ocurre lo siguiente:

  1. Un atacante inyecta esta carga útil

Xss<!--{cke_{cke_protected}protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

  1. RemoveReserveKeywords elimina { cke_protected } y lo que queda de la carga útil es:

Xss<!--{cke_protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

  1. Dado que –!> no se trata como una etiqueta final de comentario, el método de análisis CKEditor4 considera todo el texto resaltado como un comentario protegido.

Xss<!--{cke_protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

  1. protectRealComments identifica el comentario como comentario protegido y no codifica su contenido.

  2. El navegador muta la carga útil y se elimina el signo de exclamación. Por eso, el comentario se cierra y el resto de la carga útil permanece sin desinfectar, con el comentario de cierre ineficaz al final.

Xss<!--{cke_protected}--><img src=1 onerror=alert(`xss`)> -->Attack

  1. El navegador ejecuta el evento img onerror sin desinfectar

RECOMENDACIONES:

Se ha publicado la solución para este problema y se recomienda encarecidamente actualizar CKEditor 4 y Drupal a la última versión disponible. Con respecto a CKEditor, pasar a CKEditor 5 también es una opción. Si bien existe CKEditor 5, CKEditor 4 aún se mantiene porque no son del todo iguales. CKEditor 5 no tiene un botón de fuente listo para usar para la codificación HTML de estilo libre. Es posible lograr la funcionalidad del botón fuente desarrollando un complemento o consumiendo un complemento de terceros.

PreviousXSS Payload en cabeceraNextORACLE BI

Last updated