Nuevamente, otro tema interesante, por la sencillez que supone el capturar las credenciales de los usuarios de Wordpress.
Independiente de la versión, y de muchos otros traspies correspondientes a uno de los gestores de contenido mas famosos de la historia de internet.
Importante:
Independiente de la versión, y de muchos otros traspies correspondientes a uno de los gestores de contenido mas famosos de la historia de internet.
Importante:
Un poco de teoría: Arquitectura del core de Wordpress
Wordpress (wp de ahora en adelante) tiene un arquitectura que difiere al típico MVC que usualmente usabamos en PHP, dicha arquitectura se llama Event Driven.
Supongamos que wp empieza a funcionar, partimos en un punto muy sencillo, un usuario quiere leer uno de nuestro artículos. Por lo tanto wordpress le tendría que devolver el texto y las imágenes correspondientes al post que contiene dicho artículo.
Durante la ejecución del sistema (wp core), en determinados puntos se van generando dos tipos de eventos a nivel de wp, todos aquellos dentro de procesos específicos.
Por ejemplo tenemos el evento wp_init que marca el inicio del sistema wp. Otro evento sería admin_init que marca el inicio de la ejecución del panel de administrador. Hay una larga lista de eventos, pues wp es muy grande internamente, si los quieres consultar tienes éste link.
Los eventos los podemos dividir por dos tipos de procesos, los que manipulan datos, y los que esperan que se tome una acción (por ejemplo cuando se ingresa al panel de administrador).
Cuando hablamos de manipular datos, podríamos referirnos perfectamente a la encriptación del password del usuario cuando éste preciona el botón de login. Por otra parte cuando esperamos que se tome una acción, esperamos que el programa realice algo en concreto, un ejemplo de ésto sería denegar el acceso al panel de administración y redirigirlo al panel de usuario común.
El evento de manipulación de datos se puede llamar filtro, y siempre se debe devolver un dato, pues mientras manipulamos la data, el sistema espera que le devolvamos el resultado de dicha manipulación.
Diferente es cuando tomamos una acción, pués muchas veces el usuario es quien ve los resultados. Tambien podemos aplicar ésto a la creación de logs en el sistema. Por lo tanto, el sistema no espera que devolvamos nada, es al revéz, el nos hace entrega de datos para que nosotros llevemos a cabo determinada acción.
Durante la ejecución del sistema (wp core), en determinados puntos se van generando dos tipos de eventos a nivel de wp, todos aquellos dentro de procesos específicos.
Por ejemplo tenemos el evento wp_init que marca el inicio del sistema wp. Otro evento sería admin_init que marca el inicio de la ejecución del panel de administrador. Hay una larga lista de eventos, pues wp es muy grande internamente, si los quieres consultar tienes éste link.
Los eventos los podemos dividir por dos tipos de procesos, los que manipulan datos, y los que esperan que se tome una acción (por ejemplo cuando se ingresa al panel de administrador).
Cuando hablamos de manipular datos, podríamos referirnos perfectamente a la encriptación del password del usuario cuando éste preciona el botón de login. Por otra parte cuando esperamos que se tome una acción, esperamos que el programa realice algo en concreto, un ejemplo de ésto sería denegar el acceso al panel de administración y redirigirlo al panel de usuario común.
El evento de manipulación de datos se puede llamar filtro, y siempre se debe devolver un dato, pues mientras manipulamos la data, el sistema espera que le devolvamos el resultado de dicha manipulación.
Diferente es cuando tomamos una acción, pués muchas veces el usuario es quien ve los resultados. Tambien podemos aplicar ésto a la creación de logs en el sistema. Por lo tanto, el sistema no espera que devolvamos nada, es al revéz, el nos hace entrega de datos para que nosotros llevemos a cabo determinada acción.
Los manejadores de los eventos
Ahora que manejamos lo básico, pasamos a ver quien se encarga de manejar los eventos, o mejor dicho, de recibirlos. Hablamos de funciones o métodos (cuando son objetos (acá entra la programación orientada a objetos (POO) ) ).
Vamos a convenir que todos éstos "eventos" se llaman HOOKS, del inglés gancho. Osea que cuando fijamos un manejador a un evento particular, nos estamos "enganchando" a un punto en específico en la ejecución del sistema de wp.
Vamos a convenir que todos éstos "eventos" se llaman HOOKS, del inglés gancho. Osea que cuando fijamos un manejador a un evento particular, nos estamos "enganchando" a un punto en específico en la ejecución del sistema de wp.
La ejecución
Tratemos ahora la línea temporal en que se ejecuta el sistema, wp no está corriendo indefinidamente, pués eso ocacionaría un consumo de recursos abismal, y nuestro amiguito ya es un goloso cuando se trata de recursos, ésto nos lleva a la siguiente pregunta: ¿en qué punto se ejecuta wp?.
wp se ejecuta en cada request.
Cada vez que se carga una página web, tambien se cargan con ella las imágenes, estilos css, el html, los archivos javascript, audios... una larga lista de solicitudes (requests). El servidor web (apache/nginx/lite speed/...) toma dichas solcitudes, se las envía al motor PHP y éste carga el index.php que está en el directorio raíz (generalmente public_html). A partir de éste punto se ejecuta wp. Por lo tanto, si mirar un artículo involucra 500 solicitudes, wp se ejecutará 500 veces. (muy simplificado pero ya se entiende el punto).
Ahora vamos a mirar a wp como un laberinto, donde cada camino representa un punto de bifurcación en la lógica de nuestro conjuntos de desiciones para salir de dicho laberinto. Con las desiciones correctas vamos a devolver un archivo css, un js, etc.
Accesando al usuario y la clave
En el modelo de datos, ésta información se almacena en la tabla wp_users, no obstante, el password está encriptado. Nos tomaría mucho procesamiento, ergo, una factura de luz gradota calcular todo (si lo craquearamos de manera local).
¿Qué hacemos entonces?
Los capturamos en el momento en el que el usuario haga el login.
El login form de wp
Miremos bien el form de la imágen, cada instalación de wp tiene un campo distinto para el password, dependiendo de customizaciones por parte de plugins/etc.
He resaltado tres elementos, los input para usuario, password y el botón submit que envía el form al servidor.
He resaltado tres elementos, los input para usuario, password y el botón submit que envía el form al servidor.
Mecanismo de captura
Cuando el usuario envíe el formulario de login intentando accesar, deberá enviar el payload del form con la clave en bruto, y en ese momento podremos capturar todo accesando a la variable $_POST desde PHP.
Solo nos queda una cosa mas, no podemos sencillamente ejecutar nuestro colector en cualquier parte. Vamos a engancharnos en un punto específico, cuando se gatilla el hook wp_login. Dicho evento no solo nos permitirá accesar a las credenciales, si nó que tambien nos mantendrá alejados de los intentos de login fallidos, brindándonos siempre, credenciales perfectamente válidas.
Solo nos queda una cosa mas, no podemos sencillamente ejecutar nuestro colector en cualquier parte. Vamos a engancharnos en un punto específico, cuando se gatilla el hook wp_login. Dicho evento no solo nos permitirá accesar a las credenciales, si nó que tambien nos mantendrá alejados de los intentos de login fallidos, brindándonos siempre, credenciales perfectamente válidas.
Veamos entonces como quedaría el código:
PHP:
add_action( 'wp_login', function() {
if ( isset( $_POST['wp-submit'] ) && $_POST['wp-submit'] == 'Acceder' ) {
echo "<b>Usuario:</b> ".$_POST['log']."<br>";
echo "<b>Password:</b> ".$_POST['pwd'];
exit;
}
}, 99, 0 );Nótese que estamos usando el valor del input submit (botón) para validar el request. Luego sencillamente detenemos la ejecución y las credenciales son devueltas al navegador para la vista del usuario. Pero en éste punto podríamos hacer lo que quisieramos con ellas, y nadie se daría cuenta.
En el navegador se vería lo siguiente:
La función add_action
Como habrás notado, tenemos una función llamada add_action, la que nos permite engancharnos en el hook wp_login y ejecutar nuestro manejador para realizar una determinada acción que no devuelve nada al sistema. Dicha función tiene dos parámetros finales, el 99 y el 0. Respectivamente, el primero indica que ejecutamos ésta acción al final de la cola de todos los otros posibles manejadores que puedan estar ejecutándose en éste hook en particular; El segundo le indica al procesador de eventos que no queremos que nos entregue ningún dato para llevar a cabo nuestra acción.
Conclusión
Hemos aprendido como funciona la arquitectura detrás de wordpress (y de paso, porqué es tan reverendamente lento); En base a ésto, tambien aprendimos como es posible capturar las credenciales de los usuarios en el momento en que inician sesión sin que nadie se de cuenta.
Ahora lo pensaremos mejor antes de usar templates y/o plugins nulled, pues nada es gratis en la vida.
Conclusión
Hemos aprendido como funciona la arquitectura detrás de wordpress (y de paso, porqué es tan reverendamente lento); En base a ésto, tambien aprendimos como es posible capturar las credenciales de los usuarios en el momento en que inician sesión sin que nadie se de cuenta.
Ahora lo pensaremos mejor antes de usar templates y/o plugins nulled, pues nada es gratis en la vida.
