Great Victorian animal-combat scene featuring a giant squid.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Read my blog posting guidelines here.
An interesting story of uncovering an anonymous Internet social media account.
Think about all of the websites you visit every day. Now imagine if the likes of Time Warner, AT&T, and Verizon collected all of your browsing history and sold it on to the highest bidder. That’s what will probably happen if Congress has its way.
This week, lawmakers voted to allow Internet service providers to violate your privacy for their own profit. Not only have they voted to repeal a rule that protects your privacy, they are also trying to make it illegal for the Federal Communications Commission to enact other rules to protect your privacy online.
That this is not provoking greater outcry illustrates how much we’ve ceded any willingness to shape our technological future to for-profit companies and are allowing them to do it for us.
There are a lot of reasons to be worried about this. Because your Internet service provider controls your connection to the Internet, it is in a position to see everything you do on the Internet. Unlike a search engine or social networking platform or news site, you can’t easily switch to a competitor. And there’s not a lot of competition in the market, either. If you have a choice between two high-speed providers in the US, consider yourself lucky.
What can telecom companies do with this newly granted power to spy on everything you’re doing? Of course they can sell your data to marketers—and the inevitable criminals and foreign governments who also line up to buy it. But they can do more creepy things as well.
They can snoop through your traffic and insert their own ads. They can deploy systems that remove encryption so they can better eavesdrop. They can redirect your searches to other sites. They can install surveillance software on your computers and phones. None of these are hypothetical.
They’re all things Internet service providers have done before, and they are some of the reasons the FCC tried to protect your privacy in the first place. And now they’ll be able to do all of these things in secret, without your knowledge or consent. And, of course, governments worldwide will have access to these powers. And all of that data will be at risk of hacking, either by criminals and other governments.
Telecom companies have argued that other Internet players already have these creepy powers—although they didn’t use the word “creepy”—so why should they not have them as well? It’s a valid point.
Surveillance is already the business model of the Internet, and literally hundreds of companies spy on your Internet activity against your interests and for their own profit.
Your e-mail provider already knows everything you write to your family, friends, and colleagues. Google already knows our hopes, fears, and interests, because that’s what we search for.
Your cellular provider already tracks your physical location at all times: it knows where you live, where you work, when you go to sleep at night, when you wake up in the morning, and—because everyone has a smartphone—who you spend time with and who you sleep with.
And some of the things these companies do with that power is no less creepy. Facebook has run experiments in manipulating your mood by changing what you see on your news feed. Uber used its ride data to identify one-night stands. Even Sony once installed spyware on customers’ computers to try and detect if they copied music files.
Aside from spying for profit, companies can spy for other purposes. Uber has already considered using data it collects to intimidate a journalist. Imagine what an Internet service provider can do with the data it collects: against politicians, against the media, against rivals.
Of course the telecom companies want a piece of the surveillance capitalism pie. Despite dwindling revenues, increasing use of ad blockers, and increases in clickfraud, violating our privacy is still a profitable business—especially if it’s done in secret.
The bigger question is: why do we allow for-profit corporations to create our technological future in ways that are optimized for their profits and anathema to our own interests?
When markets work well, different companies compete on price and features, and society collectively rewards better products by purchasing them. This mechanism fails if there is no competition, or if rival companies choose not to compete on a particular feature. It fails when customers are unable to switch to competitors. And it fails when what companies do remains secret.
Unlike service providers like Google and Facebook, telecom companies are infrastructure that requires government involvement and regulation. The practical impossibility of consumers learning the extent of surveillance by their Internet service providers, combined with the difficulty of switching them, means that the decision about whether to be spied on should be with the consumer and not a telecom giant. That this new bill reverses that is both wrong and harmful.
Today, technology is changing the fabric of our society faster than at any other time in history. We have big questions that we need to tackle: not just privacy, but questions of freedom, fairness, and liberty. Algorithms are making decisions about policing, healthcare.
Driverless vehicles are making decisions about traffic and safety. Warfare is increasingly being fought remotely and autonomously. Censorship is on the rise globally. Propaganda is being promulgated more efficiently than ever. These problems won’t go away. If anything, the Internet of things and the computerization of every aspect of our lives will make it worse.
In today’s political climate, it seems impossible that Congress would legislate these things to our benefit. Right now, regulatory agencies such as the FTC and FCC are our best hope to protect our privacy and security against rampant corporate power. That Congress has decided to reduce that power leaves us at enormous risk.
It’s too late to do anything about this bill—Trump will certainly sign it—but we need to be alert to future bills that reduce our privacy and security.
This post previously appeared on the Guardian.
EDITED TO ADD: Former FCC Commissioner Tom Wheeler wrote a good op-ed on the subject. And here’s an essay laying out what this all means to the average Internet user.
EDITED TO ADD (4/12): States are stepping in.
Last month at the RSA Conference, I saw a lot of companies selling security incident response automation. Their promise was to replace people with computers —sometimes with the addition of machine learning or other artificial intelligence techniques —and to respond to attacks at computer speeds.
While this is a laudable goal, there’s a fundamental problem with doing this in the short term. You can only automate what you’re certain about, and there is still an enormous amount of uncertainty in cybersecurity. Automation has its place in incident response, but the focus needs to be on making the people effective, not on replacing them— security orchestration, not automation.
This isn’t just a choice of words —it’s a difference in philosophy. The US military went through this in the 1990s. What was called the Revolution in Military Affairs (RMA) was supposed to change how warfare was fought. Satellites, drones and battlefield sensors were supposed to give commanders unprecedented information about what was going on, while networked soldiers and weaponry would enable troops to coordinate to a degree never before possible. In short, the traditional fog of war would be replaced by perfect information, providing certainty instead of uncertainty. They, too, believed certainty would fuel automation and, in many circumstances, allow technology to replace people.
Of course, it didn’t work out that way. The US learned in Afghanistan and Iraq that there are a lot of holes in both its collection and coordination systems. Drones have their place, but they can’t replace ground troops. The advances from the RMA brought with them some enormous advantages, especially against militaries that didn’t have access to the same technologies, but never resulted in certainty. Uncertainty still rules the battlefield, and soldiers on the ground are still the only effective way to control a region of territory.
But along the way, we learned a lot about how the feeling of certainty affects military thinking. Last month, I attended a lecture on the topic by H.R. McMaster. This was before he became President Trump’s national security advisor-designate. Then, he was the director of the Army Capabilities Integration Center. His lecture touched on many topics, but at one point he talked about the failure of the RMA. He confirmed that military strategists mistakenly believed that data would give them certainty. But he took this change in thinking further, outlining the ways this belief in certainty had repercussions in how military strategists thought about modern conflict.
McMaster’s observations are directly relevant to Internet security incident response. We too have been led to believe that data will give us certainty, and we are making the same mistakes that the military did in the 1990s. In a world of uncertainty, there’s a premium on understanding, because commanders need to figure out what’s going on. In a world of certainty, knowing what’s going on becomes a simple matter of data collection.
I see this same fallacy in Internet security. Many companies exhibiting at the RSA Conference promised to collect and display more data and that the data will reveal everything. This simply isn’t true. Data does not equal information, and information does not equal understanding. We need data, but we also must prioritize understanding the data we have over collecting ever more data. Much like the problems with bulk surveillance, the “collect it all” approach provides minimal value over collecting the specific data that’s useful.
In a world of uncertainty, the focus is on execution. In a world of certainty, the focus is on planning. I see this manifesting in Internet security as well. My own Resilient Systems —now part of IBM Security— allows incident response teams to manage security incidents and intrusions. While the tool is useful for planning and testing, its real focus is always on execution.
Uncertainty demands initiative, while certainty demands synchronization. Here, again, we are heading too far down the wrong path. The purpose of all incident response tools should be to make the human responders more effective. They need both the ability and the capability to exercise it effectively.
When things are uncertain, you want your systems to be decentralized. When things are certain, centralization is more important. Good incident response teams know that decentralization goes hand in hand with initiative. And finally, a world of uncertainty prioritizes command, while a world of certainty prioritizes control. Again, effective incident response teams know this, and effective managers aren’t scared to release and delegate control.
Like the US military, we in the incident response field have shifted too much into the world of certainty. We have prioritized data collection, preplanning, synchronization, centralization and control. You can see it in the way people talk about the future of Internet security, and you can see it in the products and services offered on the show floor of the RSA Conference.
Automation, too, is fixed. Incident response needs to be dynamic and agile, because you are never certain and there is an adaptive, malicious adversary on the other end. You need a response system that has human controls and can modify itself on the fly. Automation just doesn’t allow a system to do that to the extent that’s needed in today’s environment. Just as the military shifted from trying to replace the soldier to making the best soldier possible, we need to do the same.
For some time, I have been talking about incident response in terms of OODA loops. This is a way of thinking about real-time adversarial relationships, originally developed for airplane dogfights, but much more broadly applicable. OODA stands for observe-orient-decide-act, and it’s what people responding to a cybersecurity incident do constantly, over and over again. We need tools that augment each of those four steps. These tools need to operate in a world of uncertainty, where there is never enough data to know everything that is going on. We need to prioritize understanding, execution, initiative, decentralization and command.
At the same time, we’re going to have to make all of this scale. If anything, the most seductive promise of a world of certainty and automation is that it allows defense to scale. The problem is that we’re not there yet. We can automate and scale parts of IT security, such as antivirus, automatic patching and firewall management, but we can’t yet scale incident response. We still need people. And we need to understand what can be automated and what can’t be.
The word I prefer is orchestration. Security orchestration represents the union of people, process and technology. It’s computer automation where it works, and human coordination where that’s necessary. It’s networked systems giving people understanding and capabilities for execution. It’s making those on the front lines of incident response the most effective they can be, instead of trying to replace them. It’s the best approach we have for cyberdefense.
Automation has its place. If you think about the product categories where it has worked, they’re all areas where we have pretty strong certainty. Automation works in antivirus, firewalls, patch management and authentication systems. None of them is perfect, but all those systems are right almost all the time, and we’ve developed ancillary systems to deal with it when they’re wrong.
Automation fails in incident response because there’s too much uncertainty. Actions can be automated once the people understand what’s going on, but people are still required. For example, IBM’s Watson for Cyber Security provides insights for incident response teams based on its ability to ingest and find patterns in an enormous amount of freeform data. It does not attempt a level of understanding necessary to take people out of the equation.
From within an orchestration model, automation can be incredibly powerful. But it’s the human-centric orchestration model— the dashboards, the reports, the collaboration— that makes automation work. Otherwise, you’re blindly trusting the machine. And when an uncertain process is automated, the results can be dangerous.
Technology continues to advance, and this is all a changing target. Eventually, computers will become intelligent enough to replace people at real-time incident response. My guess, though, is that computers are not going to get there by collecting enough data to be certain. More likely, they’ll develop the ability to exhibit understanding and operate in a world of uncertainty. That’s a much harder goal.
Yes, today, this is all science fiction. But it’s not stupid science fiction, and it might become reality during the lifetimes of our children. Until then, we need people in the loop. Orchestration is a way to achieve that.
This essay previously appeared on the Security Intelligence blog.
Kalyna is a block cipher that became a Ukrainian national standard in 2015. It supports block and key sizes of 128, 256, and 512 bits. Its structure looks like AES but optimized for 64-bit CPUs, and it has a complicated key schedule. Rounds range from 10-18, depending on block and key sizes.
There is some mention of cryptanalysis on reduced-round versions in the Wikipedia entry. And here are the other submissions to the standard.
Last Monday, the TSA announced a peculiar new security measure to take effect within 96 hours. Passengers flying into the US on foreign airlines from eight Muslim countries would be prohibited from carrying aboard any electronics larger than a smartphone. They would have to be checked and put into the cargo hold. And now the UK is following suit.
It’s difficult to make sense of this as a security measure, particularly at a time when many people question the veracity of government orders, but other explanations are either unsatisfying or damning.
So let’s look at the security aspects of this first. Laptop computers aren’t inherently dangerous, but they’re convenient carrying boxes. This is why, in the past, TSA officials have demanded passengers turn their laptops on: to confirm that they’re actually laptops and not laptop cases emptied of their electronics and then filled with explosives.
Forcing a would-be bomber to put larger laptops in the plane’s hold is a reasonable defense against this threat, because it increases the complexity of the plot. Both the shoe-bomber Richard Reid and the underwear bomber Umar Farouk Abdulmutallab carried crude bombs aboard their planes with the plan to set them off manually once aloft. Setting off a bomb in checked baggage is more work, which is why we don’t see more midair explosions like Pan Am Flight 103 over Lockerbie, Scotland, in 1988.
Security measures that restrict what passengers can carry onto planes are not unprecedented either. Airport security regularly responds to both actual attacks and intelligence regarding future attacks. After the liquid bombers were captured in 2006, the British banned all carry-on luggage except passports and wallets. I remember talking with a friend who traveled home from London with his daughters in those early weeks of the ban. They reported that airport security officials confiscated every tube of lip balm they tried to hide.
Similarly, the US started checking shoes after Reid, installed full-body scanners after Abdulmutallab and restricted liquids in 2006. But all of those measures were global, and most lessened in severity as the threat diminished.
This current restriction implies some specific intelligence of a laptop-based plot and a temporary ban to address it. However, if that’s the case, why only certain non-US carriers? And why only certain airports? Terrorists are smart enough to put a laptop bomb in checked baggage from the Middle East to Europe and then carry it on from Europe to the US.
Why not require passengers to turn their laptops on as they go through security? That would be a more effective security measure than forcing them to check them in their luggage. And lastly, why is there a delay between the ban being announced and it taking effect?
Even more confusing, the New York Times reported that “officials called the directive an attempt to address gaps in foreign airport security, and said it was not based on any specific or credible threat of an imminent attack.” The Department of Homeland Security FAQ page makes this general statement, “Yes, intelligence is one aspect of every security-related decision,” but doesn’t provide a specific security threat. And yet a report from the UK states the ban “follows the receipt of specific intelligence reports.”
Of course, the details are all classified, which leaves all of us security experts scratching our heads. On the face of it, the ban makes little sense.
One analysis painted this as a protectionist measure targeted at the heavily subsidized Middle Eastern airlines by hitting them where it hurts the most: high-paying business class travelers who need their laptops with them on planes to get work done. That reasoning makes more sense than any security-related explanation, but doesn’t explain why the British extended the ban to UK carriers as well. Or why this measure won’t backfire when those Middle Eastern countries turn around and ban laptops on American carriers in retaliation. And one aviation official told CNN that an intelligence official informed him it was not a “political move.”
In the end, national security measures based on secret information require us to trust the government. That trust is at historic low levels right now, so people both in the US and other countries are rightly skeptical of the official unsatisfying explanations. The new laptop ban highlights this mistrust.
This essay previously appeared on CNN.com.
EDITED TO ADD: Here are two essays that look at the possible political motivations, and fallout, of this ban. And the EFF rightly points out that letting a laptop out of your hands and sight is itself a security risk—for the passenger.
EDITED TO ADD (4/12): This article suggests that the ban is because of a plot to hide explosives in iPads.
Available on eBay.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Over the past few months, I have been watching my blog comments decline in civility. I blame it in part on the contentious US election and its aftermath. It’s also a consequence of not requiring visitors to register in order to post comments, and of our tolerance for impassioned conversation. Whatever the causes, I’m tired of it. Partisan nastiness is driving away visitors who might otherwise have valuable insights to offer.
I have been engaging in more active comment moderation. What that means is that I have been quicker to delete posts that are rude, insulting, or off-topic. This is my blog. I consider the comments section as analogous to a gathering at my home. It’s not a town square. Everyone is expected to be polite and respectful, and if you’re an unpleasant guest, I’m going to ask you to leave. Your freedom of speech does not compel me to publish your words.
I like people who disagree with me. I like debate. I even like arguments. But I expect everyone to behave as if they’ve been invited into my home.
I realize that I sometimes express opinions on political matters; I find they are relevant to security at all levels. On those posts, I welcome on-topic comments regarding those opinions. I don’t welcome people pissing and moaning about the fact that I’ve expressed my opinion on something other than security technology. As I said, it’s my blog.
So, please… Assume good faith. Be polite. Minimize profanity. Argue facts, not personalities. Stay on topic.
Schneier on Security is not a professional operation. There’s no advertising, so no revenue to hire staff. My part-time moderator—paid out of my own pocket—and I do what we can when we can. If you see a comment that’s spam, or off-topic, or an ad hominem attack, flag it and be patient. Don’t reply or engage; we’ll get to it. And we won’t always post an explanation when we delete something.
My own stance on privacy and anonymity means that I’m not going to require commenters to register a name or e-mail address, so that isn’t an option. And I really don’t want to disable comments.
I dislike having to deal with this problem. I’ve been proud and happy to see how interesting and useful the comments section has been all these years. I’ve watched many blogs and discussion groups descend into toxicity as a result of trolls and drive-by ideologues derailing the conversations of regular posters. I’m not going to let that happen here.
There are more CIA documents up on WikiLeaks. It seems to be mostly MacOS and iOS—including exploits that are installed on the hardware before they’re delivered to the customer.
EDITED TO ADD (3/25): Apple claims that the vulnerabilities are all fixed. Note that there are almost certainly other Apple vulnerabilities in the documents still to be released.
Turkish hackers are threatening to erase millions of iCloud user accounts unless Apple pays a ransom.
This is a weird story, and I’m skeptical of some of the details. Presumably Apple has decided that it’s smarter to spend the money on secure backups and other security measures than to pay the ransom. But we’ll see how this unfolds.
Every year, the NSA has a competition for the best cybersecurity paper. Winners get to go to the NSA to pick up the award. (Warning: you will almost certainly be fingerprinted while you’re there.)
Submission guidelines and nomination page.
I have written a paper with Orin Kerr on encryption workarounds. Our goal wasn’t to make any policy recommendations. (That was a good thing, since we probably don’t agree on any.) Our goal was to present a taxonomy of different workarounds, and discuss their technical and legal characteristics and complications.
Abstract: The widespread use of encryption has triggered a new step in many criminal investigations: the encryption workaround. We define an encryption workaround as any lawful government effort to reveal an unencrypted version of a target’s data that has been concealed by encryption. This essay provides an overview of encryption workarounds. It begins with a taxonomy of the different ways investigators might try to bypass encryption schemes. We classify six kinds of workarounds: find the key, guess the key, compel the key, exploit a flaw in the encryption software, access plaintext while the device is in use, and locate another plaintext copy. For each approach, we consider the practical, technological, and legal hurdles raised by its use.
The remainder of the essay develops lessons about encryption workarounds and the broader public debate about encryption in criminal investigations. First, encryption workarounds are inherently probabilistic. None work every time, and none can be categorically ruled out every time. Second, the different resources required for different workarounds will have significant distributional effects on law enforcement. Some techniques are inexpensive and can be used often by many law enforcement agencies; some are sophisticated or expensive and likely to be used rarely and only by a few. Third, the scope of legal authority to compel third-party assistance will be a continuing challenge. And fourth, the law governing encryption workarounds remains uncertain and underdeveloped. Whether encryption will be a game-changer or a speed bump depends on both technological change and the resolution of important legal questions that currently remain unanswered.
The paper is finished, but we’ll be revising it once more before final publication. Comments are appreciated.
Here is a listing of all the documents that the NSA has in its archives that are dated earlier than 1930.
WikiLeaks has started publishing a large collection of classified CIA documents, including information on several—possibly many—unpublished (i.e., zero-day) vulnerabilities in computing equipment used by Americans. Despite assurances that the US government prioritizes defense over offense, it seems that the CIA was hoarding vulnerabilities. (It’s not just the CIA; last year we learned that the NSA is, too.)
Publishing those vulnerabilities into the public means that they’ll get fixed, but it also means that they’ll be used by criminals and other governments in the time period between when they’re published and when they’re patched. WikiLeaks has said that it’s going to do the right thing and privately disclose those vulnerabilities to the companies first.
This process seems to be hitting some snags:
This week, Assange sent an email to Apple, Google, Microsoft and all the companies mentioned in the documents. But instead of reporting the bugs or exploits found in the leaked CIA documents it has in its possession, WikiLeaks made demands, according to multiple sources familiar with the matter who spoke on condition of anonymity.
WikiLeaks included a document in the email, requesting the companies to sign off on a series of conditions before being able to receive the actual technical details to deploy patches, according to sources. It’s unclear what the conditions are, but a source mentioned a 90-day disclosure deadline, which would compel companies to commit to issuing a patch within three months.
I’m okay with a 90-day window; that seems reasonable. But I have no idea what the other conditions are, and how onerous they are.
Honestly, at this point the CIA should do the right thing and disclose all the vulnerabilities to the companies. They’re burned as CIA attack tools. I have every confidence that Russia, China, and several other countries can hack WikiLeaks and get their hands on a copy. By now, their primary value is for defense. The CIA should bypass WikiLeaks and get the vulnerabilities fixed as soon as possible.
This is William Friedman’s highly annotated copy of Herbert Yardley’s book, The American Black Chamber.
Interesting research: “A Study of MAC Address Randomization in Mobile Devices When it Fails“:
Abstract: Media Access Control (MAC) address randomization is a privacy technique whereby mobile devices rotate through random hardware addresses in order to prevent observers from singling out their traffic or physical location from other nearby devices. Adoption of this technology, however, has been sporadic and varied across device manufacturers. In this paper, we present the first wide-scale study of MAC address randomization in the wild, including a detailed breakdown of different randomization techniques by operating system, manufacturer, and model of device. We then identify multiple flaws in these implementations which can be exploited to defeat randomization as performed by existing devices. First, we show that devices commonly make improper use of randomization by sending wireless frames with the true, global address when they should be using a randomized address. We move on to extend the passive identification techniques of Vanhoef et al. to effectively defeat randomization in 96% of Android phones. Finally, we show a method that can be used to track 100% of devices using randomization, regardless of manufacturer, by exploiting a previously unknown flaw in the way existing wireless chipsets handle low-level control frames.
Basically, iOS and Android phones are not very good at randomizing their MAC addresses. And tricks with level-2 control frames can exploit weaknesses in their chipsets.
News from the South Atlantic:
While the outlook is good at present, it is too early to predict what the final balance of this season will be. The sector is totally aware that the 2016 harvest started well, but then it registered a strong decline.
Last year only 60,315 tonnes of Illex squid were landed, well below the 126,670 tonnes landed in 2015 and the 168,729 tonnes recorded in 2014.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
The article is right; this is frighteningly good.
Researchers have demonstrated using Intel’s Software Guard Extensions to hide malware and steal cryptographic keys from inside SGX’s protected enclave:
Malware Guard Extension: Using SGX to Conceal Cache Attacks
Abstract:In modern computer systems, user processes are isolated from each other by the operating system and the hardware. Additionally, in a cloud scenario it is crucial that the hypervisor isolates tenants from other tenants that are co-located on the same physical machine. However, the hypervisor does not protect tenants against the cloud provider and thus the supplied operating system and hardware. Intel SGX provides a mechanism that addresses this scenario. It aims at protecting user-level software from attacks from other processes, the operating system, and even physical attackers.
In this paper, we demonstrate fine-grained software-based side-channel attacks from a malicious SGX enclave targeting co-located enclaves. Our attack is the first malware running on real SGX hardware, abusing SGX protection features to conceal itself. Furthermore, we demonstrate our attack both in a native environment and across multiple Docker containers. We perform a Prime+Probe cache side-channel attack on a co-located SGX enclave running an up-to-date RSA implementation that uses a constant-time multiplication primitive. The attack works although in SGX enclaves there are no timers, no large pages, no physical addresses, and no shared memory. In a semi-synchronous attack, we extract 96% of an RSA private key from a single trace. We extract the full RSA private key in an automated attack from 11 traces within 5 minutes.
News article.
CloudPets are an Internet-connected stuffed animals that allow children and parents to send each other voice messages. Last week, we learned that Spiral Toys had such poor security that it exposed 800,000 customer credentials, and two million audio recordings.
As we’ve seen time and time again in the last couple of years, so-called “smart” devices connected to the internet—what is popularly known as the Internet of Things or IoT—are often left insecure or are easily hackable, and often leak sensitive data. There will be a time when IoT developers and manufacturers learn the lesson and make secure by default devices, but that time hasn’t come yet. So if you are a parent who doesn’t want your loving messages with your kids leaked online, you might want to buy a good old fashioned teddy bear that doesn’t connect to a remote, insecure server.
That’s about right. This is me on that issue from 2014.
Some good election security news for a change: France is dropping its plans for remote Internet voting, because it’s concerned about hacking.
I am part of this very interesting project:
For many users, blog posts on how to install Signal, massive guides to protecting your digital privacy, and broad statements like “use Tor”—all offered in good faith and with the best of intentions—can be hard to understand or act upon. If we want to truly secure civil society from digital attacks and empower communities in their to fight to protect their rights, we’ve got to recognize that digital security is largely a human problem, not a technical one. Taking cues from the experiences of the deeply knowledgeable global digital security training community, the Digital Security Exchange will seek to make it easier for trainers and experts to connect directly to the communities in the U.S.—sharing expertise, documentation, and best practices—in order to increase capacity and security across the board.
Brian Krebs posts a video advertisement for Philadelphia, a ransomware package that you can purchase.
Useful best practices for malware writers, courtesy of the CIA. Seems like a lot of good advice.
General:
- DO obfuscate or encrypt all strings and configuration data that directly relate to tool functionality. Consideration should be made to also only de-obfuscating strings in-memory at the moment the data is needed. When a previously de-obfuscated value is no longer needed, it should be wiped from memory.
Rationale: String data and/or configuration data is very useful to analysts and reverse-engineers.
- DO NOT decrypt or de-obfuscate all string data or configuration data immediately upon execution.
Rationale: Raises the difficulty for automated dynamic analysis of the binary to find sensitive data.
- DO explicitly remove sensitive data (encryption keys, raw collection data, shellcode, uploaded modules, etc) from memory as soon as the data is no longer needed in plain-text form. DO NOT RELY ON THE OPERATING SYSTEM TO DO THIS UPON TERMINATION OF EXECUTION.
Rationale: Raises the difficulty for incident response and forensics review.
- DO utilize a deployment-time unique key for obfuscation/de-obfuscation of sensitive strings and configuration data.
Rationale: Raises the difficulty of analysis of multiple deployments of the same tool.
- DO strip all debug symbol information, manifests(MSVC artifact), build paths, developer usernames from the final build of a binary.
Rationale: Raises the difficulty for analysis and reverse-engineering, and removes artifacts used for attribution/origination.
- DO strip all debugging output (e.g. calls to printf(), OutputDebugString(), etc) from the final build of a tool.
Rationale: Raises the difficulty for analysis and reverse-engineering.
- DO NOT explicitly import/call functions that is not consistent with a tool’s overt functionality (i.e. WriteProcessMemory, VirtualAlloc, CreateRemoteThread, etc – for binary that is supposed to be a notepad replacement).
Rationale: Lowers potential scrutiny of binary and slightly raises the difficulty for static analysis and reverse-engineering.
- DO NOT export sensitive function names; if having exports are required for the binary, utilize an ordinal or a benign function name.
Rationale: Raises the difficulty for analysis and reverse-engineering.
- DO NOT generate crashdump files, coredump files, “Blue” screens, Dr Watson or other dialog pop-ups and/or other artifacts in the event of a program crash. DO attempt to force a program crash during unit testing in order to properly verify this.
Rationale: Avoids suspicion by the end user and system admins, and raises the difficulty for incident response and reverse-engineering.
- DO NOT perform operations that will cause the target computer to be unresponsive to the user (e.g. CPU spikes, screen flashes, screen “freezing”, etc).
Rationale: Avoids unwanted attention from the user or system administrator to tool’s existence and behavior.
- DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool.
Rationale: Shortens overall “time on air” not only to get the tool on target, but to time to execute functionality and clean-up.
- DO provide a means to completely “uninstall”/”remove” implants, function hooks, injected threads, dropped files, registry keys, services, forked processes, etc whenever possible. Explicitly document (even if the documentation is “There is no uninstall for this
“) the procedures, permissions required and side effects of removal. Rationale: Avoids unwanted data left on target. Also, proper documentation allows operators to make better operational risk assessment and fully understand the implications of using a tool or specific feature of a tool.
- DO NOT leave dates/times such as compile timestamps, linker timestamps, build times, access times, etc. that correlate to general US core working hours (i.e. 8am-6pm Eastern time)
Rationale: Avoids direct correlation to origination in the United States.
- DO NOT leave data in a binary file that demonstrates CIA, USG, or its witting partner companies involvement in the creation or use of the binary/tool.
Rationale: Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
- DO NOT have data that contains CIA and USG cover terms, compartments, operation code names or other CIA and USG specific terminology in the binary.
Rationale: Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
- DO NOT have “dirty words” (see dirty word list – TBD) in the binary.
Rationale: Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question.
Networking:
- DO use end-to-end encryption for all network communications. NEVER use networking protocols which break the end-to-end principle with respect to encryption of payloads.
Rationale: Stifles network traffic analysis and avoids exposing operational/collection data.
- DO NOT solely rely on SSL/TLS to secure data in transit.
Rationale: Numerous man-in-middle attack vectors and publicly disclosed flaws in the protocol.
- DO NOT allow network traffic, such as C2 packets, to be re-playable.
Rationale: Protects the integrity of operational equities.
- DO use ITEF RFC compliant network protocols as a blending layer. The actual data, which must be encrypted in transit across the network, should be tunneled through a well known and standardized protocol (e.g. HTTPS)
Rationale: Custom protocols can stand-out to network analysts and IDS filters.
- DO NOT break compliance of an RFC protocol that is being used as a blending layer. (i.e. Wireshark should not flag the traffic as being broken or mangled)
Rationale: Broken network protocols can easily stand-out in IDS filters and network analysis.
- DO use variable size and timing (aka jitter) of beacons/network communications. DO NOT predicatively send packets with a fixed size and timing.
Rationale: Raises the difficulty of network analysis and correlation of network activity.
- DO proper cleanup of network connections. DO NOT leave around stale network connections.
Rationale: Raises the difficulty of network analysis and incident response.
Disk I/O:
- DO explicitly document the “disk forensic footprint” that could be potentially created by various features of a binary/tool on a remote target.
Rationale: Enables better operational risk assessments with knowledge of potential file system forensic artifacts.
- DO NOT read, write and/or cache data to disk unnecessarily. Be cognizant of 3rd party code that may implicitly write/cache data to disk.
Rationale: Lowers potential for forensic artifacts and potential signatures.
- DO NOT write plain-text collection data to disk.
Rationale: Raises difficulty of incident response and forensic analysis.
- DO encrypt all data written to disk.
Rationale: Disguises intent of file (collection, sensitive code, etc) and raises difficulty of forensic analysis and incident response.
- DO utilize a secure erase when removing a file from disk that wipes at a minimum the file’s filename, datetime stamps (create, modify and access) and its content. (Note: The definition of “secure erase” varies from filesystem to filesystem, but at least a single pass of zeros of the data should be performed. The emphasis here is on removing all filesystem artifacts that could be useful during forensic analysis)
Rationale: Raises difficulty of incident response and forensic analysis.
- DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator.
Rationale: Avoids unwanted attention from the user or system administrator to tool’s existence and behavior.
- DO NOT use a “magic header/footer” for encrypted files written to disk. All encrypted files should be completely opaque data files.
Rationale: Avoids signature of custom file format’s magic values.
- DO NOT use hard-coded filenames or filepaths when writing files to disk. This must be configurable at deployment time by the operator.
Rationale: Allows operator to choose the proper filename that fits with in the operational target.
- DO have a configurable maximum size limit and/or output file count for writing encrypted output files.
Rationale: Avoids situations where a collection task can get out of control and fills the target’s disk; which will draw unwanted attention to the tool and/or the operation.
Dates/Time:
- DO use GMT/UTC/Zulu as the time zone when comparing date/time.
Rationale: Provides consistent behavior and helps ensure “triggers/beacons/etc” fire when expected.
- DO NOT use US-centric timestamp formats such as MM-DD-YYYY. YYYYMMDD is generally preferred.
Rationale: Maintains consistency across tools, and avoids associations with the United States.
PSP/AV:
- DO NOT assume a “free” PSP product is the same as a “retail” copy. Test on all SKUs where possible.
Rationale: While the PSP/AV product may come from the same vendor and appear to have the same features despite having different SKUs, they are not. Test on all SKUs where possible.
- DO test PSPs with live (or recently live) internet connection where possible. NOTE: This can be a risk vs gain balance that requires careful consideration and should not be haphazardly done with in-development software. It is well known that PSP/AV products with a live internet connection can and do upload samples software based varying criteria.
Rationale: PSP/AV products exhibit significant differences in behavior and detection when connected to the internet vise not.
Encryption: NOD publishes a Cryptography standard: “NOD Cryptographic Requirements v1.1 TOP SECRET.pdf“. Besides the guidance provided here, the requirements in that document should also be met.
The crypto requirements are complex and interesting. I’ll save commenting on them for another post.
News article.
The Department of Justice is dropping all charges in a child-porn case rather than release the details of a hack against Tor.
Here are some squid cooking tips.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Here’s a video interview I did at RSA on the Internet of Things and security.
A decade ago, I wrote about the death of ephemeral conversation. As computers were becoming ubiquitous, some unintended changes happened, too. Before computers, what we said disappeared once we’d said it. Neither face-to-face conversations nor telephone conversations were routinely recorded. A permanent communication was something different and special; we called it correspondence.
The Internet changed this. We now chat by text message and e-mail, on Facebook and on Instagram. These conversations—with friends, lovers, colleagues, fellow employees—all leave electronic trails. And while we know this intellectually, we haven’t truly internalized it. We still think of conversation as ephemeral, forgetting that we’re being recorded and what we say has the permanence of correspondence.
That our data is used by large companies for psychological manipulation —we call this advertising— is well known. So is its use by governments for law enforcement and, depending on the country, social control. What made the news over the past year were demonstrations of how vulnerable all of this data is to hackers and the effects of having it hacked, copied, and then published online. We call this doxing.
Doxing isn’t new, but it has become more common. It’s been perpetrated against corporations, law firms, individuals, the NSA and—just this week—the CIA. It’s largely harassment and not whistleblowing, and it’s not going to change anytime soon. The data in your computer and in the cloud are, and will continue to be, vulnerable to hacking and publishing online. Depending on your prominence and the details of this data, you may need some new strategies to secure your private life.
There are two basic ways hackers can get at your e-mail and private documents. One way is to guess your password. That’s how hackers got their hands on personal photos of celebrities from iCloud in 2014.
How to protect yourself from this attack is pretty obvious. First, don’t choose a guessable password. This is more than not using “password1” or “qwerty”; most easily memorizable passwords are guessable. My advice is to generate passwords you have to remember by using either the XKCD scheme or the Schneier scheme, and to use large random passwords stored in a password manager for everything else.
Second, turn on two-factor authentication where you can, like Google’s 2-Step Verification. This adds another step besides just entering a password, such as having to type in a one-time code that’s sent to your mobile phone. And third, don’t reuse the same password on any sites you actually care about.
You’re not done, though. Hackers have accessed accounts by exploiting the “secret question” feature and resetting the password. That was how Sarah Palin’s e-mail account was hacked in 2008. The problem with secret questions is that they’re not very secret and not very random. My advice is to refuse to use those features. Type randomness into your keyboard, or choose a really random answer and store it in your password manager.
Finally, you also have to stay alert to phishing attacks, where a hacker sends you an enticing e-mail with a link that sends you to a web page that looks almost like the expected page, but which actually isn’t. This sort of thing can bypass two-factor authentication, and is almost certainly what tricked John Podesta and Colin Powell.
The other way hackers can get at your personal stuff is by breaking in to the computers the information is stored on. This is how the Russians got into the Democratic National Committee’s network and how a lone hacker got into the Panamanian law firm Mossack Fonseca. Sometimes individuals are targeted, as when China hacked Google in 2010 to access the e-mail accounts of human rights activists. Sometimes the whole network is the target, and individuals are inadvertent victims, as when thousands of Sony employees had their e-mails published by North Korea in 2014.
Protecting yourself is difficult, because it often doesn’t matter what you do. If your e-mail is stored with a service provider in the cloud, what matters is the security of that network and that provider. Most users have no control over that part of the system. The only way to truly protect yourself is to not keep your data in the cloud where someone could get to it. This is hard. We like the fact that all of our e-mail is stored on a server somewhere and that we can instantly search it. But that convenience comes with risk. Consider deleting old e-mail, or at least downloading it and storing it offline on a portable hard drive. In fact, storing data offline is one of the best things you can do to protect it from being hacked and exposed. If it’s on your computer, what matters is the security of your operating system and network, not the security of your service provider.
Consider this for files on your own computer. The more things you can move offline, the safer you’ll be.
E-mail, no matter how you store it, is vulnerable. If you’re worried about your conversations becoming public, think about an encrypted chat program instead, such as Signal, WhatsApp or Off-the-Record Messaging. Consider using communications systems that don’t save everything by default.
None of this is perfect, of course. Portable hard drives are vulnerable when you connect them to your computer. There are ways to jump air gaps and access data on computers not connected to the Internet. Communications and data files you delete might still exist in backup systems somewhere—either yours or those of the various cloud providers you’re using. And always remember that there’s always another copy of any of your conversations stored with the person you’re conversing with. Even with these caveats, though, these measures will make a big difference.
When secrecy is truly paramount, go back to communications systems that are still ephemeral. Pick up the telephone and talk. Meet face to face. We don’t yet live in a world where everything is recorded and everything is saved, although that era is coming. Enjoy the last vestiges of ephemeral conversation while you still can.
This essay originally appeared in the Washington Post.
Google’s Project Zero is serious about releasing the details of security vulnerabilities 90 days after they alert the vendors, even if they’re unpatched. It just exposed a nasty vulnerability in Microsoft’s browsers.
This is the second unpatched Microsoft vulnerability it exposed last week.
I’m a big fan of responsible disclosure. The threat to publish vulnerabilities is what puts pressure on vendors to patch their systems. But I wonder what competitive pressure is on the Google team to find embarrassing vulnerabilities in competitors’ products.
If I had to guess right now, I’d say the documents came from an outsider and not an insider. My reasoning: One, there is absolutely nothing illegal in the contents of any of this stuff. It’s exactly what you’d expect the CIA to be doing in cyberspace. That makes the whistleblower motive less likely. And two, the documents are a few years old, making this more like the Shadow Brokers than Edward Snowden. An internal leaker would leak quickly. A foreign intelligence agency—like the Russians—would use the documents while they were fresh and valuable, and only expose them when the embarrassment value was greater.
James Lewis agrees:
But James Lewis, an expert on cybersecurity at the Center for Strategic and International Studies in Washington, raised another possibility: that a foreign state, most likely Russia, stole the documents by hacking or other means and delivered them to WikiLeaks, which may not know how they were obtained. Mr. Lewis noted that, according to American intelligence agencies, Russia hacked Democratic targets during the presidential campaign and gave thousands of emails to WikiLeaks for publication.
To be sure, neither of us has any idea. We’re all guessing.
To the documents themselves, I really liked these best practice coding guidelines for malware, and these crypto requirements.
I am mentioned in the latter document:
Cryptographic jargon is utilized throughout this document. This jargon has precise and subtle meaning and should not be interpreted without careful understanding of the subject matter. Suggested reading includes Practical Cryptography by Schneier and Ferguson, RFCs 4251 and 4253, RFCs 5246 and 5430, and Handbook of Applied Cryptography by Menezes, van Oorschot, and Vanstone.
EDITED TO ADD: Herbert Lin comments.
The most damning thing I’ve seen so far is yet more evidence that—despite assurances to the contrary—the US intelligence community hoards vulnerabilities in common Internet products and uses them for offensive purposes.
EDITED TO ADD (3/9): The New York Times is reporting that the CIA suspects an insider:
Investigators say that the leak was the work not of a hostile foreign power like Russia but of a disaffected insider, as WikiLeaks suggested when it released the documents Tuesday. The F.B.I. was preparing to interview anyone who had access to the information, a group likely to include at least a few hundred people, and possibly more than a thousand.
An intelligence official said the information, much of which appeared to be technical documents, may have come from a server outside the C.I.A. managed by a contractor. But neither he nor a former senior intelligence official ruled out the possibility that the leaker was a C.I.A. employee.
EDITED TO ADD (3/9): WikiLeaks said that they have published less than 1% of what they have, and that they are giving affected companies an early warning of the vulnerabilities and tools that they’re publishing.
Commentary from The Intercept.
The New York Times is reporting that the US has been conducting offensive cyberattacks against North Korea, in an effort to delay its nuclear weapons program.
EDITED TO ADD (3/8): Commentary.
WikiLeaks just released a cache of 8,761 classified CIA documents from 2012 to 2016, including details of its offensive Internet operations.
I have not read through any of them yet. If you see something interesting, tell us in the comments.
EDITED TO ADD: There’s a lot in here. Many of the hacking tools are redacted, with the tar files and zip archives replaced with messages like:
::: THIS ARCHIVE FILE IS STILL BEING EXAMINED BY WIKILEAKS. :::
::: IT MAY BE RELEASED IN THE NEAR FUTURE. WHAT FOLLOWS IS :::
::: AN AUTOMATICALLY GENERATED LIST OF ITS CONTENTS: :::
Hopefully we’ll get them eventually. The documents say that the CIA—and other intelligence services—can bypass Signal, WhatsApp and Telegram. It seems to be by hacking the end-user devices and grabbing the traffic before and after encryption, not by breaking the encryption.
New York Times article.
EDITED TO ADD: Some details from The Guardian:
According to the documents:
- CIA hackers targeted smartphones and computers.
- The Center for Cyber Intelligence is based at the CIA headquarters in Virginia but it has a second covert base in the US consulate in Frankfurt which covers Europe, the Middle East and Africa.
- A programme called Weeping Angel describes how to attack a Samsung F8000 TV set so that it appears to be off but can still be used for monitoring.
I just noticed this from the WikiLeaks page:
Recently, the CIA lost control of the majority of its hacking arsenal including malware, viruses, trojans, weaponized “zero day” exploits, malware remote control systems and associated documentation. This extraordinary collection, which amounts to more than several hundred million lines of code, gives its possessor the entire hacking capacity of the CIA. The archive appears to have been circulated among former U.S. government hackers and contractors in an unauthorized manner, one of whom has provided WikiLeaks with portions of the archive.
So it sounds like this cache of documents wasn’t taken from the CIA and given to WikiLeaks for publication, but has been passed around the community for a while—and incidentally some part of the cache was passed to WikiLeaks. So there are more documents out there, and others may release them in unredacted form.
Wired article. Slashdot thread. Two articles from the Washington Post.
EDITED TO ADD: This document talks about Comodo version 5.X and version 6.X. Version 6 was released in Feb 2013. Version 7 was released in Apr 2014. This gives us a time window of that page, and the cache in general. (WikiLeaks says that the documents cover 2013 to 2016.)
If these tools are a few years out of date, it’s similar to the NSA tools released by the “Shadow Brokers.” Most of us thought the Shadow Brokers were the Russians, specifically releasing older NSA tools that had diminished value as secrets. Could this be the Russians as well?
EDITED TO ADD: Nicholas Weaver comments.
EDITED TO ADD (3/8): These documents are interesting:
The CIA’s hand crafted hacking techniques pose a problem for the agency. Each technique it has created forms a “fingerprint” that can be used by forensic investigators to attribute multiple different attacks to the same entity.
This is analogous to finding the same distinctive knife wound on multiple separate murder victims. The unique wounding style creates suspicion that a single murderer is responsible. As soon one murder in the set is solved then the other murders also find likely attribution.
The CIA’s Remote Devices Branch‘s UMBRAGE group collects and maintains a substantial library of attack techniques ‘stolen’ from malware produced in other states including the Russian Federation.
With UMBRAGE and related projects the CIA cannot only increase its total number of attack types but also misdirect attribution by leaving behind the “fingerprints” of the groups that the attack techniques were stolen from.
UMBRAGE components cover keyloggers, password collection, webcam capture, data destruction, persistence, privilege escalation, stealth, anti-virus (PSP) avoidance and survey techniques.
This is being spun in the press as the CIA is pretending to be Russia. I’m not convinced that the documents support these allegations. Can someone else look at the documents. I don’t like my conclusion that WikiLeaks is using this document dump as a way to push their own bias.
Matthew Green and students speculate on what truly well-designed ransomware system could look like:
Most modern ransomware employs a cryptocurrency like Bitcoin to enable the payments that make the ransom possible. This is perhaps not the strongest argument for systems like Bitcoin—and yet it seems unlikely that Bitcoin is going away anytime soon. If we can’t solve the problem of Bitcoin, maybe it’s possible to use Bitcoin to make “more reliable” ransomware.
[…]
Recall that in the final step of the ransom process, the ransomware operator must deliver a decryption key to the victim. This step is the most fraught for operators, since it requires them to manage keys and respond to queries on the Internet. Wouldn’t it be better for operators if they could eliminate this step altogether?
[…]
At least in theory it might be possible to develop a DAO that’s funded entirely by ransomware payments—and in turn mindlessly contracts real human beings to develop better ransomware, deploy it against human targets, and…rinse repeat. It’s unlikely that such a system would be stable in the long run humans are clever and good at destroying dumb things but it might get a good run.
One of the reasons society hasn’t destroyed itself is that people with intelligence and skills tend to not be criminals for a living. If it ever became a viable career path, we’re doomed.
Longtime Internet security-policy pioneer Howard Schmidt died on Friday.
He will be missed.
The New York Times reports that Uber developed apps that identified and blocked government regulators using the app to find evidence of illegal behavior:
Yet using its app to identify and sidestep authorities in places where regulators said the company was breaking the law goes further in skirting ethical lines—and potentially legal ones, too. Inside Uber, some of those who knew about the VTOS program and how the Greyball tool was being used were troubled by it.
[…]
One method involved drawing a digital perimeter, or “geofence,” around authorities’ offices on a digital map of the city that Uber monitored. The company watched which people frequently opened and closed the app—a process internally called “eyeballing”—around that location, which signified that the user might be associated with city agencies.
Other techniques included looking at the user’s credit card information and whether that card was tied directly to an institution like a police credit union.
Enforcement officials involved in large-scale sting operations to catch Uber drivers also sometimes bought dozens of cellphones to create different accounts. To circumvent that tactic, Uber employees went to that city’s local electronics stores to look up device numbers of the cheapest mobile phones on sale, which were often the ones bought by city officials, whose budgets were not sizable.
In all, there were at least a dozen or so signifiers in the VTOS program that Uber employees could use to assess whether users were new riders or very likely city officials.
If those clues were not enough to confirm a user’s identity, Uber employees would search social media profiles and other available information online. Once a user was identified as law enforcement, Uber Greyballed him or her, tagging the user with a small piece of code that read Greyball followed by a string of numbers.
When Edward Snowden exposed the fact that the NSA does this sort of thing, I commented that the technologies will eventually become cheap enough for corporations to do it. Now, it has.
One discussion we need to have is whether or not this behavior is legal. But another, more important, discussion is whether or not it is ethical. Do we want to live in a society where corporations wield this sort of power against government? Against individuals? Because if we don’t align government against this kind of behavior, it’ll become the norm.
Squid evolved during an “evolutionary war”—the Mesozoic Marine Revolution—about 100 million years ago.
Research paper.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
This is my talk at the RSA Conference last month. It’s on regulation and the Internet of Things, along the lines of this essay.
I am slowly meandering around this as a book topic. It hasn’t quite solidified yet.
Researchers have demonstrated how a malicious piece of software in an air-gapped computer can communicate with a nearby drone using a blinking LED on the computer.
I have mixed feelings about research like this. On the one hand, it’s pretty cool. On the other hand, there’s not really anything new or novel, and it’s kind of a movie-plot threat.
Research paper.
Summer Fowler at CMU has invented a new word: prosilience:
I propose that we build operationally PROSILIENT organizations. If operational resilience, as we like to say, is risk management “all grown up,” then prosilience is resilience with consciousness of environment, self-awareness, and the capacity to evolve. It is not about being able to operate through disruption, it is about anticipating disruption and adapting before it even occurs—a proactive version of resilience. Nascent prosilient capabilities include exercises (tabletop or technical) that simulate how organizations would respond to a scenario. The goal, however, is to automate, expand, and perform continuous exercises based on real-world indicators rather than on scenarios.
I have long been a big fan of resilience as a security concept, and the property we should be aiming for. I’m not sure prosilience buys me anything new, but this is my first encounter with this new buzzword. It would certainly make for a best-selling business-book title.
Botnets have existed for at least a decade. As early as 2000, hackers were breaking into computers over the Internet and controlling them en masse from centralized systems. Among other things, the hackers used the combined computing power of these botnets to launch distributed denial-of-service attacks, which flood websites with traffic to take them down.
But now the problem is getting worse, thanks to a flood of cheap webcams, digital video recorders, and other gadgets in the “Internet of things.” Because these devices typically have little or no security, hackers can take them over with little effort. And that makes it easier than ever to build huge botnets that take down much more than one site at a time.
In October, a botnet made up of 100,000 compromised gadgets knocked an Internet infrastructure provider partially offline. Taking down that provider, Dyn, resulted in a cascade of effects that ultimately caused a long list of high-profile websites, including Twitter and Netflix, to temporarily disappear from the Internet. More attacks are sure to follow: the botnet that attacked Dyn was created with publicly available malware called Mirai that largely automates the process of co-opting computers.
The best defense would be for everything online to run only secure software, so botnets couldn’t be created in the first place. This isn’t going to happen anytime soon. Internet of things devices are not designed with security in mind and often have no way of being patched. The things that have become part of Mirai botnets, for example, will be vulnerable until their owners throw them away. Botnets will get larger and more powerful simply because the number of vulnerable devices will go up by orders of magnitude over the next few years.
What do hackers do with them? Many things.
Botnets are used to commit click fraud. Click fraud is a scheme to fool advertisers into thinking that people are clicking on, or viewing, their ads. There are lots of ways to commit click fraud, but the easiest is probably for the attacker to embed a Google ad in a Web page he owns. Google ads pay a site owner according to the number of people who click on them. The attacker instructs all the computers on his botnet to repeatedly visit the Web page and click on the ad. Dot, dot, dot, PROFIT! If the botnet makers figure out more effective ways to siphon revenue from big companies online, we could see the whole advertising model of the Internet crumble.
Similarly, botnets can be used to evade spam filters, which work partly by knowing which computers are sending millions of e-mails. They can speed up password guessing to break into online accounts, mine bitcoins, and do anything else that requires a large network of computers. This is why botnets are big businesses. Criminal organizations rent time on them.
But the botnet activities that most often make headlines are denial-of-service attacks. Dyn seems to have been the victim of some angry hackers, but more financially motivated groups use these attacks as a form of extortion. Political groups use them to silence websites they don’t like. Such attacks will certainly be a tactic in any future cyberwar.
Once you know a botnet exists, you can attack its command-and-control system. When botnets were rare, this tactic was effective. As they get more common, this piecemeal defense will become less so. You can also secure yourself against the effects of botnets. For example, several companies sell defenses against denial-of-service attacks. Their effectiveness varies, depending on the severity of the attack and the type of service.
But overall, the trends favor the attacker. Expect more attacks like the one against Dyn in the coming year.
This essay previously appeared in the MIT Technology Review.
ProofMode is an app for your smartphone that adds data to the photos you take to prove that they are real and unaltered:
On the technical front, what the app is doing is automatically generating an OpenPGP key for this installed instance of the app itself, and using that to automatically sign all photos and videos at time of capture. A sha256 hash is also generated, and combined with a snapshot of all available device sensor data, such as GPS location, wifi and mobile networks, altitude, device language, hardware type, and more. This is also signed, and stored with the media. All of this happens with no noticeable impact on battery life or performance, every time the user takes a photo or video.
This doesn’t solve all the problems with fake photos, but it’s a good step in the right direction.
Sidebar photo of Bruce Schneier by Joe MacInnis.