• Enable passcode/lock

Mobile phones have had passcode capabilities for a long time. Make sure you’re using it, since a passcode lock is often the first line of defense.

• Erase all data before a return, repair, or resale

If you will no longer be the owner in possession of the device, it’s best to erase everything you can first. Everything. If you can do a factory reset, do so, because your phone constantly records information and there is always some data that isn’t easily found, let alone purged.

• Regularly update firmware

I’m guilty of not doing this– sometimes the update notification will sit around for a week before I finally give it permission to run. But this is one of the easier things to do, since it’s mostly automatic.

• Don’t run shady apps

Just like with a personal computer, if you run unknown or untrusted applications, you substantially increase your chances of getting got. So if you don’t want to get got, be prudent about what apps you run on your device.

• Take advantage of the web browser’s security

For smartphones with native web browser apps, be sure to use the security features to clear caches and stored passwords when it’s necessary. Just because a web browser is on a mobile device doesn’t mean it’s a security lightweight. Check out the “settings” or “options” to see just how much your mobile phone web browser can do to help you out.

• If you’re not using it, disable it

I’m also guilty of leaving stuff running unnecessarily. Be careful about leaving debug mode enabled, Bluetooth and wifi on, etc. Generally speaking, the more doors you leave unlocked, the lighter you sleep at night. Turning off unused services when they aren’t needed is a good habit to form, even outside the realm of security.

• Secure that email

In addition to providing native web browser apps, many smartphones also come bundled with a native email app. Check the settings for these apps to take advantage of any security features they’re offering (such as SSL/TLS).

• Use a phone tracker

The GPS can be bad for privacy if you are reckless with it. However, it can also be a powerful tool to help you recover a lost/stolen device. I believe the iPhone 4 has a built in device-finding service (complete with a remote wipe). But even if you have a different smartphone, there is almost certainly an app that provides some remote tracking for lost devices (i.e. Where’s My Droid app for Android).

This certainly isn’t a comprehensive list, but it should be enough to get both new and old smartphone users thinking about general mobile device security in a healthy way.

I received an email the other day supposedly sponsored by a reputable programmer-related site. What it entailed was signing up for a big vendor’s developer program. If I did so, they would send me a $15 gift certificate to one of the major online retailers. I’m trying to keep all parties in this matter anonymous simply because I do not want to promote anything involved in this so-called promotion, and the actual parties involved are irrelevant. The email went something like this:

 

Happy Holidays Developers!

Get a $15 [online retailer] Gift Certificate by joining the [vendor] Developer Program (no charge!)

Thanks to your [programmer site] participation, here’s all you have to do!

1. Visit The [hyperlink to vendor site] and register at no cost!

2. [vendor] will send you a validation email: confirm your registration following the URL provided in the email which will prompt you to choose a password

3. Once you have chosen a password, [vendor] will then send you a password reset email: forward the password reset email and the sign up email address used to [promotional site email]

4. Once verified on our end, a gift certificate will be sent to you promptly after the program ends!

Hurry! This is limited to the first 600 respondents, one per person.

For full terms and conditions please visit [marketing link to promotional site]

Step 3 is the one that caught my eye here. You want me to forward you an email sent to me that allows me to reset my password? By doing this I would essentially be sending the promoter an email that contained a link with an embedded token allowing them to authenticate as myself and then change my password, essentially gaining access to my account at this vendor site. Mind you, this isn’t exactly a critical account. But still these are very poor security practices.

So, what’s to be learned from this? Pay attention to what’s being asked of you. If it seems slightly out of the ordinary, it probably is. Inboxes are being filled with more and more spam these days, some make it through, and some even seem legitimate. It’s up to the users to educate themselves on how to detect and avoid these types of situations. In closing, I’ll leave you with a list of things you can do to help protect yourself.

• If it seems too good to be true, it probably is. So use common sense people!
• Do not click on links in emails – period! Just because it says it’s a link to SiteA doesn’t mean it’s actually going there.
• Enable spam controls on your email client – if you’re using Outlook, Thunderbird, or even Gmail’s web interface – they are all pretty good at detecting what may or may not be spam.
• Use multiple emails or use gmail’s ‘+’ email features or mailnull to help sort out those mailing list emails and let you know which emails are being distributed to others.
• Do not load images by default or at all.
• Do not enable scripting at all!

These are just the tip of the iceberg, but you get the idea. Help protect yourself and you’ll be helping to protect all of us.

To enable the administration of your various virtual machines, storage, clusters, datacenters, and the like, you can now use the vSphere 5 Web Client. Before it can be used, it must be authorized; the best instructions I found for this are here. Follow the steps in the “Authorizing the vSphere Web Client (Server)” section. This is a one-time configuration necessary to enable the vSphere Web Client.

Once authenticated, you will see something that looks very similar to the Windows-based vSphere Client running in your browser.

This will satisfy most of your management needs, but it leaves out an all-important capability; the ability to remotely view the console of the systems. There’s a Console button, but it won’t work on a Mac. Once you’ve installed a machine, you can typically enable some sort of remote desktop capability in the operating system, but what do you do before then? If you’re running Windows, you use the vSphere client and open a console, but on a Mac, you’re out of luck. Right? Wrong.

There is an under-documented feature of vSphere that allows the capability of opening up VNC connections from the host directly to the console of the virtual machine. To perform this, we first have to enable incoming connections to your vSphere server, as vSphere 5 has an integrated firewall. This is the one step you will actually need to use the Windows vSphere Client; everything else can be done using the Web Client. This step needs to be executed once for each vSphere or ESXi host running virtual machines you want to access using VNC.

In the Windows vSphere client, choose the host you wish to enable VNC connections on. Choose the Configuration tab and on the left choose Security Profile. On the right, next to Firewall click Properties… As VMWare does not include VNC as a protocol, it is not listed as an available option. However the ports allowed by the gdbserver protocol will suit our purposes. Check the box next to gdbserver. (It is also wise to highlight the gdbserver line and click the Firewall… button and lock down where you will allow these VNC connections to take place from; in ours I restricted this to our intranet.) Click OK and you’ve now enabled the incoming ports to be used for VNC.

Finally, enabling VNC access to the console machines is a matter of setting advanced configuration parameters on each virtual machine, which can only be done when the virtual machine is off. To open up the advanced configuration:

• In the Windows vSphere client, choose the machine, click Edit Settings…, click the Options tab, choose Advanced->General on the left, and click Configuration Parameters… on the right.
• In the Web client, choose the machine, click Edit Settings… under the VM Hardware section, click VM Options, click Advanced, and click Edit Configuration….

In both cases, you now want to add three rows by clicking the Add Row button.

Once you’ve added these rows and click OK, you can now use a VNC client to connect to the console of the machine. Power up the machine, and then using Finder on the Mac, choose Go->Connect to Server (or hit Command-K), and type the following:

vnc://<ip or name of esxi host>:<port chosen in configuration settings>/

and click Connect. You will be prompted for your password, and depending on your client/version of OSX you may receive a warning about how keystroke encryption is not enabled. Accept the warning, and you will see the console of the virtual machine! (And note, since Macs don’t already use the three-finger salute, you can safely just press Ctrl-Alt-Del in that VNC-window to log into Windows systems!)

Once you’ve installed the operating system of choice, and enabled that OS’ remote desktop capability, you may want to disable this VNC access. Just shut down the VM, go back into the advanced options and change the RemoteDisplay.vnc.enabled setting to false.

Hopefully at some point soon, VMWare will enable a true web-based console application (which doesn’t require host-specific plugins to be installed) to go with their nice new web client. Until then, this is a reasonable workaround for accessing virtual machines using a Mac.

In a previous job, I was charged with creating the security documentation for a particular government system, including the disaster recovery plan. That plan necessarily had to include the power requirements for the system. However, with a certain amount of digging, I discovered that by the standards to which I would be held, the simple fact that the servers used either 110V or 220V power was considered “secure unclassified information” and my report would require rather cumbersome treatment. Mind, what put it over the top was not that the servers required 110V, or that the servers required 220V, but simply that the servers might require one or the other. Or, in other words, that the servers required electricity in the same fashion as every other standard server. The bleedingly, patently, absurdly obvious. But that fact was somehow important for security.

There is a certain tendency, with respect to security, to classify, render confidential, or otherwise obscure every piece of information. I cannot count how many times I have heard “we can’t tell you what kind of encryption we use – that would make it insecure!” or some other variant. Indeed, there is a certain value to hiding some seemingly obvious pieces of information – the number of servers, the ports being used, the location of a datacenter in a building. These are not without purpose. There is no sense in making an intruder’s job any easier, and great value in making it as trudgingly difficult and annoying for them as possible.

But this must be tempered with a modicum of sense. In risk assessment terms, this means examining a piece of information and determining what level of risk it exposes. There is no sense in restricting the fact that servers run off of electricity; an intruder knows that – it’s not something that takes much knowledge to figure out. There’s no sense in hiding the fact that a base which is in contact with the local population can see the mountains – the insurgents know that. These are obvious things.

And there’s an important psychological component there. By trying to secure patently obvious things, security by obscurity (already a bad idea) becomes security of absurdity. The very concept of security becomes eroded. Yes, it’s easier to treat all information as secure, but the end users won’t view it that way. What they’ll see – correctly – is a security posture which has gone amok and which is not connected to the reality of their work. And they’ll start ignoring it because it’s ridiculous. And then they’ll be ignoring actually sensible security; they’ve lost confidence in the directives and the purpose behind them. And then you have a problem.

The point is to maintain a real connection with the people who have to implement security directives. As I’ve said before, their job is not to keep your infrastructure secure – their job is, well, their job. To keep people following secure processes, they have to be invested. They have to be able to understand why they’re doing these things. You have to acknowledge that they know the mountains are there, and work within that reality.

The Underground Economy: Priceless (pdf) touches on the subject in a great amount of detail, even explaining the importance of reputation and the lengths people take to avoid prosecution.

Essentially, public and private servers host communities of individuals who offer their services for a fee. Maybe one person will help someone else cash out an entire bank account (for a 50% cut). And maybe another person will deliver ill-purchased goods to a safe location (for a 30% stake). In the mix are also those who initially did the work (or wrote the code) to capture the information, as well as people who specialize in forging IDs, curious researchers, law enforcement… the list goes on. Compromised financial data seems to lead to a very deep chain of events that attracts many people with varying skillsets, most of whom are simply offering to perform the same hustle(s) over and over. It is a system where both information and skills are bartered/exchanged and high risk is accepted for high returns on investment.

But not all participants are highly skilled– there should be some low-hanging fruit in there too, right? Surely, there are people who aren’t as cautious or who miscalculate their risk of exposure, yet we still have trouble keeping up with even a fraction of the online fraud. While I’m glad we are focusing efforts on preventing information from being compromised in the first place, I feel like there is a growing opportunity to focus a lot more research on thwarting these high-risk behaviors directly. Sometimes you have to treat both the symptom and the cause.

Crockford on JavaScript: The Early Years

The example that reminded me of this relates to Bitcoin, a somewhat controversial form of digital currency that’s recently been discussed by several high-profile media outlets. I’m not going to talk about any specific merits or problems associated with Bitcoin, but note that it relies on mathematically solid encryption schemes to allow transactions while preventing theft.

However, regardless of how strong your encryption, an insecure application using that encryption can introduce easily exploitable vulnerabilities. And Adam Baldwin of evilpacket has shown how this can happen with Bitcoin by creating a video demo of XSS/CSRF problems in a Bitcoin exchange site. These application-level issues could enable an attacker to steal Bitcoins without cracking the basic cryptography employed.

Using proven security technologies is important, but it’s only one part of securing your organization. I still remember my surprise when I first discovered that an “unbreakable” cipher did exist: the one-time pad. But using one-time pads is often impractical, and they are still susceptible to compromise from human factors. Building secure business operations requires understanding the risks at each level of a system and having a defense-in-depth response.

At Gemini, we can help you assess those risks, architect strategies to handle them, then apply those solutions in your organization to produce measurable security improvements. Don’t simply trust in “encryption” or WAFs to protect your data – let us help you understand the big picture of your company’s security today.

The main issue that was holding me up wasn’t anything to do with Android-OpenVPN port itself. It was simply to do with the Android device I was using (thanks Samsung for crapping on us with the Galaxy S devices). A recent ROM update finally put the final pieces I needed into motion for being able to utilize OpenVPN. The main holdback was the lack of tun in the kernel of my Android build.

Anyways, if you’ve been needing VPN access, or specifically need the OpenVPN variant they give it a shot. Outlined below is what you’ll need:

• A rooted Android device – You may also need an upgraded rom. The project is built using cynogen 6. If your device supports this ROM or one of its variants I highly recommend it. But if you’re like me and on a Samsung device or other unsupported device, look for upgrades at XDA-Developers.
• An OpenVPN configuration file. You’ll most likely have this along with your desktop client. (client.ovpn)
• Android-openvpn-installer – Available here or from the Android Market– this is mostly used to install the OpenVPN binaries onto your device.
• Android-openvpn-settings – This (and this) is what you’ll actually use in Android to start/stop/configure the VPN.
• A way to transfer files to your device’s SD card or internal storage (for those of you without expandable storage).

1. Begin by rooting your device if it’s not done already. Look towards XDA-Developers if you need help with this.
2. Install the OpenVPN-Installer either from the Google Code page, or directly from the Android Market.
   1. Run the installer and remember which path you choose to install OpenVPN into. I chose the “/system/bin” directory. You’ll need to enter this directory into OpenVPN-Settings later.
   2. If it installs correctly, it will show a green plus button and continue on.
3. You’ll now need to transfer your OpenVPN configuration file to your device’s external storage. Create a folder on the root of the storage called “openvpn” and place your configuration file here.
4. Install OpenVPN-Settings either from the Google Code page, or directly from the Android Market.
   1. Once installed, you’ll need to configure it. Menu (button) -> Advanced
   2. Now you’ll want to configure the two paths: “Path to configurations” and “Path to openvpn binary“
   3. Select them one at a time and enter the required paths. For me, the configurations path ended up being “/sdcard/openvpn” and the binary path was “/system/bin/openvpn“.
5. Now return to OpenVPN settings by using your back button and you should see a connection listed with the same name as your configuration file.
6. Enable the VPN by pressing the OpenVPN checkbox, once it’s enabled, press the checkbox for the connection you want to connect to.
7. You’ll need to enter your username and password, but the notification will most likely be in the top bar, so pull it down, click the notification, and enter your credentials. (You’ll have to do this every time you connect, no saving here).
8. Enjoy OpenVPN goodness!

They’ve made the process of using it pretty straight forward, especially for what it used to be. Feel free to check out the Google Code sites if you would like to contribute or have any issues.

One big caveat on all of this as Uncle Ben once said – “with great power comes great responsibility” so be sure to continue using safe (read secure) computing practices, as once you’re on the VPN, your device is now connected to your company’s VPN. In most cases, this is useful for communicating with exchange servers or shared file access. But be sure to disconnect when you’re done using it and ensure you keep a device password.

Links:

OpenVPN-Installer – Code | Market

android openvpn-installer

OpenVPN-Settings – Code | Market

android openvpn-settings

We had a couple people at CTIA last week — people whose words carry weight — tell us off the record that the next major version of Android would take big strides toward stopping the ugly trend toward severe fragmentation that has plagued the platform for much of this and last year. You know, the kind of fragmentation that has already left users running not one, not two, not three, but four distinct versions of the little green guy (1.5, 1.6, 2.0, and 2.1) depending on a seemingly arbitrary formula of hardware, carrier, region, software customization, and manufacturers’ ability to push updates in a timely fashion. Put simply, Google’s been iterating the core far faster than most of its partners have been able to keep up. – Engadget

Why should this matter? Well for one, having your user base spread out across multiple different versions of your OS or application can make patching updates a very serious issue. Using Google’s Android as the main example here – if you have a vulnerability found in, say, version 1.6 of your product, and you patch it in version 2.0 (Don’t ask. I don’t know where v1.7-v1.9 are either.), then having users update would be a natural progression, right? Well what if those users can’t upgrade due to one reason or another (carrier limitations). Well then you have the problem Android has been facing since launch.

Even the latest forms of Android vulnerabilities are only currently fully patched if you have v2.2 or better. So where does that leave all the people with v1.5-v2.1. Well they’re forced to find some other means of upgrading if their device or carrier won’t allow them to update. But let’s face it, not everyone has the means to root their device, dig through the numerous posts on xda-developers, and find a working rom of an updated version of Android. This entire process also shoots itself in the foot for most people in the corporate world where rooting your phone automatically takes it out of compliance with most security policies. Keeping your OS, Software, or Services patched and updated is one of the most effective ways to fight against vulnerabilities (those that are out of your control that is).

The fact that Google has, if anything, at least hinted at the fact that they’re going to take measures to help improve the process and outline of how the platform will be distributed and updated at least shows that they’ve recognized the problem, and might even go back and try and fix those in need now. But at least something can be done for future platforms to ensure everyone stays up-to-date (read: secure).

We’ve talked about the importance of two-factor authentication in the past, and even a few other areas where it’s implemented.

Google did an excellent job at throwing together some tutorials on how to set-up everything and ensure your experience is pleasant. I would go into a detailed tutorial on all of this myself, but really I doubt I could do a better job than they did. But for those who just wanted a quick refresher, here goes. You can also read a fairly straight-forward take on everything directly from Google themselves and learn how it works.

1. Setup
2. Signing in with verification codes
3. Signing in using application-specific passwords

Setup

Go to your Accounts settings page and look for the Using 2-step verification link. If you have the link, click it and start the setup process.

If you do not see the link and you are a Google Apps user, you might have to access the 2-step verification setup through a special URL. It is also possible that your domain administrator has not yet set it up for your organization. Check with your domain administrator to find out.

Once you have it enabled you’ll want to choose your primary form of contact in order to determine your verification code. If you have a “smart device” you can download an app for it which will provide an RSA key generator and generate random verification codes directly on your device.

Depending on what flavor of OS you have on your device, you’ll need to grab it from a different location.

• Android – Search for Google Authenticator from the Marketplace, or install it remotely
• iThings (iPhone, iPod Touch, iPad) – Search for Google Authenticator in the App Store.
• BlackBerry – Browse to http://m.google.com/authenticator from your device to download and install.
• WinMo / Win Phone 7 – Sorry, Google simply doesn’t love you yet, but you can still have the codes sent to you via SMS or listen to a voice message. This can be found on the Setup Page.

Signing in with verification codes

Once you have the Google Authenticator setup (or enabled SMS / voice messaging, again sorry WinMo guys, I feel your pain), you’re ready to roll with two-factor authentication. Once the set-up is complete, you’ll be logged out automatically. Go to login again, and suddenly you’re not required to enter a verification code. Welcome to the second factor!

These codes are generated every 30 seconds by the Google Authenticator using one-time passcodes, which are generated using open standards developed by the Initiative for Open Authentication (OATH) (which is unrelated to OAuth). These implementations support the HMAC-Based One-time Password (HOTP) algorithm specified in RFC 4226 and the Time-based One-time Password (TOTP) algorithm currently in draft.

The applications support:

• Multiple accounts
• Support for 30-second TOTP codes
• Support for counter-based HOTP codes
• Manual key entry of RFC 3548 base32 key strings

Signing in using application-specific passwords

Great, now you’ve added a 2^nd factor to your authentication (something you HAVE). But what about all the other areas where you interact with your Google Account? Perhaps you use GTalk, or access your email via a POP/IMAP. Well, Google has thought of that as well, and I personally like the way they implemented this.

Google has implemented a per-application password generation process that links a randomly generated password to your Google account. So what you do is generate a password, add a label associating what application or service you’ll be using it for (so that you can track it later), and then you plug that password into the application or service where you normally would have used your standard Google account password. The key here is utilizing your password management of the app or tool where you’re using this. You’d mostly want to enable the “remember my password” on these tools, as most of you probably already do. The reason I think this is a little safer is that you can now remotely wipe those passwords.

You have the ability to revoke passwords from your account settings page on Google. So let’s say you access your Gmail from your laptop through Thunderbird. Your laptop is now lost or stolen. Along with other measures you should have already taken to protect your data, you can now simply revoke the password you’ve assigned to Thunderbird, and it has now just lost access to your email.

You do need to be careful, though, as I found out already; when you generate the passwords for your apps, you only have one shot of viewing the password. Once you click the “hide” button, it’s gone forever, or at least out of sight forever. It’s a password generator, not manager. So now I actually have two different passwords for my Thunderbird access; one for incoming mail, and one for outgoing mail (SMTP). As a bonus, it provides a little extra security as well.

The random passwords that are generated consist of 16 characters and utilize lowercase letters and numbers, so they’re complex enough to resist most brute force attacks.

Conclusion

So there you have it. If you’re a business utilizing Google Apps, or an entrepreneur using Google as your email and document repository, I’d seriously consider enabling the two-factor authentication that Google has rolled out.

But WHY should you enable this, you might ask? Well, consider the scenario where you’ve used strong passwords, you’ve ensured that you haven’t reused the same password, and you’ve done everything to protect yourself. You’re still limited to a single point of failure. No matter how paranoid secure you are, the PASSWORD is still your weakest link. Key loggers, network sniffers, or just someone eaves-dropping is all it takes. If that one item is out in the open, then you’re doomed. But, add now a 2^nd form of authentication, via something you have, along with something you know. You know your password, and now you also have something–whether that be a digital certificate in the form of secure tokens, or in this scenario a randomly-generated code that is only available on your device (and for a limited time, at that). So, not only would someone need to know your password, they’d need to have access to your phone (which I hope you’re also protecting with a password, swipe-pattern, or pin).

And let’s not forget the added bonus that Google is offering with individual application password generation, and the ability to remotely revoke those passwords. It’s like getting your cake and being able to eat it too!