When all else fails, blame it on the cloud? It seems like that’s the script for just about every outage that makes the news lately, like the Wyze camera outage this week that kept people from seeing feeds from their cameras for several hours. The outage went so far that some users’ cameras weren’t even showing up in the Wyze app, and there were even reports that some people were seeing thumbnails for cameras they don’t own. That’s troubling, of course, and Wyze seems to have taken action on that quickly by disabling a tab on the app that would potentially have let people tap into camera feeds they had no business seeing. Still, it looks like curiosity got the better of some users, with 1,500 tapping through when notified of motion events and seeing other people walking around inside unknown houses. The problem was resolved quickly, with blame laid on an “AWS partner” even though there were no known AWS issues at the time of the outage. We’ve said it before and we’ll say it again: security cameras, especially mission-critical ones, have no business being connected with anything but Ethernet or coax, and exposing them to the cloud is a really, really bad idea.
Wyze2 Articles
This Week In Security: Wyze, ScreenConnect, And Untrustworthy Job Postings
For a smart home company with an emphasis on cloud-connected cameras, what could possibly be worse than accidentally showing active cameras to the wrong users? Doing it again, to far more users, less than 6 months after the previous incident.
The setup for this breach was an AWS problem, that caused a Wyze system outage last Friday morning. As the system was restored, the load spiked and a caching library took the brunt of the unintentional DDoS. This library apparently has a fail state of serving images and videos to the wrong users. An official report from Wyze mentions that this library had been recently added, and that the number of thumbnails shown to unauthorized users was around 13,000. Eek. There’s a reason we recommend picking one of the Open Source NVR systems here at Hackaday.
ScreenConnect Exploit in the Wild
A pair of vulnerabilities in ConnectWise ScreenConnect were announced this week, Proof of Concepts were released, and are already being used in active exploitation. The vulnerabilities are a CVSS 10.0 authentication bypass and a CVSS 8.4 path traversal bypass.
Huntress has a guide out, detailing how embarrassingly easy the vulnerabilities are to exploit. The authentication bypass is a result of a .Net quirk, that adding an additional directory on the end of a .aspx
URL doesn’t actually change the destination, but is captured as PathInfo. This allows a bypass of the protections against re-running the initial setup wizard: hostname/SetupWizard.aspx/literallyanything
The second vulnerability triggers during extension unpack, as the unzipping process doesn’t prevent path traversal. The most interesting part is that the unzip happens before the extension installation finishes. So an attacker can compromise the box, cancel the install, and leave very little trace of exploitation. Continue reading “This Week In Security: Wyze, ScreenConnect, And Untrustworthy Job Postings”