Attacking and Defending Infrastructure with Terraform: How we got admin across cloud environments

now for a very exciting show coming up here we have mr mike ruth talking about attacking and defending infrastructure with terraform how we got admin across cloud environments so you have a background i guess you're working at brex right infosec all right well uh take it away let's get them around the hand up there [Applause] thanks everyone i want to say like it's great to see everyone but i can't i can't see anyone actually right now so but thanks for coming my name is mike i'm a staff security engineer at brex my co-researcher oka was unfortunately unable to make it but just know that sort of all the slides and all the presentation and research that we talked

about today that was uh done through both of us so big thanks to him so yeah i want to talk a little bit about our supply chain security hacking terraform um in particular we're going to talk about how we got sensitive credentials as well as ultimately access into admin into cloud environments okay so i'm sure that a lot of you probably already know what terraform is but for those of you who don't or perhaps a bit of a refresher um i wanted to talk about some of the basics starting with what is terraform so terraform an infrastructure as code tool right um and it's used to manage and deploy uh cloud resources as well as a handful of

other resources now whether it's on-prem with vms kubernetes clusters now has support right vault handful of other things they come in a different flavors it started as an open source tool and for individuals who probably use the open source tool still they're probably using it directly from endpoints strictly from laptops right so that means that all of your source code is local to the endpoint all of your credentials to be able to get access to cloud environments and things like that that's also local to your endpoint um over time though you know the idea to productionize that so that you can remove those types of credentials from those environments um you know it became more and more of an idea

and so hashicorp came came around and pre created this sort of productionized versions right these are things like terraform enterprise and terraform cloud the scope of this presentation is going to focus on those latter two things terraform enterprise and terraform cloud and not so much on the open source version predominantly because all the credentials and things are already local right um for individuals or or companies who may have productionized terraform their open source version of terraform themselves some of our findings might still be applicable but just know that the majority of things that we're talking about today are through term enterprise and internal from cloud all right so let's talk a little bit about the internals of these services or

these tools i think it's best to start with organizations and workspaces so these act as logical boundaries starting with an org you tend to have many workspaces inside of a network inside the workspace that's where you sort of manage all of your resources and these workspaces they tend to be associated sort of one-to-one with your different environments right so you might have a workspace for your dev environment a workspace for your staging environment for your prod environment right you might also have workspaces specifically for a dedicated application an application in devs staging prod etc but typically you have them per per environment inside a workspace you tend to have what's known as a state file and as the

name implies it handles and persists all of the changes that have occurred what it believes to be the state of your given environment so this is useful so that when you go and make changes in the future there's a cross-reference between what it thinks is currently out there in states as well as the incoming changes so that they can perform a diff between the two the sort of meat of what happens inside of the workspace are all done by providers so the providers are responsible for making all of the changes in your environment so we might have providers for a bunch of different clouds aws provider gcp provider kubernetes provider etc right these are binaries that run

that are responsible for knowing about all of the resources that need to be managed right so it knows about all the configuration details and it knows how to hit the responsible or the related apis for that given provider to go and actually configure and apply those resources okay a little bit about access so for an organization who may just start out using terraform enterprise or terraform cloud it may be such that you've removed for example all of the cloud credentials from your endpoints and instead have replaced them with terraform credentials so that they can go and actually make requests to terraform enterprise terraform cloud etc and this works very much like a crud model and it's on

a per workspace basis they don't necessarily call it crud instead they use different terms plan apply read you can see their definitions here up until a couple years ago these were basically the only permissions that you could modify on a given workspace but now you can actually use custom workspace permissions and this is actually pretty relevant in particular for the read based permission because read for a while meant being able to read the output of a given plan or apply but it also meant being able to read the state and the state file the contents of the state as well so these custom workspaces permissions were actually now granular enough to only say allow read access to the output and not

necessarily read access to say the state file which you'll see might be relevant coming up here okay so there are there's some challenges or perhaps some problems with having everyone at your company or anyone who needs to manage infrastructure at your company to be able to go and communicate directly to terraform itself so a more sort of mature approach might be removing access all of those sort of individual credentials for being able to get access to your terraform cloud or enterprise systems and instead use version control this is actually pretty beneficial for a developer experience perspective too right because you don't necessarily want everyone to go and learn a new tool but most people are probably at least most engineers or

developers are probably pretty familiar with version control right github probably in particular and so the way that this works is you have a repository map to a specific workspace inside of say terraform enterprise or terra from cloud so there's sort of a one to one relationship between work state workspaces and repositories you might have a monorepo instead where you have sub directories that map to workspaces but this is essentially how this works and so when you have a repository and you go and submit either a pr or commit to it it goes and kicks off what is known as a speculative plan against the workspace and that speculative plan is then responsible for doing uh like that dry

round that we kind of talked about or that you saw on on the access side of things one thing that's worth noting is that speculative plans do not show up in a work spaces job queue so a job queue is basically all the list of plans or runs that exists for that given workspace that'll be relevant for a little bit later so just keep that in mind when these jobs are created though we have sort of a set of nodes this terraform infrastructure just a bunch of compute that's responsible for like doing all of the work that's associated with whether it's a plan or apply right all the job and and those are terraform workers right those are the responsible

for doing the actual work itself and so the idea for this reference architecture is you know you you have these terraform plans that exist they provide provide dry run results and then you go and look at the results perform some sort of code review if everything looks sane you merge the pr right and then you actually perform and apply and that's how your infrastructure gets gets modified updated and managed so this is sort of a reference architecture diagram at a high level we're going to be talking and showing this type of diagram a lot in it so it you know it probably makes sense to just sort of take a second here and look through it

so

it's a pull request the question was what's a pr um so it's it's a request to go and make change to a to your version control to your repository so a user goes and creates a pull request to the given terraform repository that goes and kicks off the speculative plan that we talked about which just happens to be a web hook that gets configured on your repository for the specific uh workspace you can figure that beforehand and so that pr gets triggered the terraform workspace has a job that gets scheduled on the terraform workers then your resources are eventually managed after the terraform plan gets reviewed the code gets reviewed merged and eventually applied okay so problem statement

we contend that in most organizations most engineers have access to create prs against your terraform repository so maybe a quick show of hands for individuals who use or have used terraform enterprise or terraform cloud at maybe their current organization or previous organizations show of hands how many of these organizations sort of allow blanket pr requests to terraform repositories i i see a handful i mean hold on yeah all right i see a handful and it makes sense right it's it's good developer experience to be able to sort of allow many individuals to create prs and the assumption is that that's a safe action so why is this a problem all right let's talk a little bit about

our findings so finding number one is all about secret sex filtration so we were able to access the secrets of a workspace through a terraform plan and in particular a speculative plan from a pr this allowed us to exfiltrate all of the terraform variables all the workspace environment variables and all the secrets that existed within that state file for that workspace so some of the secrets that might exist in state depending on your organization might be secrets that exist in hashicorp vault so if you have some sort of connection there if you've got a vault provider it would make sense to manage your secrets in such a location but in doing so referencing them in your terraform

workspace means that they end up also getting stored in state another type of secret might be say certificates or certificate keys so if you're responsible for handling ingress or load balancers or any sort of you know front-end communication and you want to do that in a programmatic manner you might use terraform for that well certificates and keys they might end up in there another use case is kms encrypted secrets if you're doing any sort of encryption in transit and you want to define say the cipher text inside of your terraform source so they can be decrypted in sort of this programmatic fashion well uh all of the uh both the ciphertext and the plaintext might end up in state file

as well so we were able to get access to all of this and this is sort of a workflow for how how it worked so step one very similar to what we looked at for our vcs reference architecture instead of um any individual creating a pr well now a malicious pr gets crafted and that gets sent up to the terraform repository which in the same way kicks off a web hook that triggers a plan that goes to the terraform console which eventually ends up being run on the terraform worker and then our malicious code kicks off and goes and extracts all of the environment variables that exist for that job and either sends it back to the output of

the plan if you have access to that but it's just as easy to go and send that information say out to a remote listener that you've already configured ahead of time okay finding number two this is about state exfiltration so we talked a little bit about workspaces being logical boundaries and we talked about how each workspace has a state file we were able to access the state files through a terraform plan of all the other workspaces inside of an org and we're able to do that from one individual workspace or any individual workspace and so the way that this works is that um whenever you create a job for a given workspace that runs on those workers

a token a terraform run token is what hashicorp calls it is created it's also known as an atlas token if you kind of look at the variable name and that gets available with every plan and every apply and it turns out that that token is sort of over authorized it has the ability to go and fetch the state from any other workspace that's within that organization similar workflow malicious pr gets crafted web hook triggers a plan plan goes to the console that body of work gets um kicked off on the terraform worker uh then a malicious code runs we go and fetch that token probably using finding one right and then we can go and fetch

the state from a given workspace by communicating to the terraform console and similarly we either push that the results that are in the state file back to the terraform console or you kick it off to you know send it to a remote listener okay finding three this is probably the most important finding apply on plan bypass so it turns out that when you perform a terraform apply you can actually perform a terraform plan within inside of it so our expectation if we consider our reference architecture previously there was a an assumption that existed where when a plan was created some sort of review had to happen prior to the apply step right that you needed

to do the code review you need to merge the code so that you can eventually perform the apply turns out that's not actually true we were able to perform terraform applies through unmerged non-code reviewed prs and they're super difficult to audit too because they're those speculative plans that we talked about earlier because the speculative plans don't show up in the job queue it's not easy to see you have to go through audit logs that provide you with sort of a run id and so now you need to know exactly what you're looking for or you need to come in sort of from the other end and know exactly how to look at a specific pr to find it

perhaps more importantly depending on the use case it also grants access to the underlying file system of that terraform worker so depending on your environment this may or may not be critical if you're using terraform cloud then all the workers are managed by hashicorp themselves and they're pretty well locked down they have your own dedicated aws account for you they don't have any instance profiles or any extra im permissions so while you do get access to the underlying file system and you might be able to get remote code execution you're not necessarily getting lateral movement here however if you are using terraform enterprise you're responsible for managing those terraform workers yourself and that probably means that they exist inside

your network and that could mean that the terraform worker has access through vpc peering or through transit gateways or some sort of access to all of your other environments that exist as well and of course privilege escalation is kind of the big thing here if you have access to the underlying file system of your workers chances are those are configured with some sort of best practice in mind right so that means if you're in aws uh the workers are using probably assume role with terraform profiles if you're in gcp or azure you're probably using a service account of some kind and in all those use cases you can hit the metadata api to go and fetch those credentials

and because terraform is responsible for managing all of your infrastructure and all of your accounts it's probably admin level credentials that you then can get through that so privilege escalation is very real and the last point that i want to make on this slide is with we don't talk too much about policy enforcement but hashicorp does provide sentinel which is sort of a policy enforcement framework and more recently they've provided run tasks with terraform and so the idea with these is that they you can have sort of an advanced language to be able to enforce any sort of you know your unique or niche use cases that you want to sort of prevent these types of things from happening

uh but unfortunately these things run within the context of a pre-apply and post plan so any sort of policy enforcement that you might be able to get out of these tools only applies after a plan and since all these attacks are occurring during the plan step we were able to bypass them as well

similar to our last two findings finding three is the apply on plan bypass again malicious pr gets crafted pr kicks off a plan the plan goes and runs we perform an escape from that the context of the plan onto the underlying file system and instead of sending the exfiltration results to say the console or to a listener we actually just go and we actually write malicious resources into the environment itself okay so let's revisit the problem statement if anyone in your organization can draft prs against your terraform repository that means that they can exfil exfiltrate secrets from any workspace they can access the state file from any workspace they can bypass all this access control

that we have in place right through unmerged non-code reviewed prs and perhaps more important to some you get access to the underlying file system of your compute for your tf workers okay so we have some demos i want to show you that kind of illustrate the workflow that we just went through

so this is sort of the demo architecture pretty similar to the reference architecture that we have looked at already so we have this sort of fake hypothetical company crypto exchange co uh and they have a repository that goes and creates speculative plans uh through this vcs integration and they've got two workspaces website dev and website prod so basically they've got one website that works and they've got a dev version of it they've got a prod version of it because they use terraform cloud their terraform workers are all kind of within the same environment and then the terraform workers are then responsible for managing the resources in a dev cloud as well as in a prod cloud

okay so let's look at finding one which i think needs a second to load this video here there we go okay so we're going to run this get environment on the dev uh the dev workspace so we go and create a pr the pr gets kicked off with a sort of innocuous or simplified name creating a template instance so it's very unassuming we can see when the pr is created that the web hook is generated against the website dev we go and take a look at the details inside of the terraform console and in there our malicious code is running where we generate a null resource to null resources in fact one to go and exfiltrate all of the

environment variables which you can see all the environment variables of the worker are just sort of listed here and also the environment variable tf vars which as we can see has say presumably provider credentials for aws

here's finding number two similarly we want to get the state file from our prod environment by running in the context of our dev environment so again we go and create a pr the pr is run against website dev as we talked about you can see that there the plan kicks off and we can see again that our malicious no resource was created and inside this we'll be able to see the link to the state file right there and then we sort of unfurl what's in there and we see that we have database credentials from vaults configured and those database credentials are associated with with what appears to be the prod environment so we've been able to get

say an act username and password for a prod environment through a pr from dev

okay finding three so we want to perform an apply on plan for our example we're going to go and create an s3 bucket so this s3 bucket is going to be named remove this bucket so when we go and take a look at our current environment we can see that crypto exchange code does not have that s3 bucket so we go through our same process again we go and create a pr pr goes and kicks off the terraform plan the speculative plan we're in website dev malicious code triggers a null resource and then here we can see that the terraform apply is actually running and we can see the output of the apply right here

apply was complete and resources were created so we go back and take a look at the environment remove this test bucket exists so we were able to go and push resources through a plan even though you know it was actually performing and apply okay um so next let's talk a little bit about remediations mitigations and some limitations to those so the first thing that we thought was like okay i think we've got something here what should we do uh so the first thing was we should probably talk to hashicorp about this and so that's what we did we ended up getting in touch with a couple of individuals from hashgraph security team uh we brought this to their attention we

had some of these conversations uh and they sort of agreed uh you know that these were sort of legitimate findings so the outcomes of these discussions were sort of twofold number one was that a security model which consists of sort of a threat model uh was created and available to everyone and then the second thing was well there were some actual mitigations for some of these findings

i wonder if does that help hold on slideshow that's better okay so this is the security model i you don't need to squint and it's actually blurry apparently so don't worry about it the link is there and we're gonna dive into uh each relevant section for each finding a little bit more so don't worry too much about this okay remediations for finding one so the first thing is you know while we showed that this was applicable with speculative plans it's still just as true for regular plans as well right if you have the credentials to go and interact with terraform uh you can make the same types of you can you know use those findings as well so if

you're not using version control um and i guess regardless actually you should probably implement the proper access control on terraform enterprise terraform cloud and all the workspaces right so this means that we should limit who has plan apply and view access on all the workspaces if you are using version control with that web hook configured chances are the majority of people do not need plan apply or view state they might not even need to view the the output the only individuals that are probably need to do that are the owners or the individuals that are reviewing code secondly is probably implementing access control on on github on your version control right so chances are you want an

approval flow you probably do not want by default everyone at the company being able to uh submit these prs this is sort of you know lease privilege if you will the third one which is probably the most technical control here is you you can disable speculative plans and that's currently disabled by default you have to turn it back on but if speculative plans are disabled uh well then plans aren't being being pushed and you know the the avenue for these findings uh is basically gone so here's a bit of a all right yeah that looks pretty good so if we this is the same workflow that we've shown on the previous slide but now we're seeing it

in the context of hashicorp's security model starting in the top right vcs contribution is the individual right the user they may have access to go and submit a speculative plan which ends up being able to read sensitive workspace variables which is kind of in the bottom left here okay so what are some of the limitations to these these remediations these mitigations that we've just talked about well the first one is if you even though you have all of these access controls on the given workspace well if you have a speculative plan that's running it's going to bypass all of them right because it has plan access that's what it's responsible for doing if you have access control on version on

your version control systems it's very possible that you've just implemented some sort of regression to your developer experience right it's really i mean when i asked with a show of hands how many individuals work at companies that anyone can push pr's the reason for that is that it's very convenient to do that so if you remove that convenience you know you're sort of shifting the way that many individuals work at the company and that might lead to some you know experience problems uh the most important one though is you know disabling expected plans because it removes that web hook it makes it super difficult to review code you know i'm not sure about anyone here but for me

when i go and review to terraform pr the first thing i do is look at the plan results from that speculative plan to see like what is changing and what's happening and when i take a look at that then i can cross-reference it with the source code to make sure that those two things align and then i can go and you know sort of give the plus one on the code review so without the terraform the plan without the speculative plan that gets super difficult and often times that might be a non-starter this is part of the the security model documentation from ashley corp one of the things was basically what is out of scope for their

security model and we can see the first thing here is malicious contributions to terraform configurations and version control right and that's kind of that's the demo those are all of our findings so we can see why sort of the planning one still exists even though we have some sort of mitigations in place there isn't a surefire remediation okay finding number two much better story with finding number two so we talked a little bit about this atlas token or the tf run token and how it was over provisioned well the most sane thing to do was actually reduce those permissions by default and that's exactly what hashicorp did so they created you know you can see the

announcement link here on the slide but basically the idea is by default that token does not have access to all of the other workspaces within the org however if you would like to provide access to specific workspaces back you can do that inside of the console itself you can see the workflow here that we've talked about but with the context of the security model again starting in the top right someone pushes a pr kicks off the speculative plan typically that means that the terraform run token can go and read and get access to the state file for other workspaces but with this change that's no longer possible and here's a little gif that kind of

shows that functionality in action so we can see that you can share state globally which is sort of the known bad default prior however the default today is with that off and you can then on a sort of workspace by workspace environment add them back in limitations on finding two um you know the finding still exists we've sort of reduced the blast radius here unless all of your workspaces have this off by default um you know you're going to slowly add you know a threat landing in the threat landscape a little bit more right one workspace might be of access to just one instead of all the other workspaces i think it's a pretty good mitigation in those types

of scenarios though we didn't talk too much about cloud agents um the cloud agent is basically the agent that you can put on terraform workers or on compute to turn them into terraform workers so this is something that you might want to do if you wanted to manage your own terraform workers with terraform cloud for example basically the cloud agents have their own token that can go and fetch jobs from the queue and when you fetch a job well you get all the environment variables that exist in that job and so that means that you can potentially go and get access either to the state file or to any individual workspaces in the state files of those workspaces

that it has access to and we can see from hashicorp's threat model that that's the case right crossworks based data access via cloud agents is still possible okay finding three i wish that there was a better story for this um there aren't very good remediations at the moment um that's finding three is pretty similar to finding one at least in terms of um the access pattern right the the exploit pattern as well as some other remediations so we can limit perhaps who can commit and create prs on the repository we might be able to prevent speculative plans but they come with the same sort of regression and developer experience that we talked about with finding one

there is a possibility of system level enforcement it's not something that we've looked too much at but if for example your terraform workers are running linux you might be able to use things like app armor se linux things like this and create profiles to ensure that all of those providers the binaries that are running all of this code they might not be able to do things or you might have them configured so that they can't do things like run arbitrary bash or run python scripts or things like this that's worth noting that this is only going to be possible if you control the terraform workers if you're using terraform cloud and they manage the terraform markers this type of

mitigation is not going to be available okay so when we take a look at the security model in the pathway there actually isn't an established route for this when you take a look at the contribution and it goes and kicks off a terraform plan there is no line if you will to the terraform apply operation so it's not actually well established which is probably why there aren't very good remediations that exist so like we said there's some limitations and they apply mostly from finding one and again you're limiting the blast radius which is great by limiting access control and who can submit prs but it does not actually remove the finding itself and we can see malicious contributions

again but if we think a little bit about it if we could sort of be in the hashicorp engine engineer's shoes or if we could you know snap our fingers and provide any functionality what what could we think of for proper remediation for this finding and so this was sort of something that we came up with and i think that we see this pattern in the open source productionized versions where people have sort of full control if they're not responsible for or if they're not using terraform enterprise or terraform cloud but organizations are instead using open source version of terraform and they've got the flexibility i think we start seeing some of these things so when we go and take a look at

how the web hook triggers a plan and step number two the terraform plan should have its own dedicated permissions right only read-only permissions for terraform plans furthermore it has dedicated infrastructure only plans run on this set of terraform workers today you have sort of a set of nodes a bunch of terraform workers that exist both plans and applies will run on those sets of terraform workers so in our sort of proposed model we have dedicated permissions as well as dedicated infrastructure right back to the basics separation of duties and least privilege that way if we try to attempt to perform any of our findings well yes you can still perhaps you do read based actions

but any sort of right-based actions that might happen to be attempted to be performed to the plans well they're no longer possible because the permissions just don't exist there and that way um finally when you get to the terraform apply step well then you have a completely different role or different set of permissions that has read write and it's capable of performing you know read and write based actions the one thing that i will say here that isn't kind of listed is if you have the ability um again maybe through this sort of open source version that we see i you might be able to put access control or policy enforcement kind of before the plan step and that

would be my sort of my suggestion as well uh you know to say hashicorp or anyone who has the capability of doing so is let's consider these secrets how great would it be if we could just move those they actually run pre-run or plea pla pre-plan and not after plan right and now we might actually have uh an opportunity to catch sort of these types of malicious code and things that we're running during these speculative plans and in our prs okay some conclusions um if there's anything that you take away from this hopefully it's these three things one all of these findings are still exploitable today so be sure to go through the remediations that we've talked about if

you're practitioners or users of terraform enterprise or terraform cloud bullet number two we should really have separation of duties and applies with these enterprise products and i hope that they come soon um you know we should make sure that we have those separation of duties and least privilege and number three secure architecture and the threat model documentation that hashicorp put out right i think it's super important for practitioners to understand what the strengths and weaknesses are inside you know of the products that you're using and i think that'll be super helpful to take a look at okay last but not least we didn't talk too much about the how here we saw some demos and we saw some workflows

we just didn't really have time so if you're interested we've automated all three of our findings it supports two entry models whether you've got a repository that's associated with your terraform workspaces or if you have access to make requests and plans directly against terraform with a terraform client you can go and take a look at the link here examples and usages are all on the readme but you can go and download that and use the automation for yourself and that's it thank you very much for attending

any questions excellent good stuff here man i really appreciate your work hi um should we take this as a cautionary tale uh against having um you know companies like terraform with their commercial products do this for us i mean i i thought that was a very interesting point you're seeing people who were working in open source they may have some limited features compared to that commercial offering or more work to do but as a does this should this cast into doubt just the whole idea of infrastructure as code being uh outsourced to a for-profit enterprise like this oh i don't know well i mean when do you think they might fix this well um i don't know the answer

to the last question but i will say that there's a constant build verse buy challenge that all of our organizations face if you have an infinite number of resources in an infinite amount of time maybe you can go and build this open source version and maybe you can go and solve all these problems but lots of organizations don't necessarily have that opportunity and i think this provides a lot um you know if if the alternative is that all of your endpoints for all of your developers or engineers have aws creds in the prod i think that this is probably the better approach that would be my thought there any other questions went over here all right

hey mike uh quick question i know it's your first two examples used null resources in terraform i couldn't tell if the third third example did it did it did okay great so i was assuming we could also mitigate this by limiting the use of null resources in terraform did you like exporting ways of doing that well on terraform enterprise or cloud i i don't think that it will solve the problem because the no resource was just the one that we ended up using because it was the most convenient but there are a lot of different providers that can do the exact same thing you've got remote provisioners you which actually work on apply but you also have

http providers there are remote providers from remote marketplaces so while i do think that trying to take a look at specific providers and not allowing them to to run that might be helpful um again though a lot of the policy enforcement that well anyway yes i think that that's a uh avenue of invest you know research and investment but a lot of times that might not be feasible if you can get rid of everything that might be able to work i will say one last comment is we were able to exfiltrate all the environment variables um just using the aws provider right we could actually set the name of a resource to the value of a secret and it would just

show up in the terraform plan results so um i think it would be a slippery slope i don't think it'll solve the problem i guess is what i'm trying to say i think they'll find other avenues to do the same thing okay we got another question um hi uh thank you great talk um i was wondering if there is a way to use other tools like static code analysis tools kind of like checkup or some grab to develop uh detections prior to running the webhook as early as the steps to the pipeline use some other tooling yeah possibly right so chekov is pretty cool because it does provide sort of this sanitary you know in like even even on a

developer endpoint right it could provide some sort of uh feedback um it's not something that i've investigated too much and i don't know what the extensibility of those types of tools are um if i mean i'm sure clint might be here if you know if he's a some grep expert so that might be something uh worth talking to to anyone who knows a little bit more about that excellent question all right we got another one uh thank you for your talk it's extremely illuminating i'm sort of already in a thought process about how to control some of this stuff and we're considering taking on uh resource whitelisting or allow listing to attempt to mitigate some of this and i'm

wondering i heard your about the information leaking but at the very least do you think that would be an effective control against the arbitrary script uh execution stuff maybe i guess it depends on how you're doing white listing i've read um article like uh vendor sort of uh customer like articles that are in unison with hashicorp that try to use sentinel policies to try to do these types of things um the problem i guess that i was i mentioned right is it happens a little too late so potentially you could do white listing it just depends on where in your sort of supply chain you've put that if it's prior to your speculative plans then that might work you know if it's a

if it's a web hook that kicks off that prior to you know your terraform plan web hook or you know it's required to run before your tow from plan web hook maybe that's something that that could work yeah okay other questions here all right um oh good fantastic you might great presentation um just quick question like what would you say is some or i guess kind of like low effort quick wins that you'd put into place just based off of everything right there was a kind of like a lot of mitigations that could be used but would be some quick things that you could do easily to prevent some of these i would i would say that um they're probably all

of the suggested remediation points that i was suggesting right so it depends on each organization's environment um you know if you're using open source and you've got all your credentials locally move to maybe an enterprise version or productionize it if all of your engineers are have access to the credentials in terraform let's remove those and perhaps use version control if you have the capability of putting like pre-configuration checks prior to your plans that's probably a little bit more effort but all the access control for vcs and for um for these providers i think is super important starting point okay cool other questions all right um i guess one last point for anyone sure who wants the slides um i think i can

upload them to the b-side site or um i'll i'll put them on my twitter as well and uh is this part of the show here up on the board what is that oh i mean i've been doing this whole conference just to summarize it oh it's pretty cool i'm super pumped by it i love that we have one here excellent work i'd like to think that i probably don't should get a screenshot

okay well i can tell you i've learned a lot from this i mean i've packed it before but a different way and but now you just like really took a deep dive on me are there any other websites uh of hacking uh terraform that you know of oh yeah i've seen plenty so we started in this research in 2020 so it's been a couple years with covid and all that stuff we haven't had a chance to present it but in that time you know similar i've seen similar uh blogs and things like this have come out so yeah i um i don't know the links off the top my head but they they're out there so it's uh great for red team

exercise pipeline poisoning right sure okay um last chance for questions okay well please give it up for mike ruth in conclusion of this sorry francisco akka couldn't make it but thank you and y'all have been a wonderful audience as well so