Episode 63 - MediaTek BootROM Broken, Free Coffee, and an iOS Kernel Exploit
< Back to post
This transcript is automatically generated, there will be mistakes
Hello everyone. Welcome to another episode of day Zero podcast. I'm Specter with me is zi in this episode. We have some work from Google pushing to secure open source, a mediatek bootrom exploit acting Nespresso smart cards for free coffee details of an iOS Colonel bug and some other miscellaneous topics that are mixed in there before we get into those though. I will quickly shout. I'll be doing a stream with teams are again this week. I believe we haven't nailed down a date yet, but you can follow us on Twitter or join our Discord. That's where we post. It's all of our
updates. That'll be so your PS4 stream again. Yeah, yeah. So how far along are you guys in that? What's the
update? So we were working at an exploit strategy. We got some more details worked out on the last stream with a team star managed to figure out a little bit house layers gobies POC work. We definitely ended off with some questions though. So I think hopefully by like the end of the next stream we should have like a promising exploit strategy somewhat implemented. We probably won't have like a rope chain down and everything but I think we will. Hopefully get a an exploit strategy like fleshed out in the next in this week stream. So
okay. Yeah, if I recall correctly you did have it crashing already,
correct? Yeah, we had a crashing. It's not the crash we want and we're gonna an assertion Panic or something like that. But yeah tune into our Discord in our Twitter. That's what post their closer to when it happens. I'm thinking it'll probably happen Wednesday or Thursday, but will let you know. On those channels, but yeah, we'll also showed up that zi you made a blog post last week. I shared it on the stream, but that it was like the day after the podcast. So I definitely think this this blog post will be interesting to people with some of the podcast. So I'll let you talk about it a little bit and yeah and quickly
shut it out there is yeah, there isn't a ton to say I mean the title that's pretty much everything getting started with exploit development. We've had that Exploit development or resource for exploit development while not dying from covid or whatever. We called it. We've had that for a long kind of link that out. But I've kind of just felt like we needed something a little bit more structured and especially after our discussion video about hacking the art of exploitation where I've kind of start moving away from oh recommending those older books basically I wanted to put something together that had you know just a bunch of free online resources that I think I need to do the job better and just walk through at least my thoughts on and they getting up to where I'd kind of consider intermediate exploit development yeah I mean
it's it's not uncommon to find like resource Tums with just like a bunch of links but I think we're you go through and explain like the purpose of including each Lincoln where you go from there and like the overall flow I think that's like really valuable and I haven't really seen many other resources that do that so
yeah I mean that's that's honestly a pet peeve of mine is just having a having a resource top like here's a bunch of books nobody's going to read every book on the Some people will but they won't know what they're supposed to get out and they'll end up wasting a lot of time. So I do kind of pick and choose like several of these resource. I do just say, you know go right through but like I bring up home College just like particular modules in it and mention kind of what you're specifically trying to learn from each of these. Which I think is at least more useful for somebody especially if you already know a few things you can figure out where you need it or where you can skip to. It's kind of another aspect of that. But yeah, I I want to kind of get it out there and I think we do plan to kind of follow this up with something about and it making that jump between and doing CTF or toy binaries and moving to more real-world exploitation, but figure we'd kind of start off with the basics.
Yeah, bridging that Gap is is challenging. So I think it's definitely the work doing another piece of content on that at some later point. But yeah, so anybody out there who's been like looking to get into exploit Feldman wasn't really sure where to start it or or just wanted more resources to look at take a look at zi zi blog post. It'll be in the link in the description of the video also link it in chat for anybody listening or anybody watching live on Twitch. But yeah, definitely check it out. But with that said though, I think we can get into some news topics so we can talk about Google's no prevent fix framework. So Google put out a post about this framework for trying to tackle vulnerabilities and open source, you know aiming to build a consensus on the meta level when it comes to fixing vulnerabilities and getting those vulnerabilities fixes shipped and increasing transparency and review for critical software. So the goal the ultimate goal here is to try to increase Security on the supply chain side of things as they point out. There's a lot of software that uses dependencies, which the people using those dependencies don't know the code base of or sometimes don't even know the existence of looking at you knowed that there's people who install like node packages and have dependencies on other node packages, which have their own dependencies and it's hell trying to figure out like what parts of your code Code are potentially vulnerable because of that. So that's where Google's kind of coming out here with their no prevent fix break down. So that basically comes down to know about the vulnerabilities in your software prevent addition of new vulnerabilities and fix or remove vulnerabilities, which is a very high level overview. I will say
yes high level It's basically just trying to break down the way of thinking about vulnerabilities for open source software. So make sense to be high level. They're not pulling into specific applications of and they kind of just lay out. I think what's more valuable? This post is more they lay out something goals, which they kind of find to reach through each of these points like as a goal for knowing your volumes. So, you know having kind of precise vulnerability data available a standard schema for or describing those vulnerabilities or like a vulnerability database. oh and they go on to the other ones the critical software one is I don't know how I want to say this. I was a little bit little bit concerning I guess and that just a wariness about Google and kind of their control over everything. I mean, I don't feel like Google should be dictating the terms for open source software and how it should be developed and I was kind of thing about that as I was reading through the Stockman's like, oh no, no how much control I really want to see Google having to Define all these terms and defined what happens. at the same time they makes absolutely valid points. I like I don't think Google is really off base in any things that are talking about here in any of the issues that they're seeing like that all seems accurate. I just kind of look this. You know, how much control are we going to how much power we going to give Google over this?
So I think that's a fair concern. I'll be honest when I was reading through it at I didn't even really think about that. I took it more as a suggestion type post of this is what we should look at doing. We're not so much. This is what we're going to make people do that. That's kind of the tone. I took away from it, but I could absolutely like understand that concern especially where it's Google.
No. No, it definitely is but Google is obviously a thought leader, you know what they push out people will Are to follow and I think you know, this will be more formalized in the future. I was starting to think, you know, is this may be the time where we should be considering sort of more certifications for like the development process and I don't know how much I would really help mean certifications aren't necessarily all that meaningful. But at the same time these are certain process level things that can actually be reasonably well audit like you are the developers knowing people or is Then on its developer and being able to have some sort of certification that open source often than say. Yes. We kind of meet this thing meet this kind of quality standard in terms of having the code reviews and having all of that. Like I think that can be somewhat fair. Oh, I don't I wouldn't want like any sort of paid certification where it's kind of a pay-to-play sort of situation. But I do feel like there's some room for actually having the proper specification righto from lesser developed out of
this. Yeah, so we kind of talked before about a project that came out of Google which was the criticality score and they actually mentioned that in this blog post the other thing which I don't think we covered was their scorecard system. At least I don't think we covered I couldn't find any mention of it and my notes but basically they're idea here is to like rate repositories evaluated there is factors of the repo and give it a rating and how that would tie into their framework would be like evaluating the score of each. See and then if it's below a certain a certain threshold, you would prompt further inspection on that. So there were a few other points. I wanted to call out here to which I had some thoughts on one of them was one of their goals for the no portion was to accurately track dependencies and reduce the size of dependency trees. Good luck with that. I feel like that's a very idealistic world, but that pointless it. I don't think that's actually going to happen. That's going to
be hard for I think a lot of companies because really doing that ends up being he built everything in house. That's where you get you gave her if all your dependencies by doing it all yourself and that, you know, it's kind of defeating the purpose of a lot of Open Source software being, you know sharing that coats. Everybody doesn't need to reinvent the
wheel. Yeah, not presents its own issues when it comes to vulnerabilities which which is another discussion, which I don't think we'll get into here. But yeah, and and another point they make which I thought was actually a good one. I think is the the standard scheme of for vulnerability database. So you kind of talked about it earlier, which so you might think like, hey, we already have CDs for that when it comes to open-source software though. There's a lot of security. Daddy issues that get fixed with no assignment of the CDE or it's hard to like it's hard to really work CD. He's into open source. So I think a better like more structured system for that does make sense, which is worth calling
out. More structured system does make sense. And I guess that's actually going to be conferred. Next topic is about their attempt or they're starting attempt at solving that but yeah before we jump onto that one of the other things they call out specifically kind of the trust in the build process and transparency for artifacts being generated and I do think that is in mile from one of the more important things. I mean get code review and all of that is absolutely important to like I said before they make a lot of really good points within this. I just want to specifically kike all the artifacts because I feel like that gets left behind in a lot of situations or people just aren't really thinking about having those verifiable and repeatable builds. so I don't know I mean it's something I think a lot of Open Source projects just need to consider is the fact that people need to be able to trust these build process they need to be able to basically take our they need it enable everybody else to be able to take their build our take their product sorry and rebuild it themselves and see that they're getting the same build as is being released kind of having that repeatable process because that comes in that's one of the place where you can detect the uh supply chain back is if hey they built this and you know had it with this you know release hash and I'm getting something completely different something's different about our builds and I think that's stronger than just having well I guess having the hash but you need to know how to build the product in order to get the exact same hash I would effect So like the hash is part of it, but it's not the whole
story. Yeah, so like there are definitely some good points in here, but I will be honest. I feel like there is a lot of cruft in here that talks about things that are like pretty obvious and things we've known about for a while. Like they have a paragraph that talks about how it would be great if we could just not introduce vulnerabilities and fix all vulnerabilities in a timely manner that her found like I mean, obviously yeah that that's the ideal scenario and I know they still probably bugs exactly just right in Like I know they try to break down those Concepts into goals to attempt to make the more achievable. My issue is though some of those goals. They seem like things that are great when you write it down. But like how are you actually going to do that when it comes to the implementation side? I think there's like some of these points are really lacking such as that reducing the size of dependency trees. For example, it just feels like kind of that p.m. Type thinking like, yeah just do these things and we'll be in a better place without like much focus on how tackle those goals actually are
In fairness. I mean, it feels like some of them are like the pipe dreams are what we want to work towards and as you said kind of an Ideal World thing, I think that's fair for them to
do. I just feel like there's a lot of it. Like there's there's some paragraphs that I think could like it. I felt like it took me a while to get to the good stuff when I was reading it. You know what I mean? Like the first like half of the page is mostly like filler mean like talking about wanting to know preventing fix vulnerabilities. I feel like a lot of people reading the post probably already know that you want to like take that process. So yeah, I just wish they were a little unfair
to list the do
though fair enough. But yeah, I mean, it's totally Possible to that. This is just an early stage post and they plan to flush out more of those details later, which as you mentioned earlier that we do have a follow-up blog post, which is pretty cool that will cover in a second here. But yeah, when it comes to the ethical concerns that you kind of brought up, I think a more of my at least my initial concerns were more on the implementation side than the ethical side.
so I guess we can talk about iOS V which is coming out of these efforts. So that stands for open source vulnerabilities. It's being launched by Google mainly to address that no portion of the framework the Project's promises promises to use automated analysis to determine where a bug was introduced and where it was fixed in a dependency used by an open source project in an effort to identify vulnerable versions of that dependency so that people can just look up whatever dependencies are. You can see if they have any vulnerabilities in that version. So it will basically take a reproduction test case for a bug and a set of steps to build the application then then it'll automatically performed by section to try to find those commits and identify the range of effective versions right now. It's only getting data fed in from OSS fuzz exclusively. They do try to plan to add support for golang and p.m. Pie pie and more in the future. It also exposes an API to let users query with their package version or commit hash header to the API to get a response to the vulnerabilities that affect that package which I think is cool. I think this is a useful project and definitely has some some real-world
value. It's a nice straightforward API as you mentioned though, like they are limiting this pretty much at well not limiting it right now. It is only OSS fuzz, which I think is a pretty big. oh that's quite lacking I guess is what I'd say OSS fuzz is going to have like obviously it's finding plenty of bugs I feel like like just for starting they should have still at least included CVS like I don't know I mean it feels like this is really designed around you know what's convenient to do with OSS funds rather than raising the question of what's easiest for open source kind of get involved with and start working with like I think if there's a way for open-source to more easily get involved where it's not just they have to be part of OSS funds in order to get their vulnerabilities knowing their if there's some mechanism for them to report something like that Like I don't know what that would look like, or maybe they'll find to do that in the future also. Got it. Oh, no. I just it feels like this is just something that's specific to OSS fuzz. Yeah, I mean I can see how you would
like interpret that. But what I think is I think they just started with OSS fuzz since that's kind of something they can control and integrate with easier
for sure. I mean clearly they're going to work with those funds because that is something they have and thank you believe kufuor the 5-month Tier 1 but yeah what's that supposed to definitely some that they're going to work with because that's convenient for them it just seems like the whole thing is kind of designed around being a convenient set up for what OSS fuzz is already doing rather than a more general purpose tool and maybe that will change in the future I like I wouldn't put it past them too to do that but at the same time I just I don't I don't see the current path forward for open source projects actually get involved with this without also needing to be part of
OSS fuzz So I think where this will really add value if it continues to get developed and it does end up pushing towards those future goals and p.m. Especially npm and go is probably where this would be useful. Although I think npm does shout-out vulnerabilities in packages when you install them right? It's just that so much garbage gets printed to the screen that nobody looks at that.
Yeah. Yeah. Mom does
So npm does kind of already have something like that.
Well, yeah tells you if I can if your dependencies do have a vulnerability or also kind of fable. Well, it'll update dependence or can update dependencies for you also. Dolphin it takes a step at resolving and I mean GitHub does something similar to in terms of scanning your dependencies. Yeah,
yeah, they have their security actions report or whatever
because you kind of
touch or sorry. Go ahead. No, go ahead. I didn't really have anything else bring up there.
That's gonna say you kind of tied in on you know, the question of whether or not Google will keep supporting it and developing it. And at first when I was writing this in the previous post, I kind of have that feeling of okay. Well, you know, Google definitely has this trend of killing products starting things and killing them. Yeah, so I was like, you know, can you trust this? Like can you you start developing golf this API? Can you actually trust Google is going to keep this around for very long? And I know so I was being a little bit cynical about that and then kind of reminded. I guess I got reminded that they did develop the open source security Foundation which you know, I mean it hasn't been around that long, but it it's unlikely that they're really going and that's it is kind of in line with something other things school has done with a long-term Focus. so I'd be more likely to trust this to kind of stay around for a little while more so than just the random Google product
yeah when it comes to security Google's a lot better I think on that front but yeah like mainly what they're trying to do here is just streamline that flow of finding bugs and getting those bugs getting people who use products that have those bugs notified that way they can update or whatever so yeah I think it's a promising system I just think it's it needs more work before it's interesting to more people I think
I'd agree with that as a summary of like I said, I've been kind of cynical about both of these posts from Google at the same time. Like I think that they're making steps are making the right steps as an industry. We need a Need to start focusing more on the security and all that then they're taking steps to tackle that I don't fault them for that whatsoever. We being cynical is just being worried about Google I guess but the same time they make them off the right points. Like I don't disagree with anything that's been done and I do think the API Lisa's
promising. I mean to be fair. I like cynicism. I think it's a it's good for Branding. So, you know all good. But yeah, even though this is an early stages if you're interested in checking it out. They do have a website at osv dot-gov, but which says the API documentation that zi was talking about and it also has a list of bugs that have already been aggregated from OSS fuzz and they have like a nice in browser search feature for that. So you can kind of see what the intent behind it is and what the end result looks like. And hopefully one of the look like when it comes to other future applications of them just OSS fuzz. But yeah, I mean looks cool. It'll be interesting to see where it goes. This is how I learn that one off. so bugcrowd did a post on the top ten most common bugs of 2021 so far so obviously we're not very far into 2021 yet but there's still some insights about crabs able to offer from the stuff that's been seen in the last month or so I don't know if we're going to go through everything on the list probably just call it the ones I found interesting
yeah there isn't a ton that's really all that surprising a lot of it related with like something that's on oh well stop 10 there's only one that was actually
Interesting to me, you're kind of
unexpected. That was a sub domain takeovers being at number three on the list. I felt like so we've covered a handful of subdomain takeovers in the last year. Like I can understand why we're seeing a few more for it's just surprising to see that so high because it's not one of those off and talked about vulnerabilities. Like Specter said that we are very early in 2021. I doubt that will be the case that by the end of 2020 one. No sub domain takeovers are one of the most popular attacks. I do think it's an attack that has been getting a little bit more practical in recent years and getting a little bit more more people kind of looking at it and looking for because it's one of those things that can be relatively easy to automate just you know find the subdomains of company actually has DNS records for and see if any of those match because the law of the takeovers that we've covered have basically been cname record or something pointing off to domain for like some cloud service that's been the majority that we've covered and I feel like that's sort of attack as the cloud has grown in popularity so have are so as the potential for that sort of attack yeah so I will probably
up I'll shut up the bottom two and top three I think of the top 10 so at the bottom to they had rce number nine they had open to redirect and then POP3 they had a sub-domain takeover cross-site scripting and sensitive data exposure number one commonly through like logs or repositories or whatever the one that there was one that surprised me other than the sub domain take over one though and that was the off bypass being so low they had off bypass at wegg number 7 so what they talk about there is like complex Off Systems and involve like single sign-on and Samuel and such it surprised me that it was that low because I feel like we cover those types of issues a lot on the podcast and it could just be that small sample size problem of not being far enough into the year to get a good conclusion on that but that was like the biggest thing that stood out to me I think was off by passing solo
I mean I think it's fair to also point out like it's low in terms of the top 10 but it's still in the top 10 So that's a present like it's it's still enough when I'm choosing the topics each week. Like if I see, you know yet another accessory Port that looks like every other excess excess report. I'm not too interested. I'm just covering it on the podcast said that can also change why while you're may be seeing something or expecting to see that a little bit higher. That's also a fair call. Oh, yeah, so there are a couple explanations for that. They don't actually release what the numbers are for an EFT is just that these are the top ten
which kind of sucks. I think the numbers would have offered some insights, but
perhaps bugcrowd is pretty opaque though. Like they have a heck tivity page like a hacker one does last time I looked at it which I haven't looked at it in the little while, but then most recently This report was like three months ago. They don't disclose reports very often. So I just imagined lost their clients don't want that information getting out. Which is totally fair. It just it would have been
cool to see those numbers, but I can understand why they wouldn't want to include them.
but yeah, like like you said when I was reading through this I thought the exact same thing a lot of these are totally expected like rce being the the last one in the list like often there's easier methods to to accomplish an attack than rce. That's kind of a and usually that's something you hit like against a client not against like a server. Something like that, which a lot of these other issues are those more like web type issues that are hitting the server directly. So it's totally like a lot of the things on the sense on this list. It makes total sense where they are in the list. So
I would except the one I had pointed out we couldn't have the question more RC than denial of service and was denial of service specifically on this list doesn't look like it. No, they don't and I think that has more to do with the that a lot of web apps like you don't get a lot of denial of service things or a lot of the denial of services that he do get reported are very minimal in terms of their impact like okay, you can't access this page. If on the user that he performed the attack with other scenario, which I don't know. I mean it denial service is definitely do get reported actually. No, I was going to say I thought bugcrowd themselves actually did a post recently about denial of services in their bug bounties, but I actually don't think it was it was one of their director's coding go. It's another Channel. He did a post about or did a Blog though. I'm just seeing if I could pull it off quickly here. But my guess would just be that more RC. Simply because denial Services maybe don't tend to get reported as often would maybe just be a stab at the dark about that?
Yeah, that was kind of my thinking as well. It's often. We were talking about dots that it's not like if it's not something that could be turned into an RC e at either doesn't get reported or the report gets ignored or closed or something like that because it's specific circumstances or it's just not interesting or it's obvious. Like hey, if you send a billion request to this page, you can like, you know stuff like that. So I just don't think I think it's just specific to web where daus isn't a Yeah, well web
and now back security like if this had if bugs out had more like the binary applications where you know every remote code execution and probably also cause a crash. I feel like it might be different cause you'd get more reports of exploits that maybe haven't been fully weaponized that just go as far as well. We got the crash that's good enough and thus getting more denial of service reports. I did also just noticed something on the page in cross-site scripting and mentions. Our cross-site scripting is said to be discovered back in 2005 by Emma Klein. For the HR to tell me if I'm going crazy, but I definitely remember cross-site scripting at least in like 2001. I don't know if it was quite cold that yet. But I mean, they're not saying that he just coined the name. It's was discovered and I feel like there's no way that can be right because I remember being you know a kid doing South that on one website that was definitely before 2005 was definitely before I was in my
teens. Yeah, that's a really weird. Like I was fairly young in 2005. I did not have a computer when I was like 6 or whatever bomb. Yeah, I mean that seems really who knew basically exercises have been around forever. So I would be surprised if it was
yeah, I mean I could imagine, you know, maybe maybe as the first verse to do like a prawn it but I'll 2005 just still seems so late. Yeah
something we can maybe check into Wikipedia has this Microsoft security Engineers introduced the term cross-site scripting in January 2000 that seems more accurate. Like if I had to guess to me don't be around 2000. So
yeah. Yeah, I could imagine being earlier but I couldn't I my memories of excess do go back to about 2001. So that's where I was kind of driving from that zi. I'm not sure if there. Baby referring to a particular I Dom based access or something. Maybe doesn't look like that though CI that I just noticed that and definitely stands out and definitely seems definitely seems wrong. Unless my memories just going crazy know I'm getting old and having memory problems. Boomer zi
but yeah with that said I think we can jump into some exploits. So we have a headlining topic right now. And that's it's a fun quick issue with Nespresso smart coffee machines, which I believe they're basically like vending machines for coffee, right? Have you ever actually seen one of these machines zi like in anywhere you've went like
yes, there's a company that I had an on-site project with they had some These machines.
Oh, really? Okay. I don't think I've ever seen one of these machines. That's that's what I was asking there. But yeah, it seems like they're basically vending machines for coffee. They use my fair smart cards for storing your balance and what not to interact with machine using NFC and and those smart cards were probably broken by a group of radboud University researchers back in 2008 Who reversed it and were able to clone and manipulate the chip contents and specifically
these are the mifare classic. Classic cards the later ones are not vulnerable in the same way. Yeah. So the attack is pretty
simple that they pull off here. They basically use the EM FOC tool to break the few non-default keys that are present on the card and they use that to decrypt the data blocks off of the card. Then they do that kind of classic thing. You'll see in like game hacking for example where they record the value of the money on the card with like one bit. One point 50 pounds, they buy it some coffee to drop the card to 50 pence and then they compare the contents to see where that memory or that money counter is stored in memory and then they just smash that value to get infinite money or rather a hundred sixty seven thousand pounds and then they rewrite that block back. So it's a fairly straightforward attack. This is definitely nothing new. If like I said, you've seen like game hacking and stuff this this is common there maybe not the crypto part but that method of Thumping to find the value and rewriting it because this is a hardware problem with the cards themselves. They can't be hot fixed though. They can be worked around by updating the machines to store the money values on the server side and then just use the cards as a piece of ID, which is probably how it should have been done in the first place. Anyway, I don't know why they would store the money on the card. But I mean
there are cases where you just can't Network it and give it that connection of I don't think that's gonna be the case for the majority of company truck but it does becoming yet another device on the network also then so I can see the arguments but I do agree with you. I think the default should be just using an ID and doing the lock off not trying to store locally because you basically eliminate the entire class of local modifications or the entire class of attacks involving those local modifications. If you simply use an ID and look it up, although then you also granted the problem for local modification changing the ID to look up another user.
Yeah, no stealing. So like
there are some potential issues there
too. Yeah for this attack of the initial report of the issues were disclosed September 24th full disclosure happened October 9th and to Nespresso is credit. They agreed to the publishing of the right up this month. And the reason I'm kind of calling that out is because that original attack from 2008 with the University of researchers. I think there was actually like a court case around that I think the article mentions that although I'm trying to find exactly where because I can't remember where they pointed that out, but there was some drama. Around that back in 2008. So it seems they've
maybe so in 2000 and later on that well in 2008 the problem was that the researchers Who first got to attack these my fare cards. They were attacking it for it was I believe a German public transit system. So it had a very significant impact and they were the ones that kind of tried to stop the publication of it, I believe and not not necessarily the come are not all of my fare. I believe was the case. I believe they'd mention that towards the start. Start up the article somewhere. Yeah, I know for a fact that I read it in
there. I just can't find where now if you like going
crazy. It's here at the start and XP tried to stop the publication of the research by requesting a planarian junction. However, the injunction was
denied. Yeah, okay. So yeah, that's that's good point to bring up. Thank you. But yeah, I mean this doesn't really seem like it's a new attack. It seems like it's rather the Revival of an older attacked be fitted to newer versions.
Well, it's just it's even just the ReUse of it. It's just it's fun to kind of talk about those NFC and like the card attacks. I mean they reused same tooling from before. I mean, it's not a new attack by
any means. Yeah, it is worth noting these my fare. Classic machines have been superseded by my third plus which uses aes-128 and it's fully backwards compatible because the main issue here is just that the keys are using our secure they can be broken by this public tool in a matter of minutes. So there is my fair plus which is more secure and they recommend clients who need that extra security to to upgrade to that. I wanted to take something at a chat though that I noticed which was I seen these but they didn't need a card you just pick the coffee you want for Free at every place up into I mean it does seem really strange that you're going to have a coffee machine at your workplace and you're going to make it so people have to pay like 50 cents or whatever for one. I mean at places that I've worked the coffee machine and the coffee is just there and you can do it for free. It seems like Mega penny-pinching to make people pay for coffee at your workplace.
Yeah. I don't know I've seen both I've well with these machines in particular, I've actually only EMF I think I've only seen him at the one company that did have I think it was like 25 cents. That they were charging. It wasn't a crazy price. I don't drink coffee. So I maybe they've had another place that I just didn't notice. I wouldn't be going out for it or going to grab any. Anyhow, I've seen both makes sense for the company trying to make somebody like like said does feel like penny-pinching even when they keep the costs really low. It's still like Yeah penny-pinching but I have seen it. There are some companies that go that route I guess is what I'll say. I don't want to start mentioning any names.
So yeah, I mean it's obviously their prerogative. It just seems silly to me or something like that. But hey, I mean if your company has one of these machines and you have to pay for coffee, and it could be a fun exercise, especially if it's a security company that you work at let's not
encourage them to steal well.
Okay, maybe bring it up with the company. Not not use it the steel coffee. Okay fair enough. So we'll move on to spoofing and attacking Skype. So in this article, we have various spoof attacks as well as spear fishing and a Doss on Skype from mr. Docs. They have a table of contents for a pick your attack basically because they detail like I think seven different attacks. Most of them are
smooth related. Yeah they did. He'll several of them at the same time almost all of these are effectively the same attack Michael scroll down here spoofing links you all you're doing is Azam. A lot of the Skype messages just have content as one of the options and like the message body, I guess. Though spoofing a link. Oh you change the url that the a giraffe goes through the a tag you move on. What's the next one there? Swooping filenames? Yeah. Oh, what do you do? Oh you're changing the content again. I just use a different thing. They're like, they're all kind of the same thing. You've got the message and they just don't do they basically generate these messages from the client side or from the sender side rather than the receiver side. Which is basically worth vulnerability comes in you can modify to show, you know, a random file size random file names. They do kind of mess mention using Skypes domain. So when you upload a file goes on to Skypes o domain there so you could use that for kind of like a spear fishing. They mention that which I did think was kind of interesting to have that Skype URL for sending files over to people obviously it's going to take a very targeted sort of a tactic like for the fact that it's like.com to actually make a difference. But I did think it was kind of interesting nonetheless eBay to do that and I'm not sure what their expiration process but sounds like they don't really expire anything and even if you delete the file or delete the message it still is retained. So, you know, maybe build a Dropbox on
that. That could be fun. Yeah, I think the most impactful attacks and tan in terms of how dangerous they could be are probably the spoof attacks when it comes to the links and file names because people will use that they'll look at the Lincoln think oh that looks safe. That's a sight. I trust or the file name is safe because it doesn't have an extension that looks malicious. But the fact that all that is entirely, you know controlled by the attacker because the message HTML is crafted clients. I'd that does make that breaks those assumptions that people commonly make so I think for me those attacks were even though they were all related to the spoofing which is a pretty simple attack. I think there's still probably the more impactful ones then I could see because the crash was like kind of interesting. The crash was based on the fact that you can add too many tags in the content section of the message body and you can basically turn that chat into a Das primitive anytime somebody opens that chat it crashes the client but not on mobile. But that's just kind of like a I don't really see many practical implications of that. Whereas The Spook to scooping in the spearfishing obviously do have more of those practical aspects to them. So yeah, I mean this this was cool right up. I am surprised. I hadn't heard about these issues before though like Skype has been around for like a super long time. I haven't used it in years. I used to use it back in like 2014 or 2015 or
something. I mean, I can remember us reporting on very similar issues in I believe it was slack having a very similar kind of problem.
Yeah. Yeah, but it's just yeah, that was one thing I was thinking about this was like why is nobody like seeing this or reported this before and maybe they did and I just didn't see them. That's that's probably likely but yeah, like like balika said in chat. This is like this is a pretty dumb issue. It should never be crafting the exact thing that the other user sees on the on the attackers side. I should be doing that on the server. I don't know why they did it this way. Probably just laziness. I don't know. But yeah, I mean at this point, I don't think there's anybody that should be using Skype Skype has is completely ruined for me as a platform even like with these security issues aside the botting issues on Skype have been real bad it also it had some lazy design and other aspects to I remember people used to be able to grab your IP. They had your like Skype name because they had like no protection on their API. There's just like there was a lot of things with Skype or I was like, yeah screw this I'm not using this anymore, especially now with this chord being out there. It does everything that Skype does and more better. So there's really no reason to use Skype. So
it doesn't make phone calls or like you receive phone calls. That's a Discord doesn't I can't give my there you go number two because I do I have a Skype number that I've used for years, so That's my permanent phone number.
Dab, that is that that's fair call out. But yeah, I mean, I feel like this is kind of like the final nail in the coffin for Skype for me is like if you use Skype read this blog post and then look at all the other stuff and then stop using
Skype and I guess In fairness, I guess we should point out that it doesn't seem like this is like a bug Bounty report seems like they're just laying out here they attack so it's not necessary that these are new attacks like nobody knew about this before. There's that they're lying about.
Yeah, it's more of like our research you type post.
They definitely don't mention anything about actually reporting these. Which makes it seem like it's probably already know
one to me. Yeah. Up next we have an article on both a local privilege escalation as well as an info dump on webos. This is from andreas's Research into web OS which is used for LG Smart TVs and fridges because we all need smart fridges and smart watches as well as some HP phones and tablets which kind of caught me off-guard when I was doing some research into what used webos. I saw HP phones and tablets. I was like, wait what HP makes phones and tablets, but I think they're older. I think they were from like 2010 or something like that. But yeah, basically web OS is a Linux based system. It runs web apps which are executed in these cure headless browser, but those web apps can basically spawn their own Services which run as node.js applications and it also implements an API server for interacting with system Services one of them being the download manager which runs through so that automatically makes it an interesting Target for exploitation for obvious reasons. One of the methods that the download manager exposes is the ability to download files as you would expect which allows you to download files over the network to a restricted directory if the caller doesn't have privileges basically how they check if you have privileges as they check the calling service name and they check it against a white list of prefixes including cam Dot webos and the that download manager has that service name so they have privileges. Equate so if you have those privileges you can download anywhere as a group. Sorry the tool that ended up having the the service name that granting privileges was the Lunas End pub server. I got that kind of jumbled and my mind there but yeah, they ended up discovering that a tool to prove to interact with the API locally, which was that Luna Pub send Pub tool because it had a prefix you could download an arbitrary file as fruit.
Yeah, but I thought that wasn't an immediate pone. I thought that was kind of a fun issue there just because of the fact that the Luna what was that whatever it was called. I forgot the pub 10 Pub. Yeah
sort of a weird name. That's why
there's Lunas and and then Luna Send Pub Pub being the one that's accessible as like by any application to download and are by any application. They can hit the pub one and then the other one is restricted to only things. Gets removed. So the name kind of makes sense. It's a Lunes en. It's meant to be used as like a command line tool. Somebody's actually on the command line making some of these requests rather than it being a Actually, I don't know how the intent is so I shouldn't make claims about that. But it seems like it's meant to be a tool for an actual developer on the command line to send something. Oh, but because of the fact that it just happens to be told they're providing you it also has the name I Specter said the way Trexler privileges is is this coming from a calm down webos or calm down poem Service and in this case Yeah by proxying through it it absolutely is.
Yeah, so, I mean it's not an immediate own because while you have an arbitrary root file, right it writes it as the root user so you can't just like hit a set you would binary because I kind of forgot this and Zi to remind me but when you overwrite a set you had binary that's set you would bet gets cleared upon right? So if you do that, the binary will no longer you won't be able to execute it as root the obvious next thing to try after that is to try smashing some File that will lead to Provost down the line. That's what they did. They found a configuration file for the lunar surface to HUB Damon for internal Communications. And that would execute A bash script as root on Startup. So if you can smash that file to make it executes and attacker control bash script, you can get command execution as root. So that's the route they went they use the arbitrary download to corrupt the configuration file, which would run the attacker control bash script which ran a reverse Shell through python. So it's a cool attack. I'm not sure if it's fixed. They reported the issue on October 5th and LG reached out on January 26th over two months later to say the issue would be fixed within the week. But there's no indication that they actually did fix it. But given the fact that they give an LG like three months at this point and it's not a remotely exploitable issue since you need command line access, they decided to publish it anyway, which I think is totally fair. From what I could find the latest release for webos is 6.0 which was released on like January 15th. I think so I doubt it is fixed since they said it would be fixed within the week at the end of January though. It's possible to fix did ship earlier on in the person who contacted the researcher wasn't made aware of that or something then that's pure speculation on my part. But there is a bit of weirdness when it comes to knowing if this is no day or that's
not it is also kind of worth noticing that are noting that at the researcher here who found this mention that it didn't actually impact the latest LG TVs because they all make some modifications to webos. So it's the core webos like they maintain and have is open source that's vulnerable to this, but that's not the webos. It's actually running on LG TVs, which is probably the most popular. user of webos Yeah, it was
it was strange trying to find devices that use it because I did a little bit of research trying to see how popular is webos and like outside of the smart TVs smart fridges. It didn't seem like it was used too much. So it's probably not like a majorly impactful issue or anything and you do need like that to access that command line utility as far as I know. The only way you're accessing that Luna Send Pub tool is through the command line. So I you I don't think you'd be able to hit it remotely or anything. So Um, yeah, it's overall. I think it's totally fair that they publish this right up. But if you have to my stress level as it might be Hannibal. Yeah, exactly. But yeah, that's all the details we have there. So next we have a blog post from space raccoon who wrote up to issue zi found in Facebook's game room when they were invited to Facebook's Bounty con. So game room is not going to be a thing for much longer it launched in November of 2016, but it's going to get canned and June of this year. But obviously while the Bounty Khan was running it was still fair game. So when he looked at the application, he noticed a few notable things for one. It's stored session data and an sqlite cookie database which Is of interest just when you're looking at cookie, like session data and being stored locally as cookies session hijacking is a potential attack that can happen there. It also included this F sharp Library, which is basically an embedded Chromium browser for C sharp. I'm
sorry. I want to stop you there session hijacking. What's
what's your attack thought on that?
Um, because like what session hijacking you need some way to leak that session and odds are like people are browsing the random web. With this so like often like you'd have some way of clicking. I get getting somebody to navigate to an attack page which can then, you know get them onto. Brr. I'm just singing out there, since you mentioned the session hijacking specifically do they mention session hijacking is one of the concerns like they mentioned the local SQL I file but I was thinking more like permissions. Just because this is a kind of stand-alone browser. Okay, so I was they didn't
call out session hijacking specifically. That was something that I was thinking of when I read it. So maybe maybe that's not the best line of thinking you were thinking something with permission. Sorry.
Well sing just in that file there. There's a chance that could be linked with bad formations perhaps I just saw that more joy away comment. I didn't really think too much about it. It's just when you mentioned that's session hijacking I think but then I guess if you had So we're going to kind of get into the attack later. Where they do kind of have a URL schema that they registered to handle but I guess in theory maybe XS through that he'd be able to steal the session within how are you going to yeah, I guess it is hitting Facebook so you could reuse the session.
Yeah, that's correct. I was thinking there
I'm thinking out loud here. But with that again to kind of move on I
guess. Yeah, no worries. It's all good. But yeah, so there was the the session or the cookies database that they noted and the other thing was it being bundled on its own with 7-Zip. Although that didn't end up being relevant. So the first issue they found was a deserialization issue due to the use of binary for matter, which is known for being. Secure Facebook used it for getting settings information as a serialized blob from the application settings database, which is something you're probably familiar with if you've written C sharp a lot. So using why so cereal he did manage to take advantage of the deserialization attack to pop calc, which is kind of cool but there's no privilege escalation there you're still running with user privileges. So it's not all that interesting right? You can just modify the like binary directly or inject the dll or whatever and do the same thing essentially. Now the second issue was of using the custom URI scheme set up by Facebook the zi mentioned earlier
which with the last one I welcome ention Facebook rejected paying out a bounty on the deserialization for the reason Specter just mentioned. Yeah, and on the session token. I was just taking a gain on that. I guess if this session gets you into the Facebook account then I guess it would be more useful than if it were just something local. I wasn't thinking about that. I was kind of thinking of this Standalone but A Facebook session could be quite useful to be able to extract
kind of there's there's plenty of exploits to choose from to since of chromium 63 came out back in October of 2017 though quite out of date
it's also just a high level thing I mean you get so many little details that matter when we're talking about like in iOS kernel exploit Oh. Less so a lot of the times when we're talking about web think so it is it does kind of make it a little bit interesting.
It's nice to see ya. So six different major bugs were discovered in the Realtek RTL 8195 a Wi-Fi module. These were found on a supply chain security assessment conducted by I think it's the do I think we've covered like articles from this site before and we can never like be How I pronounce it I'm just going to save you do because it sounds fun. But yeah, these bugs can be leveraged for remote code execution as root on the Wi-Fi module which can be used to hop to the application process via the networking stack. This is notable because as they point out these chips are used a lot they're used in iot automotive Industrial Systems pretty much anywhere that there's a low-power necessity and you're going to be using arm chips. You're probably going to be using a real Tech Wi-Fi chip, too. So they found six issues in the WPA2 handshake mechanism alone the most severe one being hittable without knowing the Wi-Fi pre-shared key regardless of if the modules was running as a client or access point two of them can be exploited without knowing the that key against clients and the other three could hit clients but needed the Network's pre-shared key further what I mentioned before we get into the issues themselves. Most of these issues are Stack overflows and they're like very straightforward. There's like zero mitigations in place for stack Overflow. There's no stack cookies. There's no way it's Al are no non-executable stack, which I mean this is iot. So I guess that's kind of expected but this is basically like 1990s exploitation. So
yeah straightforward and a lot of the issues all have kind of the same. Root problem being that they trust the size or read a dynamic size into a fixed size buffer. like I think I want to say all five of the stack overflows are just attacker controls the size of something that it reads out and it reads into a fixed size buffer. I think
for the mark because one of them is a one is that situation? Yeah. Yeah. So yeah, four of them are just straight up like zi said just passing in an unchecked sighs. So I don't think I'll cover all them and detail because like you were saying they're all basically the same but the most severe one occurs in the key exchange and the EA EA poll frame parsing for checking the message Integrity code. They the person at a controlled length and passed to mem copy with no bounds checking it's a stack buffer of 512 bytes in size you just send a large packet you can corrupt the stack and once again that can hit client or access points and it's before the the key is evaluated but yeah like the other issues using mem copy are basically the exact same thing just in different areas I think
yeah one of them is like controlling the ascended in the size of the hash at one point of either md5 or sha-1 hash but it doesn't actually check the size matches either of those it's just a 16-bit number so you can go beyond the are you going to have a reading Beyond so that's the owner balance read the only one that isn't a stack overflow Oh, yeah for all the stack overflows like the size of the key that access point is sending is read into a fixed size 257 bytebuffer. No extended a larger key or at least larger length and it's going to copy out. I don't think a lot of these are two interesting besides the fact they're there. I did think it was kind of interesting to know the effect the fact that you can kind of attack the clients. With some of these being that you would basically d off them move malicious ATP have them connect to you when then attack them. Other than that, like I didn't find a lot of these two interesting so know how much we really need to dig into
them. Yeah, I won't dig into them too much. The one thing I will say is due to extremely like lucky circumstances. Like I obviously real type didn't intend to make this like a CTF where the bugs were there, but they wanted to see if you can exploit them two of these issues can only lead to daus and not code execution and that's because basically the data can't be controlled it like one of them I think is hmac Hash data which in theory, maybe you could get some What controlled because sha-1 and then be fine that is
But yeah, practically speaking. I don't see you pulling that off and then another one just use data that I think it was another like encrypted data. So you didn't really have control of the data, but it would have been exploitable if not for those circumstances, but I just wanted to point that out. But yeah, like in all these issues and Trust untrusted data, it goes completely invalidated. It seems like they didn't even try. I wish I could say I was surprised for something like a Wi-Fi module but I can't really this is one of those reasons why iot and ICS are kind of joke when it comes to like exploitation and and security is these types of issues and its really annoying because like I said earlier these mediatek chips are not uncommon they're going to be used in like they're used in so many systems is the problem and you can't Like fragrant fragrant lie, they don't care about securing the chips because these are like if you had any security assessment on on this code, I mean there would have been like a glowing map of issues. But so that indicates to me that there wasn't even a like there was no code review done here. I don't think I can imagine
it. I will jump and say thank you Angry Chair for the raid. Oh, yeah, awesome. Thanks to you
but yeah, like these issues are just there such memes.
Yeah, so foundational. I mean we were talking kind of the other stream either last one one before that about the windows exploitation course from offensive security kind of hating on it for something older aspects of the course and you know might have bit. I mean this isn't windows but you know like that code is still out there the Old style exploitation. It's still there, especially in these iot and these basically soft targets. Yeah, he's issues. Yeah, there's you can't even really defend a lot of um.
Yeah, if you want exploitation on easy mode go to iot. Up next we have a really interesting topic that somehow barely got any coverage. It seems cross-media. I didn't see it anywhere except for our like planner basically, so we have a boot ROM vulnerability and mediatek chips, which is another one of those chips, which is used in a lot of devices including phones. This was published in the form of an mtk bypass various phones, which is used to allow bypassing the Google account login. When wiping and reinitializing a phone, I believe but this exploit will work on any platform that uses of mediatek based boot ROM and it can't be patched because the boot ROM is read-only memory. It's kind of been the name and it has no patch mechanism. It doesn't have Pat fuses or anything of that nature. So I mean mediatek can replace it in their manufacturing pipeline or fix it in their manufacturing pipeline, but that would take a lot of money and a lot of time to fix you. Would you would you would have to overhaul the production pipeline basically? Ali for something like that. So yeah this this issue is going to affect a lot of devices. Now the page we have up on screen doesn't have any technical information. We do have some information we can share from a private Source though, but they want to remain anonymous. So we're going to respect that but we will still cover some of the technical details. So getting into the bug basically when sending control requests, you can specify the index. What interface to send the request to but there's no checking on that index. The boot ROM only has three interfaces, but you can specify any index. So if you just specify an index Beyond three, it'll follow that and the reference a function pointer there and just jump to it. So you basically game code execution out of the box by by way of like
literally out of the box. Yeah, very early on very simple. There's no no deaf and place. so I I don't know if there's a SLR in place or if that's going to be device-specific but no depth. So you get a very early jump just inject your shellcode as long as you know, where to jump to. I feel like in this scenario. You're probably not going to have a SLR.
I was just literally I doubt it. Yeah bootrom. I doubt it. I doubt there's a salar.
So I was actually just trying to think like think of any boo her arms. That would have a SLR at that point and I can't really think of anything. Yeah, I can't either. Yeah, it does seem like this is impacts. Pretty much like everything media attack teams. Like yeah going well. I don't know about like anything from this year, but at least into 2020 like chips coming out there and it sounds like they don't have a good way of updating any of these to prevent it. Like they don't have a part from just stripping the ROM and putting a new Ramen which is kind of pricey like they don't have a way to update the wrong. So any chip that's already been made with us and they're probably not going to want to just toss all of them is going to continue to be vulnerable until they get new ones out.
Yeah, I mean so it's interesting this got no coverage. Like we said earlier I'm guessing it has something to do with the means of which it was released. People probably saw this like mtk bypasses like a self pone like something you'd use to mess with like the bootloader of your own device or something but it has a lot more implications than that because like we said it affects any device that uses the mediatek chip that includes modems Global navigation satellite systems and any others And that uses mediatek soc's now you do need physical access to exploit it, but that doesn't mean it's not impactful. There's many potential cases where that are within a reasonable threat model. I mean, even if you just stick to phones there's the theft of that the devices right the entire point of having the Google login when you try to reinitialize the device is trying to prevent the theft right. I'm pretty sure that's the main mechanism behind it. So there is like a classification of where this has impact so it's weird. It's a really high impact issue that affects potentially like a lot of devices and it's like nobody cares. I don't know. It's a weird. I guess it just kind of highlights how much of an impact the medium can have in which an exploit is published in terms of how far it reaches out with coverage.
Yeah, I'm not sure if it's that or if there was any attempt actually and to keep it a bit more quiet to same time. Like we don't have a lot of information about it just hears mtk bypass and that's that. So I do kind of feel like the medium probably does have an impact because it is somewhat opaque. Once you kind of know what you're looking for. Like it's not enough medium that's going to be readily understood just by your average person reading it to kind of recognize the impact of that so it can be it can also be like a actual attempt at like, you know, just don't report like telling journalists not to report on something because they can't fix it. Or can't readily fix that I guess. Yes it going either way. I don't have any evidence on that other side. So I mean going from what we see. I would probably put most of the blame just on our was released, but that is kind of just
speculative. Yeah, I mean I will call her quickly. We like to like try to speculate and get in the heads of like people in corporations on this podcast. So there are some things will say where it's like we're purely speculating. We don't have evidence for those facts. So, you know, don't take them and run. Basically, it's just something fun that we like to try to do to you know, get in those heads as fun exercise have
Yeah, exactly. I did want to take something at a chat believe. Apparently apple has a SLR and their boot ROM, which is what I was kind of thinking earlier. I wasn't sure so I didn't say it. But I feel like if there was one boot ROM that did it would be apple because they're kind of they're ahead of the curve when it comes to mitigations and whatnot. So they have depth stack up. He's in ASL are apparently in their boot ROMs because Checkmate uses Rob to get around that in their in their chain, so Yeah, I kind of figured that Apple would but most chap most chips don't I mean when you're getting into those levels aslr is usually only put into place when the colonel boots and even Colonel a SLR is like really recent like last like five or six years. I think if you go back to like 2010-2012 like Colonel SLR was extremely rare to find so and I think Apple was the first to do that to probably so, yeah. It's definitely not a common place in the boot ROM so it's a very straightforward bug it's an easy exploit and it has a lot of devices so yeah it's definitely worth keeping an eye on we'll wrap up the exploit section with they release of technical details around a pipe confusion and iOS kernels the iOS 14.1 kernels and older they came out of project zero this was found from the master of exploits themselves here in beer this issue was patched in November by Apple it was found to have been exploited than the wild which suggests that this issue is likely reachable from sandbox I'm not a hundred percent certain on that because I couldn't find confirmation in the bug report But it seems likely that this would be hittable from sandbox, especially given that it's in the the IPC subsystem the bug here is basically failure to handle edge cases around the Turn Style feature, which was added in Iowa's 12 and it again has to do with unions being used stupidly by sending a crafted mac message to a destination Port which has a special apply local Port attached to it and sending the max TSN sink overrides. flag then changing that thread special reply port to a host 025 Port you can force a type confusion when the special reply Port gets red from Basically, the code doesn't know that the user space on Port can switch to a host notify Port. So when it goes through read the pointer from K data, it thinks the port it's pointing to is anti PC Port. Meanwhile, it's actually pointing to a host notify Port. So that's where the type confusion comes into play there and that can be used for out of bounds right and possibly arbitrary read write as well. I don't think they fully flesh that out in beer. I don't know if he like went down that path or just kind of reported that and moved on but
more they mention I think that the analysis is incomplete. The baby will hear more about that. Maybe not. Yeah. Yeah, because I don't know the tricks. I would actually be used like I'm not familiar with the internals for those mock ports. It said I mean it does seem like it is kind of a classic issue with unions just being able to switch out with the type of a union from underneath that yeah. Yeah. It's more reason just not be using unions in general. It's also just like it's hard to get that right. It's hard to kind of follow this and remember every sort of edge case that can happen in this case. You've got the You know when you make it that host notified, it's what you say. It does what it's supposed to it's like everybody else has to be aware that that can happen. That's a hard thing to remember when you have a complex piece of code such as so Mike X any or such as any Colonel, you've got so much code there. Everybody needs to be aware that these things can happen. That's not an easy thing to do.
And there's so much movement like even if you do know all the code that's interacting with it presently. There's probably some change happening on a subsystem that because because it's IPC like it's going to be used in a lot of places. So like I supposed lost going back even harder to track
would like using a big Loft around it but help but that would kill performance
probably. Yeah, so I mean it's worth noting that the in points out. This probably isn't exploitable on devices with pointer authentication or pack and that's because those pointers are tagged on packed devices and this kind of shows where pack offers its value not only in trying to prevent use after phrase, but it primarily basically kills type confusions as I understand it with with pointers at least that said pack doesn't exist on devices older than A12 chips. So the iPhone XR earlier doesn't have it. So that's where the in the wild last back. There was probably targeting those older phones. Yeah. I mean like you said this is yet another example of unions and how they can screw you over all you also you can save a few measly bytes of memory even even points out that the use of a union here is completely unnecessary and suggest a fix to be plate breaking the union filled out into separate members or adding a field Uh anti PC port for storing the type of the port at least there was one final thing. I wanted the call out that I thought was cool though a section that was in the report and that was how do you think you would have found this bug? I don't remember seeing this on previous stuff from P0, but I really like this section. They go into some of the vuln research methodology of how this issue could have been discovered by attackers. In this case. They point out that it could have been found through variant or manual review. not through fuzzing due to the Nuance nature of the bug though but like that's just one of those things where you don't always get to see you don't always get to see that methodology behind it so I like that that was flushed out here and I'd like to see that in more places
yeah so this is one of their root cause analysis which most of the things that we end up covering from Project zero end up being like their actual kind of reporting on something and these root cause analysis the first time I'm really seeing Dom is with their recent posts that was also this week Deja boner ability Where they release like seven of these are CA files, I haven't seen them linked before. I don't know the page where a link are there is a page that links like all of them. I hadn't seen it before. Apparently they have been around for a little while like earlier this year. I think it's linked in this in this post, but I don't. don't see the There we go. That will be in the in the description but they have several root cause analysis that they've done these ones just being kind of recently put out or this one being recently put out. Yeah, I'd like I'd like the format it's concise. It gives you the details and there's I mean don't get me wrong. I like the Loft project zero post because we get a lot of the background we get a lot of the thought process and all that but it is nice just have these concise pieces also.
Yeah, it's short but it packs so much information into it. So that's what I was going to call it to was like I would totally rip off this report style because it's just it's so nice and like if I was getting an assessment done if I put myself in the head space of living a company or something and I saw this kind of report, I would be very happy. I think if I was in the security like Department,
I think you're getting a report. You probably want to include more about remediation and developer zi can't I was perfect. Understand the UK expect them to understand the internals. You can't always expect them to understand the vulnerabilities and why it's a problem. So there's definitely more heed one have in there. But this is nice for like another technical reader to take a look at. In fact, I do plan to try and make a RSS feed out of just these root cause
analysis. Yeah, they're they're very nice to read for us. So we'll jump into our research paper of the day. This is a paper on the security of Open Source software when it comes to code review and why bugs are mr. In code review. So I guess we have a like a theme of open-source, I guess with this episode. They basically had to driving questions by the paper one of which was which categories of security defects are more likely to be mr. In code review and the second one being which factors Fluence identification of security defects so they use chromium as a case study and did a manual and automated approach to collect 516 code reviews that caught security defects and 374 that didn't they basically the process behind that is they used automated data mining to pull. I think they said like four hundred thousand or so good reviews and then they filtered them based on a hundred five security key words, which they do have laid out in the paper. They do have laid out in the table. That's in the paper things such as As buffer overflow daus format string the kinds of keywords, you would expect and then they'd manually inspect them to get a filter data set down from 1337 reviews, which was cool number. They got that down to five sixteen for the data set of controls for the Escape vulnerabilities. They data-mine the bug tracker looking at fixed commits and automated looking at the get blame and search for cross-references of code reviews of that code to which they found 374 Miss vulnerability is Says in the code that we're peer-reviewed. So they then analyze them to try to figure out what were the leading causes of those code reviews not catching the bugs they'd stayed found. Once they had all the data. They finally establish a table of factors that could have influenced the identification of the bug pretty much anything that they thought they could quantify basically. So the number of files that were under review in that code review the amount of code churn the cyclic amp up the cyclic complexity of the code that number of code commits. It's an author and submitted reviewed the review time. I think there's like 20 different factors that they have laid out. They have that on Page 6 on table to what they ended up concluding for their two questions was for the categories that were missed the most and caught the most use of unsafe functions. Like sir copies printf and sterlin were caught with high Effectiveness. So were incorrect calculations and Bounds checking as well as memory leaks which isn't much of a surprise because those Very noisy issues. However, security defects due to insufficient validation of data authenticity were missed very often in more than eighty eight percent of the case reviews. They studied it went undetected operation on resource after release uaf, basically and exposing resources to the wrong sphere were also in that list of flagging being caught in code reviews, which makes sense because those types of issues often spend multiple functions in areas, where as the calculations is. Suffer a lot more localized like usually with the uaf. It's going to be on some kind of shared object that it's not going to be within the same function. Whereas those calculation issues typically are so that made a lot of sense to me. I think
I did also want to call out back that they didn't catch and review any of the insufficient verification of data authenticity stuff. which actually now that I'm seeing that there's yeah 13 escaped. So 100% escape the code review. That one felt little bit of weird to me one that are would Escape. So my theory on why all of them escaped is probably because they would have expected this to be on it be handled more centrally such that they don't need it. Like the developers don't need to think about it kind of ad hoc. Every time they're using the data and said something should be dealing with the more centrally that would be my guess on why they just love had that expectation. It's still kind of Stood out to me because it is kind of it is kind of a big issue. To just not catch at all. Yeah,
so when they got into reasonings behind security defects being missed it. This was a lot more complicated to answer because it's more subjective and it's harder to quantify. They basically established a model using the factors. I mentioned earlier which they go into more detail about they summarize their findings on page 9 though, which is where I'm going to talk about it. They found basically the more movement there is an introduced code change the more likely the bug To escape code review which again it totally makes sense. If you're multiple if you're working on multiple things at once or you are reviewing a lot of things at the same time. You have less time and attention to put on those more finite details and it's more likely that the assumptions will get lost or broken without realizing it. They also found files with higher commit counts. We're more likely to have security defects Escape during code review, which I thought was interesting. This one was one of the points that kind of went against the grain for me. It's easy to think of it going the other way thinking the files with less commits are less looked at and thus wouldn't have more things Escape but it mainly ties back to that idea of movement. I think if the coach changing a lot that old code assumptions get broken very quickly. So it kind of makes sense when you think about it, but it was something that I hadn't really thought about it until this paper kind of highlighted that I guess there are other finding was experience of the reviewer does not Help them to identify security defects. I think this one was a little bit more contentious for me. I mean, obviously the more familiar you are with the code base and the more you know, how it works the easier. It'll be for you to spot when something is wrong. So I thought that was a little bit weird.
Well though they do kind of conclude that we can imply that security defect identification requires specialized skill which may not increase with participation of not security code review. That's kind of towards the end of the same page. That kind of seems to be what they end on after they go through kind of the few different things are that the reviewer doesn't seem to help that because the security analysis seems to be a little bit special. I requires a little bit more specialized knowledge. So just experience isn't what really
helps you. Yeah, I mean, I would definitely be okay with saying it's one of the leads impactful factors, but the way they worded it saying it did not help them at all. I think it's just like it's kind of weird to say that because a I would think would help at least maybe a little bit even if it's only a tiny bit but you're the only one that I found kind of contentious.
I think the other thing worth noting is they're looking at the Chrome or chromium. The people involved on this project or generally I'm not sure I would consider this feed average representation of like the average developer. I think that's kind of worth pointing out to like the types of developers that are working on Chrome. I mean, yes, you do get like someone off commits, but the types that are doing the code reviews and such. Are likely you know in general fairly good developers and I feel like that might create some biases in the stata,
too. Yeah, I mean there's definitely a limited sample size which they do point out to be fair. So that is something you should keep in mind and not only that like you're looking at one project you're looking at a subset of the reviews for that project and you're looking at things that aren't easily Quantified and have some subjectivity there. So it's it's definitely not something that should be taken like whole cloth right? It's something that you should look at the nuances of nuclear Enterprise
thing filling interesting. analysis though and just out of chat free SRX mentioned there are software platforms that analyze static code catch security bugs which devs rely on there are and most of them are crap compared to what Emanuel reviewers able to do and what manual code review was able to do there's a place for the automatic like static analysis tools like they catch low-hanging fruit they catch certain issues that maybe our little bit more difficult to reason about as long as you can spend the time to really train and tailor the setup on it It's a line of defense. It's not something that really should be relied upon for the security analysis by just there's like a sanity check or an extra track to save time before you pull on actual Security Professionals to do that same
review. It's like fuzzing. You don't want to put all your eggs in one basket into buzzing and then think oh, I'm buzzing my code. It's safe. Like you want to do the manual assessment as well and manually augment that and like you were saying like static analysis. There are some some neat tools when you get into like the expensive pricey range, but a the free stuff that's out. There is like I don't even think it's worth your time looking at in all honesty. I mean, it's maybe a little bit harsh but like they're just not good. They're not good tools. I mean I've
used some of the Enterprise stuff too, and I haven't generally been impressed with the thing is you need to Tune your settings with a lot of fun to get rid of so many of the false positives most applications. Just take a while to kind of tune. They can be useful. I'm not saying there's no use in them whatsoever because that's not true either. but the manual called who it's just a separate tool it's another tool in the toolbox both of them should be
used it doesn't replace it yeah so jumping back in the paper I mean yeah I thought some of these findings and here were interesting some of them were pretty obvious and as expected though it's still cool to see some data backing that up but like I said that there is that limited sample size which they point out and they're aware of but yeah I mean there were some interesting takeaways I think out of this paper and there's a big push to try to add security to open source the open source side of things Well, I guess this benefits more than just open sources about code reviews in general. It's just using open source as a as a case study. But I mean, I like some of these Pape like some of these things were covering. I think a lot of our episodes tend to be more attack heavy this episode I think is a bit more defense heavy. We've been covering some things to try to enhance security and it's nice to mix things up a little bit for a change with that. So
what I mean we've had A number of X lights on this episode. So I'm not sure I'd say it's a defense heavy one more
competitive. Even we've had a few more than normal. Yeah, exactly. Yeah. Yeah. We're definitely not only defense for sure.
I don't know how good only defense why would be unless it's like mitigate when we go to cover some mitigations and how to break those medications but ya know I really appreciate kind of this study. I didn't find anything to be like shocking nothing was too. Prizing outfit but it's nice to actually have the numbers that back it up this some study that actually starts to back up the same things. Yeah, exactly. But um, yeah, I
think that'll pretty much wrap up of the on Cass. Did you have any additional thoughts on that or any thoughts on anything in general before we wrap it up?
Oh want anything in
No. No, I think we're good.