Depending on who you ask, the big news this week is that quantum computing researchers out of China have broken RSA. (Here’s the PDF of their paper.) And that’s true… sort of. There are multiple caveats, like the fact that this proof of concept is only factoring a 22-bit key. The minimum RSA size in use these days is 1024 bits. The other important note is that this wasn’t done on a general purpose quantum computer, but on a D-Wave quantum annealing machine.

First off, what is the difference between a general purpose and annealing quantum computer? Practically speaking, a quantum annealer can’t run Shor’s algorithm, the quantum algorithm that can factor large numbers into primes in a much shorter time than classical computers. While it’s pretty certain that this algorithm works from a mathematical perspective, it’s not at all clear that it will ever be possible to build effective quantum computers that can actually run it for the large numbers that are used in cryptography.

We’re going to vastly oversimplify the problem, and say that the challenge with general purpose quantum computing is that each q-bit is error prone, and the more q-bits a system has, the more errors it has. This error rate has proved to be a hard problem. The D-wave quantum annealing machine side-steps the issue by building a different sort of q-bits, that interact differently than in a general purpose quantum computer. The errors become much less of a problem, but you get a much less powerful primitive. And this is why annealing machines can’t run Shor’s algorithm.

The news this week is that researchers actually demonstrated a different technique on a D-wave machine that did actually factor an RSA key. From a research and engineering perspective, it is excellent work. But it doesn’t necessarily demonstrate the exponential speedup that would be required to break real-world RSA keys. To put it into perspective, you can literally crack a 22 bit RSA key by hand.

Zendesk Out of Scope

Here’s an example of two things. First off, a bug being out of scope for a bounty shouldn’t stop a researcher from working on a bug. Second, it’s worth being extra careful in how a bug bounty’s scope is set up, as sometimes bugs have unforeseen consequences. We’re talking here about Zendesk, a customer support tool and ticket manager. [Daniel] found an issue where an attacker could send an email to the support email address from a spoofed sender, and add an arbitrary email address to the ticket, gaining access to the entire ticket history.

Because the problem was related to email spoofing, and the Zendesk bounty program on HackerOne considers “SPF, DKIM, and DMARC” to be out of scope, the ticket was closed as “informative” and no bounty awarded. But [Daniel] wasn’t done. What interesting side effects could he find? How about triggering single sign on verification to go to the support email address? Since an Apple account can be used to sign on to slack, an attacker can create an apple account using the support email address, use the email spoof to get access to the created bug, and therefore the one-time code. Verify the account, and suddenly you have an Apple account at the target’s domain. [Daniel] used this to gain access to company Slack channels, but I’d guess this could be used for even more mayhem at some businesses.

Given that the original bug report was closed as “informational”, [Daniel] started reporting the bug to other companies that use Zendesk. And it paid off, netting more than $50,000 for the trouble. Zendesk never did pay a bounty on the find, but did ask [Daniel] to stop telling people about it.

Fortinet Fixed It

The good folks at Watchtowr Labs have the inside scoop on a recently fixed vulnerability in Fortinet’s FortiGate VPN appliance. It’s a good fix found internally by Fortinet, and gives us a good opportunity to talk about a class of vulnerability we haven’t ever covered. Namely, a format string vulnerability.

The printf() function and its siblings are wonderful things. You give it a string, and it prints it to standard output. You give it a string that contains a format specifier, like %s, and it will replace the specifier with the contents of a variable passed in as an additional argument. I write a lot of “printf debugging” code when trying to figure out a problem, that looks like printf("Processing %d bytes!\n", length);

What happens if the specifier doesn’t match the data type? Or if there is a specifier and no argument? You probably know the answer: Undefined behavior. Not great for device security. And in this case, it does lead to Remote Code Execution (RCE). The good news is that Fortinet found this internally, and the fix was quietly made available in February. The bad news is that attackers found it, and have since been actively using it in attacks.

Escape!

[ading2210] has the story of finding a pair of attack chains in Google Chrome/Chromium, where a malicious extension can access the chrome://policy page, and define a custom “browser” command to use when accessing specific pages. There are two separate vulnerabilities that can be used to pull off this trick. One is a race condition where disallowed JS code can run before it’s disabled after a page reload, and the other is a crash in the page inspector view. That’s not a page non-developers have a habit of visiting, so the browser extension just pulls a fast one on install, launching a simple page that claims that something went wrong, asking the user to press f12 to troubleshoot.

Multihomed Spoofing

At this point, most of us rely on Linux for our routers and firewalls. Whether you realize it or not, it’s extremely likely that that little magical box that delivers Internet goodness to your devices is a Linux machine, running iptables as the firewall. And while iptables is excellent at its job, it does have its share of quirks. Researchers at Anvil have the low down on ESTABLISHED connection spoofing.

Iptables, when run on the boarder between networks, is often set to block incoming packets by default, and allow outgoing. The catch is that you probably want responses to your requests. To allow TCP connections to work both ways, it’s common to set iptables to allow ESTABLISHED connections as well. If the IP addresses and ports all match, the packet is treated as ESTABLISHED and allowed through. So what’s missing? Unless you explicitly request it, this firewall isn’t checking that the source port is the one you expected. Packets on one interface just might get matched to a connection on a different interface and passed through. That has some particularly interesting repercussions for guest networks and the like.

Bits and Bytes

On the topic of more secure Linux installs, [Shawn Chang] has thoughts on how to run a container more securely. The easy hint is to use Podman and run rootless containers. If you want even tighter protection, there are restrictions on system calls, selinux, and a few other tricks to think about.

Check the logs! That’s the first step to looking for a breach or infection, right? But what exactly are you looking for? The folks at Trunc have thoughts on this. The basic idea is to look for logins that don’t belong, IPs that shouldn’t be there, and other specific oddities. It’s a good checklist for trouble hunting.

And finally, the playlist from DEF CON 32 is available! Among the highlights are [Cory Doctorow] talking about the future of the Internet, [HD Moore] and [Rob King] talking about SSH, and lots lots more!