Hacking a Quantum Computing Controller:
Vulnerability in the Quantum Computing Stack
TL;DR - We identified an elementary bug in an open source quantum computing stack component, specifically a default root-capable login (CWE-1392 & CWE-1188) in the QICK controller stack, provided by Open Quantum Hardware, a project at Fermilab. This publicly disclosed login would allow anyone full access to the quantum hardware the controller is connected to - and given the cost and sensitivity of these systems, it’s probably a good idea to change it as a matter of course.
UPDATE 2024-MAY-26 - the Fermilab team have made a number of updates to their quick-start writeup to take our concerns into account, and we’re reasonably happy that they are moving forward in a really positive way! That said, we’d like to point out that simply changing the password using a human password generator isn’t ideal - those kinds of passwords still tend to get written on whiteboards… whilst SSH keys tend not to! There’s still a lot of education and tech that needs to be done and built around the security of quantum stacks, however; but this is a great first step!
What is the bug?
Essentially, it's a very basic vulnerability, the kind that hackers call "low-hanging fruit"! It comes from the default configuration of an underlying piece of equipment - two RF controller boards called the ZCU111 and ZCU216 based on the PYNQ OS.
Specifically, the vulnerability is a default username and password setup by the designers of the board, AMD (formerly Xilinx). The login is:
Username: xilinx
Password: xilinx
This user has sudo privileges, though - which means it is a sensitive user, and so should have more controls applied to it to limit attackers taking advantage of this login. The CWEs for this bug is CWE-1392 (Default Credential) and CWE-1188 (Initialisation of a Resource with an Insecure Default) - no CVE has been applied for.
But how does this relate to quantum computers?
These RFSOC development boards are the basis for the QICK interface and development platform from the Open Quantum Hardware initiative, part of Fermilab:
Code: https://github.com/openquantumhardware/qick/
The controller is the classical gateway to the quantum world - it takes a series of input instructions and converts them into (in this case) microwave pulses that are communicated to a supercooled platform housing the superconducting quantum processing unit (QPU). These controllers use a linux-based control system, and so it utilizes a common access protocol such as SSH to perform administrative tasks.
This default login would allow someone pulse-level access to a quantum computer, were it attached to one, and given the privileged level of access this user affords, would essentially permit total control over the quantum computer!
Of course, a lot has to go wrong to be able to use this login; you probably have to be on an internal network (might be hard), you have to know how to use SSH (quite easy), and you have to have some malicious intent.
If you just want to trash the system or commit a Denial of Service attack, then this is something any teenage hacker has done to victim linux systems in the past. But if you wanted to implant a subtle attack to either siphon off data (circuits and information sent to the quantum computer, and who sent it) or even carry out a quantum attack, you need to know a lot more - but nothing that isn't available online!
Surely quantum computers need quantum attacks though?
This is a common misconception about quantum computers - they are very complex devices with a large number of 'classical' (read; normal computer) components.
If we look at any system, such as IBM Quantum Computing resources or AWS' Braket service, we will find that they are python powered libraries talking to cloud-based APIs! Behind these lie classical compilers and queuing software. And beyond those are controller boards, such as we have analyzed here, that allow the classically processed quantum code to be conveyed into quantum mechanical means.
But wait, if it’s so simple and so public, don’t they know about this?
It must be pointed out that Open Quantum Hardware do state that this password can be changed (see https://github.com/QuantumVillage/qicks/blob/main/quick_start/README_ZCU111.md) but do not provide adequate instructions for doing so. Also, this ‘suggestion’ is omitted from the other board’s quickstart guide (see https://github.com/QuantumVillage/qicks/blob/main/quick_start/README_ZCU216.md).
As such, it became apparent that we should try to help, and highlight the importance of securing the quantum stack in the process.
Why is this a big deal?
Quantum computers are expensive, sensitive, and if the research into potential use cases proves to be workable, quantum computers will be used to compute over some of our most sensitive datasets:
• Finance - Many Banks, financial institutions, and startups such as Multiverse Computing have stated that quantum computing could well have a strong effect on finance - there are many examples of claims of ‘conclusive results’ for various experiments performing financial calculations on quantum hardware, such as: https://multiversecomputing.com/resources/quantum-computing-two-real-world-experiments-conducted-by-cre-dit-agricole-cib-in-partnership
• Medicine - The NIH has published a survey of how quantum computing in tandem with ML could help solve major challenges in medicine (see https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6205278/) whilst pharma company Boehringer Ingelheim have published a road map detailing how quantum computing will help drug discovery - a market valued at over $19Bn in 2022 (https://www.nature.com/articles/s41567-024-02411-5 )
• Cybersecurity - Quantum Village has published the following paper on ‘quantum blue teaming’; using quantum computers to fix cybersecurity problems: https://arxiv.org/abs/2211.13740
In short, we’re gearing up to send some of our most sensitive data to these machines. We need to consider their threat models and attack surfaces, and maybe start pushing for better controls and build/integration/deployment quality.
There has been a growing amount of research, both in the academic and hacker communities, about what 'quantum malware' might look like, and a default password in such a sensitive location as the base controller for a quantum processor is a key point of failure in the complex system.
How would an attacker use this bug?
To be honest, this is a matter of conjecture at this early stage of the technology. But here are some ideas for attack scenarios and some background information.
Change circuits on the fly at the point at which they are sent to the QPU.
Hijack the resource for free - quantum computing without paying for it!
Change the underlying logic of the controller to always give bad readouts - this could be from intentionally deleting code components, or more subtle changes, e.g. changing the value of pi from 3.14159 in the code to just… 3…
Adding code to ‘send backup copies’ of everything run on the quantum computer to some external storage (data exfiltration), causing a confidentiality and information breach.
Additionally, having a default password would make triage and forensic analysis of any incident much more complicated owing to a universal level of deep access to a system.
Mark C from Quantum Village has given the following talk at QV in 2022:
Here, he describes (at 14:10) how an attacker could inject malicious ‘quantum implants’ - small circuits that can disrupt or extract information from the quantum processor. Hackers already understand the majority of the technologies in a quantum computing stack because they are just regular components that are being used to run software that then can be used to generate the signals that then manipulate qubits.
Likewise, Jakub Szefer and his team at Yale University have published work on ‘quantum viruses’ - dark patterns in quantum algorithms that can be used for nefarious purposes: https://caslab.csl.yale.edu/publications/deshpande2023design.pdf
Jakub’s work has so far landed on the idea of signature based ‘quantum antivirus’, which we at quantum village think is a fine start. However, in light of the recent developments in EDR and cybersecurity detection and incident management technologies, there is plenty more that may be done to mitigate risks to these systems.
How widely used is this software?
It's really hard to say, but the QICK GitHub repository has a folder for “AWS integration”, possibly relating to cloud integration with the AWS Braket service. If so, then it is highly likely that the code is, or at least was, used by a platform available to that service.
But how did you find these bugs?
Quite easy; we are experienced security experts, and we simply read the documentation. We quickly noticed this issue and decided to raise awareness about this bug and the broader quantum computing threat profile.
What is the fix you are proposing?
It would have been irresponsible to release this blog without some attempt at a fix!
The idea of the fix is very straightforward - just change the password! However, if done improperly this can lead to more bad passwords, albeit ones that may not be on GitHub 😅 So we have created a script and an interactive notebook that can be used when setting the system up to change the password for something that is quite secure.
We have also pushed our fixes as a PR to the host project for the QICK controller. You may find our proposed fixes here: https://github.com/openquantumhardware/qick/pull/263
Our original code may be found mostly in this folder:
https://github.com/QuantumVillage/qicks/blob/main/qick_demos/
Where can we find more information?
Well, you can of course attend this year’s Quantum Village at the DEF CON hacking conference in Las Vegas, Aug 9th-11th this year! You can find out more about DEF CON at https://defcon.org/
We also have our YouTube channel which hosts all of the recordings of our talks from the last two Quantum Village events: https://www.youtube.com/@quantum_village
If you would like to engage with us more, you can also join our discord or look at our github projects, details of which may be found on our website: https://quantumvillage.org/ or email us hello@quantumvillage.org