Wyze had a three year old flaw, VMWare warns of Log4Shell exploits, and Apple patches more
zero days!
All that coming up now on ThreatWire.
Greetings!!
I’m Shannon Morse and this is ThreatWire for April 5 2022 - this is your summary of
the threats to our security, privacy and Internet freedom.
I listen to your story requests, especially from Patreon alliance members, and this story
was requested by several of you.
Let’s talk about Wyze cameras.
Wyze cameras have often been a budget choice amongst folks looking for reliable security
cameras for home use, and to their credit, Wyze also released a hack firmware that allows
you to turn these cameras into a webcam.
That’s neat, but a lot of folks are turning away from Wyze now due to the super delayed
disclosure of a vulnerability in their cameras that was around for three years that could
allow an attacker with remote access to see videos and image files stored on the camera’s
local SD card memory.
A fix is available as of January 2022, but let’s break this down.
The issues were first discovered by researchers at Bitdefender in March of 2019.
They found and reported three different issues to Wyze at the time, two of which now have
CVE’s.
All three have now been patched.
The first of these is CVE-2019-9564, fixed in September of 2019, about 6 months after
the original disclosure.
This was an authentication bypass flaw.
Bitdefender discovered that the Wyze cam authenticates remote users via a multi step process where
the client sends a command with a specific ID of 0x2710, the camera generates a random
value and encrypts it using an ENR, sends that resulting key to the client, the client
then decrypts the value, sends a response, and the two devices create an authenticated
connection.
They could skip that set of steps by daisy chaining a stack buffer overflow leading to
RCE, which was the second CVE.
The second is CVE-2019-12266, which is a remote execution vulnerability.
This one was finally fixed in November of 2020 - that’s 21 months after being reported.
Bitdefender found that the camera doesn’t check the destination buffer to make sure
it’s long enough before it copies the contents to it’s stack, which results in the RCE.
The third issue wasn’t fixed til January of 2022, nearly three years after it was first
disclosed.
This one in particular allows for a remote attacker to look at the SD card files via
port 80 with no authentication required.
This is due to how the Wyze camera interacts with a newly inserted SD card.
It creates a symbolic link in a WWW directory, which has a webserver presence but it has
no restricted access.
The SD cards contain all of your media files from the camera - be that audio, video, and
photo, along with the camera’s unique ID and AES encryption key.
According to Bitdefender, which clarified some of the reporting and gave this quote
to the Verge, quote: “The remote [...] attacks requires an initial camera ID (it’s completely
random and non-predictable string) that can only be acquired if present on the same network
as [the] device.
In other words, if someone connects to your home WiFi, they can get that token and, at
a later moment, use any of the other working remote exploits to hack your device from their
home or wherever else in the world they are.”
However you feel about the fact that this last vulnerability would be harder to exploit
should an attacker not have some kind of network access already so they could get that camera
ID, the fact that Wyze nor Bitdefender never disclosed this vulnerability over the course
of three years that this could be exploited is a pretty big concern.
Even though Bitdefender is not the manufacturer, usually researchers have some kind of stipulation
in their findings that says if the company doesn’t fix and or publicly disclose the
vulnerability in X amount of time, the researcher will publicly post their findings, and this
usually spurs the manufacturer to finally release a patch or update that fixes the problem.
That’s the vulnerability disclosure and reporting process.
The problem we see with many smart home devices like Wyze is that home users will set it up
once then never check for updates ever again, and the same could even be said for networking
devices like routers.
Many manufacturers do not offer auto updates, or if they do, it’s opt in, so you have
to do the work to get updates set up.
In this case, these updates are now available to patch the vulnerabilities via Wyze’s
official download portal, but they are only available for Wyze Cam V2 and V3, not V1,
which reached End of Life in 2020, and was discontinued in January of 2022 which ironically
is also when they patched this last vuln.
That means anyone running the V1 Wyze Cam, which released in 2017, will remain vulnerable.
The only way to fix this issue is to buy new cameras entirely if you own a V1 Wyze Cam.
Bitdefender recommends for anyone who owns V2 or V3 Wyze Cams to update the firmware
immediately.
You can also set up smart home products like cameras on a separate isolated network.
Side note: I’m actually working on posting a video on my own channel about how to do
this.
An advanced persistent threat group called Deep Panda (aka KungFu Kittens, Bronze Firestone,
or Shell Crew) out of China is actively exploiting the Log4Shell issue in VMWare Horizon to deploy
backdoors, install rootkits, and steal data.
Yeah, remember Log4Shell over the holidays?
It ain’t over!
Deep Panda has been active since 2010, and is considered one of the more advanced nation
state groups.
They’ve targeted legal firms to steal data along with technology firms to build C&C infrastructure.
Their newest attribution is due to the fact they’re using similar rootkits to previous
attacks.
Another group called Winnti is also noted due to using similar exploits as well.
Researchers at Fortinet’s FortiGuard Labs explained that this attack has been observed
across multiple countries and a variety of sectors including financial, academic, cosmetics,
and travel industries.
The group uses the Log4j RCE flaw to deploy backdoors called Milestone and deploy a rootkit
called Fire Chili which uses stolen game development company certificates so it evades detection
on these vulnerable VMware Horizon servers.
The remote access trojan called Infoadmin, which is based off Ghost RAT code has also
been seen on these infected servers.
Fire Chili is new, though, and since it uses these stolen certs, security systems may not
detect it’s installation on a server, and it checks to make sure safe mode isn’t running.
It looks for the OS version since it doesn’t work on all machines, and it can tamper with
the registry to make sure the registry doesn’t stop malicious processes.
It also hides registry keys and TCP network connections.
This isn’t the only attack seen by researchers as of late.
Sophos also reported on the log4j vulnerability being used to install cryptominer bots, along
with initial access brokers on these VMWare Horizon servers.
The cryptominers include z0Miner, Jin, and Mimu.
The backdoor includes Sliver, which is a legitimate red teaming tool but they believe it’s being
used as a payload before the cryptominers are installed.
Another RCE exists in VMWare called Spring4Shell, which has been patched.
This is tracked as CVE 2022-22965 with a 9.8 severity score and could allow an attacker
to execute arbitrary code or take control of an infected system.
This problem exists in the Spring Core java framework.
It’s bad because this framework exists on tons of platforms and a proof of concept was
leaked on Github before a security update was available.
In the case of VMWare, this affects versions of the Tanzu Application Service for VMs,
the Operations Manager, and the TKGI with a full list available via VMWare’s advisory
I’ve linked with this story.
Of course, for all of these issues, patching for the main vulnerabilities to combat the
exploits is recommended.
The problem with Log4Shell is this problem exists in so many platforms it may be hard
for organizations to find and remediate the issue on all of their platforms, especially
if some of those platforms are third party or open source.
Big shoutout to my Hush Puppy perk level patrons for sharing their fur baby photos and for
the support.
THANK YOU to Robert B and Julian O for joining the alliance on Patreon.com/threatwire.
Let’s finish out today’s episode with my last top story, about Apple.
Apple had some active zero day flaws that it believes were being used in the wild, and
patches are now available.
Two vulnerabilities were discovered by an anonymous source and fixed by Apple.
The first of these is CVE-2022-22675 which is an out of bounds write vulnerability that
exists in an audio and video decoding component.
This is called Apple AVD and it would allow for arbitrary code execution with kernel privileges
by an attacker.
This was fixed with better bounds checking.
The second was CVE-2022-22674, also an out of bounds issue but this was a read issue
in the Intel Graphics Driver module, and could allow an attack to read kernel memory.
They improved the input validation to fix this problem.
Patching can be done by simply updating to iOS or iPadOS 15.4.1, MacOS Monterey 12.3.1,
tvOS 15.4.1, and watchOS 8.5.1.
This is another great example of why it’s so important to check for updates on mobile
and home devices, given that these two zero day flaws were potentially being actively
exploited already.
And these aren’t the only two issues to be discovered and fixed by Apple in 2022.
In 2021, they fixed over 10 zero day flaws across their devices.
This year, they’ve fixed four total so far.
The first was in January and was a zero day memory corruption flaw in many of their products
which could allow an attacker to execute code with raised privileges.
Another was fixed in February and was a use after free flaw in the Webkit browser engine.
This one was also possibly actively exploited.
Want to see more tech videos from me?
Check out my youtube channel - youtube.com/ShannonMorse for everything from tech reviews to security
tutorials.
And with that, don't forget to like and subscribe to Hak5!
I'm Shannon Morse, I'll see you on the Internet!