BG - The Dark Playground of CI/CD: Attack Delivery by GitHub Actions

uh this is the talk on the dark playground of cicd attack delivery by GitHub actions uh given by speakers yuku kubu and yuku yamama um we would like to thank our sponsors especially our Diamond sponsor Adobe and our go sponsor black cat Toyota and conductor one it is with their support along with other sponsors donors and volunteers that make this event possible these talks are being streamed live and as a courtesy to to our speakers and audience we would ask you to check to make sure your cell phones are set to silent if you have any questions use the audience uh microphone so that YouTube could hear as well um please welcome our [Applause] speakers uh hello everyone today we talk about attack techniques and related to gab actions I hope it will be useful and excited for besides Haka Community let me tell you about us I'm Yus and he is Koso we are from Japan and work for NT communication and Japanese telecommunications company we work as offensive security researcher uh sometimes works as uh internal R this is our presentation agenda uh our talk goes like this first we talk about basics of GitHub actions GitHub action is a share she platform provided by GitHub that allows us to automate build test and development pipeline this is a component of Gab actions uh in our presentation Runner and action are important so I I will explain a little my deta there are two types of Runner and GitHub host Runner and self hosted runner in short the difference is a resource owner kab hosted Runner with resource provided by GitHub uh s host Runner run with resource provided by user Runner supports some of operating system uh Mac OS reux windows but our research focused on Windows next let's look at custom actions actions are immediate tasks in the workflow we can use a combination of action to suit our purpose and we can also create and publish on actions custom action has a concept of type and location uh three types are available but we have Target JavaScript action and composite action that supports Windows so much for the basics and deep Di into the main contents at the beginning of the research we analyze the behavior of JavaScript action the figure is visualized and process Behavior as you can see uh rner worker. X executes no. X and gives index.js as argument this index of tojs is defines as entry point in the metadata file and the script engine no X is included in the run application package observing this behavior and spef specification we came up with new attack techniques uh what do you think of when you hear JavaScript in general it is a script language the core technology of the worldwide web on the other hand some may think of jscripts there is a basic compatibility but jscript and JavaScript are different our research focused on both jscript and JavaScript I mean we considered the two techniques for each first we introduce the jscript version we call this technique malicious jscript custom action this is a technique for executing jscript from JavaScript custom action via binary hijacking and bascar raing prepare work and custom action for the attack as shown the worklow has two steps First Step replace the binary and second step and execute a custom action this custom action is implemented in jscript not JavaScript the behavior of the end points when the workflow is executes is shown in the figure copy w script. x to no XZ and index.js is executed from node. X at this step node. X has been replaced by w script. x we hereby at composite action this one allows us to bundle multiple steps into the into one action the figure on this SL shows how it changes with and without composite action with composite action the workflow is one step I'll explain the reason for this later finally the JavaScript custom action combined with the composite action looks like this we call this technique as malicious jscript composite action and here is the actual P code we developed the work C calls composite action and composite action copies w script. x in step one and call the custom action in step two index.js is written in jscript in which the attack is implemented an attacker can arbitrary attack by changing the jscript implementation uh I have a quick demo of infecting C sheet from this technique let me show you the left size attacker View and right size is victim view a runner application is already running and get push to GitHub to trigger the events and then you can see that vrow yeah vrow is starts and some child's process starts from Runner worker. ex and finally sheet connection is established and at the end of the work CL the process is terminated w. XA this process is a sheet process uh it is started by AR injection and PPI dis proofing from run application so far I have talked about jscript version and next I will describe JavaScript version we have discovered and attack techniques that exploits no jsx extension noo JS has extension called ship Adon this one can be used for attack we call this technique mous JavaScript custom action there is a package called memory JS which implemented functions like open process and inject the we use we use this library in our Pok and here is the actual PO Code we developed the work worklow calls custom action this custom action includes simple DRL and node modules for the attack um index.js is implemented in J JavaScript and is designed to perform uh DL injection uh using memory JS Library open process and inject DL function uh already implemented in memory JS so our Javas JavaScript code is very simple we used memory J in our research but we can Implement on shipa Adon for arbitary attacks unfortunately there will be no demonstration today as my final part I talk about some consideration first let's discuss the attack scenario Malicia action disguised as a legitimate action could be published in the marketplace by attacker then users May mistakenly use the MAA section A thinking it is a legitimate action all users of Gab actions are potential victims so this is a big ber threat and composite action makes this threat as realistic without composite action uh Step One is required but who set up this even if users accidentally use a fake action but they will not accidentally set step one so as attacker side it is very important to add composite action it can also expand the attack possibilities in advanced technique run application TOS L child process and kills all child process when the work C is finished this mean that the process launches for the attack will also be killed it is tracked by process environment variable called Runner tracking ID we can dis tracking by rewriting this variable like this this makes the process persistent next let's consider how to protect it kab recogniz these attacks as threat and publish best practice basically it says that it is important to audit the code and the creators of course it can be detected by Security Solutions like EDR or antivirus Malicia jscript composite action is detected by EDR for defensive evation via masquerading this is unchangeable part these techniques so it is a good detection point also JS file is sometimes detected by antivirus however this is not effective because it can be easily purposed like this right uh with a few changes uh it easy to bypass of detection so antivirus is a not not effective measure detecting JavaScript custom action is a bit more difficult because this technique does not require to replace a script engine so there is oness detection point we think it is important to detect attack Behavior being carried out not this technique itself and this technique may also be effective against amsi from a quick analysis it appears that the No Ex does not support amsi so in my part let me introduce GitHub action C2 GitHub action C2 is implemented by utilizing the G actions Runner application as a agent this is an abstract image of GitHub action C2 the run application runs on target machines connecting to GitHub especially attackers only repository this connection become C2 to operate this attack attacker push a marous configuration file outside GitHub this C2 has two features or threat the first is The Source process is a regate application so runner. worker. EX ex and second point is that the destination is a regate domain and IP I will explain more precise so how to establish C2 so as off stated Runner application when launched performs a long pouring long pouring against GitHub to AWA jobs so to manage Runner as a C2 agent assign a unique LEL is needed this allows a attack to send command individually when establishing a C2 connection with multiple Target with level attacker end up sending same command to all connecting Runners how to send commands so any share commands can be executed view GitHub actions workflow workflow are described in a configuration file on attack repository so we can trigger the workflow by GitHub events like push and in this case we can uh we can use webook event called repository dispatch we can call this event using call while passing instruction from outside of GitHub plus using just introduce marous custom actions more advanced attack can also be performed I will show you short demo to make it easier to image victim Runs run applications and then after that the attacker send commands uh car. X and [Music] fori now you can see the car X is launched and we can see the Who Am my result so attackers uh attack scenario is almost the same as a C2 and firstly attacker create a public repository for attacks and then since Runners application to Target using techniques as such as fing after that Target user unknowingly runs it as shown in the demo about detections so since Source process and the destination domain is legitimate C2 establishment is hard to detect so it's very ordinary way but don't miss a lot for activities related to GitHub action C2 just the uh just they seeme legitimate last part is other threat ready to do GitHub actions I will briefly introduce three threat first threat is free jacking free jacking is a process of using free Cloud resources to perform Crypt mining operations attacka execute mining script using GitHub resources and they get Rewards to utilize GitHub resources the attacker send Pro request triggering mining using others repository to prevent this GitHub change specification and approval has been required to run workflow from public Forks since April 2021 so attacka have sifted their focus toward automatically creating GitHub account executing GitHub action and exploiting the resources secondly Marisha public for comp request the idea is that if a selfhosted runner is being used with a public repos G actions may become a potential entry point for uh external attacker to gain in putf GitHub recommend using S host run only for private Repository however it was nothing thing that there are numerous organizations still utilize hostage Runner lastly steering secret GitHub provides a feature to create encrypted environment variables called secret as organization or repository level secret can be accessed by GitHub options when they are set up for repuls this POS a potential risk of secret being stolen if accessed by external attacker through GitHub actions so I ended up here conclusion there are three point by util the feature offered by cicd such as a command and uh script execution it's possible to launch attack within the legitimate cicd process Malia's code May Infiltrate The CD pipeline without notice through publicly available marous pluging there's a risk of enabling C2 through the resum feature offered by cicd which are user owned host for executing task this is our Feature work so thank you for GitHub security team for cooporation also thank you bide Las Vegas for accep our [Applause] talk um if anybody has any questions you guys have five more minutes to ask hi uh so I work for a corporation that has a number of publicly available software development kits hosted on on public GitHub uh we use cicd uh to run unit tests and show test coverage that uh hopefully our customers can trust the efficacy of the sdks deployed uh and we've observed a couple of malicious public uh PRS uh you're saying that we're working on locking down those repos to the doesn't happen again you're saying the current industry wisdom is to Simply disable cicd for public repos is that the case or is there another is there a way I can have my unit tests and not malware so Christian uh how do I configure cicd with GitHub actions for a public repo and not be subject to malicious public PRS are there ex other access controls that we can Implement all sorry it's mean how to uh set set the mishas p uh CD pipeline yeah so the the GitHub uh suggestion is to only use cicd on private repos but our customers will only use our sdks if they have unit tests run and we can show a certain amount of test coverage uh still cover so we need to use cicd on public repos in order to get that assurance and get that testing there's there's just no way of hardening a private Runner against against malicious public PRS is that right but the uh cicd is trigger prior to review and merge well so the secret stealing that they were showing works on self hosted or uh public hosted Runners either way okay thank you um thank you for the insightful talk