Virtual Studio Technology plugins, more commonly referred to as “VSTs” are practically synonymous with the wider world of audio plug-ins at this point in history. Ubiquitous to hundreds of thousands of musicians, sound designers, and audio engineers across a variety of genres and industries, VSTs are an essential tool for modern audio production. But despite this, most musicians are not aware of the potential security risks that come with carelessly using them. In this article, I’ll go over the capabilities of VST malware, and why you, the musician, should care, and what you can do to protect yourself from attacks associated with the way this framework interacts with your computer.
But first, let’s go over a brief overview of VSTs and how they came to be.
What are VST plugins?
Developed by Steinberg, and premiering alongside their flagship Digital Audio Workstation Cubase’s 3.0 revision in 1996, VSTs (Virtual Studio Technology) were the first audio plugin framework to become widely accepted and supported by digital audio workstations. They allow users to add virtual instruments, effects, and other audio processing tools to their DAWs, enabling a more customizable and versatile production process.
The Public (non)understanding of VST plugins as potential attack vectors
So you, the musician whose been using this tech almost daily for the last decade, might be asking yourself, “Why should I care?”.
Well to answer that, let’s take a look at what can happen if say, a bad actor managed to sneak a Trojan VST into your DAW.
VST plugins are capable of running arbitrary code, just like any other program you run on your computer. While this might seem obvious many of you, what’s important to note is that, unlike literally every other modern 3rd party plugin framework, there are absolutely no safeguards in place to protect you, the musician, from having a plugin perform malicious actions on your computer. Browser plugins, for example, are sandboxed, meaning that they are unable to access your computer’s filesystem, or other programs, without your explicit permission. Reading Windows executable programs (EXEs) leverage code signing, which is a process that verifies that the program you are about to run is actually the program you think it is, and not a malicious copy. There are hundreds of other examples of how other frameworks protect you from malicious code, but VSTs are not one of them.
This is especially awkward, given that, nearly all plugins (outside of miscellaneous telemetry and activation/anti-piracy functionality) don’t really need access to more of your system resources, like your internet, filesystem, and unrelated programs, than just a place to read inputs from the DAW, quickly do some calculations, and then spit out some corresponding output– whether they are sound, MIDI, or something else entirely. Yet, because of the decades-old framework that, despite having two major revisions since it’s releases and today (1/1/2023), has largely stayed consistent in how it is loaded into VST hosts.
But to prove the point, let’s take a look at two brief examples that showcase two different ways an attacker could harm you to their benefit by convincing you open their VST
- Hijack System Resources: If you notice that your computer is running slower than usual, or is reaching abnormally high temperatures, it’s possible that a VST is using your computer’s resources to mine cryptocurrency, or perform some other task that is not related to audio production.
- Ransomware: These programs are capable of encrypting and/ or deleting important files on your computer, then try to coerce you to pay the attacker significant amounts in order to recover your data.
Don’t believe me when I say that VSTs are able to do this? Feel free to explore some pre-built proof-of-concepts.
Note: For obvious reasons, don’t open these Example VSTs directly on a computer you actually use for your production tasks. Treat this like any other malware, and only mess with it in a safe, protected environment with an abundance of caution,
The fact that this attack exists by itself is one thing
There have been no real mentions or discussions of the potential for the VST framework to be used as an attack vector, outside of a few ancient forum posts that are closer temporally to the initial release of the framework in the late 90s. Only very recently have security researchers and bloggers been revisiting this long-standing weakness, but even then, it was easier to independently investigate and discover these issues myself than to finally discover someone else who stumbled across this issue after several dozens of hours of trying to find ANY recent mention of it on the internet. But hopefully, as this issue gets talked about more on the internet, these types of posts discussing the security aspect of music technology will become more common in the music community, and will enable advancements in this area as plugin framework manufacturers and independent developers take notice and act upon these findings.
Security Policy Recommendations
Not all of the policy recommendations below will fully explained in technical detail, see What’s next?
- Disable autoscan new VST plugins offered in DAWs like REAPER and Elements
- In this context, “scanning” plugins is truly a misnomer. More accurate would be to say something like, “load plugin, and start running it’s code until it tells me it’s metadata, because, of course, lightweight information intended to be stored and accessed separately to the main content should absolutely only be accessible by first blindly trusting and running said content” 10/10 design choices.
- Side Tangent: Now that we’ve mentioned VST plugin metadata, I could prob go on a blog-length rant about how absurdity of the verificationless, trivially forgeable plugin metadata fields, including mildly critical information, such as the plugin manufacturer, but I’ll save that for one of the future posts.
- Be careful of what plugins you download and where you download them from
- Let’s go ahead and briefly address the elephant in the room: VST piracy. Ignoring the ethical reasons to avoid engaging in this type of behavior, one important piece of information to recognize is that the time and effort it takes an independent 3rd party to create a crack for modern VST is extremely significant, as the process of reverse engineering in general is rarely trivial. As such, in exchange for dedicating resources to this task, these crackers often are expecting some sort of significant return, typically a path to infected hundreds or thousands of zombie computers that can be hijacked for everything from cryptomining to DDoSing.
- Always try to download/install VSTs directly from a trusted source, like a manufacturer’s website, a secure first-party installer, or an authorized seller like PluginBotique
- For smaller VST-creators, if the plugins are open-source and still fairly popular, that is often (not always) a good sign that the plugins will be safe to use.
- For smaller VST-vendors without any sort of independent security verification, carefully consider how necessary it is for you to install the plugin before you even download the file. While this obviously really sucks for smaller creators trying to get off the ground, with the current state and (lack of) security measures in place protecting users from malicious VST plugins, it may just be safer to skip out, at least in the short-run.
Takeaways (tl;dr)
At the present, until some major framework-level change occurs with regards to how VST plugins are loaded into hosts, you should be extremely cautious with what VST plugins you install, and where you install them from.
Other relatively recent security bloggers have shown that antiviruses are not very effective at detecting whether VST plugins are safe or contain malware. As such, it is up to the user to be aware of the potential risks and take the necessary precautions to protect themselves.
What’s next?
This post is supposed to be a quick introduction for this ongoing issue for nontechnical people: namely, the digital musicians, producers, and hobbyists who use this technology on a daily basis and are most vulnerable to being exploited by a malicious VST plugin. In the future, I’ll be creating a few technical deep dives into the specifics of how VST plugins work, and how they can be used to exploit the system, including a couple more proof-of-concept VSTs that demonstrate some of the more interesting ways that VSTs can be used by bad actors to take advantage of your computer.