Shoham Danino

Today’s software development landscape has witnessed a shift towards microservices architectures. Using this approach, large software systems are composed of multiple separate microservices, each responsible for specific tasks. The breakdown to microservices is also reflected in the infrastructure, where individual microservices can be executed with different hardware configurations and scaling properties. As systems grow larger, incoming traffic can trigger multiple calls between different microservices to handle each request.

Auto-scaling is a technique widely used to adapt systems to fluctuating traffic loads by automatically increasing (scale-up) and decreasing (scale-down) the number of resources used.

Our work shows that when microservices with separate auto-scaling mechanisms work in tandem to process ingress traffic, they can overload each other. This overload results in throttling (DoS)
or the over-provisioning of resources (EDoS).

In the lecture we will demonstrate how an attacker can exploit the tandem behavior of microservices with different auto-scaling mechanisms to create an attack we denote as the Tandem Attack. We demonstrate the attack on a typical and recommended serverless architecture, using AWS Lambda for code execution and DynamoDB as database. Part of the results will be presented as an IEEE INFOCOM’23 poster.

Auto-scaling is a fundamental capability of cloud computing which allows consuming resources dynamically according to changing traffic needed to be served.
By the micro-services architecture paradigm, software systems are built as a set of loosely-coupled applications and services that can be individually scaled.
In this paper, we present a new attack the \emph{Tandem Attack} that exploits the Tandem behavior of micro-services with different scaling properties. Such issues can result in Denial of Service (DoS) and Economic Denial of Sustainability (EDoS) created by malicious attackers or self-inflicted due to wrong configurations set up by administrators. We demonstrate the Tandem attack using a popular AWS serverless infrastructure modeling two services and show that removing servers’ management responsibility from the cloud users does not mitigate the different scaling properties challenge and can even make the problem harder to solve.

It is a common belief that Auto-scaling mechanisms serve as a mitigation for Distributed Denial of Service (DDoS) attacks on cloud computing infrastructures by dynamically adding machines to cope with the additional load. Intuitively, such attacks are mostly associated with Economic Denial of Sustainability (EDoS) derived from paying for the extra resources required to process the malicious incoming traffic.

Contrary to this belief, we present and analyze the Yo-Yo attack, a new attack against the auto-scaling mechanism that can cause significant performance degradation in addition to economic damage. We demonstrate the attack on Amazon EC2, Kubernetes, and serverless architecture. We then present and analyze Tandem Attack, a new attack on Microservices architecture. In this attack, the attacker exploits the tandem behavior of services with different auto-scaling mechanisms, causing both economic and performance damage.

This paper presents a new localhost browser based vulnerability and corresponding attack that opens the door to new attacks on private networks and local devices. We show that this new vulnerability may put hundreds of millions of internet users and their IoT devices at risk. Following the attack presentation, we suggest three new protection mechanisms to mitigate this vulnerability.
This new attack bypasses recently suggested protection mechanisms designed to stop browser-based attacks on private devices and local applications.

We explore the impact of device location on the communication endpoints of IoT devices within the context of Manufacturer Usage Description (MUD), an IETF security framework for IoT devices.
Two types of device location are considered: IP-based location, which corresponds to the physical location of the device based on its IP address; and user-defined location, which is chosen during device registration.
Our findings show that IP-based location barely affects the domain set with which IoT devices interact. Conversely, user-defined location drastically changes this set, mainly through region-specific domains that embody location identifiers selected by the user at registration.
We examine these findings’ effects on creating MUD file tools and IoT device identification. As MUD files rely on allowlists of domain allowlists, we show that security appliances supporting MUD need to manage a significantly larger number of MUD rules than initially anticipated. 
To address this challenge, we leverage EDNS Client Subnet (ECS) extension to differentiate user-defined locations without needing regional domains, consequently reducing the number of Access Control Entries (ACEs) required by security appliances.