Esta semana parece que es la semana en que más actividad referente a WordPress estamos teniendo, pero lo cierto es que han coincidido los plazos en el mismo día sin plantearlo de esta forma, ya que los proyectos del libro de Máxima Seguridad en WordPress que ayer publicó 0xWord y los artículos de cómo Configurar WordPress in Paranoid Mode que ayer publicamos en ElevenPaths vienen desde mucho antes.
Como solemos hacer cuando el día de la semana nos deja, Pablo González (@pablogonzalezpe) y yo nos sentamos unos minutos a primera hora de la mañana. Suele ser una reunión en la que hablamos de nuestras aficiones y pequeños proyectos de ideas locas. De ahí salen muchas de las cosas que luego veis publicadas por ahí, incluidas como pequeñas características de los productos, en conferencias o en debates que tenemos con el laboratorio de ElevenPahts o el equipo de innovación de LUCA.
De una de ellas hace tiempo salió la idea de escribir el libro de Máxima Seguridad en WordPress con Daniel Martín Maldonado. Como es habitual, revisamos el índice de la propuesta del libro - que de esa versión inicial evolucionaría mucho a lo que se convirtió al final -, y un capítulo, pero mientras lo hacía le dije que creía que era buena idea retomar una vieja idea que tenía al respecto, y una nueva idea usando Latch sobre cómo debería ser la seguridad de un WordPress para ser más seguro. Con estas dos ideas, más dos recomendaciones extras, escribimos los dos papers que ya tenéis disponibles en ElevenPaths.
Tres formas de fortificar WordPress con Latch
La idea nueva ya la conocéis porque os he hablado mucho por aquí. Se trataba de integrar las tablas de WordPress en la base de datos de MySQL con Latch, y configurar una serie de modos de seguridad para el CMS que, por medio de triggers, permitiera al administrador del sitio poner WordPress in Paranoid Mode a golpe de Latch.
Esta idea la completamos con, como ya sabéis, la posibilidad de integrar Latch en WordPress a nivel de usuario y tener un 2FA en el proceso de login que permita saber cuándo alguien se ha hecho con tu contraseña en cuanto la use.
Figura 4: Cómo proteger WordPress con Latch en 10 minutos
Ahora, tras el lanzamiento de Latch Cloud TOTP, también se puede utilizar el plugin de Google Authenticator para WordPress pero desde Latch, para que puedas usar si prefieres los 2FA con las opciones que da Latch Cloud TOTP, algo que también se explica en el libro de Máxima Seguridad en WordPress.
Con todos estos pensamientos fue con lo que hicimos el primer paper que tienes arriba, y la conferencia de My WordPress in Paranoid Mode que conté por primera vez a principios de este año que puedes ver en este vídeo de abajo.
Figura 6: Conferencia "My WordPress in Paranoid Mode”
Hasta aquí la primera parte del trabajo, pero aún quedaba la idea vieja, que es una que me machaca la cabeza desde que comencé con la seguridad de las aplicaciones web y que nunca he entendido por qué los CMS no hacen uso de esto. Se trata de mi visión sobre cómo se debería gestionar el principio de Mínimo Privilegio Posible/Mínima Superficie de Exposición en las conexiones a las bases de datos en las aplicaciones web para mitigar el impacto de los fallos de seguridad en ataques.
Fortificar las cadenas de conexión a WordPress
En la mayoría de los sistemas CMS se utiliza un único usuario del SGBD con privilegios totales sobre todas las tablas que es con el que se hacen los cambios en la base de datos. Esto es relevante, porque si un visitante de una web hecha en WordPress, por el mero hecho de solicitar un artículo, genera automáticamente una consulta al SGBD de MySQL desde WordPress con un usuario privilegiado. Si alguien intercepta la cadena de conexión o la ejecución de la consulta con un ataque de red de NetWork Packet Manipulataion podría controlar totalmente el WordPress, pero lo mismo sucedería si hubiera un bug de SQL Injection en cualquiera de los plugins que se hubieran configurado en el tema.
Debido a esto, yo quería probar en WordPress mi idea de utilizar diferentes cadenas de conexión para los diferentes roles que hay en un servidor WordPress, y cada una de esas conexiones se haría con un usuario de MySQL que tendría solo permisos para hacer las cosas que debe hacer ese rol en las tables de WordPress que correspondan.
Pablo y yo convencimos a nuestros compañeros del laboratorio de ElevenPaths que nos hicieron una PoC en la que, primero de todo, fortificamos la conexión remota al motor de WordPress utilizando cadenas de conexión cifradas a MySQL y luego con un sistema que permite cambiar de usuario más o menos privilegiado para distintas acciones del motor.
Así, un visitante no privilegiado de la web hecha con WordPress nunca podrá forzar una conexión al motor MySQL con un usuario, por ejemplo, con permisos de escritura sobre la tabla wp_users. Todo esto está descrito en el segundo artículo que publicamos ayer.
Al final, todos son pruebas de concepto en un artículo que proponen ideas para poner sobre la mesa cómo podría tenerse una versión un poco más segura de WordPress. A saber:
Saludos Malignos!
 |
| Figura 1: Máxima Seguridad en WordPress.... en Paranoid Mode |
Como solemos hacer cuando el día de la semana nos deja, Pablo González (@pablogonzalezpe) y yo nos sentamos unos minutos a primera hora de la mañana. Suele ser una reunión en la que hablamos de nuestras aficiones y pequeños proyectos de ideas locas. De ahí salen muchas de las cosas que luego veis publicadas por ahí, incluidas como pequeñas características de los productos, en conferencias o en debates que tenemos con el laboratorio de ElevenPahts o el equipo de innovación de LUCA.
 |
| Figura 2: Libro de Máxima Seguridad en Windows |
De una de ellas hace tiempo salió la idea de escribir el libro de Máxima Seguridad en WordPress con Daniel Martín Maldonado. Como es habitual, revisamos el índice de la propuesta del libro - que de esa versión inicial evolucionaría mucho a lo que se convirtió al final -, y un capítulo, pero mientras lo hacía le dije que creía que era buena idea retomar una vieja idea que tenía al respecto, y una nueva idea usando Latch sobre cómo debería ser la seguridad de un WordPress para ser más seguro. Con estas dos ideas, más dos recomendaciones extras, escribimos los dos papers que ya tenéis disponibles en ElevenPaths.
Tres formas de fortificar WordPress con Latch
La idea nueva ya la conocéis porque os he hablado mucho por aquí. Se trataba de integrar las tablas de WordPress en la base de datos de MySQL con Latch, y configurar una serie de modos de seguridad para el CMS que, por medio de triggers, permitiera al administrador del sitio poner WordPress in Paranoid Mode a golpe de Latch.
 |
| Figura 3: WordPress in Paranoid Mode PoC |
Esta idea la completamos con, como ya sabéis, la posibilidad de integrar Latch en WordPress a nivel de usuario y tener un 2FA en el proceso de login que permita saber cuándo alguien se ha hecho con tu contraseña en cuanto la use.
Figura 4: Cómo proteger WordPress con Latch en 10 minutos
Ahora, tras el lanzamiento de Latch Cloud TOTP, también se puede utilizar el plugin de Google Authenticator para WordPress pero desde Latch, para que puedas usar si prefieres los 2FA con las opciones que da Latch Cloud TOTP, algo que también se explica en el libro de Máxima Seguridad en WordPress.
Figura 5: WordPress in paranoid Mode (Parte 1)
Con todos estos pensamientos fue con lo que hicimos el primer paper que tienes arriba, y la conferencia de My WordPress in Paranoid Mode que conté por primera vez a principios de este año que puedes ver en este vídeo de abajo.
Figura 6: Conferencia "My WordPress in Paranoid Mode”
Hasta aquí la primera parte del trabajo, pero aún quedaba la idea vieja, que es una que me machaca la cabeza desde que comencé con la seguridad de las aplicaciones web y que nunca he entendido por qué los CMS no hacen uso de esto. Se trata de mi visión sobre cómo se debería gestionar el principio de Mínimo Privilegio Posible/Mínima Superficie de Exposición en las conexiones a las bases de datos en las aplicaciones web para mitigar el impacto de los fallos de seguridad en ataques.
Fortificar las cadenas de conexión a WordPress
En la mayoría de los sistemas CMS se utiliza un único usuario del SGBD con privilegios totales sobre todas las tablas que es con el que se hacen los cambios en la base de datos. Esto es relevante, porque si un visitante de una web hecha en WordPress, por el mero hecho de solicitar un artículo, genera automáticamente una consulta al SGBD de MySQL desde WordPress con un usuario privilegiado. Si alguien intercepta la cadena de conexión o la ejecución de la consulta con un ataque de red de NetWork Packet Manipulataion podría controlar totalmente el WordPress, pero lo mismo sucedería si hubiera un bug de SQL Injection en cualquiera de los plugins que se hubieran configurado en el tema.
 |
| Figura 7: Filtro en ataque de Network Packet Manipulation para crear un usuario enWordPress a partir de una consulta SELECT de un visitante cualquiera a la web |
Debido a esto, yo quería probar en WordPress mi idea de utilizar diferentes cadenas de conexión para los diferentes roles que hay en un servidor WordPress, y cada una de esas conexiones se haría con un usuario de MySQL que tendría solo permisos para hacer las cosas que debe hacer ese rol en las tables de WordPress que correspondan.
 |
| Figura 8: Cada rol de WordPress usa una cadena de conexión con un usuario de MySQL con permisos limitados |
Pablo y yo convencimos a nuestros compañeros del laboratorio de ElevenPaths que nos hicieron una PoC en la que, primero de todo, fortificamos la conexión remota al motor de WordPress utilizando cadenas de conexión cifradas a MySQL y luego con un sistema que permite cambiar de usuario más o menos privilegiado para distintas acciones del motor.
 |
| Figura 9: WordPress con múltiples cadenas de conexión según el rol del usuario que se conecta |
Así, un visitante no privilegiado de la web hecha con WordPress nunca podrá forzar una conexión al motor MySQL con un usuario, por ejemplo, con permisos de escritura sobre la tabla wp_users. Todo esto está descrito en el segundo artículo que publicamos ayer.
Al final, todos son pruebas de concepto en un artículo que proponen ideas para poner sobre la mesa cómo podría tenerse una versión un poco más segura de WordPress. A saber:
1) Poner 2FA a todos tus usuarios con Latch y Latch Cloud TOTP: Ya es posible a día de hoy.Por supuesto, todas las ideas y pruebas de nuestros artículos para Configurar WordPress in Paranoid Mode se incluyeron también como parte del libro de Máxima Seguridad en WordPress, que como os he dicho, hemos ido trabajando el índice y los contenidos a lo largo de varios meses.
2) Poner WordPress in Paranoid Mode con 2FA a nivel de tabla: Disponible como PoC.
3) Configurar cifrado en conexiones a BBDD: Está disponible hoy.
4) Usar MPP/MSE en Cadenas de Conexión: Debería ir en el trunk principal del proyecto. Nosotros solo hemos hecho una PoC de laboratorio que tenéis en el artículo de la segunda parte.
Saludos Malignos!
Apuntado!
ResponderEliminarEs útil la verdad, sobre todo cuando se comienza. Nosotros acabamos de montar el blog de nuestra tienda física y online de informática y electrónica y poco a poco ahí vamos.
Gracias por el artículo y saludos!
Gádor Informática
www.gadorinformatica.es