As we discuss in Learning Tree’s Cloud Security Essentials course, the cloud is based on open-source technology. And, if you are developing your own solutions, as you do in PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) cloud settings, you should use carefully tested and trusted open-source components.
The OpenSSL project provides core components for cybersecurity. For one thing, it supplies the reference implementation of the TLS/SSL protocol suite. Network servers like Apache and clients like Firefox use the OpenSSL shared libraries. The OpenSSL shared libraries are called “Middleware” as they sit between the operating system and the applications.
The OpenSSL project also maintains the
openssl application toolkit, providing everything you need to create and run your own PKI (or Public Key Infrastructure).
Good stuff, well designed and implemented, and vital to the security of the Internet.
But they were hacked?
Imagine if the U.S. Marine Corps recruiting office in the local strip mall had been vandalized because the property owner left a labeled ring of spare keys lying on the sidewalk one evening. You wouldn’t say that the intruders fought and defeated the USMC! The OpenSSL hack was very analogous to this. Here’s what really happened.
Like most organizations, the OpenSSL project’s web site is hosted by someone else. This is easy to determine, look up their IP address and then see to whom that has been allocated:
$ nslookup www.openssl.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: www.openssl.org canonical name = openssl.net. Name: openssl.net Address: 18.104.22.168 $ whois 22.214.171.124 % This is the RIPE Database query service. [....] inetnum: 126.96.36.199 - 188.8.131.52 netname: NET-INDIT descr: Indit Hosting AB - Cloud country: SE admin-c: NOC140-RIPE tech-c: NOC140-RIPE status: ASSIGNED PA mnt-by: MNT-INDIT source: RIPE # Filtered role: Network Operations Center address: Indit Hosting AB, Box 48 address: 433 21 Partille, Sweden [....]
Tellingly, the IP addresses on either side of OpenSSL’s, 184.108.40.206 and 220.127.116.11, resolve to
host-002.vlan501.indithosting.net respectively. (Note that I’m assuming that they were still at the same provider two weeks later.)
The terse final report is available here. To add a little more background:
The home page was defaced in the middle of the night, detected and restored within two hours. The software repositories were audited, and found to be unchanged. Since these are the people providing the standard cryptographic hash tools, I’ll take their word for their data integrity!
The OpenSSL server is a virtualized machine. The server operating system itself wasn’t compromised.
It runs on top of either VMware ESXi or the Linux-based KVM virtualization (the provider offers both). The hypervisor wasn’t compromised.
So what happened? The final report says:
Our investigation found that the attack was made through insecure passwords at the hosting provider, leading to control of the hypervisor management console, which then was used to manipulate our virtual server.
That’s a risk of any use of someone else’s facilities: you can become a victim of their poor housekeeping.