Wyze cameras use multiple outgoing IP addresses

All 3 of my Wyze cameras seem to us multiple IPs.
My Firewall has flagged some of them as suspect. This might be a security issue.
For instance:
Cam 3 uses: 2 amazonaws.com (seems OK) and 3 IPs (US) 23.82.75.xx, (CAN) 192.99.4.xx and 108.181.63.xx.

Cam Pan uses: 1 amazonaws.com, momentohq.com (?), and BLOCKED (CAN) 192.99.101.72, (US) 108.62.57.xx
Note >10,000 of the blocked IP happen in 24 hours!

Cam 2 uses: 1 amazonaws.com, BLOCKED (US) 38.132.103.114, (CAN) 158.69.252.xx, (US) 147.135.36.xx
Again over 10,000 blocks in 24 hours

Despite the IPs that my firewall blocks the cameras still work fine.

WHY DO THESE CAMERAS USE CO MANY IPS? Some are VirusTotal flagged as bad or known issue IPs.

Are Wyze cameras hacked?

Thank you all that read this.
Can we get some Wyze techs to explain what is going on?

1 Like

I’m not an expert here, but yes, the cameras do use various address for various purposes. Note that if you block one or more of the addresses, for the most part all that accomplishes is to cause the camera to try even harder.

Doesn’t answer the question: Why do they use IP addresses flagged by VirusTotal as being a RISK. My firewall blocks them and the cameras still work fine. As does the app access to the cameras. Seems to be not needed - so why is it done? We need to see the firmware code.

Overzealous firewall.

2 Likes

Nope 38.132.103.114 flagged as Malware by BitDefender, CDRF, CyRadar, G-Data, MalwareURL.

Lazy response to my post BTW. Do some real research please.

I do know this has been talked about a number of times on this forum. Not sure if you took the time to lookup some of the ips, but first if we look at ip 38.132.103.114* looks like its own by M247 Europe. And reading about the company it says it’s:
M247 offers connectivity-driven cloud services to help businesses scale and transform with technology, serving both local and global markets.

Now for sure there could be someone using that services/company to do bad things, which could then cause other services to flag the ip address, but that doesn’t mean Wyze is hacked and in its talking to unauthorized server. And being in the cloud it could just be Wyze is taking to that service/company on different ip address, which is why different ones show up.

Also if see the posting below:

It talks about the same ip address you are posted and they have it posted as:

this is an IoT heartbeat server
not wyze-owned, it’s a part of a network that our tech partner uses to check if your devices are online
it serves no other function but blocking it could cause your device to think that the v3 is offline when you can view video and record events

Also from other postings you can email
security@wyze.com and report it up to them and maybe they will have more detail info.

3 Likes

You’re calling someone lazy but you can’t be bothered to search for the existing discussions on the topic? Why don’t you do some research?

Most connectivity uses AWS these days but they also use some cheap hosting companies (which also often get used by other parties as spam or malware sites, so their entire IP ranges will get flagged as malicious) in order to try and save some money on some functions. You can block those domains/IPs but you may just find it causes even more traffic and impedes some of the features of the cameras.

3 Likes

I did look at past posts UDP Connections Inbound - #5 by Jimbo2 As well as other sources on this issue.

The blocking does not seem to affect functionality of the cameras also confirmed in that past post (Jan 2022).

What I haven’t read is why the cameras use so many IPs. One is AWS, but the other 3 per camera seems a bit excessive. Maybe one for AWS and another for “heartbeat”.

Earlier posts mention Wyze “tech partner”. Who is that and why is the multiple IP setup in the firmware to these sites?

It would be really great if Wyze and/or their Tech Partner can simply state the use an purpose of these multiple IPs.

On a side note I had the Wyze door locks and dumped them because when the gateway after power fail reboot they tried to go to an IP address in China (103.107.1.34 or “Cloud Union (HuBei) Network Technology Co., Ltd”.

Thank you.

All of their stuff including cameras used to use Chinese servers, people freaked out, they moved US users to US servers (at those cheap hosting companies along with AWS). Some of the IPs even used to come back to the Chinese Military (which is likely just because China had their own servers they required Wyze to use or something, being Communist and all).

Any inbound unsolicited UDP should be blocked by default as long as you don’t have uPNP or port triggering enabled. I don’t see anything like that but I’m not logging inbound WAN drops either.

When I don’t have the app open, my OG cams all show a single outbound UDP connection to AWS and nothing else, it bounces between heartbeats and an established connection (assuming it only establishes when it needs to send an “event”). When I open the app and view the camera, a TCP connection to AWS establishes along with several more UDP AWS connections. A UDP connection to prudential insurance (odd, may just be incorrectly registered in ARIN) pops up but never establishes, just stays unreplied, so it is either just a heartbeat or something they forgot to remove from the code.

My Pan v3s with the app closed show two TCP connections to AWS (I’m guessing one for control and one for video). They often show 2 or 3 more TCP connections to AWS that are in TIME_WAIT so just waiting to age out, not sure if they switch servers frequently or if it is attempting to connect to something that doesn’t exist. They also show 3 UDP connections to OVH Hosting (canadian company), Velianet US, and Leaseweb USA, but they all are only heartbeating. When I view that cam in the app, the AWS TCP connections don’t change, but a ton of UDP connections to those same 3 non-AWS IPs fire off. Many of them never connect and disappear but there are a lot that do connect on various UDP ports. Then after a minute or two all the non-AWS UDP connections go away except those original 3 heartbeat ones.

I’m guessing they’re either working on migrating everything to AWS and haven’t finished, or maybe there is just old stuff still left in the code. Or initial authentication still goes through their own servers. Dunno all just guesses.

I haven’t bothered to worry about it as my cams are on an isolated network and none of them are inside my house where someone watching would see anything I care about.

Maybe someone from Wyze can add some more insight.

For my OG, the heartbeats are going to 48.182.52.225:44258 which is the one that is registered to Prudential.

For the Pan v3 the heartbeats are
23.82.72.130:10001 (Leaseweb)
192.99.8.134:10001 (OVH)
207.38.90.8:10001 (Velianet)
When viewing the cam it is those same 3 servers on many different UDP ports for a minute or two then they go back to just the ones above. The same Prudential IP also pops up on a different port for a while and then goes away.

One to a different prudential IP (48.182.52.255) starts heartbeating from my phone too while the app is open (I’m guessing that is a NAT IP since normally that would be a local broadcast address and not valid).

If that post mentioned above is to be believed, it is just some sort of up/down status tracking. Not sure why they’d be leaving that on non-AWS but perhaps it is for interoperability with other Wyze devices that may not use AWS. Also not sure why so many UDP ports would need to be established for a short time on the PAN, but I’ve seen that behavior with many applications with messy code or timeouts set too low etc.

**Edit - I suppose it makes sense. Their products work with Alexa, Google, Apple, etc, and have to interoperate with other products that use those, so there being a 3rd party aggregator that is tracking up/down status of various IOT devices from many brands for that interoperability wouldn’t be surprising. Someone has to coordinate that, every IOT company isn’t going to build a connection to every other IOT company (for logistical and security reasons).

2 Likes

Really great stuff Dave27. Thank you.
I see the same from here - IPs are slightly different so I guess they are not hard coded in the firmware.
I block all unsolicited inbound UDPs too.

My Pan V1 goes to with the App not open: (All port 10001)
192.99.101.72 (Canada - blocked about 10,000 times a day)
148.72.153.115 (US)
108.62.57.36 (US)

Thanks again.

The wyze cameras use many different services to operate. AWS for example is used for recording events I believe, and MomentHQ is a similar cloud caching service for events. You can read up on AWS Kineisis video (if that’s what they still use) and MomentHQ. They have an interesting blog post about working with wyze.

The cameras use P2P technology to establish a connection between your phone and the camera, and some of the servers used for this may be located in other parts of the world.

Wyze works closely with Chinese partners for manufacturing and development, and many times some of the developers may also be Chinese. If you wanted to check if the camera is online, you would ping a service that you know is online, such as google. In other parts of the world they have different services they use, and so the developers choose what is most familiar for them.

Regarding the malicious ips, like others said this is usually due to it being in a data center with shared IPs. If someone rents a virtual server, does something malicious on it, causing that IP to be flagged as malicious, then when that particular hosting provider switches the ip to another server is may still be marked as malicious.

Nowadays it’s hard to rely on IP addresses for identification because VPNs make is super easy to mask your location, and it also causes whatever IP the VPN is using to be flagged and it remains flagged for other users.

If you have any concerns you can contact security@wyze.com, but these IPs you are seeing are not a concern.

Most likely it is using global server load balancing. In theory, it should connect to the closest lowest latency server. Global server load balancing (GSLB) is a technique of distributing Internet traffic across servers located in different locations around the world. GSLB can improve the reliability and performance of web applications by routing the traffic to the nearest or best available server1. GSLB can be implemented on premises, in the cloud, or in a hybrid environment.

Where did you copy and paste that from?

Load balancing is typically for the benefit of the provider, not the end user, you won’t get the best server for you, you’ll get the best one for them. I’m on the east coast and several of my cams are connected to AWS West.

DNS load balancing also relies on proper Geo IP data (and proper implementation) to determine “distance” and that is an ever changing and near impossible task to keep right.

LB has nothing to do with the 3rd party IOT servers though, those remain pretty constant, a few different IPs in the same subnet at the same data center. They are for a totally different purpose than the AWS servers, and are in addition to them, not mixed with them.

So… A bit of fun with the unknown IP port 10001 traffic.
I used TShark to capture a bit of the traffic for the fun of it. UDP so short info.
I thought someone could see what is being sent and received in the traffic and might have some insights.

Here is the data send/received (HEX)
From, To, Data Captured (HEX)
HomeIpAddr 108.181.63.11 51cc000001050c00ffff00008d9a933300000000330fc965
HomeIpAddr 108.181.63.11 51cc000001050c00ffff00008d9a9333000000005c0fc965
HomeIpAddr 147.135.36.161 51cc000001050c00ffff000040ccb64800000000620dc965
HomeIpAddr 147.135.36.161 51cc000001050c00ffff000040ccb648000000008a0dc965
HomeIpAddr 147.135.36.161 51cc000001050c00ffff000040ccb64800000000b20dc965
HomeIpAddr 148.72.153.115 51cc000001050c00ffff0000c2578451000000000d0bc965
HomeIpAddr 148.72.153.115 51cc000001050c00ffff0000c257845100000000e40ac965
HomeIpAddr 158.69.252.241 51cc000001050c00ffff0000ca84677200000000030ec965
HomeIpAddr 158.69.252.241 51cc000001050c00ffff0000ca846772000000002b0ec965
HomeIpAddr 158.69.252.241 51cc000001050c00ffff0000ca84677200000000da0dc965
192.99.101.72 HomeIpAddr 51cc000001051c00ffff00002e3e233302000000bc0ac9650200861886380a7c0000000000000000
23.82.75.184 HomeIpAddr 51cc000001051c00ffff000037edff5c02000000bb0ec96502008daf86380a7c0000000000000000
147.135.36.161 HomeIpAddr 51cc000001051c00ffff000040ccb64802000000620dc9650200c00986380a7c0000000000000000
147.135.36.161 HomeIpAddr 51cc000001051c00ffff000040ccb648020000008a0dc9650200c00986380a7c0000000000000000
147.135.36.161 HomeIpAddr 51cc000001051c00ffff000040ccb64802000000b20dc9650200c00986380a7c0000000000000000
192.99.4.226 HomeIpAddr 51cc000001051c00ffff00005c7d0e41020000000b0fc96502008daf86380a7c0000000000000000
108.181.63.11 HomeIpAddr 51cc000001051c00ffff00008d9a933302000000330fc96502008daf86380a7c0000000000000000
108.181.63.11 HomeIpAddr 51cc000001051c00ffff00008d9a9333020000005c0fc96502008daf86380a7c0000000000000000
148.72.153.115 HomeIpAddr 51cc000001051c00ffff0000c2578451020000000d0bc9650200861886380a7c0000000000000000
148.72.153.115 HomeIpAddr 51cc000001051c00ffff0000c257845102000000e40ac9650200861886380a7c0000000000000000
158.69.252.241 HomeIpAddr 51cc000001051c00ffff0000ca84677202000000030ec9650200c00986380a7c0000000000000000
158.69.252.241 HomeIpAddr 51cc000001051c00ffff0000ca846772020000002b0ec9650200c00986380a7c0000000000000000
158.69.252.241 HomeIpAddr 51cc000001051c00ffff0000ca84677202000000da0dc9650200c00986380a7c0000000000000000
HomeIpAddr 192.99.101.72 51cc000001050c00ffff00002e3e233300000000bc0ac965
HomeIpAddr 192.99.4.226 51cc000001050c00ffff00005c7d0e41000000000b0fc965
HomeIpAddr 23.82.75.184 51cc000001050c00ffff000037edff5c00000000bb0ec965
HomeIpAddr 38.132.103.114 51cc000001050c00ffff00000000000000000000480cc965
HomeIpAddr 38.132.103.114 51cc000001050c00ffff00000000000000000000700cc965

I guess if people are paranoid they can try decoding and figuring out what exactly is being sent, but it has already been established that those servers are used for keeping track of your camera’s online status so the messages are just some sort of heartbeat. Since these are 3rd party IOT aggregators, my guess is they’re probably used for integration with Alexa, Google, etc. If you aren’t using your cameras with any 3rd party services, probably won’t hurt anything to block those communications if you want.

I was just general speaking. Beings you asked, I looked into it. Wyze is using AWS elastic load balancing (ELB.) The API connection that the wyze camera use is api.wyzecam.com if you do a nslookup you will see several IP addresses assigned, They are AWS addresses, all in us-west-2, api.wyzecam.com is an Alias to core-cloud-gateway-lb-prod-1988651058.us-west-2.elb.amazonaws.com. Using AWS Route 53 as the DNS service, it creates the alias and keeps the different IP address in the name record. If you want to try something, in windows CLI, ping api.wyze.com it won’t respond but notice the IP it uses. Close the CLI and open a new one and ping again. Most likely the IP address will be different than the first. This is a crude way that we use to test that its working.

1 Like

Yeah, I do this stuff all day every day, work with AWS a lot. They use DNS LB to direct you to a region, then local load balancing to direct you to specific VMs. The IP returned by DNS is typically a VIP with many servers behind it. My cameras connect to both us-east and us-west so I’m guessing those are the two regions wyze is using. Based on what I’ve seen they’re not directing you to the closest region, just letting AWS load balance (that’s the cheapest solution). The “elastic” part of their load balancing is they’ll automatically spin up more VIPs and compute power as needed, then remove it when not. So depending on the time of day you might see far fewer IPs getting returned when load is lighter.

But the main IPs in question here are not AWS at all, they are 3rd parties doing some fairly simple local load balancing (IPs in the same subnet) only and the purpose appears to just be heartbeats to let various IOT services know up/down status of your cameras.

1 Like

Ya beat me to it. :slight_smile: I was going to suggest using Wireshark to see what was in the packets being sent… :+1:

The world of wireless and wifi… On another note, since we’re talking about connectivity to the internet… It would be great if they added some code to the Wyze app for when your internet goes down. Everything is still on the local network 192.168.x.x but you can not access any of the devices when, imo, you should be able to have local control to at least view your cams and/or change thermostat settings. Anyone agree or have thoughts on that?