Action Anomalies: A Hacker's Guide to Github Actions

welcome back ladies and gentlemen how was your lunch fantastic as I see uh some people were so eager to eat that they found ice cream machine this is a very interesting compilation for me a man who's been sober two years seeing people celebrating ice cream with a beer very Estonian of you you go and also by the way why we were talking about cyber security I just have to point out don't forget the physical security the amount of amount of people with crotches and hands that need to be repaired I hope everything is going to be all right and a quick reminder for the students in the room if they are in the room after the second part of our

today's session and during the coffee break you are welcomed at the gathering with Rushmore at the workshop room but I'm going to remind you that at the end as well because I've been a school teacher I know how it works now we kick off our second part of the presentations with discussion of security risks in GitHub and we are going to hear about research based on sync security Labs work and suggestions and case studies uh to help secure GitHub so please welcome with action anomalies a hacker guide to GitHub actions Mr Elliot w

cool so thank you uh all for yeah coming to this uh my talk is yeah action anomalies a hacker guide to GitHub actions um and this is based off some of the research that we've done recently um but kind of just first we have the obligatory who am I slide uh so my name's Elliot and I'm from the UK but living in Zurich and Switzerland uh it's my first time here in Estonia so it's really cool to come and yeah visit your city and Country um yeah I'm a skateboarder snowboarder um and when I'm not hacking or skateboarding uh I'm playing probably too much RuneScape um so if there's any RuneScape players out there uh be yeah

let me know old school RuneScape not RuneScape 3E um so that's me um and kind of just to go over what we're going to talk about today so we'll very briefly introduce sneak and who sneak uh security labs are and what we do uh and then we're going to kind of go over what gith back are we're going to look at what the threat landscape is and kind of some of the misconfigurations and vulnerabilities that this can lead to uh followed by uh yeah presenting some findings and the GitHub action vulnerability scanner that we wrote to uh perform our scanning on mass basically and then we'll look at a couple of counter measures so if you're

in a a security engineering team uh or a developer then uh you can avoid making these mistakes basically so kind of just to briefly introduce sneak uh so it's not a sales pitch but if you don't know who we are we're a software security company and we kind of focus on building tools that allow companies to stay secure while developing uh so we do that through a couple of tools we have like a SAS tool an SCA tool we do container scanning IAC and just like General appsec tooling um so if you want to know more come and speak to me later um and then I work in a team called security labs and we are basically a

small team of just three people uh so it's yeah the guys on the screen there um and we kind of tend to try and do high impact uh security research that kind of has an impact on more developers so we don't really do as much stuff with kind of memory corruption bugs but we'll be looking at things kind of like Docker or like hugging face terraform um and just things that have like an impact on General and wider Developers security so what are GitHub actions uh so GitHub actions is basically the CI platform um that's built directly into GitHub and it's quite similar to things like Jenkins or circleci if you've ever used those and these allow you to

basically do automation they allow you to automate tasks uh like building uh building your code running tests running your SAS scans or deploying to some environment once those tests finished um and yeah we Define these via workflows um and those workflows exist within the repository itself um so what we're going to have a look into kind of how GitHub actions Works what its architecture is uh some of the key components and then we'll go into some of uh how those components can be misused and lead to uh some issues that can allow us to basically take over organizations repositories um based on some of these misconfigurations with some examples so just in case kind of people aren't

familiar with how a typical GitHub workflow would look like um we'll first have a look at what this might look like uh so then we can see how uh the kind of gitops flow works and how GitHub actions kind of fit into this uh so we basically kind of have a GitHub repository with a main branch where our code exists um and then when when we want to add or build a new feature uh we don't build directly into main we typically make a feature br brch and this is kind of separate from the main repository um and then this is where we make our changes we add our commits um and we do that to the feature branch and

then once we're ready we open a pull request back to the the main branch um and then we can yeah go ahead and merge these basically um and at this point uh we have our code and it's uh it's merged into the repository so this is all great um and then kind of just like what are the use cases why would we even want to have some C like continuous integration or continuous delivery um and it it's quite useful so like once we do that merge back into the main branch like we may be working with external contractors we may have different development teams all working on the same product project um and yeah we want to make sure that we have kind

of quality control in place or maybe automate deployment so it's very useful to have some sort of CI and CD and it allows us to kind of run our unit tests and basically if some of those tests fail then we can reject the PO request and we don't merge it into production and then we end up with kind of yeah some some quality control and then we can also use it for things like sending slack notifications or like uh if if something breaks in the the main build or like we we can basically do anything we want uh within the life cycle of uh our giops basically so kind of now that we understand why you might want to use

GitHub actions let's have a look at how uh how it works so that we're in a good position to kind of explore the threat landscape and see how we can attack and defend uh GitHub action based workflows so GitHub actions uh basically automates the workflows in the repository um and these are triggered by various events like pull requests or somebody creating a comment um and yeah these can run like either sequentially in parallel um and they're basically made up of jobs um and the jobs are sets of uh predefined actions um um and yeah these can simplify our workflows uh so let's kind of start with uh the key the main key concept of GitHub actions which is the workflow um

and so what is the workflow it's basically a yaml file that exists over at the yeah in a directory within the repository GitHub uh slw workflows um and yeah there we can basically create workflow files by dropping our yo files in there we can have multiple workflow by dropping them into separate yo files um and then yeah these are highly configurable and we can yeah have a lot of flexibility with how uh these work and how they're triggered um and we typically have three ways of triggering that with kind of events manually uh or with like a schedule um so kind of the next level down we have the workflow and then we have the events and the events are

basically specific activities that are going to trigger the execution of a workflow um so the kind of common events that we might see are things like pull request commits pushes issue Creations um and as well as like some external triggers so we have uh kind of like workflow dispatch calls we may have external API calls that trigger the execution of the workflow um and these are all configured in that yaml file that I've mentioned um and this is done by using the uh on directive or keyword and then we can also customize the activation of these workflows uh so we can have things like event filters and these allow us to have kind of more

granular control so maybe we don't want every like push to the repository to trigger a workflow or every merge but we only want this to happen when somebody merges into the main branch uh so we can do that with event filters and then kind of yeah within those uh yeah workflows uh that basically we Define jobs uh and the job provides us a structur approach to to basically managing the execution and each job uh groups related tasks that are yeah designed to accomplish kind of a specific task um so this might be running a security scan yeah building the code base or deploying to some environment um and those jobs are broken down into steps which are basically the

individual uh actions to achieve the task um and each step is basically like a shell script that's uh just put into the the Amo file or we may have a pre-built action that we call upon um and we'll discuss this in the next slides um but then yeah kind of another important thing so like when we have these jobs they basically run uh within the same environment so all of those jobs are going to kind of have a new environment uh specific to that job um and we Define these with the the jobs keyword and by default they run in parallel but you can configure this based on on your needs um um so kind of when we have

those jobs these are further broken down into what we call steps uh and these steps are the building blocks that Define the the individual actions that are required to actually complete that job's like task uh so each step represents a single well-defined uh action within the workflow um and we kind of have two main approaches to Define these steps so we can either create uh with custom shell scripts as I've mentioned so we can either have like an inline just like command or we may invoke some yeah shell script that's in our repository or we can use uh an external GitHub action uh so with those GitHub actions these are shared uh we can access them from the GitHub

Marketplace and when we do that we basically import it from uh an external repository um and that's kind of predefined things like checking out a repository or like common tasks that we don't want to manually do ourselves every time um and then kind of another important thing I've mentioned so like when we have those uh jobs and steps I mean these are going to run in the steps run in the same environment so each job gets its own environment um and then the steps have a shared environment uh and this is kind of useful so if we have for example two steps inside one job one pulls down some code from a a URL um and

then it does something with that um so they will share the same kind of dis in that Spa in that environment it will also have the same same uh kind of network um it will have the same uh volume mounts so we can kind of persist data within that step um and then yeah by default they run one after another um unless otherwise specified and this is kind of expected like we want to download some code and then do something with it and then we have the concept of the pre-built actions so these are basically code modules uh that automate those specific tasks like pulling down some code from GitHub um and yeah basically eliminates

the need for repetitive code um and then yeah basically when we want to use these pre pre-built actions uh we can simply reference these uh yeah within our workflow in the ammo file by using the users keyword um and there are kind of three ways to locate or reference an action we can either use a local action uh which we basically do by having like a a slash notation pointing it to some uh resource within our repository that we've checked out uh we can also kind of point it to a GitHub repository by using the the owner/ uh the repo and then the reference of the the commit um or we can use Docker where we can point it

directly to some yeah Docker image and it will go ahead and spin this up and run it um so and then yeah we have the marketplace where publicly available actions exist

there we go um and then when it comes down to actually running and executing these GitHub actions we have two options basically so GitHub provides hosted Runners um and these Runners are basically managed by GitHub and they take care of the infrastructure ensuring that they're available um whereas in contrast we can also have self-hosted Runners but when we use self-hosted Runners these are going to run on our infrastructure in our Cloud environment or our on Prem um so I mean it gives us full control over what happens there um but there's some pros and cons and trade-offs between them so kind of when we look at the environment consistency with the GitHub hosted Runners every

time uh a new job runs we basically have a a fresh virtual machine essentially uh so there's no like leftover artifacts left there um whereas with a a self-hosted runner they are going to remain um and this could be useful uh or it could kind of just get messy um so that's kind of one of the things um and then we have kind of like limited customization over the runners so when we use some one of the GitHub hosted Runners uh we basically only have three options for kind of the operating system uh we can just say whether we want a Linux or Windows or a Mac uh container to run those uh jobs whereas with um

yeah when we use a self-hosted one we have complete control so we can like have all of our pre-installed scripts that we need Etc to kind of have any task that we want to perform so everything's already ready for us um and then yeah kind of finally the last one's kind of obvious but any security issues within the base images or kind of the operating system uh with the GitHub hosted Runners that's going to be handled by GitHub so we don't need to worry about patching them um whereas with our self-hosted Runners as your security team you're going to need to make sure that you're updating and patching these and keeping them in a in

a reasonable state so kind of what does this all look like so here we have just a kind of a basic uh yeah yaml file um and kind of we have up here the workflow name and then here we have uh basically the uh the event trigger and we have uh push so this will trigger on a push event and then we have basically an event filter here so this will only trigger on pushes through the the main branch um and then we have kind of two jobs that we've defined so we have job one job two um and then yeah the first one this runs on your buntu so this is basically the runner that we've defined and then we

have some steps here so we basically have a checkout and then we run some commands so this is the actual step this is uh the job um and this one's using a shell script um and then down here we have a second job and this one depends on the successful execution of job one uh so this is kind of how we can also manage the kind of execution flow and how things actually run um and that's basically a a simple yaml file uh so kind of then we have the GitHub token uh and this is an automatically generated temporary token that's provided for every time uh it's provided by GitHub every time a workflow runs and this allows our workflows to

authenticate against GitHub um services so and it's basically scope to the workflow and it's accessible via the secrets. GitHub token context um so and yeah this this token enables us to perform actions like uh cloning repositories pushing commits uh uploading artifacts to some place or kind of just interacting with the GitHub API um and there's some interesting quirks regarding the the kind of permissioning of these tokens uh so before uh yeah 20 2 uh sorry 2022 uh any organizations that were created before 22 uh the default permission sets on this this GitHub token was read write um and this has now been changed uh for organizations that were created after we now only have uh

the rep permission um and this isn't for repositories created after 2022 like if your actual organization was created before uh then any new repositories that that you create will also inherit the default permission which is read write um but we can customize this via the um the workflow file or in the uh settings within GitHub um and yeah let's see how we can do that so you might be wondering how we actually uh change the scope um and yeah we can change this at the Enterprise level uh the organization or the specific repository level um and to do that we just need to go to the appropriate settings page go to the select actions then General um and then

there we can basically set the uh permission for the the token and while that's very powerful um it doesn't give us much fine grain control so there's a lot of different things that can actually uh that we can use that API to speak to or various Services um and just setting it broadly to read write could be quite dangerous so we can also further customize these um by using the perm Scopes um and here we have things like actions checks deployments pull requests and we can kind of give more strict and fine grained access um the documentation for these is uh could be improved and it's often quite difficult to actually know uh which permission gives you access to the

thing that you want so you might end up exposing in uh yeah certain things that you don't want to um and but for the purp purposes of kind of exploiting GitHub actions there's a main uh couple of uh permissions that we want um the first one is contents and this is the most important one and when we have kind of right access to uh contents this allows us to basically make changes to the actual repository itself um and then interestingly we have the the PO requests uh scope um and it might seem like this one if you have access you might be able to merge a PO request but uh that's not the case unfortunately and uh it only gives you

access to kind of operate on the PO request so you can add comments and things like that but you can't actually uh do any merges for that we need the the contents right um so kind of let's move on to Secrets um and these are basically essential V essentially variables that can uh yeah we include at different levels within GitHub uh such as yeah the organization repository um and these are basically there to allow us to perform tasks like interacting with a third party service so we may store API keys there tokens passwords um and we may be pushing to Docker Hub once we have a successful build uh we may be storing the results of our SAS scan or pushing

to AWS so we need to a way to store those secrets you can also use oidc um but this is a bit more complicated and kind of outside the scope of uh the talk that we're doing today um but one kind of interesting point is regarding the implicit or yeah the the the explicit the explicit nature that we need to import the secrets so even if we kind of have a secret defined in our repository it doesn't mean that we can access it um so as we're going to see kind of uh there's a yeah basically um over here uh we have kind of our secret and in the step uh we're basically using this with

uh the with um so this is making uh this secret that's in the secrets context um and assigning it to this super secret variable um we can do that in two ways using with or uh EnV um but if we didn't have that if we had kind of some script that tried to access uh this secret it wouldn't be there so it's not uh like we need to explicitly request access to it essentially uh so kind of we're we're 27 slides in and we've not covered any vulnerabilities yet we've only discussed kind of what is a branch and what is GitHub actions uh so let's kind of now look at some of the vulnerabilities uh

and misconfigurations that we might see when we're auditing um and yeah searching for that next Bounty payout so kind of first up we have the typical command command injection and these can occur in GitHub actions when we basically have some user input that is unsafely pass to some script or vulnerable actions within a workflow um and there are many events uh within GitHub that kind of allow user controllable input we have things like the the comment body the issue title uh kind of the the offer's name the offer's email address and if those are not properly sanitized uh then yeah this can lead to typical injection attacks where we might do like a a command substitution with ID or shut

down and uh it may just cause some problems for uh our jobs um so kind of what does a vulnerable action look like uh so kind of here we have basically uh something that issues a slack notification on an issue we basically open this um so when the issue is opened we're going to run this um and then we basically check out the repository uh we make our script writable and then we have kind of here where we invoke this script and we pass in uh the title of the issue uh to send their SL slack notifications so I'll receive a message in slack that says uh yeah a new issue with this title um and

this is kind of your typical command injection um we have some basically input that's being passed through a shell argument um and if we go ahead and like uh put an issue uh create an issue with uh our payload in this case it's just yeah ID uh we go ahead and run that if we look at the uh results of the uh workflow running we can see that we have command execution uh within that workflow um so kind of how do we uh mitigate this we can B basically use uh an intermediary value where instead of directly passing the the title to the the shell script we can bind this to uh an intermediate environment variable and

then this won't be expanded and we can safely pass this as an argument to run and uh you see that once this runs uh we don't have command execution anymore so that's kind of easy to fix um and then kind of we have forks and pull requests and this is where things get a bit more interesting um and kind of one particularly problematic feature in GitHub is how these are handled um and kind of the differences between like the scope in which jobs will execute so we have kind of two main uh events for handling PO requests one is pull request and then one's pull request Target um with the original pull request one uh this

executes uh within the context of the fork um and we only have access to kind of a read uh GitHub token um and it doesn't give us access to any secrets um so this is like their typically uh the original one um but it was quite limiting because it doesn't allow us to do much cuz we can't access the secrets we don't only have read access um and then yeah P request Target was introduced to kind of uh expand these capabilities and here we the when we open a p request uh the job is going to run in the context of the base repository um and not the the repository that I an attacker um

have tried to merge um and with this we can access the secrets and uh we often have the the read write permission but this is dependent on when the organization was created which leads us to a vulnerability class called poem request um and this poem request occurs when uh a workflow basically mishandles the uh pull request Target trigger um and this potentially compromises the GitHub token and it leaks Secrets uh so these specific conditions must be met for us to kind of make this exploitable we first need to control a pull request Target event so uh there'll be a repository with a pull request Target event we can open a pull request and then this is going to trigger great um

and then we need basically a couple of other things so inside the uh the workflow it needs to then check out from uh the target of the request so our repository that we control instead of the main repository um which is quite common um and then we need some basically some code execution or an injection Point uh to basically take control over

this so kind of this is what a vulnerable workflow looks like um and yeah here our job meets all of these requirements so we have over here a PO request Target event that basically anytime the pull request is changed or opened um and then we have a step here so this pulls out uh checks out the code from our pull request um and then it basically a standard job that you might see where we build and pull some dependencies so we basically invoke a make file uh so to kind of exploit this we'll just modify in our pull request uh we'll add andand ID uh to the make file and then when this is run uh we'll see

that that actually takes our codee and executes this um so it's kind of a difficult issue to fix because it's often a result as uh kind of using the wrong tool for the job um and specifically when using uh the poor request Target in GitHub actions we need to make Extra Care to make sure that uh we don't do privileged actions because it's executing in the context of the base repository with stuff that an attacker can control um so there's a couple of compensating controls that we can do here so we can configure the workflows to only run for contributors so in this case if I as an attacker open a PO request um it's not going to run

the workflow straight away because I'm not a contributor but this isn't a a difficult hurdle to overcome um because we can just go through the the repository find a typo in some readme file fix this and then at that point we're contributor um and then any further uh pull requests from us will be automatically uh running the workflows so that one's uh not too difficult to bypass we also then have kind of repository environments and uh there's a a setting called require approvers um and when we use the required approvers it will basically not run the workflow until somebody in a defined list goes ahead and clicks that they want this to run um but again this is not the

strongest control uh because often like these PO requests are used to check the quality of what's being committed um so it may be running some tests running a SAS scan um and it's there's no reason to think that code from the attacker is going to execute when those jobs run so in most cases we found actually uh people will just click yes um and it's not a huge problem um so kind of uh yeah when we intro when this uh po request Target event was introduced um they also introduced another um event type called workflow run and this basically allows us to have some degree of fixing this so we can basically separate our jobs into two workflows uh

where we have one unprivileged workflow and then one privileged workflow that will perform some sensitive action that has access to the secrets and the workflow run can basically just be configured to uh watch for successful execution of the the untrusted workflow and when that happens it will go ahead and yeah do something else um so kind of how do we kind of uh exploit this um so yeah as we mentioned it allows us to kind of run some privileged operation uh on untrusted code but this by itself I mean it represents uh a security boundary um so kind of in order for the this to be kind of abused um well that by itself can fix things but we can still abuse

this so uh basically when we have kind of those two um we we fixed kind of the poor request issue or the poem request but then we have a situation where we have this trust boundary and we have the the untrusted job that's running and then the privileged job it may do something dangerous with the results of the untrusted job so in those cases uh it may kind of yeah do like a build um and then if that runs successfully it test completes it will go ahead and then check out the code from that branch and then yeah run some further tests on it um and then push those results to a code coverage tool um and in that case we're

able to kind of take control of this still so how this would look in practice we basically have the unprivileged pool request event um and this one basically just does a checkout it sets up node it does an npm install and it runs the tests when that's successful we then have a a privileged workflow that's using workflow run when it's completed successfully it's then going to check out from the the head of the workflow uh of this repos uh this one um and then it's going to yeah do some action in this case it's just an example so we're just doing an mpm install um but in a more likely scenario we're just going to

push the results to some service um and that's going to require secrets and at that point uh we contr those Secrets um so yeah in this case we have code execution within uh the privileged job instead of the unprivileged job so kind of that's uh useful but we kind of want some kind of like hack tricks to help us uh get around some other kind of situations that we may have um so kind of when we want to take control over a job um it's not always obvious like we may not have a kind of direct uh command injection that's there um so like we can look for things that we control so maybe there's a make file

maybe there's a shell script that's being checked out and we can put our code in there and this may work that's not always the case though so there's some really good uh kind of collection of resources called uh living off the pipeline um and in here it's got a whole list of uh systems that uh when they're used we can control one file U for example with like an mpm install if we just have the mpm install that's being run we can get command execution through this by uh modifying the package.json file and putting in there uh a post a script tag uh so like a pre-install script um and then this will give us a

command execution when mpm runs and the same with things like pip make uh eslint they all provide us ways to get some code execution so um we can also use local um local actions so if we're referencing an action that's not on the marketplace but it's uh being referenced with Slash um this basically just points to act like a a default yaml file called action. yaml in the base repository um and then in there we can basically configure which job is going to uh run one of the things that's really uh more useful though um is kind of Step poisoning and this is basically where we have control over uh a partial step so kind of here we have

uh yeah down here we have this deploy to S3 step and inside here we have the environment uh variables exposed to us where the secrets um but we don't have code execution in this step whereas we only have code execution here but we don't have access to those secrets so if we tried here to actually access uh these AWS Keys it's going to fail and they're just going to be undefined um so yeah how can we gain access to those from uh the step that we have uh control over um and yeah we found that there's a well we were looking uh environment variables to see how how this could work and we found one that may be useful so

we were looking at node options um but we found that yeah a lot of these are actually restricted and when you try to set them it's not going to work um but we found that LD preload seem to have been forgotten so I mean LD preload basically allowed us to replace kind of the definition of some function or uh by when we try to invoke some function that's in a library we can provide uh a separate Library that's going to be run instead um so basically what we can do to abuse this we basically just have uh like here here is the payload um and we basically have a the step that compiles our shared object

um and down here we basically just uh yeah compile this um and the the shared object will just output the secrets that we want to the to the screen and that's yeah quite useful um it allows us to kind of bypass this so in those steps um once it's got to that final step that we had no control over it's gone ahead and printed the output of uh the WS secret so kind of let's get to some uh real findings um and some of the things that we found uh using these techniques um so oos this this is quite an interesting one just cuz it's a bit ironic that it's in a repository owned by oos for the the web security testing

guide um and yeah we found that they were vulnerable to a p request um and they basically were running a tool called text lint RC um from the PO request Branch um inside the the text L check uh step uh text lint RC also supports JavaScript format um so we were able to just replace the Json format uh that was uh in this rule definition um with some JavaScript and then use LD preload to hijack this the the previous steps um and then access the GitHub token so kind of uh oh also when we did that the the only problem here was that uh it only had the pull request right permission so we weren't actually able

to do much we could only uh write messages through the poor requests um so this was a bit lame uh but it was just yeah a bit ironic that it was in the OS repository um the second one that's more interesting uh is in a repository from Microsoft called autogen and it's basically an AI agent framework so something similar to Lang chain um and they had a couple of jobs that were vulnerable um and uh yeah the contrib open AR was vulnerable to a p request too in the retrieve chat test job um and yeah here we have some more interesting secrets so we have kind of some some Azure open AI API Keys uh so yeah when

basically looking at this one we're able to get some secrets that are owned by Microsoft um to access one of their open AI accounts um and once we go ahead and access that we can see that we have access to those API Keys um and then kind of the final one that we we're going to talk about is uh from hashicorp uh which is the company that maintains terraform and they have the terraform uh cdk action um and there they have an Integrations test yaml file um and this was also subject to a poem request um and here they had two steps uh or yeah two steps that allow control to be uh taken uh the install

dependencies and integration tests uh one used YN install um which again via a package.json we can overtake um and the other one was with a local action uh so kind of with this one uh here we have the the local action so it's using uh Slash um and uh here's the yarn install um and down here we have uh this GitHub token uh so in this case we can go ahead and steal uh this GitHub token so kind of how do we yeah exploit this what are we going to do um so we basically build a payload that would automatically uh merge our pull request so as soon as we get the code execution we basically make a request to the

GitHub API um and then we pass in that GitHub token that we were able to steal um and then yeah make the commit title poned um and then once we go ahead and uh that pull request runs uh we can see that we have the the command execution uh we are able to basically test the token we make our Co request um and as we can see from the response of this we see uh merged is true P request successfully merged and then when we go to the repository uh we see that the uh pull request was merged without any interaction so in these cases uh we could just open a p request and as soon as the job finishes our uh P

request is merged into the main branch without any uh interaction from any maintainers or contributors um and then yeah in order for us to basically scan issues uh in GitHub repo uh in our repos uh we created a CLI tool called the GitHub action scanner um and basically you can give it uh a URL um or an organization and it will go ahead parle the ammo files um and then we use basically like a regx based roll engine to find and flag findings um so there's currently seven rules uh in the um and it's got a couple of interesting features that are quite useful so one of them is for kind of making it easier

easier to test and proof of concept uh these findings so when you're kind of you found a repository that's vulnerable you don't want to be testing this against the actual live repository because uh it's going to be noisy and you have a potential to kind of break things um so you basically make a copy of the repository um make a new repository and then upload that and then you make a pull request against well you fork and pull request into uh your copy of the original repository um so the tool allows us just with a a single command to basically make a new repository that is a clone of the original one uh which is quite useful we

also have a a payload generator which will automatically generate the LD preload file um for yeah running these payloads that allow us to kind of do step poisoning attacks um and then also so repository uh Discovery so there's kind of a quite a useful feature where you can basically say scan GitHub for all repositories within between 5,000 and 20,000 stars um and it will go ahead and enumerate all of the repositories and then it will run the rules against each one of those so it's very useful for finding these kind of issues on mass uh so kind of yeah just to summarize um yeah GitHub actions are great and we can do a lot with them um

but it can also be quite dangerous when they're used in public repositories so first of all I mean like be careful when you're using GitHub actions in a public repository um and generally you'll want to use the PO request event instead of Po request Target um so be careful about which triggers that you're using um and then also be careful cautious about where user controllable input can come from or what scripts a user may have control over um and again yeah if you are using public repos with GitHub actions don't use public Runners uh because any uh command execution there will allow kind of that machine to be taken over and at that point you also

have kind of access to the network where that's deployed and if it's not properly firew off then things could go wrong there um and yeah the these issues are very common so if you go ahead and take uh the scanner and start searching like you will find a lot of issues um and yeah report them responsibly and don't cause too much uh problems um all of those three issues uh are also fixed and responsibly disclosed um and yeah thank you for taking the time to listen and I hope that yeah you learned something about GitHub actions [Applause] so we have some minutes for questions if there are

any we have one yep there is a question and there is a box and here we go uh any vulnerabilities in private repositories that you know about or have recently discovered um no so kind of with the the focus of this um it's kind of more interesting to look at the public repositories because like anybody can find them um with private repositories of course there is a concern there but the like uh window for attackers is a lot smaller uh because I mean you're you're limited to people that are already trusted to access those private repositories uh so we we didn't really look at this I mean we would have been restricted to looking at our own

company's private repositories okay

thanks any uh other

takers yes no maybe oh there we go uh just a question do you know if gitlab has similar issues I don't think they yes uh so all all of the kind of CI platforms have similar issues with the kind of just the flow of how these workflows are triggered um but we decided to focus our efforts on GitHub because the majority of public repos we found are hosted on GitHub over gitlab um so yeah well we didn't spend any time to to look at this uh very similar issues uh do affect gitlab and Jenkins and Circle C because I think the only protection mechanism which is there is that you make a secure variable that

only runs on a secure branch that runs on a secure Runner or protected which means if the branch is protected and and it only runs on a protected Branch all those things shouldn't happen right um I mean it it depends on like how their triggers work I mean if it executes in the context of of the protected Branch then maybe um um exposed only on protected branches and I believe merger quests and other things don't run in the context of a branch they in this eal middle region yeah that's possible I mean like we focused on GitHub um so there's definitely further research to be done on git lab and uh maybe there's a way to kind of get this but maybe it's

more difficult uh but I don't know

uh right so when you run the GitHub action it creates you for you a container or virtual machine or something like that right uh is there like is there any way to like return the machine to like the starting State between steps or jobs or is it always uh does it always like retain the changes made by previous steps in it yes so by running a new job uh this will run in a separate container um it will only be steps that are going to share the same container or the same environment that it's executing in um unless you're yeah using self-hosted Runners then you're you're on your own and you are responsible for cleaning up but is there

like any reason to not do new jobs every time unless you want to retain the state uh yes so I mean it would be situations where like you need to share some information between the steps um so like first installing the dependencies and then running the tests because maybe to run those tests as part of your testing framework you need you rely on like junit or something thank you s our Q&A time has come to an end at this point but there's soon going to be another break and you can ask your questions there and before we going all let speaker go here's something for for the skateboarding oh thank you thank you