Episode 32: The Great Write-up Low-down

Justin Gardner (@rhynorater):
Yo yo sup critical thinking listeners. This is Justin Gardner, AKA Rhyno Reader, and I am rolling solo today. Joel got some conflu and is out. So I've got my water and I've got a whole list of awesome news topics. It's been a couple weeks since we've been able to do any news or write up coverage or anything like that. So we have an absolute doozy today. We have one, two, three, four, five. at least five awesome write-ups we need to cover. So, I'm gonna take a sip and we'll get started. Okay, first one up on the list today is of course, and also for any of you that are listening that also want to watch, I've got my, because Joel isn't here today, I'm going to add a little bit of the visual stimulation that Joel normally provides and share my screen for those of you that are watching on YouTube. So hopefully you should be able to follow along there as well. All righty, so the first thing we were gonna cover is, of course, if James Kettle ever releases anything, then we need to jump on that right away. And he does it once again this year at Defcon. He does every single year, drops some crazy research. This year, it's called Smashing the State Machine, the True Potential of Web Race Conditions. And this is a great read. It's actually not that long as opposed to, or as compared to some of his other research that he's released. And it's a really, like beautiful and simple technique to really improve upon race conditions. So to give you the TLDR of it, there's a couple things that we need to take away and talk about from this research. The first one is the fact that race conditions often take advantage of or abuse this thing called the state machine, which is why he's writing about it and why I made it into the title. So as the application is processing a request, it transfers between different states. And abusing those states is what makes the race condition. So he has a really great example here of a race condition, which is not a particularly hard to reproduce race condition, or a particularly technically challenging race condition. But essentially, when you're signing up for an account, there would be a post to, this is an example he has here, a post to slash login, and then a post to, or a get to slash roll. And he kind of maps out here the different states that the machine goes through. When you, you know, your login state, when before you do slash, post to slash login is null. And then after you have logged in, you assume that because it redirects you directly to slash role that your account goes into a pending state. That's what it looks like on the screen. That's what the user makes the assumption off of. And then after you select your role, it does a post to slash role and assigns you the role. However, you can only be assigned the role that you are allowed to select from the list on the slash role page. And so that's the way that this sort of state machine... flow went according to the natural progression of our thought. However, he noticed that when you are able to intercept the application before you hit slash roll, by default your account gets assigned admin permissions. And this is an example of the state machine doing something a little bit funky. And this is a multi-step race condition. If we just pause before slash. slash role and then do a request somewhere else, then we have admin permissions and that's great. But, but, so this is a multi-step, this takes multiple requests. But the assumption then that he explores within the rest of the paper is that there are these sort of substates that happen within the processing of a single HTTP request. And then how can we abuse these substates to get us access to crazy cool functionality? So that's the first thing you need to understand, this whole concept of substates. Let's say, during the application, there's a line of code that says, okay, users added by default give them admin permissions or set the role to zero or something like that, which is also admin. And then later on in that same code flow, it says, okay, now update the role to staff in the example that he had here. How do we catch it at that... you know, at the timing between when we have the admin role and the staff role is assigned between that in order to exploit that. And so that's kind of what he talks about through the rest of the paper is this concept of substates and how to hit those. And due to race conditions being very tricky with, you know, distance between you to the target server and just, you know, the con... the sequential nature of HTTP 1.1, race conditions have been very challenging. And in the past, James has talked about this whole concept of a last byte sync, which allows us to get really, really fast and well-timed race conditions in HTTP 1.1. And this attack that is the second concept that we wanna explore during this this sort of summary of his research, is the single packet attack, and that is sort of a way to do something similar, but a little bit better, for HTTP2. And the reason this is possible is because HTTP2 is not a protocol that has to be sent synchronously, you know, or sequentially, excuse me. It can also be, it can be sent concurrently. and it can be split across multiple TCP packets. And so, yeah, so the concept here is, and let's see if I can find the part of the blog here so that you can see it for those of you that are watching along on YouTube. Yeah, so he said, you know, this concept essentially was already explored back in 2020. Actually, there's another reference to it up here, I believe. Eh, I can't find it. This is the struggle with actually having the screen on. Oh, here it is right here. Yeah, this is inspired by a presentation back in 2020. And if you look at this Timeless Timing Attacks presentation that he mentions in the blog, this is just another example of James going and finding research that was definitely undervalued and just reading a bunch of weird papers and then being like, oh wait, I can do something crazy with this and then taking it. And this is what he's done for the past years. So it really talks to the importance of finding sort of way out there, you know, not in the mainstream of InfoSec research, reading it just out of pure curiosity and then building upon it. So the whole concept for the single packet attack is he talks about essentially sending the full body, the headers, if you have a body in your HTTP request, sending the body except for the last byte. And then having taking advantage of something called Nagel's algorithm, which is a sort of a TCP optimization That was made in order to solve something called the small packet problem in TCP but essentially what this allows you to do is build up a buffer of data up to the maximum segment side size MSS and Then send that all at once and so what essentially he's abusing here is sending the last byte of all of these HTTP requests that he wants to send in one TCP packet. And that will, using an abusing here, Nagel's algorithm for this. And what that will ensure is that all of these HTTP requests get completed at the same time when that TCP packet is processed by the server. And that allows us to not only have you know, all of them syncing within sub one millisecond, which is phenomenal. But also it allows us to delete any sort of network jitter. Where's the mention to it? I think it's up here. Yeah, you can see like normal requests will have network latency and jitter that you've got to, you know, accommodate for. But this single packet attack can literally get it to sub millisecond synchronization across these. these requests, which is just amazing for race conditions. Really great idea. And I really like here how he also mentions, has a section of the writeup called Rolling Your Own Implementation. And this is, this kind of breaks down the HTTP2 configuration that you should use, the way that you should modify an HTTP2 library in order to be able to roll your own implementation of the single packet attack. And it's surprisingly simple. like he says here, it can fit into one little screen segment. The TLDR of it is if the request has no body, send all the headers, but do not send the end stream flag. Now the end stream flag is a flag that's attached to a HTTP2 request that indicates something about that request, right? And so if you don't add the end stream flag, it indicates that request is not complete yet. and that the server should not start processing it. If the request does have a body, send all the headers and the body data except for the final byte, sort of like a last byte sync attack from last year. And the reason for that is that it says, you might be tempted to send the full body and rely on not sending the end stream, but he's done some experimentation with HTTP2 servers and some of them will just ignore the end stream. The fact that the end stream flag is not present and just... start processing the request anyway, which breaks a race condition. So you can see he's really done his research here, and it's a really simple and beautiful algorithm, and it should be, it says right here, you should be able to verify that all of the packets, that all of the requests landed in a single packet using Wireshark. So it should be pretty easy to validate that your attack is actually working properly using this. And of course, they've integrated all of this stuff into burp as well, as per the usual flow with James in the port swigger team. The other shout out that I wanted to make here was I bounced over to the HTTP2 RFC. And this is actually like a pretty manageable size RFC, right? Some of them are like really, really long and really, really hard to read. But this actually seems pretty manageable in size. So I think I haven't done it yet, just full disclosure. But I think after this, after this, I record this podcast, I'm going to go through here and just read through this. because I think it could be really helpful to know what all of this looks like. And HTTP is such a core part of being a solid web hacker, obviously. You spend so much time in the requests. And HTTP2 is just gonna continue to grow in popularity, so the more and more familiar we are with this, and I'm very familiar with HTTP 1.1, so I think it might be time to take that deep dive and learn a little bit more about HTTP2. Yeah, and then the last thing that I wanted to highlight in this write-up with James was his example here. So he's talking about a vulnerability that he found. He always goes and tries to, you know, exploit this on book bounties to show proof of concept, which I really appreciate. And one of the ones that he found, one of the vulnus he mentioned here, also I'll back up really quick and say, you have to go and read this whole, you have to, have to, have to go and read this whole paper. because he explains all of these really in-depth mentality and methodology approaches, and just the way he's thinking about finding these race condition vulnerabilities that is really phenomenal. And I'm actually not gonna spoil it here so that you have to go and read it, but it changed the way that I look at race conditions and the way that I am able to identify race conditions when I don't have code. And it's hard to do it even when you have code. So anyway, going back to GitLab, he found a bug on GitLab and essentially what it was changing his email and he noticed that when he race-conditioned the change email endpoint, what would happen is sometimes he would get an email containing the confirmation code for a different email at his email, okay? So let's say, for example, he does a race condition and he changes his email to test one and then he changes to test two really fast, right? So he might get an email with the confirmation code for test one at the test two address or vice versa, the test one email at the test two address. And the reason for that was really cool and I appreciated the way he broke it down, which was that when you changed your email, a function was called and that function would get passed into it as a parameter, the email that the email should be sent to. the email address that the confirmation email should be sent to. And that would be, you know, and I feel like this is a pretty common, I feel like this is a pretty reasonable way of coding it, right? So pass that in as a parameter, and then inside that function, this is asynchronously, it would generate the email body using a templating engine, right? And that templating engine, the variable for the confirmation code, would get generated via templating, of course. So it's pulling it straight, and the way that it's configured here is it's pulling it straight from the database, right? So what would happen is you would send the first request, that email would get passed into the function which would define the templating for the email and send out the email, and then by the time that templating engine was ready to create the body of the email and insert the confirmation, the confirmation token that was associated with that account, that confirmation token will have changed because the second request will have already come in and generated a new confirmation token, right? So that token is getting inserted into the body of the email and that email is being sent to the original address which is being passed in via that original, excuse me, by that original parameter to the function. So that's how a mismatched confirmation token can get associated with an email. and sent to a different email. It's really cool. Really like that bug. And I think it's also really cool. I'll see if I can find it in here. I'm so bad at finding things on the fly. Somewhere in this write up, yeah, you can still view it on my profile, he says. So we can click on this and it says, it still has this email which is unconfirmed that is associated with his account. It's very cool. All right, so that's all I had for James Kettle's write-up. And I'm gonna try to, you know, as I go through some of the deeper write-ups today, I'm gonna try to sort of pepper in a little bit less technically dense content to kind of give your brain a refresher. So the next thing that I wanted to talk about then is this tweet by Alex Chapman, and essentially, what he's doing right now is he's tweeting out an automation development diary. So as he is building his own bug bounty automation over time, he's tweeting out how it's going. And I think this is really insightful for those of you that, and Alex is a top hacker, we've had him on the podcast, he's phenomenal, right? So for those of you that are a little bit bummed, like, oh man, my recon's going all weird, just know Alex Chapman has spent over two days at this point. on just getting the scope and stuff like that from all these different programs and getting it all to consolidate into one format in one spot. And I'm sure there'll be lots of other raw lessons learned and successes and failures along the way. So definitely keep an eye out for his Bug Bounty Automation Development Diary series on Twitter. Okay, water time. All righty, next piece of research. Super lit, once again, Sarush coming in, dropping some fire on IIS. Excuse me, I've got a little bit of nasal congestion as well. Yeah, so Sarush once again dropping some crazy fire on IIS here. This bug just is crazy to me. This is the cookie list duo drop IIS auth bypass in app pool priv-esque on ASP.NET framework. And this is a CVE from this year. This is a newer technique. So the TLDR of this is essentially in when you're using ASP.NET in IIS, you can send a... open parentheses, s, open parentheses, any text, close parentheses, close parentheses, or I'm sorry, with a slash in the beginning as well. So slash, open parentheses, capital S, open parentheses, any text, close parentheses, close parentheses. This is the struggle of doing this on audio medium. And essentially that will get processed as a cookie in the.NET framework and then stripped out of the freaking... path, right? So it's like classically, excuse me, this is like a beautiful, beautiful way to circumvent any sorts of IIS restricted paths, right? So it could be you've got path restrictions in IIS itself. It could be that you've got path restrictions in, you know, an NGINX proxy that's sitting in front of IIS, you know, whatever it is. There are times when you want to wall off a specific endpoint, and it's very common to do that using a reverse proxy, and this just totally destroys all of that. For those of you that are following along on YouTube, you can see right here, this just is crazy to me. Let's say we've got an endpoint called slash web form slash protected, and you shouldn't be able to access anything in protected. What he does here is slash web form. slash and then that S, uh, parentheses X thing that I mentioned and then slash pro, pro T, right? So the first couple, the first four characters are protected. And then he just inserts in there, the slash S X sort of combo thing, right? And then he says acted at the end of that. Now. What's gonna happen is that slash SX thing is just gonna get totally deleted from the path. We can see it down here. He cites the code. This remove app path modifier piece of code. And you can see right here that it returns the path without the little... session cookie indicator in there and just strips it right out, which allows you to just perfectly bypass any sort of path-based restrictions. Super awesome. Love this technique. And then there's this other thing down here called related to application pool confusion. And I'm going to be perfectly honest with you. I didn't like super fully understand this, but from what it looks like to me is you can use this cookie list session token injection in here. in order to get your path or the code that you're running within a specific path, executed within a different context, which is an application pool in IIS, which can allow for the isolation of privileges. Say, for example, you don't have the ability to run ASPX code or whatever in a specific app pool, but you do in another, how can you get the code that's in that non-executable path to run in the other application pool, and this is possible via this cookie list injection. Once again, definitely worth a read. And so definitely check out Saroosh's blog. We'll link it down below, but it's saroosh.me for those of you that don't know it already. And so really cool, really cool research here. I'll mention as well that at the beginning of this blog, he says... For a deeper dive into security issues stemming from the use of curricula sessions consider these references. So He lists three other places where you can go and read About it, and I absolutely read this one right here the isek.pl blog which is Excellent as well and this guy Paveo I believe is how that's pronounced He talks about using this for XSS when a path is being resolved from a squiggly path, right, a tilde path, to an actual path, an arbitrary path. And so for those of you following along you can see right here that he's able to inject into that because that session token is An important part of what should be associated with that path and use that to get XSS Once again a cool access technique for any of those that are into Automation XSS automation this could definitely be something really cool to do mass scanning for if you can find this reflected into the body of the request, then that would be really cool, or the body of the response, and that would be really cool. The one thing that I wanna do highlight from this, which, ah, here it is right here, is that it's not only... open parentheses, S, open parentheses, any text, close parentheses, close parentheses, that works. But also, you can sub that S for an A or an F. The A is an anonymous ID, and the F is a form authentication token. Now, being able to specify some of this stuff in the URL is also just kinda weird, and I feel like it could definitely be used for session fixation, or if you could get sort of like a client-side path traversal of sorts, your own session token into it, right? If you get a client-side password so you could inject your own session into that request and then take the data that's in that request and associate it with your own account rather than with the victim's account, which I think has a lot of potential there. And then, yeah, so this is also just helpful for bypassing like WAFs or anything that might be, they might be catching on, maybe they see Susha's blog and they say, okay, all right, we gotta block, you know, any of this cookie list stuff. And they block just the S, but then you've also got A and F you can use as well. So keep that in mind. Okay. That's all I had for Suresh's stuff. Definitely go check out the blog. I will link it down in the description as always. The description might be a little long this time around, so we might have to host it somewhere else, but we'll figure that out. Okay. Unfortunately, we're going straight into another highly technical piece right now, so bear with me and we'll hang in there. This is a really cool blog, so I think you'll like it. Okay. Next one is Ophion Security released a write-up customer account takeover in Shopify stores. This is Roshan. Amazing bug as always. Shopify. There's just so much cool stuff. So many cool pieces of functionality to play around with on Shopify. So it's always cool to see them as a target. All right, so the way, let's see, what did I wanna highlight here? Let me look at my notes really quickly. Yeah, okay, so we won't go through every single step of this writeup, but I did want to mention that this specific bug takes advantage of a couple sort of quirks, okay? So the first one is this concept of an unverified email address being associated with your account, okay? And... I imagine on the back end, for any of you blue teamers out there or devs. There's a couple ways to implement this. You could put the unverified email as the actual email for the account and then add a flag like is email verified, true, false, somewhere else in the user object, right? Or you could put the email in its own unverified email attribute of the user object and then move it to the verified email object whenever you do anything. The latter is way more secure and the former, unfortunately, is what we see here which I think causes a massive vulnerability. So, what happens is when you sign up for a shop account, you can change your email address or you can specify an email address and they will send a confirmation email to that email address but for the time being, your email is still that email. And so this is weird. This is weird and we always want to whenever you have an unverified email This sort of looks like this. This is specifically Interesting when there's only one email associated with your account. So this is not like a change email sort of feature This is when you've signed up for an account and the only email they have associated with you is this unverified email, right? Because then you know, there's a better chance that email is actually the primary email associated with your account and so Essentially what they do here is they take this unverified email account and they abuse the shop pay oauth workflow to log into a different Log into a store. Okay So I have this one line highlighted right here that I really I really want you to dial in on Even though a store may not have the sign in with shop feature I guess fully enabled and displayed in their store, it is still possible to access the shop pay OAuth directly via this endpoint, okay? So what they've done here is they've shown mastery, they've shown. in-depth knowledge of the product because they are familiar with this concept of there is a sign-in with shop feature that can be enabled and disabled, and even when it's disabled, it's still there. It's just not in the UI, right? This is incredibly important for those of you that are looking to develop this sort of spidey sense or this sort of understanding of how to find these more complex vulns. Any features that you can turn on or off or that are accessible part of the time but not accessible the other part of the time. of the time, you have to validate that. Just because it's not in the UI or just because it's not a part of the normal flow doesn't mean you can't force navigate to it and then insert yourself in the middle of this crazy flow that they've configured here. That's exactly what Erosion and the Ofeon security team do here. They take their unverified email, shop account. and they use that to sign in with shop into a Shopify store. And at the end of the day, I think it's not as simple as just hitting that endpoint. I think they also have to hit some endpoints to get the cookies that they need. And this also shows further mastery of the application. They know which cookies need to be swapped for what. in what clickies are providing authentication in the context of the Shopify store, which will allow them to gain access to a fully validated account. So this is very important, and it goes to the concept of understanding. you know, anytime you look at a HTTP request, you're just gonna see a block of cookies because of tracking, because of all this and that and the other thing. But it's very important to use something like maybe request minimizer, even just do this manually, removing all of the fluff and getting down to what is actually useful in the application. Figure out what is resulting in authentication, what is affecting the application directly. And once you've narrowed that down, you have a much greater chance finding vulnerabilities in those components because there isn't so much fluff around. Okay. So that's what they've done here and that's what results in the account takeover for them. man that had to be a crazy bounty because Shopify I think has, I want to say they have 200k crits max and that is an arbitrary count takeover so congrats to Roshan and the Ophian security team. Alrighty. Next up, well let me get some water. I got to take water between every topic. Okay, next one is a tool released by Monka, a great hacker and hack one ambassador. This is called ShortNameGuesser. This is. We talked about something similar to this a couple weeks ago, but essentially with IIS, there is a way for you to specify short names and get true or false Windows short names. So I wanna say it's the first six characters that you can enumerate in the last three characters of any given file in a directory. So, but oftentimes files are longer than six characters. So. excuse me, you've got to figure out what the rest of that name is. And I guess Monke decided that this is a perfect use for GPT-E3 and some of the AI capabilities that we've been playing with lately, thanks to OpenAI. And I couldn't agree more. I think essentially if you know how LLMs work, they're actually just looking to develop the next token, token in line and that's how they simulate all of this wonderful knowledge and comprehension that we've all been amazed by for the past, you know, six to eight months. And so what he did here is he developed just a very short piece of code. You can see here it's like 35 lines to utilize chat GPT or the OpenAI API to get a list of potential file names associated with a given short name. I think this is a great tool and I will be using this the next time I'm doing IAS short name brute forcing. All right, I'm going to have to take a big sip of water before this one. Sam Curry has released something y'all. For those of you that are not familiar with Sam Curry's work, essentially every couple months, Sam and team, whoever it tends to be that time around, releases some giant write-up that breaks the whole internet and destroys a whole industry normally. And it's an excellent read. And I think it's really unique content, because not many people, not any other people that I know of, are out here addressing sort of industry wide issues like Sam. And just kind of going after... You know, I'd like to talk it up, but it's really Sam just being like, you know, what would be the coolest shit I could hack? And then going and hacking that, and I just, I love that about Sam. And then he does these write-ups, which bless him for doing these write-ups. They're so long and they're so detailed, and they really highlight the attacker mentality as they go through this. So this is also a mandatory read. The James Kettle read earlier was absolutely a mandatory read. is also a mandatory read. So go read it. It's Sam Curry's most recent write up on points.com. It's entitled, Leaking Secrets in Unlimited Miles, Hacking the Largest Airline and Hotel Rewards Platform. As you may have imagined, this is Sam Hacking Points.com, which is a provider of points for all of these different vendors. He has a, for those of you watching, you can see here, the list of vendors that he has, but some of the top names include Delta, Emirates, Marriott, IHG, so many different companies utilize Points.com for their rewards programs. And he does a high-level overview in the beginning, which we're gonna skip, of course, here at Critical Thinking, we do low-level overviews. We talk about the technical details, the juicy, the juicy technical details, and we get hype about that shit. So, that's what we're doing. Essentially, what I've done is I've broken down each of the sections of the rest of this writeup, and I've got some key takeaways from all of the various sections, and I'm gonna provide a short summary. But like I said, you're missing out on a ton of juicy data. And hacking mentality and just vibing if you don't go and read this so That's my I've said my piece now Okay, so first section is how does it all work? This is kind of when he's discovering how this whole points comm thing works He's using way back machine to read documentation and understand the details behind it And one thing that I wanted to highlight here is he gets to this console.points.com, which allowed public registration, signs up for an account, and he says, I just want to take a quote out, the next thing we did was to examine the JavaScript that powered the dashboard. We discovered that the website console.points.com appeared to be utilized by points.com employees for executing administrative actions concerning customer accounts, rewards programs, and managing components of the website itself. Anytime you see something like this, I've done this a couple times, where you have public a portal that is management for all of these different tenants that you'd be hacking. That's gold. Go in there, read the JavaScript files, figure out what it looks like to have those requests recreated in the background. I've personally made six figures and bounties from this exact scenario as well. So that's a big takeaway there. I was also impressed, for those of you watching, you can see the graph here. For those of you not watching, essentially he has a graph where he's outlined the way that the API, the rewards API does authentication and unfortunately, it's a Mac based authentication which, I'm not gonna lie, if I was in Sam's shoes, I would've totally ignored this because I freaking hate Mac based authentication. Essentially how it works is you've got a key and you've got your message and every single message that you send, every single freaking request needs to be run through this Mac algorithm and a message authentication code. code generated and that code included with the message to ensure that message hasn't been tampered with and was sent from someone that has the key in order to send that. So that would be a pain in the butt, but that didn't scare Sam at all, and they were able to do some really cool stuff, not only despite of it, but abusing that. So props to them for that. Next section is called exploring the United Airlines point management website. So they move away from points.com after they've learned a lot about how the points API works and they go to specifically mileageplus.com, by miles.mileageplus.com, which is a United product, which is infamously out of scope in the United program, RIP. And essentially what they do here is they go through the registration process and sort of figure out what's going on. And then they do something that which we talk about all the time on critical thinking, which is they pay the freaking money to send Miles to somebody else. Right? We always say, you know, bite the bullet. pay your, in the picture that he's got right here, I just noticed he has $6,584 worth of miles he's sending somebody. I don't know that he actually sent that much, but if he did, that's ridiculous. But he bites the bullet and he sends some miles, pays the money, and sends some miles to somebody else, right? So it's Ian or Shub's happy day or whoever he's hacking with this time. They get some miles from Sam, but also what Sam gets in return in the response of that HTTP request that sends the miles is the person's points.com user auth token, the membership authorization token. which is a big L for AirPoints.com and the Mileage Plus United team. And essentially what that allows you to do. is by entering a person's first name, last name, and mileage plus number, which is their account ID, essentially you would get back their auth token from that request and you could use that auth token to log into their account, send the miles back to yourself, and get a bunch of access to a bunch of PII. Huge vulnerability, great technique in finding that out. So take away there. pay the money, just pay the freaking money, and you'll find lots of vulns like that. If you see a place where you could pay money and it's like a reasonable amount of money, you should get really excited to pay that money. That is potentially some of the best money you'll have ever paid. You're gonna get some serious ROI on that. So that's what we always say. Halfway through a Sam Curry blog post, you gotta take another sip of water. Okay. So let's talk about the next section, isolating the issue to affect other rewards programs. So at this point, what's happening is Sam is trying to figure out how exactly the points.com API is being integrated with all these other different providers. He did that with United, and he's trying to do that with other providers as well. And he highlights in the post this HTTP request right here, which for those of you not watching, it's, there's an HTTP request with a path, and then in the body, it has two parameters, MVP payload and LPID. LPID is a UUID, and MV payload is an empty object, an empty JSON object. So what he does here, it's very interesting, he appends a pound symbol to the end parameter. The reason he's doing that is he is looking for secondary context vulnerabilities. This is sort of a term, I feel like this term is actually coined by Sam himself. But this is sort of Sam's bread and butter. I found multiple bugs with Sam where he exploits secondary context bugs and he's just a master at it. And essentially what's happening is he is assuming that this ID is getting taken and put into the points.com API in the back end. that we were talking about earlier with the Mac authentication scheme and that sort of thing. And he's trying to validate that by putting a hash tag in there, a pound sign, and what that will do is that will, in the URL, it will create a hash fragment and truncate the rest of the data that comes after that. UUID. And you can see from the response he gets a 400 bad request back, which tells him that he can't process a can't process type text HTML instead of application JSON. This is a great indicator that there is some sort of secondary context going on. Then Sam proceeds to do all the tricks in the book. He's adding slashes, he's path traversing, he's using the query parameter, the question mark to truncate and add additional query parameters. what he does is he uses a path traversal sequence to back all the way up to the document root, I believe, and specify, maybe it's not the document root, maybe it's one above the document root, but you can specify, cool tip, you can find the document root, this is actually a tip that Sam taught me, by traversing past the document root, and then you'll note that you'll get a 400 bad request on that. So really, really helpful technique there that I've used several times. So for example, if the backend request get user slash user ID and that ID is where you're injecting. If instead of the ID you put dot slash dot slash, now you've gone back to the root slash, if you do one more dot slash you'll get a 400. That will allow you to identify the document root. So what we've got going on here is he traverses back and he hits an endpoint called slash V1 slash search slash orders. and then it says missing query parameter needed. So then he starts fuzzing for query parameters in the get using the... what he assumed would be the get when he specifies the path via the LPID. But unfortunately nothing was working there. And he then decides to fuzz the MV payload section. I'm gonna start saying they instead of he because I know that this is a team working on this. So they decide to fuzz the MV payload section of their original request, right? That we mentioned in the beginning, the one that had an empty object. And it turns out you're able to provide post parameters there. And they provided the queue parameter a grand total of 22 million records back to them, leaking points transactions across all of the providers. It was a God token that was being used. Just. Magnificent, magnificent vulnerability. Key takeaways there, learn how to do secondary context hacking. I've also got up on the screen here the wonderful presentation, legendary presentation by Sam, Attacking Secondary Context in Web Applications. I will link it in the description. This is also mandatory reading if you haven't. already. If you have, I would also recommend going back and rereading it because if you're not finding these volumes on a fairly regular basis, you probably should be because I am and Sam is. So definitely check this out. And if you want another really cool example of this, which is almost identical to this vulnerability, Sam and I in 2020 found a vulnerability on Starbucks, which does almost the exact same thing. You can see for those of you watching that we traverse back here and hit a one slash accounts function, which dumps all of the Starbucks accounts that were in the database. It was like 99 million records or something ridiculous like that. So definitely, yeah, nearly 100 million records. So definitely these ones are all over the place and you should definitely know how to exploit them. Okay. Let's see what else we've got. The next little section that I wanted to talk about was this, this is still within the Sam Curry blog post, is leaking credentials for the Virgin Rewards program. So this is still within that blog post. Essentially what happens here is he's kind of going around to all the different sort of. providers that are using points.com. And he's trying to figure out, you know, hey, is there any quirks in the implementation here that we can exploit to attack points.com or attack their rewards program. And this is another, and we see a large variety of techniques that have happened already. We've seen the exploitation of, well, just understanding JavaScript, reading the documentation through way back. We've seen the secondary context vuln, And right now, in this one, we're seeing a content discovery vulnerability. So this is when Sam is just running, or Sam and team, they are running... just content discovery tools like Fuff, and they get a lucky hit on login1.php, and that login1.php leaks the Mac key and Mac ID that we mentioned before that was used for authentication into the rewards API. Now if you see this, normally you might not know what this is used for, but Sam and the team have developed a mastery of... this product. They've read everything they can get their eyes on. They've sorted through minified JS files. They understand what's happening here. So when they see that Mac ID and that Mac key, they know exactly what to do with that. So they're able to use that key to authenticate into the API as the Virgin Rewards program. and they were able to dump all of the orders, all of the transactions that have happened, which includes, it looks like, actually plain text credit card information, and over, looks like, two million instances of that. So, that's real bad. Thanks work, Sam, and team. The next one that we wanted to talk about was... this section right here, authorization bypass on widgets.unitedmileageplus.com. And this is, once again, another technique that varies from the other ones. So we're not just looking for IDORs, we're not just looking for XSS, we're not just looking for secondary context bugs. We're looking for all of it. And it requires a large knowledge base of different techniques in order to be able to fully exploit some of this stuff. So it's really impressive to see what Sam does. It's also a good lesson to us to stay mentally flexible on what kind of bones we're looking for and how we're looking for them. So. This next one that we're talking about here is this, so we're back to widgets.unitedmileageplus.com or unitedmileageplus programs. And essentially what they're doing here is they're using GAU to enumerate the subdomains and the different pages, login pages, that there were to log into this widgets.unitedmileageplus.com. And they're identifying that sometimes there is a page with just your mileage plus number, your last name and your first name. Sometimes it requires a username and password. Sometimes it requires a security question, or let's see what else, yeah, answer your security question. There was a bunch of variety there. And in that variety, they were noting that the responses to those were still returning a token that looked roughly the same, right? So I'm just reading a quote here. We found that the token returned from each of the different authorization methods were identical in format to each other. So once again, showing application mastery, understanding what that token looks like. First knowing that token is important and understanding what it looks like allowed them to understand that, hey, maybe I can take the token from the less challenging authentication method, the first name, last name, and mileage plus number, and use that token in the other method was supposed to be necessary. And that's exactly what they did. And they were able to bypass auth and get access to PII disclosure, transferring miles, essentially arbitrary access to their MileagePlus account through that one login that gave them an access token via first name, last name, and MileagePlus number. Really cool technique. That's a business logic error and token swapping, right? Business logic error identifying that there's, that there shouldn't be a way to authenticate and then token swapping, knowing that they can take that auth token, put it somewhere else, and access valuable information. Really, really great vulnerability there. Now, the finale. They say that they still... Let's see if I can find the... So one of the things that I really appreciate about Sam and the team here as they're writing this up is that, so he has a section named looking for something more critical, right? Like the bugs that he hasn't found, that he's found already, just not critical enough, you know? Like we got to go max criticality. And they don't give up until they achieve it, which is really cool. And they do achieve it every time so way to go team or at least every time that we're privy to you know Maybe there are times when they've quit out a little early, but we get to see the highlights real so that's really cool So they go back to hunting on points calm and then finally they pop it and how do they pop it is it some crazy? Some crazy technical exploit that just kind of blows your mind and path traversally nonsense. No, it is the fact that The JWT token associated with the session for the console website was the word secret, all lowercase. Now, this is... This is kind of crazy to see, to be honest. This sort of vulnerability I've only found once, but Ian Carroll has released a vulnerability or a tool called Cookie Monster to exploit this vulnerability. And essentially what it does is it allows you to try to brute force and check defaults for session configurations in... in various types of applications. I think this is a great vuln because once you exploit this vulnerability, if you have the secret key to JWT token, you can do whatever the heck you want because you can sign the only thing they're using for authentication, right? So in this scenario, I suppose they were looking at the session token a little bit more in depth and they identified the fact that I guess they ran it through Cookie Monster running a brute force against it. And a few seconds, yeah, after a few seconds we had a response. It popped that the secret, that the... secret for this JWT token was secret. And so this is a reminder to me and to you and to every other reader that we need to be on the lookout for these sort of weak cryptography implementation vulnerabilities here because they are all over the place. And man, they dropped some awesome screenshots in here of like literally just being able to arbitrarily select a program, you know, a rewards program and just assign points to them and. man, you could just literally, you could just walk around the whole world, doing whatever you wanted with this pretty much because you just have unlimited access to all of these points. So really cool, awesome that they got access to that and really cool techniques along the way as well. So props to Sam and the team. Nice bug. All right, water time. We're moving along, we are, we're moving along. Okay, so like I promised in between, technical piece we'll have a sort of less technically dense segment. This time around, another tweet from Alex Chapman saying, I'm in desperate need of a platform feature browser plug-in or something else that can easily show a bug bounty program's direct competitors who also run programs. So many bugs from one company are directly applicable to others in the same industry slash niche. And then Rezo comes along and says, do this would be a sick product? What if there were a way to like tag specific functionality as well on specific book bounding programs? For example, you could identify a book bounding program and tag that, hey, this has got a PDF generator in it. Or something like that, where there's specific technologies in place. This one is using Flask. right, because from the last scenario we could go back and check the JWT token implementation. And so, Rezo tagged me in there and said, hey, shout it on the pod, maybe someone will make it. And we've had that happen before. We shouted out this concept for a CVSS advisor, which I've got up on the screen now. You can find it at CVSAdvisor.com, where you can just sort of select what, you know, different, what your CVSS configuration is, and it will give you tips and... what sort of configurations need to change for you to bump your bug to the next severity. Shout out to them again. Appreciate them building that. And also, this is my go-to CVSS tool now. So definitely keep that in mind. But also, if any of you guys are looking into or feeling program-y or want to try to decide a way or figure out a way to tag... various bookbinding programs, anonymously obviously, because we've got private programs, with specific features or functionality, I think this is something that would be widely used by hackers. So, cool idea there. Alrighty, let me just stretch. Last write up that we're gonna cover for today. This is a zero click ATO with the Sandwich Attack. This is recently released by Lupin and Holmes. This is a, man, look how beautiful this website is. Just an absolutely beautiful website, LandH.tech. This is by Ronnie Carter, also known as Lupin on Twitter. And yeah, essentially I think they're gonna be producing Bug Bounty content and this is a great place to start. This write up is on this concept called attack which abuses version 1 UUIDs or UID version 1. Okay, so for those of you that aren't familiar with UUIDs, UUIDs are, for those of you that aren't familiar with UUIDs, thank your lucky stars, because they're becoming more and more common all over the place, and they're a pain in the ass. But essentially, they're an alternative for numeric IDs that should be associated with an object. So user ID equals one, instead of that, you've got user ID equals F887AA6, you know, bladdy, blah, right? And so these are very long strings, randomly generated normally, but not in this case. They contain five different sort of segments. And the segment that you should look to for the version number is the third segment. So for those of you that are following along on YouTube right now, you can see right here the first character of the third segment of the UUID is a one in this scenario. Normally it's going to be a four. If it's a four, that UUID was randomly generated and you have very little chance of being able to iterate across those UUIDs or enumerate them. Now if... you got really lucky or you found a piece of technology that uses UUID V1, that third segment, the first character will be a one. And what that tells us is that this is not a randomly generated UUID, this is a UUID that is predictable and is highly correlated with a timestamp. So Lupin and Holm's team here do a really great job in this write-up of describing how this concept called the sandwich attack, scenario they define, there's a password reset endpoint that password reset uses UIDV1 reset tokens in order to access, to reset the password. So the attack would be... excuse me, the attack would be you reset your own account, that's the first layer of bread, you reset the victim's account, that's the meat, and then you reset your account again, and that's the top layer of bread, right? So you have two reference UUIDs, V1IDs, those are the two pieces of bread, and those will tell you the range of time, because UUIDs correlate, UUID V1 correlates directly to timestamps, of time you need to brute force for the middle ID. So then you use a tool to enumerate all of the possible UUIDs in that range, and then you try those UUIDs in order to gain access to the victim's account. By the password reset functionality great attack. I found something similar to this before and One of the things I will say is we can actually utilize this in conjunction with a race condition ish sort of thing That we mentioned, you know earlier in the in the pod with James kettle to make sure that these sandwiches You know that this is a very thin sandwich, right? that you can that your first request the second request and third request are all in a very small time period because as he mentions here, these are in millisecond timestamps. So for every second that these are off, you have 1,000 possibilities for what could, you know, that you're going to have to brute force. So you want to try to get these as tight as possible, and you should be able to get an arbitrary count takeover in these sort of situations. Alright, I will also note that in conjunction with this write up that we will be putting in the description below, there's also this awesome video that Lupin put out on their YouTube channel walking through the actual details and he does a lot better job of explaining it than I did. So, definitely check that out. Also, if you just like looking at things with your eyes, this is a beautifully produced video, so very high production quality here. Shout out to them for that. that takes a lot of work. I'm realizing that more and more as I sort of go deeper and deeper into the content creation realm. So great work Lupin and Holm's team there. Man, that's such a cool name. I love that. All right, so that's it for today. That's all I've got. Definitely. Thank you for listening to this episode. Hopefully Joel will be back and kicking next week so we can do a, a duo episode as usual. Um, if you guys wouldn't mind heading over to ctbb.show and dropping a subscribe on our newsletter. We'd really appreciate that. We're trying to grow that within the next couple of months. Also, um, for those of you that have heard me talk about my real estate investments on the podcast before, I have a big accomplishment. I'm done with the Renault that I've been working on for the past. 6 to 8 months, so super hype about that. Should be able to drop more time into the pod and into bug bounty hunting, which you guys will hopefully see lots of. So with that, have a great week and thanks for listening. Bye.