Acceso no autorizado a algunos servidores web de ConoHa WING (GMO Internet) (426 cuentas): datos en las áreas de servidor web de los clientes afectados y qué deben hacer hoy los propietarios de sitios

La empresa afirma que contactó individualmente a los clientes afectados «en la dirección de correo electrónico registrada como información de contrato», y que los clientes que no fueron contactados no están afectados.

Revise la carpeta de spam además de la bandeja de entrada. Si una agencia web firmó el contrato por usted, o se registró con una dirección antigua, el correo debió enviarse allí. Inicie sesión a través del sitio oficial que abra usted mismo para ver qué dirección está registrada, o consulte al punto de contacto del aviso (indicado en «Qué ocurrió», más abajo).

La empresa advierte sobre correos de phishing que aprovechan este incidente, y afirma que nunca pide a los clientes contraseñas ni datos de tarjeta de crédito por correo electrónico. También pide a los clientes que comprueben el remitente y el contenido de los avisos individuales antes de actuar.

Tras un incidente de alojamiento, es probable que aparezcan correos falsos con frases como (ejemplos nuestros) «su cuenta está afectada y debe restablecerse» o «confirme su contrato», que llevan a páginas diseñadas para parecerse a la pantalla de inicio de sesión. No inicie sesión desde enlaces de correos; abra el sitio oficial desde un marcador o desde su propia búsqueda (vea qué es el phishing).

La empresa afirma que envió a los clientes afectados los detalles y las «acciones que le pedimos que realice» mediante un correo individual. Ese contenido no es público, por lo que este artículo no puede repetirlo. Antes de actuar, confirme que el correo es auténtico, como en el paso 2: compruébelo a través del sitio oficial, no mediante los enlaces del correo.

Los datos concernidos son «datos almacenados en las áreas de servidor web de los clientes». El aviso no indica si fueron extraídos, pero este sitio recomienda considerarlos posiblemente leídos o alterados. Cambiar las credenciales cuesta menos, en esfuerzo y riesgo, que dejarlas en un estado desconocido.

• El nombre de usuario y la contraseña de la base de datos en el archivo wp-config.php de WordPress (tras cambiar la contraseña de la base de datos, escriba el mismo valor en wp-config.php)
• Las claves de API de servicios externos (pagos, envío de correo, mapas, etc.) en .env y archivos similares: reemítalas en el panel de cada servicio y desactive las claves antiguas
• Las contraseñas de administrador de WordPress y las claves secretas (salts) de wp-config.php; regenerar los salts cierra la sesión de todos los usuarios
• Las contraseñas y claves de FTP y SSH, y cualquier clave pública registrada en el servidor
• Los archivos de copia de seguridad guardados en el servidor (como exportaciones de la base de datos): considere también leídas las credenciales y los datos personales que contengan

Haga los cambios desde un equipo que haya analizado con software antivirus. Para repensar dónde se guardan los archivos de configuración, vea cómo mantener .env fuera de la web pública en alojamiento compartido; para gestionar claves de API, vea nociones básicas de .env y claves de API.

La empresa afirma que eliminó los programas maliciosos el 18 de septiembre. Aun así, merece la pena comprobar por sí mismo que no queda en su sitio ningún cambio que usted no haya hecho. El acceso comenzó el 3 de septiembre, así que céntrese en los cambios desde entonces.

• En el administrador de archivos, ordene la carpeta pública por fecha de modificación y busque archivos modificados en fechas en las que usted no trabajó, o archivos PHP dentro de carpetas de imágenes
• En la lista de usuarios de WordPress, busque administradores que no creó, y plugins o temas que no instaló
• En las tareas programadas (cron) del panel de control, busque entradas que no añadió

Dónde y en qué orden revisar, según el entorno, está en cómo comprobar si su sitio web o servidor ha sido vulnerado. Si encuentra algo desconocido, cópielo antes de borrarlo y contacte con la empresa. Si su sitio guardaba datos personales de terceros, como mensajes de formularios de contacto o registros de miembros, lea también en ese artículo la sección sobre cuándo pueden haberse filtrado datos personales.

Según la empresa, los datos de miembros, contratos y pagos se gestionaban en un entorno separado de los servidores afectados y no se filtraron. Es un ejemplo de una idea general: guardar cosas en lugares separados reduce hasta dónde puede llegar una brecha en una parte.

Puede hacer lo mismo en su sitio. No deje exportaciones de bases de datos ni copias antiguas en el área de servidor web, emita claves de API solo con los permisos que necesiten y guarde los archivos de configuración fuera de la carpeta pública. Cómo comprobarlo está en ¿dejó un archivo secreto en un directorio público?

Según las fechas publicadas, transcurrieron 13 días entre el inicio del acceso (3 de septiembre) y la detección (16 de septiembre). Es una diferencia entre dos fechas, no un juicio sobre si la detección fue lenta. Aun así, que usted note cambios en su sitio cuando algo ocurre en el lado del proveedor depende de lo que tenga implantado.

Un primer paso sencillo: una vez por semana, exporte la lista de usuarios administradores de WordPress y la lista de archivos PHP de la carpeta pública, y compárelas con las de la semana anterior. Cualquier novedad es motivo para empezar a revisar. Para endurecer WordPress en general, vea seguridad de WordPress: una referencia de endurecimiento para producción.

En este incidente, la forma de saber si está afectado es un correo individual a la dirección registrada en el contrato. Si sigue siendo la de una agencia web o una que ya no usa, lo perderá. Compruebe ahora, mientras todo está bien, que la dirección registrada es una que lee y que los correos del proveedor no acaban en el spam.