¿Cómo puedo proteger mejor WP contra un exploit CSRF al crear un nuevo borrador de publicación?
Si agrego una nueva publicación y la guardo como borrador, puedo interceptar la solicitud usando Burp Suite.
Usando la herramienta de participación en Burp Suite, puedo cambiar el valor de la título de la entrada y pegue la URL de nuevo en el navegador que crea un nuevo borrador con el título de publicación modificado.
¿Cómo puedo asegurarme contra esto?
Salud
señora
WordPress ya proporciona un mecanismo de protección CSRF mediante el uso de un nonce. Al crear una nueva publicación, se crea un nuevo nonce único. Este nonce es obligatorio y debe enviarse con el resto de los datos POST para que la publicación se guarde como borrador o se publique. Si el nonce no está presente o no es válido, se rechaza la solicitud. (Probado con WordPress v4.9.8)
En sus pruebas, pudo modificar el borrador porque envió el nonce correcto usando Burp, pero en un ataque CSRF este valor sería desconocido. Burp es un proxy interceptor, por lo que prácticamente realizó un MITM ataque a su propio tráfico HTTP. Si le preocupan los ataques MITM, debe usar HTTPS. Por supuesto, un atacante aún podría interceptar el tráfico de su red, pero todos los datos estarían encriptados.
Entonces, no diría que este es un exploit CSRF, sino un exploit MITM. Puede proteger su instalación de WordPress de la mayoría de las vulnerabilidades públicas manteniendo actualizados su versión, complementos y temas de WordPress, y también puede encontrar muchos complementos relacionados con la seguridad en https://wordpress.org/plugins/tags/security/.
Creo que la mejor herramienta para pruebas de seguridad en WordPress es WPScan. Tiene una enorme base de datos de vulnerabilidades y puede detectar posibles exploits y enumerar usuarios, versiones y complementos. WPScan es principalmente una herramienta de reconocimiento, pero podemos probar si las vulnerabilidades reportadas son explotables con Metasploit o Wpxf, una herramienta menos conocida pero poderosa que se especializa en la explotación de WordPress. Tenga en cuenta que esas herramientas solo pueden detectar y explotar exploits públicos. Si desea descubrir nuevas vulnerabilidades, puede usar Burp o escáneres similares y estudiar el código fuente de WordPress.
Si he entendido mal la pregunta y tiene un formulario que no tiene un nonce (digamos que está escribiendo un complemento), puede agregar un nonce con wp_nonce_field y luego verificarlo en el script que recibe el formulario con wp_verify_nonce. Sin embargo, si tiene una instalación de WordPress que no usa un nonce con sus formularios, no debe intentar agregar un nonce manualmente, sino actualizar a una versión más nueva.
-
Esto no es del todo exacto, porque los nonces de WordPress no caducan correctamente después de un solo uso. Es totalmente posible interceptar un nonce y usarlo para otras solicitudes sin obstáculos durante hasta seis horas más o menos de forma predeterminada. Este ha sido un exploit conocido durante mucho tiempo en la implementación subyacente de WordPress que el equipo central se ha negado obstinadamente a abordar durante varios años.
– mopsyd
4 oct 2018 a las 17:58
-
Los nonces de WordPress, en lugar de caducar inmediatamente, avanzan a través de dos etapas del ciclo de vida y están vinculados a acciones de formularios individuales. Cualquier nonce interceptado se puede usar para cumplir con múltiples llamadas a la misma acción de formulario a la que está vinculado, siempre que sus pasos del ciclo de vida no se hayan resuelto. Esto significa que sin que caduquen explícitamente, un interceptor puede obtener al menos una llamada a la misma acción de formulario sin impedimentos, y varias llamadas a la misma acción de formulario si la fuente que generó el nonce no las caduca (lo que una gran cantidad de complementos no hacen). ‘t, incluso si son actuales).
– mopsyd
4 oct 2018 a las 18:02
-
@mopsyd Estoy de acuerdo y gracias por los comentarios muy detallados, pero eso se evitaría con el uso de HTTPS impuesto por HSTS. No hay excusa para no usar HTTPS hoy en día.
– señora
4 oct 2018 a las 18:13
-
@mopsyd Además, si pueden interceptar el nonce, también pueden obtener las cookies, por lo que creo que este es más un escenario de ataque MITM que un ataque CSRF. Corrígeme si me equivoco, pero estamos hablando de una situación MITM, ¿verdad?
– señora
4 oct 2018 a las 18:49
-
También estoy de acuerdo, pero también entiendo al menos en parte su razonamiento. El equipo de WordPress se propuso crear una plataforma autónoma que sirva a la mayoría de los casos de uso de manera adecuada sin necesidad de dependencias rigurosas para hacerlo. Un sistema seguro que también es eficaz probablemente aprovecharía muchas otras tecnologías más allá del alcance de aquellos que no son particularmente expertos técnicamente. WordPress es una navaja suiza. Hace un montón de cosas, pero ninguna de ellas bien. Una navaja suiza tiene una sierra que cabe en tu bolsillo, pero siempre es inferior a una sierra eléctrica excepto por conveniencia.
– mopsyd
5 de octubre de 2018 a las 3:35
mopsid
WordPress no utiliza nonces tradicionales, sino que los vincula a una acción de formulario específica y una combinación de sesión de usuario, y los mantiene para uso múltiple durante dos tics (12 horas cada uno por defecto), lo que significa que son válidos de forma predeterminada durante un día completo. y tal vez utilizado repetidamente durante ese período de tiempoademás de “refrescarse” después de un uso para restablecer su período de tiempo por completo. Esto ha sido criticado constantemente durante varios años por los profesionales de seguridad como engañoso e inseguro, y el equipo central de WordPress ha defendido su postura al afirmar que el requisito de que alguien tenga tanto la sesión del usuario como el nonce real hace que esto sea una amenaza insignificante. , aunque tanto un host comprometido como un sitio que no tiene una protección SSL válida pueden hacer que esto sea bastante fácil de lograr.
El problema subyacente que está encontrando es sintomático del hecho de que un nonce de WordPress no es un nonce en absoluto. Es esencialmente un hash de control de acceso que se usa repetidamente durante un período corto para una acción de un solo formulario, y no tiene ningún mecanismo para asegurar su uso único. Esta es la razón por la que pudo interceptar y reutilizar con éxito el nonce. Para su información, este comportamiento también se puede recrear con bastante facilidad en Zed Attack Proxy, Wireshark, Charles Proxy y muchas otras utilidades similares. Burp no es la única herramienta capaz de descubrir esta debilidad.
Sin embargo, tiene algún recurso para corregir esto si lo desea, pero es bastante complicado y no particularmente simple de lograr.
Las siguientes funciones son enchufable, lo que significa que puede anularlos con los suyos propios y también controlar la interpretación del sistema de lo que es un nonce. Deberá proporcionar su propio sistema nonce utilizando estos métodos específicos y devolver valores idénticos a los originales esperados para no romper la funcionalidad del código principal/complementos:
Podría, por ejemplo, proporcionar su propia implementación de nonce utilizando un soporte de un paquete como elhardoum/nonce-php o wbswjc/noncey luego implementarlo a través de un complemento personalizado que anula las funciones conectables anteriores y las usa como contenedores para su propia implementación de nonce, aunque esto no es increíblemente sencillo y requerirá una gran cantidad de lógica personalizada para implementar.
No solo deberá anular las funciones conectables anteriores, sino que también deberá llamar apply_filters de manera similar a su propia fuente, anular adecuadamente cualquier cambio que los complementos intenten hacer que estén vinculados a esos filtros, y también devolver un valor esperado en el exactamente el mismo formato como el original para que no interrumpa la forma en que otros complementos/temas que puede estar usando los han implementado.
Si cree que existe suficiente riesgo, o que los datos que su sitio está protegiendo son de suficiente importancia, es probable que valga la pena el esfuerzo. Si no está manejando transacciones financieras o datos confidenciales, está debidamente protegido detrás de SSL, o no tiene un interés particular en escribir una implementación personalizada de nonces y luego mantenerla para evitar las formas en que inevitablemente rompe numerosos complementos que esperan que la implementación laxa predeterminada esté presente, entonces probablemente sea mejor que tome la palabra de los desarrolladores principales y use los valores predeterminados, siempre que actualice con frecuencia, tenga un complemento de seguridad sólido como wordfence o sucuri, y ejecute actualizaciones de forma rutinaria en todos sus complementos/temas.
Como mínimo absoluto, prácticamente deber tener SSL implementado para mitigar los ataques MITM y debe usar encabezados de control de acceso adecuados para mitigar CSRF.
¿Está utilizando la versión gratuita o completa de Burp Suite?
– usuario8717003
25/09/2018 a las 17:32
@magenta Gracias por la respuesta, la versión completa me permite ver este problema.
– wbdlc
26 de septiembre de 2018 a las 8:06
Desafortunadamente, no tengo acceso a la versión completa de Burp. En aras de mi curiosidad, ¿puede decirme dónde y cómo se incrusta la URL del exploit en el documento de WordPress?
– usuario8717003
26/09/2018 a las 23:15
Debe incluir la URL completa que probó, reemplazando el dominio real a menos que esté de acuerdo con compartirlo. Puede filtrar los datos de la publicación y verificar si ya se creó una publicación con el mismo título, pero no creo que sea una buena idea a menos que esté restringiendo las publicaciones para usar títulos únicos. También podría limitar la vida útil del nonce, pero WordPress ya lo maneja bastante bien.
– Sally C.J.
1 oct 2018 a las 16:35
@SallyCJ No puedo compartir la URL, aunque el problema se puede replicar en cualquier instalación de WP + Burp Suite. No puedo limitar la vida útil del nonce, ya que no se usa un nonce en los borradores. Salud
– wbdlc
2 de octubre de 2018 a las 7:47