EmailShell: A War Story On Leveraging Server Side Template Injection (SSTI) To Hack Into GCP

Um, cool. Thank you. Yeah, let's get it started. So, it's a talk uh titled email show. It's a story on how we leverage an injection vulnerability to get remote code execution and then lifted some access token of a service account in GCP to get into the GCP environment. Uh, so a bit about me. Uh, my name is Phillip. Um, I'm an ads consultant at Jumpstack. We do red teams, purple teams, that sort of stuff. and I've been in pentesting for about three years now. And a bit of background about the vulnerability about the talk, it's an SSTI vulnerability. So serverside template injection uh discovered in a client web application. So it was on an actual

test. Often most of the times they lead to remote code execution. There's some edge cases where it doesn't, but in most cases you probably be able to exploit it to get an RC. Uh and then nowadays the likelihood is that when you exploit an IC you'll end up on some sort of cloud box whether it's an EC2 or some sort of GCP um VM or an Azure V Azure VD. Uh so from there you can hit the metadata endpoint and get some access token for either the service principle service account depending on which um client environment you're in. Um and then client got notified and then issue got fixed. Everyone is happy. uh everyone but the devs who have to work

until 7 p.m. on a Friday. Um so bit of a background template engines. So template engines I think most of the languages have them. So Python has Ginger 2 and I think a couple other ones. Uh PHP has Twig and Smarty a couple other ones. Again most of them need to some sort of RC if exploited. And yeah there's a couple other ones like even JavaScript has one but these are some of the most popular one. Um, they basically just like it says, they dynamically generate text based on the content by combining static templates with dynamic data. A lot of words, but I'll explain what that means in a second. There's some benefits to them. They keep the presentation

level, so HTML, CSS, JavaScript separate from like the backend languages like PHP, Python, uh, and so on. I think there's some other benefits like not reuse being able to reuse the same code across the codebase and stuff like that. Uh, but that doesn't interest us today. Um, so how does it work? Let's say you have a account. You register with an account called Jumpse. You set up your password. You loging in with your account. Uh, and then the website might greet you saying hello Jumpse or hello Alice, hello Bob based on whatever username they provided. Sometimes it would be like backend logic, but sometimes it'll be template engines rendering that sort of stuff. Just depends on uh, you know, how someone

coded it. Uh, that's basically I think most of how it works. And uh, yeah. So like I said, serverside template injection is when you inject into the template engine. Uh very often they lead to RC's uh mainly because they allow access to um native code execution capabilities. Uh you will need to identify the correct template engine, but you can um find your favorite payloads and hack tricks or anything like that. Mostly they'll be similar. So some sort of curly bracket payload with some mathematical equation and we'll we'll get on to why in a second. uh you may not be able to access the exploitation like code execution capabilities directly. So if it's like PHP and it's Twig uh you won't be able

to pass PHP native functions like pass through or something or system uh you might need to do some tricks with like twig filters or in ginger you might have to walk the code backwards a bit uh to access some of the classes that allow you to exploit remote code executions. Um, if you guys have ever done any CTFs, then the likelihood is you've probably played around with some SSDI. [sighs and gasps] Um, so this is I think the easiest twig example. So we pass a payload into twig using twig filters such as map uh and join. So what it looks like right now is like you have this payload called cut etc pass which is just going to output

the output of a local file and it's going to what map is going to do is map is going to pass everything before the pipe into pass through. So when it renders it server side and it passes it to PHP to execute let's say uh is like you see uh in the arrow at the bottom you will have a password command that's executing the command you passed it to you can pass in multiple commands so if you look below the text there's like cat etc password a comma id so you can execute multiple commands sort of in one command when you passing it to twig and yeah like it says twig will then compile the payload into PHP executable code it

doesn't look exactly like it's shown on like password cut etc password it will look a bit different uh but essentially that's what is being given to PHP at the end of it and then this is executed by the PHP server and hopefully we get some sort of code execution and we're all happy um so this is a safe example let's say you put this payload so this is a twig specific payload I think for other engines like Ginger or any other ones it might differ slightly so you might use one curly bracket no curly brackets or you know angle brackets it really depends uh here when we pass it, it doesn't evaluate it at all. It looks

like the code is uh or the user input is being escaped properly and you just get this weird mathematical equation. And the reason why you usually use mathematical equations because it's quick, it's simple and template engines often support just evaluating arithmetic operations. So if you pass it 7 * 7 and it's exploitable, it will come back with 49 and then uh you know something's up. So like here when you set a username with 7 * 7 uh if it comes back with 49 it means something in the back end is evaluating this arithmetic uh equation or operation whatever you want to call it and the likelihood is it's some sort of template engine. Uh well the easiest way to prevent it uh

to be short like any other injection vulnerability really uh just escape user input properly valid validate and sanitize it uh never let users create or control templates because then it's very hard this is what was happening in this one. So they were directly allowing users to create um templates to send off some emails and stuff like that. So it was a valid functionality but uh yeah in that case when you let the user control everything in the template it becomes very hard to stop it. And some template engines have uh sandboxing. So Twig has sandboxing. And basically what it will do, it will restrict what code the templates can run. So you might block some filters or some functions. Uh so

you won't be able to do it or it'll be harder to do it. There's a possibility that the de developers omitted something, right? So uh they've left like an exploitable function that they shouldn't have left. So um [clears throat] I would say probably this is the weakest of them all. Uh I mean like with any injection vulnerability, the the key to fix it is to just escape user input properly and sanitize it. So this was the client application. Uh well sort of we had to um edit out all the data. So um you guys can't identify them. Um so this is what it looked like. You're able to draft like a message to send to an email. Uh and the key thing

was it's you know it's somewhere along the website didn't mention the word twig. And if you guys have ever done any CTS, if it comes up with twig or ginger or anything like that, uh you should always try any service injection vulnerab you should probably try any user input just in case you know it doesn't explicitly say anything. Uh usually you'll be able to identify the backend language easily. So if it's using PHP, you probably want to only use Twig payloads and smarty payloads and whatever other uh template engines PHP supports. Uh so yeah immediately started testing for uh SSTI injection um by using the common payloads like 7* 7. I actually tested this like a Thursday evening. Uh

didn't have anything come back and then I checked my spam the day later in the morning and I had this sitting in my spam this 4949 and I was like um okay I don't remember sending that and then it you know became clear to me uh this is probably from the web application testing from yesterday. Uh so the next step you know you want to push some impact always I mean if you get an SSTR code execution it's always bad but you know just to show the client uh you always want to get some impact on you know getting actual code execution on the server or outputting some files or you know anything. Uh so I was actually having some

troubles with exploiting it. Uh but there is this cool research by a guy called Alex Bruins. He uh basically did a research where he tried to find um payloads for multiple template engine languages. So Twig, I think he did Smarty, Ginger and a couple other ones. Uh maybe some for Ruby as well. Uh but basically it's like a polyglot excss payload sort of thing. So this should work in every environment even if it's super restrictive. If the restriction stuff like uh not allowing you to do quotation marks or anything like that, uh this should be guaranteed to like almost always work. obviously assuming that the website is vulnerable. Uh pretty cool research. If you guys want

to look at it later, I'd recommend. Uh he seems like he put in a lot work into it. Um but basically all it is, it's still uses some like smart filtering in twig, some like native twig capabilities to to bypass like some filters or just to you know um make it so once it's rendered it goes to the payload we had earlier. So, cat etc password map password and join and then when it goes to PHP ends up with pass through cat etc password so you can get your code execution right. Uh pretty simple but the payload looks horrible so he must have spent a lot of time on it. Uh so nothing really works for me. I don't

know if there was some defense defenses on the client side like you know escaping quotation marks or anything like that. U didn't really look into the source code. We don't get any look into that even when we exploit stuff. Uh I mean maybe we could have but uh I didn't. Uh so tried this payload and this payload ended up working. So vouching for this payload. I sent the email and um yeah got an email just output in the uh etc password file right to my email and the name email shell. Uh so I was right okay well the next step is to have the you know uh thing reach out to our server just um so we can uh

play around it play around with it more. Um so we have a drumstick control server. If you guys work for any companies you probably have a server somewhere facing publicly uh whether it's like a cloud box or anything uh that you can you know listen for stuff like reverse shells or you can do any testing from it. So got onto a jump control server open up an NC listener so we can you know get back uh a shell from the payload we're doing. Again a lot of troubles actually getting it to execute. If you guys uh you know if you guys get a lot of shells on like web applications sometimes it's just a pain to get get it

to act with like amperand and like angle brackets when you need to redirect the uh payload somewhere. So we B 64 encoded it then B 64 decoded it right in the command and then passed it to Bash so it executes. Uh happy days. Yeah got a uh got a shell back to our server. Yeah you know we were able to run some commands ID host name. really impactful. I didn't want to mess around with this on the 3 p.m. on a Friday. Uh so just you know uh outputed some basic commands just so I can show the client that look uh we have access to your server. We can run commands from there. We can do whatever you know. I

think this one was we were the docker container. So the next steps would be docker breakout and then priv to root. Um for those who don't know uh when you get code execution depending on your privileges it's pretty uncommon that you get like root privileges nowadays from code execution uh unless there's some like pretty serious vulnerability of the server. So you can't really fully control the server but you can probably exfiltrate some data and try to prove so you can you know have access to whatever data sits on there if the database sits on the server as well uh which is again pretty uncommon nowadays then you can get access to the database like more

data pro some more impact uh but yeah one last thing like I said uh nowadays uh there's a high chance that you'll be on some sort of cloud box when you get a code execution a lot of clients nowadays toast web apps on either AWS EC2s um you know some GCP VMs or some uh Azure VMs like Azure VDs and there is an internal metadata endpoint uh it's used for like just quering for uh whatever like service principle or whatever identity is tied to the VM it's uh used for getting information like um you know whatever like the lifetime whatever but uh the one useful thing about it useful to us and useful in some

cloud usage cases as well it's one of the endpoint producers are shortlived access token which grants you access into the cloud environment. I think usually they last sort of from 15 minutes to an hour but if you have code ex the box you can always regenerate them when they run out. Um so yeah this is a case with GCP like you can see here but this was the case with AWS and Azure. The detections for this are pretty poor. I think we've had one client in the past that could have detected us doing this on an AWS EC2 but I've never really seen anything anywhere. uh that the text is um but yeah so we got access into the we got

the access token and then from with the access token you can just simply set it up and get access into the GCP environment. Uh we didn't go there because usually these uh are bound by scope of engagement and you shouldn't really go outside of the scope of the web app. Uh I would really love to but I don't think the client will be too happy at 3 p.m. on a Friday again. So just left it there. Drop them a message. Do you want me to? And they're like no. Uh okay. Um so yeah, I mean as as the case with all of these, you know, you should always let the client know ASAP is a

critical vulnerability, so they would like to fix it. Uh especially if everyone wants to go and have a weekend so the devs are not too angry at you. Um so yeah, send them a pretty long message. You know, usually want to use some sort of secure channel to send them the actual steps of the exploit and how it happened, what the fixes are and how to prevent this. So just send them like this short uh summary over Slack and then send them another message of the actual exploit over something like Sense Safety or uh you know anything else. Um so that was it. The only reference is the guy who made the horrible payload. So shout out to him and uh yeah that's

it. Thank you. [applause]