Applying ROP Chaining Concepts to Serverless Functions

A couple of weeks ago, I gave a talk on serverless security at Check Point. After my talk, Ohad Bobrov (VP, Enterprise Mobility at Check Point) approached me, and mentioned that he sees some resemblance between the ROP chaining exploitation technique, and the “SAS-09” entry in the Serverless Top 10 Most Common Weaknesses guide – “Serverless Functions Execution Flow Manipulation”.

I find this comparison intriguing. But before we move to the comparison itself, let’s go through a quick crash course on both topics.

Return Oriented Programming

In recent years, several techniques such as canaries (stack cookies), DEP (Data Execution Prevention), ASLR (Address Space Layout Randomization), SMEP (Superior Mode Execution Protection) and CFG (Control Flow Guard) were developed in order to defend against malicious code execution exploits. This forced attackers to develop creative ways around such protections, one of which is ROP (Return-oriented programming).

When using the ROP technique, an attacker gains control of the call stack to hijack program control flow and then executes carefully chosen machine instruction sequences that are already present in the machine’s memory – these sequences are called “gadgets”. The clip below provides a nice illustration of the gadgets:

 

 

Each gadget typically ends in a return instruction and is located in a subroutine within the existing program and/or shared library code.

A typical data execution prevention cannot defend against ROP chaining, because the attacker did not use malicious code but rather combined normal instructions by changing return addresses; therefore the code used would not be marked non-executable.

Chained together, these gadgets allow an attacker to perform arbitrary operations on a machine employing defenses that thwart simpler attacks.

The movie clip below shows how normal instructions are chained together, to form a malicious exploit sequence:

Serverless Functions Execution Flow Manipulation (SAS-09)

Serverless applications oftentimes follow the micro-services design paradigm and contain many discrete functions, which are chained together in a specific predetermined order that in turn, implements the overall application logic.

In an application where multiple serverless functions exist, and each function may invoke another function, the order of invocation might be critical for achieving the desired logic. Moreover, the design might assume that certain functions are only invoked under specific scenarios and only by authorized invokers.

Applying The ROP Chaining Concept to Serverless Functions

Similar to how modern operating systems and CPU level defenses prohibit malicious users from inserting arbitrary code, serverless architectures provide function-level protections against the addition of new function code by making serverless functions immutable. When proper authentication/authorization is applied, unauthorized users cannot add new functions or modify existing function code. 

However, in a multi-function orchestrated serverless application, an attacker might map the different serverless functions, learn their permissions on resources, and their capabilities, and attempt to manipulate invocation order, essentially mimicking the concept behind ROP chaining.

The attacker will collect  and re-order function executions, turning them into “serverless-gadgets”, and then re-using them to mount an attack against the system, thus bypassing all sorts of protections such as authentication and authorization, validity checks and so forth.

I find this comparison and analogy extremely useful in explaining what SAS-09 is all about – perhaps we should update next year’s Serverless Top 10 guide to include this new description.

However, while the concepts are similar, there is a distinct difference – ROP chains are nearly a tool that allows an attacker to bypass security controls, to a point where she can upload and execute the malware. On the other hand, Serverless Function Flow Manipulation is in itself the end goal. The new function sequence carries the entire logic of the attack.

Mitigating Serverless Function Flow Manipulation Risks

The root causes behind function flow manipulation are:

1. Over-permissive serverless function roles

2. Improper authentication & authorization on functions and cloud resources

 

PureSec’s SSRE solution provides a unique analysis capability for detecting over-permissive function roles during build time. By integrating the solution with CI/CD environments, PureSec customers can easily detect such vulnerabilities and automatically apply least-privileged roles, reducing the risks mentioned in this paper.

In addition, developers and architects should always strive to perform threat modeling and make sure that proper authentication and authorization are applied to serverless functions.

       

*The slides for the movie clips in this blog post were kindly provided by Orli Gan. 



This is a Security Bloggers Network syndicated blog post authored by Ory Segal, PureSec CTO. Read the original post at: PureSec Blog (Launch)