¿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 mi table_prefix y 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 configuraciones de mi base de datos, pero el atacante necesita, por ejemplo, mi DB_HOST , que no es tan fácil de conseguir para poder conectarme a mi db (en mi caso es: define('DB_HOST', 'localhost'); , que el atacante no pudo usar para conectarse a mi db)

¿O me estoy perdiendo algo?

Realmente aprecio tu respuesta!

    
pregunta Kare 03.09.2014 - 12:53

3 respuestas

9

localhost se refiere a la máquina en la que se está ejecutando. Por ejemplo, en mi propio sitio, tomjn.com localhost es 127.0.0.1 como siempre lo es. Esto no significa que el hacker no sepa dónde conectarse, significa que el hacker reemplaza localhost con tomjn.com .

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

Así que ahora el atacante tiene los detalles de su base de datos, y pueden 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 por sí mismos, iniciar sesión, cargar un complemento a través de zip con un script de PHP Shell y comenzar a emitir comandos o usar el sitio como parte de una red bot.

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

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

En el caso de que se adquiera su wp-config.php , es probable que lo haya hecho una secuencia de comandos de ataque automática, no una persona real. Cambia todos tus detalles, restablece todas las contraseñas y cierra el agujero.

    
respondido por el Tom J Nowell 03.09.2014 - 15:21
2

¿Si solo acepta el acceso a la base de datos desde localhost (esto no se logra definiendo DB_HOST como localhost )? No demasiado por sí mismo (el peor de los casos sería que un atacante se haga 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 inicio de sesión

La gente reutiliza sus nombres de usuario y contraseñas. Un atacante verificará si el nombre de usuario y la contraseña de su base de datos (o las variaciones de ellos) funcionan para su instalación de wordpress, para su proveedor, para su correo electrónico, etc.

Como mínimo, un atacante tiene una idea de qué tipo de contraseñas utiliza (totalmente aleatorio, solo en minúsculas / minúsculas, longitud, etc.).

Prefijo de tabla

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

Llaves y sales

Encontré este artículo sugiriendo que realmente no quiero que se filtren (básicamente, cualquier persona puede hacerse cargo de su cuenta de administrador), aunque no sé qué tan actualizada está.

Conjunto de caracteres de base de datos

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

Summary

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

    
respondido por el tim 03.09.2014 - 20:00
1

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

Tu suposición de que la información de DB no es sensible es incorrecta. Supongamos que su sitio está alojado en godaddy. godaddy AFAIK está utilizando servidores dedicados de mysql a los 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 de 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 es posible que tengas 100 sitios compartiendo el servidor contigo. ¿Puedes confiar en que estén lo suficientemente seguros para que el Sr. Evil no pueda acceder a ellos y usarlos para atacar tu sitio?

    
respondido por el Mark Kaplun 03.09.2014 - 21:00

Lea otras preguntas en las etiquetas