Unikernels Implement Zero Trust Infrastructure

03/09/19

Ian Eyberg

Zero trust is the concept that external or internal to a given network you simply can't trust anything anymore. This is for good reason when you see statistics claiming that insider threats account for nearly 75 percent of all data breaches. It's been a long time since you could buy yourself a firewall from one of the big vendors and call it a day if that was ever the case.

Zero Trust Isn't Just MicroSegmentation

Usually when vendors talk about zero trust they are referring to authentication or network segmentation or something else. However, when you are looking through the attackers eyes none of this really matters. None of the zero trust solutions address the underlying issue of why attackers break into servers to begin with. Most people assume that a hacker will scan for vulnerabilities until they find one that lets them into a server and then it's game over. This is wrong. The game has only started once they've broken in. Exploiting a bug to gain access to a server is just the entrypoint. It's the window or the door to your house. Attackers could care less *which* opening they are coming through. It's imperative to understand this point because it's the wrong way to think about the problem. You see servers offer attackers a beachhead environment that is more privileged than the one they are coming from and offers them legitimacy to the broader infrastructure.

Zero Trust Isn't Just Single Sign On

All the 2FA solutions in the world doesn't overcome the fact that at some point a web server is going to talk to the database, in all likelihood across the network, on a different host, in all likelihood through and to many hosts, across several servers. Each one of these servers contains a plethora of ways to escalate privilege and continue the attack. They ways for an attacker to gain more ground is exponential.

For a quick example just to paint the picture let's pretend all of your software lives on one server (which you know it doesnt'). Let's say you have a mysql database. By default it will create a 'mysql' user - you actually have to go out of your way to run it as root. So you already have multiple users and we haven't even mentioned that there's at least one or more devops users accounts tied into this single server. Devops might say - "oh we're on a vpn" and we hide that behind a jump host - we don't expose our ssh to the world. Great - so what you're really saying is that you're running an open network once we root your jump host? This type of setup is incredibly common amongst the public cloud users. The microsegmentation folks will step in here and state that now the attacker only has access to this network but not others.

It doesn't stop there. Ask yourself - how was the mysql server provisioned? Despite the container ecosystem's enthusiasm for dockerizing everything it's still considered highly unwise to run databases in containers from a performance standpoint alone let alone all the problems - that of course is a completely different article - it's pretty widely held that containers actually don't contain anything. Anyways, the msyql server was probably provisioned through the use of a configuration management tool like ansible, terraform, chef or puppet and if you built it from source you probably have a half dozen compilers laying around now. If not using configuration management than you probably have even more problems then this article can address. Ask yourself - did the configuration management tool use something like apt-get or dnf or yum? Are those tools still present on the machine? Can this machine talk to the internet even if it doesn't need to? Most firewalls are setup to block incoming traffic but very few will block outgoing traffic. The fact that these tools that exist only to install new software are still running on your production database server should be worrisome to you. Not only can someone install new software but they can install compilers to compile new programs as well. Of course you probably have curl and wget installed as well. Then you probably have editors like nano and vi installed. This allows the attackers to craft new exploits if it's not automated through something like cat to begin with which is also installed. It's worth noting that most systems will have a few thousand libraries installed in /usr/lib or something else conveinentily located as well. Oldies but goodies like libxslt that are compiled into every single interprter out there come with a fully functioning ftp server because of course you need that to parse xml. Joy! Also while you're at it go ahead and give a count to how many interpreters and compilers actually exist on this system. You probably have at least a half dozen. This is end result of the failure of the bazaar over the cathedral. If you haven't read Poul-Henning Kamp's scathing review you'll want to setup some time to do so.

"Oldies but goodies like libxslt that are compiled into every single interpreter out there come with a fully functioning ftp server because of course you need that to parse xml."

Now we can talk about the cronjob scheduler. This is present everywhere of course and is heavily used by things like illicit cryptominers that like to install nightly jobs that look for other cryptominers to kick out and download new updated code. There's an entire cohort of attackers that are not too intelligent but cron happens to be extremely reliable software and helps facilitates an excellent update mechanism.

Let's keep in mind that we are still only talking about one server here. Assuming we have root and that should be trivial to get (hint: it's extremely common to find the devops user can 'sudo su' their way on up) we can look at the network traffic. You used to have to have some level of knowledge about l2 and l3 networking using tools like tcpdump to interpret raw traffic but now tools like sysdig go out of their way to make this painlessly easy for you to do extracting raw ascii. If you're lucky you might even find newer tools like consul and nomad on this host. You hit the jackpot - it's become commonplace especially in the container ecosystem to store a treasure trove of sensitive data like passwords, tls certs and other things in a network-wide addressable k/v store that's "encrypted" with base64. This of course is ridiculous.

Linux Rules the DataCenter Yet is Broke

Listen I don't want to sound overly negative here - I'm just trying to paint the picture of the raging dumpster fire that is "linux security" today. As an aside to avoid any confusion and online debates - linux is not going anywhere - it's still going to be the heavyweight champion for underlying hypervisors and it will forever remain $HOME for many dev environments. It is the server side application portion we are concerned with when talking about unikernels. The reality is that existing zero trust solutions might make you sleep a bit better at night but they are just like the old firewalls of yesteryear. Not to throw oil on the fire but Google, Facebook and Uber all are built on Linux along with most of the other tech elite and guess what? They all three faced serious security problems last year. Uber ended up having to shell out $165M while Facebook is looking at over a billion dollar fine.

The proverbial chickens have come home to roost. What used to just be embarrasing is now inflicting real financial pain and the intensity and all encompassing nature of it is becoming unbearable.

Different Time - Different Era

The big issue is that our current operating systems simply were built for a different era. They were inherently built to run multiple programs by many different users on the *same server*. I don't know if anyone could've predicted a future where individual banks have 400,000 virtual machines or "ride-sharing" companies spend $8M a month on virtual machines. All the sci-fi authors had us convinced we were going to be living on Mars in 2020 not managing a universe of virtual machines that are running an operating system whose design is 50 years old now (as of this writing Linux itself is 28 years old) but here we are.

Also the security environment itself has changed considerably since the time I was trying to winnuke/teardrop people off of irc as a teenager in the mid to late 90s. Nothing was encrypted back then and it was a true wild west. However the saving grace was this was a time period when the average american might've not even had dialup - truly less than half of the american population were online and almost no one used credit cards online. Even as the first dot com boom was ripping and roaring there simply wasn't that much of a server presence and we didn't have massive commercialized virtualization through VMWare. It wouldn't be until the mid 2000s that the 'cloud' was birthed which was basically an api on top of virtualization.

Today is a different story. Jeff Bezos is now the richest person alive because of the sheer demand for virtualization. While entire sectors of the economy are marching through their digital transformation security has not kept pace. If anything it has lagged behind severely and the threat environment has only gotten worse.

Unikernels implement zero trust based infrastructure because of their design to only deploy what is actually necessary to deploy - a single application. There are no more usernames/passwords to pilfer. There are no shells to use as staging grounds. Most importantly the idea that you can run entire other programs on a given server goes away. Unikernels don't rid your systems of things like RFI attacks but those become much less harmful since the vast majority implement 'web shells' that are only intended to be used for loaders and reverse backs. Similarly they don't prevent against SSRF attacks or other application specific problems but they do ensure that the host operating system isn't welcoming every single attacker with open arms ready and willing.

Some people, myself included, have stated that unikernels don't have an operating system - that's technically not true but it's an interesting way to think about it because the system they implement is night/day different from traditional general purpose operating systems we are all familiar with and a lot of people get hung up on how these actually work with all the 'stuff' that traditional operating systems bring. Another way to view them though is that they wrap each program with a small virtualization protective coating effectively isolating them from each other and I'd argue that especially in a public cloud setting this coating is 'strong enough' to keep most companies a lot less apprehensive.

While this is not a new idea we now have the capabilities through open source projects like OPS to build these and deploy them easily. This has historically kept a lot of developers from utilizing them.

Security and Dev Together Again

For the longest time security and devops have traditionally been worlds apart. Unikernels represent a special turning point. A point where infrastructure can truly embrace shift left security - not just patched on as an after thought. We're not going to get rid of all of our security problems just by using unikernels just as we aren't going to get rid of murderers by banning guns but it doesn't need to be as intense of a problem as it is currently and if we want to embrace all the new innovative things with technology we need to start somewhere.