The Hackers Guide To Software Supply Chain Attacks

thank you uh great to be here everyone so today I've kind of putting together the hacker guide for attacking the supply chain uh in this talk kind of what I wanted to be able to do is think about it from the attackers point of you um we're going to be doing kind of a whole lot of demos well not a whole lot but a few demos of how uh actual supply chain attacks uh unfold and uh again looking at this from perspectives of kind of the black hat so a little bit about me I'm from Al or New Zealand I now live in the Netherlands I work for a French company called get guardian and

just to keep everyone guessing as to where I'm going to be in the world uh you can find me anywhere at the handle at Advocate I'm also the host of the security repo podcast my mom's favorite podcast she highly recommends it to all of you and she definitely thinks you should check it out uh so what are we going to talk about today well we'll talk about a little bit about what is the supply chain we're going to be quite quick on this and then we're going to kind of look at attack three components of our software supply chain how we attack our dependencies how we can attack the source code how we can attack the build

process and finally uh we will talk a little bit about hardening the supply chain I'm more of an offensive kind of guy so the the defensive stuff I'll I'll just T touch on because lawyers say I need to all right so what do we hear when we have the supply chain in mind I mean the obvious supply chain that we think about is uh kind of car manufacturers or any kind of physical manufacturing right you have raw components you have assembly lines you have testing lines and then you ship a final product in software things work almost identically but with different artifacts right so we still have their raw components we still have kind of the assembly lines our idees our

Git Version Control Systems we have our testing lines which today is kind of our cicd pipelines and then we ship out a final product which is usually something like an out OFA an image you know Docker images or something along those lines so we kind of Follow the the same process what people and what has really become prominent now is that attacking components of this supply chain is becoming increasingly profitable for malicious actors so a little bit about economics so we have malicious organizations now and I I say organizations intentionally where we still have individual threat actors but mostly we're talking about in or at least in this case we have businesses they have employees they're trying to make money

and they make money by attacking organizations and obviously attacking an organization comes with risk right and you're trying to get a financial reward if the financial reward isn't big enough and the risk is too high you're not going to attack that company and so a lot of organizations have been immune from this type of attack because well the payoff wasn't high enough right now insert supply chain attack a component of the supply chain we can simultaneously attack hundreds thousands potentially tens of thousands of different organizations the payoff is bigger so we can invest more money into it now I know I'm not saying anything groundbreaking here probably thinking all right tell attack more organizations get bigger pay

UPS tell me something I don't know but we can actually formulate a lot of this in economic models so here is an economic model that was put out by a paper by uh uh cut right uh who who looked at how we can financially model the impact of a supply chain attack and what this financial model is trying to put out is what is the total disruption cost going to be of me targeting this component of a supply chain because if I can figure out what the cost of that is I can extrapolate from that what the potential reward is so I won't go too much into financial model it's way too late to be doing this kind of maths but

basically we can figure out using this equation you know the ongoing or cumulative effect of multiple companies through this so these are the levels of sophistication that these malicious organizations are actually going to right they're using sophisticated economic models to try and determine what that o total cost and impact is so that they can figure out how much money can I invest in attacking this component of the supply chain and that's why we're seeing increasingly sophisticated types of attacks on these Supply chains because it's not just a risk game of trying to throw it out there hope something Sticks no we can formulate that we can generate X from this so therefore we can actually produce it so

what do our software supply chain look like so this is a model called Salsa it's very simple and it just elegantly explains our software supply chain right we have our developer they create source code it goes into a build process dependencies are pulled into there and a package comes out so these are kind of the elements of a supply chain all of these elements are susceptible to supply chain attacks and all of these elements can be and have been attacked what I want to do in this talk because I don't have long enough to go through all of it is I want to look at how we can attack The Source process how we can attack the build

process and how we can attack our dependencies and I want to give demos and concrete examples of how this actually happens in real life and uh and and move on from there so let's start by targeting open source packages when we talk about the software supply chain the most common one or part of it that people talk about are open-source packages so and these are kind of as our dependencies so when we think about the applications that we build 85% of the source code some people say 90 some people say 95 I'm just going to say 85 it's going to vary but around about 85% isn't code that you write it's code that you pull in from your different

libraries we have a problem that we trust this more than our own code right so if you think about your own code you know the developers that you have when you pull and do a pull request or when codes merge it goes through code reviews you want to make sure you're using the correct formatting you really review it but you don't really follow the same processes with dependencies and a lot of that's just because you can't right so we have this thing called open source bias where we really kind of trust this code more than we should and the interesting thing about it is a sophisticated attacker probably knows it better than you do therefore they know

85% of your application better than you actually understand it so software dependencies open source dependencies we understand how they work we have our application and then we've selected these dependencies the problem is though we're in control of what dependencies we introduce we're often not in control of the dependencies that they use transitive or Downstream dependencies these are called and we can go on for layers and layers 30 layers deep is kind of typical that you can go on this level I'm going to stop to there for being poite we also have another typ of dependencies which is our third party Services these are increasingly being used and this is a really clear graph I see my third party Services I see my

open source dependencies everything's layered and structured and I can imagine that I could probably understand this if I map it out the problem is that it kind of looks more like this and that's because we have open source dependencies that depending on each other our third Party Services are dependent on open source dependencies and it's extremely impossible to even know what we have so that's what happens as we have something down here like log for J or XD right that we don't even know might be part of our our our open source uh supply chain if one of those gets turned malicious in the case of XZ or if one has a critical vulnerability in the case of log 4J this

obviously has a follow-on effect and can poison our application right so this is the open source dependencies in a nutshell now this is a graph that I'm this is a meme that I'm sure everyone's seen uh I think this came out in 2021 and it's been trending ever since and it kind of it illustrates it really well right you have everything being held up by a project some random person in Nebraska has been thanklessly maintaining it's scary how true this is it's so true that I can even name that thankless person living in Nebraska there's a thousand of them this particular particular one doesn't live in Nebraska but this is a guy called FAL Salman and FAL Salman is a maintainer

thankly of a project called UAP parer that he's been thanklessly maintaining for many many years and UAP parer is a legit open source dependency now if you're going to pick an open source dependency you're going to look at a couple of things you're going to look at how many versions it has how many weekly downloads it has how many dependence all of of this tells me that this is a very legit open source project well maintained well used takes all of the boxes but the problem is that it's still run by an individual this guy here forelle Salman and a while ago on a r on a Russian hacking Forum this came out to say that hey I'm selling access to an

npn account this account has no two Factor authentication There's 7 million weekly downloads at this point and uh I want bidding to start $10,000 starting bid $20,000 you can you can you can have it he was basically selling access to this account right I'm sure you've figured out whose account we're selling access to it's a guy that's been sanly maintaining a project who didn't have two Factor authentication on the project not to blame him but just to say that this is how easy attackers have targeted him through probably what was sophisticated fishing campaigns to be able to gain access to this account so that they could sell it some crypto min was put on that it took several several

uh weeks but eventually forel did manage to get back control of his account but by that point thousands of people were using I think millions of people were actually using the vulnerable version of this and there's also a little bit in how they shipped it out to kind of make that possible so this is kind of a process of a supply chain attack where they've targeted a component in the supply chain they've turned it malicious and the people that were affected by that were kind of powerless in in here there's other examples where in the account of event stream there was an application called event stream that this was kind of no longer being actively maintained someone from the

community came over and said I'll take over this project that person did lots of good work they then added something called flatmap stream which was a downstream dependency the problem was this nice kind member of the community was actually had malicious intention flatmap stream the only purpose of that was to turn event stream malicious but because it was transitive because it was Downstream no one really noticed it and then event stream was turned malicious so another example of how that can happen so what's kind of the Playbook here well there's a pretty solid Playbook that attackers used to attack open source dependencies right step one probably want to create a GitHub account right and we can see in 2021 a guy

called Jan created a GitHub account right now then you got to build up Trust of the organization right you have to start making non-malicious contributions because no one's going to trust you so in April 2022 that guy started making lots of submissions to a very popular package well not I wouldn't say popular but very important package something that was part of uh the core Linux project now then the next step is to fabricate internal pressure almost like a social campaigning scheme and here's what happened is that multip multiple accounts started putting pressure on the core maintainer to start introducing his submission now they weren't malicious at this point but they were sending emails they getting very they were getting very

heavy and if you're someone that works on open source you feel this from the community you're doing this thanklessly most of the time and people are getting mad at you because you're not committing enough time to this open source project so what that social that social pressure campaign did was basically said to the Manan goes stuff this you want the project have the project so then this guy becomes the core maintainer of the project right and we can know that because the core maintainer email was upd updated to be his email then he made a malicious contribution and that was when he infected the supply chain now this is the XZ example that recently happened and man we dodged that by a

here because the malicious contribution largely went undetected and was about to be part of the core Linux Distribution Systems in there so the impact of that the blast radius was absolutely massive the potential and we were very lucky that a member of the community managed to find that I have some interesting opinions about that but I won't talk about them right now you can have a beer and we'll discuss all right there's other types of campaigns as well stuff like typo squatting you've probably heard about it I'm not going to talk tooo much about typo squatting I want to talk about typo squatting version two the newer version of typo squatting which uh is quite interesting so what is

typos squatting just to start so another way to attack the supply chain kind of is to you attack popular packages and what you do is you take a popular package like this ccxt which was a crypto uh library then you create a similar package with almost identical name in this case cctx you can see and the idea is that a developer is going to misspell one of them and introduce the wrong library now if you're clever you will make your malicious Library do the same job so that everything still works you just have a sprinkling of malware in there this isn't new and it's like a spr and prey process it's it's it's hard to

kind of do large at scale so it's not all that interesting but there's a new version of this which is really interesting but I have to talk about something first which is called AI hallucination so what is AI hallucination well there's a very famous quote about it that you've probably all heard which is a artificial intelligence Hallucination is akin to the shadow that looms large but lacks substance it mimics the semblance of reality yet veils the essence of Truth which of course you all know is a quote from Abraham Lincoln unless well that's what chat GPT will tell you if you ask it now the reason why chat gbt has given me this completely false answer is because

chat gbt doesn't know how to say no it's just going to spit out an answer that it thinks is correct right and it does this all the time in lots of different ways it hallucinates answers and there's lots of examples of how this has happened but I want to talk about package hallucination so when we install an open source package how do we find that package well in the modern ways we might have used something like stack Overflow we would have done research but now we have all these great tools like chat GPT and co-pilot and what I can do is I can just ask chat GPT down here it's hard to see but I have a node

project and I want it to connect to an Orient database give me packages I want you to list all the advantages that they have and I want you to provide the installation code for them so here cat GTP has obliged me it's given me all these great packages is that I can install to connect my node project to my Orient DB project so what I'm going to do is I'm going to take this helpful installation code I'm going to run it but the package doesn't exist and in this case it's given me three packages it's giv me four packages sorry three of which don't exist okay so why is this interesting and how is this really a

problem well we can yeah another example here I used uh it came up with a project called Nano arango and again didn't exist so what's the problem here Nano Rango doesn't exist the worst case scenario I get an error I figure it out I I join something else but what if Nano arango did exist what if nango existed but not because it originally was Zer but because I figured out that chat gbt is hallucinating this and you can get it to repeat answers so if I can figure out what packages it's hallucinating I can create them and I can get chat TBT to advertise my malicious packages for me and that's the the the guide the attack is

guide of how to kind of infect the supply chain through AI uh as well we can make that and how we can do that is to go on places like stack Overflow get the how-to list this is something that I experimented with run them through something like chat GPT find out all the ones that are hallucinated regularly create them and what we find is about 30% of the packages right now are hallucinated Gemini is the worst at 60% and uh chat GPT is getting worse with hallucinations as the overall model gets better uh which is kind of interesting now this probably isn't going to be an exploit it's going to be around forever but how

do we know how many packages haven't already been maliciously created because I mean I'm talking about it so that probably means some other people are think about it too all right let's move along from open from the open source dependencies let's move to a different part of the supply chain I want to talk about targeting the source code uh which is here so source code is absolutely everywhere and source code systems can easily be abused I've picked the word abused here instead of attacked because um there there are this is kind of I would call this a supply chain abuse rather than a supply chain attack which might become apparent but I think it still fits under the whole area

so source source code doesn't need to be sensitive but it often contains the secrets of your organization and I've kind of used secrets in there as a bit of a pun because when I referring to Secrets often I'm talking about things like API Keys credentials these are riddled in your source code and attackers are constantly trying to Target the source code of organizations to try and gain access to these secrets particularly in the history of Version Control Systems and there it's a absolute TR TR Treasure Trove uh in there so let's talk an example of kind of a breach has happened because of exposed source code and then I'll talk about how that relates into the overall

picture of a supply chain abuse so Toyota company you're probably aware of they were developing a mobile application to compete with their Rising competitors of things like Tesla that were bringing out Tech they worked with a contractor to create this mobile application called t connect Right Toyota connect makes sense what happened was an employee of the contractor accidentally pushed their source code to a public repository in GitHub this happens all the time right inside that source code was the credentials to the database of all the users of tconnect their personal information and what they've been doing those database Keys remained there for 5 years before a researcher found out and notified Toyota by which time they realized that the the

information was already being sold so attackers had found uh this data right so now this isn't a supply chain attack you may be thinking about it but how did the original attackers find these credentials I don't know for sure I don't know them but I'm going to suspect that they were abusing a very common source code management system so this is GitHub the largest repository or deposit of Open Source Code in the world right over a billion commits over a billion contributions of code are made every year to GitHub it's an absolute fire hose of information and what's important to know here is that even if you aren't using GitHub in your organization your developers probably are that means that

GitHub is a part of your supply chain whether you admit it acknowledge it know about it or not it's because GitHub is kind of like LinkedIn for your portfolio you need it it's your social it's kind of social media for developers how they interact with the community it's really important so your code like in the Toyota example can end up in there so how do we abuse GitHub to try and find source code that may have accidentally leaked or source code that contains secrets in the public area we could just search on GitHub but that's lame and boring and will take way too much time there's a much better way to abuse GitHub although if anyone asked you

didn't hear it from me but first let's have a look at the kind of total amount of secrets that we can find so one of the things I work for a company called GG Guardian one of the things that we do is we scan everything public in GitHub so all of those billion commits we've scanned all of them last year and we tried to find out how many of them contain secrets so overall just last year we found 12 million Secrets nearly 13 million secrets in there now you might be wondering how do we know the real secrets about 70% of them we can validate so we can actually go run that want to test against it and see hey

is this a valid key to AWS is this a valid key to twio and then we know it so there's a huge amount of Secrets out there in in the ethos this number is continuously growing we're hopeful that we're going to see a decrease this year because of some uh some things that GitHub and other companies are doing but it's still increasing and it's still a massive it's still a massive Pro problem and the other thing that's really scary is that people don't seem to understand the importance of this so when we find a secret we notify the developer that leaked it and said hey based on your GitHub activity we think you've leaked a secret and then we

monitor to see what happens 92% of the time after they've received the notification the the key is still active we test the validity we test it when we find it and then we test it again in a couple of hours in a couple of days in a week in a month so on and so forth 92% of them never get revoked we'll see weird things like they'll delete the commit they're like oh we'll I'll delete this and that's going to solve the problem but it doesn't because it's out there right so that's kind of scary so how do we actually do this so you can understand that GitHub when I make a code public it's public anyone

can see it right but how does other people see it right no one's going to be looking at my GitHub I'm just I'm like I can like who's who's really going to be interested in what I'm doing well no one but we don't need to be thanks to the GitHub public API right anyone here can do this even on your phone you can go to api. github.com events you don't need an account it's just completely public and on this you will find a complete Ledger of everything that's happening in GitHub like we can see it here and there's some interesting information here including users email addresses their names and their messages and access to that why is that

interesting if I'm looking at targeting specific companies I can try and find people making commits with those domains look for them get the GitHub IDs and start uh trying to find uh information on them to see if they're secret so now I can get more targeted now I can go from a billion commits to maybe a million interesting commits that I want to look at as an attacker there's a bunch of events that are published in here the ones that you want to look at if you're an attacker but didn't hear it from me uh the public event this is when a private repository goes public this is by far the most interesting because with

it goes all the history so you got lots of goodies in there the other one is the push event right you just push code publicly so when you're monitoring these these events you can actually start looking and abusing the supply chain uh component of GitHub and organizations will be none the wiser because they don't probably even know it's part of their supply chain and what else can we abuse to find source code it's not just GitHub there's other places like package managers we started scanning piie python index package manager and last year we found 11 uh th000 unique Secrets just in pie packages so these are other places which I mean a pie package is basically just a

compiled version of source code right it's source code source code contains Secrets it doesn't have the history that like git has well not in the same way but it's still really interesting so we can look at this find more secrets so lots of ways anywhere that there source code I can start looking at that and also includes Docker images about 8% of Docker images contain secrets so really interesting and here we can just see some of the types of keys that we find in piie packages the types of keys are very different what you find on GitHub and what you find on piie and what you find in Docker all different but they're all really interesting and it depends on

what you want to attack if if you're so inclined now the other thing is we can also abuse git in different ways so public code is really interesting but what about private code so the git system or version control system is part of your supply chain most likely unless you're ancient and using something like Source Forge or some other things but you're probably using git and you can actually abuse the way that git Works to try and find private source code which is really interesting so when you create a git repository you go get in it and it creates a folder a directory called a dogit directory right us hidden but it's just the.git inside that you have all

your metadata that's where your history stored that's what I want as an attacker that's what I find interesting the problem is that this dogit directory gets exposed all the time without people knowing about it cyber news did some widescale scanning and they found two million of these dogit directories that were Exposed on public IPS right so just by scanning it and there's some really interesting ways in which you can find these and if we take a look at a leak that happened because of a misconfiguration we can look at the twitch example 6,000 private repositories were leaked and we found 6,600 Secrets within that this is actually exceptionally good we would expect to find way more in an

organization this sound so congratulations twitch for only leaking 6,000 Secrets but we still found 194 AWS keys and even four stripe keys and uh we have another one this is I've kind of I've I've merged this in here because it's such a good story this is an accidental supply chain attack that my friend uh committed uh his name is Philipe and he's a penetration tester and uh he was on assignment for organization and he was trying to to get into the private source code of this company and so how he was going to do that is through a fishing campaign using GitHub he purchased the domain giel hub.com and created a mirror of GitHub right you can see where this is going he

wanted to send a fishing email with G lhub the user wouldn't notice click on it log in he would get the credentials access get right that was the plan right send the email but the user didn't didn't click on it so here sounds like a [ __ ] story but it gets better trust me so the user didn't click on this but phip said oh well I'm going to use get hhub in the future I'll just try and get access in different ways let me just move on but he left get lhub running obviously and then something weird happened someone posted this tweet and it was just kind of promoting their latest open source project on Twitter right a normal

thing to do no one really liked it didn't get any viral but he made a spelling mistake and he put get lhub in the Tweet because it was a mirror it all worked perfectly and no one was none the wiser because of this tweet or at least this is what we can probably most assume the search engines started indexing get lhub and started publishing it even ahead of Open Source Repository at some point Philipe then realized he had like 20,000 GitHub credential logins so he had done a supply chain attack on GitHub without realizing it now penetration testers often will have moments in their life where they really wondering which direction they should take and this was definitely a moment

and so he says he took the good path but you know he did buy a Ferrari after that so [Music] no so how can we start doing something what's the concrete example of doing a kind of abusing git and so here I'm going to use the example of abusing the dogit folder to try and get access to private source code so what I'm doing is I'm attacking aia.com and I'm using a tool to get all of the subdomains associated with algolia decom why do I want to do this I want to try and put together a really wide Nest I'm not going to find exposed private source code on algolia with I might I'm now going to use a tool

called get scanner to basically look in all of these subdomains and see if I can find any exposed G dogit directories so anything in Orange is found a dogit directory but I don't have permission anything that comes up green it has a dog directory and it's going to download it for me and then I'll be able to recompile that and I'll have access to the source code so this is just a really simple way that you can actually start abusing how git work to gain access to it all right how we doing for time doing good so next I want to talk about another component of the supply chain so we talked about open source dependencies we've talked

about abusing source code and control systems now I want to talk about attacking the build process the cicd pipelines in that in this in the in the in the supply chain right which sits here now these are really important now if you don't know about cicd pipelines and build processes this is basically your code gets comp filed your application gets tested and then it gets shipped out and this is an automated process this has revolutionized everything because now we can take small contributions run them against test and then ship our application out which was an incredibly manual process before now we can we can we can deploy updates multiple times a day if we want to but

these build systems have made us very vulnerable so I want to start off by talking about an attack on one of these build systems the cicd pipeline I'm going to talking about the code COV attack so uh code COV is a tool that sits inside your cicd pipeline it doesn't do anything critical what it does is it checks your code coverage it's essentially testing how much of your application is being tested in the pipeline right so how how how what's the coverage of my tests and how you would run this is usually is You' take the docker image which was public and you'd plug it into your citd pipeline the problem was there was a secret inside

this Docker image someone discovered the secret and it gave access to some source code it gave read WR access to a Microsoft Drive which had inside it A bash uploader script the architecture here was a little bit weird because code COV would call this script whilst it was running and execute commands from this commit so it from this back from this bash uploader script so it was kind of really weird but basically the attackers had access to the script which means they could turn the script malicious which means they could turn code COV malicious and that's what they did there was 20,000 key targets that the attackers were after when they infected code kov and they were able to move into the

private source code or move into the infrastructure of those 20,000 customers they didn't actually go in there on 20 on all of them but they had access to and there was some really good companies in here uh rapid 7 twio uh Monday comic Corp so how did they do this what what did they actually do what they said is in this bash up loader script they added one line of code which said whenever code covers run dump the environment variables and send them remotely to me the attacker so what that means is when your application is being tested when it's built it needs to connect to all your systems your database your source code your third party Services how does

it do that it has Secrets it has passwords it has credentials in its environment variables now even if they're test environments some of them like source code credentials are still highly highly sensitive so the attacker was saying every time you run code COV dump all of those passwords all of those Secrets send them to me and I'll be taking them thank you very much so that's how they were able to move into it and it was quite a big deal this was the line of code that they have on line 525 this bash script they're not my thing so I can understand how someone missed this they're kind of something you just want to do and then never look

at it again uh I almost never pick on companies for breaches because I truly believe it can happen to anyone but I am going to pick on one company which is Hy Corp I really like Hy cor as a company if you work for hasik CP don't sue me um but hasik Corp create a product called Vault it is a Secrets manager it is a fantastic Secrets manager their whole pitch of Vault is that you no longer have to hard code secrets you will no longer have secrets in your source code because our product is so good and to a large extent it is true everyone should be using some kind of Vault however because of this breach attack is made it

into Hashi cop's private source code and they and Hai Corp had to announce that they had exposed private keys in their private source code the point of this is has if Hashi Corp has secrets in their source code there is no hope for Absol absolutely anyone else another compromise which is similar on this was with circle CI instead of targeting a component of the cicd pipeline in this take they they targeted the actual cicd pipeline itself so they infected uh they put malware on a developer machine the attackers did they then stole a a session cookie these are are more sensitive than passwords because they bypass MFA they then got access to the client's encrypted secrets that Circle CI had

installed keyword there is encrypted but they were still able to access the infrastructure and also private source code of lots of other companies how did they do that with encrypted secrets well people just were just using really shitty Master passwords basically they brute forced their way through this database and with Brute Force attacks you're either going to find a match in under a minute or you're never going to find one ever right so that's basically what they did and they were able to again access into the networks into the source code of all of these different companies using Circle C basically because attackers managed to Target the system now this looks kind of simple this is incredibly sophisticated to try

and get malware onto the right developer machine this developer had privileged access he was targeted it was probably a very long campaign to be able to do that and one that paid off because they were so this is how you can Target it all right what's an attch example now coming up with a working demo of attacking a cicd pipeline is a challenge but one that I tried to do so here is an example of how you can attack a cicd pipeline um in particular here we're using open source projects to attack it the goal here is this open source package I want to turn malicious I want to inject malware onto it so I want to

find a a good open source package and I want to inject on to it I'm going to do that through a CDD pipeline GitHub actions right so how this works is a contributor to the open source will make a pull request it will go through GitHub actions GitHub actions will run some checks on it so that the maintainer can look at it and see if that should be something they should merge into the main thing right go for manual review they pull it in the attack example of this is that they make a pool request and it goes through manual review but in instead of that the pool request has code in it that makes it do something malicious

that then injects malware onto the open source package without the manual review so we can Target the GitHub actions and this uh can H happen how do we do this well it depends on how the GitHub actions is set up but a lot of these are set up incorrectly with vulnerable processes in this case the workflow is calling the pull request title now why you would do this is you'd want all your information there so you're saying hey print the pull request title print all the checks print the runs the B I want to see everything so that I can I can I can see it it makes sense and there's plenty of examples of

this actually happening but what I'm going to do is in my pool regress title I'm going to run a command to inject malware so I have an example of this working so here I have the open source project and in here you will see this is my GitHub actions yaml file it's a little bit blurry hopefully that might clear up but I'll explain what's happening here it's printing the pull request title in the ml file right of of of what's happening so basically I'm printing that out what I'm going to do now is I'm going to switch to the attackers perspective and I'm just going to inject code uh into my pull request head so I'm going to make a pull request

now make pull request and then in the as a title I'm running a cur command to get mware which is going to uh an address in this case I just have uh a demo where I'm just going to say pwned all right I'm just trying to Echo the word Pawn but you could put anything in here you could put any kind of maware that you want and what's really important here is when I run this pull request it's going to execute this without anyone doing anything no one has to accept this just the process of me making the pull request will run this malitia script um because of the way that this has been set up so here we're

now the pull request has been made the maintainer has done nothing but what you'll see in a minute is that the GitHub action will run it will get to the malicious part the title and it's going to execute that and it's going to inject malware or in this case it's going to inject the word pwned into that that thing so we can see that it's run that there and down the bottom which you can barely see you have the word pwned you'll just oh good I assumed there you can see it so that's a way where you can abuse the the build pipeline now will this actually work yeah there's plenty of Open Source projects that have GitHub

actions that you can run this how do you find them well you can look inside them but you can just make a whole bunch of malicious pool requests from various titles and see what sticks and uh or if you're targeting specific uh open source packages you may want to do that or you could even take over one and inject and make this malicious edit to the AML file under the guise of doing something [Music] else five minutes all right so um this is what we've looked looked at how we can attack the dependencies the source code and the build I won't go into the other stuff cuz I don't have time but you get the idea right we can we can

attack various components of the of the supply chain so supply chain attacks are interesting because they feel like you're in a car crash but you have no control over it and to some degree this is true right I can't really control unless I just get absolutely terrified of everything I never use open source I do everything myself then okay that's really the only way otherwise there's a risk that you're going to feel victim to a supply chain attack and there's not much that you can do about the attack itself however you can do a lot about what the attacker can do the only thing you're working for you in a supply chain attack is that the attackers have lots

of victims to Target so like my goal in life is I always want to have a [ __ ] bicycle than my neighbors because that both our bicycles are outside I want them to steal my neighbor's bike if they're going to go to the effort so I have the same lock and that's how and software with supply chain C can be similar but what you should also do is make sure instead of putting all your energy into preventing someone from breaching your walls figure out how can I prevent them from moving inside my walls a lot of the supply chain attacks here they ended up moving inside private repositories or private networks making sure that there's no way for them to be

able to break out with that things like secrets and credentials is a great way to be able to prevent them from moving on so how do we do better there's a couple of things that we can do now SCA software software composition analysis is a series of tools that look inside your open source dependencies and finds any that have vulnerabilities it helps with other things like s bombs and compliance this is something that you need to do you need to have sca in there there's plenty of Open Source tools available for that there's commercial tools sneak is a common one get Guardian is another one I work for GG Guardian anything I say about them is incredibly

biased but they definitely the best um but also there's open source versions right there's no reason you don't need to spend if you don't have the budget for it don't spend the budget for it you know start off with open source tools they're going to there's plenty of available ones and also ones to create es bombs secrets are a big component now Secrets Don't often play a part in the supply chain attack itself but it's often how it turns into something critical right someone accessing your GitHub repository shouldn't mean that absolutely everything falls apart but it often does that's because of Secrets so we need to manage Secrets use things like Vault anyone here from Hashi corpy

promoting Vault don't sue me um but there's other ones is there as well Cloud managers uh have have secrets if you don't want to use a vault and if you really don't want to have to use any of that you can encrypt them at the very least I would not recommend this for various reasons but if the this is going to prevent you from hardcoding them then at least we're getting better right and then secret scanning again work for GG Guardian definitely the best but there's lots of Open Source scanning tools as as well so there's no need again if you don't have the budget to not use the open source tools that are available to be able to do Secret

detection which is identifying where Secrets have leaked in your networks in your repositories so that at least you know you have a problem now another area and really key part is uh using honeypots because with supply chain attacks nearly all the examples that I showed particularly with Circle C and that it takes weeks before uh anyone actually found out there was a breach and understanding and knowing that you have a breach is a huge part in being able to survive a supply chain attack so honey pots are a great way to do this my favorite type of Honey poot are honey tokens which are fake credentials these credentials you put inside your git repository on purpose and if anyone uses

them they should have access to nothing obviously but if anyone uses them you get an alert so honey tokens are really cool um there is open- Source versions of creating honey tokens as well and there's also lots of other honey pots one of my favorite honey pots is honey py which is a python application uh honey tokens are good because they're really light other honey pots can be difficult and hard to manage but you should have them and for me this is a really important way of actually understanding hey when do when an attack of breaches into your systems How can I I how can I know about it other areas zero trust our back everywhere right uh

rule based authentication um make sure you use trusted dependencies sign your requests and then always revert to least privileged access to Secrets make sure you're never issuing admin Secrets when you don't need to make sure you're your you boost your your third party Security Management relates again to the es bombs Implement salsa it's the framework I used throughout but I would recommend having a look at Salsa if you're interested in that and then finally my final point is assume it's going to happen when you should do activities like threat modeling don't just look at how can I prevent someone from accessing my systems go all right what happens if someone has and the best way to

replicate a supply chain attack is just to think about it as a malicious employee because a supply chain attack will be similar right they will have similar access to an employee so how can you prevent an employee from doing malicious things that's how you can prevent a supply chain from doing malicious things uh and that's the end and I made it on time so thank you all for [Applause] listening oh and we have time for questions if you have questions

y yeah yeah there was uh there was a research paper uh that started looking at hallucinations in other areas and then we started looking at uh yeah the package packages for it uh the hallucinations happen uh yeah pretty much uh pretty much everywhere with llms a funny story about my first experience of hallucinations is that on my podcast plug security reer podcast it uh I was getting really clear I was I'm going to save time I'm going to use llm to help me promote my episode so I in a transcript and I said hey create the best quotes from this transcript and give them back to me and it was coming up with all these great quotes I was

like don't remember him saying that that's awesome and they were really on point and it wasn't until after I had published one that I realized it wasn't true at all it had made it up but it did sometimes do correct ones and sometimes not so I'm I'm a little bit Vindicated there but that was my first experience of hallucination but there is some other good re really good research from people that have done hallucination I just can't remember the that but there was a a paper written uh that you'll be able to find in there I forget uh I forget the company but uh yeah there's which which has gone into much deeper than what I

have yeah seems while

absolutely uh I think it is the wrong to always assume nation state that doesn't mean that nation state aren't actively doing that to me like the XZ example that really smells of nation state because of just how complicated it was but we don't know for sure you know like I think people in the community have lightly attributed it to midnight blizzard but we like I don't think there's anything concrete there but I I don't think that there the right assumption and especially when it comes to supply chain abuses which is slightly different to like the long like attack it's kind of like how do we we're we're not hacking into the sply chain we're abusing the way that it

should be used and that I think is definitely being more and more used by organizations and even nation states like they're not just working for the government they're also wanting Lamborghinis and other things they all you know they're they're also doing things for profit they're just kind of tolerated by governments because of the followon impact of that