Firewall starts treating certain Wyze traffic as a threat

Just want to ask the group or Wyze if the following URL is legit:

http ://wyze-device-alarm-file-ai.s3.us-west-2.amazonaws.com

This URL is being blocked and treated under the category of “Phishing and Other Frauds” in Web Filter, as well as “Suspicious” in Threat Prevention. I am using Untangle firewall.

I don’t notice anything strange in the Wyze app, yet so I don’t know if I should bother whitelisting it.

Thanks!

3 Likes

Hi @orlypalomar. I have edited your post to make that URL un-clickable, just in case. If you want a response from Wyze about this, please submit a support request. :slight_smile:

Keep in mind that this forum is primarily a user to user community. If you don’t get a helpful reply here, please file a Support Request. You can also submit a request from within the Wyze app by going to Account > Help & Feedback > Submit a Log. This method will allow you to send an app log for diagnosis as well as report your issue. (Note that if you are using a beta version of the app, the log will be sent to the dev team rather than Wyze Support and will not generate a support request.)

2 Likes

I noticed the same thing, Didn’t even notice, but my Gmail inbox filled up with 600 messages with that URL… really kind of making me annoyed. Untangle sure doesn’t like this URL.

Can anyone on the Wyze team explain this? I have 6 cams in the house and it’s generating a lot of traffic and reports.

image

I opened up a ticket and here is their response…

Thanks for your question. It is better to be safe than to be sorry. All AWS URL’s are considered safe for whitelisting. Any data streamed for Wyze is heavily encrypted and we use AWS to host our cloud services.

We take our customers’ data safety very seriously. The communication between your mobile device, the Wyze Cam, and the AWS Cloud Server is made via https (Transport Layer Security (TLS)). We used symmetric and asymmetric encryption, hashing and other ways to make sure users’ information cannot be stolen. Each camera has its own secret key and certificate so that we can validate its identity during handshake. The contents are encrypted via AES 128-bit encryption to protect the data. Even if a hacker intercepts the data package, the data cannot be decrypted.

So I guess it’s safe.

But it all seems moot now. I haven’t seen any entry today. The last event was on 2020-03-17 03:02:50 pm (GMT+8). Though, I’m still keeping an eye for it and decide if I should allow it. I wouldn’t want to willy-nilly just let everything-AWS get through.

We’ll see when I cross that bridge.

I got plenty more alerts this morning… well over a 1000+, no joke… Why is it reaching out for a file via HTTP?
request line = GET http ://wyze-device-alarm-file.s3.us-west-2.amazonaws.com/

As I mentioned here:

Hi, folks!

We’re looking into this now but aren’t finding the issues on our end. Could anyone seeing this please send in an app log through Account > Help & Feedback > Send a Log? Please give me the log ticket number so I can get it to the team quickly.

2 Likes

We think that this has something to do with the app or firmware but haven’t been able to isolate it yet. That’s where the logs will come in handy. It doesn’t appear to be a cloud issue but we’re continuing to look into this.

1 Like

Just to point out in case it wasn’t clear… the traffic to that URL isn’t coming from the app. They’re coming from the cameras themselves.

I only received logs of it for around 30 minutes, from 2:34:13PM to 3:02:50PM on March 17, 2020 (GMT+8).

Here is a sample JSON entry from the firewall log. I have replaced the the Cam’s address with <local_Cam_IP> and my public IP with <WAN_IP>. I’ve also obscured the GPS coordinates for purposes of anonymity.

{"reason":"BLOCK_CATEGORY","appName":"web_filter","requestLine":"GET http://wyze-device-alarm-file-ai.s3.us-west-2.amazonaws.com/","sessionEvent":{"entitled":true,"partitionTablePostfix":"_2020_03_17","hostname":"**<local_Cam_IP>**","CServerPort":443,"protocol":6,"protocolName":"TCP","serverLatitude":20.8491,"localAddr":"/<local_Cam_IP>","class":"class com.untangle.uvm.app.SessionEvent","SServerAddr":"/52.218.228.17","serverIntf":1,"remoteAddr":"/52.218.228.17","CClientAddr":"/<local_Cam_IP>","serverCountry":"US","sessionId":103777098312761,"SClientAddr":"/<WAN_IP>","clientCountry":"XL","CClientPort":55249,"policyRuleId":0,"timeStamp":"2020-03-17 15:02:50.326","serverLongitude":-80.7143,"clientIntf":2,"policyId":1,"SClientPort":55249,"bypassed":false,"SServerPort":443,"CServerAddr":"/52.218.228.17","tagsString":""},"partitionTablePostfix":"_2020_03_17","timeStamp":"2020-03-17 15:02:50.528","flagged":true,"blocked":true,"tag":"Web_Filter [8]:","category":"Phishing and Other Frauds","ruleId":57,"class":"class com.untangle.app.web_filter.WebFilterEvent","categoryId":57}

Each <local_Cam_IP> generates its own JSON entry but they’re practically identical… all points to that one URL which was being blocked by the Web Filter.

1 Like

Thanks! You can also send a camera log with the app log and that would be helpful. There’s an option for choosing to send a firmware log. :slight_smile:

I’ll get this log over to the team!

3 Likes

I submitted a log report and referenced this forum page, please keep us updated. I added the Untangle Report for your information.

It would be nice to figure this out so that Untangle isn’t having to generate hundreds of reports and Google having to take in 1000+ messages a day… Don’t need either one to block each other.

I really don’t want to turn off the cameras or allow that traffic unless we’re aware of what it is. Having to work at home for the next month and I’ve got a bunch of university equipment at the house and a previous break-in.

Thanks for looking into this!

I started having this same problem on Monday March 17 as well. I suspected the issue was with Untangle though, and something changing on their end.

I have checked on this with Untangle. Their support team reports the web filter back-end is reporting this URL in this way. Untangle uses Brightcloud for the webfilter tool. (AKA webroot). You can check the status and how they classify URL’s on their website:

Jamie at untangle says this:

  • I checked out this url against the web filter engine. Our web filter uses a 3rd party web classification site called bright cloud (aka webroot). It is showing that this website is classified as “Computer and Internet Info,Phishing and Other Frauds.” *

  • The alert is coming from your untangle under Config > Events > Alerts. Rule 13 and 14. It alerts you every time web filter picks up a phishing site. *

  • If this category is incorrect, please visit URL/IP Lookup | Webroot BrightCloud and enter the URL. There is a field to request a category change which will also open up a ticket with the webroot team. Alternatively, you could disable the alert, but I do not recommend doing so. Adding the site as a pass site would have been our recommendation, however it will not change the cateogry which seems to be the root of the problem.*

I’ve checked the URL myself and I don’t see anywhere that it indicates a bad reputation or phishing. However I have put in a request that this URL no longer be handled in this manner. Perhaps Wyze proper could also take some action on this front. It might provide more weight than my request.

1 Like

UPDATE: It looks like brightcloud has cleared up this designation already. If you are using an Untangle Server you probably also need to do these steps that were provided by Jamie at Untangle support. Three cheers for Untangle on this one!!

"Can you try clearing your web cache? Go into the web filter app, then click the “advanced” tab. From there, you can select “Clear category URL cache.”
*Once you have done this, try to check the site url in the web filter app under the “site lookup” tab."

3 Likes

“So I guess it’s Safe”.

Wrong… it’s not. you notice that is says “http” and NOT “https” any app/service using http in this day and age when https is the standard is a sign of an incompetant developer/company. sorry seems harsh, but them the facts…

But in the firewall logs, “SServerPort” indicates that this request is hitting port 443 on the server side (AWS). Any insights on this?

At any rate, this seems to have been rectified by Untangle/Brighcloud. The URL is now being categorized as “Computer and Internet Info”.

Any update or actual list of known domain names/IP’s we can whitelist?