¿Qué podría hacer un hacker con mi wp-config.php

11

Estoy tratando de asegurar mi blog de WordPress. Leí algunas publicaciones en la web que deberían cambiar table_prefixy ocultar mi wp-config.php. Sin embargo, no lo entiendo? ¿Qué podría hacer un atacante con mi wp-config.php?

Quiero decir que hay mis configuraciones de base de datos, pero el atacante necesita mi, DB_HOSTpor ejemplo, que no es tan fácil de obtener, para conectarse a mi base de datos (en mi caso es:, define('DB_HOST', 'localhost');que el atacante no pudo usar para conectarse a mi base de datos). )

¿O me estoy perdiendo algo?

Realmente aprecio tu respuesta!

plugins security wp-config

— Kare
fuente

Supongo que será fácil para él inyectar SQL. Sembrado de estrellas. Esperando que los expertos respondan esto.

— Robert hue

También puede publicarlo en la versión beta de Programming Puzzles & Code Golf y ver qué piensa la gente. :)

— Joshua Taylor

1

@JoshuaTaylor Por favor no. Aparte de los problemas éticos obvios, de eso no se trata nuestro sitio: solo nos gustan las preguntas que pueden tener un criterio objetivo ganador para decidir qué solución gana, no solo "¡Oigan, todos escribamos código y diviértanse! ¡Yaaaay!"

— Pomo

@Doorknob Bueno, obviamente sería un concurso de popularidad. Pero en serio, esperaba que el ":)" transmitiera que no hablaba en serio. Si alguien ha intentado publicar sus archivos wp-config como resultado, acepte mis disculpas.

— Joshua Taylor

9

localhostse refiere a la máquina en la que se está ejecutando. Por ejemplo, en mi propio sitio tomjn.com localhost es 127.0.0.1como siempre es. Esto no significa que el hacker no sabe dónde se deben conectar, significa que los hackers sustituye localhostcon tomjn.com.

Por supuesto, si tengo un proxy sentado delante, esto no funcionará, pero tenga en cuenta que si el atacante tiene acceso a mi wp-config.php, ese mismo acceso les permitiría hacer otras cosas en esa máquina.

Entonces, el atacante tiene los detalles de su base de datos y puede leer wp-config.php. Ahora tienen acceso a todo en su base de datos y pueden cambiar cualquier cosa en su base de datos.

Dependiendo de la seguridad de su instalación, pueden crear un usuario para sí mismos, iniciar sesión, cargar un complemento a través de zip con un script PHP Shell y comenzar a emitir comandos o usar el sitio como parte de una red de bots.

También tienen sus sales y claves secretas (si no tiene ninguna de estas, malas, malas, malas), por lo que forzar de forma bruta las contraseñas de sus usuarios se vuelve significativamente más fácil. También tienen acceso a sus correos electrónicos.

Basta con decir que conseguir wp-config.phpes una de las peores cosas que podría suceder. Se pueden hacer muchas más cosas con él, pero llevaría meses escribir cada posible ataque resultante de esto.

En el caso de que wp-config.phpsea adquirido, es probable que lo haya hecho un script de ataque automatizado, no una persona real. Cambie todos sus detalles, restablezca todas las contraseñas y cierre el agujero.

— Tom J Nowell
fuente

2

Esto no significa que el hacker no sabe dónde se deben conectar, significa que los hackers sustituye localhostcon tomjn.com. > Eso supone que tiene el puerto de la base de datos accesible para el mundo exterior. ¿No estaría a salvo si cerró el puerto en las reglas del firewall y solo permitió que las computadoras de la red local (incluida la computadora que ejecuta wordpress) se conectaran a la base de datos?

— IQAndreas

1

Seguiría siendo la ubicación correcta, pero sí, los puertos son relevantes, principalmente apuntaba a la nota original en la pregunta

— Tom J Nowell

2

¿Si solo acepta el acceso a la base de datos desde localhost(esto no se logra definiendo DB_HOSTcomo localhost)? No demasiado en sí mismo (el peor de los casos sería un atacante que se hiciera cargo de la cuenta de administrador), pero en combinación con otras vulnerabilidades, podría ser útil que un atacante tenga acceso a su configuración.

Credenciales de acceso

Las personas reutilizan sus nombres de usuario y contraseñas. Un atacante verificará si su nombre de usuario y contraseña de la base de datos (o variaciones de ellos) funcionan para su instalación de WordPress, para su proveedor de alojamiento, para su correo electrónico, etc.

Por lo menos, un atacante tiene una idea de qué tipo de contraseñas usa (totalmente al azar, solo minúsculas / números, longitud, etc.).

Tabla de prefijos

Si es posible una inyección SQL, un atacante debe conocer los nombres de las tablas. Dependiendo de la base de datos, esto puede ser muy fácil o puede implicar adivinar. Si implica adivinar, es mejor tener el prefijo de la tabla.

Llaves y sales

Encontré este artículo sugiriendo que realmente no desea que se filtren (básicamente, cualquiera podría hacerse cargo de su cuenta de administrador), aunque no sé cuán actualizado está.

Conjunto de caracteres de base de datos

Algunas inyecciones SQL dependen del conjunto de caracteres, por lo que es bueno que un atacante lo sepa.

Resumen

Si no permite el acceso externo a la base de datos, si no reutiliza las contraseñas y no tiene inyecciones de SQL en ningún lado, la principal preocupación sería la clave y las sales.

— tim
fuente

Ese artículo está lo suficientemente actualizado. No quiere que se filtren sus sales y llaves. Esos son información privada. Si incluso sospecha que se han puesto a disposición, cámbielos inmediatamente a otro conjunto de datos aleatorios. No hay ningún inconveniente real en cambiarlos, simplemente cerrará la sesión del sitio web y tendrá que volver a iniciar sesión. Puede obtener un nuevo conjunto aleatorio de claves y sales desde aquí: api.wordpress.org/secret-key/1.1/salt

— Otto

1

Supongo que está preguntando sobre el acceso de lectura, ya que el acceso de escritura es básicamente acceso para inyectar su propio código para hacer lo que quiera con su sitio.

Su suposición de que la información de la base de datos no es confidencial está mal Supongamos que su sitio está alojado en godaddy. godaddy AFAIK está utilizando un servidor mysql dedicado al que probablemente solo se puede acceder desde sus propios servidores, pero si conozco sus detalles, ¿qué tan difícil es para mí crear una cuenta godaddy y escribir un script que acceda a su base de datos? En el caso de las bases de datos locales, es más difícil de explotar, pero en los servidores de alojamiento compartido puede tener 100 sitios que comparten el servidor con usted, ¿puede confiar en que estén lo suficientemente seguros como para que el Sr. Evil no pueda entrar en ellos y usarlos para atacar su sitio?

— Mark Kaplun
fuente