CKEditor 4
Last updated
Was this helpful?
Last updated
Was this helpful?
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.
CVSS: 3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N Puntaje: 6.1 (Medio)
En junio de 2020, se publicó 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. 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.
Haga clic en el botón de fuente en CKEditor 4
Pegue la siguiente carga útil:
Xss<!--{cke_protected} --!><img src=1 onerror=alert(`XSS`)> -->Attack
Haga clic en el botón fuente nuevamente para volver al editor normal.
Haga clic en el botón de fuente en CKEditor 4
Pegue la siguiente carga útil:
Xss<!--{cke_protected} --!><img src=1 onerror=alert(`XSS`)>-->Attack
Haga clic en el botón fuente nuevamente para volver al editor normal
Haga clic en el botón de fuente en CKEditor 4
Pegue la siguiente carga útil:
Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack
Haga clic en el botón fuente nuevamente para volver al editor normal.
Editar una página básica
Haga clic en el botón de fuente en CKEditor4
Pegue la siguiente carga útil:
Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack
guardar la página
El siguiente usuario que edita la misma página está expuesto, como se muestra en la siguiente captura de pantalla:
Haga clic en el botón de fuente en CKEditor4
Pegue la siguiente carga útil:
Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack
Haga clic en el botón fuente nuevamente para volver al editor normal o haga clic en el botón Guardar
El método parse divide en una matriz de elementos lo que queda de la carga útil mediante una expresión regular.
<!--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í “- ->”.
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:
Un atacante inyecta esta carga útil
Xss<!--{cke_{cke_protected}protected}--!><img src=1 onerror=alert(`xss`)> -->Attack
Xss<!--{cke_protected}--!><img src=1 onerror=alert(`xss`)> -->Attack
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
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
El navegador ejecuta el evento img onerror sin desinfectar
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.
La función removeReserveKeywords del 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.
removeReserveKeywords elimina instancias de la clave de comentario protegida.
La identifica comentarios con la siguiente estructura
El tercer elemento de la matriz que resultó del procesamiento de expresiones regulares es un .
protectRealComments codifica tercer elemento de la matriz si lo considera como un comentario real. En el caso de un comentario protegido anidado, la entrada contiene un comentario protegido. Por esa razón, no lo codifica.
RemoveReserveKeywords elimina { } y lo que queda de la carga útil es:
protectRealComments identifica comentario como comentario protegido y no codifica su contenido.