¿Son seguros los complementos de WordPress?

A lo largo de los años, la investigación ha identificado que más del 20 % de los 50 complementos de WordPress más populares son vulnerables a ataques web comunes. Además, una investigación específica sobre complementos de comercio electrónico descubrió que 7 de los 10 complementos de comercio electrónico más populares contienen vulnerabilidades. Desafortunadamente, los piratas informáticos suelen explotar estas aplicaciones vulnerables para acceder a información confidencial, como registros de salud y detalles financieros. En otros casos, las vulnerabilidades permiten a los piratas desfigurar sitios o redirigirlos a otros sitios controlados por atacantes.

En casos más recientes, hemos visto que se utilizan complementos maliciosos de WordPress no solo para mantener el acceso en servidores comprometidos, sino también para extraer criptomonedas. Entonces, esto plantea una pregunta sobre qué tan seguros son los complementos de WordPress.

En este blog, nos centraremos profundamente en los complementos de WordPress como fuentes potenciales de violaciones de seguridad.

Desarrollo web basado en complementos.

En términos generales, WordPress es el sistema de administración de contenido (CMS) más popular del mundo, ya que impulsa más del 30% de la Web.

Dicho esto, la fuerza principal de WordPress radica en su capacidad para permitir la personalización de sitios a través de su amplia oferta de decenas de miles de complementos y temas. Estos complementos varían en tipo y funcionalidad, desde agregar un formulario de contacto al sitio hasta optimizar un blog para SEO, o incluso publicar nuevas publicaciones en Facebook automáticamente.

Desarrollo de terceros.

La idea principal detrás del desarrollo basado en complementos es ofrecer funciones adicionales para ampliar las capacidades básicas de un sistema. Esencialmente, el núcleo de la aplicación generalmente lo mantiene un conjunto de desarrolladores a largo plazo, mientras que terceros crean una serie de complementos en torno al núcleo de la aplicación.

Este proceso es beneficioso tanto para el proveedor de la aplicación como para el proveedor del complemento, ya que el proveedor de la aplicación puede centrarse más en la funcionalidad principal, mientras que el proveedor del complemento no tiene que preocuparse por la infraestructura del complemento, que es proporcionada por la funcionalidad principal de la aplicación. En general, WordPress también cuenta con el respaldo de una comunidad global de miles de entusiastas y desarrolladores de software comercial y de código abierto.

Sin pautas de seguridad

En general, aunque existe un conjunto de estándares y recomendaciones de codificación, técnicamente no existen pautas de seguridad ni requisitos estándar que un desarrollador de complementos deba cumplir estrictamente. Esto significa que una vulnerabilidad en un complemento puede propagarse a través de millones de sitios web.

Y dado que WordPress se usa mucho, por lo tanto, es un objetivo popular para los ataques. Entonces, en esencia, un pirata informático que explota la vulnerabilidad de un complemento puede infectar miles de sitios. Un escenario del que ya han sido testigos muchos blogueros.

Desafortunadamente, las vulnerabilidades relacionadas con los complementos también tienden a ser recurrentes, explotables y difíciles de detectar. Por lo tanto, existe la necesidad de comprender mejor dichas vulnerabilidades para mitigar cualquier amenaza de seguridad relevante. Profundicemos más, ¿de acuerdo?

¿Es WordPress realmente seguro?

Lo primero es lo primero, vamos a responder a esta pregunta. En su mayor parte, WordPress como un ecosistema en bruto es muy seguro siempre que se cumplan las mejores prácticas de seguridad de WordPress. En promedio, alrededor de 30,000 nuevos sitios web son pirateados cada día en la web. Estos piratas informáticos tienden a apuntar a los sitios web de WordPress debido a las vulnerabilidades de los complementos, las contraseñas débiles y el software obsoleto. Por lo tanto, lograr la mejor seguridad requiere un nivel de intencionalidad, lo que significa seguir algunas de las mejores prácticas básicas de seguridad de WordPress para reducir su vulnerabilidad a los ataques.

Leer más: 11 formas efectivas de ampliar su sitio web de WordPress para un alto tráfico

¿De dónde vienen estas Vulnerabilidades?

Un informe reciente de wpscan.org reveló que WordPress tiene casi 4000 vulnerabilidades de seguridad conocidas. La gran mayoría de estas vulnerabilidades fueron causadas por complementos. Y aunque algunas de estas vulnerabilidades relacionadas con los complementos pueden tener graves consecuencias, muchas pasan desapercibidas durante años antes de ser reparadas. En la mayoría de los casos, comúnmente se pueden corregir con cambios pequeños y localizados en su código fuente.

Sin embargo, antes de adelantarnos, demos un paso atrás.

¿Qué son los complementos?

Básicamente, los complementos son extensiones de software que complementan las aplicaciones con nuevas funciones y comportamientos personalizados. En particular, WordPress ofrece miles de complementos (más de 52 000), que se han utilizado para crear miles de aplicaciones web personalizadas.

Dado que las aplicaciones web basadas en complementos se generalizaron, más desarrolladores centraron su atención en explorar su potencial para reinventar las aplicaciones web al componer, configurar y ampliar diferentes complementos con funcionalidad de vanguardia.

Implicaciones del desarrollo de complementos

Dicho esto, la capacidad de explotar complementos para ampliar los sistemas web con funciones adicionales y personalizadas tiene implicaciones tanto positivas como negativas para los desarrolladores. En primer lugar, en una nota positiva, normalmente hay múltiples opciones de personalización entre las que elegir, lo que brinda a los desarrolladores la capacidad de crear aplicaciones web de forma rápida y sencilla que se adaptan a las necesidades de los usuarios. Por lo tanto, facilita la creación rápida de prototipos y el desarrollo.

Sin embargo, en el lado negativo, una aplicación web puede terminar siendo una composición compleja de múltiples complementos de diferentes fuentes. Lo que en última instancia plantea preocupaciones relacionadas con la seguridad de los complementos. Por ejemplo, se informó que TimThumb, un complemento que fue empleado por millones de aplicaciones basadas en WordPress, estaba abierto a un exploit donde los atacantes podían ejecutar deliberadamente código remoto.

De hecho, aproximadamente el 15% de las vulnerabilidades en los sistemas web pueden considerarse críticas según la Base de datos nacional de vulnerabilidades (NVD) de los Estados Unidos, y casi el 35% de ellas son vulnerabilidades fácilmente explotables.

¿Cuáles son las consecuencias de los complementos comprometidos?

Además de que los usuarios pierdan información financiera o incluso que sus registros de salud se vean comprometidos, cuanto más grave sea una vulnerabilidad, mayor será el impacto financiero en las empresas de software. Además, esto se agrava aún más si los desarrolladores no publican una ruta viable en el momento de la divulgación. Por lo tanto, los proveedores de complementos generalmente se esfuerzan por crear aplicaciones más seguras.

Ahora investiguemos algunas vulnerabilidades de seguridad que normalmente se encuentran en los complementos para obtener una comprensión más amplia de sus consecuencias e implicaciones.

Vulnerabilidades de seguridad

Como hemos recopilado, las vulnerabilidades abren oportunidades para el mal uso potencial de los sistemas de software. En última instancia, dado que WordPress permite que millones de desarrolladores de todo el mundo creen sus propios complementos, no es realista no esperar que se produzca un nivel de compromiso en los complementos.

Como resultado, la seguridad puede verse violada por interacciones no anticipadas de complementos con el sistema central, lo que genera vulnerabilidades que los atacantes pueden explotar potencialmente. Esto implica que la seguridad de los sistemas web depende de mantener bajo control tanto el sistema central como las vulnerabilidades de los complementos.

Complejidad de WordPress

Debido a la complejidad de WordPress, a veces tiende a estar plagado de vulnerabilidades. Por ejemplo, WordPress proporciona una infraestructura intuitiva a la que los complementos pueden aportar nuevas funciones modificando el estado global compartido o ejecutando una función en un punto específico de la ejecución del núcleo del sistema. En consecuencia, puede surgir una vulnerabilidad de complemento cuando el complemento envía datos de entrada maliciosos a los componentes principales sin la desinfección adecuada o la validación de entrada.

Ejemplos de vulnerabilidades de complementos

En última instancia, las vulnerabilidades de los complementos más comunes son las secuencias de comandos entre sitios, la inyección de SQL y la falsificación de solicitudes entre sitios. En general, el tipo de vulnerabilidad más peligroso que los atacantes pueden explotar fácilmente es la inyección SQL. Sin embargo, existen otras vulnerabilidades, fuentes de incumplimiento y compromisos, a saber:

• Errores de procesamiento de datos
• Validación de entrada incorrecta
• Exposición de la información
• Recorrido de ruta
• Características de seguridad
• Controles de acceso
• Control de acceso inadecuado
• Autorización incorrecta
• Autenticación incorrecta
• Falsificación de solicitud entre sitios
• Carga de archivos sin restricciones
• Archivos accesibles para partes externas
• Enlace siguiente
• Redirección abierta
• Inyección de comandos
• Inyección de comandos del sistema operativo
• Secuencias de comandos entre sitios
• Inyección SQL
• Inyección de código

Para obtener más contexto, exploremos los ataques y las vulnerabilidades más comunes.

• · Inyección SQL: las inyecciones SQL suelen ocurrir cuando un atacante obtiene acceso a la base de datos de WordPress de un usuario ya todos los datos de su sitio web. Las inyecciones de SQL también se pueden usar para insertar nuevos datos en una base de datos, incluidos enlaces a sitios web maliciosos o de spam.

Las inyecciones SQL permiten la ejecución de comandos en el servidor back-end, como la extracción de información confidencial. En un entorno alojado, un ataque de inyección SQL se puede utilizar además como trampolín para ataques contra sitios no vulnerables.

• · Cross-Site Scripting: este ataque permite la ejecución de un script en el cliente para eludir los controles de acceso. Por lo general, se dirige a todos los visitantes de un sitio. En un entorno alojado, dicho ataque se puede utilizar para robar las cookies de sesión del administrador del sitio, lo que permite al atacante hacerse pasar por el administrador.

• · Falsificación de solicitud entre sitios: esta vulnerabilidad permite que el pirata informático realice una transacción a nivel de aplicación en nombre de la víctima. En un entorno alojado, un atacante puede iniciar sesión en el sitio en nombre del administrador y realizar actividades maliciosas, como redirigir a los usuarios o realizar transacciones administrativas.

Común en los complementos de WordPress, las vulnerabilidades de secuencias de comandos entre sitios funcionan de esta manera: un atacante encuentra una manera de hacer que una víctima cargue páginas web con secuencias de comandos de JavaScript inseguras.

¿Dónde aparecen la mayoría de las vulnerabilidades?

Un estudio técnico descubrió que la mayoría de las vulnerabilidades (alrededor del 92%) aparecen en el código del complemento. Además, según los resultados, las vulnerabilidades como Cross-site Scripting y Cross-site Request Forgery fueron más comunes en el código del complemento, mientras que otras vulnerabilidades fueron más frecuentes en el código central. De manera relacionada, el estudio reveló que la calidad de los complementos variaba y que no había correlación entre las calificaciones de los complementos y la cantidad de vulnerabilidades encontradas en ellos.

El proceso de escritura de código PHP

El proceso de escritura del código podría ser la génesis de cualquier vulnerabilidad o compromiso. En términos generales, PHP es bien conocido por admitir la ejecución de código arbitrario en el lado del servidor sin invocar directamente el sistema operativo host. Dicho esto, cada vez que los desarrolladores son negligentes durante el proceso de escritura del código, surge la posibilidad de la introducción de vulnerabilidades de secuencias de comandos entre sitios en el código del complemento.

Por otro lado, la inyección de SQL es una vulnerabilidad común porque puede detectarse y explotarse fácilmente. Irónicamente, es probable que incluso un sitio web con una base de usuarios pequeña esté sujeto a un intento de ataque de inyección SQL.

Parte de la exposición a las vulnerabilidades se debe a que los desarrolladores utilizan recursos no seguros. Del mismo modo, la validación de entrada adecuada sigue siendo un desafío importante para los desarrolladores de complementos porque muchos de los complementos desarrollados recientemente han sido creados por desarrolladores no tan calificados.

¿Son críticas las vulnerabilidades causadas por los complementos de WordPress?

Todas las cosas consideradas; una vulnerabilidad puede influir negativamente en el sistema web de varias maneras. Por ejemplo, la explotación exitosa de una vulnerabilidad puede conducir a una pérdida total de confidencialidad, aunque sin pérdida de disponibilidad.

Como se ha señalado, SQL Injection parece ser el tipo de vulnerabilidad más peligroso, aunque solo afecta parcialmente la integridad, disponibilidad y confidencialidad del sistema. Sin embargo, tal vulnerabilidad tiene el potencial de permitir a los atacantes acceso sin restricciones a archivos o información.

Por lo tanto, inadvertidamente, la mayoría de las vulnerabilidades tienen el potencial de conducir a filtraciones de datos, mientras que algunas vulnerabilidades no necesariamente exponen la aplicación web a riesgos de seguridad graves. O bien, es importante evitar correr riesgos con tales probabilidades.

¿Cuánto tiempo puede sobrevivir una vulnerabilidad en el código de un complemento de WordPress?

Por lo general, las vulnerabilidades en el código tienden a transitar por distintos estados, que van desde la introducción, pasando por la divulgación, hasta el lanzamiento de un parche que corrige la amenaza de seguridad.

Por lo general, una vulnerabilidad se revela cuando el descubridor revela los detalles de la amenaza de seguridad a un público más amplio. Finalmente, la vulnerabilidad se soluciona cuando el desarrollador lanza un parche que corrige la amenaza de seguridad subyacente. Sin embargo, a veces una vulnerabilidad pasa desapercibida en una aplicación web durante años antes de ser identificada y luego reparada.

Posibles Mitigaciones y Métodos de Detección

Más vale prevenir que curar, como dice la mayoría de la gente. Por lo tanto, si los desarrolladores de complementos pueden comprender, detectar y eliminar completamente las secuencias de comandos entre sitios, la inyección de SQL y la falsificación de solicitudes entre sitios, es posible que tengamos complementos con un 75 % menos de vulnerabilidades.

Sin embargo, vale la pena señalar que estas tres vulnerabilidades no son las únicas vulnerabilidades que pueden explotar los atacantes. Sino más bien, son las vulnerabilidades más comunes.

Entonces, si bien estas estrategias de mitigación propuestas no garantizan que un complemento determinado sea completamente seguro, sin embargo, establecen buenos principios para la prevención de vulnerabilidades. Por ejemplo:

1. Comprenda cómo se utilizan los datos y la codificación esperada por las partes centrales de WordPress. En este caso, los desarrolladores siempre deben asumir todas las entradas como maliciosas y rechazar cualquier entrada que no se ajuste estrictamente al patrón de codificación requerido, o transformarla en una entrada válida.
2. Para proteger las bases de datos de la inyección de SQL, los desarrolladores deben usar instrucciones SQL parametrizadas separando el código de la manipulación de datos. Además, siempre verifique los encabezados para verificar si la solicitud es del mismo origen. Además, también podría ser útil para evitar exponer datos a atacantes no autenticados.
3. Una buena práctica es evitar el método GET para cualquier solicitud que desencadene un cambio de estado.

Detección de vulnerabilidades

Desafortunadamente, no existe un método consistente para detectar las debilidades de código más comunes con un 100 % de precisión y cobertura. Desafortunadamente, incluso las técnicas modernas que usan análisis de flujo de datos para detectar Cross-site Scripting, a veces dan falsos positivos.

Por el contrario, los métodos de análisis manual, como las revisiones de código, tienden a ser más efectivos que los métodos completamente automatizados, especialmente para las vulnerabilidades relacionadas con el diseño. A modo de ejemplo, la falsificación de solicitudes entre sitios es especialmente difícil de detectar de manera confiable mediante métodos automatizados porque cada aplicación tiene su propia política de seguridad y forma de indicar qué solicitudes requieren una gran confianza en que el usuario tiene la intención de realizar la solicitud.

Sin embargo, por otro lado, el análisis manual puede ser útil para encontrar SQL Injection, aunque es posible que no logre la cobertura de código deseada dentro de limitaciones de tiempo limitadas. Esto puede resultar difícil para las debilidades que deben tenerse en cuenta para todas las entradas, ya que la superficie de ataque puede ser demasiado grande.

En consecuencia, algunas organizaciones enfatizan la importancia de un enfoque equilibrado que incluya revisiones manuales y análisis automatizados que abarquen todas las fases del proceso de desarrollo del sistema web.

Mejores prácticas para proteger su aplicación de WordPress

• Descargue complementos solo de fuentes confiables como WordPress.org: como cualquiera puede desarrollar un complemento de WordPress, los piratas informáticos explotan notoriamente esta vulnerabilidad para ocultar sus propios complementos maliciosos. Es posible que un mercado de buena reputación no garantice completamente el acceso a complementos inofensivos, pero se recomienda como una práctica de mitigación.
• Asegúrese siempre de que todos sus complementos estén actualizados: los usuarios de WordPress generalmente reciben correos electrónicos de notificación que a menudo ignoran. Asegúrese de configurar sus complementos para que se actualicen automáticamente, o al menos actualícelos manualmente usted mismo.
• Verifique la postura de seguridad del complemento analizándolo en busca de problemas de seguridad: la mayoría de los complementos son de código abierto, lo que significa que su código fuente está disponible. Por lo tanto, asegúrese de utilizar una herramienta de análisis de código fuente estático que le proporcionará la "certificación de salud" del complemento. Algunos escáneres avanzados pueden incluso indicarle las recomendaciones de reparación óptimas y más rápidas.
• Elimine todos los complementos no utilizados: desafortunadamente, el código de los complementos antiguos y no utilizados generalmente permanece en el servidor, incluso cuando los complementos están inactivos. Por lo tanto, asegúrese de eliminar siempre los complementos no utilizados como parte del mantenimiento de su sitio de WordPress

Recomendaciones para desarrolladores de complementos

• Siempre incorpore seguridad durante el desarrollo del complemento: las vulnerabilidades incurren en un costo mayor para solucionarlas más tarde, por lo tanto, siempre integre la seguridad dentro del desarrollo del complemento como parte de su proceso seguro de Ciclo de vida de desarrollo de software (SDLC).
• Ejecute el complemento a través de un escáner de código para asegurarse de que cumpla con los últimos estándares de seguridad. Asegúrese de realizar una prueba exhaustiva de análisis del código fuente durante el desarrollo y antes del lanzamiento.

Desarrollo de complementos seguros

Como se ha señalado, los desarrolladores de complementos deben esforzarse por escribir código seguro. Desafortunadamente, muchos desarrolladores aún no saben cómo hacerlo, ya que no están tan capacitados. En particular, dada la naturaleza de las vulnerabilidades más comunes citadas anteriormente, está claro que muchos desarrolladores no entienden los ataques comunes, las funciones de seguridad proporcionadas por el lenguaje y la plataforma que usan, y cómo usar las prácticas aplicables para mitigar los problemas de seguridad.

Por lo tanto, nuestra recomendación en Creole Studios es que tal vez se deberían desarrollar nuevas metodologías adaptadas a los desarrolladores de complementos. Dichas metodologías deberían promover la seguridad en las fases de requisitos y diseño, ya que los desarrolladores son las entidades más importantes en la seguridad del software.

Pensamientos finales

Para resumir el tema, los complementos de WordPress pueden verse comprometidos, y las vulnerabilidades más comunes son las secuencias de comandos entre sitios, la inyección de SQL y la falsificación de solicitudes entre sitios.

Desafortunadamente, la investigación parece sugerir que la frecuencia con la que ocurren estas vulnerabilidades no parece estar disminuyendo con el tiempo. Es seguro asumir que la razón principal de esto es que la mayoría de los desarrolladores de complementos de WordPress siguen estando poco calificados en lo que respecta a la programación segura.

Dicho esto, ¡la primera línea de defensa debería ser el equipo de desarrollo! Y creemos que una vez que se aplican las mejores prácticas de seguridad, los usuarios pueden dormir mejor por la noche, sabiendo que están protegidos de los ciberdelincuentes.

Para obtener más información sobre nuestras prácticas de seguridad de WordPress, asegúrese de solicitar una consulta.