Hi, guys. Welcome to the IoT Village and the 410 Talk. As you can see, we're going to be
talking about IoT, the gift that keeps on giving. And this is presented by Alex Balan,
a.k.a. Jay. Let's do this thing. Thank you. So, first of all, sound check, because during
the last talk, there were a bit of problem with a bit of background noise. So, can anybody
in the back hear me okay? Yeah? Thank you. So, thank you for taking the bait with the
first slide, first of all. And also, big shouts to the guys that actually hacked this thing,
and they're actually in the room right now. So, in case you're wondering, the machines
in the system, they're actually in the room right now. So, in case you're wondering,
these are palace run Linux. These were taken yesterday. Okay. So, we're going to talk about
three major things. First of all, the crazy state of IoT. Second, we will detail a bit
about how we did our research, what were the results, what's the impact, and how much of
the entire planet is going to be impacted by this. Some of you will already know what
we're talking about, and I will ask you to look kindly on us and our methodology. Some
of you who are not familiar with IoT security will learn something today, because we will
take you step by step through each step of our research, how we did each single thing
and how we achieved each single result. So, stay tuned, because if you want to learn how
to attack IoT, now is your chance. And third, conclusions. And you will learn why the presentation's
name is the gift that keeps on giving. So, chapter one, the crazy state of IoT. About
a few months ago, I rented a car. I registered it with my name, my e-mail address. I passed
it on to the car rental.
And then,
after about one year, I keep getting e-mails from the car saying the mileage, what the
car has done, what is the status, the pressure in the tires, whether or not it needs revision,
and that's probably because the car rental didn't bother to deregister it from my name.
So, mind you, up until today, I still get e-mails from that Chrysler with its status.
And a very important thing that I would like to point out is that, in the last two years,
again, but I would like to point out that everything becomes more. This is kind of a
cliché, but you probably have no idea the rate at which this is happening and how little
choice we have in our choices right now. When I say that everything becomes more, I mean
that we will not have the option to buy non-connected devices. And to give you just an example,
For example, we used to have parallel port printers, then USB-connected printers.
Now all printers are network-connected.
We went through that stage without even realizing it.
We took it as a benefit.
It is a benefit, but it's a herald of this new era in which everything,
including your upcoming glass of water, will probably be monitored by something connected.
Xbox without connectivity doesn't exist.
I guess there's no dumb TVs anymore, especially in the U.S.,
maybe in some third-world countries like other countries in Romania.
So it's very important to understand that IoT is not going to be optional.
It's important to realize this.
So these are not picked at random.
All of these have some kind of vulnerability discovered in them.
And that smart power outlet, for example, has a command injection, remotely exploitable.
From anywhere in the world.
As a fun story, I was at this IoT Builders event once in February last year with a colleague of mine.
By the way, it's nice to see so many familiar faces.
So there were these guys that made a device that would make you be calmer or more energetic.
Now, it's the actual...
It's the actual equivalent of electronic drugs.
When you put it on your head, you control it with a mobile app,
and that mobile app talks to the cloud, and that mobile app controls the device through Bluetooth.
And it can make you calmer, much like weed does, or more energetic, much like something else that I did never try.
And the problem was that this is the thing.
I put it on my head.
And I set it to more energetic, because I'm usually a very mellow person.
All my friends know that I'm very calm, very chilled, very relaxed.
And I turned the dial to one, two.
When I got to three and a half, I passed out.
That guy over there was with me.
He can testify to that.
I passed out.
The guy grabbed me.
And for about 20 minutes, I was unconscious almost.
I was like...
And I think that's very dangerous.
Because that device is connected to a mobile application.
It's controlled by a mobile application.
And that mobile application talks to the internet.
So if you can hijack their cloud and send commands to that mobile application,
you could effectively be able to fry all their users' brains at the same time.
And that's kind of screwed up.
It's like science fiction, like Kingsman.
But it's actually theoretically possible now through companies such as these.
I'm not saying that what they're doing is bad.
All I'm saying is that...
Maybe...
Maybe they are not ready to market this without a serious bug bounty first.
The most common issues that we've discovered is, of course, undocumented hard-coded passwords.
Win-blink Mirai.
Weak or no encryption.
There's a lot to be talked about this.
And I would like to focus more on the research part.
Command injection.
This is an example of a command injection in a smart doorbell.
They have a Dell file CGI which calls a system command called RM on UIN.
Right?
And you can just, you know, send my column and append another command to that.
Wi-Fi configuration hotspots that remain open.
Worst of all, and an advice to everybody, if you want to evaluate how good a solution is,
look at the way they update.
This is the simplest thing that you can do.
If they do automatic update, like Nest, Amazon, and a number of other good products, they're okay.
If they ask you to upload a firmware binary file that contains the update in an antique interface,
that means that product is shit.
You should throw it out.
I'm not even joking.
And the most dangerous issues discovered and will be shown today.
U-P-F-N-P.
So, just so I can get a feel of how much I'm supposed to debate about this,
how many here know what U-P-N-P does?
Okay.
A good chunk.
Thank you.
So, for those of you who don't know, U-P-N-P enables the device behind the router
to tell the router to port forward something,
effectively exposing that service directly in the Internet.
So you put this piece of this nice camera in your house,
it's going to tell the router to do port forwarding to you.
And that being said, I'm going to start this.
Just to make sure.
This is part of the demo, right?
This is the router that's going to be used for this demo.
And my laptop simulates the Internet.
Okay?
My laptop provides Internet to the router, connected to the router's external interface,
the WAN interface, and it's going to look perfectly fine, no ports open, rock solid.
The Nmap is going to take a while.
So in the meantime, hang on.
There we go.
Another big issue is device cloud, mobile app synchronization.
In this process, there's a lot of sanitization to be done.
A lot of user input sanitization to be done.
And unfortunately, 90% of the cases, it's not happening.
It's not going to be part of this talk.
We have another paper on it, probably to be presented at another conference.
But it's really, really interesting.
It's very, very fun.
So one of the key messages that I would like to send out.
Most research that's being done right now on IoT is focused on proximity-based attacks.
Stuff like Bluetooth men in the middle.
You know, hijacking the key exchange, key replays, these kind of things.
Or getting root access, you know, through some command injection in the local interface on your LAN.
And I'm not saying that's wrong.
That's really, really cool.
I mean, it gives you the opportunity to share your knowledge with the world.
And, you know, make that device better.
But you know what's even cooler than that?
Mass hacking hundreds of thousands of devices.
Because so far, it's been done with telnet.
And that's pretty, pretty trivial.
Am I right?
That's like the basics of the basics of the basics.
What if there is another step to be taken in remote compromising hundreds of thousands of devices?
Okay?
We should look at that.
And what if there's one more?
Probably more complicated.
But once discovered, it can be reused by the bad guys to compromise hundreds of thousands of devices.
The world does not begin and end with telnet when it comes to mass hacking.
Right?
So, to that point, I would like to make an analogy.
IoT's are small computers with a stack that looks like this.
Hardware, an operating system, and an application layer that companies develop poorly.
Because they don't know any better.
It's not their fault.
Much like, is anybody familiar with this stack?
Is anybody older than 30 years old in here?
Okay.
So, Red Hat 6.2, Vue FTPD?
Ring a bell to anybody?
It was one of the most popular exploits in 1998, 1999, something like that.
I would like you to recognize that it's virtually the same stack if you think about it.
If that IoT is exposed in the internet, from a hacker's perspective,
it's the same goddamn thing.
They don't care if it's IoT or WordPress.
Much like this one.
iOS 5.0, Windows hardware.
Much like this one.
Subway hack.
Right?
Or much like this one, hardware whatever, whatever application that can be hacked.
I would like to emphasize that if an IoT is accessible from the internet,
from a hacker's standpoint, it makes no goddamn difference if it's an IoT or a WordPress.
They will command execute it, add it to a botnet,
and either use it for spam, DDoS, Bitcoin mining, and whatever the hell they do.
They don't care it's IoT.
So, do not treat IoTs differently.
Have a focus on IoTs which are exposed on the internet.
So, that in mind, IoTs have a slight addition
that kind of increases the attack surface,
and that is application cloud application on the IoT communication.
And there's a load of vulnerabilities that can be discovered in this handshake.
So, why that is bad?
Well, because there's no standards in this industry.
The FTC is trying to develop some standards.
I saw this really great talk by Aaron Alva.
I hope I remember the name correctly.
From FTC at Black Hat.
And they want to develop standards,
and they want to develop a certification for IoT.
I salute that initiative.
I would like to be part of that.
We would like to help.
So, that's great.
The lack of standards in building these devices is awful.
It's the main cause for problems.
And obviously, each company builds their own stuff,
and they have no idea what they're doing.
So, chapter two.
We come to the fun part.
From China with love.
We have these two devices here.
I hope you can see them.
It's a webcam and a smart doorbell.
So, step one.
You take one standard Linksys router.
You set up the application.
And I would like to point out one step in the setup process,
which is bad resolution.
But basically, it says, to protect your privacy,
please reset your password.
Which is great, right?
It's a good thing.
And you're going to go saying, oh, my God,
this application is taking care of the security of their users.
They're enforcing a password reset,
so users do not have the same passwords everywhere.
Good job.
And it's awesome.
But as we're going to see later on, useless.
Okay?
But remember this step.
And then you blah, blah, blah, finish setup.
The setup process is the same.
And that brings me to the first thing that I want to point out.
They are two different devices with two different purposes.
However, they have a thing in common.
Video streaming.
So, as it turns out, it's the same firmware.
It's just a different coating on top of it.
And as it turns out, this very same firmware is integrated by,
I have no idea how many other vendors,
that OEM from these guys.
So, different colors, different buttons, different things,
but the same binaries and the same firmware.
So, that means that everybody, it's not going to look like this.
It's going to look different.
It's not going to look like this.
It's going to look different.
But if they have that firmware embedded into them,
they're going to have the same vulnerability.
So, the first thing that we noticed is that from a perfectly good router,
and this is the part where I plug in.
I plug something in.
This.
All 1,000 ports scanned and actually just so you can see live.
Wink, wink.
So, no ports open on the router initially, right?
I'm going to give it a minute to boot up.
Because after that,
the same router is going to have two open ports.
Why?
Because of God damn has to be killed with fire and brimstone UPnP.
I'm very, very serious about this.
UPnP is, I think it's one of the main reasons where IoTs are going to get hacked like crazy.
If your router supports UPnP and the device is retarded enough to ask for port forwarding,
your router is going to die.
You have to do it.
And that device will effectively be exposed on the Internet.
Much like these devices, which are vulnerable, are right now.
So, out of curiosity, let's see if the thing booted up.
The same main map.
There you go.
Port 80 open, port 554 open, port 1935 open.
And they weren't open before, right?
I mean, no tricks, no bots, no coconuts.
You guys see nothing up my sleeves.
So, that's the first issue.
And it's a big deal, again.
Next.
Shodan said that this has great potential.
The web server said, at the time we asked, 135,000 devices.
For the RSTP server, we found 147,000 devices.
And then what we did, we took all the IP addresses.
We did the differentiate between them.
We took out the unique ones to make sure that we were accurate.
We didn't just add them.
We just added the unique ones.
And we ended up with a final total of unique 228,808 devices exposed in the Internet with whatever we're going to show you next.
I know, right?
How messed up is that?
We got pretty excited, obviously.
We were like, woohoo!
This is awesome!
So, we started to do the basics.
Basics being, you know, Wireshark, seeing the way they communicate, taking apart the mobile application and all that blah, blah, blah.
And at some point, we realized that we have become accustomed to a number of stupid things.
If you've discovered the kind of things that we see in IOTs in your web application for your company, you would take down the server.
But we realized that we didn't care anymore because we've grown accustomed to bad coding because of these guys.
For example, they have encryption in their communication with their cloud.
But they don't have any encryption in the authentication process to the web interface or to the video stream.
So, basically, if you connect to the video stream or if you connect to the web interface, that has no authentication.
Now, we all feel that that is lame and ignorable.
But in essence, it's because we got used to these devices being shit, right?
It's not because that's the way it's okay to be.
It's because we got used to these devices being crap.
And I don't personally think that that's okay.
That's something that has to change one way or another.
So, we stumbled across this.
We have an authentication interface on web and an authentication system on RSTP.
What do we do with an input field?
We fuzz it, right?
So, we thought that we're going to have a lot of fun with it.
But unfortunately, it crashed on the first try.
So, yeah, that happened.
And, again, this is stuff that can be done remotely from the Internet on any of those right now.
So, it's kind of bad.
The RSTP server, though, didn't crash yesterday.
It hasn't crashed yet.
As we're going to see later on, they actually did something even more stupid in that place.
But, you know, security by obscurity.
We thought that, you know, it was okay.
But it wasn't.
So, what do crashes smell like?
Right?
Right?
Right.
So, we needed the binaries to see how the crash happened.
In order to be able to reproduce it.
In order to be able to see if we can achieve remote command execution.
And, obviously, I wouldn't be here if we couldn't do it.
So, spoiler alert, we did it.
But let me just tell you how we did that.
First of all, so this is, again, I promise, a quick crash course.
If you want to, you know, do this kind of thing, it's very easy.
One of the key takeaways from this presentation is that IoT hacking is trivial.
Everybody should be able to do it.
Everybody should do it.
And maybe then we're going to have, you know, safer devices and more awareness in this field.
So, we hooked up to the serial.
They had a serial.
It booted up much like you boot a system.
I'm sorry for the low resolution.
It basically says log in.
So, yeah.
This is what we got on the serial interface.
We didn't have any credentials yet.
So, what we do when we don't have credentials, we try to hijack the bootloader.
Much like you would do on a Linux machine.
When you would pass parameters to init and say init equals BIM bash or whatever in order
to reset your root or somebody else's root password.
Right?
So, it's the exact same thing with IoT.
You just pause the bootloader and pass parameters to init.
And I'm sorry, but you're not going to catch anything.
We got a dump shell exactly like you get in round level 2.
Right?
I think.
On Linux.
And we added a telnet service to the startup script.
This you can probably see.
And then we got this.
So, again, this is basic stuff.
It's simply because they do not protect their bootloader.
Some companies do.
Most companies don't.
You should probably be able to do this with almost all devices.
So, the first thing that we saw was, unfortunately,
and do you remember that slide where they asked us to change the admin password?
Yeah.
So, we did change the admin password.
But what we discovered afterwards was that they had two more users backdoored into the thing.
Like with user, user, and guest, guest.
There's no documentation about it.
Absolutely nobody, unless you know where to look, knows about that.
So, if you guys want to see some live streams from people's houses, don't do it because it's illegal.
But if you don't care about that kind of thing, just show them the thing.
And then user, user, guest, guest.
We haven't tried it ourselves, of course, because our legal department didn't allow us to do that.
But we heard from a very reliable source that it works on 99.99999% of all of those devices.
It's not, I'm not proud of this.
I mean, it's not great.
I hate this.
It shouldn't happen.
But it's true.
But, again, it's the sad state of things.
I would expect that after this talk, this to be popped on insecam.org, if you're familiar with the website, or that wall of webcams.
These are easily, very easy to add on those kind of websites because of these things.
So, what's next?
We wanted remote command execution, right?
As you can see, they decided that they want to be monolithical.
And have one binary.
In which they stuffed absolutely everything from web server, video server, authentication mechanism, you name it.
Everything is embedded into one binary.
Which actually, unfortunately, when you hack it, when you do anything to it, it reboots the thing.
But you are able, as you're going to see, to execute something.
So, debug time.
Since we got system file system access.
It had an SD card support.
We copied the entire file system to the SD card.
And we got the binary.
And we started to look at the way things work.
So, authentication works like this.
It checks the URL, HTTP, IP address, question mark user, blah.
Password, blah.
And those blah are being parsed by that data function.
Right?
So, what's going to happen is that libasparse data is going to copy the content of those two arguments.
Use them in passwords onto the stack.
And it's not going to check their length.
Now, as you can see below, there's only 460 bytes allocated to the stack.
So, if you feed it more than 460 bytes, it's going to crash.
Because of out of bounds.
So, what we needed is to be able to exploit it.
And now comes a fun part.
So, pay attention to this one if you're sleeping.
Wake up.
Because the system has ASLR enabled.
So, that was kind of bad for us.
Because if ASLR was enabled, we wouldn't know where to inject our code.
Right?
So, that was kind of a big thing.
And we were like, okay, this sucks.
So, then we, just for the sake of it, we checked the binary with check file.
It's a program by Microsoft.
Some guy in Germany.
And who is familiar with this?
Pi stands for position independent executable.
And it's a flag when you compile a file that allows ASLR to move the program, to put it at different addresses in memory.
Because that's what ASLR does.
ASLR prevents you, even though you're able to crash a process, prevents you from executing your code.
Because it always places the program at different memory addresses.
So, you're not going to know where code is.
So, you're not able to exploit it.
However, they bypassed ASLR.
Because that's how they roll, man.
ASLR is for pussies.
So, yeah.
They compiled it without position independent executable.
And as such, it's always loading at the same address.
So, from that point onwards, we used the RobGadget.
We actually had system available.
We called system.
And this is the exploit.
Actually, this is the exploit.
It's very complex, as you can see.
Very big.
This can get root access on 200,000 devices worldwide.
Actually, not this specifically.
Because you're going to need different targets for different devices.
So, it's the same method to get the targets.
But this is one memory address.
This is another memory address.
So, yeah.
Okay.
That's it for this thing.
The RSTP was a different issue.
As you recall, we weren't able to crash it.
By just, you know.
Sending garbage to it.
And that is because they rewrote it.
They actually rewrote digest authentication in their own way.
And obviously, they did it badly.
Because you see these fields which are basically user field and value.
Digest authentication has multiple entries of field value, field value, field value, field value, field value.
Now, this field value thing is implied to have 256 bytes.
And obviously, the way they wrote it is that they just parse it with scanf.
And they do not validate the limit.
So, if you put in field value, field value, anything beyond 256 bytes, you're going to crash the thing.
So, it works.
You just send this kind of string.
And this is the exploit for RSTP.
We use the same.
It's the same binary.
So, we use the same raw gadget calling system to execute our commands.
So, yeah.
It's time for demo.
So, I will just like to recap my setup here.
The laptop is the Internet.
The router gets Internet from the laptop.
So, the laptop is connected to the router's one port.
The one that's supposed to be filtered.
And these devices are connected to the router.
So, what we're going to try to do is get root access.
Actually, connect back shell because you cannot, you know, move past the router.
We have a Metasplate handler listening here already.
Wait.
That was not supposed to happen.
Okay, demo gods.
Let's see what's happening here.
Okay, this is dead.
No worries.
So, I have a quick and dirty copy-paste file.
Because it's a lot of stuff.
So, you can see we execute our exploit.
As a target, we have NIP22, which is the camera.
The IP address, which is the router IP address, which would be the Internet of accessible router IP addresses.
And then this is the command between codes.
So, we have HTTP, get Jena, which is our binary as a tribute to a great poet.
We write it to a local file called slash TMP slash Jena.
And we get it from a remote server, which would be my laptop.
Then we make it an executable.
And then we fetch another RCS, which is like the script that executes a startup from the TFTP server.
Make a copy of the original RCS.
Replace the original RCS with ours, which actually executes Jena at startup.
Because why we do this is because the thing crashes when you get the command execution.
So, we need to add it to the startup scripts because we're not going to have time to do anything on it otherwise.
So, here's to the demo gods.
Okay, it's supposed to crash in a couple of seconds.
One thing that we've added, just so you see how that script looks like.
So, we have to add a sleep 20 in its script.
Because it wouldn't execute.
It would execute earlier than the network interface would get up.
So, that's why we have to wait a little bit.
Did it reboot?
Okay, it reboots it now.
And there you go.
Shell!
So, sessions minus I3.
IR root.
Yep.
So, I will take commands from the audience for one minute.
Who wants to see stuff like...
It's on ARM.
And I'll show you where the juicy stuff is in MTD.
And then the first thing is RT2878STA.
Okay.
Not this one.
Yeah.
So...
Wi-Fi credentials.
And...
The nice thing that I was telling you about earlier.
Could we move the projector just a little bit?
Thank you.
So...
I'm going to...
Does anybody want to run any commands on it?
Seriously, it's okay.
No?
Okay.
So, we're going to close this session.
Oh.
Wait.
I forgot something very important.
Yeah.
.
It's the same exploit for RSTP.
It's the same thing.
And it's the same thing for this device.
The only difference is that you have to put a slip 60 on this one because it boots much slower than the other one.
So, you have to execute your script in the startup system a bit later than usual.
So, put a slip 60, maybe slip 70.
So, you give it time to boot up and get the network interface up.
So, we have another shell because we are a startup.
And what I want to do is clean it.
So...
Just so it's safe.
Okay.
A board session.
And there you go.
.
So, I have one comment.
One comment for the people who are probably as old as me or older.
I hope they get this reference.
20 years ago, you could telnet to a Solari server, type root as password, and roughly 16 characters as password, and the login process would crash and the system would lock you in as root.
.
So, 20 years later, we have pretty much almost the same problem.
Okay?
In the authentication mechanisms.
Okay.
Key takeaways.
What did I do?
That was not intended.
It was meant to be a different animation.
Okay.
So, as you've seen, the setup flow does request the user to change their password.
But it has two back doors.
User, user, and guest, guest.
For your peeping Tom pleasure when you go to show run and try it out.
Seriously.
Okay.
There we go.
Very lame.
Seriously.
This is not brain surgery.
I mean, the only thing very sophisticated, if you will, that we did was, you know, find the command execution method.
Right?
Other than that, passing 200 characters to a password field is really not rocket science.
So, yeah.
Seriously, check your routers, including your AT&T, Verizon, whatnot, what have you, in your homes.
Check them for UPnP.
If it's enabled, disable it.
UPnP is made so users who like the experience of setting up port forwarding on their own don't have to do that because the devices will do it for them.
But you do not want to let your devices do stuff like that on their own.
It's not good.
Because you want to control stuff like port forwarding.
Trust me.
If you don't believe me, please believe me.
At this point, it's very difficult to tell how many devices are affected.
Unfortunately, as I was saying, our legal department prohibited us from trying all of those devices on the Internet.
But we hear from reliable sources that they crash just like all the others.
We wouldn't know for sure, of course.
But that's what we hear.
You can, you know, buy this stuff yourself and try it on your own.
Or if you're brave enough, you can try it on the Internet, on the wild, wild Internet.
So, yeah.
Very important, for other models, it's the same command execution, it's the same exploit, the same methodology.
But you're going to have to go to a different memory address, very likely, in order to get command execution.
Much like this is different from this, the same methodology, different addresses.
So you're going to have to basically redo our steps to get the targets for new devices.
But it should be very, very easily.
I mean, I imagine that the bad guys would be able to do it very easily.
And you guys as well.
Very important takeaway.
So we need security certifications for these devices.
They're not computers.
They're not computers as accessible as laptops or smartphones.
They don't provide first-hand access to the operating system so you can check them.
You have to do just a little bit to spend one or two days to find out what's happening.
And obviously, all the average users can check their phones and laptops.
No one will check their thermostats or doorbells or whatever.
So they will need to find out whether or not that device has some sort of safety feature embedded into it from the store.
And I would like to stress the fact that military-grade encryption is not security.
Anybody agree with me on this one?
Yes?
Yes?
Yes?
I know.
Yeah.
Military-grade encryption, which is the crap that I get from all the people that build stuff.
You know, I ask them, so what do you do about security on this?
And at application level, you know, about injection and stuff like that.
We use military-grade encryption.
AES-256.
Okay.
We need to educate or otherwise stimulate, and this is one of the other purposes of this talk, the vendors to have a proper incident response mechanism.
You're going to ask me, did you contact them?
Of course I did.
I work for a not public company but, you know, somewhat big company.
And, again, our legal department would have my skin alive, you know, if I didn't do that.
So we did contact them repeatedly.
They ignored us.
We actually contacted another company that OEM the firmware and they confirmed it.
So different device altogether but same firmware.
The German company did confirm the vulnerability.
So I was thinking that there's something that we can do to make them more responsible about this.
So we also need to educate the users.
Right?
I don't want to, you know, turn this into a commercial talk.
I'm just going to put it out there.
Either from us or from our competition.
And I hear that some of our competitors are being hacked as we speak on one of those tables.
People will have to get some tools that evaluate the security of their smart house and ideally also defend it.
So many people have no idea how many devices they have in their houses.
Some of them relate to the things that they bought themselves.
But then you have, like, four devices from ADT or Cox.
You have about, you know, four or five other devices from your media streaming service, something that somebody else installed.
And it turns out that usually in America especially people have about seven, eight, even ten more devices than they knew in their house.
And something that does at the very least a vulnerability assessment on all of those, something that all of you can do, all of you will probably do, but none of the other users will do, something like that has to be accessible to everybody.
And people should know about that.
So there are a lot of vulnerabilities discovered in IoT.
So this is why the presentation is called IoT, the gift that keeps on giving.
You can go, if you want to do a talk at a security conference, go to Best Buy or Target, pick like this.
Take it home.
And I promise you that with a little bit of effort in one week at most, you're going to have a paper.
That's how bad the state is.
I promise you that the state of things is with IoT security right now.
Okay?
At this point, it's the low hanging fruit.
If you want to speak at conferences, just one week.
It's all it's going to take.
I promise you.
And I would urge you, for the safety of everybody, to focus on stuff that could be exploited en masse.
Okay?
So not, it's cool to have the stuff in your house, but try to focus on stuff that is accessible from the Internet.
If somebody would have drawn an alarm for the, you know, myriad of telnet services accessible from the Internet,
maybe Mirai would have had a smaller impact.
If somebody would have, you know, raised that alarm back then.
So, yeah.
So, I guess that's it.
I hope you enjoyed it.
And at this point, thank you.
Thank you.