DATOS PERSONALES FIRMA

Nombre: DNI:
Apellidos:
ESTUDIO ASIGNATURA CONVOCATORIA
MÁSTER UNIVERSITARIO EN
INGENIERÍA DE SOFTWARE Y 01067.- SEGURIDAD EN EL
SISTEMAS INFORMÁTICOS (PLAN Ordinaria
SOFTWARE
2015V2)

CIUDAD DEL
FECHA MODELO
EXAMEN

09-11/07/2021 Modelo - C

Etiqueta identificativa

INSTRUCCIONES GENERALES
1. Ten disponible tu documentación oficial para identificarte, en el caso de que se te
solicite.
2. Rellena tus datos personales en todos los espacios fijados para ello y lee
atentamente todas las preguntas antes de empezar.
3. Las preguntas se contestarán en la lengua vehicular de esta asignatura.
4. Si tu examen consta de una parte tipo test, indica las respuestas en la plantilla según
las características de este.
5. Debes contestar en el documento adjunto, respetando en todo momento el
espaciado indicado para cada pregunta. Si este es en formato digital, los márgenes,
el interlineado, fuente y tamaño de letra vienen dados por defecto y no deben
modificarse. En cualquier caso, asegúrate de que la presentación es suficientemente
clara y legible.
6. Entrega toda la documentación relativa al examen, revisando con detenimiento que
los archivos o documentos son los correctos. El envío de archivos erróneos o un
envío incompleto supondrá una calificación de “no presentado”.
7. Durante el examen y en la corrección por parte del docente, se aplicará el
Reglamento de Evaluación Académica de UNIR que regula las consecuencias
derivadas de las posibles irregularidades y prácticas académicas incorrectas con
relación al plagio y uso inadecuado de materiales y recursos.

Código de examen: 169863

 Puntuación
Preguntas de Respuesta Simple

 Puntuación máxima 2.00 puntos

Preguntas de Desarrollo

 Puntuación máxima 8.00 puntos

Preguntas de respuesta Simple. Señalar la respuesta acorde a lo indicado en el

enunciado de cada pregunta. No restan las preguntas mal contestadas. Cada
pregunta bien contestada vale 0,2 puntos. Tiempo estimado de resolución 40
minutos.

1. Señalar la respuesta correcta. El objetivo del principio de “seguridad por

defecto”:

A. Conseguir que los usuarios obtengan una experiencia más segura con la aplicación
después de una compleja configuración.
B. Asegurar que las aplicaciones estén preconfiguradas con contraseñas de
predeterminadas.
C. Conseguir que los usuarios obtengan una experiencia más segura con la aplicación,
sin necesidad de configuración exhaustiva.
D. Ninguna de las anteriores

2. Señalar la respuesta correcta. ¿Cuál es la línea de código que puede

producir un desbordamiento de búfer?

#include <stdio.h>
#include <string.h>
#define S 100
#define N 1000
int main(int argc, *argv[]) {
out[S];
buf[N];
msg[] = "Bienvenido\n";
int len = 0;
buf[0] = '\0';
printf(msg);
while (argc) {
sprintf(out, "argument %d is %s\n", argc-1, argv[argc-1]);

Código de examen: 169863

argc--;
strncat(buf,out,sizeof(buf)-len-1);
len = strlen(buf);
}
printf("%s",buf);
return 0;}

A. printf(msg)
B. sprintf(out, "argument %d is %s\n", argc-1, argv[argc-1]);
C. len = strlen(buf);
D. strncat(buf,out,sizeof(buf)-len-1);

3. Señalar la respuesta correcta. ¿Qué es un caso de abuso?

A. Un escenario que ilustra de manera gráfica y textual funcionalidades de seguridad

del software ante específicas circunstancias.
B. Una base de datos del MITRE.
C. Un escenario que ilustra de manera gráfica y textual potenciales fallos de seguridad
ante específicas circunstancias.
D. Un patrón de diseño para un desarrollador.

4. Señalar la respuesta correcta. Consideraciones sobre potenciales vulnerabilidades de

Java:

A. Seguridad de tipos. Los campos que son declarados privados o protegidos o que
tienen protección por defecto deberían ser públicamente accesibles.
B. Campos públicos. Un campo que es declarado público directamente puede no ser
accedido por cualquier parte de un programa Java y puede ser modificado por las
mismas (a no ser que el campo sea declarado como final).
C. Serialización. Esta facilidad posibilita que el estado del programa sea capturado y
convertido en una byte stream que puede ser restaurado por la operación inversa
que es la deserialización.
D. JVM. La JVM en sí misma a menudo está escrita en C para una plataforma dada.
Esto quiere decir que sin la atención cuidadosa a detalles de puesta en práctica, la
JVM en sí misma no susceptible a problemas de desbordamiento.

5. Señalar la respuesta correcta. Cual son de forma general las práctica de seguridad del
software más aplicada:

A. Pruebas de Penetración.
B. Análisis estático de código fuente.
C. Análisis hibrido.
D. Pruebas de escaneos de bugs.

6. Señalar la respuesta incorrecta. La pruebas de penetración:

Código de examen: 169863

 A. Cuando se realizan pruebas de penetración que detectan pocas o ninguna
vulnerabilidad de seguridad, quiere decir que la ejecución de esas pruebas
proporciona muy poca seguridad de que una aplicación es inmune ante ataques.
B. Las pruebas de penetración de forma general las más aplicadas de todas las mejores
prácticas de seguridad del software, y suelen ser parte del proceso de aceptación de
final.
C. Un conjunto de pruebas positivas satisfactoriamente ejecutadas, por lo general no da
confianza de que el software realizará funcionalmente su trabajo como se desea.
D. El entendimiento del ambiente de ejecución y de los problemas de configuración es
el mejor resultado de cualquier prueba de penetración.

7. Señalar la respuesta incorrecta. Los factores principales prácticos que determinan la

utilidad de una herramienta de análisis estático son:

A. El equilibrio que la herramienta hace entre la extensión del código fuente y el tipo de
lenguaje de programación.
B. Porcentaje de falsos positivos y falsos negativos de la herramienta.
C. El conjunto de errores que la herramienta comprueba.
D. Las características de la herramienta para hacerla fácil de usar.

8. Señalar la respuesta incorrecta. Los objetivos de las pruebas de seguridad basadas en

el riesgo

A. Verificar las funcionalidades del software bajo en su entorno de producción.

B. Verificar la capacidad de supervivencia del software ante la aparición de anomalías,
errores y su manejo de las mismas mediante excepciones que minimicen el alcance
e impacto de los daños que puedan resultar de los ataques.
C. Verificar la falta de defectos y debilidades explotables.
D. Verificar la seguridad del software, en términos de comportamiento seguro y cambios
de estado confiables.

9. Señalar la respuesta incorrecta. Los defectos de implementación que se pueden

cometer se pueden cometer caen dentro de las siguientes categorías:

A. Manejo de la entrada de datos.

B. Error de diseño de la arquitectura del software.
C. Errores y excepciones.
D. Desbordamiento de buffer.

10. Señalar la respuesta correcta. ¿Cuál es el siguiente principio de diseño de seguridad

del Software: “Estrategia de protección consistente en introducir múltiples capas de
seguridad, que permitan reducir la probabilidad de compromiso en caso de que una de las
capas falle y en el peor de los casos minimizar el impacto”?

A. Mínimo privilegio.
B. Simplicidad.
C. Ninguna de las anteriores.
D. Defensa en profundidad.

Código de examen: 169863

 PLANTILLA DE RESPUESTAS
Preguntas / Opciones A B C D

1 X

2 X

3 X

4 X

5 X

6 X

7 X

8 X

9 X

10 X

Código de examen: 169863

Responda a las preguntas de desarrollo (abiertas) que a continuación se le
presentan. Cada una de ellas vale cuatro (4) puntos. Tiempo estimado de
resolución 80 minutos, 40 minutos cada pregunta.

1. Desarrolle los siguiente puntos acerca del principio de diseño “Registro de Eventos de
Seguridad”:

1. Motivación de su necesidad.

Normalmente los sistemas de auditoria se dedican a registrar las acciones de los usuarios sobre el
sistema, sin embargo un sistema de auditoria también puede registrar las acciones de un atacante, y
construir alrededor de estas, sistemas de alerta que permitirían detener y quizá atrapar al atacante,
minimizando así el impacto que sufre la empresa.

Debido a que las organizaciones ya tienen (normalmente) un sistema de auditoria, ampliar este sistema
para que registre los eventos y/o acciones de un atacante constituye una capa de seguridad de bajo
coste y alto beneficio. Puede pensarse como, tener una casa con las alarmas instaladas, y solo hace falta
encender en sistema. Por supuesto, encender el sistema de alarmas no es suficiente para garantizar el
bloqueo del atacante.

2. Diferencias de los registros de auditoría de seguridad de registro los registros de eventos estándar.

a. El tipo de información capturada. Se capturan eventos ajenos a los usuarios y relevantes a la

seguridad

b. Capacidad de gestión de los incidentes. Se capturan eventos relacionados con la seguridad con
el fin de hallar patrones de ataque. Mientras que un registro estandar, se puede usar con fines
de “historias de los usuarios” (un tópico ajeno a la seguridad del software)

c. Abren la posibilidad de de generar un efecto dominó con sistemas de procesos reactivos. Es

decir, al hallarse un registro de seguridad de un determinado patrón se puede iniciar un sistema
de alarma

d. El nivel de protección de integridad.

 (Responder en 2 caras)

Código de examen: 169863

2. Explicar qué tipo de vulnerabilidad se comete y como se remedia en estos dos
fragmentos de código:

Código 1

String delimiter;

for (int i=0; i < args.length; i++) {

  if ( args[i].startsWith("--delimiter=") ) {

    delimiter = args[i].substring(12);

  }

...

for (int i = 0; i < dropSQL.length; i++) {

try {

  String formatted = dropSQL[i];

  if (delimiter!=null) formatted += delimiter;

  ...

  fileOutput.write( formatted + "\n" );

 Descripción del problema:

Estamos frente a un caso de vulnerabilidad por inyección SQL
En la línea if (delimiter!=null) formatted += delimiter; se acepta la variable ‘delimiter’ que
no ha sido validada correctamente, si el usuario puede definirla, entrará a la sentencia SQL y
hará lo que se le antoje en la base de datos.
Por ejemplo, el atacante podría ingresar con --delimiter’; DELETE * FROM table , y eliminar así
todos los registros de una tabla.
Solución:
Utilizar sentencias parametrizadas
Sugerencia adicional, validar uso de metacaracteres para delimiter

Código de examen: 169863

Código 2

for (int i=1; i < argc; i++) {

               if (!access(argv[i], O_RDONLY)) {

             fd = open(argv[i], O_RDONLY);

       }

       print(fd);

 Descripción del problema:

Estamos frente a un caso de vulnerabilidad TOCTOU (time of check, time of use).

Haciendo uso de un depurador (por ejemplo) el atacante puede hacer una pausa al
programa despues del Tiempo 1 en la línea if (!access(argv[i], O_RDONLY)).

Ahora el atacante entra en su tiempo (tiempo 2) y realiza un unlink sobre el fichero que el
programa abriría en condiciones normales.

Tras esto, el atacante continua al Tiempo 3, donde realizaría un SymLink apuntando a un

fichero diferente (por ejemplo, uno que contenga usuarios).

Finalmente, el atacante reanuda la ejecución del programa, entramos en el tiempo 4 y se

ejecuta la linea fd = open(argv[i], O_RDONLY), abre el fichero al que se está apuntando a trvés
de un SymLink y la función print(fd) presentaría información sensible en pantalla

Solución:
Eliminar de raiz la posibilidad de la vulnerabilidad TOCTOU mediante la supresión de la linea
if (!access(argv[i], O_RDONLY)) (Que para efectos prácticos es inútil), y abrir directamente el
fichero con la línea fd = open(argv[i], O_RDONLY);

Código de examen: 169863