Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Resumen- Con el crecimiento de Internet en las últimas décadas,
la industria de sistemas de gestión de contenidos (CMS) se...
código fuente, presenta un artículo [11] en el que expone que
el 20% de los 50 plugins de Wordpress más descargados son
vu...
para construir una representación intermedia en forma de árbol
que representa la estructura gramatical del token.
III. TIP...
Figura 1: Marco genérico herramienta análisis estático
De manera más concreta, la herramienta que se propone
implementará ...
T_OPEN_TAG
T_CLOSE_TAG
T_ABSTRACT
T_ARRAY_CAST
T_CALLABLE
T_CLASS_C
T_CLONE
T_INTERFACE
T_SPACESHIP
T_LINE
T_METHOD_C
T_NA...
b) El valor UNTAINT. Una variable es asociada con
este valor si no ha sido suministrada ni puede ser
controlada por el usu...
Para poder llevar a cabo este proceso de eliminación de
falsos positivos, se debe mantener un conjunto de funciones de
sec...
número de patrones vulnerables detectados y el número de
ficheros analizados, en un tiempo de procesamiento
relativamente ...
[19] “Zend Engine 1.” Php,
php.net/manual/es/internals2.ze1.php.
[20] “token_name.” Php, php.net/manual/es/function.token-...
Prochain SlideShare
Chargement dans…5
×

Detección y estimación de vulnerabilidades en plugins de WordPress

9 537 vues

Publié le

Paper sobre un trabajo realizado en el equipo de Ideas Locas del área CDO de Telefónica sobre la búsqueda de vulnerabilidades en plugins de Wordpress.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Detección y estimación de vulnerabilidades en plugins de WordPress

  1. 1. Resumen- Con el crecimiento de Internet en las últimas décadas, la industria de sistemas de gestión de contenidos (CMS) se está incrementando a un ritmo acelerado. Esto está provocando un aumento del número de espacios que se mantienen en Internet. Los gestores de contenido proporcionan una solución sencilla y rápida a esta necesidad. Wordpress es el gestor de contenidos más popular del mundo, utilizado por aproximadamente el 28.9% de todas las páginas web existentes [2], y ocupando una tasa del 60% de todo el mercado global de los CMS [3][4]. Wordpress posee la capacidad de ser extendido de manera sencilla mediante extensiones o plugins desarrollados por entidades externas. En la actualidad existen más de 50.000 extensiones con más de 1.250.000.000 descargas totales [8]. Keywords - plugins, Análisis estático, taint analysis, Wordpress, vulnerabilidad, zero day, extensión I. INTRODUCCIÓN Cada vez más empresas y usuarios utilizan Internet como un escaparate donde anunciar sus productos y creaciones. La necesidad de ofrecer la posibilidad de crear un espacio atractivo de manera sencilla y rápida ha conducido a la aparición de los sistemas de gestión de contenido (CMS). Los CMS son plataformas informáticas que permiten a uno o varios usuarios la creación de un espacio web en Internet con características de diseño avanzadas (vídeo, fotografía, colores…) sin necesidad de disponer de conocimientos de programación. En la actualidad existen más de 1.862.78.875 páginas web [1], de las cuales aproximadamente el 50% se encuentran creadas mediante alguno de los más de 1.000 CMS existentes. Wordpress es el CMS más popular del mundo, siendo utilizado por aproximadamente el 28,9% de todas las páginas web de Internet [2], y ocupando una tasa del 60% del mercado global de todos los CMS [3][4]. Tan solo en un día se crean más de 500 sitios web nuevos con esta plataforma, lo que lo convierte en el CMS que más rápido crece [5]. Teniendo en cuenta los datos mostrados en el párrafo anterior, no es de extrañar que la seguridad de Wordpress se haya convertido en una prioridad para todos los usuarios y empresas que alojan sus servicios en ella. Es por esto, que, a largo del tiempo, se han llevado a cabo diversas auditorías de seguridad y se han desarrollado varias guías de implementación segura [6]. Adicionalmente a la plataforma, Wordpress, proporciona una forma de extender sus funcionalidades por defecto de manera sencilla por cualquier usuario que tenga conocimientos de programación, a través de unas extensiones que se denominan plugins. En la actualidad existen más de 50.000 plugins de Wordpress [7], con un total de más de 1.250.000.000 descargas totales [8]. Estas cifras indican que estas extensiones representan un riesgo de seguridad tan importante como la propia plataforma, llegándose a reportar por herramientas como WPScan [9], que aproximadamente el 52% de todas las vulnerabilidades reportadas pertenecen a plugins. A pesar de esto, los plugins son comúnmente ignorados en las auditorias de seguridad y revisiones de código debido a que no forman parte integral de la plataforma en su estado por defecto, sino que son componentes externos que se añaden bajo demanda, lo que provoca que una gran cantidad de los plugins que se encuentran en el repositorio oficial de Wordpress sean vulnerables. Con todo esto en cuenta, en este artículo se propone un sistema de auditoría de código del conjunto de plugins existentes en el repositorio oficial de Wordpress. El sistema realizará un recorrido por todas y cada una de las extensiones aplicando diferentes técnicas de análisis estático sobre su código fuente. El objetivo principal consiste en la detección de un conjunto de patrones inseguros que pueden desembocar en una posible vulnerabilidad que hasta el momento no ha sido descubierta (Zero Day) tras la realización de un análisis manual por parte de un experto. II. ESTADO DEL ARTE Algunos artículos académicos y empresariales han tratado la seguridad de las extensiones de Wordpress desde diferentes puntos de vista. En [10] los autores pretenden demostrar la existencia de correlación entre el número de descargas de un plugin y el número de vulnerabilidades que posee. La conclusión que exponen es que no existe una clara correlación entre ellas, además, confirman una vulnerabilidad en un plugin que posee aproximadamente 4.000 instalaciones activas. En 2013, Checkmarx, una empresa dedicada al análisis estático de Chema Alonso1 , Santiago Hernández Ramos2 , Pablo González Pérez3 ElevenPaths, Telefónica Digital España. chema@11paths.com1 , santiago.hernandezramos@telefonica.com2 , pablo.gonzalez@11paths.com 3 Detección y estimación de vulnerabilidades en plugins de Wordpress
  2. 2. código fuente, presenta un artículo [11] en el que expone que el 20% de los 50 plugins de Wordpress más descargados son vulnerables a algún tipo de fallo de seguridad, argumentando que esto supone un grave problema de seguridad para las entidades que los albergan. Además, afirma que no existe correlación entre el número de líneas de código que poseen las extensiones y el número de vulnerabilidades, siendo más frecuente la existencia de fallos de seguridad en plugins con menos líneas de código. En relación al análisis estático de código fuente, varias herramientas han tratado la seguridad de los programas escritos en el lenguaje PHP desde el punto de vista de la seguridad de su código fuente. RIPS [12] es una herramienta de análisis estático de código PHP que utiliza técnicas como Taint Analysis para detectar y reportar sus descubrimientos. Pixy [13] es otra herramienta de análisis estático. Los autores de esta herramienta reportan el descubrimiento de 15 nuevas vulnerabilidades en diferentes aplicaciones web manteniendo una tasa de falsos positivos del 50% de los descubrimientos. Por último, trabajos previos realizados por ElevenPaths en los que se ha realizado análisis de código sobre repositorios de software libre, han demostrado la presencia de vulnerabilidades en las extensiones y programas escritos por terceros que se incluyen en una distribución determinada. En este artículo [14], los autores exponen los problemas de seguridad que existen en los paquetes disponibles en los repositorios de sistemas operativos Linux, resultando en una vulnerabilidad confirmada con un CVE asignado, y un gran número de funciones peligrosas detectadas. III. CONCEPTOS TEÓRICOS I. ANÁLISIS ESTÁTICO DE CÓDIGO FUENTE El análisis estático consiste en detectar determinados patrones en el código fuente de un programa informático sin necesidad de ejecutarlo. Sus principales usos abarcan diversas disciplinas como: • Comprobar si un lenguaje de programación cumple con su especificación formal • Comprobar si hay errores de sintaxis en el código fuente de un programa antes de ejecutarlo/compilarlo • Realizar comprobaciones de sintaxis al vuelo (errores que te muestra un IDE) • Medir la calidad del código fuente en un ciclo de desarrollo • Auditar código fuente en busca de patrones inseguros o posibles vulnerabilidades El análisis estático puede ser utilizado de manera complementaria a otras técnicas de análisis, como, por ejemplo, técnicas dinámicas. Algunas de las ventajas que aporta incluir análisis estático en el proceso de verificación del software son: • Detección temprana de errores de software: Cuanto antes se localicen los errores, menor es el coste para solucionarlos. Las técnicas de detección estática permiten encontrar fallos tan pronto como el código fuente esté disponible. • Alcance: Las técnicas de análisis estático son de mucha utilidad para encontrar vulnerabilidades en el código fuente que se encuentran escondidas o son raramente accedidas. • Costes y aplicabilidad: El análisis estático requiere menos recursos que otras técnicas de análisis de software, como, por ejemplo, técnicas de análisis dinámico. Por otra parte, su utilización es totalmente automática, reduciendo considerablemente el esfuerzo humano. II. MODELO DE ANÁLISIS El proceso de análisis estático debe realizarse sobre un modelo que represente el código fuente que se desea analizar. Las representaciones de alto nivel propias de los lenguajes de programación incluyen elementos sintácticos que se añaden con el objetivo de facilitar la lectura o comprensión de determinadas construcciones del lenguaje. Estos elementos sintácticos a menudo son irrelevantes para la realización del análisis, y provocan, entre otras cosas, un incremento en el rendimiento necesario y poca homogeneidad en las construcciones del lenguaje. Para solventar estas limitaciones, el sistema propuesto transforma el código fuente en un modelo que abstrae toda la sintaxis propia de la representación de alto nivel del lenguaje de programación. Esta representación intermedia del código fuente se construye a partir de un conjunto de fases que se especifican a continuación. A. Analizador Léxico Se corresponde con la primera fase de la construcción del modelo y recibe el código fuente en su representación de alto nivel. Consiste en la lectura del código fuente proporcionado por cada uno de los ficheros y la transformación del mismo en una secuencia de caracteres llamados lexemas. Para cada lexema el analizador léxico produce una salida de la forma: <token-name, attribute-value> B. Analizador Sintáctico La segunda fase del proceso de construcción del modelo consiste en recorrer el conjunto de tokens proporcionado por el analizador léxico y utilizar el primer componente del mismo
  3. 3. para construir una representación intermedia en forma de árbol que representa la estructura gramatical del token. III. TIPOS DE ANÁLISIS ESTÁTICO En esta sección se especifican las diferentes técnicas de análisis estático utilizadas en el desarrollo del sistema. Cada uno de los tipos de análisis presentados a continuación se aplica sobre el modelo que se especifica en la sección II. A. Análisis de control de flujo Tras la construcción del modelo, el sistema comienza a aplicar el proceso de análisis estático sobre el mismo. El primer tipo de análisis que realiza es de control de flujo. El análisis de control de flujo consiste en explorar las diferentes ramas que puede tomar el flujo del programa cuando es ejecutado. El resultado suele ser la creación de un grafo de control de flujo formado por un conjunto de bloques básicos y arcos dirigidos que representan el flujo del programa. B. Análisis de flujo de datos Los algoritmos de análisis de flujo de datos (DFA) examinan la forma en la que los datos se mueven a través del programa. Son frecuentemente utilizados en optimización de compiladores para tareas como la eliminación de código muerto. Este tipo de algoritmos recorren el grafo de control de flujo de cada función anotando donde se generan determinados datos y donde se utilizan. El análisis de flujo de datos se define formalmente como se indica a continuación. a) Descripción formal A continuación, se presenta el problema del análisis de flujo de datos desde un punto de vista formal. Un framework de análisis de flujo de datos (D, V, Λ, F) consiste en: a) Una dirección de flujo de datos D. Que puede ser: a. Backwards b. Forwards b) Un semirretículo, que incluye un dominio de valores V y un operador Λ. c) Una familia F de funciones de transferencia de V a V. b) Semirretículo Un semirretículo es un conjunto V y un operador binario Λ, tal que, para todo x, y, z en V: a) x Λ x = x (idempotente) b) x Λ y = y Λ x (conmutativo) c) x Λ (y Λ z) = (x Λ y) Λ z (asociativo) d) Tiene un elemento top, denotado T, tal que: a. Para todo x en V, T Λ x = x Es útil definir un orden parcial ≤ para un semirretículo (V, Λ). Para todo x e y en V, definimos: x ≤ y si y solo si x Λ y = x c) Funciones de transferencia La familia de funciones de transferencia F: V -> V en un framework de análisis de flujo de datos, tiene las siguientes propiedades: a) F tiene una función identidad I, tal que I(x)=x para todo x en V. b) F es cerrada bajo composición. Lo que significa que para dos funciones cualquiera f y g en F, la función h definida por h(x) = g(f(x)) está en F. C. Taint analysis Las herramientas de análisis necesitan conocer qué variables dentro de un programa tienen interacción directa o indirecta con el usuario. Utilizar un análisis de flujo de datos para determinar qué valores puede controlar un atacante, se conoce como Taint Propagation. Saber cómo la información entra en el programa y cómo fluye a través del mismo es clave para identificar y validar los datos de entrada a un programa. Por ejemplo, un programa que contenga un tipo de vulnerabilidad conocida como desbordamiento de búfer, prácticamente siempre contiene una ruta desde una función de entrada hasta la operación vulnerable. IV. IMPLEMENTACIÓN DEL SISTEMA IV. ARQUITECTURA DEL SISTEMA Las herramientas de análisis estático implementan un marco de trabajo que puede definirse mediante el esquema general que se muestra en la figura 3.
  4. 4. Figura 1: Marco genérico herramienta análisis estático De manera más concreta, la herramienta que se propone implementará el marco descrito en la figura 4. De manera adicional al módulo de análisis y presentación de resultados, se implementará un módulo de recolección automática del código fuente, que implementa una técnica conocida como crawling. A continuación, se especifican cada uno de los componentes que se muestran en la figura 4. Figura 2: Marco de la herramienta propuesta V. COMPONENTES DEL SISTEMA En esta sección se exponen los detalles de implementación de cada uno de los módulos del sistema. De manera general, la arquitectura puede definirse mediante el diagrama presentado en la figura 5. Figura 3: Arquitectura de la herramienta A continuación, se realizará un recorrido por cada uno de los componentes. A. Implementación del crawler El crawler que se ha implementado como parte del sistema propuesto, se corresponde con un programa sencillo encargado de localizar el repositorio [17] donde se almacenan cada uno de los plugins de wordpress, y realizar una descarga automática y almacenamiento de los mismos. De esta forma el código fuente será fácilmente accesible por los módulos sucesivos. Además de la descarga y almacenamiento de plugins, este módulo se encargará de manejar su versionado y control de cambios. B. Implementación de Lexer La implementación de este módulo para el lenguaje de programación PHP (lenguaje en el que están escritos los plugins de Wordpress) se ha realizado mediante la utilización de la función token_get_all [18]. Esta función analiza el código fuente de un programa con extensión .php en forma de string y retorna un conjunto de tokens PHP utilizando el escáner léxico de Zen Engine [19]. Cada uno de los tokens devueltos es un array con un identificador, (mediante la función token_name [20], lo convertimos en un nombre) el valor del token y el número de línea. Sobre la lista de tokens obtenidos se realiza un proceso adicional de filtrado a través del cual eliminamos aquellos que no serán útiles para la realización del análisis. El objetivo de este proceso de simplificación es reducir el tiempo de computo a la hora de realizar el análisis sobre el conjunto completo de tokens. El listado de tokens que se considera irrelevante para el análisis se muestra en la tabla 1. T_BAD_CHARACTER T_DOC_COMMENT T_COMMENT T_ML_COMMENT T_INLINE_HTML T_WHITESPACE T_YIELD T_VAR T_USE T_STRING_VARNAME T_GOTO T_STATIC
  5. 5. T_OPEN_TAG T_CLOSE_TAG T_ABSTRACT T_ARRAY_CAST T_CALLABLE T_CLASS_C T_CLONE T_INTERFACE T_SPACESHIP T_LINE T_METHOD_C T_NAMESPACE T_DIR T_DNUMBER T_DOLLAR_OPEN_CURLY_BRACES T_ELLIPSIS T_POW T_POW_EQUAL T_ENDDECLARE T_END_HEREDOC T_NS_SEPARATOR T_STRING_CAST T_PUBLIC T_PRIVATE T_PROTECTED T_START_HEREDOC T_CONST T_CONTINUE T_CURLY_OPEN T_TRAIT T_TRAIT_C T_OBJECT_CAST T_NS_C T_FINAL T_FINALLY T_FUNC_C T_DECLARE T_HALT_COMPILER T_IMPLEMENTS T_INSTANCEOF T_INSTEADOF Tabla 1: Tokens ignorados en el análisis El resultado de esta fase es el código fuente del programa convertido en una lista de tokens a la que se le han aplicado las optimizaciones citadas anteriormente. C. Implementación del parser Para la implementación de este módulo, se recorre la lista de tokens producida por el analizador léxico, identificando mediante el campo “nombre” los más importantes. Para cada uno de los ficheros analizados, se crea una pila de dependencias que permitirá determinar el ámbito de la función o estructura del lenguaje (if, switch…) en la que se encuentran dos variables distintas. Además, se recolectan todas las declaraciones de variables que se realizan en el fichero. Adicionalmente, se realizan determinadas acciones cuando se encuentran determinados tokens. • T_INCLUDE, T_INCLUDE_ONCE, T_REQUIRE, T_REQUIRE_ONCE identifican la inclusión de un fichero, en este caso, se añaden los tokens de ese fichero a la lista de tokens actuales. • T_FUNCTION identifica la declaración de una función, se almacenan los parámetros de la función para análisis posteriores. • T_VARIABLES identifica la declaración de una variable, se analiza la variable con relación a su contexto y se añade en una lista identificando si se encuentra en el interior de una estructura del sistema (function, if, switch…) o si se trata de una variable global. D. Análisis de control de flujo Este módulo se ha implementado de manera que reduzca al máximo posible los requerimientos de procesamiento, y, por lo tanto, no se ha construido el grafo de control de flujo. Para la realización de este módulo se han tenido en cuenta los siguientes tokens. a) Corchetes (“{”, “}”): identifican un cambio de flujo y un nuevo contexto para la declaración de nuevas variables. Cuando se localiza uno de estos tokens, se identifica el nuevo contexto y se genera una pila donde se añadirán las variables que se encuentren declaradas en su interior. Cabe destacar la importancia de añadir los corchetes en las expresiones que presentan la posibilidad de no incluirlos. b) Instrucciones de salida (T_EXIT, T_THROW…): otros de los tokens que se identifican en esta fase son los que provocan una salida del programa o de otras estructuras propias del sistema (if, switch…), en este caso, debe producirse un cambio de contexto cuando se localizan. Además, se registran para indicar al usuario el punto del programa en el que se encuentran. E. Análisis de flujo de datos Sobre los resultados obtenidos en los análisis anteriores, se aplicará un análisis de flujo de datos. Los algoritmos de flujo de datos examinan la forma en la que los datos se mueven a través del programa. Son frecuentemente utilizados en optimización de compiladores para tareas como la eliminación de código muerto. Este tipo de algoritmos recorren el grafo de control de flujo de cada función, en el que se anota donde se generan ciertos datos y donde son utilizados. El tipo de análisis que se realizará es Taint Analysis, con algunos matices que se explicarán en profundidad en los apartados siguientes. Los datos de entrada que recibirá el módulo de análisis serán los obtenidos de los módulos anteriores. A continuación, se presenta el framework de análisis de flujo de datos que se ha definido para el caso de uso planteado. - Valores de flujo de datos para el framework de Taint Analysis El conjunto de valores es un producto de retículos, con un componente por cada variable en el programa. El retículo de una única variable consiste en lo siguiente: a) El valor TAINT. Una variable es asociada con este valor si ha sido suministrada o puede ser controlada de alguna determinada manera por el usuario que ejecuta el programa.
  6. 6. b) El valor UNTAINT. Una variable es asociada con este valor si no ha sido suministrada ni puede ser controlada por el usuario. - Operador para el framework de Taint Analysis definido El operador Λ para este framework se comporta de la siguiente manera; sean x e y dos variables pertenecientes al conjunto de variables del programa, x Λ y = TAINT si x = TAINT Ѵ y = TAINT x Λ y = UNTAINT si x=y=UNTAINT - Funciones de transferencia para el framework de Taint Analysis definido El conjunto F está formado por ciertas funciones de transferencia que aceptan un mapa de variables a valores del retículo y devuelven otro mapa con esta misma forma. F contiene la función identidad, que recibe un mapa de entrada y devuelve ese mismo mapa de salida. F también dispone de la función de transferencia constante para el nodo ENTRADA. Esta función de transferencia recibe un mapa de entrada y retorna un mapa m0, donde m0(v) = UNTAINT. En general, siendo fs la función de transferencia de la instrucción s, y siendo m y m’ valores de flujo de datos, de tal manera que m’ = f(m). A continuación, se describe fs en términos de la relación entre m y m’. 1. Si s no es una instrucción de asignación, entonces fs es simplemente la función identidad. 2. Si s es una asignación a la variable x, entonces m’(v) = m(v), para todas las variables v ≠ x, siempre que se cumpla alguna de las siguientes condiciones: a. Si la parte derecha de la expresión s es una variable var, i. Si var = TAINT, m’(x) = TAINT ii. Si var = UNTAINT, m’(x) = UNTAINT b. Si la parte derecha de la expresión s es de la forma y op z, siendo op una operación cualquiera, entonces: i. m’(x) = TAINT, si cualquiera m(y) ó m(z) son TAINT ii. m’(x) = UNTAINT, si ambas m(y) y m(z) son UNTAINT c. Si la parte derecha de la expresión es una función que recoge datos proporcionados por el usuario, entonces: i. m’(x) = TAINT d. Si la parte derecha de la expresión es otra expresión cualquiera, entonces: i. m’(x) = UNTAINT - Funciones peligrosas (sinks) Tal y como se indica en los apartados anteriores, la herramienta de análisis realizará un recorrido por el flujo de datos del programa, detectando las variables que tienen contacto con una entrada de usuario y propagando estas variables a lo largo del conjunto de variables declaradas en el código fuente del programa. Cuando una de estas variables entra en contacto con una función considerada como peligrosa, la herramienta almacena ese patrón como una potencial vulnerabilidad. Para que este tipo de análisis proporcione resultados concluyentes, se requiere un conjunto de funciones peligrosas relativamente amplio, así como determinar los argumentos que pueden entrar en contacto con datos proporcionados por el usuario. Para el desarrollo de este sistema, se han localizado un conjunto de funciones vulnerables clasificadas por el tipo de fallo de seguridad que pueden ocasionar [15]. En la tabla 2, se presentan algunas de estas funciones para las vulnerabilidades más conocidas en extensiones de Wordpress. Ejecución de código PHP Revelación de información Ejecución de comandos eval phpinfo exec assert posix_mkfifo passthru preg_replace posix_getlogin system create_function posix_ttyname shell_exec include getenv `` (backticks) include_once get_current_user popen require proc_get_status proc_open Tabla 2: Funciones peligrosas - Funciones de securización Una de las partes más relevantes de la eficacia de un sistema de análisis estático es el número de falsos positivos que el sistema produce entre sus resultados. Tanto en PHP como en librerías propias de Wordpress existen un gran número de funciones de securización que permiten prevenir que el usuario introduzca determinada información en algunas funciones peligrosas que pueden desembocar en una vulnerabilidad. Para que el sistema sea completamente efectivo, debe ser capaz de identificar este tipo de funciones y evaluar si una determinada variable del sistema ha sido securizada antes de alcanzar una de las funciones peligrosas especificadas en el apartado anterior. En caso contrario, la herramienta estaría mostrando un patrón vulnerable que realmente se correspondería con un falso positivo.
  7. 7. Para poder llevar a cabo este proceso de eliminación de falsos positivos, se debe mantener un conjunto de funciones de securización propias del lenguaje y de las librerías más utilizadas. En la tabla 3 se muestran algunas funciones de securización utilizadas para evitar algunas de las vulnerabilidades más frecuentes en extensiones de Wordpress. SQL injection Cross-Site Scripting addslashes esc_url mysqli_escape_string esc_url_raw mysqli_real_escape_string esc_html maxdb_escape_string esc_js sqlite_escape_string removeslashes sqlite_udf_encode_binary stripslashed_deep dbx_escape_string sanitize_key Tabla 3: Funciones de securización V. EVALUACIÓN Y RESULTADOS Para realizar una evaluación del sistema, se ha llevado a cabo un análisis sobre una muestra reducida de 60 plugins con un número variable de descargas e instalaciones activas. La muestra de plugins seleccionada se muestra en la tabla 4. cms-tree-page- view wp-polls adminimize booking- calendar search- everything portfolio- slideshow redirection all-in-one-seo- pack buddypress wp-table- reloaded wp-greet-box backwpup wordpress- mu-domain- mapping sidebar-login exclude- pages all-in-one- event-calendar regenerate- thumbnails wp-pagenavi page-links-to wp-e- commerce wp-syntax custom-contact- forms addthis nextgen- gallery efficient- related- posts wp-to-twitter subscribe2 wp-mail-smtp user-access- manager front-end- editor w3-total-cache akismet broken-link- checker the-events- calendar subscribe- to- comments- reloaded yet-another- related-posts- plugin feedwordpress wptouch wordpress- popular-posts wp- dbmanager members wp-postratings wp-super- cache sociable contact- form-7 widget-logic wp-slimstat google- analytics-for- wordpress simple-tags wassup seo-ultimate custom-field- template advanced- custom-fields list-category- posts events- manager breadcrumb- navxt wp-security- scan secure- wordpress google- analyticator twitter- widget-pro oqey-gallery wordpress- importer tinymce- advanced fancybox-for- wordpress theme-my- login Tabla 4: Muestra de plugins seleccionados El análisis realizado con la herramienta propuesta se ha llevado a cabo en una máquina virtual Kali Linux, con una cantidad de memoria RAM de 2563MB y una única CPU. El número total de ficheros analizados ha sido de 6.988 y se ha consumido un tiempo total de 1.854 segundos para completar el análisis. En la tabla 5, se presentan los resultados globales obtenidos por la herramienta. Detecciones Patrones XSS Patrones LFI&RFI Patrones SQLi Patrones de ejecución de código 182 6 0 6 Tabla 5: Resultados de la herramienta Como puede observarse, el número de patrones detectados reduce significativamente el número de ficheros y de líneas de código que deben ser revisadas de manera manual por el analista. De 6.988 ficheros seleccionados en el conjunto de muestra, la herramienta propuesta ha seleccionado un total de 73 ficheros vulnerables y 204 patrones inseguros. Tras el análisis, se ha realizado la revisión manual de algunos de los ficheros, en la tabla 6 se muestran los resultados obtenidos con relación al número de patrones posiblemente vulnerables y los que han sido confirmados por el analista. Patrones XSS Patrones LFI&RFI Patrones SQLi Patrones de ejecución de código Patrones potencialmente vulnerables 172 5 0 5 Patrones vulnerables confirmados 10 1 0 1 Tabla 6: Patrones validados Entre los patrones vulnerables confirmados, se encontraban un total de 5 plugins vulnerables, con un impacto global de más de 1.322.000 instalaciones activas. Cada uno de estos resultados fue reportado y confirmado por los desarrolladores de las extensiones. Actualmente se han asignado 5 CVEs a dichas vulnerabilidades. En la tabla 7 se muestra el nombre de cada uno de los plugins vulnerables con su correspondiente CVE y las instalaciones activas a fecha de abril de 2018. Plugin Instalaciones activas CVE NextGen Gallery +1 millón CVE-2018-7586 Wptouch +200.000 CVE-2018-7036 Subscribe to Comments Reloaded +20.000 CVE-2018-7037 Active Directory Thumbnails +100 CVE-2018-7255 Adresses Maps Pages et Categories +40 CVE-2018-7256 Tabla 7: CVEs confirmados Los resultados obtenidos avalan la eficacia del sistema propuesto, proporcionando un equilibrio aceptable entre el
  8. 8. número de patrones vulnerables detectados y el número de ficheros analizados, en un tiempo de procesamiento relativamente bajo. El total de plugins vulnerables detectados representa un 9,23% del conjunto seleccionado como muestra, entre los que se encuentran algunos situados entre los 30 plugins con más instalaciones activas del mundo [16]. Como otros estudios citados en apartados anteriores afirman, no existe una correlación que establezca que los plugins con mayor número de líneas de código poseen un número más elevado de vulnerabilidades. Estos resultados implican que, teóricamente, en aproximadamente una de cada cinco instalaciones de plugins se están introduciendo en la plataforma de Wordpress una o más vulnerabilidades. VI. CONCLUSIONES En este artículo se presenta una estimación del número de vulnerabilidades no descubiertas en extensiones de Wordpress. Los resultados indican que uno de cada cinco plugins instalados es susceptible de poseer una o varias vulnerabilidades que pueden poner en riesgo la seguridad del sistema. Para realizar el estudio se ha llevado a cabo un análisis de flujo de datos sobre un modelo construido a partir del código fuente de los plugins. En concreto, se ha realizado un tipo de análisis de flujo de datos conocido como Taint analysis, mediante el que se realiza un seguimiento detallado de los datos introducidos por el usuario a través del flujo de instrucciones del programa. Los resultados obtenidos avalan la eficacia del sistema, habiéndose detectado un total de 5 plugins vulnerables con un impacto total de más de 1.322.000 instalaciones activas. VII. REFERENCIAS [1] “Total Number of Websites.” Total Number of Websites - Internet Live Stats, www.internetlivestats.com/total-number- of-websites/. [2] “Usage of Content Management Systems for Websites.” Usage Statistics and Market Share of Content Management Systems for Websites, April 2018, w3techs.com/technologies/overview/content_management/all. [3] “WordPress Stats 2015.” Blogington Post, www.wpblogington.com/data/wordpress-2015. [4] K, Karol. “WordPress Stats: Your Ultimate List of WordPress Statistics (Data, Studies, Facts - Even the Little- Known).” CodeinWP Blog, 21 Feb. 2018, www.codeinwp.com/blog/wordpress-statistics/. [5] “World Wide Web Technology Surveys.” W3Techs, w3techs.com/. [6] “OWASP Wordpress Security Implementation Guideline.” OWASP Wordpress Security Implementation Guideline - OWASP, www.owasp.org/index.php/OWASP_Wordpress_Security_Im plementation_Guideline. [7] “WordPress.org.” WordPress Plugins - Plugins Extend and Expand the Functionality of WordPress., wordpress.org/plugins/. [8] “More Surprising Statistics About WordPress Usage.” ManageWP, 20 Sept. 2016, managewp.com/blog/statistics- about-wordpress-usage. [9] “WPScan.” WPScan by the WPScan Team, wpscan.org/. [10] Koskinen, Teemu, Petri Ihantola, and Ville Karavirta. "Quality of WordPress plug-ins: an overview of security and user ratings." Privacy, Security, Risk and Trust (PASSAT), 2012 International Conference on and 2012 International Confernece on Social Computing (SocialCom). IEEE, 2012. [11] Checkmarx. “The Security State of WordPress' Top 50 Plugins.” The Security State of WordPress' Top 50 Plugins. 2013. [12] DAHSE, J. RIPS – a static source code analyzer for vulnerabilities in PHP scripts. http://www.php- security.org/downloads/rips.pdf, May 2010 [13] Jovanovic, N., et al. “Pixy: a Static Analysis Tool for Detecting Web Application Vulnerabilities.” 2006 IEEE Symposium on Security and Privacy (S&P06), 2006, doi:10.1109/sp.2006.29. [14] Muñoz, Alfonso Muñoz, and Pablo Gonzalez Perez. Detección De Funciones Inseguras En Repositorios De Software Libre. ElevenPaths, 7 Apr. 2016, es.slideshare.net/elevenpaths/deteccin-de-funciones-inseguras- en-repositorios-de-software-libre. [15] “Exploitable PHP Functions.” Security - Exploitable PHP Functions - Stack Overflow, stackoverflow.com/questions/3115559/exploitable-hp- functions. [16] “WordPress.org.” Popular - WordPress Plugins, wordpress.org/plugins/browse/popular/. [17] http://plugins.svn.wordpress.org/ [18] “token_get_all.” Php, php.net/manual/es/function.token- get-all.php.
  9. 9. [19] “Zend Engine 1.” Php, php.net/manual/es/internals2.ze1.php. [20] “token_name.” Php, php.net/manual/es/function.token- name.php.

×