What’s The Story of the OpenSSL Hack?

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?

Don’t panic.

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

Non-authoritative answer:
www.openssl.org canonical name = openssl.net.
Name:   openssl.net

$ whois
% This is the RIPE Database query service.

inetnum: -
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, and, resolve to gw.vlan501.indithosting.net and 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.

Bob Cromwell

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.