Episode 171: Path-Scoped Cookie Hacks with Uppercase & Post-based Raw Protobuf XSS

Justin Gardner
If you leak the age of a person, you also leak their birthday, their full date of birth, right? Because what you can do is you can just look at that age and then find the day that it changes, and then you've got the person's birthday.  All right, y'all, we've talked about ThreatLocker Ring fencing a lot. We know how it allows you to set ACLs and policies for exactly what an application is allowed to do in your network. But today, I'm going to tell you how it does that, okay? 3 technologies: MiniFilterDrivers, Window Filtering Platform, and ExVersion Kernel Notification Routines. MiniFilterDrivers are essentially a hook or callback for I/O requests, okay? So when you're trying to write or read from a file, you can create a hook with those and approve or deny based off of the ThreatLocker ACL. Windows Filtering Platform, similar situation but for connect-bind requests, right? You can say, "Okay, hey, is this process allowed to talk to port 443 over there on the internet? Yes or no? Approve or deny." Lastly, you've got ExVersionKernelNotificationRoutines. The Ex version's important because it allows you to approve or deny versus just getting a notification from the kernel. And this is specific for hooking various native API calls like NtCreateUserProcess, which is what you would use to like spin up PowerShell.exe or something like that. Okay? So those three are very useful to ThreatLocker's  Ringfencing core technology. Hope you enjoyed learning how this is implemented. Check out ThreatLocker if you think your work could benefit from something like that. All right, let's go back to the show. All right. Sup hackers. Before we jump into the episode this week, I got a couple quick announcements in the This Week in Bug Bounty section. The first one is actually the first 3 are from YesWeHack. Uh, YesWeHack has dropped another complete guide. Uh, and it's this time it's on OS command injection. Um, as I was reading through this, there's a bunch of really good summaries on what kind of techniques to use here. You can see a bunch of payloads where the, um, you know, command will break out of various different contexts. One of the things I've learned about command injection is you will only find it if you're looking for it, right? Um, and I, I know a couple hackers, Franz and Matthias, that often find these bugs. And the reason they often find them is they are often spraying payloads just like these, uh, polyglots that include multiple contexts, or these specific ones that are right here. Um, so grab some of these, integrate this into your testing workflow, and some of these command injections will fall out. I've I've seen it happen and it's amazed me. All right, y'all. Next up is another piece from Yes We Hack. This time we're covering a critical auth bypass in WordPress Azure AD SSO plugin. Man, I'm not going to lie, guys. I've had to say that— I've had to do like 3 different takes because I can't say that. But yeah, guys, this one's pretty gnarly. Essentially, this allowed unauthenticated attackers to log in as arbitrary WordPress users if they're using this plugin. So This is essentially like an RCE, right? Because if you can log in as any WordPress user, log in as an admin, upload some PHP code, and then you've got, you can shell the server. So really bad. Probe for this WordPress plugin, any of you recon boys out there. The details are laid out pretty cleanly here by YesWeHack in the write-up down in the proof of concept section. Essentially, you can just provide a JWT token an ID token specifically that just says you are anybody, right? And you can just look, you can just submit blah.base64encodedidtoken.blah, right? And it's just not checking the anything besides that middle piece of the JWT. So that's really bad. So definitely go ahead and poke at this if you haven't already. Great write-up by YesWeHack. We'll link it in the description. All right. Our last piece from Yes We Hack today is actually highlighting our boy, ituglow, who is a part of the CTBB team and writes our hacker notes. So shout out to him. Those have been great lately. Um, and this is just a bio on him. So if you want to get to know ituglow better, he's an excellent hacker. Um, and this is a good way for you to understand how he thinks, how he chooses his targets, what his favorite hacking tools are, um, that sort of thing. So we'll link that down in the description as well, highlighting our boy, iTouglow. I got to get him on the pod sometimes too. He'd be, he'd be a great addition. All right. The last and perhaps most exciting news item that we have for today is Adobe is partnering with Echo Party Miami, May 21st and May 22nd at the Echo Party event to do a live hacking event. To join the live hacking event, you can submit all findings through the normal Adobe Bug Bounty program. In scope is Adobe Stock, Lightroom Web, Adobe Workfront, and they're increasing bounties from Tier 1 to Tier 3 for the AI bonus tier here for this live hacking event. So if you're going to be at Echo Party and want to participate in this, definitely find the Adobe team and we'll link more information in the description below. All right. I think that's it. Let's jump to the main show. All right. Sup, hackers? I am finally back at home after a marathon run of live hacking events. So shout out to HackerOne and Google for their various live hacking events they've been running. I've been working long hours and I've been traveling, so I'm not going to lie, I'm pretty wiped. Last episode, Joseph and I were in Korea. We kind of very sleepily at like midnight gave you guys some of the takeaways from that event. I proceeded to spend a couple of days in Korea traveling around, spending time with my wife. And then came back to the US and have been hit with an absolute one-two punch of seasonal allergies here in Virginia. Just a shit ton of pollen and jet lag, which has been quite the combo. And solo parenting while my wife went over to Japan for a couple of days to see some friends. So yeah, been a busy, busy week. That being said, this episode is going to be pretty tight as well. My apologies for that, but I do have some really interesting content. So, um, yeah, I hope you guys get as much out of it as I did when I was finding these things. Uh, it's definitely some good, some good takeaways. So let's go ahead and take a look at those. We're going to do a couple bugs and then we're going to do a couple like just takeaways. Um, so first up is a Protobuf-based XSS. So I wanted to tell you guys about this because I've been hacking on a target that uses Protobuf a lot. Um, and I recently found an XSS that, um, requires you to actually send raw Protobuf. So binary level Protobuf, not like ProtoJSON or like base64 encoded Protobuf, uh, over, over the wire in an HTTP request for it to work. Okay. And this presents a couple challenges and I'll try to enumerate those here. Um, anyway, so like if you could send the request, then it would result in XSS. So it needs to be like a top level navigation in the browser, right? It's not checking the content type. So we can send it with text/plain. I thought it was not gonna be as hard as it was, but it was pretty tricky. So let me tell you a couple reasons why. One, there's this thing called a DOM string mutation that seems to happen whenever you actually add these, this raw binary to the DOM. So sometimes some of the payloads will get a bit mangled. So you really have to make sure your payload is largely within the pure ASCII range. Which is 0x01 to 0x7F. Otherwise you're going to— it's going to cause some problems with in get mangled. So I kind of tweaked the payload a lot to fit that range by, you know, inflating or deflating, you know, the size of various payloads, trying to shift types as much as I could or omit fields that were going to cause problems if they weren't actually strictly required in the— in the protobuf payload. There was some flexibility there, which was cool. So after a lot of smithing, I got it into that pure ASCII range. Another problem is that if you have an LF, a line feed character, which is 0x0A, then, and it is not immediately, you know, preceded by a, a cr, a carriage return field, then the browser is gonna try to fix that for you and put in one, which is very annoying and will break your whole payload. So the way that I kind of got around this, oh, and the protobuf, I'm looking at my notes down here, that's why I keep glancing down, but the protobuf field for, you know, field number 1 and wiretype 2, which is a string, is going to be OA. So you're not going to get away from using— getting an OA in your actual Protobuf payload. So the way that I actually got around this was by buffering it up with a junk field before that ended in OD. And so now I've got what appears to be a, a real CRLF, right? And OD OA. In the hex and then the browser doesn't feel like it needs to fix that invalid newline sequence there. And it was not mangling my, my Protobuf payload. So that was awesome. Obviously this is really tricky because Protobuf is a length-based thing, right? So if you're, if your lengths are off or if there's a stray byte in there somewhere and the browser does anything funky, then your payload is going to completely break. So That was one of the issues that I ran into and got, got through. The other one was you kind of need to send a, or at least the way that I was doing it, I think there are other ways to do it, but you need to send a equals character in your, your payload body. If you're, even if you're doing a text plain submission, form submission to get the top level navigation. So you need somewhere in there, there's going to be an equals sign, right? And something's going to be the, the key on one side and the value on the other side and the equal in the middle, right? So how I ended up solving this one was I padded out a field, you know, that had the, the 0x3D character as the length right where I needed it to be so that it wouldn't heck up the string before or the string after with some of these weird rules for keys versus values in a form submission. So just had to align that properly to get it to not break and get most of the values in the, or most of the data in the value, which is a little bit less liberally tweaked by the browser. So we have a lot more flexibility there. So that was another challenge was getting that equal sign in there. And then the last challenge was really interesting, which is the browser will actually append a, CRLF sequence at the end of your submission whenever you send a form, which was really annoying to me. I'm like, okay, well, that might just do me in because I need my whole, you know, protobuf payload needs to end with CRLF. Um, but actually the way I solved this in the end was define a string field at the end with a length that is 2 bytes longer than the length I actually provided it. So when, so when the browser actually appends the 2 characters at the end, that will get slurped up into the defined string at the last, you know, field of the protobuf. And it will actually not mess with the byte offsets or not parse it as extraneous data or anything. It'll just parse it as a part of the string that we already defined. So let's say I, the last, you know, character or the last string that I defined was 4 bytes long, I would only give it 2 bytes. So when the browser filled in those other 2 bytes, it would be that full 4-byte string. So anyway, just an interesting little solution there. If you're ever dealing with Protobuf, that you actually need to send over the wire in, an actual like top-level navigation via a form to trigger an XSS or otherwise, then those are some tips and tricks that I had along the way. All right, let's keep moving. Up next was, this was one that is not actually that crazy, but I like the mentality. So I wanted to tell you guys about this. So I found a way on a program recently to leak the age of a person. Excuse me, of a person. And the age of the person is an interesting thing to leak. Sure, it has some impact on itself. But as I was sitting there thinking about it, if you leak the age of a person, you also leak their birthday, their full date of birth, right? Because what you can do is you can just look at that age, and then find the day that it changes. And then you've got the person's birthday, right? And the full date of birth, which is a lot more helpful, in my opinion. Obviously you could do some brute forcing and stuff like that, but if we're talking about like PII disclosure, getting the actual month and day as well as the year is valuable. So I just wanted to, you know, throw that out there for y'all as thinking about whenever you're leaking some data, try to think about how that data can change over time and if that can give you any additional information and you might be able to find some additional impact for your bugs. Um, okay. Uh, just a couple more takeaways and then I gotta wrap this episode. Um, CSPTs work not only on web apps, but also on desktop apps or any other type of app. I was hacking on a desktop app specifically recently, and I was able to essentially incur a HTTP request with user-supplied input in the path remotely from a different machine. Okay. And this one specifically came in through sockets, WebSockets, but it actually was able to— I was able to supply a path traversal and truncate the path and hit a completely different endpoint. And that ended up having some really good impact. And I was just kind of sitting there thinking about this and I guess I just sort of assumed beforehand that this was more of a web-based vulnerability. But pretty much anything that interacts with HTTP can be CSPT because traversals are such a key part of pathing in, in most HTTP environments. So just think about that as well. I, I know that sometimes as web hackers, we struggle to make the pivot to other types of hacking, whether it be IoT or desktop apps or binaries or whatever. This is an, an attack that can be used fairly universally, um, because HTTP is really, is really common even outside of, um, strictly web apps. Okay. Just a thought. Um, and, and I'm also interested in kind of thinking about other types of vulnerabilities that are more present outside of, uh, just the web environment where we can sort of take those over. So if you have any of those, Maybe drop them in the pod talk channel in the critical thinking Discord. Yeah, I think that there's definitely going to be more. I'm going to, I'm going to keep spinning on that. Okay. Another one that is really interesting. Another takeaway that I had, guys, capital letters are really overpowered. Okay. I was hacking with somebody. I'm not going to say who recently, and we just found a ton of bypasses using capital letters. Okay. I'll give you an example of one of them. This is, this one is just, uh, one of like 3 that we use to find vulnerabilities, uh, in the past couple months. Okay. First, uh, we had a scenario where if a specific cookie was not present, that is pretty much always present, uh, when a request was issued to a specific endpoint, it would result in a vulnerability. Okay. So how do we get this cookie not, not issued? Well, we could, you know, put it in a credentialless iframe or whatever, but we kind of needed access to the victim session as well, right? So we've got this like catch-22 situation of, okay, how do I, um, send a request without just this one cookie while keeping the other cookies was essentially what we needed to do. And the way we ended up solving this was by sending a request to the same path, but with one character switched to a capital letter. Okay. And what that did was, uh, technically that is a different path. The backend was processing it as the same path, but the browser was not sending the cookie to that path because the cookie was hard scoped to a specific path that did not have that capital letter. Right. So the path attribute for the cookie was set to, let's call it /abc lowercase. And when we sent the request to /abc uppercase, that cookie would not be sent, right? So these cookies, path definitions, they're, they're case sensitive. And a lot of times our paths that we're dealing with on HTTP servers are not case sensitive. So just keep that in mind. Obviously there's encoding tricks and stuff like that you could do, but in this situation it was actually as simple as lowercase and uppercase letters. There was— as soon as some of these bugs get resolved, I'm going to come back on the pod and talk about them. Uh, cause there were some other weird ones that we solved with uppercase, uh, letters. So just be on the lookout for that. I feel like it's kind of like a, uh, you know, simple method, but it's, it's very prevalent. Okay. Um, two last takeaways, both sort of relate to, um, clickjacking or getting a new tab open inside of your browser with top-level navigation. Okay. So we're dealing with some client-side stuff here. So, um, I ran into a situation recently where I needed to be able to CSRF somebody to set a cookie. And I needed to do this inside of a iframe because of the constraints of the attack. And then inside of that iframe, there would be rendered a link. And if the user clicked that link and did a top-level navigation with it, it would result in a CSRF. Um, so essentially what I ended up doing here was, uh, performing a clickjacking attack and the person would need to control-click one button on the screen and then their account would get taken over, right? Um, cause I could trigger the, the login CSRF and then they click the button and then bad stuff happens. Okay. Um, so I hadn't really used that control-click to open up a top-level navigation from within an iframe trick before. So I thought that was a pretty interesting one that you guys might wanna know about. Once again, clickjacking, very impactful vulnerability type in my opinion, if you do it correctly, okay? Note that last caveat, if you do it correctly, very important. So keep that technique in mind. And then last but not least, I was just doing a little like brainstorming before this episode and I was thinking like, okay, if I need to do a window.open, I need to get a user gesture, right? That's the technical term that you use to get a window open, uh, without a popup block in, uh, in modern browsers. And I was looking into what that is and I've just always kind of thought of that as a click, but it's not only a click. You can also get this from, uh, a keydown event, which I think is a lot easier to get in some scenarios. I mean, really this isn't a problem very much because you can always just Perceive, um, get the user to perceive it as like one of those accept cookies, uh, pop-ups, and then you get a free click whenever, right? Really useful for POCs. Um, but just keep that in mind as well, that you can also do a window.open without a pop-up block from a keydown event. Um, the last thing that I wanted to mention was whenever you do need this control click, uh, I realized that you can actually like make buttons unclickable. Until you are holding the Control key. So that makes it a lot easier to like cerebrally convince the victim that they need to Control-click something is, uh, you can actually hide UI elements if the user's not currently holding down the Control key. Um, so just think that about that as well. It's much easier to program these things with AI nowadays. So, um, it makes your POC a lot cleaner. Also definitely want to cover it on the pod. Just popped into my brain. Uh, I don't, don't have time to do it today. But the research by Lira on SVG-enhanced clickjacking is unfreaking believable. You can make literally, you know, responsive buttons via SVG magic, essentially, um, overlaid, you know, for clickjacking purposes, right? So the problem with clickjacking is, right, there's an invisible iframe in front of it. So when you click it, it It doesn't actually do anything. You don't see the UI button depress or anything like that. But with these SVG magic things that Lira does, you can actually make it happen. So anyway, I really want to build a library out of that. I think that that is a really useful and mass-applicable technique. So anyway, I'll link that research in the description. All right, guys, that's all I got for this week. I'm sorry. We're going to bring the heat coming forward the next couple of weeks. We've got a lot of great interviews lined up. and we've also got our first meta-analysis episode, which I'm excited to present to you guys. All right, that's a wrap for this week. Peace. And that's a wrap on this episode of Critical Thinking. Thanks so much for watching to the end, y'all. If you want more critical thinking content, uh, or if you wanna support the show, head over to ctbb.show/discord. You can hop in the community. There's lots of great high-level hacking discussion happening there on top of the masterclasses, hackalongs, exclusive content. And a full-time Hunter's Guild if you're a full-time Hunter. It's a great time, trust me. I'll see you there.