Sometimes there are risks you just can’t anticipate as a homeowner, although I have to say that front door doesn’t look bad for having a cannonball hit it at 1,000 ft/sec.
Next up on MythBusters: cannonballs that can’t be stopped.
Monthly Archives: December 2011
Quoted in Inc.
A writer for Inc
has quoted me in an article called “New Ways to Keep Hackers Out of Your Business”
While you might think of encryption as something we’ve been using only since the advent of computers, it’s really a rather old practice. “Encryption is based upon a secret,” says Davi Ottenheimer, expert on the Focus network and founder of San Francisco-based security consulting firm flyingpenguin, who likes to cite Julius Caesar and Thomas Jefferson as examples of historical figures who have hidden things by using cryptography.
Caesar used a substitution cipher to communicate with his generals that involved replacing the letters in a message with a shifted alphabet. For instance, a shift of three would make all the As in message Ds; Bs would become Es, and so forth.
Jefferson used a type of wheel cipher during the Revolutionary War that involved 36 disks stacked on an axle, each with a different version of a scrambled alphabet on the outer edge. When both the sender and receiver had the numbered disks in the same order and rotated them in the right way, an understandable message would appear.
“People have historically improved encryption during times of conflict or war,” Ottenheimer says. “It’s all about secrecy, really, confidentiality. It doesn’t require super-sophisticated technology as much as it requires people being fairly intelligent about how they can keep a secret.”
VMware vCloud Connector 1.5 Certificate Installation
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 changemed. 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 changemee. 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.
Phone Porting to Bypass 2-Factor Authentication
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.