Chris Colotti offers a vCloud Connector 1.5 guide that highlights security

Security – It is important to understand the security of these components. The Server and Nodes communicate over SSL using port 8443 and this is the port used my the online portal to connect to your server. So it stands to reason you will want to generate some real certificates at least for your vCloud Connector server since that will be connected to be the remote nodes as well as the portal. The local nodes may not be as big a concern since they are on the same network. However you can see below, that if you are transferring a workload from a private cloud to the public the two nodes will interface and then you have an argument for some real certificates on all nodes as well. Generally in a production deployment I would get all real certificates, but in my lab I decided not to.

It is great to see this called out but I strongly recommend installing certificates in all deployments (and restriction to communication only over port 8443). In addition, certificate warnings should never be ignored once a new system is configured, as I explained in my presentation at VMworld — Penetration Testing the Cloud.

Vendor (i.e. VMware) default certificates should always be replaced. They do not have to be “commercial CA” certificates. You also can create your own signing certificate offline and use it to sign certificates that you generate. Many do-it-yourself options are available, as long as you carefully protect the signing certificate’s key. Microsoft’s public CA is common in Windows environments. Note that even a hardware security module (HSM) appliance is not very expensive and you of course can still use OpenSSL.

It not only is necessary to use certificates to protect authentication for all your critical systems connected to the network but it also a PCI DSS v2 Requirement.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

Requirement 2.1 gives a very broad statement that clearly is not limited to production use.

Always change vendor-supplied defaults before installing a system on the network, including but not limited to passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.

The VMware product guide for vCC (Installation and Configuration – vCloud Connector 1.5.0) has steps to replace certificates. Note the first sentence mentions production use again. Also note the passwords:

If you have not yet replaced the self-signed certificates in your vCC Server and vCC Nodes, you need to do so before production use.

Procedure

1. Log in to the admin Web console for each vCC instance in which you are going to replace the certificate.

2. For vCC Server, click on the Server tab, SSL button. For vCC Node, click on the Node tab, SSL button.

3. Generate and download a Certificate Signing Request by clicking Generate and Download CSR.

Depending on your certificate authority, you might need to create a new private key before you download the CSR. Contact your CA for more information.

a. If you need to create a new private key, log in to the console of the Server (hcserver) or Node (hcagent) as root. The default password is vmware.

b. At the prompt, change directory to /usr/local/tcserver/springsource-tc-server-standard/server or agent/conf.

c. Delete the existing private key.

/usr/java/jre-vmware/bin/keytool -delete -alias hcserver or
hcagent -keystore tcserver.jks -storepass changeme

d. Create a new private key.

/usr/java/jre-vmware/bin/keytool -genkey -keyalg RSA -keysize 2048 -alias hcserver or
hcagent -validity 1095 -keystore tcserver.jks -storepass changeme -keypass changeme

e. Log in to the Server Web admin console and download the CSR as described in Step 1 above.

4. When you have your certificates, upload the root or intermediate certificate from your CA and the new X.509 certificate for your instance by using the two Browse buttons.

5. Locate the certificates on your local machine and then click Upload.

What to do next

Once you have installed the valid certificates, deselect the Ignore SSL Certificate flag in the Node registration window for each Node. See “Register vCloud Connector Nodes with vCloud Connector Server,” on page 32 for more information on this flag. For the change to take effect, you must restart the Server.

More and more authentication systems are using SMS messages to verify the identity of users. Google, for example, offers you the option to send a PIN code to your phone when you login. This provides the second of two “factors” of authentication — something you have (the phone, with a one-time password) as well as something you know (your usual password).

IT News in Australia has a story that describes a real-world case of how this is bypassed by attackers.

The service providers generally require public forms of information before they will let you access your account — company name with tax ID and a mobile phone number with user name. This means only one-factor authentication (ironic, no?), based on easy-to-find information, is all that an attacker needed to initiate a port request (reassign a phone number to a new provider).

Back to the story, two separate social engineering calls were used to gather the information necessary according to IT News. Both calls were answered by someone other than the target individual.

In the days leading up to the fraud being committed, he had received two strange phone calls. One came through to his office two-to-three days earlier, claiming to be a representative of the Australian Tax Office, asking if he worked at the company. Another went through to his home number when he was at work. The caller claimed to be a client seeking his mobile phone number for an urgent job; his daughter gave out the number without hesitation.

Now with the information needed to execute the redirection the attackers also created camouflage to anticipate any alarm during service interruptions caused by a phone port.

The fraudsters used this information to make a call to Craig’s mobile phone provider, Vodafone Australia, asking for his phone number to be “ported” to a new device.

As the port request was processed, the criminals sent an SMS to Craig purporting to be from Vodafone. The message said that Vodafone was experiencing network difficulties and that he would likely experience problems with reception for the next 24 hours. This bought the criminals time to commit the fraud.

Within 30 minutes of the port being completed, and with a verification code in hand, the attackers were spending the $45,000 at an electronics retailer.

The anti-fraud system then kicked-in. Other systems may not have anti-fraud controls as a backup (may lack defense in depth) or attackers may be able to spend below the radar and avoid alarms. Either way this real-world porting attack is a good example of how authentication has to be assessed holistically; transfer, reset and other account management options are often a weak link.

The first company to meet the TÃœV Trust IT requirements has been announced:

Die Kunden sind vollständig voneinander getrennt und können die Produkte je nach Bedarf skalieren, um flexibel auf ihr Business reagieren zu können. Zusätzlich werden umfassende Zutrittskontrollen zu den Gebäuden des Unternehmens, Datenzugriffskontrollen und regelmäßige Stresstests der Infrastruktur sowie eine systematische Notfallplanung durchgeführt. Besonders hervorzuheben ist, dass die Host Europe GmbH die Daten ohne Ausnahme in eigenen deutschen Rechenzentren unterbringt und somit die deutschen Datenschutzbestimmungen und Gesetze gelten.

Here’s my translation:

The customers are completely separated and the platform can scale as needed to flexibly respond to demand. In addition, the company has extensive access controls for the buildings, data access control and regular stress testing of the infrastructure as well as systematic contingency planning. Most noteworthy is that Host Europe GmbH cloud solutions are located only in German data centers and thus accommodate German data protection regulations and laws.