A few years back, I was working as a tech writer for a company which made medical software. We were trying to get an important certification that we’d need to sell our product. And a crucial part of that was good documentation: we had to show how it worked, what it did, how it tracked everything, how it was secure, etc. Well, that’s what you have a tech writer for, so all is good.

It’s important to know, I didn’t have any existing documentation to work with. There was a wiki which had the developers’ notes in it, but that’s it. Nothing by way of formal hand-it-to-an-outside-entity documentation.

Okay, that’s not too abnormal; tech writing is expensive, and many companies don’t bother with it until an auditor is breathing down their neck. Hardly ideal, but to be expected, and I did have time. So, I set to it.

Since there wasn’t any existing documentation to re-do, I based my organization around the expectations set by the certification. And, a good week before the deadline, I turned in the completed documentation, all 100-something pages of it.

And that’s when disaster struck. The auditors decided they wanted the documentation in a completely different format – they weren’t going to read our documentation, no. They wanted us to fill out a questionnaire. The questionnaire was very comprehensive, encompassing exactly as much material as my documentation covered. And I had less than a week to complete it. I told my boss “No problem.” And I gave him the completed questionnaire in 3 days.

(more…)

One of the biggest complaints I’ve had with VMWare vSphere and VMWare ESX/ESXi over the last few years is that managing my virtual machines from my Mac computer was a hassle. The VMWare management utilities are all Windows-only, and even the few web-based tools either do not work or are extremely limited from a Mac. While it isn’t perfect yet, VMWare vSphere 5 has made it so you can actually do just about anything you need to using a Macintosh computer; you just need to go through a few hurdles.

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.

I recently acquired a new iMac at work to replace the 4yr old one I was using. The new iMac came with Lion on it, and since I had upgraded to Lion on my work machine, I went ahead and upgraded all of my home machines as well. My Macbook Air is my primary “workstation away from work”, and keeps client data. Because it does, I use FileVault on it. Under Snow Leopard, that only encrypted my home directory. Under Lion, FileVault now encrypts the entire drive, not just $HOME. However, if you upgrade, you have to explicitly convert your machine to use the new FileVault. And you need a lot of disk space to do it…

I have a 250 GB SSD drive – not exactly the biggest drive – and I have 11GB of that left. I wasn’t able to upgrade my machine to the new FileVault – until I moved the majority of my data to another computer and practically wiped my drive. I’m sure I’m not the only one in this situation – and generally, backups are not encrypted – Time Machine under Snow Leopard wasn’t, and most other backup options for home use are not either. So you have sensitive data backed up off an encrypted drive, just to “upgrade” to a different disk encryption technology. If I hadn’t upgraded, it wouldn’t have been a problem. If I was content to just leave $HOME encrypted, it wouldn’t have been a problem. But I wanted “bleeding edge”. Luckily, I have an iMac at work to off-load all of the files to – encrypted with Lion’s FileVault from the start.

I often talk about cross-site scripting (XSS), and that’s partly because I think it’s a pretty interesting type of vulnerability that many developers tend to overlook. It can be quite dangerous, but can also be quite misunderstood. For one thing, the name can be misleading: exploiting XSS does not always involve scripting, and the proliferation of web technologies has taken XSS issues beyond the browser.

One example of script-less cross-site scripting affected some high-profile MySpace users in 2007. Attackers were able to inject HTML into celebrity MySpace pages, but the service filtered out typical <script> payloads. Seemingly innocent <a> links were allowed, though, and adding a bit of CSS allowed one to create an invisible link that covered the entire page. In this case, clicking anywhere on an infected profile led to a malware download.

This attack could be one of the first prominent cases of clickjacking, though the term is usually applied to attacks that hijack clicks with malicious inline frames (iframes). Allowing <iframe> elements in user-controlled HTML opens up a range of issues more broadly known as UI redressing. For instance, an iframe that covers the entire page could render a fake login form that appears to be legitimate given the site’s address, leading to a powerful phishing attack. Frames and forms can also be used to bypass CSRF protections.

Of course, you can sometimes launch simple CSRF attacks using only images. By setting the “src” attribute of an <img> element to another page, the browser will still execute a GET request to that page when it tries to load the image. Without proper CSRF protections, such an attack may be possible without XSS to begin with. But images can also be a source of information leakage or tracking, since GET requests to a malicious server will also likely include a “Referer” header.

While most XSS payloads do capitalize on the power of JavaScript, keep in mind that a browser can load scripts from many places besides within script tags. Event attributes for other elements and certain CSS properties are just two examples of places a script could slip in. And don’t forget about the risks of browser plug-ins – Flash 0-day issues or malicious PDF files can also be sources of trouble.

Finally, an issue this week served to remind that XSS is no longer just a concern within the context of a web browser. As HTML and JavaScript become a greater part of developing apps built outside the browser, XSS may pop up on other platforms. On Monday, a security researcher with the handle superevr disclosed an XSS vulnerability in Skype for iOS. By inserting HTML into the “Full Name” of a user, one could send messages that when viewed would launch code capable of stealing the phone’s address book. And this wasn’t the first time XSS has been a problem for Skype – a vulnerability in desktop versions was found a few months ago, and XSS with shared content could lead to problems back in 2008.

Alternate labels, such as “HTML injection” or “web content injection,” have been proposed to describe cross-site scripting, but the established term is likely here to say. Still, remember that protecting against XSS does not simply mean blocking script tags, and keep in mind the power of XSS when integrating web technologies with other platforms.

SSL certificates have been in the news lately (again), and there’s a huge uproar. Is SSL still OK? Is PKI dead?

While most people understand the technical side of PKI, I’ve found that the “soft”, or what I call the “political” side, is not as well understood.

Anyone can set up the technical infrastructure to become a CA – but what makes the Root CAs found in your browser special? And as a corollary, how do you get into that select list? Each company officially has their own method of determining what CAs are in their list of Trusted Roots. Mozilla clearly outlines their requirements on their wiki, and Microsoft has a program for inclusion. In general, there are a few technical requirements, and “the audit” – usually a WebTrust audit. I’ve audited CAs (not a WebTrust audit), and what you look for is compliance with the stated policies. However, the stated policies might not be the best option for a Root CA. WebTrust just requires that

“Subscriber information was properly authenticated (for the registration activities performed by ABC-CA).
The integrity of keys and certificates it manages is established and protected throughout their life cycles.” (http://www.webtrust.org/item27804.pdf)

So, what is “protected”, what’s “properly authenticated?” That’s left up to the CA to decide. As long as the CP and CPS cover what the CA is doing, how they’re doing it, and the auditor thinks it’s “protected” or “properly authenticated”, it’ll pass the audit. Generally, once the audit is passed, it’s almost trivial to get into the operating systems and browsers – just a paperwork exercise.

In the case of Diginotar, we can assume they’ve had a recent audit (not necessarily WebTrust) because they’re in Windows and Firefox (NSS), and the auditor felt that they were “secure” enough. Something went wrong though in the subscriber identity proofing process (if it even happened). The CA is just a tool, it can enforce some policies, but not all – it has no clue that the people requesting the certificate for *.google.com are not really Google – the RA function checks that then instructs the CA to issue the certificate(s). If the RA function was bypassed (intrusion into the CA), then the CA will do as it’s told and issue the certificates.

Ideally, CAs have an off-line root CA – no network connection, generally turned off, and only able to be turned on by the folks who have control of the CA. This is the Root CA that is in the operating systems and browsers. Then, that Root can revoke its sub-CA certificates, and life moves on (except for folks who now have to get a new certificate), and most people won’t even know. When an on-line root is compromised, it’s a bigger deal for everyone involved to revoke that CA – patches are issued, instructions go out on how to delete it or distrust it, etc.

Most people blindly trust the Root CAs in their browser/operating system – have you looked at the list in your OS/browser of choice? Do you know anything about these CAs or are you trusting the folks at Mozilla, Apple, and Microsoft to tell you if they’re to be trusted?

Sometimes it can be a daunting task to keep up with computer security best practices, especially when it comes to prevention. There is an almost unlimited amount of things to take into account, not to mention significant decisions on which risks you need to address and which aren’t worth the effort. In addition, many different people have many different ideas about what’s important when it comes to baseline mitigation. This may explain why there are so many sources on the topic, often with different core focuses in mind. For example, Cisco’s Network Security Baseline is geared towards networking configuration, while the PCI-DSS regulations are focused on the technology surrounding credit /debit cards. The truth is that no one set of general rules will ever be ideal for all scenarios; in most cases, the best-fitting strategy would be a custom solution.

However, even an imperfect solution can be useful. This week I came across this list of 35 general mitigation strategies suggested by the Australian DSD (they’re sorta like the NSA). Many of these paint with a wide brush (patch all the things!), but some are directed at specific applications of technology and software. The approach is very proactive in targeting the most widely used components of modern attack vectors. On their website, DSD makes the claim that implementing the top 4 suggested strategies would have prevented 85% of the incidents they responded to in 2010. A bold claim (assisted by wide scopes):

1. Update and patch Adobe products, Microsoft products, and Java.
2. Update and patch your OS
3. Be stingy with administrator/superuser access
4. Whitelist your programs

I’m sure that taking these steps can eliminate much of the low hanging fruit, and doing all 35 would probably eliminate even more. But even if all 35 are not ideal for every scenario, it’s still all-around decent computer security advice. These strategies can be a great reference source when fleshing out a custom security policy for mitigating attacks. The rest of the list can be found here (pdf).

Ever wonder about how we came to have the technologies and programming languages used today? Yahoo’s senior JavaScript architect Douglas Crockford gave a presentation in early 2010 that traces the developments which brought us the beloved and hated language that powers client-side web behaviors. The video is nearly two hours and only the first in a series on JavaScript, but Crockford relates many interesting stories about the history of computing and notes patterns in how technology tends to develop. Check it out if you want to learn more about the background of that quirky yet powerful bit of tech we call JavaScript:

Crockford on JavaScript: The Early Years

LDAPS is used among security folks and developers pretty indiscriminately. The general gist is that the LDAP connection is encrypted between the client and server via SSL/TLS – with a lot of hand waving involved. But there is actually a slight difference in how SSL and TLS are negotiated over LDAP. TLS can be negotiated over the standard 389 port, rather than the 636 port we normally associate with SSL connections – although for the sake of convention, it’s generally done over port 636 as well.

LDAPS comes from LDAPv2 (retired in 2003) where the SSL negotiation takes place before any commands are sent from the client to the server. With a TLS connection, the connection is negotiated (non-encrypted) before any commands are sent – but the first command is StartTLS, which tells the server to renegotiate the connection, but this time, use TLS for encryption and authentication.

Despite these protocols being technically different, the general usage of the term LDAPS implies at least one of the methods.

My last post on the topic of S/MIME on iOS 5 got a lot of helpful comments from readers filled in the gaps left by Apple’s current lack of documentation on this topic. The previous article is still the best place for information on how to set up your device to use S/MIME. This post has more information on actually using S/MIME for encrypting email messages.

Enabling S/MIME

There’s a setting I missed in the previous post was pointed out by a commenter. After getting iOS 5 on the device and putting your certificates on there, you need to edit your email settings. Click Settings->Mail, Contacts, Calendars->Your email account->Account->Advanced. Scroll down to the S/MIME section and turn on S/MIME. (Note that this wasn’t required in order to read S/MIME encrypted email.) Enabling S/MIME causes two new options to appear, Sign and Encrypt. Selecting these will cause your iOS device to try and sign and/or encrypt each outgoing message. Make sure you enable the Encrypt option at this point to make your iOS device attempt to encrypt outgoing messages when possible. (more…)

NOTE: I’ve updated this post in a few places below today, 6/13/2011, based on help from commenters. Also see the follow-up article Sending and Receiving S/MIME Encrypted Email on iOS 5 (Beta).

During the 2011 Apple Worldwide Developer Conference keynote address, Scott Forstall indicated that iOS 5 would have support for S/MIME encrypted email. (Skip to 63:10 in the presentation.) This morning I successfully upgraded to the iOS 5 Beta and started being able to read my S/MIME encrypted email. Here is how I did it.

What you need:

-       Xcode 4.2 and iOS SDK 5 beta (requires iOS Developer Program account)

-       iOS 5 beta for your iOS device’s platform (requires iOS Developer Program account)

-       iTunes 10.5 beta (requires iOS Developer Program account)

-       iPhone Configuration Utility 3.3

-       Your S/MIME encryption and signature certificates exported in PKCS12 (.p12) format

(Note there is some discussion about not needing to pay for a developer program account to install iOS 5. I went the legitimate route.)

Click to read the whole walk-through of how I did it. (more…)