Elevate Your SSRF Game: Weaponize Internal DNS Records To Expose Hidden Endpoints

yeah cool so I'm guy I'm guy razi um today I'm going to uh show you a research that I've conducted in Microsoft it essentially allowed me uncover uh a novel technique um that deals with ssrf exploitation and defense um and I will walk through um everything that we do and how we've done it and what are the mitigations that we're pro proposing for ssrf Etc so first of all uh about me I work in the Microsoft msrc uh vulnerability and mitigation uh research team we essentially take all the vulnerabilities in Microsoft try to assess them triage them validate them and propose the right mitigation um that has the most impact on Microsoft across all our all of our

products and uh features uh I've been also in the EDR uh um research team and other uh ability research group like Azure also former Palo Alto I've been passionate about security I think most of my life uh and is something that was always bounded in me I have a few other hobbies that are not security which are like CrossFit Bonsai and do other things that are not related um and let's start so everyone knows what ssrf is right we have some basic URL fetching endpoint that allows you to request uh a a resource from the server endpoint now it allows attackers and U finders and like researchers access internal network uh Resources by breaking parcels and accessing uh assets

that they shouldn't and like we we think that we've seen everything so we have so many payloads and uh uh utilities and tooling to leverage this srf and um everything that thing that are already safe right we have the proper mitigation for ssrf which can be application Level uh in terms of like blocking known uh internal IPS use proxy with URL rewriting from the external to try and avoid accessing all kind of uh internal uh uh paths or areas that we don't want the user to access um also have some Network segmentation um capabilities that are mainly around the host uh and all the VPC uh that blocks internal access uh to the sensitive host and lastly we also

have Waf rules that are blocking common payloads so we all we all probably most of us saw uh tons of GitHub repositories and um other documentation that explicitly mention most of the uh ssrf Primitives and how to break parcel uh around uh many features and Lang languages and interpreters and um like we all know them like we can block IPS to internal uh uh to internal resources block maybe even scheme ports or even go on the other side try to wh list specific subset of host and only allow accessing these type of um of Assets Now looking it from the perspective um side like the external perspective side once I communicate with the service externally

I go through a pipeline of many features and products and applications that do all kind of different things along the way so we start off with a firewall and then we go to a load balancer and wff and all each one of them like can strip headers add headers uh route and and change the path that we're accessing to anything that you can imagine that goes through this pipeline is all about trying and keep the organization or the customer end protected from the outside and which is fine and we all know things like Waf can block internal IP ranges all kind of known payloads restrict restrict protocols and in some cases which is not mentioned here but uh we

can also widel list common parameters of values within the W that will allow us to block uh ssrf essentially from this side perspective uh we also have IP tables so these IP tables can block a specific interface called from accessing internal resources but what about uh the loac interface the lopac interface essentially can access anything on the system uh because it's not coming from um um a perspective of an interface that is set sits on the line it sits locally on the host uh there are other things like proxy rewrite urls so if there are sensitive paths or sensitive locations that we don't want uh the user to access we can straight up and and and rewrite the the URL um that

they're trying to access and restrict restrict them by either redirecting it to a different one or just blocking the endpoint um and it can look like something like that we can also create an access rule on engine X that essentially everyone that access internal / internal uh Deni them but if they're coming from an internal asset or internal node you can you can allow it and this just shows us that things like that can be all uh through away uh all along the way to the pipeline and it's not just falling into one particular spot and there is also an application Level protection which essentially there are so many variations of that right because we can uh every developer and

every team and every um company implements their own litigations for ssrf uh really depends on the implementation of what the service actually does now in this case we're taking the origin which or comes from the host header and we're trying to check if the origin is actually something that comes from internally and if it does we can allow for this action to happen because at the end of the day there are other uh internal apis that communicate the same ones externally which they serve the same functionality but because we want them to provide and uh and communicate with service to service endpoints uh we kind of bypass this mitigation in order to not create a

different service for the same functionality so if you didn't get it right um external doesn't mean trust like we look at it in the sense of there are so many security uh applica security components like wa rules rewrite URL rewrite I tables region check and all these are being blocked from the outside perspective because they're only applied on the outside they never speak about what happened inside but what if the position medals more than the payload like what about a vulnerability that works the same that it works from the outside might work the differently from the inside and we're just defending from different aspects of the wrong vectors and we're relying on things that are more signature based and

not um Behavioral or at least uh fundamentally speaking about um the application uh security stack and just about to uh defend against something that we already know and the position matters more than we think and the idea is to understand that if a primitive can be accessed from the outside it might be accessed from the inside as well and this um this is pretty common I'm not I'm not trying to come up with something new but um ssrf Square essentially what my research is about is essentially gain an internal access position so we have one primitive which is coming from the outside world let's say some API endpoint and the second primitive is the same one that points to the same API

Endo but different security context so when we access from external resource we have some context of security and when we gain for the same one internally we have a different security context and different trust boundaries um one second so basically this is how it looks so we have an attacker or a Searcher whatever you want to name it accessing an external context uh so we have this external host sl/ fetch that gets a URL parameter this URL parameter will be then fed into the same primitive that points to the Local Host and then we can change this up because we're now in a different context security context we can chain it up with things that are

blocked from the outside to the inside so essentially if this target server or essential API end point is blocked from the outside we can chain the ssrf andun run them twice in order to find um targets that are blocked from the outside now our goal is mainly especially when we take down ssrf and try to break it down it's very easy to just fuzz your way out with all the payloads and try to understand like uh maybe I can just run all the ports and understand what's going on in the network but all along the way there are things that exist on the application Level and the same one that you already exploited uh that ESS

allows you to gain more instead of doing more because you already have some primitive that has more value than we think and I'm going to also show you a few cases so this CV um was rated for 8.8 uh it's a service group me service Microsoft 1 started with a semiblind uh primitive semiblind ssrf primitive and uh essentially I tried to access the local lost but for some reason doesn't matter what I did everything was getting blocked and then I really try to understand how can we discover more internal resources what does the service or the feature actually does in order to uh try and gain more with doing less and another thing that was there that uh there was a

heavy rate limiting um essentially blocking me for trying to spam All the known payloads and everything that I'm showing now is coming from a research and a lot of pain during the way uh and these are like the takeaways from it and along the way I try to find all the interesting indicators uh in order to leverage the attack as much as possible so I took the Primitive and I tried to access uh the same primitive on a different scheme and uh happily this different scheme forced the proxy to uh expose a sensitive header that um um expose an internal kubernetes uh DNS record and this DNS Cod pointed to the same primitive that was exposed from the

outside and I I just took the Primitive and I tried to figure out how can I use it uh just from internally and like it was a simple Google search or Bing if you want to call Bing um Bing search like I I wouldn't recommend on Bing but like Google is also good uh no person personal choice I'm sorry um so documentation are your friend like always try to read the manual instead of just trying to fuzz and once we had this set of primitive uh chained up we managed to access an ey Fram resource from internal which was the same primitive uh that was from the outside and you're probably asking yourself why do we even care um because there was a

specific API endpoint that obviously I cannot share most of the impact in the research here you probably understand why um but uh that allowed me uh getting into sensitive kubernetes API clusters by chaining the same primitive and you can call it like double ssrf in a way in order to bypass proxy rules that are applied externally that are obviously are not implemented internally and this allowed us access to something that was very sensitive and this needs to teach us about taking a primitive that we already own and try to gain the most out of it and the second one it was a bit more challenging it was another group me I think this was also maybe CVSs 9 uh

started with a blind ssrf like we couldn't really reach uh any assets and try to grab the uh the content of it but we did get some indication and during along the way of the research um it was very tough to understand what are the internal endpoints and what we can do about it and so I try to spam with ssrf canaries uh which you you probably know like CVS and other uh components that are vulnerable within the network uh as there there is no authentication and no other uh um things to defend and um all all this time I was like holding the answer but I didn't know that this was the answer and that's why I'm also

presenting it here um so I've did the same triak tried to fool uh the the the the API to to give me their uh internal DNS record which exposed uh a kubernetes DNS record and allowed me to essentially use the same primitive and accesses twice in order to fetch an endpoint that you will see in a minute that was completely blocked from the outside so you can see uh initially don't know if you can see my C no so initially on the in standpoint the first uh point we access the same the one primitive from the outside with a SL Gest and we gave it a URL this URL was the same primitive that is being

served from internally and we chained another one that goes to the attacker website or or the sensitive API end point that we want to access and the idea behind this is to try to less guess and less fuzzing and try to gain more um like from what we have and this taught me along the way about trust Zone zones so essentially we could just take uh most of our findings and just compromise on the impact uh but sometimes the security context changes everything so we might be thinking that one trust zone is the same one as with like the external one is the same one as within but context changes everything so it does also change the luck and the impact

of the of our finding so you can see in this um request I basically asked ask for the same endpoint which is/ pictures just internally and I validated this blind ssrf so I couldn't access um the endpoint um but what was interesting that when I tried to access an internal endpoint that wasn't exposed from the outside I did manage to get a hit so and this basically allowed me to do all kind of other things that uh made this CVSs 9 um but essentially these API end points weren't secured and they were being used by the same stance of externally as internally and this perspective changes the way or maybe our aspect that we look

on ssrf so I think that the main takeaway from this one it will essentially bringing your primitive into its Maximum Impact uh by finding more about itself so think about it an application has so many layers and so many uh internal apis that are not being exposed from the outside and this essentially allows you to do something that is a bit um different than the normal now this is another case study which I wouldn't say his product name or or feature for different reasons um so we started with uh an a simple ssrf primitive that essentially allowed me uh to access and any uh website that I want just externally and fetch the content for me now when I try to access the the

local host or other variations of lck interfaces everything was blocked so I couldn't access any of that and you can also see the response Down Still and um doing uh also a deep investigation of the Primitive it was very easy to just take this primitive and compromise on P3 or try just just try to fix it but the idea behind the research was to to show how we can take different indicator along the way and use them that are part of our design system and in this case there was a host header that essentially exposed um it was another proxy that essentially exposed the internal DNS record that allowed us to find the same primitive from the outside just just in

in the inside and um this gain us an internal access to a very sensitive API endpoint um that wasn't exposed from the outside and this is just one of many there are so many different headles and responses that could that contain uh um unique instrumentation and indication uh of things that happens from within like proxy headers and and other uh valuable components even it can be even in the content of the request and using this approach all our finding were elevated to at least P2 so minimum um um and it's also I think changed the way that msrc and Microsoft think about mitigation right now so every time that we're trying to deploy mitigation we're

just looking on it on the external side but what happen if we take the same thing and and assume that we're already compromised or already breached um what can we do about it and this led us to a thing that says like by Design doesn't mean that it's secur by Design or secure by default um and this perspective essentially um has offensive perspective and defensive perspective so from the offensive side try to look for self reference potential so there are many uh ssrf that we will simply uh track down and try to understand their potential by exploring out exploring out uh different sets of resources and environment variables that are not exposed from the outside but no one

actually checked the same primitive just from within and once you uh transition in the security context then it will be easier for you to understand what you can compromise because it's very dependent on what application actually um promotes or delivers right because if the application uh delivers um just user to service functionality that's one thing but if it also uh consider also implements service to service functionality then there might be a service that uses the same API end point but has a different security context and allows him to run allows the Primitive to run different um impact different um calls that are not allowed from the external and one primitive can be enough like sometimes we just try to spam and

fast our way and and and we always think about taking the big payload list and try to extract as many as good payloads or URLs from the same uh research that we have and try to think more in squares and not in line so take the same primitive and try to understand what you can do with it um more instead of trying to explore other uh components in the land from the defensive uh perspective try to think about trust Zone more um and when you propose mitigations so mitigations nowaday mostly directed from the outside and everyone focused on that but trust levels has a significant meaning especially after this research uh because we found out that um it

wasn't and I'm I'm not speaking about three cases that I've just shown we're talking about dozen of cases uh that have been generated using uh the same uh um approach uh just to different features and um we we didn't also have a way to monitor these contact switches so even if someone exploited uh the functionality we didn't have a way to monitor the second jump in the ssrf and even try to understand that it's a self- reference attack um and this is a key takeaway that even Microsoft with uh all the mitigation that we propos um it was hard for us to track it down and the last thing is don't assume that internal requests are safe internal requests um

can be doing anything possible Right by uh accessing internal other internal resources or by jumping into uh the same machine on different uh ports but also consider the same application uh when evaluating it so where does it lead us we think about existing mitigations every uh ihtp client uh um implementation that uh is being uh implemented is some API needs to be re um evaluated and understand what does this uh API Endo Expos to the outside and if what um uh happens if it if we access the same API points from the inside so when we're running a threat modeling normally we will try to evaluate it from the outside but we never think about it from the

inside because we don't assume that someone can access it from within right so try to think about how can you take that and mitigate it before someone else exploits it and it also um expose us to a new class of attack so basically maybe now it exist in ssrf but potentially it could be in all other different bu class and it's something that we should consider as someone that defends on sensitive product or for just our own products and um the last thing that I will mention is that um I don't think that there is nothing nowaday that can allow us to run context aware monitoring especially when the security context changes and I think that it's just

sometimes you don't need new vulnerabilities you need just need to think about the same one just twice um thank you

and we're up to questions so if anyone wants to ask anything feel

free yeah sure yeah sure [Music]

32 this

one oh [Music] yeahp questions that was it really that that youer that andary yeah so so you mean like what is the Primitive here yeah so the Primitive essentially uh assume that you have one API end point that exposes um you for an ssrf attack right and this ssrf attack essentially can be also triggered from the inside okay so if I chain my ssrf the first one the initial one which is the public one to the internal one I reach out from the internal API Point how does Point have to each statement I'm being from the outside this if I'm being from inside some so you mean how to defense around it no how possible that actually so

imagine that you have an API end point that you serve publicly right and then this API end point is EXP goes through proxies load balancers etc etc but this API endpoint can be accessed from the same host okay from within yeah so if we access it from the outside and the parameter that you're uh providing um to the Primitive from the external one is the inside one you can access the internal API endpoint if it makes sense yes but was there just statements somewhere in C code that was uh like causing different when from outside from inside no there is no there is no need to have any if because think about it um when you go

from the external uh stance all your heads like the the some heads are being stripped or being added like your origin host header and other um headers that indicate who you are but when you are calling the same endpoint once again these header are not are forwarded to the next request so then it means that it's coming from the um service within and not from the outside so think about it as thing like they they have no idea who runs this request because the in some cases the headers can come along the way even if you're running a few requests but it really depends on the implementation but at least from what we've seen um the heads are being

stripped on on the second one and in some cases um sometimes heads are being ingested as like super Global token admins or whatever uh that were added internally so it's all about the play with the proxy and the other components that are being exposed externally that's the whole play so mustn [Music]

HTTP yeah so imagine that you have like ihtp client Handler um and on some endpoint that is implemented that accept the URL parameter it takes the URL parameter and it loads it into the igtp client Handler now this whatever SL fetch endpoint still ex exposed and and can be fed from within so it's going to be the same ihcp client Handler just different headers different indications about who called it okay actually decided that internally I'm adding this like super user because sometimes you assume most of the time people assume that internal is trusted okay so there was there was statement that oh I'm not seeing any therefore I'm yeah in in some in some cases not

every not everywhere obviously but it can happen more than it doesn't happen externally for a reason but what I'm trying to say is that no one enforces those mitigations internally they expect all the other external components to do the work for them and keep everything inside secured take a look at Nat uh it's the same thing every we assume that the land is secured so we have less um authentication less mitigations and less things that that um are enforced from the outside like firewall woles or proxy does it answer on your question [Music] yeah good question so there is a tool we've developed uh that I obviously cannot disclose but um but essentially it picks all the

uh host names and the the internal DNS records from the responses and the request you can either in burp or zap we use burp um but yeah we we didn't find it uh manually just the last one was being done manually but the rest of them was being sent as alerts so yeah good question

[Music] you mean this one mhm so this is a very sensitive U Microsoft feature of service that you probably all know um that uh essentially blocked in any in every way our way to access internal host names but this header that was exposed by the proxy because it has to know who to return the call to was exposing the host name the the internal DNS record that ultimately wasn't mitigated when like in the on the code level or also on the proxy level when try to access [Music] it so I used it from the out from the externally so from the external I just use the Primitive I have that you can also reach out but this one was chained

to the second ssrf that was pointing internally which is this host if it makes sense yeah any questions if it if it doesn't relate to anything that was exposed during the research I'm happy to talk about um cool thank you very much