Si actualizó un plugin o su CMS después de recibir uno de mis avisos de seguridad, muy bien. Ese era el paso importante y, para muchos sitios, es el único paso necesario.

Actualizar cierra el agujero de ahora en adelante. Lo que no puede decirle es si alguien encontró ese agujero antes de que usted lo cerrara. Esta página es una comprobación práctica de unos 30 minutos para que responda usted mismo a esa pregunta, escrita para propietarios de sitios que no tienen formación en seguridad ni presupuesto para ella. Son indicaciones generales, no un hallazgo sobre su sitio: desde fuera solo puedo ver qué versión de software informa un sitio, nada más.

Paso 1: compruebe qué podía hacer realmente el fallo

No todas las vulnerabilidades merecen la misma respuesta. Busque su aviso en la página de avisos a sitios y compruebe en qué categoría entra (cada página de aviso lo indica cerca del principio):

  • Toma de control de cuentas o ejecución de código (un atacante podría conseguir acceso de administrador o ejecutar su propio código): siga la lista completa de abajo.
  • Lectura de datos (un atacante podría leer información de su base de datos, pero no modificar su sitio): céntrese en los pasos 2 y 5. La pregunta es qué datos había almacenados, no si su sitio fue alterado.
  • Problemas más limitados (fallos que requieren una configuración concreta, o que solo alcanzan una pantalla de administración): la página de aviso de su componente indica qué conviene comprobar, si es que hay algo. A menudo basta con la actualización.

Paso 2: calcule su ventana de exposición

Dos fechas delimitan el periodo que importa:

  1. Cuándo se abrió el agujero en su sitio. Normalmente el día en que instaló la versión afectada. Si no lo sabe, la fecha del aviso CVE correspondiente (enlazado desde cada página de aviso) es un sustituto razonable: desde su publicación, los atacantes también lo sabían.
  2. Cuándo actualizó. El día en que lo cerró.

Todo lo que sigue se refiere a esa ventana. Si es corta, pongamos que actualizó en uno o dos días desde la publicación del aviso, su riesgo es real pero pequeño. Si la ventana dura meses, tómese la lista en serio.

Paso 3: revise quién puede acceder a su sitio

Un atacante que consiguió entrar casi siempre se deja una vía de vuelta. Compruebe, por este orden:

  • Cuentas de administrador. En WordPress: Usuarios y luego filtre por Administrador. En Joomla: Usuarios y luego Gestor de usuarios. Busque cualquier cuenta que usted no creara. Advertencia: algunos fallos (el de Simple Membership, por ejemplo) permiten a un atacante tomar el control de una cuenta existente en lugar de crear una nueva, así que esta comprobación por sí sola no demuestra nada. Por eso la rotación de credenciales del paso 4 importa incluso cuando la lista de usuarios parece limpia.
  • Plugins, temas o extensiones añadidos recientemente que usted no instaló.
  • Tareas programadas (en WordPress las muestra el plugin WP Crontrol; muchas puertas traseras se reinstalan solas desde una tarea programada).
  • Contraseñas de aplicación (WordPress: Usuarios, Perfil, Contraseñas de aplicación), una manera discreta de conservar el acceso por API después de un cambio de contraseña.

Paso 4: rote las credenciales

Si su aviso pertenecía a la categoría de toma de control de cuentas o ejecución de código y su ventana de exposición duró más de unos pocos días, rote las credenciales aunque el paso 3 no encontrara nada:

  • Las contraseñas de todas las cuentas de administrador.
  • Las claves secretas y las sales de wp-config.php (WordPress). Esto cierra la sesión de todo el mundo, incluido cualquier atacante con una sesión robada; el generador oficial proporciona valores nuevos. En Joomla, el equivalente es el valor $secret de configuration.php.
  • Las contraseñas de su panel de alojamiento y de FTP/SFTP si están compartidas con alguien o son antiguas.

Esto cuesta diez minutos y cierra la puerta a sesiones robadas y a hashes de contraseña descifrados, haya habido o no una intrusión.

Paso 5: analice y revise los archivos

  • Ejecute el análisis de malware de su proveedor de alojamiento si el panel de control lo ofrece (la mayoría de los alojamientos compartidos lo hacen), o un analizador gratuito de buena reputación. Para WordPress, el análisis gratuito de Wordfence compara sus archivos con las copias oficiales.
  • Mire los archivos modificados recientemente alrededor y después del inicio de su ventana de exposición, sobre todo los archivos PHP en los directorios de subidas. Ahí prácticamente nunca debería haber PHP.
  • Si su alojamiento conserva registros de acceso, repase la ventana en busca de peticiones al componente vulnerable desde direcciones que no reconozca. La ausencia de indicios aquí significa poco, porque los registros rotan, pero un acierto es concluyente.

Si la comprobación revela algo

No borre nada todavía. Haga primero una copia de seguridad completa, archivos y base de datos, para que lo ocurrido aún pueda examinarse. Después, por orden de coste:

  1. Su proveedor de alojamiento. La mayoría tiene un servicio de limpieza de malware o, como mínimo, le confirmará lo que ven sus propios analizadores. Es la primera llamada adecuada para la mayoría de los sitios pequeños.
  2. Un profesional. Si el sitio maneja datos de clientes o pagos, o el análisis encontró una puerta trasera, vale la pena pagar a alguien para determinar a qué se accedió; en muchos lugares la normativa de protección de datos depende de esa respuesta.
  3. La opción radical que siempre funciona: restaure una copia de seguridad anterior a la ventana de exposición, o reinstale el CMS y los plugins desde fuentes oficiales, conservando solo su contenido. Después actualice y rote todo lo anterior.

Si no está seguro de lo que está viendo, también puede sencillamente responder al correo del aviso. Leo todas las respuestas, y orientar a alguien en la dirección correcta es parte del motivo por el que envío estos avisos. No vendo un servicio de limpieza y esta página no es un argumento de venta; consulte la política de divulgación.

Si ya había actualizado antes de que llegara mi correo

Se aplica la misma lógica: el aviso significa que su sitio informó recientemente de una versión afectada, así que existió una ventana aunque ahora esté cerrada. Los pasos 2 a 4 siguen respondiendo a la pregunta que importa.