Season 1  |  Episode 4

Stu McClure, Chetan Conikee, Arun Balakrishnan, and Ben Denkers return for Episode 4 of Hacking Exposed, Qwiet Edition!

In this episode, the Qwiet Qworum touches on:

  • The ongoing (maybe never-ending?) impact of MOVEit
  • Cruise’s robotaxis neither cruised nor taxied at a critical moment
  • Should every CVE be a BFD?
  • A clever 2FA hack on the gram and the book
  • The fall of LAPSUS$
  • Exploiting WinRAR
  • AWS backdoor techniques
  • Flaws in a company portal


Resources for this episode:

Techcrunch on MOVEit

SF chronicle on Cruise robotaxis

Why CVE scores may not matter so much

Bassem M Bazzoun’s post on bypassing 2FA for FB.

The Hacker News on LAPSUS$ on WinRAR RCE

“Methods to backdoor an AWS account”

The Hacker News again, this time on security issues with the Honda e-commerce platform

Show Notes:

MOVEit Vulnerability Continues to Expand Victims

  • [00:00:35] Stu wonders if it will ever be possible to move on from MOVEit
  • [00:01:00] Chetan invokes Darwin
  • [00:02:21] So what are you supposed to do? Know your attack surface, that’s what
  • [00:03:23] Data exfiltration includes millions of SSNs

Cruise Self-Driving Taxi Outage Shows Lack of Resiliency

  • [00:05:40] Arun details how Cruise taxis neither cruised nor taxied at a critical moment
  • [00:06:58] Ben says autonomous vehicles should have backup systems for connectivity
  • [00:08:23] A proprietary cell network isn’t the answer . . .

Over-Reliance on CVE Scores Can Be Risky

  • [00:10:00] Stu cautions against blindly following CVE scores
  • [00:10:48] Arun outlines how a cURL bug was improperly scored 9.8
  • [00:12:23] CVE scores can massively influence resource allocations in an org
  • [00:12:45] A scathing quote

Clever 2FA Bypass Affects Instagram and Facebook

  • [00:15:00] Chaining Insta to FB
  • [00:17:00] Brute forcing 2FA
  • [00:18:59] Don’t forget about rate limiting
  • [00:19:52] Security never rests

LAPSUS$ Members Arrested

  • [00:21:27] How to social engineer a SIM-swap attack, purely hypothetically
  • [00:24:10] When is a fish not a fish?
  • [00:25:42] The age-old problem of ID verification

WinRAR exploit 

  • [00:28:15] Required user to open file and accept script prompt
  • [00:29:16] Chetan notes it was a chaining of two separate conditions

Ephemeral keys in the physical cloud

  • [00:31:45] Chetan explains how ephemeral CLI keys bypass controls and create stealthy access
  • [00:33:32] Ben says these are important things to look for in cloud IR/forensics
  • [00:34:20] Did you know some systems allow users to create 2 keys?

Honda Dealer Portal Bugs

  • [00:35:38] Stu explains the many ways that a Honda portal could be compromised
  • [00:37:22] Did we mention that security never rests? Cuz it never rests.
  • [00:38:06] Don’t store IDs as sequential numbers(!)
  • [00:39:46] Speed kills.


Episode Transcript

[00:00:00] Stu McClure: Well hello everybody. We are back with Hacking Exposed Podcast, Qwiet Edition, and we’re joined here with all my usual cohorts, including, Arun, I think joined us last time, at Black Hat. That was a lot of fun. Hopefully you survived that my friend. Just looking forward to talk about the topics of the week.

[00:00:35] Stu McClure: Now, we had been talking quite a bit about MOVEit and the sequel injection nature of that vulnerability. Obviously that seems to be just expanding the victims just keep going up and up and up. I mean, I don’t know if we could even like not talk about it at this point because there just seems to be so many victims, so, What are you guys seeing with [00:01:00] this?

[00:01:00] Stu McClure: Are you, are you hearing much of anything? What’s going on? 

[00:01:04] Chetan Conikee: TechCrunch recently summarized, the log of evolution fairly well, and when I read it, at best I can, I would say synonymize it to evolution, Darwinian Evolution, which is, yeah, natural selection, replication and all that playing game.

[00:01:24] Chetan Conikee: But, if you bring it all together, it’s taking different forms. It started as, an attack on authentication, which is SAML and SSO. Then it moved to SQL injection, and from there on it moved and take, it’s taken its form as a remote code injection and digitalization. So we have a cat and mouse game at this point where some CVE shows up, progress softwares out there putting a patch, they’re rushing the patch and they’re creating another situation for themselves.

[00:01:56] Chetan Conikee: So, and as a consequence, those using [00:02:00] progress and move it are in impact zone, which means how do you play catch up and merely patching, is it really gonna solve it or you gotta up your game. Essentially check for  typical symptoms of communication. Uh, so I don’t know if this is gonna end soon.

[00:02:21] Stu McClure: Yeah. With these scenarios, is there anything more you could do other than simply catch ’em? I mean, like, with, with progress software being the owner, I mean, they need to basically build a really good AppSec program, sort of catch these things before they launch, but, the victims themselves can’t do much outside of just detect and respond in these scenarios.

[00:02:41] Stu McClure: Right? 

[00:02:42] Chetan Conikee: Perhaps a little more, which is understand your own attack surface to start with. You know, if you have the mindset of defense, at best, what you could do is get into this aggressive protection mode, but have maybe a percentage of your team pretend to be actors, [00:03:00] threat actors. Go out to showdown, see what are your points of exposure.

[00:03:05] Chetan Conikee: Figure out whether someone can infiltrate using those points of exposure. So it’s a bit of a mindset shift, but again, it’s, it boils down to prioritization and figuring out, what is your expanded scope of thinking. 

[00:03:19] Stu McClure: Yeah, I know there’s just so, there’s so many different vulnerabilities as part of this attack.

[00:03:23] Stu McClure: The financially motivated certainly have a lot to work on here and a lot to exploit. I mean, what I’ve seen so far in terms of the data exfiltration, because it is a file transfer system effectively, so everybody puts files up there. You know, nonchalantly thinking everything’s secure is, I mean, millions, tens of millions of social security numbers getting out there.

[00:03:51] Stu McClure: Now, from a US perspective, that’s like a nightmare. I mean, all you need is one social security number and you could basically get everything else. To [00:04:00] transfer all of the money in your bank accounts with very little effort whatsoever. So if there’s ever a targeted attacker against you, man, it’s pretty simple.

[00:04:09] Stu McClure: Get it out there. So, I don’t know, this seems to be a fraud that’s just gonna keep a gift that’s gonna keep on giving. Like now everybody’s got all the social security numbers, now they’re gonna start, you know, exploiting with fraud, et cetera.

[00:04:23] Ben Denkers: I would say the quantification of impact is just mind boggling if you really think about it and, and all the, all the victims, you know.

[00:04:30] Ben Denkers: And I think, as Chetan, as you mentioned, it’s a snowball effect. And one of the things, I would be thinking is, is at what point is it worth it? Right? Uh, something continues to you know, a new vulnerability or a new, new potential compromise. You know, I think organizations have to look at it from that perspective and that, that risk lens to say, okay, well, The functionality is there, but is it worth the risk?

[00:04:55] Stu McClure: Yeah, I mean, look, let’s be fair. This could be box, it could be [00:05:00] Dropbox, it could be any, you know, we’re not picking on, on uh, move up at all. Uh, obviously I think it’s more of a, Hey, let’s get to the root cause problem team, everybody, and let’s go solve these problems in AppSec, because that’s really where a lot of this stuff happens.

[00:05:16] Stu McClure: Alright, let’s. Let’s move on, but I’m sure it is not gonna be our last time talking about move it. Well we all like to talk about vulnerabilities and hacks, but especially in the physical world. And that’s exactly what happened recently. Not so much a hack per se but certainly a denial of service with the cruise robo taxis in San Francisco.

[00:05:40] Stu McClure: Arun, you wanna talk about it? 

[00:05:42] Arun Balakrishnan: Sure thing. So this was pretty interesting. It happened, early last week, there’s a music festival going on in San Francisco outside, and what effectively happened is that led to a clogging up of the uh, cell network [00:06:00] and 10 cruise cars pretty much stopped in the middle of the road, put on hazard lights, and wouldn’t move for like 15, 20 minutes and there’s nothing people could do because they were really driverless. There was nobody in the car who could take over. And in some situations it was narrow streets where the whole street gets blocked. And the concern people have is, I mean, one, it’s affecting normal life where it also is blocking the street where emergency vehicles couldn’t get through if they needed to. So the, the impact is pretty high.

[00:06:35] Ben Denkers: I mean, I would say from a technical perspective, right? Like if I, if I put my, if I put my risk hat on for a moment, and you know, to me, if, if I have a, a device, in this case, an autonomous vehicle that required wireless connectivity you know, you would think that there should be a, a mandatory requirement to have an alternative navigation control or, or mechanism in place, right?

[00:06:58] Ben Denkers: You know, for this very scenario, it [00:07:00] seems to me that would be like, you know, the first thing I would think about. But it’s interesting you know how in this case there, there didn’t seem to be a backup plan of sorts? 

[00:07:09] Stu McClure: Well, it’s disaster recovery 101 on a software platform build out for sure. Um, and you’ll, you’ll see this a lot in sort of the the cars that have been out there for a long, long time is you, you have to build this bypass of, resiliency effectively, of all the, moving parts of the car, especially electronically now. So if the car is dependent on the, the wireless network or the cellular network and the cellular network goes down, I mean, I appreciate them not like speeding up, I guess when the network goes down, but, you know, maybe find an all, you know, a spot to like, pull over on the side or, you know, just simply go super slow or something.

[00:07:51] Stu McClure: But don’t stop in the middle of the, in the middle of the bloody street, because yeah, it’s gonna block traffic, including emergency traffic, which is just probably not [00:08:00] the best idea. So I’m sure they’ll figure that out. But I think it is, it’s important to call out this denial of service potential simply from, you know, self infliction.

[00:08:10] Arun Balakrishnan: The response from the organization was they’re thinking of doing a cell network by themselves. So I think it still is just moving the point of failure to something else versus having a different alternator.

[00:08:23] Stu McClure: It’s the wrong mindset. Yeah, exactly. 

[00:08:26] Chetan Conikee: What’s ringing in my head that’s at this point is back in the day you know, crash test dummies as tests was created for measuring, how accountable can you be if you are in a situation, an accident. So, Stu and Ben, are you trying to tell me that in the future, since we are dealing with vehicles are have standards. If anything cannot be solved by security, it’s punted to compliance, punted to insurance and liability. Are we gonna see more of that? 

[00:08:59] Ben Denkers: No, [00:09:00] absolutely. And that was kinda the point I was gonna raise Chetan, was you have this concept of our physical reliance, you know, on, on, you know, on physical things and our inter the interconnectivity from a technical perspective, right?

[00:09:11] Ben Denkers: And so, especially when we’re talking about autonomous vehicles, which have real world impact, if something were to go negative, You know, you have to put, pay very close attention to the potential risks, both physically and from a technology perspective. And you need to have something to govern that and to, to mandate and or, you know, validate that safeguards are in place for, for really all potential impacts.

[00:09:34] Ben Denkers: I think. 

[00:09:35] Stu McClure: Yeah, I’m sure this’ll be a point of great discussion in the transportation boards of a lot of companies or a lot of departments rather. All right, so moving on from the physical, which I always love to hack or at least expose that, I wanna talk about and sort of expose perhaps the dark underworld of CVEs.[00:10:00] 

[00:10:00] Stu McClure: And I know I’m not gonna be a very popular person talking about this, but I do wanna pull the curtain back and talk a little bit about this. I, we always talk about the CVEs are the gold standard. Okay? You, you look at a CVE. It says it’s critical and you just trust it. Oh yeah, that’s critical. We gotta fix it or we’ve gotta mitigate that risk, or whatever it might be.

[00:10:25] Stu McClure: And I think we’ve got a great example, black and white, and color, technicolor as to why that just doesn’t work. And so we recently discovered a curl vulnerability. Been out there since 2020. And, and a gentleman brings it all up in, in full frontal form. So, Arun, do you wanna talk about this?

[00:10:48] Arun Balakrishnan: Sure. Yeah. So this was a C V E in the Kern Library number 202019909. Um, so 2020 is the year so that means [00:11:00] this has been an issue since 2020, but the CVE was announced just recently, and it was given a score of 9.8. So for people who are not familiar on CVE scores, it’s a level from zero to 10. 9.8 is stop-everything-you’re-doing-fix-it-level-critical and the developers on the current team, especially the security team or the current library, they are very upfront in any issue that they’ve had, right? They write extensive blogs, they’re very clear on issues that have happened, how they remediated. So they’re upfront. They don’t want to hide things because it’s one of the most popular libraries in the world.

[00:11:40] Arun Balakrishnan: But in this specific issue, it was not a vulnerability. This was a bug. Yes. Which was reached back. There was a patch released that fixed it, but somehow this got through the CVE process, and they published it and called this library vulnerable. [00:12:00]

[00:12:00] Ben Denkers: The downstream effects of this right, are, are actually quite massive at scale if you think about it, right?

[00:12:05] Ben Denkers: Because, you know, still, you mentioned, you know, and, and Arun you both mentioned like 9.8 means “stop what you’re doing and going and fixing.” And think about the amount of hours you know, if, if I’m a CISO and, sometimes my policies dictate that I have to fix anything that’s higher than a nine immediately, right?

[00:12:23] Ben Denkers: And I don’t have a choice in, in a, in a lot of cases. And so, you know, stopping to fix something that really isn’t a problem, the amount of hours wasted on those efforts is, is huge. But you know, it also speaks to the larger problem at hand of, you know, who’s validating or how are we validating what a vulnerability is and what the actual impact is prior to saying, Hey, this is a 9.8.

[00:12:45] Stu McClure: Well, you just can’t rely on CVEs alone. I think that’s the message, and I, I don’t know how to make it more clear than this. Daniel Stenberg was the guy, Swedish researcher, I know he does a lot of work for curl, et cetera. I think he said it perfectly, which is,. [00:13:00] “Clearly nobody at NBD engaged their brains nor looked at the vulnerable code or the paths that fix the bug.”

[00:13:06] Stu McClure: So I’m not saying that we expect perfection, that that’s impossible, right? We’re not gonna expect perfection from any single person, nor department or initiative, et cetera. But they should be able to take the input and information and process it and adjust. I think that’s the problem, but you can’t rely on that.

[00:13:26] Stu McClure: So criticality inside CVEs is one element I think that you need to think about when you’re talking about what to go fix first, second, third, and prioritization. Some of the other things that I really recommend strongly is things like, you know, is it reachable? You know, can you get to it?

[00:13:47] Stu McClure: Um, if an attacker can’t get to it, it’s hidden away on some physical server with sneakernet availability only, then do you really care about it? Um, you know, is it [00:14:00] exploitable in other words, like there’s a lot of code out there that can exploit this particular problem. Or does somebody have to come up with a brand new, never seen before in the world, um you know, shell to, to make this thing work.

[00:14:12] Stu McClure: Well, those things all need to be a part of the decision making and prioritization. So, I don’t know, I’m just a big. I’m a big fan of just looking at holistically versus just blindly following CVEs. Alright, that’s a good one. I really like that one. It builds a lot of context around the problems that everybody is trying to solve and, and knowing when, when to start with what.

[00:14:35] Stu McClure: Alright, next let’s cover is meta, Facebook, et cetera, et cetera. So, If they have a great bug bounty program, a lot of vendors do and they’re very proactive, very responsive, love all the work. A lot of these tier one software vendors, et cetera, provide in terms of bug bounties. You know, we have seen bug bounty programs go wild.[00:15:00]

[00:15:00] Stu McClure: We won’t go into that on this con on this call, but what we have seen is a successful, a very successful. A recent discovery on a two-factor bi of meta of Facebook, and it’s actually a pretty clever one. Um, so the, the, the guy that that discovered it I believe from Lebanon I could, I could be got that wrong.

[00:15:26] Stu McClure: Bassem Bazo. And he discovered effectively, I think two things, two ways to characterize this, 2FA bypass. So one is this. Transitive trust nature between Instagram and Facebook. Um, and the, that the ability to sort of brute force authentication codes effectively from an endpoint to Instagram itself.

[00:15:52] Stu McClure: So how the attack works, okay is really simple. They got a great pullout on it. You can walk through it at your leisure. [00:16:00] Um, but basically it works like this. So you have two, two what? Two sort of major motions. The first is, okay, you’ve gotta, you’re gonna sign up to Instagram using a victim’s phone number.

[00:16:12] Stu McClure: So I’m gonna take Ben’s phone number and I’m gonna sign up to Instagram with Ben’s number. Well, they have obviously have to verify that I actually hold that number. What they’re gonna do is they’re gonna, they’re gonna prompt me. They’re gonna check, you know, whether or not I have the number.

[00:16:32] Stu McClure: I know what he figured out he could do is he could brute force the attempt to verify that number in a way from a trusted endpoint. Okay? That allowed him to get access and create that Instagram account, not create it, I’m sorry, but it defaults to, ah, you must own the account already. So we just assume you own the account, and so now your device is authorized and approved.

[00:16:59] Stu McClure: [00:17:00] So now you become sort of an authorized user of Instagram or that phone number on your device. Now with that moves to the second phase, which is now you can take that and you can trick Facebook meta to trusting Instagram account that you just created with the victim’s phone number, and now you can do anything you want on that account and and bypass all the two f a.

[00:17:26] Stu McClure: That’s additional to the process. So, oh, Facebook for example, so this is sort of a nice one. You know, you sort of trust it. You got the transit of trust, nature of, of apps trusting each other. And then you have the ability to sort of brute force the authentication of that original number through Instagram.

[00:17:43] Stu McClure: Now, this has all been fixed. I think he won like 30 grand or something like that. I thought it was a great one. And something, thinking about, I think the tell here would be, you know, if. If you’re starting [00:18:00] to see any, and this might be completely invisible by the way, to the, to the victim.

[00:18:03] Stu McClure: I’m not seeing anything that might get prompted up. But if you are starting to see some, some long in activity perhaps that you don’t recognize, that might be a towel to be able to identify it. But otherwise it seems pretty darn stealthy. Um, so I dunno. I just love this one.

[00:18:22] Chetan Conikee: This one’s pretty awesome, and there is a little, I’ll add on to what you just described too, because there’s a little business logic issue in your two.

[00:18:31] Chetan Conikee: Typically in Instagram, you have “sign in” where your pre-existing user, and then you have “create user” where your new user at. The little nuance there was if someone uses a preexisting number and a password, a newly minted password through the “create user” sign in. Then if they exist, it automatically logs them without 2FA, which, which goes to show that all sign-in.

[00:18:59] Chetan Conikee: [00:19:00] They had the 2FA check logic in Create User. They didn’t have the 2FA check the logic, right? So engineers were split brain. They didn’t actually think to bring controls in both spaces.

[00:19:10] Stu McClure: Yeah. And that was probably how originally asked, you know, not like, thought about. Right, exactly.

[00:19:15] Chetan Conikee: Exactly. And the other interesting nuance is rate limiting.

[00:19:18] Chetan Conikee: Now on site. If in sign in I attempt a brute force, many times that rate limit, I shut down the exchange of information. But in create user, there’s no rate limiting. So he could just continue the process.

[00:19:32] Stu McClure: If you’re constantly trying to create a user, it doesn’t restrict. Number of requests per second, let’s say, of trying to create that use exactly.

[00:19:41] Stu McClure: I think that that’s a good call out, Chetan.

[00:19:43] Ben Denkers: Yeah, and I mean, from a business logic perspective, those can be hard to identify right? Outside of the exact scenario of doing things like pen testing and, and the other types of you know, assessments that, that might highlight that.

[00:19:55] Ben Denkers: Right. And, and it, I think it speaks to,

[00:19:57] Ben Denkers: you know, you, you’re never really done in terms of security, [00:20:00] right?

[00:20:00] Ben Denkers: And you have to continuously look at it from all angles to find these kind of nuance you know, typed attacks, especially as we get more. Reliant on two factor authentication and APIs and AppSec in general. So,

[00:20:12] Chetan Conikee: and, and Ben, I’ll close this out with a safe, simple question, right. Uh, nagging question, which is again, I’m an engineer of Fortune 400. Would you as a manager, incentivize me to go and put these checks and balances or just build authentication that’s fast at serving my customer?

[00:20:29] Ben Denkers: Yes, absolutely. I’ll write you a big check.

[00:20:32] Stu McClure: It’s always the, the trade-off balance between yeah. Security and the business needs for sure.

[00:20:37] Ben Denkers: A hundred percent.

[00:20:38] Stu McClure: Alright, let’s move, let’s move on. So next, which I just saw that a hacking group called Lapsus$ seems to be financially driven. Uh, two of the hackers got convicted in London Court for some some hacks, and it was, it seems to be more of this stem jacking technique. [00:21:00] And we’ve, we have seen this before, but we like to see when the bad guys go down. These guys seem to get into a whole bunch of stuff. Uh, initially they get arrested and then they get released. Okay, under investigation, well, then they go and continue to hack. So then they, then they brought down Uber, rockstar Games, et cetera, and then they got arrested again.

[00:21:27] Stu McClure: Finally and then started to expand a lot of the arrests elsewhere. These, this particular series of attacks does seem to be financially motivated. Um, but it’s really quite simple. Let me walk through the basic premise here, right? So how this works is so if I wanted to hack into Arun, I would just like research him online extensively, you know, what is, what’s his full names, what is his email addresses that he uses?

[00:21:58] Stu McClure: What are some [00:22:00] usernames that I can try and collect on? Um, I would probably scrub and stalk him on social, although you don’t seem like a big social guy around, but maybe I’m wrong. I, maybe there’s tons and I can go find stuff. I’m not, by the way. I’m like, I hate it. Uh, and then, Of course I could fish you as best I could, right?

[00:22:18] Stu McClure: Uh, send you all kinds of crazy cool, really legitimate stuff to try and get all kinds of information. And you don’t need much, right? You need enough to basically call the cell phone provider, Verizon, at and t whatever you’re on, and try to convince them over the phone or you know, whatever, through a support ticket that you are who you say you are.

[00:22:39] Stu McClure: And you need your sim card number, the sim card to be changed. To this sim card that you have. Once that’s approved by whatever poor sap is on the other end of the phone, then now you have full access to that, to that. Anything, any communication that’s going to [00:23:00] your phone or around, it’s gonna come to my phone and now I’m gonna see all kinds of stuff.

[00:23:04] Stu McClure: Now I’m just thinking through this and I was thinking you might be able to do far more than just get, let’s say, SMS sort of 2FA code. You might be able to get far more depending on how far you could take it. But that’s the basic gist of it. So with all of that, obviously, well, what can you do when you have access to, you know, SMS codes, 2FA codes?

[00:23:29] Stu McClure: Well, you can log in and darn near anything you want, especially if you’ve got passwords. I can go into who, who’s banking account and start transferring money. I can get, you know, some sell orders on some stocks. I could do pretty much whatever I want. So I really liked this one from the aspect of, okay, there’s a bad guy, there’s a good guy that’s doing the best they can, cell phone providers to ensure legitimacy of the callers.

[00:23:54] Stu McClure: Um, although we probably need to up the game a little bit on that front. And then you have the [00:24:00] four victims that, you know, could we detect this kind of attack? Maybe. I think if you are really, really just doggedly aware, Everything that happens, like, like let’s say you get a simple little email that says, um you called in yesterday into the, your, into Verizon.

[00:24:19] Stu McClure: We hope we wanna support, request you know, customer feedback form for you to fill out. And you’re like, wait, I didn’t, I didn’t, so I didn’t call in Verizon yesterday. Like, why would they be asking me to supply that? Well just ignore it. Like, a lot of people would be like, ah, it’s just junk. Or maybe it’s a fish itself.

[00:24:39] Stu McClure: You wouldn’t know that. No. It’s legit. Somebody called in trying to impersonate you and you’ve, you’ve gotta stay aware of it. So there are those kinds of tells I think that would happen. But I’d like this ’cause we’ve got all of those aspects in play here. Um, I don’t know if you guys took a look at this or not.

[00:24:54] Ben Denkers: Yeah, absolutely.

[00:24:55] Ben Denkers: I think from, you know, I think it’s 2FA [00:25:00] is, is very much touted as, you know, a security control that should be used anywhere and everywhere, right? And for the most part it’s valuable. Uh, it’s certainly a valuable safeguard. The question is, it’s not the silver bullet, right?

[00:25:14] Ben Denkers: There’s still ways, just like sim swapping to get around you know, two factor authentication to cause a lot of damage. And I think, you know, as organizations are, are implementing technical, safeguards or controls, they need to be aware of these types of attacks. Uh, and, and again, it kind of goes back to that physical dependency versus the technical controls as well, because as our lives are intertwined, you know, it’s becoming a lot muddier, right?

[00:25:42] Stu McClure: Uh, in terms of, you know, what physically can we have to compromise an asset versus what do we have to have from a technical perspective? Yeah, it’s the age old problem list. How do you know the person with the device or with the voice is the actual person, and it becomes really, really [00:26:00] painful. Um, I do think AI and machine learning have a big role to play here. You know, my last company, Cylance, we actually did a lot of work around confirming identity and then reasserting structure around that identity throughout the lifecycle usage of a device. And that worked out pretty well. I just haven’t seen it sort of get out there much, but there’s a great, if you wanna take a look.

[00:26:23] Stu McClure: More detail on this, which is a great report. I want to get some shout outs to these guys. The Cyber Safety Review Board did a, just a very thorough inquiry into the attack, the impact, the TTPs and everything else. I thought it was just a great one and to call it out should definitely take a look at that.

[00:26:42] Stu McClure: Alright, let’s, let’s move on. We got a couple others I think are are pretty cool. Alright, winrar. How many of y’all like, you know, think you’re cool ’cause you download Winrar or 7Zip or any of these other sort of like extraction, you know, [00:27:00] decompression, you know encryption tools, right? That will encrypt files, things like this and you think you’re cool.

[00:27:05] Stu McClure: A lot of US security researchers and practitioners, we use this stuff all the time. Well, there is a new vulnerability in this, it actually exploits another vulnerability inside of Chrome to, to perform it. It’s pretty cool. And they’ve been targeting a lot of financials as well. I probably start to hear this common theme and motivation, but it’s, it’s very simple.

[00:27:29] Stu McClure: It just improper validation of, of the user supplied input. So basically how it all works, and I can, I could break it down pretty quick. You have your basic file, like let’s say I wanted to attack Chetan and I’m gonna, I’m gonna create a winrar, I’m gonna create a Winrar, that has certain files in it, you know, documents, images, whatever it is.

[00:27:54] Stu McClure: And I replace the image with a script, a script of some sort that I [00:28:00] can run on the target, on Chetan’s system. So Chetan finds this winrar, or I send it to him, he trusts me, or whatever it is, and he opens it up and he double clicks. On one of the, before he extracts this, he double clicks on one of the images.

[00:28:15] Ben Denkers: Uh, or I think you could do it after you extract as well, but you open it that then will allow a script to run and you the context of your user. So if your admin, that it’s gonna run there and it could do pretty much anything that you want. It is in part a combination with a Google Chrome zero day that was going on for quite some time.

[00:28:37] Ben Denkers: So I believe both of these have to work like winrar, like basically obfuscating the real source of the file, if you will, and then this exploited inside Google Chrome, but I’m sure it’s expanded far beyond that. So, being able to run some, anything you want in the user context is pretty cool. It does require, obviously for the user to be prompted to [00:29:00] say, Hey, wait a second.

[00:29:02] Stu McClure: Uh, something’s gonna run. Are you cool with that? But of course most users are like, yeah, sure, I’m cool with that. I’m gonna hit that button. So you have to presume people are gonna just hit that button. Um, you know, did you, have you guys looked at this one at all? I just thought it was pretty cool.

[00:29:16] Chetan Conikee: It’s pretty interesting. It’s really like you said, it’s chaining of two conditions. The other aspect is poisoning you know, representation of you know, your malted as a jpeg file. Uh, and then again, you know, rote memory says just click. I receive something from someone I trust, or I intentionally download something from someplace.

[00:29:39] Chetan Conikee: It happens more often than you think.

[00:29:42] Stu McClure: Yeah. And in this case, I mean, how many times have you been on a Zoom and somebody’s doing a share of their screen and you see in the upper right corner, the right red, like, you know, update Google Chrome now, or die instantly, and they just ignore it, you know, like whatever.

[00:29:57] Stu McClure: Okay. I mean, the actual [00:30:00] Chrome vulnerabilities, the 2021 CVE, but wanted people to donah take those dang things. So please update as much as possible and then just be really careful where you’re getting your, your zip files from or your RAR win win RAR files. In this particular case, although we’re not picking on WIN rar, that could be darn near anything.

[00:30:19] Stu McClure: 7zip, you know, standard winzip, you name it. So, I thought that was a pretty interesting one. Alright, now the next one I called out and I thought, Chetan, you would love this one is, We’re all a big cloud world now, right? So most of DevOps is all, it’s all in the cloud. It’s the way you get access to resources and automation and you know, multi-tenancy and all this kinda stuff is basically through your cloud provider and cloud providers like AWS and Google and Azure and such, really rely on authentication, traditional and, you know, two factor stuff, authentication in here.

[00:30:59] Stu McClure: So, as [00:31:00] an attacker, when I get, when I’m targeting a cloud system or any sort of person or a company, they typically have a cloud account. They typically have resources up there that I’m interested in, so I’m gonna try to log in and get access into a [] for example, to either get an account and then establish some backdoor capabilities once I me in as a user or admin, et cetera, so that I can stay stealthy.

[00:31:26] Stu McClure: So I’m not gonna be seen. And this guy Mystic zero X one, which I guess is gray hat. Good, good guy. Um, came up with a pretty cool list. I don’t know, you know, Chetan, I know you got a chance to take a look at it. What have your thoughts so far on sort of the steps he’s got here?

[00:31:45] Chetan Conikee: Um, it’s pretty interesting because to start with you know, most of these systems, like cloud-based systems, hire multimodal where you can use the web to access.

[00:31:55] Chetan Conikee: And govern your systems, or you could use the command line interface. Now [00:32:00] both of these serve different needs. So it’s a mishmash of AD or access and authorization and role-based access control because you have resources and based on roles you map who can access what. So apparently in all of this you have a situation where someone provisions an account through one of these.

[00:32:23] Chetan Conikee: They can further on create an ephemeral key and that key could potentially serve other needs like CLI access where someone wants to access using the command line for a period of time. Now, all activities obviously mapping into the same role-based access control, which means when you create a key, you somewhat become stealthy when you go through the cli, and there could be good and bad reasons to do it, and mostly in large enterprises.

[00:32:53] Chetan Conikee: Cut red tape. Engineers need to debug fast. So they intentionally go ahead and [00:33:00] create maybe an affordable key to say, I’ll go touch this database because I don’t want to get 20 sign offs and spend five days to debug a production issue because my boss says, fix it, or, you’re fired. And now this could lead to many other issues.

[00:33:14] Chetan Conikee: And, and you know, the call out on this blog was fascinating because he’s taking a chain of events, connecting them together and saying,

[00:33:21] Chetan Conikee: It could manifest as a door.

[00:33:23] Ben Denkers: You know, I, I think it’s great from an incident response perspective of things you should be looking for you know, or at least in, in, in the sense of, you know, cloud security, right?

[00:33:32] Ben Denkers: I, I think, you know, adding these to kind of, that, that list of, of what you should do as part of evaluation becomes very important.

[00:33:39] Stu McClure: Well, it also goes back to just standard, you know, audit. Like if you ever get a security audit or an assessment, especially if you’re, obviously in this case, your cloud environment.

[00:33:48] Stu McClure: We’re gonna go through with a fine tooth comb of like, okay, what are your primary accounts? What are your backup accounts? What are your tertiary accounts? What are your quaternary accounts? Whatever it might be. [00:34:00] And, and do you know what they’re for? Right. Well, right. And we’re gonna have you justify, well, what are they, I mean, who, who owns this?

[00:34:06] Stu McClure: You know, how is it maintained? Who manages it? What level of access do they have? And, and that kind of stuff. That is often an afterthought, unfortunately. But it’s why. A lot of security audits are done every quarter, every year kind of thing. So, and

[00:34:20] Arun Balakrishnan: One thing the article mentions is, so most of these platforms, once you generate a key, they don’t give you a way to retrieve it, right?

[00:34:28] Arun Balakrishnan: So even if you can log in to the ui, you cannot achieve the old key. But the article mentions some platforms apparently allow a single user to have two keys, which I didn’t know until I read that article. And what the attackers were looking at is they were listing users who only had one key generated so they could go in and generate the second key and keep it safe so that they retain access.

[00:34:54] Stu McClure: Exactly. I was unaware of that whole second key capability or feature. And so yeah, [00:35:00] the bad guys were taking advantage of that and just basically querying all users that only had one key. I thought that was real clever. That’d be something in a hacking exposed book chapter somewhere, I promise.

[00:35:10] Stu McClure: Alright. I think, you know, last, but certainly not the least, I mean there’s a lot of stuff that we can talk about, but one of the things that caught my eye was, comes in part ’cause um, my son is doing a co-op program at a little company up in Marysville, Ohio, so it kind of popped out on me. But the Honda e-commerce platform called

[00:35:38] Stu McClure: Had some vulnerabilities recently that allowed for basically password reset without the existing or current password. And, you know, we talk a lot about this kind of business logic problem right? In AppSec and making sure that you’re thinking about, hey [00:36:00] don’t just assume the user requesting a password change is a legitimate user.

[00:36:05] Stu McClure: That’s exactly what I think. One aspect of this attack was about, I think there are three parts actually, so keep me honest guys. Uh, one of ’em was the ability to sort of cycle through you. So once you had access, you could cycle through users, other users and, and get uh, information about that account, et cetera, et cetera.

[00:36:30] Stu McClure: Um, and then, let’s see. Oh, the last one was, The platform’s admin PA panel could be fully accessed by modifying an HTTP response to make it appear as if the exploited account was an admin account. So basically you could interact with an HTTP, you know, get posts response and make it look like you were an admin so you could get access into admin capabilities as well.

[00:36:57] Stu McClure: So I thought those, all three of those I think are sort of [00:37:00] interesting.

[00:37:00] Ben Denkers: Yeah, I know. I. Again, I think it speaks to this you know, concept of you, you have to continuously validate that whatever controls you think you have in place are working. Right? I mean you know, whether that’s, in this case it was a third party but generally doing things like pen testing or, or other types of after production assessments go a long way and helping identify these types of vulnerabilities.

[00:37:22] Ben Denkers: The impacts can be huge in this case, you know, it was, you know, it was somebody trying to you know, have a, basically have goodwill, right? But if it was maliciously compromised, you know, there could have been thousands upon thousands of users who were potentially impacted. Again, I think it’s important that security’s never done and you continue to have to try and, and make sure what you have in place is actually working.

[00:37:48] Stu McClure: Yeah, it looks like about 24,000. Customer orders included, name, address, phone number, and again, with all this information, you know, we can go [00:38:00] at it.

[00:38:00] Ben Denkers: Yeah. What’s the downstream effects for sure.

[00:38:03] Stu McClure: Sim, sim swapping, sim jack and all that stuff works right.

[00:38:06] Chetan Conikee: This also seems like an IDOR, an age-old business logic fault, what they call as an Insecure Direct Object Reference, where if your customers are nothing but sequential IDs in a database, you can ricochet that into the experience because someone can just guess. Yeah. But rather you should map that to something unique.

[00:38:26] Stu McClure: Yeah. And I remember when we were first doing this in like early two thousands, this kind of technique, and we were doing all kinds of bypasses to IDS systems in and around, Unicode, basically converting the, the ID that you’re cycling through into a whole bunch of different conversions that would naturally get deconverted on the other side. And so it actually would come out as exactly the same, but over the wire it would look completely different. So you wouldn’t be able to tell that it was an actual [00:39:00] attack. Um, and that worked like a champ for, gosh, it probably still works to this day.

[00:39:04] Stu McClure: Um, so at any rate, look another great series, guys. I mean, there’s always so much material here. It’s almost like a shame we gotta finish. Uh, in the short period of time that we have. We could do this all day long. And I really appreciate everybody’s input on this. Any final words before we end it? Um, I thought it was a good, good selection.

[00:39:27] Chetan Conikee: My final words always comes back to the same issue, which is, if I’m a CIO in this environment don’t take the gauntlet to your security team and say, let’s cut budgets to save, because, this is what hackers want. Yes, they’re looking for this. That’s the door.

[00:39:44] Stu McClure: Well, and I’ll add speed.

[00:39:46] Stu McClure: Speed kills. Speed kills. We’ve learned that since we were a kid, right? When you’re learning to drive, what did your parents tell you? Speed kills. Well, that means that if you’re making it super fast and easy for developers to write code, [00:40:00] you’re probably skimping on some steps that even the smallest of steps could prevent all of these attacks.

[00:40:10] Stu McClure: So please think about that as you sort of implement your best practices inside the organization and sort of recommendations for how you address code security. So with that, thanks everybody. Have a great rest of your week and uh, look forward to next time.

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit:


See for yourself – run a scan on your code right now