• No se han encontrado resultados

Módulo de JAVA para la herramienta Auditoría de Código Fuente.

N/A
N/A
Protected

Academic year: 2023

Share "Módulo de JAVA para la herramienta Auditoría de Código Fuente."

Copied!
78
0
0

Texto completo

(1)

Facultad 1

Módulo de JAVA para la herramienta Auditoría de Código Fuente.

Trabajo de diploma para optar por el título de Ingeniero en Ciencias Informáticas.

Autora:

Yanet Cabeza Chávez

Tutores:

Ing. Abel Alfonso Fírvida Donéstevez Ing. Michel Evaristo Febles Parker

La Habana, junio 2015

¨Año 57 de la Revolución¨

(2)

Declaración de autoría

Declaro ser la autora del presente Trabajo de Diploma y se reconoce a la Universidad de las Ciencias Informáticas, los derechos patrimoniales del mismo con carácter exclusivo. Para que así conste firmo la presente declaración jurada de autoría en La Habana a los _______________ días del mes de ______________ del año _____________.

Yanet Cabeza Chávez

__________________

Firma del autor

Ing. Michel Evaristo Febles Parker Ing. Abel Alfonso Fírvida Donéstevez

_______________________ ______________________

Firma del tutor Firma del tutor

(3)

¨Y si alguna de las cosas que decimos las explota el enemigo y nos producen profunda vergüenza, ¡¡bienvenida sea la vergüenza!!... ¡¡bienvenida sea la pena!!, si sabemos convertir la vergüenza en fuerza, si sabemos convertir la vergüenza en espíritu de trabajo, si sabemos convertir la vergüenza en dignidad, si sabemos convertir la vergüenza en moral.¨

Comandante Fidel Castro Ruz

(4)

Dedicatoria

A mi familia por todo su apoyo y comprensión en los momentos más difíciles durante estos cinco años, especialmente a mi mamá porque es lo más grande que tengo en

esta vida, aunque se ponga celosa de mi papá, que comparte el primer con mi

mamá. Los amo a todos.

(5)

Agradecimientos

➢ A mis tutores por su ayuda incondicional en este período, por haber sido mis mejores guías y apoyo.

➢ A mis amigos y compañeros de aula por aguantarme todos estos años sin protestar y por ser siempre sinceros conmigo.

➢ A mis profesores estos cinco años por haberme enseñado lo que hoy pongo en práctica. El esfuerzo, dedicación, conocimiento y amor que depositaron en mi enseñanza son los mejores recuerdos que tengo de esta etapa tan importante de mi vida.

➢ Al tribunal, por su ayuda y orientación este último mes.

➢ A mi prima Jenny y su esposo Landrian, por haberme ayudado estos cinco año de la carrera y no dejarme flaquear cuando algo no salía bien, porque han sido los que me han llevado de la mano, cuando mis padres no podían estar aquí en la escuela para mi.

➢ A mis suegros Lisset y Jorgito por haberme adoptado como su hija estos años y por velar por mi bienestar y educación como si fueran mis verdaderos padres, que en mi corazón ya lo son.

➢ A mi novio, que aunque da unos buenos dolores de cabeza, ha sido mi compañero

inseparable estos tres últimos años de la carrera, que con su ayuda y dedicación he llegado

hasta donde estoy hoy.

(6)

Resumen

En el Centro de Software Libre, se ha desarrollado la herramienta Auditoría de Código Fuente (ACF), la cual se encarga de la revisión de todos los ficheros de código fuente de las aplicaciones o bibliotecas que estén o se agreguen al repositorio del sistema operativo Nova, en busca de fallas de seguridad.

Actualmente ACF no soporta la revisión de código JAVA, lo que podría conllevar a la inclusión de vulnerabilidades en el repositorio. La presente investigación propone la realización de un módulo para la herramienta, con el objetivo de que se puedan auditar los ficheros con extensión .java y pueda disminuir la inclusión de vulnerabilidades dentro del repositorio de Nova. Para ello se realiza un estudio del arte de las herramientas que realizan auditoría de código fuente. Se define como metodología de desarrollo OpenUp, la cual guiará el proceso de desarrollo de software. Para la implementación de la solución propuesta se define como Entorno de Desarrollo Integrado (IDE) Eclipse, como herramienta de modelado Visual Paradigm y como lenguajes de programación C++ y XML. Finalmente se obtuvo como resultado práctico de la investigación, una biblioteca dinámica para la detección y auditoría de ficheros de código fuente JAVA, la cual posibilita la reducción de vulnerabilidades en el repositorio y una mayor seguridad.

Palabras clave:auditoría

,

código fuente, repositorio, vulnerabilidad

(7)

Índice de contenido

Introducción... 1

Capítulo 1. Fundamentación Teórica...6

Introducción... 6

1.1 Definiciones asociadas al tema investigativo...6

1.1.1 Concepto de Vulnerabilidad...6

1.1.2 Clasificación de las vulnerabilidades...7

1.2 Análisis de las principales vulnerabilidades del lenguaje JAVA...11

1.2.1 Applets de JAVA... 13

1.2.2 Vulnerabilidades de JAVA...14

1.3 Herramientas Lint... 16

1.3.1 Análisis de las principales herramientas Lint...17

1.3.2 Características comunes de las herramientas presentadas...18

1.4 Métricas y clasificaciones de las vulnerabilidades a detectar...19

1.4.1 Resultado de la aplicación del estándar CVSS...22

1.5 Metodología de desarrollo...23

1.6 Lenguajes de Programación...25

1.6.1 Lenguaje C++... 25

1.6.2 Lenguaje XML... 26

1.7 Entorno de Desarrollo Integrado (IDE)...26

1.8 Herramienta Case Visual Paradigm...27

1.9 Herramienta de documentación de código...27

Conclusiones Parciales... 28

Capítulo 2. Análisis y Diseño del Módulo de JAVA para ACF...29

Introducción... 29

(8)

2.1 Propuesta de Solución... 29

2.3 Requisitos funcionales... 30

2.4 Requisitos no funcionales...31

2.5 Definición de actores y casos de uso del sistema...31

2.5.1 Definición de actores del sistema...32

2.5.2 Diagrama de Casos de Uso del Sistema...32

2.6 Diagrama de clases del diseño...34

2.6.1 Descripción de las clases fundamentales del diseño...35

2.7 Diagramas de Secuencia...36

2.8 Estilos Arquitectónicos y patrones de diseño...36

2.8.1 Arquitectura de la solución propuesta...37

2.8.2 Patrones de diseño GRASP...38

2.8.3 Patrones de diseño GOF...40

Conclusiones Parciales... 41

Capítulo 3. Implementación y Prueba...42

Introducción... 42

3.1 Diagrama de Componentes...42

3.3 Código fuente... 43

3.3.1 Estándar de codificación...43

3.4 Pruebas de software... 45

3.4.1 Niveles de Prueba... 46

3.4.2 Método de Prueba...47

3.4.3 Técnica de prueba Partición equivalente...47

3.4.4 Diseño de Casos de Prueba basado en casos de uso...48

3.5 Resultados obtenidos de los casos de prueba...49

3.6 Análisis de proyectos JAVA...50

(9)

Conclusiones Parciales... 51

Conclusiones Generales... 52

Recomendaciones... 53

Referencias Bibliográficas... 54

Anexo 1... 58

Anexo 2... 60

Anexo 3... 62

Anexo 4... 63

Anexo 5... 64

(10)

Índice de ilustraciones

Ilustración 1. Uso de JAVA por sitios web, 20 de Febrero de 2015 (1)...1

Ilustración 2. Ejemplo de código de un applet...9

Ilustración 3. Cantidad de vulnerabilidades de JAVA reportadas en los últimos años (13)...12

Ilustración 4. Cantidad de vulnerabilidades de JAVA por tipo reportadas (14)...12

Ilustración 5. Métricas y fórmulas de CVSS...23

Ilustración 6. Relación entre las fases y el ciclo de vida de OpenUp...25

Ilustración 7. Ejemplo de documentación de código usando Doxygen...28

Ilustración 8. Ejemplo de cómo sería el funcionamiento de la solución propuesta...30

Ilustración 9. Diagrama de Casos de Uso del sistema...32

Ilustración 10. Diagrama de clases del diseño...35

Ilustración 11. Diagrama de Paquetes...37

Ilustración 12. Ejemplo donde se pone de manifiesto el uso del patrón Alta cohesión...38

Ilustración 13. Ejemplo donde se pone de manifiesto el uso del patrón Bajo Acoplamiento...39

Ilustración 14. Ejemplo donde se pone de manifiesto el uso del patrón Creador...39

Ilustración 15. Diagrama de Componentes...43

Ilustración 16. Ejemplo del Estándar de Codificación Rompiendo líneas...44

Ilustración 17. Ejemplo de Declaraciones de clases...44

Ilustración 18. Ejemplo de Declaraciones de métodos y variables...45

Ilustración 19. Salto de línea después de punto y coma...45

Ilustración 20. Salto de línea después de abrir una llave...45

Ilustración 21. Esquema del Método de Caja Negra...47

Ilustración 22. Estadísticas de las pruebas...50

Ilustración 23. Imagen del código de la clase acf-java...60

Ilustración 24. Imagen del código de la clase Plugin.cpp...61

(11)

Ilustración 25. Diagrama de secuencia ¨Detectar vulnerabilidades¨...62 Ilustración 26. Resultado de la auditoría del fichero TesisGra...63 Ilustración 27. Imagen del resumen detallado de la auditoría del fichero TesisGra...63

(12)

Índice de tablas

Tabla 1. Ejemplo de vulnerabilidades de JAVA que conllevan a una denegación de servicios (7)...8

Tabla 2. Listado de vulnerabilidades más explotadas y la tecnología donde se encuentran (17)...14

Tabla 3. Comparación de las herramientas que realizan análisis de código JAVA...18

Tabla 4. Actores del sistema... 32

Tabla 5. Descripción textual del caso de uso del sistema ¨Detectar vulnerabilidades en el código fuente JAVA¨... 34

Tabla 6. Descripción de los escenarios del caso de prueba ¨Detectar vulnerabilidades¨...49

Tabla 7. Análisis de proyectos JAVA...51

Tabla 8. Métrica Explotabilidad...58

Tabla 9. Métrica Impacto... 59

Tabla 10. Clasificación según la métrica base...59

Tabla 11. Funciones vulnerables a detectar...66

(13)

Introducción

En la actualidad ha aumentado considerablemente el uso de las Tecnologías de la Información y las Comunicaciones (TIC's) ya que constituyen un avance considerable en el constante desarrollo del hombre, pues amplía sus capacidades físicas y mentales, contribuyendo a la vez al desarrollo de la propia sociedad.

Insertados dentro del ámbito de las TIC's, se encuentran los lenguajes de programación definidos como un idioma artificial diseñado para establecer una comunicación entre el hombre y la computadora. Según el reporte de 2014 de la Web Technology Surveys (W3 Techs), JAVA es el tercer lenguaje de programación más usado con un 2,8 % de uso en el desarrollo de sitios web conocidos, este emergió después de decaer su uso en años anteriores, como se muestra en la siguiente imagen (1):

JAVA fue creado por Sun Microsystems1. El cual fue pensado originalmente para utilizarse en cualquier tipo

1 Sun Microsystems: una empresa informática que se dedicaba a vender estaciones de trabajo, servidores, componentes informáticos, software (sistemas operativos) y servicios informáticos. Fue adquirida en el año 2010 por Oracle Corporation.

Ilustración 1. Uso de JAVA por sitios web, 20 de Febrero de 2015 (1).

(14)

de electrodomésticos pero la idea fracasó y fue retomada al surgir la Web. Uno de los primeros triunfos de este lenguaje fue que se integró en el navegador Netscape y permitía ejecutar programas dentro de una página web, hasta entonces impensable con el HTML2 (2).

En la Universidad de las Ciencias Informáticas (UCI) el lenguaje JAVA es utilizado en centros productivos y proyectos, como es el caso del Centro de Identificación y Seguridad Digital (CISED), Auditoría de Bases de Datos (AuditBD), Gestión Hospitalaria, el Centro de Telemática (TLM), el Centro Especializado en Informática Médica (CESIM) y el Centro de Software Libre (CESOL). Este último posee como objetivos fundamentales:

1. Desarrollar la Distribución GNU/Linux Nova para la migración en Cuba.

2. Definir las directrices, lineamientos y soluciones que guiarán la migración3 nacional.

Según la Resolución 179/14 emitida por la Rectora de la UCI el centro CESOL, como miembro del Comité de Migración creado por la Dirección de Informatización, que es la que conducirá el proceso de migración en la Universidad, es el encargado del desarrollo y actualización de la Distribución GNU/Linux Nova, así como las acciones de capacitación y soporte que sean requeridas por los usuarios para el manejo de las aplicaciones o del propio sistema.

Los centros productivos que sean migrados incluirán aplicaciones al repositorio4 de Nova, por tanto todos los que utilicen JAVA como lenguaje de programación, algunos de los cuales se mencionaron con anterioridad, podrían incluir vulnerabilidades en el repositorio si no se auditan con antelación.

Nova, la distribución cubana de GNU/Linux, cuenta con la herramienta Auditoría de Código Fuente (ACF), la cual se utiliza para encontrar fallas de seguridad en el código fuente de cualquier aplicación o biblioteca que esté o se agregue a su repositorio; pero hasta ahora, ACF no soporta la revisión de código fuente JAVA

2 HTML: Hypertext Transfer Protocol en inglés y en español Protocolo de Transferencia de Hipertexto, este es un estándar que sirve de referencia para la elaboración de páginas web en sus diferentes versiones, define una estructura básica y un código (denominado código HTML) para la definición de contenido de una página web, como texto, imágenes y videos.

3 La migración de un sistema de información tiene por finalidad su traslado a un nuevo ambiente operativo, conservando su funcionalidad y datos originales.

4 Repositorio de GNU/Linux: un repositorio de GNU/Linux es una colección de paquetes de programas de una distribución de Linux específica que generalmente contiene archivos binarios pre-compilados que pueden ser descargados e instalados por los usuarios de la distribución correspondiente. Es posible también encontrar paquetes de código fuente.

(15)

lo que conllevaría a la inclusión de vulnerabilidades en el repositorio al no poder dicha herramienta auditar las aplicaciones desarrolladas en JAVA que se pretendan incorporar en dicho repositorio.

Partiendo de esta situación se plantea el siguiente problema de la investigación: ¿Cómo detectar vulnerabilidades en código fuente JAVA en el repositorio de Nova haciendo uso de la herramienta ACF?

Se trazó como objeto de estudio el proceso de detección de vulnerabilidades en código fuente.

Se define como objetivo general: Desarrollar un módulo que permita a la herramienta ACF la revisión de código fuente JAVA en el repositorio de Nova.

Para darle cumplimiento al objetivo general planteado, se han proyectado los siguientes objetivos específicos:

1. Analizar las herramientas de auditoría de código JAVA existentes, enfocándose en las más utilizadas actualmente.

2. Diseñar un módulo para la herramienta ACF que permita la detección de vulnerabilidades en el código fuente JAVA.

3. Implementar las funcionalidades del módulo para la herramienta ACF.

4. Realizar pruebas funcionales al módulo implementado para la herramienta ACF.

Se define como campo de acción el código fuente JAVA y como idea a defender que un módulo para la detección de vulnerabilidades en el código fuente JAVA disminuirá la inclusión de vulnerabilidades en el repositorio de Nova.

Para dar cumplimiento al objetivo se definieron las siguientes tareas de investigación:

• Revisión de bibliografía asociada a las herramientas de auditoría de código JAVA.

• Identificación de los requisitos funcionales y no funcionales para el módulo a desarrollar.

• Análisis de la arquitectura de ACF.

• Diseño del módulo acoplado a la arquitectura de ACF.

• Codificación de las funcionalidades definidas.

• Diseño de casos de prueba a las funcionalidades implementadas.

(16)

• Ejecución de los casos de prueba a las funcionalidades implementadas.

Los resultados esperados son que la herramienta ACF sea capaz de analizar y detectar vulnerabilidades en el código fuente JAVA.

Los métodos científicos utilizados en el proceso investigativo fueron el análisis histórico-lógico, el inductivo-deductivo y la modelación. El análisis histórico-lógico es empleado con el objetivo de verificar cómo evolucionan teóricamente las aplicaciones que realizan análisis de código fuente y de este modo poder realizar una selección de las técnicas, las herramientas y los algoritmos que se van a utilizar para desarrollar el módulo para la herramienta ACF. Por otra parte, el método inductivo-deductivo permite llegar a proposiciones generales a partir de los hechos que conforman la teoría, o a partir de dichas teorías arribar a conclusiones sobre casos particulares que se llevaron a la práctica. En la investigación es usado este método para, a partir del análisis de las herramientas existentes que realizan este proceso de detección de vulnerabilidades, seleccionar las características que va a poseer el módulo para la herramienta ACF de forma tal que realice el análisis de código fuente JAVA correctamente. El método modelación es utilizado para confeccionar los diagramas correspondientes a la representación de la propuesta de solución.

Los métodos empíricos utilizados en el proceso investigativo fueron el análisis documental y la tormenta de ideas. El análisis documental es empleado para la revisión de la literatura necesaria durante la investigación sobre el proceso de detección de vulnerabilidades en el lenguaje JAVA. El método tormenta de ideas es utilizado para el levantamiento de requisitos, así como para la determinación de las restricciones de software e implementación que deben tenerse en cuenta en el proceso de desarrollo.

El presente documento se encuentra estructurado de la forma siguiente:

Capítulo 1. Fundamentación teórica. En este capítulo se define el concepto de herramientas Lint, se realiza un profundo análisis de las principales características de cada herramienta encontrada. Se define el concepto de vulnerabilidad, así como su clasificación. También se realiza un análisis de las principales vulnerabilidades que presenta el lenguaje JAVA, dentro de las que se destacan, denegación de servicio, obtención de información, ejecución de código arbitrario y obtención de permisos. Además se realiza un

(17)

estudio de las herramientas y tecnologías que van ser utilizadas para el desarrollo de la solución y sus principales características, así como la justificación del por qué fueron escogidas. Se selecciona la metodología de desarrollo que va a guiar todo el proceso de construcción de un módulo para la herramienta ACF que detecte vulnerabilidades en los ficheros de código fuente JAVA.

Capítulo 2. Análisis y Diseño del Módulo de JAVA para ACF. Se explica detalladamente la propuesta de solución mediante una imagen que muestra las relaciones entre los principales conceptos del sistema. Se realiza la especificación de requisitos funcionales y no funcionales, así como el diagrama de casos de uso y su descripción. Se explican los patrones de diseño y arquitectura que se utilizaron y el momento en que fueron empleados. Se presenta el diagrama de clases del diseño que describe la estructura de un sistema mostrando sus clases y sus relaciones con las demás. Se expone el diagrama de secuencia que muestra gráficamente las interacciones del actor y de las operaciones que dan origen.

Capítulo 3. Implementación y Prueba. Comprende la explicación de los estándares de codificación utilizados en el desarrollo de la solución propuesta, así como el diagrama de componentes que apoya el proceso de implementación. Se explican los distintos tipos de pruebas que se van a utilizar para comprobar el correcto funcionamiento de la solución. Se muestran los resultados de las pruebas y el impacto social de la investigación.

(18)

Capítulo 1. Fundamentación Teórica

Introducción

En el presente capítulo se definen los principales conceptos asociados al tema investigativo dígase el concepto de vulnerabilidad, sus clasificaciones y las vulnerabilidades presentes en el lenguaje JAVA.

También se realiza un análisis de las herramientas que existen y que se utilizan en la detección de vulnerabilidades en el código fuente JAVA. Se realizan las clasificaciones de las vulnerabilidades que se desean detectar a través del estándar Common Vulnerability Scoring System (CVSS). También se lleva a cabo un estudio que incluye las tecnologías actuales para el desarrollo de software y las principales herramientas que serán utilizadas para la implementación de la solución.

1.1 Definiciones asociadas al tema investigativo 1.1.1 Concepto de Vulnerabilidad

Las vulnerabilidades son puntos débiles del software que permiten que un atacante comprometa la integridad, disponibilidad o confidencialidad del mismo. Algunas de las vulnerabilidades más severas permiten que los atacantes ejecuten código arbitrario, denominadas vulnerabilidades de seguridad, en un sistema comprometido (3). Las vulnerabilidades de los Sistemas Informáticos (SI) se pueden agrupar en función de:

Diseño

• Debilidad en el diseño de protocolos utilizados en las redes.

• Políticas de seguridad, deficientes e inexistentes.

Implementación

• Errores de programación.

• Existencia de “puertas traseras” en los sistemas informáticos.

• Descuido de los fabricantes.

Uso

(19)

• Configuración inadecuada de los sistemas informáticos.

• Desconocimiento y falta de sensibilización de los usuarios y de los responsables de informática.

• Disponibilidad de herramientas que facilitan los ataques.

• Limitación gubernamental de tecnologías de seguridad.

1.1.2 Clasificación de las vulnerabilidades Vulnerabilidades de condición de carrera

La condición de carrera se da principalmente cuando varios procesos acceden al mismo tiempo a un recurso compartido, por ejemplo una variable, cambiando su estado y obteniendo de esta forma un valor no esperado de la misma (4).

Vulnerabilidades de error de formato de cadena

La principal causa de los errores de cadena de formato es aceptar sin validar la entrada de datos proporcionada por el usuario. Es un error de programación y el lenguaje más afectado es C/C++. Un ataque puede conducir de manera inmediata a la ejecución de código arbitrario y a revelación de información (5).

Vulnerabilidades de Inyección SQL5

Una inyección SQL se produce cuando, de alguna manera, se inserta o "inyecta" código SQL invasor dentro del código SQL programado, a fin de alterar el funcionamiento normal del programa y lograr así que se ejecute la porción de código "invasor" incrustado, en la base de datos (6).

Vulnerabilidades de denegación del servicio

La denegación de servicio provoca que un servicio o recurso sea inaccesible a los usuarios legítimos.

Normalmente provoca la pérdida de la conectividad de la red por el consumo del ancho de banda de la víctima o sobrecarga de los recursos informáticos del sistema (7). A continuación se presenta una tabla con seis ejemplos de vulnerabilidades de JAVA que provocan denegación de servicios.

Identificación Lugar donde radica Clasificación Denegación de Servicio Forma de

5 SQL: el lenguaje de consulta estructurado o SQL (por sus siglas en inglés Structured Query Language) es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en ellas.

(20)

Explotación CVE-2012-1719 CORBA (Common

Object Request Broker Architecture)

Moderada Denegación parcial del servicio. Forma local

CVE-2012-1713 Administrador de fuentes.

Crítica Denegación de servicio parcial en la máquina virtual de JAVA.

Explotable remotamente CVE-2012-1716 Componente Swing Crítica Denegación parcial del servicio o

saltar las restricciones de la sandbox6 de JAVA.

Explotable remotamente

CVE-2012-1718 Lista de Certificados Revocados (CRL, Certificate Revocation Lists)

Moderada Denegación de servicio parcial. Forma local

CVE-2012-1723 y CVE-2012- 1725

JAVA HotSpot Virtual Machine

Crítica Una denegación de servicio en la máquina virtual de JAVA, saltar las restricciones de su sandbox o potencialmente ejecutar código arbitrario a través de una aplicación JAVA especialmente manipulada.

Explotable remotamente

CVE-2012-1726 Función

java.lang.invoke.Meth odHandles.Lookup

Importante No concede correctamente los modos de acceso. Lo que podría permitir a una aplicación JAVA no verificada saltar las restricciones de seguridad impuestas por la sandbox.

Explotable Remotamente

Tabla 1. Ejemplo de vulnerabilidades de JAVA que conllevan a una denegación de servicios (7).

6 Sandbox: el aislamiento de procesos (del inglés sandbox) es un mecanismo para ejecutar programas con seguridad y de manera separada. A menudo se utiliza para ejecutar código nuevo, o software de dudosa confiabilidad proveniente de terceros.

(21)

Vulnerabilidades de ventanas engañosas (Windows Spoofing).

Las ventanas engañosas son aquellas que dicen que eres el ganador de tal o cual evento, lo cual es mentira y lo único que quieren es que des información (8). Hay otro tipo de ventanas que, si las sigues, obtienen datos del ordenador para luego realizar un ataque.

Exploit 0-day

Esta vulnerabilidad afecta a todos aquellos usuarios que posean la versión 7 de JAVA. Ya existe en circulación un malware7 que aprovecha esta vulnerabilidad y permite infectar a aquellos usuarios que ingresen a un sitio web con un applet8 malicioso (9).

Desde el laboratorio de ESET Latinoamérica9 se realizó un análisis sobre el mencionado exploit y a partir de este estudio es importante destacar algunos aspectos para entender su funcionamiento. Los applets generalmente se ejecutan en el entorno de un sitio web y proveen funcionalidades diferentes, agregando en muchos casos, dinamismo al sitio web. El código de un applet en un sitio web es como el siguiente:

Como se observa en la imagen anterior, el código HTML del sitio web carga un archivo jar10, que en el ejemplo responde al nombre de Exploit.jar, el cual se ejecuta en el entorno del applet, aquí es donde yace la vulnerabilidad. JAVA permite la ejecución de código del tipo applet pero lo hace con permisos

7 Malware: el término malware es muy utilizado por profesionales de la informática para referirse a una variedad de software hostil, intrusivo o molesto.

8 Applet: los applets son programas hechos en JAVA que se coloca en un servidor web y se asocia con una etiqueta <applets> en una página HTML.

9 ESET: es una compañía de seguridad informática establecida en Bratislava, Eslovaquia.

10 Un archivo jar (por sus siglas en inglés, Java Archive): es un tipo de archivo que permite ejecutar aplicaciones escritas en el lenguaje JAVA.

Ilustración 2. Ejemplo de código de un applet.

(22)

restringidos. Esta vulnerabilidad, en términos generales, permite elevar el nivel de permisos y ejecutar código arbitrario sobre el sistema de la víctima. De esa forma, si el usuario ingresa a un sitio web que contiene un applet malicioso, su sistema puede ser comprometido. Vale aclarar que la carga del applet es totalmente legítima, es el propio archivo jar el que manipula la máquina virtual de JAVA (JVM) y salta las protecciones correspondientes para ejecutar el código arbitrario (10).

JAVA/Exploit.Bytverify. Vulnerabilidad en JAVA Características generales del Exploit.Bytverify:

Nombre: JAVA/Exploit.Bytverify

Nombre Nod32: JAVA/Exploit.Bytverify Tipo: Caballo de Troya11

Alias: Trojan.ByteVerify, Exploit-ByteVerify, Exploit.Java.Bytverify, JAVA_BYTVERIFY.A Fecha de actualización: 2/septiembre/2004

Plataforma: Windows 32-bit Tamaño: variable

Se trata de un caballo de Troya que explota una vulnerabilidad descrita por Microsoft en el boletín MS03- 011 (abril de 2003) y que permite a un sitio malicioso ejecutar código en los equipos vulnerables. Un fallo en las versiones 3809 y anteriores de la JVM de Microsoft, permite, por un error en el componente ByteCode Verifier, que sitios o usuarios maliciosos, lo utilicen para ejecutar código en forma arbitraria en la máquina de la víctima, saltándose las restricciones impuestas a todo código JAVA (11).

El código está incluido en un applet de JAVA, o puede ser descargado por un troyano, de modo que la computadora del usuario es afectada cuando ello ocurre. Esto también puede explotarse a través de la apertura de un correo electrónico con formato HTML.

Cuando un applet malicioso se ejecuta, puede realizar las siguientes acciones:

1. Modificar los permisos de ejecución para su propio código.

2. Abrir determinadas páginas web para obtener datos de configuración, con los que puede modificar

11 Caballo de Troya: en informática, se denomina 'caballo de Troya' a un virus informático que se presenta al usuario como un programa aparentemente legítimo e inofensivo, pero que, al ejecutarlo, le brinda a un atacante acceso remoto al equipo infectado.

(23)

la página de inicio y las opciones de búsqueda del Internet Explorer, además del archivo HOST12 de Windows, para redireccionar determinados sitios a otros proporcionados por el atacante.

3. Agregar enlaces a la lista de favoritos, generalmente relacionados con sitios indebidos.

4. Crear archivos HTML o scripts13 locales, que permiten ejecutar otras acciones, incluso la descarga de otros códigos malignos.

La notificación de una infección con este troyano, no significa necesariamente que la máquina ya esté infectada, sino que el código capaz de hacer todo lo indicado antes está incluido en algún applet descargado (11).

Los applets suelen distribuirse en archivos comprimidos, los cuáles son abiertos en tiempo de ejecución. La eliminación del código significa borrar todo el archivo comprimido.

1.2 Análisis de las principales vulnerabilidades del lenguaje JAVA

Las vulnerabilidades en JAVA no son un tema nuevo puesto que han estado siempre presente pero con dos diferencias importantes respecto a las actuales: la plataforma recién comenzaba a popularizarse y Sun Microsystems tenía una capacidad de respuesta muy buena para corregir las vulnerabilidades reportadas, sin embargo es de esperarse que al volverse famoso sería blanco de inherentes ataques por lo tanto la motivación por encontrar nuevas vulnerabilidades aumenta.

Cada año se detectan nuevas vulnerabilidades, pero coincidentemente desde el año 2010 en que Oracle14 compró a Sun Microsystems todo cambió. El número de vulnerabilidades en JAVA ha incrementado su búsqueda no sólo por parte de los investigadores sino también de aquellos que buscan una oportunidad con fines de lucro, utilizando una peligrosa combinación: Internet y la capacidad de JAVA de ejecutarse en

12 El término HOST ("anfitrión", en español): es usado en informática para referirse a las computadoras conectadas a una red, que proveen y utilizan servicios de ella.

13 En informática un script, archivo de órdenes, archivo de procesamiento por lotes o guión: es un programa usualmente simple, que por lo regular se almacena en un archivo de texto plano. El uso habitual de los scripts es realizar diversas tareas como combinar componentes, interactuar con el sistema operativo o con el usuario. Por este uso es frecuente que los shells sean a la vez intérpretes de este tipo de programas.

14 Oracle Database: es un sistema de gestión de base de datos objeto-relacional (u ORDBMS por el acrónimo en inglés de Object-Relational Data Base Management System), desarrollado por Oracle Corporation.

(24)

un navegador (12).

Hay quienes se han dado la tarea de informar cada vez que ocurre una nueva vulnerabilidad de día 0 (zero-day) o los detalles de las vulnerabilidades encontradas. A continuación se muestra en una gráfica las cantidades de vulnerabilidades que se han encontrado en la plataforma JAVA desde el 2001 hasta el 2013, donde se evidencia el aumento considerable en los últimos años, así como una segunda gráfica donde se puede observar las cantidades de vulnerabilidades reportadas por tipo en donde existen cinco tipos con cantidades mayores a quince, lo que demuestra la creciente incertidumbre a la que se enfrenta el lenguaje JAVA en la actualidad.

Ilustración 3. Cantidad de vulnerabilidades de JAVA reportadas en los últimos años (13).

Ilustración 4. Cantidad de vulnerabilidades de JAVA por tipo reportadas (14).

(25)

1.2.1 Applets de JAVA

Cuando un usuario entra a una página con un applet asociado, el applet se descarga junto con la página y una vez descargado, en el navegador del usuario se ejecuta siempre y cuando el navegador tenga la configuración necesaria para permitirlo (15). Es así donde el applet, si fue programado para explotar una vulnerabilidad, se ejecuta y arruina la navegación en Internet.

En condiciones normales un applet sigue un estricto control de seguridad, pues no permite la ejecución de código nativo15 en la computadora del usuario, ni puede conectarse a un servidor diferente a aquel de donde fue descargado. El problema radica cuando un programador de applet descubre la forma de burlar esos controles.

El navegador que carga y ejecuta el applet se conoce en términos genéricos como el "contenedor" de los applets. El kit de desarrollo de software para JAVA Standard Edition 7 (1.7.1 versión más actual, puesta en marcha el 18 de octubre de 2011) incluye un contenedor de applets, llamado appletviewer, para probar los applets antes de incrustarlos en una página web (16).

Ventajas de los applets

• Son multiplataforma (funcionan en Linux, Windows, OS X16 y en cualquier sistema operativo para el cual exista una JVM).

• Es compatible con la mayoría de los navegadores web.

• Puede ser almacenado en la memoria caché de la mayoría de los navegadores web, de modo que se cargará rápidamente cuando se vuelva a cargar la página web, aunque puede quedar atascado en la caché, causando problemas cuando se publican nuevas versiones.

• Puede tener acceso completo a la máquina en la que se está ejecutando, si el usuario lo permite.

• Puede ejecutarse a velocidades comparables a las de otros lenguajes compilados, como C++

(dependiendo de la versión de la JVM).

Desventajas de los applets

15 Código nativo: se usa como seudónimo de lenguaje de máquina. Este puede ser creado directamente para microcontroladores extremadamente sencillos o código fuente ya compilado, que puede ser interpretado por la máquina.

16 OS X, antes llamado Mac OS X, es un entorno operativo basado en Unix, desarrollado, comercializado y vendido por Apple Inc.

(26)

Requiere el plug-in17 de JAVA, que no está disponible por omisión en todos los navegadores web.

• No puede iniciar la ejecución hasta que la JVM esté en funcionamiento y esto puede tomar tiempo la primera vez que se ejecuta un applet.

• Si no está firmado como confiable, tiene un acceso limitado al sistema del usuario - en particular no tiene acceso directo al disco duro del cliente o al portapapeles.

• Puede tener vulnerabilidades que permitan ejecutar código malicioso.

1.2.2 Vulnerabilidades de JAVA.

A continuación se presenta un listado de vulnerabilidades encontradas en sitios web atacados en los últimos 6 meses del 2014 y así poder determinar cuáles son las vulnerabilidades más explotadas por los ciberdelincuentes18.

Vulnerabilidad Tecnología CVE-2013-2423 JAVA CVE-2012-1723 JAVA CVE-2012-0159 Win32 CVE-2012-0507 JAVA CVE-2011-3402 Adobe CVE-2013-0422 JAVA CVE-2012-0158 Active X CVE-2012-4681 JAVA CVE-2012-0003 Win32 CVE-2007-0071 Adobe

Tabla 2. Listado de vulnerabilidades más explotadas y la tecnología donde se encuentran (17).

Al analizar esta tabla sorprende que dentro de las 10 vulnerabilidades más explotadas se encuentra una que fue reportada en el año 2007 (CVE-2007-0071). Esta permite que sobre la máquina del usuario se

17 Plug-in: es un módulo de hardware o software que añade una característica o un servicio específico a un sistema más grande.

18 Ciberdelincuentes: son personas que realizan actividades delictivas en Internet como robar información, acceder a redes privadas, estafas y todo lo que tiene que ver con los delitos e ilegalidad.

(27)

ejecuten códigos maliciosos a través de la ejecución de un archivo tipo SWF19 diseñado para generar un desbordamiento de buffer (17).

La vulnerabilidad CVE-2013-2423, es la más reciente de las vulnerabilidades descubiertas por lo cual tiene sentido que sea la más explotada. Aprovecha una vulnerabilidad en el JAVA Runtime Environment (JRE) asociado a Oracle JAVA SE 7 Update 17 y versiones anteriores (18). La actualización de seguridad de esta vulnerabilidad fue lanzada por Oracle en abril del 2013.

Otra de las vulnerabilidades más utilizadas y que también está asociada con JAVA es la CVE-2012-1723, que afecta el JRE que está asociado con la versión Oracle JAVA SE 7 Update 4 y las versiones anteriores (19). Particularmente esta vulnerabilidad puede afectar la confidencialidad, integridad y disponibilidad de los datos que se encuentren en la máquina afectada. Para esta vulnerabilidad está disponible la actualización de seguridad desde junio del año 2014.

En el caso de la vulnerabilidad CVE-2012-0159 está asociada a Sistemas Operativos Microsoft Windows XP SP2 y SP3, Windows Vista SP2 y algunas versiones de Windows Server y del paquete Office 2003, 2007 y 2010 (20). Para esta vulnerabilidad Microsoft en sus boletines de seguridad de mayo y junio del 2012 puso a disposición de los usuarios las actualizaciones necesarias para corregirla.

La vulnerabilidad CVE-2012-0507 también afecta Oracle JAVA SE 7 pero esta vez solamente a las asociadas a la actualización 2 o anteriores. Una característica de esta vulnerabilidad es que permite a los atacantes evitar las restricciones del sandbox de JAVA, además de colapsar la JVM (21). La actualización de seguridad está disponible desde febrero del 2012.

Dentro de las primeras 5 vulnerabilidades, se destaca la CVE-2011-3402, que está relacionada con el producto Adobe Photoshop y un plug-in para GIMP20. Esta vulnerabilidad puede ser aprovechada por un atacante para ejecutar código malicioso en la computadora de la víctima utilizando un archivo PSD21 alterado (22).

19 Archivo SWF: es un formato de archivo de gráficos vectoriales creado por la empresa Macromedia (actualmente Adobe Systems).

20 GIMP (GNU Image Manipulation Program): es un programa de edición de imágenes de fuente libre, licenciado bajo GNU GPL. Puede ser usado para editar imágenes de mapa de bits, como fotografías.

21 PSD, PDD: formato estándar de Photoshop con soporte de capas.

(28)

Las restantes cinco vulnerabilidades tienen comportamientos similares, que permiten a un atacante ejecutar código arbitrario en la máquina de la víctima, lo cual lo hace susceptible de ser infectado con algún tipo de código malicioso. Es importante destacar que para estas diez vulnerabilidades, actualmente existen actualizaciones de seguridad que las corrigen (23). Por lo cual es importante hacer énfasis en la importancia de mantener actualizadas las aplicaciones que se utilizan en la computadora, como medida de protección adicional al hecho de tener una solución de seguridad instalada.

1.3 Herramientas Lint

Originalmente Lint era el nombre de una herramienta de programación utilizada para detectar código sospechoso, confuso o incompatible entre distintas arquitecturas en programas escritos en C, es decir, errores de programación que escapan al habitual análisis sintáctico que hace el compilador (24). En la actualidad, se utiliza este término para designar a herramientas que realizan estas tareas de comprobación en cualquier lenguaje de programación. Las herramientas de tipo Lint generalmente funcionan realizando un análisis estático del código fuente.

Las construcciones sospechosas que se suelen buscar son usos de variables antes de ser inicializadas o creadas, condiciones que no varían bajo ninguna circunstancia (son siempre verdaderas o siempre falsas) y cálculos cuyos resultados probablemente caigan fuera del rango permitido por las variables utilizadas.

También se está empezando a incluir la detección de estas construcciones incorrectas en su lista de avisos (Warnings).

Las herramientas más avanzadas realizan cada vez más comprobaciones, como por ejemplo, que el código sea consistente entre distintos compiladores, o el soporte para incorporar anotaciones acerca del comportamiento esperado o las propiedades del código.

La primera versión de Lint (fuera de los laboratorios Bell Labs) apareció en la versión 7 (V7) del sistema operativo UNIX, en 1979. Formaba parte del compilador PCC (Portable C Compiler), que fue el segundo compilador de C incorporado a las máquinas PDP-1122. Su autor, Stephen C. Johnson, es también el

22 PDP-11: fue una computadora fabricada por la empresa Digital Equipment Corp. en las décadas de 1970 y 1980. Fue la primera minicomputadora en interconectar todos los elementos del sistema.

(29)

creador de yacc (Yet another compiler compiler) y del previamente mencionado PCC (25).

1.3.1 Análisis de las principales herramientas Lint

En este apartado se analizan las herramientas para el análisis de código fuente más extendidas. Haciendo una descripción inicial de su disponibilidad y los tipos de errores que detectan.

A continuación se muestra una tabla donde se realiza una comparación entre herramientas Lint que detectan errores en código JAVA, se tiene en cuenta como criterios de comparación sus características fundamentales y la plataforma en la que se ejecutan.

Nombre Plataforma Características Detección de vulnerabilidades de tipo DS23, ECA24 o Proceso L/E25.

Ant Multiplataforma Motor de ejecución de scripts similar a

“make” o “gnu make”. Sus ficheros de script son ficheros XML26 donde se definen los objetivos y el orden de los mismos. Se pueden establecer propiedades dentro del fichero de construcción, pasárselas como parámetros mediante la línea de comandos y usar las propiedades de sistema (26).

No

Jlint Multiplataforma Detecta los errores analizando ficheros compilados (.class) de JAVA. Puede detectar errores de sincronización de

No

23 DS: denegación de servicio.

24 ECA: ejecución de código arbitrario.

25 Proceso L/E: procesos de lectura y escritura sobre recursos críticos del sistema.

26 XML, siglas en inglés de eXtensible Markup Language ('lenguaje de marcas extensible'), es un lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C) utilizado para almacenar datos en forma legible.

(30)

hilos27, en la jerarquía de herencia y de valores o rangos de variables locales o campos (27).

AntiC Linux Los errores que puede detectar son de prioridad de operadores, en el cuerpo de las declaraciones y los relacionados con los tokens28 (27).

No

FindBugs Linux Se centra en el análisis de ficheros .class. Para ello hace uso de la librería BCEL29, que sirve para manipular este tipo de código.

Mediante dicho análisis se pretende encontrar patrones de error en las clases (28).

No

PMD Linux Intenta indagar posibles errores mediante la comprobación de reglas en los ficheros (29).

No

JTest Linux Incluye tecnología para la detección de errores de generación Unit, de análisis estático, de prueba de regresión.

No

Tabla 3. Comparación de las herramientas que realizan análisis de código JAVA.

1.3.2 Características comunes de las herramientas presentadas

Las herramientas que se han presentado anteriormente, corresponden a las alternativas más utilizadas para analizar código fuente, asegurando gran efectividad de detección ante vulnerabilidades tales como:

27 Sincronización de hilos: la sincronización fuerza a que la ejecución de los dos hilos sea mutuamente exclusiva en el tiempo.

28 Tokens: es una cadena de caracteres que tiene un significado coherente en cierto lenguaje de programación.

29 Librería BCEL: Byte Code Engineering Library, es una librería para analizar, manipular y crear archivos Java class. En nuestro contexto es una ayuda para parsear los archivos .class y obtener toda la información que necesitamos para la ejecución del bytecode en nuestra máquina virtual de JAVA.

(31)

desbordamientos de buffer, condiciones de carrera y problemas asociados a funciones de impresión con formato, reconocen patrones los cuales son posibles errores que pueden aparecer en tiempo de ejecución, código que no se puede ejecutar nunca porque no hay manera de llegar a él, código que puede ser optimizado, expresiones lógicas que puedan ser simplificadas y malos usos del lenguaje.

Ninguna de estas herramientas realizan búsquedas de vulnerabilidades asociadas a denegación de servicio, ni evitan la ejecución de código arbitrario. Tampoco verifican los procesos de lectura y escritura sobre recursos críticos del sistema, tales como los ficheros donde son almacenados los usuarios del sistema y sus respectivas contraseñas, ya que al poder leer o escribir en estos ficheros pueden ser creados usuarios ilegítimos en el sistema o alterar los permisos de los ya existentes. Por ello, el uso de las mismas, aunque sea efectivo en otras áreas no evitará enfrentarse a estas vulnerabilidades sin ser detectadas. Por lo que no se escoge ninguna de ellas como propuesta de solución, a pesar de esto el estudio de las mismas permitió un mejor entendimiento de las prácticas utilizadas en el proceso de detección de vulnerabilidades.

1.4 Métricas y clasificaciones de las vulnerabilidades a detectar

CVSS es una iniciativa pública concebida por la National Infraestructure Assurance Council (NIAC) de Estados Unidos (EE.UU), un grupo que provee de recomendaciones al Department of Homeland Security de los EE.UU. Entre las organizaciones que lo adoptaron tempranamente destacan Cisco, US National Institute of Standards and Technology (NIST), Qualys y Oracle. En la actualidad, el CVSS está bajo la custodia del Forum for International Response Teams (FIRST) (49).

Entre los beneficios que ofrece el CVSS están:

Puntuación estándar de vulnerabilidades: el CVSS es neutro desde el punto de vista de las aplicaciones, permitiendo que distintas organizaciones asignen una puntuación a sus vulnerabilidades a través de un único esquema.

Puntuación contextualizada: la puntuación asignada por una organización corresponde al riesgo que la vulnerabilidad representa para dicha organización.

(32)

Sistema abierto: el CVSS provee todos los detalles sobre los parámetros usados en la generación de cada puntuación permitiendo comprender tanto el razonamiento que sustenta una puntuación como el significado de diferencias entre puntuaciones.

Las puntuaciones asignadas por el CVSS se derivan de los tres grupos de métricas siguientes:

Base: este grupo representa las propiedades de una vulnerabilidad que son inmutables en el tiempo, específicamente: complejidad de acceso, vector de acceso y grado en que compromete la confidencialidad, integridad y disponibilidad del sistema.

Temporal: este grupo mide las propiedades de una vulnerabilidad que sí cambian en el tiempo, como por ejemplo la existencia de parches o código para su explotación.

Medio ambientales: este grupo mide las propiedades de una vulnerabilidad que son representativas de los ambientes de uso de las TIC como por ejemplo la prevalencia de sistemas afectados y pérdidas potenciales.

CVSS usa fórmulas sencillas y a partir de los grupos de métrica arriba enumerados arroja la puntuación final asociada a la vulnerabilidad.

De las métricas de base se deriva una puntuación de 0.0 a 10.0 basado en las respuestas a las siguientes preguntas:

Métrica de base:

1. Métricas de Explotabilidad

Vector de acceso Local

Remoto

Complejidad de ataque Baja

Alta

Nivel de autenticación requerida No requerida

(33)

Requerida

2. Métricas de Impacto

Impacto en la confidencialidad:

Ninguna Parcial Completa

Impacto en la integridad:

Ninguna Parcial Completa

Impacto en la disponibilidad:

Ninguna Parcial Completa

Mayor impacto en:

Confidencialidad Integridad Disponibilidad

Las métricas temporales modifican la puntuación base, reduciéndola hasta en un tercio dependiendo de las respuestas a las siguientes preguntas:

Métricas Temporales:

Disponibilidad del exploit No probada

Prototipo de ataque Existencia de exploit Alta

(34)

Tipo de solución disponible Solución oficial

Solución temporal

Solución de contingencia No disponible

Finalmente, las métricas medio ambientales modifican la puntuación obtenida y generan un valor final dependiendo de las respuestas a las siguientes preguntas:

Métricas medio ambientales:

Daño colateral potencial Ninguno

Bajo Medio Alto

Porcentaje de sistemas vulnerables Ninguno

Bajo Medio Alto

1.4.1 Resultado de la aplicación del estándar CVSS

En el Anexo 1 se muestra una tabla con las puntuaciones alcanzadas por las vulnerabilidades que se desean detectar. En la determinación de estas se tuvo en cuenta sólo las métricas de Base, ya que según la Guía de CVSS versión 2.0, con esta métrica es suficiente para una correcta identificación de las clasificaciones necesarias, se plantea que las demás son opcionales como se muestra en la siguiente imagen.

(35)

Para el cálculo de los puntajes se hizo uso de la siguiente ecuación definida por la CVSS:

BaseScore = round_to_1_decimal( ( ( 0.6*Impact ) +( 0.4 * Exploitability ) – 1.5 ) * f ( Impact ) ) Impact = 10.41 * ( 1 - ( 1-ConfImpact ) * ( 1 – IntegImpact ) * ( 1 – AvailImpact ) )

Exploitability = 20 * AccessVector *AccessComplexity *Authentication

Como resultado de la aplicación de este estándar, se obtuvo las siguientes clasificaciones:

Warning para las vulnerabilidades de tipo denegación de servicio y obtención de información.

Alert para las vulnerabilidades de tipo desbordamiento de buffer y obtención de privilegios.

Information para las vulnerabilidades de tipo Inyección SQL.

1.5 Metodología de desarrollo

El proceso de desarrollo de la herramienta ACF fue guiado por la metodología OpenUp por lo que se hace uso de esta para guiar el proceso de desarrollo. Además es la idónea para el trabajo de equipos pequeños con poco tiempo para la culminación del sistema, razones por las cuales se escoge esta metodología para el desarrollo del módulo.

OpenUp/Basic es un framework (marco de trabajo) de procesos de desarrollo de programas de código abierto, que con el tiempo espera cubrir un amplio conjunto de necesidades en el campo del desarrollo de programas. Permite un abordaje ágil en el análisis con solamente proveer un conjunto simplificado de contenidos, fundamentalmente relacionados con orientación, productos de trabajo, roles y tareas (31). Es

Ilustración 5. Métricas y fórmulas de CVSS.

(36)

un proceso interactivo de desarrollo de software simplificado, completo y extensible; para pequeños equipos de desarrollo que valoran los beneficios de la colaboración y los involucrados, con el resultado del proyecto por encima de formalidades innecesarias.

Fases de OpenUp:

Inicio

La fase de Inicio se trata de comprender el alcance y los objetivos del proyecto y obtener suficiente información para confirmar que el proyecto debe continuar. Se definen para el proyecto: el ámbito, los límites, el criterio de aceptación, los casos de uso críticos, una estimación inicial del coste y un boceto de la planificación.

Elaboración

En esta fase se realizan tareas de análisis del dominio y definición de la arquitectura del sistema. Se debe elaborar un plan de proyecto, estableciendo unos requisitos y una arquitectura estables. Por otro lado, el proceso de desarrollo, las herramientas, la infraestructura a utilizar y el entorno de desarrollo también se especifican en detalle en esta fase. Al final de la fase se debe tener una definición clara y precisa de los casos de uso, los actores, la arquitectura del sistema y un prototipo ejecutable de la misma.

La metodología propone como vistas de la arquitectura las siguientes:

Lógica: describe la estructura y el comportamiento de porciones arquitectónicamente significativos del sistema. Esto podría incluir la estructura de paquetes, interfaces críticas, clases y subsistemas importantes y las relaciones entre estos elementos. También incluye vistas físicas y lógicas de datos persistentes, si la persistencia se construirá en el sistema. Este es un subconjunto documentado del diseño.

Operacional: describe los nodos físicos del sistema y de los procesos, hilos y los componentes que se ejecutan en los nodos físicos. Este punto de vista no es necesario si el sistema se ejecuta en un proceso único.

Caso de uso: una lista o diagrama de los casos de uso que contienen.

Construcción

(37)

Esta fase está enfocada al diseño, implementación y prueba de las funcionalidades del sistema. El propósito de esta fase es completar el desarrollo del sistema basado en la arquitectura definida.

Transición

Su propósito es asegurar que el sistema es entregado a los usuarios y evalúan las funcionalidades y rendimiento.

El siguiente diagrama muestra la relación existente entre las distintas fases y el ciclo de vida de la metodología.

1.6 Lenguajes de Programación 1.6.1 Lenguaje C++

Se escoge como lenguaje de programación C++ ya que es el lenguaje que se utilizó para el desarrollo de la herramienta ACF, así como para el desarrollo de los módulos ya existentes, además se desea seguir los mismos estándares de codificación que posee ACF. Las principales características del Lenguaje C++ son:

1. Tiene un conjunto completo de instrucciones de control.

2. Permite la agrupación de instrucciones.

3. Incluye el concepto de puntero (variable que contiene la dirección de otra variable).

Ilustración 6. Relación entre las fases y el ciclo de vida de OpenUp.

(38)

4. Los argumentos de las funciones se transfieren por su valor.

5. Los procesos de Entrada y Salida no forman parte del lenguaje, sino que se proporciona a través de una biblioteca de funciones.

6. Permite la separación de un programa en módulos que admiten compilación independiente.

1.6.2 Lenguaje XML

Se escoge el lenguaje XML para la creación de un diccionario que va a contener las vulnerabilidades, su tipo y el mensaje con la descripción, esto en forma de árbol, ya que este lenguaje se considera un estándar para el intercambio de información estructurada, además permite definir etiquetas personalizadas para descripción y organización de datos. La utilización de este permitió centralizar las vulnerabilidades en una solo fichero, de forma tal que para añadir una nueva vulnerabilidad no sea necesario modificar el código fuente del módulo a desarrollar, sino que con modificar el XML será suficiente para que el módulo realice la detección de las nuevas vulnerabilidades.

Una de las principales características de este lenguaje lo constitiye su cualidad de ser abierto, derivado del SGML30, optimizado para su uso en la Web y que permite describir el sentido o la semántica de los datos.

XML a diferencia del HTML, separa el contenido de la presentación. Es un Meta-Lenguaje31, que permite la definición de lenguajes concretos de representación de documentos (50).

1.7 Entorno de Desarrollo Integrado (IDE)

Un entorno de desarrollo integrado (IDE) es un programa compuesto por un conjunto de herramientas para que el programador las utilice. Puede dedicarse en exclusiva a un solo lenguaje de programación o bien, puede utilizarse para varios. El entorno de desarrollo es imprescindible en la producción de un software.

Para el desarrollo de la solución se propone la utilización del IDE Eclipse en su versión 3.8. Se escoge este ya que es el entorno de desarrollo integrado que más domina la autora, además que es el IDE idóneo para el trabajo con el lenguaje C++, definido como lenguaje a utilizar en el desarrollo de la propuesta de

30 SGML: Standar Generalizer Markup Lenguage en inglés y Estándar de Lenguaje de Etiquetado Generalizado en español. Es una norma que se aplica a todos los lenguajes de marcas, donde los más reconocidos son HTML y RTF.

31

(39)

solución. Mayoritariamente se utiliza para desarrollar lo que se conoce como "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores. Es una potente y completa plataforma de programación, desarrollo y compilación de elementos tan variados como sitios web, programas en C++ o aplicaciones JAVA. Integra herramientas y funciones necesarias para el trabajo, recogidas además en una atractiva interfaz que lo hace fácil y agradable de usar.

1.8 Herramienta Case32 Visual Paradigm.

Visual Paradigm es una herramienta UML (Unified Modeling Language) profesional que soporta el ciclo de vida completo del desarrollo de software: análisis y diseño Orientados a Objetos, construcción, pruebas y despliegue (33). El software de modelado UML ayuda a una más rápida construcción de aplicaciones.

Permite dibujar todos los tipos de diagramas de clases, código inverso y generar documentación.

Se selecciona esta herramienta ya que todos los diagramas del proceso de desarrollo de ACF en su versión actual están realizados en la misma.

1.9 Herramienta de documentación de código

Doxygen es un programa que analiza el código en busca de directivas en forma de comentarios y las transforma en documentación, ya sea HTML, LaTeX33 e incluso se puede crear una página de manual de Linux para visualizar con el comando "man"34. Esta acepta multitud de lenguajes como C/C++ o JAVA. La principal ventaja de esta herramienta es que las directivas no son más que comentarios de forma tal que no es necesario crear una documentación aparte, sino, simplemente, comentar el código.

32 Las herramientas CASE (Computer Aided Software Engineering, ingeniería asistida por computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero.

33 LaTeX: es un sistema de composición de textos, orientado a la creación de documentos escritos que presenten una alta calidad tipográfica. Por sus características y posibilidades, es usado de forma especialmente intensa en la generación de artículos y libros científicos que incluyen, entre otros elementos, expresiones matemáticas.

34 Man: muestra el manual del comando que se le indique.

(40)

Se escoge la misma en su versión 1.7.8 ya que esta es la herramienta de documentación de código que se utilizó para documentar el código de ACF.

Conclusiones Parciales

A lo largo de este capítulo han sido expuestos los principales puntos de interés relacionados con el concepto de vulnerabilidad y sus clasificaciones y el análisis de código fuente lo que permitió realizar un profundo análisis de las principales vulnerabilidades presentes en el lenguaje JAVA donde resaltan la denegación de servicio, ejecución de código arbitrario, obtención de información y el desbordamiento de buffer como las más utilizadas para explotar sistemas informáticos. Se realizó un estudio de las herramientas que realizan auditoría de código fuente y se concluyó que ninguna de ellas realiza una búsqueda completa de los tipos de vulnerabilidades presentes en el lenguaje JAVA.

El estudio del arte realizado permitió identificar la metodología de desarrollo de software y herramientas que se utilizarán en el desarrollo de la solución que se propone, teniendo como resultado las siguientes:

como metodología de desarrollo de software OpenUp, como lenguajes de programación C++ y XML, entorno de desarrollo Eclipse y como herramienta Case: Visual Paradigm.

Ilustración 7. Ejemplo de documentación de código usando Doxygen.

(41)

Capítulo 2. Análisis y Diseño del Módulo de JAVA para ACF

Introducción

En el presente capítulo se establecen las principales características y funcionalidades con que contará la solución ya sean requisitos funcionales o no funcionales. Se generan los diagramas correspondientes a las etapas de planificación y diseño que propone la metodología de desarrollo OpenUp. Además se describen los patrones de diseño y arquitectura que se utilizarán, así como el modelo de dominio del sistema y el diagrama de clases del diseño.

2.1 Propuesta de Solución

Actualmente ACF se encuentra en su versión 1.0. Esta realiza análisis de código fuente de los lenguajes Bash, C++, Perl y Python, además cuenta con un módulo llamado Cuba el cual se encarga de prevenir ataques políticos a través de ficheros.

Para la creación de la solución propuesta se tuvo en cuenta que ya existen cinco módulos, por lo que es necesario que el que se cree cumpla con los mismos estándares de codificación que los demás. Deberá realizar un análisis estático de código fuente, donde detecte funciones o clases que podrían conllevar a una de las vulnerabilidades descritas en el capítulo anterior. En el Anexo 5 se muestra una tabla con dichas funciones o clases y las vulnerabilidades a las que corresponden.

El módulo debe ser capaz, además de detectar dichas vulnerabilidades, de generar un reporte detallado con la dirección local donde se encuentran los ficheros que presenten vulnerabilidades, así como el daño que pueden ocasionar, estas serán clasificadas en Warning, Alert o Information.

En la siguiente imagen se muestra cómo será el proceso de detectar vulnerabilidades. Este comienza cuando el usuario inserta en los campos de la interfaz de la herramienta los ficheros de código que desea auditar y la dirección donde se generará el reporte. Después de insertados los datos ACF verifica la extensión de los ficheros, si son .java entonces activa el módulo de JAVA, el cual analiza los ficheros y genera el reporte. ACF obtiene el reporte generado y lo muestra al usuario, culminando de esta forma el

(42)

proceso de detección.

2.3 Requisitos funcionales

Un requisito funcional define una función del software o sus componentes; pueden ser cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que se supone, un sistema debe cumplir (34).

Requisitos funcionales:

RF1 Definir extensiones de los archivos del código fuente JAVA para conformar la información que debe brindar el módulo.

RF2 Detectar vulnerabilidades que conlleven a una denegación de servicio.

RF3 Detectar vulnerabilidades de ejecución de código.

RF4 Detectar vulnerabilidades correspondiente a bypass something35. RF5 Detectar vulnerabilidades en el uso de funciones de manejo de buffer.

RF6 Detectar vulnerabilidades que impliquen la obtención de información.

RF7 Detectar vulnerabilidades que impliquen la obtención de privilegios.

35 Bypass something: se refiere a la omisión de parámetros y objetos.

Ilustración 8. Ejemplo de cómo sería el funcionamiento de la solución propuesta.

(43)

RF8 Detectar vulnerabilidades que impliquen la corrupción de memoria.

RF9 Generar reporte de vulnerabilidades encontradas.

2.4 Requisitos no funcionales.

Un requisito no funcional especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Sirven de apoyo a los requisitos funcionales (36).

Usabilidad

El módulo deberá presentar facilidades al usuario para el manejo de la información, se pretende acoplar a la vista descriptiva, sencilla y fácil de usar que posee ACF para la realización de todas las operaciones, con el objetivo de propiciar un buen entendimiento a los usuarios finales.

Restricciones de implementación:

1. Utilizar como lenguaje de programación C++.

2. El estilo de programación debe ser el estándar de codificación del lenguaje C++.

3. Uso de la herramienta de documentación de código Doxygen en su versión 1.7.8.

Restricciones de software:

1. Es necesario instalar el sistema operativo Nova 2013 ya la herramienta ACF está diseñada para que funcione correctamente sobre este sistema operativo.

Compatibilidad

El módulo a desarrollar deberá integrarse con el resto de la aplicación y analizar todos los ficheros de extensión .java que le proporcione la herramienta, además deberá ser capaz de generar un reporte de las vulnerabilidades encontradas.

2.5 Definición de actores y casos de uso del sistema.

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores (37).

Referencias

Documento similar

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

o Si dispone en su establecimiento de alguna silla de ruedas Jazz S50 o 708D cuyo nº de serie figura en el anexo 1 de esta nota informativa, consulte la nota de aviso de la