Os presento una pequeña guía que os puede servir a la hora de auditar vuestros propios WordPress. En este caso no hace falta ningún tipo de conocimiento ni herramientas para poder realizar algunos cambios que nos pueden ahorrar más de un disgusto.
Lo primero que podemos hacer cuando queremos auditar un sitio con WordPress es buscar información (lo suyo es seguir la guía OWASP punto por punto) sobre las versiones que están instaladas.
- Identificación de la versión de WordPress.
Podemos buscar información de varias formas, pero si no queremos utilizar herramientas automáticas, lo suyo es "auditar" el código en busca de la versión instalada de WordPress.
Como podemos ver en la imagen de arriba, en este caso la versión de WordPress es una 3.2.1 del 12 de Julio de 2011 (podéis ver las versiones y sus fechas desde aquí). Como veis, la versión es bastante antigua y todas las vulnerabilidades que tiene, podemos verlas desde esta página, para así saber que ataques podrían llevarse a cabo en nuestro WordPress.
Siguiendo con el fin de esta entrada, podemos ver la versión de WordPress visitando el archivo readme.html del sitio. Esto suele estar disponible en casi todos los WordPress. Es un archivo que queda tras la instalación y que ya sabes que deberías borrar.
Otra de las cosas que podemos hacer es verificar si estamos dando información de más. Para ello hacemos una llamada a un directorio que sepamos que no va a existir, en este caso, llamamos a /test y vemos lo que ocurre.
En este caso podemos observar que el servidor en un Debian y que se usa un Apache 2.2.16, versión del 2005 (podemos comprobar las versiones desde aquí y las vulnerabilidades conocidas desde aquí).
Cuando se devuelve un error, cuanta menos información demos, mucho mejor, de esta forma ponemos las cosas un poco más difícil a los atacantes. Desde esta web podéis ver algunos errores chulos.
Otra cosa más a vigilar. Podemos buscar si tenemos un "path disclosure", que no es más que la revelación de los directorios.
En la imagen anterior podemos ver un pequeño listado de los ficheros y directorios, entre ellos "wp-admin" que es el que contiene todos los archivos de administración de WordPress y que no deberían ser accesibles a nadie.
Más cosas que podemos revisar es si mostramos información sobre los plugins que tenemos instalados y que también pueden (o no) ser vulnerables.
Una forma de verlo -una vez más sin usar ninguna herramienta- pasa por volver a ver el código fuente de la página.
Simplemente usando la búsqueda del navegador (Ctrl+f) pondremos palabras claves como:
En este caso podemos observar que el servidor en un Debian y que se usa un Apache 2.2.16, versión del 2005 (podemos comprobar las versiones desde aquí y las vulnerabilidades conocidas desde aquí).
Cuando se devuelve un error, cuanta menos información demos, mucho mejor, de esta forma ponemos las cosas un poco más difícil a los atacantes. Desde esta web podéis ver algunos errores chulos.
Otra cosa más a vigilar. Podemos buscar si tenemos un "path disclosure", que no es más que la revelación de los directorios.
En la imagen anterior podemos ver un pequeño listado de los ficheros y directorios, entre ellos "wp-admin" que es el que contiene todos los archivos de administración de WordPress y que no deberían ser accesibles a nadie.
Más cosas que podemos revisar es si mostramos información sobre los plugins que tenemos instalados y que también pueden (o no) ser vulnerables.
Una forma de verlo -una vez más sin usar ninguna herramienta- pasa por volver a ver el código fuente de la página.
Simplemente usando la búsqueda del navegador (Ctrl+f) pondremos palabras claves como:
- plugins
- wp-content
- Búsqueda de comentarios (<!--)
Otra de las cosas que podemos realizar es la enumeración de usuarios. Esto simplemente consiste en poner detrás de la URL del sitio un "/?author=0" de forma que quede de la siguiente manera.
www.dominio.com/?author=0
En este caso nos encontramos que tanto con el 0 como con el 1, nos devuelve un error de "no encontrado".
En cambio, si empezamos a enumerarlos desde el 10, nos aparece lo siguiente.
Con esto no solo obtenemos los post que ha escrito cada usuario, sino que además tenemos su nombre y apellido que podríamos utilizar a la hora de "bruteforcear" el login.
Como vemos en la imagen de arriba ya sabemos que el usuario existe y que esa no es la contraseña para el usuario.
Hasta aquí la entrada de hoy, en la siguiente veremos un poco más en profundidad como podemos prevenir estos errores.
Como veis, nosotros mismos podemos revisar cuatro cosas básicas tras realizar las instalaciones de WordPress y que nos pueden ayudar para que no nos "hackeen" nuestra web.
En cambio, si empezamos a enumerarlos desde el 10, nos aparece lo siguiente.
Como vemos en la imagen de arriba ya sabemos que el usuario existe y que esa no es la contraseña para el usuario.
Hasta aquí la entrada de hoy, en la siguiente veremos un poco más en profundidad como podemos prevenir estos errores.
Como veis, nosotros mismos podemos revisar cuatro cosas básicas tras realizar las instalaciones de WordPress y que nos pueden ayudar para que no nos "hackeen" nuestra web.
¿Conoces alguna forma más de revisar cosas básicas sin usar herramientas? No dudes en dejarnos un comentario con la información, así podremos añadirla.
Roberto García (@1GbDeInfo)