What the Function: A Deep Dive into Azure Function App Security

[Music]

but this is what the function a deep dive into Azure function app security we're going to be talking about the Azure function app service in the Azure Cloud couple of quick backgrounds here I'm Carl Fen currently a VP of research at netspy been at the company for 13 years now so I've seen lots of different things at the company I'm worn a lot of different but during that time uh been a pentester helped lead the cloud pentesting team ended up co-authoring a book penetration testing Azure for ethical hackers I also created the toolkit microburst for pen testing Azure environments so done a little bit of cloud stuff over the uh the last few years but uh yeah here's

Thomas all right thank you Carl um I'm Thomas Elling I'm a director at netspy and I uh Focus specifically on uh Azure cloud and Google Cloud security um and fun fact I was also a technical editor on Carl's book so um also contributed to Micro Burst a little bit as well so so before we get into our contributions to the research here want to take a second to highlight all of these other names on here now I know that's probably really hard to see in the back even up on those TVs over there but all of the folks that we have on the list here have contributed in some way shape or form to the research that we're going to be be

talking about today so if anybody's watching online uh we'll have the slides out available with the links available but definitely go check out the research of all of these other folks we'll try to point out specific research points as we go through the presentation of hey this is Andy's work or this is rosier's work or something like that but a lot of the stuff that we'll be referencing comes from these blog posts here along with some additional stuff that we've put together on our side so quick outline here of what we're going to cover we'll give everybody introduction to app services and function apps since not everybody here may have experience with Azure we'll give you an overview of how

those things work we'll explain how the storage accounts work to support function apps and explain some key decryption that Thomas will highlight here and we also have the VFS file apis and some vulnerabilities we identified around those to start things off we're going to explain what app services are so for those that are not familiar with app Azure Azure being the cloud platform from Microsoft they have application hosting as a service through the app Services service so you have an app service resource that gives you an azurewebsites.net domain name and you can host a website there if you want a really cheap Andor free way to host a website this is it like sign up for an

Azure account create an app Services app service plan on the free tier you get a free web server that can host whatever you want and you've got a domain name on azurewebsites.net you can put custom domains on there I find it one of the easiest ways to host a web server out on the internet really big fan of it only alternative to that being like storage accounts in Azure if you just need HTML that's super cheap that's even more free than the free tier on the app Services here uh but yeah really easy container-based way to host web applications up in the Azure Cloud they are somewhat vulnerable to subdomain takeover so if you have a

subdomain for a parent domain whatever we'll use Nets spy.com here uh if we had bides pdxp by.com pointing to an Azure app Services app and then we just deleted the resource and kind of forgot about the subdomain redirect somebody else could create that same app Services name call it besides px. azurewebsites.net and take over that subdomain redirect so that they could take over that subdomain from netspy this is kind of fixed we've seen it work in some situations I actually just saw this exact scenario work a week ago where somebody noted that there was a subdomain for one of our clients that was pointing to an expired resource for azurewebsites.net we fired up one of

those app Services apps in our own tenant and took over that subdomain got a full SSL CT and everything and had a client domain at our disposal so definitely keep an eye out for that uh if you're looking at subdomain takeover opportunities the app Services resource type also supports integrated authentication providers so things like inra ID authentication where your Microsoft account you authenticate to Microsoft they authenticate you to the web application here or other aoth providers your Google Apple Facebook whatever this authentication support actually resulted in a very interesting vulnerability that whiz reported a year and a half ago almost two years ago now called the B bang vulnerability they basically took over these search results

for Bing through an authentication provider on one of these app Services apps basically their off provider said yeah anybody with a Microsoft account can log in here and whiz found that login logged into the application and took over all of the Bing search results so you could take over front page results really interesting thing definitely go give that a read and look that up so with app Services you have a couple of different ways to manage the app Services applications you have a console which is the top screenshot here that's built directly into the portal with the right permissions you can just hop into that and execute commands in the container alternatively if you have

the right credentials or the right roles in Azure you have the kudu interface or the SCM interface which allows the exact same functionality but it also allows for things like file upload file download it's hosted on the sc. azurewebsites.net subdomain so that's why we call it the SCM interface sometimes or refer to it that way both of those are handy ways to get command execution in the containers so if you're ever pen testing a uh an app Services application really handy way to get things like environmental variables out of there if you have the right permissions to access that finally here uh it supports managed identities so managed identities are a concept within Azure where you have a resource

and it wants to be seen as a user in enter ID a managed identity would basically be the web server saying hey I'm this web server go ahead and give me access to these specific Azure resources you get tokens for that those tokens can be used elsewhere to then authenticate to Azure and act like the web server somewhere else so if you wanted to read a key Vault somewhere else you get the token you go somewhere else use the token to go read the key Vault so handy uh for an attacker but also as somebody building applications question human hum can masate as Services that's the one what is that humans masting as Services yeah so the the question about it was

humans masquerading and services yeah you can take the token and pretend to be the service basically outside of there uh with a little logging around it uh so it's kind of hard to track down uh and all of app Services is technically inclusive of function apps function apps are really just the API component of a web application built on app service services so if you just want to limit things down to I just want to host an API that takes Json input that's a function app really really easy to use to spin up your own apis I use function apps for all sorts of stuff if you just need a really light like lightweight API

to spin up function apps is what you want to go for uh the functions themselves underneath the function apps are stored under the API directory so if we created this HD HP Trigger 1 function that's going to be under SL API htpt Trigger 1 and we can see here that we have the code editor directly in the browser here that makes it really easy to edit your functions like I said anytime I need to spin up a lightweight API this is my go-to I can edit it in the browser it's facing up to the Internet super easy to use it does support both windows and Linux based containers for running your apis there's benefits to each of those and we'll talk

about some some differences in those later on and it also supports the console and kudu interfaces or the SCM interface for alternative management of the containers and like I said the editing in the portal is really really handy if you just want to throw some Powershell in a function to process Json coming in easiest way to set up an API and this also supports managed identities as well we often see them used to reach out to key vaults get secrets from the key Vault to bring into the function app for doing some kind of processing for authenticating to the function apps you can have just purely Anonymous wide openen apis available that's just the anonymous setting for

that but you can also have individual function level keys that are associated with the function you might want to put those in place to prevent some random person on the internet sending random garbage off to your apis it's a nice way to protect it and it's just a good base level authentication authorization schema there if you want to go another step further kind of higher up at the function level we have the resource level Keys including the master and default key the master key has full control over the function app it can do everything with function app you can overwrite files you can take over the containers effectively that master key is very sensitive you have to be very

careful with that because you can do all sorts of stuff with it the default key at the resource level is also sensitive because it allows you to make calls to any API functions underneath the function app so instead of just being able to call HTTP trigger one you can call any of the other apis as well with that resource level default key so technically like three different keys that you can think about with that and support for anonymous as well likewise this does support that integrated authentication so if somebody with a Microsoft account wanted to call those apis you can still do that same integrated off to call those apis as well and the service itself is actually

supported by a storage account something that you'll see with a lot of different Azure resources is Microsoft likes to build on Azure so you have function apps that are supported by storage accounts that run on containers that probably run in AKs I don't know maybe there's some other container service that's orchestrating that I don't really know but the important part here that we're going to highlight is that storage accounts support function apps all right so that brings us to a uh account key decryption so storage accounts are going to play a really important part of this so per Microsoft documentation and if you've ever played with function apps before um you know function apps require storage accounts

to some degree right so depending on your runtime stack depending on your operating system depending on you know the your deployment model you may use uh you know containers so blob storage or you could be using SMB file shares and depending on what you're using you know one or M of those are going to be used within uh that dedicated storage account that gets spun up for your function app right so in terms of what's actually in you know the storage accounts your container files or your blob storage that's where all of your web jobs data is going to be so this is really important metadata for the function app to actually work right so uh you can see

in the screenshot over here we have Azure web jobs hosts Azure web job Secrets those containers are going to be really important as we kind of move forward and start talking about key decryption because that's where your application and function keys are going to live so that those master keys the system level Keys the default kind of function level Keys all of those are going to be encrypted in a host. Json file and that lives in the container files in terms of your file share files that's where your application code and again your log files is going to live depending on your deployment model so if we're using just you know an asp.net or a Powershell core or a python uh you

know function app that's where you're going to see your files you know in your data directories your site www rout directories and things like that and your file share files there's are going those are going to be used by default in your consumption and premium plans and all of these configurations that we're talking about are going to be default configurations you can configure uh to actually save account keys outside of storage account and likewise for your application code you won't always need to have your uh your application code in SMB file shares but in default configs this is what you're going to see and then in terms of cues and tables you're really only going to see these with

certain trigger types um but we're really just going to focus on HTTP triggers for the sake of this discussion and that finally brings us to our key decryption overview right so like we said before your function app keys are going to be stored in kind of container blob storage in an encrypted format host. Json right access Keys as long as you have access to that host. Json file they can be decrypted within the function app container itself and offline which is pretty significant right this works with Windows and Linux on pretty much any runtime stack that we've tested um and decryption requires basically two things your first thing is access to the encryption key that's

going to be stored in an environment variable in the actual function app container so you need some sort of access to the container itself to retrieve that key right and then you know secondly you're going to need to actually have the encrypted key material from host. Json so you need read access to the containers and the files there right access is what you're going to need to the actual SMB file shares which we'll jump into in a bit later we did report this to msrc and this was confirmed to be expected and documented Behavior so in terms of permissions right the key takeway here and you know basically all these slides that we're going to be talking about afterwards

here is that these are permissions only for the dedicated storage account that's backing these function apps right you need zero permissions whatsoever to the function app or app Services itself to perform these exploits which is pretty crazy right because when we're talking about these managed services like function apps and things like that many people don't think about all the backing services that are actually available in your Azure environment that you then have to worry about right so now your security threat model is not only these managed services but all these other subservices that are being used by Azure as a part of that threat model and that security model that you're building right so kind of like a cross- service

privilege escalation so in terms of your read access to your containers you need to be able to read that Azure web job Secrets container list those files and specifically access the encrypted content in host. Json remember these are data plan operations that we're talking about management plan operations are not not going to be enough here so you need to be able to read those files themselves and then you're going to need to have right access to file shares and this is going to be used to actually create new functions upload your exploit code right and again a data plane operation so the way that you can actually get access read and write access you know there's a couple of ways

so in terms of rback roles and permissions storage account contributor is going to get you both of those things it'll get you read it'll get you that right access and the way that it does that Isa storage accounts list Keys action so if you're not familiar with this permission basically what it allows you to do is to actually list and use the shared access keys for a storage account right and that doesn't explicitly get you data plane operation permissions but the shared access key does allow you to do all of those things it's like your administrative level key so you're going to want to look out for custom roles that has list Keys action or specific data plane read and write

operations we kind of talked about storage key access and that's that list Keys action but don't forget about SAS tokens as well you know SAS tokens can be highly over permissioned sometimes so make sure to always double check your permissions um in your SAS tokens that you get access to all right so we've talked about storage accounts we've talked about you know what permissions you need now we're actually going to start attacking these storage accounts themselves to affect the function apps right so what we're going to do here is we're going to create a completely new function without function level ACC or function app access by uploading data uploading files to our dedicated storage accounts right

so uh Roger deckman has some really cool research on this where he attacks these storage accounts and a somewhat similar way um but what he's doing and what he's found is that you can actually back door a lot of existing functions just by modifying the file shares and the file share code to get access we're not going to talk about that so much but I do recommend you go and read his research there very cool stuff so what we're going to do um instead of backdooring things is we're going to create a new function so if you look inside your SMB file share you know in the screenshot over here we're going to go to site ww

root and then we're going to create a new directory we'll just call it new function or something like that right and within this directory we're going to create a PS core or Powershell uh function app HTTP trigger so we're going to upload run. PS1 which is going to contain all of our decryption code and things like that function. Json which is required by I think almost every function type and that's going to Define your authentication level so let's see right there if you can see that and in this screenshot it's set to Anonymous and then we have type HTTP trigger and then that also defines a few other more important things such as the methods

that are allowed and things like that and again what you're going to have to upload is going to be be dependent on your runtime stack and programming language so once you upload all of this stuff create the new directories put your code up there you're just going to wait for that new function to populate your mileage may vary here but we found that it takes maybe 5 to 10 minutes unless there is some sort of State changing operation that actually resets the function app then it will be almost synced pretty quickly all right so we talked about a bunch of stuff to kind of get us to the actual decryption so the way that this

decryption works on the back end is basically asp.net core data protection that is kind of the back end and the kind of core areas where all of this stuff happens and we're not going to dig into this too deep because this is a very complex area but what you need to know for the purposes of this is that Azure and specifically app services and function apps has a specific library that it's built upon asp.net core data protection called Azure web data protection and you can see some examples of code there where it's using the specific function Secrets um kind of protector to do these operations ation right um and this library is in fact actually used within the function app

container itself so if you go and look on GitHub this is all open source you can see where this code is actually being used here and you can see the actual specific Azure web data protection Library you can see that on GitHub right there so you can take a look at that link and funny enough um there was an msdn forums post and you can tell this is really old because we' got link stuck in there um where somebody was actually trying to do this many many years ago um this code no longer works right now so don't try it because function apps have changed but um The Core Concepts that this person was trying to achieve still hold true so

remember a few slides ago we talked about how you could decrypt these access Keys within the function app containers themselves and offline this is how you're going to do it within the function container itself so we're going to take that Azure web data protection Library put that into our actual run. PS1 code right and then at that point we're going to take our encrypt application or function keys whatever you're trying to decrypt from host. Json whether that be the Master Key System key whatever you want and then you're going to put that and hardcode that into your in you know your code that you're pushing up there you're going to add that new function folder push those code

files to that folder and then basically at this point you can just wait for those decryption keys to come back to you decryption will happen within the function container itself because it has access to the environment variables there's nothing stopping that code from getting access to those environment variables at that point and then at this point once you have everything decrypted you can send that decrypted key off to you know your burp collaborator server to another listening web server or just have it output directly within the HTTP response right so you can do this via your HTTP triggers or if you want to use a timer Trigger or something like that the type of trigger doesn't matter too

much here and then you know this is an example of where we actually able to get it to run and we have our master key stuck in burp collaboration there so but what if we wanted to do this completely offline we don't want to actually run it within the function app container itself right so the process is actually pretty much the same but instead of our code doing all the decryption in the container we just want to return the encryption keys to us right so if you go and look at that GitHub directory or that uh GitHub repository there's going to be two environment variables where the encryption keys are going to be stored and again depending on your OS and your

runtime you're usually going to have to look at Azure web encryption key or machine key decryption key those are where those are going to be stored right and you can kind of see that in one of these definition files up from on GitHub then you basically take that GitHub repository for the Azure web data protetion Library fire up your Visual Studio get everything running and there's an actual test case that I use to get this you know spun up really quickly um data protection provider tests. CS you basically replace all of the information and hardcode it in this code right here so we have just like our encrypted data we have everything there and where we're creating our function

Secrets protector and then we can basically do that all offline not on Azure not on the function app itself and then you can write your unprotected or you know decrypted results to a file and that's how you would get that to run there so we'll include some examples here um you know in this tool but uh yeah I can explain the tool here so to automate all of this because we don't want to have to do this by hand every single time we wrote a toolkit called funko pop that will allow you to select a subscription it utilizes the a Powershell modules to list out the available storage accounts so effectively you're going to scan for

storage accounts that might be vulnerable to function app takeover and it uses those a Powershell modules to look at the storage accounts look at the files within them you're going to need read and write access to those so scan with somebody with say contributor on the storage accounts or storage account contributor something with the right permissions to read and write on those storage accounts and then it will populate the list of storage accounts that you might want to attack when it does that it'll actually show you the name of the function app that you're trying to attack gives you a nice little out grid view that you can select the specific function app you want to attack

and what it does at that point it'll actually identify what operating system and what runtime it's utilizing so it tries to figure out okay is it a Linux container or Windows cuz there's a couple of different code branches we got to follow that way and then depending on the type of runtime be it Powershell Java node whatever we got a whole table on the next slide here uh it will it'll choose different kind of payloads for that specific uh runtime that we're utilizing so you pick the storage count that you want to attack and the specific function and it will upload the malicious code which will then uh return back the decryption key along with any managed identity tokens

if those are available so that's kind of Handy and uh it just it'll clean up all of the code after everything's done it helps if we just give you a demo of this because this will this will show a little bit easier here uh let's I think if you just click forward or the play okay so we can see that we are essay contributor here and we see that we have access to a couple of stor accounts if we go to the function apps we don't see any function apps we don't have any access to any function apps so as the storage account contributor we can go ahead and browse and see yep we have

storage account contributor here on the subscription so we have access to all of these different storage accounts some of which have function app stored in them and we run our code so invoke a function app takeover and we're doing device code off here to authenticate first which device code off is fun for fishing and probably a whole another talk to talk about but uh we're going to run the a function app takeover and it's going to ask us which subscription we want to select we're going to go against our research subscription here and we're taking a look at all of the storage accounts so it found what five different function apps within that one and we're going to pick now we'll go

Linux Powershell so we've selected our storage account and function to attack it's figuring out okay it's Powershell and I believe that it's Linux it's creating the new function with or new folder within the function executing it and we got back our encryption key the encrypted master key from the host. Json we got a management Vault or management token Vault token and graph token as well so uh to explain this a little bit uh Thomas already talked about the encryption key and the encryption master key here or encrypted Master here uh and we're going to put those into the Funko Pop app which is part of the toolkit you can spin that up in your own function app here and that

covers the decryption for you and hey we decrypted it but the management key Vault and graph tokens those are managed identity tokens scoped to those three different Scopes so management graph and vault which would allow you to access those different services and here we're just validating with another user that we in we got the correct master key out of that so I know that was a whole lot of stuff happening all at once one thing I was going to highlight here is that when we create these what we're doing is we're creating basically a folder that's named after a guid so nobody's going to Brute Force the name of the folder and on top of

that we actually write our own host. Json file to the container and we actually set our own key to use to call that so we set this completely random key to call the function so nobody else is going to get access to this function that we're maliciously uploading here so it's a safe way to run an exploit against this I guess kind of I don't know um but one thing that I don't know if you touched on did you touch about the encrypted true okay can we bounce back like here I got it so is it here yeah I don't know how clear it is but in the bottom right hand corner here on the host. Json you see

encrypted true and the value up here one of the other blogs that we have linked here they figured out that you could just set the encrypted defaults and set the value of the function app key to whatever you want so if you have storage account access to the function app storage account you can just set it to false and just set the key to whatever you want and then you have full master key access at that point doing basically the same thing with we're doing so we go a little bit more involved because we don't want to do major State change and like break existing function app keys that're there but you know it's handy okay so uh last a little bit about

the tool here uh we do support decryption of keys and managed ID token generation for everything but Java so if anybody's a Java programmer and wants to write a payload for us to put into Funko Pop just let us know and check out the repo neither of us really care to write the Java to do this so uh we don't see that many Java function apps either like we see all the other ones but that's the one run time we haven't tackled yet so there you go and we kind of talked about this uh as we were talking about the keys or the uh tokens that were returned uh now that we have these keys and

tokens what do we do well we can use those tokens to query things like the management rest apis Vault apis graph to dump out resources get access to key vaults potentially read things from uh enter ID anything like that or from graph and with function app Keys we can use those to back door existing code keep access to a function app uh if we want to persist access to the function app those keys don't get rolled that frequently or it's pretty rare for us to see that happen so this gives you persistent access there or if you just want to use the functions uh maybe it's a sensitive API that you're trying to call and it requires that function app

key you now have the key you can now call the function you already have access to the source code maybe that's a way that you get access to sensitive data that's in the function app all right so next up we're going to talk about part of function apps but it's kind of a left turn from everything we were talking about with storage accounts uh file access to the files that we're were just looking at in the storage account can actually be done through the Azure portal and up until about a year ago uh reader rolls all through any other higher privilege roles could read all of the files associated with the function app so this includes Bas level

kind of container files that we see up at the top these are things like uh requirements. psd1 here so Powershell requirements those kind of things there's a root level host. Json we did often times find sensitive data in those files as that reader roll but that wasn't enough for Microsoft to be like hey we got to restrict that readers shouldn't read that um likewise with the function app code itself which is kind of weird because reader can read code for things like automation accounts directly out of the automation account but now you can't read the code anymore as reader role for function app so you can't see what the function is actually doing anymore probably a good thing I

don't know if readers really need to see that but it's annoying as we often get reader level role when we start doing Azure assessments and we're curious to see what's in that function app code um so yeah anyways point is is from the port P this is what it looks like you can see there's file browsers at kind of both levels at the function level and the function app level and like I said disabled for the reader Ro but still definitely available for contributor and above and the apis that are used to pull those files into that web interface is what we call the VFS API this is what that URL looks like for the API in the

back end you don't really have to worry about like sub ID or Resource Group those kind of things the important thing is that the VFS slash so basically we're saying for the specific function app we want to use this VFS API and you see the double slash there that's the root directory and the question mark relative path equals one that just sets the relative path saying hey just look here in the function app ignore everything else that's the relative path that we want to use is just start in the function app well we can modify that you can actually change that to zero to show the root file system and it drops you to the root slash there just by changing

the one to a zero in the URL and with that for kind of every request that you make against this VFS API here I know the text is pretty small here but here we're going against asp.net data protection Keys etc etc uh if you just do it at the slash for each of the directories it does a directory listing for you so you can just browse all the files and go after those again this does require contributor level access however readers used to have access to this API so they could could potentially read all of these files and for Windows containers this kind of just resulted in access to the data protection keys so the keys that we

were using to decrypt for the windows side of things if you had read access on that host. Json you could then get access to the key here and decrypt those reader shouldn't be able to read that host. Json so not really a permission boundary issue here just more of a yeah they shouldn't have access to that key that was the initial thing that we found when trying to replicate this vulnerability for a coworker here at NFI I tried it against a Linux container not realizing it was a Linux container I thought I was replicating it for the windows thing and realized that oh you can actually just access the root of the Linux container and so much more so for

Linux containers they have the proc file system and for those that are not familiar with it proc is basically your processes that are running you can get a lot of different information about that so we can see here like proc uh slpr 59 here on the top one and that's for process ID 59 so if you go slash Environ for environmental variables that Returns the environmental variables so we can basically script this or use some kind of intercepting proxy something like that and iterate through all of the available process IDs get all of their environmental variables which include sensitive data like the encryption key on top of that they we have this thing called the container

start start Contex SAS URI which is a SAS tokened URL for a storage account lives off in Microsoft land that lives for a certain amount of time that contains a configuration for how that function app container is supposed to start up so it contains some sensitive information here we'll look at that in a minute but uh we now have access to the encryption key to decrypt that SAS URI and if we go next page here so with the encryption key and the data from that SAS URI we can see in the bottom right here we see encrypted context we grab that encrypted data we take the key in the IV the IV is being stored in the

encrypted context here throw it into something like cyers Chef here and do an AES decrypt because we have all the components to decrypt it with AES and now we have access to the storage account connection string which is the key to the storage account so if you only had access to the uh reader level role here you'd now have storage account keys to get into storage accounts on top of that it exposes the master secret as well as any function level secrets in this configuration if there's any integrated authentication providers like entry ID that exposed any of those Secrets uh all of those things are still available the next thing is not what also was returned

in this de en crypted configuration was an MSI specialization payload and this is kind of short for the managed identity configuration so if you had any managed identities associated with the function app the certificates for them were included in clear text here in that configuration that you have decrypted and that would include the pfx files in base 64 format for the managed identity and managed identities are never supposed to authenticate off of the resource that they're on uh that's just part of how managed identities work in Microsoft Azure is That's supposed to be that resource that resource is only supposed to authenticate as itself from itself and with access to these certificates we can then authenticate as

the managed identity somewhere else this applies for both system assigned managed identities as well as user assign managed identities they two kind of different concepts system assigned are tied to to that specific resource user assigned or a subscription level resource that can be shared against multiple different things either way you as user should never have access to those pfx files which were being returned here so what this did is this gave us an escalation from the reader role all the way up to getting full control over the function app along with getting certificates to act as the managed identity outside of the resource so pretty significant escalation up here uh along with that when you authenticate

with those pfx files off of the resource uh Microsoft never expects you to authenticate as that manage identity off of the resource so the logging just looks like you authenticated from the resource they don't capture any external IPS anything like that so very limited logging on that kind of thing um but yeah like I said this completely breaks the model for how managed identities are supposed to work and what do we got okay so uh from a remediation perspective here uh Microsoft is now encrypting the managed identity certificates they did not necessarily fix the apis so as a contributor like they fixed the reader level like reading of the VFS apis but as a contributor on a Linux container

you can still get all of the decryption working and get that SAS context decryption working but you get access to stuff you already have so things like the function app keys well that is logged in the activity log when you take the of listing the keys this doesn't do that so uh this is a potential kind of Bypass or kind of sneakier way to get to the function app keys but we also have the sneakier way of doing it by going through storage accounts as well so we have a couple of different options for getting the function app keys but yeah as a contributor you can still follow the same exploit uh it's still pretty

viable shouldn't really trigger any of those normal detections you might build up on that but if you do have access to a function app definitely take a look at Environmental variables there's some fun stuff that's there next all right and that brings us to the end here and we have just this basically a recommendation slide um you know of how you can kind of prevent some of these things right so least privilege and following that principle just do it everywhere in Azure you know get used to doing it everywhere right because even those things that you can't necessarily control that are kind of that the shared responsibility or shared fate sort of thing lease privilege will help you a

bit that right so that's you know thinking about things such as you know limiting those roles you know maybe not using owner if you don't absolutely need to and then limiting the scope at which you actually Grant those roles so looking at resource groups rather than your kind of subscription level Scopes um specifically for function apps you want to protect those storage accounts right so consider disabling access key authentication using entry ID authentication instead um disabling shared access key access Al together and thus disable SAS tokens if you don't need them and obviously don't store anything in clear Tex ever that really helps um and then limiting permission on those function app identities such that

if they are ever compromised you know that blast radius does get a little bit smaller right and then when we're talking about specific function apps and storage accounts and kind of like you can really apply this to any manage service out there you know it could be function apps it could be Lambda it could be you know Google Cloud composer or something like that all of these kind of share that uh you know usage of other Cloud resources to support that managed service right so you got to include that in your threat model when you're thinking about that from a security standpoint and for Azure specifically you know use dedicated resource groups those specific resources that are

dedicated to function apps don't reuse those right should only be used for function apps and then finally with logging make sure you have diagnostic logs enabled on both the function app and storage accounts so you can capture any of that activ that might be malicious right and we're talking about control plane and data plane logging for that and right here in the corner kind of small we have Microsoft's recommendations for everything so you can use key volts to actually store some of these materials that we're talking about such that even if you do get access to a storage account you then need access to a key Vault to go that next step further so that's a good mitigation for this vet

integration and making sure that it's not accessible from the public internet at all also a very good mitigation if that's something you want to consider and this is all of our msrc disclosure timelines so with all of these things we do talk to Microsoft and work on coordinated disclosure so you can see all the details and kind of the timelines here for each of these issues that we talked about and right before we leave here we wanted to do a special thanks to all of these researchers that we had in that first slide Roger has done a lot of great work Andy Robins a lot of great work everybody up here has done some really great research in terms of manage

identities function apps app services so please go and take a look at their work as well it's it's great right very good stuff one thing I forgot to mention yes so uh we do have links for the blog as well as the GitHub for Funko Pop here uh ronic and shog here they actually had a blog post that talked about logic apps so one other thing to think about with using the Funko Pop tool is logic apps that utilize the standard plan which is kind of the fancier Premium plan those are actually function apps they're function apps under the hood and you can actually Target those they have their own storage account associated with it

it gets spun up kind of in the side and you don't really realize it when you set up that standard plan Funko Pop and this whole attack thing can totally attack those logic apps as well and we really frequently see managed identities tied to those uh function or logic apps as well so that might be a viable attack thing meant to mention that earlier but saw their names up here and figured bring it up so yeah uh this is where you can find us if you have more questions or anything like that um yeah we'll be here and thank you all for coming to the

talk I guess any immediate questions here so the question was how do gcp and AWS do it better um I'll let you cover the gcp side sure yeah experience there I mean it's this is a really tough question because it it goes back to the way that these Cloud providers have kind of architected their manage models right so I've got a Blog coming out actually relatively soon about something that I found in uh Google Cloud composer um and the way that cloud composer Works um if you're not familiar with Google cloud or the the cloud composer manag service is it's basically AP pachy air flow under the hood and like Azure like AWS they actually use their GK managed products

and cloud storage buckets to actually back that service so I think you're going to know where I'm going to be going with this but basically a lot of cloud providers do share these exact same things the way that they approach and secure the manag services and those subservices that they use are all going to be a little bit different and they all make a little bit of different choices but again this what it really comes down to is that shared responsibility model is that they kind of put the responsibility on you to make sure you're securing all of these resources that are within your control right so I don't want to say somebody does it better than somebody else but

they all do it slightly differently yeah oh so the the question was around logic apps and how does that apply okay so specifically for logic apps if you're on that standard plan that spins up a function app with the storage account in the back end and all of those requests kind of get executed through that function app it's through a node.js container uh that was actually part of the reason we pushed to get the payload updated for node.js to work it actually didn't work all that well before but anyways with the standard plan uh you can do the exact same kind of attack where you're attacking the storage account uh it just gets a little

bit more complicated you treat it like a regular function app versus treating it like a logic app you could hypothetically go into the storage account modify the logic app code because there's I don't remember the specific do you remember I think it's in Json I don't remember I don't remember how that workbook actually works but you can actually modify that and back door those as well uh that was the blog post I was talking about with ronuk and shrug yep so the question was do the tips for function apps apply to logic apps in that same way yep 100% as long as you're protecting that storage account that's backing the function app uh that should

help protect you yeah uh so the question was uh is there is there monetary potential for hacking on some of this stuff yeah Microsoft does offer bug bounties for stuff that's submitted through msrc you can go consult their whole Bounty program thing but they have a pretty generous program yeah uh so Microsoft specifically partners with integrity at the moment to process their stuff but they take all of all of the input through msrc website yep so if you want to hack on this stuff uh definitely follow the Microsoft guidelines check out the msrc website they give you a lot more recommendations around that stuff and any other questions thanks very much yeah thank you all right

thanks again everybody [Music]

[Music]