{"id":16912,"date":"2018-10-25T14:31:00","date_gmt":"2018-10-25T14:31:00","guid":{"rendered":"https:\/\/www.darkreading.com\/cloud\/securing-serverless-attacking-an-aws-account-via-a-lambda-function\/a\/d-id\/1333047"},"modified":"2018-10-25T14:31:00","modified_gmt":"2018-10-25T14:31:00","slug":"securing-serverless-attacking-an-aws-account-via-a-lambda-function","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/securing-serverless-attacking-an-aws-account-via-a-lambda-function\/","title":{"rendered":"Securing Serverless: Attacking an AWS Account via a Lambda Function"},"content":{"rendered":"
\n<\/header>\n

It’s not every day that someone lets you freely wreak havoc on their account just to find out what happens when you do.<\/span> <\/p>\n

Part two of a two-part series. Click to read Caleb Sima\u2019s Securing Severless: Defend or Attack?<\/strong><\/a><\/em><\/p>\n

On August 3rd 2018, I got a cryptic LinkedIn message from Caleb Sima, with only the following text:<\/p>\n

\"\"<\/a><\/div>\n

I have to admit, at first, I didn’t quite understand what Caleb was trying to tell me, however a quick glimpse at the URL, which contained the words Lambda and Shell, seemed as if he was trying to show me that he deployed a Lambda function which allows users to execute shell commands. I’ve seen several such projects in the past, such as Lambdash<\/a><\/span>, which is why I failed to be overly impressed or engaged. A few seconds later, I decided to take a peek at the Web page, and noticed the call for a challenge:<\/p>\n

\"\"<\/a><\/div>\n

Seeing this, I first had to figure out Caleb’s motives, so I fired him another message, trying to get more understanding as to why he decided to build this:<\/p>\n

\"\"<\/a><\/div>\n

So\u2026 Caleb decided to let people attack his AWS account through a Lambda function that enables you to run shell commands. Sounds like a worthy challenge. After all, it’s not every day that someone lets you wreak havoc on their account and run attacks freely. Now I was excited!<\/p>\n

Step 1: Gathering Reconnaissance<\/strong>
I started by extracting the filename of the function\u2019s handler by running ‘ls -lF’ on the current directory (\/var\/task):<\/p>\n

\"\"<\/a><\/div>\n

With the filename at hand (index.js), I went on to retrieve the source code of the function by running ‘cat index.js’ (output truncated):<\/p>\n

\"\"<\/a><\/div>\n

At the time, the original source code was quite unimpressive to say the least. It was the classic ‘aws-lambda-function-that-executes-shell-commands’ function, which as mentioned earlier, I\u2019ve seen plenty such projects in the past.<\/p>\n

“Ok then…” I thought to myself, “I can run shell commands, what’s next? How do we go from here, to inflicting some real damage for the account?”<\/p>\n

My next attempt to gather more information was to list all the environment variables, and see if Caleb left something in there that might be useful, and so I ran the \u2018env\u2019 command (output truncated)<\/p>\n

\"\"<\/a><\/div>\n

Step 2: Impersonating the Lambda Function<\/strong>
The next morning, I got to work, and decided to take another peak at the environment variables. Suddenly something dawned on me – when an AWS Lambda function executes, it uses the temporary security credentials received by assuming the IAM role<\/a><\/span> the developer granted to that function. When assuming a role, the assuming entity receives 3 parameters from AWS STS (security token service)<\/a><\/span>:<\/p>\n