Speaker 1: Welcome to tech Stuff, a production from I Heart Radio.
Speaker 1: Hey there, and welcome to tech Stuff. I'm your host,
Speaker 1: Jonathan Strickland. I'm an executive producer with iHeart Radio. And
Speaker 1: how the tech are you all right? Way back in
Speaker 1: nine a guy named Leonard klein Rock wrote a paper
Speaker 1: titled information Flow in Large Communication Nets, and a lot
Speaker 1: of folks point to this paper as laying out the
Speaker 1: basics for what would become networked computer communications, which in
Speaker 1: turn would evolve into the ARPA net Project, where the
Speaker 1: basic rules for computer to computer communication were established. And
Speaker 1: then you had things like radio based networks, you had
Speaker 1: satellite based networks. You had these all kind of coming together.
Speaker 1: And from that we then get an evolution into the Internet,
Speaker 1: which is the network of networks, and that really got
Speaker 1: its start around as different networks could finally communicate with
Speaker 1: one another, not just within themselves, and it was because
Speaker 1: of the establishment of common protocols. Now, many of us
Speaker 1: out in the real world, away from all these different
Speaker 1: research centers and government facilities and things like that, a
Speaker 1: lot of us remain blissfully ignorant of the Internet until
Speaker 1: you got up to the early nineties and the launch
Speaker 1: of the World wide web. The Web was an easier
Speaker 1: concept for most people to grasp than the larger idea
Speaker 1: of the Internet, because you could look at the Web
Speaker 1: and you could say, oh, it's like a magazine, but
Speaker 1: it's on your computer. It also wasn't that different from
Speaker 1: online service providers like a O L where you weren't
Speaker 1: connected to an internet at large, but you were connecting
Speaker 1: into a single network. And for a lot of people,
Speaker 1: the Web and the Internet were synonymous, right it was
Speaker 1: the Web was the Internet. Over time, I would say
Speaker 1: the general public came to understand what the Internet was,
Speaker 1: at least sort of. I mean, there's still people who
Speaker 1: do refer to the Web as the Internet, and the
Speaker 1: Internet is the Web and that's all there is to it.
Speaker 1: That's not the case. The Web sits on top of
Speaker 1: the Internet, but the Internet is more than just the Web.
Speaker 1: But then let's get up to the late nineties. That's
Speaker 1: when there was this guy working at Procter and Gamble
Speaker 1: who had an idea, and he proposed using r F
Speaker 1: I D chips on components and products for the purposes
Speaker 1: of tracking stuff as that stuff moves through supply chain.
Speaker 1: So an example of this might be for a microchip
Speaker 1: that's going to go into a larger product. Maybe the
Speaker 1: box that holds the little micro chip has an r
Speaker 1: f I D chip on it so that you can
Speaker 1: easily scan it as it goes from one point in
Speaker 1: the supply chain to the next. That way, you can
Speaker 1: keep track of where everything is throughout the entire system.
Speaker 1: And UH, that was a neat idea, right. It's a
Speaker 1: great way to try and keep an eye and monitor
Speaker 1: a supply chain. Give a logistics manager the capability to
Speaker 1: know what's going on at any given minute and respond
Speaker 1: to it, perhaps make changes if there is a delay
Speaker 1: at one point in the supply chain. Great idea. But
Speaker 1: you know this guy wanted to be able to convince
Speaker 1: his superiors to uh, to buy into this idea. So
Speaker 1: the guy's name is Kevin Ashton, and Kevin Ashton thought
Speaker 1: he needs kind of a sexy phrase to get his
Speaker 1: idea sold to these these higher ups, to get them
Speaker 1: to buy into his vision. So he called the approach
Speaker 1: the inter net of Things. Now, Ashton was allegedly just
Speaker 1: trying to get higher ups to support his idea for
Speaker 1: including r F I D tags and those tags wouldn't
Speaker 1: magically send information on their own to a network, you'd
Speaker 1: have to scan them and everything. But it wouldn't take
Speaker 1: long for this basic concept to evolve. And in fact,
Speaker 1: there were previous cases where people had connected sensors to
Speaker 1: certain devices and then connected those to a network so
Speaker 1: that they could monitor a device remotely. There was ones
Speaker 1: where people did that with vending machines, for example, so
Speaker 1: that they would know when the vending machine was running
Speaker 1: low on specific stuff that's that's, or in some cases,
Speaker 1: so that the person who had installed it would know, Oh,
Speaker 1: I'm not gonna bother walking down there. They're out of
Speaker 1: dr pepper. So I'm not even gonna bother leaving my
Speaker 1: desk because I know there's no dr pepper in the
Speaker 1: vending machine downstairs. But it didn't take long for this
Speaker 1: basic concept to evolve of into something more uh ambitious.
Speaker 1: And I think it's fascinating that the phrase internet of
Speaker 1: things actually predates the consumer smartphone era by nearly a decade,
Speaker 1: because I think for most people, myself included that that
Speaker 1: their awareness of the Internet of things came after smartphones
Speaker 1: first started to really become popular among the general population.
Speaker 1: I point to the iPhone launch in two thousand seven
Speaker 1: as the beginning of the smartphone era. Obviously, there were
Speaker 1: smartphones before the iPhone. Apple did not invent the smartphone,
Speaker 1: but smartphones were kind of a niche product that we're
Speaker 1: mostly just used by business leaders, executives, that kind of thing,
Speaker 1: and not so much the average person. But Apple changed
Speaker 1: all that, and then subsequently once we were all adjusting
Speaker 1: to the idea of being able to access stuff online
Speaker 1: through our phones in a way that was actually, you know,
Speaker 1: fun to do and useful. Because if you ever had
Speaker 1: a basic cell phone before the smartphone era, you know
Speaker 1: that if you did have any web enabled services on there,
Speaker 1: it was not good. Like it just didn't it didn't
Speaker 1: work well, it wasn't easy to navigate in. The iPhone
Speaker 1: changed all that. Well for me at least, my awareness
Speaker 1: of smartphones came first, and then I later became aware
Speaker 1: of this idea of Internet of things. But of course
Speaker 1: the Internet of things concept had been going pretty strong
Speaker 1: already for almost a decade. Anyway, as time would go on,
Speaker 1: we would see more folks experiment with Internet connectivity and
Speaker 1: everything from components like simple sensors or actuators which could
Speaker 1: go into larger systems. So you make a tiny part
Speaker 1: that is meant to go into something else. You make
Speaker 1: that one part capable of connecting to a network, and
Speaker 1: then maybe the rest of it also can, or maybe
Speaker 1: it can all the way up to more complicated integrations
Speaker 1: where the entire system is meant to be Internet capable,
Speaker 1: stuff like smart TVs. Right these days, you can outfit
Speaker 1: your home numerous smart devices that all connect to a
Speaker 1: home network or the Internet at large. And then there's
Speaker 1: also a growing use of Internet connected devices out in
Speaker 1: the world just outside of your home. Everything from cars
Speaker 1: to city infrastructure, security cameras, all sorts of stuff are
Speaker 1: all connected into the Internet, creating this massive Internet of things. Now.
Speaker 1: Throughout all that time, there have been security experts who
Speaker 1: have cautioned companies and consumers about the Internet of things,
Speaker 1: because the Internet of Things does come with it a
Speaker 1: lot of benefits. You can see a lot of really
Speaker 1: compelling use cases for the Internet of things, whether it's
Speaker 1: just keeping an eye on things to make sure that
Speaker 1: everything is working properly, to creating more convenient and lightful experiences.
Speaker 1: But any network connected device can potentially serve as an
Speaker 1: entry point for bad actors, for for malicious hackers, so
Speaker 1: devices can be compromised, and that might allow a hacker
Speaker 1: to get a foothold into say, your your home network
Speaker 1: and search for ways to get greater access so that
Speaker 1: they can do all sorts of stuff from stealing information
Speaker 1: to turning your network or devices on your network into
Speaker 1: agents that they use and things like a bot net,
Speaker 1: or they may use it to do stuff like mine
Speaker 1: for cryptocurrency. It's nothing like having you know, your your
Speaker 1: web server crash because some hacker has compromised tens of
Speaker 1: thousands of Internet connected doorbells and then directed all those
Speaker 1: doorbells to paying your web server. That's something that can happen,
Speaker 1: like those button nets that can do distributed denial of
Speaker 1: service attacks or de dos attacks. It doesn't have to
Speaker 1: be a computer like I often think of computers when
Speaker 1: I think of de DOS attacks. But the truth is
Speaker 1: any network connected device capable of sending a ping to
Speaker 1: a server can potentially be part of a boton net.
Speaker 1: So that includes a lot of devices we connect to
Speaker 1: networks that are not computers or smartphones. And if those
Speaker 1: devices don't have the proper security enabled on them, or
Speaker 1: if we're really lazy and we don't bother to update
Speaker 1: things like default passwords and user names, we can start
Speaker 1: to create the opportunity for some pretty serious mischief. Then,
Speaker 1: of course, there are the tens of thousands of devices
Speaker 1: that have been connected to the Internet, and then subsequently
Speaker 1: the company is responsible for the hardware or the services
Speaker 1: that run on the hardware have stopped supporting them or
Speaker 1: completely gone out of business. If this happens all the time, Right,
Speaker 1: We've got all these different companies that have created Internet
Speaker 1: of Things type devices or components for devices, and then
Speaker 1: the company gets acquired and then effectively services are no
Speaker 1: longer supported for some things. Well, if those devices are
Speaker 1: still connected to networks and they're no longer actively serving
Speaker 1: a purpose, they could potentially act as an entry point
Speaker 1: for hackers as well, right, especially if they use default
Speaker 1: user names and passwords, default log incredentials, because you no
Speaker 1: longer have a company that's actually actively pushing out updates,
Speaker 1: so there's no hope of someone sending out, say a
Speaker 1: firmware update that requires you to change your devices log incredentials.
Speaker 1: So if you've got these orphaned devices that are still
Speaker 1: connect into networks, they can serve as a point of
Speaker 1: entry for hackers. Uh, These these forgotten Internet of things devices. Uh.
Speaker 1: In some cases, forgotten can also just mean that, oh,
Speaker 1: you you connected this thing to your network, you forgot
Speaker 1: you did it, you haven't used it in ages. It's
Speaker 1: still technically connected and still active, but you're not like
Speaker 1: constantly using it. Uh. That can potentially become a vulnerability.
Speaker 1: This is really one of the big problems with Internet
Speaker 1: of things in general is that the Internet of Things
Speaker 1: as a concept depends heavily upon companies that create Internet
Speaker 1: of things products and services remaining solvent and actively supporting them.
Speaker 1: And if they stop supporting them, that the rest of
Speaker 1: us take the effort to remove those devices from our
Speaker 1: networks because they now h constitute a threat to our security.
Speaker 1: That's something that we're not very good at doing. Yet.
Speaker 1: I'll explain a bit about, you know, some examples of
Speaker 1: of where that all went wrong after we come back
Speaker 1: from this quick break. So I thought it would chat
Speaker 1: about some of the instances where hackers were able to
Speaker 1: exploit Internet of things devices. Uh. This isn't to warn
Speaker 1: everyone away from IoT. It's rather to remind ourselves that
Speaker 1: good security goes beyond resetting our router passwords or our
Speaker 1: modem log in credentials, and that it goes beyond being
Speaker 1: savvy with our computer security and and avoiding things like
Speaker 1: phishing attacks and that sort of stuff. All of that
Speaker 1: is important, and I think it still remains true that
Speaker 1: in your typical system, the weakest point is usually the people,
Speaker 1: not the not the systems, not components. But that doesn't
Speaker 1: mean that all components are bulletproof. And if there are
Speaker 1: vulnerabilities and the hacker community learns about it, that information
Speaker 1: can spread quickly in hacker circles and it may not
Speaker 1: get to anyone who can do anything about it until
Speaker 1: it's too late. You know, any time we're talking about
Speaker 1: adding components to a network, we need to think about security.
Speaker 1: Uh do we know? I mean I've been guilty of
Speaker 1: this too. I've added stuff to buy home network and
Speaker 1: then later thought, oh, you know what this thing that
Speaker 1: I just logged into, like I connected to my home network,
Speaker 1: it has a default user name and password that I
Speaker 1: can't change. And I bet there are people out there
Speaker 1: who know what the default user name and password happens
Speaker 1: to be for this particular device. I should just disconnect
Speaker 1: this from our network and not use it. And That's
Speaker 1: what I've done, Sometimes not immediately. Sometimes it's only after reflection. Luckily,
Speaker 1: as far as I know anyway, I've never been the
Speaker 1: target of a true intrusion. But it's not because I
Speaker 1: was careful enough. It's because I was lucky. And you
Speaker 1: can't count on that. And I'm saying this out loud
Speaker 1: so that I remember I can't count on that. So yeah,
Speaker 1: if we if we don't take the right steps, it's
Speaker 1: not like I would say, we're inviting trouble, but we're
Speaker 1: certainly going to be underprepared if trouble happens to find us.
Speaker 1: So let's begin with a big instance of a problem
Speaker 1: that affected not just the Internet of things, uh, category
Speaker 1: of technology, but IoT is certainly part of it. And
Speaker 1: it requires a bit of an explanation. So one thing
Speaker 1: that a lot of different systems, including a lot of
Speaker 1: IoT devices, tend to do, is log Uh. It's it's
Speaker 1: called logging. And now I don't mean that IoT devices
Speaker 1: are all putting on flannel and singing about being a lumberjack,
Speaker 1: and that's okay. No. In this case, log being means
Speaker 1: keeping a record of activity. So there are lots of
Speaker 1: systems out there that log stuff, and that makes sense, right.
Speaker 1: There's some systems that are designed to log something. That's
Speaker 1: all they're meant to do. Like let's say that you've
Speaker 1: got some environmental sensors set up in an area. They
Speaker 1: might be intended to log changes in things like temperature. Well,
Speaker 1: that's the whole purpose of that device. But even beyond that,
Speaker 1: in systems that aren't primarily about logging, they typically do
Speaker 1: have some form of logging capability. So you have Internet
Speaker 1: devices that are part of larger systems that are tracking changes,
Speaker 1: or you've got uh a logging system that logs performance
Speaker 1: information so you know how well your system is performing,
Speaker 1: is it running hot, is it efficient? You have error
Speaker 1: logging systems so that way, whenever anything goes askew, if
Speaker 1: something does not perform to expectations, you get a logged event.
Speaker 1: So that way a technician can later go back and
Speaker 1: see what the heck happened, How can we fix it
Speaker 1: and make sure it doesn't happen again so that doesn't
Speaker 1: interrupt service or worse, Um, you can log security status,
Speaker 1: all sorts of things like this. Well, it's standard essentially
Speaker 1: to have some means of logging errors, because if you
Speaker 1: don't have a way of logging errors, then when something
Speaker 1: goes wrong, it becomes like a murder mystery to figure
Speaker 1: out what the heck happened? Did it in fact go
Speaker 1: wrong or did the end user misuse the technology and
Speaker 1: misunderstand it. So you want to have that logging feature
Speaker 1: to to be able to diagnose problems much more quickly
Speaker 1: and then get to a solution. One set of logging tools,
Speaker 1: which include like a data set, a library set, that's
Speaker 1: that's heavily used in throughout technology, comes from a company
Speaker 1: called Apache. Jump on it. Apache used is used by
Speaker 1: a lot of high profile systems like cloud Flare uses
Speaker 1: Apache and cloud Flare, among other things, provides protections against
Speaker 1: denial of service attacks um. But it's also used by
Speaker 1: stuff like Steam and Twitter. And it had a tool
Speaker 1: called log for J. And what wasn't really known was
Speaker 1: that at least as far back as two thousand thirteen,
Speaker 1: there was a vulnerability in log for J that would
Speaker 1: allow for remote code execution or r c E. And
Speaker 1: that is just what it sounds like. It's a feature
Speaker 1: that lets someone run code on a point on a
Speaker 1: system from a remote location, so you can control a
Speaker 1: system as if you were right there with full access,
Speaker 1: maybe not full access, but with access, so you might
Speaker 1: actually build this into a system on purpose, Right, you
Speaker 1: might want to have remote operators able to access a system,
Speaker 1: but it can also be a vulnerability, like it could
Speaker 1: be something that you've overlooked where someone has figured out
Speaker 1: a way to execute code on a system that otherwise
Speaker 1: they should not have access to. And that was the
Speaker 1: problem with log for J. And you might wonder what
Speaker 1: specifically was going on, how did this happen? What was
Speaker 1: happening on a technical level, So I'll try to explain
Speaker 1: it from a high high viewpoint. The log for J
Speaker 1: tool uses a Java Naming and Directory Interface or j
Speaker 1: n d I. So someone who was trying to take
Speaker 1: advantage of this vulnerability and log for J would send
Speaker 1: a special h T t P or even an HTTPS
Speaker 1: based request to log an event, and they would target
Speaker 1: a server and they would send this UH this request
Speaker 1: which would include in the header a j n d
Speaker 1: I request. So um the target server would receive this
Speaker 1: and likely log this request as an error using log
Speaker 1: for J. Law for J. While logging the error sees
Speaker 1: that there's this j n d I request in the
Speaker 1: header of the request that was sent to them, right,
Speaker 1: And it's so essentially it reaches out to the server
Speaker 1: that sent the request in the first place, the hackers server.
Speaker 1: So this is kind of like someone saying, hey, can
Speaker 1: I help you? I see that you're having some issues,
Speaker 1: only it's a trap. As Admiral Akbar would say. The
Speaker 1: server would then direct this request from the target. You know,
Speaker 1: the target is saying, hey, how can I help. The
Speaker 1: server would direct that request to a directory that would
Speaker 1: contain malicious code, which, when the log for J system
Speaker 1: would continue this this process would activate that malicious code,
Speaker 1: which would then run on the log for Jay's target
Speaker 1: system UM and would create a backdoor access point for hackers.
Speaker 1: So if you've seen thor Ragnarok, this is the classic
Speaker 1: get he routine. That's essentially what the log for J
Speaker 1: vulnerability allowed hackers to do. Was it was like saying, uh,
Speaker 1: something has gone wrong. Log for J is looking into
Speaker 1: it and and the process gets trapped into running this
Speaker 1: malicious code. Didn't work all the time because obviously the
Speaker 1: server that you're targeting had to rely on log for
Speaker 1: J in the first place for this uh this vulnerability
Speaker 1: to be relevant. But this vulnerability and log for J
Speaker 1: persisted in several versions. So every time Apache was sitting
Speaker 1: on a new version of log for j This vulnerability
Speaker 1: was kind of baked in and no one knew about it,
Speaker 1: so it just it stayed there version after version, and
Speaker 1: apparently no one had Apache had noticed it, and no
Speaker 1: one outside of Apache had alerted them to it. And
Speaker 1: that changed on December ninth, twenty one. So remember this
Speaker 1: vulnerability may have been around since like thirteen, and it
Speaker 1: wasn't until someone, someone outside the hacker community figured this out.
Speaker 1: And that was when a security engineer named chen Xiao
Speaker 1: Jun who worked at the Chinese company Ali Baba Cloud,
Speaker 1: sent Apache a notification saying, hey, log for j has
Speaker 1: this critical vulnerability in it. So another side note, Ali
Speaker 1: Baba Cloud actually got into hot water for that because
Speaker 1: the Chinese government was mightily miffed that they were not
Speaker 1: informed of the vulnerability before Apache was told. And that
Speaker 1: sounds a little scary. I mean, maybe they were upset
Speaker 1: because they wanted the opportunity to address the vulnerability in
Speaker 1: their own systems because log for jays used so widely,
Speaker 1: and maybe that's why they were thinking, well, because you
Speaker 1: told them, now there's this window where attackers could attack
Speaker 1: our systems. Or maybe it was implying that the Chinese
Speaker 1: government would have preferred to keep the vulnerability secret and
Speaker 1: potentially use it as an exploit themselves. But whatever the
Speaker 1: log for J tool was is used all over the world,
Speaker 1: and this vulnerability affected any system that used the specific
Speaker 1: versions of log for J that contained this vulnerability, even
Speaker 1: if those systems were just using log for J to
Speaker 1: log errors so that technicians could diagnose system problems. Anyway,
Speaker 1: once word got out, there was a scramble to patch
Speaker 1: systems that were using affected versions of log for J.
Speaker 1: And if you were tuned into network security late in
Speaker 1: one and early in two, you probably heard about the
Speaker 1: log shell exploit. That was the exploit that would allow
Speaker 1: someone to penetrate a system by exploiting this vulnerability, uh
Speaker 1: and haven't run whatever code they wanted. And it was
Speaker 1: and is a huge issue. In fact, hackers have exploited
Speaker 1: the logshell vulnerability to create boton nets. Early ones included
Speaker 1: where one called Marai, which was perpetuated in various ways,
Speaker 1: but the log four J exploit was a big one,
Speaker 1: and another one called mush Stick. And when we come back,
Speaker 1: I'm gonna talk a little bit more about Marai, plus
Speaker 1: some other some other IoT vulnerability issues that we've seen.
Speaker 1: But first let's take another quick break. So back in
Speaker 1: the Marai boton net consisted of thousands of IoT devices
Speaker 1: and it was perpetuated in a couple of different ways,
Speaker 1: and one of them was through malware. And when a
Speaker 1: computer got infected by this particular kind of malware, it
Speaker 1: would immediately start a search for IoT devices that could
Speaker 1: also be infected and added to the button net. So
Speaker 1: one it was essentially doing was making a computer detect
Speaker 1: IoT devices and then use the default user names and
Speaker 1: passwords that manufacturers had set for these devices to try
Speaker 1: and add them to the button net. And because it
Speaker 1: can sometimes be impossible to change the default log in credentials,
Speaker 1: like there just isn't away at least not an easy
Speaker 1: way for the average person to make those changes, or
Speaker 1: a lot of people just don't bother to do it
Speaker 1: even if there is a way to make those changes.
Speaker 1: That meant that these devices were readily available to be
Speaker 1: added to button nets, and uh, stuff like DVR players
Speaker 1: were compromised and joined this bottonet army and the botton
Speaker 1: at the Murai Bottonet launched a massive de dos attack
Speaker 1: in you might even remember it. This was the one
Speaker 1: that that did some pretty big damage. Not I guess
Speaker 1: damage is the wrong word, but it definitely brought stuff
Speaker 1: down for several hours. So that included service is like Reddit, Twitter, Netflix.
Speaker 1: Outlets like CNN and The Guardian were affected, among others.
Speaker 1: According to a ten networks, the hacker group Charming Kitten
Speaker 1: out of Iran leaned on the logshell log for J
Speaker 1: exploit we were talking about before the break. They used
Speaker 1: that same exploit to launch attacks against Israeli servers, including
Speaker 1: ones belonging to the Israeli government. And while companies have
Speaker 1: been rolling out patches to their products that feature log
Speaker 1: for J, the fact that this was a widely dispersed
Speaker 1: tool and library set means it's very tricky to resolve.
Speaker 1: Like imagine it's it's something that's been spread throughout the
Speaker 1: world and then years later you find out, oh, shoot,
Speaker 1: it's got this fatal flaw in it that we didn't
Speaker 1: know about and everybody's got one. Now, how do you
Speaker 1: get the message out so that anyone affected can take
Speaker 1: steps to get rid of that thing. That's kind of
Speaker 1: where we are now. I mean it's the big companies
Speaker 1: started rushing out patches right away. Uh, And these were
Speaker 1: companies that had built log for J into lots and
Speaker 1: lots of different products, but smaller companies may still be
Speaker 1: struggling to fix that. And you know, it's it's just
Speaker 1: a it's just a tough situation. I liken it to
Speaker 1: being aboard an enormous ship that has thousands of tiny
Speaker 1: holes in the hull. You you're patching holes and patching
Speaker 1: holes and patching holes, and there always seems to be more. Uh,
Speaker 1: that's kind of where we're at now. And in case
Speaker 1: you're wondering, like the compromise systems, some of them are
Speaker 1: engaged in these sort of de dos botan net boton
Speaker 1: net attacks, and some of them are being put to
Speaker 1: you know, mine cryptocurrency. So yeah, fun times. While there
Speaker 1: are steps that companies and even network administrators can go
Speaker 1: through to help eliminate risk with log for J, it
Speaker 1: requires a lot of effort. And for any systems out
Speaker 1: there that are orphaned or that are part of the
Speaker 1: organization that just lacks the resources to address problems like this,
Speaker 1: it means there remains vulnerable points within various systems and
Speaker 1: hackers will continue to probe for them. But let's talk
Speaker 1: about an IoT device that made it was made to
Speaker 1: give you greater security, but in fact it brought with
Speaker 1: it a big security vulnerability. So a company called trend
Speaker 1: Micro has a product called the Home Network Security Station.
Speaker 1: This device connects to home routers and what it's what
Speaker 1: it's supposed to do is scan for activity. It's supposed
Speaker 1: to alert you to any possible network intrusions. So, in
Speaker 1: other words, if someone is trying to gain unauthorized access
Speaker 1: to your network, it's supposed to give you an alert.
Speaker 1: Supposed to give you a centralized point where you can
Speaker 1: change access settings on network devices so you can, you know,
Speaker 1: like revoke permissions for devices so that they can no
Speaker 1: longer access your network. That kind of stuff, which is
Speaker 1: legit a useful tool to have in your arsenal. However,
Speaker 1: when they first started shipping this product, it had some
Speaker 1: bugs in it that created potential attack vectors. Some researchers
Speaker 1: at Cisco Talos uncovered these problems. There were three of them,
Speaker 1: so one was the one of the components inside the
Speaker 1: device used a hard coded password. And and as that
Speaker 1: phrase suggests, this is when you've got a predetermined password
Speaker 1: that's hard coded into a system at some level. And
Speaker 1: you know, systems are made up of lots of different components.
Speaker 1: Sometimes just an individual component can have a hard coded password,
Speaker 1: and that alone can be a vulnerability because if a
Speaker 1: hacker knows or can guess that hard coded password, they
Speaker 1: can potentially first exploit that component and then perhaps escalate
Speaker 1: that into getting control of more of the system. This
Speaker 1: process of a hacker establishing an attack point and then
Speaker 1: using that to gain more purchase is called privilege s scalation.
Speaker 1: In network security settings. The goal is to obtain the
Speaker 1: highest level of access across the broadest spectrum of systems
Speaker 1: that you can, and it all starts somewhere, including these
Speaker 1: smaller components that have a hard coded password associated with them. This,
Speaker 1: by the way, is why it is a good idea
Speaker 1: to change your default password on your various devices if
Speaker 1: you can, because there are hackers out there who just
Speaker 1: maintain enormous databases of log in credentials for lots of
Speaker 1: different components network components. Anyway, the researchers at Cisco tell
Speaker 1: Us found, in addition to the hard coded password to
Speaker 1: other vulnerabilities that allowed for this privilege escalation. Uh and
Speaker 1: together that just marked a real bad vulnerability. But Cisco
Speaker 1: tell Us researchers alerted trend Micro. Trend Micro were able
Speaker 1: to send out an update to connected systems that helped
Speaker 1: fix that problem, so they were able to patch out
Speaker 1: those vulnerabilities. And the good news is that while the
Speaker 1: vulnerability could have potentially handed hackers access to affecting systems,
Speaker 1: there were no attacks found in the wild. So it
Speaker 1: looks like this vulnerability was found and uh and mitigated
Speaker 1: without anyone in the hacker group being aware of it,
Speaker 1: so no one was able to take advantage of it
Speaker 1: before that door was shut. So that's a good good
Speaker 1: story there. All right, Well, that's an example of an
Speaker 1: IoT device meant to secure your network and the device
Speaker 1: itself ends up having vulnerabilities in it. But what a
Speaker 1: valut device that's meant to just keep you alive. That's
Speaker 1: a big old yikes. And yeah, back in CNN reported
Speaker 1: that the FDA discovered that implantable cardiac devices from St.
Speaker 1: Jude's Medical had some vulnerabilities in them, and that means
Speaker 1: that devices that are intended to stimulate a person's heart
Speaker 1: so that it continues beating could possibly be hacked. And
Speaker 1: this is kind of getting into like science fiction dystopian
Speaker 1: horror story territory here. The f d A said that
Speaker 1: a hacker could use a transmitter that would normally perform
Speaker 1: a scan of cardiac devices and it was intended to
Speaker 1: give physicians information about how a patient is doing remotely,
Speaker 1: but instead the hacker could use that transmitter to potentially
Speaker 1: drain at cardiac implants battery or change the pace of stimulation,
Speaker 1: which could obviously lead to disastrous results. St. Jude Medical
Speaker 1: swiftly got to work patching the vulnerabilities, so they fixed
Speaker 1: the problem. But when you're talking about devices, especially ones
Speaker 1: that have already been implanted in patients. These are devices
Speaker 1: that are meant to help keep people having a healthy life, well,
Speaker 1: stuff gets complicated. You can't just push out a firmware
Speaker 1: update to someone's heart you know, if you have to
Speaker 1: reboot your router at our firmware update, that's usually not
Speaker 1: a big deal that most it's a minor inconvenience, But
Speaker 1: when you're talking about a device that regulates heartbeat, well,
Speaker 1: implementing a patch could cause an interruption of service, and
Speaker 1: in this case, that service can be critical to that end.
Speaker 1: Officials were urging caution to physicians before they installed patches
Speaker 1: to patient cardiac implants because there's a risk that something
Speaker 1: could go wrong in that process, including the loss of
Speaker 1: functionality from the device, and that's clearly not what you
Speaker 1: don't want to create, and a medical emergency while you're
Speaker 1: trying to prevent a hypothetical future one. So yeah, that
Speaker 1: was a really bad instance of vulnerabilities. It's legitimately terrifying,
Speaker 1: and it reminds us that while the Internet of things
Speaker 1: vision has undeniable benefits, I mean, even in that case,
Speaker 1: right a physician being able to monitor patients remotely, that's incredible.
Speaker 1: It could mean the difference between someone suffering a cardiac
Speaker 1: event and having it prevented, and that has a tremendous
Speaker 1: effect on that person's quality of life. So that is
Speaker 1: something to be wished for. That is something we should
Speaker 1: strive for. But we also have to keep in mind
Speaker 1: that whenever we're talking about connectivity, there are risks that
Speaker 1: come with that, and it means that we need to
Speaker 1: really search out vulnerabilities in these products before they get
Speaker 1: to the shipping process, which is easier than than done.
Speaker 1: Companies have limited resources, it is very difficult to suss
Speaker 1: out any and all vulnerabilities uh in some cases, and
Speaker 1: when it's released to the world, then you've got the
Speaker 1: resources of the entire world that could potentially look into
Speaker 1: a product and find vulnerability. So I don't want to
Speaker 1: put a lot of blame and unfair burden on companies
Speaker 1: that have released things that have had vulnerabilities in them.
Speaker 1: In some cases, it's not even their fault. It's because
Speaker 1: as they incorporated a component that for that came from
Speaker 1: a different company, and that O. E. M company had
Speaker 1: was the source of a vulnerability. But no matter what
Speaker 1: blame you want to place, the end result is that
Speaker 1: we need to be able to identify these quickly and
Speaker 1: address them and preferably prevent them from ever getting out there,
Speaker 1: and making sure that the shipped product is as secure
Speaker 1: as possible so that we can enjoy those benefits without
Speaker 1: the risk of these security vulnerabilities. Um, there's some other
Speaker 1: examples we can talk about. You know. There was the
Speaker 1: example of hackers getting access to IoT devices with trend Net.
Speaker 1: This was a company that produces internet connected security systems.
Speaker 1: Ironically enough, UH, they had this one webcam that they
Speaker 1: were UH marketing over in the early twenty tens. UM
Speaker 1: they were marketing it as either a home security system
Speaker 1: or a baby mon The ring system but there was
Speaker 1: a major problem, and that was like essentially between twelve
Speaker 1: these specific web based cameras would allow anyone who had
Speaker 1: the IP address for that camera to look at the feed.
Speaker 1: So that's it. All you needed was the IP address.
Speaker 1: If you had the IP address, you could see whatever
Speaker 1: that camera could see. And that enormous invasion of privacy.
Speaker 1: Right if someone gets hold of of that IP address
Speaker 1: and they wouldn't normally have access to the camera, that's
Speaker 1: phenomenally bad. Right. But then also trend neet was had
Speaker 1: a really bad habit of doing things like transmitting user
Speaker 1: log in credentials in plain text over the Internet, which
Speaker 1: means anyone snooping on any of that communication would see
Speaker 1: plain text log in credentials. Not not a secure way
Speaker 1: of doing things. Um, the FTC brought an enforcement at
Speaker 1: action against trend net. The company paid out a settlement
Speaker 1: the following year, and trend net still operates to this day.
Speaker 1: But now they take the steps to mask all these
Speaker 1: things so that they are not uh these massive security vulnerabilities.
Speaker 1: So they did take steps to address those problems and
Speaker 1: fix them in the future. But this is the sort
Speaker 1: of stuff we have to be aware of, you know,
Speaker 1: anytime you wanna think about smart systems, whether you're talking
Speaker 1: about your home or an office, or you're looking at
Speaker 1: smart connected vehicles, it's good to do the research to
Speaker 1: look into things like, what does the security community say
Speaker 1: about this stuff? Are there any alerts about it? Should
Speaker 1: I be concerned before I connected? If there are things
Speaker 1: like log in credentials or or network access features I
Speaker 1: need to know about? Are there steps I need to
Speaker 1: take in order to change default passwords? These are all
Speaker 1: important steps. And I know it sounds like a lot,
Speaker 1: and I know it also may sound like, well, what's
Speaker 1: the likelihood that I'm going to be targeted? But if
Speaker 1: we look back to that Marai example, the Marai malware
Speaker 1: and bought net that was you know, that doesn't mean
Speaker 1: that you were a target in a hacker's eye. It's
Speaker 1: not like the hacker saw you and said, oh, I'm
Speaker 1: gonna see if this person's network security is up to speed.
Speaker 1: That was a malware that was automatically making computer scan
Speaker 1: for other devices that could potentially be compromised. When you've
Speaker 1: automated that and you've created a malware that spreads this
Speaker 1: way where it gets increasingly more powerful and more um
Speaker 1: prevalent in an area. You don't need to be anyone
Speaker 1: special to get targeted. It just can happen. So it's
Speaker 1: important to keep all that in mind whenever we're thinking
Speaker 1: about the Internet of Things. I really like the vision
Speaker 1: of the Internet of Things. I like the ential benefits,
Speaker 1: but I also worry about rushing into implementations without properly
Speaker 1: giving security and privacy a lot of consideration. Okay, that
Speaker 1: wraps up this episode of tech Stuff. That's the show
Speaker 1: I'm doing right now, right, yes, tech Stuff. If you
Speaker 1: have suggestions for future topics or questions or anything like that.
Speaker 1: A couple of different ways you can get in touch
Speaker 1: with me. One is to download the I Heart radio app.
Speaker 1: It's free to downloads free to use. You can navigate
Speaker 1: over to tech Stuff by typing that into the little
Speaker 1: search engine. Pop on over to the podcast page. You'll
Speaker 1: see that there is a microphone icon. If you hold
Speaker 1: that down, you can leave a message up to thirty
Speaker 1: seconds in length and let me know if you would
Speaker 1: like me to play it in a future episode. I
Speaker 1: don't have to, I'll only play it if you tell
Speaker 1: me to. Uh. But yeah, that's one way to ask questions.
Speaker 1: Another is to go on Twitter. The handle for the
Speaker 1: show is tech Stuff hs W, so you can use
Speaker 1: that to get in touch with me. A couple of
Speaker 1: you have been asking if I'm on Mastodon for tech Stuff.
Speaker 1: I am not not yet, but I will be looking
Speaker 1: into that this week to see if I can use
Speaker 1: that as another way of contact me. One last thing,
Speaker 1: On Wednesday, we will be playing an episode of The
Speaker 1: Restless Ones here in the tech Stuff feed. The Restless
Speaker 1: Ones is an interview show that I host where I
Speaker 1: talked to leaders in technology departments in big companies and
Speaker 1: UM it's a it's a fun show about leadership and
Speaker 1: technology and UH and the benefits of UH networks. So
Speaker 1: I hope you will enjoy that, and I just wanted
Speaker 1: to give a shout out so that way you're not
Speaker 1: surprised when it happens on Wednesday. It's totally planned, supposed
Speaker 1: to happen. That's it. I hope you're having a great
Speaker 1: start to your week so far, and I'll talk to
Speaker 1: you again really soon. Text Stuff is an I Heart
Speaker 1: Radio production. For more podcasts from I Heart Radio, visit
Speaker 1: the i Heart Radio app, Apple Podcasts, or wherever you
Speaker 1: listen to your favorite shows.