This week on the podcast, we discuss the Common Vulnerability Scoring System or CVSS and why one popular developer thinks its completely broken. After that, we cover Lumen's Black Lotus Labs' research into a Juniper backdoor malware. We end with the latest car hacking research and an admin portal with possibly the worst MFA implementation ever.
View Transcript
Marc Laliberte 0:00
Hey everyone, welcome back to the 443, Security Simplified. I'm your host, Marc Laliberte, and joining me today is Corey.
Corey Nachreiner 0:08
$1 million Nachreiner,
Marc Laliberte 0:14
That's the worst… I need to, I need to grab my cat, the worst doctor, evil impression I think I've ever seen.
Corey Nachreiner 0:21
I'm not an impressionist. At least he knew where it was going, probably because we recorded the joke before the intro.
Marc Laliberte 0:29
Anyways, on today's episode, we will cover the latest in car hacking by Sam curry. Before that, we'll go into J magic packets targeting Juniper routers and switches, no, just routers. But before that, we'll have a bit of a discussion on is the CVSS scoring system flawed and totally irreparable. Just
Corey Nachreiner 0:49
throwing with that Marc, it sucks. It's gone. It's dead, yep. Like AV, it's completely dead.
Marc Laliberte 0:57
With that, let's go ahead and drive our way in. DREW
Corey Nachreiner 1:02
You. Room So
Marc Laliberte 1:06
Corey, I want to start this week with an interest, an interesting blog post that I saw. It popped up on our slash cyber security early last week, and it caught my attention from the title and from the author once I actually landed on the page. So the title was CVSS is dead to us, and it was written by Dan Stenberg, who is the founder and lead developer of curl and libcURL, yeah,
Corey Nachreiner 1:34
at all. What a very tame and boring title, right?
Marc Laliberte 1:37
And like I assumed, based off the title, where it was going, and it was going pretty close to that. But it's also it's a topic that even internally, like we've kind of wrestled with when it comes to dealing with these, what feel like arbitrary scoring systems for vulnerabilities. So before diving into this blog post, like real quick, if you're not familiar with CVSS or the common vulnerability scoring system. It's a way to convert like metrics or factors about a vulnerability into a 0.0 through 10.0 number, which you can then extrapolate into a severity of low, medium, high critical. CVSS 4.0 was just released in November of 2023 I think it takes into account factors like the attack complexity, whether there's any pre existing conditions that need to be present, the actual attack vector so you need network access or need to be like on the machine itself, whether user interactions require the privilege is required. And then it also takes into factors the impact of the vulnerability. So what's the impact to the CIA triad? So confidentiality, integrity and availability? Is it low or none, partial or none, medium or high on neither
Corey Nachreiner 2:52
of those non partial, incomplete, I think, for things like confidentiality, unless the Wikipedia is behind correct
Marc Laliberte 3:00
so, and it takes all those into account you can use, like a fancy little calculator that's hosted everywhere. Click a bunch of buttons and it puts in a bunch of weights and spits out a zero through 10 auto score of how severe your vulnerability is. But one of the things CVSS does is it's really just a worst case scenario severity rating for every vulnerability. It's like, if this is exploited or and exposed, how severe could it be at worst? But there's the other
Corey Nachreiner 3:29
thing that I think we might get into the blog post is it also is very simplified in that, if you have this software and you have this version, there's a vulnerability, but it doesn't necessarily have all the details of like, there's many situations where, yes, that version of software has a vulnerability, but only if it's compiled with the switches or only if it's used in this situation. And that type of nuance is kind of harder to display in CVS, as I'm sure we'll get into as we go further into the blog post. Yeah,
Marc Laliberte 4:04
like a great example of that is, like open SSL. It's a library used on Linux and I guess Windows machines too, for encryption and basically anything to do with encryption. It's one of the most bloated libraries that there is these days, to the point where wasn't it Google that released, like, boring SSL or something like that, which was a super stripped down version of it, but open SSL, they've got vulnerabilities all the time, but lately they've been in like, how they handle certificates, or how they handle like, diffie hellman key exchanges, and if you aren't using that specific component of it, like you just said, Yes, you may have a vulnerable version that's Going to get picked up and flagged by vulnerability scanners. But if you're not using like, the specific vulnerable function, it's really not applicable. It's not a vulnerability in your system. So every CVE record for vulnerabilities is supposed to have a CVSS score. It's not like explicitly required. But it's heavily recommended for each of them to help just enrich the record and let most people make a quick decision of how severe is this issue. But like you said, there's, there's a lot of nuance beyond that zero to 10 score in there, certified numbering authorities like WatchGuard, we're responsible for publishing that initial CVE record for vulnerabilities in our products.
Corey Nachreiner 5:21
By the way, that takes extra work, though, right? I mean, every vendor, every product or piece of software, might have someone report to CVE to get the CVSS, but to be actually like to kind of own your own destiny, you have to do work to become that CNA, not. Not every vendor is a CNA, and a lot of companies get their vulnerabilities reported with CVS scores independent of them if they haven't taken those steps exactly.
Marc Laliberte 5:49
But if you are a CNA, then you're responsible for setting that initial CVSS score. But if you don't, there's actually an entire process for handling that. It's called the authorized data publishers or ADPs, which are responsible for enriching CVE records, like those in IT and security that have ever looked up a CVE probably ended up on either miters website, which is like the CVE services, like source of truth, or NVD, the National Vulnerability Database. By I think it's NIST, and historically, NIST and NVD were the ones that were enriching these records, and they were kind of just doing it for the heck of it. They were a special CNA that was allowed to go edit other CVEs with the latest updates to the CVE program. They created this new ADP, or authorized data publishers thing, which NVD would be one if they continued doing it. They basically, I think it was about a year ago, put out an announcement saying we're done enriching CVEs. It's too much work. We can't handle it anymore. And CISA actually took over the cybersecurity, infrastructure and security agency. So now CISA goes through and adds on that enrichment anytime it sees a vulnerability that doesn't have the CVSS score. This is where problems can arise, where, like CISA in this case, or other ADPs, they don't know all the details about the vulnerability. They know what is published in the record, which is usually a couple of sentences, and if they have
Corey Nachreiner 7:16
maybe what a researcher is posted, if it was disclosed externally, I guess, but
Marc Laliberte 7:22
they're doing like, 1000s of these, yes, even 10s of 1000s. So I have to imagine, like, except for the biggest and most widely used projects or libraries, they're not doing probably a whole bunch of research on it, and that can lead to some inaccurate results. So this brings us back to curl and Dan Stenberg, where they made a decision years ago now to stop using the CVSS scoring system, and they instead just use their own knowledge about the actual severity of the issue or the risk of the issue, and grade it in a bucket of low, medium, high or critical. But because they're not adding CVSS scores to CVE records. That means other people are so Dan explained this story in here where he was notified of this new critical vulnerability in curl. And he goes, Well, that's weird, like I am not aware of any new critical vulnerabilities in curl, and it turns out it's a vulnerability they had published CVE, 2024, 11, 053, which was a they called it a redirect credential leak vulnerability. So it's an issue that can happen in very certain circumstances for Linux users, when they use a specific configuration file in a specific way, and it could potentially leak a like an HTTP authentication credential to a redirected website. So this very like narrow set of circumstances, they graded as a low risk issue, and that's what they published it as CISA went in and updated the record and graded it as a 9.1 out of 10, which is a critical issue. And it was pretty quick then for news publications and researchers out there to pick it up as Oh curl, one of the most widely used libraries out there, has a 9.1 severity critical issue out there. That means vulnerability scanners would start picking that up too and start flagging a critical severity vulnerability on people's networks too. You can see where this could be an issue of that disconnect, like CISA, their initial grading wasn't ideal. In fact, Dan submitted a pull request to the public repository. CISA has for all of this to do an actual CVSS scoring, which he calculated as a 5.3 sis actually merged it in as a 3.4 instead of that original critical one. But it was already like damage was done at this point, most tech public, well, not most. Some tech publications aren't going to go back and say, Oh, wait, never mind. That's not a critical and like, delete their news post or update it. And so now there's just posts all over there about this 9.1 critical issue in curl that simply doesn't exist. Yep. So this. Was it was an interesting like, blog post about him basically saying the system is flawed and we should not use the system. And CVS says 4.0 which made a bunch of improvements to try and make more accurate numbers, says it doesn't ultimately do anything on either. It's still a flawed system. So this, I thought it was interesting. Like, we've talked a lot internally at WatchGuard through our own vulnerability management process of you know, a critical vulnerability doesn't mean critical risk, and we try and grade our response and trio and prioritize our response based off risk, not severity. I think that's where
Corey Nachreiner 10:36
the because, because we're a CNA, we're able to more accurately use CVSS, including our knowledge of what the real internal impact is. So I think we might our CFS, course, might be better in general. But to your point, as an enterprise ourself, when we're looking at external CVSS, we have a risk management process that brings in our own it. We consider the CVSS the public impact, the public related impact. But for likelihood, we have our own calculations based on our environment and whether or not we're doing you know, whether or not we maybe are using the parameters that can actually take a CVSS score and make it a lower severity for our own team, because we know that CVSS as this type of nuance, and sometimes your own implementation can greatly lower the risk. So just like you're saying, I think hopefully the ones we publish are pretty good, because we are the vendor, and we understand how these products interact with our product, but when we're using external CVSS, we sometimes know that we have to pay attention to the reality of the vulnerability.
Marc Laliberte 11:52
And like I so I respect Dan. He's a extremely talented engineer, clearly, but I think this is where, like, his disconnect is coming from is confusing or not confusing, but conflating severity with risk, and I think we need a severity rating for vulnerabilities, even if, like a 10.0 doesn't mean drop everything you're doing to patch it, just means go, investigate it, go, actual risk is
Corey Nachreiner 12:17
so I agree with you as we're Talking about this, I don't think CVSS is dead in the pure fact that he doesn't share an alternative like I actually agree with all his problems. He's properly stating problems and he's sharing where nuance can actually make it have some natural CVS scores be conflated. So I think we all agree kind of with that, but it's the best system we have so far, and he hasn't imposed an alternative, and the alternative can't we're internally without transparency, going to have our own system that we don't tell anyone about and we don't interact with the rest of the industry. So whether you love it or hate it in its current form, CVSS is at least that industry standard. That's a starting point, and we need these vulnerability scanners to be yes. Sometimes it means there's nines reported everywhere that are not really that big a deal. But for the most part, I think it works to bring the industry together to at least have a mediocre, mediocre standard, which is better than no standard at all to have a starting point. And I think you make the excellent point that a nine or 10 doesn't mean immediately. You know, you use your brain. We all have our own critical thinking. We can still read the detail of the vulnerability and see how it impacts us directly. So I think he's good for bringing up the problems, but I don't think you can say CVSS is dead unless he proposes something that works for all industries across the board, and is transparent and standardized, because we need a rating.
Marc Laliberte 13:55
And I think he's like, if I'm going to put words in his mouth, I think he's burned out from just people, IT professionals here, professionals using CVSS incorrectly so that, using it as the sole factor and deciding, like, how to respond to an issue absolutely like in reality, it's it's one factor, like you mentioned, you need to take into account. How are you using that application is even exposed the exploit code maturity, a 10 Dotto critical, like theoretical vulnerability, is very different from a 10 Dotto actively exploited vulnerability worth source code up on GitHub on how to explain
Corey Nachreiner 14:32
and the cell point. Oh, sorry, yeah, go ahead and I kind of agreed. Like the other thing is maybe fed up with tech media not taking enough research on their own. On one hand, I'm actually supportive of tech media paying attention to cyber security and holding negligence accountable, but sometimes even authors that you point out that are not my favorite authors anymore, like take these stories and report them with no nuance and make. Big deals out of something that are patently on untrue, you know, or just jump on a nine without doing a little research to figure out, Is this really as bad as it is? You know, get at least one expert, you know, if it's in a curl library, maybe contact curl before publishing the story to get their response. I think, in the 24/7 media cacophony, where they want to publish a lot of scary things that get attention immediately. They don't really care about the detail they want the oh, this is critical. Come look at it now, because 20 minutes from now, I have to move on to something else and you'll never come back to it again. And while I believe in free media to help keep people in line that are really doing bad things. I think media has a bit of a responsibility here, and they probably are part of why. Wow, I already forgot the name is a Daniel. I'm screwing up fast. Yeah, why? Daniel is maybe fed up. But again, like you putting potential thoughts in his head. Now,
Marc Laliberte 16:02
before we move on, like, let's at least entertain the thought experiment of, let's say everyone stops using CVSS scoring tomorrow, and maybe we do move to some like, arbitrary, like, every vendor just says what they think the risk is, or maybe there's nothing at all. Like, my concern with that would be, would would vendors not be incentivized then to downplay the severity of their issues, like literally not to throw stones in glass houses, but if you're Fortinet cranking out critical vulnerabilities every single week for the last couple of months, you might be incentivized to say, actually, you know, this one's really only a low when the reality might be a little bit different, or
Corey Nachreiner 16:37
lean heavily on the user interaction. Yes, there are certain vulnerabilities that a user might have, have to, have to do a bad configuration. We've had some ourselves, but that doesn't actually mean the initial critical vulnerability wasn't critical. So, you know, we're, we're saying this because even as a vendor, we would have to keep cards on ourself. It business and profit are, are are a motive that drive a lot of businesses. And, you know, I don't think there would be as much transparency, which I think actually is even bad for that business. I think it's much better to have customers fully aware of what even your own vulnerabilities are, and that transparency actually provides customers that want to stay with you. So I think it's ironically good for business to be as transparent as possible, but I agree with you in general, not yes, some businesses would be better actors than others, maybe, but that that profit and marketing is a big driver, so it'd be hard to really trust the reliability of it if everyone was just kind of doing their own thing. And more importantly, how would something like a vulnerability scanner work? You know, we all as companies, need technology to automate finding where we need to update and all these, you know, rather than going to one source a database that's kept up. You know, globally, you'd have to go to every individual company that makes software as a vulnerability scanner, and that would kind of, I feel like, put them out of business, as far as cogs, which maybe you don't care that you have to pay for a vulnerability scanner anymore, but ultimately, that's going to make you more and more insecure over time. So I just think having a standard is important to everyone,
Marc Laliberte 18:24
yep, but if there's one takeaway, it's don't just use CVSS as the single factor for absolutely responding to issues. Take into account other things, like your own environment, exploit code maturity in order to make your decision on whether you need to actually update it or not. And
Corey Nachreiner 18:40
then for faws, like cryptographic flaws, like a what sounds big like a 50% weakness in a cryptography algorithm may mean it goes from trillions of years to billions of years. And yes, it was a huge hit, but really is taking now half a billion years less secure. And you know what I mean. So like you say, do a little analysis of the floss. CVS is not an excuse to ignore the detail. Yep, 100%
Marc Laliberte 19:11
so moving on, there was another cool research post just last week from lumens, Black Lotus labs. And I want to give them credit, even though I really dislike lumens reliability when it comes to being an Internet service provider sometimes. But so their research lab found what they call the J magic back door, because it uses magic packets to go after Juniper routers. So they wrote a blog post about the research from a campaign. Should
Corey Nachreiner 19:42
we pause on a magic packet real quick and just read like a magic packet isn't necessarily the whole packet, but when we usually talk about magic bytes, they're just a bite sequence that is being looked for. If you see that byte sequence do something. So to me, a magic packet is still a normal packet. It's just. Where in the data set there's going to be a special byte sequence? Is that accurate? Yep. So
Marc Laliberte 20:06
this campaign was active from September 2023 through mid 2024 and this all started when they saw a file uploaded a virus total called Juno script service, which mimics the June OS automation scripting service on Juniper routers. They don't know the initial attack vector. All they know is the script ended up on virus total. They don't know how it would end up on a router itself, but they know that when it ends up on a router and when it's executed, takes in two arguments on the command line, one for an interface name and one for a port, and then it renames itself, NFS IOD zero to hide as the NFS IO Server on the Junos routers, and it starts up a function called start to
Corey Nachreiner 20:50
kind of NFS IO it's a NFS asynchronous NFS server that you might expect to be on these routers for A legitimate purpose, you know, the real one anyways.
Marc Laliberte 21:02
So then it spins up a kind of obvious to its purpose, named function called Start PCAP listener, which then reviews all packets received by the filter on the interface that's provided and looks for specific bytes in certain fields, like, for example, looks for a certain value at an offset in the TP. TCP options looks for a very specific TCP options length, looks for certain sequence numbers in the packets, strings following IP headers or TCP headers. Think there's like five or six different conditions that it goes through for a packet that it receives, and if all of the conditions match, then it spawns a reverse shell and connects back to the IP that sent that packet. So it's basically a way to sit there listening, kind of hidden behind the scenes, until a very specific packet from an IP address comes in, gets picked up by that filter, probably dropped by the router itself, assuming there's no route tables to handle it, and that kicks off a reverse shell back to that attacker's IP.
Corey Nachreiner 22:04
You'll probably get to this. But interestingly, it seems to be based on some pretty public code that has been around for a while. I mean, not the conditions it seems like are unique to this threat actor, but the code doing this kind of monitoring, Port knocking spawn reverse shell is a I'm sure we'll get to it, but is something that's been out there publicly for a while. I
Marc Laliberte 22:28
think it was like decades even. So when it connects back, that's not just everything it does. It actually does a challenge response mechanism to prevent other people from stumbling across it and triggering that reverse shell. It's got, like, I think
Corey Nachreiner 22:45
even researchers like if, even if they didn't know all the sequence that trigger it, they might, if they know the beginning, they could kind of mass scan the Internet and send this to try to see if a router were infected. But it's a little hard to do with the conditions in the RSA key, right?
Marc Laliberte 23:01
Yeah, so it creates a random five character long string and then encrypts it with a hard coded RSA key as a challenge, and the response must contain that decrypted string, basically proving that you've got the the other the private key for that RSA key pair, so to prevent that shell from opening to someone else, other than the attacker, they so lumen looked into their global telemetry for this, they preserved, or actually, like you mentioned, real quick before we move on. You're right that this back door, it seems to be based off of something from, I think, 2000 so, like, literally 25 years ago now, which is
Corey Nachreiner 23:42
dated version. Of it. I mean, there's one that was on packet storm, which old people may know, which? There's a lot of evil source, not not evil, but scripts and stuff there you can get for old malware. But apparently, there's a newer version of the the same name GitHub project that has some updating, and I think it has some classic port knocking, where it starts working across different ports too. Yep.
Marc Laliberte 24:08
So lumen, being a internet service provider, they've got access to a whole lot of internet traffic. So they started looking through all of their telemetry from march 2004 to september 2004 they found 36 unique IP addresses around the globe that appeared impacted. 36 is, in the grand scheme of things, pretty small, like normally, when we see attacks against network, connected hardware, it's hundreds or 1000s.
Corey Nachreiner 24:35
Would suggest nation, state level, apt style, actors who are a little more targeted, maybe exactly, versus one possibility or hypothesis you could draw from a low number of targets. The
Marc Laliberte 24:50
bulk of the IP addresses were VPN gateways. So Juniper routers configured to be VPN gateways, the few other. I think there's like a half dozen were just exposed net conf, which is a configuration information and management interface for G Os.
Corey Nachreiner 25:09
They didn't, as they said, they don't know the actual root cause of getting this script on the router, but I wonder if anything about having exposed net conf ports, I mean, you'd still probably need authentication. But is there a vulnerability there? This is purely my speculation, by the way, not the lumen team.
Marc Laliberte 25:29
Yeah, exactly. They looked at the verticals. It was a mix of like construction, heavy machinery, it and manufacturing. Interestingly, though, is primarily in the United Kingdom, Norway and Russia as the victims, like almost entirely just those countries. So pretty dang targeted. It was interesting
Corey Nachreiner 25:48
seeing Russia's interest. Yeah, that's very interesting. Generally,
Marc Laliberte 25:52
if it was a threat actor in Russia, as long as they don't target people in Russia as well, they're like, ignored,
Corey Nachreiner 25:58
yeah, and some of the adversaries we commonly put together, like China and North Korea, seem like they are pro Russia. So who would have maybe back door agreements not to target each other in their their malicious cyber this is again, speculation land, but you know, you'd even think the classic Chinas and North Koreas. It's unusual for them to target Russia, in my opinion, picturing
Marc Laliberte 26:25
them at like the Dr Evil table, all making sure they've got good rules of engagement until one of them gets launched into the pit of fire for taking them off,
Corey Nachreiner 26:33
yeah, or fed to the Shark Tank, literally leaves
Marc Laliberte 26:37
Dr Evil in this case. Is it Xi Jinping or is it Putin. I'm not sure who would have to be Xi Jinping, one
Corey Nachreiner 26:44
of this million dollars. Marc, $1 million I've been frozen for far too long.
Marc Laliberte 26:50
Yeah. Anyways, either way, the main takeaway from this, it's like, it's tough if you're using network equipment as it's supposed to be. So like a VPN endpoint, you kind of have to have that exposed to the internet. So I guess the main takeaway would be keep it updated to resolve any known vulnerabilities, and then just hope that there isn't an unknown one.
Corey Nachreiner 27:08
This is our theme, man. We've again, we're not throwing stones because we've had one case like this ourself, which is well taken care of, but clearly the adversaries are targeting routing devices, which includes much a lot of security equipment, virtual and hardware wise. So what we've been saying for the last two years, I feel like patch your routers, pay attention to your VPNs. Use MFA on anything that you have to expose, and don't expose any management interfaces that you don't have to. Yep, 100%
Marc Laliberte 27:42
so moving on to the last story. This was another fun one. So last September, we talked about researcher Sam Curry's like latest car hack at the time. This is when he was able to unlock key as with just a license plate number. He built this whole like web app for being able to do it. It was pretty awesome. But last week, he published a new post called Hacking Subaru tracking and controlling cars via the Starlink admin panel. And real quick, it's not to be confused with space X's Starlink. So it turns out Subaru launched their Starlink car connectivity thing back in 2014, five years before SpaceX launched their Starlink. So two totally different care about trademarks, apparently not, and apparently Subaru doesn't care about by the
Corey Nachreiner 28:23
way, this story starts with some odds. I don't know if you, since we're kind of, you know, doing this or without the notes, don't know if you're going to mention it, but I thought it was really cute that it starts by he bought this Subaru for his mom, with the only caveat that he gets to do some research against it
Marc Laliberte 28:43
exactly with the promise that she would let him try and hack it, which is pretty dang cute. That's it. That's yeah. So he did that back in 2023 and he spent the next like two years trying to find vulnerabilities, but really didn't have much success, until this last Thanksgiving, where he finally asked his mom for her credentials to log into the my Subaru app. He poked around in that app for a bit, but actually had really good authorization. He wasn't able to find what he typically finds like in that Kia set of vulnerabilities for gaining control over it, but he wanted to keep investigating further, and so he actually engaged one of his friends and asked them, Hey, do you have any ideas on, like, what we should look at? And his friend immediately replied back with, Hey, have you seen this domain, Subaru, cs.com so it turns out that the my.subaru.com domain for the app was just a C Name record pointed at this my s dot pro dot Subaru, cs.com domain, so an entirely different one. So Sam spun up a fuzzing tool to go find different sub domains for it, and ultimately stumbled across across Pro, or what is it? Port? Dot prod, dot Subaru cs.com, which was the Starlink admin portal. So Starlink being the communication backbone for Subaru, Subaru cars and computers. So on that portal, like he tried logging in, it actually had good access control, or decent access control there. So he started looking at the the scripts that it was loading, found one script called Starlink, enroll.js, in a specific folder. He assumed that there would be other scripts in there, so used a pretty cool tool called FF, UF to start it's basically uses a dictionary to look for other scripts. And he found one called login js, and that one included a code snippet for sending a password reset without seeming to confirm any token of some sort. You know, normally when you click a password reset email, it's got a token that the server knows about to verify that you actually got that email to go reset the password.
Corey Nachreiner 30:55
Nope, this one. Just give me an email and tell me your password, and I'll do it for you. Exactly what a script.
Marc Laliberte 31:01
He predicted, if it worked as it was written in the JavaScript, then attacker would just need a valid emails, valid employees email to take over their account. So next he went to go try and find valid emails. He found another JavaScript or another endpoint that could let him enumerate email addresses. It was the end point for returning a Forgot Your Password challenge question. He then went on LinkedIn and searched for Subaru Starlink and found a bunch of employees. Used that as a word list, and ultimately found a valid email address.
Corey Nachreiner 31:33
We also pretty easily found, like most businesses, like honestly, you shouldn't be using the email address as a factor of authentication, even though it technically is as your name. But he did quickly find, I mean, most businesses use a pretty standard email technique for every email address, whether it's first name, last name, first initial, last name, blah, blah, blah. He found that pretty quickly. This
Marc Laliberte 31:59
is why every WatchGuard employee gets a randomly generated 30 character string for our email addresses. And
Corey Nachreiner 32:04
Scott, I wish, and I don't wish for security people. We would like it. But could you imagine, I guess our contact book would but it would be a pain in the butt to send emails. Yep. So
Marc Laliberte 32:17
he was able to go and reset the email or reset the password for that particular employee. Uh, when he went to go log into the portal, there
Corey Nachreiner 32:25
was a John Doe, there exactly a Joe doe or Joseph do or a Jacob doe. But either way, when he
Marc Laliberte 32:32
logged into that portal, though there was a little pop up that was presumably a second factor that he had to enter an unknown thing that he didn't know about but he went in and just viewed the source code for that and noticed that he could simply remove the source code that showed that pop up window and behind the scenes, everything all worked like it didn't actually do any verification. It was basically just like a blur thing,
Corey Nachreiner 32:56
true security by obscurity, like beyond the pale in your own code. Let's pretend to do MFA to give people the worm and fuzzies.
Marc Laliberte 33:06
Yep, so he could just hide that window and now interact fully with the admin portal for Starlink, for Subaru. And so through this portal, he could see like PII for different owners. He tested it with his mom's car. Found that he could track her location from every single time she started her engine for the past year down to like five meters of accuracy. He tested with a friend's car where they shared their license plate, he found he could look up their car in the admin panel, add himself as an authorized user to the car, which sent him an email, and then he could then unlock that car remotely. And succeeded. And for the victim, in this case, his friend, they didn't get any notifications that someone had been added to their car as well, so they had no way of knowing that this was the case. So, long story short, like he could remote, start, stop, lock, unlock and do location tracking for cars, complete location history for the past year, whole bunch of PII for the customer, including all of their billing info for their super their my Subaru account could access records like call histories with the customers the previous owner, odometer readings, sales history, a whole bunch of different PII through this pretty powerful portal. And
Corey Nachreiner 34:23
even though he manually did it through the portal, it looks like he wrote a lovely script called Subaru that uses the same API to gather all this stuff for you. Too. Nice.
Marc Laliberte 34:33
Good news is he reported it to Subaru and they patched it within 24 hours of his report. So very, very quick response in that case, but so the end of his blog post had a bit of a thought provoking addendum that I thought was interesting. So he said, quote, the auto industry is unique in that a 18 year old employee from Texas can query the billing information of a vehicle in California, and it won't set off any alarm bells. Else. It's part of the normal day to day job. The employees all have access to a ton of personal information, and the whole thing relies on trust. Seems really hard to secure these systems when such a broad access is built into the system by default.
Corey Nachreiner 35:14
By the way, I greatly disagree with one part of that. What's that the auto industry is unique. I have a feeling there's a lot of IoT devices in the world similar to auto industry, whether it be healthcare, manufacturing, the stuff we bring in our homes, where this is exactly the same in big ways too. I mean, I think his point is it's cars and yet, this is all easy to do, but I don't think it's unique to the audio industry. I think it's unique to many OT and IoT internet connected things we have out there. Yeah,
Marc Laliberte 35:50
that's, I think, totally fair and accurate. But the thought of that is, like, I agree with him on this. Like a lot of organizations, you know, you need powerful tools sometimes to manage your systems, to manage your product, service, whatever you have, but a lot of times they don't place enough like protections on it. So if someone were to get compromised, it's nearly impossible to recover. Yeah,
Corey Nachreiner 36:16
Marc, I totally agree. Like I think vendors, they need to have their service providers, their support have access to things. They technically need at least a given route to their customers accounts to do certain things. But I think, like PCI regulation has this right for service providers where one of their checks is, is there is there some sort of customer request that allows you to get access to the account. So an example I would give is our firebox. Our firebox is not designed to send any critical information or give access to us as a company, to a customer's firebox, but we have a support mechanism, both on the firebox and in the cloud, where you can, as a customer, can request us to have access, and you have to initiate it and send us a, you know, a key, and then when we can get set access, so it's you're giving us access to do support. And obviously these car manufacturers need their support reps to be able to do this, but it needs to have some additional authenticated access that's really customer approved and under the customer's attention. So I agree with you that this type of like the company does have to have this access, but they need to put more checks and balances around it. It needs to be authenticated. It shouldn't be automatic, and they should be security testing the heck out of admin portals like this, and not just leaving them open with horrible forget my passwords and fake MFA and all that. Bs this would be like if Subaru has to follow PCI. This is all kinds of PCI violations, let alone any other compliance.
Marc Laliberte 37:58
For God's sake, stop using client side CSS and JavaScript to control access to applications. Like,
Corey Nachreiner 38:06
yeah, I'm going to give the people accessing my application the ability to change things to improve their own access.
Marc Laliberte 38:13
Oops, that's nuts. But anyways, this is another cool bit of research from him. I'm looking forward. He meant, and made a comment that he's kind of sick of car hacking posts, but I'm looking forward to his next one. He seems to have a lot of I
Corey Nachreiner 38:27
guess he's probably sick of it, because there's too many examples of him finding it. But I think it's industry that much needs improvement. So I definitely like you appreciate his posts. I
Marc Laliberte 38:39
agree 100% so hats off, Sam, looking forward to the next one. Hey everyone, thanks again for listening. As always, if you enjoyed today's episode, don't forget to rate, review and subscribe. If you have any questions for us, questions on today's topics, that's how it goes. Suggestions for future episode topics you can reach out to us on blue sky. I'm at, it's Marc.me. Corey is at second app. Dot, blue sky. Dot, whatever the default thing is,
Corey Nachreiner 39:07
I'll fix it. I'll get onto your it's me, you should,
Marc Laliberte 39:13
yeah, there you go. And the both of us are on Instagram technically at WatchGuard technologies. WatchGuard technologies, yeah, it's like, I'm not on Instagram, but someone will relay your message to us. So thanks again for listening, and you will hear from us next week.
Corey Nachreiner 39:29
Give this guy a little vacation and he forgets his entire outro script. Yeah, Jesus. I'm kidding. You did fantastic.