<\/a>Introducci\u00f3n<\/h2>\nLa computaci\u00f3n sin servidor es un modelo de nube en el que proveedores como AWS (Lambda), Azure (Functions) y Google Cloud (Functions) gestionan la infraestructura, el escalado y el mantenimiento. Este modelo permite a las organizaciones y a sus desarrolladores centrarse \u00fanicamente en el c\u00f3digo, mientras que el proveedor de la nube se encarga de las tareas de backend.<\/p>\n
Al funcionar por eventos, las funciones sin servidor se ejecutan en respuesta a desencadenantes como solicitudes HTTP, cambios en la base de datos o eventos programados. El escalado automatizado del servicio de funciones ajusta los recursos a la demanda, garantizando la rentabilidad al cobrar el proveedor de la nube \u00fanicamente por el tiempo de ejecuci\u00f3n y los recursos utilizados.<\/p>\n
Si bien la computaci\u00f3n sin servidor simplifica el desarrollo y la implementaci\u00f3n, es importante comprender los riesgos potenciales asociados con estos servicios. Algunos de esos riesgos surgen del hecho de que los desarrolladores pueden asignar identidades a las funciones sin servidor, y esas identidades se presentan como conjuntos de credenciales que son accesibles al c\u00f3digo que se ejecuta dentro de la funci\u00f3n. Estas credenciales se utilizan para la autenticaci\u00f3n y autorizaci\u00f3n para realizar operaciones en la nube.<\/p>\n
Estas credenciales se aplican con un conjunto de permisos que dictan su uso. Seg\u00fan los permisos asociados a la identidad vinculada a la funci\u00f3n, esas credenciales pueden permitir el acceso a los recursos de la nube y a datos confidenciales.<\/p>\n
Los atacantes apuntan a las funciones sin servidor por estas razones:<\/p>\n
\n- Muchas veces, las funciones sin servidor pueden ser vulnerables a ataques de ejecuci\u00f3n remota de c\u00f3digo (RCE) o de falsificaci\u00f3n de peticiones del lado del servidor (SSRF) debido a pr\u00e1cticas de desarrollo inseguras.<\/li>\n
- Las funciones sin servidor suelen estar expuestas p\u00fablicamente (ya sea por dise\u00f1o o debido a una mala configuraci\u00f3n) o procesan entradas de fuentes externas.<\/li>\n
- Los atacantes pueden explotar los tokens de autenticaci\u00f3n de funciones sin servidor para obtener acceso no autorizado de lectura\/escritura que podr\u00eda poner en peligro infraestructuras y datos cr\u00edticos.<\/li>\n<\/ul>\n
Cuando se utilizan funciones sin servidor, es importante tener en cuenta los riesgos que se producen cuando los desarrolladores de aplicaciones implementan c\u00f3digo inseguro en funciones en la nube, y comprender las amenazas que se dirigen a estas funciones.<\/p>\n
<\/a>C\u00f3mo funciona la autenticaci\u00f3n sin servidor en las principales plataformas en la nube<\/h2>\nMediante el enfoque sin servidor, las aplicaciones se implementan con la ejecuci\u00f3n de funciones bajo demanda. La mayor ventaja de este planteamiento es que las aplicaciones o componentes espec\u00edficos pueden ejecutarse en funci\u00f3n de las necesidades, sin necesidad de un entorno de ejecuci\u00f3n continuo.<\/p>\n
Cada uno de los proveedores de nube m\u00e1s importantes comparte conceptos parecidos para las funciones sin servidor, como por ejemplo:<\/p>\n
\n- Compatibilidad con varios lenguajes de programaci\u00f3n.<\/li>\n
- La ausencia de acceso SSH debido a su arquitectura totalmente gestionada.<\/li>\n
- Uso de funciones, cuentas de servicio o identidades gestionadas para gestionar de forma segura el acceso a los recursos.<\/li>\n<\/ul>\n
<\/a>AWS Lambda<\/strong><\/h3>\nEl servicio IAM de AWS permite crear y administrar usuarios, permisos, grupos y roles. El servicio es responsable de administrar las identidades y su nivel de acceso a las cuentas y servicios de AWS, as\u00ed como del control de diversas caracter\u00edsticas dentro de una cuenta de AWS.<\/p>\n
Las funciones sin servidor usan roles de Lambda, que no tienen permisos por defecto; se deben usar pol\u00edticas de IAM para administrar los permisos y asegurar el acceso a otros servicios de AWS.<\/p>\n
Para simplificar la administraci\u00f3n de permisos, AWS proporciona pol\u00edticas administradas (como AWSLambdaBasicExecutionRole<\/span>) que los desarrolladores suelen adjuntar a estas funciones para habilitar r\u00e1pidamente la funcionalidad b\u00e1sica.<\/p>\nCuando se asocia un rol de IAM a una funci\u00f3n de Lambda, el servicio de tokens de seguridad (STS)<\/a> de AWS genera autom\u00e1ticamente credenciales de seguridad temporales<\/a> para ese rol.<\/p>\nSe trata de una forma segura de acceder a las credenciales en tiempo de ejecuci\u00f3n sin los riesgos asociados con las credenciales codificadas a largo plazo.<\/p>\n
Estas credenciales se rigen por los permisos definidos en la pol\u00edtica de acceso asociada con el rol. Incluyen un identificador de clave de acceso, una clave de acceso secreta y un token de sesi\u00f3n.<\/p>\n
En tiempo de ejecuci\u00f3n, el servicio en tiempo de ejecuci\u00f3n de Lambda carga las credenciales de rol en el entorno de ejecuci\u00f3n de la funci\u00f3n y las almacena como variables de entorno, por ejemplo, AWS_ACCESS_KEY_ID<\/span>, AWS_SECRET_ACCESS_KEY<\/span> y AWS_SESSION_TOKEN<\/span>. Estas variables son accesibles al c\u00f3digo de la funci\u00f3n durante el tiempo de ejecuci\u00f3n, lo que permite a la funci\u00f3n interactuar de forma segura con otros servicios de AWS.<\/p>\n<\/a>Google Cloud Functions<\/strong><\/h3>\nGoogle Cloud Functions utiliza tokens de cuenta de servicio para autenticar y autorizar el acceso a otros servicios de Google Cloud. Una cuenta de servicio es una cuenta de Google especializada que est\u00e1 vinculada con un proyecto<\/a> y representa una identidad no humana, en lugar de representar a un usuario individual.<\/p>\nAl implementar una Cloud Function, los desarrolladores pueden adjuntar la funci\u00f3n a una cuenta de servicio personalizada o a la cuenta de servicio por defecto<\/a>. Cuando se utiliza una cuenta de servicio personalizada, los desarrolladores pueden asignar roles IAM espec\u00edficos para definir los permisos exactos que requiere la funci\u00f3n para realizar sus tareas.<\/p>\nLas cuentas de servicio por defecto son cuentas gestionadas por el usuario<\/a> que Google Cloud crea autom\u00e1ticamente cuando los usuarios habilitan servicios espec\u00edficos. Por defecto, Google Cloud Functions utiliza diferentes cuentas de servicio en funci\u00f3n de la generaci\u00f3n<\/a>:<\/p>\n\n- Cloud Run functions de primera generaci\u00f3n utilizan la cuenta de servicio por defecto de App Engine (<project_id>@appspot.gserviceaccount.com<\/span>)<\/li>\n
- Cloud Run functions de segunda generaci\u00f3n utilizan la cuenta de servicio por defecto de Compute (<project_number>- compute@developer.gserviceaccount.com<\/span>)<\/li>\n<\/ul>\n
A estas cuentas de servicio por defecto se les conceden permisos de editor cuando los desarrolladores se incorporan a GCP sin una organizaci\u00f3n, lo que les permite crear, modificar y eliminar recursos dentro del proyecto. Sin embargo, en los proyectos que dependen de una organizaci\u00f3n GCP, las cuentas de servicio por defecto se crean sin ning\u00fan permiso. En esos casos, solo pueden realizar acciones permitidas expl\u00edcitamente por los roles que se les han asignado.<\/p>\n
Aunque una funci\u00f3n de GCP opera en un entorno sin servidor, cuando se trata de acceder a las credenciales asociadas con la funci\u00f3n, se comporta de manera similar a un servidor tradicional, como una instancia de m\u00e1quina virtual (VM), recuperando sus tokens de cuenta de servicio del servidor de metadatos de instancia (IMDS)<\/a> en tiempo de ejecuci\u00f3n. El IMDS en hxxp:\/\/metadata.google[.]internal\/<\/span> proporciona tokens de acceso de corta duraci\u00f3n para la cuenta de servicio asociada con la funci\u00f3n. Estos tokens permiten a la funci\u00f3n autenticarse en los servicios de GCP.<\/p>\n<\/a>Azure Functions<\/strong><\/h3>\nLas identidades gestionadas de Azure proporcionan una forma segura y transparente para que los recursos de Azure se autentiquen e interact\u00faen con otros servicios de Azure sin necesidad de utilizar credenciales codificadas. Del mismo modo que los servicios de funciones de AWS y GCP, estas identidades eliminan los riesgos asociados con la gesti\u00f3n de credenciales en el c\u00f3digo.<\/p>\n
Las identidades gestionadas asignadas por el sistema se vinculan a un \u00fanico recurso y se eliminan autom\u00e1ticamente cuando se elimina el recurso. Por otro lado, las identidades gestionadas asignadas por el usuario son recursos independientes que pueden asignarse a diversos servicios, lo que ofrece m\u00e1s flexibilidad para escenarios de autenticaci\u00f3n compartida.<\/p>\n
Una funci\u00f3n de Azure con una identidad gestionada adjunta debe utilizar su token de identidad gestionada para autenticarse en un recurso de Azure. El proceso de autenticaci\u00f3n paso a paso es el siguiente:<\/p>\n
\n- La funci\u00f3n consulta sus variables de entorno para recuperar los valores de IDENTITY_ENDPOINT<\/span> e IDENTITY_HEADER<\/span>.\n
\n- IDENTITY_ENDPOINT<\/span>: Una variable de entorno<\/a> que contiene la direcci\u00f3n del endpoint local de identidad gestionada proporcionado por Azure. Se trata de una URL local desde la que una aplicaci\u00f3n puede solicitar tokens.<\/li>\n
- IDENTITY_HEADER<\/span>: Par\u00e1metro obligatorio al consultar el endpoint local de identidad gestionada. Esta cabecera se utiliza para mitigar los ataques SSRF.<\/li>\n<\/ul>\n<\/li>\n
- La funci\u00f3n env\u00eda una solicitud HTTP GET al endpoint local de identidad gestionada con el IDENTITY_HEADER<\/span> incluido como cabecera HTTP. (Para obtener m\u00e1s informaci\u00f3n sobre la estructura de la solicitud, consulte la documentaci\u00f3n de Azure sobre la adquisici\u00f3n de tokens para App Services<\/a>)<\/li>\n
- Microsoft Entra ID<\/a> (anteriormente Azure Active Directory) verifica la identidad de la funci\u00f3n y emite un token OAuth 2.0 temporal que se asigna espec\u00edficamente al recurso de destino.<\/li>\n
- La funci\u00f3n incluye el token emitido en su solicitud al recurso Azure (p. ej., Azure Key Vault<\/a>, Storage Account<\/a>).<\/li>\n
- El recurso Azure valida el token y comprueba los permisos de la funci\u00f3n mediante el control de acceso basado en roles<\/a> o pol\u00edticas de acceso espec\u00edficas del recurso<\/a>.<\/li>\n<\/ul>\n
Si est\u00e1 autorizado, el recurso concede acceso para realizar la operaci\u00f3n solicitada. Esto garantiza una autenticaci\u00f3n segura y perfecta sin necesidad de utilizar secretos codificados en el c\u00f3digo.<\/p>\n
<\/a>Vectores de ataque de extracci\u00f3n de tokens<\/h2>\nEn esta secci\u00f3n se analizan los riesgos y amenazas que conlleva el uso de funciones sin servidor. Al desarrollar y configurar funciones, los desarrolladores de aplicaciones deben asegurarse de proteger esas funciones contra ataques como SSRF y RCE. En ausencia de dicha seguridad, los atacantes podr\u00edan manipular las funciones sin servidor que son vulnerables a SSRF, haciendo que las funciones env\u00eden solicitudes no autorizadas a los servicios internos. Esto puede conducir a un acceso no intencionado o a la exposici\u00f3n de informaci\u00f3n confidencial dentro del sistema, como tokens de acceso, contenido de bases de datos internas o configuraciones de servicios. Es importante subrayar que estos riesgos surgen principalmente cuando las funciones son p\u00fablicas o procesan entradas de usuarios externos y otras fuentes.<\/p>\n
En los ataques SSRF, un atacante enga\u00f1a a un servidor (como una funci\u00f3n sin servidor) para que realice peticiones HTTP a recursos internos o externos a los que el atacante no deber\u00eda tener acceso. Dado que es el propio servidor el que realiza la petici\u00f3n, puede acceder a servicios internos que no est\u00e1n expuestos a Internet. Una funci\u00f3n vulnerable sin servidor toma una URL como entrada y obtiene datos de ella.<\/p>\n
En GCP, SSRF puede utilizarse para acceder al IMDS en hxxp:\/\/metadata.google[.]internal\/<\/span>, extrayendo tokens de cuenta de servicio de corta duraci\u00f3n. Un atacante puede entonces aprovechar estos tokens para hacerse pasar por la funci\u00f3n y realizar acciones no autorizadas dentro de los permisos de su rol IAM. Las vulnerabilidades de ejecuci\u00f3n remota de c\u00f3digo permiten a los atacantes ejecutar c\u00f3digo arbitrario dentro del entorno de una funci\u00f3n.<\/p>\nPara AWS Lambda, los ataques RCE podr\u00edan exponer credenciales temporales almacenadas en variables de entorno, como AWS_ACCESS_KEY_ID<\/span> y AWS_SESSION_TOKEN<\/span>.<\/p>\nEs esencial se\u00f1alar que estos vectores de ataque no son fallos inherentes a las propias plataformas en nube, sino que surgen de c\u00f3digo inseguro escrito por desarrolladores de aplicaciones que podr\u00edan introducir vulnerabilidades, como SSRF o RCE. Los desarrolladores de aplicaciones pueden mitigar estos riesgos mediante la aplicaci\u00f3n de pr\u00e1cticas de codificaci\u00f3n seguras, como la validaci\u00f3n de entradas.<\/p>\n
<\/a>Simulaciones de vectores de ataque<\/strong><\/h3>\nEn las siguientes simulaciones se muestran posibles formas en las que los atacantes podr\u00edan extraer tokens de autenticaci\u00f3n de funciones sin servidor y utilizarlos para actividades maliciosas en diferentes proveedores de servicios en la nube (CSP). Estos ataques podr\u00edan aprovechar el c\u00f3digo de funci\u00f3n inseguro implementado por los desarrolladores de aplicaciones.<\/p>\n
<\/a>Simulaci\u00f3n 1: acceso directo al IMDS desde la funci\u00f3n GCP<\/h4>\nPara llevar a cabo esta simulaci\u00f3n, implementamos dos funciones de Cloud Run de Google que acceden al servicio de metadatos de funciones y extraen los tokens de las dos cuentas de servicio adjuntas diferentes de la siguiente ruta:<\/p>\n
\n- hxxp[:\/\/]metadata.google[.]internal\/computeMetadata\/v1\/instance\/service-accounts\/default\/token<\/span><\/li>\n<\/ul>\n
En el primer ejemplo se muestra la extracci\u00f3n de una cuenta de servicio por defecto. En el segundo ejemplo se muestra la extracci\u00f3n de una cuenta de servicio personalizada. En estos ejemplos se muestra c\u00f3mo el c\u00f3digo puede acceder directamente al servicio de metadatos, del mismo modo que una aplicaci\u00f3n de c\u00f3digo SSRF vulnerable tambi\u00e9n podr\u00eda acceder a \u00e9l.<\/p>\n
<\/a>Ejemplo 1: extracci\u00f3n de una cuenta de servicio por defecto de GCP<\/strong><\/h5>\nComo se muestra en la Figura\u00a01, la cuenta de servicio adjunta a la funci\u00f3n era la cuenta de servicio sin servidor predeterminada. En la Figura\u00a02 se muestra que el token de acceso devuelto pertenece a la misma cuenta de servicio.<\/p>\n![\"Captura]()
Figura 1. Informaci\u00f3n general sobre la funci\u00f3n, incluido un nombre de cuenta de servicio adjunto (la cuenta de servicio por defecto).<\/figcaption><\/figure>\n![\"Captura]()
Figura 2. Fragmento de c\u00f3digo de un comando utilizado para extraer el token de acceso a la cuenta de servicio, incluida la salida.<\/figcaption><\/figure>\n<\/a>Ejemplo 2: extracci\u00f3n de una cuenta de servicio personalizada de GCP<\/strong><\/h5>\nEn la Figura\u00a03 se muestra la cuenta de servicio personalizada que adjuntamos a la funci\u00f3n. En la Figura\u00a04 se muestra el token de acceso devuelto perteneciente a la cuenta de servicio personalizada. A continuaci\u00f3n, utilizamos el token devuelto para realizar operaciones en el entorno.<\/p>\n![\"Captura]()
Figura 3. Informaci\u00f3n general sobre la funci\u00f3n, incluido el nombre de la cuenta de servicio adjunta (una cuenta de servicio personalizada).<\/figcaption><\/figure>\n![\"Captura]()
Figura 4. Fragmento de c\u00f3digo de un comando utilizado para extraer el token de acceso a la cuenta de servicio, incluida la salida.<\/figcaption><\/figure>\nEn la Figura\u00a05 se muestra un ejemplo de comando para mostrar dep\u00f3sitos.<\/p>\n![\"Captura]()
Figura 5. Utilizar el token devuelto para mostrar los dep\u00f3sitos de una cuenta de servicio.<\/figcaption><\/figure>\nSi los atacantes pueden mostrar y leer el contenido de los dep\u00f3sitos en GCP, pueden acceder a archivos confidenciales como credenciales, copias de seguridad o configuraciones internas. Esto les permite robar datos, comprometer el sistema o moverse lateralmente dentro del entorno.<\/p>\n
Una vez que los atacantes obtienen un token de acceso para una cuenta de servicio con permisos de editor en GCP (como la cuenta de servicio Compute Engine predeterminada), pueden modificar, eliminar o crear recursos en la mayor\u00eda de los servicios. Esto incluye acceder a datos confidenciales, implementar cargas de trabajo maliciosas, escalar privilegios o interrumpir servicios. El acceso de editor otorga un control casi total sobre el proyecto.<\/p>\n
<\/a>Simulaci\u00f3n 2: uso de RCE para recuperar tokens almacenados en variables de entorno de funciones de AWS Lambda<\/h4>\nEn esta simulaci\u00f3n, accedimos a las variables de entorno de la funci\u00f3n Lambda y extrajimos de ella el AWS_ACCESS_KEY_ID<\/span>, AWS_SECRET_ACCESS_KEY<\/span> y AWS_SESSION_TOKEN<\/span>.<\/p>\nEn la Figura\u00a06 se muestra la salida del c\u00f3digo de la funci\u00f3n Lambda.<\/p>\n![\"Captura]()
Figura 6. Los valores de las variables de entorno devueltas.<\/figcaption><\/figure>\nEn la Figura\u00a07 se muestra la configuraci\u00f3n de las credenciales temporales de AWS obtenidas en el paso anterior (las variables de entorno de Lambda).<\/p>\n![\"Pantalla]()
Figura 7. Fragmento de c\u00f3digo de los comandos utilizados para mostrar los dep\u00f3sitos s3.<\/figcaption><\/figure>\nA continuaci\u00f3n, utilizamos el siguiente comando para mostrar todos los dep\u00f3sitos de S3 a los que puede acceder la sesi\u00f3n autenticada.<\/p>\n
aws s3 ls<\/pre>\n<\/a>Simulaci\u00f3n 3: uso de RCE para recuperar tokens del endpoint local de identidad de Azure Function<\/h4>\nEn esta simulaci\u00f3n, accedimos a las variables de entorno de Azure y extrajimos el IDENTITY_ENDPOINT<\/span> y el IDENTITY_HEADER<\/span> ejecutando comandos remotos. A continuaci\u00f3n, extrajimos el token de identidad gestionada del endpoint local de identidad, proporcionando estos par\u00e1metros que se muestran a continuaci\u00f3n en la Figura\u00a08:<\/p>\n\n- Recurso<\/li>\n
- api-version<\/span><\/li>\n
- X-IDENTITY-HEADER<\/span><\/li>\n<\/ul>\n
![\"Captura]()
Figura 8. Salida del script, que incluye el token de acceso.<\/figcaption><\/figure>\n<\/a>Detecci\u00f3n y prevenci\u00f3n de la filtraci\u00f3n de tokens<\/h2>\n<\/a>Detecci\u00f3n de la exfiltraci\u00f3n de tokens en entornos sin servidor<\/h3>\nLos mecanismos de detecci\u00f3n eficaces son fundamentales para identificar la exfiltraci\u00f3n de tokens en entornos sin servidor. Estos mecanismos se centran en las anomal\u00edas de comportamiento para se\u00f1alar actividades no autorizadas. A continuaci\u00f3n se exponen algunas de las mejores estrategias de detecci\u00f3n aplicadas en las principales plataformas en nube.<\/p>\n
La detecci\u00f3n consta de dos etapas:<\/p>\n
\n- Validaci\u00f3n de que la identidad est\u00e1 vinculada con una funci\u00f3n sin servidor.<\/li>\n
- Identificaci\u00f3n de comportamientos an\u00f3malos de las identidades sin servidor. Tal comportamiento podr\u00eda incluir lo siguiente:\n
\n- Direcciones IP de origen que no se ajustan al contexto en el que se ejecuta la funci\u00f3n, como direcciones de N\u00fameros de Sistema Aut\u00f3nomo (ASN) que no est\u00e1n asociadas con un proveedor de nube.<\/li>\n
- Identidades sin servidor que realizan peticiones con agentes de usuario sospechosos.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/a>Paso 1: identificaci\u00f3n de identidades sin servidor<\/h4>\nPara identificar las cuentas de servicio adjuntas a las funciones sin servidor en GCP, analizamos la secci\u00f3n serviceAccountDelegationInfo<\/span> en los registros. Esta informaci\u00f3n proporciona datos cruciales sobre la cadena de delegaci\u00f3n de cuentas de servicio. En concreto, cuando una cuenta de servicio se adjunta a una funci\u00f3n, delega su autoridad en una cuenta de servicio sin servidor por defecto:<\/p>\n\n- Agente del servicio de Cloud Run de Google (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>)<\/li>\n
- gcf-admin-robot.iam.gserviceaccount[.]com<\/span> (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com<\/span>)<\/li>\n<\/ul>\n
Estas cuentas de servicio ejecutan tareas en nombre de la funci\u00f3n.<\/p>\n
Por ejemplo, en la entrada de registro de la Figura\u00a09, vemos la cuenta de servicio personalizada que se adjunt\u00f3 a una funci\u00f3n (sa-test@<project-id>.iam.gserviceaccount[.]com<\/span>) que delega su autoridad en el agente de servicio Cloud Run.<\/p>\n![\"Captura]()
Figura 9. Entrada de registro con la cuenta de servicio personalizada.<\/figcaption><\/figure>\nEn la Figura\u00a09, el campo principalEmail<\/span> de authenticationInfo<\/span> especifica la cuenta de servicio que se est\u00e1 utilizando (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com<\/span>).<\/p>\nEl serviceAccountDelegationInfo<\/span> muestra el principal de la primera parte (en este caso: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>), indicando que la cuenta de servicio est\u00e1 operando dentro de un entorno sin servidor como Cloud Functions o Cloud Run.<\/p>\nUn enfoque eficaz para descubrir identidades sin servidor es crear perfiles de cuentas de servicio que hayan delegado previamente su autoridad en cuentas de servicio sin servidor por defecto. De este modo se garantiza que incluso si se adjuntan cuentas de servicio no predeterminadas a las funciones, estas se identifiquen.<\/p>\n
En AWS, las funciones Lambda se basan en roles IAM para el acceso seguro a los servicios de AWS. Estas funciones generan credenciales temporales. Podemos identificar la identidad Lambda por su nombre de rol.<\/p>\n
En Azure, las identidades gestionadas adjuntas a Azure Function Apps se utilizan para la autenticaci\u00f3n.<\/p>\n
<\/a>Paso 2: identificaci\u00f3n de comportamientos inusuales en las identidades sin servidor<\/h4>\nEn un entorno de nube seguro, las funciones sin servidor suelen estar destinadas a realizar tareas automatizadas y de alcance limitado, como responder a solicitudes de API o procesar eventos. Estas funciones no deben utilizarse de forma interactiva. Sin embargo, si los atacantes obtienen acceso al entorno de una funci\u00f3n sin servidor o a su identidad, podr\u00edan hacer un uso indebido para ejecutar comandos de interfaz de l\u00ednea de comandos (CLI) (por ejemplo, gcloud CLI<\/span> o curl<\/span>) para interactuar directamente con los recursos de la nube.<\/p>\nUna forma de detecci\u00f3n consiste en analizar el agente de usuario de las llamadas a la API. Si el agente de usuario coincide con herramientas CLI conocidas (por ejemplo, gcloud CLI<\/span>) o marcos de pruebas de penetraci\u00f3n, se marca como sospechoso, ya que las identidades sin servidor no deber\u00edan utilizar normalmente CLI. Esto indica una posible explotaci\u00f3n de los tokens del entorno o de la cuenta de servicio.<\/p>\nCabe destacar que este m\u00e9todo de identificar el uso remoto de tokens de autenticaci\u00f3n de funciones sin servidor seg\u00fan el agente de usuario no se puede realizar en Azure, ya que la informaci\u00f3n del agente de usuario no aparece en los registros de Azure.<\/p>\n
Otro enfoque para detectar el uso remoto de un token de identidad sin servidor consiste en correlacionar la ubicaci\u00f3n del uso de un token con rangos ASN de direcciones IP de proveedores de nube conocidos. Si una solicitud se origina en una direcci\u00f3n IP externa no asociada con el CSP, se activa una alerta que pone de manifiesto el posible uso no autorizado de tokens fuera del entorno de la nube.<\/p>\n
<\/a>Estrategias de prevenci\u00f3n<\/h3>\nAsegurar los tokens de autenticaci\u00f3n de funciones sin servidor requiere una combinaci\u00f3n de medidas proactivas, gesti\u00f3n de posturas y pr\u00e1cticas de seguridad de monitorizaci\u00f3n en tiempo de ejecuci\u00f3n para minimizar el riesgo de explotaci\u00f3n. En primer lugar, aplique el principio del menor privilegio asignando roles con los permisos m\u00ednimos necesarios para las funciones sin servidor. Esto reduce el impacto potencial del uso indebido de tokens.<\/p>\n
Adem\u00e1s, para proteger los entornos de ejecuci\u00f3n sin servidor en GCP y Azure, restrinja el acceso a IMDS configurando controles a nivel de red y aplicando mecanismos de validaci\u00f3n de solicitudes. Garantice una s\u00f3lida validaci\u00f3n y limpieza de entradas para evitar que los atacantes utilicen t\u00e9cnicas de explotaci\u00f3n como SSRF para acceder a metadatos confidenciales, tokens y otros recursos de la nube como API y bases de datos.<\/p>\n
<\/a>Conclusi\u00f3n<\/h2>\nLa computaci\u00f3n sin servidor es la opci\u00f3n preferida para el desarrollo de aplicaciones modernas porque ofrece ventajas significativas en escalabilidad, rentabilidad y gesti\u00f3n simplificada de la infraestructura.<\/p>\n
Las credenciales que permiten a estas funciones interactuar con los servicios en la nube son un elemento de seguridad cr\u00edtico y un objetivo prioritario para los atacantes. Comprometer estas credenciales puede acarrear graves consecuencias, como el acceso no autorizado a los recursos de la nube y la filtraci\u00f3n de datos.<\/p>\n
La implementaci\u00f3n de protecciones proactivas de gesti\u00f3n de posturas y supervisi\u00f3n en tiempo de ejecuci\u00f3n es una estrategia crucial para proteger los entornos en nube.<\/p>\n
Las organizaciones pueden proteger mejor sus entornos sin servidor mediante:<\/p>\n
\n- Comprender la mec\u00e1nica de las credenciales sin servidor y las mejores pr\u00e1cticas para aprovisionarlas y administrarlas en AWS, Azure y GCP<\/a>.<\/li>\n
- Reconocimiento de vectores de ataque comunes, como la exfiltraci\u00f3n de tokens mediante la explotaci\u00f3n de IMDS o el acceso a variables de entorno.<\/li>\n<\/ul>\n
<\/a>Protecci\u00f3n y mitigaci\u00f3n de Palo Alto Networks<\/h2>\nLos clientes de Palo Alto Networks est\u00e1n mejor protegidos frente a las amenazas mencionadas gracias a los siguientes productos:<\/p>\n
Si cree que puede haber resultado vulnerado o tiene un problema urgente, p\u00f3ngase en contacto con el equipo de respuesta ante incidentes de Unit\u00a042<\/a> o llame al:<\/p>\n\n- Tel\u00e9fono gratuito para Norteam\u00e9rica: +866.486.4842 (+866.4.UNIT42)<\/li>\n
- EUROPA, ORIENTE MEDIO Y \u00c1FRICA: +31.20.299.3130<\/li>\n
- APAC: +65.6983.8730<\/li>\n
- Jap\u00f3n: +81.50.1790.0200<\/li>\n<\/ul>\n
Palo Alto Networks ha compartido estos resultados con nuestros compa\u00f1eros de Cyber Threat Alliance (CTA). Los miembros de CTA utilizan esta inteligencia para implementar r\u00e1pidamente medidas de protecci\u00f3n para sus clientes y desarticular sistem\u00e1ticamente a los ciberdelincuentes. M\u00e1s informaci\u00f3n sobre Cyber Threat Alliance<\/a>.<\/p>\n<\/a>Recursos adicionales<\/h2>\n\n- Trabajar con variables de entorno de Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Protecci\u00f3n de las variables de entorno de Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Administraci\u00f3n de permisos en AWS Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Funci\u00f3n Identidad<\/a>: Google Cloud<\/li>\n
- \u00bfQu\u00e9 son las identidades gestionadas para los recursos de Azure?<\/a>: Microsoft Learn<\/li>\n
- Protecci\u00f3n de Azure Functions<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es AWS Secrets Manager?<\/a>: gu\u00eda del usuario de AWS Secret Manager<\/li>\n
- Conceptos b\u00e1sicos de Azure Key Vault<\/a>: Microsoft Learn<\/li>\n
- Descripci\u00f3n general de Secret Manager<\/a>: documentaci\u00f3n de Google Cloud Secret Manager<\/li>\n
- \u00bfQu\u00e9 es la gesti\u00f3n de identidades y accesos (IAM)?<\/a>: Microsoft Security<\/li>\n
- \u00bfQu\u00e9 son las identidades gestionadas para los recursos de Azure?<\/a>: Microsoft Learn<\/li>\n
- Identidad y control de acceso<\/a>: introducci\u00f3n a la seguridad de AWS Whitepaper de AWS<\/li>\n
- Credenciales de la cuenta de servicio<\/a>: documentaci\u00f3n de Google Cloud IAM<\/li>\n
- Credenciales de seguridad temporales en IAM<\/a>: gu\u00eda del usuario de la gesti\u00f3n de acceso e identidades de AWS<\/li>\n
- Referencia de la API del servicio de tokens de seguridad de AWS<\/a>: documentaci\u00f3n del servicio de tokens de seguridad de AWS<\/li>\n
- Instancias de Compute Engine<\/a>: documentaci\u00f3n sobre Google Cloud<\/li>\n
- Proyectos de Google Cloud<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Cuentas de servicio gestionadas por el usuario<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Comparaci\u00f3n de las funciones de Cloud Run<\/a>: documentaci\u00f3n de Cloud Run de Google<\/li>\n
- Cuentas de servicio por defecto<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Referencia de endpoint REST<\/a>: identidades gestionadas para App Service y Azure Functions<\/li>\n
- Variables de entorno y configuraci\u00f3n de aplicaciones en Azure App Service<\/a>: Microsoft Learn<\/li>\n
- C\u00f3mo utilizar identidades gestionadas para recursos Azure en una m\u00e1quina virtual Azure para adquirir un token de acceso<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es Microsoft Entra ID?<\/a>: Microsoft Entra ID<\/li>\n
- Acerca de Azure Key Vault<\/a>: Microsoft Learn<\/li>\n
- Autorizar el acceso a blobs mediante Microsoft Entra ID<\/a>: Microsoft Learn<\/li>\n
- Descripci\u00f3n general de la cuenta de almacenamiento<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es el control de acceso basado en rol de Azure (RBAC)?<\/a>: Microsoft Learn<\/li>\n
- Pol\u00edticas de acceso a recursos espec\u00edficos<\/a>: Microsoft Learn<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.<\/p>\n","protected":false},"author":366,"featured_media":143167,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8838,8730],"tags":[9291,9329,9330,8861],"product_categories":[8932,8933,8890],"coauthors":[4194],"class_list":["post-146596","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-threat-research-es-la","category-cloud-cybersecurity-research-es-la","tag-aws-es-la","tag-google-cloud-es-la","tag-microsoft-azure-es-la","tag-serverless-es-la","product_categories-cortex-es-la","product_categories-cortex-cloud-es-la","product_categories-unit-42-incident-response-es-la"],"yoast_head":"\n
Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n<\/title>\n<meta name=\"description\" content=\"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:locale\" content=\"es_LA\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n\" \/>\n<meta property=\"og:description\" content=\"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:site_name\" content=\"Unit 42\" \/>\n<meta property=\"article:published_time\" content=\"2025-06-13T17:16:43+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-07-11T17:28:42+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"900\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Zohar Zigdon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","og_locale":"es_LA","og_type":"article","og_title":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","og_description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","og_url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","og_site_name":"Unit 42","article_published_time":"2025-06-13T17:16:43+00:00","article_modified_time":"2025-07-11T17:28:42+00:00","og_image":[{"width":1920,"height":900,"url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","type":"image\/jpeg"}],"author":"Zohar Zigdon","twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#article","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"},"author":{"name":"Sheida Azimi","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"headline":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","datePublished":"2025-06-13T17:16:43+00:00","dateModified":"2025-07-11T17:28:42+00:00","mainEntityOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"},"wordCount":4687,"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","keywords":["AWS","Google Cloud","Microsoft Azure","serverless"],"articleSection":["Investigaci\u00f3n de amenazas","Investigaci\u00f3n de ciberseguridad en la nube"],"inLanguage":"es"},{"@type":"WebPage","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","name":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","datePublished":"2025-06-13T17:16:43+00:00","dateModified":"2025-07-11T17:28:42+00:00","author":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","breadcrumb":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"]}]},{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","width":1920,"height":900,"caption":"Pictorial representation of serverless tokens in the cloud. East Asian woman examining data on multiple screens in a high-tech environment, surrounded by digital graphics and code."},{"@type":"BreadcrumbList","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/unit42.paloaltonetworks.com\/"},{"@type":"ListItem","position":2,"name":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n"}]},{"@type":"WebSite","@id":"https:\/\/unit42.paloaltonetworks.com\/#website","url":"https:\/\/unit42.paloaltonetworks.com\/","name":"Unit 42","description":"Palo Alto Networks","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/unit42.paloaltonetworks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"es"},{"@type":"Person","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639","name":"Sheida Azimi","image":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/image\/4ffb3c2d260a0150fb91b3715442f8b3","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","caption":"Sheida Azimi"},"url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/author\/sheida-azimi\/"}]}},"_links":{"self":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/users\/366"}],"replies":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/comments?post=146596"}],"version-history":[{"count":4,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596\/revisions"}],"predecessor-version":[{"id":146700,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596\/revisions\/146700"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/media\/143167"}],"wp:attachment":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/media?parent=146596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/categories?post=146596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/tags?post=146596"},{"taxonomy":"product_categories","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/product_categories?post=146596"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/coauthors?post=146596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Cuando se utilizan funciones sin servidor, es importante tener en cuenta los riesgos que se producen cuando los desarrolladores de aplicaciones implementan c\u00f3digo inseguro en funciones en la nube, y comprender las amenazas que se dirigen a estas funciones.<\/p>\n
<\/a>C\u00f3mo funciona la autenticaci\u00f3n sin servidor en las principales plataformas en la nube<\/h2>\nMediante el enfoque sin servidor, las aplicaciones se implementan con la ejecuci\u00f3n de funciones bajo demanda. La mayor ventaja de este planteamiento es que las aplicaciones o componentes espec\u00edficos pueden ejecutarse en funci\u00f3n de las necesidades, sin necesidad de un entorno de ejecuci\u00f3n continuo.<\/p>\n
Cada uno de los proveedores de nube m\u00e1s importantes comparte conceptos parecidos para las funciones sin servidor, como por ejemplo:<\/p>\n
\n- Compatibilidad con varios lenguajes de programaci\u00f3n.<\/li>\n
- La ausencia de acceso SSH debido a su arquitectura totalmente gestionada.<\/li>\n
- Uso de funciones, cuentas de servicio o identidades gestionadas para gestionar de forma segura el acceso a los recursos.<\/li>\n<\/ul>\n
<\/a>AWS Lambda<\/strong><\/h3>\nEl servicio IAM de AWS permite crear y administrar usuarios, permisos, grupos y roles. El servicio es responsable de administrar las identidades y su nivel de acceso a las cuentas y servicios de AWS, as\u00ed como del control de diversas caracter\u00edsticas dentro de una cuenta de AWS.<\/p>\n
Las funciones sin servidor usan roles de Lambda, que no tienen permisos por defecto; se deben usar pol\u00edticas de IAM para administrar los permisos y asegurar el acceso a otros servicios de AWS.<\/p>\n
Para simplificar la administraci\u00f3n de permisos, AWS proporciona pol\u00edticas administradas (como AWSLambdaBasicExecutionRole<\/span>) que los desarrolladores suelen adjuntar a estas funciones para habilitar r\u00e1pidamente la funcionalidad b\u00e1sica.<\/p>\nCuando se asocia un rol de IAM a una funci\u00f3n de Lambda, el servicio de tokens de seguridad (STS)<\/a> de AWS genera autom\u00e1ticamente credenciales de seguridad temporales<\/a> para ese rol.<\/p>\nSe trata de una forma segura de acceder a las credenciales en tiempo de ejecuci\u00f3n sin los riesgos asociados con las credenciales codificadas a largo plazo.<\/p>\n
Estas credenciales se rigen por los permisos definidos en la pol\u00edtica de acceso asociada con el rol. Incluyen un identificador de clave de acceso, una clave de acceso secreta y un token de sesi\u00f3n.<\/p>\n
En tiempo de ejecuci\u00f3n, el servicio en tiempo de ejecuci\u00f3n de Lambda carga las credenciales de rol en el entorno de ejecuci\u00f3n de la funci\u00f3n y las almacena como variables de entorno, por ejemplo, AWS_ACCESS_KEY_ID<\/span>, AWS_SECRET_ACCESS_KEY<\/span> y AWS_SESSION_TOKEN<\/span>. Estas variables son accesibles al c\u00f3digo de la funci\u00f3n durante el tiempo de ejecuci\u00f3n, lo que permite a la funci\u00f3n interactuar de forma segura con otros servicios de AWS.<\/p>\n<\/a>Google Cloud Functions<\/strong><\/h3>\nGoogle Cloud Functions utiliza tokens de cuenta de servicio para autenticar y autorizar el acceso a otros servicios de Google Cloud. Una cuenta de servicio es una cuenta de Google especializada que est\u00e1 vinculada con un proyecto<\/a> y representa una identidad no humana, en lugar de representar a un usuario individual.<\/p>\nAl implementar una Cloud Function, los desarrolladores pueden adjuntar la funci\u00f3n a una cuenta de servicio personalizada o a la cuenta de servicio por defecto<\/a>. Cuando se utiliza una cuenta de servicio personalizada, los desarrolladores pueden asignar roles IAM espec\u00edficos para definir los permisos exactos que requiere la funci\u00f3n para realizar sus tareas.<\/p>\nLas cuentas de servicio por defecto son cuentas gestionadas por el usuario<\/a> que Google Cloud crea autom\u00e1ticamente cuando los usuarios habilitan servicios espec\u00edficos. Por defecto, Google Cloud Functions utiliza diferentes cuentas de servicio en funci\u00f3n de la generaci\u00f3n<\/a>:<\/p>\n\n- Cloud Run functions de primera generaci\u00f3n utilizan la cuenta de servicio por defecto de App Engine (<project_id>@appspot.gserviceaccount.com<\/span>)<\/li>\n
- Cloud Run functions de segunda generaci\u00f3n utilizan la cuenta de servicio por defecto de Compute (<project_number>- compute@developer.gserviceaccount.com<\/span>)<\/li>\n<\/ul>\n
A estas cuentas de servicio por defecto se les conceden permisos de editor cuando los desarrolladores se incorporan a GCP sin una organizaci\u00f3n, lo que les permite crear, modificar y eliminar recursos dentro del proyecto. Sin embargo, en los proyectos que dependen de una organizaci\u00f3n GCP, las cuentas de servicio por defecto se crean sin ning\u00fan permiso. En esos casos, solo pueden realizar acciones permitidas expl\u00edcitamente por los roles que se les han asignado.<\/p>\n
Aunque una funci\u00f3n de GCP opera en un entorno sin servidor, cuando se trata de acceder a las credenciales asociadas con la funci\u00f3n, se comporta de manera similar a un servidor tradicional, como una instancia de m\u00e1quina virtual (VM), recuperando sus tokens de cuenta de servicio del servidor de metadatos de instancia (IMDS)<\/a> en tiempo de ejecuci\u00f3n. El IMDS en hxxp:\/\/metadata.google[.]internal\/<\/span> proporciona tokens de acceso de corta duraci\u00f3n para la cuenta de servicio asociada con la funci\u00f3n. Estos tokens permiten a la funci\u00f3n autenticarse en los servicios de GCP.<\/p>\n<\/a>Azure Functions<\/strong><\/h3>\nLas identidades gestionadas de Azure proporcionan una forma segura y transparente para que los recursos de Azure se autentiquen e interact\u00faen con otros servicios de Azure sin necesidad de utilizar credenciales codificadas. Del mismo modo que los servicios de funciones de AWS y GCP, estas identidades eliminan los riesgos asociados con la gesti\u00f3n de credenciales en el c\u00f3digo.<\/p>\n
Las identidades gestionadas asignadas por el sistema se vinculan a un \u00fanico recurso y se eliminan autom\u00e1ticamente cuando se elimina el recurso. Por otro lado, las identidades gestionadas asignadas por el usuario son recursos independientes que pueden asignarse a diversos servicios, lo que ofrece m\u00e1s flexibilidad para escenarios de autenticaci\u00f3n compartida.<\/p>\n
Una funci\u00f3n de Azure con una identidad gestionada adjunta debe utilizar su token de identidad gestionada para autenticarse en un recurso de Azure. El proceso de autenticaci\u00f3n paso a paso es el siguiente:<\/p>\n
\n- La funci\u00f3n consulta sus variables de entorno para recuperar los valores de IDENTITY_ENDPOINT<\/span> e IDENTITY_HEADER<\/span>.\n
\n- IDENTITY_ENDPOINT<\/span>: Una variable de entorno<\/a> que contiene la direcci\u00f3n del endpoint local de identidad gestionada proporcionado por Azure. Se trata de una URL local desde la que una aplicaci\u00f3n puede solicitar tokens.<\/li>\n
- IDENTITY_HEADER<\/span>: Par\u00e1metro obligatorio al consultar el endpoint local de identidad gestionada. Esta cabecera se utiliza para mitigar los ataques SSRF.<\/li>\n<\/ul>\n<\/li>\n
- La funci\u00f3n env\u00eda una solicitud HTTP GET al endpoint local de identidad gestionada con el IDENTITY_HEADER<\/span> incluido como cabecera HTTP. (Para obtener m\u00e1s informaci\u00f3n sobre la estructura de la solicitud, consulte la documentaci\u00f3n de Azure sobre la adquisici\u00f3n de tokens para App Services<\/a>)<\/li>\n
- Microsoft Entra ID<\/a> (anteriormente Azure Active Directory) verifica la identidad de la funci\u00f3n y emite un token OAuth 2.0 temporal que se asigna espec\u00edficamente al recurso de destino.<\/li>\n
- La funci\u00f3n incluye el token emitido en su solicitud al recurso Azure (p. ej., Azure Key Vault<\/a>, Storage Account<\/a>).<\/li>\n
- El recurso Azure valida el token y comprueba los permisos de la funci\u00f3n mediante el control de acceso basado en roles<\/a> o pol\u00edticas de acceso espec\u00edficas del recurso<\/a>.<\/li>\n<\/ul>\n
Si est\u00e1 autorizado, el recurso concede acceso para realizar la operaci\u00f3n solicitada. Esto garantiza una autenticaci\u00f3n segura y perfecta sin necesidad de utilizar secretos codificados en el c\u00f3digo.<\/p>\n
<\/a>Vectores de ataque de extracci\u00f3n de tokens<\/h2>\nEn esta secci\u00f3n se analizan los riesgos y amenazas que conlleva el uso de funciones sin servidor. Al desarrollar y configurar funciones, los desarrolladores de aplicaciones deben asegurarse de proteger esas funciones contra ataques como SSRF y RCE. En ausencia de dicha seguridad, los atacantes podr\u00edan manipular las funciones sin servidor que son vulnerables a SSRF, haciendo que las funciones env\u00eden solicitudes no autorizadas a los servicios internos. Esto puede conducir a un acceso no intencionado o a la exposici\u00f3n de informaci\u00f3n confidencial dentro del sistema, como tokens de acceso, contenido de bases de datos internas o configuraciones de servicios. Es importante subrayar que estos riesgos surgen principalmente cuando las funciones son p\u00fablicas o procesan entradas de usuarios externos y otras fuentes.<\/p>\n
En los ataques SSRF, un atacante enga\u00f1a a un servidor (como una funci\u00f3n sin servidor) para que realice peticiones HTTP a recursos internos o externos a los que el atacante no deber\u00eda tener acceso. Dado que es el propio servidor el que realiza la petici\u00f3n, puede acceder a servicios internos que no est\u00e1n expuestos a Internet. Una funci\u00f3n vulnerable sin servidor toma una URL como entrada y obtiene datos de ella.<\/p>\n
En GCP, SSRF puede utilizarse para acceder al IMDS en hxxp:\/\/metadata.google[.]internal\/<\/span>, extrayendo tokens de cuenta de servicio de corta duraci\u00f3n. Un atacante puede entonces aprovechar estos tokens para hacerse pasar por la funci\u00f3n y realizar acciones no autorizadas dentro de los permisos de su rol IAM. Las vulnerabilidades de ejecuci\u00f3n remota de c\u00f3digo permiten a los atacantes ejecutar c\u00f3digo arbitrario dentro del entorno de una funci\u00f3n.<\/p>\nPara AWS Lambda, los ataques RCE podr\u00edan exponer credenciales temporales almacenadas en variables de entorno, como AWS_ACCESS_KEY_ID<\/span> y AWS_SESSION_TOKEN<\/span>.<\/p>\nEs esencial se\u00f1alar que estos vectores de ataque no son fallos inherentes a las propias plataformas en nube, sino que surgen de c\u00f3digo inseguro escrito por desarrolladores de aplicaciones que podr\u00edan introducir vulnerabilidades, como SSRF o RCE. Los desarrolladores de aplicaciones pueden mitigar estos riesgos mediante la aplicaci\u00f3n de pr\u00e1cticas de codificaci\u00f3n seguras, como la validaci\u00f3n de entradas.<\/p>\n
<\/a>Simulaciones de vectores de ataque<\/strong><\/h3>\nEn las siguientes simulaciones se muestran posibles formas en las que los atacantes podr\u00edan extraer tokens de autenticaci\u00f3n de funciones sin servidor y utilizarlos para actividades maliciosas en diferentes proveedores de servicios en la nube (CSP). Estos ataques podr\u00edan aprovechar el c\u00f3digo de funci\u00f3n inseguro implementado por los desarrolladores de aplicaciones.<\/p>\n
<\/a>Simulaci\u00f3n 1: acceso directo al IMDS desde la funci\u00f3n GCP<\/h4>\nPara llevar a cabo esta simulaci\u00f3n, implementamos dos funciones de Cloud Run de Google que acceden al servicio de metadatos de funciones y extraen los tokens de las dos cuentas de servicio adjuntas diferentes de la siguiente ruta:<\/p>\n
\n- hxxp[:\/\/]metadata.google[.]internal\/computeMetadata\/v1\/instance\/service-accounts\/default\/token<\/span><\/li>\n<\/ul>\n
En el primer ejemplo se muestra la extracci\u00f3n de una cuenta de servicio por defecto. En el segundo ejemplo se muestra la extracci\u00f3n de una cuenta de servicio personalizada. En estos ejemplos se muestra c\u00f3mo el c\u00f3digo puede acceder directamente al servicio de metadatos, del mismo modo que una aplicaci\u00f3n de c\u00f3digo SSRF vulnerable tambi\u00e9n podr\u00eda acceder a \u00e9l.<\/p>\n
<\/a>Ejemplo 1: extracci\u00f3n de una cuenta de servicio por defecto de GCP<\/strong><\/h5>\nComo se muestra en la Figura\u00a01, la cuenta de servicio adjunta a la funci\u00f3n era la cuenta de servicio sin servidor predeterminada. En la Figura\u00a02 se muestra que el token de acceso devuelto pertenece a la misma cuenta de servicio.<\/p>\n![\"Captura]()
Figura 1. Informaci\u00f3n general sobre la funci\u00f3n, incluido un nombre de cuenta de servicio adjunto (la cuenta de servicio por defecto).<\/figcaption><\/figure>\n![\"Captura]()
Figura 2. Fragmento de c\u00f3digo de un comando utilizado para extraer el token de acceso a la cuenta de servicio, incluida la salida.<\/figcaption><\/figure>\n<\/a>Ejemplo 2: extracci\u00f3n de una cuenta de servicio personalizada de GCP<\/strong><\/h5>\nEn la Figura\u00a03 se muestra la cuenta de servicio personalizada que adjuntamos a la funci\u00f3n. En la Figura\u00a04 se muestra el token de acceso devuelto perteneciente a la cuenta de servicio personalizada. A continuaci\u00f3n, utilizamos el token devuelto para realizar operaciones en el entorno.<\/p>\n![\"Captura]()
Figura 3. Informaci\u00f3n general sobre la funci\u00f3n, incluido el nombre de la cuenta de servicio adjunta (una cuenta de servicio personalizada).<\/figcaption><\/figure>\n![\"Captura]()
Figura 4. Fragmento de c\u00f3digo de un comando utilizado para extraer el token de acceso a la cuenta de servicio, incluida la salida.<\/figcaption><\/figure>\nEn la Figura\u00a05 se muestra un ejemplo de comando para mostrar dep\u00f3sitos.<\/p>\n![\"Captura]()
Figura 5. Utilizar el token devuelto para mostrar los dep\u00f3sitos de una cuenta de servicio.<\/figcaption><\/figure>\nSi los atacantes pueden mostrar y leer el contenido de los dep\u00f3sitos en GCP, pueden acceder a archivos confidenciales como credenciales, copias de seguridad o configuraciones internas. Esto les permite robar datos, comprometer el sistema o moverse lateralmente dentro del entorno.<\/p>\n
Una vez que los atacantes obtienen un token de acceso para una cuenta de servicio con permisos de editor en GCP (como la cuenta de servicio Compute Engine predeterminada), pueden modificar, eliminar o crear recursos en la mayor\u00eda de los servicios. Esto incluye acceder a datos confidenciales, implementar cargas de trabajo maliciosas, escalar privilegios o interrumpir servicios. El acceso de editor otorga un control casi total sobre el proyecto.<\/p>\n
<\/a>Simulaci\u00f3n 2: uso de RCE para recuperar tokens almacenados en variables de entorno de funciones de AWS Lambda<\/h4>\nEn esta simulaci\u00f3n, accedimos a las variables de entorno de la funci\u00f3n Lambda y extrajimos de ella el AWS_ACCESS_KEY_ID<\/span>, AWS_SECRET_ACCESS_KEY<\/span> y AWS_SESSION_TOKEN<\/span>.<\/p>\nEn la Figura\u00a06 se muestra la salida del c\u00f3digo de la funci\u00f3n Lambda.<\/p>\n![\"Captura]()
Figura 6. Los valores de las variables de entorno devueltas.<\/figcaption><\/figure>\nEn la Figura\u00a07 se muestra la configuraci\u00f3n de las credenciales temporales de AWS obtenidas en el paso anterior (las variables de entorno de Lambda).<\/p>\n![\"Pantalla]()
Figura 7. Fragmento de c\u00f3digo de los comandos utilizados para mostrar los dep\u00f3sitos s3.<\/figcaption><\/figure>\nA continuaci\u00f3n, utilizamos el siguiente comando para mostrar todos los dep\u00f3sitos de S3 a los que puede acceder la sesi\u00f3n autenticada.<\/p>\n
aws s3 ls<\/pre>\n<\/a>Simulaci\u00f3n 3: uso de RCE para recuperar tokens del endpoint local de identidad de Azure Function<\/h4>\nEn esta simulaci\u00f3n, accedimos a las variables de entorno de Azure y extrajimos el IDENTITY_ENDPOINT<\/span> y el IDENTITY_HEADER<\/span> ejecutando comandos remotos. A continuaci\u00f3n, extrajimos el token de identidad gestionada del endpoint local de identidad, proporcionando estos par\u00e1metros que se muestran a continuaci\u00f3n en la Figura\u00a08:<\/p>\n\n- Recurso<\/li>\n
- api-version<\/span><\/li>\n
- X-IDENTITY-HEADER<\/span><\/li>\n<\/ul>\n
![\"Captura]()
Figura 8. Salida del script, que incluye el token de acceso.<\/figcaption><\/figure>\n<\/a>Detecci\u00f3n y prevenci\u00f3n de la filtraci\u00f3n de tokens<\/h2>\n<\/a>Detecci\u00f3n de la exfiltraci\u00f3n de tokens en entornos sin servidor<\/h3>\nLos mecanismos de detecci\u00f3n eficaces son fundamentales para identificar la exfiltraci\u00f3n de tokens en entornos sin servidor. Estos mecanismos se centran en las anomal\u00edas de comportamiento para se\u00f1alar actividades no autorizadas. A continuaci\u00f3n se exponen algunas de las mejores estrategias de detecci\u00f3n aplicadas en las principales plataformas en nube.<\/p>\n
La detecci\u00f3n consta de dos etapas:<\/p>\n
\n- Validaci\u00f3n de que la identidad est\u00e1 vinculada con una funci\u00f3n sin servidor.<\/li>\n
- Identificaci\u00f3n de comportamientos an\u00f3malos de las identidades sin servidor. Tal comportamiento podr\u00eda incluir lo siguiente:\n
\n- Direcciones IP de origen que no se ajustan al contexto en el que se ejecuta la funci\u00f3n, como direcciones de N\u00fameros de Sistema Aut\u00f3nomo (ASN) que no est\u00e1n asociadas con un proveedor de nube.<\/li>\n
- Identidades sin servidor que realizan peticiones con agentes de usuario sospechosos.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/a>Paso 1: identificaci\u00f3n de identidades sin servidor<\/h4>\nPara identificar las cuentas de servicio adjuntas a las funciones sin servidor en GCP, analizamos la secci\u00f3n serviceAccountDelegationInfo<\/span> en los registros. Esta informaci\u00f3n proporciona datos cruciales sobre la cadena de delegaci\u00f3n de cuentas de servicio. En concreto, cuando una cuenta de servicio se adjunta a una funci\u00f3n, delega su autoridad en una cuenta de servicio sin servidor por defecto:<\/p>\n\n- Agente del servicio de Cloud Run de Google (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>)<\/li>\n
- gcf-admin-robot.iam.gserviceaccount[.]com<\/span> (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com<\/span>)<\/li>\n<\/ul>\n
Estas cuentas de servicio ejecutan tareas en nombre de la funci\u00f3n.<\/p>\n
Por ejemplo, en la entrada de registro de la Figura\u00a09, vemos la cuenta de servicio personalizada que se adjunt\u00f3 a una funci\u00f3n (sa-test@<project-id>.iam.gserviceaccount[.]com<\/span>) que delega su autoridad en el agente de servicio Cloud Run.<\/p>\n![\"Captura]()
Figura 9. Entrada de registro con la cuenta de servicio personalizada.<\/figcaption><\/figure>\nEn la Figura\u00a09, el campo principalEmail<\/span> de authenticationInfo<\/span> especifica la cuenta de servicio que se est\u00e1 utilizando (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com<\/span>).<\/p>\nEl serviceAccountDelegationInfo<\/span> muestra el principal de la primera parte (en este caso: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>), indicando que la cuenta de servicio est\u00e1 operando dentro de un entorno sin servidor como Cloud Functions o Cloud Run.<\/p>\nUn enfoque eficaz para descubrir identidades sin servidor es crear perfiles de cuentas de servicio que hayan delegado previamente su autoridad en cuentas de servicio sin servidor por defecto. De este modo se garantiza que incluso si se adjuntan cuentas de servicio no predeterminadas a las funciones, estas se identifiquen.<\/p>\n
En AWS, las funciones Lambda se basan en roles IAM para el acceso seguro a los servicios de AWS. Estas funciones generan credenciales temporales. Podemos identificar la identidad Lambda por su nombre de rol.<\/p>\n
En Azure, las identidades gestionadas adjuntas a Azure Function Apps se utilizan para la autenticaci\u00f3n.<\/p>\n
<\/a>Paso 2: identificaci\u00f3n de comportamientos inusuales en las identidades sin servidor<\/h4>\nEn un entorno de nube seguro, las funciones sin servidor suelen estar destinadas a realizar tareas automatizadas y de alcance limitado, como responder a solicitudes de API o procesar eventos. Estas funciones no deben utilizarse de forma interactiva. Sin embargo, si los atacantes obtienen acceso al entorno de una funci\u00f3n sin servidor o a su identidad, podr\u00edan hacer un uso indebido para ejecutar comandos de interfaz de l\u00ednea de comandos (CLI) (por ejemplo, gcloud CLI<\/span> o curl<\/span>) para interactuar directamente con los recursos de la nube.<\/p>\nUna forma de detecci\u00f3n consiste en analizar el agente de usuario de las llamadas a la API. Si el agente de usuario coincide con herramientas CLI conocidas (por ejemplo, gcloud CLI<\/span>) o marcos de pruebas de penetraci\u00f3n, se marca como sospechoso, ya que las identidades sin servidor no deber\u00edan utilizar normalmente CLI. Esto indica una posible explotaci\u00f3n de los tokens del entorno o de la cuenta de servicio.<\/p>\nCabe destacar que este m\u00e9todo de identificar el uso remoto de tokens de autenticaci\u00f3n de funciones sin servidor seg\u00fan el agente de usuario no se puede realizar en Azure, ya que la informaci\u00f3n del agente de usuario no aparece en los registros de Azure.<\/p>\n
Otro enfoque para detectar el uso remoto de un token de identidad sin servidor consiste en correlacionar la ubicaci\u00f3n del uso de un token con rangos ASN de direcciones IP de proveedores de nube conocidos. Si una solicitud se origina en una direcci\u00f3n IP externa no asociada con el CSP, se activa una alerta que pone de manifiesto el posible uso no autorizado de tokens fuera del entorno de la nube.<\/p>\n
<\/a>Estrategias de prevenci\u00f3n<\/h3>\nAsegurar los tokens de autenticaci\u00f3n de funciones sin servidor requiere una combinaci\u00f3n de medidas proactivas, gesti\u00f3n de posturas y pr\u00e1cticas de seguridad de monitorizaci\u00f3n en tiempo de ejecuci\u00f3n para minimizar el riesgo de explotaci\u00f3n. En primer lugar, aplique el principio del menor privilegio asignando roles con los permisos m\u00ednimos necesarios para las funciones sin servidor. Esto reduce el impacto potencial del uso indebido de tokens.<\/p>\n
Adem\u00e1s, para proteger los entornos de ejecuci\u00f3n sin servidor en GCP y Azure, restrinja el acceso a IMDS configurando controles a nivel de red y aplicando mecanismos de validaci\u00f3n de solicitudes. Garantice una s\u00f3lida validaci\u00f3n y limpieza de entradas para evitar que los atacantes utilicen t\u00e9cnicas de explotaci\u00f3n como SSRF para acceder a metadatos confidenciales, tokens y otros recursos de la nube como API y bases de datos.<\/p>\n
<\/a>Conclusi\u00f3n<\/h2>\nLa computaci\u00f3n sin servidor es la opci\u00f3n preferida para el desarrollo de aplicaciones modernas porque ofrece ventajas significativas en escalabilidad, rentabilidad y gesti\u00f3n simplificada de la infraestructura.<\/p>\n
Las credenciales que permiten a estas funciones interactuar con los servicios en la nube son un elemento de seguridad cr\u00edtico y un objetivo prioritario para los atacantes. Comprometer estas credenciales puede acarrear graves consecuencias, como el acceso no autorizado a los recursos de la nube y la filtraci\u00f3n de datos.<\/p>\n
La implementaci\u00f3n de protecciones proactivas de gesti\u00f3n de posturas y supervisi\u00f3n en tiempo de ejecuci\u00f3n es una estrategia crucial para proteger los entornos en nube.<\/p>\n
Las organizaciones pueden proteger mejor sus entornos sin servidor mediante:<\/p>\n
\n- Comprender la mec\u00e1nica de las credenciales sin servidor y las mejores pr\u00e1cticas para aprovisionarlas y administrarlas en AWS, Azure y GCP<\/a>.<\/li>\n
- Reconocimiento de vectores de ataque comunes, como la exfiltraci\u00f3n de tokens mediante la explotaci\u00f3n de IMDS o el acceso a variables de entorno.<\/li>\n<\/ul>\n
<\/a>Protecci\u00f3n y mitigaci\u00f3n de Palo Alto Networks<\/h2>\nLos clientes de Palo Alto Networks est\u00e1n mejor protegidos frente a las amenazas mencionadas gracias a los siguientes productos:<\/p>\n
Si cree que puede haber resultado vulnerado o tiene un problema urgente, p\u00f3ngase en contacto con el equipo de respuesta ante incidentes de Unit\u00a042<\/a> o llame al:<\/p>\n\n- Tel\u00e9fono gratuito para Norteam\u00e9rica: +866.486.4842 (+866.4.UNIT42)<\/li>\n
- EUROPA, ORIENTE MEDIO Y \u00c1FRICA: +31.20.299.3130<\/li>\n
- APAC: +65.6983.8730<\/li>\n
- Jap\u00f3n: +81.50.1790.0200<\/li>\n<\/ul>\n
Palo Alto Networks ha compartido estos resultados con nuestros compa\u00f1eros de Cyber Threat Alliance (CTA). Los miembros de CTA utilizan esta inteligencia para implementar r\u00e1pidamente medidas de protecci\u00f3n para sus clientes y desarticular sistem\u00e1ticamente a los ciberdelincuentes. M\u00e1s informaci\u00f3n sobre Cyber Threat Alliance<\/a>.<\/p>\n<\/a>Recursos adicionales<\/h2>\n\n- Trabajar con variables de entorno de Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Protecci\u00f3n de las variables de entorno de Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Administraci\u00f3n de permisos en AWS Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Funci\u00f3n Identidad<\/a>: Google Cloud<\/li>\n
- \u00bfQu\u00e9 son las identidades gestionadas para los recursos de Azure?<\/a>: Microsoft Learn<\/li>\n
- Protecci\u00f3n de Azure Functions<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es AWS Secrets Manager?<\/a>: gu\u00eda del usuario de AWS Secret Manager<\/li>\n
- Conceptos b\u00e1sicos de Azure Key Vault<\/a>: Microsoft Learn<\/li>\n
- Descripci\u00f3n general de Secret Manager<\/a>: documentaci\u00f3n de Google Cloud Secret Manager<\/li>\n
- \u00bfQu\u00e9 es la gesti\u00f3n de identidades y accesos (IAM)?<\/a>: Microsoft Security<\/li>\n
- \u00bfQu\u00e9 son las identidades gestionadas para los recursos de Azure?<\/a>: Microsoft Learn<\/li>\n
- Identidad y control de acceso<\/a>: introducci\u00f3n a la seguridad de AWS Whitepaper de AWS<\/li>\n
- Credenciales de la cuenta de servicio<\/a>: documentaci\u00f3n de Google Cloud IAM<\/li>\n
- Credenciales de seguridad temporales en IAM<\/a>: gu\u00eda del usuario de la gesti\u00f3n de acceso e identidades de AWS<\/li>\n
- Referencia de la API del servicio de tokens de seguridad de AWS<\/a>: documentaci\u00f3n del servicio de tokens de seguridad de AWS<\/li>\n
- Instancias de Compute Engine<\/a>: documentaci\u00f3n sobre Google Cloud<\/li>\n
- Proyectos de Google Cloud<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Cuentas de servicio gestionadas por el usuario<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Comparaci\u00f3n de las funciones de Cloud Run<\/a>: documentaci\u00f3n de Cloud Run de Google<\/li>\n
- Cuentas de servicio por defecto<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Referencia de endpoint REST<\/a>: identidades gestionadas para App Service y Azure Functions<\/li>\n
- Variables de entorno y configuraci\u00f3n de aplicaciones en Azure App Service<\/a>: Microsoft Learn<\/li>\n
- C\u00f3mo utilizar identidades gestionadas para recursos Azure en una m\u00e1quina virtual Azure para adquirir un token de acceso<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es Microsoft Entra ID?<\/a>: Microsoft Entra ID<\/li>\n
- Acerca de Azure Key Vault<\/a>: Microsoft Learn<\/li>\n
- Autorizar el acceso a blobs mediante Microsoft Entra ID<\/a>: Microsoft Learn<\/li>\n
- Descripci\u00f3n general de la cuenta de almacenamiento<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es el control de acceso basado en rol de Azure (RBAC)?<\/a>: Microsoft Learn<\/li>\n
- Pol\u00edticas de acceso a recursos espec\u00edficos<\/a>: Microsoft Learn<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.<\/p>\n","protected":false},"author":366,"featured_media":143167,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8838,8730],"tags":[9291,9329,9330,8861],"product_categories":[8932,8933,8890],"coauthors":[4194],"class_list":["post-146596","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-threat-research-es-la","category-cloud-cybersecurity-research-es-la","tag-aws-es-la","tag-google-cloud-es-la","tag-microsoft-azure-es-la","tag-serverless-es-la","product_categories-cortex-es-la","product_categories-cortex-cloud-es-la","product_categories-unit-42-incident-response-es-la"],"yoast_head":"\n
Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n<\/title>\n<meta name=\"description\" content=\"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:locale\" content=\"es_LA\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n\" \/>\n<meta property=\"og:description\" content=\"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:site_name\" content=\"Unit 42\" \/>\n<meta property=\"article:published_time\" content=\"2025-06-13T17:16:43+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-07-11T17:28:42+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"900\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Zohar Zigdon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","og_locale":"es_LA","og_type":"article","og_title":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","og_description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","og_url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","og_site_name":"Unit 42","article_published_time":"2025-06-13T17:16:43+00:00","article_modified_time":"2025-07-11T17:28:42+00:00","og_image":[{"width":1920,"height":900,"url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","type":"image\/jpeg"}],"author":"Zohar Zigdon","twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#article","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"},"author":{"name":"Sheida Azimi","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"headline":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","datePublished":"2025-06-13T17:16:43+00:00","dateModified":"2025-07-11T17:28:42+00:00","mainEntityOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"},"wordCount":4687,"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","keywords":["AWS","Google Cloud","Microsoft Azure","serverless"],"articleSection":["Investigaci\u00f3n de amenazas","Investigaci\u00f3n de ciberseguridad en la nube"],"inLanguage":"es"},{"@type":"WebPage","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","name":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","datePublished":"2025-06-13T17:16:43+00:00","dateModified":"2025-07-11T17:28:42+00:00","author":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","breadcrumb":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"]}]},{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","width":1920,"height":900,"caption":"Pictorial representation of serverless tokens in the cloud. East Asian woman examining data on multiple screens in a high-tech environment, surrounded by digital graphics and code."},{"@type":"BreadcrumbList","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/unit42.paloaltonetworks.com\/"},{"@type":"ListItem","position":2,"name":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n"}]},{"@type":"WebSite","@id":"https:\/\/unit42.paloaltonetworks.com\/#website","url":"https:\/\/unit42.paloaltonetworks.com\/","name":"Unit 42","description":"Palo Alto Networks","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/unit42.paloaltonetworks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"es"},{"@type":"Person","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639","name":"Sheida Azimi","image":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/image\/4ffb3c2d260a0150fb91b3715442f8b3","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","caption":"Sheida Azimi"},"url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/author\/sheida-azimi\/"}]}},"_links":{"self":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/users\/366"}],"replies":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/comments?post=146596"}],"version-history":[{"count":4,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596\/revisions"}],"predecessor-version":[{"id":146700,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596\/revisions\/146700"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/media\/143167"}],"wp:attachment":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/media?parent=146596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/categories?post=146596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/tags?post=146596"},{"taxonomy":"product_categories","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/product_categories?post=146596"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/coauthors?post=146596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
<\/a>AWS Lambda<\/strong><\/h3>\nEl servicio IAM de AWS permite crear y administrar usuarios, permisos, grupos y roles. El servicio es responsable de administrar las identidades y su nivel de acceso a las cuentas y servicios de AWS, as\u00ed como del control de diversas caracter\u00edsticas dentro de una cuenta de AWS.<\/p>\n
Las funciones sin servidor usan roles de Lambda, que no tienen permisos por defecto; se deben usar pol\u00edticas de IAM para administrar los permisos y asegurar el acceso a otros servicios de AWS.<\/p>\n
Para simplificar la administraci\u00f3n de permisos, AWS proporciona pol\u00edticas administradas (como AWSLambdaBasicExecutionRole<\/span>) que los desarrolladores suelen adjuntar a estas funciones para habilitar r\u00e1pidamente la funcionalidad b\u00e1sica.<\/p>\nCuando se asocia un rol de IAM a una funci\u00f3n de Lambda, el servicio de tokens de seguridad (STS)<\/a> de AWS genera autom\u00e1ticamente credenciales de seguridad temporales<\/a> para ese rol.<\/p>\nSe trata de una forma segura de acceder a las credenciales en tiempo de ejecuci\u00f3n sin los riesgos asociados con las credenciales codificadas a largo plazo.<\/p>\n
Estas credenciales se rigen por los permisos definidos en la pol\u00edtica de acceso asociada con el rol. Incluyen un identificador de clave de acceso, una clave de acceso secreta y un token de sesi\u00f3n.<\/p>\n
En tiempo de ejecuci\u00f3n, el servicio en tiempo de ejecuci\u00f3n de Lambda carga las credenciales de rol en el entorno de ejecuci\u00f3n de la funci\u00f3n y las almacena como variables de entorno, por ejemplo, AWS_ACCESS_KEY_ID<\/span>, AWS_SECRET_ACCESS_KEY<\/span> y AWS_SESSION_TOKEN<\/span>. Estas variables son accesibles al c\u00f3digo de la funci\u00f3n durante el tiempo de ejecuci\u00f3n, lo que permite a la funci\u00f3n interactuar de forma segura con otros servicios de AWS.<\/p>\n<\/a>Google Cloud Functions<\/strong><\/h3>\nGoogle Cloud Functions utiliza tokens de cuenta de servicio para autenticar y autorizar el acceso a otros servicios de Google Cloud. Una cuenta de servicio es una cuenta de Google especializada que est\u00e1 vinculada con un proyecto<\/a> y representa una identidad no humana, en lugar de representar a un usuario individual.<\/p>\nAl implementar una Cloud Function, los desarrolladores pueden adjuntar la funci\u00f3n a una cuenta de servicio personalizada o a la cuenta de servicio por defecto<\/a>. Cuando se utiliza una cuenta de servicio personalizada, los desarrolladores pueden asignar roles IAM espec\u00edficos para definir los permisos exactos que requiere la funci\u00f3n para realizar sus tareas.<\/p>\nLas cuentas de servicio por defecto son cuentas gestionadas por el usuario<\/a> que Google Cloud crea autom\u00e1ticamente cuando los usuarios habilitan servicios espec\u00edficos. Por defecto, Google Cloud Functions utiliza diferentes cuentas de servicio en funci\u00f3n de la generaci\u00f3n<\/a>:<\/p>\n\n- Cloud Run functions de primera generaci\u00f3n utilizan la cuenta de servicio por defecto de App Engine (<project_id>@appspot.gserviceaccount.com<\/span>)<\/li>\n
- Cloud Run functions de segunda generaci\u00f3n utilizan la cuenta de servicio por defecto de Compute (<project_number>- compute@developer.gserviceaccount.com<\/span>)<\/li>\n<\/ul>\n
A estas cuentas de servicio por defecto se les conceden permisos de editor cuando los desarrolladores se incorporan a GCP sin una organizaci\u00f3n, lo que les permite crear, modificar y eliminar recursos dentro del proyecto. Sin embargo, en los proyectos que dependen de una organizaci\u00f3n GCP, las cuentas de servicio por defecto se crean sin ning\u00fan permiso. En esos casos, solo pueden realizar acciones permitidas expl\u00edcitamente por los roles que se les han asignado.<\/p>\n
Aunque una funci\u00f3n de GCP opera en un entorno sin servidor, cuando se trata de acceder a las credenciales asociadas con la funci\u00f3n, se comporta de manera similar a un servidor tradicional, como una instancia de m\u00e1quina virtual (VM), recuperando sus tokens de cuenta de servicio del servidor de metadatos de instancia (IMDS)<\/a> en tiempo de ejecuci\u00f3n. El IMDS en hxxp:\/\/metadata.google[.]internal\/<\/span> proporciona tokens de acceso de corta duraci\u00f3n para la cuenta de servicio asociada con la funci\u00f3n. Estos tokens permiten a la funci\u00f3n autenticarse en los servicios de GCP.<\/p>\n<\/a>Azure Functions<\/strong><\/h3>\nLas identidades gestionadas de Azure proporcionan una forma segura y transparente para que los recursos de Azure se autentiquen e interact\u00faen con otros servicios de Azure sin necesidad de utilizar credenciales codificadas. Del mismo modo que los servicios de funciones de AWS y GCP, estas identidades eliminan los riesgos asociados con la gesti\u00f3n de credenciales en el c\u00f3digo.<\/p>\n
Las identidades gestionadas asignadas por el sistema se vinculan a un \u00fanico recurso y se eliminan autom\u00e1ticamente cuando se elimina el recurso. Por otro lado, las identidades gestionadas asignadas por el usuario son recursos independientes que pueden asignarse a diversos servicios, lo que ofrece m\u00e1s flexibilidad para escenarios de autenticaci\u00f3n compartida.<\/p>\n
Una funci\u00f3n de Azure con una identidad gestionada adjunta debe utilizar su token de identidad gestionada para autenticarse en un recurso de Azure. El proceso de autenticaci\u00f3n paso a paso es el siguiente:<\/p>\n
\n- La funci\u00f3n consulta sus variables de entorno para recuperar los valores de IDENTITY_ENDPOINT<\/span> e IDENTITY_HEADER<\/span>.\n
\n- IDENTITY_ENDPOINT<\/span>: Una variable de entorno<\/a> que contiene la direcci\u00f3n del endpoint local de identidad gestionada proporcionado por Azure. Se trata de una URL local desde la que una aplicaci\u00f3n puede solicitar tokens.<\/li>\n
- IDENTITY_HEADER<\/span>: Par\u00e1metro obligatorio al consultar el endpoint local de identidad gestionada. Esta cabecera se utiliza para mitigar los ataques SSRF.<\/li>\n<\/ul>\n<\/li>\n
- La funci\u00f3n env\u00eda una solicitud HTTP GET al endpoint local de identidad gestionada con el IDENTITY_HEADER<\/span> incluido como cabecera HTTP. (Para obtener m\u00e1s informaci\u00f3n sobre la estructura de la solicitud, consulte la documentaci\u00f3n de Azure sobre la adquisici\u00f3n de tokens para App Services<\/a>)<\/li>\n
- Microsoft Entra ID<\/a> (anteriormente Azure Active Directory) verifica la identidad de la funci\u00f3n y emite un token OAuth 2.0 temporal que se asigna espec\u00edficamente al recurso de destino.<\/li>\n
- La funci\u00f3n incluye el token emitido en su solicitud al recurso Azure (p. ej., Azure Key Vault<\/a>, Storage Account<\/a>).<\/li>\n
- El recurso Azure valida el token y comprueba los permisos de la funci\u00f3n mediante el control de acceso basado en roles<\/a> o pol\u00edticas de acceso espec\u00edficas del recurso<\/a>.<\/li>\n<\/ul>\n
Si est\u00e1 autorizado, el recurso concede acceso para realizar la operaci\u00f3n solicitada. Esto garantiza una autenticaci\u00f3n segura y perfecta sin necesidad de utilizar secretos codificados en el c\u00f3digo.<\/p>\n
<\/a>Vectores de ataque de extracci\u00f3n de tokens<\/h2>\nEn esta secci\u00f3n se analizan los riesgos y amenazas que conlleva el uso de funciones sin servidor. Al desarrollar y configurar funciones, los desarrolladores de aplicaciones deben asegurarse de proteger esas funciones contra ataques como SSRF y RCE. En ausencia de dicha seguridad, los atacantes podr\u00edan manipular las funciones sin servidor que son vulnerables a SSRF, haciendo que las funciones env\u00eden solicitudes no autorizadas a los servicios internos. Esto puede conducir a un acceso no intencionado o a la exposici\u00f3n de informaci\u00f3n confidencial dentro del sistema, como tokens de acceso, contenido de bases de datos internas o configuraciones de servicios. Es importante subrayar que estos riesgos surgen principalmente cuando las funciones son p\u00fablicas o procesan entradas de usuarios externos y otras fuentes.<\/p>\n
En los ataques SSRF, un atacante enga\u00f1a a un servidor (como una funci\u00f3n sin servidor) para que realice peticiones HTTP a recursos internos o externos a los que el atacante no deber\u00eda tener acceso. Dado que es el propio servidor el que realiza la petici\u00f3n, puede acceder a servicios internos que no est\u00e1n expuestos a Internet. Una funci\u00f3n vulnerable sin servidor toma una URL como entrada y obtiene datos de ella.<\/p>\n
En GCP, SSRF puede utilizarse para acceder al IMDS en hxxp:\/\/metadata.google[.]internal\/<\/span>, extrayendo tokens de cuenta de servicio de corta duraci\u00f3n. Un atacante puede entonces aprovechar estos tokens para hacerse pasar por la funci\u00f3n y realizar acciones no autorizadas dentro de los permisos de su rol IAM. Las vulnerabilidades de ejecuci\u00f3n remota de c\u00f3digo permiten a los atacantes ejecutar c\u00f3digo arbitrario dentro del entorno de una funci\u00f3n.<\/p>\nPara AWS Lambda, los ataques RCE podr\u00edan exponer credenciales temporales almacenadas en variables de entorno, como AWS_ACCESS_KEY_ID<\/span> y AWS_SESSION_TOKEN<\/span>.<\/p>\nEs esencial se\u00f1alar que estos vectores de ataque no son fallos inherentes a las propias plataformas en nube, sino que surgen de c\u00f3digo inseguro escrito por desarrolladores de aplicaciones que podr\u00edan introducir vulnerabilidades, como SSRF o RCE. Los desarrolladores de aplicaciones pueden mitigar estos riesgos mediante la aplicaci\u00f3n de pr\u00e1cticas de codificaci\u00f3n seguras, como la validaci\u00f3n de entradas.<\/p>\n
<\/a>Simulaciones de vectores de ataque<\/strong><\/h3>\nEn las siguientes simulaciones se muestran posibles formas en las que los atacantes podr\u00edan extraer tokens de autenticaci\u00f3n de funciones sin servidor y utilizarlos para actividades maliciosas en diferentes proveedores de servicios en la nube (CSP). Estos ataques podr\u00edan aprovechar el c\u00f3digo de funci\u00f3n inseguro implementado por los desarrolladores de aplicaciones.<\/p>\n
<\/a>Simulaci\u00f3n 1: acceso directo al IMDS desde la funci\u00f3n GCP<\/h4>\nPara llevar a cabo esta simulaci\u00f3n, implementamos dos funciones de Cloud Run de Google que acceden al servicio de metadatos de funciones y extraen los tokens de las dos cuentas de servicio adjuntas diferentes de la siguiente ruta:<\/p>\n
\n- hxxp[:\/\/]metadata.google[.]internal\/computeMetadata\/v1\/instance\/service-accounts\/default\/token<\/span><\/li>\n<\/ul>\n
En el primer ejemplo se muestra la extracci\u00f3n de una cuenta de servicio por defecto. En el segundo ejemplo se muestra la extracci\u00f3n de una cuenta de servicio personalizada. En estos ejemplos se muestra c\u00f3mo el c\u00f3digo puede acceder directamente al servicio de metadatos, del mismo modo que una aplicaci\u00f3n de c\u00f3digo SSRF vulnerable tambi\u00e9n podr\u00eda acceder a \u00e9l.<\/p>\n
<\/a>Ejemplo 1: extracci\u00f3n de una cuenta de servicio por defecto de GCP<\/strong><\/h5>\nComo se muestra en la Figura\u00a01, la cuenta de servicio adjunta a la funci\u00f3n era la cuenta de servicio sin servidor predeterminada. En la Figura\u00a02 se muestra que el token de acceso devuelto pertenece a la misma cuenta de servicio.<\/p>\n![\"Captura]()
Figura 1. Informaci\u00f3n general sobre la funci\u00f3n, incluido un nombre de cuenta de servicio adjunto (la cuenta de servicio por defecto).<\/figcaption><\/figure>\n![\"Captura]()
Figura 2. Fragmento de c\u00f3digo de un comando utilizado para extraer el token de acceso a la cuenta de servicio, incluida la salida.<\/figcaption><\/figure>\n<\/a>Ejemplo 2: extracci\u00f3n de una cuenta de servicio personalizada de GCP<\/strong><\/h5>\nEn la Figura\u00a03 se muestra la cuenta de servicio personalizada que adjuntamos a la funci\u00f3n. En la Figura\u00a04 se muestra el token de acceso devuelto perteneciente a la cuenta de servicio personalizada. A continuaci\u00f3n, utilizamos el token devuelto para realizar operaciones en el entorno.<\/p>\n![\"Captura]()
Figura 3. Informaci\u00f3n general sobre la funci\u00f3n, incluido el nombre de la cuenta de servicio adjunta (una cuenta de servicio personalizada).<\/figcaption><\/figure>\n![\"Captura]()
Figura 4. Fragmento de c\u00f3digo de un comando utilizado para extraer el token de acceso a la cuenta de servicio, incluida la salida.<\/figcaption><\/figure>\nEn la Figura\u00a05 se muestra un ejemplo de comando para mostrar dep\u00f3sitos.<\/p>\n![\"Captura]()
Figura 5. Utilizar el token devuelto para mostrar los dep\u00f3sitos de una cuenta de servicio.<\/figcaption><\/figure>\nSi los atacantes pueden mostrar y leer el contenido de los dep\u00f3sitos en GCP, pueden acceder a archivos confidenciales como credenciales, copias de seguridad o configuraciones internas. Esto les permite robar datos, comprometer el sistema o moverse lateralmente dentro del entorno.<\/p>\n
Una vez que los atacantes obtienen un token de acceso para una cuenta de servicio con permisos de editor en GCP (como la cuenta de servicio Compute Engine predeterminada), pueden modificar, eliminar o crear recursos en la mayor\u00eda de los servicios. Esto incluye acceder a datos confidenciales, implementar cargas de trabajo maliciosas, escalar privilegios o interrumpir servicios. El acceso de editor otorga un control casi total sobre el proyecto.<\/p>\n
<\/a>Simulaci\u00f3n 2: uso de RCE para recuperar tokens almacenados en variables de entorno de funciones de AWS Lambda<\/h4>\nEn esta simulaci\u00f3n, accedimos a las variables de entorno de la funci\u00f3n Lambda y extrajimos de ella el AWS_ACCESS_KEY_ID<\/span>, AWS_SECRET_ACCESS_KEY<\/span> y AWS_SESSION_TOKEN<\/span>.<\/p>\nEn la Figura\u00a06 se muestra la salida del c\u00f3digo de la funci\u00f3n Lambda.<\/p>\n![\"Captura]()
Figura 6. Los valores de las variables de entorno devueltas.<\/figcaption><\/figure>\nEn la Figura\u00a07 se muestra la configuraci\u00f3n de las credenciales temporales de AWS obtenidas en el paso anterior (las variables de entorno de Lambda).<\/p>\n![\"Pantalla]()
Figura 7. Fragmento de c\u00f3digo de los comandos utilizados para mostrar los dep\u00f3sitos s3.<\/figcaption><\/figure>\nA continuaci\u00f3n, utilizamos el siguiente comando para mostrar todos los dep\u00f3sitos de S3 a los que puede acceder la sesi\u00f3n autenticada.<\/p>\n
aws s3 ls<\/pre>\n<\/a>Simulaci\u00f3n 3: uso de RCE para recuperar tokens del endpoint local de identidad de Azure Function<\/h4>\nEn esta simulaci\u00f3n, accedimos a las variables de entorno de Azure y extrajimos el IDENTITY_ENDPOINT<\/span> y el IDENTITY_HEADER<\/span> ejecutando comandos remotos. A continuaci\u00f3n, extrajimos el token de identidad gestionada del endpoint local de identidad, proporcionando estos par\u00e1metros que se muestran a continuaci\u00f3n en la Figura\u00a08:<\/p>\n\n- Recurso<\/li>\n
- api-version<\/span><\/li>\n
- X-IDENTITY-HEADER<\/span><\/li>\n<\/ul>\n
![\"Captura]()
Figura 8. Salida del script, que incluye el token de acceso.<\/figcaption><\/figure>\n<\/a>Detecci\u00f3n y prevenci\u00f3n de la filtraci\u00f3n de tokens<\/h2>\n<\/a>Detecci\u00f3n de la exfiltraci\u00f3n de tokens en entornos sin servidor<\/h3>\nLos mecanismos de detecci\u00f3n eficaces son fundamentales para identificar la exfiltraci\u00f3n de tokens en entornos sin servidor. Estos mecanismos se centran en las anomal\u00edas de comportamiento para se\u00f1alar actividades no autorizadas. A continuaci\u00f3n se exponen algunas de las mejores estrategias de detecci\u00f3n aplicadas en las principales plataformas en nube.<\/p>\n
La detecci\u00f3n consta de dos etapas:<\/p>\n
\n- Validaci\u00f3n de que la identidad est\u00e1 vinculada con una funci\u00f3n sin servidor.<\/li>\n
- Identificaci\u00f3n de comportamientos an\u00f3malos de las identidades sin servidor. Tal comportamiento podr\u00eda incluir lo siguiente:\n
\n- Direcciones IP de origen que no se ajustan al contexto en el que se ejecuta la funci\u00f3n, como direcciones de N\u00fameros de Sistema Aut\u00f3nomo (ASN) que no est\u00e1n asociadas con un proveedor de nube.<\/li>\n
- Identidades sin servidor que realizan peticiones con agentes de usuario sospechosos.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/a>Paso 1: identificaci\u00f3n de identidades sin servidor<\/h4>\nPara identificar las cuentas de servicio adjuntas a las funciones sin servidor en GCP, analizamos la secci\u00f3n serviceAccountDelegationInfo<\/span> en los registros. Esta informaci\u00f3n proporciona datos cruciales sobre la cadena de delegaci\u00f3n de cuentas de servicio. En concreto, cuando una cuenta de servicio se adjunta a una funci\u00f3n, delega su autoridad en una cuenta de servicio sin servidor por defecto:<\/p>\n\n- Agente del servicio de Cloud Run de Google (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>)<\/li>\n
- gcf-admin-robot.iam.gserviceaccount[.]com<\/span> (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com<\/span>)<\/li>\n<\/ul>\n
Estas cuentas de servicio ejecutan tareas en nombre de la funci\u00f3n.<\/p>\n
Por ejemplo, en la entrada de registro de la Figura\u00a09, vemos la cuenta de servicio personalizada que se adjunt\u00f3 a una funci\u00f3n (sa-test@<project-id>.iam.gserviceaccount[.]com<\/span>) que delega su autoridad en el agente de servicio Cloud Run.<\/p>\n![\"Captura]()
Figura 9. Entrada de registro con la cuenta de servicio personalizada.<\/figcaption><\/figure>\nEn la Figura\u00a09, el campo principalEmail<\/span> de authenticationInfo<\/span> especifica la cuenta de servicio que se est\u00e1 utilizando (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com<\/span>).<\/p>\nEl serviceAccountDelegationInfo<\/span> muestra el principal de la primera parte (en este caso: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>), indicando que la cuenta de servicio est\u00e1 operando dentro de un entorno sin servidor como Cloud Functions o Cloud Run.<\/p>\nUn enfoque eficaz para descubrir identidades sin servidor es crear perfiles de cuentas de servicio que hayan delegado previamente su autoridad en cuentas de servicio sin servidor por defecto. De este modo se garantiza que incluso si se adjuntan cuentas de servicio no predeterminadas a las funciones, estas se identifiquen.<\/p>\n
En AWS, las funciones Lambda se basan en roles IAM para el acceso seguro a los servicios de AWS. Estas funciones generan credenciales temporales. Podemos identificar la identidad Lambda por su nombre de rol.<\/p>\n
En Azure, las identidades gestionadas adjuntas a Azure Function Apps se utilizan para la autenticaci\u00f3n.<\/p>\n
<\/a>Paso 2: identificaci\u00f3n de comportamientos inusuales en las identidades sin servidor<\/h4>\nEn un entorno de nube seguro, las funciones sin servidor suelen estar destinadas a realizar tareas automatizadas y de alcance limitado, como responder a solicitudes de API o procesar eventos. Estas funciones no deben utilizarse de forma interactiva. Sin embargo, si los atacantes obtienen acceso al entorno de una funci\u00f3n sin servidor o a su identidad, podr\u00edan hacer un uso indebido para ejecutar comandos de interfaz de l\u00ednea de comandos (CLI) (por ejemplo, gcloud CLI<\/span> o curl<\/span>) para interactuar directamente con los recursos de la nube.<\/p>\nUna forma de detecci\u00f3n consiste en analizar el agente de usuario de las llamadas a la API. Si el agente de usuario coincide con herramientas CLI conocidas (por ejemplo, gcloud CLI<\/span>) o marcos de pruebas de penetraci\u00f3n, se marca como sospechoso, ya que las identidades sin servidor no deber\u00edan utilizar normalmente CLI. Esto indica una posible explotaci\u00f3n de los tokens del entorno o de la cuenta de servicio.<\/p>\nCabe destacar que este m\u00e9todo de identificar el uso remoto de tokens de autenticaci\u00f3n de funciones sin servidor seg\u00fan el agente de usuario no se puede realizar en Azure, ya que la informaci\u00f3n del agente de usuario no aparece en los registros de Azure.<\/p>\n
Otro enfoque para detectar el uso remoto de un token de identidad sin servidor consiste en correlacionar la ubicaci\u00f3n del uso de un token con rangos ASN de direcciones IP de proveedores de nube conocidos. Si una solicitud se origina en una direcci\u00f3n IP externa no asociada con el CSP, se activa una alerta que pone de manifiesto el posible uso no autorizado de tokens fuera del entorno de la nube.<\/p>\n
<\/a>Estrategias de prevenci\u00f3n<\/h3>\nAsegurar los tokens de autenticaci\u00f3n de funciones sin servidor requiere una combinaci\u00f3n de medidas proactivas, gesti\u00f3n de posturas y pr\u00e1cticas de seguridad de monitorizaci\u00f3n en tiempo de ejecuci\u00f3n para minimizar el riesgo de explotaci\u00f3n. En primer lugar, aplique el principio del menor privilegio asignando roles con los permisos m\u00ednimos necesarios para las funciones sin servidor. Esto reduce el impacto potencial del uso indebido de tokens.<\/p>\n
Adem\u00e1s, para proteger los entornos de ejecuci\u00f3n sin servidor en GCP y Azure, restrinja el acceso a IMDS configurando controles a nivel de red y aplicando mecanismos de validaci\u00f3n de solicitudes. Garantice una s\u00f3lida validaci\u00f3n y limpieza de entradas para evitar que los atacantes utilicen t\u00e9cnicas de explotaci\u00f3n como SSRF para acceder a metadatos confidenciales, tokens y otros recursos de la nube como API y bases de datos.<\/p>\n
<\/a>Conclusi\u00f3n<\/h2>\nLa computaci\u00f3n sin servidor es la opci\u00f3n preferida para el desarrollo de aplicaciones modernas porque ofrece ventajas significativas en escalabilidad, rentabilidad y gesti\u00f3n simplificada de la infraestructura.<\/p>\n
Las credenciales que permiten a estas funciones interactuar con los servicios en la nube son un elemento de seguridad cr\u00edtico y un objetivo prioritario para los atacantes. Comprometer estas credenciales puede acarrear graves consecuencias, como el acceso no autorizado a los recursos de la nube y la filtraci\u00f3n de datos.<\/p>\n
La implementaci\u00f3n de protecciones proactivas de gesti\u00f3n de posturas y supervisi\u00f3n en tiempo de ejecuci\u00f3n es una estrategia crucial para proteger los entornos en nube.<\/p>\n
Las organizaciones pueden proteger mejor sus entornos sin servidor mediante:<\/p>\n
\n- Comprender la mec\u00e1nica de las credenciales sin servidor y las mejores pr\u00e1cticas para aprovisionarlas y administrarlas en AWS, Azure y GCP<\/a>.<\/li>\n
- Reconocimiento de vectores de ataque comunes, como la exfiltraci\u00f3n de tokens mediante la explotaci\u00f3n de IMDS o el acceso a variables de entorno.<\/li>\n<\/ul>\n
<\/a>Protecci\u00f3n y mitigaci\u00f3n de Palo Alto Networks<\/h2>\nLos clientes de Palo Alto Networks est\u00e1n mejor protegidos frente a las amenazas mencionadas gracias a los siguientes productos:<\/p>\n
Si cree que puede haber resultado vulnerado o tiene un problema urgente, p\u00f3ngase en contacto con el equipo de respuesta ante incidentes de Unit\u00a042<\/a> o llame al:<\/p>\n\n- Tel\u00e9fono gratuito para Norteam\u00e9rica: +866.486.4842 (+866.4.UNIT42)<\/li>\n
- EUROPA, ORIENTE MEDIO Y \u00c1FRICA: +31.20.299.3130<\/li>\n
- APAC: +65.6983.8730<\/li>\n
- Jap\u00f3n: +81.50.1790.0200<\/li>\n<\/ul>\n
Palo Alto Networks ha compartido estos resultados con nuestros compa\u00f1eros de Cyber Threat Alliance (CTA). Los miembros de CTA utilizan esta inteligencia para implementar r\u00e1pidamente medidas de protecci\u00f3n para sus clientes y desarticular sistem\u00e1ticamente a los ciberdelincuentes. M\u00e1s informaci\u00f3n sobre Cyber Threat Alliance<\/a>.<\/p>\n<\/a>Recursos adicionales<\/h2>\n\n- Trabajar con variables de entorno de Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Protecci\u00f3n de las variables de entorno de Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Administraci\u00f3n de permisos en AWS Lambda<\/a>: gu\u00eda de desarrollo de AWS Lambda<\/li>\n
- Funci\u00f3n Identidad<\/a>: Google Cloud<\/li>\n
- \u00bfQu\u00e9 son las identidades gestionadas para los recursos de Azure?<\/a>: Microsoft Learn<\/li>\n
- Protecci\u00f3n de Azure Functions<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es AWS Secrets Manager?<\/a>: gu\u00eda del usuario de AWS Secret Manager<\/li>\n
- Conceptos b\u00e1sicos de Azure Key Vault<\/a>: Microsoft Learn<\/li>\n
- Descripci\u00f3n general de Secret Manager<\/a>: documentaci\u00f3n de Google Cloud Secret Manager<\/li>\n
- \u00bfQu\u00e9 es la gesti\u00f3n de identidades y accesos (IAM)?<\/a>: Microsoft Security<\/li>\n
- \u00bfQu\u00e9 son las identidades gestionadas para los recursos de Azure?<\/a>: Microsoft Learn<\/li>\n
- Identidad y control de acceso<\/a>: introducci\u00f3n a la seguridad de AWS Whitepaper de AWS<\/li>\n
- Credenciales de la cuenta de servicio<\/a>: documentaci\u00f3n de Google Cloud IAM<\/li>\n
- Credenciales de seguridad temporales en IAM<\/a>: gu\u00eda del usuario de la gesti\u00f3n de acceso e identidades de AWS<\/li>\n
- Referencia de la API del servicio de tokens de seguridad de AWS<\/a>: documentaci\u00f3n del servicio de tokens de seguridad de AWS<\/li>\n
- Instancias de Compute Engine<\/a>: documentaci\u00f3n sobre Google Cloud<\/li>\n
- Proyectos de Google Cloud<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Cuentas de servicio gestionadas por el usuario<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Comparaci\u00f3n de las funciones de Cloud Run<\/a>: documentaci\u00f3n de Cloud Run de Google<\/li>\n
- Cuentas de servicio por defecto<\/a>: documentaci\u00f3n de Google Cloud<\/li>\n
- Referencia de endpoint REST<\/a>: identidades gestionadas para App Service y Azure Functions<\/li>\n
- Variables de entorno y configuraci\u00f3n de aplicaciones en Azure App Service<\/a>: Microsoft Learn<\/li>\n
- C\u00f3mo utilizar identidades gestionadas para recursos Azure en una m\u00e1quina virtual Azure para adquirir un token de acceso<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es Microsoft Entra ID?<\/a>: Microsoft Entra ID<\/li>\n
- Acerca de Azure Key Vault<\/a>: Microsoft Learn<\/li>\n
- Autorizar el acceso a blobs mediante Microsoft Entra ID<\/a>: Microsoft Learn<\/li>\n
- Descripci\u00f3n general de la cuenta de almacenamiento<\/a>: Microsoft Learn<\/li>\n
- \u00bfQu\u00e9 es el control de acceso basado en rol de Azure (RBAC)?<\/a>: Microsoft Learn<\/li>\n
- Pol\u00edticas de acceso a recursos espec\u00edficos<\/a>: Microsoft Learn<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.<\/p>\n","protected":false},"author":366,"featured_media":143167,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8838,8730],"tags":[9291,9329,9330,8861],"product_categories":[8932,8933,8890],"coauthors":[4194],"class_list":["post-146596","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-threat-research-es-la","category-cloud-cybersecurity-research-es-la","tag-aws-es-la","tag-google-cloud-es-la","tag-microsoft-azure-es-la","tag-serverless-es-la","product_categories-cortex-es-la","product_categories-cortex-cloud-es-la","product_categories-unit-42-incident-response-es-la"],"yoast_head":"\n
Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n<\/title>\n<meta name=\"description\" content=\"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:locale\" content=\"es_LA\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n\" \/>\n<meta property=\"og:description\" content=\"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/\" \/>\n<meta property=\"og:site_name\" content=\"Unit 42\" \/>\n<meta property=\"article:published_time\" content=\"2025-06-13T17:16:43+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-07-11T17:28:42+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"900\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Zohar Zigdon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","og_locale":"es_LA","og_type":"article","og_title":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","og_description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","og_url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","og_site_name":"Unit 42","article_published_time":"2025-06-13T17:16:43+00:00","article_modified_time":"2025-07-11T17:28:42+00:00","og_image":[{"width":1920,"height":900,"url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","type":"image\/jpeg"}],"author":"Zohar Zigdon","twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#article","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"},"author":{"name":"Sheida Azimi","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"headline":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","datePublished":"2025-06-13T17:16:43+00:00","dateModified":"2025-07-11T17:28:42+00:00","mainEntityOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"},"wordCount":4687,"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","keywords":["AWS","Google Cloud","Microsoft Azure","serverless"],"articleSection":["Investigaci\u00f3n de amenazas","Investigaci\u00f3n de ciberseguridad en la nube"],"inLanguage":"es"},{"@type":"WebPage","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/","name":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n","isPartOf":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"image":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage"},"thumbnailUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","datePublished":"2025-06-13T17:16:43+00:00","dateModified":"2025-07-11T17:28:42+00:00","author":{"@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639"},"description":"Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.","breadcrumb":{"@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/"]}]},{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#primaryimage","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/06\/07_Cloud_cybersecurity_research_Overview_1920x900.jpg","width":1920,"height":900,"caption":"Pictorial representation of serverless tokens in the cloud. East Asian woman examining data on multiple screens in a high-tech environment, surrounded by digital graphics and code."},{"@type":"BreadcrumbList","@id":"https:\/\/unit42.paloaltonetworks.com\/es-la\/serverless-authentication-cloud\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/unit42.paloaltonetworks.com\/"},{"@type":"ListItem","position":2,"name":"Tokens de autenticaci\u00f3n de funciones sin servidor en la nube: explotaci\u00f3n y detecci\u00f3n"}]},{"@type":"WebSite","@id":"https:\/\/unit42.paloaltonetworks.com\/#website","url":"https:\/\/unit42.paloaltonetworks.com\/","name":"Unit 42","description":"Palo Alto Networks","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/unit42.paloaltonetworks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"es"},{"@type":"Person","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/7ee97ec6f224446d57c0383eb5fd3639","name":"Sheida Azimi","image":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/unit42.paloaltonetworks.com\/#\/schema\/person\/image\/4ffb3c2d260a0150fb91b3715442f8b3","url":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","contentUrl":"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2018\/11\/unit-news-meta.svg","caption":"Sheida Azimi"},"url":"https:\/\/unit42.paloaltonetworks.com\/es-la\/author\/sheida-azimi\/"}]}},"_links":{"self":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/users\/366"}],"replies":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/comments?post=146596"}],"version-history":[{"count":4,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596\/revisions"}],"predecessor-version":[{"id":146700,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/posts\/146596\/revisions\/146700"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/media\/143167"}],"wp:attachment":[{"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/media?parent=146596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/categories?post=146596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/tags?post=146596"},{"taxonomy":"product_categories","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/product_categories?post=146596"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/unit42.paloaltonetworks.com\/es-la\/wp-json\/wp\/v2\/coauthors?post=146596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Cuando se asocia un rol de IAM a una funci\u00f3n de Lambda, el servicio de tokens de seguridad (STS)<\/a> de AWS genera autom\u00e1ticamente credenciales de seguridad temporales<\/a> para ese rol.<\/p>\n Se trata de una forma segura de acceder a las credenciales en tiempo de ejecuci\u00f3n sin los riesgos asociados con las credenciales codificadas a largo plazo.<\/p>\n Estas credenciales se rigen por los permisos definidos en la pol\u00edtica de acceso asociada con el rol. Incluyen un identificador de clave de acceso, una clave de acceso secreta y un token de sesi\u00f3n.<\/p>\n En tiempo de ejecuci\u00f3n, el servicio en tiempo de ejecuci\u00f3n de Lambda carga las credenciales de rol en el entorno de ejecuci\u00f3n de la funci\u00f3n y las almacena como variables de entorno, por ejemplo, AWS_ACCESS_KEY_ID<\/span>, AWS_SECRET_ACCESS_KEY<\/span> y AWS_SESSION_TOKEN<\/span>. Estas variables son accesibles al c\u00f3digo de la funci\u00f3n durante el tiempo de ejecuci\u00f3n, lo que permite a la funci\u00f3n interactuar de forma segura con otros servicios de AWS.<\/p>\n Google Cloud Functions utiliza tokens de cuenta de servicio para autenticar y autorizar el acceso a otros servicios de Google Cloud. Una cuenta de servicio es una cuenta de Google especializada que est\u00e1 vinculada con un proyecto<\/a> y representa una identidad no humana, en lugar de representar a un usuario individual.<\/p>\n Al implementar una Cloud Function, los desarrolladores pueden adjuntar la funci\u00f3n a una cuenta de servicio personalizada o a la cuenta de servicio por defecto<\/a>. Cuando se utiliza una cuenta de servicio personalizada, los desarrolladores pueden asignar roles IAM espec\u00edficos para definir los permisos exactos que requiere la funci\u00f3n para realizar sus tareas.<\/p>\n Las cuentas de servicio por defecto son cuentas gestionadas por el usuario<\/a> que Google Cloud crea autom\u00e1ticamente cuando los usuarios habilitan servicios espec\u00edficos. Por defecto, Google Cloud Functions utiliza diferentes cuentas de servicio en funci\u00f3n de la generaci\u00f3n<\/a>:<\/p>\n A estas cuentas de servicio por defecto se les conceden permisos de editor cuando los desarrolladores se incorporan a GCP sin una organizaci\u00f3n, lo que les permite crear, modificar y eliminar recursos dentro del proyecto. Sin embargo, en los proyectos que dependen de una organizaci\u00f3n GCP, las cuentas de servicio por defecto se crean sin ning\u00fan permiso. En esos casos, solo pueden realizar acciones permitidas expl\u00edcitamente por los roles que se les han asignado.<\/p>\n Aunque una funci\u00f3n de GCP opera en un entorno sin servidor, cuando se trata de acceder a las credenciales asociadas con la funci\u00f3n, se comporta de manera similar a un servidor tradicional, como una instancia de m\u00e1quina virtual (VM), recuperando sus tokens de cuenta de servicio del servidor de metadatos de instancia (IMDS)<\/a> en tiempo de ejecuci\u00f3n. El IMDS en hxxp:\/\/metadata.google[.]internal\/<\/span> proporciona tokens de acceso de corta duraci\u00f3n para la cuenta de servicio asociada con la funci\u00f3n. Estos tokens permiten a la funci\u00f3n autenticarse en los servicios de GCP.<\/p>\n Las identidades gestionadas de Azure proporcionan una forma segura y transparente para que los recursos de Azure se autentiquen e interact\u00faen con otros servicios de Azure sin necesidad de utilizar credenciales codificadas. Del mismo modo que los servicios de funciones de AWS y GCP, estas identidades eliminan los riesgos asociados con la gesti\u00f3n de credenciales en el c\u00f3digo.<\/p>\n Las identidades gestionadas asignadas por el sistema se vinculan a un \u00fanico recurso y se eliminan autom\u00e1ticamente cuando se elimina el recurso. Por otro lado, las identidades gestionadas asignadas por el usuario son recursos independientes que pueden asignarse a diversos servicios, lo que ofrece m\u00e1s flexibilidad para escenarios de autenticaci\u00f3n compartida.<\/p>\n Una funci\u00f3n de Azure con una identidad gestionada adjunta debe utilizar su token de identidad gestionada para autenticarse en un recurso de Azure. El proceso de autenticaci\u00f3n paso a paso es el siguiente:<\/p>\n Si est\u00e1 autorizado, el recurso concede acceso para realizar la operaci\u00f3n solicitada. Esto garantiza una autenticaci\u00f3n segura y perfecta sin necesidad de utilizar secretos codificados en el c\u00f3digo.<\/p>\n En esta secci\u00f3n se analizan los riesgos y amenazas que conlleva el uso de funciones sin servidor. Al desarrollar y configurar funciones, los desarrolladores de aplicaciones deben asegurarse de proteger esas funciones contra ataques como SSRF y RCE. En ausencia de dicha seguridad, los atacantes podr\u00edan manipular las funciones sin servidor que son vulnerables a SSRF, haciendo que las funciones env\u00eden solicitudes no autorizadas a los servicios internos. Esto puede conducir a un acceso no intencionado o a la exposici\u00f3n de informaci\u00f3n confidencial dentro del sistema, como tokens de acceso, contenido de bases de datos internas o configuraciones de servicios. Es importante subrayar que estos riesgos surgen principalmente cuando las funciones son p\u00fablicas o procesan entradas de usuarios externos y otras fuentes.<\/p>\n En los ataques SSRF, un atacante enga\u00f1a a un servidor (como una funci\u00f3n sin servidor) para que realice peticiones HTTP a recursos internos o externos a los que el atacante no deber\u00eda tener acceso. Dado que es el propio servidor el que realiza la petici\u00f3n, puede acceder a servicios internos que no est\u00e1n expuestos a Internet. Una funci\u00f3n vulnerable sin servidor toma una URL como entrada y obtiene datos de ella.<\/p>\n En GCP, SSRF puede utilizarse para acceder al IMDS en hxxp:\/\/metadata.google[.]internal\/<\/span>, extrayendo tokens de cuenta de servicio de corta duraci\u00f3n. Un atacante puede entonces aprovechar estos tokens para hacerse pasar por la funci\u00f3n y realizar acciones no autorizadas dentro de los permisos de su rol IAM. Las vulnerabilidades de ejecuci\u00f3n remota de c\u00f3digo permiten a los atacantes ejecutar c\u00f3digo arbitrario dentro del entorno de una funci\u00f3n.<\/p>\n Para AWS Lambda, los ataques RCE podr\u00edan exponer credenciales temporales almacenadas en variables de entorno, como AWS_ACCESS_KEY_ID<\/span> y AWS_SESSION_TOKEN<\/span>.<\/p>\n Es esencial se\u00f1alar que estos vectores de ataque no son fallos inherentes a las propias plataformas en nube, sino que surgen de c\u00f3digo inseguro escrito por desarrolladores de aplicaciones que podr\u00edan introducir vulnerabilidades, como SSRF o RCE. Los desarrolladores de aplicaciones pueden mitigar estos riesgos mediante la aplicaci\u00f3n de pr\u00e1cticas de codificaci\u00f3n seguras, como la validaci\u00f3n de entradas.<\/p>\n En las siguientes simulaciones se muestran posibles formas en las que los atacantes podr\u00edan extraer tokens de autenticaci\u00f3n de funciones sin servidor y utilizarlos para actividades maliciosas en diferentes proveedores de servicios en la nube (CSP). Estos ataques podr\u00edan aprovechar el c\u00f3digo de funci\u00f3n inseguro implementado por los desarrolladores de aplicaciones.<\/p>\n Para llevar a cabo esta simulaci\u00f3n, implementamos dos funciones de Cloud Run de Google que acceden al servicio de metadatos de funciones y extraen los tokens de las dos cuentas de servicio adjuntas diferentes de la siguiente ruta:<\/p>\n En el primer ejemplo se muestra la extracci\u00f3n de una cuenta de servicio por defecto. En el segundo ejemplo se muestra la extracci\u00f3n de una cuenta de servicio personalizada. En estos ejemplos se muestra c\u00f3mo el c\u00f3digo puede acceder directamente al servicio de metadatos, del mismo modo que una aplicaci\u00f3n de c\u00f3digo SSRF vulnerable tambi\u00e9n podr\u00eda acceder a \u00e9l.<\/p>\n Como se muestra en la Figura\u00a01, la cuenta de servicio adjunta a la funci\u00f3n era la cuenta de servicio sin servidor predeterminada. En la Figura\u00a02 se muestra que el token de acceso devuelto pertenece a la misma cuenta de servicio.<\/p>\n En la Figura\u00a03 se muestra la cuenta de servicio personalizada que adjuntamos a la funci\u00f3n. En la Figura\u00a04 se muestra el token de acceso devuelto perteneciente a la cuenta de servicio personalizada. A continuaci\u00f3n, utilizamos el token devuelto para realizar operaciones en el entorno.<\/p>\n En la Figura\u00a05 se muestra un ejemplo de comando para mostrar dep\u00f3sitos.<\/p>\n Si los atacantes pueden mostrar y leer el contenido de los dep\u00f3sitos en GCP, pueden acceder a archivos confidenciales como credenciales, copias de seguridad o configuraciones internas. Esto les permite robar datos, comprometer el sistema o moverse lateralmente dentro del entorno.<\/p>\n Una vez que los atacantes obtienen un token de acceso para una cuenta de servicio con permisos de editor en GCP (como la cuenta de servicio Compute Engine predeterminada), pueden modificar, eliminar o crear recursos en la mayor\u00eda de los servicios. Esto incluye acceder a datos confidenciales, implementar cargas de trabajo maliciosas, escalar privilegios o interrumpir servicios. El acceso de editor otorga un control casi total sobre el proyecto.<\/p>\n En esta simulaci\u00f3n, accedimos a las variables de entorno de la funci\u00f3n Lambda y extrajimos de ella el AWS_ACCESS_KEY_ID<\/span>, AWS_SECRET_ACCESS_KEY<\/span> y AWS_SESSION_TOKEN<\/span>.<\/p>\n En la Figura\u00a06 se muestra la salida del c\u00f3digo de la funci\u00f3n Lambda.<\/p>\n En la Figura\u00a07 se muestra la configuraci\u00f3n de las credenciales temporales de AWS obtenidas en el paso anterior (las variables de entorno de Lambda).<\/p>\n A continuaci\u00f3n, utilizamos el siguiente comando para mostrar todos los dep\u00f3sitos de S3 a los que puede acceder la sesi\u00f3n autenticada.<\/p>\n En esta simulaci\u00f3n, accedimos a las variables de entorno de Azure y extrajimos el IDENTITY_ENDPOINT<\/span> y el IDENTITY_HEADER<\/span> ejecutando comandos remotos. A continuaci\u00f3n, extrajimos el token de identidad gestionada del endpoint local de identidad, proporcionando estos par\u00e1metros que se muestran a continuaci\u00f3n en la Figura\u00a08:<\/p>\n Los mecanismos de detecci\u00f3n eficaces son fundamentales para identificar la exfiltraci\u00f3n de tokens en entornos sin servidor. Estos mecanismos se centran en las anomal\u00edas de comportamiento para se\u00f1alar actividades no autorizadas. A continuaci\u00f3n se exponen algunas de las mejores estrategias de detecci\u00f3n aplicadas en las principales plataformas en nube.<\/p>\n La detecci\u00f3n consta de dos etapas:<\/p>\n Para identificar las cuentas de servicio adjuntas a las funciones sin servidor en GCP, analizamos la secci\u00f3n serviceAccountDelegationInfo<\/span> en los registros. Esta informaci\u00f3n proporciona datos cruciales sobre la cadena de delegaci\u00f3n de cuentas de servicio. En concreto, cuando una cuenta de servicio se adjunta a una funci\u00f3n, delega su autoridad en una cuenta de servicio sin servidor por defecto:<\/p>\n Estas cuentas de servicio ejecutan tareas en nombre de la funci\u00f3n.<\/p>\n Por ejemplo, en la entrada de registro de la Figura\u00a09, vemos la cuenta de servicio personalizada que se adjunt\u00f3 a una funci\u00f3n (sa-test@<project-id>.iam.gserviceaccount[.]com<\/span>) que delega su autoridad en el agente de servicio Cloud Run.<\/p>\n En la Figura\u00a09, el campo principalEmail<\/span> de authenticationInfo<\/span> especifica la cuenta de servicio que se est\u00e1 utilizando (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com<\/span>).<\/p>\n El serviceAccountDelegationInfo<\/span> muestra el principal de la primera parte (en este caso: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com<\/span>), indicando que la cuenta de servicio est\u00e1 operando dentro de un entorno sin servidor como Cloud Functions o Cloud Run.<\/p>\n Un enfoque eficaz para descubrir identidades sin servidor es crear perfiles de cuentas de servicio que hayan delegado previamente su autoridad en cuentas de servicio sin servidor por defecto. De este modo se garantiza que incluso si se adjuntan cuentas de servicio no predeterminadas a las funciones, estas se identifiquen.<\/p>\n En AWS, las funciones Lambda se basan en roles IAM para el acceso seguro a los servicios de AWS. Estas funciones generan credenciales temporales. Podemos identificar la identidad Lambda por su nombre de rol.<\/p>\n En Azure, las identidades gestionadas adjuntas a Azure Function Apps se utilizan para la autenticaci\u00f3n.<\/p>\n En un entorno de nube seguro, las funciones sin servidor suelen estar destinadas a realizar tareas automatizadas y de alcance limitado, como responder a solicitudes de API o procesar eventos. Estas funciones no deben utilizarse de forma interactiva. Sin embargo, si los atacantes obtienen acceso al entorno de una funci\u00f3n sin servidor o a su identidad, podr\u00edan hacer un uso indebido para ejecutar comandos de interfaz de l\u00ednea de comandos (CLI) (por ejemplo, gcloud CLI<\/span> o curl<\/span>) para interactuar directamente con los recursos de la nube.<\/p>\n Una forma de detecci\u00f3n consiste en analizar el agente de usuario de las llamadas a la API. Si el agente de usuario coincide con herramientas CLI conocidas (por ejemplo, gcloud CLI<\/span>) o marcos de pruebas de penetraci\u00f3n, se marca como sospechoso, ya que las identidades sin servidor no deber\u00edan utilizar normalmente CLI. Esto indica una posible explotaci\u00f3n de los tokens del entorno o de la cuenta de servicio.<\/p>\n Cabe destacar que este m\u00e9todo de identificar el uso remoto de tokens de autenticaci\u00f3n de funciones sin servidor seg\u00fan el agente de usuario no se puede realizar en Azure, ya que la informaci\u00f3n del agente de usuario no aparece en los registros de Azure.<\/p>\n Otro enfoque para detectar el uso remoto de un token de identidad sin servidor consiste en correlacionar la ubicaci\u00f3n del uso de un token con rangos ASN de direcciones IP de proveedores de nube conocidos. Si una solicitud se origina en una direcci\u00f3n IP externa no asociada con el CSP, se activa una alerta que pone de manifiesto el posible uso no autorizado de tokens fuera del entorno de la nube.<\/p>\n Asegurar los tokens de autenticaci\u00f3n de funciones sin servidor requiere una combinaci\u00f3n de medidas proactivas, gesti\u00f3n de posturas y pr\u00e1cticas de seguridad de monitorizaci\u00f3n en tiempo de ejecuci\u00f3n para minimizar el riesgo de explotaci\u00f3n. En primer lugar, aplique el principio del menor privilegio asignando roles con los permisos m\u00ednimos necesarios para las funciones sin servidor. Esto reduce el impacto potencial del uso indebido de tokens.<\/p>\n Adem\u00e1s, para proteger los entornos de ejecuci\u00f3n sin servidor en GCP y Azure, restrinja el acceso a IMDS configurando controles a nivel de red y aplicando mecanismos de validaci\u00f3n de solicitudes. Garantice una s\u00f3lida validaci\u00f3n y limpieza de entradas para evitar que los atacantes utilicen t\u00e9cnicas de explotaci\u00f3n como SSRF para acceder a metadatos confidenciales, tokens y otros recursos de la nube como API y bases de datos.<\/p>\n La computaci\u00f3n sin servidor es la opci\u00f3n preferida para el desarrollo de aplicaciones modernas porque ofrece ventajas significativas en escalabilidad, rentabilidad y gesti\u00f3n simplificada de la infraestructura.<\/p>\n Las credenciales que permiten a estas funciones interactuar con los servicios en la nube son un elemento de seguridad cr\u00edtico y un objetivo prioritario para los atacantes. Comprometer estas credenciales puede acarrear graves consecuencias, como el acceso no autorizado a los recursos de la nube y la filtraci\u00f3n de datos.<\/p>\n La implementaci\u00f3n de protecciones proactivas de gesti\u00f3n de posturas y supervisi\u00f3n en tiempo de ejecuci\u00f3n es una estrategia crucial para proteger los entornos en nube.<\/p>\n Las organizaciones pueden proteger mejor sus entornos sin servidor mediante:<\/p>\n Los clientes de Palo Alto Networks est\u00e1n mejor protegidos frente a las amenazas mencionadas gracias a los siguientes productos:<\/p>\n Si cree que puede haber resultado vulnerado o tiene un problema urgente, p\u00f3ngase en contacto con el equipo de respuesta ante incidentes de Unit\u00a042<\/a> o llame al:<\/p>\n Palo Alto Networks ha compartido estos resultados con nuestros compa\u00f1eros de Cyber Threat Alliance (CTA). Los miembros de CTA utilizan esta inteligencia para implementar r\u00e1pidamente medidas de protecci\u00f3n para sus clientes y desarticular sistem\u00e1ticamente a los ciberdelincuentes. M\u00e1s informaci\u00f3n sobre Cyber Threat Alliance<\/a>.<\/p>\n Comprenda la mec\u00e1nica de la autenticaci\u00f3n sin servidor: tres ataques simulados a trav\u00e9s de los principales CSP ofrecen enfoques eficaces para los desarrolladores de aplicaciones.<\/p>\n","protected":false},"author":366,"featured_media":143167,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[8838,8730],"tags":[9291,9329,9330,8861],"product_categories":[8932,8933,8890],"coauthors":[4194],"class_list":["post-146596","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-threat-research-es-la","category-cloud-cybersecurity-research-es-la","tag-aws-es-la","tag-google-cloud-es-la","tag-microsoft-azure-es-la","tag-serverless-es-la","product_categories-cortex-es-la","product_categories-cortex-cloud-es-la","product_categories-unit-42-incident-response-es-la"],"yoast_head":"\n<\/a>Google Cloud Functions<\/strong><\/h3>\n
\n
<\/a>Azure Functions<\/strong><\/h3>\n
\n
\n
<\/a>Vectores de ataque de extracci\u00f3n de tokens<\/h2>\n
<\/a>Simulaciones de vectores de ataque<\/strong><\/h3>\n
<\/a>Simulaci\u00f3n 1: acceso directo al IMDS desde la funci\u00f3n GCP<\/h4>\n
\n
<\/a>Ejemplo 1: extracci\u00f3n de una cuenta de servicio por defecto de GCP<\/strong><\/h5>\n
![\"Captura](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-970480-146596-1.png\")
![\"Captura](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-972562-146596-2.png\")
<\/a>Ejemplo 2: extracci\u00f3n de una cuenta de servicio personalizada de GCP<\/strong><\/h5>\n
![\"Captura](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-975117-146596-3.png\")
![\"Captura](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-977988-146596-4.png\")
![\"Captura](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-980227-146596-5.png\")
<\/a>Simulaci\u00f3n 2: uso de RCE para recuperar tokens almacenados en variables de entorno de funciones de AWS Lambda<\/h4>\n
![\"Captura](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-982125-146596-6.png\")
![\"Pantalla](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-984127-146596-7.png\")
aws s3 ls<\/pre>\n
<\/a>Simulaci\u00f3n 3: uso de RCE para recuperar tokens del endpoint local de identidad de Azure Function<\/h4>\n
\n
![\"Captura](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-986214-146596-8.png\")
<\/a>Detecci\u00f3n y prevenci\u00f3n de la filtraci\u00f3n de tokens<\/h2>\n
<\/a>Detecci\u00f3n de la exfiltraci\u00f3n de tokens en entornos sin servidor<\/h3>\n
\n
\n
<\/a>Paso 1: identificaci\u00f3n de identidades sin servidor<\/h4>\n
\n
![\"Captura](\"https:\/\/unit42.paloaltonetworks.com\/wp-content\/uploads\/2025\/07\/word-image-988065-146596-9.png\")
<\/a>Paso 2: identificaci\u00f3n de comportamientos inusuales en las identidades sin servidor<\/h4>\n
<\/a>Estrategias de prevenci\u00f3n<\/h3>\n
<\/a>Conclusi\u00f3n<\/h2>\n
\n
<\/a>Protecci\u00f3n y mitigaci\u00f3n de Palo Alto Networks<\/h2>\n
\n
<\/a>Recursos adicionales<\/h2>\n
\n