# Recent openssl website defacement



## wlanboy (Jan 3, 2014)

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 (Jan 3, 2014)

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.


----------



## rds100 (Jan 3, 2014)

wlanboy said:


> But a reminder to all OpenVZ customers.
> 
> You are only as save as your hoster is.


Why exactky to the OpenVZ customers, when this was a VMWare host, nothing to do with OpenVZ?


----------



## nunim (Jan 3, 2014)

rds100 said:


> 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 (Jan 3, 2014)

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 (Jan 3, 2014)

@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.


----------



## mikho (Jan 3, 2014)

drmike said:


> More tutorials, practices, etc. need published for folks.


you are more then welcome to send in your entry : http://www.lowendguide.com/contest-2013-2014/


----------



## Echelon (Jan 4, 2014)

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.


----------



## RyanC (Jan 6, 2014)

nunim said:


> OpenVZ allows vzctl enter <your container> without a password, so I believe he is saying you're only as safe as your host.


Linode was running xen and the hackers(lol) had no issues accessing VMs on there.


----------



## Wintereise (Jan 6, 2014)

RyanC said:


> Linode was running xen and the hackers(lol) had no issues accessing VMs on there.


Xen-Pv and HVM are *very* different things.


----------



## JPC-Sabrina (Jan 28, 2014)

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.


----------

