So you may have gotten a Slack password reset prompt. Something like half a percent of Slack’s userbase had their password hash potentially exposed due to an odd bug. When sending shared invitation links, the password hash was sent to other members of the workspace. It’s a bit hard to work out how this exact problem happened, as password hashes shouldn’t ever be sent to users like this. My guess is that other users got a state update packet when the link was created, and a logic error in the code resulted in too much state information being sent.

The evidence suggests that the first person to catch the bug was a researcher who disclosed the problem mid-July. Slack seems to use a sane password policy, only storing hashed, salted passwords. That may sound like a breakfast recipe, but just means that when you type your password in to log in to slack, the password goes through a one-way cryptographic hash, and the results of the hash are stored. Salting is the addition of extra data, to make a precomputation attack impractical. Slack stated that even if this bug was used to capture these hashes, they cannot be used to directly authenticate as an affected user. The normal advice about turning on 2-factor authentication still applies, as an extra guard against misuse of leaked information.

Et Tu Twilio

Not to be outdone, Twilio just disclosed an ongoing problem, but this one was an active social engineering attack. It started as a targeted phishing campaign against Twilio employees, and as employees fell for the fake login page, the attackers used the captured credentials to access internal tools and access end-user data. Of particular note is that these phishing attempts were successful because they were targeted at known Twilio employees, using the correct phone numbers, and included names or usernames. It’s reported that other companies, namely Cloudflare and Cicso, are experiencing similar attacks. It’s possible there was a breach in a shared provider, that enabled the targeted fishing.

More From The CPU Vulnerability Nightmares Front

Leading the charge is Intel’s ÆPIC Leak, a new sort of processor bug. This isn’t a speculative execution bug — we’re not tricking the CPU into acting on memory that will be rolled back. This is more like reading from uninitialized memory, and finding another process’s secrets there. That’s actually the exact sort of bug the researchers were looking for, as they intentionally filled buffers and caches with a known pattern, and then attempted to read from nonsensical memory locations looking for those patterns. If a memory read returned their canary data, then something interesting was afoot.

This was exactly what happened when reading from I/O addresses assigned to the Advanced Programmable Interrupt Controller (APIC). Certain bytes inside the APIC range are reserved, and trying to read them invokes undefined behavior. On many CPU models, this means a system hang and/or full CPU crash. On some processors, the read worked, but because the APIC doesn’t actually send data on these addresses, stale cache contents are returned. This is a very interesting result, but note that actually pulling off the attack requires root-level access to the system. That makes it basically meaningless, as the kernel can already read arbitrary memory, right?

There is an important exception to the rule of Kernel-sees-all. Intel’s SGX enclave technology is specifically designed to protect regions of memory from even the kernel. In practice this means DRM keys and SGX protected virtual machines. DRM key leakage is not a threat *to* the end user, so isn’t something to worry about. And the collection of people that run SGX protected VMs is likely quite small.

SQUIP

AMD isn’t missing out on the fun, making SQUIP public this week (whitepaper). It’s a new side-channel that derives process state from the scheduler queue. Simultaneous MultiThreading (SMT) is the technique used by modern processors to feed two threads of instructions into a single processing core. Because different instructions use different components of the CPU, SMT results in higher throughput than traditional one-thread-per-core arrangements. One downside is that the activity of one thread can have an impact on the performance of the other. For instance, for doing live audio processing, one of the recommendation was to disable SMT to avoid data underruns. For the security minded, there’s an obvious side-effect, that one process can learn a bit of information about what its sibling thread is doing on the CPU core. There have been a handful of methods to detect and take advantage of this effect, and what SQUIP brings is a new method to spy on the sibling thread.

In AMD Zen processors, there are multiple Arithmetic Logic Units (ALUs) per CPU core, but only one of those units can do multiplication, division, and Cyclic Redundancy Check (CRC) operations. SQUIP queues up many multiplication operations requests in a row, and then issues an rdpru instruction, Read Processor Register. It’s specifically looking for the value of the Actual Performance Frequency Clock Counter (APERF). There’s a quirky behavior here that is the key to the attack. There are separate queues for each of the ALUs, as well as the master queue for the core. The master queue pushes instructions into the individual sub-queues, but if the next target queue is full, the master queue stalls until the next instruction can be sent to the correct component. In effect, if the ALU1 queue is full+1, the rdpru call is delayed. Once that instruction makes it to the end of the primary CPU queue, it can immediately execute on one of the other ALUs. This, in essence, allows an underpriviledged process to spy on how many multiplication instructions are being performed by its sibling process, even if that sibling happens to be in a different VM, for instance.

So we can determine multiplication instructions. What exactly does that get us? The example the researchers reached for was RSA’s square-and-multiply, where each bit of the secret key will trigger either two or three multiplications, depending on the value of that given bit. By using the SQUIP technique over many runs (more than 50,000), it’s possible to infer the value of the secret key. It’s a brilliant bit of work, but probably of limited real-world use. This is AMD’s take, at least, as their guidance is to use best-practice coding techniques to mitigate this issue.

Microsoft Office and Symbols

It’s another of those “hath hell frozen over?” moments, as Microsoft announces the release of debugging symbols for Microsoft Office. What exactly are debugging symbols you ask? Maybe think of them as a roadmap to what’s in a binary file. When a program crashes, debugging symbols tell you what function was being executed when the crash happened, and maybe even the name of the variable that was the culprit. Now while this isn’t as much information as a full source release, it really does bring a lot of transparency to what is happening inside a given program. Imagine what a Ghidra decompile of Office might turn up. And that’s sort of the point. Microsoft wants researchers to find exploitable bugs and report them. On top of that, third-parties make plugins and integrations for Office, and better debugging makes both jobs easier.

VMWare

[Steven Seeley] of Source Incite found a collection of VMWare vulnerabilties back in May, and when they are put together, they make for an impressive RCE to root vulnerability chain. First off is a quirk that’s probably a feature. When an admin creates a dashboard link in the vRealize Manager application, a token embedded in that link allows anyone to access the dashboard without a valid account. While it’s essentially read-only access, there’s a second issue, where an API call to create a new user bypasses the normal authentication checks.

That next problem happens to be sensitive information that winds up in the logs, and that the system allows log access to an underprivileged user, or no user at all, in this case! The log line in question contains a Basic authorization string. Basic auth is just Password and ID run through a Base64 encoding. As demonstrated in this attack chain, it’s really not a good idea to use. Regardless, this allows a password reset for the admin user, getting an attacker admin access to the system. admin can go enable the SSH port, and log in. So an attacker has admin and SSH, but that’s still not root.

Up next is a sudo rule that allows any user to run a specific Python script with sudo — meaning that script runs as root. That script looks to an environment variable to find its binaries, and that variable is trivial to set. Set the variable so the script running as root will run a script you wrote, and you can do anything, like giving your account full sudo rights. The full exploit chain is called DashOverride, and patches are available for the three vulnerabilities in play. Well done [Steven] for the find.

SELinux

If you play in RedHat land, you’re probably familiar with SELinux, if only as the pesky thing that you turn off to make software work. Many of us sysadmins that work on RHEL and its clones are used to temporarily disabling it as a first troubleshooting step. Well, [esp0x31] would like you to reconsider that habit, making the case that SELinux can be a useful tool for system hardening. The post describes how you can set up a file context for a given program, and then strictly limit its access to only files with that context. Should this application be able to talk over UDP? If not, add a rule that prevents any UDP socket creation. A killer tip is the newrole command, which puts you into the SELinux domain you just defined — perfect for bashing on your new rules looking for a loophole.

Bits and Bytes

The Point-to-Point Protocol in Windows has a flaw, CVE-2022-30133, where sending traffic to port 1723 can result in arbitrary code execution. The scary bit about this one is that it’s potentially wormable, and that the port might be intentionally exposed to the internet, as this was an early VPN solution in Windows. Yoiks.

X-as-a-Service is one of the hottest ways to monetize, and the criminal element has jumped onboard. We’ve had ransomware-as-a-service, and now there’s command&control-as-a-Service. Is directing the hoard of machines in your botnet just too much trouble? For a low monthly fee, these guys will do it for you, and it comes with a slick looking dashboard and everything. We truly live in modern times.

Rsync has a flaw, where a malicious server can write arbitrary files on a connecting client. This could also be leveraged in the form of a man-in-the-middle attack. Look for a release of 3.2.5 in the coming days, which will contain the fix.

5.4 million Twitter accounts had their private data scraped and sold, thanks to a zero-day in Twitter’s web code. The sensitive bit was the email or phone number used to verify the account. For most of us it would just be an annoyance for that to escape. Just another make it another couple spammers’ lists. There are a handful of Twitter accounts that are run anonymously for good reason, and this sort of leak could be quite a problem, if it allowed bad actors to connect the dots. Thanks to [app-le-bees] for pointing this one out in our Discord!