Alexa, Hack My Server(less) Please

## Overview

Presented by Tal (Head of Security Research at Protego, recently acquired by Check Point) alongside an Alexa-driven "hacking assistant," this talk explores the emerging attack surface in serverless architectures across AWS, Azure, and Google Cloud Platform (GCP). The core premise establishes that serverless attacks typically do not exploit vulnerabilities in the cloud provider's underlying infrastructure; instead, they target application-level vulnerabilities, poor coding practices, and IAM misconfigurations.

While serverless adoption has shown linear growth over five years (utilized by companies like iRobot, Capital One, and Netflix), attention to serverless security remains disproportionately low. In serverless models, cloud providers handle OS maintenance, patching, scaling, and virtualization, shifting customer responsibility directly onto application code and cloud resource configurations under the shared responsibility model.

## Serverless Architectural Challenges & Threat Model

Unlike traditional architectures where security controls, internal firewalls, and segmented perimeter networks shield backend systems, serverless is event-driven. Cloud functions (such as AWS Lambda) trigger directly off of disparate event sources (e.g., API gateways, S3/storage buckets, emails, database mutations, notifications).

Because the customer does not own the network perimeter or the transport layer between cloud resources, traditional firewalls cannot be placed in front of non-API triggers. Developers must enforce all validation and controls directly within function code. If vulnerabilities like command or code injection exist, attackers can interact with the underlying execution container and pivot into the wider cloud environment.

## Cross-Cloud Container Anatomy & Credential Theft

When a cloud function executes, the provider spins up an ephemeral container. Tal outlined key architectural differences across providers:

- **AWS Lambda:** Highly ephemeral; filesystem is strictly read-only except for `/tmp`; code resides under `/var/task` or `proc/cwd`; supports over 23 native event trigger types. - **Azure Functions:** Offers 12+ trigger types; writable areas differ from AWS; application code resides under `/home/site/wwwroot`. - **Google Cloud Functions (GCP):** Writable directories include `/tmp` and `/home`; application code resides under `user_code`.

When command execution is achieved inside a container, attackers can harvest the temporary cloud credentials assigned to the function's execution role and call cloud APIs directly from their own local machines:

- **GCP:** Querying the internal metadata service via `curl` yields an access token that mirrors the function's permissions, enabling enumeration of Cloud Storage buckets. - **AWS:** Functions inherit credentials exposed as environment variables (`AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, `AWS_ACCESS_KEY_ID`), which can be extracted and loaded into local tools to invoke AWS APIs. - **Azure:** Environment variables contain the MSI endpoint and secret, which can be queried from inside the function to obtain an API access token.

## IAM Misconfiguration & Privilege Creep

A primary enabler of serverless post-exploitation is overly permissive IAM policies. In an AWS S3-triggered Lambda function designed simply to read and process uploaded objects (`GetObject`), developers frequently copy overly broad policy templates:

1. **Full Wildcards (`Action: "*", Resource: "*"`):** Functions are granted capabilities to delete files, alter buckets, or change permissions across every bucket in the account. 2. **Scattered/Overly Broad Permissions:** Even when scoped down to a single bucket, actions often retain wildcards (e.g., `s3:*` on a specific resource). 3. **Least Privilege Challenges:** True least privilege requires strictly scoping both actions (`s3:GetObject`) and exact resources (specific bucket ARN). While feasible for a single function, maintaining this granular enforcement manually does not scale across enterprise environments deploying hundreds or thousands of discrete microservices.