Working in the security industry we are regularly in conversations about how BYOK (Bring Your Own Key) can help solve security concerns around data confidentiality, compliance, protection from espionage, and much more.
However, it is most often the case that BYOK does not and cannot solve the problems that people are led or misled to believe it does.
This post is an attempt to address some of these misunderstandings.
First, we need to establish the vocabulary; BYOK is short for Bring Your Own Key, which means the customer provides a data encryption key to the service provider, and the service provider then holds and uses this key for some security function in relation to providing service to the customer.
Already here now that we talk about it, it should be clear that there are a great many problems this scheme does not solve, as the service provider holds a copy of the key.
Another key acronym in security is MFA, or Multi-Factor Authentication. MFA requires that the customer does not just log in using a username and password, but that at least one more factor is provided, which could be a time-based code the user can read from a device only the user possesses. In a sense, this is unrelated to BYOK, but as we shall see, MFA is often the actual working solution to problems believed to be addressed by BYOK.
With that out of the way, let’s look at a few common myths of what BYOK brings to the table then go through why this is not actually the case:
Myth #1: BYOK protects my data in case my account gets compromised.
That would be lovely, but this is not the case at all. First of all, the data encryption key is online all the time. This is a necessary condition for the service to be available and online because what good would your cloud service be if data wasn’t accessible? So, your key is online and now your account gets compromised. An attacker successfully poses as you, so naturally, all data is available to the attacker just as it would be to you, BYOK or not.
Myth #2: In case of compromise, revoking my key renders data unreadable.
This is wishful thinking, unfortunately, and for reasons, you may not expect. As is the case on commonly available BYOK platforms (AWS to name one) the key you bring is not even used for the actual data encryption! Since the service provider cannot trust that a customer can competently generate a strong key, the service provider will use their own key for the actual data encryption.
This key though may then be encrypted with another key, and then finally this package can be encrypted with the actual customer-supplied key. What this means is that the customer has some degree of control over one of the keys used in the encryption of a ‘key package’ which may be used in concert with the encrypted data during a bulk transfer between regions for example. But this is a very niche use. In day-to-day operations, on the most well-established BYOK-enabled platforms in the world today, the customer-supplied key plays NO role in data encryption of the customer data.
The customer can lose the key, revoke the key, modify the key, get the key stolen, have the key tampered with, or all of the above, leaving the day-to-day operations of the service absolutely and completely unaffected because the customer-supplied key plays no role in day-to-day operations. This is not a ‘dirty secret’ in any way; this is well documented in publicly available descriptions of these systems.
The only realistic protection against account compromise is MFA. You can only do so much to make it more difficult for an attacker to compromise your account. That’s why you need to realize that when your account is compromised, someone can actually pose as you, and do what you can do. Cryptography cannot help you at this point.
Myth #3: If the service provider is compromised, I can revoke the key.
By now we know your key isn’t used for actual data encryption. But for argument’s sake, let’s play along and pretend it actually is (but it really isn’t). This means the service provider is encrypting data using the customer-supplied key to which they hold a copy, otherwise, they couldn’t use it.
Now, what happens if the service provider is compromised? Let’s say that either an attacker gains full control of the service provider platform or the government under which the provider operates seizes their systems. Well, the key is being used by the service provider for data encryption and decryption, so obviously the key is available there in one form or another. In other words; what the customer does with their copy of the key has no bearing on the copy that is available and in the hands of the service provider or whomever now controls their platform.
Realistic protections here are along the lines of choosing the region in which the service is provided carefully and ensuring the service provider implements a mature information security management system.
As was said famously by renowned cryptographer Bruce Schneier, ‘If you believe cryptography solves your problem, then either you do not understand your problem or you do not understand cryptography.”
There is a lot of truth in this statement. It does not mean that cryptography does not play an important role in solving security challenges, but it does underline that simple encryption in isolation does not solve the challenges we are facing.
BYOK is no silver bullet. In fact, it is very often not even helpful. Further, if the employment of BYOK delays initiatives to seriously implement MFA or other effective security mechanisms, then BYOK may be outright harmful to the overall security posture of your organization.
I hope this short write-up helps bring clarity to an area of information security that is too often not discussed in detail or even widely understood.
As part of our mission to secure the world’s OT, IoT and Cyber Physical infrastructures, we invest resources into offensive research of vulnerabilities and attack techniques.
Ripple20 are 19 vulnerabilities revealed by Israeli firm JSOF that affect millions of OT and IOT devices. The vulnerabilities reside in a TCP/IP stack developed by Treck, Inc. The TCP/IP stack is widely used by manufacturers in the OT and IoT industries and thus affects a tremendous amount of devices.
Among the affected devices are Cisco Routers, HP Printers, Digi IoT devices, PLCs by Rockwell Automation and many more. Official advisories by companies who confirmed having affected devices can be found here, in the “More Information” section.
The most critical vulnerabilities are three that can cause a stable Remote Code Execution (CVE-2020-11896, CVE-2020-11897, CVE-2020-11901) and another that can cause the target device’s memory heap to be leaked (CVE-2020-11898).
On behalf of our customers, we set out to explore the real impact of these vulnerabilities, which we’re now sharing with the public.
The research has been conducted by researchers Maayan Fishelov and Dan Haim, and has been managed by SCADAfence’s Co-Founder and CTO, Ofer Shaked.
We set out to check the exploitability of these vulnerabilities, starting with CVE-2020-11898 (the heap memory leak vulnerability), one of the 19 published vulnerabilities.
We created a Python POC script that is based on JSOF official whitepaper for this vulnerability. According to JSOF, the implementation is very similar to CVE-2020-11896, which is an RCE vulnerability that is described in the whitepaper. Also mentioned about the RCE vulnerability: “Variants of this Issue can be triggered to cause a Denial of Service or a persistent Denial of Service, requiring a hard reset.”
Test 1 target: Samsung ProXpress printer model SL-M4070FR firmware version V4.00.02.18 MAY-08-2017. This device is vulnerable according to the HP Advisory.
Test 1 result: The printer’s network crashed and required a hard reset to recover. We were unable to reproduce the heap memory leak as described, and this vulnerability would have been tagged as unauthenticated remote DoS instead, on this specific printer.
Test 2 target: HP printer model M130fw. This device is vulnerable according to the HP Advisory.
Test 2 result: Although reported as vulnerable by the manufacturer, we were unable to reproduce the vulnerability, and we believe that this device isn’t affected by this vulnerability. We believe that’s because the IPinIP feature isn’t enabled on this printer, which we’ve verified with a specially crafted packet.
Test 3 target: Undisclosed at this stage due to disclosure guidelines. We will reveal this finding in the near future.
Test 3 result: We found an unreported vendor and device, on which we can use CVE-2020-11898 to remotely leak 368 bytes from the device’s heap, disclosing sensitive information. No patch is available for this device. Due to our strict policy of using Google’s Responsible Disclosure, we’ve reported this to the manufacturer, to allow them to make a patch available prior to the publication date.
We’ve confirmed the exploitability vulnerabilities on our IoT lab devices.
On the negative side: The vulnerabilities exist on additional products that are unknown to the public. Attackers are likely to use this information gap to attack networks.
On the positive side: Some devices that are reported as affected by the manufacturers are actually not affected, or are affected by other vulnerabilities. It might require attackers to tailor their exploits to specific products, increasing the cost of exploitation, and prevent them from using the vulnerability on products that are reported as vulnerable.
SCADAfence Research Recommendations
Check your asset inventory and vulnerability assessment solutions for unpatched products affected by Ripple20.
The SCADAfence Platform creates an asset inventory with product and software versions passively and actively, and allows you to manage your CVEs across all embedded and Windows devices.
Prioritize patching or other mitigation measures based on: Exposure to the internet, exposure to insecure networks (business LAN and others), criticality of the asset.
This prioritization can automatically be obtained from tools such as the SCADAfence Platform.
Detect exploitation based on network traffic analysis.
The SCADAfence Platform detects usage of these exploits in network activity by searching for patterns that indicate usage of this vulnerability in the TCP/IP communications.
If you have any questions or concerns about Ripple20, please contact us and we’ll be happy to assist you and share our knowledge with you or with your security experts.
About Version 2 Limited
Version 2 Limited is one of the most dynamic IT companies in Asia. The company develops and distributes IT products for Internet and IP-based networks, including communication systems, Internet software, security, network, and media products. Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 Limited offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
SCADAfence helps companies with large-scale operational technology (OT) networks embrace the benefits of industrial IoT by reducing cyber risks and mitigating operational threats. Our non-intrusive platform provides full coverage of large-scale networks, offering best-in-class detection accuracy, asset discovery and user experience. The platform seamlessly integrates OT security within existing security operations, bridging the IT/OT convergence gap. SCADAfence secures OT networks in manufacturing, building management and critical infrastructure industries. We deliver security and visibility for some of world’s most complex OT networks, including Europe’s largest manufacturing facility. With SCADAfence, companies can operate securely, reliably and efficiently as they go through the digital transformation journey.