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.

We see a fair few glitcher projects, especially the simpler voltage glitchers. Still, quite often due to their relative simplicity, they’re little more than a microcontroller board and a few components hanging off some wires. PicoGlitcher by Hackaday.IO user [Matthias Kesenheimer] is a simple voltage glitcher which aims to make the hardware setup a little more robust without getting caught up in the complexities of other techniques. Based on the Raspberry Pico (obviously!), the board has sufficient niceties to simplify glitching attacks in various situations, providing controllable host power if required.

A pair of 74LVC8T245 (according to the provided BoM) level shifters allow connecting to targets at voltages from 1.8 V to 5 V if powered by PicoGlitcher or anything in spec for the ‘245 if target power is being used. In addition to the expected RESET and TRIGGER signals, spare GPIOs are brought out to a header for whatever purpose is needed to control a particular attack. If a programmed reset doesn’t get the job done, the target power is provided via a TPS2041 load switch to enable cold starts. The final part of the interface is an analog input provided by an SMA connector.

The glitching signal is also brought out to an SMA connector via a pair of transistors; an IRLML2502 NMOS performs ‘low power’ glitching by momentarily connecting the glitch output to ground. This ‘crowbarring’ causes a rapid dip in supply voltage and upsets the target, hopefully in a helpful way. An IRF7807 ‘NMOS device provides a higher power option, which can handle pulse loads of up to 66A. Which transistor you select in the Findus glitching toolchain depends on the type of load connected, particularly the amount of decoupling capacitance that needs to be discharged. For boards with heavier decoupling, use the beefy IRF7807 and accept the glitch won’t be as sharp as you’d like. For other hardware, the faster, smaller device is sufficient.

The software to drive PicoGlitcher and the hardware design files for KiCAD are provided on the project GitHub page. There also appears to be an Eagle project in there. You can’t have too much hardware documentation! For the software, check out the documentation for a quick overview of how it all works and some nice examples against some targets known to be susceptible to this type of attack.

For a cheap way to glitch an STM8, you can just use a pile of wires. But for something a bit more complicated, such as a Starlink user terminal, you need something a bit more robust. Finally, voltage glitching doesn’t always work, so the next tool you can reach for is a picoEMP.

A British journalistic trope involves the phrase “The pound in your pocket”, a derisory reference to the 1960s Prime Minister Harold Wilson’s use of it to try to persuade the public that a proposed currency devaluation wouldn’t affect them. Nearly six decades later not so many Brits carry physical pounds in their pockets as electronic transfers have become more prevalent, but the currency remains. So much so that the governor of the Bank of England has had to reassure the world that the pound won’t be replaced by a proposed “Britcoin” cryptocurrency should that be introduced.

Normally matters of monetary policy aren’t within Hackaday’s remit, but since the UK is not the only country to mull over the idea of a tightly regulated cryptocurrency tied to their existing one, there’s a privacy angle to be considered while still steering clear of the fog of cryptocurrency enthusiasts. The problem is that reading the justification for the new digital pound from the Bank of England, it’s very difficult to see much it offers which isn’t already offered by existing cashless payment systems. Meanwhile it offers to them a blank regulatory sheet upon which they can write any new rules they want, and since that inevitably means some of those rules will affect digital privacy in a negative manner, it should be a worry to anyone whose government has considered the idea. Being at pains to tell us that we’ll still be able to see a picture of the King (or a dead President, or a set of bridges) on a bit of paper thus feels like an irrelevance as increasingly few of us handle banknotes much anyway these days. Perhaps that act in itself will now become more of an act of protest. And just when we’d persuaded our hackerspaces to go cashless, too.

Header: Wikitropia, CC BY-SA 3.0.

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!

The Internet Archive has been hacked. This is an ongoing story, but it looks like this started at least as early as September 28, while the site itself was showing a creative message on October 9th, telling visitors they should be watching for their email addresses to show up on Have I Been Pwnd.

Hi folks, yes, I'm aware of this. I've been in communication with the Internet Archive over the last few days re the data breach, didn't know the site was defaced until people started flagging it with me just now. More soon. https://t.co/uRROXX1CF9

— Troy Hunt (@troyhunt) October 9, 2024

There are questions still. The site defacement seems to have included either a subdomain takeover, or a long tail attack resulting from the polyfill takeover. So far my money is on something else as the initial vector, and the polyfill subdomain as essentially a red herring.

Troy Hunt has confirmed that he received 31 million records, loaded them into the HIBP database, and sent out notices to subscribers. The Internet Archive had email addresses, usernames, and bcrypt hashed passwords.

In addition, the Archive has been facing Distributed Denial of Service (DDoS) attacks off and on this week. It’s open question whether the same people are behind the breach, the message, and the DDoS. So far it looks like one group or individual is behind both the breach and vandalism, and another group, SN_BLACKMETA, is behind the DDoS.

Palo Alto Expedition

Researchers at HORIZON3 started with a known vulnerability in Palo Alto’s Expedition application. This follows a pattern we’ve seen many times before. A vulnerability is found, usually in a codebase or niche that hadn’t been considered interesting to researchers. A new vulnerability is announced, and suddenly the boring code seems interesting.

The new vulnerability was pretty straightforward — an HTTP call to a specific endpoint resets the admin password to default. The obvious next step was to look for something to do with this new admin power. Expedition uses cron to schedule tasks, and while there didn’t seem to be a way to directly set the command, the start time wasn’t sanitized, and ended up part of a string executed in bash. Yes, it’s a simple command line injection. Sometimes the simple approach just works.

The flaws were fixed with 1.2.96. As Expedition is intended for network migration, it’s not expected to be run indefinitely. Shodan lists a whopping 23 Expedition servers on the Internet. Don’t be like those guys.

Arbitrary Write, But Read Only Filesystem

[Stefan Schiller] from Sonar had an interesting challenge. He had found an arbitrary file upload widget in a node.js application. This sort of write anything anywhere flaw is usually an instant exploit, with many options to choose from. This particular application was hardened: The filesystem was read only. This is a great strategy for making exploitation harder. But as we see here, it’s not foolproof. In Unix, everything is a file. And that means that file write vulnerabilities are useful even with a read-only FS.

In this case, the weak point was an anonymous pipe, an inter-process communication (IPC) construction. The Linux procfs puts those pipes on the filesystem. Listening on the other end of one of those pipes was libuv, a signal handling library. One of the things this library does with these messages is to jump execution to a pointer in the message, as a callback function implementation. Build this data structure properly, and you have shell code execution. Nifty!

Glitching With a Lighter

Memory glitching attacks are really cool. And most of the time, they’re pretty difficult to pull off. Getting access often means physically attacking a chip, or using some expensive EM generator. [David Buchanan] wanted to know if that style of attack is possible with makeshift tools. So, he channeled his inner MacGyver, and looked at the junk in his pockets. A scrap of wire and a pocket lighter? Perfect!

That lighter didn’t use flint and steel, but instead a piezo-electric trigger. Solder the wire onto the memory chip of a laptop, and flick the lighter right next to it. That scrap of wire is suddenly an antenna, and the em burst from the lighter is enough to flip a bit. It’s rowhammer, with an antenna.

And yes, using similar techniques to rowhammer, it’s quite possible to use this to compromise a machine, assuming you can get some arbitrary data somewhere in memory. It’s a clever bit of magic, and while not particularly useful as an attack, it’s really great to see someone working with these attacks on a shoestring budget and making it work.

Firefox 0-day

It’s time to update Firefox. Mozilla has released an emergency update, version 131.0.2, to fix a critical use-after-free vulnerability in Animation timelines, part of the Web Animations API. Not much is known about this vulnerability, but it’s being used in real-world attacks already. We know that ESET discovered the flaw, but not yet whether that discovery was from observing it in use. Regardless, the fix is now available.

Bits and Bytes

We normally think of data breaches as leaking personal information, and then brace for the inevitable targeted spam. Here’s your reminder that it can be worse than that. AT&T seems to have an ongoing data breach where someone with access to shipping information for new iPhones is sending it to organized porch pirate rings.

And finally, Google Project Zero has a new post out, from [Nick Galloway], chatting about OSS-Fuzz and the Dav1d AV1 decoder. [Nick] expanded the fuzzing setup for Dav1d, and managed to find an integer overflow while at it. And while you’re here, maybe check out the OSS-Fuzz Bounty program, where Google offers to pay programmers for adding Open Source software to the OSS-Fuzz project.

There are a great many organizations out there, all with their own intentions—some selfish, some selfless, some that land somewhere in between. Most would put the Internet Archive in the category of the library—with its aim of preserving and providing knowledge for the aid of all who might call on it. Sadly, as [theresnotime] reports, it appears this grand institution has been hacked.

On Wednesday, users visiting the Internet Archive were greeted with a foreboding popup that stated the following:

Have you ever felt like the Internet Archive runs on sticks and is constantly on the verge of suffering a catastrophic security breach? It just happened. See 31 million of you on HIBP!

The quote appears to refer to Have I Been Pwned (HIBP), a site that collates details of security breaches so individuals can check if their details have been compromised.

According to founder Brewster Kahle, the site was apparently DDOS’d, with the site defaced via a JavaScript library. It’s believed this may have been a polyfill supply chain attack. As for the meat of the hack, it appears the individuals involved made off with usernames, emails, and encrypted and salted passwords. Meanwhile, as Wired reports, it appears Have I Been Pwned first received the stolen data of 31 million users on September 30.

At the time of writing, it appears the Internet Archive has restored the website to some degree of normal operation. It’s sad to see one of the Internet’s most useful and humble institutions fall victim to a hack like this one. As is always the way, no connected machine is ever truly safe, no matter how much we might hope that’s not the case.

[Thanks to Sammy for the tip!]