blog

El hacking al servidor web es una parte de un universo mayor, conocido comúnmente como “hacking de red”. Para la mayoría de personas, esta es la primera área del hacking donde se está inmerso, en la cual también se incluyen la mayoría de las herramientas más conocidas a través de los diferentes medios.

Obviamente, ciertas herramientas y técnicas deben ser conocidas por todos los profesionales del área. El hacking de red hace uso de algunas de las herramientas de hacking actualmente más populares; como por ejemplo, Nmap, OpenVAS y Metasploit Framework. Por lo tanto para poder hacia técnicas de hacking más avanzadas, se necesita dominar las técnicas y herramientas.

Existe una gran cantidad de recursos y herramientas dedicados a todas estas herramientas, pero las cosas se tornan diferentes cuando se está evaluando específicamente un servidor web. Tradicionalmente el hacking de red sigue una metodología muy sistemática. Se realiza un reconocimiento, escaneo de puertos, escaneo de vulnerabilidades, y explotación mientras se evalúa un servidor web como cualquier servicio de red bajo ataque.

Para iniciar este proceso, se realizan acciones manuales como analizar el archivo de nombre “robots.txt” sobre el servidor web, para entender mejor cuales directorios no se desea sean incluidos en los resultados de los motores de búsqueda. Esto es una potencial hoja de ruta hacia información sensible dentro del servidor web, y es factible hacerlo desde la comodidad de un navegador web. También es factible utilizar herramientas específicas dedicadas a hacking al servidor web como Nikto. Aquí se aúnan sólidas herramientas y técnicas del tradicional hacking de red, lo cual permite tener una mejor perspectiva para realizar hacking al servidor web.

Fuentes:

https://nmap.org/
http://www.openvas.org/
https://github.com/rapid7/metasploit-framework
https://github.com/sullo/nikto
http://robotstxt.org/

Las aplicaciones web pueden ser explotadas atacando vulnerabilidades bien conocidas. Aunque existen otras muchas vulnerabilidades relacionadas al ámbito web, algunas de estas deben ser consideradas como referencia fundamental.

Inyección

Las fallas de inyección se dan cuando datos no fiables del usuario son enviados hacia la aplicación web como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar a la aplicación web, para ejecutar comandos indeseables o acceder de manera no autorizada hacia los datos. La inyección ocurre cuando un atacante alimenta entradas maliciosas dentro de la aplicación web, para luego actuar de una manera insegura. Este es uno de los ataques más antiguos contra las aplicaciones web, pero sigue siendo el rey de las vulnerabilidades porque es ampliamente difundida y muy dañina.

Las vulnerabilidades de inyección pueden surgir en todo tipo de lugares dentro de una aplicación web, los cuales permitan al usuario proporcionan entradas maliciosas. Algunos de los tipos más comunes para ataques de inyección, tienen como objetivo las siguientes funcionalidades.

• Consultas SQL (Structured Query Language)
• Consultas LDAP (Lightweight Directory Access Protocol)
• Consultas de lenguaje de ruta XML (XPATH)
• Comandos OS (Sistema Operativo)

Cuando la entrada del usuario es aceptada por la aplicación web, y procesada sin la limpieza apropiada ocurrirá la inyección. Esto significa el atacante puede influir en como las consultas y comandos de las aplicación web son construidas, y los datos a ser incluidos en los resultados. Este es un tipo de explotación muy poderoso.

Cross Site Scripting (XSS)

Cross Site Scripting (XSS) ocurre cuando la entrada del usuario es aceptada por la aplicación como parte de una petición, y luego es utilizada en la salida de una respuesta sin la codificación de salida implementada para validación y limpieza. XSS permite a los atacantes ejecutar scripts en el navegador de la victima, lo cual puede secuestrar sesiones, actuar como un capturador de teclado, redireccionar al usuario hacia sitios maliciosos, o cualquier cosa requerida por el atacante. Un atacante puede inyectar un script malicioso; frecuentemente JavaScript, pero también podría ser VBScript; el cual es interpretado en el navegador de la victima. Debido al script es parte de la respuesta desde la aplicación web, el navegador de la victima confía en esta y permite su ejecución.

Cross Site Scriping tiene dos categorías principales; reflejado y almacenado. Un XSS reflejado es más difundido en las aplicaciones web y es considerado menos dañino. La razón por la cual es considerado así no es por su capacidad de acción, sino por ser un ataque de un instante o momento, donde el payload enviado en una ataque XSS reflejado es únicamente válido en una petición. Cuando el usuario hace clic, el enlace conteniendo el script malicioso será abierto únicamente por la persona afectada por este ataque. Es generalmente un proporción de 1:1 entre el atacante y la víctima. El atacante puede enviar la misma URL maliciosa hacia millones de victimas potenciales, pero únicamente aquellos haciendo clic en el enlace serán afectados, no existe una conexión entre los usuarios comprometidos.

Un XSS Almacenado es más difícil de encontrar en las aplicaciones web, pero es más dañino porque es persistente entre múltiples peticiones, además puede explotar numerosos usuarios con un ataque. Esto ocurre cuando un atacante es capaz de inyectar un script malicioso dentro de la aplicación, estando disponible para todos los usuarios visitantes. Estará ubicado en la base de datos utilizada por la aplicación web, o cualquier otro mecanismo utilizado para almacenar las entradas. Como un usuario legítimo se hace una petición a la página, el exploit XSS se ejecuta en cada navegador. Esta es una proporción 1:Varios entre el atacante y la victima.

Ambos tipos de XSS tienen los mismos payloads; solo son entregado de diferente manera.

Gestión Inadecuada de la Autenticación y Sesión

Las sesiones son los únicos identificadores asignados a los usuarios después de autenticarse, y tienen muchas vulnerabilidades o ataques asociados con como estos identificadores son utilizados por la aplicación web. Las sesiones son también un componente clave del hacking al usuario web.

Las funciones de la aplicación web relacionadas a la gestión de la autenticación y sesión, no son frecuentemente implementadas de manera correcta, permitiendo a los atacantes comprometer contraseñas, claves, tokes de sesión, o explotar otras fallas en la implementación para asumir la identidad de otros usuarios. Funcionalidades de la aplicación web los cuales también abarca la autenticación es el reajuste de la contraseña, cambio de contraseña, y recuperación de la cuenta, por nombrar algunas.

Una aplicación web utiliza la gestión de sesión para mantener un seguimiento de las peticiones de cada usuario. Sin una gestión de sesión, se debería autenticarse cada vez se realiza una petición. Solo imaginar autenticarse después de cada búsqueda de un producto, luego nuevamente cuando se requiera añadir algo al carro de compras, y luego nuevamente cuando se requiera pagar, y luego nuevamente cuando se requiera ingresar la información sobre el pago. Por esto se creó la gestión de la sesión, de tal manera los usuarios únicamente se autentiquen una sola vez por visita, y la aplicación web deberá recordar los productos añadidos por el usuario al carro de compras. Las malas noticias son la gestión de la autenticación y sesión, son una idea tardía comparada con el Internet original. No era necesario gestión de la autenticación y sesión, cuando no había un carro de compras o pago. La Internet actual como la conocemos dio un giro y ahora utiliza la gestión de la autenticación y sesión.

Cross Site Request Forgery

Un CSRF ocurre cuando un atacante es capaz de enviar una petición maliciosa bien creada hacia un usuario autenticado, el cual incluye los parámetros (variables) necesarios para completar una petición válida a la aplicación web, sin el conocimiento de la victima (usuario).

Esto es similar a un XSS reflejado, en la cual un atacante debe inducir a la victima a realizar alguna acción en la aplicación web. Un script maliciosos podría ser ejecutado en el navegador de la victima, pero un CSRF puede también realizar una petición válida hacia la aplicación web. Algunos resultados de CSRF son cambiar una contraseña, crear un nuevo usuario, crear contenido en la aplicación web mediante un CMS. El atacante conoce exactamente cuales parámetros son necesarios para completar una petición, y la victima está autenticada en la aplicación, la petición se ejecutará como si el usuario lo hubiese hecho conscientemente.

Inadecuada Configuración de Seguridad

Esta categoría de vulnerabilidad específicamente trata con la seguridad (o ausencia de ella) de la pila completa para la aplicación web. Para aquellos no familiarizados con el termino “pila”, esto se refiere al sistema operativo, servidor web, y sistemas gestores de bases de datos, los cuales ejecutan y son accedidas por el código de la aplicación web. Este riesgo es incluso más problemático cuando las practicas para el fortalecimiento de la seguridad no son seguidas de la mejor manera para proteger el servidor web desde un acceso no autorizado. Entre las vulnerabilidades plagando un servidor web se incluyen.

• Software innecesario o desactualizado
• Servicios habilitados innecesarios
• Políticas inseguras de cuentas
• Mensajes de error con verbosidad

Una seguridad efectiva requiere tener definida una configuración segura, y desplegarla para la aplicación, frameworks, servidor de aplicación, servidor web, servidor de base de datos, y sistema operativo. Todas estas configuraciones deben ser definidas, implementadas, y mantenidas, pues muchas no son entregadas por defecto con seguridad. Esto incluye mantener todo el software actualizado, incluyendo librerías de código utilizados por la aplicación.

Fuentes:

https://www.owasp.org/index.php/Injection_Flaws
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
https://www.owasp.org/index.php/Broken_Authentication_and_Session_Manag…
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration

Algunas metodologías de ataque proporcionan el proceso, etapas, herramientas y técnicas a considerar como mejores prácticas. Si se es un profesional en el área, tales actividades son denominadas como pruebas de penetración “Penetration Testing”, en el cual se realizan las mismas actividades de los atacantes maliciosos. Existen dos metodologías para pruebas de penetración ampliamente aceptadas actualmente, Open Source Security Testing Methodology Manual (OSSTMM), y Penetration Testing Execution Standad (PTES).

Open Source Security Testing Methodology Manual (OSSTMM)

OSSTMM fue creado en un proceso de revisión el cual gestó casos de prueba en cinco secciones:

• Controles para información y datos.
• Niveles para concientizar al personal sobre seguridad.
• Niveles de fraude e ingeniería social.
• Redes de computadoras y telecomunicaciones, dispositivos inalámbricos, y dispositivos móviles.
• Controles de acceso para seguridad física, proceso de seguridad y ubicaciones físicas.

OSSTMM mide los detalles técnicos de cada una de estas áreas, y proporciona una directriz sobre aquello lo cual hacer antes, durante y después de una evaluación de seguridad. Se puede encontrar más información sobre OSSTMM en el sitio web del proyecto, detallado en la parte final de presente texto.

Penetration Testing Execution Standard (PTES)

PTES es un estándar el cual proporciona un lenguaje común a seguir por todos los profesionales en pruebas de penetración, y profesionales en evaluaciones de seguridad. PTES proporciona al cliente una referencia sobre la postura en seguridad, de tal manera se este en una mejor posición para percibir los hallazgos obtenidos durante una prueba de penetración. PTES está diseñado como lo mínimo necesario a ser realizado, como parte de una prueba de penetración completa. El estándar contiene muchos niveles diferentes de servicios, los cuales deben ser parte de pruebas de penetración avanzadas. Más información puede ser encontrada en el sitio web del proyecto, detallado en la parte final de presente texto.

Entender las Metodologías Existentes

Debido al detalle de los procesos, estos estándares son bastante desalentadores para un principiante. Ambos abarcan básicamente todos los aspectos posibles sobre una prueba de seguridad, haciendo un gran trabajo. Muchas personas inteligentes y talentosas, han dedicado innumerables horas para crear estos estándares orientados a los profesionales en pruebas de penetración y haking ético. Estos esfuerzos son ciertamente encomiables, pero los principiantes lo perciben como algo abrumador. Por ejemplo; ¿Cómo se podría considerar intentar “Hackear” un dispositivo móvil el cual accede hacia la versión móvil de una aplicación web, cuando no se está cómodo con la manera en la cual las aplicaciones web extraen y utilizan datos desde una base de datos?. Lo necesario es reducir toda esta excelente información de estándares como OSSTMM y PTES, en una metodología más manejable para los principiantes.

Fuentes:

http://www.isecom.org/research/
http://www.pentest-standard.org/index.php/Main_Page

Otro interesante tema para los atacantes maliciosos, es el hecho de las aplicaciones web interactúan con virtualmente todos los sistemas centrales de la infraestructura dentro de una empresa. Es común pensar la aplicación web es sólo código el cual se ejecuta sobre un servidor web, escondido de manera segura en una DMZ, incapaz de causar daños internos graves a la empresa. Existen muchas áreas adicionales sobre una infraestructura de TI, las cuales se necesitan considerar para enfocarse completamente en atacar un sistema, porque el alcance de las aplicaciones web es mucho más amplio a código escrito por un programador. Los siguientes componentes necesitan ser considerados como posibles vectores para ataque.

• Servidor de Base de Datos y Base de Datos: El sistema el cual hospeda la base de datos utilizada por la aplicación web, puede ser vulnerables a ataques los cuales permiten datos sensibles sean creados, leídos actualizados, o borrados.
• Servidor de Archivos: El sistema, frecuentemente una unidad mapeada sobre un servidor, permite la funcionalidad para subir y descargar archivos, el cual puede ser vulnerable a ataques los cuales permiten acceder hacia recursos del servidor por parte de un atacante malicioso.
• Componentes de terceros: Módulos de código, como un sistema para la gestión de contenidos (CMS), son definitivamente un objetivo por ser ampliamente adoptados, y porque existe una amplia documentación sobre estos sistemas.

Fuentes:

https://en.wikipedia.org/wiki/Content_management_system
https://www.acunetix.com/websitesecurity/web-app-security/

Este enfoque sobre los fundamentos del hacking web esta constituido de cuatro fases, las cuales abarcan todas las tareas necesarias a realizar durante un ataque; reconocimiento, escaneo, explotación, y arreglos. Es apropiado presentar y discutir como estas vulnerabilidades y ataques pueden ser mitigadas, es por ello la inclusión de una fase para los arreglos. Como un profesional en pruebas de penetración o hacking ético, se tienen muchas preguntas después de los hechos, sobre como solucionar o arreglar las vulnerabilidades descubiertas. El considerar la inclusión de la fase sobre los arreglos, es un recurso importante para ayudar a responder estas preguntas.

Los Objetivos

Este enfoque fundamental tiene tres objetivos separados con vectores de ataque relacionados; el servidor web, la aplicación web, y el usuario web.

• Servidor Web:La aplicación funcionando sobre un sistema operativo, el cual hospeda la aplicación web. No se habla del hardware tradicional de computadoras, sino de los servicios funcionando en puertos abiertos, los cuales permiten a una aplicación web ser alcanzada por los navegadores web de los usuarios. Este servidor web puede ser vulnerable a intentos de hacking a través de la red, atacando estos servicios para ganar acceso no autorizado hacia la estructura y sistema de archivos del servidor web.
• Aplicación Web: El código fuente actual ejecutándose sobre el servidor web, el cual proporciona la funcionalidad para los usuarios web interactúen con el objetivo más popular para los atacantes maliciosos. La aplicación web puede ser susceptible a una vasta colección de ataques, las cuales intentan realizar acciones no autorizadas dentro de la aplicación web.
• Usuario Web: Los usuarios internos quienes manejan la aplicación web (administradores y programadores), además de los usuarios externos (clientes humanos o proveedores) de la aplicación web, son potenciales objetivos de ataque. Existen vulnerabilidades de Cross-Site Scripting (XSS) o Cross-Site Request Forgery (CSRF) en la aplicación web, los cuales generan muchos dolores de cabeza. Los ataques técnicos de ingeniería social contra los usuarios web, y el basarse sobre vulnerabilidades no existentes en la aplicación web también se incluyen aquí.

Las vulnerabilidades, “exploits”, y “payloads”, son únicos para cada uno de los objetivos, de tal manera se necesitan técnicas y herramientas para atacarlas eficientemente.

Herramientas

Por cada herramienta conocida, probablemente existan otras cinco herramientas las cuales puedan realizar un trabajo similar. Estas herramientas frecuentemente son de fácil utilización para principiantes, pero no se utilizan por esta característica, sino por ser herramientas fundamentales para virtualmente todos los profesionales en pruebas de penetración, quienes lo utilizan regularmente. Algunas de estas herramientas son:

• Zed Attack Proxy: Es la herramienta por excelencia del mundo open source para pruebas de penetración contra aplicaciones web. Entre sus diversas características y funcionalidades incluye un escaner de vulnerabilidades para aplicaciones web.
• Burp Suite: Aunque tiene una versión libre, es una herramienta comercial de pago. Es una poderosa herramienta, con una amplia diversidad de características. Siendo ampliamente aceptada por la comunidad.
• Nmap, Nikto, OpenVAS, Metasploit: Herramientas tradicionales para pruebas de penetración o hackig ético.
• SQLMap, John The Ripper, Social Enginieering Toolkit (SET): Herramientas para roles específicos.

Fuentes:

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
https://cirt.net/Nikto2
http://sqlmap.org/

HTTP es un proceso acordado para interactuar y comunicarse con una aplicación web. Es un protocolo completamente en texto plano, por lo cual no se asume la existencia de seguridad o privacidad cuando se utiliza HTTP. Actualmente HTTP es un protocolo sin estado, de tal manera cada petición del cliente y respuesta de la aplicación web, es un evento nuevo e independiente, sin conocimiento previo de ninguna petición. Sin embargo es crítico la aplicación mantenga un seguimiento de las peticiones del cliente, de tal manera sea factible completar transacciones de varios pasos, como una compra en línea , donde se añaden artículos a un carro de compras, seleccionar el método de pago, e ingresar información del pago.

HTTP sin la utilización de las Cookies requeriría volver a iniciar sesión durante cada uno de los pasos. Esto simplemente no es realista, por lo cual se creó el concepto de sesión, donde la aplicación web realiza un seguimiento de las peticiones después de iniciar sesión. Aunque las sesiones son una excelente manera de incrementar la facilidad de uso de una aplicación web, también proporcionan otro vector de ataque para las aplicaciones web. HTTP no se creó originalmente para manejar este tipo de transacciones web, requiriendo un alto grado de seguridad y privacidad. Se pueden inspeccionar todos los profundos detalles de como opera HTTP, con herramientas como Wireshark o un Proxy HTTP local.

La utilización de HTTP seguro (HTTPS) hace poco por detener los ataques. HTTPS se logra cuando HTTP se superpone sobre el protocolo SSL (Secure Socket Layer) /TLS (Transport Layer Security), lo cual añade SSL/TLS a las peticiones y respuestas HTTP normales. Es más adecuado para garantizar los ataques de hombre en el medio, o ataques de interceptación no sean exitosos; asegura una “llamada privada” entre el navegador web y la aplicación web, opuesto a tener una conversación en una sala llena de gente, donde cualquiera puede escuchar los secretos. Sin embargo, desde la perspectiva del “Hacking”, HTTPS sólo significa se realizará la comunicación con la aplicación web a través de un canal de comunicación cifrado, para convertirlo en una conversación privada. El cifrado bidireccional de HTTPS no evitará los ataques sean procesador por la aplicación web.

Ciclos HTTP

Una de las operaciones fundamentalmente más importantes en cada aplicación web es el ciclo de peticiones hechas por los navegadores de los clientes, y las respuestas devueltas por el servidor web. Es una premisa muy sencilla, la cual ocurre muchas veces al día. Un navegador web envía una petición con parámetros (variables) manejando las entradas del usuario, y el servidor web envía una respuesta, la cual es dirigida por la petición enviada. La aplicación web puede actuar basándose en los valores de los parámetros, por lo cual son los primeros objetivos para los atacantes, insertando valores maliciosos en los parámetros para explotar la aplicación web y el servidor web.

Cabeceras HTTP Relevantes

Cada ciclo HTTP también incluye cabeceras en las peticiones del cliente y las respuestas del servidor, los cuales transmiten detalles sobre la petición y respuesta. Existen muchas de estas cabeceras, pero algunas son las más relevantes para el tema del Hacking.

Las cabeceras más relevantes son aquellas ajustadas por el servidor y enviadas al navegador del cliente como parte del ciclo de respuesta.

• Set-Cookie: Esta cabecera comúnmente proporciona el identificador de sesión (Cookie) hacia el cliente, para asegurar se mantiene la sesión actual del usuario. Si un atacante malicioso puede robar una sesión de usuario (aprovechándose de diversos ataques), estos puede suplantar la identidad del usuario explotado dentro de la aplicación web.
• Content-Lenght: Esta valor de la cabecera es la longitud del cuerpo de la respuesta en bytes. Esta cabecera es útil para los atacantes maliciosos porque se puede mirar por la variación en el número de bytes de la respuesta, para ayudar a descifrar la respuesta de la aplicación hacia la entrada. Esto es especialmente aplicable cuando se realizan ataques por fuerza bruta (adivinar repetidamente).
• Location: Esta cabecera es utilizada cuando una aplicación redirecciona a un usuario hacia una nueva página. Esto es útil para un atacante malicioso porque puede ser utilizada para ayudar a identificar páginas las cuales únicamente son permitidas después de una autenticación exitosa hacia la aplicación web.

Las cabeceras relevantes las cuales son enviadas por el navegador del cliente como parte de una petición web son:

• Cookie: Esta cabecera envía la Cookie (o varias Cookies) devuelta hacia el servidor para mantener la sesión del usuario. Este valor de la cabecera Cookie siempre debe coincidir con el valor de la cabecera “Set-Cookie” la cual fue entregada por el servidor. Esta cabecera es útil para un atacante maliciosos porque puede proporcionar una sesión válida con la aplicación web, la cual puede ser utilizada en ataques contra otros usuarios de la aplicación. Otras Cookies no soy tan atractivas, como la Cookie la cual define el lenguaje deseado.
• Referer: Esta cabecera lista la página web en la cual previamente estuvo el usuario cuando la siguiente petición fue realizada. Se puede pensar en esta cabecera como un almacén para “la última página visitada”. Esto es de ayuda para un atacante malicioso porque este valor puede ser fácilmente cambiado. Por lo tanto, si la aplicación web confía en esta cabecera para un tema de seguridad, puede ser fácilmente evadido con un valor falsificado.

Códigos de Estado HTTP Relevantes

Como las respuestas del servidor web son recibidas por el navegador web, se incluyen códigos de estado para señalar cual es el tipo de respuesta. Existen más de 50 códigos de respuestas HTTP numéricos agrupados en cinco familias, los cuales proporcionan tipos similares de códigos de estado. Conocer la representación de cada tipo de familia de respuesta, permite obtener una comprensión de como la entrada fue procesada por la aplicación web.

• 100: Estas respuestas son puramente informativas desde el servidor web, y usualmente significan están próximas respuestas adicionales desde el servidor web. Estas son raramente vistas en las respuesta de los servidores web modernos, y son usualmente son seguidas después con otro tipo de respuesta.
• 200: Estas respuestas señalan la petición del cliente fue exitosamente aceptada y procesada por el servidor web, además la respuesta ha sido enviada devuelta al navegador del cliente. El código de estado más común es el “200 OK”.
• 300: Estas respuestas son utilizadas para señalar redirección cuando respuestas adicionales deben ser enviadas hacia el cliente. La implementación más común de esto es para redireccionar al navegador de un usuario, hacia una página segura después de autenticarse exitosamente en la aplicación web. Esto podría ser un “302 Redirect” para enviar otra respuesta la cual podría ser un “200 OK”.
• 400: Estas respuestas son utilizadas para señalar un error en la petición desde el cliente. Esto significa el usuario a enviado una petición la cual no puede ser procesada por la aplicación web. Algunos de estos códigos de estado son “401 unauthorized”, “403 Forbidden”, o “404 Not Found”.
• 500: Estas respuestas son utilizadas para señalar un error en el lado del servidor. El código de estado más común utilizados en esta familia son ”500 Internal Server Error” y “503 Service Unavailable”.

Fuentes:

https://www.w3.org/Protocols/rfc2616/rfc2616.html
https://tools.ietf.org/html/rfc5246
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Un servidor web es sólo una parte del software ejecutándose sobre el sistema operativo de un servidor, el cual permite conexiones para acceder hacia la aplicación web. Los servidores web más comunes son Internet Information Services (IIS) sobre un servidor Windows, y Apache HTTP sobre un servidor GNU/Linux. Los servidores tienen una estructura de directorios normal como en cualquier otra computadora, y estos directorios hospedan la aplicación web.

En el caso de una instalación en un servidor web IIS, el directorio por defecto es “C:\Inetpub\wwwroot\” y los recursos vitales para la aplicación están contenidos allí.

GNU/Linux es más variado en su estructura de archivos, aunque la mayoría de aplicaciones web se hospedan en el directorio “/var/www/”. Existen muchos otros directorios en un servidor web GNU/Linux, los cuales son especialmente relevantes para el Hacking.

• /etc/shadow Aquí es donde residen los hashes de las contraseñas para todos los usuarios del sistema.
• /usr/lib/ Este directorio incluye archivos objeto y binarios internos, los cuales no tienen como propósito ser ejecutado por los usuarios, o también guiones shells. Todos los datos para dependencia utilizados por la aplicación también residirán en este directorio. Aunque no hay ejecutables aquí, se puede arruinar el día de alguien borrando todos los archivos de dependencia para una aplicación.
• /var/ Este directorio incluye los archivos para bases de datos, registros de eventos del sistema, y código fuente para la aplicación web por si misma.
• /bin/ Este directorio contiene programas necesarios para el sistema funcione, como las shells, ls, grep, y otros binarios importantes y esenciales. “bin” proviene de “binary” o binario. Muchos comandos estándar del sistema operativo están ubicados aquí, como archivos binarios ejecutables separados.

El servidor web es un objetivo por si mismo para ataques, porque ofrece puertos abiertos, y acceso a versiones potencialmente vulnerables del software para servidor web instalado, versiones vulnerables de otro software instalado, y malas configuraciones del sistema operativos sobre el cual funciona.

Fuentes:

https://www.iis.net/
https://httpd.apache.org/

El termino “aplicación web” tiene diferentes significados para diferentes personas, dependiendo con quien se hable y el contexto. Diferentes personas podrían utilizar términos como aplicación web, sitio web, sistema basado en web, software basado en web, o simplemente Web, y todos pueden tener el mismo significado. La amplia adopción de las aplicaciones web actualmente lo hace difícil para diferenciarla claramente de generaciones previas de sitios web, los cuales sirven páginas HTML no interactivas estáticas. El termino aplicación web se utiliza para cualquier software basado en web el cual realiza acciones (funcionalidad), basada en una entrada del usuario, y usualmente interactúa con sistemas backend. Cuando un usuario interactúa con un sitio web para realizar alguna acción, como registrar un ingreso, comprar, o hacer banca en línea, está utilizando una aplicación web.

Confiar en las aplicaciones web virtualmente para todo, crea una alta superficie de ataque (potenciales puntos de entrada) para los atacantes maliciosos. Basándose en el hecho las aplicaciones web son codificadas por programadores humanos, esto incrementa la probabilidad de errores aunque existan las mejores intenciones. Lo humanos pueden estar aburridos, enojados, cansados, o distraídos, todo lo cual puede introducir agujeros dentro de la aplicación web siendo desarrollada. Esta es la tormenta perfecta para los atacantes maliciosos, de tal manera sea factible explotar estas aplicaciones web, en las cuales se confía tanto.

Se podría asumir una vulnerabilidad en una aplicación web es meramente un error humano, el cual puede ser arreglado rápidamente por un programador. Nada más lejano a la realidad; muchas de las vulnerabilidades no se pueden arreglar fácilmente, porque muchas fallas en las aplicaciones web se remontan a las primeras fases del ciclo de vida para el desarrollo del software. En un esfuerzo por ahorrar detalles sangrientos de las metodologías para la ingeniería de software, simplemente se debe considerar la seguridad es más fácil de manejar (y más efectiva), cuando es considerada inicialmente en las fases de planificación y requerimientos para el desarrollo del software. La seguridad debe continuar como una fuerza impulsadora del proyecto durante todo el camino a través del diseño, construcción, implementación y prueba.

Pero desafortunadamente, la seguridad frecuentemente se trata como una ocurrencia tardía, este tipo de desarrollo deja las aplicaciones web recién creadas, maduren con vulnerabilidades las cuales pueden ser identificadas y explotadas por atacantes maliciosos.

Fuentes:

https://www.owasp.org/index.php/OWASP_Secure_Software_Development_Lifec…

Existe mucho a abarcar antes de empezar a utilizar herramientas específicas, además de como configurar y ejecutarlas para cumplir los requerimientos para la explotación de aplicaciones web. Para tener un sólido fundamento son necesarios muchos años de práctica, estos son principios fundamentales los cuales se necesitan completamente entender y comprender. Estos fundamentos incluyen material relacionado a la mayoría de vulnerabilidades comunes, las cuales continúan plagando la web, aunque incluso algunos de ellos han estado allí por años. Algunas de las vulnerabilidades más dañinas en aplicaciones web, se han diseminado ampliamente, y siguen causando daño muchos años después de haberse descubierto.

Es importante también entender el momento y lugar para el uso ético y apropiado de las herramientas y técnicas las cuales se aprenden. Es importante entonces preparar un entorno aislado para experimentar todo lo concerniente al Hacking Web.

Como la seguridad se ha movido más hacia la delantera de la gestión tecnológica, la seguridad global de los servidores, redes, y servicios ha mejorado enormemente. Esto es en gran parte debido a la mejora de productos como firewalls y sistemas para la detección de intrusiones, los cuales aseguran la capa de red. Sin embargo, estos dispositivos hacen poco protegiendo la aplicación web y los datos utilizados por la aplicación web. Como resultados de esto, los atacantes maliciosos se han desplazado para atacar las aplicaciones web, las cuales interactúan directamente con todos los sistemas internos, como servidores de base de datos, las cuales son protegidos por firewalls u otros dispositivos de red.

En los recientes años se ha puesto más énfasis en el desarrollo seguro de software, y como resultado, las aplicaciones web actuales son más seguras comparadas a las versiones anteriores. Ha habido un fuerte impulso para incluir la seguridad en el ciclo de vida para el desarrollo del software, y para formalizar la especificación de estos requisitos de una manera estandarizada También ha habido un alto incremento en la organización de muchos grupos comunitarios dedicados a la seguridad de aplicaciones, como el Proyecto Abierto de Seguridad para Aplicaciones Web (OWASP). De hecho aún existen aplicaciones web vulnerables por naturaleza, principalmente debido porque los programados están más preocupados en la funcionalidad que en la seguridad, aunque los días de explotación fácil de aparentemente todas las aplicaciones web ha terminado.

Por lo tanto, debido a la seguridad de las aplicaciones web ha mejorado al igual que la red, la superficie de ataque nuevamente se ha desplazado, esta vez para atacar a los usuarios web. Es muy poco lo cual los administradores de la red o programadores web pueden hacer para proteger a los usuarios web de estos ataques usuario sobre usuario, los cuales prevalecen más en la actualidad. Imaginar la alegría de un atacante malicioso, pues ahora puede apuntar a un usuario desprevenido, sin deber preocuparse por sistemas para la detección de intrusiones, o registros para los eventos de la aplicación web, y firewalls para aplicaciones web. Los atacantes maliciosos ahora se enfocan directamente en los usuarios web, eludiendo de manera efectiva todas y cada una de las salvaguardas desarrolladas en los últimos años, tanto para redes cuanto para aplicaciones web.

Sin embargo, aún existen muchos ataques viables dirigidos contra servidores web y aplicaciones web, además de los ataques a los usuarios web. Lo importante en comprender como todos estos ataques explotan un servidor web, aplicación web o usuario web, conocimiento como se realizan estos ataques y las herramientas a utilizar.

Fuentes:

https://www.owasp.org/index.php/Main_Page

Es suficientemente bueno si se está en la misma red local del sistema objetivo de evaluación, pero ¿Si el sistema objetivo de evaluación es remoto?. Si se tiene una sesión con Meterpreter obtenida a través de un código de explotación “exploit”, se puede proceder a registrar o grabar remotamente el tráfico de la red correspondiente al sistema objetivo de evaluación.

La siguiente demostración inicia con una sesión de Meterpreter activa obtenida mediante algún código de explotación. Como se puede visualizar la sesión obtenida tiene asignado el número 1.

Dado el hecho de no tener los máximos privilegios en el sistema objetivo, se procede a obtenerlos utilizado el módulo de nombre “exploit/windows/local/bypassuac_injection”.

Al ejecutar el script en Meterpreter de nombre “packetrecorder”; el cual permite realizar algunas afinaciones para capturar paquetes de red; se muestra un mensaje el cual versa sobre el script se considera obsoleto y se debe utilizar el módulo de post-explotación de nombre “post/windows/manage/rpcapd_start”

meterpreter > run packetrecorder

Se ejecuta packetrecorder con la opción “-li” para listar las interfaces factibles de ser utilizadas para la captura. El mensaje de error expuesto al ejecutar el comando indica la imposibilidad de obtener esta información.

Dado el hecho la primera interfaz es localhost, y el objetivo de evaluación tiene dos interfaces de red configuradas, se procede a definir la opción “-i” con el número dos para iniciar la captura de tráfico en la interfaz adecuada.

meterpreter > run packetrecorder -i 2

El tráfico capturado se registra en un directorio dentro de la ruta “/root/.msf4/logs/scripts/packetrecorder/”.

Si desde el objetivo de evaluación se realiza una conexión hacia un servidor FTP externo; por defecto el protocolo FTP transmite todo el tráfico en texto plano; todas las credenciales podrán ser capturadas.

Se utiliza la herramienta Wireshark, para abrir el archivo conteniendo el tráfico remoto capturado desde el host objetivo. Donde es factible visualizar las credenciales utilizadas para conectarse hacia el servidor FTP.

Fuentes:

https://www.offensive-security.com/metasploit-unleashed/packet-sniffing/
https://www.rapid7.com/db/modules/post/windows/manage/rpcapd_start