April 15, 2022
by Bruce Schneier
Fellow and Lecturer, Harvard Kennedy School
A free monthly newsletter providing summaries, analyses, insights, and commentaries on security: computer and otherwise.
For back issues, or to subscribe, visit Crypto-Gram’s web page.
These same essays and news items appear in the Schneier on Security blog, along with a lively and intelligent comment section. An RSS feed is available.
- US Critical Infrastructure Companies Will Have to Report When They Are Hacked
- Breaking RSA through Insufficiently Random Primes
- “Change Password”
- Why Vaccine Cards Are So Easily Forged
- Developer Sabotages Open-Source Software Package
- White House Warns of Possible Russian Cyberattacks
- NASA’s Insider Threat Program
- Linux Improves Its Random Number Generator
- Gus Simmons’s Memoir
- A Detailed Look at the Conti Ransomware Gang
- Stalking with an Apple Watch
- Chrome Zero-Day from North Korea
- Bypassing Two-Factor Authentication
- Wyze Camera Vulnerability
- Hackers Using Fake Police Data Requests against Tech Companies
- Cyberweapons Arms Manufacturer FinFisher Shuts Down
- US Disrupts Russian Botnet
- AirTags Are Used for Stalking Far More than Previously Reported
- De-anonymizing Bitcoin
- John Oliver on Data Brokers
- Russian Cyberattack against Ukrainian Power Grid Prevented
- Industrial Control System Malware Discovered
- Upcoming Speaking Engagements
Companies critical to U.S. national interests will now have to report when they’re hacked or they pay ransomware, according to new rules approved by Congress.
The reporting requirement legislation was approved by the House and the Senate on Thursday and is expected to be signed into law by President Joe Biden soon. It requires any entity that’s considered part of the nation’s critical infrastructure, which includes the finance, transportation and energy sectors, to report any “substantial cyber incident” to the government within three days and any ransomware payment made within 24 hours.
Even better would be if they had to report it to the public.
[2022.03.16] Basically, the SafeZone library doesn’t sufficiently randomize the two prime numbers it used to generate RSA keys. They’re too close to each other, which makes them vulnerable to recovery.
There aren’t many weak keys out there, but there are some:
So far, Böck has identified only a handful of keys in the wild that are vulnerable to the factorization attack. Some of the keys are from printers from two manufacturers, Canon and Fujifilm (originally branded as Fuji Xerox). Printer users can use the keys to generate a Certificate Signing Request. The creation date for the all the weak keys was 2020 or later. The weak Canon keys are tracked as CVE-2022-26351.
Böck also found four vulnerable PGP keys, typically used to encrypt email, on SKS PGP key servers. A user ID tied to the keys implied they were created for testing, so he doesn’t believe they’re in active use.
Instead of telling you when it’s safe to cross the street, the walk signs in Crystal City, VA are just repeating ‘CHANGE PASSWORD.’ Something’s gone terribly wrong here.
EDITED TO ADD (4/13): Details of what happened.
[2022.03.18] My proof of COVID-19 vaccination is recorded on an easy-to-forge paper card. With little trouble, I could print a blank form, fill it out, and snap a photo. Small imperfections wouldn’t pose any problem; you can’t see whether the paper’s weight is right in a digital image. When I fly internationally, I have to show a negative COVID-19 test result. That, too, would be easy to fake. I could change the date on an old test, or put my name on someone else’s test, or even just make something up on my computer. After all, there’s no standard format for test results; airlines accept anything that looks plausible.
After a career spent in cybersecurity, this is just how my mind works: I find vulnerabilities in everything I see. When it comes to the measures intended to keep us safe from COVID-19, I don’t even have to look very hard. But I’m not alarmed. The fact that these measures are flawed is precisely why they’re going to be so helpful in getting us past the pandemic.
Back in 2003, at the height of our collective terrorism panic, I coined the term security theater to describe measures that look like they’re doing something but aren’t. We did a lot of security theater back then: ID checks to get into buildings, even though terrorists have IDs; random bag searches in subway stations, forcing terrorists to walk to the next station; airport bans on containers with more than 3.4 ounces of liquid, which can be recombined into larger bottles on the other side of security. At first glance, asking people for photos of easily forged pieces of paper or printouts of readily faked test results might look like the same sort of security theater. There’s an important difference, though, between the most effective strategies for preventing terrorism and those for preventing COVID-19 transmission.
Security measures fail in one of two ways: Either they can’t stop a bad actor from doing a bad thing, or they block an innocent person from doing an innocuous thing. Sometimes one is more important than the other. When it comes to attacks that have catastrophic effects—say, launching nuclear missiles—we want the security to stop all bad actors, even at the expense of usability. But when we’re talking about milder attacks, the balance is less obvious. Sure, banks want credit cards to be impervious to fraud, but if the security measures also regularly prevent us from using our own credit cards, we would rebel and banks would lose money. So banks often put ease of use ahead of security.
That’s how we should think about COVID-19 vaccine cards and test documentation. We’re not looking for perfection. If most everyone follows the rules and doesn’t cheat, we win. Making these systems easy to use is the priority. The alternative just isn’t worth it.
I design computer security systems for a living. Given the challenge, I could design a system of vaccine and test verification that makes cheating very hard. I could issue cards that are as unforgeable as passports, or create phone apps that are linked to highly secure centralized databases. I could build a massive surveillance apparatus and enforce the sorts of strict containment measures used in China’s zero-COVID-19 policy. But the costs—in money, in liberty, in privacy—are too high. We can get most of the benefits with some pieces of paper and broad, but not universal, compliance with the rules.
It also helps that many of the people who break the rules are so very bad at it. Every story of someone getting arrested for faking a vaccine card, or selling a fake, makes it less likely that the next person will cheat. Every traveler arrested for faking a COVID-19 test does the same thing. When a famous athlete such as Novak Djokovic gets caught lying about his past COVID-19 diagnosis when trying to enter Australia, others conclude that they shouldn’t try lying themselves.
Our goal should be to impose the best policies that we can, given the trade-offs. The small number of cheaters isn’t going to be a public-health problem. I don’t even care if they feel smug about cheating the system. The system is resilient; it can withstand some cheating.
Last month, I visited New York City, where restrictions that are now being lifted were then still in effect. Every restaurant and cocktail bar I went to verified the photo of my vaccine card that I keep on my phone, and at least pretended to compare the name on that card with the one on my photo ID. I felt a lot safer in those restaurants because of that security theater, even if a few of my fellow patrons cheated.
This essay previously appeared in the Atlantic.
A developer has been caught adding malicious code to a popular open-source package that wiped files on computers located in Russia and Belarus as part of a protest that has enraged many users and raised concerns about the safety of free and open source software.
The application, node-ipc, adds remote interprocess communication and neural networking capabilities to other open source code libraries. As a dependency, node-ipc is automatically downloaded and incorporated into other libraries, including ones like Vue.js CLI, which has more than 1 million weekly downloads.
The node-ipc update is just one example of what some researchers are calling protestware. Experts have begun tracking other open source projects that are also releasing updates calling out the brutality of Russia’s war. This spreadsheet lists 21 separate packages that are affected.
One such package is es5-ext, which provides code for the ECMAScript 6 scripting language specification. A new dependency named postinstall.js, which the developer added on March 7, checks to see if the user’s computer has a Russian IP address, in which case the code broadcasts a “call for peace.”
It constantly surprises non-computer people how much critical software is dependent on the whims of random programmers who inconsistently maintain software libraries. Between log4j and this new protestware, it’s becoming a serious vulnerability. The White House tried to start addressing this problem last year, requiring a “software bill of materials” for government software:
…the term “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.
It’s not a solution, but it’s a start.
EDITED TO ADD (3/22): Brian Krebs on protestware.
The White House has issued its starkest warning that Russia may be planning cyberattacks against critical-sector U.S. companies amid the Ukraine invasion.
Context: The alert comes after Russia has lobbed a series of digital attacks at the Ukrainian government and critical industry sectors. But there’s been no sign so far of major disruptive hacks against U.S. targets even as the government has imposed increasingly harsh sanctions that have battered the Russian economy.
- The public alert followed classified briefings government officials conducted last week for more than 100 companies in sectors at the highest risk of Russian hacks, Neuberger said. The briefing was prompted by “preparatory activity” by Russian hackers, she said.
- U.S. analysts have detected scanning of some critical sectors’ computers by Russian government actors and other preparatory work, one U.S. official told my colleague Ellen Nakashima on the condition of anonymity because of the matter’s sensitivity. But whether that is a signal that there will be a cyberattack on a critical system is not clear, Neuberger said.
- Neuberger declined to name specific industry sectors under threat but said they’re part of critical infrastructure—a government designation that includes industries deemed vital to the economy and national security, including energy, finance, transportation and pipelines.
EDITED TO ADD (3/23): Long—three hour—conference call with CISA.
While NASA has a fully operational insider threat program for its classified systems, the vast majority of the Agency’s information technology (IT) systems—including many containing high-value assets or critical infrastructure—are unclassified and are therefore not covered by its current insider threat program. Consequently, the Agency may be facing a higher-than-necessary risk to its unclassified systems and data. While NASA’s exclusion of unclassified systems from its insider threat program is common among federal agencies, adding those systems to a multi-faceted security program could provide an additional level of maturity to the program and better protect agency resources. According to Agency officials, expanding the insider threat program to unclassified systems would benefit the Agency’s cybersecurity posture if incremental improvements, such as focusing on IT systems and people at the most risk, were implemented. However, on-going concerns including staffing challenges, technology resource limitations, and lack of funding to support such an expansion would need to be addressed prior to enhancing the existing program.
Further amplifying the complexities of insider threats are the cross-discipline challenges surrounding cybersecurity expertise. At NASA, responsibilities for unclassified systems are largely shared between the Office of Protective Services and the Office of the Chief Information Officer. In addition, Agency contracts are managed by the Office of Procurement while grants and cooperative agreements are managed by the Office of the Chief Financial Officer. Nonetheless, in our view, mitigating the risk of an insider threat is a team sport in which a comprehensive insider threat risk assessment would allow the Agency to gather key information on weak spots or gaps in administrative processes and cybersecurity. At a time when there is growing concern about the continuing threats of foreign influence, taking the proactive step to conduct a risk assessment to evaluate NASA’s unclassified systems ensures that gaps cannot be exploited in ways that undermine the Agency’s ability to carry out its mission.
[2022.03.24] In kernel version 5.17, both /dev/random and /dev/urandom have been replaced with a new algorithm—the same one for both—based on the BLAKE2 hash function, which is an excellent security improvement.
[2022.03.25] Gus Simmons is an early pioneer in cryptography and computer security. I know him best for his work on authentication and covert channels, specifically as related to nuclear treaty verification. His work is cited extensively in Applied Cryptography.
He has written a memoir of growing up dirt-poor in 1930s rural West Virginia. I’m in the middle of reading it, and it’s fascinating.
The Conti ransomware gang runs like any number of businesses around the world. It has multiple departments, from HR and administrators to coders and researchers. It has policies on how its hackers should process their code, and shares best practices to keep the group’s members hidden from law enforcement.
Police reportedly arrived on the scene last week and found the man crouched beside the woman’s passenger side door. According to the police, the man had, at some point, wrapped his Apple Watch across the spokes of the woman’s passenger side front car wheel and then used the Watch to track her movements. When police eventually confronted him, he admitted the Watch was his. Now, he’s reportedly being charged with attaching an electronic tracking device to the woman’s vehicle.
The flaw, tracked as CVE-2022-0609, was exploited by two separate North Korean hacking groups. Both groups deployed the same exploit kit on websites that either belonged to legitimate organizations and were hacked or were set up for the express purpose of serving attack code on unsuspecting visitors. One group was dubbed Operation Dream Job, and it targeted more than 250 people working for 10 different companies. The other group, known as AppleJeus, targeted 85 users.
The attackers made use of an exploit kit that contained multiple stages and components in order to exploit targeted users. The attackers placed links to the exploit kit within hidden iframes, which they embedded on both websites they owned as well as some websites they compromised.
Careful to protect their exploits, the attackers deployed multiple safeguards to make it difficult for security teams to recover any of the stages. These safeguards included:
- Only serving the iframe at specific times, presumably when they knew an intended target would be visiting the site.
- On some email campaigns the targets received links with unique IDs. This was potentially used to enforce a one-time-click policy for each link and allow the exploit kit to only be served once.
- The exploit kit would AES encrypt each stage, including the clients’ responses with a session-specific key.
- Additional stages were not served if the previous stage failed.
Although we recovered a Chrome RCE, we also found evidence where the attackers specifically checked for visitors using Safari on MacOS or Firefox (on any OS), and directed them to specific links on known exploitation servers. We did not recover any responses from those URLs.
If you’re a Chrome user, patch your system now.
…some forms of MFA are stronger than others, and recent events show that these weaker forms aren’t much of a hurdle for some hackers to clear. In the past few months, suspected script kiddies like the Lapsus$ data extortion gang and elite Russian-state threat actors (like Cozy Bear, the group behind the SolarWinds hack) have both successfully defeated the protection.
- Sending a bunch of MFA requests and hoping the target finally accepts one to make the noise stop.
- Sending one or two prompts per day. This method often attracts less attention, but “there is still a good chance the target will accept the MFA request.”
- Calling the target, pretending to be part of the company, and telling the target they need to send an MFA request as part of a company process.
FIDO2 multi-factor authentication systems are not susceptible to these attacks, because they are tied to a physical computer.
And even though there are attacks against these two-factor systems, they’re much more secure than not having them at all. If nothing else, they block pretty much all automated attacks.
In case you’re wondering, no, that is not normal in the security community. While experts tell me that the concept of a “responsible disclosure timeline” is a little outdated and heavily depends on the situation, we’re generally measuring in days, not years. “The majority of researchers have policies where if they make a good faith effort to reach a vendor and don’t get a response, that they publicly disclose in 30 days,” Alex Stamos, director of the Stanford Internet Observatory and former chief security officer at Facebook, tells me.
Virtually all major technology companies serving large numbers of users online have departments that routinely review and process such requests, which are typically granted as long as the proper documents are provided and the request appears to come from an email address connected to an actual police department domain name.
But in certain circumstances—such as a case involving imminent harm or death—an investigating authority may make what’s known as an Emergency Data Request (EDR), which largely bypasses any official review and does not require the requestor to supply any court-approved documents.
It is now clear that some hackers have figured out there is no quick and easy way for a company that receives one of these EDRs to know whether it is legitimate. Using their illicit access to police email systems, the hackers will send a fake EDR along with an attestation that innocent people will likely suffer greatly or die unless the requested data is provided immediately.
In this scenario, the receiving company finds itself caught between two unsavory outcomes: Failing to immediately comply with an EDR—and potentially having someone’s blood on their hands—or possibly leaking a customer record to the wrong person.
We allude to this kind of risk in our 2015 “Keys Under Doormats” paper:
Third, exceptional access would create concentrated targets that could attract bad actors. Security credentials that unlock the data would have to be retained by the platform provider, law enforcement agencies, or some other trusted third party. If law enforcement’s keys guaranteed access to everything, an attacker who gained access to these keys would enjoy the same privilege. Moreover, law enforcement’s stated need for rapid access to data would make it impractical to store keys offline or split keys among multiple keyholders, as security engineers would normally do with extremely high-value credentials.
The “credentials” are even more insecure than we could have imagined: access to an email address. And the data, of course, isn’t very secure. But imagine how this kind of thing could be abused with a law enforcement encryption backdoor.
The Justice Department today announced a court-authorized operation, conducted in March 2022, to disrupt a two-tiered global botnet of thousands of infected network hardware devices under the control of a threat actor known to security researchers as Sandworm, which the U.S. government has previously attributed to the Main Intelligence Directorate of the General Staff of the Armed Forces of the Russian Federation (the GRU). The operation copied and removed malware from vulnerable internet-connected firewall devices that Sandworm used for command and control (C2) of the underlying botnet. Although the operation did not involve access to the Sandworm malware on the thousands of underlying victim devices worldwide, referred to as “bots,” the disabling of the C2 mechanism severed those bots from the Sandworm C2 devices’ control.
The botnet “targets network devices manufactured by WatchGuard Technologies Inc. (WatchGuard) and ASUSTek Computer Inc. (ASUS).” And note that only the command-and-control mechanism was disrupted. Those devices are still vulnerable.
The Justice Department made a point that they did this before the botnet was used for anything offensive.
EDITED TO ADD (4/13): WatchGuard knew and fixed it nearly a year ago, but tried to keep it hidden. The patches were reverse-engineered.
[2022.04.08] Ever since Apple introduced AirTags, security people have warned that they could be used for stalking. But while there have been a bunch of anecdotal stories, this is the first vaguely scientific survey:
Motherboard requested records mentioning AirTags in a recent eight month period from dozens of the country’s largest police departments. We obtained records from eight police departments.
Of the 150 total police reports mentioning AirTags, in 50 cases women called the police because they started getting notifications that their whereabouts were being tracked by an AirTag they didn’t own. Of those, 25 could identify a man in their lives—ex-partners, husbands, bosses—who they strongly suspected planted the AirTags on their cars in order to follow and harass them. Those women reported that current and former intimate partners—the most likely people to harm women overall—are using AirTags to stalk and harass them.
Eight police departments over eight months yielded fifty cases. And that’s only where the victim (1) realized they were being tracked by someone else’s AirTag, and (2) contacted the police. That’s going to multiply out to a lot of AirTag stalking in the country, and the world.
EDITED TO ADD (4/13): AirTags are being used by Ukrainians to track goods stolen by Russians and, as a nice side effect, to track the movements of Russian troops.
Within a few years of Bitcoin’s arrival, academic security researchers—and then companies like Chainalysis—began to tear gaping holes in the masks separating Bitcoin users’ addresses and their real-world identities. They could follow bitcoins on the blockchain as they moved from address to address until they reached one that could be tied to a known identity. In some cases, an investigator could learn someone’s Bitcoin addresses by transacting with them, the way an undercover narcotics agent might conduct a buy-and-bust. In other cases, they could trace a target’s coins to an account at a cryptocurrency exchange where financial regulations required users to prove their identity. A quick subpoena to the exchange from one of Chainalysis’ customers in law enforcement was then enough to strip away any illusion of Bitcoin’s anonymity.
Chainalysis had combined these techniques for de-anonymizing Bitcoin users with methods that allowed it to “cluster” addresses, showing that anywhere from dozens to millions of addresses sometimes belonged to a single person or organization. When coins from two or more addresses were spent in a single transaction, for instance, it revealed that whoever created that “multi-input” transaction must have control of both spender addresses, allowing Chainalysis to lump them into a single identity. In other cases, Chainalysis and its users could follow a “peel chain”—a process analogous to tracking a single wad of cash as a user repeatedly pulled it out, peeled off a few bills, and put it back in a different pocket. In those peel chains, bitcoins would be moved out of one address as a fraction was paid to a recipient and then the remainder returned to the spender at a “change” address. Distinguishing those change addresses could allow an investigator to follow a sum of money as it hopped from one address to the next, charting its path through the noise of Bitcoin’s blockchain.
Thanks to tricks like these, Bitcoin had turned out to be practically the opposite of untraceable: a kind of honeypot for crypto criminals that had, for years, dutifully and unerasably recorded evidence of their dirty deals. By 2017, agencies like the FBI, the Drug Enforcement Agency, and the IRS’s Criminal Investigation division (or IRS-CI) had traced Bitcoin transactions to carry out one investigative coup after another, very often with the help of Chainalysis.
- ESET researchers collaborated with CERT-UA to analyze the attack against the Ukrainian energy company
- The destructive actions were scheduled for 2022-04-08 but artifacts suggest that the attack had been planned for at least two weeks
- The attack used ICS-capable malware and regular disk wipers for Windows, Linux and Solaris operating systems
- We assess with high confidence that the attackers used a new version of the Industroyer malware, which was used in 2016 to cut power in Ukraine
- We assess with high confidence that the APT group Sandworm is responsible for this new attack
EDITED TO ADD: Better news coverage from Wired.
[2022.04.14] The Department of Energy, CISA, the FBI, and the NSA jointly issued an advisory describing a sophisticated piece of malware called Pipedream that’s designed to attack a wide range of industrial control systems. This is clearly from a government, but no attribution is given. There’s also no indication of how the malware was discovered. It seems not to have been used yet.
[2022.04.14] This is a current list of where and when I am scheduled to speak:
- I’m speaking at Future Summits in Antwerp, Belgium, on May 18, 2022.
- I’m speaking at IT-S Now 2022 in Vienna, Austria, on June 2, 2022.
- I’m speaking at the 14th International Conference on Cyber Conflict, CyCon 2022, in Tallinn, Estonia, on June 3, 2022.
- I’m speaking at the RSA Conference 2022 in San Francisco, June 6-9, 2022.
- I’m speaking at the Dublin Tech Summit in Dublin, Ireland, June 15-16, 2022.
The list is maintained on this page.
Since 1998, CRYPTO-GRAM has been a free monthly newsletter providing summaries, analyses, insights, and commentaries on security technology. To subscribe, or to read back issues, see Crypto-Gram’s web page.
You can also read these articles on my blog, Schneier on Security.
Please feel free to forward CRYPTO-GRAM, in whole or in part, to colleagues and friends who will find it valuable. Permission is also granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.
Bruce Schneier is an internationally renowned security technologist, called a security guru by the Economist. He is the author of over one dozen books—including his latest, We Have Root—as well as hundreds of articles, essays, and academic papers. His newsletter and blog are read by over 250,000 people. Schneier is a fellow at the Berkman Klein Center for Internet & Society at Harvard University; a Lecturer in Public Policy at the Harvard Kennedy School; a board member of the Electronic Frontier Foundation, AccessNow, and the Tor Project; and an Advisory Board Member of the Electronic Privacy Information Center and VerifiedVoting.org. He is the Chief of Security Architecture at Inrupt, Inc.
Copyright © 2022 by Bruce Schneier.