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