Seguridad en arquitecturas serverless y entornos cloud

Seguridad en
arquitecturas serverless y
entornos cloud
José Manuel Ortega

Agenda
● Introducción a las arquitecturas serverless
● Seguridad en arquitecturas serverless
● OWASP Serverless Top 10
● Pentesting sobre aplicaciones cloud
● Mejores prácticas de seguridad al trabajar en
entornos cloud

Introducción a las arquitecturas serverless
● AWS: AWS Lambda
a. https://aws.amazon.com/lambda
● Microsoft Azure: Azure Functions
a. https://azure.microsoft.com/en-us/services/functions
● Google Cloud: Cloud Functions
a. https://cloud.google.com/functions

https://aws.amazon.com/es/compliance/shared-responsibility-model

● Flexibilidad, administración y escalado de los recursos necesarios
por parte del proveedor.
● Suministro ágil de los recursos en tiempo real, incluso en caso de
picos de carga imprevisibles o un crecimiento desproporcionado.
● Solo se cobran los gastos por recursos que realmente se han usado.
● Tolerancia a fallos gracias a la infraestructura flexible de hardware en
los centros de cálculo del proveedor.

Ventajas Inconvenientes
Escalado y administración de los recursos necesarios
por parte del proveedor
Se restringe el acceso a máquinas virtuales y sistemas
operativos.
Suministro ágil de los recursos en tiempo real, incluso en
caso de picos de carga imprevisibles o un crecimiento
desproporcionado
Gran dependencia del proveedor (“efecto Lock-in”):
en caso de cambiar de operador, por ejemplo, suele ser
necesario escribir nuevamente todas las funciones
basadas en eventos.
Solo se cobran gastos por recursos que realmente se
han usado
Procesos de monitorización y depuración de errores
relativamente complejos, ya que, por norma general, no
es posible realizar análisis profundos de errores y
rendimiento.
Gran tolerancia a errores gracias a la infraestructura
flexible de hardware en los centros de cálculo del
proveedor.

● FaaS (Function as a Service)
● Arquitectura basadas en eventos (EDA)
● Funciones sin estado
● Los flujos de trabajo y la ejecución de funciones se
activan mediante eventos
● Los desencadenantes pueden iniciarse por acciones
como entradas de usuario o cambios en una base de
datos.

● Composición de varias funciones sin estado
● Gráfico acíclico dirigido (DAG)

Disparadores/Eventos
Dependiendo del proveedor:
▸ Cambios en bases de datos (Firebase, Dynamo)
▸ Cambios en un almacenamiento (S3, GS, FireStore)
▸ Cambios en la infraestructura
▸ Eventos en colas (SQS, PubSub)
▸ Acciones en Alexa, Google Home

https://docs.aws.amazon.com/lambda/latest/dg/lambda-services.html

Seguridad en arquitecturas serverless
● Inyección de datos de eventos
● Mayor superficie de ataque
● Manipulación de la ejecución del
flujo de funciones serverless
● Denegación de servicio y
agotamiento de recursos
financieros
● Manejo inadecuado de
excepciones y mensajes de error

Ataques De Inyección
● SQL
● Cross site scripting(XSS)
● De comandos

Ataques que se minimizan
● Fuerza bruta
● Ataques DDoS

Ataques DDoS
● En Serverless, una función no puede recibir más de una invocación
concurrente, por lo que nuevas llamadas levantarán nuevas instancias
de funciones.
● En esta situación un ataque DDoS podría provocar que se levantaran miles
de instancias de una función agotando así todos los recursos de la
infraestructura, pudiendo afectar incluso a otras funciones que no se puedan
levantar debido a esto.
● Es necesario por tanto que nuestro proveedor serverless nos permita
definir el número máximo de peticiones concurrentes (o instancias en
este caso) tanto de toda la plataforma como de cada una de las funciones.

Ataques DDoS
● Concurrencia
● Número de transacciones por segundo

Ataques DoW(Denial of Wallet)
● Agotamiento de los recursos contratados
● Funciones con alto nivel de concurrencia
● Escalado automático en el uso de memoria y
CPU

● Limitar el número de llamadas a funciones
● Limitar el acceso a los recursos
● Definir límite de presupuesto
● Usar herramientas como AWS Shield
a. https://aws.amazon.com/es/shield

https://aws.amazon.com/es/blogs/mt/introducing-service-quotas-view-and-manage-your-quotas-for-aws-ser
vices-from-one-central-location

OWASP Serverless Top 10
● SAS-1: Function Event Data Injection
● SAS-2: Broken Authentication
● SAS-3: Insecure Serverless Deployment Configuration
● SAS-4: Over-Privileged Function Permissions and Roles
● SAS-5: Inadequate Function Monitoring and Logging
● SAS-6: Insecure 3rd Party Dependencies
● SAS-7: Insecure Application Secrets Storage
● SAS-8: Denial of Service and Financial Resource Exhaustion
● SAS-9: Serverless Function Execution Flow Manipulation
● SAS-10: Improper Exception Handling and Verbose Error Messages
https://owasp.org/www-pdf-archive/OWASP-Top-10-Serverless-Interpretation-en.pdf

Risk/Attack vector Cloud applications
(IaaS, PaaS)
Serverless Applications (FaaS)
Data Injection Impact level:3 Impact:4, increases the level of
impact as it increases the attack
surface.
Broken Authentication
and Access Control
Impact:4 Impact:3, it is more difficult for an
attacker to exploit a serverless
function in isolation.
Security
Misconfiguration and
insecure Serverless
Deployment
Configuration
Impact:3 Impact:3, same impact level

Risk/Attack vector Cloud
applications
(IaaS, PaaS)
Security
Misconfiguration and
Over-Privileged
Function Permissions
and Roles
Impact level:3 Impact:3, same impact level
Security Logging and
Monitoring Failures
Impact:2 Impact:3, higher impact level
Vulnerable and
Outdated Components
Impact:3 Impact:3, same impact level

Risk/Attack vector Cloud applications
(IaaS, PaaS)
Software and Data
Integrity Failures. 3rd
Party Dependencies
Impact level:4 Impact:3, the impact is reduced
since the functions have finite
execution time.
Denial of Service &
Financial Resource
Exhaustion
Impact:3 Impact:4, higher impact level due to
the presence of the Denial of
Wallet
Serverless Functions
Execution Flow
Manipulation
Impact:1 Impact:3, greater impact level since
it is a new problem in serverless
architectures

● SAS-1: Function Event Data Injection
a. Inyección de código en funciones
b. Inyección de comandos del sistema operativo
c. Manipulación de mensajes en sistemas
Publish/Subscribe
d. Inyección NoSQL

dynamodb_client.put_item(TableName=TABLE_NAME,
Item={"email": {"S": parser['From']},
"subject": {"S": parser['Subject']},
"received": {"S": str(datetime.utcnow()).split('.')[0]},
"filename": {"S": file_name},
"requestid": {'S': context.aws_request_id},
"content": {'S': pdf_content.decode("utf-8")}})
- Effect: Allow
Action:
- 'dynamodb:*'
Resource:
- 'arn:aws:dynamodb:us-east-1:****************:table/TABLE_NAME'

https://github.com/functionalone/serverless-iam-roles-per-function
functions:
func1:
handler: handler.get
iamRoleStatementsName: my-custom-role-name #optional custom role name
setting instead of the default generated one
iamRoleStatements:
- Effect: "Allow"
Action:
- dynamodb:GetItem
Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/mytable"

● SAS-9: Functions Execution Flow Manipulation

Mitigaciones/contramedidas
● Tener un mayor control de los recursos
● Controlar el número de eventos que pueden
desencadenar la ejecución de una función
● Desarrollar pequeñas funciones que realicen una tarea
específica con una lógica de negocio mínima
● Uso de patrones de diseño para aplicaciones serverless

Serverless framework
● Especificar múltiples tiempos de ejecución (nodejs, go, python, etc) y
proveedores (aws, azure).
● Desplegar desde línea de comandos en diferentes entornos (staging,
producción).
● Controlar los recursos que se crearán, como tablas de DynamoDB,
buckets de S3.
● Crear nuestra API con endpoints y funciones que se ejecutarán para
cada método HTTP.
● Cambiar los parámetros de las funciones, el uso de memoria o el tiempo
de ejecución de las funciones.
https://www.serverless.com

Serverless vulnerable app
https://github.com/ine-labs/AWSGoat
https://github.com/OWASP/DVSA

https://github.com/OWASP/DVSA/blob/master/backend/src/functions/processing/send_receipt_email.py

https://github.com/OWASP/DVSA/blob/master/template.yml

Estrategias de seguridad entornos cloud

Pentesting sobre aplicaciones cloud
https://cloudcustodian.io

https://github.com/prowler-cloud/prowler
● Prowler es una herramienta de
seguridad de código abierto para
realizar evaluaciones de las mejores
prácticas de seguridad de AWS y Azure
● Permite realizar auditorías, respuesta
a incidentes, monitorización continua,
hardening y gestionar la revocación de
secretos.

aws configure
export AWS_ACCESS_KEY_ID="ASXXXXXXX"
export AWS_SECRET_ACCESS_KEY="XXXXXXXXX"
export AWS_SESSION_TOKEN="XXXXXXXXX"
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

Principales servicios de seguridad en AWS

Principales servicios de seguridad en AWS
https://maturitymodel.security.aws.dev/es

Conclusiones
● https://github.com/puresec/sas-top-10
● La mayoría de los riesgos de seguridad siguen presentes
en serverless, presentados de forma diferente.
● Las aplicaciones sin servidor podrían aumentar en
complejidad.
● Se reduce el impacto de los ataques de denegación de
servicio (DoS), pero aparecen nuevos riesgos como la
denegación de cartera (Denial of Wallet).

Conclusiones
● DoW adquiere mayor relevancia al conectar
aplicaciones serverless con dispositivos IoT.
● Ataque DOW debido a la pérdida de control de la
generación de eventos por peticiones realizadas desde
dispositivos IoT.
● Control de la generación de eventos en aplicaciones.
● Sigue las mejores prácticas de diseño
https://12factor.net/es/ y desarrollo de software seguro.

¡Gracias!
@jmortegac
https://www.linkedin.com
/in/jmortega1
https://jmortega.github.io
¿Preguntas?

Seguridad en arquitecturas serverless y entornos cloud

Recomendados

Recomendados

Más contenido relacionado

Similar a Seguridad en arquitecturas serverless y entornos cloud

Similar a Seguridad en arquitecturas serverless y entornos cloud (20)

Más de Jose Manuel Ortega Candel

Más de Jose Manuel Ortega Candel (20)

Último

Último (10)

Seguridad en arquitecturas serverless y entornos cloud