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.

By default, the installation of VMware’s vCenter and ESXi use self-signed certificates with hardcoded passwords to protect the private keys of their SSL web services. While it gets you services that work out of the box, it is really bad form and a poor security practice.

If you install (or update to) version 5.1 of the VMware infrastructure components, you will be left with a bunch of warning windows like the ones on the left. If you’re lucky enough to have access to your own public key infrastructure, you can issue your own certificates to replace those provided by VMware so you don’t see constant warnings. However, if you undertake this effort be forewarned: VMWare’s guidance (Replacing Default vCenter 5.1 and ESXi Certificates) is incomplete, inconsistent, and at times incorrect. This article describes the problems with VMware’s document, and the final section will hopefully help save you a little of the difficulty I suffered in updating these certificates.

Incomplete

The first thing that is problematic about VMware’s guidance is that it is incomplete. It leaves out an important detail: you have to use their hardcoded password. It says so right in this knowledgebase article.

Changing the keystorePass parameter from the default testpassword is not permitted. Also, the password used to generate the rui.pfx file must be testpassword.

While it is possible to change the passwords for many of the certificates for many of the services, you are wandering into unsupported territory. A grep search reveals at least 7 .xml and .properties files that need to get updated, and again you’re working against the advice of the knowledgebase article above. Only one time, for one certificate, does their whitepaper let you know that you must use their default password of testpassword.

Inconsistent

There are six services that are used as part of vCenter/ESXi v5.1, and each one needs its own certificate. The generation process for each is very similar, and really could be simplified if VMware were to create a script to automate the generation of certificate requests. Without a script to help automate the process of generating the certificate requests, the chances of an inconsistency causing errors being made increase greatly.

There are many other ways in which the document is inconsistent with itself:

• At times, the document assumes that all the services are running on separate machines. At other times, the document assumes that some of the services are running on the same machine.
• Sometimes, the document includes links to the prerequisite steps for each part of the process. Sometimes it does not.
• Sometimes, the document includes the paths to where the files exist on Windows 2003 server and on Windows 2008 server. Sometimes, it only includes one or another.

Incorrect

One of my favorite quotes from the document is here: After the initial restart of the services, wait for five minutes. If the VMware vSphere Profile Driven Storage service stops during this time, restart it. If you have done everything correctly except you have changed one of the default passwords without updating the appropriate .properties and/or .xml files, you can start this service, and it will stop within 30 seconds. So you read this instruction, and restart it again. And carry on with the rest of the document. Unfortunately, you will never get this service, or any of the other services which rely upon it, to start and run correctly.  The certificate password problem causes the service to fail to start, and while you can continue on through the rest of the document, the services will not work.

And if you’ve got a setup where most of your vCenter installation is on one machine (as I do), and you follow their instructions, you end up generating and overwriting most of your certificates, as the document expects them all to be in the same folder with the same name.

Final Suggestions

With that, here is my advice for a successful update to all the vCenter and ESXi certificates.

1. Password: As much as it pains me, stick with their default password of testpassword. In all cases, their instructions require you to also place the raw, unencrypted private key in the same location as the file protected with the hardcoded password. So, it is no worse than having the private key in its unencrypted form. Make sure you do set appropriate operating system controls on the files to limit who can have access to those files.
2. Organization: Create a folder called c:\certs (or something) and have 6 subfolders: InventoryService, LogBrowser, SSO, UpdateManager, vCenter, WebClient. Place all your .cfg files in these folders, and generate/place your .key, .csr, .crt, and .pfx files in these folders as well. This will help you stay consistent and make sure you don’t accidentally overwrite files.
3. Make backups: Make sure you never overwrite any of the files when you are putting new certificates in place. Always copy or rename the original files so that you can get things working again if one of the inconsistencies of the document causes you a problem.
4. Check Services: Anytime you’ve finished updating certificate files for one of the services, make sure the service will start, and run properly. If you start a service successfully, check on it again a minute later. If it has stopped, don’t continue blindly – check the log files for errors. Unfortunately the Windows Event Viewer will typically only tell you about service-specific error 1 (0×1) or 2 (0×2). You’ll need to check your logs in folders such as %ALLUSERSPROFILE%\Application Data\VMware\…\logs.

I hope these tidbits can help save someone else some time. If you would be interested in a script that could help automate much of this process, let us know in the comments!

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.

Yesterday, this story on Wired was making the rounds: How a Google Headhunter’s E-mail Unraveled a Massive Net Security Hole. Sure, the title is probably hyperbole, but it is an interesting story. At a high level, mathematician Zach Harris noticed that emails from Google – and from several other prominent domains including eBay, PayPal, Yahoo, Amazon, etc. – could be spoofed.

Anyone who has ever run telnet to port 25 and sent an email from santaclaus@northpole.net or billgates@microsoft.com knows that email has always been pretty easy to spoof. Given the rise in unsolicited emails also known as spam, something had to be done. In 2006, a working group was founded to try and create a standard that would make email harder to spoof. It is called  DomainKeys Identified Mail or DKIM. The way DKIM works is that the sending email server applies a digital signature to the mail message headers (completely transparent to the user). The public key which can be used to verify the signature appears in the sending email server’s DNS record.

Since it uses some fancy technology like a digital signature and relies on DNS – a core capability of the internet – email with a valid DKIM signature can generally be trusted that it is legitimately from the domain listed in the From field… Well, that is if you’re doing DKIM correctly.

Mr. Harris found that the DKIM signatures for a number of popular domains used such weak cryptography that it was very easily cracked. While the DKIM standard calls for 1024 bit keys, he found popular domains with 768 bit, 512 bit, and even 384 bit keys. As he points out in the article, he was able to crack the 384 bit keys on his laptop, and for $75 he cracked some 512 bit keys by outsourcing the computing power to Amazon Web Services.

The best quote in the entire article, and the reason I bring this story to your attention is the following:

“People who use cryptographic tools need to realize that local configurations need to be maintained just like software updates need to be maintained,” he says. “In 1998 it was an academic breakthrough of great concerted effort to crack a 512 bit key. Today little old me can do it by myself in 72 hours on AWS. The field of cryptography keeps developing and breaking new ground just like everything else, and you can’t just install a private key, or select a hash algorithm, and expect it to be good forever.”

Wise words, indeed. If connected to any network, you must consider your operating system, your software, and your cryptographic algorithms and keys all as perishable items. They need to be examined for mold and rot periodically, and replaced when necessary. You can no longer afford to “set and forget” anything and consider it dependable.

It’s a little embarrassing to admit, but it seems that the mistakes of one person globally syndicated columnist have led to a rapid increase in the acceptance and use of two-factor authentication technologies for authentication. Within the last week, I have set up both my Dropbox account and this very blog with two-factor authentication.

Mat Honan’s sordid tale did a lot to raise awareness of how passwords are imperfect as an authentication mechanism, as have the many password breaches that have occurred over the years. Most interesting, though, is how Google created and freely released Google Authenticator as an open source application and how quickly organizations have begun to embrace it. While I’ve traditionally been a PKI guy (I know, that’s SO 2003), when the time came for us to secure our VPN with a second factor we went with Google Authenticator rather than a PKI token. Why? Cost. Hard to argue with free.

So now, I have Google Authenticator token set up with: my personal Google account, my corporate Google Apps account, my corporate VPN, my blog, and my Dropbox. What do you think the next systems to add Google Authenticator support will be? Let us know in the comments.

During security assessments, I always make sure they’re performing security testing as part of their development process.

This is why: “Apple security blunder exposes Lion login passwords in clear text”

No need to go into details as to what happened here; it’s well-researched in the linked article. However, this is exactly the scenario that development security testing is meant to avoid. A seemingly innocent patch disables or circumvents an important security feature. The results are predictable.

It could be worse, though. Here’s the worst case: the problem isn’t detected. Because the security was included in the original version, and because nobody checked, it is assumed that the security is in place, and successive updates are made, with the security feature in question not working, but everyone assuming it does. And successive patches are built upon the circumvented security. By the time the bug is discovered, fixing it is a gargantuan task.

So, it’s not that bad. It’s still a major breach, though. So if you ever wonder if that testing is really necessary during development, you can point to this incident and confidently say “Yes.”

tl;dr Abstract

To improve performance, particularly for mobile users, many websites have started caching app logic on client devices via HTML5 local storage. Unfortunately, this can make common injection vulnerabilities even more dangerous, as malicious code can invisibly persist in the cache. Real-world examples of this problem have now been discovered in third-party “widgets” embedded across many websites, creating security risks for the companies using such services – even if their sites are otherwise protected against attacks. Striking a balance between security and performance can be difficult, but certain precautions may help prevent an attacker from exploiting local storage caches.

Background

Throughout the history of web development, people have found ways to use and abuse various technologies beyond their intended purposes. Before CSS gained widespread support, many developers created complex layouts with HTML tables. Now that browsers provide far more presentation-layer tools, one can recreate complex images using only CSS. Such tricks can at times be very helpful in overcoming the limits of a browser-based environment, but they can also inadvertently create security issues.

(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.

Security researcher Mario Heiderich (also creator of the HTML5 Security Cheatsheet and lead developer for PHPIDS) has been posting some interesting cross-site scripting challenges lately that highlight aspects of security on the client side. The most recent, called XSSMe², involved a page with a reflected XSS vulnerability that allowed one to insert arbitrary HTML – no filters applied by the server. The goal? Retrieve a particular bit of data, originally stored in document.cookie, without any user interaction. I say “originally,” because the page included JavaScript which attempted to lock down access to the data by removing it from document.cookie and hiding it unless retrieved by a user click. The code used evolved as bypasses were found, with several tricks employed along the way.

One trick was to hide the variable in a closure. In JavaScript, every function has its own local scope. If you define a variable within a function block, that variable is distinct from one defined in the global scope. In a way, the variable is hidden from code executed in the global scope, though the function can provide a gatekeeper method to access it. Consider this block of code:

document.cookie = "secret";

var Safe = function() {
    var cookie = document.cookie;
    this.get = function(magicWord) {
        if (magicWord === "please") {
            return cookie;
        }
        return null;
    }
}
window.Safe = new Safe();

document.cookie = "";

alert(document.cookie);
alert(Safe.get(""));
alert(Safe.get("please"));

The first alert returns nothing – document.cookie has been set to an empty string. The second alert only returns null, given the if statement in the definition of Safe.get. But with the third alert, the statement return cookie gets executed – and that statement is in the local scope of the function, so it returns the cookie variable defined in that scope, which is “secret”. This is the concept of a closure – the local variable of the function lives on as it was defined in that context.

Initially, this may seem to be a good defense against cross-site scripting, since the power of XSS comes from all a page’s scripts executing in the same scope. But as entries in the challenge demonstrated, a script has many resources for attacking itself. For instance, the challenge included code that checked whether a function requesting the secret variable was a mouse click event initiated by the user. That last bit came from checking the isTrusted property on the event, which should tell you whether the click came from a script or from the user.

But in JavaScript, new objects are created by cloning a model object called a prototype. If you change a particular prototype, any new variety of that object will inherit the changes you made. In this case, changing the isTrusted property of a mouse event’s prototype to always be true meant any spoofed clicks generated automatically by a script would fool the protective code and retrieve the secret value.

With each new bypass, Mario updated the code with new protections to block them. Eventually, he created a Firefox-specific version that essentially rewrote the entire page to get rid of the original Document Object Model and all its loopholes. If you’re interested in reading more about other bypass techniques and the challenge’s implications for client-side filtering, researcher Krzysztof Kotowicz has an excellent write-up that covers more details. But the challenge is also worth studying as a way of understanding more about web scripting and XSS. I certainly learned more about closures and event spoofing by tackling the puzzle, and it helps illustrate the difficulties of trying to protect against code running in the same origin and same scope. We may be moving towards DOM features that provide enough security to block even client-side attacks, but for right now, any untrusted script has myriad ways of overcoming client-side protections.

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.