Logo Studenta

Entregable Final - Javier Mendoza (1)

¡Este material tiene más páginas!

Vista previa del material en texto

Índice. 
1. Resumen………………………………………………………………………………………………....2
1.1. Abstract…………………………………………………………………………………..…….2
2. Introducción……………………………………………………………………………………………..3
 2.1. Seguridad de Aplicaciones.…………………………………………………………………3
 2.2. Estándares de Seguridad……..……………………………………………………………..4
 2.3. Pruebas de Seguridad…………………………………………………………………………5
 2.4. Tipos de Ataques a Aplicaciones………………………………………………………….6
3. Desarrollo……………………………………………………………………………………………….8
3.1. Presentación de evidencias………………………………………………………………8
4. Conclusiones………………………………………………………………………………………….14
5. Referencias…………………………………………………………………………………………….15
1. Resumen. 
El presente documento es la conclusión del curso de Seguridad de Sistemas y Aplicaciones en el cual se aplican los conocimientos adquiridos durante dicho curso mediante la realización de un ejercicio de fuzzing a una aplicación vulnerable. Este documento esta estructurado en tres partes, la primera es la parte teórica en donde se abordan los principales conocimientos que fueron tratados durante el curso, la segunda es la parte practica en donde se aplican los conocimientos adquiridos durante las investigaciones previas y las sesiones presenciales para finalizar con la conclusión de la asignatura y del proyecto.
En la parte de la introducción se abordan los conceptos de la seguridad de aplicaciones y su importancia, los principales estándares de seguridad, pruebas de seguridad en las aplicaciones y los principales ataques realizados a las mismas. Para la sección del desarrollo se expondrá la secuencia que se siguió para completar un ejercicio de buffer overflow en una aplicación vulnerable llamada FreeFloat FTP Server.
 
1.1. Abstract 
This document is the conclusion of the Safety and Applications Security Course in which the knowledge acquired during said course is applied by conducting a fuzzing exercise to a vulnerable application. This document is structured in three parts, the first is the theoretical part where the main knowledge that was treated during the course is addressed, the second is the practical part where the knowledge acquired during previous investigations and the face -to -face sessions for Finish with the conclusion of the subject and the project.
In the part of the introduction, the concepts of application security and its importance, the main security standards, security tests in the applications and the main attacks conducted to them are addressed. For the development section, the sequence that was followed to complete an overflow buffer exercise in a vulnerable application called FreeFloat FTP Server will be exposed.
Keywords
Fuzzing
Buffer OverFlow
FreeFloat FTP Server
Application Security
2. Introducción.
El presente documento tiene como objetivo aplicar los conocimientos adquiridos durante el curso de Seguridad de Sistemas y Aplicaciones, con la realización de un ejercicio práctico de Fuzzing, para ello primeramente se expondrán algunos conceptos fundamentales para el entendimiento del ejercicio. Este proyecto se realiza en el contexto actual de seguridad, en donde es de vital importancia para las instituciones públicas y empresas tanto grandes como pequeñas, proteger la información que manejan, puesto que en la gran mayoría de estas es el activo más importante y estas organizaciones constantemente reciben ataques cibernéticos con el objetivo de obtener esta información y a partir de esta generar ingresos económicos.
A continuación, se expondrán los conceptos correspondientes a la parte teórica del proyecto como la importancia de la seguridad de aplicaciones, los estándares o normas internacionales involucrados, tipos y ejemplos de pruebas de seguridad y ataques más comunes a las aplicaciones.
2.1. Seguridad de Aplicaciones.
Cuando hablamos de la seguridad de aplicaciones nos referimos a la implementación de todas aquellas medidas y controles de seguridad a nivel aplicación, que tienen como objetivo evitar el robo de información, esto engloba las consideraciones de seguridad que se deben tener en cuenta al desarrollar y diseñar aplicaciones, además de los sistemas y los enfoques para proteger las aplicaciones después de distribuirlas. Esto también se refiere al proceso de desarrollar, añadir y probar características de seguridad dentro de las aplicaciones para evitar vulnerabilidades de seguridad contra amenazas, tales como la modificación y el acceso no autorizados.
Las infracciones más exitosas apuntan a vulnerabilidades explotables en la capa de aplicación, lo que indica que los departamentos de TI de la empresa deben estar muy atentos a la seguridad de la aplicación. El número y la complejidad de las aplicaciones está aumentando para exacerbar el problema. Las soluciones de seguridad de aplicaciones analizan vulnerabilidades explotables potenciales en aplicaciones web, analizan código, coordinan esfuerzos y permiten a las partes interesadas implementar la colaboración en el proceso de desarrollo y administración de seguridad. 
Existen diferentes tipos de funciones de seguridad de aplicaciones, como autenticación, autorización, cifrado, registro y pruebas de seguridad de aplicaciones. Los desarrolladores también pueden programar aplicaciones para reducir las vulnerabilidades de seguridad. Los desarrolladores de software pueden incorporar mecanismos de autenticación y autorización en sus aplicaciones para que solo los usuarios autorizados puedan acceder a ellas. El procedimiento de autenticación garantiza la identidad del usuario. Esto se logra obligando al usuario a proporcionar un nombre de usuario y una contraseña para iniciar sesión en la aplicación. 
Si una aplicación está en riesgo, los registros pueden ayudarlo a determinar quién accedió a sus datos y cómo. El archivo de registro de la aplicación contiene una marca de tiempo que muestra a qué aspectos de la aplicación se accedió y quién estuvo involucrado. Se requieren pruebas de seguridad de la aplicación para garantizar que todos estos controles de seguridad funcionen correctamente. 
 El control de seguridad de aplicaciones es una técnica para mejorar la seguridad de las aplicaciones y mitigar las vulnerabilidades de las amenazas a nivel de programación. Muchos de estos controles afectan la forma en que su aplicación responde a entradas inesperadas que los ciberdelincuentes pueden usar para aprovechar la vulnerabilidad. Los programadores pueden escribir código de aplicación que les dé más control sobre los resultados de estas entradas inesperadas.
2.2. Estándares de Seguridad. 
En esta sección conoceremos los principales estándares y metodologías de seguridad de aplicaciones entre las que se encuentra la norma ISO/IEC 27034, el estándar OWASP ASVS y metodología Microsoft SDL.
ISO/IEC 27034 es un estándar reconocido internacionalmente centrado en la seguridad de las aplicaciones. Este estándar brinda orientación sobre cómo especificar, diseñar/seleccionar y aplicar controles de seguridad de la información para ayudar a las organizaciones a incorporar la seguridad en los procesos utilizados para administrar sus aplicaciones. Esto se puede aplicar a aplicaciones desarrolladas internamente, aplicaciones obtenidas de terceros y aplicaciones que subcontratan el desarrollo o la operación de la aplicación. Se basa en los siguientes principios fundamentales:
· La seguridad es un requisito
· La seguridad de las aplicaciones depende del contexto
· Inversión apropiada para aplicaciones de seguridad
· La seguridad en las aplicaciones debe ser demostrada
El objetivo es garantizar que las aplicaciones informáticas brinden el nivel de seguridad deseado o requerido y brindar orientación sobre seguridad de la información en el diseño, desarrollo, programación e implementación de sistemas de aplicación. Esto incluye aplicaciones de software desarrolladas internamente, a través de adquisiciones externas, externalización/deslocalización o enfoques híbridos. Abarca todo, desde la determinación de los requisitos de seguridad de la información hasta la protección de lainformación a la que accede su aplicación y la prevención del uso y la acción no autorizados por parte de su aplicación. La norma consistente en 6 partes:
· Conceptos generales.  
· Marco normativo de la organización. 
· Proceso de gestión de seguridad en aplicaciones. 
· Validación de la seguridad en aplicaciones. 
· Estructura de datos y protocolos y controles de seguridad de aplicaciones. 
· Guía de seguridad para aplicaciones de uso específico. 
· Seguridad de la aplicación. 
OWASP.
El proyecto Estándares de verificación de seguridad de aplicaciones (ASVS) de OWASP proporciona la base para probar los controles de seguridad técnica para aplicaciones web y proporciona a los desarrolladores una lista de requisitos de desarrollo seguro. El objetivo principal del proyecto ASVS es estandarizar el nivel de cobertura y rigor disponible en el mercado para las pruebas de seguridad de aplicaciones web utilizando estándares abiertos comercialmente viables. 
 Este estándar proporciona la base para probar los controles técnicos de seguridad de las aplicaciones y los entornos que se utilizan para protegerse contra vulnerabilidades como las secuencias de comandos entre sitios y la inyección de SQL. Este estándar se puede utilizar para establecer un nivel de confianza en la seguridad de las aplicaciones web.
Microsoft SDL.
Esta metodología se enfoca en el desarrollo de software seguro y se basa en tres conceptos básicos: capacitación, mejora continua de procesos y rendición de cuentas. Debido a que los riesgos de seguridad no son estáticos, SDL enfatiza la importancia de comprender las causas y las implicaciones de las vulnerabilidades de seguridad, con evaluaciones y ajustes regulares del proceso para responder a los avances tecnológicos y las amenazas emergentes. 
 Los datos se recopilan para evaluar la eficacia de la capacitación, las métricas de proceso se utilizan para documentar el cumplimiento y las métricas posteriores al lanzamiento ayudan a definir cambios futuros. SDL necesita archivar todos los datos necesarios para mantener la aplicación en caso de problemas. El modelo de optimización de SDL se centra en cinco áreas de rendimiento que corresponden aproximadamente a las fases del ciclo de vida del desarrollo de software:
1)Formación, directivas y capacidades organizativas
2) Requisitos y diseño
3) Implementación
4) Comprobación
5) Lanzamiento y respuesta
2.3. Pruebas de Seguridad.
Los desarrolladores de aplicaciones ejecutan pruebas de seguridad como parte del proceso de desarrollo para asegurarse de que las versiones nuevas o actualizadas de sus aplicaciones sean vulnerables. Una auditoría de seguridad puede garantizar que su aplicación cumpla con ciertos estándares de seguridad. Si su aplicación pasa la auditoría, el desarrollador debe permitir que solo los usuarios autorizados puedan acceder a ella. Los desarrolladores piensan como ciberdelincuentes en las pruebas de penetración y buscan formas de entrar en su aplicación.
Las pruebas de penetración pueden incluir ingeniería social e intentos de engañar a los usuarios para que permitan el acceso no autorizado. Los auditores suelen realizar escaneos de seguridad autenticados y no autenticados para detectar vulnerabilidades que pueden no existir en ambos estados. Estas pruebas se pueden dividir en dos tipos: pruebas SAST y pruebas DAST.
Pruebas Estáticas de Seguridad de Aplicaciones (SAST).
Las pruebas de seguridad estáticas pueden ayudarlo a analizar los archivos de origen de su aplicación, determinar la causa del problema y corregir las vulnerabilidades de seguridad subyacentes. Estas pruebas identifican y eliminan vulnerabilidades de código fuente, binario o byte, acceden a recomendaciones para verificar resultados de análisis estáticos en tiempo real y navegan cada línea de código en busca de vulnerabilidades. La ventaja es que puede descubrir más rápidamente y realizar una auditoría conjunta. Además de la integración en el entorno de desarrollo.
Pruebas Dinámicas de Seguridad de Aplicaciones (DAST).
Las pruebas de seguridad dinámicas simulan un ataque controlado en una aplicación o servicio web en ejecución para identificar vulnerabilidades que pueden explotarse en un entorno en ejecución. Este tipo de prueba tiene la ventaja de brindar una visión completa de la seguridad al centrarse en lo que se puede explotar y abarcar todos los componentes, como servidores, código y servicios. 
 Además de permitir el análisis de aplicaciones heredadas, las pruebas DAST brindan un enfoque más amplio para la gestión de riesgos de aplicaciones. Otra ventaja es que puede probar aplicaciones en ejecución, a diferencia de SAST, que no puede detectar problemas ambientales y de tiempo de ejecución.
2.4. Tipos de Ataques a Aplicaciones.
A continuación, se enlistan los principales ataques a aplicaciones, además de una breve explicación sobre el objetivo de cada uno de estos:
Cross-Site Request. 
Este ataque implica una falsificación de solicitud entre sitios, un tipo de explotación en la que los usuarios en los que confían los sitios web envían comandos maliciosos. A diferencia de las secuencias de comandos entre sitios, que abusan de la confianza de un usuario en un sitio en particular, explota la confianza del sitio en el navegador del usuario, lo que permite que el atacante actúe en nombre de la víctima como si él o ella lo hubiera hecho. realizar acciones. Este ataque es básicamente una falsificación digital de la identificación del usuario.
Inyección SQL. 
Este es uno de los ataques más populares a las aplicaciones web. Los piratas informáticos confían en las vulnerabilidades que pueden aparecer en el nivel de la base de datos de las aplicaciones web. Este código puede poner en riesgo esta herramienta, datos confidenciales, información, etc. Lógicamente, esto impedirá que el programa funcione correctamente. El atacante realiza inyección SQL porque modifica código previamente programado. Cambia las características principales que tiene.
Desbordamiento de buffer
Otro tipo de ataque se conoce como desbordamiento de búfer. Este es un problema en el que el proceso almacena datos en un búfer fuera de la memoria que el programador ha reservado para él. Este es otro tipo de amenaza muy común. Los datos adicionales sobrescriben la memoria que puede contener otros datos, incluidas las variables del programa y los datos de control de flujo del programa. Esto puede provocar errores de acceso a la memoria, resultados incorrectos, finalización del programa o violaciones de la seguridad del sistema. Tenga en cuenta que este tipo de vulnerabilidad puede estar presente en todo tipo de sistemas, aplicaciones y servidores. Implica enviar más datos de los que la aplicación espera recibir y hacer que falle.
Navegación forzada
En este caso, estamos ante un ataque cuyo objetivo es enumerar y acceder a recursos a los que la aplicación no hace referencia, pero que aún son accesibles. Podemos nombrar ejemplos de carpetas como configuración, copias de seguridad, registros accesibles y puede revelar mucha información sobre la aplicación en sí, contraseñas, actividades, etc. Este método es uno de los métodos más utilizados para comprometer la seguridad del servidor. Para controlar y modificar carpetas.
Hidden Manipulation
Consiste en manipular valores almacenados en un formulario web que, aparte de mostrarlos, no ofrece ninguna protección contra modificaciones. Es por eso que debes usarlo por seguridad. Podemos acceder a ellos mirando el código fuente del sitio web y manipulándolos de varias maneras.
Parameter tampering
Durante la autenticación, todas las operaciones se realizan en función de la identificación del usuario, que se envía en un formulario fácilmente editable.
Backdoor y debug options
Los implementadores utilizan aplicaciones con opciones o extensiones ocultas en el desarrollo de estas opciones y se han olvidado de eliminarlas.
Vulnerabilidades conocidas
El programa tiene un error. Si nuestra máquina no está actualizada, alguien que sepa lo que tenemos instaladopuede descubrir fácilmente cómo atacar.
Fuzzing 
Es una técnica sofisticada utilizada por investigadores de amenazas profesionales en un entorno de laboratorio para descubrir vulnerabilidades en interfaces y aplicaciones de hardware y software. Lo hace mediante la inyección de datos no válidos, no deseados o semialeatorios en una interfaz o programa y luego monitorea eventos como bloqueos, transferencias no documentadas para depurar el proceso, la aserción del código falla y puede haber una pérdida de memoria.
3. Desarrollo.
En esta parte del proyecto se desarrollará el componente practico de la teoría anteriormente expuesta, el siguiente ejercicio es un ataque de buffer overflow a una aplicación vulnerable llamada FreeFloat FTP Server en la que se busca controlar las instrucciones que ejecutara mediante el desbordamiento de sus registros EIP y ESP. Para la ejecución de este ejercicio se utilizó una máquina virtual de Kali Linux desde la cual se transmitió el ataque y una máquina virtual Windows en la cual se estaba ejecutando la aplicación vulnerable. A continuación, se presenta la evidencia del ejercicio.
3.1. Presentación de Evidencias.
Para iniciar con esta práctica primero debemos conocer la dirección IP de ambas maquinas, en el caso de la maquina Kali Linux se ejecuta el código “ifconfig” en la terminal de comandos para obtener la dirección.
Imagen 1. Identificación de dirección IP (Kali Linux)
Posteriormente pasamos a la máquina virtual Windows para ejecutar la aplicación vulnerable y al igual que en la anterior conocer su dirección IP, en este caso la aplicación por atacar muestra la dirección IP de la máquina, en el caso de que no fuera visible simplemente basta con abrir la terminal de comandos de Windows y ejecutar la instrucción “ipconfig” para conocerla dirección IP de esta máquina.
Imagen 2. Identificación de dirección IP (Windows)
El siguiente paso es abrir un debugger en Windows para observar el comportamiento de la aplicación con cada ataque, en este caso la aplicación utilizada es ImmunityDebugger.
Imagen 3. ImmunityDebugger.
Teniendo ambas direcciones procedemos a comprobar que exista comunicación entre las maquinas mediante la transmisión de un ping de Kali a Windows y como se puede observar en la siguiente imagen existe comunicación.
Imagen 4. Prueba de comunicación entre maquinas.
Puesto que ya sabemos que existe comunicación entre ambas partes, el siguiente paso es la creación de un pequeño script para empezar con el ataque, con este programa buscamos conocer la cantidad de datos necesaria para hacer que el programa presente problemas.
Imagen 5. Programa de Fuzzing.
Al ejecutar el programa podemos observar que la aplicación vulnerable tiene problemas cuando le enviamos entre 300 y 400 bytes.
Imagen 6. Envió de 1er script
Con la anterior información procedemos a visualizar que sucedió con la aplicación en el debugger, en este encontramos que el programa se detuvo y en el registro EIP se almacenaron los datos enviados en el script, los cuales son el carácter “A” expresado en el registro EIP como “41414141”.
Imagen 7. Registro EIP con carácter enviado
Debido a que sabemos que el programa presenta fallas después de 300 bytes, procedemos a generar un patrón con esta dimensión para enviarlo en el script creado anteriormente.
Imagen 8. Creación de patrón.
Nuevamente volvemos al debugger y en esta ocasión encontramos que en el registro EIP se encuentran una serie de caracteres que nos servirán para conocer el valor de offset del registro.
Imagen 9. Caracteres para el offset
Como se menciona anteriormente con el valor del registro EIP volvemos a Kali y obtenemos el valor exacto del offset mediante el comando “msf-pattern_offset -q“ y el valor de EIP (34694133), posteriormente en el script eliminamos la sección correspondiente al patrón anterior puesto que ya no es necesaria, agregamos este valor en la cantidad de veces que se enviara el carácter “A” y añadimos el carácter “B” en la cadena para comprobar que el programa funcione como se espera.
 
 Imagen 10. Obtención de Offset Imagen 11. Carácter “B” en registro EIP.
Al observar que el registro EIP tiene los caracteres que establecimos en el script, confirmamos que se tiene el control de este registro, ahora necesitamos enviar otro arreglo de caracteres para buscar tomar el control del registro ESP, en este caso obtuve el arreglo de caracteres de una página web y únicamente fue necesario eliminar los caracteres \x0a y \x0d, puesto que el carácter \x00 no venía por defecto y no fue necesario retirarlo..
Imagen 12. Arreglo de caracteres.
Al enviar nuevamente el script, pero con el anterior arreglo vemos que todos los caracteres fueron validos y almacenados en el registro ESP.
Imagen 13. Comprobación de caracteres validos
El siguiente paso es buscar alguna instrucción en el código de la aplicación que nos permita dar un salto al registro ESP, para esto empleamos un modulo del debugger llamado Mona, después de buscar los módulos ejecutables encontramos que el módulo “Shell32” nos permite dar el salto que buscamos.
Imagen 14. Herramienta Mona
Al seleccionar el modulo nos dirigimos al código en donde se encuentra la instrucción y comprobamos que esta nos permite saltar al registro ESP, posteriormente agregamos esta “dirección” a la cadena en el script.
Imagen 15. Instrucción JMP ESP.
A continuación, generamos el arreglo final para el reverse Shell indicando la dirección IP de la maquina Kali, el puerto al que se recibirá la transmisión.
Imagen 16. Generación del código Shell reverso.
Imagen 17. Script final.
Finalmente ejecutamos el script y abrimos otra ventana desde la cual obtendremos la respuesta con la herramienta Netcat, arrojando la siguiente información, dando por finalizado el ejercicio.
Imagen 18. Información Final.
4. Conclusiones.
Con este trabajo concluye el curso de Seguridad de Sistemas y Aplicaciones impartido por el Dr. Alejandro Gómez Ramos perteneciente a la Maestría en Seguridad de Tecnologías de la Información en donde aprendí nuevos conceptos, técnicas, herramientas y normas para la protección de las aplicaciones, me fue de gran ayuda las practicas realizadas durante las sesiones presenciales, porque me ayudaron a comprender la parte teórica de las investigaciones previas y de la información proporcionada por el profesor. Al iniciar el curso cuando revise la carta descriptiva pensé que esta clase sería muy teórica, enfocada en el diseño de software y no tanto en la seguridad, pero afortunadamente no fue así, me pareció más interesante y productivo aprender las técnicas de ataque a las aplicaciones que vimos como la ingeniería inversa y el fuzzing.
Los ejercicios prácticos que vimos durante este curso me gustaron mucho porque me fueron de mayor utilidad en comparación con las investigaciones que realice, aunque me falta mucho por practicar para mejorar mis habilidades, este curso fue un muy buen punto de entrada a estas actividades que tienen muchas formas de aplicar el conocimiento, como vimos en la primera sesión, cuando el profesor hackeo un videojuego para obtener beneficios en el mismo, este ejercicio me pareció especialmente interesante porque yo suelo jugar y me he dado cuenta que en algunos juegos existe mucho este problema en donde otros jugadores hackean la aplicación para tener ventaja sobre los demás, al ver lo “fácil” con que el profesor hackeo un juego en poco tiempo me hace cuestionarme que clase de trabajo realizan los desarrolladores de estas aplicaciones, siendo que la mayoría de estos son de pago alcanzando precios de mas de $1,000 Mxn y resultando que no son seguros y casi cualquier persona con estos conocimiento pueda vulnerar una aplicación tan fácilmente.
Al igual que en el caso de los videojuegos muchas otras aplicaciones que son de pago no son seguras y en la gran mayoría de ellas usualmente incluimos información personal e incluso datos de cuentas bancarias, lo que hace preguntarme hasta quenivel de seguridad existe en esas aplicaciones, ¿Qué tan seguros están nuestros datos personales? Otro caso de seguridad en aplicaciones que me genero dudas con respecto a nuestra privacidad y el tratamiento de nuestros datos personales es el uso de los asistentes virtuales y muchos otros dispositivos IoT, puesto que realmente la gran mayoría de los usuarios no sabemos que es lo que hacen, por lo que deberíamos por lo menos revisar que tantos privilegios les damos a estos dispositivos.
Para finalizar con este proyecto concluyo que el ejercicio realizado me fue de mucha ayuda con el pude emplear los conceptos adquiridos durante el curso, además de hacer que tenga ganas de seguir practicando para mejorar mis habilidades y que un futuro cercano las pueda aplicar en el ámbito laboral, identificando vulnerabilidades el sistemas y aplicaciones para mejorar su seguridad.
5. Referencias.
MicroFocus. (s. f.). What is Application Security? microfocus.com. https://www.microfocus.com/es-es/what-is/application-security
¿Qué es la seguridad de las aplicaciones? | Glosario de VMware | LATAM
Confederación de Empresarios de la Coruña. (2020, 20 marzo). ISO/IEC 27034: Estándar Internacional para la seguridad de las aplicaciones | noticias.cec.es. noticias.cec.es. https://noticias.cec.es/index.php/2020/03/20/isoiec-27034-estandar-internacional-para-la-seguridad-de-las-aplicaciones/
Ciberseguridad. (2020, 24 enero). OWASP – Seguridad en la web. https://ciberseguridad.com/guias/desarrollo-seguro/owasp/
Microsoft SDL - Security Development Lifecycle. (s. f.). SeguridadIt. https://seguridadit.blogspot.com/2012/01/microsoft-sdl-security-development.html
Jiménez, J. (2021, 19 julio). Todos los ataques a aplicaciones web de los servidores. RedesZone. https://www.redeszone.net/tutoriales/seguridad/principales-ataques-aplicaciones-web-servidores/
Identifying Bad Characters Manually. (2019, 14 septiembre). Ins1gn1a. https://www.ins1gn1a.com/identifying-bad-characters
2

Continuar navegando