Repo Jacking: How GitHub Exposes Over 70,000 Projects to Remote Code Injection

this next talk is from our breaking ground track we have indiana moreau discussing repo jacking how github exposes over 70 000 projects to remote code injection welcome to my talk on repo jacking and how github usernames expose 70 000 open source projects to remote cone injection my name is indiana and today we're going to be talking about repo jacking a novel supply chain vulnerability which is very widespread and results in remote code injection we're starting we're going to start by talking about supply chain attacks in general and looking at some common instances and i'm going to talk about repo jacking how it's exploited how we came about it and just how widespread it is we're going to look at all open source

projects and how we manage to scan them for this vulnerability and then we're going to look at the final impact and which count projects are impacted and finally we'll look at remediations and how to protect yourself from this vulnerability so let's start by talking about supply chain attacks there are two main types of supply chain attacks you've got hardware supply chain attacks and software supply chain attacks i'm going to be mainly talking about software supply chain attacks and in this space you have something called vendor supply chain attacks and for example solarwinds made the news and this is where an attacker targets a vendor to target downstream companies essentially but i don't want to talk

about vendor supply chain tax as much as i want to talk about open source supply chain tax so attacks that are targeting open source software obviously open source software is super relevant nowadays virtually every application is using at least something of open source and because of that attackers are targeting more and more it's a very lucrative target for attackers because open source software is usually not as well funded or defended as something like a vendor i think and that leads on to one key difference between vendor and open source attacks when you're going for a vendor supply chain attack you want to go after the biggest and baddest vendor because they're the one that everyone's

going to be using but for open source projects that's not necessarily necessarily the case here's an example of a page called unseen infrastructures maintained by libraries.io and what this page is is basically looks at repositories and projects which are open source and are highly dependent on so lots of different projects use them but aren't very popular so if we look at example number two here uh concat map what this is is it is a project that has 800 000 dependent repositories so lots of different projects that depend on it but it only has 30 stars and one contributor on github so it's not very popular this is a prime target for an attacker because it doesn't it's not very known

it might not be very well defended but it's very dependent upon if you look these are all different projects that use this concat map and some of these are are definitely large projects i'm sure you all recognize so that's why open source supply chain tax can be more dangerous because even the small targets can be very impactful now for these small targets like concat map maybe it's a very small library and you can't find the vulnerability in it or attack you can't find vulnerability and so instead of having to directly exploit that library sometimes they can just ask the owner if they can have it this actually happened back in 2018 with the event stream library

this was a package very much like concat map that was loaded by thousands of different projects now a malicious attacker contacted the owner and said hi i would like to push new updates and i want to update this library because i use it trying to present themselves as someone who wants to help the development the owner had moved on to different projects and said sure and passed on the event stream library and almost immediately that malicious attacker loaded in malicious code and that malicious code was attempting to break into a cryptocurrency wallet that was using event stream as a dependency now eventually they were caught and the scary part of the story though is that they're only caught because they

used an outdated api call within their malicious code so that popped up a warning every time the code was run if they hadn't used that api call who knows how long this could have gone undetected for so this really highlights why open source supply chain tasks can be very valuable because you can target very small targets and have a very large impact now let's say that you can't find the vulnerability and you don't want to ask for the project one alternative to break into these for these projects would be repo jacking so let's talk about how i actually ran into repo jack so the first time i ran into repo jacking i was doing a code a code review for a

project this project was written in go and it had a dependency to a github bureau very common i've done it hundreds of times browse through the url to see what it was and i got redirected to a different url different github repository that's that's very rare never seen that before try it again same thing so i thought that was bizarre and if we look at a github url there's three main elements you have the protocol and domain that's the first part that's not going to be changing right that's that's static and then the second part is the username and the last spot the the repository name the username is the one who determines the repository name since the user

gets the name the repositories so essentially in this url the the key identifying part is that username so i had this url which was loading code and it was working and i decided to go see what the user was and when i tried to browse to the username i got a 404 error user not found so that user doesn't exist but this project is clearly loading code from a url that points to it so if that usually doesn't exist i thought what happens if i were to register so i tried and it worked so i could re-register this user and i thought what happened if i recreate the repository so i tried that and it also worked and

now that url which used to redirect me to a completely different repository stopped redirecting me and brought me directly to this this repository which i just written and since the project i was looking at loaded in code from this as a dependency i now had done remote code injection on that project and that's the key premise basically of repo jacking github allows username reuse and because of that if someone is to rename or delete their github username then anyone can go in and re-register them and any of the old links pointing towards that username are now hijacked and would result in code injection so there's a couple of key points of repo jacking it's conceptually similar

to s3 bucket sniping or subdomain takeover if you're familiar with those essentially you have a location on on an online service or a yin name or unique identifier that can be re-registered after it's deleted it's very dangerous because since github is a code hosting platform a lot of people use it to load in dependencies so it often results in code injection and another scary part of repo jacking is that you may not change anything in your code you might have all your repositories which you've checked and they're not redirecting they're not doing anything funky but all of a sudden one of those dependencies owners decides to change their username and all of a sudden now you're exposed

to a remote code injection because of repo jacking so it can it can it can happen to anyone without changing their code and then obviously since github is public this is exploitable by anyone and it's trivial to do so you just have to be able to create a github account now let's look at three specific scenarios that can lead to repo tracking so scenario number one is the most obvious a user deletes their account so if a user deletes their account then obviously that account is going to be re-registerable by anyone and in doing so anyone who points to the old urls is are going to load in code from this new account now the issue with when a user deletes

their account is that in between the time that user deletes their account and a new account is re-registered all the links are going to break so all the dependencies are going to work so anyone who tries to update their project and is using one of these links is going to see an error and it's going to change their where they're pointing at so for an attacker to exploit this scenario they have to be very well timed and know exactly when a user is going to delete their account now this scenario has actually happened in the wild before kodi which is a video streaming platform allows for add-ons which can be loaded from github urls there's a popular add-on that was loaded

from a github url but the owner of that repository deleted their account in doing so that add-on broke whenever it tried to update but someone went back in and re-registered that account name so now they could start pushing updates to all these kodi instances now in this case it wasn't malicious but if they wanted to they could have pushed any type of update to all these instances and taking them over so that has happened in the wild before but effectively it was it's very noisy right everyone is aware of it because everything starts breaking scenario two here a user renames their account i'm gonna talk about scenario two and three because they're distinctly more dangerous than scenario one

scenario two two over here is where user they rename their account which means that now their account has a different name and that makes sense right you can re-register that original name and scenario three is a user transfers repository to another user and then then deletes their account now scenario 2 and 3 are more dangerous because of something called repository redirects so back in 2013 github implemented a new feature called repository redirects the premise was if someone renames or transfers a repository over all of the old urls will continue working and this is exactly what i saw when i first found repo jacking there was a repository redirect setup when a user renamed their account

which meant that all the old links were now pointing to the new links so look how it actually works right now if you browse to github.com twitter bootstrap you'll notice that you get redirected to twitter.com twbs bootstrap and this is a repository redirect twitter used to have the bootstrap project under its user and there's github user and everyone used to point to that link and then when they transfer it to a different user to manage bootstrap exclusively then there was a repository redirect that was set up so everyone who had that original that top url as a dependency it would now get redirected to the bottom url so that's very useful because it doesn't break everyone's builds and

everything continues working now the issue here is that if twitter were to change their twitter username to something else then every link that used to be pointing to that twitter bootstrap would be hijackable and everyone who depended on that url would then be vulnerable to code injection that's the dangers of repository redirects and that's the reason why scenario two and three are more dangerous because they set up repository redirects so user renames their account github sets up a repository redirect to redirect all your repositories to the new account but that username the original username is still available to be re-registered so anyone who depended on those projects as github urls all their projects will continue working

their dependencies will continue updating fine but now they might be vulnerable to repo jacking and another interesting thing about repository redirects is that it works for git clone operations so i use someone doesn't have to change all their get references and every time they update their user or transfer repository so that's essentially repo jacking um very impactful very easy um and so we went to github we said all right github this is what we found we think this is very dangerous and the response was oh yeah we know about this and that's okay because we've already mitigated it with this fix so they pointed me to this fix and essentially what they've done is they've

said any project has had more than 100 clones in the week leading up to it being renamed or deleted can no longer be re-registered so they blocked re-registering for projects that had more than 100 clones in the week before this is unfortunately not a sufficient fix in my opinion because if you look at something like microsoft typescript that's obviously a very big project and that's going to have more than 100 clones for sure in the week leaning up if it were to be renamed but if you look at some like concat map that just had 30 stars one contributor that's very unlikely to have 100 clones so if that concat map user were to rename their account

it would now be vulnerable to repo jacking and it would be very impactful we saw the types of projects which used concat map so this can work for very large projects but unfortunately very large projects are not necessarily the ones that would be targeted and would be the most impactful so we know that repo jacking exists github's not going to change the way it works so let's look at all open source projects scan through all the code and see how many projects are actually vulnerable we're going to walk through the different steps we took to perform this mass analysis so step one is data collection we've had two data sets here the first one is the

github activity data published directly by github is raw source code three terabytes of raw source code that's really great because you can search through it and extract all the github links out there the only issue is i was last updated in 2019 so some of the data might be stale and the second data set is libraries.i o libraries. the same page that maintained that unseen infrastructure page before and what they do is they essentially maintain a database of dependencies between open source projects this is really great because it's formatted data and once we find all the vulnerable projects we can use this to build out our graph database and find everything that depends on a vulnerable project

those are two data sets so we take these data sets scan through them uh takes quite a while but we end up with just shy of four million unique github links in source code so what this means is these are links that are pointing to github and their unique links pointing to github in the source code but we still need to clean this up so step two is cleanup we might have links for example like this this is a readme file and there's a link to a github repository but obviously code is not going to be loaded from a readme file so this is not impactful right even if someone were to take over this

repository they wouldn't be able to inject code or anything so we want to remove that and we remove for example github urls in a comment which we see very often because that obviously will not be loaded either what you want to keep are things like this this is a docker file and in here they're doing a wget on a github repository so if this protocol buffer user were to change the username then this w get would be vulnerable to repo jacking and therefore this the docker file and the docker container would be vulnerable to code injection now another thing to note when we're cleaning this up is that different package managers have different way of referencing a github

url most of most note here is the npm and the rubygem shorthand so if you look at the top one here you don't even have to include github anywhere if you just include a username slash a repository as the dependency npm is going to assume you're talking about github and go download that code and i think that really speaks to just how common linking to github for dependencies is because they've got this shorthand where you don't even have to say it's github we just everyone assumes all right if it's a repository username you want it from github clean this up we'll grab make sure you get all the links for github and after that we're left with 2.1

unique impactful github link so these are links which are going to be loading code directly from github so if any of the links are vulnerable to repo jacking then that link would be a center would lead to code injection so we've got all these links now we're going to extract the user names right we need to see which ones exist and which ones don't which ones can we re-register so we search through 650 000 github usernames it took quite a while over the github api with their rate limiting but eventually we were left with 50 000 unregistered usernames 7 now this is really a large number when going into this i was expecting maybe sub one percent

but seven percent is is quite significant and this is the point where i kind of realized just how impactful this might be so you've got 50 000 unregistered usernames and now it's the easy backwards backwards steps where you see okay got all these unregistered usernames how many of those how many links are using those unregistered usernames so we've got 92 000 hijackable github links so links that are used to load in code and can be hijacked by just creating a new username all right and how many projects are using one of those links i ended up with 18 000 directly vulnerable projects so these are projects that are directly vulnerable to repo jacking let's take a look at one

example here we have algolia search helper version 3.2.2 it's since been fixed and what we're seeing at the top here is a package.json file and that is the npm package manager file that tells you where you want to pull in dependencies we've got this shorthand which you'll call is links to the github shorthand here where it's a super wolf user slash mel smith in place repository so first step to see if it's vulnerable we checked the user does this super wolf user exist and you browse to that and it does not so this user doesn't exist so it can be re-registered by anyone now in that case why would this why would a good search helper be using this

as a dependency if we actually browse to this url we see that it's getting redirected to mel smith slash mel smith in place so what probably happened is that super bowl fuser renamed their account to metalsmith and it set up a repository redirect so a girl search helper is still loading in code from here but if we were to recreate that super wolf user and recreate that metalsmith in place repository we would now be able to inject our own code into a google search helper so that's an example of a directly vulnerable project now the story doesn't end there though because i'll go to search up there's just a library and we want to see what projects are

using this library so if we take a look at our google search helper we want to see every project that depends on it so we want to do a reverse dependency analysis search and this is where that libraries the io data comes in handy we created load it all up into a craft database and then you can walk through the database and the graph to see what is dependent on this and which projects actually use this because anything that loads a search helper as a dependency is going to be also impacted by repo jacking so if we walk through and we see all the different projects we eventually reach a view instance search all right and what uses that and this is

that recursive dependency analysis that we want to do to see what is what is really impacted by this vulnerability reach the view cli dash ui and eventually just the view cli so anyone who's familiar with vue.js will recognize this as the official vue.js command line tool and anyone who is developing a vue.js is going to have this tool installed so essentially what we have is we have a google search helper as a dependency of view the vue.js command line tool so because i'll go to search helper or because that superwolf user renamed their account now all viewed the entire vue.js ecosystem can be potentially vulnerable to remote code injection and that really speaks to one not only how

impactful repo jacking is but just how impactful in general open source supply chain attacks can be because one small library can impact huge projects so that's why it's really important to do this dependency analysis so we can see the full scope of impacted projects so we start by doing that depends analysis at depth one those are directly vulnerable projects and then we move on to depth two we've got thirty two thousand projects and depth three thirty eight thousand fifty five thousand eventually at the depth of five we have seventy thousand impacted projects now we had to stop at the depth of five because as we attempted to compute the depth of six it just wouldn't go and

that's because at the depth of five we reached some major major frameworks that were used by hundreds of thousands of other projects and it physically took too long for the computer to process the next depth level and we didn't want to end us because this was more than enough to prove just how widespread is 70 000 impacted projects and so that's where we stopped the analysis so now we've got all these findings let's uh let's actually look at what some of these findings are so we've got 70 000 affected open source projects these affect projects in every language javascript python go everyone can load code in from github and everyone does and so it's spread out across all these

different languages and it's also spread across all types of projects we found router firmware personal projects websites crypto wallets a whole gamut of different projects and also affects virtually every single big open source company or open source uh contributor such as google facebook microsoft even github themselves were affected so definitely very widespread if we actually combine all of the github stars of all the impacted projects we have 1.5 million github stars which is huge amount and now this last stat is hard to quantify because you no one you can't really tell exactly how many how much repository is downloaded and not all project not all project managers are would tell you just how many daily downloads it has

but we estimate that there's at least a minimum of two million daily downloads unique daily downloads for these impacted projects so again a huge number so i have all these projects and they're all loaded up into a graph database i thought it would be good to make a visualization just to see uh just how impactful it is so i've got here is i'm going to have a little animation and this blue circle is one project and the size of the blue circle is scaled up depending on how popular it is so in this case this is a project with a thousand downloads a month and you're going to see white lines and those white lines are how different

projects relate to each other so we're going to zoom out here as we look at this one project 1000 a month and at depth level one these are the directly vulnerable projects so you see there's some big projects already it's directly vulnerable as you move down you're gonna see the the different projects are moving out in circles so at depth three we've got already you know lots of project and you can notice that if we stop if we stop at depth five here you notice just how many projects there and how big they are that project in the center you can no longer even see it and it's overwhelmed by such that's the number of projects and the size of some

of these projects and you'll notice that depth five over on the right side here there are some huge projects were impacted and this is why we couldn't reach depth six i think this visualization is helpful to kind of comprehend just how impactful this is and you can also draw some interesting you know conclusions and some analysis by looking at this bundling on the left and such and all these huge projects so definitely very impactful now remediations because we need to be able to protect ourselves from refill jacking so the first and most obvious remediation is don't link directly to github repositories always use a package manager package managers are there for that they're meant to be a

unique link to a piece of code so always use the respective package manager whatever's popular for your language and even using a package manager make sure you don't use the package manager but just link to a github url because that defeats the purpose there's no real safe way to link to the github to a github repository and it's just easier not to do it alternatively what you can do is something called version pinning so when a version pending is usually a package manager will allow you to version pin a dependency so like a github repository to a specific commit so in this case we see mel smith in place this is the example for the algola

search helper um at the end here you've got the uh the little hashtag and then a git commit and so what they're doing is they're version painting they're saying okay npm only download this specific commit and this is effective because it stops someone who were to hijack the repository from putting their own code since it wouldn't match the right commit hash obviously you don't want to pin to a tag or branch because those are mutable and those can be changed by the attacker now unfortunately there it version painting is not perfect as i was doing this research i also took a look at some of the most common package managers and looked at their version pinning went

through the code and turns out a lot of them can be bypassed they're not perfect and sometimes people are using them just to ensure that they get the right version and it's not necessarily a hundred percent uh purely for security so there are cases where it can be bypassed and in that case and that's why version pinning is not the perfect solution and remediation number one is still better where you just don't link directly to github there's no way for anyone to hijack a github repository that way now remission number three here and it's very much like version pinning air lock files log file is basically a file that ensures that only a specific version

of a dependency is downloaded very much like version pinning now unfortunately not all lock files are created equal lock files are useful for many other things security just being one of them if we take a look at the npm log file here over at the top we've got events which is a dependency and this dependency comes directly from the npm index and it has an integrity check so that's great because that way even if someone were to break into the you know npm registry and modify that events dependency the integrity check would fail and you wouldn't be able to modify that so that's a great use of a log file there unfortunately when dependencies are

downloaded directly from github urls for example this express you see it goes to github vision media express there's no integrity check um it just relies on this git commit hash to be that integrity and as you saw version pinning that can be bypassed in certain cases so log files are good again but not perfect so the tldr basically of this talk is that github repositories can be hijacked you should never link to them directly and doing so might result in code injection so just don't do it repo jacking i've written the blog post about it if you want more information things i couldn't cover in this talk repo jacking exploring the penn state supply chain over at the screen

innovation blog post feel free to read that and keep an eye out there for a potential future blog post with some updated findings you can reach me at any of the any of the common places and thank you for listening to my talk i hope you learned something new about repo jacking all right excellent everyone thank you for joining us this is the q a for our session on repo jacking specifically most of the talk focused on github but you know the concept in general is is broader as you know we've seen recently in fact i mean i've seen this kind of vulnerability you know goes beyond just repos to some degree right as we just

recently saw with uh domain repurposing and the embedded video ads on many popular websites that suddenly found themselves serving up you know porn ads on news sites and so forth right um so i i loved the the the individual advice you gave to you know to folks on how they can protect themselves in github on this but i mean do you think we can ever get ahead of this kind of thing by just focusing on the individual or even on individual domains this seems um you know even something as pervasive and indispensable as github right you know uh there there's a a broader problem of of trust here that seems like uh you know we're basing trust on identities that

are not unique and immutable you know as we thought they were right and over time we see that the the improbable becomes almost certain um what you know do you have any thoughts on like a broader um the broader impact of this and the in the structure of the industry and and how we use and consume resources on the web yeah that's a great that's a great question um a very similar example to repo jacking which i mentioned in the talk here was s3 bucket sniping so the concept is very similar with an s3 bucket an aws s3 bucket uh you have a unique name if you delete the bucket anyone can re-register it and

any links to the old bucket uh would not be controlled by whoever re-registered it um so the content of various limiter as you said it all links back to the idea of not having a unique id right so in the case of s3 buckets they're global um so anyone can can register them so i think the the kind of overarching solution to this kind of problem is not necessarily individual but it's more on the company making these um allowing for that reuse is really the biggest the biggest problem here um solutions are because obviously as you know with github usernames there's only a certain number you don't want you don't want someone to take grab all

of them and then there's no more good usernames so you want to allow some reuse um but you want to have the the usernames be more unique so one potential solution you have there would be have some kind of id um you know maybe like uh you know i i know discord does something similar where you have you know maybe github username and then hashtag 37 or whatever or whatever unique id and that way that specific one can't be reused um and i see that's kind of the the solution from the the server side there um but yeah that's just a question you know different service need to implement them themselves right yeah and that's and then getting

everyone to do something like that consistently is always a joy in infosec that's a lot of cats to hurt right um so i have a question from a user asking if they hijack a project uh can i see if there's any version specific requests like can i replace the specific version right okay so great question um so there's a couple of different uh points here so github is uh hosts get projects right and to access when you're accessing a git project there's many different ways you can do it so the most common of which is just browse you know to github and you arrive to the latest version right on the main branch but you can access projects through

different ways so you can access a specific commit right and that's like a sha-1 hash commit of that specific uh location code or you can access maybe a branch right there could be many different branches or a tag so it highly depends on how the project which is reaching this github repository is actually attempting to grab the version so if it's a branch or a tag um which is very common maybe you'll tag a certain uh a certain commit as version three or whatever unfortunately github doesn't provide any stats for those um so it won't tell you hey you know this certain branch was downloaded x amount of time or this tag was down in x amount of time

what github does provide is the total number of clones or the total number of times it's been downloaded and that includes all the different versions or the total number of times a specific release has been downloaded um that's that proves to not be terribly useful because most people don't link to the the release files um which are you know like an individual file that you can that you can host on on github um so unfortunately that i haven't found that to be accessed a lot a lot of the time people will be accessing a tag or branch or specific commit and in all those cases there's no way of knowing but you can still replace them

and the brute force approach would be a replace everything go and you know if you hijack a repository you can change all the tags change all the branches to include whatever you want or the more specific approach would be to find a target of the supply chain that you're targeting see what version they're calling and then replace only that version all right sorry we got we had another question coming in here i see i see the typey typey happening but uh it's oh no oh well um ah there we go uh oh okay just uh general thank you okay great no i i agree it was an excellent presentation the the thing that gets me most on this one

is just the absolute scale of it right like i did i knew this was an issue you know we've also like i said we've seen this in many other kinds of places but the number of projects watching that animation go and realizing like i almost i want to i want to put out like ask somebody to buy you some more servers because i want to see that computation complete out to that that sixth level or you know and beyond right you know it's um uh just mind blowing uh how inter-woven all this stuff is to the point where uh you can a relatively small you know uh project like that could have that much impact and potential you know inroads

absolutely i mean that's the nature of libraries and open source right it's all about sharing code um but it also means that everything is interconnected in some way or another so if you can get one you can get them all and i mean dude this is where i was going you have a sense is this a um is this an outlier or is this pretty would you assume that almost any you know project that that you know has this uh is in this state would have a similar graph right uh or is this just like you you you looked at a hundred of these and this one was the the the 99th percentile and the others

are you know like what's the distribution yeah so so that graph was actually um a graph that included all the projects which were okay so that initial that first uh dot there that was just kind of like a fourth scale uh dot to be like hey this is the size of a thousand dollars a month but that include everything i know thanks for the clarification that i i think i was trying to do too many things at once i missed that so yeah i'm glad that i'm glad you like the graph because i'm not gonna lie to mia it took me quite a while wow no it's it's one thing to see the numbers it's another to watch that

animation like you know happen and uh it really made it impactful oh we got one more coming maybe uh mr glass one of our very own oh no okay um all right that being said uh unless oh okay here we go um yeah you showed at the end that not all npm locks are created equal but those files tend to be way too large for humans to read right so do you know a way to scan for an unlocked include using npm audit or similar tool so when i was talking about uh not all log files being equal i was referring to log files being different among different package managers um so in the sense that you know npm

does it one way and then maybe pip does it a different way and um you know composer for php does a different way so within but if we look at within this specific package manager so for npm effectively you're right that you can have some dependencies which are in that log file and some that aren't i haven't found a way specifically to get a list of those that aren't in the lock file so i wouldn't be able to help there um but yeah i guess i guess it would i'm sure i'm sure it'd be relatively easy to do it would be a question of actually doing it so unfortunately if i've got no help uh

no help there um so uh given that there isn't uh an implemented like s-bomb out you know secure build materials uh software build materials uh how can i find out what multi-level dependencies a project has that's a great question um and that's actually really it's a tough problem um because effectively you know you can look at maybe a very specific package manager and then maybe they have some way of doing it i know npm has a way to graph out the tree uh with an npm um but that often doesn't catch everything you know maybe npm package manager is only looking at dependencies to the npn index so it's not looking at dependencies to a github

url um and you know and with the mass amount of different package managers it's really hard to have that standardized um and the best i found for that is libraries.io so i've actually i talked a bit and that was one of the data sources i used to perform the the dependency computation libraries io it's a website that maintains essentially a database of dependencies and one of the features they have is if you search up any project it can be a github repository or any package really for basically any package manager you often have the ability to explore dependencies on the right side there so if you if you go there it will give you a nice graph and it might take a

little while to cube it'll give you a nice graph of the different dependencies a project has and i found that just to be the best way to see the size see the scale and in general it's a great way to to kind of navigate open source projects and their dependencies so that's what i would recommend great that's uh yeah even if it's not perfect you get a 90 pictures is uh give you an idea of the scale of your exposure yeah exactly all right uh well we greatly appreciate your your talk and showing up for the q a this has been uh a good contribution to the overall discussion here thanks for your time thank you very much hope to see you

later on absolutely