If you’ve answered as many spam calls as I have, you probably hear the warranty scam robocall in your sleep: “We’ve been trying to reach you about your car’s extended warranty.” That particular robocalling operation is about to run out of quarters, as the FCC has announced a nearly $300 million fine levied against that particular operation. The scammers had a list of 500 million phone numbers, and made over five billion calls in three months. Multiple laws were violated, including some really scummy behavior like spoofing employer caller ID, to try to convince people to pick up the call.

Now, that record-setting fine probably isn’t ever going to get paid. The group of companies on the hook for the amount don’t really exist in a meaningful way. The individuals behind the scams are Roy Cox and Aaron Jones, who have already been fined significant amounts and been banned from making telemarketing calls. Neither of those measures put an end to the problem, but going after Avid Telecom, the company that was providing telephone service, did finally put the scheme down.

Mastodon Data Scooped

There are some gotchas to Mastodon. Direct Messages aren’t end-to-end encrypted, your posts are publicly viewable, and if your server operator gets raided by law enforcement, your data gets caught up in the seizure.

The background here is the administrator of the server in question had an unrelated legal issue, and was raided by FBI agents while working on an issue with the Mastodon instance. As a result, when agents seized electronics as evidence, a database backup of the instance was grabbed too. While Mastodon posts are obviously public by design, there is some non-public data to be lost. IP addresses aren’t exactly out of reach of law enforcement, it’s still a bit of personal information that many of us like to avoid publishing. Then there’s hashed passwords. While it’s better than plaintext passwords, having your password hash out there just waiting to be brute-forced is a bit disheartening. But the one that really hurts is that Mastodon doesn’t have end-to-end encryption for private messages.

Citrix Under Seige

Citrix is back in the news, this time for an RCE in the Netscaler and Gateway server appliances. CVE-2023-3519 was first used as a 0-day back in June, and patched on July 18th. The RCE saw widespread use within a couple days, and there are at least 640 compromised systems in the wild. If you have one of these Citrix systems, and didn’t have it patched by July 20th, just go ahead and assume it to be compromised.

ARM’s Memory Tagging Extensions

Google’s Project Zero has gotten their hands on some pre-production hardware that implements ARM Memory Tagging Extensions. This bit of security magic maintains some metadata for each memory allocation, and memory accesses use the top four bits of the pointer value as a key to that memory. If the pointer key doesn’t match the metadata, it’s probably an illicit access, and the program can be terminated with a segfault.

The three-part review of that technology starts with the question of speculative side channels. Does MTE block Spectre, and can you use something like Spectre to trivially defeat it? The answer to both questions seems to be a no. There is an interesting side effect of using segfaults to enforce memory safety: if an attack can rewrite the segfault handler code, it neuters the MTE protection.

Part two looks at how difficult MTE actually makes it for exploits. The answer is… it depends. In the case of an exploit in a browser’s renderer, if a Spectre-ish side channel can be used to detect the keys before launching exploit code, MTE will likely be rather easy to bypass. Without a side channel, it becomes much harder, particularly if MTE is running in synchronous mode, where the fault is raised immediately upon the unauthorized memory access. Something like exploiting the phone from an incoming text message? Very difficult to impossible.

Part three looks at the implementation in the Linux kernel, and the special cases and problems presented. One of the biggest is that there are parts of the kernel where managing pointer tags is just impossible, so there’s a known master key that always works. And that’s not to mention all the Direct Memory Access from other hardware bits, and other issues. All in all, it’s an interesting overview of the promise and limitations of ARM’s MTE solution.

Microsoft Security Negligence?

Just this Wednesday [Amit Yoran], CEO of Tenable, published an open letter lambasting Microsoft for their continuing security problems. The basis of this complaint isn’t the staggering fact that over 42% of all 0-day vulnerabilities in the last 8 years were in Microsoft products. It’s the unusually long fix times, and continual lack of transparency.

The proverbial last straw in this case is a flaw a Tenable researcher found in Azure — a proxy bypass that allowed unauthenticated access to Azure function hosts. That bypass was as easy as running a custom connector, and doing a hostname lookup in that connector’s code. Once discovered, a properly formatted HTTP request to that host would result in all sorts of information, including OAuth client IDs and secrets. What really pushed Tenable over the edge was that Microsoft took longer than 90 days to roll out a partial fix, which only applied to new applications. It took til this week to actually fix the issue in entirety, not coincidentally one day after this open letter was published.

There is a very odd detail about this story. According to Tenable’s disclosure timeline, on July 21, over three months after disclosure, Microsoft informed Tenable that a complete fix would take until September 28 to roll out. Tenable published their scathing letter on August 2nd, and the fix was in place the very next day, far ahead of the late-September projection. This is the sort of behavior that led Tenable to use terms like gross irresponsibility and negligence.

Mikrotik Foisted

The Mikrotik RouterOS firmware has an issue, CVE-2023-30799, that allows an admin user to escape into the underlying system and install a root shell. It was first pulled off in the virtual machine version of RouterOS, and requires admin credentials, so didn’t garner much interest. The folks at VulnCheck took another look at this issue, and think it might warrant a bit more concern.

It turns out that the old install defaults for RouterOS was admin and a blank password. And until more recent versions, that blank password didn’t trigger a forced password reset. And a failed login attempt with a valid user returns a slightly different response than a failed attempt with an invalid user. So enumerating the publicly available RouterOS devices using the default admin username is pretty straightforward. RouterOS also has no brute force protections on the web or API interfaces. That makes for about 5,500 online devices that are potentially susceptible to brute-force and credential stuffing attacks.

Bits and Bytes

Why no SVGs? You may notice that many websites avoid using SVGs, and you might wonder why, since SVGs are great for high quality details, animation, and more. One problem is that the SVG file format is Turing complete, and can contain scripts and other shenanigans. [Teetje Stark] has the lowdown, including how to use SVGs securely, and what fun SVG tricks you lose in the process.

Have a Canon printer connected to your WiFi? When you get ready to pass it on, don’t forget to factory reset it, so you don’t accidentally give away your Wireless password. But it turns out that’s not enough, as the password may survive a full reset. The full dance includes resetting your network settings, turning WiFi back on, and resetting your network settings a second time, just to be sure. Sheesh.

It used to be that one sure way to recognize spam and phishing emails was to look for the typos and bad grammar. Well thankfully, we have machine learning now, writing perfect spam emails every time. Email is increasingly turning into AIs writing emails to other AIs, trying to get to us. What a time to be alive.

And finally, the FBI has concluded an investigation into why a government contractor purchased NSO tools only a few days after the President put NSO on a do-not-buy list. The culprit, it turns out, was the FBI, who was using the tool via a contractor. The FBI has further concluded that there was no wrongdoing by the FBI. Thank goodness.