I really, really appreciate and grateful for being here.
So thank you a lot for DEF CON, for DEF CON Heritage Village,
SentinelOne, and everyone that supported me along the way.
We'll speak about it also soon. Let's start with the title.
So, Hacking Smart Devices for Fun and Profit.
This is a true and genuine story about me trying from exploiting my smart home
into gaining control over thousands of smart devices in the entire world.
So, let's start.
So, first about me. My name is Barak Sternberg.
I also live in DEF in Twitter, so make sure to follow.
I'm a security researcher and also an author in SentinelOne Labs.
I have a master's in computer science on algorithms.
And one of the favorite things I love to mention is that I'm also a party lover and a DJ.
So, you can make sure you follow my Mixcloud to see my set and stuff.
But besides following our party, which is not so relevant in the corona period,
I love to focus on vulnerability research.
I love computer security. I'm an enthusiast about network security,
IoT, embedded devices, Linux, web apps, and more and more.
And also to analyzing malwares in the wild.
I'm a CTF player and I love a good game of hacking any kind of devices.
So, with this in mind, let's start.
So, starting this project goes quite well, well, way back.
And when I say way back, I mean really back, 2010.
What happened in 2010?
So, first, we are renovating our family home.
We are fixing all this home.
The second most important thing was the Walking Dead first season was just coming up.
The first season, just to keep in mind, today it's the 10th season already, I think,
of the Walking Dead.
And it's kept counting.
Amazing series.
Much watched.
Must watch one.
And, well, we installed smart home devices, which were the Philips Dynalite.
And the Philips Dynalite have software and apps, but they were really, really expensive.
Back then, it was really high extras.
And we didn't buy it.
Just the technician came, installed the softwares and apps to itself,
to configure all of our devices, all of our smart home systems.
And from there on, we didn't have anything to control it.
So, you can say it's a smart home device, but not quite, really.
And so, we don't have any remote app control.
And usually, in these scenarios, we can think about ourselves as, well,
our own technicians that can do it by ourselves, right?
So, why not do it ourselves?
So, this scary diagram is not that scary.
What you see here is actually the Philips Dynalite controllers
that control my smart home devices in my parents' home.
These actually have been the controllers themselves.
So, as you can see here, this one is the full electricity diagram
downloaded freely from the Philips site.
And the interesting thing you can observe here is that, well,
each controller controls something.
Controller-specific maybe lights have specific capabilities and attributes.
So, this electricity diagram have on this side the channels,
which are directly connected usually to the relays,
to the dimmers, to the buttons, to anything.
For example, this channel, channel one,
have powered out electricity to your lights,
your light bulb, or maybe to a window,
or maybe to a large light system, or anything else.
So, this is on these sides, and this is the relay,
the switch on and off stuff.
And on the other side, they are connected, as you can see here,
the microprocessor. This is the microprocessor.
And this microprocessor is very cool
because it's the thing that connects between the electricity circuits here
and the serial, which is here.
So, on its other end, there is a serial output,
you can obviously understand it might be the controlling area.
So, when I connect to these devices to configure them,
I usually use this serial interface.
And this uses something that's called Dynet protocol
of the Dynalite Philips systems.
And it's really cool.
It's connected by RS-485, which is really, it's not that unique,
in the sense that many industrial systems
are actually using this kind of type of serials
compared to the usual serial RS-2322.
And also, what you can understand is that this serial
is connected to this building block, which is, what is that?
So, this is, I bought actually an IP serial adapter.
And this is a cool serial adapter that is used to connect
all up between the serial and the IP.
And I am sitting here gently and trying to wait
for something to happen, right?
Sending commands maybe, seeing something, I don't know.
So, what happened next is that I tried to send codes
to these controllers.
I'm sending codes to these controllers and nothing happened.
Nothing.
I use this wonderful GitHub repo, which is not complete.
It has some several API documentations of Dynet-01,
but it's not exactly the Dynet I needed.
It's really weird.
And also, the packets.
So, I could have observed the type of the packets used
to be sent to Dynet.
The packets usually are in the structure of sync number,
an area code, a command type, and some extra data
to navigate between the different possibilities.
For example, I want the light to be in 100%
or 50% percentage of light.
So, I can put this stuff in the extra data area,
which is right here.
So, this is a packet used to be sent over a serial connection,
as I've seen before, as we have seen before.
And this is really cool.
So, I start sending packets, nothing happens.
And I remember me and my father sitting in the saloon,
and like, why not send in all the packets?
And when I mean all the packets, let's just send,
let's just fuzz the system, right?
What could happen, right?
Sending all opcodes to the controllers could be
an amazing thing to do, no?
Really, all.
Like, in four, I exchange 256.
And it wasn't a surprise that, yeah,
maybe you laugh right now, but it's actually a real thing.
It's a house that people live in that went crazy.
So, we send all of these commands,
and all of a sudden, I remember myself sitting in the kitchen,
and all the lights are flipping crazy,
windows turning on and off at the same time,
and we don't know what is happening.
And, well, try to remember which command you're sending,
this fuzzing loop that tried to fuzz all these commands.
So, I did try to fix it to my responsibility, of course.
And I tried to fix it.
And I tried to reverse these commands.
And some of them have been fixed.
But remember, these commands,
not just for turning on and off the lights,
it also controls the configuration,
the main configuration of the lights,
and the buttons, and everything you can think about.
So, this is insane.
And, well, I tried to fix it.
And, yeah, and all of a sudden, 6 a.m.,
I got this message from my mom sending me that,
well, I hope you guys have fun the other day,
because I woke up 6 a.m.
because all the lights were turning on at the same time.
At this point, we've come to a small conclusion that,
well, the first one is that Barak is not touching, again,
the smartphone devices.
We'll see about that later.
But the second one is that, well,
we need to install new smartphone devices,
because until we do that,
we don't actually have lights, and powers,
and electricity for some things.
So, yeah, okay, new smartphone devices.
And I was excited, because for me,
it's another research to do.
They didn't know that yet,
but for me, it's a whole nother research.
Okay, so let's continue.
So, the new smartphone devices is the HDL automation devices.
And by HDL automation devices,
I actually mean a company which is called HDL Automation.
And this company is a big company, an amazing one, actually.
I must say to them, thank you,
because they helped me a lot through the disclosure,
and working with them,
and they really consider the security highly in this manner and respect.
And also, they have more than 10,000 projects around the globe,
museums, buildings, hotels,
and headquarters of some high priority companies,
and stuff like that, using their systems.
So, even airports, if I didn't say that.
So, it's really, really interesting to investigate these controllers, right?
And they have smart controllers for lights, windows, cameras,
a sensor, anything, anything you even didn't think about it.
Cool.
So, we learned about the HDL automation,
and we've installed in our family home the HDL smart home devices.
Let's now see how the HDL smart home works.
Sorry.
So, the HDL smart home system have three basic components.
The first component is the HDL demo relay modules.
This is the modules which you can observe just right here.
These modules have on the one direction outside the serial,
exactly kind of the same serial you've seen in the Philips Dynalite systems,
with RS-485 connections, which they call BusPro, of course,
because, for example, this BusPro is the complete analogy of the Dynet.
So, this is like the protocols upside on the upper side of the serial connection.
Cool. And this is connected to the IP gateway.
And the IP gateway is actually kind of the same as I built an IP gateway
to adapt between the serial and the IP connection,
from the serial to the internet, to the entire world.
So, they have their own smart devices.
They have their own unique IP adapter as well.
Also, Philips have it, but it was really, really expensive.
This is why I didn't bought it also in the second time.
But in our scenario, my parents thought, okay, it's a good idea.
Let's buy all the things.
And Barack doesn't even have an idea to start and jiggering with this kind of things.
Oh, boy, they were wrong.
And this IP gateway is serial to IP.
And the third bullet was the HDL cloud servers.
The HDL cloud servers are actually used mainly for remote connections,
but not just remote connections.
They're used to store the configuration for the smart home devices.
They're used to connect remotely to things because you have routers, you have firewall.
So, this IP gateway is connected to this HDL cloud servers.
And then when you are online on the internet, you can connect to their HDL cloud servers
with public IP interface so you can reach your devices as well.
And now a little bit deeper about how they install it.
So, first time installation is quite easy and it works like this.
You install the HDL bus for software as a technician.
So, for example, I'm a technician. I'm coming to your home.
I'm installing the HDL bus for software on my desktop machine.
And I connect directly with my PC, my technician PC, to this IP gateway.
It's very cool.
And when I'm connected to this IP gateway with my HDL bus,
I'm starting to configure all these devices.
Because remember, these devices are connected serially to this IP gateway.
So, I connect to this IP gateway and configure all these ones.
And that's what I said. I configure the bus for adapter and I have a configuration.
Now that I have a configuration, I can use this data, this configuration data,
to upload it, for example, to the cloud and save it also on my Android app in other apps as well.
So, what I do next is register a new account in the HDL on application.
This is an Android application of HDL automation.
It's used to control remotely and also locally within the Wi-Fi, these smart home devices.
And when, as a technician, I register this new account,
I also upload the local configuration to the app itself.
So now, remember, I have a phone in my hand.
I register the new account in this application.
And I upload the configuration from this IP gateway or from my laptop,
from the BusPro desktop software to this phone.
I upload the configuration to my phone.
Now the configuration to control everything in my smart home devices is inside my phone.
So, for my phone, I can also connect to the internet.
And this is exactly how I backup my configuration in the cloud.
So, after I have the configuration in my phone, I upload it also to the cloud.
And now it's also kept here.
Cool.
So, what happens when a new user comes in and joins to our game
and wants also to enter these devices and control them?
So, what happens next is that the first time you download the HGLON app.
Why does that?
Because you need to log into the HGL account that has been opened to him
directly in order to control all these dimmers and other devices.
So, we download this HGLON app and you log into the HGL account
that has been opened by the technician.
And what he does next, you can actually bet on that, that...
Well, yes, he download the configuration from the cloud.
And when he download the configuration from the cloud,
he have all the configuration to fully control these devices over here
within the Wi-Fi or from remote.
So, I'm a bit cheating here because there are two possibilities to operate these devices.
And we'll talk about it in the next slide, which is the remote and the local mode.
So, we can operate this HGL system in a remote and local connection.
And the difference between them is that the local connection is accessible from Wi-Fi.
Usually only from Wi-Fi and local networks.
And the remote is accessible from the wide internet and from anywhere inside the world.
And usually, it makes a real sense that we want to make a remote control connection about it.
Well, we want to be able to...
For example, I have an air conditioner and I want to control this air conditioner before I get on
because it's really, really hot today and it's a summer.
So, I would love it to be operated before I get back home, right?
And this is really a cool thing.
And at first time installation, the technician actually choose whether
to enable and allow remote connections or not.
And usually, many times, because of the reasons I mentioned, the remote connection is enabled.
And this is really interesting.
Remember that in any scenario, we are using the HGL cloud service.
Because in the first scenario of the Wi-Fi local connection,
we still backup our configuration for new users to come.
And on the remote connection mode, of course, we use this cloud service to connect back to us.
So, the third point, the third bullet is always used.
The HGL cloud servers are amazing, super interesting.
Yeah, Internet of Things.
Now, let's add Wi-Fi to all the things and let's see what happens.
Cool.
So, the focus of my research.
Yes, we can research one and two.
But first, my family will kill me again if I will destroy all their smartphone devices
using the connection to the one and two bullets.
And the second reason and the most relevant one, because I love your family,
but it's not that exciting and relevant.
The most relevancy is the hardware.
The hardware and the software can be really device dependent.
And it will take a lot of time to investigate and research any specific device.
Because each device has its own capabilities, own serial connection, own things.
And to reach the point you can really research and find vulnerabilities,
takes much more time and much more time from other things,
which are publicly known as cloud servers or websites.
So, of course, I thought that the Azure cloud server,
which are a critical bottleneck in these connections,
are really, really an interesting and a great idea to investigate.
And also, when you think about a seesaw, a seesaw view or a view of some people that
works for the network security and the integrity of the network,
you might think that what you need to defend might be, not always,
is from the outside, from arbitrary outside, and from the inside, from specific devices.
But in this scenario, this cloud server might be okay, might be whitelisted, fully whitelisted,
because this cloud server is just connecting to these devices,
just connected to your devices, to your certified devices you put in your systems.
But you need to understand, even as someone that works for security,
that the bottleneck can be also outside your organization.
And also, in the third bullet, in servers that you don't even have the code for them,
and you don't even know what they're actually kind of doing.
So this is really interesting in the point of focus as well.
But we speak about focus a lot. Let's now speak about the cloud server.
So a starting point for this is the HGLON app, how it works, the HGLON app.
So first is the login screen, yeah, nice login screen.
You can see a simple login here, and a sign-up button also,
and the forgot password mechanism, which is really cool.
And also interesting, forgot password actually is working the same as you think.
It sends you a reset link to your email, and you can click on this link,
and immediately go to this link.
But the URL in the forgot password was really, really interesting.
And we'll speak about it later.
Sign-up. Sign-up includes... you can enter either phone or an email,
and you can also add the password. Well, you should add the password.
And then you have all your things enabled.
And after that, you can upload from the app the configuration you have.
Remember this IP gateway, where I configure all this stuff,
so I can upload the configuration from this IP adapter to my phone.
And from there on, I can upload this to the cloud.
And I can also download cloud configurations using this app
to configure my system, my application,
to control these devices in my Wi-Fi network and stuff.
So this is the sign-up.
Well, enough chitchat. Let's talk about vulnerabilities.
So the first vulnerability, really cool.
Account takeover number one, or let's forget our password together.
So let's forget our password.
I click on the forgot password, and I got this following link.
Well, this seems like a nice, naive link that doesn't going to affect anyone, right?
Well, the main thing you can see here and observe, I'll make sure you understand that.
Well, there are a couple of parameters, really, really interesting.
The first one is the time.
Time seems like just the time in some format.
An email, which is actually my email.
The email that I want to reset the password now for.
And this parameter and these kind of parameters as well.
And this is really, really interesting,
because you can think that maybe something random should be placed there, right?
Something random that I couldn't fake this kind of link.
You could also think that if I change this email to any arbitrary email,
it won't work, right?
It will be verified in some manner,
and they won't let me change the password for any arbitrary user.
Come on.
Well, they did.
They actually did let me change any user password by its email to any user.
The way to exploit it,
for example, if I'm thinking hacker-wise,
is to do forget password to my email account,
get this link, okay,
and change only the email, the email area, to the victim emails.
And from there on, I get fully authorization to change its password.
This link needs to change the password of this user.
I can fully change his password.
Really cool.
And it works.
Perfect.
So, let's do it again.
So, account takeover number two.
Or maybe let's forget our password again.
And how can we do it?
So, let's forget now about the users I already showed you,
about the users and the forgetting the passwords again.
And now let's focus about other thing that's called the technician user.
The technician user is the user that is automatically generated
when the user register with its email.
So, when the user first time register with an email,
for example, a technician, install the system,
and register your HDL account,
what he's doing is actually also opens up automatically a technician user
with the same password as the username, as the original user.
For example, I open register with this email at mymail.com.
It is automatically also open a technician user at email-debug at mymail.com.
And this is really interesting now,
because the technician user is able to change settings
and control all system configuration of the smart home devices as well.
And this can be really bad, right, if we can hack this technician user.
We can also change the cloud configuration.
We can also do many, many more things.
In these times, I usually ask the crowd if they know how to hack this system.
I guess some of you actually understand where I'm going to,
and it's actually really working.
So to exploit and to take over any technician user,
what we need to do is to find the victim email,
let's say victim at mymail.com,
and open a new email at this mymail.com service at victim-debug at mymail.com.
So I open this new email account, and I have it.
And yes, what I will do next is just forget my password.
I click on forget password for this victim-debug at mymail.com.
And when I do reset password to this account,
I will be sending... they will send to me their email of link reset,
the reset of the password.
So I actually can change the victim-debug at mymail.com password.
So I actually can get access to all the technician features.
I can access the technician user.
Just to conclude, and to make sure everyone is with me,
what I'm doing is I'm opening another account for the technician email
at victim-debug at mymail.com.
And I call the reset password for this email.
And this is really cool, and it's working.
And the reason it's working is because they don't verify this email is not a valid email,
and they shouldn't send a forget password to this technician users at all,
or even find another way to put users for the technician,
which is not relevant with this dash-debug.
Yes, it's really worked, and it made me to take over any account of, well, technician accounts.
Very cool.
It's working for some providers, not all of them.
I feel in the sense that some of them replacing dash with another,
so it can probably be bypassed even in mails that doesn't allow dash in their username,
but I need to think about it even more.
Cool.
So now we spoke about the pre-authentication vulnerabilities.
Let's see what is happening post-authentication.
So let's get our devices and start investigating some several API endpoints.
And I actually encountered many API endpoints which are open,
and some of them were the device by region list.
And the device by region list is a very interesting API endpoint.
It comes right after the login.
You log in, and you have a device list,
and you can actually search this device list by the region name,
the region ID, by device ID, by anything you want.
So it's really cool.
And how you do it, you go to the device section,
and the parameters to control is the region ID, device ID, device name.
So all of these guys are fully controllable and very, very interesting.
So the first try I did was sending this.
This was in the post data body of the message I've been sending.
And this data was containing the parameters need to be searched for.
And as you can observe quite well, there is the SQL injection I tried to put.
And, well, yes, it did return to me all the devices in the system.
But remember, to find out if there is an SQL injection in the site or not,
it's not enough just to test for this kind of screen and to see that I get all the data.
I need to do a little bit more than that.
And to see that it actually does an SQL statement I fully control of, black box wise.
Cool.
And so the second try was something like this.
And it actually worked again.
And I got all the devices.
So it's not...
And also I tried to make an invalid SQL statement.
And what I got is that I get a response, an error response,
specifically on invalid SQL statements.
So, yes, I have an SQL injection.
Very, very cool.
I get in all the data.
All the data not in the DB.
All the data I have on my devices.
So there is some way to gain control and to get all the data of the HDL database.
So why not extract more data, right?
Well, problems.
Some of the problems is that the return columns and specifically the ASP parser.
So the server, as far as I tell you, it's the HDL cloud servers.
They have ASP server inside of them.
Windows server.
And this ASP parser checks the validity of the return columns.
So, for example, if I do a union SQL injection, I need to verify and validate that all my data
return is correctly to the manner of the ASP parser.
And if it's not, I wouldn't be able to pass and get my data.
I just get in an error.
Error response.
Nothing happens.
And, well, yes, you might think to yourself, well, let's do blind SQL injection, right?
Let's do, like, SQL timed SQL injection, something like that.
But it's not that easy.
Because I am bounded in this scenario by not sending so much data.
Well, first thing is that I didn't want to alert the system.
I didn't want to bomb the system.
I didn't want to stress the system or to do anything like that, in a sense.
And, well, and the second thing is that even if I do I will do it, it can take a lot of
time.
Because I have more than 11 columns returning from the SQL injection, from this SQL query,
not the injection, from the SQL query, more than 11 columns.
Which means almost 4 million queries were required to inspect all the relevant types
and values.
Remember, the ASP parser also checks for the validity even of the ranges of some of the
values returned.
Yes.
And also it's worth mentioning that, well, I didn't use VPN.
And it's a really good reason not to, like, jiggle with the site and try to brute force,
like, arbitrary sites.
So, yeah, not a good idea.
Don't try it at all.
And so this is the blind SQL injection idea.
As I told you, even timed or parser error, yes or no, will take a lot of time.
Cool.
But let's forget about this SQL injection.
Let's think about another way to bypass the ASP parser.
You all must agree with me that if I find another SQL injection that returns much, much
less columns, I could go over all the possibilities with this union SQL injection or something
and finding out the relevant order to make it work and to return all the data and bypass
the ASP parser.
So this is exactly what I was going for.
So to bypass the ASP parser, I was going to the... you remember the device name.
This is the original parameter for the SQL injection.
I tried to find this device name, the exact name, the exact argument in another API endpoint.
And I actually did find it.
I find it in the get room binding device.
There is the device name parameter.
There is an SQL injection there.
You go to the room section, you search by the device binding name, and voila, you have
an SQL injection.
Very cool.
SQL injection in the same argument.
And the most amazing thing here is that only four columns are being returned.
Only four columns.
That's all.
And it's really amazing.
We can do the permutation over all these options with the possibility to do all of it really,
really in short amount of queries.
So permutating over columns order and trying the correct way to make it was doing like
this.
So here you can see the union SQL injection, and here you can see and observe the parameters
I've been put.
And I just scrambled and permuted this one any time and tried to see if it works.
And I also increased the number of columns because I didn't really know the number of
columns.
But I knew it was around four.
I say only four.
I'm sorry.
It's like it was really around four because I seen that the number of columns was four
in the data, but it could be maybe one more for the ID or the key saved in the SQL.
But it was eventually four.
So it doesn't really interesting.
And I found that this is working.
And to conclude all of this, it was quite amazing to see that I'm getting all the database
with one single query, one single SQL injection to rule them all, bypassing the ASP parser
and getting all the database, all the things as well.
Cool.
So at this point, of course, I reached the HGL automation company.
I did fully coordinated disclosure with them, worked with them silently and helped them
a lot.
And they also helped me.
They were really enthusiastic about helping and securing the system.
So it was great for them.
But let's now speak about how we can hack into any arbitrary HGL user.
For example, you have your own, I don't know,
HGL account in your smart home in Dubai.
Or you have your own smart home in some airport.
Because there are airports and museums in HGL.
So you can actually find a scenario of how you can fully control any HGL account.
What we found, the vulnerabilities we have is two SQL injections and two account takeovers.
And there are two scenarios to gain full takeover over any user.
The first scenario, you know the attackers, you know the victim's email.
You know the victim's email.
And you just get from the database the hashed, salted password.
And you now brute force this password.
And when you brute force this password, you can get after some time the password, of course.
And the second option is to do one of the takeovers I've mentioned.
Actually, the second one, the technician one, is much more silently.
When you do account takeover over the technician account,
usually the normal accounts use the normal people,
the older people that use normal people in the sense of using the system.
They use the normal accounts.
And they don't use the technician account.
Only for configuration and when something gets wrong.
So you can connect and take over only the technician account.
And it will work silently and no one will know.
The second scenario is where you can control any arbitrary HDL user without an email.
And now we can do it.
For example, you know the company name.
You know the phone name of the victim.
You know its full name, in a sense, or something like that.
So you can scrape through the HDL database and find its account, find its email.
And then go back to the first scenario and hack its user by any of these possibilities.
Okay, really, really cool.
So we can hack any HDL user in the entire world.
Let's now go through the security implications to conclude what I've been talking about.
So let's start with the easygoing security implications.
Not to frighten all the people so much.
So the first security implications are the private data leaks, of course.
Hash passwords, emails, phone numbers, company names, names in general.
Tremendous amount of data.
And also the HDL cloud backup configuration is there, which gives us the following.
The full smart devices info.
And the full smart devices info is amazing.
What you see here, what you can observe here, is exactly from the app.
You can see that this app can control cameras, TVs, security sensors in other manners,
and air conditioners also in the server rooms as well.
Internal network IPs can be exposed using these systems as well, firmware versions.
Internal network IPs are because they are written inside of the configuration, some of them.
And you can actually use some of them to observe and see where are the HDL devices,
IPs, and some of them kind of in the sense.
And very cool.
And also the remote control.
So you can actually, again, of course, remote control over these things.
And you can adjust, well, as I said before, the air conditioner in the server room.
You can make it up to 50 Celsius.
I don't think they actually support it, but 35, something like that for a week,
would probably destroy the server room, I guess.
And also to watch their IP cameras.
So it can be really, really bad.
Disable some sensors.
Now, I'm sorry for that in advance.
This is kind of a pure evil, pure evil ideas.
But we need to discuss them because we need to understand and realize that the security
implications, even if I don't have a full RCE over any kind of device,
there are tremendous and high impact and costly impacts over the organizations as well
that can be done.
And the first one is, well, you can add internal non-exposed IP address.
Sometimes they are hiding the gateways that control other systems.
For example, hidden security areas, hidden secure rooms and stuff like that.
You can actually expose them because there is an auto search functionality in the app.
Another thing you can do is you can encrypt all the configurations, remove all the configurations
from the AGL app.
And some people can do kind of a ransomware and blackmail the companies.
And until they won't do it, you won't give them back their possibility to control their
system, to control their lights, to control their powers, their RCEs.
This can really shut down a company in the logistics, in the industry manner.
Logistics manner a lot.
Another thing is to use a conditional to affect critical locations.
And also something I really love, which is called an hidden trigger attack.
What is a hidden trigger attack?
So let's, for example, say that we are not in the Wi-Fi.
We are not in a local connection.
OK, you are smart guys.
You block all the remote connections.
You keep only the local connections.
But remember, the configuration is still on the AGL cloud servers.
So when the user will update, and it will update its configuration sometimes, you can
actually connect the button, for example, switch on the lights to the button that's
also switch and adjust the air conditioner to 35 degrees, 35 Celsius degrees.
So you can connect two buttons, for example, to the same button.
So the user just opens up the light.
But he actually did a lot of other stuff as well.
Disabled sensors and did a lot of other things.
And for this attack, you don't even need the remote mode connection.
Even in the local mode, it can really affect the users in the organization.
Because the configuration is still on the AGL cloud backup database.
The AGL cloud servers are really affecting the organization as a bottleneck.
Also, another thing you can do, you can disable and control other critical sensors.
You can disable security cameras.
You can disable sensors for overheating, security alerts, and also you name it.
Well, this is another idea.
This is not a direct security issue.
But this is another idea I had in mind, which is exploiting the internal network.
For example, I can change a cloud configuration file to a malicious one.
Maybe something that does something on the device.
Maybe I can exploit the device when they update the configuration file on the device.
It can be really interesting.
It can be ideas for further research and stuff like that.
So this is really cool.
And it increased the attack surface to the internal network and to the organization as well.
Cool.
So we are coming to conclusion.
And some of the ideas to continue is, of course, to find a way from the account takeover
to getting into the internal network of the organization.
Can it be done?
How it can be done?
Taking over the device.
Taking over something like something else.
Maybe taking advantage of the way they control the smart home devices in the network.
I don't know.
You name it.
And another thing is to access from the LAN and the Wi-Fi access.
For example, I have already Wi-Fi and LAN access.
To find an RC over one of the smart devices platform.
Specifically, of course, the IP adapter.
The IP serial adapter of the HDL gateway devices, which is really cool also.
And yes, so many amazing ideas can be done.
It can be amazing.
I had so much fun working for this project.
And I come really to conclusion.
I want to thank anyone, starting from the HDL automation company, for fast fix and
coordinated disclosure of all the vulnerabilities.
HDL automation, you are really great.
And I love working with you guys.
The second thing is that I wanted to really thank Ofer Peleg, which is the HDL Israel
representative, for supporting me along the way and helping me fixing this.
He was also an amazing guy.
And well, of course, thank you to my family for letting me break in their house.
But only one time.
Only one time.
Hopefully not on the second time, but we'll see about that.
And of course, and of course, I'm really thankful for Sentinel One.
Sentinel One, thank you for sponsoring and supporting my research.
Thank you so much.
And well, I think this is it.
We are coming to reach to a live questions and answers.
So if you want to, if you have any questions about my lecture, or if you want to read my
full blog.
So first, I wanted to know that my full blog and my full research will be published right
now as we speak in the Sentinel Labs blog.
So make sure you follow Sentinel Labs and go to the Sentinel Labs website in Sentinel
One.
And there is my full research with a lot of other code sections and stuff like this.
And from now on, I will go to the questions and answers in the Discord channel in DEF CON for
more questions and answers.
And I'll be happy to answer any questions you have in mind.
And thank you all for listening.
Thank you all for coming here.
And I hope to see you soon in DEF CON in another, even non-Corona events.
We can see face to face also.
So thank you very much.