If you think security breaches like the ones at Toyota or Facebook are bad, just wait. That’s what attackers are doing. Playing the long game. It’s referred to as “sit and wait” or sometimes “spray and pray.” Either way these new forms of attack capitalize on the convergence of several key factors including: nation-state sponsored attacks; the acceleration of software development; increasing complexity of modern software architectures; and an application security (AppSec) industry that’s playing catch-up.
Unfortunately, this all means that today’s software is more vulnerable than ever to backdoor attacks. And the scary part? There’s evidence attackers have taken notice. For example, just look at Industroyer (also known as CrashOverride), which was used to attack the Ukraine power grid. Part of this malware installs a new version of Notepad on Windows. That new version contains a backdoor that allows it to be controlled by an adversary at will.
The history of backdoors in source code has largely been about managing insider threats. For example, a rogue developer looking to sabotage the organization. What’s changed is that increasingly well-funded nation-state attackers can afford to take a much longer-term view. This means writing useful code with backdoors planted deep inside it, making the code widely available, and waiting to see who adopts it.
If you believe the speculation, the infamous “_NSAKEY” variable discovered in Windows NT 4.0 may have been the first major instance of a nation-state planting a “sit-and-wait” style backdoor (although Microsoft denies this). However, more recent examples such as STUXNET, and the backdoors found in Juniper and Huawei products, suggest the approach is on the rise. In the cases of Juniper and Huawei, the backdoor wasn’t meant to attack the networking firmware it was written into, but rather to monitor traffic of those that adopted the products. The attackers’ gamble being that if they waited long enough, the products would be adopted by organizations with something of value. Wait and see. Spray and pray. Your organization isn’t being targeted, but if you have something worth stealing, backdoors in products you’ve adopted make it easier than ever to initiate an attack. This applies equally to both end-user customers and software development organizations.
Historically, the most well-funded attacks went after the highest value targets. Typically, this meant criminals targeted finance, and nation-states keyed on defense, federal government and critical infrastructure. Traditionally, these attacks have always been sophisticated and direct. They may have unfolded over weeks, months or years, but they had specific goals and specific targets. This meant the vast majority of software development organizations, operating outside of these industries, were largely unaffected. Not anymore.
Today, AppSec is more difficult than ever. Ironically, many of the advances in software development practices that have driven new efficiencies have also undermined its security. Agile methods, cloud adoption, DevOps, and more have led to faster release cycles via automation and continuous delivery. But traditional AppSec methods, which are manual and time consuming, just can’t keep up with the level of vulnerabilities. Before a proper security review can be performed, a new software release (if not multiple releases) has likely already been deployed into production.
The reality is, modern software development architectures make applications particularly vulnerable to backdoors due to their complexities and dependencies. The shift from “monolithic” code bases to “microservices” provides leverage to a development organization. Developers work on a small subset of the code that interacts with other subsets through internal APIs. Similarly, source code is increasingly made up of code that’s written elsewhere, called dependencies such as frameworks, open source libraries and commercial SDKs. In other words, if someone already wrote great software and your organization can have it for free, or rent it inexpensively, there’s tremendous leverage to working on the unique value that your custom code creates (not the elements you can plug in). It’s just like Ford or GM. They design and built the motor, transmission, interior and exterior styling, but they use suppliers for more generic parts like tires or spark plugs.
Microservices and dependencies increase development efficiency by enabling focus. To get this value, it inherently means developer knowledge becomes siloed. Developers working on microservice “A” may never understand how microservices “B” and “C” work (or at least not as well as “A”). The same goes for open source libraries and 3rd party SDKs. Their value comes from needing only to know them well enough to get them working reliably in your service. In other words, developing software more efficiently means ultimately understanding less and less of your code base. Combine this with the increasing use of external APIs, where software intentionally sends and/or receives data from 3rd parties, and we’ve created the perfect storm for backdoors.
In fact, these practices are so prevalent (and almost required to stay competitive in the software market) that organizations that don’t use these tactics likely won’t be commercially viable in the next 10 years. This juxtaposition of added complexity and loss of control is one of the paramount concerns associated with application security.
As an industry, AppSec has a lot of catching up to do. Not only are traditional methods of securing applications in development hindered by slow tools that generate massive amounts of manual work, they also simply weren’t designed to find backdoors because: a) they don’t understand data flows within an applications (so they can’t identify external communications); b) they don’t understand an application’s business logic (which defines whether external data flows are intended or unintended); and c) they rely on “known” vulnerabilities to analyze open source libraries and SDKs (which means they are blind to “sit and wait” attacks until it’s too late).
Unfortunately, the situation is going to get much worse before it gets better, especially if the software industry continues to embrace feature development velocity over security. Until this changes, there will always be easy targets.
So, what are some initial steps you can take to help keep your organization safe from backdoors today?
First, look for tools that enable security analysts to apply their knowledge of how the application works (e.g., ShiftLeft or Joern). What does the business logic imply about whether external communications are intended for a 3rd party API or unintended to a command and control server? Since no code analysis tool can inherently know business logic, the key is amplifying your team’s understanding of it.
Second, focus on accuracy to drive speed. Customizing security checks to your code base will maximize accuracy. Conversely, comprehensive code analysis tools today often generate so much noise that the signal gets lost and ultimately ignored (too many false positives and negatives). A smaller number of accurate security checks, that developers can rely on and can be built up over time, is much more valuable than a large number of inaccurate alerts that get ignored or take weeks to triage.
Third, drive speed via automation. After building highly accurate security checks, insert them into your workflow to automatically evaluate every version of software before it hits production (e.g., upon pull request, build, or deployment).
Backdoors can give attackers the keys to the kingdom. They’re arguably the most dangerous type of software vulnerability. When combined with the market conditions that make them easier than ever to plant, and harder than ever to detect, it’s logical to conclude that the anecdotal evidence of high-profile exploits is an early indicator of a larger trend. And, one that will ultimately cost consumers and developers if better solutions are not created and implemented.