BSidesNoVA 2021 | Josh Stella |Blowing up Serverless Security with IAM ( And How to Avoid It)

okay hi everyone uh my name is josh stella we've been having technical issues all morning i hope you can hear me and me now uh can somebody put in the chat okay loud and clear thank you uh uh graphique uh well that's probably less lucky for you i am uh josh stella i'm the ceo and co-founder of feud we are a cloud security company uh focused purely on uh cloud infrastructure security um infrastructure has code security uh we were the pioneers in that uh back in the in the 2016 era and it's 10 years or so of my life focused on cloud security um and so i think i've learned a few things that i want to share with you and

hopefully it is helpful uh in the last really two and a half years fugue completely re-architected our system uh basing it on lambdas so in the past we had we we've been around i left aws to found fugue about seven years ago uh by the way when i was at aws i was a principal solutions architect for the department of defense and other national security kinds of environments and nasa and folks like that so uh just a couple few years ago we re-architected on lambda we were on you know ec2 and the earlier services uh but uh we we were doing a major shift in how our product worked to assass and we built it all in lambda

and we have a few containers and of course we have some other service types aside from just functions but going through that experience was really interesting as an architect i'm a my background is a programmer and architect software architect i'm not a security analyst but i've lived in a lot of really security sensitive worlds so i've been architecting systems hopefully in a secure way for a long time so far uh pretty well so i was very interested to see how going serverless really changed how we had to think about the security of the system and the good news is there's much less attack surface much less drastically less because you're not worrying about operating systems

that's managed by the cloud provider and they're unless they've really done a poor job and they usually do a very very good job there's no way to break out into the operating system from a function so you don't have to worry about that stuff uh but in another place it gets a little more complex and that's because you your your architecture is kind of externalized things that would have been bits of code talking to each other inside of one machine now become networked distributed functions and so the attack surface gets smaller in the kinds of things you have to concern yourself with and larger in the number of things you have to concern yourself with

because if if you do serverless really well you're going to have a lot of these things okay all right let's see if i can figure out how to share my screen on this guy um share options uh it's only seen two of my screens let's do that okay i hope you're seeing a deck can somebody tell me in chat if you are seeing a deck i'm not seeing any indication is that a no thaddeus you seen a deck no black screen okay well that didn't work let's try this another way thank you for that feedback let's try it over here that screen it seemed to see all right yeah yeah it's not a black themed deck

uh now it looks like you're it looks like you're getting a duck okay um yes seeing a black screen okay i think it's i think it's a deck now because i can see this little icon up here it looks like i'm not used to this um uh excel events thing okay cool cool so what we're going to talk about today is uh blowing up serverless security uh how the way i like to think about security is to think like a hacker that's really all that matters right things like compliance standards and so on are great and necessary but are means to ends and the ends are stopping hackers of one form or another you know whether

it's inside threat external hacker state act or whatever good luck stopping state actors by the way but uh uh yeah so i like to think like a hacker and so the way i approach these topics and i hope you enjoy this is to look at it from that perspective and how as a hacker am i going to blow up a serverless environment and and breach it and get to the data right usually as a hacker we're trying to get to data um alternately might be crypto mining in your account but usually it's get to data at least somewhat uh and that's primarily going to be through uh iam configuration uh identity and access management configuration okay

hence blowing up serverless security with iam and how to avoid it all right we're gonna set the table i'm doing that now and thanks everyone for your patience while i had those uh technical challenges um getting in here uh but we've got a we've got a long session so uh we should have plenty of time for uh covering everything that we need to and and and everything that you want to another thing i'll say is go ahead and interrupt me in the chat i love it when people uh when these sessions are interactive they're just much better so if there's stuff you want me to cover that i'm not drilling into or you have questions or you want to challenge an

assertion whatever just hit me up in the chat and i'll try to notice it quickly so right now what we're doing is setting the stage and then i'm going to do some deep dive and what i mean by deep dive here is i'm going to be mostly white boarding and pointing at diagrams and resources through a web browser like the aws console and so on and just walking through a number of uh different uh ways you you need to be concerned with uh with your security and then uh we'll make some recommendations and it says q and a's at the end the q a is all the time okay so anytime just shout out all right

so um rethinking security in a serverless world um first of all let me say as i alluded to earlier i think as security architects as as people who are engineering secure systems the serverless world is awesome compared to what we were used to but you have to think about it differently and many of the misconfigurations that create vulnerabilities they do often involve iim there are exceptions to that but a lot of them involve iam and i'm going to explain why shortly but a lot of these kinds of misconfigurations are not seen as problems in compliance standards and so in feud we support probably more than anyone you know all the cis standards and nist and hipaa and

gdpr and nist 853 iso 27k that stuff is all really important but it doesn't it hasn't really kept up with the times in terms of uh well at least most vendors interpretations of and most teams interpretations and auditors interpretations of those aren't really probably going to catch all the stuff you can get wrong in these serverless environments and the reason is simply that they were really initiated thinking about data centers and servers and so on in part because of that most security teams don't recognize these things as vulnerabilities they look fine right very often security teams are reliant on those compliance standards to help them what's safe and what's unsafe so because the compliance standards are behind

a lot of the security teams think they're in a better posture uh my favorite one of my favorite g2 reviews of our product and i'm not going to be pitching our product today but uh was uh that fugue is going to is going to hurt your feelings and what the guy made it was a positive review but what he meant by that is we're going to find stuff that is dangerous that you thought was okay and it's really important to have that that cloud domain specific knowledge whether on your team or in a product like ours or something else because these things go overlooked and the compliance standards aren't going to help you too much

most of these are only apparent in the full context of an environment right you can't just look at the code in a lambda there are things you can do in code in lambdas or other kinds of serverless functions that are dangerous and and and bad ideas most of the stuff that is dangerous and our bad ideas only becomes uh possible to to reason about when you see that function in the context of the broader distributed architecture so our director's security likes to say that in serverless security is architectural just fundamentally architectural okay excuse me and because of all these things uh easy to overlook during security audits if you don't know you have problems you're not going to find them your

auditors aren't going to catch them but hackers are aware of them and will exploit them so this is this is the problem and often they can exploit them without detection so as you get into excuse me frog in my throat as you get into the serverless and really distributed world um the traditional places where you look for where you look for issues like the network boundaries largely become irrelevant because you're not typically traversing um user visible network boundaries with these serverless distributed applications you tend to be using the identity systems and and and policies as your network uh and therefore it can be really easy for hackers to do bad stuff that you will never

even know happened okay i want to talk a little bit about the dreaded shared responsibility model if you're if you're a fan of corey quinn you'll know that he is he has a much pithier and less safer work description of of this in which he says it's basically all the hard stuff is on you and okay there's a lot of hard stuff that aws and microsoft and google took on but they do leave a lot to you so if we look at this shared responsibility model i'm going to assume folks are mostly familiar with it but i'll spend a little time drilling into it down at the bottom is the lowest layer right this is like

at the very bottom you've got regions availabilities ends edge locations this one is aws focused we're there we're talking about like physical plant right you know buildings and as we go up we get into the actual global infrastructure like the the networks that are run by the cloud service provider the physical devices that the cloud services are run from you know the compute and storage and database and virtualized networking the higher order software kinds of uh you know layers that they put on top of those lambda being one for example and that's where their responsibility ends in this version of the model and then you go up into the blue stuff that's all on you

it's on us right um client-side data encryption operating system network and firewall platform application identity and access management configuration and customer data network traffic all right so when i design a system in the cloud one of the principal things i'm trying to do is shove as much stuff to aws or to microsoft or google in this shared uh responsibility model for security i want to handle as little of it as possible and this is a beautiful thing about serverless and things like manage databases is a lot of that stuff you can shove onto the yellow side of this line in that software box okay that software box are those kind of higher order services so uh and if you're using containers

you know use and you can you can argue that containers are kinda serverless i mean they're more like little little pseudo vms i suppose you know but um actually interestingly on aws i believe all the native container services are actually not linux containers but um micro vms which is much much better from a security boundary perspective no shared kernel memory space things like that um but what you want to do is shove all the stuff onto them right if you can do that in a cost-effective manner what we found for our application with lambda is uh not only could we shove the vast majority of this stuff onto aws in the shared security in the shared responsibility

model but also uh our application got much less expensive to run uh in lots of ways both in our aws bill and in our maintenance costs uh you know internally and so on so so those things can go together uh but you really want less of this on your plate more of it on the cloud provider's plate see if i get my mask to the right screen all right so let's do some deep diving i'm going to stop sharing for a minute due to my technical challenges earlier my my setup got a little munch so give me just a second here

i'm gonna share a whiteboard with you okay so the first thing i want to do is really walk through um the the mental model of how to think about security in in in cloud in general and in this case in serverless it's it's like just fundamental to serverless security okay so in uh clouds and and i'm going to use i'm i came from aws i'm primarily an aws user uh but everything i'm saying here is is equally true on google's cloud and microsoft's cloud um those

thing here is when you're when you're thinking about security in the cloud it can get very overwhelming and so i think it's good to have a mental model that you can uh kind of come back to to rationalize things to get your head around things because otherwise there's just so many details and so many so many devils living in them that it can it can really get out of hand all right so i'm going to use the aws terms as i said so in the cloud there are really from a security and policy perspective which is mostly what we're going to be talking about here there are three kinds of principal uh objects three kinds of like

fundamental objects one is principles okay so uh does anyone know what a principle is in aws well i'll i'll watch the chat and see but um i'll tell you on this one a principal is something like a user okay so you might have a human principle which might be josh uh but it is also and this is where in serverless you're going to deal with this a lot a principle can be a cloud resource so for example you can have a lambda as a principle i'll come back to this so you've got principles you have actions and actions are uh things you can do through the cloud apis yeah principle user or role exactly hitachi yes it's the actor if

you're used to old like uml stuff i shouldn't say old people still use it i guess uh the uh actor is kind of what the principle is in aws cloud the actions are are the verb list they're the api endpoints uh so things like you know um you know get objects from s3 or execute on a lambda right and then you have resources okay resources are things like ec2 instances lambdas that's my favorite uh rds databases the the stuff you create that has unique identifiers so instances of things in the cloud your vpc networks those are the resources okay so out of the box aws has uh a default policy about which principles can talk

to which actions and can talk to which resources does anyone know what the default uh policy is in aws i'm gonna get a sip of water while i wait

going once okay uh it's deny deny everything this is the correct architecture this is very good design on their part and what that means is if i am a principal or let's say it's josh uh yeah default deny all exactly no permissions yes oh man there is a real lag so uh you guys were getting it i just wasn't waiting long enough good job that means i can't use any actions and i can't use any resources right none of that is provided me because it's by default deny everything so this is where policy comes in in the aws cloud policy has a lot of locations and this talk is primarily about iam because a lot of this stuff is handled

through iam and and is exploited through iam in creative ways by hackers uh but there's other layers of policy too that i'll speak to as well so what you're doing with with these policies is you are creating uh allowances you're saying allow uh get object for example so you're poking a hole through that wall of denial so josh is now if i have an iim policy that says uh allow get object you know s3 get object now i can do that action okay um and i never put an s3 bucket over here let's do that and depending on how my policy is configured around resources i may or may not be able to apply that

action to this particular s3 bucket we'll call it bar let's uh imagine in this scenario that i i did allow for that so as you're creating these uh iam allowances you can define which resources they apply to this is something when i give a lot of these talks uh yeah here we've got david resource bucket scps yes kms etc yes there's lots of places policy uh happens in the aws stack and and many of these interrelate and the way that they interrelate is the entire chain of policies that are relevant are kind of added up and if anything in that stack denies it's denied so you can do patterns like for example having an s3 bucket

with an s3 uh bucket policy on it that only allows requests from oh maybe a a cider block or a particular uh you know vpc and so you might have an actor that has access to get an object out of an s3 bucket but the the resource policy or the s3 bucket policy might then block that and that's that's a valid and i think actually quite useful pattern so uh but the main thing when we're working with serverless is the number of principles is going to be huge uh if we have anything like a complex application okay so in in in by principles i i really mean that i mentioned earlier i put a lambda

over on the left and there's another lambda over here on the right why is that because when you create objects resources in the aws cloud generally speaking the right way to configure access for those things to other resources is by them acting as principles using the associated iam policy okay so you end up resource to resource where the calling resources the new principal remember that's the actor and the receiving resource is thought of as the resource from a policy perspective so um let me let me draw that too because that's maybe a little confusing so we'll get out of but keep in mind the principal actions resource uh triumvirate there so let's say we've got

a uh an application and we are starting with an api gateway this is a very common um architectural pattern for using lambdas for using serverless is to have a gateway that is identifying the request uh type coming in within the api and delivering it uh to the correct um to the correct lambda uh on the based on which one it is so what we're going to end up with are a number of lambdas over here and depending on how that request comes in it'll route to the correct one but then very typically what's happening in a serverless application is they're a whole lot more than those first entry point lambdas there's a whole chain of them that usually ultimately

ends up hitting some data persistence layer of one form or another either for read or write operation so we might have over on the right here you know an rds database uh or a dynamodb table okay and then we're going to have this big bunch of lambdas in here and maybe we have mixed in here some like let's see if i can draw a whale some containers i'm not gonna try any more whales that's pretty bad i'm just gonna mark k's for you know kubernetes and and we're chaining these together logically uh to perform operations right so in the the pre-serverless days uh you would uh kind of bundle your different operations together uh into a

program right and the program would call functions within itself so uh serverless is super cool because it externalizes those functions right it puts them on separate infrastructure so for fugue for example we can we manage millions of cloud resources for our customers doing security for them we do billions of evaluations a day we don't have to scale a server for our peak load because we have a highly variable load based on what our customers are doing um we can just let the the scaling happen in the aws uh lambda service where things are going to get spun up for us as needed so we're going to have a lot of these things in fact we

we can run a lot of them at once in fugue um and so what you have to be concerned with then is what kind of permission uh you're giving as you work your way through this stack ultimately to an rds database so the whale is awesome thank you donald uh if i could send you a t-shirt i would um so so you're going to be concerned with every one of these right is an allowance remember deny everything said no lambda can talk to any other lambda unless it's allowed to okay so some of the advice i'm going to give actually i'm going to pull up i'm going to pull up a diagram so here i'm i'm showing you fugue our

product but really just to show you how these things look so um and i really should have pulled up i'm giving a serverless talk i should have pulled up a serverless application shouldn't i have uh well i didn't so we're stuck with my bad choice all right what i wanted to show you is this so this is um an ec2 instance which is a resource that is acting as a principle okay it's acting uh as a principle uh because it is allowed to call other infrastructure and it does that via this stuff right here the im instance profile and uh the i am roll those uh that let's let's see what we i don't know

oh yeah here you go um so uh our product team are always adding really cool stuff so so this is uh the demo app role it it's what's giving that thing the permissions it needs to go through now normally when i teach this stuff i recommend limiting the number of uh of policies out there and roles out there because they can become really hard to manage and i also normally recommend not putting uh specific named resources as uh limitations uh within an i i am policy so in i am policy you're gonna have uh a few sections uh you know what you're allowing or denying and you can have a resource section where you can specify

on which resources you're allowing that and normally i kind of discourage a lot of that use because in a lot of cloud environments things are coming and going rapidly and changing names because the new one is going to have probably a different name so those kinds of im policies can be really really tricky to manage and can actually drive you to bad architectural choices they can they can make you want to not replace stuff that should be because now you got to go figure out everywhere it's touched well that's the advice i normally give i'm going to give you the opposite advice today for lambda i think in lambdas each of these lambdas we've got

right each of these guys should be limited extremely limited in the i am role that it is using as to what other resources it can talk to so for example it would be a really bad thing if this lambda over here if it did not need to talk to the database if that had permission to talk to the database that is that is pretty ugly the more common i don't see that mistake as commonly because people tend to be aware that databases and the like are are sensitive what i do see more commonly is giving lambdas the ability to execute other lambdas and scoping that too broadly uh that needs to be scoped yes david

says least privilege absolutely we're going to get to some of the implications of that um because if you're in a system like ours where we have hundreds and hundreds of lambdas in very complex execution chains this gets really tricky uh but i'm gonna share with you an approach that um that we use so so this uh back to back to this lambda over here we also if it doesn't need to talk to this uh to this to the whale we'll talk to the whale uh and we give it that um that is another form of uh you know security gap and and the execution commands in that case it wouldn't actually be an execute because that's a container not you'd be

some kind of network connection probably or what have you but the what you don't want is for hackers to get a hold of the credentials associated with the role right so going back to our um going back to here this guy has come on uh this guy has this instance profile and a role um what that does is at runtime it generates temporary credentials so um in ec tuning containers that's often distributed by the metadata service in a lambda if somebody does manage to somehow execute some hostile code inside the lambda probably what i would do with it is try to get those credentials and spit them back out return them because those credentials can then be

used depending on how you've architected your policy lots of places to do lots of things so you really want those don't just think about you know um don't just think about keep losing my mouse um what is happening in in your graph think about what could be done with any role you've granted here from somewhere else because that's how they're going to do it typically it's it's really painful to try to hack lambda and and do anything meaningful because you can't really get purchase right so in the traditional world uh you would get into something with an operating system and you would kind of hang out there you would you would get purchased there and

then operate from there because you had a bunch of tools you know i do a talk on the on one one breach the the you know one style of breach using im on ec2 where having shell and then access to the aws command line is is critical well you don't have access to the aws command unless you've got a really weird lambda i don't know if you could do that somebody told me could could you bake the aws cli into a lambda and have it function i don't know the answer but i doubt you're gonna find it when you land there right if you're a hacker and you somehow get purchased in one of these things

like sloppily written application code for example you're really only going to be able to see the configuration of the lambda and perhaps some cache data that is something you should be aware of and i almost forgot to bring up depending on how you're using these functions you can have in-memory cache data left from earlier transactions so do not think that the transaction boundary is a security boundary temporally on the same lambda so if you have a long-lived lambda and it does you know a bunch of different tasks for different people coming into the system there is the potential there from one transaction to the next for there to be cash data left over from the earlier operation and that's

something a lot of folks don't necessarily think about in terms of um security architecture with with serverless so so what you want then is for each of these guys and typically in these scenarios the paths through these are really you know uh pretty unique um right you're gonna have some kind of operation up front that the api gateway is gonna see maybe it's a in our case it might be like scan the cloud environment for for security issues and that hits a certain lambda that kicks that process off and then as we start scanning we spawn you know 300 lambdas to do scans and policy analyses and then it goes into a database and then it

returns some token so there's this path through this distributed system and each of those kinds of operations your system needs to do needs to perform probably have quite different paths with hopefully not a lot of shared long-lived resources that's kind of an anti-pattern in serverless you uh aws sort of uh optimistically named lambda lambda um it it it you know and if you're familiar with what a lambda is in programming it's a function uh meaning that uh there are no side effects right and that's that's not quite true in lambda but what that means is a good way to think about these things are um as you're designing your system both for application design and for

security um item potency and uh limitation side effects so in other words you should be able to call the same lambda function twice in a row with the same inputs and get the same out in most cases until you get to the data persistence tier anyway i've gotten a little off the trail um so how do you do this let's let's say a few we've got hundreds of these things and there are thousands of paths through um the short answer is a big part of your job when you're writing a a true serverless application is your application should be generating the iam roles it needs in an automated way you should build that into your budget

for programmer okay because that that isn't a part of the application design now these im roles should all be generated every time you do a build of the system they should be absolutely limited in scope you should probably think about and there's uh i don't really have a link to send you i should have i should have looked ahead i'm sure there are projects on github for doing this um we we rolled our own but um you really want this these these iam role associations and the policies that are attendant to them to be a natural thing that falls out of your cicd pipeline if you're not doing that i'm happier as a hacker because

you're probably doing two things if you're not doing what i just described or maybe someone has another option that's the best one we could come up with and it's worked really well for us because as we have grown the system and added functionality we just add to the generation of im policies that we need and it kind of grows naturally with the system the upfront learning is probably the hardest part um i give a couple of talks on on details of iam that might be helpful there that you can find on our uh on our youtube channel uh but if i'm not doing auto generation i'm probably doing two things that are bad uh one is i am probably not doing least

permission least permissive uh least privileged i am probably being too broad and as i said at the beginning uh the worst i've seen that or actually not not the worst i've seen it a common mistake is well any lambda should be able to talk to any other lambda it's just lambdas right no execution of lambdas is not something you you you want most lambdas to be able to do most lambda should not be able to execute most other lambdas and frankly shouldn't be able to see them and this is another aspect of cloud security that that i like to really beat the drum on 90 of hacking at least probably what 95 is discovery is learning what is out there okay

and denying hackers the ability to do discovery is a critical part of your security strategy when you're talking about iam so things like list permissions are do not belong in your production environment people think of list as harmless it is not harmless it is probably one of the most dangerous things to have sitting around in your running environment now obviously if it's you know josh on the left or david on the left acting as a principal i'm going to need some list permissions you know i can't i can't go and uh you know do [Music] something like this where i want to go interrogate the whole infrastructure and enumerate everything and you know diagram it i need to list to do that but

i don't need this thing running in this to have the list permission that is uh super super dangerous so um trying to keep track on time we got a few more minutes i think um well any questions on anything i have shown you and i know we've got a delay so i'll wait a couple minutes while i type in a url here

okay not seeing anything i'll give another sec uh i'm gonna show you a little bit about um creating i am policies this is this is pretty central i mean as you get good at this you're gonna automate it and and you're not gonna be clicking around an interface but to learn about it it is um it is pretty helpful

okay so so what i've done here is i've started a policy that is oriented toward doing things with the lambda service and resources okay and what you're going to see in here are different uh categories list right yeah like this guy list functions don't don't put that out there don't do that if i can list functions i can probably infer what they do and you've probably got some function out there in a distributed architecture that's like a database connector or something something like that some you know ss3 read writer i don't know uh but uh if i'm a hacker i'm gonna if i can list functions it gives me a little bit of a map i start

to build a mental map all right uh so here you can see lambda one of the other nice things about lambda is there are believe it or not so few of these uh in the service if you compare this to something like uh ec2 where i think there are 400 though these are the actions that i was talking about in the diagram right you have the principles the actor you have a list of actions and then the list of resources so these are the actions and there's lots and lots and lots of them in aws but lambda only has i don't know it looks like maybe like 60. maybe not even that 24 56 i was in the ballpark uh yeah probably

is about 60. um yeah so um so as you're so learn these this is a manageable list the older services the bigger services like ec2 boy is it a hill to climb to to navigate through the 400 and change actions on that service it is really challenging uh much less so with lambda lambda is much easier to understand and i think that that that um maybe that's aws learning with experience how to not give us so so many actions to try to manage uh could also just be a function that ec2 has been around forever and and aws does a really good job of not deprecating uh actions and api endpoints um because uh man that can really break

systems right if you've if you've already written something that relies on them so uh learn these um again i would recommend you know turn that off you don't need to list in production there's other ways to pass that data around through a secrets manager or something like this even a database um most of these reads like get account settings you don't you don't need that um and the the various right ones so so you want to be careful when you're uh when you're creating uh your im policies really spend a lot of time there um use uh ruthlessly that uh principle of least privilege of least you know permissiveness uh careful with your allowances where'd my deck go

oh it ended up over there somehow i'm having a bad computer day um oh yeah here i've actually got some of these recommendations to put in front of you so instead of just me calling them out you can see them yeah so least privilege one iam role per function be careful oh we didn't even get into this cross account i am can be really uh nasty with in terms of the unintended consequences in these environments so be very careful with that um yeah use code reviews to identify uh vulnerabilities like event injection uh in an earlier form of this i had our head of uh engineering with me and he actually shared some code on event injection actually that's

up on our youtube channel there's a couple of classes on serverless on our youtube channel that have a that actually have source code in them this today i didn't i didn't i didn't do that um yeah delete lambdas you're no longer using delete everything you are no longer using in the cloud orphaned infrastructure is just uh very tasty to hackers it's probably being ignored and it's probably full of mistakes that you've made in the past don't use it minimize your dependencies and keep them up to date to avoid library vulnerabilities so we partner with cenotype and you know there are there are other tools out there that will really help you understand that i'm down to a minute here um

don't use the lambda execution environment to store user data or events this is this is what i was talking about where you can have cache data sitting around that uh or data in memory that uh lives across invocations which might be different users so don't do that stuff um yeah avoid executing shell scripts within lambdas if possible especially if handling user input definitely put them behind an api gateway and use the authentication mechanism in the api gateway uh and protect the apis with a waff are our recommendations and i'm just about out of time here so uh yep serverless security is deeply architectural but you still need to write secure code if you have code vulnerabilities then

i am well that's how they're going to get to the im i suppose but um yeah i'm just gonna pull we're out of time so i'm just gonna pull another couple out of here um we don't recommend putting lambdas in vpcs you know in in some in some cloud architectures vpcs are security benefit um the uh in lambdas that it actually opens an entire attack surface so so we don't recommend doing that unless you really need to um yeah i won't read these whole things out loud to you because we're running out of time we're out of time uh uh that's me um i've got a request for our youtube channel link i will send that