amuck-landowner

Recent openssl website defacement

wlanboy

Content Contributer
First off the final details:


Last updated: 3rd January 2014

On Sun 29th December 2013 at around 1am GMT the home page of
www.openssl.org was defaced. We restored the home page just after 3am
GMT and started forensics, investigation, and recovery.

The OpenSSL server is a virtual server which shares a hypervisor with
other customers of the same ISP. 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.

The source repositories were audited and they were not affected.

Other than the modification to the index.html page no changes to the
website were made. No vulnerability in the OS or OpenSSL applications
was used to perform this defacement.

Steps have been taken to protect against this means of attack in
future.

And of course the response of VMWare:


VMware is aware of suggestions that the recent defacement of the
OpenSSL Foundation website may be as a result of a hypervisor compromise.

The VMware Security Response Center has actively investigated this incident
with both the OpenSSL Foundation and their Hosting Provider in order to
understand whether VMware products are implicated and whether VMware
needs to take any action to ensure customer safety.

We have no reason to believe that the OpenSSL website defacement is a result
of a security vulnerability in any VMware products and that the defacement
is a result of an operational security error.

VMware recommends the use of vCloud Director in deployment scenarios
that require secure Internet facing access to Virtual Center and ESXi.
In the event that Virtual Center is directly Internet facing VMware
recommends customers remain current with patches and updates and that
they follow the best practices in the vSphere Security Hardening guides
https://www.vmware.com/support/support-resources/hardening-guides.html.

So at least no access to the source files.

"Just" a defacement.

But a reminder to all OpenVZ customers.

You are only as save as your hoster is.
 

drmike

100% Tier-1 Gogent
Everything is very insecure.

Security is still at infancy stage.

A lot of issues should be addressed through hardening and locking of everything by end user.   More tutorials, practices, etc. need published for folks.
 

nunim

VPS Junkie
Why exactky to the OpenVZ customers, when this was a VMWare host, nothing to do with OpenVZ?
OpenVZ allows vzctl enter <your container> without a password, so I believe he is saying you're only as safe as your host.
 

Aldryic C'boas

The Pony
To be fair, you should always exercise caution with any platform.  For example - VMWare and KVM hosts that allow console access... if you leave the console logged in, anyone coming after you that opens the console will be right inside the VM where you left off.
 

rds100

New Member
Verified Provider
@nunim true, you are only as safe as your host no matter what virtualization they are using. OpenVZ might require a little less typing once you've rooted the host node, but this doesn't make the rest (Xen/KVM/VMWare/whatever) any more secure.
 

Echelon

New Member
Verified Provider
Based on their comment at the end of their release, I'd imagine they're doing the same as quite a few companies are, which is using VMware as a hypervisor, and writing their own control panel to handle communicating and managing the hypervisor on the bare metal machines. This is purely speculative, but this is what I gather from the statement.
 

JPC-Sabrina

New Member
Very interesting to note this: "Our investigation found that the attack was made through insecure passwords." Pretty basic practice to keep passwords secure. There are many ways to gain access but I believe the first potential open door for an attack or infiltartion starts right there.
 
Top
amuck-landowner