I’m in the FutureID3 workshop in Jesus College, Cambridge, and will try to liveblog the talks in followups to this post.
Category Archives: Academic papers
Struck by a Thunderbolt
At the Network and Distributed Systems Security Symposium in San Diego today we’re presenting Thunderclap, which describes a set of new vulnerabilities involving the security of computer peripherals and the open-source research platform used to discover them. This is a joint work with Colin Rothwell, Brett Gutstein, Allison Pearce, Peter Neumann, Simon Moore and Robert Watson.
We look at the security of input/output devices that use the Thunderbolt interface, which is available via USB-C ports in many modern laptops. Our work also covers PCI Express (PCIe) peripherals which are found in desktops and servers.
Such ports offer very privileged, low-level, direct memory access (DMA), which gives peripherals much more privilege than regular USB devices. If no defences are used on the host, an attacker has unrestricted memory access, and can completely take control of a target computer: they can steal passwords, banking logins, encryption keys, browser sessions and private files, and they can also inject malicious software that can run anywhere in the system.
We studied the defences of existing systems in the face of malicious DMA-enabled peripheral devices and found them to be very weak.
The primary defence is a component called the Input-Output Memory Management Unit (IOMMU), which, in principle, can allow devices to access only the memory needed to do their job and nothing else. However, we found existing operating systems do not use the IOMMU effectively.
To begin with, most systems don’t enable the IOMMU at all. Windows 7, Windows 8, and Windows 10 Home and Pro didn’t support the IOMMU. Windows 10 Enterprise can optionally use it, but in a very limited way that leaves most of the system undefended. Linux and FreeBSD do support using the IOMMU, but this support is not enabled by default in most distributions. MacOS is the only OS we studied that uses the IOMMU out of the box.
This state of affairs is not good, and our investigations revealed significant further vulnerabilities even when the IOMMU is enabled.
We built a fake network card that is capable of interacting with the operating system in the same way as a real one, including announcing itself correctly, causing drivers to attach, and sending and receiving network packets. To do this, we extracted a software model of an Intel E1000 from the QEMU full-system emulator and ran it on an FPGA. Because this is a software model, we can easily add malicious behaviour to find and exploit vulnerabilities.
We found the attack surface available to a network card was much richer and more nuanced than was previously thought. By examining the memory it was given access to while sending and receiving packets, our device was able to read traffic from networks that it wasn’t supposed to. This included VPN plaintext and traffic from Unix domain sockets that should never leave the machine.
On MacOS and FreeBSD, our network card was able to start arbitrary programs as the system administrator, and on Linux it had access to sensitive kernel data structures. Additionally, on MacOS devices are not protected from one another, so a network card is allowed to read the display contents and keystrokes from a USB keyboard.
Worst of all, on Linux we could completely bypass the enabled IOMMU, simply by setting a few option fields in the messages that our malicious network card sent.
Such attacks are very plausible in practice. The combination of power, video, and peripheral-device DMA over Thunderbolt 3 ports facilitates the creation of malicious charging stations or displays that function correctly but simultaneously take control of connected machines.
We’ve been collaborating with vendors about these vulnerabilities since 2016, and a number of mitigations have been shipped. We have also been working with vendors, helping them to use our Thunderclap tools to explore this vulnerability space and audit their systems for problems.
MacOS fixed the specific vulnerability we used to get administrator access in macOS 10.12.4 in 2016, although the more general scope of such attacks remain relevant. More recently, new laptops that ship with Windows 10 version 1803 or later have a feature called Kernel DMA Protection for Thunderbolt 3, which at least enables the IOMMU for Thunderbolt devices (but not PCI Express ones). Since this feature requires firmware support, older laptops that were shipped before 1803 remain vulnerable. Recently, Intel committed patches to Linux to enable the IOMMU for Thunderbolt devices, and to disable the ATS feature that allowed our IOMMU bypass. These are part of the Linux kernel 5.0 which is currently in the release process.
One major laptop vendor told us they would like to study these vulnerabilities in more detail before adding Thunderbolt to new product lines.
More generally, since this is a new space of many vulnerabilities, rather than a specific example, we believe all operating systems are vulnerable to similar attacks, and that more substantial design changes will be needed to remedy these problems. We noticed similarities between the vulnerability surface available to malicious peripherals in the face of IOMMU protections and that of the kernel system call interface, long a source of operating system vulnerabilities. The kernel system call interface has been subjected to much scrutiny, security analysis, and code hardening over the years, which must now be applied to the interface between peripherals and the IOMMU.
As well as asking vendors to improve the security of their systems, we advise users to update their systems and to be cautious about attaching unfamiliar USB-C devices to their machines – especially those in public places.
We have placed more background on our work and a list of FAQs on our website, thunderclap.io. There, we have also open sourced the Thunderclap research platform to allow other researchers to reproduce and extend our work, and to aid vendors in performing security evaluation of their products.
Thunderclap: Exploring Vulnerabilities in Operating System IOMMU Protection via DMA from Untrustworthy Peripherals A. Theodore Markettos, Colin Rothwell, Brett F. Gutstein, Allison Pearce, Peter G. Neumann, Simon W. Moore, Robert N. M. Watson. Proceedings of the Network and Distributed Systems Security Symposium (NDSS), 24-27 February 2019, San Diego, USA.
Financial Cryptography 2019
I’m at Financial Crypto 2019 and will try to liveblog some of the sessions in followups to this post.
Visualizing Diffusion of Stolen Bitcoins
In previous work we have shown how stolen bitcoins can be traced if we simply apply existing law. If bitcoins are “mixed”, that is to say if multiple actors pool together their coins in one transaction to obfuscate which coins belong to whom, then the precedent in Clayton’s Case says that FIFO ordering must be used to track which fragments of coin are tainted. If the first input satoshi (atomic unit of Bitcoin) was stolen then the first output satoshi should be marked stolen, and so on.
This led us to design Taintchain, a system for tracing stolen coins through the Bitcoin network. However, we quickly discovered a problem: while it was now possible to trace coins, it was harder to spot patterns. A decent way of visualizing the data is important to make sense of the patterns of splits and joins that are used to obfuscate bitcoin transactions. We therefore designed a visualization tool that interactively expands the taint graph based on user input. We first came up with a way to represent transactions and their associated taints in a temporal graph. After realizing the sheer number of hops that some satoshis go through and the high outdegree of some transactions, we came up with a way to do graph generation on-the-fly while assuming some restrictions on maximum hop length and outdegree.
Using this tool, we were able to spot many of the common tricks used by bitcoin launderers. A summary of our findings can be found in the short paper here.
Symposium on Post-Bitcoin Cryptocurrencies
I am at the Symposium on Post-Bitcoin Cryptocurrencies in Vienna and will try to liveblog the talks in follow-ups to this post.
The introduction was by Bernhard Haslhofer of AIT, who maintains the graphsense.info toolkit and runs the Titanium project on bitcoin forensics jointly with Rainer Boehme of Innsbruck. Rainer then presented an economic analysis arguing that criminal transactions were pretty well the only logical app for bitcoin as it’s permissionless and trustless; if you have access to the courts then there are better ways of doing things. However in the post-bitcoin world of ICOs and smart contracts, it’s not just the anti-money-laundering agencies who need to understand cryptocurrency but the securities regulators and the tax collectors. Yet there is a real policy tension. Governments hype blockchains; Austria uses them to auction sovereign bonds. Yet the only way in for the citizen is through the swamp. How can the swamp be drained?
Privacy for Tigers
As mobile phone masts went up across the world’s jungles, savannas and mountains, so did poaching. Wildlife crime syndicates can not only coordinate better but can mine growing public data sets, often of geotagged images. Privacy matters for tigers, for snow leopards, for elephants and rhinos – and even for tortoises and sharks. Animal data protection laws, where they exist at all, are oblivious to these new threats, and no-one seems to have started to think seriously about information security.
So we have been doing some work on this, and presented some initial ideas via an invited talk at Usenix Security in August. A video of the talk is now online.
The most serious poaching threats involve insiders: game guards who go over to the dark side, corrupt officials, and (now) the compromise of data and tools assembled for scientific and conservation purposes. Aggregation of data makes things worse; I might not care too much about a single geotagged photo, but a corpus of thousands of such photos tells a poacher where to set his traps. Cool new AI tools for recognising individual animals can make his work even easier. So people developing systems to help in the conservation mission need to start paying attention to computer security. Compartmentation is necessary, but there are hundreds of conservancies and game reserves, many of which are mutually mistrustful; there is no central authority at Fort Meade to manage classifications and clearances. Data sharing is haphazard and poorly understood, and the limits of open data are only now starting to be recognised. What sort of policies do we need to support, and what sort of tools do we need to create?
This is joint work with Tanya Berger-Wolf of Wildbook, one of the wildlife data aggregation sites, which is currently redeveloping its core systems to incorporate and test the ideas we describe. We are also working to spread the word to both conservators and online service firms.
How Protocols Evolve
Over the last thirty years or so, we’ve seen security protocols evolving in different ways, at different speeds, and at different levels in the stack. Today’s TLS is much more complex than the early SSL of the mid-1990s; the EMV card-payment protocols we now use at ATMs are much more complex than the ISO 8583 protocols used in the eighties when ATM networking was being developed; and there are similar stories for GSM/3g/4g, SSH and much else.
How do we make sense of all this?
Reconciling Multiple Objectives – Politics or Markets? was particularly inspired by Jan Groenewegen’s model of innovation according to which the rate of change depends on the granularity of change. Can a new protocol be adopted by individuals, or does it need companies to adopt it en masse for internal use, or does it need to spread through a whole ecosystem, or – the hardest case of all – does it require a change in culture, norms or values?
Security engineers tend to neglect such “soft” aspects of engineering, and we probably shouldn’t. So we sketch a model of the innovation stack for security and draw a few lessons.
Perhaps the most overlooked need in security engineering, particularly in the early stages of a system’s evolution, is recourse. Just as early ATM and point-of-sale system operators often turned away fraud victims claiming “Our systems are secure so it must have been your fault”, so nowadays people who suffer abuse on social media can find that there’s nowhere to turn. A prudent engineer should anticipate disputes, and give some thought in advance to how they should be resolved.
Reconciling Multiple Objectives appeared at Security Protocols 2017. I forgot to put the accepted version online and in the repository after the proceedings were published in late 2017. Sorry about that. Fortunately the REF rule that papers must be made open access within three months doesn’t apply to conference proceedings that are a book series; it may be of value to others to know this!
Bitter Harvest: Systematically Fingerprinting Low- and Medium-interaction Honeypots at Internet Scale
Next week we will present a new paper at USENIX WOOT 2018, in which we show that we can find low- and medium-interaction honeypots on the Internet with a few packets. So if you are running such a honeypot (Cowrie, Glastopf, Conpot etc.), then “we know where you live” and the bad guys might soon as well.
In total, we identify 7,605 honeypot instances across nine different honeypot implementations for the most important network protocols SSH, Telnet, and HTTP.
These honeypots rely on standard libraries to implement large parts of the transport layer, but they were never intended to provide identical behaviour to the systems being impersonated. We show that fixing the identity string pretending to be OpenSSH or Apache and not “any” library or fixing other common identifiers such as error messages is not enough. The problem is that there are literally thousands of distinguishing protocol interactions, part of the contribution of the paper is to show how to pick the “best” one. Even worse, to fingerprint these honeypots, we do not need to send any credentials so it will be hard to tell from the logging that you have been detected.
We also find that many honeypots are deployed and forgotten about because part of the fingerprinting has been to determine how many people are not actively patching their systems! We find that 27% of the SSH honeypots have not been updated within the last 31 months and only 39% incorporate improvements from 7 months ago. It turns out that security professionals are as bad as anyone.
We argue that our method is a ‘class break’ in that trivial patches cannot address the issue. Thus we need to move on from the current dominant honeypot architecture of python libraries and python programs for low- and medium-interaction honeypots. We also have developed a modified version of the OpenSSH daemon (sshd) which can front-end a Cowrie instance so that the protocol layer distinguishers will no longer work.
The paper is available here.
Cybercrime conference
I’m at the Cambridge Cybercrime Centre’s Third Annual Cybercrime Conference. I will try to liveblog the event in followups to this post.
Graphical Models of Security (GraMSec 2018)
I was at The Fifth International Workshop on Graphical Models for Security (part of FLoC 2018) this weekend where I presented a paper. Following is a summarized account of the talks that took place there. Slides can be found here.
The first speaker was Mike Fisk who was giving an invited talk on Intrusion Tolerance in Complex Cyber Systems. Mike started off by elaborating the differences in the construction of physically secure systems such as forts versus the way software engineers go about creating so-called secure systems. He then made the case for thinking in terms of intrusion tolerance rather than just intrusion resistance – even if an intruder gets in, your system should be designed in such a way that it impedes the intruder’s exploration of your network. He then instantiated this idea by talking about credentials for accessing network resource and how they’re stored. He noted that normal users (with the notable exceptions of sysadmins) show predictable access patterns whereas attackers show wildly different access patterns; an intrusion tolerant system should take these into account and ask for re-authentication in case of abnormal patterns. He then talked about metrics for figuring out which nodes in a network are most interesting to an attacker. While some of these are expected – say, the ActiveDirectory server – others are quite surprising such as regular desktops with very high network centrality. He concluded by giving advise on how to use these metrics to direct resources for intrusion resistance most effectively.
Sabarathinam Chockalingam gave a talk on using Bayesian networks and fishbone diagrams to distinguish between intentional attacks and accidental technical failures in cyber-physical systems. His work focused specifically on water level sensors used in floodgates. He first gave an introduction to fishbone diagrams highlighting their salient features such as the ability to facilitate brainstorming sessions while showcasing all the relevant factors in a problem. He then presented a way to translate fishbone diagrams into Bayesian networks. He utilized this technique to convert the risk factor fishbone diagram for the water level sensors into a Bayesian network and generated some predictions. These predictions were mostly based on expert knowledge and literature review. He concluded by pointing at some possible future research directions primary of which was exploring the conversion of fishbone diagrams into conditional probability tables.
I gave a talk on visualizing the diffusion of stolen bitcoins. This works builds upon our previous work on applying the FIFO algorithm to tainting bitcoins, presented at SPW2018. Here, I focused on the challenges facing effective visualization of the tainting dataset. I highlighted the size of the dataset (>450 GB for just 56 kinds of taint), the unbounded number of inputs and outputs as well as the unbounded number of hops a satoshi can take. All these make visualization without abstraction challenging. We refused to use lossy abstractions since what is interesting to the user might be something that we abstract away. Instead, we made two prototypes that, for the most part, convey the underlying information in an accessible manner to the end-user without using any abstractions. The first provides a static map of the taint-graph, useful for getting a global view of the graph; the second provides an interactive way to explore individual transactions. I concluded by pointing out that this is a much more general problem since what we are trying to do is visualize a large subset of transactions in a massive dataset – something that is encountered in many other domains.
Ross Horne presented a specialization of attack trees where he took into consideration of an attacker about the underlying system that they are trying to compromise. He pointed out that existing attack trees assume perfect knowledge on the part of the attacker whereas this is not realistic. The attacker often acts under uncertainty. To model this, he introduced a new operator to act between branches of an attack tree that conveys ignorance on the effectiveness and possible outcomes in case the attacker chooses to traverse that sub-tree. He then introduced a way of reasoning about the specialization of such trees and showed how the placement of the newly introduced operator has varying impact on the capabilities of the attacker. He concluded by remarking how these new attack trees could be used for moving target defence.
Harley Eades III gave a talk on applying linear logic to attack trees. He started off by pointing out that when understanding the difficulty of execution of an attack, we only care about the weights assigned to the leaves of the tree, the root nodes only serve as combinatorial operators. He then presented an exhaustive list of operators and provided a representation to convert attack trees into linear logic statements. He then introduced Maude, a quarternary semantics of attack trees followed by the introduction of Lina, an embedded domain specific programming language. Lina is used to do automated reasoning about attack trees using Maude. He presented Lina’s functionalities and showed an example application of Lina: automated threat analysis. He concluded by talking about future work conjecturing different formal models of causal attack trees specifically mentioning a petri net model.