A04:2021 - Insecure design - Information disclosure

Introducción

La divulgación de información es una vulnerabilidad de seguridad, cuya criticidad dependerá de lo sensible que sea la información obtenida. 

Se produce cuando una aplicación web expone inadvertidamente datos sensibles o confidenciales a usuarios no autorizados. Esta vulnerabilidad puede manifestarse de diversas formas, incluyendo la revelación de detalles técnicos del sistema, información de configuración, datos de usuarios, o incluso fragmentos de código fuente. 

Esta exposición no solo compromete la integridad y confidencialidad de la aplicación, sino que también puede proporcionar a potenciales atacantes información valiosa para planificar y ejecutar ataques más sofisticados contra el sistema.

Impacto

El impacto de la divulgación de información en la seguridad de una aplicación web puede ser significativo:

• Exposición de datos sensibles: Puede revelar información confidencial como contraseñas, datos de usuarios o detalles de la infraestructura.

• Facilitación de ataques más sofisticados: Los atacantes pueden utilizar la información obtenida para planificar y ejecutar ataques más precisos y efectivos.

• Pérdida de confianza: Si los usuarios descubren que la aplicación es vulnerable, puede resultar en una pérdida de confianza y daño a la reputación de la organización.

• Incumplimiento normativo: Dependiendo de la naturaleza de la información divulgada, puede llevar a violaciones de normativas de privacidad y seguridad de datos.

• Compromiso de la integridad del sistema: La información revelada puede ser utilizada para comprometer la integridad y seguridad general del sistema.

Estos impactos subrayan la importancia de identificar y mitigar las vulnerabilidades de divulgación de información en aplicaciones web.

Ejemplos Prácticos

A continuación, se presentan algunos ejemplos prácticos de vulnerabilidades de divulgación de información en aplicaciones web. Estos casos ilustran cómo la información sensible puede ser expuesta inadvertidamente, proporcionando a los atacantes datos valiosos sobre la infraestructura y el funcionamiento interno de la aplicación.

Cada ejemplo incluye una descripción del escenario, el impacto potencial, y las medidas de mitigación recomendadas. Es importante comprender estos casos para mejorar la seguridad de las aplicaciones web y proteger la información sensible de la organización.

1. Mensajes de Error

Este caso específico se refiere a una técnica deliberada de provocar errores en una página web con un propósito estratégico. El objetivo principal de esta práctica es inducir al sistema a revelar información crucial sobre la versión del software que está siendo utilizado. 

Esta táctica, aunque aparentemente simple, puede proporcionar a un atacante datos valiosos sobre la infraestructura tecnológica subyacente de la aplicación web. Al forzar intencionalmente estos errores, un atacante busca explotar las respuestas del sistema para obtener detalles técnicos que normalmente estarían ocultos. 

Esta información puede incluir no solo la versión exacta del software, sino también otros detalles como el tipo de servidor web, el sistema operativo subyacente, o incluso fragmentos de código fuente. Todos estos elementos pueden ser utilizados posteriormente para planificar ataques más sofisticados y dirigidos.

Resumen

• Se provoca un error deliberadamente en la aplicación web.

• El mensaje de error generado revela cierta información. La información obtenida puede incluir versiones de software, rutas de archivos, o configuraciones del servidor.

Ejemplo

Existen múltiples formas de generar un error en una página web. En este caso, se va a explicar uno muy común que ocurre cuando a un parámetro que se espera que reciba un valor numérico INTEGER, se le envía un valor no numérico.

https://<victim_web>/product?productId=2

En este caso, se alterará el valor del parámetro productId para enviar un valor no numérico y así forzar un error:

https://<victim_web>/product?productId="

En la imagen, se puede observar que, de esta manera, es posible forzar un error y obtener la versión del servidor web del que se hace uso.

Mitigación

Para prevenir este tipo de vulnerabilidad, se recomienda:

• Configurar adecuadamente los mensajes de error para que no revelen información sensible

• Implementar manejo de errores personalizado que oculte detalles técnicos

• Mantener el software y los sistemas actualizados para reducir las vulnerabilidades conocidas

• Realizar pruebas de seguridad regulares para identificar y corregir posibles fugas de información

2. Archivos de instalación por defecto / Debug files

En este escenario, el objetivo es identificar y localizar archivos de instalación que se han dejado en su configuración predeterminada. Estos archivos pueden proporcionar información valiosa y potencialmente sensible acerca de las versiones específicas del software utilizado en la infraestructura del sistema. 

La presencia de estos archivos no solo puede revelar detalles técnicos cruciales, sino que también puede exponer vulnerabilidades conocidas asociadas con versiones particulares del software, lo que podría ser explotado por atacantes malintencionados para comprometer la seguridad del sistema.

Resumen

• Se ejecuta una fase de reconocimiento, donde se buscan archivos y directorios mediante archivos como sitemap.xml o robots.txt, además de herramientas de crawling, o enumeración de directorios

• EL archivo de depuración o el generado durante la instalación contiene cierta información sensible. La información obtenida puede incluir versiones de software, rutas de archivos, configuraciones del servidor, claves y tokens en texto claro

Ejemplo

En este caso, mediante la herramienta de enumeración de directorios dirsearch y el diccionario big.txt de SecList, ha sido posible enumerar el siguiente archivo.

dirsearch -u https://victim_web -w ~/Tools/SecLists/Discovery/Web-Content/big.txt

El archivo phpinfo.php es un script de diagnóstico comúnmente utilizado en servidores web con PHP. Este archivo, cuando se accede, muestra información detallada sobre la configuración del servidor PHP, incluyendo versiones de software, extensiones habilitadas y variables del sistema.

En este caso, se puede observar que, entre la información contenida en este archivo, se encuentra múltiple información sensible, a la cual es posible acceder sin una autenticación previa.

Tal y como podemos observar, dejar este archivo accesible en un entorno de producción puede representar un riesgo de seguridad significativo, ya que expone información sensible que podría ser aprovechada por atacantes malintencionados.

Mitigación

Para prevenir los riesgos asociados con archivos de instalación por defecto o de debugging se recomienda:

• Eliminar o restringir el acceso a archivos de diagnóstico en entornos de producción

• Implementar controles de acceso robustos para archivos sensibles

• Utilizar firewalls de aplicaciones web (WAF) para bloquear el acceso a archivos potencialmente peligrosos

• Realizar auditorías regulares de seguridad para identificar y eliminar archivos innecesarios

• Configurar correctamente los permisos de archivos y directorios en el servidor web

• Utilizar herramientas de escaneo de vulnerabilidades para detectar archivos expuestos

• Implementar políticas de seguridad que prohíban la presencia de archivos de debugging en producción

• Educar a los desarrolladores sobre los riesgos de dejar archivos de diagnóstico accesibles

3. Archivos Ocultos

En este escenario, el objetivo es identificar y localizar archivos ocultos que puedan contener información sensible o potencialmente peligrosa para la organización. Estos archivos, a menudo inadvertidamente expuestos, pueden representar un riesgo significativo para la seguridad de la empresa si son descubiertos y explotados por actores malintencionados. 

Aunque las técnicas de crawling y enumeración de directorios, mencionadas en ejemplos anteriores, podrían ser aplicables, este caso particular se centrará en métodos alternativos y más sutiles para descubrir estos recursos ocultos. Estas estrategias alternativas pueden incluir el análisis de respuestas del servidor, la inspección de código fuente, y la explotación de patrones de nomenclatura comunes, entre otros enfoques más sofisticados y menos intrusivos.

Resumen

• Se ejecuta una fase de reconocimiento, donde se buscan archivos y directorios mediante archivos como sitemap.xml o robots.txt, además de herramientas de crawling, o enumeración de directorios.

• Los archivos encontrados mediante estas técnicas pueden ir desde documentación interna, datos económicos, credenciales de usuarios, código fuente, etc.

Ejemplo

Para este ejemplo, se obtendrá información acerca de la estructura de archivos del aplicativo web, accediendo al archivo robots.txt.

El archivo robots.txt es un archivo de texto utilizado en sitios web para indicar a los robots de los motores de búsqueda qué páginas o secciones del sitio deben o no ser rastreadas e indexadas.

https://victim_web/robots.txt

Tras acceder al directorio de /backup, se puede observar en este ejemplo como hay un archivo con código fuente de la aplicación.

En este caso, se puede observar que en el archivo de backup se encuentra código fuente de la aplicación con información sensible como la cadena de conexión a una base de datos, donde se encuentra la contraseña. Además de una consulta a la base de datos donde se puede intuir una inyección SQL.

Mitigación

Para prevenir los riesgos asociados con archivos de instalación por defecto o de debugging se recomienda:

• Identificar todos los archivos que se muestren desde la web

• Eliminar o restringir el acceso a archivos con información crítica, como, por ejemplo, código fuente, credenciales…

• Implementar controles de acceso robustos para archivos sensibles

• Utilizar firewalls de aplicaciones web (WAF) para bloquear el acceso a archivos potencialmente peligrosos

• Realizar auditorías regulares de seguridad para identificar y eliminar archivos innecesarios

• Configurar correctamente los permisos de archivos y directorios en el servidor web

• Utilizar herramientas de escaneo de vulnerabilidades para detectar archivos expuestos

Dimas Pastor, Analista de ciberseguridad en Grupo Zerolynx.

A03:2021 – Injection

Las inyecciones son un tipo de vulnerabilidad consistente en la realización de un envío de datos no confiables mediante una petición o consulta a un intérprete, por parte de un atacante, causando una disrupción en el flujo de ejecución o el comportamiento previsto inicialmente para la aplicación. 

De esta forma, se pueden llegar a realizar acciones que van desde la extracción de información adicional sobre el sistema atacado, hasta el robo de una sesión de usuario o incluso la ejecución remota de comandos y la posterior toma de control del propio servidor web donde se aloja la aplicación.

Las inyecciones se han catalogado como las más críticas y constantes a lo largo de las sucesivas ediciones de los OWASP Top 10, debido a que pueden llegar a derivar en el control absoluto de la máquina objetivo. De hecho, han estado en el número uno de la lista durante todas las ediciones hasta la del 2021, donde bajó a la tercera posición.

Tipos de inyecciones

Como depende en gran medida, del intérprete utilizado, del lenguaje empleado o del sistema de almacenamiento empleado en el backend del servidor, hay también un importante número de inyecciones diferentes que se pueden dar, como son:

Inyecciones SQL (SQLi - SQL injections) 

Permite la manipulación no deseada de los datos existentes en bases de datos no relacionales, modificando o alterando la información de los datos, o bien permitiendo la evasión de los sistemas de autenticación y/o autorizaciones existentes. 

Contrariamente a lo que gente no experta suele opinar, este tipo de inyecciones no son una “cosa de los 90”. Hoy en día se siguen empleando inyecciones de tipo SQL (Structured Query Language), empleados en consultas o modificaciones de bases de datos relacionales. Un ejemplo claro ha sido incluso muchas veces, como se ha demostrado en una de las vulnerabilidades detectadas en el sistema TSA (Transportation Security Administration), que ha permitido ignorar la seguridad de 77 aerolíneas que usaban un sistema determinado para llegar a tener privilegios de administración con una de las inyecciones de este tipo más triviales. 

Inyecciones NoSQL (NoSQLi -NoSQL injections)

Con la aparición de las bases de datos no relacionales, como MongoDB (donde los datos quedan almacenados en BSON, un formato de datos similar a JSON), CouchDB, o Redis, el tipo de inyección cambia para ajustarse a este tipo de información, pero el resultado puede ser igual de devastador. 

Inyecciones de comandos (CI- Command Injections)

En este caso, lo que se “inyectan” son comandos no deseados en el sistema operativo subyacente. 

Inyecciones LDAP (LDAPi - Ligthweight Directory Access Protocol injections)

En este caso, la explotación de la inyección viene dada por la manipulación no deseada de consultas LDAP o Protocolo Ligero de Acceso a Directorios, para acceder o manipular recursos de red o la autenticación de usuarios que empleen este tipo de protocolo en la aplicación web. 

Inyecciones XML (XMLi - XML injection, XXE - XML eXternal Entity injection)

En este caso se manipulan las peticiones XML realizadas al servidor para incluir entidades no controladas, incluso entidades externas cargadas desde la propia máquina atacante (en el caso de XXE), para poder leer ficheros internos o incluso realizar ejecución remota de comandos. 

Inyecciones XPath

En este caso se abusará de la manipulación de consultas XPath (lenguaje XML Path), para el acceso o modificación de datos, o atributos en documentos XML. 

Uso de secuencias de comandos en sitios cruzados (XSS - CrossSite Scripting)

En este tipo de inyecciones, inicialmente se consideran inyecciones en el lado “cliente”, por afectar principalmente a la relación entra las aplicaciones web y lo que acontece en el navegador de los usuarios. 

Pero este hecho, que inicialmente podría considerarse como no especialmente relevante, no lo es tal, si se considera que una XSS de carácter reflejado puede llevar a ataques de robo de identidad o robo de sesiones de usuario o, en el caso de los XSS almacenados, llevar a comprometer una infraestructura completa y no solo el defacement o desfiguración del aplicativo web. 

Además, en combinación con otro tipo de ataques (el mencionado SQLi, u otros como SSRF-Server-Side Request Forgery, CSRF o XSRF-Cross-Site Request Forgery…) pueden ser especialmente peligrosos. 

Destacan por la utilización de JavaScript (o lenguajes de scripting similares empleados en el cliente, como vbscript, aunque menos frecuente hoy en día) y HTML (HTMLi o HTML Injection). 

Inyecciones de Plantillas del lado servidor (SSTI - Server-Side Template Injection)

Con la aparición de nuevos frameworks en servidores web como PHP, Spring en Java, Flask/Django en Python, Express (Node.js), a los backends tradicionales, surgieron ciertos motores populares de procesamiento de plantillas en el servidor web, como Jinja o Jinja2 (Python), Twig (PHP), Pug/Jade (Node.js), EJS (JavaScript), Freemarker (Java), etc. 

Y con ellos, nuevos tipos de inyección abusando de estas plantillas existentes, donde, mediante su adecuada manipulación e inyección de comandos específicos, un atacante podría llegar a interactuar con todo el entorno del servidor, incluidos archivos o servicios existentes, o incluso el propio sistema operativo. 

ORM Injection (Object-Relational Mapping Injection)

Si bien el uso de una capa de abstracción empleando Orientación a Objetos es muy deseable para evitar precisamente tipos de inyección SQL o NoSQL, evitando la construcción y manipulación directa de cadenas SQL, una mala implementación de ORM puede llevar al descubrimiento de información de la base de datos subyacente, mediante el empleo de consultas dinámicas manipulando la lógica de este tipo de objetos, de forma análoga a como se haría con un SQLi. 

Se han descubierto en este sentido varias formas de inyección en ORMs populares como SQLAlchemy (para Python) o Hibernate (para Java). 

Inyecciones de código (Code Injection)

El abuso de este tipo de inyecciones depende exclusivamente del tipo de lenguaje empleado para la ejecución dinámica de código en la aplicación web. Por ejemplo, PHP (con funciones como eval()) o Python. 

Inyecciones de formato de cadena (Format String Injection)

Aquí la inyección vendría dada en las funciones de formato de cadena empleadas para la manipulación de datos de entrada de usuario, que permitirían la divulgación de información no deseada en el lado servidor, o la ejecución incluso de código arbitrario. 

Inyecciones de expresiones regulares (Regex Injection)

La explotación de este tipo de inyecciones viene generalmente dada por la laxitud en la implementación de ciertas expresiones regulares empleadas en el sistema, permitiendo su manipulación para realizar ataques de obtención de información adicional, evasión de filtros, o incluso ataques de Denegación de Servicio (DoS).

Inyecciones de cabecera HTTP (HTTP Header Injection)

La inyección en este caso viene dada en la propia cabecera HTTP de las peticiones enviadas al servidor, permitiendo otro tipo de ataques como el envenenamiento de caché (Cache Poisoning) o la manipulación de cookies empleadas en la sesión de la aplicación. 

De hecho, es habitual emplear otro tipo de inyecciones mencionadas dentro también de las cabeceras. 

¿Por qué ocurren las inyecciones?

La mayoría de las inyecciones ocurren por un motivo común, independientemente del lenguaje empleado en el backend, de la infraestructura desplegada o de la configuración del servidor, que motivarán la elección del uso de unos tipos de inyección u otras. 

El principal motivo es la falta de controles para la validación de los datos de entrada del usuario, así como también en la salida (o el procesamiento entre capas), de la información hacia el servidor.

No se debe olvidar que las peticiones iniciales pueden ser interceptadas tras pasar los filtros en el lado cliente, y manipuladas para afectar igualmente al servidor, siempre y cuando no se hayan establecido controles y validaciones especialmente en este lado.

Tampoco se deben concebir este tipo de ataques como ataques que afectan únicamente a aplicaciones web, siendo muchas de estas inyecciones descritas posibles (especialmente SQLi) en arquitecturas cliente-servidor no web (incluso donde el cliente y el servidor se encuentran en la misma máquina).

Medidas de mitigación

Como recomendaciones principales, se dan las siguientes:

• Se debe establecer una política de confianza cero en todo lo que respecta a los inputs que una aplicación puede recibir, estableciendo una sanitización adecuada, de tal forma que se escapen caracteres no deseados (evitando en la medida de lo posible el uso de listas negras y sustituyéndolas por las funcionalidades de seguridad en cuanto a escape de caracteres dependientes de las tecnologías empleadas). 

• Se recomienda adicionalmente, el empleo de consultas parametrizadas en el caso de acceso a servidores de bases de datos, siguiendo las recomendaciones de seguridad de cada proveedor de bases de datos, así como de la tecnología empleada. 

• Se deben realizar las debidas abstracciones de bases de datos para evitar la construcción directa de consultas SQL mediante un uso correcto de ORM (Object-Relational Mapping). 

• Se deben implementar, con independencia de lo anteriormente citado, un correcto control de acceso, limitando los permisos en el servidor, tanto del servicio web en ejecución, como en el acceso a la base de datos, o a los directorios específicos donde se está ejecutando la aplicación, de tal manera que se limite severamente el acceso a otras áreas del servidor. 

De esta manera, mediante un establecimiento del “principio de mínimo privilegio”, se restringirán al máximo los pasos posteriores de un posible atacante, en caso de haber obtenido éxito en la explotación de cualquiera de estos ataques. 

• Recurrir a capas de protección adicionales, como son la ejecución de un WAF (Web Application Firewall), con unas reglas bien definidas para parar este tipo de ataques, o bloquear posibles automatizaciones en intentos de inyección. 

Eso sí, sin confiar única y ciegamente en este tipo de sistemas, que también pueden ser evadidos. 

Roberto Trigo, Analista de Ciberseguridad en Zerolynx.