Modulo Seguridad en Aplicaciones Web 2012 1

1UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web SEGURIDAD EN APLICACIONES WEB 233008 CONTENIDO DIDACTICO DEL CURSO Elaborado por: Ing. Carlos Alberto Amaya Tarazona DUITAMA (Boyacá). Enero de 2013 2 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web ASPECTOS DE PROPIEDAD INTELECTUAL Y VERSIONAMIENTO GUÍA DIDÁCTICA Autor: Carlos Alberto Amaya Tarazona Ingeniero de Sistemas Magister en Software Libre y Admi ni stración de Redes y sistemas Operativos COMITÉ DIRECTIVO Jaime Alberto Leal Afanador Rector Gloria Herrera Vicerrectora Académica y de Investigación Roberto Salazar Ramos Vicerrector de Medios y Mediaciones Pedagógicas Gustavo Velásquez Decano Escuela de Ciencias Básicas Tecnología e Ingeniería Celia del Carmen López Secretaria Académica Escuela de Ciencias Básicas Tecnología e Ingeniería Al exandra Aparicio Coordinadora Nacional Ingeniería de Sistemas. CURSO SEGURIDAD EN APLICACIONES WEB MATERIAL ACADEMICO Pri mera Edición @Copy Right Uni versidad Nacional Abierta y a Distancia ISBN 2005 Centro Nacional de Medios para el aprendizaje 2008 Actualización: No aplica 3 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web CONTENIDO Pág INTRODUCCION: 9 UNIDAD I: INTRODUCCION A LA SEGURIDAD EN APLICACIONES WEB 11 CAPITULO 1: CONCEPTOS BÁSICOS DE SEGURIDAD EN 11 APLICACIONES WEB Lección 1: INTRODUCCION AL PROTOCOLO HTTP 14 1.1 Características y Funcionamiento 15 1.2 Análisis de una cabecera HTTP 16 1.3 Métodos HTTP 19 1.4 Codificación de la Información 21 Lección 2: VULNERABILIDADES EN APLICACIONES WEB 22 2.1 Como trabajan las aplicaciones web 22 2.2 Arquitecturas mas complejas 23 2.3 Proyecto OWASP y las Vulnerabilidades en Aplicaciones Webs 25 2.4 Sniffeo y codificación de cabeceras 27 2.5 Inyectando código 28 2.6 CR/LF Injections 28 2.7 XSS y SQL Injections 29 2.8 PHP Injections 30 2.9 Banner Grabbing 31 2.10 HTTP Fingerprinting 32 Lección 3: HERRAMIENTAS PARA LA DETECCIÓN DE VULNERABILIDADES 35 3.1 Fiabilidad de los Analizadores Automáticos de Vulnerabilidades 35 3.2 Ventajas y Beneficios 36 3.3 Inconvenientes y Desventajas 37 3.4 Criterios de valoración para herramientas de seguridad web 38 3.4.1 Herramientas Comerciales 38 3.4.2 Herramientas de Código abierto 39 3.4.3 Herramientas de auditoría aplicadas a SQL Injection 40 3.4.4 Herramientas de auditoría aplicadas a XSS (Ataques de Cross-Site Scripting) Lección 4: MITOS EN LA SEGURIDAD WEB 43 4.1 Auditoría y control de vulnerabilidades 45 4.2 Puntos débiles 45 4.3 Tipos de Escaners 46 Lección 5: SISTEMA DE LOGS 46 5.1 Formato del fichero de LOG 47 4 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 5.2 Análisis del fichero de LOG 48 5.3 Programas de análisis de LOGS 49 CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB 49 Lección 6: TIPOS DE ANALISIS 51 6.1 Metodologías de análisis de seguridad web 51 Lección 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB 52 Lección 8: AUTENTICACION Y AUTORIZACION 53 8.1 La Autenticación 53 8.2 La Autorización 55 Lección 9: EJ ECUCION DE INSTRUCCIONES DE ACCESO 55 9.1 Codificación y las validaciones de Entrada / Salida 55 9.2 Gestión de sesiones y usuarios 56 9.3 Gestión de errores y excepciones 57 Lección 10: CONFIGURACION SEGURA DE SERVIDORES 58 10.1 Organización del servidor Web 58 10.2 Organización de las aplicaciones Web 59 CAPITULO3: DESARROLLO SEGURO DE APLICACIONES 60 Lección 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO 60 DE APLICACIONES 11.1 Normas básicas de seguridad 62 Lección 12: CONTROLES DE AUTORIZACION DE OBJ ETOS 64 12.1 Listas de control de acceso (ACL) 66 12.1.1 Configuración de las ACL 67 12.1.2 Funciones de la ACL 67 Lección 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES 67 13.1 Exposición de datos 68 13.2 Páginas privadas y los sistemas de autenticación 68 13.3 Ataques de fuerza bruta 68 13.4 Espionaje de contraseñas (Password sniffing) 69 13.5 Registros persistentes 70 Lección 14: VALIDACION DE ENTRADAS 70 5 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Lección 15: SQL INJ ECTION 72 15.1 Variantes de sintaxis 77 15.2 Otras clases de Inyección 77 UNIDAD 2: ANALISIS Y DISEÑO SEGURO DE APLICACIONES WEB 78 CAPITULO 4: AREAS CRITICAS DE DESARROLLO 78 Lección 16: SECUENCIAS DE COMANDOS EN SITIOS CRUZADOS (XSS) 78 16.1 Tipos de vulnerabilidades XSS 78 Lección 17: PERDIDA DE AUTENTICACION Y GESTION DE SESIONES 81 Lección 18: REFERENCIA DIRECTA INSEGURA A OBJ ETOS 83 Lección 19: ALMACENAMIENTO CRIPTOGRAFICO INSEGURO 84 Lección 20: RESTRICCIONES DE ACCESO A URL 86 CAPITULO 5: CICLO DE VIDA DE DESARROLLO SEGURO DEL SOFTWARE (SDLC) Lección 21: INTRODUCCION A SDLC 88 Lección 22: Fases de SDLC 89 22.1 Seguridad en la fase de análisis 90 22.2 Seguridad en la etapa de diseño 91 22.3 Seguridad en la codificación 92 22.4 Seguridad en la etapa de pruebas 93 22,5 Seguridad en la implementación 94 Lección 23: SDLC-IT 95 Lección 24: APLICACIÓN DE SDLC 99 Lección 25: OTRAS VULNERABILIDADES QUE AFECTAN SDLC 101 25.1 Vulnerabilidades de la capa de transporte 102 25.2 Origen de las vulnerabilidades 103 25.3 Herramientas de monitoreo 104 25.4 Sistema de detección de intrusos 105 25.5 Tipos de IDS 105 25.6 Herramientas de gestión 107 CAPITULO 6: ATAQUES DE DENEGACION DE SERVICIO (DDoS) APLICACIONES WEB Lección 26: DENEGACION DE SERVICIO (DoS) / (DDoS) 109 6 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 26.1 Denegación De Servicio Distribuido: DDoS 110 26.2 Denegación De Servicio Distribuido: DDoS 111 26.3 Plataformas afectadas 112 26.4 Caracterización de los ataques DoS 112 26.4.1 Uso de IP Source Spoofing 112 26.4.2 Similitud de tráfico legítimo 113 Lección 27: FASES PREVIAS A LA REALIZACION DEL ATAQUE 114 27.1 Actividades previas al ataque (DoS) 114 27.2 Topología o distribución física 115 27.3 Función de ICMP en los ataques DoS 116 27.4 Descubrimiento de usuarios 119 27.5 Información del Dominio 119 Lección 28: FINGERPRINTING 120 28.1 Transmisión en el protocolo de control 120 28.2 Exploración de puertos 122 28.2.1 Exploración de puertos UDP 123 28.2.2 Escaneo basado en el protocolo ICMP 124 28.3 Fragmentación IP 125 Lección 29: TIPOS DE ATAQUES 129 29.1 ATAQUE TCP/SYN Flooding: 129 29.2 Ataque Broadcast IP Flooding 133 29.3 Smurf 134 29.4 STeardrop 134 29.5 Snork 136 29.6 Ataque Distribuido TRINOO /TRIN00 137 Lección 30: HERRAMIENTAS QUE AYUDAN A PREVENIR ATAQUES DoS 139 GLOSARIO DE TERMINOS 143 ANEXOS 152 FUENTES DOCUMENTALES 153 7 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LISTADO DE TABLAS Pág Tabla 1: Códigos de estado en HTTP 20 Tabla 2: Propiedades de los controles de validación 65 Tabla 3: Tipos de Amenazas 103 Tabla 4: Mensajes y códigos del protocolo ICMP 118 Tabla 5: Escenario para un ataque DoS TCP/SYN Flooding 131 Tabla 6: Descripción de los parámetros del ataque TCP/SYN Flooding 132 Tabla 7: Herramientas de gestión que ayudan a detectar ataques DoS 141 Tabla 8: Herramientas utilizadas 142 LISTADO DE FIGURAS Pág Figura 1: Niveles superiores de OSI. Origen de vulnerabilidades en sitios 13 web Figura 2: Tecnologías y protocolos de red modelo OSI 14 Figura 3: Operaciones de solicitud – respuesta con HTTP 16 Figura 4: Análisis de cabeceras HTTP 18 Figura 5: Niveles de comunicación en aplicaciones web 22 Figura 6: Arquitectura de cuatro capas en aplicaciones web 24 Figura 7: OWSP Top 10 – 2013 26 Figura 8: Banner detección FTP 31 Figura 9: Banner grabbing por método HEAD 32 Figura 10: Uso de un “Escucha de Red” para hallar huellas identificativas 33 de un host en la red Ethernet Figura 11: Uso de un “Escucha de Red” para hallar huellas identificativas 34 de un host remoto Figura 12: Funciones de auditoría en escáneres de aplicaciones web. 39 Herramientas comerciales Figura 13: de auditoría en escáneres de aplicaciones web. 40 Herramientas de código Figura 14: Funciones de auditoría en escáneres de aplicaciones 41 web para SQL Injection Figura 15: Funciones de auditoría en escáneres de aplicaciones 42 web para XSS Figura 16: Categoría de Vulnerabilidades 44 Figura 17: Formato de fichero de Logs 47 Figura 18: Metodología de desarrollo seguro 61 Figura 19: Filtrado de paquetes con ACL 66 Figura 20: Formulario de validación de datos 76 Figura 21: Pérdida de Autenticación 82 8 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 22: Almacenamiento criptográfico inseguro 86 Figura 23: Relación costo – tiempo en el desarrollo de aplicaciones web 88 Figura 24: SDLC 90 Figura 25: Escenario de un Ataque de Denegación de servicio (DoS) 110 Figura 26: Escenario de un Ataque de Denegación de servicio Distribuído 111 Figura 27: Estructura de un datagrama IP V 4.0 115 Figura 28: Estructura de un mensaje ICMP 116 Figura 29: Cabecera de un datagrama ICMP 117 Figura 30: Topología de una red genérica 120 Figura 31: Mecanismo de tres vías 121 Figura 32: Datagrama IP No fragmentado 126 Figura 33: Datagrama IP de 4028 fragmentado con MTU de 1500 bytes 127 Figura 34: Reensamblado de frames en Wireshark 128 Figura 35: Fragmentación y Reensamblado de 4028 bytes con una MTU 128 de 1500 bytes. Analizado en Wireshark Figura 36: Fragmentación Reensamblado TCP. Diagrama Flow Graph 129 Figura 37: Escenario para un ataque DoS TCP/SYN Flooding 130 Figura 38: Ataque Broadcast IP Flooding 133 Figura 39: Ataque Smurf 134 Figura 40: Cabecera Paquete IP V 4.0. 135 Figura 41: Ataque DoS Snork 136 Figura 42: Ataque DDoS TRIN00 138 Figura 43: Esquema de comunicaciones de TRIN00 139 9 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web INTRODUCCIÓN Tanto el auge de internet , las Telecomunicaciones, el mundo digital y todo lo que engloba el manejo de datos, han tenido un crecimiento significativo , exponencial y paralelos a las temáticas que tienen que ver con la privacidad formación tanto personal como profesional. En la web encontramos funcionando a tiendas en línea, redes sociales, negocios que mueven grandes cantidades de dinero, redes de los servicios que habilitan el comercio a nivel internacional que contienen información muy delicada de la vida privada de sus miembros. Para dar inicio a este universo de la privacidad y seguridad de la información que en la web viaja, el presente contenido académico hace relevancia a la necesidad de implementar procedimientos seguros cuando se desarrollan aplicaciones web para compartir y publicar información pueden haber muchos puntos de vista pero uno de los más más críticos de la seguridad del Internet, lo tienen las piezas que intervienen de forma directa con las masas de usuarios, los servidores web. Para poder abordar el siguiente contenido académico, es necesario tener como base muchos de los conceptos de seguridad abordados en redes de telecomunicaciones, sistemas operativos e informática forense. Es por ello que el tema de seguridad se debe asimilar como un engranaje en el que intervienen muchas áreas y técnicas cuando se trata de proteger la integridad de la información y la privacidad de los datos de los usuarios.- El contenido que a continuación se presenta aborda los conceptos y mecanismos fundamentales para la detección de vulnerabilidades en aplicaciones web, en las que primero se incluyen temáticas básicas introductorias pero específicas al diseño de aplicaciones web seguras, para luego tratar con los protocolos de seguridad más usados en aplicaciones web. Las áreas críticas del diseño de aplicaciones web demostrarán que van desde la misma infraestructura en telecomunicaciones, el entorno de implementación, hasta el código c y los lenguajes de programación usados para la puesta en marcha de las aplicaciones web. Todo es parte de un ciclo de vida de desarrollo web pero teniendo en cuanta aspectos de seguridad que protegen la forma y el fondo de las aplicaciones.- No se trata de diseñar y de implementar aplicaciones que solo den una buena imagen y gusto al cliente, sino también aspectos de seguridad que minimicen el riesgo de pérdida de información o de manipulación de la misma. 10 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web En cuanto a la utilidad práctica de estos contenidos, alcanza a llevar a que el estudiante sea competente en la identificación de diseños inseguros en aplicaciones web y que lo lleve a proponer mejoras o planes de contingencia que reduzcan el riesgo. El módulo, no pretende conceptualizar ni ejercitar al estudiante en el proceso de implementación de servidores web o soluciones tipo LAMP 1 , ó WAMP 2 Finalmente el contenido de este módulo, se encuentra referenciado y apoyado al proyecto OWASP (The Open Web Application Security Project), , ni ahondarnos en el desarrollo web, que deben ser competencias previas como presaberes a estos contenidos. Tampoco es posible llegar a la práctica o demostración de cada herramienta que detecte vulnerabilidades o demostrar cada riesgo. Estos son aspectos Técnicos que se aplican de forma operativa y el curso entiéndase tiene un carácter académico investigativo que lleva al estudiante a formular diseños propios, soluciones y análisis de todas las herramientas y que lo lleven a detectar vulnerabilidades y controlarlas. Durante el desarrollo del aula, se ejercitarán prácticas que en lo posible toquen cada tema expuesto en los contenidos de este módulo. 3 1 Disponible en internet desde <http://www.lamphowto.com/> 2 Disponible en internet desde <http://www.wampserver.com/en/> 3 Disponible en internet desde <https://www.owasp.org/index.php/Main_Page> como un grupo de expertos en temas de desarrollo y seguridad con las intensiones de plantear proyectos que a su vez trabajaran en temas de seguridad de aplicaciones, buenas prácticas para desarrollo seguro, pruebas de seguridad para software entre otros. Muchas referencias, actividades y experiencias en la temática de aplicaciones web, están apoyadas en este proyecto. 11 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web PRIMERA UNIDAD INTRODUCCION A LA SEGURIDAD EN APLICACIONES WEB CAPITULO I 1. CONCEPTOS BÁSICOS DE SEGURIDAD EN APLICACIONES WEB : El enfoque dado a los contenidos, pretende confrontar “Mitos” que se tienen cuando se tratan vulnerabilidades de aplicaciones web. Uno de ellos es el de no contemplar entornos y escenarios externos, topologías, otras capas del modelo OSI, protocolos y servicios. La seguridad tiene que verse como un todo, en donde cualquier variable puede afectar lo menos pensado. Es por ello que no solo se trata de identificar riesgos en aplicaciones web sino también en los equipos (computadores, servidores) que las soportan, las redes por donde viajan los datos y los servicios que los sistemas operativos y las aplicaciones ofrecen. Para dar inicio a este curso que trata los temas de la privacidad y seguridad de la información que en la web viaja, el presente contenido académico hace relevancia a la necesidad de implementar procedimientos seguros cuando se desarrollan aplicaciones web para compartir y publicar información pueden haber muchos puntos de vista pero uno de los más críticos de la seguridad del Internet, lo tienen las piezas que intervienen de forma directa con las masas de usuarios, los servidores web No se deja a un lado la seguridad perimetral ni de la infraestructura de telecomunicaciones, que desde las capas inferiores del modelo OSI deben contemplar los diseñadores, programadores y administradores de sistemas, hasta las capas superiores, pero si se enfoca este material a que el lector pueda determinar los aspectos funcionales en diseño, arquitectura, conceptualización e implementación de aplicaciones web que medianamente puedan ser seguras o que estén enmarcadas en su implementación dentro de un protocolo y estándar de funcionamiento medianamente seguro. Respecto a los servidores web, es común escuchar sobre fallas en los sistemas de protección de los servidores más frecuentemente utilizados: 12 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Apache: Este es el más común y más utilizado en todo el mundo. Además, es gratuito y de código abierto, así que se podría decir que corre sobre cualquier plataforma 4 Microsoft IIS: Su proveedor es Microsoft, y como servidor de aplicaciones web ha tenido randes avances en seguridad y en servicios. 5 Tomcat: Servidor web también llamado J akarta Tomcat. Funciona como un contenedor de servelets desarrollado bajo el proyecto J akarta en la Apache Software Foundation. Tomcat. implementa las especificaciones de los servelets y de J avaServer Pages (J SP) de Sun Microsystems. 6 Sun Java System Web Server: Este producto pertenece a la casa Sun, y suele empalarse sobre entorno de este sistema. Sin embargo, como Apache, es multiplataforma, y recientemente Sun ha decidido distribuirlo con licencias de código abierto (BSD concretamente). 7 Ngnix: Este es un servidor Web muy ligero y corre sobre sistemas Unix y Windows. Se ha convertido en el 4º servidor HTTP más popular de la red y también se distribuye bajo licencia BSD. 8 Lighttp: Este servidor Web es otro de los más ligeros que hay en el mercado. Está especialmente pensado para hacer cargas pesadas sin perder balance, utilizando poca RAM y poca de CPU. Algunas páginas populares que lo usan son Youtube, Wikipedia y otras que soportan gran tráfico diariamente. También es gratuito y se distribuye bajo licencia BSD. 9 El material aquí abordado referencia la mayoría de los problemas de seguridad en los sitios web que tienen su origen en los niveles superiores del modelo OSI a nivel de aplicación (Ver figura 1) y que son el resultado de escritura defectuosa de código, que por lo general viene motivada por aspectos de forma en los que el diseñador le importa cómo se vea un sitio web o una aplicación y que tan llamativo y cautivador para el cliente puedan ser, pero no se detallan aspectos de forma en cuanto a seguridad; debemos entender que programar aplicaciones web seguras O en los lenguajes de programación en los que son escritas las aplicaciones que son ejecutadas por estos servidores. Es de reconocer, que la mayoría de los problemas de vulnerabilidad detectados en servicios web no son provocados por fallas intrínsecas de ninguna de estas partes, ya que una gran cantidad de los problemas se generan por malos usos por parte de los programadores. 4 Disponible en internet dese <http://httpd.apache.org/> 5 Disponible en internet desde <http://www.iis.net/> 6 Disponible en internet desde <http://tomcat.apache.org/> 7 Disponible en internet desde <http://docs.oracle.com/cd/E19146-01/index.html> 8 Disponible en internet desde <http://nginx.org/en/> 9 Disponible en internet desde <http://www.lighttpd.net/> 13 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web no es una tarea fácil, ya que requiere por parte del programador, no únicamente mostrar atención en cumplir con el objetivo funcional básico de la aplicación, sino una concepción general de los riesgos que puede correr la información contenida, solicitada y recibida por el sistema. No quiere decir esto que en los demás niveles no se presenten amenazas y vulnerabilidades que afecten a los sitios web. E la Lección 25, trataremos aspectos de seguridad en otros niveles y protocolos de la capa OSI que afectan aplicaciones web. Figura 1: Niveles superiores de OSI, orígenes de vulnerabilidades en sitios web Fuente: El autor En la figura1, se puede identificar los niveles superiores del modelo OSI donde son típicas las vulnerabilidades en aplicaciones web. En la actualidad, aunque existen muchos documentos, publicaciones, estudios basados en prueba y error, comunidades de desarrollo sobre todo en código abierto (comunidades libres), que permiten formar un criterio sobre el tema, no existen acuerdos básicos sobre lo que se debe o no se debe hacer, y lo que en algunas publicaciones se recomienda, en otras es atacado. Sin embargo, en lo sustancial sí existen algunas recomendaciones que son generales y serán las que describo en este documento junto con los ataques más comunes a aplicaciones web y las técnicas de defensa a las inicialmente el profesional puede aplicar en primera instancia. Es tarea del profesional que aborde estas temáticas, que 14 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web defina su estrategia de diseño e implementación segura de sus aplicaciones web basado en experiencias como las que presenta este módulo y comparto. En el contenido de este escrito, se tratan temas esenciales de seguridad que se suelen encontrar en las aplicaciones PHP, además se remiten ejemplos y estrategias para evitar cometer los mismos errores, si bien, la mayoría de los problemas (sino es que todos) revisados serán para código PHP, los mismos consejos suelen aplicar para otros lenguajes de tecnologías similares que por lo mismo enfrentan problemas parecidos y cuya solución es la misma, sólo con las variantes propias del lenguaje. LECCION 1: INTRODUCCION AL PROTOCOLO HTTP: El modelo TCP/IP cuenta con diversos protocolos en su capa de aplicación: HTTP, SMTP y FTP son tres de los más importantes. En principio, cualquiera de ellos puede ser utilizado para la transferencia de mensajes SOAP pero HTML es el protocolo estándar para la web y el más usado en los servicios web XML. En la figura 2 se observa los protocolos que actúan en las respectivas capas del modelo OSI. Todos los protocolos presentan deficiencias en su diseño y por tanto ofrecen de alguna forma vulnerabilidades que afectan las características de seguridad de una aplicación web (integridad, disponibilidad, confidencialidad). Figura 2: Tecnologías y protocolos de red modelo OSI Fuente: El autor 15 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los clientes web y los servidores HTTP. Es un protocolo del nivel de aplicación usado para la transferencia de información entre sistemas, de forma clara y rápida. Este protocolo ha sido usado por el World- Wide Web desde 1990. La especificación completa del protocolo HTTP/1.0 está recogida en el RFC 1945. 10 10 Disponible en internet desde <http://www.freesoft.org/CIE/RFC/1945/index.htm> Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información como el World Wide Web. El protocolo HTTP se basa en un paradigma de peticiones y respuestas. Un cliente envía una petición en forma de método, una URI, y una versión de protocolo seguida de los modificadores de la petición de forma parecida a un mensaje MIME, información sobre el cliente y al final un posible contenido. El servidor contesta con una línea de estado que incluye la versión del protocolo y un código que indica éxito o error, seguido de la información del servidor en forma de mensaje MIME y un posible contenido 1.1 CARACTERISTICAS Y FUNCIONAMIENTO Desde el punto de vista de las comunicaciones, HTTP se establece sobre la capa de conexión TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexión de los clientes web. Una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores. HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto web es identificado por su URL. La figura 3 muestra estas sencillas operaciones de diálogo que genera HTTP cuando se lanza una solicitud de servicio a una aplicación web. 16 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 3: Operaciones de solicitud - respuesta con HTTP Fuente: El autor Se detalla a continuación las principales características del protocolo HTTP: • Toda la comunicación entre los clientes y servidores se realiza a partir de caracteres US-ASCII de 7 bits. • Permite la transferencia de objetos multimedia, codificando los archivos binarios en cadenas de caracteres. El contenido de cada objeto intercambiado está identificado por su clasificación MIME. • Existen ocho verbos que permiten que un cliente pueda dialogar con el servidor. Los tres más utilizados son: GET, para recoger un objeto, POST, para enviar información al servidor y HEAD, para solicitar las características de un objeto (por ejemplo, la fecha de modificación de un documento HTML). 17 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web • Cada operación HTTP implica una conexión con el servidor, que es liberada al término de la misma. Es decir, en una operación se puede recoger un único objeto. Con la versión HTTP 1.1 se ha mejorado este procedimiento, permitiendo que una misma conexión se mantenga activa durante un cierto periodo de tiempo de forma que sea utilizada en sucesivas transacciones. Este mecanismo, denominado HTTP Keep Alive, es empleado por la mayoría de los clientes y servidores modernos. • No mantiene estado. Cada petición de un cliente a un servidor no es influida por las transacciones anteriores. El servidor trata cada petición como una operación totalmente independiente del resto. • Cada objeto al que se aplican los verbos del protocolo está identificado a través de un localizador uniforme de recurso (URL) único. Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes pasos: 1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola directamente en el navegador. 2. El cliente web descodifica la URL, separando sus diferentes partes. Así identifica el protocolo de acceso, la dirección DNS o IP del servidor, el puerto (de carácter opcional; el valor por defecto es 80) y el objeto requerido del servidor. 3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente. 4. Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD,…), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada y un conjunto variable de información, que incluye datos sobre las capacidades del navegador, datos opcionales para el servidor, etc. 5. El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de dato MIME de la información de retorno, seguido de la propia información. 18 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 6. Se cierra la conexión TCP. Si no se utiliza el modo HTTP Keep Alive, este proceso se repite para cada acceso al servidor HTTP. El diálogo con los servidores HTTP se establece a través de mensajes formados por líneas de texto, cada una de las cuales contiene los diferentes comandos y opciones del protocolo. Solo existen dos tipos de mensajes, uno para realizar peticiones y otro para devolver la correspondiente respuesta. 1.2 ANALISIS DE UNA CABECERA HTTP: Realizando una petición HEAD al sitio web www.unad.edu.co como se muestra en la figura 4, identificaremos las cabeceras HTTP. El ejercicio se realiza desde una sesión de consola en un sistema operativo BackTrack 5 con permisos de root y accediendo a la web mediante una conexión ADSL sin restricciones o puertas traseras “firewalls” configurados y sin restricción de puertos. Figura 4: Análisis de cabeceras HTTP Fuente: El autor Al realizar la petición al sitio web, el servidor nos manda el código de respuesta [2] 200. Los códigos de rango 2xx indican que la operación se ha realizado con éxito, Cache-Control: Genera las directivas que deben ser usadas por cualquier mecanismo a lo largo de la petición/respuesta. Connection: Indica que la conexión se cierra, no se mantiene como en keep-alive Date: Fecha y hora actual. Server: Indica el tipo de S.O que corre en el servidor (Vease /.0x07) 19 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Content-Length: Campo que indica el tamaño del cuerpo del documento o, en decimal, enviado al destinatario que hubiera enviado la petición. ContenrtType: Tipo de contenido y codificación del archivo al que realizamos la petición Expires: Muestra la fecha en la que va caducar la cache de nuestra petición. Set-Cookie: Es la coockie que nos envía la pagina a la que hemos realizado la petición, en ella aparece su ID. Su fecha de expiración, sobre que directorio actúa y el dumio desde donde se ha obtenido. 1.3 METODOS HTTP: Los métodos HTTP más comunes y los más usados son los que a continuación se mencionan. Es importante identificarlos ya que son los más manipulados en la aplicación en ataques y técnicas de PenTesting y de snifeo de cabeceras HTTP. GET: Sirve para recoger cualquier tipo de información del servidor. Se utiliza siempre que se pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el servidor HTTP envía el documento ubicado en la dirección especificada por dicha URL. HEAD: Es un comando similar a GET pero que pide solamente la cabecera del objeto. Lo utilizan principalmente los gestores de cachés de páginas o los servidores proxy para conocer cuándo es necesario actualizar la copia que se mantiene de un fichero. POST: Este comando envía datos de información al servidor, normalmente procedentes de un formulario web, para que el servidor los administre o los añada a una base de datos. PUT: Almacena un objeto en la URL especificada. Si la dirección de destino ya contenía un objeto, se considera que se está enviando una versión actualizada del mismo. DELETE: Elimina el objeto especificado. Este comando es muy poco utilizado. TRACE: Realiza un eco de la solicitud recibida para que el cliente pueda conocer qué servidores intermedios están añadiendo información o modificando la petición. OPTIONS: Devuelve los métodos HTTP que soporta el cliente. Se suele utilizar para comprobar la funcionalidad de un servidor web. CONNECT: Se utiliza en los servidores proxy que puedan establecer un túnel dinámicamente (por ejemplo, un túnel SSL). Ante cada transacción con un servidor HTTP, éste devuelve un código numérico en la primera línea del mensaje de respuesta que informa sobre el resultado de la operación. Estos códigos aparecen en algunos casos en la pantalla del cliente, cuando se produce un error. Los códigos de estado están clasificados en cinco categorías: • 1xx: Mensajes informativos. • 2xx: Mensajes asociados con operaciones realizadas correctamente. 20 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web • 3xx: Mensajes de redirección, que informan de operaciones complementarias que se deben realizar para finalizar la operación. • 4xx: Errores del cliente; el requerimiento contiene algún error, o no puede ser realizado. • 5xx: Errores del servidor, que no ha podido llevar a cabo una solicitud. En la siguiente tabla podemos ver una lista con los códigos que se utilizan con mayor frecuencia: La tabla 1 muestra los códigos de estado más comunes en una conversación establecida con el protocolo HTTP. Estos códigos son los que generalmente se modifican en interceptaciones o ataques a servicios HTTP y serán parte del análisis en los ejercicios propuestos del curso. CODIGO ACCION DESCRIPCION 200 OK Operación realizada satisfactoriamente 201 Created La operación ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. Este nuevo objeto ya está disponible. 202 Accepted La operación ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. El nuevo objeto no está disponible por el momento. En el cuerpo de la respuesta se debe informar sobre la disponibilidad de la información. 204 No Content La operación ha sido aceptada, pero no ha producido ningún resultado de interés. El cliente no deberá modificar el documento que está mostrando en este momento. 301 Moved Pemanently El objeto al que se accede ha sido movido a otro lugar de forma permanente. El servidor proporciona, además, la nueva URL en el campo Location de la respuesta. 302 Found El objeto al que se accede ha sido movido a otro lugar de forma temporal. El servidor proporciona, además, la nueva URL en el campo Location de la respuesta. El cliente no debe modificar ninguna de las referencias a la URL errónea. 304 Not Modified Se devuelve cuando se hace un GET condicional y el documento no ha sido modificado 400 Bad Request La petición tiene un error de sintaxis y no es entendida por el servidor. 401 Unauthorized La petición requiere una autorización especial, que normalmente consiste en un nombre y clave que el servidor verificará. El campo WWW-Autenticate informa de los protocolos de autentificación aceptados para este recurso. 403 Forbidden Está prohibido el acceso a este recurso. No es posible utilizar una clave para modificar la protección. 404 Not Found La URL solicitada no existe, no está disponible o no se encuentra. 500 Internal Server Error El servidor ha tenido un error interno, y no puede continuar con el procesamiento. 501 Not Implemented El servidor no tiene capacidad, por su diseño interno, para llevar a cabo el requerimiento del cliente. 502 Bad Gateway El servidor, que está actuando como proxy o pasarela, ha encontrado un error al acceder al recurso que había solicitado el cliente. 503 Service Unavailable El servidor está actualmente deshabilitado y no es capaz de atender el requerimiento. Tabla 1: Códigos de estado en HTTP Fuente: <http://www.rfc-editor.org/rfc/rfc1866.txt> 21 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 1.4 CODIFICACION DE LA INFORMACION: Una de las características de HTTP reside en que la comunicación entre cliente y servidor se realiza a partir de caracteres US-ASCII de 7 bits. El problema aparece cuando deseamos realizar la transmisión de un archivo binario, cuyo contenido no puede ser representado por este grupo tan reducido de caracteres. Para solventar esta limitación se utiliza el estándar de Internet MIME (Extensiones de correo de Internet multipropósito). Son una serie de convenciones o especificaciones dirigidas a que se puedan intercambiar a través de Internet todo tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario. Una parte importante de MIME está dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y alfabetos. La especificación de este estándar se encuentra recogidas en las RFC 2045, 2046, 2047, 2048 y 2049. 11 Los recursos u objetos que actúan como entrada o salida de un comando HTTP están clasificados por su descripción MIME, que se especifica en el campo de cabecera “Content-Type”. De esta forma, el protocolo puede intercambiar cualquier tipo de dato sin preocuparse de su contenido. La identificación MIME permitirá que el receptor trate adecuadamente los datos. Existen nueve tipos definidos por la IANA: 12 • 7 bit: Utilizado por defecto, supone que los archivos son de texto. application, audio, example, image, message, model, multipart, text y video. Dentro de cada tipo existen multitud de subtipos: (text/html, image/gif, image/jpeg, audio/x-mpeg, video/quicktime…). Existen tres métodos básicos de codificación: • Quoted-printable: Se usa para codificar texto con caracteres que excedan de los 7 bits utilizados en US-ASCII. Con esto podremos representar caracteres de otros alfabetos como los idiomas procedentes del latín. Se codifica en 3 caracteres de 7 bits. Por ejemplo, la letra “ñ” se corresponderá con los caracteres “=F1”. • Base64: Se utiliza para codificar contenido no legible por humanos, como por ejemplo archivos multimedia. Cada 3 octetos se codifican en 4 caracteres que pertenecen a un subconjunto de 64 caracteres imprimibles del US-ASCII. 11 Disponible en internet desde <http://www.ietf.org/rfc/rfc2045.txt> 12 Disponible en internet desde <http://www.iana.org/> 22 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 2: VULNERABILIDADES EN APLICACIONES WEB: 2.1 COMO TRABAJAN LAS APLICACIONES WEB Iniciemos con una breve descripción de cómo trabajan e interactúan las aplicaciones y servicios web con diferentes componentes y escenarios tecnológicos. El uso de aplicaciones web es tan común como tan masificado hoy en día por todo tipo de usuarios, empresas e instituciones. Su uso va desde la simple acción de leer un correo electrónico hasta realizar una compra en línea o una transacción bancaria sin importar el cubrimiento de estas aplicaciones, el tamaño, diseño, código en que estén realizadas, plataformas y arquitecturas en las que estén montadas. Algo en común de estas aplicaciones es que la mayoría son interactivas, agradables para el usuario, con datos en línea que se comparten y que ponen a disposición del usuario. Muchas de ellas soportadas por grandes bases de datos y que usan como canal de distribución Internet. La forma como una aplicación web trabaja, a simple vista es sencilla y práctica. Tal vez por ello y sin ser una afirmación, es que son vulnerables. Po lo general consisten en una base de datos que por decirlo así, está ubicada detrás del sitio web alojado en un servidor y que está escrita en un lenguaje de programación que es capaz de extraer información específica de esa base de datos por solicitudes y peticiones de los usuarios remotos o locales mediante interacciones dinámicas con esos usuarios o clientes. Cuando se usan bases de datos para la gestión de los mismos en aplicaciones web, es común que estas aplicaciones estén compuestas por tres niveles: Un nivel de presentación (un navegador web o motor de búsqueda). Un nivel lógico (un lenguaje de programación, como C #, ASP, NET, PHP, J SP, etc.). Y un nivel de almacenamiento (base de datos como Microsoft SQL Server, MySQL, Oracle, etc.) 23 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 5: Niveles de comunicación en aplicaciones web. Fuente: El autor En la (figura 5) se identifica la secuencia de peticiones y operación de los tres niveles en donde si el navegador Web (el nivel de presentación, por ejemplo, Internet Explorer, Safari, Firefox, etc) envía peticiones a la capa media (la capa de lógica), que define los servicios, las solicitudes, consultas y actualizaciones de la base de datos (el nivel de almacenamiento). 2.2 UNA ARQUITECTURA MÁS COMPLEJA: En los últimos años, el modelo de tres niveles fue reevaluado y un nuevo concepto basado en la escalabilidad y mantenimiento fue creado. Surge una solución de cuatro niveles que implica el uso de una pieza de middleware, típicamente llamado un servidor de aplicaciones, entre el servidor Web y el servidor de aplicaciones de base de datos. Esta nueva capa de abstracción, consta de un servidor que aloja una interfaz de programación de aplicaciones (API) para exponer la lógica de negocio y procesos de negocio para uso de los servidores Web. Además, el servidor de aplicaciones 24 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web pueden hablar con varias fuentes de datos, incluyendo bases de datos, mainframes u otros sistemas de legado. Figura 6: Arquitectura de cuatro capas en aplicaciones web. Fuente: El autor En la Figura 6, el navegador Web (presentación) envía peticiones a la capa intermedia (lógica), que a su vez llama a la API expuesta del servidor de aplicaciones que residen en la capa de aplicación y es el que realiza las consultas y actualizaciones de la base de datos (almacenamiento). El usuario ejecuta en el navegador de Internet una consulta y se conecta a http://www.victima. com. El servidor web que reside en la capa de lógica carga una secuencia de comandos del sistema de archivos y se lo pasa a través de su motor de scripting en el que se analiza y se ejecuta El script llama a una API expuesta desde el servidor de aplicación que reside en la capa de aplicación. El servidor de aplicación abre una conexión con el nivel de almacenamiento usando un conector de base de datos y ejecuta una instrucción SQL en la base de datos. Se devuelven los datos al conector de la base de datos y al servidor de aplicaciones que implementa las reglas de la lógica de aplicación o negocio antes de devolver los datos al servidor Web que aplica un retoque de (lógica final) antes de la presentación de los datos en formato HTML en el navegador Web del usuario. La presentación de la web se hace mediante HTML que le muestra al usuario una representación gráfica de la código Esto sucede de manera instantánea y es transparente para el usuario. Pero por que se dividen las tareas en capas o niveles?: El concepto básico de una arquitectura estratificada implica dividir una aplicación en trozos lógicos, o niveles, cada uno de los cuales se le asignan roles. Las capas se pueden localizar 25 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web (implementar) en diferentes máquinas o en la misma máquina de forma virtualizada o separados el uno del otro. Ventajas: Cuando se dividen las responsabilidades de una aplicación en múltiples capas hace que sea más fácil de escalar la aplicación, permite una mejor distribución de las tareas de desarrollo entre los desarrolladores, y hace una aplicación más fácil de leer dándole incluso enfoque de rehúso y de adaptabilidad a otras aplicaciones existentes o nuevas. Le da características de robustez a las aplicaciones permitiendo eliminar puntos de fallos críticos y únicos que se puedan presentar si la aplicación sufre una caída total o irreparable. Por ejemplo, la decisión de cambiar de proveedor de bases de datos debe requerir nada más que algunos cambios en las porciones aplicables de la capa de aplicación, la presentación y los niveles lógicos. 2.3 EL PROYECTO OWASP Y LAS VULNERABILIDADES EN APLICACIONES WEB Antes de dar inicio y entrar en la temática fuerte de la seguridad en aplicaciones web, se trae a la lectura como referencia el proyecto OWASP: El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en inglés) es una comunidad abierta dedicada a habilitar a las organizaciones para desarrollar, comprar y mantener aplicaciones confiables. Se citan textualmente apartes del mismo proyecto que dejan claro que la temática es amplia y de trabajo continuo. Este módulo académico que se presenta acá, no pretende abarcar la totalidad de las vulnerabilidades, estrategias, escenarios, herramientas y metodología usados tanto para detectar, diseñar, proveer, monitorear y corregir fallos de seguridad en aplicaciones web. Es un referente para que el profesional tome como partida y apoyo para el análisis de las temáticas que acá se presentan. Existen otros proyectos que tratan este tema y de los cuales también se han referenciado lecciones en este módulo, pero con OWASP se pretende que el estudiante lo identifique y derive sus conclusiones, aportes y posiciones con referencia a la temática. Que mejor que apoyarse en esa experiencia de una comunidad de desarrolladores, empresas, corporaciones, casas fabricantes de software, profesionales de la TICs, para citar este inicio que nos ubica en el contexto de la seguridad en la web y que se aborda de manera académica, objetiva, investigativa y como un ejercicio profesional en el área de la seguridad, así: No sin antes 26 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web referenciar el “ OWASP top 10 de 2013” que lo encuentran acá: 13 Figura 7: OWASP – Top 10 - 2013 y que es de necesaria lectura antes de continuar. Fuente: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20- %20RC1.pdf Con licencia Creative Commons La guía completa del Top 10, es parte del anexo de este módulo: No se detenga en el Top 10. Existen cientos de problemas que pueden afectar la seguridad general de una aplicación web tal como se ha discutido en la Guia de Desarrollo OWASP. 14 13 Disponible en internet con acceso y formato pdf <https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project> 14 Disponible en internet desde <https://www.owasp.org/index.php/Guide> Este documento es de lectura esencial para cualquiera desarrollando aplicaciones web hoy en día. Una efectiva orientación en como encontrar vulnerabilidades en aplicaciones web es suministrada en la 27 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Guia de Testeo OWASP 15 y la Guia de Revision de Codigo OWASP, 16 Piense positivamente. Cuando se encuentre preparado para dejar de buscar vulnerabilidades y focalizarse en establecer controles seguros de aplicaciones, OWASP ha producido el las cuales han sido significativamente actualizadas desde la última edición del Top 10. Cambio constante. Este Top 10 continuara cambiando. Incluso sin cambiar una línea de código en su aplicación, la misma puede ser vulnerable a algo que nadie haya pensado anteriormente. Por favor revise los consejos detallados al final del Top 10 “Próximos pasos para Desarrolladores, Verificadores y Organizaciones” para mayor información. Application Security Verification Standard (ASVS) 17 SDLC Seguro. Aplicaciones Web seguras son solo posibles cuando se utiliza un SDLC Seguro. Para orientación sobre como implementar un SDLC Seguro, leer el como una guía para organizaciones y revisores de aplicaciones que detalla los controles de seguridad a verificar en una aplicación. Utilice herramientas inteligentemente. Las vulnerabilidades de seguridad pueden ser bastante complejas y encontrarse ocultas en montañas de código. En virtualmente todos los casos, el enfoque mas eficiente y económico para encontrar y eliminar estas vulnerabilidades es asignar expertos armados de buenas herramientas para realizar esta tarea. Open Software Assurance Maturity Model (SAMM), 18 el cual es una actualización significativa al OWASP CLASP Project. 19 Estas herramientas pueden venir en forma de Addons o Plugins para diferentes navegadores, que entre los cuales destacan para FireFox, Tamper Data y Live HTTP Headers, o también pueden ser programas independientes propietarios o de 2.4 SNIFFEO Y CODIFICACION DE CABECERAS: La temática que hasta aquí se ha tratado, ha descrito de forma general el protocolo HTTP y las negociaciones entre cliente-servidor que se establecen a través de cabeceras, “los HTTP Headers.” Para poder trabajar con las cabeceras necesitaremos de una serie de utilidades cuya finalidad es la de interceptar las cabeceras que manda nuestro navegador, para permitir su análisis o su modificación. Estas utilidades se denominan sniffers, y funcionan interceptando el tráfico que pasa por el puerto 80 (HTTP). 15 Disponible en internet desde <https://www.owasp.org/index.php/Category:OWASP_Testing_Project> 16 Disponible en internet desde <https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project> 17 Disponible en internet desde <https://www.owasp.org/index.php/ASVS> 18 Disponible en internet desde <https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model> 19 Disponible en internet desde <https://www.owasp.org/index.php/Category:OWASP_CLASP_Project> 28 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web código abierto. Estas herramientas son fundamentales para el trabajo con las cabeceras http. Existen otras formas de trabajar con las cabeceras sin tener que sniffearlas para modificarlas, como por ejemplo aprovechar algún programa que haga negociaciones TCP, como por ejemplo pueden ser Telnet, Putty, o los populares Netcat y CryptCat. 2.5 INYECTANDO CODIGO Cuando se hace un proceso de sniffing a las cabeceras HTTP, se puede hacer con dos objetivos: Observar los datos que se envían y de ahí buscar un posible CSRF (Cross Site Request Forguery) o bien para modificar la cabecera y añadirle código malicioso, el cual provoque en una aplicación vulnerable una respuesta que no era la que debía. Se inyecta código a las cabeceras y si se manejan datos procedentes de la cabecera sin realizarles un correcto filtrado, es ahí cuando una aplicación web se vuele más vulnerable y más cuando sin restricciones o controles de acceso, se le permite al “front-End” (usuarios hackers) la modificación de la cabecera para que la aplicación web maneje códigos maliciosos, y ejecute éstos, de esta forma podemos convertir a las cabeceras como medio para inyectar sentencias SQL maliciosas, J avaScript, etc. para realizar diversos ataques a una web. En las siguientes lecciones, se detallarán los procedimientos para detectar inyecciones de código como el “SQL Injection” 2.6 CR/LF INJECTIONS: Esta vulnerabilidad hace referencia a un término común: (HTTP Splitting). Hace referencia al manejo de cabeceras con caracteres especiales que trabajan en conjunto llamados CR (Carriage Retun) y LF (Line Feed) que básicamente traducen un “Salto de línea” en el momento de una conversación o salto de cabecera. En programación las señales de salto de línea se plasman con los caracteres de escape \r\n. Una aplicación es vulnerable a CR/LF injection cuando no filtra de forma correcta las variables, permitiendo escanear (indagar) en ellas valores prohibidos como lo son éstos. Esta vulnerabilidad implica el que un usuario malintencionado pueda 29 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web manipular a su antojo las cabeceras de un servidor y más si es bien conocido que la finalización de una cabecera se señala con un doble salto de línea Es aquí cuando un atacante identificando ese salto de línea final, provocará la “partición” de la cabecera, permitiendo colocar junto al doble salto de línea el código que él considere oportuno, normalmente será una segunda cabecera. A la técnica de “truncar” o “cortar” una cabecera para controlar una respuesta del servidor se la denomina “HTTP Splitting”. Una técnica derivada del HTTP Splitting puede ser lo que se denomina “File Download Injection” y consiste en infectar con el código que nosotros deseemos una descarga. 2.7 XSS Y SQL INJECTIONS Las fallas de inyección, ya sea de SQL, LDAP o comandos del sistema operativo, son comunes en aplicaciones Web. La inyección ocurre cuando los datos proporcionados por el usuario son enviados e interpretados como parte de una orden o consulta. Los atacantes interrumpen el intérprete para que ejecute comandos no intencionados proporcionando datos especialmente modificados. Esta técnica es usada para explotar aplicaciones web que no validan la información suministrada por el cliente, para generar consultas SQL maliciosas. El proceso de inyección requiere de verificar cada parámetros que se envía y se recibe, lo que suele no ser sencillo y muchas veces se puede creer que no es vulnerable una aplicación que lo es. Se debe chequear cada parámetro de cada script de cada aplicación. Para el siguiente ejemplo en la que se inyecta el comando (se solicita una información): SELECT id FROM usuarios WHERE user=‘$f_user’ AND password=‘$f_pass’; Si no se identifica un usuario (campo en blanco en la validación) o si se typean los parámetros predeterminados de los usuarios: admin, administrator, guest, invitado entre otros, al modificar la injección de SQL por: $f_user=“‘ or 1=1 --” en las que se usa: ; para ejecutar múltiples queries -- para comentar el final del query construcciones del tipo ´ or ´´=´ construcciones del tipo numero or 1=1 30 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Se podría explotar esta vulnerabilidad de validación de usuario e ingresar al sistema Ataques de Cross −Site Scripting : Las fallas de XSS ocurren cuando una aplicación toma información originada por un usuario y la envía a un navegador Web sin primero validar o codificar el contenido. XSS permite a los atacantes ejecutar secuencias de comandos en el navegador Web de la víctima que pueden secuestrar sesiones de usuario, modificar sitios Web, insertar contenido hostil, etc. Este tipo de ataques han sido explotados para crear poderosos ataques de phishing y de abusos en el navegador donde los atacantes típicamente se valen de código HTML y de scripts ejecutados en el cliente. “Desde la liberación del lenguaje J avaScript, se previeron los riesgos de permitir a un servidor Web enviar código ejecutable al navegador. Un problema se presenta cuando los usuarios tienen abiertos varias ventanas de navegador, en algunos casos un script de una página podría acceder datos en otra página u objeto, observando el peligro de que un sitio malicioso intentara acceder datos sensibles de esta forma. “ 20 20 Tomado de: UNAM CERT; “Aspectos Básicos de la Seguridad en Aplicaciones Web” Política same−origin: Esencialmente esta política permite la interacción entre objetos y páginas, mientras estos objetos provengan del mismo dominio y en el mismo protocolo. Evitando así que un sitio malicioso tenga acceso a datos sensibles en otra ventana del navegador vía J avaScript. A partir de entonces se han introducido otros mecanismos y políticas de control en los navegadores y en los lenguajes en el lado del cliente, para proteger a los usuarios de sitios maliciosos. Las vulnerabilidades XSS pueden ser vistas como técnicas de evasión de las políticas de protección. La mayoría de casos la variable vulnerable (en el caso de los XSS) suele ser alguna que se utiliza para mostrar alguna información tipo IP, User-Agent y demás. Por so la mayoría de webs que ofrecen servicios adicionales como el de mostrar el nombre de usuario logueado, mostrar la IP, mostrar zonas horarias, mostrar datos de fecha de inicio de sesión entre otros, datos que suelen ser vulnerables cuando se modifican las cabeceras. 2.8 PHP INJECTIONS Existen algunos ataques que aprovechan la posibilidad de la aplicación de subir archivos al servidor. Estos ataques funcionan de la siguiente manera: 31 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Generalmente PHP almacena los archivos subidos en un carpeta temporal, sin embargo es común en las aplicaciones cambiar la localización del archivo subido a una carpeta permanente y leerlo en la memoria. Al hacer este tipo de procedimientos debemos revisar el parámetro que hará referencia al nombre del archivo, ya que puede ser truqueado a modo de apuntar a archivos de configuración del sistema (como /etc/passwd en sistemas Unix). Las aplicaciones invocan comandos externos a través de un intérprete de comandos. Según la forma de invocarlos, es posible que un usuario malicioso logre ejecutar un comando externo distinto al esperado. Ej.: uso del caracter “;” en Unix o “&” en Windows. 2.9 BANNER GRABBING Se le suceder que el sitio web despliegue banners que emiten información del sitio. De estos banners no hay que fiarse si no se tienen definidos los scripts filtrados para los usuarios que accedan al sitio. Se define básicamente banner a la información (aplicación, versión, plataforma sobre la que corre) que trasmite un servicio cuando se trabaja sobre en el. Un ejemplo de detección de esta información (se revela el servicio que está disponible, el tipo de servidor montado y el puerto 21 al que responde) es el acceso a servicios ftp. La figura 8 muestra un rastreo al servicio de alojamiento de archivos (descargas) muy típico del sitio www.hp.com. Figura 8: Banner detección por ftp Fuente: El autor 32 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web En la figura 9 se aplica un banner grabbing hacia la web www.unad.edu.co: Información del tipo de servidor, versión sistema operativo sobre el cual se ejecuta, versión de PHP entre otros. Figura 9: Banner grabbing por método HEAD Fuente: El autor El ataque consistiría en obtener los encabezados por HEAD desde un navegador y editaros para reenviar peticiones y modificar comportamientos del sitio. 2.10 HTTP FINGERPRINTING Se trata entonces de obtener información de un sistema concreto y de alguna vulnerabilidad específica. Esto se hace obteniendo su huella identificativa respecto de la pila TCP/IP de los equipos atacados. Esta técnica es la que se conoce como Fingerprinting y la información que puede brindar esta técnica dentro de las muchas opciones que tiene de descubrir datos de la víctima es la de permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en la maquina analizada. La aplicación de esta técnica consiste en la ejecución de 4 tests (orden de campos al hacer un HEAD, respuesta ante un DELETE, respuesta ante una versión del protocolo HTTP incorrecta, y por último, la respuesta que da el servidor ante un protocolo erróneo). Con los resultados de los mencionados cuatro tests, podremos diferenciar perfectamente entre servidores Apache y los IIS, ya que de cada uno se extrae un resultado diferente ante cada uno de los tests. Además de las versiones de 33 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web sistema operativo, puertos abiertos y capas de seguridad implementadas al protocolo HTTP. La información que puede brindar esta técnica dentro de las muchas opciones que tiene de descubrir datos de la víctima son: • Permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en la maquina analizada. • Identificar el tipo de servidor y la versión en la que se soporta el servicio • El tipo de servicio que se ejecuta y la versión. Una de las muchas técnicas que existen para levantar este tipo de información con respecto al levantamiento de una huella identificativa, es el uso de “Escuchas de Red” o escaners de puertos como la herramienta nmap, con miras a establecer un posible ataque. En la Figura 10 se muestra un escaneo a un host de una red local en busca de su huella identificativa. Se ha identificado información con el número de puertos cerrados que tiene la víctima, en este caso con la dirección IP 10.1.1.16, los puertos en servicio abiertos, la identificación del sistema Operativo y la dirección física de la interfaz de red. Se ha ejecutado en una consola haciendo uso de nmap como herramienta de exploración. Figura 10: Uso de un “Escucha de Red” para hallar huellas identificativas de un host en la red Ethernet Fuente: El autor 34 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web En la Figura 11 se ha realizado la inspección de la huella identificativa de un sistema remoto en la web. Es el caso de www.unab.edu.co haciendo uso de un Sniffer como Ettercap. Se identifica el Sistema Operativo del Servidor, en este caso FreeBSD 4.3 que da el servicio, el puerto que está activo con el servicio http en el puerto TCP 80 y el administrador Web que da el servicio: Oracle Aplication Server. Figura 11: Uso de un “Escucha de Red” para hallar huellas identificativas de un host remoto Fuente: El autor Una de las herramientas para realizar estas detecciones y ataques es usar “hping2, se puede: evaluar el desempeño de la red utilizando diferentes protocolos, tamaños de paquetes, TOS (type of service, o sea, tipo de servicio), y fragmentación; realizar descubrimiento de camino utilizando el campo MTU (onda traceroute); transferir archivos (incluso ante reglas de firewall muy fascistas); realizar funciones al estilo `traceroute' pero bajo diferentes protocolos; detección remota de OS (`remote OS fingerprinting'); auditar una implementación de TCP/IP (`TCP/IP stack') en particular; etc. hping2 es una buena herramienta para aprender acerca de TCP/IP.” 21 21 <RODES, Michael. Pruebas de seguridad con hping. “El Baile”. Magazine N 38> 35 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 3: HERRAMIENTAS PARA LA DETECCION DE VULNERABILIDDES 3.1 FIABILIDAD DE LOS ANAIZADORES AUTOMATICOS DE VULNERABILIDADES WEB Se llega al punto de definir qué tan fiables los analizadores automáticos de vulnerabilidades Web. En primera instancia al gran número de herramientas existentes, los diferentes escenarios en que se aplican y en sí mismo la casi por decirlo así infinitas vulnerabilidades que se presentan y la no certeza de detección y protección total. Los profesionales informáticos, empresas, administradores de TICS, diseñadores, desarrolladores e incluso usuarios, concentran sus actividades en aspectos de seguridad en emplear, cada vez más, herramientas para facilitar la ardua tarea de verificar el nivel de seguridad real de una aplicación web. Nombres como Appscan, Webinspect, Acunetix y otros tantos son cada vez más conocidos y utilizados por los profesionales en cualquier proyecto de auditoría o de pentest. Las ventajas son innumerables pero también los riesgos, y es necesario conocerlos y valorarlos a la hora de decidir el presupuesto de que se dispone para analizar si una página Web puede ser comprometida, desde el punto de vista de la seguridad, o si, por el contrario, cumplirá con su cometido a la perfección. Por Escáner Web se entiende cualquier programa con la capacidad de analizar la seguridad de una aplicación o página Web, es decir, debe incluir los siguientes complementos: a) Un navegador Web para poder interpretar el código HTML, javascript y demás de la propia página. b) Un "spider" o "crawler" para poder detectar toda la estructura de navegación de la Web (archivos, directorios, ficheros de imágenes, etc.) c) Un escáner propiamente dicho para hallar fallos de configuración y vulnerabilidades a nivel Web. d) Un interface de usuario amigable y fácil de utilizar, que permita configurar de forma sencilla la aplicación y todos los parámetros de análisis. 36 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web e) Un generador de reportes que incluya las vulnerabilidades y errores encontrados, su posible impacto para la aplicación Web y la forma de corregir los mismos de forma genérica. Existen multitud de herramientas así, comerciales de pago y con licencia GNU, para Windows y para Linux, más sencillas y más completas, de desarrolladores conocidos como RedHat, Oracle, Cisco. 3.2 VENTAJAS Y BENEFICIOS 1. Reducción de costes: el precio y el esfuerzo en horas de revisar una aplicación Web se reducen considerablemente utilizando herramientas comerciales del tipo de las anteriormente nombradas, Acunetix, Appscan, Webinspect, etc. A pesar de que el precio por licencia de uso es importante, basta realizar unos pocos análisis y revisiones para amortizar la herramienta. Además, existen incluso aplicaciones que no son comerciales sino Open Source que también son importantes, es el caso de Wapiti 22 , Skipfish, Nikto, etc. 2. Disponibilidad y automatización: al poder programar y automatizar cualquier análisis de seguridad, se puede repetir tantas veces como sea necesario para verificar que se han corregido los errores y vulnerabilidades ya detectados. También se puede definir una frecuencia determinada para que se revise una página Web concreta una vez al mes, por ejemplo, y comprobar así si ha habido cambios en la misma y detectar incluso anomalías que pudieran indicar un ataque a la página en forma de intrusión o Denegación de Servicio (DoS). Si en un escaneo programado la página no está operativa puede ser debido a un ataque de DoS o un problema de disponibilidad no controlado. 3. Constante revisión y mantenimiento de la aplicación: La mayoría de herramientas lo hacen todo, revisan, analizan detectan las vulnerabilidades y errores de configuración, sugieren soluciones, generan los informes y reportes. Es trabajo del profesional analizar que herramienta aplicar y si le ofrece estos servicios. 22 Disponible en internet dese <http://hacktimes.com/vulnerabilidades_en_aplicaciones_web_-_wapiti> 37 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 3.3 INCONVENIENTES Y DESVENTAJAS 1. Gran cantidad de falsos positivos y falsos negativos: dos peticiones iguales en momentos diferentes a la aplicación Web por parte del escáner, pueden generar respuestas distintas que la herramienta puede interpretar de forma errónea y reportar como una vulnerabilidad inexistente. Anuncios, dependencias con otras páginas y aplicaciones, usuarios conectados interactuando con la Web analizada, etc. En multitud de ocasiones la revisión de seguridad se limita a pasar la herramienta automática y no se verifica la existencia de las vulnerabilidades reportadas, pudiendo ser falsos positivos o indicios de otras vulnerabilidades sí presentes pero no detectadas por la herramienta. También, otras veces, la página Web analizada presenta diverso código y contenido inútil para revisar la seguridad de la misma que una persona puede identificar de forma rápida y sencilla, pero que no lo es tanto para un ordenador y la correspondiente aplicación automática. Un ordenador no es capaz de entender la lógica de la aplicación Web, y el escaneo de seguridad se basa en comprobar la respuesta de la página Web ante los controles y tests que tiene predefinidos la herramienta de análisis como vulnerabilidades ya conocidas. 2. Imposibilidad de encontrar 0days y errores de diseño: al basarse el análisis en comprobar la respuesta de la página Web ante los controles y tests que la herramienta tiene predefinidos como vulnerabilidades ya conocidas, es muy difícil detectar la presencia de errores no conocidos (0days) y que no están incluidos en la base de datos del escáner Web con el que se realiza la revisión de seguridad. Además, es complicado que un ordenador pueda entender la lógica de la aplicación, cosa que para un técnico con conocimientos no supone ningún reto. 3. Problemas con vul nerabilidades de aplicación conocidas como Cross Site Scripting (XSS) y SQL Injection (SQLi): estas vulnerabilidades en todas sus modalidades (Blind SQLi, Stored XSS, reflected, etc.) presentan multitud de patrones de ataque, y si además se encuentran por en medio mecanismos de seguridad como WAF, IPS, firewalls y otros, las herramientas automáticas no son capaces de modificar sus peticiones para evadir dichos filtros que plantean estos dispositivos de seguridad. En diversas ocasiones, se ha reportado una vulnerabilidad de SQLi estándar como Blind SQL y la solución para corregirla es ligeramente distinta. Otro 38 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web problema es que numerosas herramientas automáticas no detectan como ataque de SQLi una vulnerabilidad en "ORDER BY", además es diferente la forma de tratar esta vulnerabilidad en función del motor de base de datos existente, ya sea MS SQL, MySQL, PostgreSQL, etc. 4. Riesgos directos para la aplicación Web: ya no solo por el límite de peticiones que una herramienta automática puede lanzar en paralelo contra la aplicación Web que puede saturar a la misma y dejarla inaccesible para sus usuarios legítimos, sino también por el tipo de patrones y pruebas que tiene definidas para encontrar vulnerabilidades. Una de esas pruebas consiste en utilizar la conocida sentencia para detectar vulnerabilidades de SQLi, "or 1=1--". En una petición de "SELECT" no hay problema pero si eso mismo acompaña a una petición de "DELETE" quedaría una cosa parecida a "DELETE FROM users where id=1 or 1=1 --" con lo que esto supondría para la aplicación Web. Un técnico no usaría nunca este método de ataque pero aún existen muchas herramientas que se sirven de ella como patrón de ataque Resumiendo, para entornos productivos, lo más recomendable para disponer de un nivel aceptable de seguridad en las aplicaciones Web es combinar escaneos con herramientas automáticas y detectar aquellas vulnerabilidades de bajo nivel ya conocidas, y disponer también de técnicos de seguridad con amplios conocimientos que puedan realizar pruebas manuales específicas para cada aplicación. No es lo mismo revisar un CMS conocido tipo Wordpress, J oomla, etc. que una página Web sin contenido dinámico ni base de datos detrás. Un técnico puede ajustar las pruebas y los análisis a realizar en función de las necesidades de cada caso, se trata de soluciones no industrializadas 3.4 CRITERIOS DE VALORACION PARA HERRAMIENTAS DE SEGURIDAD WEB Continuación se presenta un análisis de las principales herramientas usadas para detección y gestión de riesgos en seguridad de aplicaciones web. Tanto herramientas de código privado como de código libre. Dentro de los parámetros que se han tenido en cuenta para esta evaluación, se han tenido e cuenta que las vulnerabilidades y las herramientas se han aplicado en sistemas con seguridad perimetral, interna y de entorno básicas, con conexiones de internet libres sin restricciones, como las que tienen la mayoría de usuarios. El criterio de valoración fue la primera serie de características de auditoría de cada herramienta soporta. Una herramienta automatizada no puede detectar una exposición que no puede reconocer (al menos no directamente, y no sin un 39 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web análisis manual), y por lo tanto, el número de características de auditoría afectará la cantidad de exposiciones que la herramienta será capaz para detectar (suponiendo que la función de auditoría se aplican adecuadamente, que los puntos vulnerables de entrada será detectado y que la herramienta se encargará de escanear los vectores de entrada vulnerables). Las herramientas evaluadas fueron a nivel de aplicación, en cuanto a la detección de los riesgos que se podrían presentar para atacar a la aplicación web, y el ataque a los clientes legítimos. 3.4.1 Herramientas Comerciales: El número de funciones de auditoría en escáneres de aplicaciones Web - Herramientas Comerciales. Figura 12: Funciones de auditoría en escáneres de aplicaciones web. Herramientas comerciales Fuente: <Proyecto OWASP> 3.4.2 Herramientas de código Abierto: El número de funciones de auditoría en escáneres de aplicaciones Web - Herramientas de código abierto. 40 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 13: Funciones de auditoría en escáneres de aplicaciones web. Herramientas de código abierto Fuente: <Proyecto OWASP> 3.4.3 Herramientas de auditoría aplicadas a SQL INJECTION El análisis aplica a las herramientas que pueden detectar de SQL Injection, una de las exposiciones más famosas en ataques comúnmente aplicado en los escáneres de aplicaciones web. El análisis siguiente es producto de la evaluación de que tan buenas son las herramientas en la detección de riesgos de inyección SQL, partiendo de un punto sin ningún tipo de restricciones que pueden impedir que la herramienta funcione correctamente. 41 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web La evaluación se realizó en una aplicación que utiliza MySQL 5.5.x como su repositorio de datos, y por lo tanto, reflejará la exactitud de la detección de la herramienta cuando se escanean los repositorios de datos similares. La barra azul representa el caso vulnerable prueba de precisión de detección, mientras que la barra roja representa falsas categorías positivas detectadas por la herramienta. Herramientas de código privado Herramientas de código abierto Figura 14: Funciones de auditoría en escáneres de aplicaciones web para SQL Injection Fuente: <Proyecto OWASP> 42 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 3.4.4 Herramientas de auditoría aplicadas a XSS (Ataques de Cross−Site Scripting) Para el segundo ataque más común implementado en los escáneres de aplicaciones web se aplicó le mismo procedimiento que en los atajes de SQL Injection. Herramientas de código privado Herramientas de código abierto Figura 15: Funciones de auditoría en escáneres de aplicaciones web para XSS Fuente: <Proyecto OWASP> 43 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Continuando con la evaluación de herramientas y aplicando ciertos criterios de efectividad y de aplicabilidad, se adjunta como ANEXOS de este módulo, los análisis de ciertas variables que son de importancia analizarlas. Todas estas herramientas son tan solo un puñado entre la cantidad de estrategias, métodos y utilidades que se pueden seguir para realizar la explotación de las vulnerabilidades en una aplicación web. El objetivo es obtener información de la aplicación, tratar de realizar una evaluación de la vulnerabilidad con el fin de obtener información sobre los exploits que se pueden utilizar. Una vez hecho esto, explotar las vulnerabilidades y si es necesario, cargar un backdoor o un script que determine la vulnerabilidad encontrada. Referencio el WAVSEP (The Web Application Vulnerability Scanner Evaluation Project) como una aplicación web vulnerable diseñado para ayudar a evaluar las características, la calidad y la precisión de los escáneres de vulnerabilidades de las aplicaciones web. 23 LECCION 4: MITOS EN LA SEGURIDAD WEB Siempre se cree que las vulnerabilidades más comunes como SQL Injection, DDoS y XSS, son las que afectan a las aplicaciones web. También que los errores son por deficiencias en la programación e implementación de estas aplicaciones. Se referencian ciertos mitos que desmienten estas apreciaciones y que muestran que tan lejos estamos de la realidad del entorno en que las aplicaciones web se aplican y las vulnerabilidades que las rodean: • El cliente hace las peticiones básicas del sitio y accede a los links que solo le referencia la página o sitio (se asume que el cliente no “escarba” dentro del sitio). • HTML admite el uso de tags (etiquetas) que manipulan la entradas a la aplicación, por ejemplo si la aplicación utiliza campos ocultos para enviar información sensible estos pueden ser fácilmente manipulados desde el cliente. 23 Disponible en internet desde <http://code.google.com/p/wavsep/> 44 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web • La validación solo se puede realizarse únicamente del lado del cliente con J avaScript (esto es falso) si no se efectúa ninguna validación del lado del servidor, cualquier atacante que evite esta validación (para nada difícil de lograr) tendrá acceso total a toda la aplicación. • Cuando se tiene un sistema y entorno seguro no hay riesgo de vulnerabilidades. El uso de firewalls es suficiente - como explicamos anteriormente, si el firewall tiene que habilitar los puertos 80 y/o 443 para que la aplicación sea accesible al exterior, no podrá hacer nada para detectar entradas maliciosas del cliente, y por supuesto no es protección contra ataques internos. • El uso de SSL es una solución suficiente - SSL simplemente cubre el request/response HTTP dificultando la intercepción del tráfico entre cliente y servidor, pero no agrega seguridad al servidor ni evita el envío de código malicioso desde el cliente. Otro Mito es el que los desarrolladores y técnicos encargados de la seguridad enmarcan dentro de solo las “supuestas” cinco vulnerabilidades más comunes, dejando a un lado las estrategias de prevenir, analizar, detectar y sobre todo diseñar aplicaciones expuestas a otro tipo de vulnerabilidades. Figura 16: Categoría de Vulnerabilidades Fuente: El Autor 45 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 4.1 AUDITORÍA Y CONTROL DE VULNERABILIDADES: Muchas empresas sólo realizan el escaneo de vulnerabilidades para los periodos de las famosas auditoria seguridad informáticas – y quizás rara vez, generalmente como una vez al año. Este es un gran error; no sólo se deben realizar las actualizaciones a las redes de forma frecuente, si no que hay que saber que nuevas vulnerabilidades se descubren semanalmente por no decir de forma diaria. Para organizaciones muy grandes, es importante realizar el escaneo de vulnerabilidades como parte del análisis de seguridad regular con una mayor cantidad de escaneos, mucho más frecuente (un ejemplo podría ser realizar el escaneo de vulnerabilidades, de forma exhaustiva, cada 4 meses, o sea unas 3 veces al año). 4.2 PUNTOS DEBILES: Los hackers siempre quieren encontrar el acceso más fácil a las redes de las organizaciones valiéndose de una variedad de técnicas diferentes. Pero una característica que todos los atacantes “hackers” tienen en común es su deseo de buscar los puntos débiles de una red, cuál de ellos puedan usar para lanzar ataques con el mínimo esfuerzo. Un ladrón normal busca una puerta abierta en una casa, un ladrón de autos busca el vehículo en donde el conductor se haya dejado la llave olvidada, un hacker puede examinar múltiples redes para encontrar la que le proporcione un acceso rápido y simple. Esta situación plantea un desafío para los administradores de redes que, para combatir a los hackers, deben comenzar a pensar como ellos. Con referencia a lo anterior, un aspecto que siempre se debe cuidar es evitar que en nuestro sistema se Exploren puertos: Exploración de puertos: El escaneo o exploración de puertos permite determinar las características de una red o sistemas remotos, con el objetivo de identificar los equipos disponibles y alcanzables desde Internet, así como los servicios que ofrece cada uno. Se puede llegar a conocer los sistemas existentes, los servicios ofrecidos por ellos, cómo están organizados los equipos, que sistemas operativos ejecutan y cual es le propósito de cada uno. Una herramienta de código abierto que sirve para efectuar rastreo de puertos es nmap. Con la herramienta hping2 en el modo SCAN (-8 --scan): Permite realizar análisis de puertos, se pueden especificar distintas opciones para los puertos, rangos, excluir determinados puertos, los puertos incluidos en /etc/services, etc. 46 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 4.3 TIPOS DE ESCANERS: Parte de los mitos que rodean la seguridad en aplicaciones web, está el que aplican los técnicos, administradores de red, desarrolladores y profesionales, que les llevan a pensar que solo se deben implementar escáneres que detecten riesgos en las capas superiores del modelo OSI, La seguridad de la información es un conjunto engranado que enmarca todos los aspectos en comunicación, transferencia, trato de información. Es por ello que se deben aplicar escáner de este tipo para que medianamente se puedan minimizar riesgos y maximizar la seguridad: Escáner de Red: escáner de uso general usado para encontrar vulnerabilidades potenciales en la red de la empresa. (También se podría incluir a los escaners de redes VoIP) Escáner de Puerto: software diseñado para buscar en una red los puertos abiertos que podrían ser usados por los atacantes como puntos de entrada. Escáner para la Seguridad de aplicaciones web: Permite a los negocios realizar evaluaciones de riesgo para identificar las vulnerabilidad en aplicaciones web y así evitar ataques. Este tipo de escaners deben ser utilizados también por el departamento de desarrollo (programación) de una aplicación web, ayudando así a encontrar todos los bugs que puedan generarse durante la creación de la aplicación, antes de poner la aplicación a un entorno de producción. Escáner de Base de datos: permite encontrar puntos débiles en bases de datos, protegiendo así el activo más importante de una empresa. LECCION 5: SISTEMA DE LOGS La auditoría y el registro de los eventos que suceden al ejecutar nuestras aplicaciones nos permite monitorizarlas y detectar posibles intentos de ataques o intrusiones. Un log es un registro oficial de eventos durante un rango de tiempo en particular. Para los profesionales en seguridad informática se utiliza para registrar datos o información sobre quién, qué, cuándo, dónde y por qué un evento ocurre en un dispositivo en particular o aplicación. 47 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web La mayoría de los logs son almacenados o desplegados en el formato estándar, el cual es un conjunto de caracteres para dispositivos comunes y aplicaciones. De esta forma cada log generado por un dispositivo en particular puede ser leído y desplegado en otro diferente. También se le considera como aquel mensaje que genera el programador de un sistema operativo, alguna aplicación o algún proceso, en virtud del cual se muestra un evento del sistema. 24 Figura 17: Formato de fichero de Logs Fuente: <MATEU, Carles; Desarrollo de aplicaciones web; UOC> Los sistemas de los deben garantizar la monitorización de los eventos que se producen en la aplicación y asegurar la información de los ficheros de registro. 5.1 FORMATO DEL FICHERO DE LOG: Por norma general, los servidores web guardan los registros en un formato llamado Common Log Format. Los servidores que no usan dicho formato por defecto suelen incluir una opción para usarlo. El formato Common Log Format es el siguiente: 24 Disponible en internet dese <http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/desarrollo/auditoria-y- registro> 48 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Existen variantes extendidas que se aplican a estos formatos. Variantes que dependen del sistema usado y que generalmente en herramientas de tipo IDS con código abierto, el administrador de la red puede modificar y parametrizar para obtener la información deseada. 5.2 ANALISIS DEL FICHERO DE LOG: Mucha información que suministran estos ficheros de registro, no son claros y requieren que se asocien a otros para poderlos interpretar. Lo más común es encontrar los siguientes datos: • Número de peticiones recibidas (hits). • Volumen total en bytes de datos y ficheros servidos. • Número de peticiones por tipo de fichero (por ejemplo, HTML). • Direcciones de clientes diferentes atendidas y peticiones para cada una de ellas. • Número de peticiones por dominio (a partir de dirección IP). • Número de peticiones por directorio o fichero. • Número de peticiones por código de retorno HTTP. • Direcciones de procedencia (referrer). • Navegadores y versiones de éstos usados. A pesar de que las informaciones que podemos obtener del análisis de los ficheros de log son numerosas, hay unas cuantas que no podemos obtener. De ellas, algunas resultarían de especial interés: • Identidad de los usuarios, excepto en aquellos casos en los que el usuario se identifique por petición del servidor. • Número de usuarios. A pesar de tener el número de direcciones IP distintas, no podemos saber de forma absoluta el número de usuarios, y más si tenemos en cuenta la existencia de servidores proxy-cache. • Datos cualitativos: motivaciones de los usuarios, reacciones al contenido, uso de los datos obtenidos, etc. • Ficheros no vistos • Qué visitó el usuario al salir de nuestro servidor. Este dato quedará recogido en los log del servidor donde el usuario fue después del nuestro. El análisis de estos ficheros, es específico para cada aplicación de captura que se tenga. 49 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 5.3 PROGRAMAS DE ANALISIS DE LOGS Al igual que las herramientas de detección de vulnerabilidades, y escuchas de red; son innumerables las que hay disponibles tanto en código propietario como de código abierto. Los programas de análisis de ficheros de log de código libre y que se pueden usar para obtener información sobre los registros de visitas de nuestro sitio web permiten mayor manipulación de la información y tratamiento de la misma. La mayoría de ellos generan los correspondientes informes en forma de páginas web que podemos publicar incluso en nuestro sitio web. Es de mencionar los más comunes que poseen interfaces gráficas y con características completas en cuanto a registros capturados: Webalizer, Awstats, Analog, CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB El análisis de estos protocolos nos ubica especialmente en los procesos que incluyen transacciones e información que se intercambie en sitios web y que por supuesto es manejada por aplicaciones web. A continuación se detalla los principales protocolos de seguridad que se manejan actualmente: 1. Secure Socket Layer (SSL) Secure Sockets Layer (SSL) es el estándar mundial de la seguridad en la Web. La tecnología SSL se enfrenta a potenciales problemas derivados de la visualización no autorizada de información confidencial, la manipulación de datos, la apropiación de datos, el phishing y los demás tipos de amenazas en los sitios Web. Para ello, se cifra la información confidencial a fin de que sólo los destinatarios autorizados puedan leerla. Además de evitar la manipulación de la información confidencial, SSL contribuye a que los usuarios tengan la seguridad de acceder a un sitio Web válido. Los principales sistemas operativos, aplicaciones Web y hardware del servidor son compatibles con SSL, lo que significa que esta poderosa tecnología de cifrado de SSL ayuda a implementar en cada empresa una manta de seguridad que limita la responsabilidad para todo el sistema con el fin de afianzar la seguridad de los clientes, incrementar el porcentaje de transacciones finalizadas y optimizar los resultados finales. Gracias a los avances recientes obtenidos en la tecnología SSL, existe una amplia variedad de tipos de SSL. 50 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 2. Transport Layer Security (TLS) Para intentar corregir las deficiencias observadas en SSL v3 se buscó un nuevo protocolo que permitiera transacciones seguras por Internet, sobre todo teniendo en cuenta que SSL es propiedad de la empresa Nestcape. El resultado de esta búsqueda fue el protocolo TLS, que permite una compatibilidad total con SSL siendo un protocolo público, estandarizado por el IETF. TLS busca integrar en un esquema tipo SSL al sistema operativo, a nivel de la capa TCP/IP, para que el efecto "túnel" que se implementó con SSL sea realmente transparente a las aplicaciones que se están ejecutando. 3. Protocolo S-HTTP El protocolo Secure HTTP fue desarrollado por Enterprise Integration Technologies, EIT, y al igual que SSL permite tanto el cifrado de documentos como la autenticación mediante firma y certificados digitales, pero se diferencia de SSL en que se implementa a nivel de aplicación. Se puede identificar rápidamente a una página web servida con este protocolo porque la extensión de la misma pasa a ser .shtml en vez de .html como las páginas normales. 4. Protocolo SET SET se basa en el uso de certificados digitales para asegurar la perfecta identificación de todas aquellas partes que intervienen en una transacción on-line basada en el uso de tarjetas de pago, y en el uso de sistemas criptográficos de clave pública para proteger el envío de los datos sensibles en su viaje entre los diferentes servidores que participan en el proceso. Con ello se persigue mantener el carácter estrictamente confidencial de los datos, garantizar la integridad de los mismos y autenticar la legitimidad de las entidades o personas que participan en la transacción, creando así un protocolo estándar abierto para la industria que sirva de base a la expansión del comercio electrónico por Internet. 51 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 6: TIPOS DE ANALISIS: 6.1 METODOLOGÍAS DE ANÁLISIS DE SEGURIDAD WEB: Las aplicaciones web pueden ser analizadas utilizando distintos enfoques, entre ellos, es posible distinguir los siguientes: Análisis estático de código: El analista de seguridad posee acceso al código fuente de la aplicación, y posiblemente a manuales del usuario pero NO POSEE acceso a la aplicación en sí misma. Tiene como desventajas: Suele suceder, sobre todo con sistemas grandes, que la cantidad de información es tanta que puede resultar muy complejo manejarla. No es posible analizar todas las líneas del programa en búsqueda de vulnerabilidades, lo cual hace que sea complejo definir exactamente que secciones analizar. Cuando no es posible acceder a la aplicación, es común que el analista se "pierda" entre tanto código. White box: En este enfoque, el analista de seguridad posee acceso al código fuente de la aplicación, manuales del usuario, credenciales válidas del sistema, configuración del servidor Web, y acceso a la aplicación en sí misma. Tiene como ventajas: Más información disponible, más vulnerabilidades que se pueden descubrir. Es posible descubrir TODAS las vulnerabilidades (si se tiene el tiempo suficiente) y no es necesario suponer nada, todo está en el código. Black box: En este enfoque, el analista de seguridad posee únicamente acceso a la aplicación. Tiene como ventajas la simplicidad, menor tiempo de testing y provee un enfoque real, ya que se posee el mismo nivel de conocimiento sobre la aplicación que un potencial intruso. Como desventajas están: Vulnerabilidades trivialmente detectables con white box testing, no pueden ser detectadas con esta enfoque. (if user ==‘tester002’ and password ==‘backdoor__’) No se aprovecha el código fuente de la aplicación a favor de la seguridad de la misma. Dependiendo del tipo de enfoque, se aplican herramientas de análisis como las vistas en la Lección 2 de este módulo. 52 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB: Su definición es la obtención de los privilegios del administrador. Por ello, debe existir una política o normativa específica que establezca el uso de mecanismos para impedir intentos de escalado de privilegios en nuestras aplicaciones web. Se considera que un sistema aplica políticas para evitar el escalado de privilegios cuando: No es posible acceder a información del sistema que pueda ser utilizada para la escalada de privilegios, no es posible ejecutar acciones haciéndose pasar por otro usuario, etc. Las pruebas de escalada en aplicaciones web involucran por lo menos dos tipos de autenticación y validación. Un escenario típico para analizar la jerarquía de privilegios es si dada una aplicación web que debe tener al menos dos tipos de credenciales: para un usuario con privilegios elevados y bajos de privilegio. Al iniciar sesión como usuario con privilegios elevados (por ejemplo, admin), obviamente tenemos acceso a mucha más información (más elementos de menú, más funcionalidad, etc.) El punto de análisis crítico es determinar si esos temas (accesos a servicios) se puede acceder directamente por el usuario con pocos privilegios. El desarrollador debe estar seguro que la navegación por toda la aplicación de un usuario con privilegios bajos es confiable y que abarco cada entrada y salida de la aplicación. El manejo de estos privilegios suele ser administrado mediante credenciales de acceso haciendo uso de bases de datos. La exposición de estas credenciales son “huecos” vulnerables para la aplicación. Los datos de usuario y password son sensibles, por lo que deben tener garantizada una atención especial. Su presencia en el código fuente es un riesgo inevitable. Un caso típico de diseño de software es que sean administradas por un lenguaje de programación de uso general de código del lado del servidor originalmente diseñado para el desarrollo web como es PHP. Por conveniencia, estos datos son almacenados en un archivo como db.inc y suelen tener esta forma: <?php $db_user ='myuser'; $db_pass ='mypass'; $db_host ='127.0.0.1'; $db =mysql_connect($db_host, $db_user, $db_pass); ?> 53 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Al analizar el archivo por default http.confg de Apache, encontramos que el tipo default es text/plain. Esto significa un riesgo si el archivo db.inc se localiza en la raíz del directorio. Todo recurso localizado en la raíz tiene una dirección URL y como Apache no tiene un tipo de contenido asociado a los archivos .inc la respuesta del servidor será devolver el contenido en texto plano del archivo, en donde se podrían observar las credenciales del servidor. La mejor solución a este problema es almacenar los archivos a incluir en otro lugar fuera del directorio raíz. No es necesario tenerlos en algún lugar en particular en el sistema de archivos para ser capaces de incluirlos o requerirlos, solo es necesario garantizar que el servidor tenga privilegios de lectura. De hecho únicamente se debe localizar en la raíz los recursos que se deseen sean accesibles, o configurar un directorio público con las respectivas directivas de seguridad. LECCION 8: AUTENTICACION Y AUTORIZACION: Normalmente, casi todas las aplicaciones o sistemas necesitan de los procesos de autentificación y autorización. 8.1 LA AUTENTIFICACIÓN: Es el proceso por el cual un usuario o servicio tiene que autentificarse para poder acceder a ciertos servicios que ofrece nuestro sistema. Existen distintas categorías de autentificación: ¿Qué sabes?: Información que el usuario conoce, ejemplos: contraseñas, respuestas a preguntas de indicio a contraseñas. ¿Qué tienes?: Elementos físicos que el usuario posee, como por ejemplo una determinada tarjeta. ¿Quién eres?: Técnicas biométricas como lectura de retina o huellas dactilares. El control de acceso es el proceso de decidir si el usuario tiene permiso para ejecutar algo o no. HTTP por defecto tiene características de autentificación: autenticación del protocolo que se utiliza para intercambiar mensajes. Para la mayoría de los 54 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web servicios Web XML, esto significa aprovechar las características de autenticación disponibles en HTTP. Los tipos de autenticación típica son: Básica: utilizada para identificación no segura o poco segura de clientes, ya que el nombre de usuario y la contraseña se envían como texto codificado en base 64, que puede ser fácilmente descodificado. En el caso de IIS, autorizará el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida. Básica sobre SSL: igual que la autenticación básica, excepto que el canal de comunicación está cifrado y protege de ese modo el nombre de usuario y la contraseña. Una buena opción para entornos en Internet; sin embargo, el uso de SSL influye negativamente en el rendimiento. Implícita: utiliza algoritmos hash para transmitir las credenciales del cliente de forma segura. Sin embargo, es posible que no sea compatible con todas las herramientas de desarrollo para generar clientes de servicios Web XML. IIS autorizará el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida. Autenticación de Windows integrada: resulta útil sobre todo en entornos en Intranet. Utiliza NTLM o Kerberos. El cliente debe pertenecer al mismo dominio que el servidor o a un dominio en el que el dominio del servidor confía. IIS autorizará el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida. Certificados de cliente a través de SSL: requiere que cada cliente obtenga un certificado. Los certificados se asignan a las cuentas de usuario, que son utilizadas por IIS para autorizar el acceso a los servicios Web XML. Se trata de una solución viable para entornos en Internet, aunque el uso de certificados digitales no está muy extendido actualmente. Es posible que no sea compatible con todas las herramientas de desarrollo para generar clientes de servicios Web XML. Sólo está disponible en conexiones SSL, de modo que el rendimiento puede verse afectado 55 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 8.2 LA AUTORIZACIÓN: 25 • Que sólo las personas autorizadas podrán acceder a ciertos recursos (sistemas, equipos, programas, aplicaciones, bases de datos, redes, etc.) por sus funciones laborales. Se refiere a la gestión del acceso a los recursos protegidos y al proceso de determinar si un usuario está autorizado a acceder a un recurso particular. Por ejemplo, muchas aplicaciones web cuentan con recursos que sólo están disponibles para los usuarios autenticados, recursos que sólo están disponibles para los administradores, y los recursos que están disponibles para todos. Así, al establecer privilegios de acceso a los usuarios podemos asegurar la confidencialidad y disponibilidad de la información; pero, además, podemos: • Nos permiten identificar y auditar los accesos realizados, estableciendo controles de seguridad internos. • Documentar los procedimientos de acceso a las diferentes aplicaciones que tratan datos personales. • En definitiva, controlar los accesos desde diferentes vertientes: red, sistemas y aplicaciones. Se presentan dos categorías de Autorización: Autorización declarativa: En este tipo de autorización los privilegios son gestionados un administrador independientemente de manera externa al código de la aplicación Autorización programática: En este tipo de autorización las decisiones de autorización se realizan desde el código fuente de la aplicación. LECCION 9: EJECUCION DE INSTRUCCIONES DE ACCESO: 9.1 CODIFICACIÓN Y LAS VALIDACIONES DE ENTRADA / SALIDA: Indican que la debilidad de seguridad más común en aplicaciones web es la falta de validación apropiada de las entradas del cliente o del entorno. Teniendo en cuenta una serie de indicaciones y consejos a la hora de codificar nuestras aplicaciones podremos evitar problemas como la inyección de código SQL, de comandos, LDAP, XPath, XML o por XSS. 25 Disponible en internet dese <http://www.yiiframework.com/doc/guide/1.1/es/topics.auth> 56 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Esta debilidad lleva a casi todas las principales vulnerabilidades en las aplicaciones, tales como intérprete de inyección, ataques locale/Unicode, ataques al sistema de archivos y desbordamientos de memoria. Nunca se debe confiar en los datos introducidos por el cliente, ya que podría manipularlos. Hay que garantizar que la aplicación sea robusta contra todas las formas de ingreso de datos, ya sea obtenida del usuario, de la infraestructura, de entidades externas o de sistemas de base de datos. Existen vulnerabilidades asociadas a la validación de los datos, Vulnerabilidad de la integridad de los datos: El atacante manipula los datos introduciendo intencionadamente datos erróneos que manipulan la función de negocio. Violación del formato de los datos: Un atacante consigue introducir datos sin la sintaxis correcta, fuera de los límites de longitud, que contenga caracteres no permitidos, con signo incorrecto o fuera de los límites del rango. Esto provoca un mal funcionamiento de la aplicación. Incumplimiento de las reglas de negocio: Se introducen datos que no cumplen con las reglas de negocio. Lo que provoca un comportamiento no esperado de la aplicación. 9.2 GESTIÓN DE SESIONES Y USUARIOS: El manejo de la sesión es uno de los aspectos críticos de la seguridad WEB. Veremos cómo es posible mejorar la seguridad en el control de acceso y la autenticación a través del manejo de las sesiones y de la información de los usuarios de nuestras aplicaciones. Se detectan las siguientes vulnerabilidades significativas. Fijación de sesión que intenta explotar la vulnerabilidad de un sistema que permite a una persona fijar el identificador de sesión de otra persona. La mayoría de ataques de fijación del período de sesiones están basados en la web, y la mayoría depende de los identificadores de sesión que han sido aceptados de URL o datos POST Identificador de la sesión vul nerable, si no se reserva un tamaño adecuado el atacante, mediante técnicas de fuerza bruta atacante puede conocer el identificador de una sesión autenticada y por lo tanto hacerse con el control de la sesión. 57 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Manejo de la información de sesión errónea, ya sea por estar en un espacio compartido o mal encriptada, el atacante puede obtener datos de la sesión de otro usuario. Ataques de proxys o cachés, las aplicaciones web deben especificar mecanismos para impedir estos ataques de tal manera que no sea posible suplantar sesiones de otros usuarios. 9.3 GESTIÓN DE ERRORES Y EXCEPCIONES: Uno de los focos que originan vulnerabilidades en nuestras aplicaciones se basa en la falta de control sobre los errores que se producen en su ejecución y el tratamiento correcto de las excepciones. Veremos cómo disminuir los riesgos de ser atacados a partir de la generación de un error o excepción en la aplicación. El manejo de errores y excepciones son dos aspectos para realizar un seguimiento de fallos dentro de una aplicación. En términos generales, hay tres situaciones que hacen que las excepciones sean lanzadas: Excepciones que se producen en el código del cliente: El código cliente intenta hacer algo que no está permitido por la API, de esta forma viola el contrato. El cliente puede tomar algún camino alternativo, si hay información útil proporcionada en la excepción. Por ejemplo: una excepción es lanzada cuando se está analizando un documento XML que no está bien formado. La excepción contiene información útil acerca de la localización en el documento XML donde se produce el problema. El cliente puede utilizar esta información para recuperarse del problema. Excepciones por fallos en los recursos mantenidos: Las excepciones se producen si existe un fallo derivado de un recurso. Por ejemplo, el agotamiento de memoria o el fallo de conexión cuando se cae una red. La respuesta del cliente a los recursos que fallan depende del contexto. El cliente puede reintentar la operación después de algún tiempo o simplemente registrar el fallo del recurso y detener la aplicación. Excepciones por errores derivados del código programado: En esta categoría, las excepciones se producen en la ejecución del código. El código cliente usualmente no puede hacer nada con estos errores. 58 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 10: CONFIGURACION SEGURA DE SERVIDORES: La mayoría de los servidores web modernos nos permiten controlar desde el programa servidor aquellos aspectos relacionados con la seguridad y la autenticación de los usuarios. El modo más simple de control es el proporcionado por el uso de ficheros .htaccess. Éste es un sistema de seguridad que proviene de uno de los primeros servidores web (del NCSA httpd), que consiste en poner un fichero de nombre .htaccess en cualquier directorio del contenido web que se vaya a servir, indicando en este fichero qué usuarios, máquinas, etc., tienen acceso a los ficheros y subdirectorios del directorio donde está el fichero. Como el servidor de NCSA fue el servidor más usado durante mucho tiempo, la mayoría de servidores modernos permiten utilizar el fichero .htaccess respetando la sintaxis del servidor de NCSA. Otros servidores permiten especificar reglas de servicio de directorios y ficheros en la configuración del servidor web, indicando allí qué usuarios, máquinas, etc., pueden acceder al recurso indicado. Por lo que respecta a la autenticación (validación del nombre de usuario y contraseña proporcionados por el cliente), las prestaciones ofrecidas por los diversos servidores web son de lo más variado. La mayoría permiten, como mínimo, proporcionar al servidor web un fichero con nombres de usuario y contraseñas contra el que se pueda validar lo enviado por el cliente. De todos modos, es frecuente que los servidores proporcionen pasarelas que permitan delegar las tareas de autenticación y validación a otro software (por ejemplo RADIUS, LDAP, etc.). Si usamos un sistema operativo como Linux, que dispone de una infraestructura de autenticación como PAM (pluggable authentication modules), podemos usar esta funcionalidad como modo de autenticación del servidor web, permitiéndonos así usar los múltiples métodos disponibles en PAM para autenticar contra diversos sistemas de seguridad. 26 Una forma de implementar aspecto de seguridad en servidores web es la de administrar procesos y atender peticiones de una manera eficiente y económica, es necesario definir algunos términos. 10.1 ORGANIZACIÓN DEL SERVIDOR WEB: 26 <MATEU, Carles; Desarrollo de aplicaciones web, p 24, 25 > 59 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Proceso: la unidad más “pesada” de la planificación de tareas que ofrece el sistema operativo. No comparte espacios de direcciones ni recursos relacionados con ficheros, excepto de manera explícita (heredando referencias a ficheros o segmentos de memoria compartida), y el cambio de tarea lo fuerza el núcleo del sistema operativo (preemptivo). Flujo o thread: la unidad más “ligera” de planificación de tareas que ofrece el sistema operativo. Como mínimo, hay un flujo por proceso. Si distintos flujos coexisten en un proceso, todos comparten la misma memoria y recursos de archivos. El cambio de tarea en los flujos lo fuerza el núcleo del sistema operativo (preemptivo). Fibra: flujos gestionados por el usuario de manera cooperativa (no preemptivo), con cambios de contexto en operaciones de entrada/salida u otros puntos explícitos: al llamar a ciertas funciones. La acostumbran a implementar librerías fuera del núcleo, y la ofrecen distintos sistemas operativos. En general, los modelos con muchos procesos son costosos de memoria (cada proceso ocupa su parte) y de carga (creación de procesos). En servidores de alto rendimiento, los modelos con flujos parecen mejores, aunque tienen el problema de la portabilidad difícil y la posible necesidad de mecanismos que anticipan el coste de creación de procesos o flujos y, por lo tanto, son muy rápidos atendiendo peticiones. En máquinas uniprocesador, los modelos con un solo flujo funcionan bien. En máquinas multiprocesador, es necesario usar múltiples flujos o procesos para aprovechar el paralelismo del hardware. 10.2 ORGANIZACIÓN DE LAS APLICACIONES WEB: Los servidores web se encargan de atender y servir peticiones HTTP de recursos, que en su forma más simple acostumbran a ser documentos guardados en el sistema de ficheros. Sin embargo, la otra función importante de un servidor web es la de actuar de mediador entre un cliente y un programa que procesa datos. Recibe una petición con algún argumento, la procesa y devuelve un resultado que el servidor web entrega al cliente. La interacción entre el servidor web y los procesos que tiene asociados es otro aspecto que hay que considerar. Existen distintas maneras de organizar una aplicación web. A continuación, por orden cronológico de complejidad y rendimiento creciente, se presentan distintos modelos de organización. 60 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web CGI: es el modelo más antiguo y simple. Para cada petición HTTP se invoca un programa que recibe datos por las variables del entorno y/o de entrada estándar, y devuelve un resultado por la salida estándar. Consumir un proceso por cada petición genera problemas importantes de rendimiento, que el modelo FastCGI intenta mejorar. Servlets: es un modelo diseñado para J ava, más eficiente y estructurado, que permite elegir distintos modelos de gestión de flujos o threads, duración de procesos del servidor, etc. Partiendo de este modelo, se han construido servidores de aplicaciones con múltiples funciones adicionales que facilitan el desarrollo de aplicaciones web complejas. CAPITULO 3 DESARROLLO SEGURO DE APLICACIONES: LECCION 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO DE APLICACIONES: La importancia de una metodología de desarrollo seguro en aplicaciones Web inicia cuando el principal problema reside en la falta de controles durante el ciclo de vida del desarrollo de un aplicativo, ya que impera mas el hecho que funcione que el hecho de ser seguro, lo cual es un problema para aplicaciones WEB. ¿Qué amenazas tiene una persona que navegue por Internet? Suplantación de identidad, robo de credenciales, alteración de los contenidos de la web, ejecución de acciones sin su conocimiento. Cada uno de ellos está derivado tanto de una mala metodología de desarrollo como de una falta de concienciación de los usuarios, los cuales acceden a cualquier enlace sin identificar su procedencia. Las amenazas, debido a una mala programación, pueden permitir al atacante desde la obtención de las credenciales de un usuario, hasta la modificación del contenido de la página web vulnerable pasando por la realización de acciones sin conocimiento del usuario como compras o transacciones bancarias. Para cada una de estas acciones hay soluciones más o menos sencillas pero hace falta más concienciación por parte del equipo de desarrollo para identificarlas en las diferentes fases del desarrollo. Por ello, hay que hacer hincapié en identificar en las fases de diseño además de los casos de uso, los casos de abuso. Un caso de abuso, es la identificación de las diferentes amenazas que pueden asociarse a un caso de uso. Por ejemplo, en 61 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web una ventana de login (página donde se introduce el usuario y la contraseña) ¿Cuáles son las amenazas principales? autenticarse sin conocer la contraseña, obtención de credenciales, enumeración de usuarios,… Una vez identificados los diferentes casos de abuso, el siguiente paso sería implantar y diseñar los controles para evitar estas amenazas. La mayoría de las amenazas se mitigan a través de una validación robusta de los datos de entrada. Cada vez es más importante el posicionamiento en internet para la venta de diferentes productos o servicios. Si una determinada empresa A tiene una vulnerabilidad en su web y está, a su vez, es explotada ¿Cuál es el impacto para la organización? Pérdida de confianza de sus clientes con la consiguiente pérdida económica y de imagen, impacto económico en base a las normativas vigentes de protección de datos si se publican datos de carácter personal. Además hay que añadir el gasto que supone la corrección de las vulnerabilidades, este gasto es superior al gasto económico que hubiera supuesto la realización de pruebas de identificación de vulnerabilidades en el proceso de desarrollo software. .No existen páginas webs 100% seguras a pesar de que se les haya implementado un ciclo de desarrollo seguro de aplicaciones. Figura 18: Metodología de desarrollo seguro Fuente: <http://www.consultec.es/> 62 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Entendemos por aplicaciones web a todo aquél software que interacciona con el usuario utilizando el protocolo HTTP. Por su parte, los servicios web son un conjunto de funciones empaquetadas dentro de una entidad única y publicadas dentro de la red para que puedan ser utilizadas por las aplicaciones web. 11.1 NORMAS BASICAS DE SGEURIDAD: El proyecto OWASP (Open Web Application Security Project) tiene como objetivo ofrecer una metodología, de libre acceso y utilización, que pueda ser utilizada como material de referencia por parte de los arquitectos de software, desarrolladores, fabricantes y profesionales de la seguridad involucrados en el diseño, desarrollo, despliegue y verificación de la seguridad de las aplicaciones y servicios web. La guía empieza estableciendo el principio básico de seguridad que cualquier aplicación o servicio web debe cumplir: • Validación de la entrada y salida de información La entrada y salida de información es el principal mecanismo que dispone un atacante para enviar o recibir código malicioso contra el sistema. Por tanto, siempre debe verificarse que cualquier dato entrante o saliente es apropiado y en el formato que se espera. Las características de estos datos deben estar predefinidas y debe verificarse en todas las ocasiones. • Diseños simples Los mecanismos de seguridad deben diseñarse para que sean los más sencillos posibles, huyendo de sofisticaciones que compliquen excesivamente la vida a los usuarios. Si los pasos necesarios para proteger de forma adecuada una función o modulo son muy complejos, la probabilidad de que estos pasos no se ejecuten de forma adecuada es muy elevada. • Utilización y reutilización de componentes de confianza Debe evitarse reinventar la rueda constantemente. Por tanto, cuando exista un componente que resuelva un problema de forma correcta, lo más inteligente es utilizarlo. • Defensa en profundidad Nunca confiar en que un componente realizará su función de forma permanente y ante cualquier situación. Hemos de disponer de los mecanismos de seguridad suficientes para que cuando un componente del sistema fallen ante un determinado evento, otros sean capaces de detectarlo. 63 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web • Tan seguros como en eslabón más débil La frase "garantizamos la seguridad, ya que se utiliza SSL" es realmente muy popular, pero también es muy inexacta. La utilización de SSL garantiza que el tráfico en tránsito entre el servidor y el cliente se encuentra cifrado, pero no garantiza nada acerca de los mecanismos de seguridad existentes. Por tanto, no debemos fiarnos únicamente de los mecanismos de seguridad "exteriores", sino que es preciso identificar cuáles son los puntos precisos en los que deben establecerse las medidas de seguridad. Si nosotros no hacemos este trabajo, seguro que los atacantes si lo harán. • La "seguridad gracias al desconocimiento" no funciona El simple hecho de ocultar algo no impide que, a medio o largo plazo, llegue a ser descubierto. Tampoco es ninguna garantía de que tampoco será descubierto a corto plazo. • Verificación de privilegios. Los sistemas deben diseñarse para que funcionen con los menos privilegios posibles. Igualmente, es importante que los procesos únicamente dispongan de los privilegios necesarios para desarrollar su función, de forma que queden compartimentados. • Ofrecer la mínima información Ante una situación de error o una validación negativa, los mecanismos de seguridad deben diseñarse para que faciliten la mínima información posible. De la misma forma, estos mecanismos deben estar diseñados para que una vez denegada una operación, cualquier operación posterior sea igualmente denegada. Otros aspectos tratados en la guía son: consideraciones de arquitectura, mecanismos de autenticación, gestión de sesiones de usuario, control de acceso, registro de actividad, prevención de problemas comunes, consideraciones de privacidad y criptografía El proyecto OWASP, “The Open Web Application Security Project” presenta a disposición de todos los usuarios en la web “A Guide to Building Secure Web Applications” 27 27 Disponible en internet desde <http://www.owasp.org/guide/> y ha sido reconocida como una metodología de desarrollo seguro que ha dado resultados. Estos documento se presentan como anexos a este módulo. 64 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Se referencian estos documentos: Secure Programming for Linux and Unix HOWTO 28 SPSMM - Estándar de programación segura (Secure Programming Standards Methodology Manual) que documentan estrategias seguras en el desarrollo de aplicaciones web. 29 LECCION 12: CONTROLES DE AUTORIZACION DE OBJETOS: Un control simple de objeto en una aplicación web puede ser el solo simple hecho de comprobar el tipo de dato. La validación de datos garantiza la corrección y precisión de todos los valores de datos de la aplicación. Estas acciones se pueden diseñar utilizando distintos enfoques: código de interfaz de usuario, código de aplicación o restricciones de bases de datos. Un ejemplo de validación de control de objetos es el código de servicio con tipo de datos "character" sólo puede admitir caracteres alfabéticos de la A a la Z; el resto de caracteres no sería válido. Otro tipo de control típico es el que se aplica al validar un control TextBox y mostrar un mensaje personalizado cuando se produce un error en la validación. De manera predeterminada, la validación se realiza al hacer clic en un control de botón, como Button, ImageButton o LinkButton. Hay varios tipos de validación de datos: • Validación del tipo de datos. • Comprobación del intervalo. • Comprobación del código. • Validación compleja La tabla 2 muestra las propiedades básicas de un control de validación 28 Disponible en internet desde <http://www.dwheeler.com/secure-programs/> 29 Disponible en internet dese <http://isecom.securenetltd.com/spsmm.0.5.1.en.pdf> 65 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web PROPIEDAD DESCRIPCION ControlToValidate Id. de programación del control de salida que evaluará el control de validación. Si no es un Id legítimo, se iniciará una excepción. Display Modo en que se muestra el control de validación especificado. Esta propiedad puede ser uno de los siguientes valores: Ni nguno: El control de validación jamás se muestra en línea. Utilice esta opción cuando desee mostrar el mensaje de error sólo en un control ValidationSummary Estáti co: El control de validación muestra un mensaje de error si se produce un error en la validación. Se asigna un espacio en la página Web para el mensaje de error incluso si el control de entrada supera la validación. No cambia el diseño de la página cuando el control de validación muestra su mensaje de error. Como el diseño de página es estático, si hay varios controles de validación para el mismo control de entrada, éstos deberán ocupar distintas ubicaciones en la página. Di námi co: El control de validación muestra un mensaje de error si se produce un error en la validación. El espacio para el mensaje de error se asigna dinámicamente en la página cuando se produce un error en la validación. De este modo, varios controles de validación pueden compartir la misma ubicación física en la página. EnableClientScript Indica si está habilitada la validación en el cliente. Para deshabilitar la validación en el cliente en los exploradores que admitan esta función, establezca la propiedad Enabl eCl i entScri pt en false. Enabled Indica si está habilitado el control de validación. Para impedir que el control de validación valide un control de entrada, establezca esta propiedad en fal se. ErrorMessage Mensaje de error que se va a mostrar en el control ValidationSummary si se produce un error en la validación. Si no está establecida la propiedad Text del control de validación, también se muestra este texto en el control de validación cuando se produce un error en la validación. Se utiliza normalmente la propiedad ErrorMessage para proporcionar diferentes mensajes para el control de validación y el control Vali dati onSummary. ForeColor Especifica el color en el que se va a mostrar el mensaje en línea cuando se produce un error en la validación. IsValid Indica si el control de entrada especificado por la propiedad Control ToVali date se determina como válido. Text Si esta establecida esta propiedad, se muestra este mensaje en el control de validación cuando se produce un error en la validación. Si no está establecida esta propiedad, el texto especificado en la propiedad ErrorMessage se muestra en el control. Tabla 2: Propiedades de los controles de validación Fuente: <http://www.microsoft.com/asp.net > 66 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 12.1 LISTAS DE CONTROL DE ACCESO (ACL) Los controles de acceso también están incluidos en aspectos de denegación de servicio que no solo afectan a los accesos y validaciones propios del sitio, sino también al entorno del mismo. Un ACL es una lista secuencial de sentencias de permiso o denegación que se aplican a direcciones IP o protocolos de capa superior. La ACL puede extraer la siguiente información del encabezado del paquete, probarla respecto de las reglas y decidir si “permitir” o “denegar” el ingreso según los siguientes criterios: • Dirección IP de Origen • Dirección IP de Destino • Tipo de mensaje ICMP La ACL también puede extraer información de las capas superiores y probarla respecto de las reglas. La información de las capas superiores incluye: • Puerto TCP / UDP de Origen • Puerto TCP / UDP de Destino Figura 19: Filtrado de paquetes con ACL Fuente: El Autor 67 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web El funciónenlo de ACL se basa en una búsqueda de arriba abajo (de la lista de texto plano), una línea a la vez y se busca un patrón que coincida con el paquete entrante. La figura 19 muestra como se realiza el filtrado de paquetes con ACL 12.1.1. Configuración de las ACL: Pueden configurarse por Protocolo, Por dirección y Por interfaz. ALC por Protocolo: Para controlar el flujo de tráfico de una interfaz, se debe definir una ACL para cada protocolo habilitado en la interfaz. ALC por Di rección: Las ACL controlan el tráfico en una dirección a la vez de una interfaz. Deben crearse dos ACL por separado para controlar el tráfico entrante y saliente. ALC por Interfaz: Las ACL controlan el tráfico para una interfaz, ejemplo eth0 (si se está en un sistema UNIX). 12.1.2. Funciones de la ACL: Las ACL realizan las siguientes tareas: • Limitar el tráfico de red para mejorar el rendimiento de esta. • Brindar control de flujo de tráfico • Proporciona un nivel básico de seguridad para el acceso a la red • Se debe decidir qué tipos de tráfico enviar o bloquear en las interfaces del router • Controlar las áreas de red a las que puedan acceder un cliente. • Analizar los hosts para permitir o denegar su acceso a los servicios de red • Puede darle prioridad al tráfico de la red. LECCION 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES: La mayoría de las aplicaciones web son usadas como un conducto entre muchas fuentes de datos y el usuario, esto es, las aplicaciones web son usadas frecuentemente para interactuar con una base de datos. Aunque el tema de la seguridad en las bases de datos merece un tratamiento diferente al de las aplicaciones web, se encuentran íntimamente relacionados. Toda entrada al sistema debe ser filtrada, y toda salida escapada. Lo mismo aplica cuando las entradas o salidas son de o hacia una base de datos. 68 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Muchos programadores no dan importancia al filtrado de datos provenientes de una consulta a la base de datos, debido a que consideran a esta fuente como confiable. Aunque el riesgo a primera vista parecería menor, es una práctica recomendable no confiar en la seguridad de la base de datos e implementar la seguridad a fondo y con redundancia. Si algún dato malicioso pudiera haber sido inyectado a la base de datos, nuestra lógica de filtrado puede percatarse de ello, pero sólo si se ha implementado este mecanismo. 13.1 EXPOSICION DE DATOS Una de las preocupaciones más comunes relacionadas con las bases de datos es la exposición de datos sensibles. Al almacenar números de tarjetas de crédito, o algo tan delicado, es preferible asegurarse que los datos almacenados en la base de datos se encuentran seguros e inaccesibles incluso para los administradores de la base. Una buena recomendación es encriptar los datos más sensibles, de esta manera si la base de datos llega a ser comprometida el desastre será menor. Un ejemplo de esta técnica es almacenar las contraseñas de usuario convertidas con md5. De esta manera, las cadenas de las claves almacenadas en la base de datos como md5 no son útiles al atacante para conocer contraseñas que le permitirían el acceso al sistema ya que no es posible conocer la cadena de texto original. 13.2 PÁGINAS PRIVADAS Y LOS SISTEMAS DE AUTENTICACIÓN La autenticación es el proceso por el cual la identidad de un usuario en el sistema es validada. Comúnmente el procedimiento involucra un nombre de usuario y una contraseña a revisar. Una vez autenticado el usuario es registrado (logueado) como un usuario que se ha autenticado. Muchas aplicaciones tienen recursos que son accesibles sólo para los usuarios autenticados, recursos que son accesibles únicamente para los administradores y recursos totalmente públicos. El control de acceso debe encontrarse totalmente integrado al diseño original. No debe ser algo improvisado sobre una aplicación ya existente. 13.3 ATAQUES DE FUERZA BRUTA Un ataque de este tipo agota todas las posibilidades sin preocuparse por cuales opciones son las que tienen mayor probabilidad de funcionar. En los términos del 69 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web control de acceso, generalmente encontramos al atacante intentando registrarse mediante un gran número de pruebas. En algunos casos el atacante puede conocer nombres de usuario válidos y la contraseña es la única parte que se trata de adivinar. Limitar el número de intentos que se le permite al usuario tratar de adivinar es una medida efectiva en contra de estos ataques, pero tiene por desventaja de poder afectar el uso del sistema a usuarios legítimos. Una propuesta un poco más considerada con el usuario seria intentar encontrar patrones en las peticiones enviadas por el atacante y únicamente bloquear el uso de la cuenta para peticiones que cumplan con dicho patrón, de esta forma se interfiere menos el uso al usuario legítimo. Otra opción sería imponer un intervalo de tiempo pequeño (ejemplo 15 segundos) que se debe esperar para poder intentar registrarse en el sistema de nuevo después de una falta en la autenticación. De esta manera, se niega el acceso sin importar si se presentaron las credenciales fue correcta, por supuesto que no se le dice al atacante la razón por la que se le negó el acceso para evitar lo intente de nuevo cuando haya terminado el plazo de espera. Trabajando de esta forma, se busca reducir el tiempo útil que tiene el atacante para intentar adivinar las credenciales de acceso. 13.4 ESPIONAJE DE CONTRASEÑAS (PASSWORD SNIFFING) Cuando un atacante tiene los medios para analizar el tráfico entre los usuarios y el servidor de la aplicación, debemos preocuparnos por la exposición que pueden tener los datos en el trayecto, sobre todo cuando se trata de credenciales de acceso. Una manera efectiva de prevenir este tipo de problemas es usar SSL para proteger los contenidos enviados en las peticiones y respuestas en HTTP. Debemos considerar utilizar esta tecnología tanto para cuando se envíen las credenciales de acceso como los identificadores de una sesión ya establecida, de esta forma evitamos un secuestro de la sesión. Usar SSL para proteger el envío de HTML es además una medida útil para brindar confianza a los usuarios de enviar sus datos cuando ven en su navegador el uso de https. Pero como se vio en la lección “Mitos de seguridad en aplicaciones web”, ésta sola medida no es suficiente. 70 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 13.5 REGISTROS PERSISTENTES Cuando un usuario permanece en el estado de registrado después de un tiempo no razonable (cuando la sesión expiró por ejemplo), tenemos un problema de registros persistentes. Este tipo de problemas disminuyen la seguridad de nuestro mecanismo de autenticación. Generalmente estos problemas son causados por una cookie persistente, o un ticket enviado al usuario para hacer referencia a la sesión de registro establecida que no se considera como expirado jamás o que no cambia en cada nuevo registro establecido por el usuario. Si el ticket de acceso permanece constante para cualquier sesión establecida tenemos un problema serio, la manera más sencilla de evitarlo es haciéndolo dependiente de una variable aleatoria. Otra medida recomendable es requerir la contraseña del usuario cuando vaya a realizar alguna tarea administrativa importante en el sistema. Con este esquema se permite el acceso únicamente a los recursos que no son tan sensibles. LECCION 14: VALIDACION DE ENTRADAS: La debilidad de seguridad más común en aplicaciones web es la falta de validación apropiada de las entradas del cliente o del entorno. Teniendo en cuenta una serie de indicaciones y consejos a la hora de codificar nuestras aplicaciones podremos evitar problemas como la inyección de código SQL, de comandos, LDAP, XPath, XML o por XSS. Esta debilidad lleva a casi todas las principales vulnerabilidades en las aplicaciones, tales como intérprete de inyección, ataques locale/Unicode, ataques al sistema de archivos y desbordamientos de memoria. Nunca se debe confiar en los datos introducidos por el cliente, ya que podría manipularlos. Hay que garantizar que la aplicación sea robusta contra todas las formas de ingreso de datos, ya sea obtenida del usuario, de la infraestructura, de entidades externas o de sistemas de base de datos. Existen vulnerabilidades asociadas a la validación de los datos: 71 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Vulnerabilidad de la integridad de los datos: El atacante manipula los datos introduciendo intencionadamente datos erróneos que manipulan la función de negocio. Violación del formato de los datos: Un atacante consigue introducir datos sin la sintaxis correcta, fuera de los límites de longitud, que contenga caracteres no permitidos, con signo incorrecto o fuera de los límites del rango. Esto provoca un mal funcionamiento de la aplicación. Incumplimiento de las reglas de negocio: Se introducen datos que no cumplen con las reglas de negocio. Lo que provoca un comportamiento no esperado de la aplicación. HTML resulta adecuado para aplicaciones simples, pero es poco adecuado para aplicaciones complejas: • Conjuntos de datos complejos. • Datos que deben ser manipulados de formas diversas. • Datos para controlar programas. • Sin capacidad de validación formal. Ante todo esto, el W3C desarrolló un nuevo lenguaje (XML), que proporciona: Extensibilidad: se pueden definir nuevas marcas y atributos según sea necesario. Estructura: se puede modelar cualquier tipo de datos que esté organizado jerárquicamente. Validez: podemos validar automáticamente los datos (de forma estructural). Independencia del medio: podemos publicar el mismo contenido en multitud de medios. XML no es un lenguaje, sino un meta-lenguaje que permite definir multitud de lenguajes para propósitos específicos. Estas definiciones, e incluso las definiciones de programas de traducción y transformación de ficheros XML, se definen en XML, lo que da una muestra de la potencia de XML. En XML se ha definido gran número de lenguajes. De hecho, el fichero de configuración de algunos de los programas más usados en la web (Tomcat, Roxen, etc.) está definidos con XML. Hay muchos ficheros de datos, de documentos, etc., que también lo usan para su definición. Algunos de los lenguajes definidos con XML más conocidos son: • SVG (scalable vector graphics). 72 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web • DocBook XML (Docbook-XML). • XMI (XML metadata interface format). • WML (WAP markup language). • MathML (mathematical markup language). • XHTML (XML hypertext markup language). XML posibilita la comprobación automática de la correcta forma de un documento, pero sin información adicional es imposible comprobar la validez de éste a partir del propio documento. Para ello, el W3C ha desarrollado algunos estándares de XML que permiten validar un documento a partir de una especificación formal de cómo debe ser éste. Dichos estándares son DTD y XSchema. DTD es un estándar antiguo, derivado de SGML y que adolece de algunas deficiencias graves, siendo la más grave de ellas el hecho de no estar escrito en XML. XSchema, por otro lado, es un estándar relativamente moderno, muy potente y extensible, que además está escrito en XML íntegramente. Muchas de las entradas de validación de datos se apoyan en este estándar. LECCION 15: SQL IJECTION: La inyección SQL (Structured Query Language) Injection es un ataque en el que se inserta código SQL o como anexo en los parámetros de entrada de la solicitud de usuario que posteriormente se pasan a un servidor back-end de SQL Server para su análisis y ejecución. Cualquier procedimiento que construye declaraciones SQL podría ser vulnerable, ya que la naturaleza diversa de SQL y los métodos disponibles para la construcción que proporcionan una gran cantidad de codificación. Un ataque menos directo inyecta código malicioso en las cadenas que están destinados para el almacenamiento en una tabla o como metadato. Cuando estas cadenas son almacenadas posteriormente se concatenan en una tabla dinámica que ejecuta comandos inesperados y sentencias de SQL y es allí donde el código malicioso es ejecutado en la aplicación web. Cuando se utiliza un servidor SQL para ejecutar comandos que interactúan con el sistema operativo, el proceso se ejecutará con los mismos permisos que el componente que ejecutó el comando (por ejemplo, servidor de base de datos, servidor de aplicaciones o servidor web), que a menudo suelen ser sentencias, sesione se instrucciones con información muy privilegiada. 73 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Mediante un ejemplo sencillo se puede interpretar esta vulnerabilidad: Si un usuario hace una consulta a un sitio web (tienda online) para ver todos los productos que cuesten menos de $ 100, a través de la siguiente URL: http://www.victim.com/products.php?val=100 El ejemplo de la URL anterior utiliza los parámetros GET en lugar de POST de parámetros para facilitar la ilustración. Parámetros POST son tan fáciles de manipular, sin embargo, esto generalmente implica el uso de otro componente, como una herramienta de manipulación de tráfico, navegador Web plug-in o aplicación proxy en línea El atacante intenta inyectar sus propios comandos SQL modificando el parámetro de entrada “val” añadiendo la cadena 'OR '1' ='1 a la URL: http://www.victim.com/products.php?val=100’ OR ‘1’=’1 Esta vez, la sentencia de SQL que el script de PHP genera y ejecuta, devolverá todos los productos en la base de datos, independientemente de su precio. Esto se debe a que se ha modificado la lógica de la pregunta. Esto sucede porque los resultados de la instrucción del operando de consulta siempre devuelve “true”, es decir, 1 siempre será igual a 1. Esta es la consulta que fue construida y ejecutada: SELECT * FROM ProductsTbl WHERE Price <'100.00' OR '1'='1' ORDER BY ProductDescription; Hay muchas maneras para aprovechar las vulnerabilidades de inyección SQL para lograr una gran variedad de objetivos, el éxito del ataque es generalmente altamente dependiente de la base de datos subyacente y de los sistemas interconectados que están bajo ataque. A veces puede tomar una gran cantidad de habilidad y perseverancia para explotar una vulnerabilidad en todo su potencial. En el ejemplo anterior demuestra cómo un atacante puede manipular una sentencia SQL creada dinámicamente que se forma a partir de la entrada que no se ha validado o codificada para llevar a cabo acciones que el desarrollador de una aplicación no previó. 74 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web El ejemplo, sin embargo, tal vez no ilustra la eficacia de esa vulnerabilidad; después de todo, sólo se utiliza el vector (vec) para ver todos los productos en la base de datos, y que un usuario legítimo podría haberlo hecho mediante la consulta a la misma aplicación. Si esa misma aplicación fuera administrada de forma remota mediante utilizando un sistema de gestión de contenidos (CMS) (Un CMS es una aplicación Web que se utiliza para crear, editar, gestionar y publicar contenido en un sitio Web, sin necesidad de tener un conocimiento en profundidad de la capacidad de codificar o en HTML). Se podría acceder a la aplicación CMS mediante la siguiente URL: http://www.victim.com/cms/login.php?username=foo&password=bar La aplicación CMS requiere que usted proporcione un nombre de usuario y contraseña para poder acceder a su funcionalidad de administrar y modificar el sitio. Si un atacante digita un nombre de usuario y contraseña errados, la aplicación devuelve un error "nombre de usuario o contraseña incorrecta, por favor, inténtelo de nuevo". Aquí está el código para el script login.php que devuelve el error: // connect to the database $conn =mysql_connect("localhost","username","password"); // dynamically build the sql statement with the input$query ="SELECT userid FROM CMSUsers WHERE user ='$_GET["user"]' " . "AND password ='$_GET["password"]'"; // execute the query against the database $result =mysql_query($query); // check to see how many rows were returned from the database $rowcount = mysql_num_rows($result); // if a row is returned then the credentials must be valid, so // forward the user to the admin pages if ($rowcount !=0){header("Location: admin.php");} // if a row is not returned then the credentials must be invalid else {die('Incorrect username or password, please try again.')} El script login.php crea dinámicamente una sentencia SQL que devuelve un conjunto de registros si un nombre de usuario y contraseña correspondiente es 75 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web digitado. La sentencia SQL que el script de PHP genera y ejecuta, se ilustra más claramente en la consulta siguiente: SELECT userid FROM CMSUsers WHERE user ='foo' AND password ='bar'; Devolverá el ID de usuario que corresponde al usuario y los valores de la contraseña si los datos introducidos coinciden con un valor correspondiente almacenado en la tabla de CMSUsers El problema con el código es que el desarrollador de aplicaciones asuma que el número de registros devueltos cuando la secuencia de comandos se ejecuta siempre será cero o uno. En el ejemplo anterior la inyección, se utilizó el vector explotable para cambiar el significado de la consulta SQL para devolver siempre el valor “true”. Si utilizamos la misma técnica con la aplicación de la CMS, podemos hacer que la lógica de la aplicación falle. Añadiendo la cadena 'OR '1' ='1 a la siguiente dirección URL, la sentencia SQL que el script PHP construye y ejecuta en ese momento, devolverá todos los identificadores de usuario para todos los usuarios de la URL que estén en la tabla CMSUsers: http://www.victim.com/cms/login.php?username=foo&password=bar’ OR ‘1’=’1 Todos los identificadores de usuario se devuelven debido a que se altera la lógica de las consultas o peticiones de acceso. Esto sucede porque los resultados de la instrucción del operando de la consulta siempre se devuelven como verdaderas, es decir, 1 siempre será igual a 1. Esta es la consulta que se ejecuta: SELECT userid FROM CMSUsers WHERE user ='foo' AND password ='password' OR '1'='1'; La lógica de la aplicación significa que si la base de datos devuelve más de cero registros, debemos haber entrado en las credenciales de autenticación correctas y deben ser redirigido y con acceso al script admin.php. Con esto se ha modificado la lógica de la aplicación y la inyección de código ha surtido efecto. 76 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Ahora especifiquemos ¿Cómo un intruso inyectará una sentencia SQL en lugar de colocar el nombre de usuario, Password y cuenta?: En la figura 20 se muestra una web con formularios de ingreso que podrían ser vulnerables: Figura 20: Formulario de validación de datos Fuente: El Autor Si los campos de datos, la aplicación y el gestor de datos no están validados y filtrados (no escapa a los caracteres especiales) y asegurados, se podrá incluir una comilla simple ‘y seguido a ella, el resto de lo que será interpreta do por el gestor de base de datos como código SQL. SELECT id FROM login WHERE usuario =‘admin’´ AND clave =‘’’OR AND cuenta =46789675 77 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Un parámetro no esperado, como esta comilla, cambia el comportamiento de la aplicación. De este modo , si el usuario es el admin y tiene un Password / con la condición, si 1 es igual a 1(que de hecho lo es), éste será válido y tendrá acceso a la aplicación web o a la intranet en la mayoría de casos. ¿Cómo saber que determinado campo de datos o URL, es vulnerable a la inyección de código SQL? Esto se logra intentando escribir y enviar una comilla simple en el campo del formulario para obtener determinado error del sistema que es generado por la base de datos del sistema. Hay otros métodos que son propios de cada navegador o aplicación de ataque o de monitoreo. ¿Cómo buscar en Internet sitios web con formularios de acceso a aplicaciones web tentativamente vulnerables? En un buscador se pueden dar estas opciones de búsqueda que darán como resultados muchos formularios de acceso, links o campos de consulta de datos para ver dichos errores. inurl:login.asp ó inurl:buscar.asp ó site:.ar ó password.asp ó intranet ó contraseña.asp ó clave.asp ó intitle:”acceso restringido” ó site.asp Incluso en muchos casos, son tan vulnerables que la aplicación leva al usuario al salto de la famosa “pregunta secreta” para restaurar la contraseña. 15.1 VARIANTES DE SINTAXIS: Las variantes de sintaxis (en inyección) varían según el gestor de base de datos (MS-SQL, Mysql, Oracle, PostgreSQL). 15.2 OTRAS CLASES DE INYECCIÓN: Las hay del tipo ORM, LDAP, XML (hacking SOAP), SSI, XPATH, e IMAP/SMTP. El proyecto OWASP documenta cada tipo de vulnerabilidad en el sitio web oficial. 78 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web UNIDAD 2: ANALISIS Y DISEÑO SEGURO DE APLICACIONES WEB CAPITULO 4: AREAS CRÍTICAS DE DESARROLLO: LECCION 16: SECUENCIA DE COMANDOS EN SITIOS CRUZADOS (XSS) XSS es un tipo de vulnerabilidad de seguridad informática típicamente encontrada en aplicaciones web que permiten la inyección de código por usuarios maliciosos en páginas web vistas por otros usuarios. Los atacantes típicamente se valen de código HTML y de scripts ejecutados en el cliente. Una vulnerabilidad de este tipo puede ser usada por los atacantes para burlar los controles de acceso comunes. Recientemente este tipo de ataques han sido explotados para crear poderosos ataques de phishing y de abusos en el navegador. Desde la liberación del lenguaje J avaScript, se previeron los riesgos de permitir a un servidor Web enviar código ejecutable al navegador. Un problema se presenta cuando los usuarios tienen abiertos varias ventanas de navegador, en algunos casos un script de una página podría acceder datos en otra página u objeto, observando el peligro de que un sitio malicioso intentara acceder datos sensibles de esta forma. Por ello se introdujo la política same −origin. Esencialmente esta política permite la interacción entre objetos y páginas, mientras estos objetos provengan del mismo dominio y en el mismo protocolo. Evitando así que un sitio malicioso tenga acceso a datos sensibles en otra ventana del navegador vía J avaScript. A partir de entonces se han introducido otros mecanismos y políticas de control en los navegadores y en los lenguajes en el lado del cliente, para proteger a los usuarios de sitios maliciosos. Las vulnerabilidades XSS pueden ser vistas como técnicas de evasión de las políticas de protección. Encontrando formas ingeniosas de inyectar códigos maliciosos en las páginas servidas por otros dominios, un atacante puede ganar privilegios a datos sensibles, cookies de sesión y otros objetos. 16.1 TIPOS DE VULNERABILIDAD XSS Existen dos diferentes tipos de vulnerabilidades XSS: 79 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Tipo 0: También conocido como basado en el DOM o Local. Con este tipo de vulnerabilidad, el problema existe en el script del lado del cliente. Si un código de J avaScript accede a una URL como un parámetro de una petición al servidor y utiliza esta información para escribir HTML en la misma página sin ser codificada empleando entidades HTML, existe un agujero XSS, dado que estos datos escritos serán interpretados por los navegadores como código HTML que puede incluir en si código adicional del lado del cliente. Los ataques de este tipo pueden devenir en la ejecución remota de comandos. En el caso de que el atacante suba un sitio malicioso, que contenga un link a una página vulnerable en el sistema de archivos del cliente, resultando en la ejecución con privilegios del navegador del sistema. De esta manera no sólo se pasan las restricciones de comunicación entre dominios. Tipo 1: A este tipo de agujero XSS se le conoce también como no persistente o reflejado, y es por mucho el más común. Estos agujeros aparecen cuando los datos provistos por un cliente web son usados inmediatamente en el lado del servidor para generar una página de resultados para el usuario. Si los datos no validados por el usuario son incluidos en la página resultante sin codificación HTML, se le permite al cliente inyectar código en la página dinámica. Un ejemplo clásico de este tipo es en los motores de búsqueda, si alguno busca una cadena que incluya caracteres especiales HTML, comúnmente la cadena de búsqueda será formateada para representar lo que se buscó, o al menos incluirá los términos de la búsqueda en la caja de texto para ser editados. Si las ocurrencias de los términos no son codificados como entidades HTML existe un agujero XSS. Esto no parecería un problema dado que los usuarios son los únicos que pueden inyectar código en sus propias páginas. Pero con un pequeño esfuerzo de ingeniería social, un atacante puede convencer a alguien de seguir una URL que se encargue de inyectar el código en esta página de resultados, dando al atacante acceso completo al contenido de la página. La mejor forma de proteger una aplicación de ataques XSS es asegurarse de que la aplicación valide todas las cabeceras, cookies, queries a la base de datos, campos de las formas (entre estos los campos ocultos). Es decir, todos los parámetros entrantes teniendo como referencia una especificación rigurosa de lo que debe ser permitido. 80 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web De ninguna manera el proceso de validación debe intentar identificar el contenido peligroso y removerlo, filtrarlo o sanearlo. Existen muchos tipos de contenido activo o peligros y muchas maneras de codificarlo para burlar los filtros para este tipo de contenido. Se recomienda ampliamente utilizar un esquema positivo de política de seguridad (listas blancas) que especifique de forma clara lo único que es permitido Las políticas de lista negra son complicadas de mantener actualizadas y siempre con posibilidades de quedar incompletas. Codificar la salidas que dependan de los datos provistos por el usuario es una manera eficaz de evitar vulnerabilidades XSS previniendo la transmisión de scripts insertados a usuarios en una forma ejecutable. Las aplicaciones pueden ganar protección de los ataques basados en J avaScript convirtiendo los caracteres especiales en su equivalente codificado en entidad HTML. 1.<&lt; or &#60; 2.>&gt; or &#62; 3.& &amp; or &#38; 4." &quot; or &#34; 5.' &apos; or &#39; 6.( &#40; 7.) &#41; 8.#&#35; 9.% &#37; 10.; &#59; 11.+&#43; 12. &#45 Es preferible utilizar un esquema de lista blanca como la función HTMLEntityEncode de J ava. Además es crucial deshabilitar el soporte de HTTP TRACE en los servidores web (Apache, IIS, etc.) al hacerlo evitaremos que el servidor devuelva los parámetros de la solicitud errónea recibida. La secuencia de comandos en sitios cruzados, más conocida como XSS 30 30 Disponible en internet desde <https://www.owasp.org/index.php/Top_10_2007- Secuencia_de_Comandos_en_Sitios_Cruzados_%28XSS%29> , es en realidad un subconjunto de inyección HTML El proyecto OWASP incluye dentro de su Top 10 esta vulnerabilidad con todos los matices y aspectos de 81 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web protección, entornos afectados, herramientas usadas, monitoreo, ejemplos y sitios online de prueba para realizar los ataques. LECCION 17: PERDIDA DE AUTENTICACION Y GESTION DE SESIONES Concepto: Permiten suplantar la información de un usuario determinado. Ejemplo la cuenta del Administrador para sabotear controles de autorización y registro. Otra característica es el acceso no autorizado a información que se encuentre almacenada en el servidor o los servicios que han sido comprometidos. Cuando se presentan: • Cuando se gestionan las contraseñas. • Cuando expiran las sesiones o el proceso de cierre de sesión. • Cuando hay recuperación de los valores del usuario de forma automática. • Cuando se trae la famosa “Pregunta secreta.” • Cuando se actualiza una cuenta. • Cuando el usuario pierde su contraseña y solicita “Recordar contraseña” EJEMPLO DE PÉRDIDA DE AUTENTICACION: Un usuario autenticado puede consultar una serie de artículos de una determinada categoría. Navegando por cada uno de los artículos accede a uno que le interesa y que quiere compartir con sus amigos, por lo que accede a la URL que tiene en su navegador. Luego cierra su navegador y postea en una red social este enlace para que todos puedan acceder a este curioso artículo. El servidor no cierra la sesión del usuario. Cualquiera de sus “amigos” que acceda a dicho enlace aparecerá registrado en la aplicación como el usuario autenticado En la figura 21 se ilustra este ejemplo de pérdida de autenticación 82 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 21: Pérdida de Autenticación Fuente: El Autor Formas de protección: • Cierre de sesión correctamente mediante los enlaces del sitio para ello (no cerrar ventanas) • Gestión de contraseñas • Tiempo de desconexión. • Eliminar la opción recordar contraseña en los navegadores • Pregunta secreta. • Actualización de cuentas. • Utilizar conexiones SSL. • Ingreso de identificadores no validos. 83 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 18: REFERENCIA DIRECTA INSEGURA A OBJETOS Una referencia directa insegura a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un fichero, directorio, o base de datos. Sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular estas referencias para acceder datos no autorizados. Por ejemplo, en las aplicaciones “Home Banking”, es común usar el número de cuenta como clave primaria. Por lo tanto, es tentador usar el número de cuenta directamente en la interfaz web. Incluso si los desarrolladores tomaron las medidas necesarias para prevenir ataques de SQL Injection, si no hay validaciones extra que verifiquen que el usuario es el dueño de la cuenta y que está autorizado para verla, un atacante puede forzar el parámetro número de cuenta y lograr ver o cambiar todas las cuentas. Los escenarios típicos donde se presentan: Una aplicación presenta una referencia directa insegura a objetos, por ejemplo, una lista con posibles documentos que pueden ser seleccionados para ser visualizarlos, donde cada entrada de la lista referencia directamente a un fichero del sistema de archivos. Un atacante, como usuario autorizado en el sistema, simplemente modifica el valor de un parámetro (uno de esos documentos) que se refiere directamente a un objeto del sistema a otro objeto para el que el usuario no se encuentra autorizado. Normalmente, las aplicaciones utilizan el nombre o clave actual de un objeto cuando se generan las páginas web. Las aplicaciones no siempre verifican que el usuario tiene autorización sobre el objetivo. Esto resulta en una vulnerabilidad de referencia directa insegura a objetos. Los auditores pueden manipular fácilmente los valores del parámetro para detectar estas vulnerabilidades y un análisis de código mostraría rápidamente si la autorización se verifica correctamente. Definición de objeto: Elementos internos de la aplicación, es decir, ficheros, directorios y registros de bases de datos que utiliza nuestra aplicación para almacenar información, y que son referenciados a través de parámetros en url’s o en formularios. Por esto último se dice que se realiza una referencia directa de ellos, porque según la información que contengan estos parámetros, se accederá a uno u otro dato. 84 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Ejemplo de algunas vulnerabilidades: • Enlace a una carga de con la información de un número de cuenta: Si se desea ingresar a la información de un número de cuenta de un usuario que tiene por identificación el número: 1234567890 URL: https://www.ejemplo/cuentas.php?cuenta=1234567890 Con esto se cargarían los movimientos de dicha cuenta propiedad del usuario. Si se introduce otro número de cuenta cercano por arriba o abajo del nuestro, por ejemplo 1234567891, en principio, si todo se hubiera hecho correctamente, debería mostrar un error al estar introduciendo una cuenta ajena, pero si somos vulnerable a la referencia directa de objetos de forma insegura, mostrará los datos de esta cuenta sin ser nuestra. • Descarga de un archivo que no es controlada o sin restricción: Si se tiene un enlace de descarga de un archivo pdf con el reporte bancario de un extracto o algo similar en la que el nombre del archivo de la descarga se referencia por el número de cédula del cliente así: URL: http://www.banco.com/descarga.php?dir=nomina&file=10234765.pdf Con tan solo modificar un número en la cédula del usuario, se podría estar descargando la información de otro usuario, La referencia directa insegura a objetos, es incluido en el proyecto OWASP dentro de su Top 10. 31 LECCION 19: ALMACENMIENTO CRIPTOGRAFICO INSEGURO: Este tipo de vulnerabilidad ocurre cuando: • No se identifican todos los datos sensitivos • No se identifican todos los lugares donde estos datos son almacenados: Base de datos, ficheros, carpetas, archivos de log, backups, etc. • No se protege esta información en todas sus ubicaciones 31 Disponible en internet desde <https://www.owasp.org/index.php/Top_10_2007- Referencia_Insegura_y_Directa_a_Objetos> 85 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Los impactos: • Atacantes acceden o modifican información privada o confidencial: Ej., tarjetas de crédito, registros médicos, datos financieros • Atacantes extraen secretos a ser usados en otros ataques • Mala Imagen para la Compañía, clientes insatisfechos, y pérdida de confianza • Gastos para corregir el incidente, tales como análisis forense, enviar cartas de disculpas, nueva impresión de tarjetas de crédito, etc. • El Negocio es demandado o multado Como evitarlo: Verificar la arquitectura • Identificar todos los datos sensitivos • Identificar todos los lugares donde estos datos son almacenados • Utilice encripcion para contrarrestar las amenazas, no solo para ‘encriptar’ datos Proteger la información con mecanismos apropiados • Encripción en ficheros, base de datos, etc. Utilizar los mecanismos correctamente • Usar únicamente algoritmos públicos reconocidos (como AES, RSA, y SHA- 256) • No utilizar algoritmos considerados débiles (como MD5 o SHA1) • Nunca transmitir claves privadas por canales inseguros • No almacenar información innecesaria. Ej, código CVV de tarjeta de crédito (req. PCI DSS) Verificar la implementación • Un algoritmo estándar es utilizado, y es el algoritmo apropiado para dicha situación • Todas las llaves, certificados, y contraseñas se encuentran debidamente almacenadas y protegidas • Los métodos para distribuir las llaves son seguros y efectivos • Mas difícil: Analizar el código de encripción por posibles fallas 86 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 22: Almacenamiento criptográfico inseguro Fuente: El Autor LECCION 20: RESTRICCIONES DE ACESO A URL: Comúnmente, la única protección de una URL, es que el enlace a esa página no se muestre a usuarios no autorizados. Sin embargo, un atacante motivado, habilidoso o simplemente con suerte, puede ser capaz de encontrar el acceso a estas páginas, invocar funciones, y visualizar información. La seguridad por oscuridad no es suficiente para proteger la funcionalidad e información en una aplicación. La revisión de control de acceso debe ser realizada antes de que una petición a una función sensible se conceda, lo cual asegura que el usuario está autorizado para acceder a esa función. Muchas aplicaciones web verifican los privilegios de acceso a URL antes de generar enlaces o botones protegidos. Sin embargo, las aplicaciones necesitan realizar controles similares cada vez que estas páginas son accedidas, o los atacantes podrán falsificar URL para acceder a estas páginas igualmente. 87 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Entornos afectados Todos los entornos de aplicaciones Web son vulnerables a las fallas de restricciones de acceso a URL. Características: • Explotación fácil: Explotación es fácil porque solo basta con cambiar la URL sin privilegios a una página con privilegios. • Prevalencia Poco común: La detección de esta falla porque para el atacante es difícil identificar que URLS tienen esta vulnerabilidad • Detección media: Suele pasar inadvertida esta vulnerabilidad por los escáneres. Los escáneres de vulnerabilidades y los motores de análisis estático tienen dificultades con la verificación de control de acceso a URLs, pero por razones diferentes. Los escáneres de vulnerabilidades tienen dificultades para adivinar las páginas ocultas y determinar qué páginas se deben permitir para cada usuario, mientras que los motores de análisis estático batallan para identificar los controles de acceso personalizado en el código y vincular la capa de presentación con la lógica de negocio. • Impacto moderado: El impacto de esta falla es moderado porque permite el acceso no autorizado a funciones administrativas de la aplicación. Vulnerabilidad: El método primario de ataque para esta vulnerabilidad es llamado "navegación forzada", que abarca adivinado de enlaces y técnicas de fuerza bruta para encontrar paginas desprotegidas. Las aplicaciones permiten con frecuencia que el código de control de acceso se desarrolle y se separe a través de código fuente, dando como resultado un modelo complejo que sea difícil de entender para los desarrolladores y para los especialistas de la seguridad también. Esta complejidad hace que sea probable que se produzcan errores de páginas perdidas, dejándolas expuestas Algunos ejemplos comunes de estos defectos incluyen: • URL "ocultas" o "especiales”, suministradas sólo a administradores o usuarios con privilegios, pero accesibles a todos los usuarios si ellos saben que existen, tales como /administrar/agregarusuario.php o /aprobarTransferencia.do. Esto es particularmente predominante con código de menú. 88 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web • Las aplicaciones a menudo permiten el acceso a archivos "ocultos", tales como XML estáticos o reportes generados por el sistema, confiando en la seguridad por oscuridad para ocultarlos Protección. Bloquear o eliminar páginas mediante un archivo robots.txt CAPITULO 5: CICLO DE VIDA DE DESARROLLO SEGURO DE SOFTWARE (SDLC) LECCION 21: NTRODUCCION A SDLC: Actualmente la mayoría de los procesos de desarrollo no incluyen seguridad, o bien la incluyen al final (etapa de testing). El costo de solucionar las vulnerabilidades es mayor cuanto más tarde se detectan las mismas (igual que los bugs). En la figura 23 se identifica al relación costo – tiempo con las fases de desarrollo de una aplicación web. Figura 23: Relación costo – tiempo en el desarrollo de aplicaciones web Fuente: El Autor 89 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web El modelado de amenazas es una técnica formal, estructurada y repetible que permite determinar y ponderar los riesgos y amenazas a los que estará expuesta una aplicación y que puede aplicarse al Ciclo de Vida del Desarrollo de Software (SDLC). AL rededor de este ciclo de vida de desarrollo seguro de software, surgen mitos que vencer como: • La seguridad de la aplicación es responsabilidad del programador. • Nadie sabe cómo funciona, por ende, no la van a atacar. • A nadie le interesaría atacar nuestra aplicación. • La aplicación es segura porque corre detrás de un firewall. • La aplicación es segura porque usa encripción. • Si no corre como Administrator / root, no funciona. • No hay tiempo para incluir seguridad Para eliminar estas premisas, la tendencia actual y que se debe seguir para aplicar el ciclo de desarrollo, enmarca aspectos como: Participación de Seguridad Informática desde el comienzo de todos los proyectos de desarrollo. Incorporar seguridad a lo largo de todas las etapas del ciclo de vida del desarrollo de software (SDLC). LECCION 22: FASES DE SDLC: El ciclo de desarrollo de los sistemas o ciclo de vida de los sistemas (SDLC: Systems Devetopment Life Cycle) es un enfoque por etapas de análisis y de diseño, que postula que el desarrollo de los sistemas mejora cuando existe un ciclo específico de actividades del analista y de los usuarios. 90 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 24: SDLC Fuente: <CLARK, Justin. SDLC > 22.1 SEGURIDAD EN LA FASE DE ANÁLISIS: Durante el análisis de requerimientos, se pueden identificar diversas características que derivarán en los requerimientos de seguridad del software. Por ejemplo: Arquitectura de la aplicación: ¿Cliente/servidor o Desktop? Plataforma donde correrá la aplicación: PC / Palm / Teléfono celular Tipos de datos que se almacenan o transfieren: Confidenciales / públicos Requerimiento de compliance con normativas y marcos regulatorios: SOX, PCI- DSS, “A” 4609 Tipos de registro que el sistema debe generar: Acceso a recursos, uso de privilegios, etc. Perfiles de usuario necesarios para la aplicación: Administrador, revisor, editor, usuario básico, etc. Tipos de acceso a los datos por parte de cada perfil: Lectura, escritura, modificación, agregado, borrado, etc. Acciones sobre el sistema que puede hacer cada perfil: Cambiar la configuración del sistema, arrancar o detener servicios Modos de autenticación: Passwords, Tokens, Biométricos. 91 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 22.2 SEGURIDAD EN LA ETAPA DE DISEÑO: Muchas de las vulnerabilidades encontradas en aplicaciones web tienen su causa en errores de diseño. Ejemplos de ello: Aplicación Home banking (WEB): Incluía el número de cuenta en el request de transferencias. No validaba que la cuenta origen perteneciera al usuario logueado. Vulnerabilidad: Transferencias desde cuentas ajenas Aplicación de Adm y Finanzas (Consola Unix): Tomaba el usuario de una variable de entorno. Permitía que el usuario “escapara” a un Shell. Vulnerabilidad: Se puede establecer un usuario arbitrario Buenas prácticas para el diseño de una aplicación segura incluyen aspectos como: • Reducción de Superficie de ataque • Criterio del menor privilegio • Fallar de manera segura • Criterio de defensa en profundidad • Diseño seguro de mensajes de error • Diseño seguro de autenticación • Separación de privilegios • Interacción “amigable” con Firewalls e IDS's. • Administración segura información Sensible • Diseño de Auditoría y Logging • Análisis de riesgo Durante esta etapa de diseño se suelen aplicar técnicas para analizar el riesgo, como: Análisis de riesgo – Threat Modeling: Técnica formal, estructurada y repetible que permite determinar y ponderar los riesgos y amenazas a los que estará expuesta nuestra aplicación. Consta de las siguientes etapas: 1) Conformar un grupo de análisis de riesgos 2) Descomponer la aplicación e identificar componentes clave. 3) Determinar las amenazas a cada componente de la aplicación. 4) Asignar un valor a cada amenaza. 92 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 5) Decidir cómo responder a las amenazas. 6) Identificar las técnicas y tecnologías necesarias para mitigar los riesgos identificados. Método STRIDE: Ayuda a identificar amenazas en los componentes de un sistema. Su nombre es un acrónimo de: Spoofing Identity: Suplantar la identidad de otro usuario o servicio. Tampering with Data: Modificar maliciosamente datos almacenados. Repudiation: Imposibilidad de identificar el autor de una acción. Information Disclosure: Divulgar información a usuarios no autorizados. Denial of Service: Provocar que un servicio deje de funcionar. Elevation of privilege: Conseguir privilegios mayores a los asignados Método DREAD: Ayuda a ponderar las amenazas identificadas. Es un acrónimo de los siguientes 5 ítems: Damage Potencial: ¿Cuán importante es el daño de esta amenaza? Reproducibility: ¿Cuán reproducible es la vulnerabilidad? Exploitability: ¿Cuán fácil es de explotar? Affected Users: ¿Cuáles y cuántos usuarios se verían afectados? Discoverability: ¿Cuán fácil de descubrir es la vulnerabilidad? 22. 3 SEGURIDAD EN LA CODIFICACION: La falta de controles adecuados en la codificación, muchas veces deriva en vulnerabilidades que pueden comprometer a la aplicación o a los datos de la misma Los tipos de vulnerabilidades más habituales y que directamente son producto de una codificación de mediano y bajo perfil de seguridad son: 93 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web • Stack buffer overflows • Heap buffer overflows • SQL Injections • Cross Site Scripting (XSS) • Directory Traversal • Stack buffer overflows • Heap buffer overflows • SQL Injections • Cross Site Scripting (XSS) • Directory Traversal Las prácticas recomendadas para la codificación segura cuando se desarrollan aplicaciones web son: • Validar siempre los datos de entrada antes de procesarlos • Nunca confiar en que los datos recibidos sean correctos. • Realizar validación de datos en todas las capas • Usar siempre criterio de “White List” en las validaciones • Controlar tamaño y tipo de datos • “Sanitizar” los valores de entrada y salida • Eliminar o “escapear” caracteres especiales • Transformar los datos de entrada a un “encoding” establecido • Reemplazar sentencias SQL dinámicas por Stored Procedures • Evitar generar código con valores ingresados por el usuario • No mezclar datos con código • Capturar errores de capas inferiores y no mostrarlos al usuario 22.4 SEGURIDAD EN LA ETAPA DE TESTING (PRUEBAS): Se aplican varias técnicas en esta etapa: Testing de seguridad funcional: Testing Funcional (clásico) aplicado a las funcionalidades de seguridad de una aplicación. Ejemplos: • Requisitos. de autenticación • Requisitos. de complejidad de contraseñas Bloqueo automático de cuentas • Funcionalidad de captchas • Restricciones de acceso según diseño • Mecanismos de registro y logging • Mensajes de error especificados 94 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Testing de seguridad basado en Riesgo: Técnica que se desprende del Threat Modelling. Se identifican todas las interfaces de la aplicación. Se generan casos de test sobre cada interfaz basado en STRIDE Testing con un cliente / server falso: Consiste en diseñar un cliente o server “Ad Hoc” que permita: • Enviar peticiones /respuestas incorrectas o inválidas. • Enviar peticiones/ respuestas fuera de orden. • Insertar delays arbitrarios. • Comportarse de manera diferente al cliente o servidor real. Test de stress: Consiste en llevar la carga o funcionalidad de la aplicación al límite • Generar una carga alta de peticiones/transacciones a la aplicación. • Mantener esta carga durante tiempos prolongados. • Simular tráfico en ráfagas. Test de mutación de datos: Se testea la aplicación ingresando en sus interfaces datos “mutados”. Entre estos datos se pueden citar: Diferente signo, diferente tipo, diferente longitud, fuera de rango, caracteres especiales, código (ej: javascripts), valores nulos, valores aleatorios 22.5 SEGURIDAD EN LA ETATA DE IMPLEMENTACION: Se suelen aplicar técnicas como: Hardening de software de base que comprende aplicar aspectos como: • Servicios innecesarios • Usuarios y contraseñas default • Configuración de intérpretes • Proceso de implementación • Separación de ambientes • Administración de implementación y mantenimiento • Releases y Patches • Firma de código 95 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 23: SDLC - IT: (SDLC - IT: Systems Devetopment Life Cycle for Information Tecnologies) En general, los analistas no están de acuerdo respecto al número exacto de etapas que conforman el ciclo de desarrollo de los sistemas para aplicaciones, y en general para las tecnologías de la información; sin embargo, se reconoce la importancia de su enfoque sistemático. Este ciclo específico de vida consta de siete capas o etapas que aunque se presentan de manera discreta, nunca se llevan a cabo como un elemento Independiente. En lugar de ello se realizan al mismo tiempo diversas actividades, y éstas llegan a repetirse. Por ello es de mayor utilidad suponer que e! ciclo de desarrollo de los sistemas transcurre en etapas (con actividades en acción que luego cesan poco a poco) y no como elementos separados 1) Identificación de problemas, oportunidades y objetivos. En esta primera etapa del ciclo de desarrollo de los sistemas, el analista se involucra en la identificación de los problemas, de las oportunidades y de los objetivos. Esta fase es crucial para el éxito del resto del proyecto, pues nadie estará dispuesto a desperdiciar su tiempo dedicándolo al problema equivocado. La primera etapa requiere que el analista observe de forma objetiva lo que ocurre en una empresa. Luego, en conjunto con los otros miembros de la organización hará notar los problemas. Muchas veces esto ya fue realizado previamente: y por ello es que se llega a invitar al analista. Las oportunidades son acuellas situaciones que el analista considera que pueden perfeccionarse mediante el uso de los sistemas de información computarizados. Al aprovechar las oportunidades, la empresa puede lograr una ventaja competitiva o llegar a establecer un estándar industrial. La identificación de objetivos también es un componente importante de la primera fase. En un comienzo, el analista deberá descubrir lo que la empresa intenta realizar, y luego estará en posibilidad de determinar si el uso de los sistemas de información apoyaría a la empresa para alcanzar sus metas, el encaminarla a problemas u oportunidades específicas. 2) Determinación de los requerimientos de información. La siguiente etapa que aborda el analista, es la determinación de los requerimientos de información a partir de los usuarios particularmente 96 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web involucrados. Para identificar los requerimientos de información dentro de ¡a empresa, pueden utilizarse diversos instrumentos, los cuales incluyen: el muestreo, el estudio de los datos y formas usadas por la organización, la entrevista, los cuestionarios: la observación de la conducta de quien toma las decisiones, asi como de su ambiente: y también el desarrollo de prototipos. En esta etapa el analista hace todo lo posible por identificar qué información requiere el usuario para desempeñar sus tareas. Puede ver, cómo varios de los métodos para establecer las necesidades de información, lo obligan a relacionarse directamente con los usuarios. Esta etapa sirve para elaborar la imagen que el analista tiene de la organización y de sus objetivos. En ocasiones, se llegan a concluir sólo las primeras dos etapas del ciclo de desarrollo de los sistemas. El analista es e! especialista que emprende esta clase de estudios. 3) Análisis de las necesidades del sistema. La siguiente etapa que ejecuta el analista de sistemas consiste en analizar las necesidades propias del sistema. Una vez más, existen herramientas y técnicas especiales que facilitan al analista la realización de las determinaciones requeridas. Estas incluyen el uso de los diagramas de flujo de datos (DFD)que cuentan con una técnica estructurada para representar en forma gráfica la entrada de datos de la empresa, los procesos y la salida de la información. A partir del diagrama de flujo de datos se desarrolla un diccionario de datos que contiene todos los elementos que utiliza el sistema, así como sus especificaciones, si son alfanuméricos, descripción, clave primaria, entre otros. Durante esta fase. el analista de sistemas también analiza las decisiones estructuradas por realizar, que son decisiones donde las condiciones, condiciones alternativas, acciones y reglas de acción podrán determinarse. Existen tres métodos para el análisis de las decisiones estructuradas: el lenguaje estructurado (en nuestro caso el español), las tablas de decisión y los árboles de decisión. No todas las decisiones en las empresas se encuentran estructuradas; no obstante, es importante que las comprenda e! analista de sistemas. Las decisiones semiestructuradas (decisiones que se toman bajo nesgo) con frecuencia se apoyan en los Sistemas de Toma de Decisiones. Cuando analiza las decisiones semiestructuradas. el analista las examina de acuerdo con el grado de complejidad del problema y con el número de criterios considerados al llevar a cabo las decisiones. 97 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web El análisis de decisiones de criterio múltiple (aquellas decisiones donde numerosos factores tienen que equilibrarse) también es parte de esta etapa. Se disponen de muchas técnicas para e' análisis de decisiones de criterio múltiple; incluyendo entre otras, e! proceso de intercambio y la aplicación de métodos de ponderado. A esta altura del ciclo de desarrollo del sistema, el analista prepara una propuesta del sistema que resume todo lo que ha encontrado, presenta un análisis costo / beneficio de las alternativas y plantea las recomendaciones (si es que existen) de lo que deberá realizarse. Si la dirección acepta alguna de las recomendaciones, el analista procederá de acuerdo con ella. 4) Diseño del sistema recomendado. En esta etapa del ciclo de desarrollo de los sistemas, el analista de sistemas usa la información que recolectó con anterioridad y elabora el diseño lógico del sistema de información. El analista diseña procedimientos precisos de captura de datos, con el fin de que los datos que se introducen al sistema sean los correctos. Ei analista también diseña accesos efectivos al sistema de información, mediante el uso de las técnicas de diseño de formularios y de pantallas. Una parte del diseño lógico del sistema de información es el diseño de la interfaz con el usuario. La interfaz conecta al usuario con el sistema, y evidentemente, es de suma importancia. Serían ejemplos de interfaces para el usuario: el uso del teclado para introducir preguntas o respuestas, el uso de menús en la pantalla, con las opciones que tiene el usuario, el uso de dispositivos como el ratón (mouse) y muchos otros. La etapa del diseño también incluye e! diseño de los archivos o la base de datos que almacenará aquellos datos requeridos por quien toma las decisiones en la organización. Una base de datos bien organizada es fundamental para cualquier sistema de información. En esta etapa, el analista diseña la salida (en pantalla o impresa) hacia el usuario, de acuerdo con sus necesidades de información. 5) Desarrollo y documentación del software En esta etapa del ciclo de desarrollo de los sistemas, el analista trabaja con los programadores para desarrollar todo el software original que sea necesario. Dentro de las técnicas estructuradas para el diseño y documentación de! software se tienen: el método HIPO, los diagramas de flujo. ios diagramas Nassi- 98 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Schneiderman, ios diagramas Warnier-Orr y el pseudocódigo. Aquí es donde, el analista de sistemas transmite al programador los requerimientos de programación. Durante esta fase, el analista también colabora con los usuarios para desarrollar la documentación indispensable del software, incluyendo los manuales de procedimientos. La documentación le dirá al usuario como operar el software, y así también, qué hacer en caso de presentarse algún problema. 6) Pruebas v mantenimiento del sistema. El sistema de información debe probarse antes de utilizarlo. E! costo es menor si se detectan los problemas antes cié la entrega del sistema. El programador realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboración con el analista de sistemas. En un principio, se hace una serie de pruebas, con datos tipo, para identificar las posibles fallas del sistema: más adelante, se utilizarán los datos reales. El mantenimiento del sistema y de su documentación empiezan justamente en esta etapa: y después, esta función se realizará de forma rutinaria a lo largo de toda la vida del sistema. Las actividades de mantenimiento integran una buena parte de la rutina del programador, que para las empresas llegan a implicar importantes sumas de dinero. Sin embargo, el costo del mantenimiento disminuye de manera importante cuando el analista aplica procedimientos sistemáticos en el desarrollo de los sistemas. 7) Implantación y evaluación de sistema. En esta última etapa del desarrollo del sistema, el analista ayuda a implantar el sistema de información. Esto incluye el adiestramiento que el usuario requerirá. Si bien, parte de esta capacitación la dan las casas comerciales, la supervisión del adiestramiento es una responsabilidad del analista de sistemas. Más aún, el analista necesita planear la suave transición que trae consigo un cambio de sistemas. 99 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Aunque la evaluación del sistema se plantea como parte integrante de la última etapa del ciclo de desarrollo de los sistemas; realmente, la evaluación toma parte en cada una de las etapas. Uno de los criterios fundamentales que debe satisfacerse, es que el futuro usuario utilice el sistema desarrollado. LECCION 24: APLICACIÓN DE SDLC: El ciclo de desarrollo de aplicaciones sigue siendo uno de los puntos de más complejidad en el entorno TI, una preocupación constante por parte de los desarrolladores que requiere de un desgaste muy alto en recursos, dinero y estrés. La solución pasa por estandarizar el proceso de desarrollo: • Definir los criterios de calidad en relación a las necesidades. Como siempre, hay que intentar ser pragmático, definir algo medible y del cual podremos obtener un feedback en tiempo real. • Publicar las métricas de calidad de desarrollo. La transparencia es clave para ganar la confianza del negocio y demostrar el valor aportado. • Revisar los objetivos de los diferentes equipos y proveedores para incluir criterios claros y medibles de calidad. • Pasar más tiempo en definir correctamente los requerimientos. Todos tenemos en mente proyectos que han arrancado sobre una definición de requerimientos insuficiente. • Definir y estandarizar planes de prueba más inteligentes para probar menos y mejor. • Utilizar una plataforma integrada que consolide la información de demanda, costes, recursos, calidad y así simplificar y flexibilizar el proceso. PRUEBAS Y CALIDAD: La planificación de prototipos, pruebas y tests para el aseguramiento de la calidad es también un tema muy tratado en la ingeniería del Software y en el proceso cíclico de diseño de aplicaciones seguras. Para que un proyecto software tenga éxito, es necesario que el resultado cuente con la calidad esperada por el cliente o los usuarios. Así pues, la calidad del proyecto deberá poderse definir en términos de prestaciones, respuestas esperadas a determinadas acciones, o accesibilidad del producto en diferentes 100 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web condiciones para poder probarla posteriormente mediante unos tests de calidad específicos. Deberá ser posible realizar un plan de pruebas o de aseguramiento de la calidad que clasifique las actividades relacionadas con la calidad del producto según su importancia, y que defina con qué frecuencia y qué resultados se deberían obtener de cada una para pasar a la siguiente o para cumplir los requisitos para esa release en particular. El proceso de aseguramiento de la calidad no trata únicamente de que el producto pase todos los tests establecidos, sino que implicará en muchos casos aspectos como: • El uso de hojas de estilo aprobadas por los usuarios. • La confección y repaso de checklists sobre funcionalidades. • La revisión periódica del producto con los usuarios • Las herramientas que pondremos a disposición de los usuarios para comunicar los errores o sugerencias. • El uso de herramientas de análisis para medir la respuesta del proyecto a determinadas situaciones, o para simular un uso normal del mismo Los modelos tradicionales de ciclo de vida del software incluían la fase de pruebas como un proceso que había que llevar a cabo una vez finalizado el desarrollo. Esto se ha probado que resulta altamente contraproducente, no sólo por el coste de arreglar fallos o deficiencias una vez terminado el desarrollo, sino por la naturaleza evolutiva de muchos proyectos (sobre todo en entornos de software libre), en los que la fase de desarrollo no termina nunca estrictamente hablando. Así pues, se tiende a incorporar las pruebas (o los mecanismos para llevarlas a cabo de modo automatizado) en el desarrollo desde el primer momento. Tecnologías como las pruebas unitarias o modelos como el pair-programming o el peer-testing nos ayudarán a mantener una disciplina en el desarrollo y a aumentar la calidad del resultado del proyecto. 32 32 AYCART, David. Ingeniería del software en entornos de SL. P 24-27. UOC SEGURIDAD EN LA APLICACIÓN DE SDLC: Los principios básicos de la seguridad de un sistema son los siguientes: Confidencialidad: los recursos (o funcionalidades sobre ellos) son accesibles sólo para los usuarios (o procesos) autorizados. 101 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Integridad: los recursos pueden ser modificables sólo por los usuarios autorizados. •Disponibilidad: los recursos accesibles están disponibles. Muy frecuentemente, la seguridad de un proyecto irá más allá del mismo, afectando al sistema en el que éste se va a implantar, y por lo tanto deberemos asegurar que su implantación deja al sistema final en un estado seguro. Es por esta razón por lo que, en la fase de diseño del proyecto, se debe tener en cuenta la seguridad del mismo, primero de forma general mediante un análisis de riesgos y de actividades destinadas a mitigarlos, y más adelante mediante la ampliación de los casos de uso según los principios básicos de la seguridad comentados anteriormente El análisis de riesgos consistirá, de forma muy resumida, en las siguientes actividades: Recopilación de los recursos que deben ser protegidos. La información, todo un sistema, un sólo dispositivo, etc. Clasificación de los actores del proyecto. Cuáles son sus casos de uso y qué roles representan. Recopilación de requisitos legales y de negocio. Certificaciones que hay que cumplir, restricciones de encriptación por exportación a determinados países o bien reglas de negocio más específicas como la aceptación o no de la repudiación por parte de los usuarios. Con la información recopilada, deberíamos ser capaces de construir una tabla en la que, para cada riesgo, estimáramos el coste que tiene por incidente, y a partir de una estimación de incidentes por año, nos permitiera decidir sobre la estrategia que hay que implantar (aceptar el riesgo tal como es y definir un plan de contingencia en caso de producirse, o bien mitigarlo mediante desarrollos adicionales, otras herramientas o cambios en el diseño que lo permitan). LECCION 25: OTRAS VULNERABILIDADES QUE AFECTAN LOS SDLC La seguridad en aplicaciones web no solo reside en las capas superiores del modelo OSI, como hemos visto en las lecciones anteriores. Tampoco en el único entorno de aplicación que se despliegue, ejecute o administre en (navegadores, 102 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web servidores, clientes). Iniciamos acá una temática de seguridad que afecta directamente a las aplicaciones web y que independiente de la forma como se le haya aplicado los ciclos de desarrollo seguro (SDLC), van a estar afectadas y que es de relevancia tratarlas. Una de ellas son las denegaciones de servicio y que a continuación se plasma más como la solución a detectarlas y mitigarlas que a definirlas y conceptualizarlas. Son muchas las estrategias y herramientas que enmarcan estudios completos con miras a detectar, prevenir y contrarrestar ataques de Denegación de Servicio. Los métodos más comunes hacen uso del filtrado de paquetes, como una solución viable y eficaz a este problema. Hay otra estrategia que es la modificación de la pila TCP/IP en los sistemas operativos. Mientras que los ataques SYN no puede ser totalmente prevenibles, el ajuste de la pila TCP / IP ayudará a reducir el impacto de ataques SYN al tiempo que permite el tráfico de clientes legítimos con sus respectivos paquetes. Actualmente los sistemas operativos integran mecanismos de protección como las galletas o SYN SynAttackProtect como barrera para contrarrestar estas amenazas. Las investigaciones que se encuentran frente a esta situación, son de diversa índole y tratan estas estrategias de manera particular. Estudios interesantes han llevado a tratar las características del protocolo TCP y modificarlas con el fin de cambiar el comportamiento de la pila TCP / IP. Pero esto puede tener consecuencias graves cuando se trata de comunicarse con otros sistemas de diferente topología, MTU, filtrado, etc. Finalmente, cada resultado de una investigación, encadena otro que propone un complemento o mejora para resolver el problema, y cada autor le da camino a su investigación de acuerdo a la necesidad urgente o escenario propio de cada situación. El escenario de los ataques de denegación de servicio (DoS) a aplicaciones web, nos ubica en la capa de transporte del modelo OSI. 25.1 VULNERABILIDADES DE LA CAPA DE TRANSPORTE: 33 La capa de transporte transmite información TCP o UDP sobre datagramas IP. En esta capa podamos encontrar problemas de autenticación, de integridad y de 33 JOANCOMARTI, Jordi Herrera. Aspectos Avanzados de seguridad en redes. Seg edición. Barcelona España 2005. 62p 103 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web confidencialidad. Algunos de los ataques más conocidos en esta capa son las denegaciones de servicio debidas a protocolos de transporte. En cuanto a los mecanismos de seguridad incorporados en el diseño del protocolo de TCP (como las negociaciones involucradas en el establecimiento de una sesión TCP), existe una serie de ataques que aprovechan ciertas deficiencias en su diseño. Una de las vulnerabilidades más graves contra estos mecanismos de control puede comportar la posibilidad de interceptación de sesiones TCP establecidas, con el objetivo de secuestrarlas y dirigirlas a otros equipos con fines deshonestos. Estos ataques de secuestro se aprovechan de la poca exigencia en el protocolo de intercambio de TCP respecto a la autenticación de los equipos involucrados en una sesión. Así, si un usuario hostil puede observar los intercambios de información utilizados durante el inicio de la sesión y es capaz de interceptar con éxito una conexión en marcha con todos los parámetros de autenticación configurados adecuadamente, podrá secuestrar la sesión.” 25.2 ORIGEN DE LAS VULNERABILIDADES: Las vulnerabilidades pretenden describir las debilidades y los métodos más comunes que se utilizan para perpetrar ataques a la seguridad de la familia de protocolos TCP/IP (confidencialidad, integridad y disponibilidad de la información). Amenazas Consecuenci as INTEGRIDAD Datos modificados Información perdida Caballo de Troya Maquina penetrada Memoria cambiada Vulnerabilidad a otras amenazas Mensajes modificados Información degradada, dañada CONFIDENCIALIDAD Mensajes escuchados en la red Perdida de privacidad Datos robados de servidores Revela contraseñas etc. Análisis de trafico Identifica patrones de acceso Detecta configuración de la red Facilita otros ataques DENIAL OF SERVICE 104 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Procesos matados Molestias Inundación con paquetes Interferencia con trabajo Llenado de discos Denegación a servicios Aislamiento de maquinas (DNS) Aislamiento de la red AUTENTIFICACION Identidades falsas Acciones atribuidas al usuario Datos falsos Daño al nombre institucional Tabla3. Tipos de Amenazas Fuente: <El Autor> La tabla (3) muestra en resumen el tipo de amenazas y las consecuencias que le producen al sistema. Las amenazas están clasificadas en los cuatro aspectos básicos y esenciales que afectan la seguridad: La integridad, la Confidencialidad, las denegaciones de servicio (de las que se encarga este trabajo) y las de Autenticación 25.3 HERRAMIENTAS DE MONITOREO: Son muchas las estrategias y herramientas de monitoreo que existen para ser aplicadas a entornos de comunicaciones y redes tipo Ethernet. La mayoría de ellas funcionan sobre plataformas de código abierto lo que les ofrece grandes posibilidades de expansión y de parametrizacion de acuerdo a las necesidades del Administrador de red. Nagios: 34 Nessus: La herramienta Nessus permite escanear vulnerabilidades cuando se trata de transferencia de datos y ejecución de servicios en diferentes sistemas operativos. Genera informes que permiten ejecutar las acciones correctivas “La monitorización cualitativa de los servicios se realiza mediante el sistema Nagios siendo este un sistema potente que permite seguir el estado de múltiples servicios de red en múltiples servidores y avisar a personas o grupos de personas responsables de los mismos. En Nagios se permiten escaladas de avisos en función del tiempo de parada y otros parámetros, múltiples métodos de aviso (correo electrónico, SMS...) y presentación gráfica muy práctica del estado actual y del histórico de estados.” 34 Herramientas de Gestión Nagios, Nessus [web en línea]. Disponible desde Internet en: <http://www.csi.map.es/csi/tecnimap/tecnimap_2006/01T_PDF/monitorizacion.pdf> 105 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web adecuadas (parcheo, reconfiguración de servicios, adición de reglas de cortafuegos). Su arquitectura cliente servidor consiste en nessusd, el daemon Nessus, que realiza el escaneo en el sistema objetivo, y nessus, el cliente (basado en consola o gráfico) que muestra el avance y reporte de los escaneos. Desde consola nessus puede ser programado para hacer escaneos programados con cron (administrador de procesos en segundo plano). 25.4 SISTEMA DE DETECCION DE INTRUSOS: “Un IDS o Sistema de Detección de Intrusiones es una herramienta de seguridad que intenta detectar o monitorizar los eventos ocurridos en un determinado sistema informático o red informática en busca de intentos de comprometer la seguridad de dicho sistema. Aportan a la seguridad de una red la capacidad de prevención y de alerta anticipada ante cualquier actividad sospechosa. No están diseñados para detener un ataque, aunque sí pueden generar ciertos tipos de respuesta ante éstos. Vigilan el tráfico de nuestra red, examinan los paquetes analizándolos en busca de datos sospechosos y detectan las primeras fases de cualquier ataque como pueden ser el análisis de la red, barrido de puertos, etc.” 35 Bien ubicados, pueden analizar grandes redes y su impacto en el tráfico suele ser pequeño. Actúan mediante la utilización de un dispositivo de red configurado en modo promiscuo (analizan, “ven” todos los paquetes que circulan por un segmento 25.5 TIPOS DE IDS: HIDS (Host IDS): Protege contra un único Servidor, PC o host. Monitorizan gran cantidad de eventos, analizando actividades con una gran precisión, determinando de esta manera qué procesos y usuarios se involucran en una determinada acción. Recaban información del sistema como ficheros, logs, recursos, etc, para su posterior análisis en busca de posibles incidencias. Todo ello en modo local, dentro del propio sistema. Fueron los primeros IDS en desarrollar por la industria de la seguridad informática. NIDS (Net IDS): Protege un sistema basado en red. Actúan sobre una red capturando y analizando paquetes de red, es decir, son sniffers del tráfico de red. Luego analizan los paquetes capturados, buscando patrones que supongan algún tipo de ataque. 35 Sistema de detección de Intrusos y Snort. Disponible desde Internet en: <http://seguridadyredes.nireblog.com/post/2007/12/28/sistemas-de-deteccion-de-intrusos-y-snort-i> 106 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web de red aunque estos nos vayan dirigidos a un determinado equipo). Analizan el tráfico de red, normalmente, en tiempo real. No sólo trabajan a nivel TCP/IP, también lo pueden hacer a nivel de aplicación. Otros tipos son los híbridos. Por el tipo de respuesta se pueden clasificar en: Pasivos: Son aquellos IDS que notifican a la autoridad competente o administrador de la red mediante el sistema que sea, alerta, etc. Pero no actúa sobre el ataque o atacante. Activos: Generan algún tipo de respuesta sobre el sistema atacante o fuente de ataque como cerrar la conexión o enviar algún tipo de respuesta predefinida en nuestra configuración. Snort: Snort es un IDS o Sistema de detección de intrusiones basado en red (NIDS). Implementa un motor de detección de ataques y barrido de puertos que permite registrar, alertar y responder ante cualquier anomalía previamente definida como patrones que corresponden a ataques, barridos, intentos aprovechar alguna vulnerabilidad, análisis de protocolos, etc conocidos. Todo esto en tiempo real. “Snort está disponible bajo licencia GPL, gratuito y funciona bajo plataformas Windows y UNIX/Linux. Es uno de los más usados y dispone de una gran cantidad de filtros o patrones ya predefinidos, así como actualizaciones constantes ante casos de ataques, barridos o vulnerabilidades que vayan siendo detectadas a través de los distintos boletines de seguridad.” 36 La característica más apreciada de Snort, además de su funcionalidad, es su subsistema flexible de firmas de ataques. Snort tiene una base de datos de ataques que se está actualizando constantemente y a la cual se puede añadir o actualizar a través de la Internet. Los usuarios pueden crear 'firmas' basadas en las características de los nuevos ataques de red y enviarlas a la lista de correo de firmas de Snort, para que así todos los usuarios de Snort se puedan beneficiar y crear una comunidad con las características de los proyectos de entorno de desarrollo libre. Este IDS implementa un lenguaje de creación de reglas flexibles, potente y sencilla. Durante su instalación ya provee de cientos de filtros o reglas para backdoor, ddos, finger, ftp, ataques web, CGI, escaneos Nmap. Puede funcionar como sniffer (se puede ver en consola y en tiempo real qué ocurre en la red, todo el tráfico), registro de paquetes (permite guardar en un archivo los logs para su posterior análisis, un análisis offline) o como un IDS normal (en este caso NIDS). 36 Disponible en Internet. < http://www.snort.org/> Con acceso Junio 28 de 2012 107 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 25.6 HERRAMIENTAS DE GESTION: JFFNMS: 37 También utiliza programas como nmap, fping y otros para probar conectividad, puertos abiertos y otros parámetros de red. En tal sentido, J FFNMS es un sistema integrador para el monitoreo. Además de estos programas fundamentales que realizan la consulta y captura de los datos, J FFNMS requiere de una base de datos robusta para almacenarlos (PostgreSQL ó MySQL), un Servidor Web para presentarlos (Apache), el intérprete PHP bajo el cual se ejecutará J FFNMS, utilidades y programas para generar gráficos (RRDtool, Graphviz, etc.) .J FFNMS se distribuye bajo la licencia GPL. Es un software desarrollado por J avier Szyszlican, en el año 2002, para monitoreo de dispositivos, que integra varias utilidades que interrogan y capturan los datos de los dispositivos. Los programas utilizados por J FFNMS para el monitoreo, son los siguientes: “ POLLER: Actúa como manager del protocolo SNMP interrogando a los agentes instalados en los dispositivos a monitorear. SNMPTRAPD: Recibe los “traps” desde los dispositivos monitoreados. Los “traps” son eventos o alarmas que los dispositivos envían sin necesidad de ser consultados. SYSLOG: Servicio que recoge la información de auditoría (mensajes logs) de los dispositivos. No forma parte del protocolo SNMP. Se basa en los registros de auditoría de los sistemas UNIX. 38 Fping: Nmap: (Network Mapper). Esta herramienta implementa la gran mayoría de técnicas conocidas para exploración de puertos y permite descubrir información de los servicios y sistemas encontrados. Nmap también implementa un gran número de técnicas de reconocimiento de huellas identificativas. Generalmente, Nmap es utilizado internamente por otras aplicaciones como, por ejemplo, escáner de vulnerabilidades, herramientas de detección de sistemas activos, servicios web que ofrecen exploración de puertos, etc. 39 37 Disponible en Internet. <http://wiki.canaima.softwarelibre.gob.ve/wiki/index.php/Servidor_Jffnms> 38 Disponible en Internet <http://www.es.gnu.org/modules/content/index.php?id=8> 39 Disponible en Internet. <http://fping.sourceforge.net/> La utilidad ping comprueba el estado de la conexión con uno o varios equipos remotos por medio de los paquetes de solicitud de eco y de respuesta de eco (ambos definidos en el protocolo de red ICMP) para determinar si un sistema 108 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web IP específico es accesible en una red. Es útil para diagnosticar los errores en redes o enrutadores IP.” Fping es una utilidad que realiza un ping original pero con múltiples funciones extras, proporcionándote así mucha más información y detalles. RRDtool: RRDtool es el estándar de la industria OpenSource para el registro de datos de alto rendimiento con un sistema de representación gráfica de datos de series en una línea de tiempo. Es útil para escribir shell scripts de seguimiento personalizado o crear aplicaciones usando lenguajes como Perl, Python, Ruby, TCL o enlaces de PHP. 40 40 Disponible en internet. <http://oss.oetiker.ch/rrdtool/> “RRDtool es el acrónimo de Round Robin Database tool. Trabaja con una base de datos que maneja planificación según Round-Robin. Esta técnica trabaja con una cantidad de datos fija, definida en el momento de crear la base de datos, y un puntero al elemento actual. La base de datos como si fuese un círculo, sobrescribiendo los datos almacenados con anterioridad una vez alcanzada la capacidad máxima de la misma. Esta capacidad máxima dependerá de la cantidad de información que se quiera conservar como historial.” Su finalidad principal es el tratamiento de datos temporales y datos seriales como temperaturas, transferencias en redes, cargas del procesador, etc. Algunos proyectos que utilizan RRDtool son: Cacti, Ganglia, J FFNMS, Lighttpd, MRTG, Munin, Smokeping, Zenoss. 109 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web CAPITULO 6: ATAQUES DE DENEGACION DE SERVICIO (DDoS) A APLICACIONES WEB LECCION 26: DENEGACION DE SERVICIO (DoS) / (DDoS) Es importante diferenciar dos tipos de ataques de denegación del servicio si se tiene en cuenta que uno en los que se va a centrar este proyecto, puede actuar teniendo un único origen o varios dependiendo la técnica usada para ejecutarlo: • Ataques de denegación de servicio simples (Deny Of Service). Este tipo de ataques se caracterizan por tener un único origen desde el cual se realiza la denegación del servicio. • Ataques de denegación de servicio distribuido (Distributed DOS o DDOS). En este tipo de ataques se utilizan varias fuentes coordinadas que pueden realizar un ataque progresivo, rotatorio o total. Se define la denegación de servicio (Deny Of Service, DOS) como la imposibilidad de acceso a un recurso o servicio por parte de un usuario legítimo. De esta forma se puede definir un ataque de denegación de servicio (DOS Attack) como: 41 Siendo más concreto y enfocando los ataques a redes IP como el que se pretende llevar a cabo en el desarrollo del proyecto, se encuentra una definición con argumentos explicativos concretos que definen los ataques de denegación del servicio como “La apropiación exclusiva de un recurso o servicio con la intención de evitar cualquier acceso de terceros. También se incluyen en esta definición los ataques destinados a colapsar un recurso o sistema con la intención de destruir el servicio o recurso”. 42 41 Search Software Quality. [Web en línea]. Disponible desde Internet en: <http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci213591,00.html> 42 CERT® Advisory CA-1999-17 Denial-of-Service Tools. [Web en línea]. Disponible desde Internet en: <http://www.cert.org/advisories/CA-1999-17.html> “la consecución total o parcial (temporal o totalmente) del cese en la prestación de servicio de un ordenador conectado a Internet.” 110 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 25. Escenario de un Ataque de Denegación de servicio (DoS) Fuente: <El Autor> Adaptado < MIRKOVIC.J. D-WARD Source-End Defense Against Distributed Denial-of-Service Attacks.2003. p 38.> En la Figura 25, se explica una denegación del servicio típica. Que se produce cuando la víctima (V) recibe un malicioso flujo de paquetes obligándola a evitar recibir algún recurso o servicio de los clientes legítimos C1, y C2. Una característica de estos ataques es que los atacantes rara vez utilizan sus propias máquinas para llevar a cabo los ataques por lo que la máquina A se convierte en un agente o participante involuntario 26.1 DENEGACIÓN DE SERVICIO DISTRIBUIDO: DDOS Se han definido los ataques de denegación de servicio distribuido (DDOS) como 43 43 [Web en línea].Disponible desde Internet en: <http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci557336,00.html> “un ataque de denegación de servicio (DOS) dónde existen múltiples focos distribuidos y sincronizados que focalizan su ataque en un mismo destino” 111 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 26. Escenario de un Ataque de Denegación de servicio Distribuído (DDoS) Fuente: <El Autor> Adaptado < MIRKOVIC.J. D-WARD Source-End Defense Against Distributed Denial-of-Service Attacks.2003. p 40.> La Figura 26, muestra una negociación distribuida simple en el que varias máquinas (A,B) atacantes detienen un servicio al enviar paquetes de datos con flujos maliciosos a la víctima (V) negando el servicio a los clientes legítimos C1 y C2. 26.2 FUENTES DE ORIGEN DE LOS ATAQUES DOS / DDOS Los ataques de denegación de servicio suelen tener varios orígenes, lo que complica la posibilidad de mantener un control efectivo sobre todos los recursos o servicios ofrecidos. Una detección tempanara con un sistema de alertas como el que se ha propuesto en este proyecto podrían minimizar el riesgo. No obstante, los distintos orígenes o fuentes pueden provenir principalmente de dos fuentes: 44 44 VERDEJO. G. Seguridad en Redes IP. Universitat Autónoma de Barcelona. Barcelona Sep. 2003. p,36 “Usuarios legítimos o internos: Este grupo se subdivide en aquellos usuarios poco cuidadosos que colapsan el sistema o servicio inconscientemente (por ejemplo la persona que llena el disco duro del sistema bajando archivos de música), usuarios malintencionados (aquellos que aprovechan su acceso para causar problemas de forma premeditada) y usuarios ladrones que utilizan el acceso de un usuario legítimo (ya sea robándolo del usuario legítimo o aprovechándose de la confianza de este).” 112 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Agentes externos: Este grupo hace referencia a los no usuarios del sistema. De esta forma se consigue acceso al recurso o servicio sin necesidad de ser un usuario legítimo (un sistema que no controle la autenticación de usuarios, un sistema que presente un “bug” conocido...). En este grupo usualmente se falsea la dirección de origen (faked/spoofed IP) con el propósito de evitar el origen real del ataque.” Antes de diferenciar algunos ataques y principalmente el que se va a tratar en esta tesis, es conveniente identificar como actúan o las fases previas a un ataque. 26.3 PLATAFORMAS AFECTADAS: El enfoque que abarca estos contenidos académicos para el curso, comprende escenarios en los que se presenten ataques de servicio en redes IP. La trascendencia de estos ataques está dada por su independencia de plataformas en las que pueden perpetrarse y hacer efectivos estos ataques. 26.4 CARACTERÍZACION DE LOS ATAQUES DOS: Dependiendo de la técnica usada o las características del ataque, se debe proyectar su defensa o estrategia de protección. Es por ello importante identificarlas para proyectar su análisis en busca de proponer una mejor solución como se indica a continuación: 26.4.1 Uso de IP Source Spoofing: En la que los atacantes utilizan la suplantación o falseo de una dirección IP durante el ataque emitiendo información falsa desde el mismo origen del ataque ocultando información de la cabecera de los paquetes IP. Una de las características de este ataque es que las máquinas “Agente” o las que envían el ataque, son difíciles de rastrear, incluso con la información que capturan y la dirección oculta de donde se realiza el ataque, se pueden realizar ataques futuros. La otra característica que tiene esta falsificación de direcciones IP, es la que le permite a los atacantes hacer una “reflexión del ataque” que consiste que las solicitudes a un determinado servicio que realiza el atacante en nombre de la víctima, genera muchas respuestas de un tamaño pequeño. A medida que realice más solicitudes, estas obtendrán más respuestas que son recibidas por la víctima. Puede extender su ataque enviando solicitudes a servidores públicos que otorgan mayor número de respuestas. 113 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Un gran número de máqui nas agente: Acá se complica el ataque, por que incluso si un sistema de detección de intrusos (IDS) detecta las peticiones y el origen de las mismas, por el gran volumen de atacantes y la diversidad de paquetes enviados, pueden evitar que las repuestas lleguen al sistema de detección y tomar mucho tiempo en procesarse dando oportunidad a usar la “reflexión” explicada anteriormente para retomar el ataque. 26.4.2 Similitud de tráfico legítimo: Cualquier tipo de tráfico puede ser utilizado para ejecutar un ataque de denegación de servicio. Algunos tipos de tráfico requieren un mayor volumen de paquetes para que tengan mayor éxito que otros. El tráfico legítimo fácilmente puede ser confundido con el tráfico malicioso. Un sistema de defensa estaría basado en la obtención de un volumen de datos estadísticos para su análisis de la semántica o estructura de las transacciones habituales y compararlas con las que se tengan duda. Es un principio básico de muchos sistemas de detección de intrusos (IDS). La seguridad en Internet es altamente Independiente: En donde las víctimas son también altamente dependientes de la seguridad de otros subsistemas a los que estén añadidos o de los que tomen los servicios. Este aspecto se tiene en cuenta sobre todo en redes de gran cobertura y tamaño. Control de internet Distribuido: La gestión de internet es distribuida y cada red ejecuta sus políticas de seguridad y manejo de información de acuerdo a las establecidas por sus dueños. No hay manera de hacer cumplir un mecanismo particular de seguridad y se torna complejo el estudio del tráfico de red que atraviesan diferentes redes para optar por la mejor estrategia. Los recursos de Internet son limitados: Cada entidad de internet, ya sea un host, red, equipo activo; dispone de recursos limitados que generalmente son consumidos en su totalidad por los usuarios e incluso sobrepasados. De allí que todo intento de ataque de denegación de servicio (DoS) tendrá éxito siempre y cuando no hay un mecanismo de protección previo. Existen más aspectos de diseño en la red, que afectan la probabilidad o no de que suceda un ataque y más aún inciden en el tipo de ataque que se puede realizar. Estos aspectos son analizados en el desarrollo del proyecto y se convierten en variables a tener en cuenta para el diseño de un mecanismo de protección. 114 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 27: FASES PREVIAS A LA REALIZACION DEL ATAQUE: Para poder realizar el ataque a la red local, o a una aplicación web o a una URL específica, se identificaron unas etapas previas o fases que se realizan para poder perpetrar un ataque (DoS) de nivel de seguridad a una red TCP/IP que permitan identificar estrategias con miras a determinar un sistema de alarmas que minimicen el riesgo y que lo identifiquen de forma específica y concreta. 27.1 ACTIVIDADES PREVIAS AL ATAQUE (DOS): El objetivo se apoya con gran relevancia en la correcta interpretación y análisis del comportamiento de los datos en las conversaciones establecidas usando el protocolo TCP/IP y los servicios implementados por el protocolo IP y su unidad de datos básica que es el datagrama, cuyo tamaño máximo es de 65535 bytes (64K). La Figura 27 muestra la estructura de un datagrama IP V 4.0 en el que se resalta el campo TTL (Time to Live) que determina el tiempo de vida del datagrama antes de ser rechazado por alguna causa en el mecanismo de comunicación que adopta el protocolo. Limita el tiempo que un datagrama puede pasar en la red. TTL se decrementa en una unidad cada vez que pasa por un encaminador si todo va bien, o en una unidad por segundo en el encaminador si hay congestión. Al llegar a cero el datagrama es descartado. Este campo que se inicializa en el ordenador de origen a un valor (máximo 2^8=256) y se va decrementando en una unidad cada vez que atraviesa un router. De esta forma, si se produce un bucle y/o no alcanza su destino en un máximo de 255 “saltos”, es descartado. En este caso se envía un datagrama ICMP de error al ordenador de origen para avisar de su pérdida. La ubicación en la figura del campo TTL antecede a la identificación del tipo de protocolo que interviene en la comunicación. 115 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura 27. Estructura de un datagrama IP V 4.0 Fuente: <El Autor> 27.2 TOPOLOGÍA O DISTRIBUCIÓN FÍSICA: Los ataques (DoS), también basan sus técnicas inicialmente capturando información relacionada con la topología de red o distribución física identificando el tipo de sistema entre el atacante y las victimas. La comunicación está implementada sobre el protocolo IP (Internet Protocol) siendo la pieza fundamental en la que se sustenta el sistema TCP/IP y por tanto todo el funcionamiento de Internet. Su especificación está recogida en [RFC791]. 45 Se parte también de un análisis básico de la estructura de un datagrama IP, que está dividida en bloques de 32 bits (4 bytes). El datagrama IP se transmite “El protocolo IP está dado para facilitar un sistema sin conexión (connectionless) y no fiable (unreliable) de entrega de datagramas entre dos ordenadores cualesquiera conectados a Internet. Además, no mantiene ningún tipo de información referente al estado de las conexiones. Cada datagrama es encaminado de forma independiente, lo que le convierte en un protocolo sin conexión. Debido a estas particulares características, puede pasar que se pierdan datagramas y/o que estos no lleguen en orden. De esta manera, cualquier fiabilidad que se necesite, deberá ser realizada por las capas superiores (TCP).” 45 Ibid, p. 13 116 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web enviando primero el bit 0, luego el bit 1, 2, 3... Y así sucesivamente hasta finalizar el datagrama. Este orden se denomina network byte order. Para el estudio que se lleva a cabo en la detección de ataques DoS, es muy importante conocer este orden de transmisión de la información, puesto que los diferentes ordenadores tienen diferentes sistemas de almacenamiento de bits en memoria. Para poder capturar esta información referente a la topología de red o distribución física identificando el tipo de sistema entre el atacante y las victimas, los ataques DoS manipulan el campo TTL de la cabecera IP de un paquete para determinar la forma que los saltos uno a uno se dan y por los que un determinado paquete avanza por la red TCP/IP. El campo TTL actúa como un contador de saltos, viéndose reducido en una unidad al ser reenviado por cada dispositivo de encaminamiento. Específicamente este campo TTL “ tiempo de vida” (Time To Live), es un campo de 8 bits que indica el tiempo máximo que el datagrama será válido y podrá ser transmitido por la red. Esto permite un mecanismo de control para evitar datagramas que circulen eternamente por la red (por ejemplo en el caso de bucles). 27.3 FUNCIÓN DE ICMP EN LOS ATAQUES DOS. Un análisis inicial muestra la importancia de este protocolo y su papel cuando se trata de extraer información de una conversación TCP con miras a ser atacada o a denegar algún servicio. El protocolo ICMP (Internet Control Message Protocol) es un protocolo simple que va encapsulado en datagramas IP y que tiene por función el control del flujo de la comunicación así como la comunicación de errores [RFC792]. En la Figura 28 se muestra la estructura de un mensaje ICMP. Los mensajes de error de este protocolo los genera y procesa TCP/IP y no el usuario. Dentro del datagrama IP se muestra la ubicación de la cabecera ICMP de 8 bytes. Figura 28. Estructura de un mensaje ICMP Fuente: <El Autor> 117 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web ICMP también permite obtener información como la franja horaria del sistema destino o la máscara de red. La simple ejecución del comando ping contra la dirección IP asociada a un nombre de dominio ofrece al atacante información de gran utilidad. Para empezar, esta información le permitirá determinar la existencia de uno o más equipos conectados a la red de este dominio. Una explicación sencilla de como se identifican equipos conectados la da un servicio de entrega basado en el mejor intento (best effort) que adopta IP. Significa que cuando se detecta un error en la transmisión o funcionamiento irregular ya sea por tiempo de entrega de paquetes, tamaños, tipos de servicios, direcciones origen o destino, se contempla un sistema muy simple de tratamiento de errores. Este mecanismo de control de errores viene regulado por el protocolo ICMP (Internet Control Message Protocol). Generalmente la víctima (equipo, host o cliente), descarta los datagramas y enviaría un mensaje de error ICMP al ordenador de origen sin encargarse de la retransmisión del datagrama, lo que no implica fiabilidad. La cabecera del protocolo ICMP tiene un tamaño de 8 bytes que contiene varios campos que permiten la identificación del mensaje. En la Figura 29 se muestran estos campos que dan información del Tipo de Mensaje, un código de identificación y la ubicación del campo de 16 bits chkeksum expuesta en el texto del [RFC793] que documenta acerca del cálculo del campo del checksum para TCP. Figura 29. Cabecera de un datagrama ICMP Fuente: <El Autor> El Tipo (Type) indica el carácter del mensaje enviado, ya que el protocolo permite especificar una gran variedad de errores o mensajes de control de flujo de las comunicaciones La tabla 4 muestra el tipo de mensajes que el protocolo ICMP emite y los códigos de error utilizados para su identificación. Estos códigos están ordenados en la 118 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web columna izquierda en orden jerárquico clasificados en Mensajes informativos y Códigos de error. Mensajes informativos 0 Echo Reply (respuesta de eco) 3 Destination Unreacheable (destino inaccesible) 4 Source Quench (disminución del tráfico desde el origen) 5 Redirect (redireccionar - cambio de ruta) 8 Echo (solicitud de eco) 11 Time Exceeded (tiempo excedido para un datagrama) 12 Parameter Problem (problema de parámetros 13 Timestamp (solicitud de marca de tiempo) 14 Timestamp Reply (respuesta de marca de tiempo) 15 Information Request (solicitud de información) - obsoleto- 16 Information Reply (respuesta de información) - obsoleto- 17 Addressmask (solicitud de máscara de dirección) 18 Addressmask Reply (respuesta de máscara de dirección Códigos de error 0 no se puede llegar a la red 1 no se puede llegar al host o aplicación de destino 2 el destino no dispone del protocolo solicitado 3 no se puede llegar al puerto destino o la aplicación destino no está libre 4 se necesita aplicar fragmentación, pero el flag correspondiente indica lo contrario 5 la ruta de origen no es correcta 6 no se conoce la red destino 7 no se conoce el host destino 8 el host origen está aislado 9 la comunicación con la red destino está prohibida por razones administrativas 10 la comunicación con el host destino está prohibida por razones administrativas 11 no se puede llegar a la red destino debido al Tipo de servicio 12 no se puede llegar al host destino debido al Tipo de servicio Tabla4. Mensajes y códigos del protocolo ICMP Fuente: <El Autor> Poder identificar los errores en el campo de Código (Code) que indica el código de error dentro del tipo de error indicado en el campo “tipo” agrupando los mensajes en tipos y dentro de cada tipo especificando el código concreto al que se refiere, ayudan a determinar alertas sobre los fallos en la red o posibles ataques. 119 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web El Checksum simplemente permite verificar la integridad del mensaje enviado, lo que permite detectar posibles errores en el envío, transporte o recepción del mensaje de control ICMP. El campo de Operación (Operation) depende directamente del contenido de los campos de tipo y código, permitiendo la inclusión de una información extra referida al código de error. 27.4 DESCUBRIMIENTO DE USUARIOS: Obtención de usuarios válidos. Otra información relevante en un sistema es el nombre de los usuarios que tienen acceso a los equipos. Mediante el uso de un servicio sobre el protocolo TCP en el puerto 79, denominado “finger” [RFC1288], se porta como un protocolo que proporciona información de los usuarios de una máquina en el momento de acceder a algún tipo de servicio. 27.5 INFORMACIÓN DEL DOMINIO: Se debe contemplar escenarios reales en los que intervengan redes heterogéneas. Un escenario típico es cuando una organización tiene implementado Dominios, que ofrecen información acerca de las subredes que están detrás de el y que despliegan información cando se hacen las consultas de nombre de dominio (DNS). El sistema DNS funciona principalmente en base al protocolo UDP. Los requerimientos se realizan a través del puerto 53. Se referencia el análisis del protocolo UDP como un protocolo simple y orientado a datagrama. Su definición se recoge en [RFC7680]. El sistema está estructurado en forma de “árbol“. Cada nodo del árbol está compuesto por un grupo de servidores que se encargan de resolver un conjunto de dominios (zona de autoridad). Un servidor puede delegar en otro (u otros) la autoridad sobre alguna de sus sub-zonas (esto es, algún subdominio de la zona sobre la que él tiene autoridad) Son aspectos computacionales que se deben tener en cuenta en el diseño del modelo ya que sea que se comporten como agentes externos o no, influyen en el diseño. Si los servidores que ofrecen la información de los Dominos no están configurados debidamente, seguramente que tanto los tiempos, estrategias o técnicas que usan los ataque de denegación del servicio, varían 120 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web LECCION 28: FINGERPRINTING La seguridad en aplicaciones web, debe llevar a los profesionales que traten esta temática, poder identificar ataques DoS en redes Ethernet. Se trata entonces de obtener información de un sistema concreto y de alguna vulnerabilidad específica. Esto se hace obteniendo su huella identificativa respecto de la pila TCP/IP de los equipos atacados. Esta técnica es la que se conoce como Fingerprinting y la información que puede brindar esta técnica dentro de las muchas opciones que tiene de descubrir datos de la víctima es la de permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en la maquina analizada. Un análisis previo de esta Pila TCP/IP permite ver como es de vulnerable esta implementación: 28.1TRANSMISIÓN EN EL PROTOCOLO DE CONTROL. Cuando TCP se encuentra entre IP y la capa de aplicación, el Protocolo de Control de Transmisión (TCP) garantiza una comunicación fiable orientada a conexión para las estaciones y para los servicios que estas implementan. TCP garantiza que los datagramas se entregan en orden, sin que haya errores, y sin duplicación. Los servicios se proporcionan utilizando mecanismos de control de flujo tales como el de “Ventana deslizante” (Three-way Handshake) y la adaptación de Técnicas de retransmisión Figura 30. Topología de una red genérica Fuente: <Schuba. C, Krsul. I y Kuhn. M. Analysys of a Denial Service Attack on TCP, p 16.> Three-way Handshake: Para entender el proceso de establecimiento de conexión en tres vías se ha tomado una topología de una red genérica como la que se muestra en la figura (30). Similar al escenario que el proyecto pretende comprobar en la detección de ataques de denegación de servicio. 121 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Antes de poder transmitir datos entre un host de origen S y un host de destino D, TCP tiene que establecer una conexión entre S y D como se ve en la figura (6). El establecimiento de esta conexión recibe el nombre de “conexión en tres vías” como se representa en la figura (31). Figura 31. Mecanismo de tres vias Fuente: <Schuba. C, Krsul. I y Kuhn. M. Analysys of a Denial Service Attack on TCP, p 16.> El mecanismo es el siguiente: 46 46 Protocolo de acuerdo a tres vías. Disponible desde Internet en: <http://neo.lcc.uma.es/evirtual/cdd/tutorial/transporte/twhandshake.html> “0. El host receptor, que en el caso de más común será un servidor, espera pasivamente una conexión ejecutando las primitivas LISTEN y ACCEPT. 1. En primer lugar, el host que desea iniciar la conexión ejecuta una primitiva CONNECT especificando la dirección IP y el puerto con el que se desea conectar, el tamaño máximo del segmento que está dispuesto a aceptar y opcionalmente otros datos, como alguna contraseña de usuario. Entonces la primitiva CONNCET hace una apertura activa, enviando al otro host un paquete que tiene el bit SYN (ver formato de un segmento TCP más abajo) activado, indicándole también el número de secuencia inicial "x" que usará para enviar sus mensajes. 122 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 2. El segundo paso continúa con el host receptor que recibe el segmento revisa si hay algún proceso activo que haya ejecutado un LISTEN en el puerto solicitado, es decir, preparado para recibir datos por ese puerto. Si lo hay, el proceso a la escucha recibe el segmento TCP entrante, registra el número de secuencia "x" y, si desea abrir la conexión, responde con un acuse de recibo "x +1" con el bit SYN activado e incluye su propio número de secuencia inicial "y", dejando entonces abierta la conexión por su extremo. El número de acuse de recibo "x +1" significa que el host ha recibido todos los octetos hasta e incluyendo "x", y espera "x +1" a continuación. Si no deséa establecer la conexión, envía un contestación con el bit RST activado, para que el host en el otro extremo lo sepa. 3. El primer host recibe el segmento y envía su confirmación, momento a partir del cual puede enviar datos al otro extremo, abriendo entonces la conexión por su extremo. 4. La máquina receptora recibe la confirmación y entiende que el otro extremo ha abierto ya su conexión, por lo que a partir de ese momento también puede ella enviar datos. Con esto, la conexión ha quedado abierta en ambos sentidos.” 28.2 EXPLORACIÓN DE PUERTOS: El escaneo o exploración de puertos permite determinar las características de una red o sistema remoto, con el objetivo de identificar los equipos disponibles y alcanzables desde Internet, así como los servicios que ofrece cada uno. Se puede llegar a conocer los sistemas existentes, los servicios ofrecidos por ellos, cómo están organizados los equipos, que sistemas operativos ejecutan y cual es le propósito de cada uno. Hay diferentes formas de explotar las vulnerabilidades de TCP/IP en los que los ataques de Denegación de Servicio hacen uso de diferentes técnicas para realizar esta exploración de puertos TCP. Entre las más conocidas, se destacan las siguientes: • TCP connect scan. Mediante el establecimiento de una conexión TCP completa (completando los tres pasos del establecimiento de la conexión) la exploración puede ir analizando todos los puertos posibles. Si la conexión se realiza correctamente, se anotara el puerto como abierto (realizando una suposición de su servicio asociado según el número de puerto). 123 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web  TCP SYN scan. Enviando únicamente paquetes de inicio de conexión (SYN) por cada uno de los puertos que se quieren analizar se puede determinar si ´estos están abiertos o no. Recibir como respuesta un paquete RST-ACK significa que no existe ningún servicio que escuche por este puerto. Por el contrario, si se recibe un paquete SYN-ACK, podemos afirmar la existencia de un servicio asociado a dicho puerto TCP. En este caso, se enviara un paquete RST-ACK para no establecer conexión y no ser registrados por el sistema objetivo, a diferencia del caso anterior (TCP connect scan). Existen otras “vulnerabilidades” que se pueden explotar pero que son dependientes de la implementación de la pila TCP/IP. Por Ejemplo: • TCP FIN scan. Al enviar un paquete FIN a un puerto, deberíamos recibir un paquete de reset (RST) sí dicho puerto esta cerrado. Esta técnica se aplica principalmente sobre implementaciones de pilas TCP/IP de sistemas Unix. • TCP Xmas Tree scan. Esta técnica es muy similar a la anterior, y también se obtiene como resultado un paquete de reset si el puerto está cerrado. En este caso se envían paquetes FIN, URG y PUSH. • TCP Null scan. En el caso de poner a cero todos los indicadores de la cabecera TCP, la exploración debería recibir como resultado un paquete de reset en los puertos no activos. . 28.2.1 Exploración de puertos UDP: Para poder detectar si existe un sistema de filtrado o cortafuegos, los sistemas de Detección de intrusos (IDS) utilizan el protocolo UDP para mandar paquetes UDP con 0 bytes en el campo datos, si el puerto está cerrado se debe recibir un ICMP Port Unreachable. Si el puerto está abierto, no se recibe ninguna respuesta. Si se detectan muchas puertas abiertas, puede haber un dispositivo de filtrado (firewall) en el medio. Para verificar esto, se envía un paquete UDP al puerto cero, si no se recibe una respuesta ICMP Port Unreachable, entonces hay un dispositivo de filtrado de tráfico. Para un análisis de vulnerabilidades en aplicaciones web que detecte ataques de denegación de servicio (DoS) en el caso de usar paquetes UDP para la exploración de puertos, hay que tener en cuenta que a diferencia de las exploraciones TCP, se trata de un proceso mas lento puesto que la recepción de 124 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web los paquetes enviados se consigue mediante el vencimiento de temporizadores (timeouts). 28.2.2 Escaneo basado en el protocolo ICMP: La identificación de respuestas ICMP permite obtener huellas identificativas cuando se le da un mal uso a este protocolo. Muchas de las características que tienen las respuestas ICMP no son propias de los sistemas operativos. Algunos si responderán y otros no. Incluso y así la experiencia en la implementación de este protocolo dice que se pude deshabilitar este servicio de detección de errores en los sistemas de comunicación a través del mismo sistema operativo Por lo anterior, el análisis de respuestas ofrecidas mediante el tráfico ICMP como las del ICMP echo, ICMP timestap, ICMP information; se dará en la medida del desarrollo del proyecto y el análisis del ataque. Básicamente la interpretación de estas respuestas ofrecidas son: ICMP echo: comúnmente llamado “Ping”. Se le utiliza para saber cuáles son los dispositivos que se encuentran activos en una subred. Esto se hace de forma masiva para detectar todos los host. Los IDS también detectan este tipo de diálogos. ICMP broadcast: Se hace un único ping a la dirección de broadcast y se logra que todos los equipos contesten. Depende del sistema operativo la reacción a este tipo de cosas. Los sistemas Windows actuales no responden a estas solicitudes. ICMP Timestamp: Se envía un paquete ICMP Timestamp y si el sistema objetivo está activo, responde, nuevamente depende la implementación del sistema operativo si se responde o no a estos paquetes. Otros métodos tienen que ver con el uso indirecto de ICMP haciendo que un equipo conteste con paquetes de este tipo cuando se introducen errores en los paquetes IP: • IP bad header field: Se introducen errores en los campos de la cabecera IP, esto hace que si un equipo descarta el paquete debido a estos errores entonces notifica con un ICMP parameter problem. No todas las implementanciones responden a los mismos errores. Esto sirve, por ejemplo, para identificar los fabricantes de los routers. 125 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Los firewall y los IDS deberían tener en cuenta este tipo de tráfico, y manejarlo con cuidado, ya que si un firewall simplemente no deja volver paquete ICMP parameter problem, entonces un atacante puede detectar la existencia del mismo. • IP non-valid field values: Se ingresan valores incorrectos en los campos, en respuesta a esto se debería recibir un ICMP Destination Unreacheable. Por ejemplo, se podría indicar que en el campo datos hay un paquete de un protocolo no existente. Si un firewall filtra los paquetes ICMP de este tipo, entonces parecerá que existen una serie de protocolos abiertos que no existen. 28.3 FRAGMENTACIÓN IP. 47 “La unidad máxima de transferencia (Maximum Transfer Unit - MTU) es un término de redes de computadoras que expresa el tamaño en bytes de la unidad de datos más grande que puede enviarse usando un Protocolo de Internet.” Este tamaño también puede variar de una red a otra dependiendo el medio físico empleado para su transmisión. La MTU por defecto de un datagrama IP para una red de tipo Ethernet es de 1500 bytes. Si un datagrama IP es mayor a este tamaño y necesita pasar por este tipo de red, es necesario fragmentarlo; labor que la realiza el router o encaminador que dirige la red. Su RFC corresponde al [RFC 1191] Esta fragmentación puede ser usada por un atacante para hacer mal uso de eta propiedad del protocolo IP para provocar ataques de Denegación de Servicio (DoS) a causa de una mala implementación de la pila TCP/IP así como para esconder y facilitar la fase de recogida de información, búsqueda de huellas identificativas y exploración de puertos. También esta manipulación de la MTU permite a los atacantes cuando realizan ataques de denegación de servicio distribuido (DDoS), poder pasar desapercibidos e introducir en la red paquetes para la exploración de servicios. Es importante tener en cuenta esta propiedad del protocolo IP de fragmentar sus datagramas, ya que si se va a generar un mecanismos que prevea y detecte ataques DoS, poder implementar el reensamblado de paquetes ya que hoy en día muchos de los sistemas de detección de intrusos (IDS), no lo hacen y por ello no detectan este tipo de vulnerabilidades. 47 Unidad máxima de transferencia. Disponible en Internet <http://es.wikipedia.org/wiki/Unidad_m%C3%A1xima_de_transferencia> 126 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web La figura (32) se observa la configuración de un datagrama IP no fragmentado que contiene una cabecera UP que generalmente es de un tamaño de 20 bytes con información necesaria para poder dirigir el datagrama IP hacia su destino (dirección IP de origen y destino o de encaminamiento). Los 1480 bytes de datos restantes encapsulados corresponden pueden ser d eun protocolo TCP, UDP o ICMP. Figura 32. Datagrama IP No fragmentado Fuente: <El Autor.>Adaptado<Joancomarti . J, Alfaro. J y Tornil . X. Aspectos avanzados de seguridad en redes. P. 27 Para el siguiente ejemplo en un sistema tipo UNIX se identifica una MTU de 1500 bytes por defecto: root@bt:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:a0:d1:9b:b4:56 inet addr:10.1.1.10 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:d1ff:fe9b:b456/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:32429 errors:0 dropped:0 overruns:0 frame:0 TX packets:42772 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:13248489 (13.2 MB) TX bytes:11158515 (11.1 MB) Interrupt:16 root@bt:~# La forma de modificar el tamaño de la MTU se evidencia en los siguientes comandos de UNIX para una red Ethernet con un adaptador de red eth0. root@bt:~# ifconfig eth0 mtu 1000 root@bt:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:a0:d1:9b:b4:56 inet addr:10.1.1.10 Bcast:10.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1000 Metric:1 RX packets:32874 errors:0 dropped:0 overruns:0 frame:0 TX packets:43243 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:13306127 (13.3 MB) TX bytes:11213127 (11.2 MB) Interrupt:16 root@bt:~# 127 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Continuando el análisis con una MTU básica o típica de 1500 bytes, en una petición de echo request del protocolo ICMP (ping) con un envío de tres paquetes como se muestra a continuación y con un datagrama de 4028 bytes, se puede identificar como el protocolo ICMP separa los 8 bytes correspondiente a la cabecera ICMP: root@bt:~# ping -c 3 -s 4020 10.1.1.11 PING 10.1.1.11 (10.1.1.11) 4020(4048) bytes of data. 4028 bytes from 10.1.1.11: icmp_seq=1 ttl=128 time=4.73 ms 4028 bytes from 10.1.1.11: icmp_seq=2 ttl=128 time=1.29 ms 4028 bytes from 10.1.1.11: icmp_seq=3 ttl=128 time=1.28 ms --- 10.1.1.11 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev =1.281/2.436/4.735/1.625 ms root@bt:~# La fragmentación del datagrama de 4028 bytes se dividirá en fragmentos de 1550 bytes o menos para el envío. En la Figura 33 se observa la descomposición del datagrama en tres partes. Cada fragmento seguirá conteniendo una cabecera IP de 20 bytes y una cabecera ICMP (petición echo ICMP) de 8 bytes. Se ha diferenciado con color los fragmentos de 1500 bytes y el fragmento restante de 1068 bytes. Figura 33. Datagrama IP de 4028 fragmentado con MTU de 1500 bytes Fuente: El autor 128 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Un análisis del re ensamblado se evidencia con el analizador de protocolos Wireshark como se muestra en la Figura 34 y 35. Se identifica una cabecera de 20 bytes y los tres frames: (Dos de 1480 y uno de 1068 butes). Esta información la ha arrojado un analizador de protocolos. Se identifica claramente la dirección IP origen 10.1.1.2 (source) y la dirección IP destino 10.1.1.11 (Destination) confirmando el re ensamblado IP en tres (03) Frames. Figura 34. Reensamblado de frames en Wireshark. Fuente: El autor Figura 35. Fragmentación y Reensamblado de 4028 bytes con una MTU de 1500 bytes. Analizado en Wireshark Fuente: El autor 129 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web La comunicación TCP y su re ensamblado se confirma en la negociación de tres vías en el diagrama “Flow Graph” Figura (36). Los paquetes IP e ICMP son re ensamblados en orden jerárquico desde su origen la dirección IP 10.1.1.2 al 57 destino la dirección IP 10.1.1.11 . Este re ensamblado se realiza en dieciocho (18) envíos que corresponden a 6 mensajes por cada fragmento. Al ser tres (03) fragmentos se completan los 18 envíos Figura 36. Fragmentación Reensamblado TCP. Diagrama Flow Graph Fuente: El autor LECCION 29: TIPOS DE ATAQUES: Los ataques que a continuación se describen afectan directamente la disponibilidad de aplicaciones web. 29.1 ATAQUE TCP/SYN Flooding: Aprovechándose de la debilidad del protocolo TCP en las primeras implementaciones de las pilas TCP, los ataques a trabajar se basan en no poder completar intencionalmente el protocolo de intercambio TCP. Se ha seleccionado este tipo de ataque para su análisis y detección de alarmas ya que es uno de los más implementados con diferentes formas de actuar. No tiene límite de envío de 130 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web paquetes por lo que el rendimiento en la red se baja de inmediato y considerablemente hasta llegar a denegar el servicio. El ataque TCP/SYN Flooding se basa en una inundación masiva de la red mediante datagramas IP y por consiguiente lleva a no completar intencionalmente el protocolo de intercambio TCP para inundar la cola de espera. La víctima se queda esperando por establecer un servicio pues el atacante no responde con ACK los SYN/ACK de la víctima, Esto ocurre hasta saturar los recursos de memoria y así consigue la denegación de servicios de la víctima. En la Figura 37 se observa en rojo la ruta del ataque. Las víctimas pueden ser todos los hosts e incluso el router. El ataque es lanzado desde un sistema BackTrack con dirección IP 10.1.1.10/24 que se encara de generar el tráfico malicioso. Figura37. Escenario para un ataque DoS TCP/SYN Flooding Fuente: <El Autor.> La denegación de servicios se da por que el sistema está a la espera de que baje el umbral que generalmente es 1 minuto para aceptar mas conexiones, cada conexión generada por un SYN, tienen un temporizador de 1 minuto, cuando se 131 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web excede el límite de tiempo o umbral, se libera la memoria que mantiene el estado de la conexión y la cuenta de la cola de servicios se disminuye en 1. El atacante debe usar un IP falso para que no le hagan seguimiento a las conexiones. La interpretación del ataque se presenta en la tabla (5) en donde se indican los flujos de origen y destino en el ataque. Diagrama del ataque TCP/SYN Flooding ORIGEN DESTINO IP=1.2.3.4 → SYN IP=10.1.1.11 IP=1.2.3.4 ← SYN/ACK IP=10.1.1.11 Nunca responde con ACK El IP=10.1.1.11guarda en la cola la petición de conexión por 1 minuto Se repite la secuencia de requerimiento El IP=10.1.1.11se satura por tanto requerimiento encolado y ocurre el DoS Cualquier IP cliente pide servicio al servidor El IP=10.1.1.11 no puede atender requerimientos pues está en medio de un ataque DoS. Solamente cuando cese el ataque automáticamente se atienden los requerimientos de los clientes Tabla5. Diagrama del ataque TCP/SYN Flooding Fuente: <El Autor> Procedimiento: La instrucción del ataque es así: # hping2 10..1.11 –-rand-source –S –-destport 80 –-faster --debug –w 2048 La explicación de esta instrucción está dada en la tabla (6) Descripción de los parámetros: PARAMETRO DESCRIPCION 10.1.1.11 IP de la Victima --rand-source IP ficticio o spoofed, se genera aleatorio, la idea es que no exista en la red, al no existir este no responde y así el atacante pasa inadvertido --debug Muestra cada intento 132 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web -S Indica el flag “S” o SYN para solicitar un servicio --destport Indica el servicio requerido, es clave que este servicio este habilitado en la victima --faster Hace el intento de envió de SYN lo mas rápido que se pueda .w 2048 La ventana de envío máximo será de 2048 Tabla 6. Descripción de los parámetros del ataque TCP/SYN Flooding Fuente: <El Autor Las opciones de envío o inundación de peticiones que hacen de este ataque uno de los mas perpetrados en redes Ethernet son comprobadas mediante el incremento del envío de paquetes por cada segundo que pasa. Debe inundarse la red con muchos paquetes por segundo para que el ataque sea efectivo. Estas opciones se ejecutan con los siguientes comandos: #hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu1000000, para 1 paquete por segundo #hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu500000, para 2 paquetes por segundo #hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu333333, para 3 paquetes por segundo (*) #hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu250000, para 4 paquetes por segundo (*) #hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu200000, para 5 paquetes por segundo (*) Tipo de datagramas: La inundación de datagramas IP puede ser de diferentes tipos: UDP: Generar peticiones sin conexión a cualquiera de los 65535 puertos disponibles. En muchos sistemas operativos, las peticiones masivas a puertos específicos UDP (ECHO, WINS) causan el colapso de los servicios que lo soportan. ICMP: Generación de mensajes de error o control de flujo malicioso. En este caso el objetivo es doble, degradar el servicio de red con la inundación de peticiones y/o conseguir que los sistemas receptores quede inutilizados por no poder procesar todas las peticiones que les llegan. 133 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web TCP: Genera peticiones de conexión con el objetivo de saturar los recursos de red de la máquina atacada. Este protocolo es orientado a conexión, y como tal consume recursos de memoria y CPU por cada conexión. El objetivo es el de saturar los recursos de red disponibles de los ordenadores que reciben las peticiones de conexión y degradar la calidad del servicio. 29.2 Ataque Broadcast IP Flooding: Es una variante del ataque IP Flloding. Análogamente, IP también tiene un sistema de radiodifusión (broadcast) [RFC919] que permite la comunicación simultánea con todos los ordenadores de la misma red. En este tipo de ataque se utiliza la dirección de identificación de la red IP (broadcast address) como dirección de destino del paquete IP. De esta forma, el router se ve obligado a enviar el paquete a todos los ordenadores pertenecientes a la red, consumiendo ancho de banda y degradando el rendimiento del servicio. También existen variantes dónde se envían peticiones de PING a varios ordenadores falseando la dirección IP de origen y substituyéndola por la dirección de broadcast de la red a atacar. De esta forma, todas las respuestas individuales (Figura 38) se ven amplificadas y propagadas a todos los ordenadores pertenecientes a la red amplificándolas y propagándolas consiguiendo una alta efectividad en el ataque. Figura38. Ataque Broadcast IP Flooding Fuente: <El Autor.> 134 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web 29.3 Smurf: Este tipo de ataque se basa en falsear las direcciones de origen y destino de una petición ICMP de ECHO (ping). La Figura 39 muestra la topología del ataque que como dirección de origen utiliza la dirección IP de la máquina que va a ser atacada. En el campo de la dirección de destino se ubica la dirección broadcast de la red local o red que se utilizará como “lanzadera” para colapsar al sistema elegido. Con esta petición fraudulenta, se consigue que todas las máquinas de la red contesten a la vez a una misma máquina, consumiendo el ancho de banda disponible y saturando al ordenador elegido. Figura39. Ataque Smurf Fuente: <El Autor.> La sintaxis básica para este ataque es: hpi ng3 - a [ I P obj et i vo a spoof ear ] - - f l ood [ I P Br oadcast ] 29.4 STeardrop: Este tipo de ataque aprovecha las deficiencias que presenta el reensamblado de paquetes IP cuando son fragmentados. Por definición del protocolo, un paquete IP tiene un tamaño máximo de 64K (65.535Bytes). r oot @bt : ~# pi ng - c 3 - s 70000 10. 1. 1. 16 Error: packet size 70000 is too large. Maximum is 65507 r oot @bt : ~# 135 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Cada red por la que transitan los paquetes IP tiene un tamaño máximo de paquete (MTU, Maximum Transfer Unit), es por ello que se necesitan fragmentar los paquetes IP en varios trozos que serán reconstruidos al llegar al destino. El protocolo IP especifica unos campos en la cabecera encargados de señalar si el paquete IP está fragmentado (forma parte de un paquete mayor) y que posición ocupa dentro del datagrama original. En la Figura 40 se observan los campos que intervienen en la fragmentación. Figura40. Cabecera Paquete IP V 4.0. Fuente: <El Autor.> En el campo de banderas (flags) existe un bit denominado “More” (mas) que indica que el paquete recibido es un fragmento de un datagrama mayor, igualmente el campo de número de identificación del datagrama especifica la posición del fragmento en el datagrama original. El ataque “ teardrop” utiliza esta funcionalidad para intentar confundir al sistema operativo en la reconstrucción del datagrama original y lograr el colapso del servicio y/o del sistema. Este ataque y sus variantes se basan en falsear los datos de posición y/o longitud de forma que el datagrama se sobrescriba (overlapping) y produzca un error de sobreescritura del buffer (buffer-overrun) al tratar con desplazamientos negativos Usualmente el sistema operativo detecta el intento de acceso a una zona de memoria que no corresponde al proceso ejecutado y aborta el servicio. Dependiendo de la robustez del sistema operativo podemos perder “solo” el servicio atacado o incluso llegar a colapsar todo el ordenador. 136 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Otra variante de este ataque consiste en enviar cientos de fragmentos “modificados” de forma que se solapen con el objetivo de saturar la pila de protocolo IP de la máquina atacada. 29.5 Snork: El protocolo IP necesita verificar su funcionamiento. Par realizar esta acción el sistema envía un datagrama “especial” al ordenador destino, que lo reconoce y envía una respuesta al origen (ECHO → REPLY). El protocolo IP define para estas pruebas [RFC862] un servicio para la recepción de un datagrama UDP al puerto 7 (ECHO). Existe un servicio proporcionado en muchos sistemas operativos tipo UNIX denominado CHARGEN (CHARacter GENerator, generador de caracteres) que dada una petición responde con una secuencia aleatoria de caracteres. Este servicio se encuentra disponible “escuchando” en el puerto 19 a datagramas UDP. En sistemas Windows NT se suele utilizar el puerto 135 (Microsoft Locator Service) para el ataque “snork”. En la Figura 41 se muestra el escenario típico del ataque Snort que se basa en una utilización malintencionada de estos dos servicios típicos en sistemas UNIX (CHARGEN y el servicio ECHO). El ataque consiste en cruzar ambos servicios enviando una petición falsa al servicio CHARGEN (que retorna una secuencia de caracteres pseudo-aleatoria) falseando la dirección de origen dando como puerto de respuesta el puerto ECHO (que responde a cualquier petición) de la máquina a atacar. De esta forma, se inicia un juego de pingpong infinito. Figura41. Ataque DoS Snork Fuente: <El Autor.> 137 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Este ataque puede realizarse entre varios ordenadores (consumiendo ancho de banda y degradando el rendimiento de la red) o desde un mismo ordenador (él mismo se envía una petición y responde) consiguiendo consumir los recursos existentes (especialmente CPU y memoria) de la máquina atacada. 29.6 Ataque Distribuido TRINOO /TRIN00: Es una herramienta que implementa un ataque de denegación de servicio mediante un modelo jerárquico maestro/esclavo (master/slave). El ataque consiste en la instalación de las herramientas de TRIN00 (sniffers de red, puertas traseras o backdoors, daemons, root-kits.) en los equipos desde los que partirá el ataque. Esta instalación las ha hecho previamente el atacante aprovechando bugs conocidos del sistema operativo (buffer overflow) o mediante técnicas de sniffing con explotación de servicios. Posteriormente, desde este ordenador comprometido se procede al rastreo (scanning) de otros ordenadores con vulnerabilidades conocidas en servicios básicos (FTP, RPC, NFS…) para proceder a su infección. Este rastreo suele realizarse dentro de la misma red ya que la velocidad de transmisión es más rápida y permite “verificar” más máquinas por segundo. Por otro lado las medidas de seguridad entre ordenadores locales suelen ser mínimas. Con los resultados obtenidos del rastreo se genera una lista de ordenadores vulnerables dónde se ejecutarán los programas para obtener el acceso (exploits). Para verificar que ordenadores de la lista han podido ser captados, el ordenador de origen suele tener un proceso demonio (daemon) que escucha el puerto TCP 1524, dónde se enviará una señal por cada ordenador infectado. La arquitectura de este ataque se ve en la Figura 42 en un diagrama de tres capas. Se observa cómo a partir de un único computador el atacante podrá llegara obtener toda una red de equipos a su disposición para realizar el ataque distribuido. 138 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura42. Ataque DDoS TRIN00 Fuente: <El Autor.> “La comunicación entre las distintas capas se realiza mediante conexiones TCP (fiables) para la parte atacante-master, y conexiones UDP (no fiables) para la parte master-save y slave-master, en puertos específicos para cada máquina. La comunicación siempre se inicia con la transmisión de una contraseña. Esto permite que ni el administrador del equipo ni el de otros atacantes puedan acceder al control de la red de ataques de TRIN00. Los demonios de TRIN00 situados en los equipos master y slave permiten la ejecución de comandos para iniciar, controlar y detener ataques de denegación tradicionales como ICMP Flloding, SYN Flooding, Smurf, etc. Para acceder a estos comandos, el atacante realizará una conexión Telnet en el puerto especificado como el que se relaciona en la Figura 43. “ 48 48 <HERRERA. Jordi, GARCIA, Alfaro y PERRAMON. Javier. Aspectos Avanzados de Seguridad en Redes. UOC. España. P. 42> 139 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Figura43. Esquema de comunicaciones de TRIN00 Fuente: <El Autor.> LECCION 30: HERRAMIENTAS QUE AYUDAN A PREVENIR ATAQUES (DoS): La selección de las herramientas a usar (tabla 7) enmarcan un sistema de detección de intrusos que a la vez realice gestión de red se compone de una serie de herramientas software que ayudan al ingeniero a gestionar una red de datos. Estas herramientas suelen incluir elementos y servicios que en conjunto forman un sistema completo de gestión. La mayoría de ellas ofrecen características como: • Ofrecen al usuario un interfaz gráfico • Suelen ofrecer facilidades de exportación de datos para su tratamiento mediante bases de datos, hojas de cálculo, etc. • Gestión proactiva: generación de informes basados en web, con datos históricos que ayudan a identificar problemas potenciales, mediante análisis de tendencias. • Los datos recopilados acerca de la topología, los eventos generados y los datos recogidos mediante SNMP se almacenan de manera inteligente. • Capacidad de tolerancia a fallos: planificación de copias de seguridad de la información de gestión más sensible 140 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web HERRAMIENTAS FUNCION Descubrimiento automático de la topología de la red Un descubrimiento dinámico, proactivo, reactivo y programado permite una detección rápida y eficiente de los cambios y las actualizaciones en la red. Herramientas de diagnóstico de la red Este conjunto de herramientas permite que el usuario conozca el estado de su conexión Herramientas de seguridad Proveen los mecanismos adecuados para que la información de una organizaron o empresa sea segura, y esto se consigue con las garantías de: Confidencialidad: que garantiza que la información sea accesible Integridad: protege la exactitud y totalidad de la información Disponibilidad: que garantiza a los usuarios autorizados acceso a la información y los recursos. Diagnóstico de problemas Detectar, prevenir y diagnosticar problemas de conectividad o funcionamientos con un servicio de red. Especialmente en los niveles uno (1) y dos (2) del modelo OSI. Monitorización de la red Monitorea gráficamente servicios de red, protocolos e interfaces. Monitoreo de desempeño: – Disponibilidad. – Tiempos de respuesta. – Carga de cpu, espacio de disco, uso de la memoria. Monitoreo de Seguridad --Recolección de indicadores y alertas. – Análisis y correlación por parte del analista – Alarma al equipo de toma de decisiones Gestión de MIB’s Navegadores de MIBs (MIB Browsers) Compiladores de MIBs Generadores de tráfico Calculadoras de direcciones IP Servidores TFTP Software de Gestión de red Muy simple (SNMP) o muy complejo (OSI) Requiere acceso a MIB local y a agentes y gestores remotos. Gestión de direcciones de red Calculadoras IP Software Vlans: Adminstra direcciones de red por varios métodos: --Por los servicios que presta cada host. --Por Protocolos. --Por Puertos. --Por direcciones físicas Mac Adress Analizador de protocolos Herramientas que sirve para desarrollar y depurar protocolos y aplicaciones de red. Permite al ordenador capturar diversas tramas de red para analizarlas, ya sea en tiempo real o después de haberlas capturado. Por analizar se entiende que el programa puede reconocer 141 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web que la trama capturada pertenece a un protocolo concreto. Finalmente le muestra al usuario la información codificada. Analizadores de niveles de carga en la red. El usuario puede ver todo aquello que en un momento concreto está circulando por la red que se está analizando. Software e presentación Permite al usuario monitorizar y controlar la red Interfaz de usuario unificada La misma en cualquier nodo Organizan, resumen y simplifican la información Representación gráfica preferible Lenguajes de programación Para manipular bugs, registros de logs, creación de sniffers. Tabla 7. Herramientas de gestión que ayudan a detectar ataques DoS Fuente: <El Autor> El análisis está enfocado al uso de herramientas de software Libre, teniendo en cuenta que la eficiencia de la gestión de red, y sus plataformas, se garantizan en arquitecturas tipo UNIX por las características propias de ese sistema. Por la gran diversidad de las mismas, solo se definen las más efectivas o implementadas y las que son básicas para posteriormente ahondar en ellas, combinarlas y complementarlas para así construir un modelo que permita la detección de ataques DoS. Los sistemas de gestión y de detección de intrusos, se componen de diversas herramientas, hacen uso de servicios, protocolos y técnicas de captura y análisis de información. FUNCION QUE CUMPLE NOMBRE DESCRIPCION DESCUBRIMIENTO AUTOMÁTICO DE LA TOPOLOGÍA DE LA RED Nmap: programa de código abierto que sirve para efectuar rastreo de puertos . Fuente: http://nmap.org/ Ettercap: Es un interceptor/sniffer/registrador para LANs con ethernet basado en terminales (terminal-based) Fuente: http://ettercap.sourceforge.net Descubrimiento de servidores: Identifica computadoras en una red, por ejemplo listando aquellas que responden ping. Identifica puertos abiertos en una computadora objetivo. Determina qué servicios está ejecutando la misma.Determinar qué sistema operativo y versión utiliza dicha computadora, (esta técnica es también conocida como fingerprinting). Obtiene algunas características del hardware de red de la máquina objeto de la prueba. HERRAMIENTAS DE MONITOREO DE RED NTop: Un monitor de uso de tráfico de red. Fuente: http://www.ntop.org/ Ntop muestra el uso de la red en una manera similar a lo que hace top por los procesos. En modo interactivo, muestra el estado de la red en una terminal de usuario. En Modo Web, actúa como un servidor de Web, volcando en HTML el estado de la red. Viene con un recolector/emisor NetFlow/sFlow, una interfaz de cliente basada en HTTP para crear aplicaciones de monitoreo centradas en top, y 142 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web RRD para almacenar persistentemente estadísticas de tráfico ANALIZADOR DE PROTOCOLOS Wi reshark: Fuente: http://www.wireshark.org/ Es un analizador de protocolos de red para Unix y Windows, Permite examinar datos de una red viva o de un archivo de captura en algún disco. HERRAMIENTAS DE SEGURIDAD Snorth: Sistema de detección de intrusiones de red de poco peso (para el sistema), capaz de realizar análisis de tráfico en tiempo real y registro de paquetes en redes con IP. Fuente: http://www.snort.org/ TCPDump: Paquetes de red basado en texto.. Fuente: http://www.tcpdump.org/ Utilizados para mostrar los encabezados de los paquetes en una interfaz de red (network interface) que concuerden con cierta expresión de búsqueda GESTION DE MIBS Apache Fuente: http://httpd.apache.org/ MySQL Fuente: http://www.mysql.com/ Interprete PHP Fuente: http://www.php.net/ Servi dor JFFNMS Fuente: http://www.jffnms.org/ RRDtool Fuente: http://oss.oetiker.ch/rrdtool/ Servidor Web Sistema de gestión de base de datos relacional Lenguaje de programación interpretado, Servidor Integrado para monitoreo y gestión de dispositivos Generador de gráficos GESTIÓN DE DIRECCIONES DE RED Hpi ng Fuente: http://www.hping.org/ Si pcal c Fuente: http://www.routemeister.net/pr ojects/sipcalc/ Trabaja en línea de comandos. Orientada a Analizar paquetes TCP/IP. La interfaz está inspirada en el servicio ping de comandos de Unix. hping envía solicitudes de echo ICMP. Soporta TCP, UDP, ICMP y RAW-IP, tiene un modo de traceroute y la capacidad de enviar archivos entre un canal cubierto o protegido. ADMINISTRADOR DE SERVICIOS Webmi n Fuente http://www.webmin.com/ Herramienta de configuración de sistemas accesible vía web Tabla8. Herramientas utilizadas Fuente: <El Autor> 143 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web GLOSARIO DE TERMINOS: Abuso de funcionalidad: Una técnica de ataque que usa las características y la funcionalidad de un sitio web para consumir, estafar o evadir el acceso al sitio. También puede tener referencia con el término (DoS). Autenticación: El proceso de verificación de la identidad o localización de un usuario, servicio o aplicación. La autenticación se realiza utilizando al menos uno de tres mecanismos: "algo que tienes", "algo que sé "o" algo que es”. La aplicación puede autenticar y proporcionar diferentes servicios basados en la ubicación, método de acceso, el tiempo de permanencia y los hábitos de uso de la aplicación web. Autenticación Básica: Una forma simple de autenticación del cliente apoyado en HTTP. El cliente HTTP envía un encabezado con la solicitud al servidor web que contiene un nombre de usuario y la contraseña codificada en Base64.Si la combinación de nombre de usuario / contraseña es válida, entonces se da el acceso al recurso solicitado. Autori zación: La determinación de los recursos que un usuario, un servicio o aplicación tienen como permisos de acceso. Recursos accesibles que pueden ser URL, archivos, directorios, bases de datos, servelets, caminos de ejecución. ADDRESS RESOLUTION PROTOCOL (ARP): protocolo de la familia TCP/IP que asocia direcciones IP a direcciones MAC. AGENTE: Programa que permite a un dispositivo responder a solicitudes SNMP. APACHE: Es un software libre servidor HTTP de código abierto para plataforma Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1, y la noción del sitio virtual. ASN (Abstract Syntax Notation): Lenguaje utilizado para definir tipos de datos. Backup File Disclosure: Divulgación del archivo de copia de seguridad: (Obsoleto). Actualmente se usa el término: "Ubicación de archivo predecible". Brute Force: Un proceso automatizado de prueba y error utilizado para adivinar el "secreto" de la protección de un sistema. Ejemplos de estos secretos son nombres de usuario, contraseñas o claves criptográficas. También puede asociarse a términos como: "Autenticación", "Autenticación insuficiente", 144 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web "Password Recovery Sistema "," La débil validación de recuperación de contraseña ". BROADCAST: Transmisión de un paquete que será recibido por todos los dispositivos en una red. Buffer Overflow: Desbordamiento de Buffer: Una técnica de explotación que altera el flujo de una aplicación sobrescribiendo partes de la memoria. Desbordamientos de búfer es una causa frecuente de un mal funcionamiento del software. Si los datos escritos en un búfer superan su tamaño, el espacio de memoria adyacente se corromperá y normalmente producen un fallo. Un atacante puede ser capaz de utilizar esta situación de desbordamiento y alterar el proceso del flujo de una aplicación. Si sobrecarga el buffer y se sobrescriben por ejemplo los punteros en la pila de memoria, esta acción podría ser utilizada para ejecutar órdenes erradas al sistema operativo. ". CGI Scanner: Programa de seguridad automatizada que busca vulnerabilidades en servidores web y en aplicaciones web. Su uso muchas veces no va más allá de probar una serie de peticiones HTTP contra conocidas cadenas de CGI Client-Side Scripting: Función de navegador Web que extiende la funcionalidad e interactividad del lenguaje de marcado de hipertexto (HTML) est´tico en las páginas web. Ejemplos de lenguajes de script del lado del cliente son J avaScript, J Script y VBScript. Véase también "controles ActiveX", "J ava Applets ". CGI: Acrónimo: (Common Gateway Interface): Programación estándar para el software para conectar y ejecutar aplicaciones que residen en los servidores web. Véase también "Aplicación Web", "Servidor de aplicaciones", "Servidor Web Controles Acti veX: Controles ActiveX son programas informáticos basados en la Component Object Model (COM) y anteriormente conocido como OLE controles. Los controles ActiveX son portables y reutilizables, y pueden ser utilizados por muchos lenguajes de programación. Ellos son ampliamente utilizados por las aplicaciones web para extender su funcionalidad (por ejemplo: el sitio Windows Update) Véase también "J ava", "applets J ava", "J avaScript", "Web Browser ". Content Spoofing: “La suplantación de contenido”: Una técnica de ataque utilizada para engañar a un usuario para que acceda a contenidos falsos creyendo que son datos legítimos. 145 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web Cookie: Pequeña cantidad de datos enviados por el servidor web, a una web de un cliente, que puede ser almacenada y recuperada en un momento posterior. Típicamente se utilizan cookies para realizar un seguimiento de un estado de los usuarios a medida que usan, navegan o interactúan con un sitio web. Cookie Poisoni ng: (Obsoleto). Vea “Manipulación Cookie”. Cross-Site Scripting: (acrónimo - XSS) Una técnica de ataque que obliga a un sitio web para hacerse eco de los datos suministrados por el cliente, que se ejecutan en un navegador web por parte del usuario. Cuando un usuario interactúa entre varios sitios y aplicaciones que están haciendo eco de datos entre sí, el atacante tendrá acceso a todo el contenido navegador web (cookies, historial, versión de la aplicación, etc). Véase también "Client-Side Scripting". CSMA/CD (Carrier Sentido acceso múltiple / Detección de Colisión) es el protocolo usado en Ethernet en red para garantizar que sólo un nodo de red se transmite en el cable de red en cualquier momento. CONFIDENCIALIDAD: Que la información solo sea vista por los lentes involucrados en la comunicación y que un tercer no pueda ingresar. CONTROL DE ACCESO Y AUTORIZACIÓN: el proceso de determinar los recursos y servicios que puede usar una entidad. CORTAFUEGOS: Elemento de prevención que realizara un control de acceso para proteger una red de los equipos del exterior (potencialmente hostiles). DENEGACIÓN DE SERVICIO (DoS): ataque que hace una apropiación exclusiva de un recurso o servicio con la intención de evitar cualquier acceso a terceras partes. En inglés, deny of service. Debug Commands: Los comandos de depuración: Son características de depuración de aplicaciones o comandos que ayudan a identificar los errores de programación durante el proceso de desarrollo de software. Directory Traversal: Una técnica utilizada para explotar sitios web al acceder a los archivos y los comandos más allá del directorio raíz de los documentos que forman la estructura del sitio. La mayoría de los sitios web deben restringir el acceso de usuarios a una parte específica del sistema de archivos que normalmente se denomina “el directorio raíz” de documentos o de raíz CGI directorio. Estos directorios contienen los archivos ejecutables destinados al uso público. En la mayoría de los casos, un usuario no debería poder acceder a los archivos más allá de este punto. 146 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web DESBORDAMIENTO DE BUFFER: posibilidad de corromper la pila de ejecución para modificar el valor de retorno de una llamada a función y provocar la ejecución de código arbitrario. DISPONIBILIDAD: Los servicios y la información deben, en todo momento, estar disponibles. DNS: Servicio de Nombres de Dominio. DoS: (de las siglas en inglés Denial of Service), Ataque de Denegación de servicio DDoS: (de las siglas en inglés Distribuited Denial of Service), Ataque de Denegación de servicio Distribuido Encodi ng Attacks: Los ataques de codificación: una técnica que ayuda a la explotación de un ataque de cambiar el formato de los datos proporcionados por el usuario para omitir la comprobación de aplicación de filtros. Véase también " Null Injection". Examen de directorios: (Obsoleto) Véase "Indexación de Directorio". Enumeración de Di rectorio: (Obsoleto) Consulte "Ubicación de archivo predecible" Expiración de sesión i nsuficiente: Cuando un sitio web permite a un atacante reutilizar credenciales de sesiones viejas o anteriores para autorización y poder tener ingreso. Form Field Manipulation: Manipulación de campos en formularios: La alteración o modificación de formularios HTML. Los valores del campo de entrada que se ingresan mediante HTTP, sirven para explotar los problemas de seguridad en una aplicación web. Véase también "Cookie” ESCÁNER DE VULNERABILIDADES: aplicación que permite comprobar si un sistema es vulnerable a un conjunto de deficiencias de seguridad. EXPLOIT: aplicación, generalmente escrita en C o ensamblador, que fuerza las condiciones necesarias para aprovecharse de un error de programación que permite vulnerar su seguridad. EXPLORACION DE PUERTOS: técnica utilizada para identificar los servicios que ofrece un sistema. 147 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web EXPLOTACIÓN DE UN SERVICIO: actividad realizada por un atacante para conseguir una escalada de privilegios, abusando de alguna deficiencia del servicio o del sistema. FINGERPRINTING: Huella identificativa. FIREWALL: Un equipo que impone un conjunto de directivas de seguridad que restringen de forma severa el acceso al sistema y a los recursos. Formato de ataque Stri ng: Una técnica de explotación que altera el flujo de una aplicación mediante operaciones de biblioteca de formato de cadenas para acceder a otra instancia o momento de la aplicación. FRAGMENTACIÓN IP: proceso de división de un datagrama IP en fragmentos de menor longitud. HERRAMIENTA DE MONITOREO JFFNMS: Es un sistema de gestión y monitorización de red designando para monitorizar una red IP, puede ser utilizado para monitorizar cualquier dispositivo SNMP, router, switch, servidor, puerto TCP o cualquier elemento siempre que se programe una extensión adecuada a dicho elemento J FFNSM. HIDS: Sistemas de detección de intrusos de Ordenador HUELLA IDENTIFICATIVA: información muy precisa que permite identificar un sistema o una red en concreto. En inglés, fingerprinting. ICMP: Internet Control Message Protocol. IANA: Internet Assigned Numbers Authority Indexación de Di rectorio: Una característica común a los servidores web más populares, que expone el contenido de un directorio cuando no está presente la página de índice. Véase también "Ubicación del archivo predecible". Insuficiente Autenticación: cuando un sitio web permite a un atacante acceder a contenido sensible o a sus funcionalidades sin verificar su identidad. Véase también "Autenticación". Insuficiente Autorización: Cuando un sitio web permite a un atacante acceder a contenido sensible o a sus funcionalidades que deberían requerir mayores restricciones de acceso y control. Véase también "Autorización". 148 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web IDS (Intrusion Detection System): Sistema de detección de Intrusos. Es una herramienta que permite monitorear el comportamiento y el uso que se le da a los recursos en una máquina y detectar si alguien está haciendo algo indebido. IEEE: Tecnología desarrollada por Apple Computer en 1986 que permite transmitir información a alta velocidad. Fue adoptado como estándar en 1995 y es similar al puerto USB. IEEE 802.3 proporciona una LAN estándar desarrollada originalmente por Xerox y ampliada. Define dos categorías: banda base (específica una señal digital) y banda ancha (especifica una señal analógica). IEEE define únicamente una especificación para la categoría de banda ancha. Sin embargo, la restricción de la máxima longitud del cable puede cambiar usando dispositivos de red tales como repetidores o puentes. INTEGRIDAD: los datos reflejen la realidad y que correspondan con lo que debe ser y no ha sido modificadas indebidamente. INTERNET CONTROL MESSAGE PROTOCOL (ICMP): protocolo encargado de realizar el control de flujo de los datagramas IP que circulan por la red. INTERNET PROTOCOL (IP): protocolo para la interconexión de redes. INTEGRIDAD: Los datos reflejan la realidad y que correspondan con lo que debe ser y no ha sido modificadas indebidamente. Java: Lenguaje de programación popular desarrollado por Sun Microsystems (tm). Véase también "ActiveX controls", "Navegador Web", "J avaScript", "Client-Side Scripting". Java Applets: Un applet es un programa escrito en un lenguaje de programación como J ava que puede ser incluido en una página web. Cuando un navegador web tiene habilitado java, y la página contiene applets , el código es ejecutado por la máquina virtual de J ava (J VM). Véase también "Web Browser "," J ava "," ActiveX "," J avaScript "," Client-Side Scripting ". JavaScript: Lenguaje de scripting del lado cliente utilizado por el navegador web, para crear contenido dinámico página web. Véase también "ActiveX", "J ava Applets "," Client-Side Scripting ". LDAP Inyección: Una técnica para la explotación de un sitio web mediante la alteración de backend sentencias LDAP a través de la manipulación de entrada de la aplicación. Al igual que en la metodología de inyección SQL. Véase también "Parámetro Manipulación "," Manipulación de campos de formulario”. 149 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web MAC: Media Access Control Manipulación Cookie: La alteración o modificación de los valores de las cookies del navegador web del cliente, para explotar aspectos de seguridad dentro de una aplicación web. Los atacantes normalmente manipulan los valores de los cookies para autenticarse y realizar fraudes a la aplicación web. Este es un típico ejemplo de establecer por defecto la configuración predeterminada de los navegadores . Véase también "Cookie". Manipulación de Nombre de Archi vo: Una técnica de ataque usada para explotar sitios web mediante la manipulación de los nombres de archivo de URL para provocar errores de aplicación, descubrir el contenido oculto, o visualizar el código fuente de una aplicación. Véase también "Ubicación del archivo predecible". MODEM ADSL: Modula las señales enviadas desde la red local para que puedan transmitirse por la línea ADSL y demodula las señales recibidas por ésta para que los equipos de la LAN puedan interpretarlos. De hecho, existen configuraciones formadas por un módem ADSL y un router que hacen la misma función que un router ADSL. MTU: Maximum Transfer Unit MySQL: Es un sistema de gestión de base de datos relacional y multiusuario ubica las tablas en ficheros diferenciados, es recomendable para desarrollos que necesiten manejar numerosos registros y sesiones simultaneas. NIDS: Sistema de detección de intrusos de Red. NMAP: Programa de código abierto que abierto que sirve para efectuar rastreo de puertos TCP y UDP. Se usa para evaluar la seguridad de sistemas informáticos así como para descubrir servicios o servidores en una red informática. NMS (Network Management Station): estación de red encargada de gestionar varios dispositivos de red. OID (Object ID): identifica de manera única cada objeto representado en la MIB y es una secuencia de números enteros no negativos separados por un punto. OSI: El Modelo OSI es un lineamiento funcional para tareas de comunicaciones y, por consiguiente, no especifica un estándar de comunicación para dichas tareas. OWASP:(The Open Web Application Security Project). 150 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web PDU (Protocol Data Unit): define la estructura de la información que va a ser enviada por la red. PHP: Es Un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Es usado principalmente en interpretación del lado del servidor (server–side scripting) pero actualmente puede ser utilizado desde una interfaz de línea de comandos o en la creación de otros tipos de programas incluyendo aplicaciones con interfaz grafica. PUERTA DE ENLACE: Es La que proporciona salida hacia el exterior a una red local. ROUTER: Es un dispositivo que permite conectar uno o varios equipos o incluso una red de área local (LAN) a Internet a través de una línea telefónica con un servicio ADSL. Revelación de Información: Cuando un sitio web revela datos sensibles, tales como comentarios de los desarrolladores o mensajes de error, lo que ayuda a un atacante a explotar el sistema. Servidor de aplicaciones: Un servidor de software, normalmente a través de HTTP, que tiene la capacidad de ejecutar aplicaciones web dinámicas. También se conoce como middleware. RRDTOOL: Herramienta que trabaja con una base de datos que maneja planificación según Round-Robin. Esta técnica trabaja con una cantidad de datos fija, definida en el momento de crear la base de datos, y un puntero al elemento actual. Su finalidad principal es el tratamiento de datos temporales y datos seriales como temperaturas, transferencias en redes, cargas del procesador, entre otros. SNMP: (Simple Network Managment Protocol): usado para administrar la configuración de dispositivos de red desde una estación de trabajo. SMI (Structure of Management Information): define agrupaciones, nombres, tipos de datos permitidos y la sintaxis para escribir MIB’s. SYN: Bit de control dentro del segmentoTCP. SYN FLOODING: Ataque de denegación de servicio que se basa en no complementar intencionadamente el protocolo de intercambio de TCP. TCP: Transmission Control Protocol. 151 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web TCP/IP: Es la base de Internet, y sirve para enlazar computadoras que utilizan diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras centrales sobre redes de área local (LAN) y área extensa (WAN) TIA: Telecommunications Industry Association. TRANSMISSION CONTROL PROTOCOL (TCP): Protocolo de transporte de la arquitectura de protocolos TCP/IP. TTL: Time To Live UDP: User Datagram Protocol. USER DATAGRAM PROTOCOL (UDP): protocolo de transporte de la arquitectura. USM (User-based Security Model): modelo de seguridad utilizado por SNMPv3 para administrar el envío de mensajes SNMPv3. Ubicación de Archi vo Predecible: Una técnica que se utiliza para acceder a los datos ocultos de un sitio web o a su contenido o funcionalidad, haciendo conjeturas, de forma manual o automáticamente a los los nombres y ubicaciones de los archivos. Los lugares pueden incluir directorios, archivos de configuración de copia de seguridad archivos, archivos temporales, etc Validación de proceso i nsuficiente: cuando un sitio web permite a un atacante para eludir o evadir el control de flujo previsto de un aplicación. VACM (View-based Access Control Model): modelo de control de acceso que permite administrar quien tiene acceso a qué información en la MIB. WINPCAP: Es el mejor motor de captura de paquetes y filtrado de muchas de las herramientas de las herramientas de red comerciales y de código abierto, incluyendo analizadores de protocolos, monitores de red, sistemas de detección de intrusos de red. 152 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web ANEXOS ANEXO 1: OWASP Top 10. Traducido al español: Documento pdf de 22p. Copyright © 2003 – 2010 Fundación OWASP Este documento es publicado bajo la licencia Creative Commons Attribution ShareAlike 3.0. Para cualquier reutilización o distribución, usted debe dejar en claro a otros los términos de la licencia sobre este trabajo. ANEXO 2: Informe que compara las licencias de desarrollo, la tecnología y las fuentes de los diferentes escáneres. ANEXO 3: Informes comparativo de la detección de vulnerabilidades de los distintos escáneres probados: ANEXO 4: Informe que compara las características complementarias de detección de vulnerabilidad en los buscadores probados: ANEXO 5: Informe donde se comparan las características de usabilidad, cobertura y estabilidad de los buscadores probados: 153 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web FUENTES DOCUMENTALES • LUIS GÓMEZ FERNÁNDEZ Y ANA ANDRÉS ÁLVAREZ . Guía de aplicación de la Norma UNE- ISO/IEC 27001 sobre seguridad en sistemas de información para pymes. 2.ª edición Autores: © AENOR (Asociación Española de Normalización y Certificación), 2012 Todos los derechos reservados. AENOR. ISBN: 978-84-8143-7 áÜ - ß Impreso en España Edita: AENOR Maqueta y diseño de cubierta: AENOR Disponible en internet http://site.ebrary.com/lib/unadsp/Doc?id=10637105&ppg=2 Con acceso Noviembre de 2012 • Miguel Colobran Huguet, Josep Maria Arqués Soldevila y Eduard Marco Galindo. Editorial UOC Primera edición en lengua castellana: noviembre 2008. España: Editorial UOC, 2008. p 4. Disponible en Internet < http://site.ebrary.com/lib/unadsp/Doc?id=10638510&ppg=5> con acceso Octubre de 2012 • HOWARD, MICHAEL LEBLANC, DAVID. 19 puntos críticos sobre seguridad de software: fallas de programación y cómo corregirlas. Pág: 305. Editorial: McGraw-Hill Professional Publishing Ubicación: México. Fecha de publicación: 12/2010. Idioma: es pISBN: 9789701058985 • DÍAZ, GABRIEL MUR, FRANCISCO SANCRISTÓBAL, ELIO. Seguridad en las comunicaciones y en la información. Páginas: 473. Editorial: UNED - Universidad Nacional de Educación a Distancia. Ubicación: España. Fecha de publicación: 2004. Idioma: es Número de clasificación de la Biblioteca del Congreso: eISBN: 9788436247893 • JUSTIN, CLARKE. SQL Injection Attacks and Defense. Syngress Publishing, Inc. Elsevier, Inc. 30 Corporate Drive ISBN 13: 978-1-59749-424-3. • CUI-MEI, B. Intrusion Detection Based on One-class SVM and SNMP MIB data. Shandong University of Technology Zibo. China 2009. Fifth International Conference on information Assurance and Security, p. 346-351. • SCHUBA, C; KRSUL, I; KUHN, M; SPAFFORD, E; SUNDARAM, A y ZAMBONI,D. Analysis of Denial of Service Attack on TCP. COAST Laboratory. Departament of Computer Sciences Purdue University, p. 66-82. • TSUNODA, H ; OHTA, K[b]; YAMAMOTO , A; ANSARI, N [d]; WAIZUMI, Y , y NEMOTO, Y . Detecting DRDoS attacks by a simple response packet confirmation mechanism. Computer Comunications Journal. 2008, p. 3299-3307 154 UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas Tecnología e Ingeniería Especialización en Seguridad Informática / Curso de Seguridad en Aplicaciones Web • CARVAJAL, A. Introducción a las técnicas de ataque e investigación Forense, Un enfoque pragmático. Colombia, Agosto de 2007, seg Ed, p. 245 • CRUZ, A y TORRES, P. Sistema para Generar Gráficas a Partir de Logs Tcpdump usando Hadoop. Escuela Superior Politécnica del Litoral. Guayaquil, Ecuador, p. 59 • HIA, H y MIDKIFF, S. Securing SNMP Across Backbone Networks. Bradley Departament of Electrical and Computer Engineering. Virginia Polytechnic Insttitute and State University. Virgini USA, p . 190-198. • ZENG, W y WANG, Y. Design and implementation of Server Monitoring System Based on SNMP. College of Information & Technology, Hebei University of Economics & Business. Information and Network Management Center, North China Electric Power University, p. 680-682 • HATEFI, F y GOLSHANI, F. A new framework for secure network management. Departament of Computer Science and Engineering, Arizona State University, Tempe, USA. 1999, p. 629-636. • BERNSTEIN. J. Daniel. Bernstein's own explanation of SYN Cookies Disponible en Internet. http://cr.yp.to/syncookies.html