Last week we learned of Yet Another Breach. This time NordVPN, one of the more popular VPN services, had experienced a compromise. Briefly, a private key associated with how NordVPN clients verify and authentication to NordVPN had been stolen through a vulnerability within their hosting provider’s infrastructure.
How Big is This Breach?
Probably not that catastrophic. While millions of users rely on these VPN services to increase privacy and anonymity, the exposure from this latest breach would likely be nil. This is because while the theft of a private key isn’t great as it pertains to the integrity of a VPN service, it also doesn’t equate to the en mass personal identifiable Information (PII) and credential dumps we are sadly becoming accustom to.
That is not to say there is no reason to be concerned. The theft of a private key could enable an attacker to perform a man in the middle attack (MitM) and intercept traffic thought to be secure, private and anonymous. However, the attack to acquire the key and then re-use it would not be trivial and the threat actors interested in performing this type of attack are not the usual cyber criminals the majority of us are worried about.
So What are the “Real” Lessons to Learn from this Breach?
The majority of the news coverage on this breach is about how a company dedicated to security and privacy had been breached and users should be scared. While a gaff like this should erode user confidence in a company charged with providing “security and privacy”, I’d argue there are much bigger lessons to learn for both consumers as well as IT professionals from this recent breach.
Mandatory Breach Notifications Are Only For Privacy Breaches
While I cringe every time I read about Yet Another Breach, I guess there is some comfort in knowing that the public breach notifications are likely nudging other companies to do a better job at protecting our data before it is their turn on the breach news cycle. However, NordVPN’s breach happened 18 months ago and was only brought to our attention from an Internet security researcher who stumbled upon the stolen keys on the Dark web!
So, why are we only finding out about this now?
First, I think privacy laws are doing a good job at whipping companies into doing the right thing by protecting our data and notifying us when they screw up. However, most privacy laws which mandate breach notifications, are focused around the compromise of personal identifiable information. As far as NordVPN is concerned they do not collect much of any PII, the compromised key did not directly equate to PII theft and therefore no legal obligation to inform the public of the compromise.
Second, NordVPN was justifying keeping this breach under wraps to avoid the risk that the same vulnerability could exist in other hosting environments which could lead to a much larger compromise. While I agree that is a legitimate concern, the proper course of action should have been to contact their hosting providers immediately and ensure that patching of this management layer was initiated. Considering AWS has a track record for patching their entire infrastructure within days, surely 18 months should have been more than adequate to patch and update their vulnerability management layers to encompass the newly discovered attack surface.
So be forewarned that even with the privacy laws in place, you still might find out about a breach that affects you through the legendary third party.
Don’t Trust, Verify the Lower Layers
The technical cause of this compromise was a vulnerability not within NordVPN’s software but rather within their hosting provider’s management layer. NordVPN claimed they were unaware of this management interface and thus could not defend against it. While I agree patching that interface was out of their control, I call balderdash on their skirting of culpability due to lack of awareness. This because a company like NordVPN that operates 5000+ servers within a myriad of data centres around the world, would know how hosting providers operate and manage their infrastructure.
Why am I so confident that NordVPN would have known of the management interface? Well, before VPN services such as NordVPN became a thing, I am confident to say I was one of the first geeks to roll their own VPN service to access US streaming services. I worked with the very same hosting providers to spin up virtual servers and know that those hosting providers had as much access or could gain as much access to my server through their management interfaces as I did.
Now to be fair NordVPN had no technical ability to patch this vulnerability and thus likely unaware a vulnerability existed within the management layer. NordVPN as with most IT shops using Cloud services had assumed their hosting provider were doing the right things… And here in lies the inconvenient truth with outsourced IT: Whether it is someone else’s data centre or someone else’s application you are residing on top of, we blindly are trusting that the lower layers have been secured by the provider. This blind trust reminds me very much of the problem with application development, whereas the developers are “borrowing” code from someone else and because it is open source, have this blind trust that “someone else” has vetted it and therefore it is trusted. However, the reality is this blind trust is what will continue to be our downfall.
So, let’s acknowledge that we are all going to consume more and more outsourced services in one way or the other so what can we do?
Understand the Shared Responsibility Model
While I think a company like NordVPN who prides themselves on security and privacy should have performed more extensive due diligence of their hosting provider to understand these lower layers below their application, I also think it is fair to say that most organizations that are adopting external services such as Cloud are not doing so and blindly trusting their hosting provider to do “the right thing”. This is because in our modern world of virtualized this and containerized that, it is hard to understand all the layers and we find ourselves asking are we in reality or the Matrix?
The tier 1 Cloud Service Providers (CSPs) such as AWS and Azure have been championing the awareness of shared responsibility within all these different layers. This is because many Cloud adopters thought they were outsourcing all responsibility over to the CSP and that is quite frankly not the case. The model essentially articulates various layers within the Cloud service technology stack and which layers are the CSP’s responsibility to secure and which layers are the Cloud consumer’s responsibility to secure.
Now with tier 1 CSPs I am confident to say that patching the lower layers is A) the CSPs responsibility and B) is done in a timely and transparent manner. However, when we start looking at the off broadway CSPs, there are legitimate concerns on whether they are managing cyber security risks within the layers of their responsibilities. In NordVPN’s case it seems their hosting provider did not have a good vulnerability management program nor adequate situational awareness of threat actors accessing their management layer.
Do Due Diligence, Dig Deep
It is important to understand that not all Cloud providers are created equal, especially in the Software as a Service (SaaS) space. In my previous writings I discussed that the majority of SaaS offerings are run by small Ma and Pa dev shops who just do not have the time nor resources to do security well. Our businesses may thrive off of the SaaS solution, but we are usually blind to the lower layers which house the poor architectures and vulnerabilities.
Therefore, it is recommended to add technical due diligence into your procurement process to look beyond a SaaS provider’s boilerplate privacy and security sections on their website. This is because in all truths their “military grade encryption” is likely poorly implemented TLS, their “annual pentests” are nothing more than a default Nessus scan skipping over the inevitable vulnerabilities in their layer 7 and sound security architecture, vulnerability management and security monitoring are likely not a thing.
Mature Your Vulnerability Management Program
While you may not be able to manage the lower layers, you should consider getting a list of the software layers below your layers of responsibility and add them to your vulnerability management program. Being aware of vulnerabilities in the lower layers can enable your organization to better understand your risk exposures and more importantly keep pressure on your CSP to do the right thing and manage the risk accordingly.
Design for Breach
Most IT professionals, especially in the networking space are likely aware of the concept of the “zero trust model” by now. Networking vendors have been pushing microsegmentation through Network Access Control (NAC) capabilities for well over a decade and we are seeing many organizations finally putting some sort of trust boundary between users and critical systems. However, microsegmentation is only one layer of the zero trust model and in the day and age of using outsourced IT services such as Cloud, we need to start designing zero trust into our systems well beyond the network.
Details are not available on how the attackers actually conducted the attack to gain access to NordVPN’s server and then steal their private key. However, it stands to reason that there may have been too much inherit trust between NordVPN’s application and NordVPN’s hosting provider. Therefore, when leveraging Cloud services it is important to take into consideration the layers below and the risk they post to your system if they were compromised.
Conclusion
When we are designing systems which sit on top of “other people’s computers”, our architectures must now consider that the lower layers could be breached and understand how that would impact the confidentiality, integrity or availability of our layers. Proper due diligence, security architecture and threat modeling should be tools in our tool belts to better comprehend the threats and design to minimize the impact of a breach.
COMMENTS