If you don’t know what happend how do you know your system is secure now?
I have to agree with @aidbish, that the timing of the state-changes doesn’t appear like it was done manually (via GUI at least). Just to verify, can you do all this:
04-07-2018 10:32:21;eetkamerlichtaan;switch.eraamhoek;on
04-07-2018 10:32:21;beamer_on;switch.kelder_ledstrip_power;off
04-07-2018 10:32:21;keukenlichtaan;light.keuken_boven_vitrine;on
04-07-2018 10:32:21;keukenlichtaan;light.keuken_kookplaat;on
04-07-2018 10:32:21;keukenlichtaan;light.bijkeuken;on
04-07-2018 10:32:21;woonkamer_tvaan;switch.tv_woonkamer_power;on
04-07-2018 10:32:21;woonkamerlichtaan;switch.hrozenhoek;on
04-07-2018 10:32:21;eetkamerlichtaan;switch.ewandmeubel;on
04-07-2018 10:32:21;beamer_on;switch.beamer_power;on
in 1 second manually? If not, then it seems more like there’s some automation or script that has done that. Or at least confirms the theory, that this hasn’t been done via the UI.
It could of course be possible, that the attacker just used the API directly with a script. That would make so many events in such a short time possible.
Another thought: could it be an issue with AppDaemon? AD would also be able to do so many things quickly.
@aidbish and @danielperna84 it seems fast but most of that is because a lot of those switches and lights are grouped in automations. with certain delays after each other.
for example:
woonkamerlichtaan;input_boolean.woonkamer_verlichting
is an input boolean that triggers an automation that switches 4 switches.
so this is actually just 1 action:
04-07-2018 10:32:15;woonkamerlichtaan;input_boolean.woonkamer_verlichting;on
04-07-2018 10:32:16;woonkamerlichtaan;switch.hboog;on
04-07-2018 10:32:20;woonkamerlichtaan;switch.hbank;on
04-07-2018 10:32:21;woonkamerlichtaan;switch.hrozenhoek;on
04-07-2018 10:32:22;woonkamerlichtaan;switch.kachel_9_1;on
the actions that are done are:
04-07-2018 10:32:14;kellerlichtaan;input_boolean.keller_lights;on
04-07-2018 10:32:15;woonkamerlichtaan;input_boolean.woonkamer_verlichting;on
04-07-2018 10:32:16;zolderlichtaan;input_boolean.zolder_verlichting;on
04-07-2018 10:32:16;ganglichtaan;input_boolean.gang_verlichting;on
04-07-2018 10:32:17;beamer_on;input_boolean.keller_tv;on
04-07-2018 10:32:17;eetkamerlichtaan;input_boolean.eetkamer_verlichting;on
04-07-2018 10:32:18;woonkamer_tvaan;input_boolean.woonkamer_tv;on
04-07-2018 10:32:18;keukenlichtaan;input_boolean.keuken_verlichting;on
those are all things that are in different groups (on 1 tab), so i suspect that he/she just did put the groups on.
when you are just blindly activating groups on a page it isnt that hard to do that in that time.
no MQTT switches.
and to make it more clear:
this:
04-07-2018 10:32:16;zolderlichtaan;input_boolean.zolder_verlichting;on
04-07-2018 10:32:18;zolderlichtaan;light.mancave_raam_links;on
04-07-2018 10:32:18;zolderlichtaan;light.mancave_wasbak;on
are 2 lights that are grouped and have an input_boolean as mainswitch.
i have them added not that long ago, they are in no automations at all
the lights are limitless led and can only be switched on by HA or the milight app. (which HA wouldnt notice
they are on no dashboard and i havent used them since i implemented them.
@sjee i did a complete close down from my network. HA can now only be reached if someone is inside my house and nows my new password. and because this absolutely must have been a manual action i dont suspect that it is combined with installing some malware somehow.
@danielperna84 in theory it could be done with AD. and the log comes from AD.
but to get to a result like that with my apps, AD would need to get several false state changes over a few seconds with different delays in between.
and because i havent got even 1 false statechange in the 2 years that i use it, i am pretty sure i can rule that out.
You may not know that to turn on all devices are pretty easy then you thought. HA provide a homeassistant.turn_on service, with optional entity_id parameter. That means if you don’t provide entity_id, it will call all entities which support standard turn_on service.
It is too powerful and should be removed IMO, but it probably off topic.
So, if someone/program/script happened to pass a None to this function, “you got hacked”
If I was the hacker, I would like to change your entity’s friendly name to “HA is sucks” (likes the hacker done in another thread) instead of turn your lights on, it is no fun.
if i would have the config editor in my frontend then changing my config would have been easy. (thats another security risk in my eyes, config should never be reachable from the outside)
what if the hacker only knows a way to get passed the password, and then can only do what the HA frontend allows him?
if the others that got hacked had a config editor active, that would explain that. and they did have hassio, so probably they had an editor.
i know about the service, but then way more things would have been turned on.
remember also this: most of the things in my frontend are dutch. and when the hacker isnt he doesnt know what to look for unless he uses a translator.
and dont forget that i interupted him. in the other cases there were also lights turned on and off.
hey,
Just a few ideas: 1) is there some kind of “auth.log” in HA? so you know when some ip succeed (or not) to access HA with a password? 2) should we/developers/somebody build some kind of HA honeypot so we intentionally expose it to the internet to be hacked in the hope we gain some insight on how it’s done?
I have noticed in the past that successful logins are identified but not sure how to pull this info. If you manually start HA and watch all the intial setup message and subsequent actions you will see log-ins pass by. I noticed this on a dev instance that had nothing running on it other than the front end. I have been meaning to set it up again and pull an example.
I’d like to know the login info as well.
There must be somewhere that HA logs the logins or it wouldn’t know to ban an IP after a certain number of bad attempts.
Ironically, I just had 3 failed log in attempts last night in a matter of a few hours. I have no idea if they were eventually successful or not. They might have figured out my password after a couple of attempts but I saw no indications they made it thru. I had no weird light action or anything.
Since I basically have 3 or 4 IP’s max that SHOULD be accessing HA, knowing what IP’s were successful would tell me if they made it in or not…
Really? So you only login with devices which have a fixed IP? Sounds too good to be true…
Founder of Shodan here: we don’t circumvent passwords/ authentication and we never try to login. We routinely get flagged by abuse databases because they classify any web request to their honeypots/ sensors as malicious. And we actually do a lot of crawling for malware which involves pretending we’re infected, see:
All of the HTTP requests you observed are standard URLs and not malicious in nature (the “400 0” responses are from SSL testing where no HTTP request is submitted).
If your web server returned data then those locations weren’t password protected. My guess is that you have a virtual host configuration for your dynamic DNS domain that uses passwords but visiting your IP directly uses the default vhost which isn’t password protected.
6 Likes
Greetings, no, our application server didn’t use vhost at all. Don’t know OP’s reverse proxy config.
I was responding to @ReneTode as his nginx configuration was for the vhost my.duckdns.org but the Shodan crawlers visit the IP directly so those nginx rules don’t apply. Instead, the nginx rules for the default vhost are used which I was guessing weren’t password protected.
1 Like
nginx indeed wasnt password protected.
and i dont think it was something shodan related.
i think the hacker uses shodan to find out addresses to try. (and that fits with the fact that there is a shodan scan seconds before the breach)
but i see that achillean is already greyed out again, so hell probably cant read my reaction anymore.
but if you ever get to read this: no hard feelings or suspection towards shodan from my side.
It takes a bit for Shodan results to go live as our search index isn’t updated in real-time. The crawlers collect the data, pass it through our pipeline/ firehose, our webservices then consume the data/ firehose and push it to the search engine which refreshes it’s information periodically - that process adds a delay of a few minutes.
And I just joined the conversation because there’s a lot of misinformation out there about what we do so I try to correct it when possible. What we do is very technical and unless you’re trained in reading logs it’s not always obvious what’s going on. One of the main things we actually do as a company is help others monitor their public IP space and let them know if anything is open (whether intended or not):
https://help.shodan.io/guides/how-to-monitor-network
Anyways, I think having a password should be ok though ideally you’d put it behind a VPN or use a whitelist as others have already mentioned.
2 Likes
the password wasnt in nginx istselve but in the HA website where nginx was only the proxy server.
so it wasnt open.
I already have a VPN for the moment, so it isnt a problem for the moment.
I guess it was just a coinsidence then that there was a shodan scan 1 minute before there was a breach.
i just looked up the IP and it was mentioned as malicious 1800 times in the last six months. i didnt know it was a shodan IP untill another mentioned that.
if i would have recoqnized it i probably only would have mentioned the scan and not provided the log info. 
if i look up an address or click on 1 of the links from shodan, there is just a lookup in your DBs?
there is no way to create a direct scan from your site?
the reason i ask is because in all hacking topics here on the forum there is talked about how easy it is to find people who use HA on shodan, and i see a lot of indications that there is someone “hacking” who might be active on the forum.
that combined with a scan from shodan just 1 minute before the actual hack, gives me the feeling that the scan wasnt a coinsidence. (off course coinsidences always happen when you dont expect and want them)
so can you confirm to me that the scan was just a general scan that is done on regular bases and that happened to be just by coinsidence at that moment?
Yes, that activity was done as part of the regular 24/7 activity from the crawler. We use different crawlers for our user-initiated scans and they tend to do a lot more than just check for a single service.
FYI: Shodan works a bit differently than a typical network scan, the following loop runs 24/7:
- Generate a random IP
- Generate a random port
- Check the IP:port
- Goto 1
3 Likes
hmm, oke thanks. at least it takes out some part of my suspisions (gets me even more in the dark, but better suspect nothing then the wrong thing)
ill probably never will find out what really happened, but no harm was done and i am even more on alert then i was before, so thats not bad.
thanks for making things clear.
still didnt ask for my information to be available for everyone cause you own a website…
It only displays information anyone could get. I think a “thank you” for providing a service that might help you find a hole before a cracker does would be more in order.
7 Likes
I think what @toast is refering to is that the information is not being used to warn a user but published for everybody to see.
If someone would do the same with home security, checkout if doors are locked, windows are closed, alarmsystem is activated and publishes on a webiste a list of homes, adresses and which doors are unlocked without even warning the owner I don’t think a lot of people will say “thank you” for providing this service.
1 Like