Az - Function Apps
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azure Functions es una solución sin servidor que te permite escribir menos código, mantener menos infraestructura y ahorrar en costos. En lugar de preocuparte por desplegar y mantener servidores, la infraestructura en la nube proporciona todos los recursos actualizados necesarios para mantener tus aplicaciones en funcionamiento.
En el portal de Azure, se facilita la integración entre Azure Functions y Azure API Management, permitiendo que los puntos finales de función activados por HTTP se expongan como APIs REST. Las APIs expuestas de esta manera se describen utilizando una definición OpenAPI, proporcionando una interfaz estándar y agnóstica al lenguaje para APIs RESTful.
El plan de Consumo Flex ofrece escalado dinámico y basado en eventos con opciones de computación flexibles. Agrega o elimina automáticamente instancias de función según la demanda, asegurando un uso eficiente de los recursos y rentabilidad a través de un modelo de pago por uso. Este plan admite redes virtuales para una mayor seguridad y te permite reducir los inicios en frío al preaprovisionar instancias. Es ideal para aplicaciones que experimentan cargas de trabajo variables y requieren escalado rápido sin necesidad de soporte de contenedores.
El plan de Consumo tradicional para Azure Functions es la opción de alojamiento sin servidor predeterminada, donde solo pagas por los recursos de computación cuando tus funciones están en ejecución. Escala automáticamente según el número de eventos entrantes, lo que lo hace altamente rentable para aplicaciones con cargas de trabajo intermitentes o impredecibles. Aunque no admite despliegues de contenedores, incluye optimizaciones para reducir los tiempos de inicio en frío y es adecuado para una amplia gama de aplicaciones sin servidor que requieren escalado automático sin la sobrecarga de gestionar infraestructura.
El plan Premium para Azure Functions está diseñado para aplicaciones que necesitan un rendimiento consistente y características avanzadas. Escala automáticamente según la demanda utilizando trabajadores precalentados, eliminando los inicios en frío y asegurando que las funciones se ejecuten puntualmente incluso después de períodos de inactividad. Este plan ofrece instancias más potentes, tiempos de ejecución extendidos y admite conectividad de red virtual. Además, permite el uso de imágenes de Linux personalizadas, lo que lo hace adecuado para aplicaciones críticas que requieren alto rendimiento y mayor control sobre los recursos.
El plan Dedicado, también conocido como el plan de App Service, ejecuta tus funciones en máquinas virtuales dedicadas dentro de un entorno de App Service. Este plan proporciona facturación predecible y permite el escalado manual o automático de instancias, lo que lo hace ideal para escenarios de larga duración donde las Funciones Duraderas no son adecuadas. Admite la ejecución de múltiples aplicaciones web y de función en el mismo plan, ofrece tamaños de computación más grandes y asegura un aislamiento completo de computación y acceso seguro a la red a través de Entornos de App Service (ASE). Esta opción es la mejor para aplicaciones que necesitan asignación de recursos consistente y personalización extensa.
Container Apps te permiten desplegar aplicaciones de función en contenedores dentro de un entorno completamente gestionado alojado por Azure Container Apps. Esta opción es perfecta para construir aplicaciones sin servidor impulsadas por eventos que se ejecutan junto a otros microservicios, APIs y flujos de trabajo. Admite empaquetar bibliotecas personalizadas con tu código de función, migrar aplicaciones heredadas a microservicios nativos de la nube y aprovechar la potencia de procesamiento de alto rendimiento con recursos de GPU. Container Apps simplifican el despliegue al eliminar la necesidad de gestionar clústeres de Kubernetes, lo que las hace ideales para desarrolladores que buscan flexibilidad y escalabilidad en un entorno de contenedores.
Al crear una nueva Function App no contenedorizada (pero proporcionando el código para ejecutar), el código y otros datos relacionados con la función se almacenarán en una cuenta de Almacenamiento. Por defecto, la consola web creará una nueva por función para almacenar el código.
Además, cada vez que se necesite ejecutar una nueva instancia de la aplicación, el código de la aplicación se recogerá de aquí y se ejecutará.
Esto es muy interesante desde la perspectiva de un atacante, ya que el acceso de escritura sobre este bucket permitirá a un atacante comprometer el código y escalar privilegios a las identidades gestionadas dentro de la Function App.
Es posible dar acceso a una función a todo Internet sin requerir ninguna autenticación o dar acceso basado en IAM.
También es posible dar o restringir el acceso a la Function App desde Internet, dando acceso a una red interna (VPC) a la Function App.
Esto es muy interesante desde la perspectiva de un atacante, ya que podría ser posible pivotar a redes internas desde una función Lambda vulnerable expuesta a Internet.
Es posible configurar variables de entorno dentro de una aplicación. Además, por defecto se crean las variables de entorno AzureWebJobsStorage y WEBSITE_CONTENTAZUREFILECONNECTIONSTRING (entre otras). Estas son especialmente interesantes porque contienen la clave de la cuenta para controlar con PERMISOS COMPLETOS la cuenta de almacenamiento que contiene los datos de la aplicación.
Dentro del sandbox, el código fuente se encuentra en /home/site/wwwroot en el archivo function_app.py (si se utiliza Python) y el usuario que ejecuta el código es app (sin permisos de sudo).
Además, la Function App puede tener ciertos puntos finales que requieren un cierto nivel de autenticación, como "admin" o "anónimo". Un atacante podría intentar acceder a los puntos finales permitidos anónimamente para eludir las restricciones y obtener acceso a datos o funcionalidades sensibles.
Ten en cuenta que no hay permisos RBAC para dar acceso a los usuarios para invocar las funciones. La invocación de funciones depende del trigger seleccionado cuando se creó y si se seleccionó un Trigger HTTP, podría ser necesario usar una clave de acceso.
Al crear un punto final dentro de una función utilizando un trigger HTTP, es posible indicar el nivel de autorización de clave de acceso necesario para activar la función. Hay tres opciones disponibles:
ANÓNIMO: Todos pueden acceder a la función a través de la URL.
FUNCIÓN: El punto final solo es accesible para usuarios que utilizan una clave de función, host o maestra.
ADMIN: El punto final solo es accesible para usuarios con una clave maestra.
Tipo de claves:
Claves de Función: Las claves de función pueden ser predeterminadas o definidas por el usuario y están diseñadas para otorgar acceso exclusivamente a puntos finales de función específicos dentro de una Function App. Esto permite un control de seguridad más detallado, asegurando que solo los usuarios o servicios autorizados puedan invocar funciones particulares sin exponer toda la aplicación.
Claves de Host: Las claves de host, que también pueden ser predeterminadas o definidas por el usuario, proporcionan acceso a todos los puntos finales de función dentro de una Function App. Esto es útil cuando se necesita acceder a múltiples funciones utilizando una sola clave, simplificando la gestión y reduciendo el número de claves que deben distribuirse o almacenarse de forma segura.
Clave Maestra: La clave maestra (_master) sirve como una clave administrativa que ofrece permisos elevados, incluyendo acceso a las APIs REST de una Function App. Esta clave no puede ser revocada y debe ser manejada con el máximo cuidado. Es crucial no compartir la clave maestra con terceros o incluirla en aplicaciones cliente nativas para prevenir el acceso administrativo no autorizado.
Al establecer la autenticación de una función en ADMIN (y no ANÓNIMO o FUNCIÓN), es necesario usar esta clave.
Claves del Sistema: Las claves del sistema son gestionadas por extensiones específicas y son necesarias para acceder a los puntos finales de webhook utilizados por componentes internos. Ejemplos incluyen el trigger de Event Grid y las Funciones Duraderas, que utilizan claves del sistema para interactuar de manera segura con sus respectivas APIs. Las claves del sistema pueden ser regeneradas a través del Portal de Azure o APIs de claves para mantener la seguridad.
Ejemplo para acceder a un punto final de API de función utilizando una clave:
https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key>
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
