Windows Bugs, Duo 2FA Bypass, and some Reverse Engineering< Back to Episode Overview
This transcript is automatically generated, there will be mistakes
Hello everyone and welcome to another episode of the day Zero podcast. I'm Specter with me is zi today. We've got some P0 disclosure policy changes. Lots of Windows exploits quite a few and some Snapchat attacks. So we'll get into the P0 policy changes first. So project zero has revised their disclosure policy as they said they would and last year's post. This year's changes have a focus on quote improving the current industry benchmarks on disclosing timeframes and adding Period for user patch adoption. So the changes aren't two major for the regular vulnerabilities the 90-day to disclosure deadline remains in place where issues that are left on fixed for 90 days are release immediately, but details about the issue come out 30 days after the fix if one is implemented which means technical details could come out earlier if it was fixed earlier than 60 days into the discussion period or it could come out a bit later if it was more towards the end of the The 90-day disclosure deadline. And again, that's to allow that user patch adoption. Similarly with issues found in the wild. The seven-day disclosure deadline is being left in place. But if the bug is fixed within that seven-day window, the technical details won't go out after the seven days immediately like they have in the past. There's going to be that 30-day period so yeah, I mean the changes are two major there. They're mostly like centered around that initial premise of just trying to give users more time to Ouch,
yeah, which they end up mentioning that they introduced that 30 days are basically they've included the patch time as part of their policy because it seems like while the intent last year of the whole 90 days was if a vendor wanted to provide users time to patch they would prioritize getting that patch out earlier. So that would fit within the 90 days and what they found were the vendors just weren't really either grasping that or being The willfully ignorant of that aspect and then you know kind of maybe not complaining. I don't know what the actual communication look like between Google and security teams. But they say there seems to be a disconnect in understanding like, you know, you should prioritize getting that patch out earlier. If you actually want to give users time to patch and save just 90 days. So that's kind of why they've decided to include that. I just find it interesting that there was that disconnect between their intent in the vendors. This definitely makes a lot more clear. Like I think it's a good move and this actually just reminds me of the the complaints. I've had towards hacker one where hacker one is in kind of that really. good position to Kind of walk clients towards having a better more mature security process. Whereas in this case. Google is just like that. This is our disclosure policy and like they're slowly inching towards. What is a more ideal policy. They even mentioned here like in the future they're doing the 90 plus 30 right now giving more time than jumping straight to what they want, which is 60 plus 30. And then talk about reduce get down to 84 28. So they fall on numbers divided by 7. So basically basically you're not ending up with deadlines on a weekend ideally unless I do a disclosure like the initial report on the weekend. I think it's a good move. I like seeing Google making these incremental updates to it and explaining why because honestly since project zero first like launch with their 90 ish day policy. In the year since then because I was back in when was Project zero established. I want to say 2014 might have been 13. Since then like 90 days has become almost an industry standard for a lot of
So they've been in a sense kind of the market leader on this if you can call with that, so I appreciate the fact they're being a lot more open about how they're coming about these numbers so that other people kind of start following get an understand where it's coming
from. Yeah, so I just looked it up July 2014 was when Google project zero is founded. I initially searched up project zero established and I got 1967 so that wasn't the Google project zero and I
think yeah. Well they were doing the vulnerability reports way back.
There were way ahead of their time. Yeah, like like you said, I think it's a positive move. I do find it interesting they speculate on what they could be moving to for 2022. They say for example based on our current Data Tracking vulnerability pastimes this likely that we can move to a 84 plus 28 model for 2022. Right? So and and yeah, that's what you're talking about a little bit with the deadlines not falling on weekends. So yeah, I mean that it seems like a positive move. It's cool that we could end up getting vulnerability details earlier if companies are kind of proactive and get it fixed quickly that said I think it's Going to fall more on disclosures happening later than sooner just based on the way that we've seen things go but
I've been clients are almost are not client. Sorry vendors are almost certainly going to push off fixing things. That is what they tend to do. Push it off as long as possible give themselves as much time as possible. That's Ed by establishing that patch time in with their disclosure timeline in this case. Yeah, they are. Extending it out. But like they mentioned their goal is reaching that 60 60 30 split rather than the 9030. They're just starting here. So in a few years, hopefully they'll be able to reach the point where they're hating get closer to that 6030
split. Yeah, so yeah, some good moves by project zero and don't can't really find many issues with the new policy. So I think they're good
stuff. Thanks balika for your seventh month of
subscribing. Oh, yeah, welcome and dude. Alright, so our next post is around what's app on Android and to vulnerabilities that can lead to rce and leakage of noise protocol Keys using something called a man in the disk attack, which is is basically man in the Middle where you use your access to the external storage or SD card to link data. It's worth noting that these attacks should not be possible on Android 11 Android 10 introduce scope storage where you were kind of sandbox to your own content on external.
to prevent exactly these kinds of issues but on 10, it was somewhat permissive to allow like a graceful transition period for developers. So these issues affect Android 10 and lower but not Android 11 that said a lot of users aren't running Android 11 or probably not even Android 10. So that doesn't really take away from the potential impact of the vulnerability, right? So what are the phones it basically boils down to the fact that WhatsApp had TLS session State information. Including Secrets cash to the external storage to utilize TLS session resumption which they go into an in some detail in this article, but I don't think it's too relevant that we need to cover it.
Yeah, they go into a lot of detail and that's talking both about the session resumption information the Chrome CV that they kind of use to exploit this but really the vulnerability simple their writing sensitive information to a publicly accessible location namely bestie card. I think the crypto information out to the SD card where somebody could read it. Like it's simple, but this is a very long post for a fairly simple
issue. Yeah, so yeah, I mean they mentioned a few ways you could utilize that for an attack. They mentioned you could like pull it off by fishing using a chrome same origin policy bypass which was a 20/20 CDE. So the Chrome could access the media store of other applications zi the to vulnerability is basically the same issue but on different endpoints being TLS 1.2 for client to server communication and TLS 1.34 end-to-end encryption for check. Indications. So with the TLs 1.2 MIT em, you can get an RC e and that basically is based on the ability to send downloadables from the server such as doodle emojis or photo filters or whatever which are downloaded by way of the zip files. So if you just replace the URL where it downloads from it can download malicious Sip and WhatsApp uses Facebook Super PAC for Distributing native libraries, which are packed with the application so you can use a malicious zip File to replace those libraries to get your own code ran when they get loaded in. The second attack was leakage of noise protocol keys for end-to-end encryption. If you can man in the middle TLS 1.2 and 1.3 which their attack there was basically intentionally triggering an out of memory exception to get the application Heap dumped and sent to the server through crash logs and the application Heap dump that was sent to the server would include decrypted. Sation information as well as the noise protocol key pairs, there was like no filtering on the crash dumping to you know, not dump really sensitive information. So yeah, they they basically trigger that a memory Exception by using the MIT em to tamper with the response that gets read into the string buffer for getting stickers. And then yeah, they would just pull the crash on while it was being sent to pulled the keys out of it. So yeah some cool attacks. The post goes does go into a bit more detail than I think. Think it probably needs to but it is there if you want to check it out and get some information about how TLS TLS replay works or TLS session reuse. These wounds are a good example though of why that defense in depth and the form of scope storage is is necessary and it's actually a little bit surprising that it took Google as long as it did to do scope storage, like only like Android 11 is pretty new. It just came out. Number of 2020. So yeah, I guess there were a bit late on that on that front. So Yeah, I mean just some crazy issues and like I said, I really don't know why they're sending the keys in the conversation info and just a massive heat blob to the server. I feel like they they really should be doing some kind of filtering on the crashdown process,
but they show people what do you filter like do you because like your crash timeshare just like, you know, what's in memory at this time. So you go through and you look Kay. What values are you going to compare to actually look for a not to dump or what memory region should it? Not dumb and one hand you could say it should remove some of those things from memory, but given the fact that you're going to be like those conversations may be active at the time of the crash. Like they have to at least some will be available the readable and memory. So I think it would be more rather than filtering pulling out the relevant information, but that kind of reduces the usefulness of a crash
dump. I think it's probably keeping the crash reporting. I think the crew the keys at least the key should be put into like an isolated he brewarrina or it's like if the heat gets dumped then that area of the Heap is excluded. So I did
the flip side would be including some of that. Oh, but encrypting it before it gets sent out using public key crypto. That way you can't be read by a man in the middle. You can definitely still have some issues where okay, but now WhatsApp is able to read these supposedly end to end. Cryptic messages so there's still some issues with the crypto aspect. It's somewhat feels like they just shouldn't have the feature to begin
with. Yeah, and for what it's worth like doing public key crypto on Crash dumping functionality is not uncommon. It's funny Sony actually got hit with the same issue on the PS4 fail overflow managed to abuse the crashed on functionality of the PS4 and be able to pull crash dumps because they weren't encrypting them. So they had to go back and retroactively like add encryption or not retroactively, but, you know in newer firmware updates, I guess add encryption on That so yeah, I mean it I guess crash come functionality is just one of those things where developers don't necessarily think about it as a potential like as a area it could be side channeled I guess but it absolutely is and yeah, I guess it's just somewhere that people don't really think about so that's why they get attacked as they do.
Yeah. I mean it kind of comes down to the same idea with just overzealous logging where applications might Lease a log a password or like log the entire request and it just happens to happen during like a password request or not are like during the login and like something that includes a password. That's kind of the same HR feels like the same issue as these crash dumps its just overzealous information
collection. Yeah, exactly. So not a super complex issue, but it pretty impactful issue basically. All right up. Next we have a blog post from positive security about multiple bugs. They found in popular software like cryptocurrency wallets Mumble Wireshark telegram next cloud and others one of which we've actually covered on the show a month ago on episode 69 with Wireshark as such we'll probably just briefly cover this one because all the issues are based around the same premise and that's allowing arbitrary URLs without filtering out the scheme at all. So by allowing an attacker to control the URL that gets shown as Clickable link or whatever and not rejecting things like the file scheme or SMB or SFTP or whatever that can lead to whatever action is attached at filter getting ran right whether it be like an executable getting ran or a Java archive or whatever being downloaded and ran what's cool about this post isn't so much about the issues as they're pretty straightforward. It basically comes down to filter your lengths, but they also have the central listing of like the common operating systems and the the opening behaviors they have so that includes Windows Linux based operating systems and Mac OS and they give kind of an overview of the types of places. They found those vulnerabilities. So I think the OS link behavior is probably the most useful part of this post to
me. Yeah, the I found it just interesting some of the place that they found it was getting used actually in particular. I thought the VLC issue was interesting. Let's see if they have a link right to it. I mean the okay, they have a link to it. But I apparently can't actually there couldn't click on it. Um the VLC issue ended up being in. When you would have a playlist. I'm just try to skip ahead here for those of you that are watching and then you go show containing folder and that happens to do the open like that's not where I would have expected it to be trying to do that. Like it makes sense that it's trying to open that location that way it was just a little bit surprising. Like I had never it's not somewhere. I've even thought of as being a risk to click, you know showing containing folder. So I found that one interest we as a blog post. It's just a lot more on the research side. Just here's an overview of everything not entirely surprising we've seen this sort of issue before we've talked about the vulnerability these types of vulnerabilities before so it's not not necessarily new. It's just an overview of it and likes it. It gives the information across platform or across several different platforms.
Yeah, and like what I've kind of said before is with these types of issues. The impact is usually pretty limited if it's just like a clickable link because in most cases you're going to be able to see the Lincoln see okay, that's a really fishy URL. I'm not going to click on that hopefully but I mean there are some cases where it's not as cut and dry and it could be more impactful. But yeah, I mean a lot of these applications like with telegram and Wireshark like when we covered it at the time. And like Bitcoin and Dogecoin wallets, like they mentioned you would have to do social engineering in order to get somebody hit with that. So like not super practical issues and a lot of cases but it's used to be aware of nonetheless. And like I said, I think the the information on the schemes with different operating systems is useful because those schemes aren't really standardized between operating systems so that it's easy to like not be aware of how dangerous they could be. So
yeah, I mean ultimately applications just like if you're going to give that click through ability just look and make sure it's actually like HTTP are it's actually more or less what you're expecting. This is validate what you're sending out what I think I saw some comments maybe was on Reddit to this something suggest or maybe it was even in this Posse suggest the operating system is kind of at fault for even doing that. Providing get there. I wouldn't I was going to come like I wouldn't blame the operating system for this. I think it's definitely case applications using the
Or misusing get in these cases.
Yeah, exactly. It's up to the applications to filter like links that are going through it at that's not the fault of the operating system. Yeah. Alright, so we have a quick issue in an open source project called in for a box which involves log injection, which I know was what you found interesting about this topic say so I'll let you go ahead and take this one away.
Yeah, the actual vulnerability itself or as the name implies with log injection, you're able to control what's being written to a log not an insanely damaging if she like you're not getting code execution. You're not revealing any sensitive information that would affect. You just have this Json request to this API slash login point and the actual value and long here just gets written out to The Container named off log. So you've got path traversal they're also has to end with dialogue. I don't know how deeply they looked into like if no whites are some could cancel out but in theory, it's going to be your doll log files. So you can't just arbitrarily arbitrarily override anything and as an issue. I just want to kind of shout it out. That's something that it's difficult to test for if you're like a bug Bounty situation for log injection. Unless you can actually read the logs or if you have Source access. So this is one of those issues that I think kind of gets overlooked and definitely get to downplayed because it gets down for I mean think shout out here kind of the ability to possibly do excess and like whatever the log viewer is that's going to vary most log viewers probably are going to give you access, but it definitely happens. But I do think one of the big issues there's as soon as you need to do incident response. On one of these things like on a vulnerable applications all of a sudden you can trust the logs at all because somebody can just go ahead and inject any sort of log entry. They want make it look like anything happened before after an attack. Like you can't trust any of the entries and that is why I think log injection is a fairly important issue to at least consider even though I think he gets down played quite a
bit. Yeah, it's not something we see too often on the show. I think we have covered one before in the past back on episode 48. We had an xss through logging user agents and Leo stream connect broker. So yeah, like that's an example of one we've covered before but it's certainly not something that's covered super often. So yeah, like since you can write the arbitrary contents to a log file just like in that case and this case you can use xss. And you could also like maybe do other things too like fake log events of some kind. Well, maybe decided to bury something in the
log. The faking law commands is exactly what I'm talking about with doing log injection is being able to tamper with those entries. Yeah, because when you can do that, like now instead of response can't trust anything that comes out fed, especially if this ends up going to like a universal logging system, depending on how well it's able to determine where the log Source came from you might be able to Vlog from other applications and things like that, of course as an attacker, you also have a hard time knowing what your logs data look like their challenges with that but it's one of those issues that really I think needs to be there kind of for that in-depth protection because like your logs at least in my experience. I am not an expert when it comes like forensics or anything in my experience. Like if you're doing incident response, like that is a big thing that you're going to be looking at perhaps professionals. Maybe have some better tooling that I'm just Earlier with that's completely possible. But I feel like logs are still fairly important. So I just want to shout this out as one of those attacks at it's worth considering even if people are going to downplay it or ignore it on you.
Yeah, that's got to be like nightmare fuel for for IR I can imagine. All right. So up next we have to two-factor authentication bypass has in do o2f a detailed by Sean kamerlingh. It says it was posted on January 28th, but it only went public recently. So it's one of those cases where the date that's on. It is actually the native writing the potato publishing which is really confusing. But yeah, I don't let the date to see view. It's a lot newer than the titles or and then the byline suggest it details to 2fa bypasses. The first bypass was sort of a replay attack due to The authentication State not being tied to the user session. So basically what you could do what you could capture your own legitimate to a favor Quest block the response from reaching your device to prompt for authentication then submit it to a favor Quest using the victims credentials as an attacker, which they presumably compromised then replace the session ID in that request with the session ID from their legitimate request and that would get the duo app to prompt for authentication using the victims off State instead of your own.
Okay. So I I might have misunderstood part of it, but I believed and what was going on with that first request the attacker one when they grab the SSID that it would drop the request of the request itself was never actually going to hit the server with their SI D. They just called me there S ID from that first request that went out and then they copy that one into the second the victims. Request copy there S ID into that one. Let the request actually go all the way through that time. So the first time the the S idea was being seen was when it was kind of associated with the victim's
account. Yeah, sorry, so I was kind of conflating the first issue in the second issue. You're right. The first issue was on the dropping the request my bad. Thanks for correcting me there. But yeah, that path was a bit racy because that session ID would expire pretty fast. So you would need to pull off the entire process in a pretty timely manner, but they found another variant which got around the problem which before you
go into the second variant. They mentioned they kind of had to be quick about that with the SAT. But this feels like something that could be automated pretty easily. Especially since you control the device is going through this. So I just to be clear with this. It's a 2fa bypass. You still need to know the victims credentials. You're just by like Duo provides the multi-factor authentication. They've got their own little system. I'll show you a little alert on their app and you can like approve the log in there. Oh, so you still need the credential? So it feels like something you could pretty easily just automate like a few, you know python requests or something just automate these the login attempt in the other events going through there something or been maybe man in the middle. It's probably doing some sort of serpentine or something to make that little bit more difficult. So I feel like that's righteous within kind of their expected threat model. I don't know for sure, but I'd imagine they're doing something but But still this feels like something you could pretty easily automate so saying that it's racy or like it. They've got to move quickly like just don't do it by hand. Would be the solution not we need a whole new vulnerability. I mean, I'm glad they included a second vulnerability there, too. It just feels like maybe it wasn't necessarily like their problem with it. Like maybe if they include more information on why they conned automate it but as is writing this I just felt like well, why didn't you automate it?
Yeah, it feels a little bit over engineered and that regard but yeah, they did go through the process of finding a variant that was more stable or wasn't as racy. The second method was kind of what I was getting it confused with earlier and it was on a slightly different part of the authorization flow and it was instead of Making the request you would attack the response the to a favors response which would contain a transaction ID or token which would be used to pull for the status of whether or not the user accepted the bush requests on the device. So you can basically start an innocuous dual off requests on an attacker device accept it intercept the request sent back to the server then replace the transaction ID with the one from the victim's user account login and trick it into thinking the victim do a lot and that method was more stable since it didn't have the same. Timing aspect you had to beat the victim to using the transaction ID, but that's a lot larger River Race and especially if you're automating it like zi said that's not even a concern really so but yeah, you didn't have that aggressive expiry like you did with the first path. So yeah, like you said it did feel a little bit over engineered. There were a few parts of this where I was I was wondering like if the authorization flow is this week, it feels like you could just attack it like In a simpler way, but that could have just been that there was some information missing. I'm not
sure that was kind of my issues especially with the second one where it's used in the transaction ID. It feels to me like if because all you're doing you're replacing the transaction, I'd like you intercept the request going out drop in your attack or transaction ID instead of the original one and it gets the response saying it's okay and it moves on Is this an all client side validation? Like that's that's what it feels like to me. And the only thing I can think of is okay, perhaps it's doing something like you can only access each transaction like after it hits a status. Okay, you can only accept like once or something in which case. Yeah the fact that it's seeing it would kind of be okay, or maybe it's doing something on the server side like messing with your SSID when you get that first response, that isn't okay. I don't know it's just The way they describe it. It sounds like you should also be able to intercept the response and just drop in that status. Okay and likes a - pushed are like the Sorry, the status result success just being able to push it that in feels like you should just be able to do that and it should just work in theory.
Yeah, so, I
don't know like they don't really explain why it work this way. Maybe they don't know. Maybe there's some to it. It just this looks to me like just that standard old client side validation where the client is just looking to see this result success and the response. Without any concern over whether or not it's the right. on this case transaction, but either way It's just really suspicious to me obviously wasn't vulnerability. They reported this out. Like I'm not questioning whether or not to real vuln. Something just doesn't add up. It feels like we're either missing some information or something's happening on the server or something like
that. It seems like the authorization flow is kind of weak on Duo side and yeah to clarify when I was saying that it just feels over-engineered. I meant the attack definitely not D authorization flow the authorization like Duo side was actually under under engineered.
We all know if the attack would necessarily be over-engineered if they're doing it by hand. It's just because they didn't spend the And engineer like the script up on in case in the case of the first vulnerability. So doing it by hand. Is it really over engineering yet? No. No, I'm on the second one area on the second one though. They're just try dropping in the transaction ID. It's a lot more intuitive. I guess a lot more common to intercept or requests and intercept the response to a
So during the change there instead of trying to do it on the response I think is completely Fair. Oh, no, it doesn't feel over engineer to me. But
whatever. So to be fair to Duo these issues were reported to them and said suppose gave them some praise here saying they were pleasant to work with which they said wasn't super common in their experience with with company. So yeah, and it's and it said like that raise their opinion of Duo as a customer because they say they use Duo for authentication for their like company whatever. So, yeah. It's always nice to see that kind of I guess feel-good Story coming out of the wall. Nobility disclosure timeline the issue was fixed pretty quickly from what I can gather. It was fixed within like a week or two.
So well, so they have the report on December 14th reports Duo and on the 18th dual confirm that the fix had been in place for a few days. So that's only four days and then the fix had already been there for a few days. So it seems like they may have fix it within a day or two not a week or two.
Yeah, so even better. So yeah there we've kind of said in the past that like the response matters more than the original issue. I think and in this case, you know while the authorization flow did kind of seem weak to me like we were saying though like it could just be missing information but regardless like the response was very positive. So yeah. To see all right up next we have a hacker one report about grammarly in single sign-on authentication before it was made available to the general public. So that's good that it was caught early zi. I'll let you get this one off because I know you like the sam'l aspect which you've talked about before on the show
or doesn't say I won't say I like the sam'l aspect but I figured at least I'm familiar with it to cover this one
or not Witcher.
I mean the sam'l aspect is Central you don't really need to understand all of sam'l though. Grammarly implementing their single sign-on solution or while so you can integrate with other providers. I'm actually not sure now that I'm thinking about which direction things when should be interacting with other providers though. Yeah. I can't see why grammarly would be a provider anyway, so what would happen here is kind of a disconnect when an attacker when you would log in when Ukraine organization. You set off this entity ID. The anti idea is supposed to be kind of globally unique identifier usually look something like a URL or might even actually be a URL includes like the domain name of the provider some like that. So, you know belongs to that provider and it's globally unique. It seems like grammarly might have kind of depended on the fact that's globally unique. So what would happen is if you were to create an entity well, crane organization give it and to the ID that had a space at the end of it, but otherwise exactly matched an existing organization and their existing entity ID then when somebody tried to log in on the original organization, it would do the proper sam'l thing there, but then when grammarly would look up the by the anti idea would go and look up what organization should log the user into our add them to And when we do that, it would always pull up the anti the idea that had the space at the end. My guess is you know, it would it was like a database query it would look up for this entity ID. And because the two were so similar it would pull up both of them, but it's only expecting one result. So just take the first result and it just happened to like sort by the latest entry or something like that. So it always get the attackers version of it and add them to that. Application or add them to that and to the organization so that ends up allowing you in theory. You could probably come up with some sort of authentication bypass with that or like taking over an account. They mostly just had denial of service where users can no longer access their actual organization or any of things in there, but yeah, I know. I just thought it was kind of an interesting attack in that look up and they trace down a seeming to be because of a Sam like using a trim on the issuer to look it up. Either way straightforward issue. Not really what I would expect her really non-intuitive a sheet of though I
think. It was a bit complex to follow which is interesting because usually like hacker one reports that kind of a quick to understand and cover but this one was a little bit confusing especially where like you were saying like you have more of the experience with the sample type systems and I did so I'm not going to lie. I struggled through this one a little bit. But yeah, I basically just seems to be like a desync around how that entity ID is handled and that can lead to daus or user account. As if they were already in the or if they weren't in the organization yet and they were being added that for the attack organization was created the the researcher got a nice Bounty for it though. I think they got like 10 10 and 1/2 k for this bounty. So yeah, it was a very high-paying issue. But yeah little bit complex to follow but coolest you nonetheless
actually since you mention that I'm just pulling up for trying to pull up at least what grammar Lee's usual average bounties only two to three hundred. So that's
That's quite a bit higher. Yeah, apparently though they do on the focus copay up to 20 K uncritical which is also surprising. I didn't realize grammarly wouldn't go that high. But yeah interesting. So PT security PT swarm, they put out a post about a bunch vulnerabilities. They found in cockpit CMS a total of four. No SQL injections, which were all pre-authorization and a fifth issue, which was a authenticated. PHP injection, so the first issue they cover was and the off check endpoint for authenticating users. They take a user-provided parameter of the username and they pass it directly into it filter object and they don't do any sensation on it, which means you can embed an object with mongodb operators into the parameter. And now the
sorry just going to add in for what it's worth like when it comes to these no SQL injections. This is the most common way you're going to see it is Usually it's something in a filter where they're intending to just pass in the string. So you filter by the filter Chi and then it takes a string from there. And when they don't account for the fact that you can create an object. That's where you get the injection because you start doing matches by a ton of other options such as the regex or think they use EQ as one of their examples are like you can do a ton of other comparisons than just the equality against the string. So I figured I'd just shout though, like that's kind of how How mongodb Works in this case just some that's often forgotten about and the root cause of these sorts of injections.
Yeah, so the injection is a blind injection, which they get around by getting a warning displayed by intentionally passing an array for the password parameter. They note a few ways. You could take advantage of this injection such as using the EQ operator to Brute Force user names and side channeling with the warning. It's like if the warning is true The user exists. If not, the request was successful in says he was or wasn't found another way was using the regular expression operator for another brute force the most interesting Way by far though was using the funk operator of the Mongo light Library which gets used which can basically allows you to call any PHP function with a single parameter which would include VAR dump. So you could use VAR dump and just dump all the users and the base. So yeah, I mean that was that was definitely the most useful way.
May not feel like an attack there that I don't I know they cover something else that uses eval but having a call as a funk. I mean, I don't know maybe the plug-in itself will like you do this but having a collie valid all the usernames.
I can see that being put on like a danger list there were well.
Yeah I could too but you don't even say something like that.
Yeah. Yeah, II know SQL injection was the off requests reset for creating password reset tokens. Again, it's the exact same issue. No checking on the user parameter third and fourth issues were in the reset password and new password and points again same issue, but on a different variable it was for the token parameter that went unchecked. T' and that time they could use the funk operator trick to not dump usernames this time but existing tokens from the database which is a lot worse. So with the ability to chain together, one of the first two issues and one of the second two issues, you could dump valid user names and valid tokens, which gives you all you need to be able to compromise user accounts through the API because you can now use the API with the token you have to dump user account information. You can brute-force the password hash and reset the password with the reset. I swear I'm point which can then lead to rce because cockpit has a finder component, which is basically it's like a File Explorer File uploader and you can upload a file which includes a web shell for example. Final bonus issue was a PHP injection when parsing filters on the accounts find method which will take a user provided filter and use it to build up a query that gets past the eval like zi zi was saying earlier though, like this endpoint does require authentication as I said at the beginning of this topic, so it's not unauthenticated like the others and thus I don't really know how useful it is because like they pointed out if you're authenticated you can already upload a web shell so being able to execute PHP code. Through that manner doesn't really escalate you as far as I can read, but it is an interesting issue point out.
Nonetheless. Yeah. I mean, it's another route to the same thing. That's I do want to call out that the vulnerability itself is in the fact that it reflects the key value out of this dictionary. Oh I don't know. There's just something because so often, you know, you're going to attack a value you're going to attack the value of the value not the key. So, I don't know. I just like seeing the vulnerabilities even though this one its impact is kind of a gay by the fact that you can do this elsewhere to it's not the only way of getting code execution. I should just kind of like seeing it when they have such a vulnerability words the key. That's the issue or you've got a kind of you've got a test, you know random things in the key instead of the actual Valley there. I don't know. I mean it's stupid, but I just think it's such a fun place to find issues end.
Yeah, it's kind of a nice change of pace. So yeah, lots of vulnerabilities and details on how those vulnerabilities could be abused in this post in terms of timeline turnaround was very quick first set of issues was reported October 14th and fixed 26th. And then the second dish set of issues was reported on March 15th of this year and fix March 17th. So within like two weeks on the first set and within two days on the second set, so yeah quick turn around our next topic. Is a container filled container Escape for bitbucket pipelines zi I'll let you take this one away because I was a bit late to get into this one. So I don't have a good summary on it. So I'll let you take this one.
Yeah, so this one was also a little bit. Well, it's a bit of a long read. Oh, there's a couple issues that they come into. So first of all kind of explaining the whole container set up there looking at trying to escape the Kata or a cat of VM. And so the way these build pipelines are set up. They do have a Graphic here. The idea is first of all with Kata VMS the idea is kind of have a more secure VM. Lightweight container runtime that feels like containers but offers lot stronger isolation and then inside of all the VMS that's where they'll run all the container. So I want to say they're back in here was qm uvm's and then all these containers around inside of it including your actual build. So bitbucket kind of being anti being like GitHub, but not its from atlassian. obvious offering the The ability to run builds when you commit whatever so breaking off the build container itself was fairly easy privileged Docker container use the no one technique to get out of that but one of the things they wanted to ensure with this more complicated setup is like you could not interfere with other users and other users builds that are happening on the same kind of container host. So you have this isolation between the different house. So what they found was that inside of the build container the docker the user bin Docker would give mounted in there and it was mounted as a read-only file, but what they found once they escaped that build container and they were just sitting inside the VM the docker executable was actually in a rewrite mounted folder. There's just this General folder that had a bunch of things including amount to the read write talk. So once you escape the container you can go and just replace it DOC or with anything you wanted and all the other containers on that same coming from the same container host would use that tamper Docker. That was the first vulnerability that they reported. They did also start looking into getting a full VM Escape, which I thought was a little bit more interesting it gained. It came down to things being mounted that maybe shouldn't have or in this case gets amount was necessary, but What they found was that there's this log directory see if I can find it here. VAR log pods so basically all the pods and then name space pod name whatever and director there and it had the output for every file just being rude or the standard output for all the builds and services. Whatever else would be written into 0 DOT log. So standard out of log. It's written there. And then the container D service on the host was actually or sorry a process on the host was writing to these logs and container D would also kind of have it open doing things there that's being used for like the web UI things like that. But anyways something on the host so was writing to these log files getting the output from like the docker run or from the container run whatever writing them into these log files. So what they found Is that they could just go ahead since it's a read/write mount go ahead and replace that 0 DOT log with a symlink some other file. Which would actually give them because it's being written by something on the host when the host tried to write that symlink. It would go ahead and write to any other location or well it would go and write to any location that it could on the host allowing for kind of a container Escape. It was a little bit trickier with that just because container D would basically ignore are so when you replace the file when you replay said zero dialogue with a Symlink It Whatever reopening actually fall assembling it would just get an error when it tried writing and with that are it would just ignore it. So what they found was they could take advantage of the log rotation system by creating a file that is greater than 10 Meg's it would see that and be like, hey, we need to rotate the slog rotates it and then tells container D to reopen it after does that rotation and if you could race that where it would get rid of the log file and then come back with and then tell container D to open it. You can basically race that crate your symlink before container the opens up, but after the rotation has happened. And at that point you can get to go ahead and write out to any file on the on the house what they didn't get the chance to do is actually find a Target or the scripture right to to override some script. That would be executed. Part of the challenge with that is because the file being written. I believe the permissions on it were owner read right but not execute and group and everyone. We're also had no read-write access. Sorry, so that may be a little bit challenging. They didn't have the time to actually go through and find it and up getting patched before they could Find any proper Target but there's a reasonable chance that some script might have been getting executed directly just calling bash and filename that they could have overwritten with this. They didn't go through it. But that would have been how you'd get the escape from it. Yeah, you
could also a config file or something to possibly
yeah, there are some other places you could look to try and figure like I guess actress since there's a log rotate. I know we've talked about are see-through log rotate before they're one of the actions. So depending on I doubt it was using the normal log rotate that we use when we talk about that phone vulnerability, but it would be something you might be able to do something similar if they have some sort of config actions like that. But yeah, they didn't get the chance to do that. So we don't really have information on how you could have escalated just they had an arbitrary file. Right, which is a fairly powerful primitive for trying to
escape. Yeah, it sounds like a pretty cool attack than involves some pretty clever tricks. So yeah, definitely like sounds like there was some cool stuff to read in there. But you said though it is like really long and that's kind of what got me to is it was long. So I went to I was going to get around to it. I kind of you know crafting a little bit and then yeah I ran out of time. So thanks for coming. So next we have a real fast issue on X screensaver on Debian through project zero. It's an issue where the X screen saver app has the cap net raw capability which allows you to open raw sockets. That's usually a privilege functionality because the ability to create raw sockets and send your own packets on them is pretty sensitive. It opens up a whole new area of attack surface for parser bugs and whatnot. Since you can control data at the you know, the protocol level. So yeah. Very straightforward is basically just an exposed capability that shouldn't have been exposed for I just a permission that wasn't track properly.
Yeah, I mean it's kind of funny just fact that you have a screen saver has cab never access on it like that. That's a little bit more than what you'd expect. Apparently. There's a screensaver that was like this so sonar but it would show different IPS here communicating with and that's why would you say it it's just excessive it's old but it's definitely kind of excessive.
Yeah, it kind of breaks that rule of only giving permissions where needed basically at least
privileges. Yeah, I believe I thought Tavis actually Sound - yeah, I'm going to open up a tweet from
him. Oh that you have a
yes. I can you put it on about the vulnerability to okay and had a little Spring Shot basically of doing a using Sonar using this screen saver to run a TCP dump without needing grouped.
But he also has video of the actual screen saver. That was the source of this. At least I thought he did
and just look at some of the replies. Oh, no, not X screensaver again.
I did think that the screensaver itself. At least looks kind of interesting. I've got it up on screen. Obviously those of you listening to us can't see it. But as I said like a little screen saver that would show the IPS being connected to and have them ping up on there and if a fun idea but how it's implemented is just a little bit excessive fun vulnerability
though. I will say like that is a really neat screensaver idea. But yeah, that's funny that it led to the vulnerability. So all right, we'll jump in to a bunch of our Windows issues. So our first one is reverse engineering TCP IP sis and discovering a vulnerability and trying to exploit it through patch stuffing. So yeah, this was a vulnerability that was fixed in February and the TCP IP dot says kernel driver. So they Reverse engineered that patch tried to figure out what the issue was and ultimately wrote a POC for it though. It's not really it's not a POC for code execution because the bug is ultimately an ulti reference which is usually it's not really exploitable these days there has been a few exceptions and the past where we saw one were it was possible to maybe get around
what so that you're thinking of that bro Vin post the
dog Association am was that when I was talking about is like wait,
wasn't that what Koreans?
North Korean actor
Pope's got a reference again that one I mean dos RC was a was very much a bad name for it because like the actual vulnerability wasn't an OD reference or denial service to take advantage up with this one though. There's a ton of reverse engineering and like the process. I went through to figure things out. vulnerability itself brilliant up coming down to just the Back that when it created this net buffer, it would actually sorry. I'm going off topic. I had actually gone and interrupted you more to mention that the Dawson this case while it is just a Doss and it's not RC. It's a little bit more powerful of a dots because this is something you could send over the internet. I could just send you this packet and crash your computer because it when you were running Windows, which a lot of people are like single packet to kill the Entire Computer is a pretty powerful exploit. Even if it's just the Dawson, uh code execution. It's the type of thing that could definitely still be abused especially by Script kiddies to just Spam it out with or something. But the actual issue came down to the truncation when it would create the net buffer. It would pass in. Let me see if I can find the function
here. I think it was the retreat Hot Spot like
yeah, so it would pass in the header and options like but specifically it would send it in as a 16-bit unsigned integer rather than I'm not actually sure. I think it's 32 bits. Yeah, it was their turn to bit. Yeah. Oh it would send it in as a 16-bit one when it would call this net. I'll Retreat net buffer which is effectively kind of the first initialization of it. So that would end up saying the data size of it to the 16-bit. You so if the header and options length was actually greater than 16 bits it would get truncated, but then when the ndis a get data buffer, so that's you've got the snap offer. And now that functions being called to actually get a pointer to like a contiguous chunk of the backing buffer inside of that net buffer. Basically, you'd call that it would call it with the full-size that for 32-bit size. And that would create a disconnect. It would look inside there. Like hey is the size of our is the size that they're asking for which is what that argument is. Is that greater than the size of the actual buffer that we have since it is it's like hey, this is an air condition it would return a null but as you can see in this code, it just does buffer equals and takes that buffer right out of The end s response it doesn't check for null creating that note the reference way actually tries to write the value to that
buffer. Yeah, just dereference the pointer without doing any checks on it.
Yeah, so the vulnerability is interesting, but also not easy to see how to exploit that because that's just the getter and options length of your packet. You need to get that greater than like a 16-bit unsigned in
which standard system and over the Internet. You're not sending a packet that huge. Like maximum transmission unit usually something like 1200 1500 bytes. Give her two. Yeah, whatever like you're not getting something that big. So the actual sir the actual way they went to bed with Ed's using recursive fragmentation, which there's a second post that they showed out here. They have a link to From quartz slabs which I think covers the fragmentation aspect a little bit better or at least visualizes it.
Yeah, the way packets are structured as really like complicated and it's not like the same everytime right? Like the way you structure the headers is going to be dependent on what protocol you're using or whatever so it's
no so the IPv6 headers are always going to be the same and then like the lower protocols like your application layer protocol is just kind of inside the data segment of the IPv6 header itself. So this is still within the IPv6 header. But what they did with the fragmentation to do recursively see if you just sent a normal. So, of course when you run into an issue where you're dealing with the maximum transmission, you need to get round that fragmentations kind of where you should go. The problem is even when you fragmented that header and option length is still going to be limited by your first pack like you can't in theory. You can't really split that up over several packets because that needs to be included with every packet it'll send IPv6 header in the fragment header and then data the needs to include that part every time there's at least some fed every time so you are limited. So they fragment one packet and then at the start up all the fragments it would have a second fragment packet or header inside of the fragments so it would reassemble and then see like, oh this is actually this needs to be reassembled again out of this buffer. So it basically just recursively and up fragmenting the packet which I thought was a really neat trick. To get around that and that recursively created packet could have like an endless size for its headers allowing them to get a large enough to be larger than the 16 bits. Required for the truncation to create that disconnect where the 32-bit and 16-bit values are
used. I did want to say also thank you sodding for the raid. Welcome in everybody. We were a little bit late on that because we are covering the issue. But yeah, I didn't yeah
you out there. I apologize. I miss that here. I'm not getting the audio through and re-tap. Yeah. Thank you for the
raid. Yeah, no worries. I didn't want to interrupt you while you're recovering issue. So yeah, it is like a really long post with centrally an Aldi ref. Like you said though. The impact is a bit, you know more notable than you might think. Was it is remote that's why it's you know, title includes packet of death. But yeah, I think what was cool was the reverse engineering aspect to it, which something we don't cover on the show a ton because we typically cover stuff where the source is available or even when it's not the post just kind of skipped over it and hand waves it like yeah, we did some re and found that it did this and it and they keep it very specific to that one. Like exactly where the bomb was. So where this post goes more into like the patch. Stiffing and their thought process when trying to figure out where the bug was from and trying to figure out like not from a black box perspective because they had symbols but I guess kind of like a gray box perspective. So it was cool to kind of get that shake-up of covering reverse engineering and we don't always get to and that's true with a few more of our topics today to actually do to Windows being such heya such a prevalent topic this week. So yeah, I mean with that said we'll jump into our next window. Topic which is exporting system mechanic driver. So this is one of those maintenance products for doing like system clean up and whatnot. Like Active Care. I mean a lot of those products I think are like scams and I don't think people should be using them anyway, but I don't know about this one specifically. Maybe it is a useful tool. I'm not sure but yeah avoid SEC ended up looking into this product. So again because it's Windows it touches on that reverse engineering aspect to finding Vulnerabilities they talk about how they reverse engineered to find all the I octuples at the driver would expose that this program used and then once they found them they did some fuzzing on them using I octal be F which is a basic generation based father within seconds of launching that father had found an access violation, which turned out to be an ulti reference though. The bug was actually more powerful than that. The know the reference was basically a side effect of a larger problem. I believe the core of the issue came down to the fact that There's an object that resides in user space that gets read in from the kernel in an unnamed subroutine that gets called by various ayako handlers and that object contains a pointer that gets dereferenced and just it just gets trusted by the kernel for some reason. It's like there's like no checking on if that pointer is actually a user space pointer so it can get you arbitrary right and certain paths depending on the I octal that you call
me. It's arbitrary right? You don't really control the You being written it just whatever the return value is. So 0xffff and less character looks like Annie I guess I'm not I think yeah. Yeah. Yeah, so that's what gets written by you end up controlling word is they go into like reverse engineering that structure a little bit how like it'll use index offset at one point like they cover the structure, but the gist of it is as you said, ultimately you have this one call that basically just writes out to whatever. Address you provided as long as everything else seems legit. It'll write that. Negative like to or whatever that value is ol2 wherever in memory you want it which is a pretty decent primitive to have they covered the XY tragedy nothing too special over in token. They cover the essay kasl are bypass, but effectively I've just overwriting it with maximum
privileges. Yeah, it's crazy that it's like 20 21 and we're still talking about Colonel just trusting pointers. I write a not doing any checks on them like
the well, this is a bad driver. Well kind of dry but especially Windows.
Yeah, it's just like even I know it's Windows driver, but this is still at like inexcusable with like you don't just take pointers and trust them but you know, whatever.
It's like a lot of Windows drivers do just take pointers and trust
them. Yeah, it's wild it's wild and windows world. I don't know. But yeah, so the reason the crash got triggered was because the ayako that was taken by the father's 0 that buffer. So that's how that null pointer ended up getting getting created. Like zi said it is a constrained right? You can't just write whatever you want. But because of they basically abuse that return value right in order to right into the present and enabled privileges on the token structure to get LPE. So yeah cool exploits trap. Not a very cool bug though, like-- that's--just man trusting pointers in 2021 crazy. All right, we'll get into our next Windows bug which is also not the last one. We have another one after this to this one covers an out of bounds right in the desktop window manager dll and it involves the direct composition API in win32 K. So basically the way the pipeline works for getting to the desktop Window Manager as you invoke these system calls and when 32k to Eight channels process Channel batches and commit to the channel and then those get serialized and sent over to the desktop Window Manager. There's a few problems in one of the commands you can pass for setting that resource bruh buffer property and that command can take like expression types such as like a direct draw surface Vector, I believe and it'll either like add a new property to the resource. If one under that ID wasn't already defined or it'll update it. If it's already there. One of the issues is the fact that you can add. Parties to a resource and cause it to fail if the property ID and storage offsets don't match but it only fails after adding the property and this happens in both the dll and in and when 32k the other problem is the fact that the update flow path in the dll doesn't check if the property ID you provide it's less than the total number of properties. It's being tracked though. That check is done in the colonel. So by combining these two issues you can basically cause a desync You can inflate the colonel property count so that it's higher than what's in the in the dll that it gets in the window manager dll and then use that to abuse the update path in order to get the out of bounds right past the buffer used for properties. There are some other things you have to account for you have to satisfy some conditions on some out of bounds reads that occur first that do checking on like the storage offset and property type, but you can get around that by doing some heat grooming to get controlled data there which they do using the same command actually. Actually,
yeah, this is kinda hand wave over their grooming technique. Like they just kind of mention create the large resource to get even to specific stay like if you understand he's grooming. This is all pretty understandable basically spam agathe likes to get large into like a They kill off some of the randomness and they're creating gaps than hoping that the gaps get felt like it's a pretty standard technique. I just felt like it almost hand waved over some
effect. It would have been nice if it covered that a bit more,
but but you can get that sort of information L father write-ups
to Yeah, they focus more on the like vulnerability than the exploit dad side, which is
fair. Yeah, totally fair.
Yeah. So this is one ability was discovered in the wild. So obviously it's exploitable when analyzing it they believe it's the same apt group that bitter or biter or whatever which abuse a difference every day which we also covered back in episode 64 and when 32k so, you know, we have a recurring guest I guess in the form of an apt group. But yeah, it's a bit. The complex issue basically this though. This attack wouldn't even be possible. If they did some same checking on the add property flow so that it checks the property ID on sword drops as before actually committing the property Edition. So yeah, there's kind of two issues there I guess and it mainly just comes down to the dll and the win32 K having slightly different code. It seems like it's basically a copy pasted code and again this kind of points to why Ization is key to move towards. Although I'm not totally sure how you do it the way they have this set up because you are dealing with like a user space in a kernel component. So it's it would be tricky to try to centralize that but yeah, like where you have code that's copy-pasted if there's one change made in one code base. It's easy for it not to make it to the other one and that's basically half the battle with with getting this issue to occur. So yeah.
Yeah, I mean part of the thing is like In Theory without that ad issue. This Kernel check would have been sufficient. It's just because you're able to create that disconnect disconnect where you're adding property is without having them count properly because you can create that disconnect. That's where you're able to exploit the secondary one the update property, but that check is sufficient like assuming there's no other vulnerabilities the fact it does the check in the kernel like that works. That's all you need to do. If it fails that the colonel it fails in the user line to our never hits the user land. Yeah, we don't necessarily. Yeah, they don't necessarily need to centralize it and have the same code like in this case because of another vulnerability the fact they don't check it creates a problem, but
it doesn't notice nonetheless though. Like they should probably check it in both, but I get what you're saying, like without the other issue. It still wouldn't be a problem anyway, or not an exploitable problem. I should say so yeah, we'll get into our last exploit topic for Windows which is from Project zeros in the wild series. It's a keep overflow in Windows Defender. It's essentially a parsing bug when trying to unpack ASP or asp.net act packed executables, which we've covered before issues in a spring up from trying to parse these custom pack formats. I'm pretty sure from P0. Actually though. I don't remember the exact details, but I know we've covered at least one before so this issue was when parsing section entries, it would only check that the next sections and trade Is lower than the previous one. It didn't check if they're equal though. So if you have two entries with the same address, you get one entry that has a zero size, but then the next Century it sees inside has a nonzero size. It will try to copy data there when nothing actually gets allocated there. So you kind of get this copy into a hole basically which can be abused for for smashing the Heap they think this like this issue is likely found by either fuzzing or manual code review. I'd Edge probably word fuzzing if I had to pick a side this type of issue is prime for the type of issue that a father would detect quickly these kinds of parsing bugs.
Yeah, I'd agree. But at the same time of this sort of issue just not checking for basically not handling an elf else. That's that's one of those things that stands out doing code review too. So I could see it happening on both. I kind of agree. I'd put this in more likely on the fuzzing, but I think it's pretty reasonable to say could have been review
also. Yeah, which is fair. They also detail the exploit strategy of how you be able to get arbitrary read write by using the original overflow to trigger two more out of bounds rights first on and out find switch object then using that perform an or operation on a virtual memory manager context structure field and that field is used for tracking the length of the table for tracking virtual Pages, which can then lead to additional out of bounds of reads and writes which you can use to smash another. That has been struck to get arbitrary read right? It is a little bit like because it's these in the wild posts. These are usually quite concise. They just like cover the vulnerability and exploit Strat They Don't Really cover a ton of background info like we get on all the P0 posts. So the objects they mention there if you're not familiar with like Windows and those objects than that might not mean much to you. But basically what they're hitting here is the virtual memory manager. They're trying to chain together Primitives in ER to hit that structure in order to abuse fields in that object because when you're managing virtual memory you have a lot of sensitive pointers in there. So yeah, they use that to get the arbitrary rude, right, but they kind of hand wave like those objects and exactly what they do. So I just thought I'd point that out quickly. Yeah. I kind of
appreciate these really concise reports. I don't take too long to understand just what the issue was and how Well, maybe not how it ex-wife have might take a bit more digging. But I appreciate these posts. I will also mention if you see the disclosure patch date as 12th of January. This is another one of those cases where might have been written on that day might have been disclosed or even patch on that day, but we didn't get this report until more
recently. Can't trust the dates at all anymore. But yeah, they talk about some of the improvements that can also be made to harden this area of code. Noting that the NP engine from Defender could be built with sand to catch these issues faster. Also, noting that open sourcing the some packing code could be useful for killing these issues faster. So like their improvements is mostly suggesting stuff on the on the phone research angle not so much on like the mitigation angle. they also say the defender emulation should be running inside of the sandbox, which is weird because apparently Microsoft put out an article in 2018 saying Defender can run in the sandbox, but it just doesn't by default I guess so while they had the VR suggestions, they also suggested to try to sandbox this parsing routines these parsing routines away because when you have all these like custom packing formats and you're trying to deal with them that just seems like a never-ending attack surface, so It is a lot of sense to try to throw that in the sandbox if you can
yeah, it's a process that's dealing with untrusted input. The untrusted input happens to be the binaries, but it's still
untrusted. Exactly. So whenever you're dealing with that much untrusted input. It's easier to just throw it in the same box if you can and like I said like it's weird that they don't especially with something like what with what Defender threat model is the fact that it can run in the sandbox and it doesn't is a little bit weird to me that's in there might be months. It could be performance or some other issue where it's like For whatever reason the way they designed it It's tricky to do certain things. So like even though technically runs in a sandbox, maybe it can't communicate properly outside of it. I don't know. I don't I don't have the necessary like Windows internals knowledge to really comment too much on that but I thought that was kind of an interesting sentence to to highlight. So we'll get into our last exploit topic which touches on exporting a chrome and day on a Tesla Model 3. We don't cover exploits of older bugs too much on the podcast especially ones that have had previous exploits written for them with like a year ago or whatever. So I won't really dive too much into the exploit details, but it's basically about porting an existing exploit to a unique Target being the Tesla. I will touch on the bug quickly. It's it's a type confusion when doing side effect modelling in turbofan, which is optimization stuff and side of V8, which to be fair. Like I'm not really I'm not well-versed in the optimization routines of browsers that is like a really complex subsystem the way I understood the volume from a high level perspective is it'll it'll try to infer like a map of objects, which is essentially like the type but that type can either be reliable or unreliable. And what makes it unreliable as if a call can have side effects and like taint the object. Well, if a call has side effects, but it mistakenly gets marked as a reliable by the optimizer. That's where you have some of this trouble and the basis for this bug. There's a Miss case where the function that gets called, which is KJ as create gets reached. It could Mark results as reliable when they should be marked so unreliable. So by inlining a function that pops values out of an array using Reflect on construct which uses that KJ's create function pathing. You can create a type confusion on the array switching it from an array of integers to an array of doubles which while it may not sound like much remember the browser's are like absolutely like absolute monsters when it comes to internal State tracking and those types of arrays are very different with how they're handled under the hood in the engine. So by being able to cause that type confusion that is absolutely enough to get code execution. So yeah, basically what they did was they exploited the they use that to corrupt the length of the float array to get out of bounds right which they work to get the popular dress up and fake object Primitives, which are basically the end game and browser exploits. I'm not going to cover that here. But if that sounds interesting to you, you should check out Salos Frack paper on attacking JS engines. It does a really good job of explaining those Primitives and why they're so powerful. But yeah, the researcher discovered their Tesla was on an outdated V8 that was vulnerable to this bug when they tried running the weaponized exploit though. It didn't work but they notice the pock of the original bugs still triggered a crash and it was kind of funny. They discovered that the browser was actually two out of date because it didn't contain a feature that the exploit that was written for this issue abuse, which is called pointer compression pointer compression is basically where they take the upper 32 bits of a jam. As object pointer, they store that in a register since that isn't going to change throughout the run time and then they combine it with the lower 32 bits which are stored on the Heap to form the final address. And that's presumably to save space on the Heap. I guess. I don't know all the reasonings behind it. But that that's the most immediately obvious reason to do that. The reason this cause issues that was because they were using an array of doubles this mashup pointer now because that pointer compression wasn't there because the browser was too old. The double was no longer the same size of pointers to stop compress anymore. So they basically they could use a lot of the exploit but they had to change how the address of an fake object Primitives were obtained because the way Exodus originally obtained it was by allocating an object next to the corrupted float array in memory using keep spraying and leaking the value through an inline property and similar to get readwrite. They pushed an array on the array to corrupt an adjacent stack of backing store pointers for like a un 32 array or Never so all the author had to change really was with the leak primitive. They had to make it so that it leaked addresses by popping from the corrupted float array instead of trying to read out of bounds on it on an adjacent object and they used a similar strategy for the read/write. They pushed on it to smash the backing store. But you went 32 array. Finally. They use webos web ASM Shell Code for code execution doesn't really touch on that part too much but Yeah, I mean the most interesting point from here was the fact that they noted the Tesla was running x86 64 for the instruction set, which is really interesting. I'd like the author said I was kind of expecting like arm or Arc 64 for the chip that was running where the browser was coming off of but yeah, it's running an x86 chip which makes robbing everything and she'll coding like a lot easier because you can test it without having to emulate a different is Say but
yeah, yes, definitely an interesting aspect to it. Like I wasn't really expecting Tesla to be running x86. Yeah, super
strange. Arm like an arm chip makes a lot more sense, right but like a lower power chip. But yeah, that's just what they decided to go with I guess I mean
Tesla you want high
power unlimited power.
Like I can see the argument on the low-power side and going arm for that reason at the same time perhaps. I mean development time could be a little bit quicker going off x86, perhaps more libraries or something you could use Perhaps some sensor that they work with like I've not sure what hanza Memoria PSI T and chat says make it play AAA
games. I'm reminded of that Joe Rogan interview that musk did where he was talking about all the secret Easter eggs. They put in the Tesla with like games and all that stuff. Maybe that's why they used an x86 chip may be really stupid. But I mean, that would be a pretty funny reason. But yeah, like it's not a new bug or a totally new exploit but it is fun to see how an exploit like a browser exploit exported to different targets and some of the roadblocks that can get hit while doing that. That I have kind of a special place in my heart for that kind of stuff from console stuff, too. So yeah interesting posts to read but it is kind of an older exploit and there are other resources like The Exodus right up if you want more information on the core of the bug and how it was exploit originally. So yeah that post mostly focuses on the porting. All right, so that pretty much concludes all of our exploit topics will move into our show notes section of the show. I don't have any but zi has to so I'll let zi cover his shoutouts and then we'll wrap it up.
Oh, no, I think the second one is your was your link
that so you're right. Sorry. I forgetful.
That's you are correct. Yeah, I've got this one's just a really brief blog post qemu and you from actress security. I think it's after the security. There are security research pen testing that type of company. Oh talk about doing basically whole system tracing using qemu. I thought it was just interesting gave him a bit of an insight into one is a bit of how qemu works and then obviously how you can use that start writing your own tracing implementations up. I just found it to be an interesting read not really an excellent, but still related to doing the vulnerability research. So want to give that a quick shout
out. And the shadow that I was going to give away to see that I like forgot that was actually mine is a Blog that somebody posted in the reverse engineering server a couple days ago. This contains a bunch of posts on various topics like some CTF write-ups, but also like some fuzzing based stuff binary analysis doing some like Trace analysis and some stuff on the elf and portable executable formats. It's nothing to like advanced. But and it is a bit old like a lot of these posts are from 2020 like February and March and whatnot. But it contains like the way these posts are written are very accessible to people who are not familiar with the topic. So I wanted to show to that because I think this is a very good beginner resource and I was I was like really glad to see this blog especially like when I was looking into the fuzzing articles fuzzing is a little bit hard to wrap your head around if you're not already familiar with the space because There's there's a lot of like invented terminology and stuff like that, which I think these posts do a good job of covering. So if you're looking to get started and you want to look at one of these topics like binary analysis or pausing or whatever these posts are definitely worth checking out for getting like a getting some background info on that topic without having to read something that assumes you have a lot of knowledge or something and that's not to say that the post Our simple it's just they're really well written for anybody right there. They're very accessible. So I wanted to give that a quick shout-out.
Yeah. I had looked at it after you pass the link over after agree. Like looks like there's some good information on there. I was having read everything but no, I look solid.