Wired has a fascinating story this week, about the length Sophos has gone to for the last 5 years, to track down a group of malicious but clever security researchers that were continually discovering vulnerabilities and then using those findings to attack real-world targets. Sophos believes this adversary to be overlapping Chinese groups known as APT31, APT41, and Volt Typhoon.

The story is actually refreshing in its honesty, with Sophos freely admitting that their products, and security products from multiple other vendors have been caught in the crosshairs of these attacks. And indeed, we’ve covered stories about these vulnerabilities over the past weeks and months right here on this column. The sneaky truth is that many of these security products actually have pretty severe security problems.

The issues at Sophos started with an infection of an informational computer at a subsidiary office. They believe this was an information gathering exercise, that was a precursor to the widespread campaign. That campaign used multiple 0-days to crack “tens of thousands of firewalls around the world”. Sophos rolled out fixes for those 0-days, and included just a bit of extra logging as an undocumented feature. That logging paid off, as Sophos’ team of researchers soon identified an early signal among the telemetry. This wasn’t merely the first device to be attacked, but was actually a test device used to develop the attack. The game was on.

Sophos managed to deploy it’s own spyware to these test devices, to stealthily keep an eye on this clever opponent. This even thwarted a later attack before it could really start. Among the interesting observations was a bootkit infection on one of these firewalls. This wasn’t ever found in the wild, but the very nature of such an attack makes it hard to discover.

There’s one more interesting wrinkle to this story. In at least one case, Sophos received the 0-day vulnerability used in an attack through their bug bounty program, right after the wave of attacks was launched. The timing, combined with the Chinese IP Address makes it pretty clear this was more than a coincidence. This might be a Chinese hacker making a bit of extra cash on the side. It’s also reminiscent of the Chinese law requiring companies to disclose vulnerabilities to the Chinese government.

PTA 0-Day

GreyNoise runs a honeypot and an AI threat detection system, and found something interesting with that combination. The PTZOptics network security camera was the intended target, and there were a pair of vulnerabilities that this attack was intended to exploit. The first is a simple authorization bypass, where sending HTTP packets without an authorization header to the param.cgi endpoint returns data without any authorization needed. Use the get_system_conf parameter, and the system helpfully prints out valid username and password hashes. How convenient.

Gaining arbitrary command execution is trivial, as the ntp configuration isn’t properly sanitized, and the ntp binary is called insecurely. A simple $(cmd) can be injected for easy execution. Those two were being chained together for a dead simple attack chain, presumably to add the IoT devices to a botnet. The flaws have been fixed, and law enforcement have been on the case, at least seizing the IP address observed in the attacks.

Speaking of camera hacks, we do have an impressive tale from Pwn2Own 2024, where researchers at Synacktiv used a format string vulnerability to pwn the Synology TC500 camera. The firmware in question had a whole alphabet of security features, like ASLR, PIE, NX, and Full RelRO. That’s Address Space Layout Randomization, Position Independent Executables, Non-Executable memory, and Full Relocation Read-Only protections. Oh, and the payload was limited to 128 characters, with the first 32 ASCII characters unavailable for use.

How exactly does one write an exploit in this case? A bit of a lucky break with the existing memory layout gave access to what the write-up calls a “looping pointer”. That seems to be a pointer that points to itself, which is quite useful to work from offsets instead of precise memory locations. The vulnerability allowed for writing a shell command into unused memory. Then finally a bit of Return Oriented Programming, a ROP gadget, manages to launch a system call on the saved command line. Impressive.

Maybe It Wasn’t a Great Idea

…to give LLMs code execution capabilities. That’s the conclusion we came to after reading CyberArk’s post on how to achieve Remote Code Execution on a Large Language Model. The trick here is that this particular example, LoLLMs, can run python code on the backend to perform certain tasks, like do math calculations. This implementation uses Python sandboxing, and naturally there’s a known way to defeat it. The trick can be pulled off just by getting the model to evaluate the right JSON snippet, but it’s smart enough to realize that something is off and refuse to evaluate the JSON.

The interesting detail here is that it is the LLM itself that is refusing, so it’s the LLM that needs bypassed. There has been very interesting work done on LLM jailbreaks, like DAN, the Do Anything Now prompt. That would probably have worked, but this exploit can be even sneakier than that. Simply ask the LLM to help you write some JSON. Specify the payload, and ask it to add something to it. It gladly complies, and code is executed. Who knew that LLMs were so gullible?

More Quantum Erratta

This story just keeps on giving. This time it’s [Dan Goodin] at Ars Technica that has the lowdown, filling in the last few missing details about the much over-hyped quantum computing breakthrough. One of the first of those details is that the story of the compromise of AES was published in the South China Morning Post, which has over-hyped Chinese quantum progress before. What [Goodin]’s article really adds to the discussion is opinions from experts. The important takeaway is that the performance of the D-Wave quantum computer is comparable to classical approaches.

Bits and Bytes

Remember the traffic light hacking? And part two? We now have the third installment, which is really all about you, too, can purchase and hack on one of these traffic controllers. It may or may not surprise you that the answer is to buy them on Ebay and cobble together a makeshift power supply.

It’s amazing how often printers, point of sale, and other IoT gadgets are just running stripped-down, ancient versions of Android. This point of sale system is no exception, running an old, custom Android 6 system, that seems to actually be rather well locked down. Except that it has an NFC reader, and you can program NFC tags to launch Android apps. Use this creative workaround to get into Android settings, and you’re in business.

I have long maintained that printers are terrible. That sentiment apparently is extending into security research on printers, with Lexmark moving to a new encrypted filesystem for printer firmware. Thankfully, like most of these schemes, it’s not foolproof, and [Peter] has the scoop on getting in. May you never need it. Because seriously, printers are the worst.

Leading off the week is the controversy around the Linux kernel and an unexpected change in maintainership. The exact change was that over a dozen developers with ties to or employment by Russian entities were removed as maintainers. The unfortunate thing about this patch was that it was merged without any discussion or real explanation, other than being “due to various compliance requirements”. We eventually got more answers, that this was due to US sanctions against certain Russian businesses, and that the Linux Foundation lawyers gave guidance that:

If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file.

So that’s that. One might observe that it’s unfortunate that a single government has that much control over the kernel’s development process. There were some questions about why Russian entities were targeted and not sanctioned Chinese companies like Huawei. [Ted Ts’o] spoke to that, explaining that in the US there are exemptions and different rules for each country and business. This was all fairly standard compliance stuff, up until a very surprising statement from [James Bottomley], a very core Kernel maintainer:

We are hoping that this action alone will be sufficient to satisfy the US Treasury department in charge of sanctions and we won’t also have to remove any existing patches.

I can only conclude from this that the US Treasury has in fact made this threat, that code would need to be removed. Now this is genuinely surprising, given the legal precedent that code is 1st Amendment protected speech. That precedent was established when dealing with encryption code that was being export restricted in the 90s. It seems particularly problematic that the US government believes it can specify what code does and does not belong in the Linux kernel.

SELinux

Since we’re in Kernel land, let’s talk SELinux. Many modern Linux systems, and Android in particular, use SELinux to provide an extra security layer. It’s not an uncommon troubleshooting step, to turn off SELinux to see if that helps with mysterious issues. What we have here in the klecko Blog is an intro to bypassing SELinux. The setup is that an exploit has achieved root, but is in a unprivileged context. What options does an attacker have to try to bypass SELinux?

The first, most obvious solution is to just disable SELinux altogether. If you can write to memory, the SELinux enabled bit can just be set to false. But that might not work, if you can’t write to memory, or have a hypervisor to wrestle with, like some Android systems. Another option is the set of permissive flags that can be overwritten, or the AVC cache that can be poisoned, both approaches resulting in every SELinux request being approved. It’s an interesting overview.

Printer Root

Xerox printers with the “Network Troubleshooting” feature have some unintended hidden functionality. The troubleshooting is done by calling tcpdump as root, and the configuration allows setting the IP address to use for the troubleshooting process. And as you might expect, that IP address was used to create a command line string, and it isn’t properly escaped. You can sneak a $(bash ...) in as part of the address, allowing code execution. The good news is that access to this troubleshooting function is locked behind the web admin account. Xerox has made fixed firmware available for this issue.

Fix Your Roundcube

The Roundcube email web client has a Cross-Site Scripting (XSS) vulnerability that is actively being exploited. The flaw is the processing of SVGs, and the addition of an extra space in an href tag, that the browser ignores. Sneaking this inside an SVG allows for arbitrary Javascript to run when opening this malicious email.

Roundcube has released 1.5.7 and 1.6.7 that address the issue. This is under active exploitation, currently being used against the Russian aligned CIS countries. It’s a simple exploit, so expect to see it more widely used soon.

The Archive

The Internet Archive continues to be under siege. The Distributed Denial of Service (DDoS) attacks were apparently done by SN-Blackmeta. But the hacker behind the data breach is still a mystery. But the news this week is that there is still someone with access to Internet Archive API keys. Specifically Zendesk, illustrated by the fact that when Mashable reached out via email, the hacker answered, “It’s dispiriting to see that even after being made aware of the breach 2 weeks ago, IA has still not done the due diligence of rotating many of the API keys that were exposed in their gitlab secrets.”

It’s obviously been a terrible, horrible, no good, and very bad month for the Internet Archive. As it’s such an important resource, we’re hoping for some additional support, and getting the service back to 100%.

Quantum Errata

You may remember last week, that we talked about a Quantum Annealing machine making progress on solving RSA cryptography. In the comments, it was pointed out that some coverage on this talks about RSA, and some talks about AES, a cryptography thought to be quantum-resistant. At least one source is claiming that this confusion is because there were actually two papers from the same team, one discussing RSA, and the other techniques that could be used against AES. This isn’t confirmed yet, and there are outstanding questions about both papers.

Bits and Bytes

SQL injection attacks are old hat by this point. [NastyStereo] has an interesting idea: Polyglot SQL injection attacks. The idea is simple. A SQL query might be escapable with a single quote or a double quote. To test it, just include both: OR 1#"OR"'OR''='"="'OR''='. There are more examples and some analysis at the link.

Kaspersky researchers found a Chrome exploit, that was being delivered in the form of an online tank battle game. In reality, the game was stolen from its original developers, and the web site was a crypto stealing scam, making use of the browser 0-day. This campaign has been pinned on Lazarus, the APT from North Korea.

And yet another example of fake software, researchers at kandji discovered a fake Cloudflare Authenticator campaign. This one is a MacOS malware dropper that does a reasonably good job of looking like it’s an official Cloudflare app. It’s malware, and places itself in the system crontab, to get launched on every boot. Follow the link for Indicators of Compromise if you need them.

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!

Diamonds are nearly perfect crystals, but not totally perfect. The defects in these crystals give the stones their characteristic colors. But one type of defect, the NV — nitrogen-vacancy — center, can hold a particular spin, and you can change that spin with the correct application of energy. [Asianometry] explains why this is important in the video below.

Interestingly, even at room temperature, an NV center stays stable for a long time. Even more importantly, you can measure the spin nondestructively by detecting light emissions from the center.

There are obvious applications for quantum computing, but an even more practical application is sensing magnetic fields. These could replace SQUIDs, which are often used for sensitive magnetic measurements but require cold temperatures to support superconductivity.

Of course, you have to create a diamond artificially to get the NV centers the way you want and it turns out that semiconductor manufacturing tools can help produce the diamonds you need.

The last time we looked in on diamond defects, the proposal was to use them for data storage. It seems like this could be easier than holding out for room-temperature superconductors to improve SQUIDs.

If you’re like us, you’ve never spent a second thinking about what happens when you dunk an ordinary LED into liquid nitrogen. That’s too bad because as it turns out, the results are pretty interesting and actually give us a little bit of a look at the quantum world.

The LED fun that [Sebastian] over at Baltic Lab demonstrates in the video below starts with a bright yellow LED and a beaker full of liquid nitrogen. Lowering the powered LED into the nitrogen changes the color of the light from yellow to green, an effect that reverses as the LED is withdrawn and starts to warm up again. There’s no apparent damage to the LED either, although we suppose that repeated thermal cycles might be detrimental at some point. The color change is quite rapid, and seems to also result in a general increase in the LED’s intensity, although that could be an optical illusion; our eyes are most sensitive in the greenish wavelengths, after all.

So why does this happen? [Sebastian] goes into some detail about that, and this is where quantum physics comes into it. The color of an LED is a property of the bandgap of the semiconductor material. Bandgap is just the difference in energy between electrons in the valence band (the energy levels electrons end up at when excited) and the conduction band (the energy levels they start at.) There’s no bandgap in conductive materials — the two bands overlap — while insulators have a huge bandgap and semiconductors have a narrow gap. Bandgap is also dependent on temperature; it increases with decreasing temperature, with different amounts for different semiconductors, but not observably so over normal temperature ranges. But liquid nitrogen is cold enough for the shift to be dramatically visible.

We’d love to see the color shift associated with other cryogens, or see what happens with a blue LED. Want to try this but don’t have any liquid nitrogen? Make some yourself!

GPS has changed the way we get around the globe. But if you command a warship, you must think about what you would do if an adversary destroyed or compromised your GPS system. The Royal Navy and Imperial College London think a quantum navigation system might be the answer.
Of course, Heisenberg says you can’t know your speed and position simultaneously. But at the real-world level, you can apparently get close enough. The quantum sensors in question are essentially accelerometers. Unlike conventional accelerometers, though, these devices use ultracold atoms to make very precise measurements using a laser optical ruler, which means they do not drift as rapidly as, say, the accelerometer in your phone. Navigating with accelerometers is well understood, but the issue is how often you have to correct your computed position with an actual reference due to drift and other error accumulation. You can see a Sky News report on the trial below.The tests were done in a rapid prototyping pod carried onboard XV Patrick Blackett, a fitting name for an experimental ship since Lord Blackett was a Nobel laureate and head of the physics department at Imperial College for a decade ending in 1963. The underlying tech came out of the university back in 2018, but making it work in a real-world environment onboard a ship is another matter. You probably won’t have the cryonics and lasers needed for such a quantum compass anytime soon in your smartphone, but the tech could have civilian applications for larger vehicles.

Recently, [Jabrils] set out to accomplish a difficult task: porting a quantum-inspired algorithm to run on a (simulated) quantum computer. Algorithms are often inspired by all sorts of natural phenomena. For example, a solution to the traveling salesman problem models ants and their pheromone trails. Another famous example is neural nets, which are inspired by the neurons in your brain. However, attempting to run a machine learning algorithm on your neurons, even with the assistance of pen and paper would be a nearly impossible exercise.

The quantum-inspired algorithm in question is known as the wavefunction collapse function. In a nutshell, you have a cube of voxels, a graph of nodes, or simply a grid of tiles as well as a list of detailed rules to determine the state of a node or tile. At the start of the algorithm, each node or point is considered in a state of superposition, which means it is considered to be in every possible state. Looking at the list of rules, the algorithm then begins to collapse the states. Unlike a quantum computer, states of superposition is not an intrinsic part of a classic computer, so this solving must be done iteratively. In order to reduce possible conflicts and contradictions later down the line, the nodes with the least entropy (the smallest number of possible states) are solved first. At first, random states are assigned, with the changes propagating through the system. This process is continued until the waveform is ultimately collapsed to a stable state or a contradiction is reached.

What’s interesting is that the ruleset doesn’t need to be coded, it can be inferred from an example. A classic use case of this algorithm is 2D pixel-art level design. By providing a small sample level, the algorithm churns and produces similar but wholly unique output. This makes it easy to provide thousands of unique and beautiful levels from an easy source image, however it comes at a price. Even a small level can take hours to fully collapse. In theory, a quantum computer should be able to do this much faster, since after all, it was the inspiration for this algorithm in the first place.

[Jabrils] spent weeks trying to get things running but ultimately didn’t succeed. However, his efforts give us a peek into the world of quantum computing and this amazing algorithm. We look forward to hearing more about this project from [Jabrils] who is continuing to work on it in his spare time. Maybe give it a shot yourself by learning the basics of quantum computing for yourself.