WordPress Role Based Database Connection Strings
Una aplicaci�n web, o un framework CMS como WordPress, utiliza un repositorio de datos en un motor de bases de datos, en concreto MySQL. Para eso, durante el proceso de instalaci�n se crea un usuario del motor de bases de datos que es el que tiene el control de todas las tablas dentro de la base de datos y puede hacer con ellas lo que le plazca. Es decir, puede insertar, modificar o borrar registros en todas y cada una de las tablas sin ninguna limitaci�n.
 |
| Figura 1: Role-Based Database Connection Strings |
Las acciones que ese usuario de MySQL realiza dentro de ellas, como por ejemplo dar de alta un nuevo registro mediante una instrucci�n INSERT que represente a un nuevo usuario del CMS, est�n limitadas por el c�digo de la propia aplicaci�n, es decir, el c�digo PHP del motor WordPress.
Esta es una situaci�n muy habitual en todas las aplicaciones web, y en especial en la mayor�a de los frameworks de Internet, y tiene implicaciones en la seguridad porque, si un atacante es capaz de encontrar un bug de SQL Injection en cualquiera de los c�digos de WordPress, ya sea en el core del framework, en un plugin o en un tema, implicar�a directamente el control de todas las tablas y su contenido que est�n en MySQL. En la charla de Hardening Wordpress Like a Hacker lo explico en detalle.
Figura 2: Hardening WordPres like a Hacker
Esto se debe a que WordPress no utiliza un sistema de Role-Based DB Connection Strings, es decir, que todos los usuarios de WordPesss - ya sea un usuario an�nimo o el administrador - utilizan la misma cuenta de MySQL en la cadena de conexi�n para ejecutar las consultas SQL, algo que deber�a evitarse en un entorno fortificado.
De esto ya os habl� hace tiempo, y aunque lo suyo es que cada usuario de la aplicaci�n web tuviera su representaci�n en un usuario de la base de datos, a veces por gesti�n de cuentas vol�tiles, por licencias en algunos modelos de venta de algunos motores de base de datos, por la implicaci�n que cuentas del motor puedan tener dentro del resto del sistema inform�tico - por ejemplo, motores integrados en Active Directory - o por complejidad en el desarrollo no se hace. En esos casos, habr�a que dise�ar un modelo de Role-Based Database Connection Strings.
En el gr�fico que os pintaba en el art�culo de hace unos a�os, os hablaba de que se deber�an reconocer los roles principales de la aplicaci�n, en este caso del motor de WordPress, y crear un usuario en MySQL por cada uno de esos roles. Despu�s, se deber�an entregar permisos sobre las tablas a cada uno de esos usuarios teniendo en cuenta que solo deber�an tener acceso a lo estrictamente necesario para el cumplimiento de su rol.
 |
| Figura 3: Esquema de Role-Based Database Connections |
Despu�s, cuando se produce el proceso de login de un usuario de WordPress en el framework, el sistema debe ser capaz de reconocer su rol en WordPress y ejecutar las consultas SQL al motor MySQL con una DB Connection que haya utilizado el usuario adecuado de su rol, consiguiendo limitar el impacto que pueda tener un posible bug de SQL Injection que fuera descubierto en un plugin, un tema o en el core del sistema.
 |
| Figura 4: Cuando sea un usuario loggado se utiliza un usuario privilegiado en MySQL |
 |
| Figura 5: Cuando sea un usuario an�nimo se utiliza un usuario sin privilegios en MySQL |
De esta forma, cuando se lance una consulta al motor MySQL esta utilizar� un usuario distinto de MySQL, siendo el segundo un usuario sin ning�n privilegio de INSERT, UPDATE o DELETE en las tablas que WordPress utiliza en MySQL.
 |
| Figura 6: Definici�n de distintas cadenas de conexi�n |
El funcionamiento es muy sencillo, cuando se va a realizar la conexi�n a MySQL desde WordPress, miramos a ver si el usuario est� logado o no en el framework y se elige uno u otro usuario de MySQL para tirar la cadena de conexi�n.
 |
| Figura 7: Comprobaci�n de si usuario est� logado o no en la PoC |
Toda la informaci�n la ten�is en el paper y en los diferentes art�culos que he ido recogido, pero este v�deo de aqu� os ense�a c�mo funciona en nuestra prueba de concepto.
Figura 7: WordPress Role-Based Database Connection Strings to MySQL
Para que teng�is toda la informaci�n disponible, os dejo aqu� la lista de recursos sobre Hacking, Hardening y Seguridad en WordPress que he ido publicando en el �ltimo tiempo por aqu�.
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[V�deo] Proteger WordPress con Latch
[V�deo] Proteger WordPress con Latch Cloud TOTP
[V�deo] MyWordPress in Paranoid Mode (conferencia Chema Alonso)
[V�deo] MyWordPress in Paranoid Mode (ElevenPaths Talks de Pablo Gonz�lez)
[V�deo] Ejemplo de uso de Latch en WordPress
[V�deo] WordPress Demo XSS en WP-UserAgent
[V�deo] Hardening WordPress like a Hacker
[BlogPost] My WordPress in Paranoid Mode
[BlogPost] M�xima Seguridad en WordPress
[BlogPost] Hackear un WordPress con Network Packet Manipulation
[BlogPost] Fortificar comunicaci�n entre WordPress y MySQL
[BlogPost] WordPress Latch Enforcement
[BlogPost] WordPress: Role-Based Database Connection Strings
[BlogPost] WordPress a�n m�s seguro con Latch Lock After Request
[BlogPost] Fortificar WordPress frente a ataques de fuerza bruta
[BlogPost] Ataques (al coraz�n) de tu WordPress
[BlogPost] C�mo robarle las contrase�as a los administradores de WordPress
[BlogPost] Agrupar el control de varios WordPress con un solo Latch
[BlogPost] WordPress: Time-Based XSPA (Cross-Site Port Attack)
[BlogPost] C�mo deber�a ser un WordPress un poco m�s seguro
[BlogPost] WPHardening: Automatizar fortificaci�n de WordPress
[BlogPost] Protege los borradores de los art�culos de tu WordPress
[BlogPost] Registro de cuentas en WordPress p�blicos
[BlogPost] Riesgos en la ejecuci�n de tareas de Cron
[BlogPost] WordPres: XSS en plugin WP-UserAgent
[BlogPost] Listar los plugins de WordPress en un pentest
[BlogPost] WordPress: SQL Injection en Scarcity Builder Plugin
Saludos Malignos!
Sigue Un inform�tico en el lado del mal - Google+ RSS 0xWord
download file now
alternative link download