• Author / Uploaded
• Jesson Ember Bejarano Mosquera

Citation preview

22-6-2020

LABORATORIO Laboratorio Seguridad en el Software

CARLOS ALBERTO HERNANDEZ RINCON JESSON EMBER BEJARANO MOSQUERA MAESTRÍA EN INGENIERÍA DE SOFTWARE Y SISTEMAS INFORMÁTICOS

Laboratorio: Auditoría de código de una aplicación OBJETIVOS » Análisis del código fuente de una aplicación para poder determinar el nivel de riesgo de las vulnerabilidades encontradas. » Conocer el tipo de defectos de seguridad que se pueden cometer en lenguajes como C y Java. » Prepararse para poder analizar el código en base al conocimiento de los defectos de programación que se pueden cometer. » Proporcionar información relevante sobre cuáles serían las recomendaciones de solución más eficaces para mitigar los efectos de la vulnerabilidad encontrada en durante la auditoría del código fuente de una aplicación.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

INTRODUCCION El análisis estático de software es un tipo de análisis de software que se realiza sin ejecutar el programa (el análisis realizado sobre los programas en ejecución se conoce como análisis dinámico de software). En la mayoría de los casos, el análisis se realiza en alguna versión del código fuente y en otros casos se realiza en el código objeto. En el desarrollado de la siguiente actividad analizaremos los tipos de vulnerabilidades y amenazas que se dan sobre el código examinado con la herramienta Fortity. Una muy importante fuente de información de seguridad de aplicaciones en general es el CWE (Common Weakness Enumeration), una comunidad perteneciente al MIT, que como su nombre lo indica se dedica a enumerar y clasificar los tipos de debilidades y vulnerabilidades de las aplicaciones, incluyendo por supuesto a las aplicaciones web.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

Resultado del análisis de cada una de las 15 vulnerabilidades detectadas por la herramienta 1. Buffer Overflow (Input Validation and Representation, Data Flow)cli_console.c: Critica. Codigo CWE: 20

1.1 Diagrama

1. 2 Codigo Fuente y explicación

La función readline_thread () en cli_console.c está escribiendo fuera de los límites de memoria asignado como se puede ver en la línea 502, esto podría ocasionar daños en los datos, bloqueos en el programa o ejecución de código malicioso.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

1.3

Recomendación

Se recomienda no usuar funciones gets() y evitar el uso de funciones no seguras como strcpy (), remplace las funciones limitadas con funciones de WinAPI. Cuando manipule memoria recuerde que las vulnerabilidades de desbordamiento de bufer generalmente ocurren en código que: -

2.

Basado en códigos externos para controlar su comportamiento Dependencia de datos que aplican fuera del alcance del código Es complejo de que el programado lo identifique para controlar su comportamiento. Nunca confiar en propiedad externa para proporcionar información sobre control correcto de una operación de memoria. Limite la complejidad en la manipulación de memoria, documente claramente las verificaciones que realiza. Cuando los Datos son muy grandes trúnquelos y sígalos procesando No confié en herramientas de control externo de memoria

Format String (Input Validation and Representation, Data Flow)ice_session.c: Critico Codigo CWE: 134

2.1 Diagrama

Un posible atacante podría controlar el argumento en una cadena de formato para snprintf () en ice_session.c línea 364 provocando un ataque parecido al desbordamiento de buffer.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

2.2 Recomendación De ser posible, se debe pasar las cadenas de formato estático a funciones que acepten un argumento de cadena de formato. Si las cadenas de formato deben construirse dinámicamente, defina un conjunto de cadenas de formato válidas y realice selecciones de este conjunto seguro. Finalmente, siempre verifique que el número de directivas de formato en la cadena de formato seleccionada corresponda al número de argumentos a formatear.

3. Password Management: Empty Password Structural): http_client.c_270. CWE:258

(Security

Features,

3.1 Diagrama

3.2 Código Fuente y explicación No es Recomendable asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se usa para autenticarse con éxito en otro sistema, entonces la seguridad de la cuenta correspondiente se ve comprometida porque acepta una contraseña vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, puede confundir a cualquier persona que no esté familiarizada con el código y potencialmente causar problemas en rutas de flujo de control inesperadas. 3.3 Recomendación Leer siempre los valores de contraseña almacenados de recursos externos encriptados y asignarles valores significativos a las variables de contraseña. Asegurar que los recursos confidenciales nunca estén protegidos con contraseñas vacías o nulas.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

4. Privacy Violation (Security Features, Data Flow)-log_writer_stdout.cCritic0. CWE:359

4.1 Diagrama

4.2 Codigo Fuente y explicación

La función pj_log_write () en log_writer_stdout.c hace mal uso de la información confidencial en la línea 51, el programa podría comprometer la privacidad del usuario. Las violaciones de privacidad ocurren cuando: 1. La información privada del usuario ingresa al programa. 2. Los datos se escriben en una ubicación externa, como la consola, el sistema de archivos o la red. En este caso, los datos se pasan a printf () en log_writer_stdout.c en la línea 51

4.3 Recomendación

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

Siempre se debe garantizar la privacidad de información del usuario, esto se logra limpiando cualquier información privada antes de publicar un programa. La mejor política con respecto a los datos privados en minimizar su exposición.

5. Weak Encryption: Insecure Initialization Vector (Security Features, Structural:aes_gcm_ossl.c: Alta. CWE: 329

5.1 Diagrama

5.2 Código Fuente y explicación

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

Los vectores de inicialización deben crearse utilizando un generador de números aleatorios criptográficos. Los vectores de inicialización (IV) deberán crearse utilizando un generador de números aleatorios criptográficos. No hacer uso de un aleatorio hace el texto predecible y susceptible a un ataque. Se debe usar un vector de inicialización (IV) de longitud suficiente con bytes de una fuente de datos aleatorios adecuada. Por ejemplo unsigned char * iv; int fd = open("/dev/random", O_RDONLY); if (fd != -1) { (void) read(fd, (void *)&iv, ivlength); (void) close(fd); } EVP_EncryptInit_ex(&ctx, EVP_idea_cbc(), NULL, key, iv);

6 Buffer Overflow: Format String (Input Validation and Representation, Buffer json.cpp: Alta. CWE:134 6.1 Diagrama

6.2 Código Fuente y explicación

En el argumento de cadena de formato para snprintf () en la línea 320 de json.cpp no limita adecuadamente la cantidad de datos que la función puede escribir, lo que permite TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

que el programa escriba fuera de los límites de la memoria asignada. Este comportamiento podría dañar los datos, bloquear el programa o provocar la ejecución de código malicioso. El desbordamiento de búfer es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben qué es una vulnerabilidad de desbordamiento de búfer, pero los ataques de desbordamiento de búfer contra aplicaciones heredadas y recientemente desarrolladas siguen siendo bastante comunes. Parte del problema se debe a la gran variedad de formas en que pueden ocurrir desbordamientos del búfer, y parte se debe a las técnicas propensas a errores que a menudo se usan para prevenirlos. En una explotación clásica de desbordamiento de búfer, el atacante envía datos a un programa, que almacena en un búfer de pila de tamaño reducido. El resultado es que la información en la pila de llamadas se sobrescribe, incluido el puntero de retorno de la función. Los datos establecen el valor del puntero de retorno para que cuando la función regrese, transfiera el control al código malicioso contenido en los datos del atacante. Aunque este tipo de desbordamiento de búfer en la pila sigue siendo común en algunas plataformas y en algunas comunidades de desarrollo, hay una variedad de otros tipos de desbordamiento de búfer, incluidos los desbordamientos del búfer del montón y los errores fuera de uno, entre otros. Hay una serie de excelentes libros que proporcionan información detallada sobre cómo A nivel de código, las vulnerabilidades de desbordamiento de búfer generalmente implican la violación de los supuestos de un programador. Muchas funciones de manipulación de memoria en C y C ++ no realizan la verificación de límites y pueden superar fácilmente los límites asignados de las memorias intermedias en las que operan. Incluso las funciones limitadas, como strncpy (), pueden causar vulnerabilidades cuando se usan incorrectamente. La combinación de manipulación de memoria y suposiciones erróneas sobre el tamaño o la composición de un dato es la causa principal de la mayoría de los desbordamientos del búfer. En este caso, una cadena de formato construida incorrectamente hace que el programa escriba más allá de los límites de la memoria asignada. 6.3 Recomendación

Aunque el uso cuidadoso de las funciones limitadas puede reducir en gran medida el riesgo de desbordamiento de búfer, esta migración no se puede realizar a ciegas y no llega lo suficientemente lejos por sí sola para garantizar la seguridad. Siempre que manipule memoria, especialmente cadenas, recuerde que las vulnerabilidades de desbordamiento de búfer generalmente ocurren en código que: - Se basa en datos externos para controlar su comportamiento. TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

- Depende de las propiedades de los datos que se aplican fuera del alcance inmediato del código. - Es tan complejo que un programador no puede predecir con precisión su comportamiento.

Además, considere los siguientes principios: - Nunca confíe en una fuente externa para proporcionar información de control correcta a una operación de memoria. - Nunca confíe en que las propiedades sobre los datos que manipula su programa se mantendrán en todo el programa. Datos de comprobación de cordura antes de operar en él. - Limite la complejidad de la manipulación de la memoria y el código de verificación de límites. Manténgalo simple y documente claramente las comprobaciones que realiza, los supuestos que prueba y cuál es el comportamiento esperado del programa en caso de que falle la validación de entrada. - Cuando los datos de entrada son demasiado grandes, tenga cuidado de truncar los datos y continuar procesándolos. El truncamiento puede cambiar el significado de la entrada

7. Format String (Input Validation Flow):os_core_unix.c: Alta. CWE:20

and

Representation,

Data

7.1 Diagrama

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

7. 2 Código Fuente y explicación

Un atacante puede tomar control de un argumento de cadena permitiendo un ataque muy parecido al desbordamiento de buffer. Las vulnerabilidades de cadena de formato se producen cuando: 1. Los datos ingresan a la aplicación desde una fuente no confiable. En este caso, los datos ingresan en gethostname () en sock_bsd.c en la línea 466. 2. Los datos se pasan como argumento de cadena de formato a una función como sprintf (), FormatMessageW () o syslog (). En este caso, los datos se pasan a snprintf () en os_core_unix.c en la línea 1184. 7.3 Recomendaciones Siempre que sea posible, pase cadenas de formato estático a funciones que acepten un argumento de cadena de formato. Si las cadenas de formato deben construirse dinámicamente, defina un conjunto de cadenas de formato válidas y realice selecciones de este conjunto seguro. Finalmente, siempre verifique que el número de directivas de formato en la cadena de formato seleccionada corresponda al número de argumentos a formatear.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

8 Buffer Overflow: Format String (Input Validation and Representation, Buffer): jbut_test.c: Alta. CWE: 134

8.1 Diagrama

8. 2 Código Fuente y explicación

El argumento de cadena de formato para sscanf () en jbuf_test.c línea 59 no limita adecuadamente la cantidad de datos que la función puede escribir, lo que permite que el programa escriba fuera de los límites de la memoria asignada. Este comportamiento podría dañar los datos, bloquear el programa o provocar la ejecución de código malicioso. El desbordamiento del búfer es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben qué es una vulnerabilidad de desbordamiento de búfer, pero los ataques de desbordamiento de búfer contra aplicaciones heredadas y recientemente desarrolladas siguen siendo bastante TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

comunes. Parte del problema se debe a la gran variedad de formas en que pueden ocurrir desbordamientos del búfer, y parte se debe a las técnicas propensas a errores que a menudo se usan para prevenirlos. En una explotación clásica de desbordamiento del búfer, el atacante envía datos a un programa, que almacena en un búfer de pila de tamaño reducido. El resultado es que la información en la pila de llamadas se sobrescribe, incluido el puntero de retorno de la función. Los datos establecen el valor del puntero de retorno para que cuando la función regrese, transfiera el control al código malicioso contenido en los datos del atacante.

8.3 Recomendación Aunque el uso cuidadoso de las funciones limitadas puede reducir en gran medida el riesgo de desbordamiento de búfer, esta migración no se puede realizar a ciegas y no llega lo suficientemente lejos por sí sola para garantizar la seguridad. Siempre que manipule memoria, especialmente cadenas, recuerde que las vulnerabilidades de desbordamiento de búfer generalmente ocurren en código que: - Se basa en datos externos para controlar su comportamiento. - Depende de las propiedades de los datos que se aplican fuera del alcance inmediato del código. - Es tan complejo que un programador no puede predecir con precisión su comportamiento. Además, considere los siguientes principios: - Nunca confíe en una fuente externa para proporcionar información de control correcta a una operación de memoria.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

- Nunca confíe en que las propiedades sobre los datos que manipula su programa se mantendrán en todo el programa. Datos de comprobación de cordura antes de operar en él. - Limite la complejidad de la manipulación de la memoria y el código de verificación de límites. Manténgalo simple y documente claramente las comprobaciones que realiza, los supuestos que prueba y cuál es el comportamiento esperado del programa en caso de que falle la validación de entrada. - Cuando los datos de entrada son demasiado grandes, tenga cuidado de truncar los datos y continuar procesándolos. El truncamiento puede cambiar el significado de la entrada. - No confíe en herramientas, como StackGuard, o pilas no ejecutables para evitar vulnerabilidades de desbordamiento del búfer. Estos enfoques no abordan los desbordamientos del búfer de almacenamiento dinámico y los desbordamientos de pila más sutiles que pueden cambiar el contenido de las variables que controlan el programa. Además, muchos de estos enfoques son fáciles de vencer, e incluso cuando funcionan correctamente, abordan el síntoma del problema y no su causa. 9 Buffer Overflow: Format String (Input Validation and Representation, Buffer): main_console.c:69 Media. CWE:134 9.1 Diagrama

9. 2 Código Fuente y explicación

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

El argumento de cadena de formato para sprintf () en main_console.c línea 69 no limita adecuadamente la cantidad de datos que la función puede escribir, lo que permite que el programa escriba fuera de los límites de la memoria asignada. Este comportamiento podría dañar los datos, bloquear el programa o provocar la ejecución de código malicioso. l desbordamiento del búfer es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben qué es una vulnerabilidad de desbordamiento de búfer, pero los ataques de desbordamiento de búfer contra aplicaciones heredadas y recientemente desarrolladas siguen siendo bastante comunes. Parte del problema se debe a la gran variedad de formas en que pueden ocurrir desbordamientos del búfer, y parte se debe a las técnicas propensas a errores que a menudo se usan para prevenirlos. En una explotación clásica de desbordamiento del búfer, el atacante envía datos a un programa, que almacena en un búfer de pila de tamaño reducido. El resultado es que la información en la pila de llamadas se sobrescribe, incluido el puntero de retorno de la función. Los datos establecen el valor del puntero de retorno para que cuando la función regrese, transfiera el control al código malicioso contenido en los datos del atacante. 9.3 Recomendación Aunque el uso cuidadoso de las funciones limitadas puede reducir en gran medida el riesgo de desbordamiento de búfer, esta migración no se puede realizar a ciegas y no llega lo suficientemente lejos por sí sola para garantizar la seguridad. Siempre que manipule memoria, especialmente cadenas, recuerde que las vulnerabilidades de desbordamiento de búfer generalmente ocurren en código que: - Se basa en datos externos para controlar su comportamiento. TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

- Depende de las propiedades de los datos que se aplican fuera del alcance inmediato del código. - Es tan complejo que un programador no puede predecir con precisión su comportamiento. Además, considere los siguientes principios: - Nunca confíe en una fuente externa para proporcionar información de control correcta a una operación de memoria. - Nunca confíe en que las propiedades sobre los datos que manipula su programa se mantendrán en todo el programa. Datos de comprobación de cordura antes de operar en él. 10 Path Manipulation (Input Validation and Representation, Data Flow) open() at file_io_ansi.c line 63: Critica. CWE:20 10.1 Diagrama

10. 2 Código Fuente y explicación

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

Los atacantes pueden controlar el argumento de la ruta del sistema de archivos a fopen () en file_io_ansi.c línea 63, lo que les permite acceder o modificar archivos protegidos de otra manera. Se producen errores de manipulación cuando se cumplen las dos condiciones siguientes: 1. Un atacante puede especificar una ruta utilizada en una operación en el sistema de archivos. 2. Al especificar el recurso, el atacante obtiene una capacidad que de otro modo no se permitiría. Por ejemplo, el programa puede darle al atacante la capacidad de sobrescribir el archivo especificado o ejecutarlo con una configuración controlada por el atacante. En este caso, el atacante puede especificar el valor que ingresa al programa en main () en aectest.c en la línea 90, y este valor se usa para acceder a un recurso del sistema de archivos en fopen () en file_io_ansi.c en la línea 63. 10.3 Recomendación La mejor manera de evitar la manipulación de rutas es con un nivel de indirección: cree una lista de nombres de recursos legítimos que un usuario puede especificar y solo permita que el usuario seleccione de la lista. Con este enfoque, la entrada proporcionada por el usuario nunca se usa directamente para especificar el nombre del recurso. En algunas situaciones, este enfoque no es práctico porque el conjunto de nombres de recursos legítimos es demasiado grande o demasiado difícil de seguir. Los programadores TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

a menudo recurren a las listas negras en estas situaciones. La lista negra rechaza o escapa selectivamente caracteres potencialmente peligrosos antes de usar la entrada. Sin embargo, es probable que cualquier lista de caracteres inseguros de este tipo esté incompleta y casi seguramente quedará desactualizada. Un mejor enfoque es crear una lista blanca de caracteres que pueden aparecer en el nombre del recurso y aceptar entradas compuestas exclusivamente de caracteres en el conjunto aprobado.

11. Buffer Overflow (Input Validation and Representation, Data Flow) pj_stun_client_tsx_create () in stun_transaction.c: Critico. CWE: 119/94 11.1 Diagrama

11. 2 Código Fuente y explicación

La función pj_stun_client_tsx_create () en stun_transaction.c podría escribir fuera de los límites de la memoria asignada en la línea 95, lo que podría dañar los datos, hacer que el programa se bloquee o provocar la ejecución de código malicioso.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

El desbordamiento de búfer es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben qué es una vulnerabilidad de desbordamiento de búfer, pero los ataques de desbordamiento de búfer contra aplicaciones heredadas y recientemente desarrolladas siguen siendo bastante comunes. Parte del problema se debe a la gran variedad de formas en que pueden ocurrir desbordamientos del búfer, y parte se debe a las técnicas propensas a errores que a menudo se usan para prevenirlos.

11.3 Recomendación Nunca use funciones inherentemente inseguras, como gets (), y evite el uso de funciones que son difíciles de usar de manera segura como strcpy (). Reemplace las funciones ilimitadas como strcpy () con sus equivalentes acotados, como strncpy () o las funciones WinAPI definidas en strsafe.h. Aunque el uso cuidadoso de las funciones limitadas puede reducir en gran medida el riesgo de desbordamiento de búfer, esta migración no se puede realizar a ciegas y no llega lo suficientemente lejos por sí sola para garantizar la seguridad. Siempre que manipule memoria, especialmente cadenas, recuerde que las vulnerabilidades de desbordamiento de búfer generalmente ocurren en código que:

- Se basa en datos externos para controlar su comportamiento

- Depende de las propiedades de los datos que se aplican fuera del alcance inmediato del código

- Es tan complejo que un programador no puede predecir con precisión su comportamiento.

Además, considere el siguiente principio

12.

Insecure

Transport:

sl_sock_ossl.c:576

(Insecure

Weak

SSL

Transport:

Protocol Weak

SSL

(Security

Features)

Protocol):

Critico.

CWE:327 12.1 Diagrama

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

12. 2 Código Fuente y explicación

Los protocolos SSLv2, SSLv23 y SSLv3 contienen varios defectos que los hacen inseguros, por lo que no deben usarse para transmitir datos confidenciales.

Los protocolos Transport Layer Security (TLS) y Secure Sockets Layer (SSL) proporcionan un mecanismo de protección para garantizar la autenticidad, confidencialidad e integridad de los datos transmitidos entre un cliente y un servidor web. Tanto TLS como SSL se han sometido a revisiones que dan como resultado actualizaciones periódicas de versiones. Cada nueva revisión fue diseñada para abordar las debilidades de seguridad descubiertas en las versiones anteriores. El uso de una versión insegura de TLS / SSL debilitará la fortaleza de la protección de datos y podría permitir que un atacante comprometa, robe o modifique información confidencial.

12.3 Recomendación Se recomienda encarecidamente obligar al cliente a usar solo los protocolos más seguros. c->sslContext = SSL_CTX_new (TLSv1_2_method());

13.

Weak Encryption: Insecure Initialization Vector (Security Features,

Structural): aes_gcm_ossl.c:203 (Weak Encryption: Insecure Initialization Vector): Alta. CWE:329 TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

13. 1 Diagrama

13. 2 Código Fuente y explicación

Los vectores de inicialización deben crearse utilizando un generador de números pseudoaleatorios criptográficos. No usar un aleatorio hace que el texto cifrado resultante sea mucho más predecible y susceptible a un ataque de diccionario.

13.3 Recomendación Utilice un vector de inicialización (IV) de longitud suficiente con bytes de una fuente de datos aleatorios adecuada. 14 Password Management: Empty Password (Security Features, Structural): http_client.c:270 (Password Management: Empty Password): Alta 14.1 Diagrama

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

14. 2 Código Fuente y explicación

Las contraseñas vacías pueden comprometer la seguridad del sistema de una manera que no se puede remediar fácilmente. Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se usa para autenticarse con éxito en otro sistema, entonces la seguridad de la cuenta correspondiente se ve comprometida porque acepta una contraseña vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, puede confundir a cualquier persona que no esté familiarizada con el código y potencialmente causar problemas en rutas de flujo de control inesperadas.

14.3 Recomendación TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

Lea siempre los valores de contraseña almacenados de recursos externos encriptados y asigne valores significativos a las variables de contraseña. Asegúrese de que los recursos confidenciales nunca estén protegidos con contraseñas vacías o nulas. 15. Buffer Overflow: Format String (Input Validation and Representation, Buffer): siprtp.c:1545 (Buffer Overflow: Format String): Alta. CWE 134 15.1 Diagrama

15. 2 Código Fuente y explicación

El argumento de cadena de formato para sprintf () en siprtp.c línea 1545 no limita adecuadamente la cantidad de datos que la función puede escribir, lo que permite que el programa escriba fuera de los límites de la memoria asignada. Este comportamiento podría dañar los datos, bloquear el programa o provocar la ejecución de código malicioso En una explotación clásica de desbordamiento de búfer, el atacante envía datos a un programa, que almacena en un búfer de pila de tamaño reducido. El resultado es que la información en la pila de llamadas se sobrescribe, incluido el puntero de retorno de la función. Los datos establecen el valor del puntero de retorno para que cuando la función regrese, transfiera el control al código malicioso contenido en los datos del atacante. 15.3 Recomendación

Aunque el uso cuidadoso de las funciones limitadas puede reducir en gran medida el riesgo de desbordamiento de búfer, esta migración no se puede realizar a ciegas y no llega lo suficientemente lejos por sí sola para garantizar la seguridad. TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

16. Weak Encryption: Insecure Initialization Vector (Security Features, Structural): es_icm_ossl.c:251 (Weak Encryption: Insecure Initialization Vector) Alta. CWE:329 16.1 Diagrama

16. 2 Código Fuente y explicación

Los vectores de inicialización deben crearse utilizando un generador de números pseudoaleatorios criptográficos.

16.3 Recomendación Utilice un vector de inicialización (IV) de longitud suficiente con bytes de una fuente de datos aleatorios adecuada.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

CONCLUSIONES En el desarrollo de la actividad pudimos establecer que patrones tener en cuenta en el momento de escribir código libre de amenazas que afecten la seguridad y performe de la aplicación, tomando como base los resultados entregados por la herramienta Fortity revisamos diversos ejemplos

de errores comunes que se comenten en la escritura de

código lo cual nos permitió abtraer todo aquello que debemos tener en cuenta en el momento de escribir una aplicación.

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)

BIBLIOGRAFIA CAPEC CATEGORY: Engage in Deceptive Interactions http://capec.mitre.org./data/definitions/156.html

TEMA 5 –Actividades

© Universidad Internacional de La Rioja (UNIR)