Yo, sub everyone and welcome to the pilot episode of Critical Thinking Bug Bounty Podcast. In this episode, Joel and I will do some introductions, give an analysis of some awesome bugs and drop some fire bug bounty tips. Thanks for listening, and I hope you enjoyed this episode. Alrighty, this is the first episode of Critical Thinking. I'm your host Justin Gardner, and I've got Joel Margolis here as well. Say hi Joel. Hey, how's it going? It's going good man. Getting ready to buy a house I think this week. It should be interesting. Yeah, it's going to be good stuff. Yeah, like I said, so this is for everyone, this is the first episode we've done. I just for a little context, I hit Joel up a couple weeks ago and was like, let's do a podcast and we kind of just rolled from there. We came up with some topics and this is the first time we're getting to materialize some of it. So yeah, I'm excited and I think today we'll mostly talk about just a little bit of an introduction to ourselves. So you know who your hosts are. And then also give just some general thoughts about the podcast and then we'll kind of go into an analysis of a couple bugs that we just like did just to kind of cover some bugs for the first some technical content for the first episode and then we'll we'll end it up with some with some bug bounty tips. So that's that's some good usual. Yeah, man, I'm really looking forward to this. Sweet. Well, with that, why don't you go ahead and start us off with a little bit of an intro to who Joel Margolis is? Sure. Yeah, so I'm Joel Margolis. I also go by the handle TechnoGeek, which you might know me better by. During the day, I'm an AppSek engineer. I work at Tinder right now and then in the evenings I'm a hacker. I'm primarily a mobile hacker. That's where a lot of my background comes from. So yeah, that's that's a little bit about me. Are you are you are you doing are you doing mobile hacking at Tinder in particular or is that just your bug bounty thing? I do. I mean, obviously Tinder is a mobile app. So a lot of what we do involves sort of like the mobile security side. But yeah, that it's definitely like a little bit of both nice. Okay, solid. Yeah, for me, I guess I'm Justin Gardner, aka Rhino Reader. I am full time bug bounty hunter and have been for about a month coming on three years now. Just moved back to the US from Japan, where I was over there for the past two years. And yeah, just mostly working on hitting some bug bounty programs real hard. I don't have a specific. I'm not like one of those hackers that has a specific program that I crush all the time. Those guys are super cool, but I don't know. That's just not quite my speed. I jump around a decent bit and participate in live hacking events and that sort of thing. Although lately, Joe and I have been collaborating a little bit on on hacking some IoT devices, right? Yeah, yeah, we've got some really cool findings, really cool research that we've been able to do. Yeah, I'm hoping I'm hoping the company is going to let us talk about like what what IoT device that is and we can get into some of the details of that on this podcast because some of those bugs are like, I know they don't have the greatest reputation. For that, but those bugs are pretty sick. So I'm hoping we maybe we maybe we can do like a, I don't know, maybe I'm just being hopeful, but I'm hoping we can do like a masked, you know, disclosure or something like that. So there's this IoT device, right? And that sort of vibe, but I don't know. You know, it's got internet on it and things and stuff. You can talk to it, you know. Connect the dots yourself. Yeah. Take a guess. That might be bordering on the edges of, of, you know, legality there, but yeah, I suppose we'll see. We'll keep them guessing. Yeah, yeah. So, all right. Well, I guess with that, I'm trying to think if there's anything else. Yeah, I think that would be good for introduction. So we'll go ahead and transition then over to thoughts for the podcast. So Joel, you know, I just kind of hit you up and was like, yeah, I'm doing a podcast. And I didn't give him much, much insight into what exactly we were going to do with it. And I have to admit, you know, it's not fully formulated just yet, right? Like we don't, we don't have an exact, you know, curriculum for what we're going to do. But, you know, we have an idea that we want to try to keep it technical and we want to be releasing applicable technical content every single time we're doing a podcast. So I'm hoping you can expect that from the podcast. Joel, do you have any other thoughts on what kind of stuff we'll be talking about or any other, you know, values for the podcast you want to convey to the audience? Yeah, for sure. So I think like one of the things that we wanted to make sure is that this is sort of like a consumable knowledge, like resource that you can go to and like regular sort of like updates and getting formed and like staying in the loop on stuff. Yeah, yeah. So I think a lot of what we're going to be doing is talking about like bones that have come out and we're going to try and throw in some interviews. We're going to talk about some of the techniques that like are going around in the community, stuff that we've personally, you know, done in our own hacking. Right. You know, any like really cool bugs and stuff like stuff we were talking about earlier. So I think those are like, you know, a lot of it. And, you know, you did say it's going to get technical. I don't think we're going to get super, super technical right. We're going to get like into the weeds, but we don't want to make it so that like, you know, people don't can't understand that. And we're sort of limited by the audio medium a little bit because you can't really get that technical with a, you know, I'm not just going to start reading to you code, you know, and expect you to read and eat JavaScript. Yeah, exactly. It's for you to digest that content with any sort of, you know, consistency or whatever. So yeah, I think those are all great points. And then one thing that Joel, I was thinking of, which I'm excited about that I hadn't mentioned to you yet, was, you know, a little bit of a spin on the interviews, but I'm hoping what we can do is we can reach out to some of our buddies from these live hacking events and talk a little bit about, like get them in here, get, figure out what their bread and butter vulnerability is and talk to them about like the tips and tricks for that, like how they find it, you know, what, what does their go to sort of thing? And I'm, I'm lucky, you know, I've got a, I've got a, a mobile hacker in here as a co-host to I would love to pick your brain on sometimes because definitely that's definitely a skill set where I'm lacking a bit. Yeah, man, I think that's a great idea. I would love to do like a little, maybe like a mini series of some kind where we talked to all the, the NVH from all the events. Oh, dude, that'd be sick. And we do a little interview and just sort of get some of their top tips. Nice. Yeah, I definitely think we could make that happen. So we'll definitely be on the lookout for that. Let me just glance at these notes really quickly here. Oh, yeah, I think also, you know, in addition to some of the things you, you mentioned Joel, I think we'll probably, we'll probably also have a couple of soft skill episodes or like more softer episodes that are going to be like talking to tree ojurs, talking about writing reports, that sort of thing that that's very applicable and like life changing information, but it doesn't necessarily have a technical base to it. Yeah. And then of course, at the end of the episodes, we're going to, we thought we'd include some little tips and tricks. Oh, yeah. We're going to, if you listen all the way to the end and you listen past all of our ramblings and whatever, then we're going to include a couple little extra bug bounty tips at the end, you know, just personal advice and feedback and stuff that we've seen, you know, through our hacking experience that will, you know, just sort of share openly with all of y'all. Yeah. And I think those are not necessary. Just full disclosure. I don't necessarily think those will be super cohesive. Like, you know, we might jump from like, ah, this is this cool like reversing tip that I had to like, oh, this is like some cool scope. You should you guys should check out or like an attack factor you should think of. So, you know, it might be all over the place, but those tips are going to be likely strongly correlated to our own bug bounty experiences and how we, you know, what kind of stuff we've learned in the past week and like, what kind of bugs we've found. So hopefully that'll be, that'll add value for your all and keep you, keep you tuned in until the last last bit of the podcast. I mean, it's not like they can't just skip ahead to the end of the podcast. Right? So, you know, are you or listen statistics are going to be all right? Yeah, don't don't do that. You know, you you heard me you heard me say it. I, you know, I got you if you if you did it. So I called you out already. Um, yeah, I think I guess I don't really have anything off the top of my head else about the podcast itself. You got any other thoughts Joel? No, let's let's get right into it. All right, man, you want me to talk about my bug first or do you want to talk about your bug? I'll go ahead and talk about mine and then I'll let you I'll let you go ahead. Yeah. So, um, I know, I don't know who, you know, checks out the hacker one activity, but there's a lot of really cool stuff in there all the time. And, you know, if you're ever looking for techniques like activity, great place to look, um, you can always see like, you know, what they got for a bounty. Like the details of the report is off and disclosed. Um, you know, you can see what programs are paying nicely, like what things are paying for. So it gives you a lot of information about sort of like what much of mine want to put your focus on. And, um, yeah, a couple months ago, there was a researcher who goes by a YV.
BVDWF, they are big like GitLab hacker and I don't know this hacker personally, but it seems like they do a lot of really intense Pointing what a what a profile, dude. You look at his guys profile It's really crazy. Yeah crazy stats crazy bugs crazy crits crazy payouts 7.0 signal over the last 90 days You know like really really impressive stuff and and one of the reports is spent at the top of the activity for for a couple weeks Because they just caught a lot of trend attraction. They got full RCE in in GitLab via GitHub import So you may or may not know that GitLab has the ability to import repos from GitHub So you can you know you want to move over to get lab or whatever you can import it directly from your GitHub URL And it uses octokit to do that to get the data from GitHub and The way that you know I won't get two into the weeds on it But GitLab octokit uses this class called Sawyer that sort of like hashes, you know different IDs and stuff into a format that's used within the code later Okay, so this is a bug in octokit then or is this a is this a GitLab like native code sort of thing? Yeah, so interestingly you'd think that it might be an octokit issue, but I don't think it's it's something that's inherently wrong with like Sawyer or the class or like Octokit itself It's really how GitLab is using and trusting that later, right? So they make an instance of this object and then they're like using it incorrectly They're not checking that it's like you know validly formed that doesn't have like you know in this case redis and it was sort of the injection vector So this researcher found that they could basically replace this ID when you know when they're importing a repo They could change this ID to like an object that would then get ingested Convert it into like a legitimate Ruby object and then they could inject redis commands and from there They were able to discover you know, okay full redis takeover they tried getting a net cat shell or a curl or something, but they were blocked Which is the case nowadays, you know, it's really hard often nowadays. They just have firewalls and you know IP Allow lists and all that kind of stuff so it they make it really difficult to actually get an x-fill But they were able to actually get out through redis directly so they basically set up Yeah, they sent it a command to basically like make a replica of the redis server onto their own redis They started getting things so they were like okay, this is legit They set it up on their own local they just double checked right they saw that there was like tons of redis access So they basically get full redis takeover which is like you know, okay already basically pounded at that point But they wanted to go further they wanted to get rc So they put together this you know crazy payload And It's it's super wild basically what it does is it they like poison their own get lab like profile like the project They're like image for right and then they like It so it had like some excess payload in it and then every time they load the page it just like 500s So Even I think at the time of writing the Report they said that they were unable to to actually load their project page anymore just 500s every time they try and load it So so they forever broke it. I don't know if they were actually able to get a full rc But I would I would say that like pretty cool. Yeah, it's at that point 33k 33k bounty So it's it's you know the get the get lab team doesn't like hand those out like like cookies, you know, so that it's got to be a pretty serious one Yeah, exactly so it's for it's really really cool to see these stuff like this I think like get lab is one of those awesome Like unique programs where it's so cool because I mean, it's all open source right like all of get labs Source code is like public right like and everybody always says how you know like open source is more secure, right but like Yeah, I don't I don't think it means more secure, but I think it does give an awesome opportunity for hacking Yeah, I totally agree and I think I think you know There's definitely a trade off right because they definitely wouldn't be getting this much attention from the bug bounty scene if they They didn't have open source So they're definitely cleaning up their their scope a little bit, but also like definitely would not be these bugs would not be found if it wasn't for For you know having this source code available, so Yeah, yeah, so get lab is one of those programs I've just I've always in the back on my mind. I've been like dang. I should really yeah I should have I should have get low. I'm actually kind of surprised to just clicked on the get labs like thank page or whatever But I don't see Alex Chapman up up in the top 10 even for that. Oh man. That means we have a chance I know yeah, I was just I'm kind of surprised because it's like Alex Alex's thing is is get so I I'm kind of surprised he's not not looked at this so much or maybe he has and just you know Has more luck with GitHub or with You know some of the other things that I won't disclose that he's absolutely destroyed, but Yeah, definitely seems like a ripe scope and there's definitely crits being found on this like all time so I might know what I'm heckin on this weekend. Yeah, seriously So I'm just I'm looking through this and so what what kind of takeaways would you have after reading this report? That would be like good tips and trips we could pass on to the viewership here So I think like one of the like you know, obviously you probably could find this doing like manual code review But that's not the best route for everybody. So maybe what you could do. I think I really come and like good thing You could look at is that initial payload that That the researcher tried which is that they provided this object in the like the ID Where was it getting pulled in as an ID parameter? Yeah, yeah, yeah, this this like object type and so maybe just like throw that in your payload list Yeah, you know toss that if you're hacking on a Yeah, get hub also written in Ruby get lab written in Ruby They're both Ruby on Rails applications hacker one also review on Rails application So you know who know that in your Ruby payloads, you know and you know, maybe you'll you'll get a hit somewhere Because you know octokit for sure is a widely used SDK and I'm sure that Sawyer class is probably yes by other things So it really can't hurt to just have it in there. I was also thinking it's pretty it's pretty this is a pretty interesting technique for redis injection as well Is this replica like just clone it out to a different server that you've set up right and I guess you have to kind of Insecurely configure your your redis instance to accept foreign, you know, replicas Just kind of like hitting in to it, but that's that's a pretty cool trick to like X fill and Get out when you you're injecting into redis which can happen in lots of environments. It's not just this crazy You know deserialization or like ID mess that goes into you know getting controller Ruby object injecting into redis You can get that with with some forms of SSRF you can get it just with generic like injection redis injection itself is just of vulnerability If they they don't escape, you know the stuff that they're injecting right in so that's definitely something to keep in mind Yeah, for sure and like you were saying Even before they did this replica start like the replica redis command. They actually had tried some other redis like RCE escalation payloads and those are like also great examples like anytime you're hacking on something redis They they use this L push and they said that they use an existing gadget So if you look at the payload it looks like it's it is a little bit specific to GitLab where they're using this system hook push Type you know gadget row it's something that exists within the redis instance already But anytime you're hacking on GitLab great thing to try Looking GitHub see if you can find some kind of you know parallel there do some research. I'm I'm not a super like redis expert But I'm sure that there's a ton of payloads out there that you can that are going to be very similar to this You know how how I'm just looking through this how is this ID getting interpreted as a as a Because it says normally ID should be a number however ID and then list some stuff we can inject additional redis commands by using Byte's eyes to limit the previous command when it is constructed into I guess a Ruby object. That's kind of crazy I guess it's some sort of DC realization right? Yeah, so it it seems that like if you look if you look at the code that when it does this GitHub import It checks basically each object that it's importing and it and each object within Git has like a unique ID And so basically it like it gets that object and it checks. Oh, how I already do I already have like a cache entry and redis for this And so that seems to be where it starts to fall. Oh, yeah, where it takes that object and it does like ID for already imported cash and then it does some Some magic and that can that's really shows. Yeah way more familiar with this This source code because yeah, man, it feels like there's there's a lot of juice to be had there absolutely It's paid a ton of bounties for sure for sure And yeah, this is always I guess another really cool lesson to kind of take away This is really just track your sources and sinks really well, you know, he he started off this attack by By doing a GitHub import and obviously that has a bunch of You know nuances to it that are gonna create a situation where you're you know, there's Potential for vulnerabilities. So definitely watch any sort of areas where you can do imports from You know, others code bases or any sort of fringe features like that because that's where the sketchy stuff happens Yeah, now this might be a little controversial
I think one of the ways that I like to look at for bugs, especially in source code is a little bit backwards. Well, I'll look for something dangerous, like a command being executed, and then I'll go backwards to see if there's any entry point into there, versus being like, oh, this looks like an interesting feature. Let me see if I can exploit something in this by throwing payloads at it. If you have the source code, you can always just look for those dangerous methods, look at those things. So if you have something like this, if you find something down the road that's like this, look and see if it's systemic, check the source code, see if there's other patterns of it. Yeah, that's interesting. I think there's two widely taken approaches with source code or you like that, because you can try to find your sinks, where code is being executed or something like that, or you can try to find your sources and then trace them to something sketchy. And I'm a little bit, and I'm by no means an example of a tremendously skilled, white box coder viewer, but I, in my experiences, especially with the, with the, Grafana SSRF that I found a couple of years back, and I kind of talked about that methodology and a talk, but the approach was I was new I wanted on authenticated bug. So I looked at all the unethonicated routes, right? And then I kind of traced those where they were going, and one of them was ending up in a get request to a foreign server, and I was like, this feels SSRF-y. So, I kind of went down that path, and I think there are people that have success doing both approaches, starting from a source and kind of investigating from there, and then also starting from a sink and working back. - Yeah, yeah, that's awesome. All right, I've talked enough, go ahead. I want you to talk about your bug. It sounds like you had a crazy SRF. - Yeah, yeah. - So why don't you tell me a little bit about the-- - All right, we'll take it off from there then. - Yeah, so, okay, I don't actually have permission to fully disclose this system, what kind of program I was working on, but really love this program, how to really good experience with them, and I'll probably shout them out by name at a different point. So, keep an eye out there, maybe you can draw some lines together, but the-- - If you leak it, if you leak it, we could just bleep it out, probably. - Yeah, yeah, I'm probably just gonna, you know, I'll probably say it in this explanation, and I'll have to bleep it, but we'll see. We'll see. So, yeah, so the bug is an SRF, and I'm just gonna kind of talk through how I found it, and it's on a specific, on a grocery provider, right, which is relevant to the system, or to the Expo later, also, I wouldn't tell you. But, yeah, so the first step of all this, it was, I was hacking with a mentee of mine, actually, and sorry, I had to get some water there. I was hacking with a mentee of mine, and we came across this panel that was where they had set up access for their various retailers to go on and sign up for the service, right? So, obviously, if you're a grocery delivery provider, you know, you're, you're, you know, you need to have the products that all the, the groceries are selling, and that sort of thing. So, there needs to be a web application that, that those providers can log into. So, we found that system, and obviously, we didn't have cred, so we started looking through the JS files, trying to see if we could hit any routes or anything like that, and we came upon a hidden sign-up endpoint that was in those JS files, right? And that's-- - Those are my favorite. - I know, that's, that's like the best sort of situation, man. And so, of course, you know, we get in there, we're like, yeah, this, you know, I think, as of a bounty hunter, you kind of got to like manage your expectations, sometimes, right? So, you know, you come into that situation with like, all right, yeah, this probably isn't gonna work, but I'm gonna give it a go. And so, you know, we started suscing it, and yeah, it popped, and we were able to get an email, you know, saying your account was created, but we couldn't log into the account, and then we did a password reset, you know, using another endpoint that we found there, and we're able to get access to the account, but at this point, we didn't have access to any companies, because none of the companies had like, on-boarded us as like, a employee at their company, right? And so, - So, did you have to, did you have to go into the JS and like, manually make that request, or was there some sort of like web interface that you hit Slive Signup, or? - No, unfortunately, this was one of the, 'cause you know, I'm a big fan of like, trying to use Match and Replace to like, trick the client side into automatically building those requests for you, 'cause it's like, it's really a pain to build it manually, but this time, we actually had to build it manually. Or at least for the, for, oh, no, actually the signup, the signup endpoint, that one was accessible. We just hit that endpoint and completed the signup, and the forgot password was available at the front page. But then, later on in the process, we had to build some custom, some custom requests. But it was nice, 'cause that one. - It was a real business show though. - Yeah, it was nice because, you know, that first little bit, that first little bit that tells you there's a problem that was available without having to build any requests. So, you know, at this point, we're authed, we're in the system, we don't have access to anything, so it's like, is this really a bug? Like, I don't know, maybe. And we start reading the JS files, and so I start from the top, and my mentee being the genius that he is, starts from the bottom, right? And so, I tried the first three endpoints that I found, building the requests from scratch, and kind of using API endpoints that were generated by the login or whatever, and none of them worked. And so I was like, this is the dead end, right? And then, right then, my mentee had tried, you know, a couple, finally gotten his first one built from the bottom, and it worked, and it was just like a classic numeric eye door, right? And we were like, oh dang. So then we obviously had to sus all the endpoints, and so we kind of went down that path, and you know, we found a bunch of eye doors, some really, really impactful stuff. And then towards, you know, as we're getting a little bit more into this JS file, we discovered the ad product endpoint, right? And it required a couple of IDs that we had been able to successfully numerate before. And so we try to add this product, and it gives us a weird error. Like, you know, this route doesn't exist, or something like that, and we're like, this is the same format as all of the other things that we've been going after. And so we kind of like sticking in a burp tab and move on, and later we found a similar host that seems to also host a version of that API, and we tried it on that host, and it found the route. And so that's another cool tip, is like, definitely check and see if there's different hosts with a similar API structure, and see if you can try and points there. So now we've got it working, and of course, you know, one of these, you know, parameters that we had in here is remote image URL, to load an image of the product, and I'm like, heck yeah, this is my jam right here. So I pop a URL in there, get the hit on the way out, and I'm like, this is great. And then we run into like a serious problem, okay? So in the response, it doesn't, it doesn't, you know, we see the hit on our server, and in the response it dumps back a cloud front URL, right? And you go to this cloud front, and it says, "Ax to Nide." So I know, I know for sure, right? This bug was driving nuts. I know for sure that there is a, that it downloaded my response and stuck in an image, right? So this would be a full read SSRF. And, but I can't figure out where this S3 bucket is, and it gave me a path to like the file name, and that sort of thing, but I don't know what bucket it's in. So I look, I look, I probably put like eight hours into just looking for this endpoint, right? And I finally found in another section of the application when you send a request to like upload an image somewhere else, it kicks back this S3 bucket, and if you try the path on that S3 bucket, then it works, right? And then so we had-- - That's better routing. - Yeah, yeah, so for some reason, through cloud front, it was saying, "Ax is denied," but then when we tried it through this other bucket, through the bucket directly, it gave us a, it gave us a access to the response. And so at that point, yeah, at that point, you're, you know, the blood is pumping, you're excited. And yeah, so I obviously hit the AWS metadata endpoint for those of you that don't know what that is, for servers hosted in AWS, particularly EC2 instances. If there is a AWS role associated with the EC2 instances, which we find there normally is, if you hit the endpoint 169.254.169.254, I will never forget that IP address, right? - Ever. - Ever, it's like in grade in my memory forever. Then it will drop to you metadata about that EC2 instance. And one of those things that they included in the metadata was the credentials to log into AWS as that role, which is like just a gem of a piece of information because it's resulted in so many RCEs from SSRFs, it's absolutely nuts. So-- - Yeah, and it's an awesome proof of concept to be like, look, this is real. Like I'm getting real data, it's a safe way, usually, if you wanna just get the instance ID or something, there's a lot more information that's provided through that metadata API that can be like, sort of more safe, you know what I mean? - Yeah, yeah, and so you definitely don't always have to pull the credentials. There's actually,
There's like, I want to say it's under latest slash user data as well as sometimes like some startup scripts for that EC2 instance, which I found some worse stuff in there actually before then in the actual credentials. So there's lots of places you can, you can go. And I will shout out my own blog here for a moment. This wasn't, I wasn't sure that I was going to talk about this, but I do have a, a little bit of a piece of research on my blog, ryanarrader.github.io about AWS metadata identity and how there's like, this weird set of credentials that you can get access to that has some cool permissions. So if anybody wants to take my research that I put over there and go a couple steps further, I didn't end up getting it into, to anything more than like leaking the password policy for the AWS account. But there's definitely some, some opportunities for cool stuff using these credentials that are not the credentials that you normally get. It's a different set of credentials. So definitely check that out. Dang, that's a really cool bug man. Yeah. And the end, we actually, we actually got RC on 56 different instances in their network. Did they pay, did they pay for instances? I wish, I wish they did. Dude, that would have been sick. But yeah, obviously, it did get max bounty. So that, that was a fun one for sure. That's awesome. So what would you say like the key like, those key takeaways are for like, what were like the real keys to like finding that bug and like making it impactful? Yeah, for sure. So I think the first one is, you know, we wouldn't have been in this system at all if we hadn't read through those JS files. And you, you know, you hear at time and time again and reading, minified JS is nobody's favorite pastime, right? But it really, it really is a good investment of time to go in and find those, those endpoints. And especially, you know, just search for some key stuff, give it a glance because sometimes it's as simple as hitting that sign up endpoint. And sometimes, you know, like I forget, I think it was a Corbin that had a bug a while back where he was like, yeah, I just took one of the endpoints out of the JS file and then I hit it and then it said an admin cookie. And I was like, what the fray, you know, like, those sort of scenarios are out there. So it's always good to see that sort of thing. And then I guess the other pieces would be look for when you get something like you're when you're updating uploading to s3, look around, you know, and you can't, you can't necessarily find where that file is landed. Look around in the application, look at other places where s3 is being used. Look where images are being hosted, you know, do your in-depth due diligence there to see if you can find where that might be. And then I guess the last one is hit that AWS metadata instance. For those of you that, that, you know, get SSRFs from time to time, hit that metadata instance and pull down those creds and also do some additional research into these AWS metadata creds. Someone who's better at AWS than I am, please check it out. It's a really awesome scope, I think, and it could be really impactful. So yeah, and if I'm not mistaken, there are metadata URLs on the other hosting providers as well. So like this isn't unique to AWS. I'm almost certain that Azure has one. Yeah, GCP has one. So, you know, if you're not on AWS, check look up the IP address for whatever host you got to ping back from, see who's hosting it and, you know, do a quick Google search and you'll find it. Another thing you mentioned about JS files, they're really frustrating to look through. There's a great site, beautifier.io. And it'll, it's made for like JavaScript and HTML and that kind of stuff. If you have a minified JavaScript file, it's super hard to read. You can just toss it in there, click beautify code. It will auto reformat it for you. You just put it in your text editor and you can scroll through it. It's much easier. I think Visual Studio code also has a built-in beautifier to some extent. Oh, nice. But yeah, if not, I know that there's like, there's an extension that I use that, you know, does that formatting as well. So there are definitely lots of ways to make that just a little more readable. And you know, that'll, that'll, you can find all those end points and you're grubbed a lot easier. You can read through and see what it's doing. Yeah, absolutely. That's absolutely essential. And actually, I'll give a shout out as well to a another tool that I use for for JS beautification, which is P prettier. And I want to say this was built by the mixer team. If anyone's still remembers mixer, the competitor to Twitch that was out there a while back. And it's out there somewhere. The way it's kind of hard to track down. But there was like this tool called prettier that would, you know, beautify JS. And then I think the mixer team wrapped it and they named it P prettier for parallelization. So it's super fast. And I've had a really good success with it. Like where other JS beautifiers will fail and say like, I don't understand the syntax here. This one normally does a really good job. So definitely check that out as well for command line based JS beautification. Yeah, that's awesome. Nice. Well, actually, I mean, we're already in the bug bounty tips section. All right. So let's let's let's keep on plugging along. Um, Jolly, you want to talk about about yours first. I just dropped down. Yeah, sure. So, um, I know like a lot of times if you're doing mobile, um, mobile hacking can be really a pain to proxy stuff. Um, and there's there's a trick that I use every single time without fail. I need to whether it's using an emulator, whether it's a physical device, you can proxy directly over ADB. So if you're not familiar, ADB is the Android bug bridge. It's how you talk with emulators and devices. You can, you know, open a shell on your phone. You can, you know, install APKs over USB, all that kind of stuff. But you can also there's, uh, there's actually you can go both ways. There's ADB forward and ADB reverse. And what this lets you do is it opens a tunnel between the host machine where you're running the ADB commands and the device itself. And if it's plugged in over USB, that tunnel happens over USB. If it's an emulator, it just happens directly on your computer. But you can do ADB space reverse. And then you give it two parameters, which is basically the, uh, connection type and the port for the local and the device. So typically that would be TCP 8080, TCP colon 8080 space TCP colon 8080. And what that will do is it'll open a tunnel from local host port 8080 to local host host port 8080 on your host machine to the device. And then on your device, where you would normally set your proxy in the Wi-Fi settings and stuff instead of setting that IP address to, you know, 192.168.whatever, you set it to 127.0.0.1. And you're not running a proxy server on the device, but there is a port that's been opened through ADB that goes directly to your computers port 8080. And then you just listen with burp like normal on local host 8080. You proxy to 127 8080. And then I just, you just have to remember anytime you open your device, you're going to have to ADB reverse to reopen the tunnel. But yeah, it's a super great tip. You don't have to worry like if you have inconsistent Wi-Fi, you have weird netting, you have, you know, any types of, it doesn't matter. It all goes over ADB. So it's directly connected to the device. Dude, this, this is a game changer. I think especially for people using Windows System for Linux too, because like the NAT that they have for this sort of setup is like super awful. And actually when you, when you were making the show notes for this and I saw ADB reverse, I didn't, I didn't know what it was. But I remembered when you started explaining it, I actually used this at the latest live hacking event for a, for a bug where I needed to do SSL decryption on a non-HTTP protocol. And the way that I did it was I knew which host it was communicating with. So I, I actually set up a ADB reverse and I put, I did a IP tables rule on the device to send just that traffic at that port at that host through the reverse, I guess what, what did you call that reverse tunnel? They used setup through with ADB reverse and then I proxy it back in through Wireshark on my, on my computer. Actually it was, it was polar proxy, not Wireshark. Polar proxy which does the, the TLS decryption for me. And I finally got to inspect that protocol and some crazy bugs got, got found as a result of it. So hopefully we can talk about this sometime. That's awesome, that's awesome. Yeah, I actually wrote a little bit about this same proxying process in the intro to Android hacking. What's posted with hacker one. So if you want some more info about this and there's a lot of other like really great tips in there, you can look up hacker one Android hacking I think would probably just find it. And there's a blog post in there that I wrote in 2020 and it's got like a lot of just sort of like that intro like background knowledge, it has some tips and tricks for like how to get information from the APK, how to proxy, bypassing SSL pinning I actually included my own three to SSL bypass script. I included a link to it in that blog post. So you can go use that and yeah, yeah, that's, you know, it's a huge, it makes things so much easier. I used to struggle all the time with like that Wi-Fi, that proxy. Yeah, absolutely dude. And also I guess that also works if you are, oh my gosh, because then if you're on a network where like for example your phone and your computer are segmented, like if you're at like Starbucks or something like that, then you can still proxy, right? Exactly. Dang, that's helpful. Nice one dude. I for some reason I never correlated that that use case.
but that's that's super helpful. Nice stuff. Honestly, where it really comes in helpful is live hacking events. Oh, yeah. The networks are so bogged down from all the traffic and all the payloads and everything. That a lot of the times it's really hard to get a consistent proxy going and like you said, you'll be segmented, you'll be on a different net or something. So this is bypasses all the other stuff. That's awesome. That's a great, that's a great tip. And hopefully, you know, definitely go check out for everyone listening. Definitely go check out Joel's blog post. But who knows, you know, maybe within the next couple episodes, we'll have a little, a little mobile brain dump from Joel on the podcast. So definitely be on the lookout for that as well. So I guess I'll go ahead and keep and keep the tips sort of cohesive together. And I'll talk a little bit about a mobile reversing tip that I stumbled upon lately. I don't know why I have never, maybe like everyone knows about this and I don't, but I was like totally mind blown whenever I found this. So obviously, you know, when you're dealing with Android, reversing, you've got an APK file, right? And inside of that APK file are our decks files. And there's this really cool tool called Dex to Jar, which will convert those decks. I mean, it does exactly what it sounds like. It converts Dex's into jars, right? And so as I was becoming a little bit more familiar with with jars and sort of like Java concepts, I found out that you can just kind of like stick jars in your class path and then just call classes from within that that jar file. And so I was like, and I was working on reversing a cryptography function in a specific Android app. And it just blew my mind because all I had to do had to do was take the Dex to jar, right? Convert it to Dex to Jar. And then put that jar in my class path. And then I could write little like scripts, you calling the function, just the decrypt function within the actual app within the actual app itself, which was like a total game changer. I don't know. I mean, have you heard, did you hear about that before I, is this just me that doesn't know about this or? Well, yeah. So I use that all the time. I got a job. Yeah. So, so I'll say like, especially with mobile stuff, because so much of the mobile apps, like, especially the Android stuff, it's all Java when you do you compile it. You can take advantage of that like, like a lot, right? Because the majority of the stuff that's being used within like the Android SE is just like standard Java stuff or there are parallels to like the standard Java Libs. Yeah. So if there's a function that's doing a string decryption or, you know, there's like, I see this all the time, there's an obfuscation where there's like a bunch of like strings, all the hard credit strings have been turned into a function call that passes in some like byte array and an integer and then it turns back some like, you know, fully formed string. Right? So the two main ways that I'll go about actually figuring out what that is, one, I'll copy paste the code into a separate job file and I'll call it directly. And I'll just make sure I have all the imports and everything. Or I'll launch the app. I'll hook it with Frida and I'll call a function directly on the app through Frida and I'll just pass it in parameters and I'll do it that way. Yeah. And both of those are great ways to like, you know, don't worry about like trying to reverse engineers and you know, obfuscated cryptography algorithm. You know, if you really want to know, maybe toss it in the chat GPT. Yeah. Chat chat. And otherwise just don't worry about it. Just call it and see what it does. You know, see what the inputs and outputs do because you know, most of the time you don't actually need to like understand, oh, this is a, you know, this specific encrypt shot 256. Right. It doesn't matter. Yeah. No, that's, that's a great tip. And I must say like the last time I was working with Joel on a, on this sort of thing, he was like, dude, you just got to rebuild the class in, in Java on your computer. And you know, because it's a, it's a VM language, you can definitely do that. And I was like, dude, but then I got to like fix all this dependency hell and that sort of thing. And I was really like not having it. And Joel was like, dude, just suck it up and do it. And so I did. And it really didn't take that long. And it was a pretty complex function too. So definitely, you know, that is one of the big pluses of Java as much as I choke on those words. That is, that is one of the big pluses of Java where, you know, it is pretty portable. And you can run it on lots of different systems. So definitely keep that in mind. Yeah. And stuff works the same. So like, even if it's not that you're like trying to decrypt something or whatever, if you're just trying to see why is this function behaving this way or trying to get more insight, you can just, you know, copy past it. And you'll find that that dependency hell, like it gets reduced significantly when you're only copying like one function. Yeah. It's a lot of the time. All those imports are for like the rest of the class. And if you just want to get one single function, you can, you can dumb it down like significantly. Good stuff there, man. Good, good, good tips. Let's, let's keep the, let's keep the, you know, ideas together as much as we can here. So why don't you, the other thing that I was going to kind of pick your brain about in this tip section is JS bridges in mobile apps, right? So you want to talk to me a little bit about that and drop some tips there. Yeah. Um, you know, typically I'm sure we've all seen this you, you know, click a link in an app and it opens like what looks like a browser, right? But it's not like opening your browser app. It's, well, it's called a web view. Mm-hmm. And so typically the app has to have some way to communicate with that web view, whether that be like a callback or a JS bridge, right? So sometimes they'll be like, it'll redirect you to a URL that URL is handled by the app. The app then takes data from the URL, parses it. The other way is that it directly communicates with the app through a JavaScript interface. So basically when you create the web view in the app, you register like all this, if you call an object called like bridge dot my function, then it'll, it'll talk directly with a Java function in the app and those two can communicate so that you can do stuff like store a system property or, you know, open a view in the, I wrote it right. Like whatever you need to do in the app, you can trigger that and communicate between the two from JavaScript from the website. Right? So that's like really powerful as a developer, but you also have to be careful about how that's implemented. You have to make sure that like you're not overly trusting whatever's being sent over that interface, right? So generally if you see a web view, it's a great idea to look and see how is this communicating with the app. If I do something in this web view, what, like why did they do it in a web view versus just opening the URL? Like what kind of date is being sent back here? Is it a login? Is it an off token? Is it just a parameter? I have seen some crazy crazy things through JavaScript interfaces. I can't even talk about them. I will say one of the largest social media apps that's out there. There was a JavaScript interface that let you do all sorts of crazy things, including installing APKs. What? Oh my gosh. That's not crazy. It's crazy things that you will find through JavaScript interfaces. So we're thinking about that. How do we enumerate these JavaScript interfaces that mostly like white box code review or are we doing something else? Yeah, so what's great is that generally speaking, they're registered all like in the same way. There's a decorator. It's at JavaScript interface. Oh nice. Like one word. And basically that is attached to any of the functions that are going to be handlers for JavaScript functions from the web view. Generally speaking, that keyword is also just something that you could just search for. Nice. Nice. And see, are they do they have other classes called JavaScript interface? Are they handling all these registers in one place? Generally, like that more complex stuff, like what I just mentioned in terms of very complex JavaScript interface functionality, it's going to be handled by some big class that's like serializing and has a bunch of commands and stuff like that. So you know, it's worth diving into. You might like definitely be in the weeds a little bit to like try and figure out like how does all this stuff work? How does it tar together? But if you're ever confused, I recommend just like starting like at this simplest step and just like try and call that function directly. One great tip is that if you have a web view open and your phone is connected to your laptop and it's in debug mode and you have 80B enabled and everything. Generally speaking, you can open a Chrome console over USB to that web view regardless of what app it is because your app is in because your phone is in debug mode. So all you have to do in Chrome is you go to Chrome, call and slash slash inspect and it will show you all the web views on your device. So if you have an emulator and you have a web view open in an app, it should show up in there. And you have a Chrome console, you can run JavaScript through that Chrome console, you can actually do like, you know, click to select elements and stuff, all that. It's really, it's really, really helpful. Okay, so let me, let me, let me break that down because that's, that's a great tip. So you're saying that if we have everything, you know, hooked up together through 80B and stuff like that, we open up the Chrome console on our, on our browser on our device or on our computer. So like say you're, you, you're using like example app, right? And you have your phone connected, you have it in debug mode, you have 80B enabled, you can see your device on 80B. If you're, if that app opens up a web view, you should then see it in the Chrome, like inspect a tab. It should show up there and you can click on it and you can open a console and it'll show like what it shows on your device in that web view. You can see all the HTML elements, you can type stuff in the console.
just like you would normally, right? So you can actually interact with like the interface you can see how it works, right? So then that gives you like a foothold. So you know like, oh, if I can get this web you to open an arbitrary URL, all I have to do is run this JavaScript and I can, that's it, right? Like, yeah. - That's a sick tip. I'm definitely gonna have to go try that out on a couple apps after this, 'cause I have not been able to get that to work successfully. So I'm definitely gonna go, go, assess that after this. And actually dude, oh my gosh, this actually goes, this is all closely together dude. This are, okay, so the thing, the thing that I was gonna, the last little tip that I was gonna throw out there today is actually something about Chrome DevTools Protocol, which is nuts, 'cause we just kind of like cluster together a bunch of little tips and somehow they all came together. So I mean, I was looking into Chrome DevTools stuff a little bit lately for some headless browser stuff. And there are a lot of cases where these headless browsers are leaving the remote debugging port open for obvious reasons for remote debugging. And there are some really interesting endpoints on that. There's a slash JSON endpoint in there that will dump all of the open tabs. There's slash JSON slash new, which when you pass in a, you just put like question mark and then put it a URL directly, that will open up a new tab at that URL and give you reference to the management interface for it. And then there's also like this whole DevTools inspector thing where you can pass in a web socket URL and it will run, it'll pull up the DevTools for that. So all of these, I thought that the JSON endpoint thing was particularly interesting because I know there are some restrictions around how many popups you can open from what events you can open a popup. And so I actually did a little bit of testing and it seems like there's some popup bypass stuff you can do there. And I don't know that it absolutely consists of bug, but obviously Chromium source code is all public. So you can go read through the source code and look at all the other HTTP handlers there. And I bet there's some cool attack surface there, some CSRFable content as well as some cool attack surface for anyone who's gonna be doing anything in headless browsers with multiple tabs and stuff like that. So definitely give that a peep if you're interested in checking out Chromium hacks. - Yeah, so I got two questions about that. So one, do you just like port scan to find that? - So it's normally, I mean, you could port scan and there is some ways that you could hit it potentially with, I wanna say it's web assembly and you're doing port scanning, but normally it's open on port 9222. That's like the defaults go to port for that sort of thing. So in the times that I've seen it in writeups and the times that I've, every time I've ever seen the remote debugging port command, it's been 9222. So that would be a good place to check for or see if remote debugging is enabled. - Cool, that's awesome. Yeah, I'll definitely be checking that on hardware devices, no? - Yeah, for sure. All right, so that's what we had for bug bounty tips. The last little thing, I was also just gonna test this out this time and see what kind of cool stuff you guys know. I was gonna pose a question. I've been screwing around a little bit with ways to get references to windows in browsers, right? And with a reference to a window, you can send post messages and you can do all sorts of stuff. And I saw this, or actually Vax William sent out or sent me a article the other day referencing how you can get a reference to a window where you know the name of it. And I tried to reproduce it and I couldn't get it to work. And actually, I'm talking to the guy that wrote the article now. So hopefully I'll get some more detail on that soon. But I wanted to pose that challenge to you guys, see if there's any way that you can get a reference to a window using the name of that window. And I think that could be really helpful as we're moving into this sort of same site default land where there's lots of weird stuff that happens when you try to open like a page in an iFrame or like a page in a window that you, you know, like cookies get, or it's kind of like a crapshoot where their cookies are gonna get sent from time to time nowadays. So I wanted to pose that question, definitely let us know. If you have any cool solution to that, you can hit us up on Twitter or you can hit us up at
[email protected]. And yeah, that's all I had for content. Joel, you got anything else you want to say before we sign off? - Now I'll just say that that Vax guy, another he hacks a ton of GitLab monster for sure. - Yeah, go check his profile 'cause he's got a bunch of disclose reports, tons of RCEs. He actually had a fair, like one week after the one, the report that we talked about at the beginning of this episode, he submitted it a very, very similar type of report. It was just another instance of it, somewhere else he saw it from the patch notes. So yeah, go check out his report. That one's also public and you can go read through it. - Go to baller. Yeah, definitely shout out to Vax and-- - Yeah, VAK, VAKZZ Vax. - Yeah, weird spelling for sure. That definitely check out his reports. And yeah, I think that's all we've got for this time. So thanks for listening and hopefully we'll hear from you in later episodes. Have a good one everybody. - Awesome. - See ya. - Thanks again for listening to this pilot episode of Critical Thinking Bug Bounty Podcast. If you enjoyed it, please give us a follow on Twitter @ctbbpodcast or shoot us an email at
[email protected] for any feedback or additional concerns. Thanks.
PodcastTranscript AI