158th episode of Absolute Absec. I'm Ken Johnson, at CKTricky on Twitter, joined by Magic Hands, at Seth Law, at Seth Law on Twitter. Seth, say hi.
Hey, everybody. Welcome back to another episode. Happy to be here.
We've got a few things to talk about today. First and foremost, I did want to... Plug KernelCon again.
Make sure everybody, if you haven't been listening to the podcast and you don't know that we are going to be teaching our secure code review course at KernelCon at the end of March. There are still seats available, but I know they are selling out. So if you are up to it, come join us there.
We'd love to have you. Those that have been asking about whether or not we're going to start doing training again. Yes, we are, obviously. So that's your first opportunity.
Not to mention that those guys put on a good conference. They've been running for a few years at this point, and it's a good little local conference there in Omaha. So come out with us and learn secure code review. Outside of that, last week we had our After Dark episode, Ken, and found another item with Laravel.io, but did have a few updates. on that front.
First of all, we did report those back finally to the development team and kind of got called on the carpet a little bit for how long it actually took us to report that first one, which was rightfully so. It took us about a month to actually report the user impersonation vulnerability that we found. They have since fixed it. They were pretty quick about jumping on it, but we did read. did have some people reach out via back channels on that they weren't too happy that it took us quite so long to get them that vulnerability um which is i i mean it's fair right like you know we're publicly putting something out there we'll do better next time around life got in the way and it was over the holidays but it's really no excuse for us not to to push something to developers especially when we publicly release it like we did um yeah yeah i mean and so you don't have to take the head hit set i had said i was going to report the first one and Like you said, life got in the way, holidays, things happen, life events.
Not to make excuses, but didn't get to it and did some apologizing to some folks. But did check out, but you know, at the end, at the end of the day, I think it went well. And ultimately, we did prevent a pretty serious flaw in their website, which they did push a PR, they did push a pull request fix for it, they merged it. So now that Not the second episode's vulnerability with not requiring a current password.
I don't know if that was fixed, but I definitely saw the PR and exchanged my feedback on the PR through, like you said, back channels and verified that the values that are being pulled out of the session were set in this session to begin with in a secure way. So, yeah, they're... they've done a, they've done a, uh, some work to fix that registration. And it looked pretty good. Um, I guess in the future going forward, I think we're going to figure out how to, uh, you know, maybe like live, we'll even report the vulnerability as we discover it, um, is one of the options we've talked through.
I don't think either Seth or I want to go. One of the things that had been talked about during the conversations we had were, um, Hey, maybe you do these privately and then, um, report them. And then when, it's been fixed, replaced them publicly.
To be clear, this was never about trying to drop O days as was the terms that were used. This wasn't about dropping O days at all. This is about how to do code review.
It just happened to be that we stumbled across some vulnerabilities as we're likely to do for reviewing open source code. And that's what we do for a living. So ultimately, I think in our... In my mind, we did the right thing in terms of reporting it.
I think we just didn't. I just think, you know, the fact that I didn't report it for like a month was my fault and pretty bad. So I admit that.
However, I think the format of doing these live publicly and if we disclose something or if we find something, we immediately disclose something while we're even on the stream is probably the way I'd rather go than trying to, you know. do it just doesn't have the same feel also again the point is not to find it's not that we're trying to find vulnerabilities although i guess that's gonna happen but uh you know it's more just like to follow a methodology show people what it looks like to do that and uh I like doing it live, man. I like doing it live.
I don't think we should stop doing it that way. So yeah, we'll do our best to report quickly, but it is open source. It is out there in the world. This is an open source podcast. We don't get paid for this.
This is our, you know, this is our hobby. So it is what it is, you know? Yeah.
Yeah. Yeah. I mean, all things considered when it first came across, I was, you know. Yeah, like, you know, I think you and I go back to that, right?
Like, oh, well, it's open source. The vulnerabilities exist, whether or not somebody actually looks at them and finds them. That's the danger. But that's also the nice thing about open source is people can publicly fix this stuff and know about it.
And, I mean, it was never intended to be malicious, right? And, you know, I hope those guys take that with it. the i don't know how it was intended right like you know i i i never want to come across to developers as attacking right as you know hey guess what your code like i i get that these guys put a lot of work and a lot of sweat and tears into the code that they release right i mean you and i have both been involved in open source projects and we know how much time and effort it actually takes to push that stuff out um and so like we're just trying to make it better right? And we're trying to help other people learn how to do what we do. So I'm with you.
I don't really want to back up on the, hey, we do this, we live stream it. I think just as notes from us, I think we'll make sure that there is a security contact that we know who to contact if we do find something before we start things and any of the live streams as we move forward so that people can see how that goes. um and how people respond to it so yeah and we could even possibly just give people uh like owners of a project a heads up that hey this is what we're going to be reviewing like if we know it in advance we could always tell them hey if you want to watch the stream live to see if we find anything go for it and uh you can fix it but be aware this is what we're going to do um and be on standby we might report something but again If the purpose of this podcast or if the purpose of those episodes, the After Dark episodes were just like, let's find vulnerabilities and mess up websites.
Yeah, I could understand that. But it's not just it just happened to be that as we're going through the methodology. Well, guess what? It works.
And if we find vulnerabilities, that is our profession. That is what this methodology is about. So it's inherent that we will find something and that something might be really insignificant and small.
Or in this case, something that. is not insignificant and small and is actually pretty serious. It's going to happen. So we'll do our best going forward.
But I think we'll stick with the format. I like the format. And I think it's pretty real, pretty raw. And that's what this has always been about, being real and being practical.
Yep. Yep. But I did want to give them kudos for how quickly they fixed the vulnerability. The PR went in within a few hours of us actually reporting it.
even if we didn't hear directly back from them, only through back channels, they did a good job of eliminating the vulnerability and it no longer exists. Okay. That did bother me actually, is that I found out from everybody, but the actual people we reached out to that they were upset.
And that probably is the thing that did, the one thing that kind of out of this did annoy me was probably that the most. I wish the people had reached out so we could have a conversation. But in any case, we had the conversations without them. the software got fixed uh we reviewed the pr it is what it is right yeah yep yep so uh you know we'll let everybody know when we're doing another after dark episode um you know we'll decide if we want to keep going on the same same code base if we pick something new uh but um as as always jump into the slack channel let us know if there's a project that is near and dear to your heart that you would like us to look at and like we Like Ken's saying, we don't always find things when we do source code review, right?
Like professionally, yeah, there are those apps that we find hundreds of things. And then there's those apps where we'll find like one small misconfiguration. And it's about the process.
It's about learning how to do what we do and knowing that we've actually done our due diligence. I'll say this. After having reviewed...
the Laravel framework a bit more. You know, if I wrote PHP, I'd probably use this framework. So for what it's worth, because what we found for those who hadn't seen the After Dark episodes, that wasn't like something inherent to the framework.
It was just a... their website, which is built on the framework, their community website, it's built on the framework. And in the community website, there were, you know, vulnerabilities written there, but not it wasn't in the framework itself.
So but also just like the framework, the way it's structured reminds me very much of Ruby on Rails, but just for PHP. And I feel like we've talked about that quite a bit. But whenever you have an opinionated framework, where things are kind of structured in a specific way, it's usually easier to like write tooling. um to find things because you know where things are going like literally the source to sync flow you know where uh configuration files are going to be it makes it much easier to when it's pretty uniform um which you only really get those things from an opinionated framework which is what laravel is so to their credit pretty cool yeah yeah it seems to do pretty well it makes me wonder if somebody's actually started to build a brakeman Style scanner for Laravel.
And I mean, you and I, neither of us claim to be PHP experts, right? Like the last time I coded PHP professionally was a long time ago, but I have seen a fair bit of PHP code and crappy PHP code over the course of the last 15 plus years. So it's nice to see that it has come a long way, right?
The only time I've professionally coded PHP is when I'm writing web shells. That counts, right? CMD, PHP open. I can't remember. Yeah.
That's about the only time that I literally have ever written PHP and gotten paid to do it. Ken, Ken, Ken. Good times. But anyways, whatever.
Whatever, whatever. Well, it'll be fun. I mean, I think. We'll determine what we're going to review next for, maybe we'll leave Laravel.io alone for the next one and find a new one. So if anybody has any ideas for things they'd like to see reviewed, and just to cover the guidelines, if you'd like to see something reviewed, do not submit us code that is from your, from like a private location for, you know, something that is, yeah, used to make money.
professionally or as sensitive in any way just give us a public repo of a you know public resource preferably a web app um and uh we'll do that i did want to mention um since you just put that colonel khan lincoln seth that uh cactus khan is in feb the first week of february heads up you do need to be uh vaccinated to attend that conference um so uh you know that's just a requirement i guess they put in so just be aware that if you are going to do that that you you will be required to have that if you want to attend in person otherwise virtual options are there they're doing a mixed um virtual and in-person conference uh but yeah that's like february 4th and 5th i think maybe yeah it's a couple couple weeks away right that's that's pretty quick here yeah yeah um but that should be a good one as well right like just looking over it Yeah, I talked to Andrew and, you know, there's obviously they're having to deal with, you know, the current state of the world and, you know, different people's risk tolerances and preferences and, you know, everywhere in between people fall in that spectrum. So it's been actually really hard for them. But I just want to say, like, I really appreciate that someone's willing to try to put back, get us back on track with physical in-person conferences. So thank you to the CactusCon. organizers and Andrew Wilson for at least trying.
Yeah. Yeah. I know it's, it's been anyway, it's been odd, right?
So. Odd and contentious, but here we are. Here we are.
Here we are. We're here. Cool. All right. So from a news perspective, first thing I wanted to call out today was the list.
Dum, dum, dum from Portswager. uh they've um released their well they haven't released it but they are allowing people to nominate uh top 10 web hacking techniques for 2021 so i just dropped it into the chat here we can highlight it here for a minute and we've talked talked looking through this list ken we've talked about i don't know most of these over the course of the last year right um everything from some of the web caching that you know the new stuff from kettle on request smuggling XSS, AppCache. Like I'm looking through the list and there's quite a bit here to actually take in.
I see breaking GitHub private pages for 35,000 on there. Yeah, let's highlight that one. We'll bump that one up, right?
Yeah, there's quite a few. What else stands out to you in that list, right? If you're looking through it.
um stuff that we i'm going to talk about stuff we or i'm going to mention stuff we have not talked about okay i guess i'm interested just if i'm just literally looking at the headlines like xss to rc and opera is interesting just because i'm like i can guess how that's happening but yeah i'm curious how that's happening i guess like uh the anything that has to do with http2 so the sequel is always worse that's interesting i i actually i think we did talk about prototype pollution Right? Or no? I can't remember. I can't remember now.
We'll have to look into it. I don't know. You know, one I hadn't seen is the universal deserialization gadget for Ruby 2X and 3X. So that is interesting to me, just looking through this. Well, Marshall load, we always know that's vulnerable, but they have a safe load option for Marshall.
But yeah. Well, if this is just about Marshall, then I'm not that interested, just because we've known that for a long time. Just a quick skim. It goes into great detail.
Since the channel is blah, blah, blah. For a few... They're using deprecated instance variable proxy. You know what?
We did actually talk about this. I think we have. Man, we've done so much.
Gosh, we've just covered so many things and had so much content. It's hard to remember. I love my little humble brag there, but yeah, just so we're just so great, man. We just done it all about it all. Yeah, no, but we have talked about so many things.
It's like hard to remember sometimes what we talked about. Yeah, no, no, it is. I find I have to go dig back through the episodes to see.
Oh, I remember having a discussion or reading that article at some point. And then I have to go back and listen to remember what what it was we actually said. What was our opinions back then?
Yeah, exactly. My opinion was literally like a month ago. Exactly. It could change day to day.
Yeah. I don't know. All of this stuff is pretty interesting, I guess.
Yeah, I don't know how I would actually vote on that list, to be honest with you, without going back through and reading. I mean, obviously, like this year, when I really think about 2021, and I know we kind of did, hey, what do we expect for 2022 last year? or last episode, right?
But we never really did a 2021 year in review. And that's where I'm kind of going with this is, I know we've talked quite a bit in the last year about package managers, right? And the attacks that are going on there, the supply chain or software supply chain attacks that are happening via NPM and everything else. We talked a lot about request smuggling.
We talked a lot about caching vulnerabilities, right? If I was to highlight kind of three main, I guess, vulnerability classes that popped up last year that we've spent a fair that I can remember us spending a fair amount of time discussing. Those would probably be the three that I would bring up unless you've got something else.
No, no. And I was looking at the like what they what the I'm trying to say what the qualifier what the qualification for nomination should be. And it looks like it's a. a novel technique that can be reapplied. That's the caveat.
So it can be reapplied to other systems. Now, I think anything that's deserialization related, prototype pollution, those are pretty generic things that can be reapplied. Like maybe bypassing 2FA using an open ID misconfiguration. My guess is maybe there's a bypass for other 2FA systems or a bypass that can be reapplied. It's just a guess.
caching anything caching related is probably going to be something that can be reused um but but a lot of the the opera stuff i would say i wouldn't although it's interesting for me to read on uh probably not you know a lot of it's like rc or local file traversal or some something like that and it's kind of like okay well that's opera and you know what it's not not not you know there's like three opera things on here so it's like i'm not super interested about and how that would apply to other browsers i guess um uh i guess fuzzing for xss is i i guess if i cared more about xss i would probably be more into it i don't know man i think like if it's yeah if it's probably something to do with http protocols something that's like a serialization issue anything that's like um yeah just reusable essentially yeah yeah well and that's yeah yeah no i mean there's a couple things here around like Basically supply chain kind of stuff like the RCE and Homebrew by compromising the official cask repository. Anything that's in a supply chain attack, I would say anything that falls under supply chain attack is probably a good nomination because that's, I mean, we gave our predictions for this year and we expect to see more supply chain attacks. So yeah, you're weird if we didn't mention it. Yeah. Yep.
So yeah, I don't know. Right. I mean, part of me wants to.
Should I nominate making a nomination? Oh, so is the nomination just like, oh, that's now phased for further information. So those are the nomination. I guess they've got a panel, right?
Launch community vote. So that should be launched here, right? Like the community vote, if you want to vote.
Right. Hmm. Clicked email addresses, Port Swigger on Twitter. So follow Port Swigger Res, or research on Twitter, if you want to actually be able to vote on, you know, the ones that you consider to be the top 10. I think that's where they're going with that. Yeah, there's a lot there.
Like I'm overwhelmed a little bit looking through the list on, you know, what we should talk about. But yeah. Where do you want to go with that? Prototype pollution.
I got completely distracted as you were talking, looking at those articles, Ken. Sorry about that. Oh, no, no, no. It's all good. I'm thinking like for me, the HTTP2 one's probably the one I would sort of nominate just because this is where they talk about, what is it?
Smuggling, request smuggling. desync attacks, stuff like that. And in my mind, that is an area that we have less stuff built for, frankly, on the defender side of things, both to test for, detect for, and prevent.
And I guess what I'm saying is it's an emerging area, and I expect there to be a whole lot of additional attacks that come through with between... um http2 but also just like uh distributed service oriented architecture type systems so i've been beating that i feel like that that's been beaten to death over the last couple months by us but i'm not going to stop because i think it is like going to be the the thing this year besides supply chain attacks that really comes to light and maybe we see new testing methodologies built for uh these things um more tools released whatever more research in general so that probably might here i'll put it i'll put it in here this is this is the one i think is is a in a very important one yeah yeah i it definitely is right like and there's i'm expecting more to come out of you know james kettle on that one right uh and other sources as well but they they keep you know picking at that and looking for different ways to exploit it and to smuggle requests and microservices the way that we're actually set up nowadays to deliver software this is going to be a and it's going to be a large problem a large surface for the foreseeable future i know it's gonna be weird though for them to have their own research as a nominated uh you know article um i don't know about you but i'd be you pretty self-conscious about that. Like if my own research was included and it's good research, but it just happens to come from the same folks that are maintaining this list. So, um, but I would have nominated it to begin to, even if it was somebody else. So yeah.
Um, but no, man, I'm, I'm excited for what this year is going to bring in terms of, uh, vulnerabilities. I think we're going to see some cool stuff. Yeah.
Well, speaking of supply chain attacks, and I know I didn't pop this one at you before, but, um, This Medium post from Hacker Noon that, you know, I don't know if you've seen this, right? I'm trying to actually copy. Let me inspect that so I can get the link. Because if you don't know, like with our platform we use for this stuff, for those listening, I can't, you can't just, I can't just like click on the link he puts in there or he can't click on my, whoever puts a link in there, you can't just click on it. So it's like, can you just send that in like absolute abstract Slack?
Cause I can't. Yep. I'll send it on or I'll drop it there.
Oh, I see it. Oh, okay, cool. Yeah, I see it. Let me read this. I actually like reading things on the fly because then I if I don't have a good opinion and it's not fully formed nobody can blame me be like well I just read it two seconds ago uh it's been a fanatic frantic fanatic frantic week uh security vulnerabilities spell pwn wrong but okay um patient form element card number that's what blurs meant and that uh And of course, when I wrote this code, it has this attacker injector.
Yeah, XSS. So if it was my distribution method, I would need to come up with some borderline. I'm pretty sure.
Yeah, it's entertaining, right? Because it settles on NPM as a distribution method, writes a package that basically just changes the color of your console output right right and then pushes it out but it it contains uh code that looks to see if there's something interesting on the page and then sends it off somewhere else right um so oh so is it looking for forms like html on the page that has like credit card number or something interesting and then it yeah If the page contains words like credit card, checkout, login, password, element matches, card number, password, whatever, right? Takes all the data from those form fields and posts them up to send it off to legit-analytics.com, right? They did make a pretty wild assumption here, which is that since they're trying to bypass CSP for...
for sites that have CSP enabled and then it wouldn't make it possible to exfiltrate easily. The, the contents of a form element, um, they, they, they did say, Oh, well, if someone's sending their, uh, failed stuff to report your eye, the report, your eye endpoint for CSP, then they're going to see what I'm doing. Fair point, except for in practical world.
And I know we're going to have Neil Medital on next week, uh, in the practical real world, nobody's checking that report. report your eye. If you've ever tried, you can ask Neil about it.
It's just too much, too much data. And maybe if you're like a small website, maybe, but man, even then, I think you're not going to find super anyways, whatever reading, reading, going through reading more. That's just something that sticks out to me.
It's like, nobody's checking report your eye. Don't worry about it. Well, I mean, the other thing that he's got is the prefetch that CSP does, right? Is he's actually putting the data into the prefit.
Pre-fetch, right? Oh, which one of our articles today is about pre-fetch and some stuff in Chrome 98, but we'll save that. Yeah.
So when checking your CSP and checking it twice, if everything else is locked down, but I don't see form action there, I just go and change the action where the data is sent when you click sign in. Oh, boom. Thanks for sending me your PayPal username and password, pal.
I'll send you a thank you card with the photo of stuff I bought with your money. Perfect. how to stop okay option one that's funny that is funny so that the what can i do to fix this the option one uh or it says okay i'm sufficiently concerned what can i do option one just a picture of a log cabin in the middle of nowhere not connected to anything oh man some days that's where my head's at anyways so cool uh option two edit i've detailed this in a follow-up post part two how to stop harvesting credit card numbers and passers from your site So there is a suggestion there.
So how did they get past the CSP? So I guess CSP will disallow certain things, form action being one of them, if you've locked that down. But see, the fact that he's combing the page first, and then he's doing a prefetch request with that data in it, right?
So even though it's going to be shut down, that it's not going to make the full request. it's still going to do the prefetch it's still going to do the lookup right and send that url as a lookup so uh yeah basically that's how they're getting around the the csp um basically he can read what the csp is going to be and then yeah excuse me uh work around it interesting wait get okay am i wait hold on am i reading this right it says using this method i took over trump's twitter account started sending out all sorts of weird shit and yet no one has noticed yeah i don't know man like yeah who's this david gilbertson oh a serious note right down at the bottom this post is entirely fictional but altogether plausible oh okay because i'm like what that can't be real yeah at that point i'm sort of like when i read that i was like wait something doesn't feel right a second and i never got down that far right i'm with you so I know that sometimes my relentless sarcasm can be difficult to unravel. Okay. All right.
There's no shortage of smart and ask you out there. Okay. So it's a hypothetical post.
All right, cool. So that's, that's, but I mean, to be fair, you know, technically it doesn't seem like. No.
Well, and that's just it. Right. Like that's, I think that's why I put it together because each of those different steps, I can see that happening. Right. Like it's, you know, for the last five years you create a little package i mean look at what's happened in the past week with what faker and whatever those two packages were right like your color faker js and color js i think yep yep yeah and yeah i mean we've always talked about that rim raw fall package that was in the in npm years ago um that actually did the rm minus rf on your you know on your package um By the way, I'm glad you brought that up because I when we originally were talking about color, J.S.
and Faker, I did not know that that person who wrote that code that like was kind of a middle finger to corporations. I didn't realize like they had a history that was documented of like mental health issues and like had tried to make a bomb or something like that, according to that news page. So I didn't know all that.
So we. When we were talking about it, I was thinking in the lens of this is somebody who's just taking like a hard. I didn't know all that. So for whatever it's worth.
Now I know that. And so the context is really different. It's really at that point, it's probably just a lone person. I don't expect this to be a trend at the time.
I think we were why I say that is because at the time we were talking about like, is this going to become a trend? Like, I hope not. But now knowing it's like kind of like an isolated. This person had like kind of a moment. Yeah, it isn't as serious as, well, you know what I mean?
It's not a, I don't predict it to be something that's become like a trend. That's what I'm trying to say. Yeah, well, I don't necessarily think it, well, yeah, well, I, yeah, I mean, what actually happened there probably wouldn't necessarily repeat itself in the same way, but it's all that trust that we put into, into play.
uh with the mp with npm with any of the package repositories that's where it i think that's where it raises alarms for me and you is um there's always going to be bad actors and and to this post point right like there's 580 000 packages in npm not all of those are going to be uh not all of those developers are going to have the same values that you and i or that anyone that the developer does so You've just got to be careful about what you're pulling into your package. But it's also difficult because, yeah, I mean, we've discussed this at length, right? Like the packages that you depend on depend on other packages that you may or may not realize are actually in there. And, you know, how deep does that actually go?
Where's that code actually being written? Who develops it? Who are you trusting?
I don't envy the guys at NPM or over there that work for your parent company anymore. or yeah on the amount of work you have to put into protecting that ecosystem or any of the package repository ecosystems because that's a difficult problem to solve i could tell you i work with the folks at npm literally multiple times a week and um man they are awesome developers they're even as good or even better people with great intentions um and i gotta say their job is stupid hard. Like it is not easy. And, but I'm glad somebody is doing that work, but yeah, it's difficult. It's not, it's not easy.
Full disclosure, you know, like I said, I work with them. I work for GitHub. I feel like I have to say that now because of that whole legal requirement.
Now, if you talk about a service, you have to like say that you're anyways, whatever. But yeah, no, they're great people. I think they're amazing and not an easy job.
I'll say that. And especially the more popular you become as a package manager, the more people want to attack you, right? The bigger that gain becomes if you're able to attack the ecosystem.
So it's just, yeah, it's tough. It's very tough. And again, a lot of this is about trust.
I mean, there's so many signals to sort of that you can use to determine trust. But at the end of the day, you still have to trust someone. And, you know, hopefully most of the time it works out well. Sometimes it doesn't.
It's just a risk and reward. Yeah. Yep. It really is. I don't know.
I always go back to the what Matt module counts dot com. Right. Yeah.
It's interesting to me to see the amount of risk that we just take on a daily basis. Right. And to Hacker Noon's point. you know that article that's basically what he's trying to call out is the fact that we're so trusting of code that we don't know what actually what it actually does and then he does call out the point that right like whatever's pushed him to npm is not necessarily what's out on github as the open source repository it's easy to hide things in packages there's multiple different ways that you can go about exploiting that trust that people have you Well, yeah, it's interesting. I mean, really, by that list, it looks like NuGet's like the biggest package manager, the most used, unless I'm reading that wrong.
It's average growth wise, right? There's the most packages getting pushed into that right now. But I mean, NPM, right?
NPM and NuGet, basically, that's what it's saying for the last week, are the most active, right? By double almost in.NET and NuGet. which is interesting. I wonder what's going on there that we're seeing so many new packages pop up. Yeah, no, I'm curious.
Like, well, that's, yeah, that's bizarre. Yeah, because I was doing a quick search of like nougat hacked or nougat packages hacked. There have been some things, but it doesn't seem like it's as a my god i'm sorry i got distracted there's the biggest bernese mountain dog i've ever seen in my life outside my window right now holy wow it's as big as the person walking it wow anywho um back to this new get uh is micro supportive mechanism yeah well we know that um well it's interesting because actually today there was a dump of something like a hundred thousand packages no not quite 70 80 000 packages wow Like that's why the count went up as there was just like a huge increase of, well, no, it was like 30,000 packages in a single day, which makes me think that there was a version push or something like that into NuGet.
And that's probably why. I wonder if you go into the last 90 days. I haven't tried to push to NuGet, but I wonder what kind of credentials it uses for that.
I'm about to go down a rabbit hole. Probably should just back away from that. Yeah. Yeah. If you look at NuGet, it's pretty steady.
And then within the last week, all of a sudden it spikes up the number of packages that are in it. Yeah. Now I'm looking at security advisories for... Anyway.
All right. Okay. I'm going to back away because I'm going to start going down a rabbit hole there.
Before we hop off, because we've been on for almost 40 minutes, I did want to cover, if we have time or if you're cool with it, the Chrome. Yep, let's go for it. Let's go for it. That was interesting. Another Port Swigger article here.
I don't know why I'm putting that up. People will just have to copy it or click on the link. That's too long of a URL. So the gist of it is that Chrome is trying to prevent C-Surf attacks on internal network resources. So a lot of this stuff around like, yeah, just using, abusing people's browsers to send requests on their behalf.
The example they show is like a... I don't know if it's actually in the article or if it's in the RFC spec that they linked from that article. But the idea was like, let's say you have a page with an iframe.
That iframe has a URL in it that submits a get request to say like, you know, admin, admin at some local internal resource with a parameter that then sets some sort of like, I don't know if it was a DNS setting or like a firewall. opening a firewall port or whatever it was, but it was something like that where, you know, just a simple get request would have made a change on this internal network management system. And it would be a security hole because of that.
So the idea is, and to prevent that, what they want to do is they want to first do a prefetch, determine if that asset is less public than where you're, than the site that you're browsing is. And if it's less public than the website you're browsing, it will not make that course request and therefore will not allow that C-SERF request to go through. That's the basic gist of it. Sorry, they use the course pre-flight check to prevent the C-SERF request. So then the question becomes like, well, how do you know what's up?
Because I was curious. I was like, well, how do they determine a private network? Basically anything that has a private app. address space when it's resolved so they do like the uh the whole dns um look up see if it's a private network if it's a private network but you're like i said you're browsing a public network space then it's not going to allow those requests on through that so what are your thoughts on that seth what do you think of that do you do does that raise any spidey senses or do you feel like that's a pretty good control what are your thoughts yeah i like I, in general terms, and I'm just reading this too, right?
Like I haven't been through this article. So my general thoughts initially, exactly what you were saying, like, how do you determine what that is? There's still obviously going to be issues with DNS confusion, right? If there could be some way to actually insert something in there.
I'm wondering how Chrome's going to interpret that. access control allow private network right like if the site itself doesn't have that it looks like it's defaulting to false which is what you would want to see well um yeah so right because there is an access control allow private network header and if it's true if it's true then it's actually allowed right so the pre-flight actually checks to see whether or not, yeah, that's going to allow that request to go through. I start to have questions about pre-flight. I'm going to be honest, right?
Like we see those requests go out all the time and the data that's involved with some of that can cause, right, depending on the application that's being called, like internally. Preflight requests may actually end up doing just as much damage as a full request. I don't know if I'm just like being overly pessimistic on how the preflights and the prefetch stuff actually happens. We've seen preflight abused via timing attacks to enumerate resources. So I don't disagree that that's maybe not bulletproof in that way.
I mean, that's not the hole that they're trying to close with this. No, right. Absolutely.
It is. This is a wide swath or an attempt to eliminate kind of a class of vulnerabilities that we're seeing abused to do things like change firewalls and like internal network devices, IoT devices that probably just don't have very good security built into them. I mean, if you can trick the browser into its DNS lookup.
resolving to a public space, then this protection goes away. Yeah. Which I'm sure there are. I mean, I haven't really thought through the entire thing. I just thought it was an interesting proposal.
But I mean, these are the ways we're talking about. Theoretically, you would bypass something like this if it was in place. Also, does everybody use Chrome? Well, if you look, right, that's the problem is that Chrome is now the.
the 500 pound gorilla in the room when it comes to yeah what's actually out there between chrome chromium i like we yeah anyway didn't we have an article about that a couple weeks ago that we talked through about how chrome is the is the one right the one true browser right now i think we might have you sure it's not opera just joking yeah um no it is the primary you're right i mean it's absolutely like the the uh the beast but i'm just saying it's not um it's not foolproof obviously there's other browsers and i think also like like i said if you know i don't know how the browsers determining where it's going to i'm assuming it has like a list baked in of like acceptable dns servers it's allowed to resolve to but it's just like anytime there anytime dns is involved i just feel like there's maybe a hole there you know it is dns after all so yeah i i mean we are built on you know bailing wire and duct tape when it comes to dns as it is right but Absolutely. Yep. Good times.
Good times. So apparently we're just going to become app sec nihilists and call it good. Where's Stefan when we need him? He is on PTO. That's right.
I know. I know. Yeah, I'm interested to see how this actually works. As far as going back to that article, though. right um yeah me too it'll be interesting to see what shows up in dev tools if it if it actually affects you know that much as far as what we you and i do on a day-to-day basis probably not but i can see it affecting kind of the some of the red team activities that are happening um like pages that are being built targeted you know phishing vishing whatever you want to call it attacks um to change network access.
I mean, overall, I think it's a good thing, right? The improvement that we see in those browsers to prevent people from doing dumb stuff or developers using old tech. I think it's good. So I want to say Mike West is involved in this. He's one of the authors and I highly respect Mike West's work here in the space.
Also, but the second thing is the DNS So they actually have a note about DNS rebinding here. I'm just going to read it verbatim. The mitigation described here operates upon the IP address, which the user agent actually connects to when loading our particular resource. This check must be performed for each new connection made as DNS rebinding attacks may otherwise trick the user agent into revealing information it should modify. So this is to your point where you said, I wonder if introducing this could lead to other...
issues. That's why I was kind of bringing up the fact that we've seen pre-flight requests used to enumerate assets, internal assets, or internal endpoints. In any case, that's what this section is about. And the modifications to this course pre-flight cache are intended to mitigate that attack vector. So fairly interesting.
I guess what I'm saying is they've already thought through some of that. So that's great. I assumed they had, but...
also seeing mike west involved like makes me feel better um or is there no mixed content does not prevent secure contacts from fetching resources from origins whose host is local host or an ip address in the uh local host basically ranges see also edition i wonder also like yeah forget that that would work um yeah i don't know this is a hard one to unpack It is a pretty substantial change. HTTP cache. Cache subresources are not currently protected by this. Cache subresources are not currently protected by this specification, even though the HTTP cache remembers the source IP address, which could be used in the private network access check algorithm.
So cached. Sub resources, maybe not so much. I don't know.
I think we have to dig into this. There might be some ways that it's still vulnerable. This sounds like a good, for those who are watching or listening and are a researcher, this seems like something you'd want to dig into. So check out private network access under the W3C spec.
I'm going to link it here separately from that article. And yeah, I'd say start taking a look at that. It's pretty interesting.
Yeah. hmm yeah like now i'm digging into all of this right Yeah. Yeah. It's interesting. Yeah.
I don't know. I mean, the more that we expand out, the more that we try to set up these guardrails, right, for security. I mean, in general, I think this is a great thing, right? I just, yeah. And as long as we've done the proper threat modeling, it looks like they've done some tests the last couple of rounds of Chrome as well on it.
seems to be working. Like most developers probably aren't going to ever see this, right? I mean, they're never going to run into this because it does have a very limited or it has a very specific attack pattern that it's going after.
Yeah. And also like this, you know, you are, you are, you do have to put this on your, your website, right? As an admin. or as a developer, you do have to actually include this in your...
So I'm wondering if there's going to be a plan to maybe then inside of like, say, like a secure header style library or baked into frameworks, if this is going to be a default header that they just include so that it's just on by default. My guess is no, but that would be... I mean, I think with a security-centric library like secure header, sure, but like...
just standard default out of the box, who's going to be thinking to do this. So I feel like it would have to be pushed as a standard response header in most frameworks, unless I'm completely misunderstanding, which is totally possible. Spent all five minutes on this article, but maybe 10 minutes.
Yeah, I think that's what it like it defaults to closed, right? So basically, if you don't include that header, then that public site will not be able to make that request, which is what you would put. what you want to see i see so you have to declare the false in order so you'd actually it's the opposite way i'm thinking that by default it's true by the browser and then it unless it sees that header with a false then then it will allow it through but um otherwise it's going to assume that you meant to put that header yeah and then on your site true i guess is that what you're saying i don't know no i i think it's opposite right like i think if if the header is not included it won't allow access, right?
So if the header, yeah, if the header is there and includes the true tag, then it does allow that access. That's sorry. I meant true, not fog. Yeah. Yeah.
Yeah. Sorry. A little brain fog today. Nope.
You're fine. That's that. That is definitely what it feels like. Right. Yeah.
Cool. Cool. I mean, it's, it's, it's improvement, right?
Like, and yeah. We'll see. We'll see how it actually actually comes about in reality here and probably the next couple of weeks because it looks like it's pushing out. Whether or not we dig into it will be a different question. But if somebody wants to do some research on it and present it to us, that would be great.
Yeah, absolutely. Yeah. Actually, you know what? We should. I have a couple folks that I'm supposed to set up.
I have three different. Well. uh four technically but anyways i i'll put i'm gonna add to this list that's right in front of me mike west so because i actually would love to get mike's west on here and ask about a couple specs and just you know in general get to know introduce mike west to the broader public i don't feel like um i feel like usually these days like bug bounty people uh researchers with hacking techniques those are the folks that you see discussed more widely Um, and I feel like people need to be a little bit more, uh, or made a little bit more aware of folks like Mike West who does incredible work behind the scenes to help, um, keep you safe. So more defender, uh, sort of love there. Yeah, definitely.
Cool. Um, let's see. Yeah, we're, you know, we're, we're pushing it up on time today, Ken, but, um, so I don't. I don't, I don't know if we want to dig into anything else. I think anything else we pull up is going to take us more than a few minutes to, to get into.
Yeah. So I guess just as a reminder, we just tell people what's going on next week with Neil and then just like where we'll be and stuff like that. Yeah. Yep.
Let's go for it. Yeah. So next week we have Neil Matital joining.
I'm sure we'll talk about CSPs because that is Neil's bread and butter. Right. but I'm sure it'll be interesting to see what else he's been working on.
I know you work pretty closely with Neil as it is. No, I used to. He left GitHub just to pursue. different things, to be honest with you. And that's, I think, what he wants to talk about in some of his pursuits.
So I'm excited about that. I know we got Mike. Mike McCabe is going to come back on.
We've got a couple surprise guests. And I'm working on something along the lines of that surprise avenue. So it's 2022. Time for me to get it together on scheduling guests again.
And that's my goal. So our goal. Our goal. Yes. Oh, we are starting work on a, you know, getting into AppSec blog post that's going to be coming out.
That was one of the things that was suggested to us during After Dark is one of the guys that joined up, you know, had some questions. So we're going to be pushing out that, trying to actually refocus on putting some content out on the website that's not necessarily related. specifically to the podcast, but it's just application security related.
So watch for some of that as we get some of those posts together, we'll start promoting them outside, like on the podcast, obviously, but outside of it as well. If you want to get involved in any of that, join the Slack channel and yeah, start, let us know, right. We'd love to have more people involved.
Absolutely. Yeah. Cool. And also we'll schedule another after dark episode.
Cause those are very fun. I would love to continue down the layer of L. I. O. Route. I do feel like maybe that is unfortunately not a good idea. So we'll probably have to choose something else.
So again, if you email us with ideas for things you'd like us to talk about, not just during after dark episodes, like, well, let me split this out. Email us at info at. absoluteappsec.com. Again, info at absoluteappsec.com.
If you would like to do one of two things, one is to suggest a topic or a speaker that you'd like us to either talk about or have on the podcast. The second is if you have an idea for open source software you'd like reviewed live on our third episode of After Dark, we will take those suggestions and you know, take a look at whatever is suggested and pick, pick from that lot. If we don't get any suggestions, we'll just figure out something ourselves, I'm sure.
But yeah, we prefer people give it to us so that we can just sort of like go blind into something and show how the framework or the methodology we use works. Yep. Yep.
Cool. All right. Well then everyone, we will talk to you all next week at the very latest and yeah.
Happy hacking, I guess. Right. If that's what you're doing.
Or happy defending. Happy whatever. Have a good week, everybody.