Saltar navegación

DEFENSA PROYECTO ASIR - ANTONIO MANUEL CASTILLO MENGIBAR - Contenido educativo

Ajuste de pantalla

El ajuste de pantalla se aprecia al ver el vídeo en pantalla completa. Elige la presentación que más te guste:

Subido el 19 de enero de 2024 por Jorge Antonio P.

7 visualizaciones

Más información Transcripción

Descargar la transcripción

Bueno, pues como te comentaba, voy a proceder a leerte la información. 00:00:00
Buenas tardes, Alberto. Perdón. 00:00:06
Buenas tardes, Antonio. 00:00:11
Hoy, día 18 de enero, estamos convocados a través de jefatura de departamento para la defensa del modo profesional 00:00:15
de proyecto del ciclo formativo de grado superior de administración de sistemas informáticos en red. 00:00:22
Te informo que esta grabación se usará en el entorno cerrado de EDUCA Madrid 00:00:27
con fines exclusivamente educativos y solo está a la disposición de los profesores evaluadores 00:00:34
en el aula virtual para llevar a cabo la evaluación y calificación de la defensa del proyecto. 00:00:39
En el aula virtual de proyectos habéis sido informados de los criterios y la rúbrica de calificación. 00:00:44
El orden de la presentación del proyecto es el siguiente. 00:00:50
15 minutos máximo para defender el proyecto y 5 minutos para preguntas por parte del tribunal si lo estima oportuno. 00:00:53
Dicho esto, el tiempo de la exposición comienza a partir de este mismo momento. 00:01:02
Adelante y venga, suerte. 00:01:07
Buenas tardes y muchas gracias por atender a la presentación que voy a exponer. 00:01:10
Voy a hablar sobre OWASP, análisis sobre las vulnerabilidades más comunes en la web. 00:01:20
La presentación gira en torno a tres preguntas. 00:01:37
¿Qué es OWASP? ¿En qué me conciene a mí como usuario de una web? 00:01:41
¿Y por qué deberíamos respetar más los datos que nos identifican? 00:01:48
Las dos últimas preguntas se contestarán solas a lo largo de la presentación. 00:01:53
OWASP son las siglas en inglés de proyecto abierto de seguridad de aplicaciones web. 00:02:02
Cada cuatro años, más o menos, realizan un documento con los 10 riesgos de seguridad más importantes en los servicios o aplicaciones web. 00:02:09
Es un proyecto abierto y colaborativo. 00:02:21
Todo el mundo puede aportar algo. 00:02:24
De hecho, cada vez se debería aportar más porque las vulnerabilidades cada vez son más importantes y avanzan cada vez a pasos agigantados. 00:02:28
¿Qué motivación y qué objetivos tiene este proyecto? 00:02:47
La motivación esencial es la de divulgar y concienciar sobre la seguridad de la información en la web. 00:02:52
No solo desde el punto de vista del usuario, sino también desde el punto de vista del desarrollador. 00:02:59
Ya que es la primera línea de seguridad cuando tratamos las aplicaciones en la web. 00:03:06
Por otra parte, el objetivo es analizar las vulnerabilidades más comunes. 00:03:13
Saber identificarlas y proponer soluciones para su mitigación y mejorarlas. 00:03:19
La metodología y herramientas a utilizar son, por una parte, tenemos el modelo cliente-servidor, 00:03:29
que es el diagrama que más vamos a ver en los ataques. 00:03:44
Que se trata de que nos conectamos a una web. 00:03:53
Que la web nos puede proveer un servicio que sea de compra-venta de cualquier artículo. 00:03:57
O simplemente poner un formulario, ya sea en una web como Hacienda o Correos. 00:04:04
Y las herramientas a utilizar son las de Apache. 00:04:13
O sea, las esenciales para crear un servidor web. 00:04:19
Que pueden ser Apache, PHP, Yma y SQL como base de datos. 00:04:23
Y sobre todo voy a utilizar los laboratorios de Postswigger, que son gratuitos. 00:04:28
Que es de las herramientas de Wordfeed. 00:04:34
Y en menor medida Python y un blog de notas para poder ejecutar el programa. 00:04:38
La metodología va a ser la debilidad enumerada. 00:04:49
El escenario vulnerable que se presentará. 00:04:54
Y después de presentar el escenario se hará la explotación y mitigación de dicha vulnerabilidad. 00:04:58
Aquí tenemos los 10 riesgos más vulnerables de la web de 2021. 00:05:08
Porque han cambiado desde el 2017. 00:05:20
Y se pretendía que en este año se saliese otro documento WAF. 00:05:24
Pero todavía no se sabe la fecha. 00:05:33
Y estas 10 vulnerabilidades son control de acceso inadecuado. 00:05:37
Fallos criptográficos, inyección, diseño inseguro, configuración incorrecta de seguridad. 00:05:45
Componentes vulnerables y obsoletas. 00:05:52
Fallos de identificación y autentificación. 00:05:55
Fallos de integridad de datos y software. 00:05:58
Fallos en el registro y monitoreo de seguridad. 00:06:01
Y falsificación de solicitudes del lado del servicio. 00:06:04
Antonio, creo que después nos vas a mostrar una simulación de la 1, la 3, la 5, la 7 y la 10, ¿verdad? 00:06:08
Sí, verdad. Eso iba a comentar. 00:06:16
Como esta presentación se queda corta, digamos, en el tiempo. 00:06:19
Pues voy a presentar la 1, la 3, la 5. 00:06:24
Perdón, la 5, la 7 y la 10. 00:06:31
¿Vale? 00:06:35
Sí. 00:06:38
Bueno, voy a seguir. 00:06:40
Vale. 00:06:44
Por otra parte, hay tres conceptos clave en el diseño y en el despliegue de pruebas que debemos conocer. 00:06:45
Son las tres palabras claves estas de CVE, que es enumeración de debilidades comunes. 00:06:52
Que clasifica los tipos de vulnerabilidades de software. 00:07:01
O sea, trata la causa, por así decirlo, es una debilidad. 00:07:06
CVE, que son las vulnerabilidades y exposiciones comunes. 00:07:13
Que es un sistema que proporciona un método de referencia para la vulnerabilidad y exposición en seguridad conocida. 00:07:17
Es decir, trata los síntomas y es una manifestación de CVE. 00:07:26
Y, por último, es CVSS, que es un sistema común de puntuación de vulnerabilidades. 00:07:33
Y clasifica la criticidad de dicha vulnerabilidad. 00:07:40
Por poner un ejemplo, todo el mundo habrá visto que se ve, cuando se dice una vulnerabilidad, se ve CVE 2013 y un cuadro número. 00:07:45
Pues eso es una manifestación de la debilidad que es el CVE con una puntuación que es el CVSS. 00:08:01
Por cada categoría del documento WASP, voy a realizar la explotación de una debilidad CVE, venérica, siguiendo la metodología que antes mencioné. 00:08:11
Que es el escenario de la vulnerabilidad, la explotación y la mitigación. 00:08:26
Vale. La primera, que sería el control de acceso y, concretamente, sería la ruta transversal. 00:08:30
El escenario que se presenta sería el siguiente. 00:08:40
Tenemos una web que puede ser, como he dicho antes, un servicio que sea de compra-venta de un artículo. 00:08:44
Actualmente, Comisiones Obreras fue atacada con esta vulnerabilidad y es conocida desde 2005. 00:08:54
Y nos da una perspectiva de lo que debería avanzar la ciberseguridad en este aspecto. 00:09:05
Y trata de… Perdón. Ataca fundamentalmente al vector de ataque de la entrada del usuario en la petición URL. 00:09:13
Perdón. Ataca fundamentalmente al vector de ataque de la entrada del usuario en la petición URL. 00:09:28
Un recurso PHP que tenemos, que tiene una función que coge un archivo, podemos apuntarla a un archivo del sistema. 00:09:43
Aquí lo vemos más en profundidad. 00:10:07
Si nos metemos en una web de compra-venta y añadimos… Bueno, añadimos no. Vemos la ruta, una imagen del producto. 00:10:11
Vemos que la ruta es imagen interrogante file igual a 20.jpg. Ese archivo reside en el sistema. 00:10:28
Y lo que podríamos hacer es, para que apunta a un archivo que esté dentro del sistema, sería retroceder en el directorio 00:10:40
para ver si podemos apuntar a las raíces de las raíces. Poder apuntar a, por ejemplo, ETC, WD, que es donde residen las contraseñas del sistema. 00:10:52
Y vemos que en este caso, como no está sanitizado, como vamos a ver en la miticación, podemos encontrar el archivo. 00:11:04
Aquí proponemos una serie de mitigación que sería la de validar el input, que esta siempre la vamos a ver presente en los demás ataques. 00:11:15
Y normalmente en las APIs tienen una función para hacer una ruta canónica. 00:11:29
Y esta ruta canónica la podemos comparar con la ruta que nos da el usuario o hacerla canónica directamente con la API. 00:11:36
Y así nos curamos en salud y no nos pueden atacar por este método. 00:11:50
La siguiente inyección sería inyección XSS, que sería el XSS de cross-site scripting. 00:11:57
Secuencia en sitios cruzados. Y trata de meter lenguaje de scripting, en este caso JavaScript, como hemos visto antes también en el ataque anterior, en la URL. 00:12:10
Y esto es porque tampoco está sanitizado. 00:12:38
La flotación de la vulnerabilidad en esta ocasión no he utilizado un laboratorio de Postgre como en el ataque anterior. 00:12:43
Y he montado un servidor web con el HTML genérico que vemos en la izquierda y con el recurso PHP para que apuntase a un archivo. 00:12:56
Vale. El archivo HTML es un formulario para que nos podemos encontrar en cualquier web. 00:13:13
Y al no estar sanitizado y poder inyectar código JavaScript, podemos, bueno, en este ataque que he hecho, simplemente se ve una alerta y sale un pop-up con un 3. 00:13:30
Pero el ataque cobra valor, digamos, porque si yo como atacante y otra persona como usuario, si yo meto el lenguaje de scripting y le sale a esa persona como usuario el pop-up, 00:13:46
yo puedo tener la contraseña del otro usuario. 00:14:11
La mitigación de XSH. Igual que antes, validar el input del usuario y que contenga caracteres esperados solamente y limitar la entrada a los caracteres de formulario. 00:14:15
Por ejemplo, un campo de teléfono que sean números de X extensión. 00:14:40
E intentar limpiar la entrada no válida para hacerla válida es más propenso a errores. 00:14:45
Vale. Lo siguiente ataque sería configuración de seguridad incorrecta. Bueno, está mal puesto, perdón. 00:14:51
Es XXG. Entidades de XML. Se trata de inyectar una entidad XML al documento para que apunte a una dirección dentro del sistema. 00:15:04
Que en este caso sería el filename de tcpassword. Vale. 00:15:28
En la petición, como estamos viendo aquí, que es un laboratorio de PostSuite, la web sería, como antes hemos visto también, una compra-venta de cualquier artículo. 00:15:36
Una web de compra-venta. Y en la derecha vemos la intersección con PostSuite de la respuesta que nos da la web con la estructura XML. 00:15:50
Como vemos aquí, lo he mandado al repite en PostSuite y lo que he hecho es crear una entidad XML para que apuntase a tcpassword. 00:16:08
Y dentro de la estructura he apuntado a la dirección de X, que es la entidad que he definido. 00:16:24
Y en la respuesta nos devuelve invalidProductId, porque no es el id correcto, pero nos vuelca todo el archivo de tcpassword. 00:16:32
Y la mitigación de esta vulnerabilidad es deshabilitar la resolución de entidades externas XML que normalmente los desarrolladores por productividad de la empresa dejan y se convierte en un vector de ataque. 00:16:45
Y la siguiente sería fallos de autenticación y fijación de sesión. 00:17:04
El escenario este es simple también. También es un laboratorio de PostSuite. 00:17:12
Antonio, una pregunta. ¿Has elegido cada laboratorio de pruebas en función de la regla OWASP, por las características que tiene o por qué otro criterio has elegido en cada caso un laboratorio u otro? 00:17:19
Sí, es el laboratorio más genérico de cada, digamos, debilidad. 00:17:33
Porque las debilidades, una cosa que no he dicho es que las categorías OWASP se hacen, digamos, que las empresas mandan a OWASP las debilidades que ellos enumeran en un producto 00:17:42
y OWASP lo que hace es organizarlas según la afinidad que tienen las debilidades. 00:17:59
Y en base a eso hace la categoría y cada categoría, como estamos viendo, tiene distintos vectores de ataque que son las vulnerabilidades. 00:18:07
Y dentro de esa, por ejemplo, la fijación de sesión o la ruta transversal que hemos visto es una entre muchas que tiene esa categoría. 00:18:18
Y la que he elegido es genérica, digamos, porque la de ruta transversal que hemos visto al principio de OWASP la tenían mucho. 00:18:30
Ahora la tienen cada vez menos, menos comisiones obreras como hemos visto que sí la tuvo. 00:18:42
Vale, la de fallo de autenticación de fijación de sesión tiene que ver con el doble factor de autenticación. 00:18:52
Y es que muchos escenarios empresariales tienen doble factor, pero incluso en los dobles factor de autenticación tienen dos formas de autenticarse. 00:19:02
Y normalmente cuando nosotros iniciamos sesión, como estamos viendo aquí en la diapositiva, nos mandan un código al correo que es el doble factor. 00:19:17
Pero si tenemos las credenciales, porque se han filtrado en internet de un usuario o lo que sea, si esa web tiene un doble factor de autenticación, 00:19:34
pero nosotros, como estamos viendo aquí en el laboratorio, tenemos el recurso que actualiza cuando nosotros metemos el primer factor, que en este caso es My Account. 00:19:47
Si nosotros metemos las credenciales de la víctima, nos va a pedir el segundo factor de autenticación, pero podemos bypassearlo, saltárnoslo, poniéndolo directamente en la URL, el recurso My Account, 00:20:04
y vemos que podemos acceder porque han fijado la sesión a la cookie del usuario. 00:20:25
La parte de mitigación de esta vulnerabilidad sería implementar la autenticación multifactor, o sea, de varios factores para evitar ataques de fuerza bruta y ataques de contraseña que estén expuestas en internet. 00:20:34
Ya sea por hackeo o por descuido del usuario porque lo haya puesto en Pastebin o GitHub o alguna plataforma. 00:20:53
Implementar un sistema de contraseñas robusto y limitar los intentos de inicio de sesión para esto mismo, para que no hagan ataques de fuerza bruta. 00:21:06
El último ataque sería falsificación de solicitudes del lado del servidor SSRF, en inglés, y esta categoría es nueva en este 2021, bueno, en el último documento, 00:21:14
porque las empresas han enumerado muchas debilidades de esta parte y trata de que dentro de la infraestructura de la empresa, si nosotros tenemos en la DMZ de la web, 00:21:31
pero dentro de esa web, dentro de esa infraestructura o dentro de esa máquina que sirve la web, hay otra tarjeta de red con un IP de la red interna. 00:21:49
Nosotros, como atacantes, si accedemos al servidor web, pero aunque esté en la DMZ, si está dentro de la red interna, podemos apuntar a cualquier máquina de esa red que esté el servidor web. 00:22:05
Vale, aquí vemos, esto es un laboratorio de Paul Swigert, que no he puesto, digamos, la portada, pero sería también, parecía, perdón, sería parecía a la de compra-venta y de producto. 00:22:30
Y vemos aquí la respuesta que nos ofrece, porque lo hemos intercetado con WoodSuite y sería de stock API igual a HTTP tal, tal, tal y un chorraco, que sería, que estaría codificado en UTF-8, creo, sí, la barra y eso. 00:23:01
Antonio, además de mostrarnos la presentación con las cinco reglas de Wasp que has elegido, ¿nos vas a mostrar algo más o sería, lo digo porque llevamos ya 25 minutos casi de exposición y por el tema del tiempo querías saber si vas a mostrar algo más? 00:23:26
Bueno, sí, sería eso vía futura y conclusiones. Me queda en esta, ya. 00:23:45
Vale, y ya, y con eso terminas. 00:23:53
Sí, sí. 00:23:55
Vale. 00:23:56
Eh, vale, sería aquí, eh, vale, he dicho que está en UTF-8, vale. 00:23:58
Eh, interceptando esto podemos aplicar un decodificado a esto, a el stock API igual a HTTP tal y poner HTTP localhost barra admin. 00:24:07
Para que nos devolviese el HTML del panel de control del admin. 00:24:25
Y así ver los recursos para, por ejemplo, borrar un usuario y con este recurso podemos ponerlo en la URL y a la derecha lo que vemos es que poniendo ese recurso en la, en la, perdón, en la URL, no, en la petición directamente, 00:24:32
eh, nos responde con que un 302 found, o sea que ha borrado el usuario y con eso podemos explotar la vulnerabilidad. 00:24:56
La mitigación de, de esta parte sería, sería como vemos aquí a nivel de cementar los recursos, eh, aplicar las políticas de firewall de negación por defecto y a nivel de aplicación sanitizar y validar todos los datos de entrada como hemos visto antes. 00:25:11
Eso es, eh, es igual en casi todas, por no decir todas. 00:25:31
Eh, la vía futura de, de esta es decir poco. O sea, yo me he imaginado un futuro en que la, la IA esté integrada en la herramienta de control y, y sean estas herramientas de aprendizaje automático y análisis automático de patrones de ataque. 00:25:38
Eh, automatización de respuestas ante amenazas y predicción de posibles vulnerabilidades mediante sistema de análisis predictivo o proactivo. Y las conclusiones del, del proyecto serían. 00:26:00
Sí, estamos, estamos fiando en todos los ámbitos, eh, mucho en las posibilidades de la, de la inteligencia artificial en el futuro. Es un arma de doble filo también porque según como se utilice, pues ya sabemos, ¿no? 00:26:13
Claro, eh, a ver, actualmente han, hicieron, eh, como un chat GPT, pero enfocaba a ciberseguridad, a hacking, pero no le llega a la suela de los zapatos a un auditor porque todavía le queda mucho recorrido. 00:26:28
Lo que sí es verdad es que, por ejemplo, con chat GPT, lo que, si tú dominas la rama, le puedes ir enfocando las preguntas y te responden más concisamente. Por ejemplo, los desarrolladores sí que lo utilizan mucho y actualmente las empresas sí que lo están utilizando para desarrollar. 00:26:48
Pero eso sí, enfocándolo, como estoy diciendo, las preguntas muy concretas y conclusiones que la conclusión sería que hoy en día la seguridad en aplicaciones web es muy importante y las vulnerabilidades web pueden tener consecuencias graves para la confidencialidad, integridad y disponibilidad de los datos. 00:27:09
O sea, la triada, eh, no se debe confiar directamente en la entrada del usuario, como hemos visto, porque siempre el usuario la caga, por así decirlo, porque mete cosas que no están previstas o siempre va a intentar saltarse algo. 00:27:35
Y volviendo a las dos preguntas del principio, porque la primera era Wasp y ya se ha definido en qué me conciene a mí como usuario de una web y cómo los datos son propios, o sea, perdón, la pregunta sería en qué me conciene a mí como usuario de una web. 00:27:57
Como los datos son propios, deben ser confidenciales y la integridad de ellos en el momento en que le accedemos estos datos a un tercero debe respetarse y deberían ser disponibles para restringir el uso de ellos si así lo deseamos. 00:28:16
¿Y por qué deberíamos respetar más los datos que no identifican? Pues no sabemos qué persona o entidad va a hacer uso de ellos y con qué finalidad. Y, por último, dar las gracias por la atención recibida. 00:28:34
Vale, Antonio. En cuanto a la mitigación de las vulnerabilidades, entiendo que hay medidas reactivas y medidas proactivas. Entonces, lo que interesa siempre es incrementar el número de proactivas, curarnos en salud, para no tener que aplicar las reactivas. 00:28:55
Eso, ¿cómo está planteado dentro de las directivas de OWASP? Quiero decir, ¿qué porcentaje crees tú, a día de hoy, de las reglas OWASP que son reactivas y otras que son proactivas, que es el objetivo? 00:29:16
Vale. Pues, actualmente yo creo que son más reactivas que proactivas. Proactivas serían una vez ya la amenaza, o sea, ya en sí lo atacaron, ¿no? 00:29:36
No, al contrario. Proactivas se entiende como preventivas y reactivas como respuesta ya al ataque. El concepto es el contrario. 00:29:55
Pues, preventivas serían, pues eso, como hemos visto, por ejemplo, en SSRF, sería segmentar los recursos de la infraestructura para acotar, digamos, la posible amenaza o vulnerabilidad. 00:30:10
Y también sanitizar el código, aplicar a los desarrolladores concienciación de código seguro, que actualmente, por ejemplo, existe la figura de DevOps y hay ahora otra rama que sería la de DevSecOps, que sería DevOps, pero enfocada a seguridad. 00:30:29
Que eso profundizaría en sanitización de código, que no hubiese buffer overflow, que no se pusiese variables donde no debería haberlas. 00:30:53
O como hemos visto, lo de las entidades XML, que no se creasen entidades externas. 00:31:12
Vale. Pues, dado que llevamos ya 31 minutos, nos hemos pasado el doble de lo que… 00:31:23
Lo siento. 00:31:30
No, no te preocupes. Lo único que tengo ahora otra a continuación, con otro alumno. O sea, quedamos por terminada la presentación, si te parece. 00:31:32
Vale. 00:31:39
Idioma/s:
es
Subido por:
Jorge Antonio P.
Licencia:
Dominio público
Visualizaciones:
7
Fecha:
19 de enero de 2024 - 18:41
Visibilidad:
Clave
Centro:
IES CIFP a Distancia Ignacio Ellacuría
Duración:
31′ 42″
Relación de aspecto:
1.78:1
Resolución:
1920x1080 píxeles
Tamaño:
227.90 MBytes

Del mismo autor…

Ver más del mismo autor

EducaMadrid, Plataforma Educativa de la Comunidad de Madrid

Plataforma Educativa EducaMadrid