Hacking Google Cloud Projects | Bug Bounty Explained transcript

Cloud tools are honestly super convenient and I use them a lot myself. Big companies use them a lot as well when they need to make applications, they need to integrate databases, or they just need to have some like AI integration. These cloud tools are very convenient for them and pretty much every company out there uses some form of cloud tools. This makes it a super good target for us as bug bounty hunters because every single target is going to be potentially vulnerable to this kind of attack.

So, in this video I'm going to be looking at Google Cloud product, which is the cloud product developed by Google and it's a super good avenue research at the moment. I'm actually kind of developing it myself, so I'm kind of new to it at the moment, but I wanted to share my progress with you guys and show you kind of what I've discovered about Google Cloud and the types of misconfigurations that can occur here. So, for like 99% of targets, there's basically going to be two available cloud tools.

There's just obviously more, but this is just what I've seen across bug bounty programs. There's AWS, which are the cloud tools developed by Amazon. It's Amazon Web Services and it's actually by far the more popular cloud tool. Across like bug bounty programs that I've been hacking on, I've seen only a few that use the competitor, which is called Google Cloud product. And this is obviously developed by Google. So, Amazon, Google control like most of the market share for these kind of cloud tools and there's a number of key differences although they kind of do the same thing.

They work quite differently, especially in terms of resources. So, these cloud tools are absolutely huge. So, they have a huge range of products from these API gateways, load balancers, authentication services, reverse proxy. They do like literally anything, which is why they're so good because you can have one platform and you can do anything on it. And most of the services are going to be publicly reachable from a URL.

So, a lot of them are going to be just HTTPS URLs you can visit online. And this is mainly where the misconfiguration is going to be that we're going to be looking at is when some of these services are reachable and they're misconfigured and they're available publicly online, we attackers can find them and exploit them. So, the harder part is actually going to be finding them, which is what we're going to delve into.

And the differences here between AWS and Google Cloud product is that finding them is, you know, going to be a different journey on both. That's because resources are kind of key differently between these platforms. So, on AWS, the keys are mostly going to be created through random values. So, that you can think these kind of UUID values. And on AWS, they call these like ARNs. I think that's just like resource number or whatever.

Amazon resource number, I imagine that's what that stands for. But, enumerating it is pretty [snorts] hard. Almost every service generates its own kind of UUID. There's almost no way to guess it. Although, there are a lot of, you know, enumeration oracles that are developed by the community, but they are actively patched out quite often as well. So, AWS resources are kind of hard to just enumerate ourselves. And that's why a lot of the AWS stuff is going to be centered around trying to leak this information, trying to find those oracles, or finding a misconfiguration where the service itself actually provides us these IDs.

But, for Google Cloud product, it actually works very differently. Instead of random values being often used for the resource keys, a lot of the time it's a derived value from either the project ID or the number. And this is important because the project ID is essentially like user set. It's a value that a user will give to Google Cloud that they want their project to be called. The number isn't, I'll talk about that in a minute, but for now let's talk about the project ID.

It's set by the user and that usually always means that it's quite guessable. Just because users are normally going to give names they can remember and relate with. Let's say you're hacking on Stripe. If Stripe used Google Cloud product, they probably called their project like Stripe applications or something. They'd call it, you know, something that would differentiate it as being from Stripe and would also kind of give the general function of what the project is for.

It's just a natural way to name things. And that means that we are going to be able to use AI to enumerate it, which is phenomenal. The number is different. The number is something that we can't enumerate. The number is set by Google and it's an iterative number. So, it's just like, you know, a random number that goes up. So, it's pretty hard to get that number. And from the project ID, I haven't found an easy way to translate that into the number because Google doesn't want you to do that because they're kind of been trying to patch this stuff out as well.

But for now, we're going to focus on the project ID and having a number would be nice, but I haven't really found a way to leak that yet. And what do I mean by the resources being keyed by the project ID? Well, these are going to just be URLs, right? Standard HTTPS URLs that we can visit. And this is kind of the structure of the domain that Google will give you. So, for these various Google Cloud project services, this is how Google will construct the default URL for you.

Let's take App Spot for example here, this one. So, when you have this project ID here, you can see project ID, the App Spot URL will just be the default domain. So, if we know the project ID, we can check if you have an App Spot um App Spot service enabled. And usually there'll be some like service name or whatever at the end here, but that's again all something that we can enumerate. Same thing with Firebase here. You can see Firebase right here.

You can see it's keyed basically exactly on the project ID. So, if we can get the project ID of the company, we can get the Firebase service. And you can see this is uh Google Cloud Run. This is for hosting applications. Now, this is keyed on the project number. So, this is harder to get. It's not impossible to get this, but it's going to require more work than getting the project ID. And it's also keyed by various services.

Now, this is going to be used a decent bit, this Run app, because Cloud Run is actually quite a used application and it's going to be very good for the types of attacks that I'm going to demonstrate and it's actually going to part of the example that I show in this video. And it's a worthwhile one to get. So, the project number is quite nice if you can get it. It can then unlock a lot of different things, but I just don't really know how to do it at the moment.

So, I'm going to be doing more research on that, but I'm going to show you the project ID side of it in this video. And this is basically the main attack scenario that I've kind of devised for these Google Cloud projects. So, we want to first discover this project ID and the number. I'll show you how we're to reliably discover the ID and I'm just going to basically show you how the number could get leaked by the application.

Then we want to map out the Google Cloud product stack. So, we want to basically kind of just build a tool that can run through every single one of these potential URLs and just check what we know exists and check what is accessible, etc., etc. And then we want to basically start attacking the kind of services that they have enabled. So, I've kind of split this into two categories. One of them is attacking these public resources.

So, this is basically when a company will create a resource and they set it to public. So, say they create a Firebase database and they enable anyone to access it. This is obviously great if you find it, but for mature targets, like say Stripe again, if you're hacking on Stripe, then I would say that they're probably not likely to do this just because Google Cloud pen testing is, you know, pretty developed at this point.

Google provides their own tools to check what people can access and such. So, it's not that common that I would be able to see just something leaving it like completely open. However, you know, if you do find it, that's great. The second, and in my opinion more likely scenario, is that you end up finding a legacy application. For example, on like this um Google Cloud Run endpoint, you're able to access it, and you find a vulnerability on that application that allows you to escalate to basically do the service account takeover or getting some sensitive data.

That's I think the most likely scenario for attacking this Google Cloud project. And the important thing is, in a lot of these applications, like Google Cloud Run, you know, the App Spot or whatever, the service account token is often available at the metadata or some kind of adjacent endpoint, or just just a way to basically get it. And this is nice. So, for example, if you find a Google Cloud Run application, and you're able to find an SSRF where you can forward the header for Google, you need to have that like X-Metadata Flavor Google header.

If you can find that, then you will always be able to reach that metadata, always. There's actually no way to disable it at all. So, that's something really nice to know is that an SSRF on this type of application will always result in being able to take over the service account. So, that's very nice. Okay, I think I've shown you that, and we're going to hop into the live example where I show where I'm going to get the project ID from, and where I can going to basically potentially get the project number from, and then I'm going to enumerate the Google Cloud stack of my sample project, and then show you some of the vulnerable applications that could potentially be reachable.

So, this is the sample lab I'm going to be using today. Now, it's currently available, but I'm not sure if I'm going to keep it available because this involves leaking the service account tokens, which is not ideal because some of them are quite overpowered by default. And I'm going to check if I can disable some of them, but if not, I might not be able to publish this lab. If it is available, it will be available in the description, so you can click on it or whatever.

But, for now, you can just follow me. If it's available, then, you know, pause the video and go do it, but if it's not, then just listen to me here. All right, so this is a extremely simple file upload application, and it's going to be integrating with Google Cloud Platform. So, we're going to go ahead and choose a file that you want to upload. So, we've chosen a file that we want to upload, and, you know, we upload it, whatever, and it gets uploaded.

That's pretty cool, and let's see how it works for real. So, we're going to go here. We're going to go into the HTTP history section, and we're going to check it out right here. As you can see, the three requests that were sent in. The first is a post request, and I'm going to save all of these in the repeater just so you can actually see them properly. Okay, there you go. There's all our three projects. If you see them well, yeah.

And this is basically how the flow goes. So, we click on the, you know, index.php URL, we get taken to a HTML back end, and then we can send a post request. And when we send that post request, we get back a pre-signed URL for a Google Cloud Storage bucket. This is the most common pattern you will almost ever see on the internet at this point is you can just get a pre-signed URL and upload to a bucket. Very cool. That's basically the number one way to use cloud services, so I'm pretty sure you're going to see this on almost every application at this point.

So, you're going to get a Google Cloud Storage bucket here. The next part is that our The will take that URL, and it's going to send a preflight CORS check, which is boring. Anyway, after that, it's going to upload the file, and then it's going to be on the Cloud Bucket server. You can just send it in, and you'll see Okay, apparently it's forbidden phenomenal. Well, anyway, it would go in and upload it, right? But, this is the interesting part.

This is the part where we can actually infer the project ID. If you look at this pre-signed URL very closely, you'll see that there's a service account embedded in it. So, this particular header here, X-Google-Credentials, and then after it, you can see the service account. And what it looks like is actually an email, but this encoded percentage 40 is like an at symbol. And you can see the service account is called PHP upload service account, and the second part is this jacobjl vulnproject iamthegoogleserviceaccount.com.

And if you've been paying attention, this part is actually the project ID that we want to attack. So, whenever you have one of these Google Cloud service integrations, the project ID will always be embedded inside the pre-signed URL, which is major. And that's basically a guaranteed leak. So, the project ID, you don't even really have to guess it or enumerate it, because it's probably going to be given to you, which is very nice.

So, we can save that project ID and, you know, store it somewhere or whatever. Now, with the number I told you it's trickier, so you're probably going to have to run on the app leaking it or some kind of Oracle on Google, which I'm trying to work on finding at the moment. But, for now, I just included it inside this cloud.json endpoint here, where it's going to give us the project ID like before, and it's also going to give us the project number.

So, I'm going to go copy that now. This is probably not realistic, to be honest, but you can probably find it embedded in something like this. JavaScript, I assume, or probably have it. Some OAuth endpoints have it, I know, and then certain default service accounts will also leak them. So, these are kind of the vectors for the moment, but as I mentioned, I'm working on it more myself now. So, now we have all these numbers.

So, we have this data about this Google Cloud service project. We know that our target is using Google Cloud project. So, now what do we do? Well, the second step now is to basically launch some kind of tool that's going to enumerate Google Cloud service for us. And honestly, I didn't find a lot of tools that do this pretty well. I found one, but it only really looks at three types of applications. I built my own tool using Cloud.

It might be available in the description. It's not really production ready at the moment, but I'm going to make it available at some point, but for now we're going to use this 5 coded version of it. So, I'm inside this terminal here, and I'm going to access this tool. So, the tool we're looking at is Cloud GCP I, and we can just run it with Python here and see what it takes in. And this is going to take in basically the project ID and the number.

For some enumerations on Google Cloud, it's good to supply your own token into it because for some of the authentication endpoints, it will block you if you don't supply a token at all. But after you supply a token, there's basically like existence oracles you can use. So, basically it will tell you whether a project exists or not based on whether or not you're authenticated. So, if you're not authenticated, it won't tell you if it exists.

It'll just give you like a generic like 403 error. But if you are authenticated, it'll basically like switch to either being 404 or 403, which will tell you if the service exists or not, which is useful information even if you don't have access to it. So, we're just going to use this straight away. We're going to put the project ID we found, which that's the number. Okay, put the number in first then. The number here, and then the project ID is Jacob JN von project.

So, now I'm going to launch this tool very quickly and some of the things will fail because there's no token. This is pretty slow, so we're just going to wait for it to finish now. Right, so the results are in. We have our two results right here. I'm going to go through them a little bit. You can see it's scanning through all of these uh Google services, so Cloud, Firebase, and App Engine, and it's found a couple of things.

These storage buckets are going to be the default App Spot uh storage buckets. So, this is actually a very good way to confirm that App Spot is being used if these storage buckets are available. And the second thing we see here is the actual App Spot coming up. So, this is a very good indicator that App Spot is indeed being used by the project. Well, it's not even a good indicator, it just means that it is being used.

And then Cloud Functions, which are kind of similar to Cloud Run, but they work a little bit differently. Cloud Run itself, which we can see is also open, so we have something open. This is keyed by the project ID. You can see the project ID and the actual region itself. And then the first part of it is an service name that we basically have to guess. And that's kind of all that's available. You can see all of this kind of junk in the middle of it is this is just like kind of false positive stuff because App Spot will return the same thing if you put this dot in the middle of it and a service name.

So, this is a work in progress tool, okay? But anyway, we can get started with the first one. So, App Spot is going to be the main one you're able to find if you just have the project ID. It's only keyed by the project ID, you can see. So, the good thing about App Spot, the cool thing about it is it actually has an default admin panel, which is usually enabled. Well, not usually, but like it could be enabled, and we can visit it on this domain here.

So, this _ah is what's going to be used for this admin panel. And if you find this, what I recommend is just to tell Cloud to go into this admin panel or look for like endpoints admin panel. There's a legacy version of it and there's a modern version of it and Cloud will just do everything for you, so that's completely fine. And if you're able to find this admin panel, it's very nice. If you're able to find it, you can be very happy with yourself because this app spotting usually has good amount of capabilities on the project.

It can read storage, read the list, etc. which is quite nice for storage buckets because that's means user data is in there and user data makes us happy because it proves impact. So that's kind of the good thing about this admin panel. And when you have this here, you can visit basically this endpoint called token. I don't think that this is actually how it looks like. I asked Cloud to make it and I think it looks differently than this.

But Okay, maybe it's not a token. What is it? Okay, it's just a token here. And basically it'll give you like the service account token or whatever, which is nice. So you you might be able to see that available. And that's kind of what the app spot app is going to look like. This can just be a normal application as well, by the way. So you could be able to, you know, hit the web application and, you know, escalate from there.

It could be one of those legacy applications. Or you could get lucky and just find the admin panel. And then in this case, I coded it to be actually the admin panel. So that's one of the things you can find. And if you go back as well to the second one, we saw Cloud Run. Now Cloud Run is going to be the very interesting one because it's the main way that you can deploy applications. Kind of simpler type applications to Google Cloud.

The other way is with the Kubernetes engine, which is more complicated. But just looking at the Cloud Run, it's basically just a way to like fire off an app and just forget about it. So if you go here, you'll see we have an internal request proxy as the owner to make it an SSRF demonstration, okay? But what I mentioned before is that if you're able to get SSRF from one of these Cloud Run applications, you're able to basically escalate the service account immediately, which is super nice.

So, if we come here and we go back to the HP proxy, we can go over here and then we can basically type in the metadata URL here. So, we can come in here, we can type the stuff in and then we can basically fetch it. Okay, I'm not sure why I did that. I think it might have to go to compute metadata instead and it should basically give me this um missing requirement. So, Google kind of upped their defenses of their metadata after a lot of SSRF attacks.

So, now you have to have this special header called metadata flavor in it. So, we have to go and manually include that header. Now, that's annoying that didn't get proxied. So, I need to go back and click this button. And then when I press the fetch button, it should appear in my history. Okay, there it is. So, I'm going to bring it into the replay tab so you can see it again. So, we can go into this URL. We can go into this compute metadata.

And what the header that we need to specify, assuming that your app has passed through or whatever, is X-Metadata Flavor and the flavor is Google. Okay, never mind. Okay, it's just um it's just metadata flavor. It's not X-Metadata flavor. So, once you supply that header, it's going to give you access to this V1 domain. So, you can go into V1 and you can see what's in there. But, the main token is going to be at V1 -Instance.

It's going to be at Instance and it should point us to service accounts as well. So, we can just, you know, explore this area and then it'll be at the default one. But, we can go into the different service accounts. But, the main one we're interested in will be in default and it'll be in the token as well we want. So, be in token. And once we have that, it will actually return the access token and we can become the service account, which is exactly what we wanted to do.

And we have now escalated to basically taken over the service account. So, that's kind of what I wanted to show you guys today is how you can basically find a completely unrelated Google Cloud project application, just an app that actually uses Google Cloud project, find the ID with just some trivial techniques, and then escalate on a completely different application that you didn't even know about, that the company itself didn't know you could reach, and then reach and take over the service account, which I think is a very cool attack scenario, and really broadens the attack vector in terms of people that use Google Cloud project.

So, I hope you enjoyed this video of basically attacking Google Cloud project from an unauthenticated context. I saw a lot of guides online, especially from pen testers, about hacking Google Cloud project, and they often talk about having these like low privilege service accounts and escalating or whatever. If you're in a position in bug bounty where you have a service account, then you probably should already report it and stop escalating, unless it's actually intended as a feature.

So, we're more than likely not going to be in a position to basically escalate that way on cloud. We're going to be in a position to find out kind of details about it, but the chance of us having a service account is basically zero. And I like this methodology because it assumes you're completely unauthenticated, but you can actually still reach some decently sensitive targets, and you can enumerate their stack pretty well.

So, it's pretty tailored to bug bounty [music] and not pen testing, which is what I was aiming for. And yeah, if you did enjoy the video, then please leave a like and subscribe to the channel for more bug bounty content, recommended to you by the algorithm, which will give you that edge over the competition you need to find that bug and not get duped on it. And yeah, that's it for me. Thanks for watching, and happy hunting.