Exploiting SNI SSRF To Access The AWS IMDSv2 - Oliver Morton

hello everybody um thank you very much for coming my Talk's about exploiting TS SN ssrf to access the AWS imds version 2 everyone loves an acronym I am going to Define what all those are so um if you're lost already don't worry uh my name's Oliver um I was a penetration tester for several years testing internal external networks web applications whole bunch of other stuff uh once I even caused a bomb SC with a Raspberry Pi so my experience is fairly varied but it is all offensive focused uh I now work at appcheck on a vulnerability scanner so I'm doing offensive research and development so as I say I've got a very offensive uh mindset um mostly to do

with technology but not all uh a few disclaimers to start as I say sorry about all the acronyms um I will do my best to Define them as we go along sorry if I get tongue tied and I'm also sorry if imds is uh mixed up throughout the talk I may have got some of the letters the wrong way around throughout um I want to say I didn't discover Sni ssrf there's a great blog post by Alexi churin um on the invict blog uh which was December 2022 which was the first time I'd seen it so that was a few years ago now there's also been various thoughts at Defcon and black hat about exploiting the Sni field

for a variety of different vulnerabilities um but to my knowledge I am the only person person talking about using it to access the instance metadata Service uh version two in particular um if I'm wrong with that I'm sorry but hey here we are um I'm sure there's a variety of experience and knowledge bases in the room so I'll hope you all bear with me as I I build up to the the finale with the actual uh access to uh the metadata service I'm going to walk through each of the different parts of the vulnerability and talk about the underlying technology a little bit uh just so you got that understanding of how it all comes together at the end um

and all that's in an effort to not leave anybody behind cuz I like everyone to be able to learn rather than it flying over everybody's head so first off ssrf first acronym love it serice side request forer so this is one of the Earl's top 10 um I'm not going to Define that acronym you'll have to look that one up um it was added to the 2021 ear's top 10 so it's quite a prevalent vulnerability based on the survey of Industry the Crux of that vulnerability is that an attack can supply a URL to the application and then doesn't validate it before using it to make a request itself so that allows an attacker to send the messages to

resources they may otherwise not have access to which can cause information leak leakage or allow uh other vulnerabilities such as remote code execution or crossy scripting um and you can see in that diagram there example.com is our vulnerable application we've got that page parameter and within there we can specify a URL URI um to um make the application form a request to that destination that we've specified so you can see there it's connecting to uh the red server because we've told it to um so in all these examples example.com is our application and page is the notable parameter that first one about.php that might be intended and allowed that's just how that application works how that component Works however

if we haven't got sufficient validation of the inputs then we might be able to access other res sources so config.php for example and that might have credentials in it um or we might be able to access other sensitive information there um you could also access other resources that may or may not be interpreted so you might just get raw source code out or you may get uh PHP execution it depends on the scenario we might also be able to supply a full URL as in that second example which then uh makes the system connect out to a different application under our control and you might be able to use that to uh attack a different application and

I'm secure that you're the one doing it or you might be able to connect to a malicious application that you control which can then serve malicious resources so you can use this to get things like crossy scripting uh maybe code execution depending on exactly how things work um the other thing in in this area when we're connecting out the server the application might automatically add some authentication information or other useful headers so if we're monitoring uh the requests that we receive on our malicious server we might be able to extract credentials um I'll come on to a moment on how Windows helps with that um this kind of attack where we're getting the server to call out to our malicious

service is called an out of band attack I'm not going to dwell on that too much there's various Services you can use to help automate this bur collaborator and nuclei interact sh being two of the common ones or you can make your own with a little bit of scripting um another example we might be able to connect to local hosts so various services that are only running on the loot back address of the server we can't access them remotely at all we've got to be on the Box in order to access them because of that restriction they're often not as secure they might not require credentials at all um so then by bypassing that with the service side

request fory attack we can access more sensitive systems that we overw would not be able to and have not been properly secured under the assumption that if you're on loot back you're trusted some other examples for service C request forgery we can do things like UNCC paths so we're able to access Windows Network shares for example again depends on the system it's all scenario based you've got to go through all the permutations in order to find the vulnerability in the particular instance you're looking at uh Windows is very helpful about authenticating for you as kind of their single sign on type deal so um if you're running a particular web service I you can prompt for Windows

credentials and uh the client will helpfully send those on you capture net ntlm hash uh which you can then crack in order to recover the user's password assuming it's weak enough uh laurant gaffy made us tool called responder which can use for this it's mostly used for poisoning um Network messages uh net bios and LL M&R but you can just turn on the uh the module that captures credentials from a a web with web or network request uh in order to to get credentials that way so ssrf it's a well-known vulnerability it's very common and can be quite powerful so now that you've got a bit of a ground in serice side request forer and that concept of making a a

vulnerable server make a connection out to something you control let's quickly talk about TLS Sni so um TLS is the successor to SSL it's what's used to encrypt your HTTP traffic in your browser to make it https and you get that padlock or in Chrome now you don't they just they hide it away whether you're doing HT s or not but you used to get a padlock and everyone used to think that means you're secure um as you can see in that diagram on the left there's lots of messages that go into creating this connection you've got the TCP handshake at the start the TLs handshake after that and then the HTTP traffic in that

application data at the bottom and that application data is encrypted with the key created in the TLs session so that's great everyone loves encryption it means that no one along the path your traffic can read that data unless unless they got the keys um but the problem with that is some devices need to make decisions based on the application or server that you're trying to access um so in order to do that uh we've got to tell them what we're trying to access so the uh we can't use the host header in the HTTP request for this because as you can see it's at the bottom of the uh bottom of that flow diagram so it's not

accessible at the point when we're doing the TLs connection and making these uh routing decisions so um the server name indication Sni is an extension of the TLs standard which defines an unencrypted field on the client Hello message which is that second one on the left hand side uh and that contains the domain name of the server that the traffic is for this has been around since 2003 and it's widely supported in basically every web client click there we go um so our our client on the left wants to access blue. example.com uh but that has to pass through this proxy which facilitates access to multiple different servers so the client is going to send a request

for blue. example.com and in that client Hello message it's got blue. example.com in the Sni field unencrypted so anyone can read it if they can see your traffic um the intermediary device the proxy uh in this diagram is going to make a decision based on its configuration so it might respond with a serve Hello message containing a certificate that's valid for blue. example.com terminating the TLs connection there between uh the client and itself and then pass on that HTTP traffic to the backend blue server alternatively it might uh see blue. example.com and say I can't handle that I just need to stream that connection on and then it's the blue server which would then respond with a server Hello

message with its certificate so that decision needs to be made using the domain name so that's why the Sni field is unencrypted and accessible there have been some attempts to create an encrypted version of this field but they haven't had uptake as far as I've seen um yeah so Sni is generally transparent to the user it's just something that the client does for them you'll have been using it for years since 2003 uh Without Really noticing it unless you've been looking at your network traffic so since we're playing the role of a malicious user how do we manipulate the Sni field to do what we want it to do rather than what it's supposed to do and do by default it's

pretty easy with some simple Network commands there's a few different options available curl will helpfully send an Sni for us using the domain name in the URL so that final line htps arbitrary snit test. example.com it will send an Sni for that domain name automatically however we don't want to actually connect to to to that domain that we're um we're putting in the URL there that's our like attack payload we want to connect to our vulnerable service so we have to specify the IP address we're going to connect to with that resolve flag so what this does is just spef it bypasses the DNS look up and says when you see arbitrary snit test example.com for Port 443 connect to

this IP address instead um so it then helpfully connects and does the Sni for us uh you can also Supply the host header and you've got all the options that you normally would incur to set further requests uh if curl is too high level for you you've also got the option of using op SSL clients uh and in my opinion this is easier to to read and understand what's going on and see those differences because curl isn't um being helpful and making the decisions for you you can actually see explicitly what's going on so at the top we've got the HTTP request that we're going to send and then the connect section that's the Target that we're attacking and the

final server name is the Sni field so we can be explicit about what we're putting in there um and you can stream whatever you want in the HTTP connection uh if you like packet captures this is what that looks like in wi shark excuse my terrible editing because uh obviously I didn't connect to the documentation IP address uh the the top blue line shows the destination server um that we were connecting to and the second blue line is the Sni within the actual packet um wire shark has obviously helpfully passed this for us it's a great tool so so now let's put a bit of knowledge about the Sni field and ssrf together and start talking about Sni

ssrf and uh open proxies um the naming of this vulnerability is a little bit wishy-washy um I just went with what was already out there rather than trying to add more confusion so uh snrf or open proxy we're kind of talking about the same thing so the vulnerability comes about when the Sni proxy does not validate the server name is permitted and just uses it same as a normal SSR refundability um the that user input defines where the request is going in our example here the proxy is only expecting to get SN for blue red and green servers but if we specify a domain we control in the Sni field that vulnerable Sni server is

going to make a DNS request for our domain and then try and connect to it and then send the HTTP request since we control that domain and the server that we've specified we can monitor on there for the network traffic to our systems so that we can determine whether it's vulnerable or not we this is that out of band attack again you can see the DNS requests you can see the hdtp connection remember you might only see the HTTP connect sorry you might only see the DNS connection because they might be blocking HTTP outbound DNS is rarely blocked you can often just tunnel whatever you like over the DNS protocol because uh it's just proxied through uh

by different servers um yes I've mentioned B collaborate and interact already so alternatively we we don't need to uh connect to an external server we can connect to an internal service or the loot back address of the host um so the Sni proxy will connect in and uh provide us access to uh that service there is a fairly large limitation here in that we can't specify the port I'll come on to that in a moment so one more piece of groundwork before we uh start putting everything together properly what is the AWS instance metadata service and isn't accessing it with SSR F already well really well known and well talked about in multiple different talks so

instance metadata service provides access from an ec2 instance to the metadata which is used to configure and manage that running instance it's a HTTP API it's accessible on an IP version for link local address which is that 169 address at the bottom the Met dat includes the local IP address of the instance the image that was used to create it user data which can be scripts to configure that service which might have things like SSH keys or service credentials in it quite commonly it also has the instance profile which has the AWS API credentials in it excuse me so version one of the service uh has only one restriction you have to be able to communicate with it

so because it's using an IP version for link local address it's only direct accessible from the instance itself however that vulnerability serice side request forgery can meet that requirement because it's the application on the vulnerable server that's sending the request and it therefore has access to that link local address uh sorry about this name Andre Riano I believe Shone a light on this in 2013 so this issue has been known about for quite some time uh highly recommend the uh deeps and black hat talks there um which are a fantastic introduction to this as a concept uh in that talk they were demonstrating how to retrieve information from the uh metadata service including the user data setup scripts

API Keys com the instant profile and then abusing all of that um those instant permissions that we gain to escalate privileges to access other services within AWS so like other service side request forer and open proxy issues the Sni variant can also be used to access version one of the metadata service um in order to be exploitable there's got to be several require Ms in place uh both from the from the vulnerability that you've gained and from the Sni proxy itself first and foremost uh the Sni proxy has got to be using the Sni field uh without sufficient validation now remember it's not no validation it's not sufficient validation so um if they are checking

that it contains their top level domain for example um or if it starts with that domain you can usually do things like uh whatever domain they're looking for DOT your malicious domain and you bypass the check in that way because they're not making it anchored it's not got to end with the domain they trust um or it's just got to contain it in some way the other common one here is using regular Expressions to try and validate a domain name and forgetting that the dot in a domain name is a wild card is really really common so you've got all those same domain name based validation issues can also exist in this field so no not

no validation insufficient validation now according to the specification the Sni field is supposed to be a domain name it must be a domain name however in practice uh whether a non-domain name value is accepted or not is implementation specific and this might be implementation in your client or in the service however that doesn't really matter because we can uh just add a DNS record for whatever IP address we want uh aw. scrim hacker.com for example resolves to the uh instance metadata address which is what I'll be using in the demonstration shortly um the next requirement is the Sni proy has got to terminate the TLs connection the metadata service does not accept https connections it only accepts

plain text um and to that point as well the the proxy must be configured to pass on to Port 80 of the Upstream service because we cannot specify a port number the Sni field is the domain name the server name not a URL you can't specify the ports if anyone knows of or finds a way to specify a port for this kind of issue please let me know because I'd be very interested to hear it but I've not found one um and I've not seen one anywhere might be possible it might not um more research required so onto my first little demo this is accessing version one of the metadata Service uh so first off if I just

uh do a DNS request for uh AWS Grim hacker.com you can see there that we're resolving to the AWS IP

address oops typo everything so and then we're going to do a Cod request as I showed on the slides um we using aw. Grim hacker.com which for some reason isn't showing on the slides um to hit the metadata URL uh with that resolve flag so that we're actually hitting my vulnerable AWS instance which is uh live right now so if I just run that you can see we get back the um the the top level categories from the metadata API um which you might recognize if you've done this kind of thing before so the next stage uh with this kind of attack clear that again um you can access the security security credentials for the uh AWS

instance um which uh isn't showing particularly well on there but um hopefully it gives you an idea of what's going on let me just clear that off sorry so yeah we've got those instance credentials from version one of the metadata service this is the vulnerability that's was talked about in 2013 and was still quite prevalent for for many years um so this there's nothing new here nothing new there we're just using the Sni field as the entry point for our payload so let's go back so version one it's not enabled by default anymore as far as I can tell certainly not when I've been setting up fresh um accounts as a whole um version two has been available for nearly 5

years this November I believe and so that means that everyone has put in the effort to disable version one in all the environments that they've set up in the 10 years before version 2 was available right everyone spent lots of time doing that let's assume for the moment that that optimistic statement is true and talk about version two of the service version two was released in 2019 and it tries to address the security shortcomings of version one Eddie rest published a nice in-depth blog post about this and how it works and why they've done things um highly recommend having a read of that if you're working in this area so the major change um is the use

of session authentication instead of being able to send a request to the service directly you now need to retrieve a token first a put request is used to help prevent uh exploit via web application firewalls that have been misconfigured because the put request is rarely supported by wafs uh a HTTP request headit is required with the TTL um because that stops exploitation by vulnerabilities that don't allow you to specify request headers the token has a maximum lifetime of 6 hours so if it leaks into a log or anywhere else then it's invalidated fairly quickly and you can specify a shorter lifetime if you want um and even if that token is somehow leaked it can

only be used from the ec2 instance that started the session Additionally the IP packet with that token in that you're retrieving has a IP packet TTL of one which guards against open layer free firewalls and Nats because the response is dropped one hop after it leaves the metadata service so for example even an application running a Docker container on the ec2 instance can't get that response because it goes to the instance and then into the docker container that's too hot so it gets dropped and finally the metadata Service uh will not respond to any requests that have got the X4 for request header which guards against open uh reverse proxies which commonly have that header so we have all the same

requirements as before for this to be exploitable and then we also have the Sni proxy must be one hop from the Met service we must must have control of request headers the Sni proxy must not have the must not add the X forwarded for header and the Sni proxy must send the request to the same ec2 instance because if it's low balancing bouncing around between different instances then our token will not be valid so demo number two accessing version two of the service so if I just this is on a a different server within AWS um which has version one of the metadata service disabled so you can see there we got four one response if we

send the request that we did previously so that's not a problem because with the Sni uh exploit uh in this particular configuration the request is being sent on in its entirety so we can do a put request we can specify headers none of that's a problem so uh this kill command is going to uh request the token and put it into an environment variable for me and then just Echo it out so that we can see it and you can see there this is the access token which is valid for uh 10 minutes which which means I need to get a move on but that's fine cuz I'm running out of time um so now that we have access to

a token we can send that previous request again using the token you can just see it's in the header there and we've now got access to the catch giz again so again taking that the next step we can access the uh security credentials for the instance using that token because we're just sending the request we're just using the service as it's intended to be used except it's Vira vulnerable proxy um so next we actually want to make use of those credentials for something so if we request a credentials I'm passing through my simple python script which just formats them as required oh no live demos why are you doing this to me I'm in the wrong

directory uh documents personal besides demo clear there we go which will format my uh my output as required so we've got the ads access KY ID secret token and session token uh which is obviously just massive uh and then we can actually make use of that using the AWS CLI so we no longer need to be um accessing Services via the ec2 instance we can make use of those instant credentials from our machine like outside of AWS so this is the official Docker container for uh the AWS CLI um and I'm passing in those credentials that I've just written into a file which I extracted from the ec2 instance and then I'm going to call the

STS service um in order to just get information about myself so we should now see there we go so we can see that um uh the role I have my user ID so on my machine I am acting as if I have the permissions of the ec2 instance um I'm not going to go into detail about how to escalate privileges within AWS because it's it varies it's very situation dependent and uh to be honest it's not my area there are plenty of talks about the fun you can have in AWS once we start getting security tokens like this so highly recommend looking into that this is just one more way of finding um those credentials that first bit of

information so how do we mitigate this the um Sni field it's a piece of user input like any other you might not consider it usually because it's automatically handled it's just transparent but it is a piece of user input it can be manipulated by an attacker so if you're going to use that value make sure you validate it make sure it's what you're expecting um or restricted to things that you allow so if you need to allow multiple subdomains make sure you're correctly validating the parent domain within that field disabled version one of the metadata service this is a little bit easier than it sounds because you've got to update any code that you have that's using the

metadata service to support version two you got to be able to send that put request with the header and then use the token you VI en Harden your ads configuration so that if you do um get exploited in some way like this or The Talk this morning where secrets are leaked in some other way um you can restrict the damage by hardening configuration as much possible defense in depth lease privilege all that good stuff again plenty of guides on how to do that and it does change quite regularly because adws are constantly changing things um so you've got to keep on top of that as well final thoughts around this um in the last year I've

seen around a 100 vulnerable Sni proxies so this is fairly rare but it's not zero however I'm sorry to say that I've not seen any vulnerable Sni proxies that allow access to the Amazon Instant metadata service however there's a definite sampling bias there because it's the things that have been scanned with the plug-in that I wrote so uh it doesn't mean it's not out there it just means I personally haven't found it so um another thing to look out for and it's an interesting one in my opinion so if you do find that tweet me um or masteron or or whatever I'd love to hear about it or email me if you want um so when attacking or defending systems

it's important to learn about the underpinning Technologies in this case we've got the IP protocol TLS Sni the ads instant metadata service and Sni proerties all coming together to allow this vulnerability to happen you know it's a specific scenario but there's lots involved in it and you wouldn't have a clue if you didn't know um about these underlying Technologies how they work and how they can be abused so don't just uh be satisfied with surface level information actually take the time to understand how things work not how people think they work or just accept that they do take the time to understand properly um this allows you to find the weak points in how systems are

integrated or how Technologies are used which can then lead to finding the really interesting vulnerabilities oh look about that just about on time thank you very much for listening um if anyone's got any questions we're out of time now but just grab me I'm fairly visible in the fluorescent orange shirt um on socials if you like and thank you very much for listening he