Hello, my name is Julien LePilaire, and it is a great pleasure to be presenting the work we've done with my colleagues Rusi Kapiskac, Martin Scheffe, and Marc Santolucito on a new kind of vulnerability that we call intra-update sniping vulnerability in Infrastructure as Code. First, let me explain to you Infrastructure as Code.

The typical backend of an application might look like the figure on the left, where you have a reverse proxy that balances the load onto multiple application servers that run an application. And you might also have multiple databases that are synchronized together to have some redundancy

and make sure that if you lose one of them then you don't lose all of your client's data. You can of course always manage all this infrastructure by hand, but it might be more practical to use Infrastructure as Code, which is essentially writing this JSON file on the right, where you declare a list of resources,

where you have for instance a database instance that corresponds to the database servers, and that has some properties where you declare maybe the engine that is running, so it could be Aurora, which is an AWS thing, or MySQL, or MariaDB, or PostgreSQL, etc.

You can also have other types of properties, and you would have a resource for your application server and some properties like the code that is running, etc. All of these could be managed by one of the many tools that exist for Infrastructure as Code,

and you would benefit from the many advantages that it provides. So for instance, all of your configuration for all of your servers would be in the same place, so you would know the big picture of your infrastructure, you would know exactly which server you're running, where they are located, etc.

And then Infrastructure as Code would help you ensure some consistency between your servers, so for instance you might want to make sure that all of your application servers are running the same version of the application, which might be tedious when you do it by hand, and you have many application servers, but with Infrastructure as Code,

you can have applied the same template to all of your servers. Of course, since it's a configuration file, you can always version control it, you can apply rollbacks, and usually those languages are static and declarative, which makes them pretty easy to use.

However, this comes to the price of having some new vulnerabilities, like these sniping vulnerabilities. So let's look at an example. If you look on the left, we have an infrastructure where we have here the purple gateway that lets users on the internet communicate with our infrastructure.

We have a lambda in orange that is just AWS terminology for just a function that answers requests from the client, and this lambda is connected to a database that is presented in blue here.

And we can imagine that in this infrastructure, when a client sends a request, they can get the name of users and their profile picture, which we can consider as public data. Imagine then that you want to update this infrastructure to a new version of your lambda function,

let's call it lambda2, and that new function would return some private data, such as the account balance of users, which you can see on the right here. So since we are now returning some private data, we don't want anyone on the internet to be able to get it.

So we also want to add some security layer, and we add those red resources here as the security layer to make sure that only authorized users are able to communicate with the lambda. And then it's also important to note that only the lambda can access the database, not users directly.

Of course, in these two scenarios, the infrastructure is secure in the first case because it only returns public data, and in the second case because it returns private data only to authorized users.

However, in infrastructure of course, the order in which updates are applied is not guaranteed at all. So there are actually two different upgrade orders that are possible in this infrastructure. You can either first update the lambda to lambda2 and then add the security layer,

or you could first add the security layer and then update the lambda. And this is chosen by the tool, and we don't really know which order is going to happen. But if you look at this first possibility, you can see that during the update,

when your infrastructure looks like that, any user is able to use your API, communicate with the lambda, and get your private data, which is pretty bad. So it means that this infrastructure is not vulnerable during the upgrade, and we have actually reproduced this vulnerability in AWS and Google.

And we have talked to Google about that, and even though they analyzed the issue, they also said that users should take care of themselves. But in infrastructure of Escort, there are many options, more than thousands,

maybe tens of thousands of options that users can set, so we don't really expect users to really understand exactly what's happening in terms of security with something so subtle. So we wanted to build a tool that we call Hubha that checks security property

that in every intermediate state, it checks that the security of resources are not lower than the security of that resource, either in the initial or in the target state.

And one of the core features is that it has no false negatives, so it's able to prove the absence of issues, and it is able to actually find some potential vulnerable resources. And when it does, it suggests to add some dependencies like these

to remove the vulnerable upgrade orders. So in this example, we would add a dependency on the authorizer from the lambda to ensure that the authorizer is updated first, which is the secure upgrade order. So in order to build our tool, we had first to develop a semantics for infrastructure as code.

So first, what is a configuration file? A configuration file is essentially a list of resources which can represent a server, a service, or a software that is running in your infrastructure. Each resource has a unique identifier, which is usually its name,

and also it has a type, which is one of many. Actually, there are thousands of different types in AWS alone, and this could be, for instance, a lambda database or bucket for AWS. It also has some properties, which can be some internal configuration options

like the memory size or the name of a cluster or database, etc. These properties can also reference other resources in many different ways for many different purposes, such as access restriction or telling a resource where it can fetch some data it can use

or where to send logs to in case of some events, etc. And we note that the semantics of these properties depends on the type of resource and on the cloud vendor. A resource can also have optional dependencies,

which restrict the order of updates, ensuring the security in a previous example, for instance. So in our model, we have a function from identifiers in the infrastructure to a tuple that contains a type and a list of references, as well as D, which is the set of dependencies

and it's represented by a relation between identifiers, and it's only used for updates. The type in the tuple is actually a generalized type, so we don't use the thousands of different types for AWS. Instead, we have only four generic types,

which can be the public type for resources that are accessible from the web directly, security type for resources that ensure some kind of security role in connections between resources, the collection type, which is used to give some common configurations to other resources,

and non-type for resources that have no specific behavior. Then we also have some generalized types for the references. We have the network type for a connection between resources so they can send requests to one another, the collect type that says that a resource is part of some collection, and the protect type that says that a resource is protected by some security resource.

An example of our model would be the figure on the left, where we have four different resources, the private lambda, which has the non-type and no references, the private cat, which has the public type and two references, a network reference that says that it is able to send requests to the private lambda,

and a collect type that says that it is part of the MyAPI collection, and the MyAPI is actually a collection type with no references. And we have the authorizer, which is of type security, and it has one reference that is of protect type

that says that this authorizer is protecting input to MyAPI resources. So this situation can be represented graphically with the figure on the right, where we have the authorizer that protects the connection to the private cat because the private cat is part of MyAPI and the authorizer protects MyAPI.

And then we have a connection from private cat to the private lambda because the private cat can send requests to the private lambda. And the private lambda is not accessible from the web because it's not public. Okay, so now we can talk about resource security. So first we have to remember that requests can flow from resource to resources,

and some of those connections can be protected by a security resource. For instance, this connection from the web to the private cat is protected by the authorizer. And so the security level of a resource is simply the lowest security under which it can be reached.

So for instance, the private cat is accessible only from the web through the authorizer, so its security level is the same as the security level provided by the authorizer. And similarly, the private lambda is accessible only from the private cat, and so its security level is also the security level provided by the authorizer.

So now that we understand what happens in a single deployment, we need to understand what happens when we deploy a new configuration over an existing configuration. So the tool will actually compare the two versions of your infrastructure, and it can send commands to different services to your cloud provider to either delete some resources,

to update the configuration of some resources, or to create some new resources that you created in your configuration. And we can model that with a simple interleaving semantics that we show here. So we can upgrade a configuration if it's not yet in its target state,

and all of its dependencies have already been updated. We can also add a new resource if it's not yet part of the current deployment, and if all of its dependencies have already been upgraded. And we can remove resources if they're not part of the target deployment.

Here we cannot use dependencies because it's not part of the target deployment, so it cannot have a dependency. Alright, we now have all the formal elements we need in order to find sniping vulnerabilities. The first idea would be to generate all of the intermediate states

and then use an existing tool to analyze them. However, there are an exponential number of intermediate states, and we would like our tool to be scalable. An existing and an existing tool would actually not be so interesting because it would find errors in intermediate states that the user does not know about.

Instead, we would like to use our own tool, and for scalability, we want to use a single structure for the analysis. I'm only going to give you some overview, and you will of course find all of the details in the paper.

So remember that in intermediate states, you might find either the initial or the target state of any resource, so we need to have them both here. This is represented by this public lambda and the private lambda, which are two versions of the same lambda resource.

The security resources also can be either updated or not updated, so we need to have them both, and we can only use the lowest security level of them, because we don't know which one is actually going to be used. So for instance here, if we didn't have an authorizer in the initial state

and we have an authorizer in the target one, then we can only use the no-authorizer here to protect this connection. Then we can check the security of these resources in the same way we did for a single infrastructure. In this case, the GET method is unaccessible with no authorizer,

so it's publicly accessible, and a public and a private lambda are both accessible publicly. Once we have these security levels, we can compare them with the initial and target states, and for instance here, the public lambda is publicly accessible, and that was already the case in the initial state, so there is no policy violation here. However, the private lambda is publicly accessible

in these upgrade states, but in the target state it was accessible only for authorized users, so here the tool detects a potential policy violation, and it suggests to add a dependency on the authorizer to ensure the authorizer is updated first.

I have said that we wanted the tool to be scalable, so we have evaluated it on existing files from public repositories on GitHub, specifically we have on 36 of them, and all of their different versions and updates, and in all of these cases, hardware was run under one second for each,

so we believe it can be used by developers maybe as part of their continuous integration pipelines in order to check the infrastructure before they actually deploy them and fix issues, if the tool finds any. In conclusion, we have presented a new type of vulnerability

that happens in Infrastructure SCOD, that is called intra-update sniping vulnerabilities, and we have presented a first model for Infrastructure SCOD and their updates. We have implemented a static analysis of updates that is able to suggest constraints to avoid vulnerable intermediate states,

and our tool, Hayha, is available online as open source at the following URL. Thank you for your attention, and I will now be very happy to answer any of your questions.