One of the lesser-known features of Windows 8 is the ability to sync a number of your settings for your system with your Microsoft account. This means you can sync your apps, your people (including Facebook, Twitter, Outlook, and LinkedIn contacts), and your photos so that they all appear no matter which Windows 8 system you log in to.

In addition to those settings, you can also sync your themes, favorites, history, and passwords to your Microsoft account. This means that your browser will look and behave the same as long as you are synchronized with the same Microsoft account.

These settings presented some concerns to me, because if my Microsoft account got hacked, some potentially sensitive information (passwords, bookmarks, and history) could end up in the wrong hands.

Fortunately, Microsoft has begun to roll out a long-awaited feature which improves the security of the Microsoft account: two factor authentication. I was excited to set this up for the account I use to synchronize my Windows 8 PC. Setting it up is easy. Go to https://account.live.com/ and after logging in, choose “Security Info” on the left side.

Click “Set up two-step verification” and begin the process. In my case, since I had already linked a phone number to my account (which previously saved my account), it offered me the possibility of calling me or texting me with a code in order to continue. Once I completed that process, my account was now configured to require a second factor of authentication whenever I connect from an unrecognized device.

To simplify things you can also use an authenticator app, either the Microsoft Authenticator for Windows Phone, or the Google Authenticator for iOS or Android. On the security settings page, click “Set Up” under the Authenticator App section of the page. You will receive a page like this:

Scan the barcode, and you will be able to generate login codes using the app. (Pro tip: if you have an authenticator account configured with same email address that is associated with your Microsoft account, you might want to rename the existing account in your authenticator app before scanning. Otherwise your account’s code might be overwritten.)

Now that my Microsoft Account is well and truly secure, now it’s time to configure the synchronization of my Windows 8 account and my Microsoft account. Hit the Windows button, and search for “Sync” in your settings. Choose “Sync Your Settings”.

Then, go ahead and turn on all the sync settings you want! Feel confident that your account settings are configured with a well-protected account.

Note: I am part of the Windows Champions program. As part of this program, I receive equipment and software from Microsoft to assist me in evaluating products and developing content.

The tl;dr summary for those with short attention spans - Don’t open the attachment, be quick to delete anything you’re not sure about, and if you want to help in the fight against phishing, report it using the guidelines I’ve outlined below.

I received a pretty awesome phishing email today. It included a significant attachment that I’m looking forward to analyzing at a later date.

Since it will take me a while before I’ve got the time to run the analysis, I decided I wanted to forward it around to the appropriate organizations to ensure that they take some time and analyze it and make sure other individuals can be protected from it.

It turns out that there are more places to forward this than I expected. So here’s what I’ve found. You can forward the email to these addresses:

• US-CERT (Computer Emergency Readiness Team) at phishing-report@us-cert.gov (link)
• The Federal Trade Commission at spam@uce.gov (link)
• The Anti-Phishing Working group at reportphishing@apwg.org (link)
• If IRS-related, the IRS at phishing@irs.gov (link)
• If appropriate, some state governments have cyber-crime divisions as well, such as here in Virginia: cybercrime@oag.state.va.us
• You can also often forward to abuse@[domain] where applicable.

You can submit phishing websites to:

• Google
• The FBI’s Internet Crime Complaint Center (IC3)
• US-CERT (Computer Emergency Readiness Team) by sending email to phishing-report@us-cert.gov
• The Anti-Phishing Working group (APWG)

Most anti-malware providers are part of the APWG, so definitely make sure you submit there to increase the chances of later defense against the same attack.

Now what happens when you forward the email and you get an error?

Well, some (good) email providers scan email upon sending. In that case, you might not be able to actually email the example for further analysis. In this case you can typically send an encrypted zip file.

To do this, find a way to get the raw message source for the email. (Some help here and here.) Then, save the source as a plain text file using a local text editor. Finally, use a method to zip that text file with password-based encryption (use Google to find steps that will work best for you).

When you send the email, attach the encrypted zip file and explain you attached an encrypted zip file of the suspected phishing email, and include the password you used when zipping it. The password is just there to get past the email server, you don’t want the recipient to not be able to view the message!

Now, pat yourself on the back for helping take a bite out of crime.

We are working with a security policy that treats two passwords of equivalent strength:

• 8 character password with two character sets represented (pick two of upper/lower/number/symbol)
• 6 character password with three character sets represented (pick three of upper/lower/number/symbol)

The question arises, how equivalent (or not) are they? Well, it’s time to do some math.

Total Possible Passwords

One way to measure password strength is in the total number of passwords that one might be able to generate that meet that criteria. More would be better. There are 26 uppercase, 26 lowercase, 10 digit, and 33 ASCII-printable symbols available on the average keyboard (totaling 95 options). If we simply asked how many possible 6 character passwords are there, you can multiply 95 for each character that your password is long (i.e. 95 to the 6th power):

Total possible passwords from 95 printable character choices
six characters? 95 x 95 x 95 x 95 x 95 x 95 = 735 billion +
eight characters? 95 x 95 x 95 x 95 x 95 x 95 x 95 x 95 = 6.6 quadrillion +

You can see that these aren’t equal – the longer password is clearly stronger. However, there is no accounting for the different character sets that are required – maybe that will make a difference? Read on for more of the math behind passwords. (more…)

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