El 12 de junio de 2020, Wordfence Threat Intelligence descubrió una vulnerabilidad de Scripting entre sitios (XSS) almacenada no autenticada en TC Custom JavaScript, un complemento de WordPress con más de 10,000 instalaciones.
Los clientes de Wordfence Premium recibieron una nueva regla de firewall para proporcionar protección contra ataques dirigidos a esta vulnerabilidad el mismo día. Los usuarios de Wordfence que todavía usan la versión gratuita recibieron esta regla después de 30 días, el 12 de julio de 2020.
Intentamos contactar al desarrollador del complemento el mismo día, el 12 de junio de 2020, pero no recibimos una respuesta. Después de 10 días sin una respuesta inicial, contactamos al equipo de WordPress Plugins el 22 de junio de 2020. Se lanzó un parche inicial al día siguiente, el 23 de junio de 2020, y se lanzó un parche completo el 29 de junio de 2020.
Descripción:
Plugin afectado de scripting cruzado almacenado no autenticado (XSS) : TC Custom JavaScript
Plugin Slug: tc-custom-javascript
Versiones afectadas: <1.2.2
ID CVE : CVE-2020-14063
Puntaje CVSS: 8.3 (alto)
Vector CVSS: CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: L / I: L / A: L
Versión completamente parcheada: 1.2.2
TC Custom JavaScript es un complemento de WordPress que permite a los propietarios de sitios agregar JavaScript personalizado a cada página de un sitio y enfatiza un enfoque minimalista. Si bien este tipo de funcionalidad puede ser increíblemente útil, también puede ser increíblemente peligroso sin los controles de acceso adecuados.
Este complemento ejecutó la TCCJ_Core_Content::updatefunción inmediatamente después del inicio. Esto era inusual, ya que la mayoría de los complementos de WordPress registran funciones para ejecutarse en puntos predecibles en el proceso de carga de WordPress.
Como resultado, la updatefunción se ejecutó antes de que se pudieran usar las funciones de control de acceso de WordPress, como las comprobaciones de capacidad y la verificación nonce. Esto, combinado con la falta de comprobaciones de capacidad y la verificación de nonce en la función, hizo posible que visitantes no autorizados utilizaran la updatefunción.
La updatefunción utilizó una función complementaria,, has_update_requestpara verificar si el tccj-update POSTparámetro se suministró y se configuró en Update. Si se aprueba esta comprobación, la updatefunción aceptaría el contenido del tccj-content POSTparámetro y lo agregaría a la base de datos.
|
3
4 4
5 5
6 6
7 7
8
9
10
11
12
13
14
15
dieciséis
17
18 años
19
20
21
22
23
24
25
26
27
28
|
class TCCJ_Core_Content { public static function update() { if ( self::has_update_request() ) { if ( get_magic_quotes_gpc() ) $tccj_content = stripslashes( $_POST['tccj-content'] ); else $tccj_content = $_POST['tccj-content']; // Sanitizing data before insert to database $tccj_content = wp_check_invalid_utf8( $tccj_content, true ); $tccj_content = htmlentities( $tccj_content ); if ( ! get_magic_quotes_runtime() ) $tccj_content = addslashes( $tccj_content ); update_option( 'tccj_content', $tccj_content ); } } private static function has_update_request() { if ( isset( $_POST['tccj-update'] ) && ( $_POST['tccj-update'] == 'Update' ) ) return true; else return false; }} |
Si bien la updatefunción se ejecutó htmlentitiesen el contenido proporcionado tccj-contentantes de almacenarlo, esto no proporcionó ninguna seguridad adicional, ya que la TCCJ_Core_Frontend::print_script_in_footerfunción utilizada para mostrar el script agregado no solo se usaba html_entity_decodeen el contenido almacenado sino que también agregaba <script>etiquetas a su alrededor.
|
3
4 4
5 5
6 6
7 7
8
9
10
11
12
13
14
|
class TCCJ_Core_Frontend { public static function print_script_in_footer() { //$tccj_content = sanitize_text_field( get_option( 'tccj_content', '' ) ); $tccj_content = get_option( 'tccj_content', '' ); $tccj_content = stripslashes( $tccj_content ); $tccj_content = html_entity_decode( $tccj_content ); if ( $tccj_content != '' ) { echo '<script type="text/javascript">' . $tccj_content . '</script>'; } }} |
Como tal, un atacante podría enviar una POSTsolicitud a cualquier ubicación en un sitio vulnerable con el tccj-updateparámetro establecido en Updatey el tccj-contentparámetro establecido en JavaScript malicioso, y este JavaScript se mostraría en el pie de página de cada página del sitio.
JavaScript malicioso de este tipo se puede utilizar para redirigir a los visitantes a sitios de publicidad maliciosa o robar información de pago. Peor aún, puede detectar cuándo un administrador visita el sitio y enviar una solicitud en su nombre para infectar archivos con una puerta trasera o posiblemente crear una nueva cuenta de usuario administrador maliciosa que conduzca a la toma de control de todo el sitio.
Cronograma
12 de junio de 2020 : Wordfence Threat Intelligence descubre una vulnerabilidad en TC Custom JavaScript. Lanzamos una regla de firewall disponible para los usuarios de Wordfence Premium e intentamos hacer contacto con el desarrollador del complemento.
22 de junio de 2020 : después de no establecer contacto con el desarrollador del complemento, nos contactamos con el equipo de complementos de WordPress para notificarles sobre la vulnerabilidad.
23 de junio de 2020 : el desarrollador del complemento lanza un parche inicial que aún es vulnerable a los ataques CSRF.
29 de junio de 2020 : se lanza una versión completamente parcheada del complemento.
12 de julio de 2020 : la regla de firewall está disponible para los usuarios gratuitos de Wordfence.
Conclusión
En el artículo de hoy, revisamos una vulnerabilidad de XSS (Cross-Site Scripting) almacenada no autenticada en el complemento JavaScript personalizado de TC. Este defecto se ha corregido por completo en la versión 1.2.2 y recomendamos encarecidamente actualizar a esta versión lo antes posible. Los sitios que ejecutan Wordfence Premium están protegidos contra estas vulnerabilidades desde el 12 de junio de 2020, mientras que los sitios que todavía usan la versión gratuita de Wordfence recibieron la regla de firewall el 12 de julio de 2020.
