El viernes 17 de julio, miles de sitios WordPress en Chile amanecieron con una versi\u00f3n distinta a la que ten\u00edan la noche anterior.<\/p>\n
Nadie apret\u00f3 el bot\u00f3n de actualizar. En muchos casos, el due\u00f1o del sitio ten\u00eda las actualizaciones autom\u00e1ticas desactivadas justamente para que eso no pasara. Igual se actualiz\u00f3.<\/p>\n
No fue una falla. WordPress lo hizo a prop\u00f3sito, y ten\u00eda una buena raz\u00f3n. Lo que llama la atenci\u00f3n es otra cosa: la mayor\u00eda de las personas a las que les pas\u00f3 se enter\u00f3 por casualidad, semanas despu\u00e9s, mirando el n\u00famero de versi\u00f3n.<\/p>\n
Ese d\u00eda WordPress public\u00f3 una actualizaci\u00f3n de seguridad de emergencia y liber\u00f3 tres versiones al mismo tiempo: 7.0.2<\/strong>, 6.9.5<\/strong> y 6.8.6<\/strong>.<\/p>\n Lo hizo para tapar una falla que en el mundo de la seguridad bautizaron como wp2shell<\/strong>. Y no la tap\u00f3 y esper\u00f3 a que cada quien actualizara cuando pudiera: activ\u00f3 la actualizaci\u00f3n autom\u00e1tica forzada para las instalaciones afectadas.<\/p>\n Eso significa que el sitio se actualiz\u00f3 solo, aunque el due\u00f1o hubiera dicho que no quer\u00eda actualizaciones autom\u00e1ticas.<\/p>\n WordPress ha usado ese mecanismo muy pocas veces en su historia. Cuando lo hace, es porque considera que el riesgo de dejar los sitios sin parchar es mayor que el riesgo de romper algo al actualizar.<\/p>\n wp2shell no es una falla, son dos, y el problema es que se pueden encadenar.<\/p>\n La primera est\u00e1 en una parte de WordPress que recibe varias peticiones juntas para procesarlas de una vez. Un atacante puede confundir a esa parte para que interprete mal lo que le est\u00e1n pidiendo.<\/p>\n La segunda es una inyecci\u00f3n SQL: una forma de colar instrucciones dentro de una consulta a la base de datos, en un par\u00e1metro que WordPress usa para filtrar contenido por autor.<\/p>\n Por separado, cada una es un problema. Juntas, permiten que alguien escriba un archivo PHP dentro de tu servidor. Y un archivo PHP puesto por un extra\u00f1o dentro de tu sitio es, en la pr\u00e1ctica, una consola de comandos: desde ah\u00ed puede leer tu base de datos, crearse un usuario administrador, meter publicidad o redirigir a tus visitas a otro sitio.<\/p>\n De ah\u00ed el nombre. De WordPress a shell.<\/p>\n Todos los meses aparecen fallas en plugins y temas de WordPress. Casi siempre pasa una de estas tres cosas: afectan a un plugin espec\u00edfico que quiz\u00e1s ni tienes instalado, necesitan que el atacante ya tenga una cuenta en tu sitio, o requieren que alguien haga clic en algo.<\/p>\n Esta no cumple ninguna de las tres.<\/p>\n A los pocos d\u00edas de publicado el parche ya circulaban p\u00fablicamente los detalles t\u00e9cnicos completos y c\u00f3digo listo para explotarla. El 21 de julio ambas fallas fueron agregadas al cat\u00e1logo de vulnerabilidades explotadas activamente de CISA, la agencia de ciberseguridad de Estados Unidos, lo que significa que ya se estaban usando contra sitios reales.<\/p>\n Esto es lo que conviene tener claro para revisar tu propio sitio:<\/p>\n Si hoy tu sitio muestra 7.0.2, 6.9.5, 6.8.6 o algo m\u00e1s nuevo, est\u00e1s parchado.<\/p>\n Ac\u00e1 viene lo que motiv\u00f3 este art\u00edculo.<\/p>\n Esta fue probablemente la falla de seguridad m\u00e1s seria de WordPress en a\u00f1os. Oblig\u00f3 a la organizaci\u00f3n a tomar una medida excepcional sobre millones de sitios en el mundo, incluidos muchos chilenos.<\/p>\n Y a la mayor\u00eda de los due\u00f1os de esos sitios no les lleg\u00f3 ni un correo.<\/p>\n No estamos hablando de que el proveedor tuviera que arreglarlo: en la mayor\u00eda de los casos el parche lleg\u00f3 solo, por el mecanismo autom\u00e1tico de WordPress. Estamos hablando de algo mucho m\u00e1s b\u00e1sico, que es avisar.<\/p>\n Avisar que iba a pasar. Avisar que pas\u00f3. Avisar qu\u00e9 revisar despu\u00e9s. Porque una actualizaci\u00f3n forzada del n\u00facleo, aunque sea necesaria, puede dejar efectos: un plugin antiguo que deja de ser compatible, un tema hecho a medida que se comporta distinto, una funci\u00f3n que dej\u00f3 de responder.<\/p>\n Un sitio que se rompe un viernes en la noche y cuyo due\u00f1o no sabe siquiera que hubo una actualizaci\u00f3n, va a pasar el fin de semana entero buscando el problema en el lugar equivocado.<\/p>\n Ese es el punto. La diferencia entre un proveedor y otro casi nunca est\u00e1 en el disco duro ni en el panel de control. Est\u00e1 en si te enteras de las cosas por tu proveedor o por casualidad.<\/p>\n Aunque hayan pasado unos d\u00edas, esto sigue valiendo la pena.<\/p>\n 1. En qu\u00e9 versi\u00f3n est\u00e1s realmente.<\/strong> Entra a tu escritorio de WordPress. Abajo a la derecha, o en Escritorio \u2192 Actualizaciones, aparece la versi\u00f3n. Si no llega a las que mencionamos arriba, actualiza ahora, antes de seguir leyendo.<\/p>\n 2. Si el sitio qued\u00f3 funcionando bien.<\/strong> No basta con que cargue la portada. Revisa lo que de verdad usas: el formulario de contacto (env\u00eda uno de prueba y confirma que llegue), el carrito y el proceso de compra si vendes, el inicio de sesi\u00f3n, y el sitio en el celular. Los efectos de una actualizaci\u00f3n suelen aparecer en la parte que nadie mira todos los d\u00edas.<\/p>\n 3. Si hay se\u00f1ales de que entraron antes del parche.<\/strong> Esto es lo m\u00e1s importante y lo que casi nadie hace. La actualizaci\u00f3n te protege desde ahora, pero no borra lo que haya pasado antes. Revisa la lista de usuarios en Usuarios \u2192 Todos los usuarios y confirma que no haya administradores que no reconozcas. Revisa las entradas y p\u00e1ginas por si aparece contenido que no escribiste. Y busca en Google tu propio dominio con 4. De qu\u00e9 fecha son tus backups.<\/strong> Este detalle se pasa por alto y es clave. Si tu \u00fanico respaldo es del 20 de julio y resulta que entraron a tu sitio el 18, tu respaldo tambi\u00e9n trae el problema adentro. Lo ideal es tener respaldos que alcancen a fechas anteriores al 17 de julio. Si no sabes con qu\u00e9 frecuencia se est\u00e1n guardando ni por cu\u00e1nto tiempo se conservan, ese es un tema para resolver esta semana, no el pr\u00f3ximo mes. Ac\u00e1 explicamos c\u00f3mo hacer y verificar respaldos de tu sitio<\/a>.<\/p>\n Pasa, y no significa que hayas hecho algo mal.<\/p>\n Lo primero es no revertir la actualizaci\u00f3n del n\u00facleo para volver a una versi\u00f3n anterior. Eso te devuelve al punto de partida con la falla abierta, que es peor que el problema que est\u00e1s tratando de arreglar.<\/p>\n El camino correcto es al rev\u00e9s: actualizar los plugins y el tema para que se pongan al d\u00eda con el n\u00facleo nuevo. Si uno de ellos lleva a\u00f1os sin actualizarse por su autor, esa es una se\u00f1al en s\u00ed misma y probablemente toque reemplazarlo.<\/p>\n Las actualizaciones autom\u00e1ticas tienen mala fama, y en parte es justificada: a nadie le gusta que le cambien algo sin avisar.<\/p>\n Pero lo que pas\u00f3 el 17 de julio muestra el otro lado. Entre un sitio que se actualiza solo y puede tener un detalle que arreglar, y un sitio sin parchar con c\u00f3digo de ataque p\u00fablico circulando, la elecci\u00f3n no es dif\u00edcil.<\/p>\n Lo que no deber\u00eda pasar es lo tercero: que te actualicen el sitio, que nadie te avise, y que te enteres cuando algo falla.<\/p>\n Un hosting no es solo el espacio donde vive tu sitio. Es tambi\u00e9n qui\u00e9n te avisa cuando algo cambia y qui\u00e9n te contesta cuando algo se rompe. Si esta vez no supiste nada por tu proveedor, vale la pena preguntarse qu\u00e9 otras cosas est\u00e1n pasando sin que te enteres.<\/p>\nQu\u00e9 es wp2shell, explicado sin tecnicismos<\/h2>\n
Por qu\u00e9 esta fue distinta a las vulnerabilidades de siempre<\/h2>\n
\n
Qu\u00e9 versiones estaban afectadas<\/h2>\n
\n
La parte inc\u00f3moda: \u00bfte avis\u00f3 alguien?<\/h2>\n
Las cuatro cosas que conviene revisar hoy<\/h2>\n
site:tudominio.cl<\/code> para ver si aparecen p\u00e1ginas extra\u00f1as indexadas. Si algo no cuadra, tenemos una gu\u00eda completa de las se\u00f1ales de un WordPress hackeado<\/a>.<\/p>\nSi el sitio qued\u00f3 con problemas despu\u00e9s de actualizar<\/h2>\n
La lecci\u00f3n que deja julio<\/h2>\n