[Eaton Zveare] purchased a Jacuzzi hot tub, and splurged for the SmartTub add-on, which connects the whirlpool to the internet so you can control temperature, lights, etc from afar. He didn’t realize he was about to discover a nightmare of security problems. Because as we all know, in IoT, the S stands for security. In this case, the registration email came from smarttub.io, so it was natural to pull up that URL in a web browser to see what was there. The page presented a login prompt, so [Eaton] punched in the credentials he had just generated. “Unauthorized” Well that’s not surprising, but what was very odd was the flash of a dashboard that appeared just before the authorization complaint. Could that have been real data that was unintentionally sent? A screen recorder answered that question, revealing that there was indeed a table loaded up with valid-looking data.
Digging around in the page’s JavaScript comes up with the login flow. The page uses the Auth0 service to handle logins, and that service sends back an access token. The page sends that access token right back to the Auth0 service to get user privileges. If the logged in user isn’t an admin, the redirect happens. However, we already know that some real data gets loaded. It appears that the limitations to data is all implemented on the client side, and the backend only requires a valid access token for data requests. What would happen if the response from Auth0 were modified? There are a few approaches to accomplish this, but he opted to use Fiddler. Rewrite the response so the front-end believes you’re an admin, and you’re in.
This approach seems to gain admin access to all of the SmartTub admin controls, though [Eaton] didn’t try actually making changes to see if he had write access, too. This was enough to demonstrate the flaw, and making changes would be flirting with that dangerous line that separates research from computer crime. The real problem started when he tried to disclose the vulnerability. SmartTub didn’t have a security contact, but an email to their support email address did elicit a reply asking for details. And after details were supplied, complete radio silence. Exasperated, he finally turned to Auth0, asking them to intervene. Their solution was to pull the plug on one of the two URL endpoints. Finally, after six months of trying to inform Jacuzzi and SmartTub of their severe security issues, both admin portals were secured.
Jogging Away from Security
There are two layers of fail in this story about the Strava exercise app. Strava lets its users track their running, cycling, and hiking. Due to privacy concerns, there’s an option to hide the user’s location, but it turns out that a clever use of the heatmap and segment functions can defeat that protection. Upload runs from a fake user, and the app helpfully compares your run to other users in the area, hidden or not. That list of users would allow a dedicated investigator to map out where individuals have spent their time. The emphasis of this research was on tracking military members, which revealed some predictably interesting results.
And that’s the second security fail. The Israeli military allow their soldiers, even special forces members, to use an app that is phoning home with GPS locations. Even if there were no easily-exploitable security weakness in the app, it’s still a terrible operation security problem. The research was disclosed to Strava, who removed the fake user used in research. It’s unclear if the app makers actually addressed the problem in a real way. The Israeli military states that they are rolling out procedures to try to prevent this sort of data leakage in the future.
OpenSSL AVX512 Bug
There’s a bug in OpenSSL 3.0.4, and may be a particularly nasty one, but it only occurs on CPUs with the AVX512 extensions. The problem is triggered in ossl_rsaz_mod_exp_avx512_x2(), which makes a call off to bn_reduce_once_in_place(). The call includes the value factor_size, which is supposed to be the number of words to process, but the old code was instead sending the bit size. This worked most of the time, but in certain cases, resulted in a heap buffer overflow. The spooky part of this is that it can be triggered by a TLS handshake, and other potentially attacker-controlled inputs. The only thing lacking to call this a 10.0 CVSS CVE is an actual demonstration of exploitation. As it is, it’s easy to demonstrate a crash. A 3.0.5 release will be made soon, containing the fix, but it’s unclear when that will happen. Most distros seem to be delaying shipping the 3.0.4 release, waiting for the fix for this potentially serious issue.
FreeBSD BadBeacon
I’ve taken the liberty of choosing the obvious name for this vulnerability, BadBeacon. Discovered by [m00nbsd], it’s a simple heap overflow, but this one gives the attacker control over exactly how many bytes to write, and the contents of those bytes. It’s a problem in FreeBSD’s handling of WiFi Beacon frames. A frame is essentially a WiFi packet, and a Beacon is the packet that announces the details of a WiFi network. There are many possible fields in a beacon, and many of those require dedicated code-paths to process them.
One such field is the Mesh ID value. It contains a length and value, and the FreeBSD kernel takes those as the inputs for a memcpy() call into a fixed-size buffer. The way data is laid out in the containing struct, overflowing this buffer also overwrites another data structure, which ends in a data pointer and length value. That data pointer is then used as the target location of another memcpy() call. It’s a “Write-What-Where” primitive, AKA an easy technique to write nearly arbitrary data anywhere.
The direction they chose to take next was to set up a kernel backdoor in unused memory segment, then hook that code into part of the frame processing code. It works as a one-way kernel backdoor. Their Proof-of-Concept code simply prints a message to the kernel log, but would be fairly easily weaponized. FreeBSD patched the flaw in April. It’s unclear when or if pfSense has released an update with the fix, though it’s likely it has happened, and just didn’t advertise the CVE fixed, CVE-2022-23088.
The Linux Syslogk Rootkit
There’s a particularly stealthy kernel rootkit, Syslogk, lurking in the wild. The version of the rootkit that researchers at Avast examined seemed to be targeted at Centos 6 and similar era kernels. It goes to great lengths to disappear, hiding its files, and even erasing itself from the list of loaded kernel modules. There is a hidden feature, writing a 1 to /proc/syslogk, that turns off the stealth features. So if you have an older server that may have been compromised, try poking that location to see if anything happens.
iOS Infection Via The DCP
If you can’t crack the security of the main processor, maybe you can go through a co-processor backdoor? That’s exactly what a fake Vodaphone app does on the iPhone. The Display Co-Processor (DCP) is a new section of the M1 SoC, and this malicious app uses it in one of its bundled exploits. The write-up is detailed and in-depth, as is usually the case with Google Project Zero posts. Rather than dig into the details, I’ll just leave you with [Hector Martin]’s thoughts on it, as probably the foremost expert on the M1 chip outside a handful of Apple engineers:
Ha, a DCP-based exploit that jumps from userspace to DCP and back to the kernel. Cute.
Remember what I said about M1 coprocessors not being able to pwn the system? That's assuming your driver doesn't implement "sudo pwn the system" like Apple's does
.https://t.co/3uNVBVrD4F
— Hector Martin (@marcan42) June 24, 2022
0 Commentaires