hacking attempt
-
Need help understanding how the following happened. I am definitely not an expert. I have been using pfSense for years without any issues. The following hacking attempt happened to my HomeAssistant server from an IP address in Singapore, and I am trying to figure out how they goth through my firewall default deny WAN rule. I have no ports open or forwarded at all. Here is report from my server:
Logger: homeassistant.components.http.ban
Source: components/http/ban.py:138
Integration: HTTP (documentation, issues)
First occurred: 6:19:26 AM (1 occurrence)
Last logged: 6:19:26 AM
Login attempt or request with invalid authentication from 104.28.222.47 (104.28.222.47). Requested URL: '/api/config'. (Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.4 Safari/605.1.15) -
would love any insights or comments you might have…
seems the would be attacker was using a MacIntosh… I am on Windows.
could it be my HASS server is compromised and advertising its location to the outside ? or would it be my windows machine which I use to log-in to the HASS server ? or something else ?
-
@njaimo If you have no wan rules nor nats then I very much doubt it came in that way. More likely that you have an internal device that's infected with something. No amount of wan rules will stop an infected device on your lan that reaches out to a c&c server and lets them attack you via that established connection.
Edit: That wouldn't explain the external IP address. Are you sure you have no wan rules, no nats, and upn isn't enabled?
-
@KOM MANY thanks for the note. I really have no WAN rules, just the default deny, no open ports or NAT, and UPnP is disabled. not sure I follow you on your saying "that wouldn't explain the external IP"...
-
@njaimo If the homeassistant itself has been infected and has connected externally to a c&c server, that would explain the singapore ip address. if it was another device on your network, the attacking ip would come from that device. Check pfsense's state table to see if there is a live connection to that external address. Filter based on your homeassistant ip and see what comes up.
-
@KOM Thanks again ! I've looked at the States Table, and below is what I found.
all HomeAssistant server (HASS) states:
10.121.1.60 -> 3.216.7.170 Amazon Technologies Inc. USA
10.121.1.60 -> 40.160.72.112 OVH US LLC
10.121.1.60 -> 52.203.190.4 Amazon Technologies Inc. USAstates on my windows machine for IPs starting with 104 (like the IP source for the hacking attempt, which was also Cloudflare in Singapore)
10.121.1.100 -> 104.20.29.151 CloudFlare Inc. in the USA
10.121.1.100 -> 104.26.4.238 CloudFlare Inc. in the USAIt looks like the state to Singapore was somehow terminated by itself?
-
should have said that my HASS has Nabu Casa subscription so I can access it from anywhere, which may justify at least one of the states...
-
@njaimo said in hacking attempt:
Oh geez, that should have been your first suspect. A remote access service for your home assistant. Someone is likely scanning the urls the service uses to let you access your instance.
-
@KOM good point. the Nabu Casa service is run by the Home Assistant creators, I figured it would be safe...
-
...still, the hacker should not have been able to get in from the outside, right ? or do you think they have actually hacked Nabu Casa and are using my credentials to reach my HASS server ?
-
@njaimo From Claude:
"Why guessing doesn't work but discovery does. The subdomain is a long random hex string, so brute-forcing the namespace is hopeless, and you can't find instances by port-scanning either, since nothing is listening on your IP — everything terminates on Nabu Casa's proxy and routes by SNI. But Home Assistant requests a Let's Encrypt certificate for your remote-access hostname automatically, and every publicly trusted certificate issued since 2018 lands in an append-only Certificate Transparency log. So the FQDN is published the moment the cert is issued. A crt.sh query for ui.nabu.casa returns the list. Nabu Casa actually points at this same mechanism as a feature — they recommend auditing CT logs to confirm nobody else has obtained a certificate for your remote URL — but transparency cuts both ways: the log that lets you audit your own cert also enumerates everyone else's hostname. A custom domain doesn't help, since that cert gets logged too.
What discovery actually gets an attacker. The login page, and that's it. Nabu Casa is upfront about this: with Cloud enabled your instance is exposed to the wider internet, and while the login page has been audited by security professionals, password brute-forcing remains possible with enough time. Their two recommendations are a strong generated password and two-factor authentication on every account. There's no end-run around the auth layer from knowing the hostname — the tunnel is end-to-end encrypted and the private key never leaves your box, to the point that Nabu Casa can't restore access for you if you lose it."
-
@KOM Thanks for this. I have changed my password to something quite stronger now that it seems it can be accessed form the outside, and will implement MFA as well. ...also considering "deleting" access via Nabu Casa's service and using Tailscale or similar to access when am away...
Thank you again for the tips !
-
Mmm, using VPN seems like a better solution if that other thing proxies connections both ways.
-
@stephenw10 Thanks for the note. I figure Tailscale establishes a VPN connection ?... or do you suggest I use a custom OpenVPN tunnel ?
-
got a very interesting comment from the folks at the HASS Forum, where I also posted my issue. I thought it would be an AWESOME idea. Here it is:
***They were unsuccessful.
(this time)…
On the 25th anniversary of a physical terrorist attack that was successful, are you reacting appropriately from a digital one?
We’re talking helicopter gunships, missiles, bunker busting MOABs, ground troops, etc.
Why not?
Time to change the mindset.
The age of passive resistance should end. You invoking my defence shield trigger gives me the unassailable right to respond with all methods available.
An HACS addon, triggered by possible attack should invoke a small DDOS response. This would (rolled out globally) force the hosters to seriously reconsider their positions of allowing digital terrorists (call them for what they are - not skript kiddies) to piggyback on their infrastructure. Make it hurt for them in their wallets. Automated reports to their support areas, traffic increases, something that causes them to reconsider.
This is not a political call to arms. This is an individual being forced to respond to anonymous terrorist attacks on an ongoing basis saying enough is enough. Time to fight back.
Forget reactive - time to get proactive. Send out the offensive and see what happens. Change the world order.
Don’t be annoyed. Be angry.
Why is the war on digital terrorism so one sided? Should it be? Could it be changed?***
-
@njaimo Bizarre. Home Assistant seems ot have some sort of fail2ban equivalent that you should enable. Set ip_ban_enabled: true and a low login_attempts_threshold in your http: config.
-
@KOM Thanks for that, was not aware but will do. Cheers
-
@njaimo Yeah tailscale/wireguard would also work fine.
I just find it odd that a proxy service like that would allow an attacker to even try to open a connection to your box. I expect a user to login to the remote front end before it allows anything over the link back to your home box. Thus any sort of attack would be against the proxy not your device. But I guess this is not that.
-
@njaimo Wireguard is a very good and easy to setup VPN. That's what I use for remote access to Home Assistant. With Nabu Casa basically forwarding to port 8123 - not only do you need a strong password but you're hoping there's no latent vulnerability in the app running on 8123 - so just a single level of defense. On top of wiregaurd you can enable Captive Portal and get three levels of defense.
-
@stephenw10 said in hacking attempt:
I expect a user to login to the remote front end before it allows anything over the link back to your home box.
Not really how those are setup. They would have to know your password the proxy entry point for that. Or you would have to have 2 passwords - one for the proxy service, and then also your password for your service.
They work by device on your end just opening a connection to the proxy, and then anything that hits a specific url is sent to your device.
You would hope such a service would block known bad actors - that IP is for sure a known bad guy
https://www.abuseipdb.com/check/104.28.222.47
Such services are really no better than just opening up a port - The only protection is the the strength of your authentication. And with most users this is minimal - their draw is ease of setup because no portforward or open ports on your end are required, so they work behind a cgnat, etc.
If you can setup a vpn this would be better option because now there would be 2 different authentications required - one to the vpn, which should be say cert based, so pretty impossible to brute. And then also your normal authentication to your service.
Privacy Policy · Cookie Policy