Las vulnerabilidades de la API REST de WordPress continúan

Han pasado casi dos semanas desde que el equipo de seguridad de WordPress reveló una vulnerabilidad de escalada de privilegios sin autenticar en un extremo de la API REST en 4.7 y 4.7.1. La vulnerabilidad se corrigió silenciosamente y la divulgación se retrasó una semana para dar a los propietarios de sitios de WordPress una ventaja en la actualización a 4.7.2. La semana pasada, cientos de miles de sitios vulnerables ya habían sido desfigurados y los informes de daños aún continúan.

Durante el fin de semana, los ataques aumentaron y las empresas de seguridad de WordPress han visto más intentos bloqueados por sus firewalls. Sucuri, la firma de seguridad del sitio web que informó sobre la vulnerabilidad de WordPress, estaba rastreando la campaña "Hackeado por w4l3XzY3" la semana pasada y estimó 66,000 desfiguraciones. Esa campaña en particular ahora ha superado las 260.000 páginas indexadas por Google. Es una de las casi dos docenas de campañas de desfiguración dirigidas a la vulnerabilidad.

“Durante las últimas 24 horas, hemos visto un crecimiento promedio de páginas desfiguradas por campaña del 44%”, dijo el viernes el director ejecutivo de Wordfence, Mark Maunder. “El número total de páginas desfiguradas para todas estas campañas, según lo indexado por Google, ha aumentado de 1.496.020 a 1.893.690. Eso es un aumento del 26 % en el total de páginas desfiguradas en solo 24 horas”.

Maunder hizo referencia a un gráfico de Tendencias de Google que, según él, demuestra el éxito que han tenido las campañas de desfiguración durante la semana pasada. El pico comenzó el día que WordPress reveló la vulnerabilidad.

Sin embargo, White Fir Design, otra empresa que ofrece servicios de seguridad, cuestiona las afirmaciones de Wordfence de que se piratearon 1,8 millones de páginas. La cifra de ~2 millones de páginas se cita en informes de BBC, The Enquirer, Ars Technica, CIO.com y otras publicaciones. White Fir Design sostiene que las páginas pirateadas que han sido indexadas por Google no son una representación precisa.

El CTO de Sucuri, Daniel Cid, tampoco está totalmente de acuerdo con la evaluación de la situación de Wordfence. Después de investigar un poco durante el fin de semana, Sucuri estima que más de 50,000 sitios fueron pirateados con 20-30 páginas por sitio desfiguradas. Esto sería aproximadamente un millón en el extremo inferior de la estimación y oscila hasta 1,5 millones.

Sucuri también está comenzando a ver intentos más serios sobre la vulnerabilidad de la API REST en forma de ataques de ejecución remota de código (RCE) en sitios que utilizan complementos que permiten la ejecución de PHP desde publicaciones y páginas. Una de esas campañas intenta inyectar una inclusión de PHP para agregar contenido de un sitio comprometido y luego inyectar una puerta trasera oculta en /wp-content/uploads.

“Las desfiguraciones no ofrecen beneficios económicos, por lo que es probable que desaparezcan pronto”, dijo Cid. “Lo que quedará son los intentos de ejecutar comandos (RCE), ya que les da a los atacantes el control total de un sitio, y ofrece múltiples formas de monetizar, y SPAM SEO / enlace de afiliado / inyecciones de anuncios. Estamos comenzando a ver que se intentan en algunos sitios, y esa será probablemente la dirección en la que esta vulnerabilidad se utilizará indebidamente en los próximos días, semanas y posiblemente meses”.

Los piratas informáticos están apuntando a cualquier sitio que no se haya actualizado a 4.7.2; no parece haber ningún patrón entre ellos. Un vistazo rápido a los resultados de Google para las campañas más activas muestra que los sitios comprometidos incluyen blogs, medios, gobierno, educación, deportes, sitios web médicos y de tecnología.

Por qué la API REST está habilitada de forma predeterminada

La API REST de WordPress está habilitada de forma predeterminada, ya que el plan es que más funciones de administración y complementos dependan de la API REST en el futuro. Después de los ataques recientes, varios usuarios comentaron sobre la divulgación de la vulnerabilidad para preguntar por qué está habilitada de forma predeterminada.

“El problema de seguridad está en una función que no uso en ninguno de mis sitios (API REST) ​​y aún así, esta función está habilitada primero de forma predeterminada y segundo desde WordPress 4.7, incluso necesita un complemento, lo que podría presentar más problemas de seguridad. para deshabilitar la función? un usuario (@helios2121) comentó la publicación. “Por favor, reconsidere su enfoque de la seguridad. Crea características que no todo el mundo necesita habilitar. O al menos dar una forma de darse de baja sin requerir complementos adicionales”.

Morten Rand-Hendriksen abrió un ticket de seguimiento para discutir la desactivación de la API REST de forma predeterminada y habilitarla solo cuando el administrador del sitio lo solicite, o un tema o complemento dependa de él.

El Core Committer Sergey Biryukov confirmó que el plan es introducir más funciones básicas que se basen en la API REST. “Desactivar la API REST es como desactivar admin-ajax.php: ambos dañarán su sitio”, dijo Biryukov.

Rand-Hendriksen preguntó por qué los puntos finales de contenido no se pueden proteger de forma predeterminada mientras se permite que la API REST esté activada de forma predeterminada para fines administrativos. Otro usuario preguntó por qué el extremo de Usuarios no está protegido de forma predeterminada (es decir, https://news.microsoft.com/wp-json/wp/v2/users o https://www.obama.org/wp-json/wp /v2/users), que "hace que sea más fácil que nunca obtener todos los nombres de usuario" en cualquier sitio que use 4.7+.

“Si realmente desea deshabilitar la API REST en su(s) sitio(s), esta es nuestra recomendación actual: restringirla a usuarios autenticados”, dijo James Nylen, responsable principal. “Sin embargo, queremos continuar aumentando la adopción y el uso de la API REST, y espero que incluso esta modificación rompa cada vez más la funcionalidad de WP a medida que pasa el tiempo, como los temas e incrustaciones controlados por API”.

Nylen recomienda el complemento Disable JSON API para aquellos que quieran seguir esa recomendación en sitios que usan WordPress 4.7+. El complemento actualmente tiene más de 10,000 instalaciones activas.

El equipo de seguridad de WordPress trabajó diligentemente para mitigar los ataques al ayudar a los hosts y las empresas de seguridad a implementar protecciones antes de que el problema se hiciera público. Sin embargo, la divulgación completa de la vulnerabilidad se enterró en el blog Make/Core, un sitio que no es muy leído entre los propietarios habituales de sitios de WordPress. El enlace a la divulgación se publicó como una adición a la publicación anterior en el blog de noticias de WordPress una semana después.

“Si bien aprecio la divulgación responsable de este problema y el esfuerzo por resolverlo, espero que considere hacer anuncios futuros a través de una nueva publicación en el sitio de noticias de WordPress, en lugar de simplemente agregar una actualización a una publicación anterior”, comentó el usuario @johnrork. en la divulgación oficial. "Probablemente no soy el único que podría haber evitado verse comprometido si esto hubiera aparecido como un elemento nuevo en mi lector de RSS el miércoles".

Aquellos que leyeron los blogs de Make tuvieron una ventaja inicial en arreglar sus propios sitios y/o los sitios de sus clientes. Aquellos que dependen del blog de noticias de WordPress para obtener información sobre actualizaciones de seguridad probablemente leyeron la publicación cuando se publicó inicialmente y nunca volvieron a ver la actualización una semana después. Un problema tan grave justificaba la transparencia de WordPress en una nueva publicación en su blog de noticias. Esto también habría enviado automáticamente un tweet a más de medio millón de seguidores en la cuenta oficial de WordPress y la cuenta de Facebook que tiene más de un millón de me gusta.

Afortunadamente, la cantidad de sitios vulnerables que también tienen complementos que podrían permitir a los atacantes aprovechar esta vulnerabilidad es mucho menor. Los sitios desfigurados son vergonzosos pero fáciles de arreglar. En la mayoría de los casos, los administradores solo necesitan actualizar a 4.7.2 y revertir las publicaciones desfiguradas a la revisión más reciente. La mayoría de los propietarios de sitios no tienen idea de qué tan rápido comienzan a aparecer los exploits después de la divulgación pública, pero esta situación proporcionó un suave recordatorio de la importancia de actualizar WordPress y el beneficio de dejar activadas las actualizaciones automáticas.