The Security MVPs have a private mailing list on which we gather to share expertise or our interesting findings – the following was raised by an MVP, and very much interested me, on a number of levels:
The US Postal Service has a web service (as well as a physical method) for signing up to have your mail held if you’re not going to be able to check on it for a while.
This service represents a number of lessons in privacy and security.
First, let’s look at the web site itself, at least as it was this morning (the certificate error has been fixed since then):
Okay, I don’t know about you, but that’s not what I expect to see when I go to the post office.
[For those of you using a search engine to reach this page, the text reads:
There is a problem with this website’s security certificate.
The security certificate presented by this website was not issued by a trusted certificate authority.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.
Continue to this website (not recommended).]
If you’re anything other than someone trying to research this issue and see its cause, then I suggest you follow the browser’s recommendation right now and close the webpage. This page is broken, just as if it was displaying any other error. It is not an appropriate use of Internet security technology to “Continue to this website (not recommended)”. Really.
So, let’s show you what we get when we do continue to the website:
The web page certainly looks like the rest of the USPS web site – same colours, same graphics, etc. But all that can be easily faked. What about the part that isn’t so easy to fake, the certificate that tells me that this really is a usps.gov web page? No, that’s a problem, as you can clearly see from the “Certificate Error” message.
Note that if this had been a bad page pretending to be the USPS, we would possibly have just started running evil code, designed to take over our system, steal our information, and generally mess with our lives. This is why I said earlier that you should just leave it alone, think of it as a broken page, and not deal with it any more. Unless you’re trying to debug the problem in the web server.
Let’s see what the details are of the Certificate Error (Microsoft, take note – it’s a bad thing that you have to visit the page in order to view its certificate from within IE!):
Okay, that’s pretty much what the other page said – the certificate this web site gave us was not issued by someone we trust.
Let’s view the certificate and find out more about it:
“This certificate cannot be verified up to a trusted certification authority”, huh?
[An interesting note here is that the certificate is issued to “*.usps.gov” – this is a wildcard certificate, and is generally expensive to get, and requires some understanding of certificates and how to safely manage them, because a wildcard certificate is open to abuse if it escapes. Bear that in mind as you read on.]
Why can’t we verify the certificate chain?
If you’ve only ever bought a Verisign certificate, you’ve probably got a certificate that’s signed directly by a trusted root certification authority (CA).
That means that the “Issuer” identified in the certificate is already installed in everyone’s “Trusted Roots” certificate store when your operating system was first installed. But that doesn’t always have to be the way.
Certificates can, in fact, be issued by subordinate Certificate Authorities (CAs) – and those subordinate CAs have their own certificates that are issued by other CAs, and so on up to an eventual root CA, whose certificate is installed in your clients’ systems.
So what’s the problem here? This certificate says it’s issued by “Comodo Class 3 Security Services CA” – isn’t that good enough?
Not for the browser – remember, it’s not a human, and doesn’t know how to get a hold of “Comodo Class 3 Security Services CA” to tell if it’s a valid issuer, and part of a chain up to a trusted root. It needs to be given a certificate, or told how to find it.
Let’s look at the Extensions in the certificate, and see what might be of use there:
Okay, so a CRL Distribution Point is a list of places where a Certificate Revocation List (CRL) might be published – and a CRL will tell the browser whether or not this certificate has been declared unsafe. Oh, if only there was such a Distribution Point for the issuer’s certificate!
There is, of course, or I wouldn’t be leading you there.
Let’s take a look at Microsoft’s secure certificate extensions:
No, because actually, that’s not the only way to provide an Intermediate CA’s certificate. It’s the only way that guarantees that the certificate chain can be checked no matter how the certificate can be delivered, but SSL / TLS give you an extra opportunity to fix this.
In the SSL handshake, where the server gives its certificate to the connecting client, there’s the possibility for the server to give several certificates – a chain, in fact, from its own certificate all the way up to its root, if necessary.
The Post Office can – and did – ensure that the server gives out its own certificate and the rest of its chain.
I’m not much of a web administrator – in fact, I know next to nothing about web servers. However, I have been told that in Windows, all you need to do is import the intermediate CA’s certificate, and the server will automatically give it out to the client.
The basic lesson here is that you need to test your certificates on a system that isn’t in your domain and doesn’t have any of the imported certificates that you might already have fetched from your dealings with your CA.
You need to discover if your CA put a valid AIA in your certificate when it issued it, and if it didn’t, then at least import the intermediate CA’s certificate into your server, so that it’s ready to go.
But this page made me think about more than how to fix the lack of Intermediate CA… more next time.
Apple Updater showed me two new software updates the other day – “Quicktime” and “iTunes + QuickTime”.
I use QuickTime about once every six months, when there’s a movie I just have to see, and it’s only available in QuickTime format. [The last such movie was the Thunderbirds trailer for a series that sadly never made it to production.]
And once I did upgrade my QuickTime, selecting not to “upgrade” a non-existent iTunes, it again stuck an icon on my desktop, and another into my system tray, blatantly ignoring my patiently set preferences.
Apple doesn’t get it – it’s my machine, not theirs, and I’m just not into their software. It’s not even as if they made the operating system, and get to decide how it’s “supposed” to look.
Subtitle: How often do you train your users?
On three separate occasions in the last month, I’ve been stirred from my revery at work by an inbound email that didn’t come from my colleagues.
This isn’t normal – the only emails I get at work are generally from the people with whom and for whom I work.
So each time I’ve been irritated by the email to begin with, and each time the email is the same.
It goes roughly like this (the items in angle-brackets, such as “<yourcompany>” and “<theircharity>” were real names in the original email, but it really doesn’t matter who they are, because I’m sure we all get this kind of email.):
From: <someone not @ yourcompany>
Subject: <theircharity> fund-raising program.
This is a reminder on behalf of <yourcompany> that the <theircharity> drive is going on right now.
We need you to visit the <theircharity> web site at <link> to register your donation to <theircharity> – your user name at that site is your email address, and your password is XYZZY-Plugh.
If you do not wish to donate, you should still log on to the web site at <link> so that we can remove you from our database.
I will readily admit that my first reaction was peevish discontent with my employers that they’d allowed a charity to interrupt my work – over and over again – to request money (does my company pay me enough to persuade me to donate to a charity not of my choosing?)
But after a few seconds’ thought, it hit me that this is more serious than that.
This is a phishing email – or if it’s official, it’s fundamentally indistinguishable from a phishing email. It bears all the characteristics – no branding, the “From” address is from a different domain than the link to the web site, and neither one belong to <yourcompany>.
I’m serious that if this is an official mail, it’s training our users to be vulnerable to spam and phishing, because it’s telling them that it’s okay to click on links in email without first verifying that the email comes from a recognised and approved source.
I’ve made recommendations that future mailings made by third parties to our employees should use some method to prove their link to our company – this will train our employees to expect such proof in all unsolicited non-work-related email, making it a little harder for spammers and phishers to con the people with whom I work.
What policies does your company have in place for third-party emails that are approved to be sent to your company’s entire address list?
Are you inadvertently training your users to be more vulnerable to spam? Or are you actively training them, day after day, with every email they receive from you and your authorised partners, to be suspicious of email that doesn’t carry proof of its authenticity?
So, the answer to the question raised in the subtitle is that you train your users with every email your organisation sends. Every time you talk to someone, every time you email, every time you post to your web site or blog, you get an opportunity to model appropriate and acceptable behaviour.
I bought two SD Cards today, each of which are 2GB in size (and each with a warning on the back that this means 2*10^6, not 2*2^30, bytes).
One of them is to go into my wife’s pink camera, the other is to go into my laptop, as a ReadyBoost drive (aka spare memory).
Now, a ReadyBoost drive has to pass a couple of simple speed restrictions – so, every time you try to get a drive to work as a ReadyBoost drive, Windows Vista runs a little test to make sure that the drive is fast enough to give a little extra performance.
Occasionally, someone will say “how can I disable the test, and enable ReadyBoost on a drive that isn’t so fast?” – the answer, quite frankly, is “well, duh, you can’t!” Okay, so that’s a little tactless – how about I borrow a trick from Jesper, and simply rephrase the question: “How can I make Windows add a component into my system’s data flow that deliberately slows the system down?”
When you put it that way, the answer of “well, duh, you can’t!” actually seems appropriate.
I ran the test on my two drives – actually, I waited for the hard-drive light to stop running (Vista was indexing some stuff, and the test doesn’t work so accurately when Vista is busy), and then I ran the test.
The SD Card from SanDisk (whose primary selling point, apparently, is that it has a pink label) passed the test.
The SD Card from PNY, labeled “Windows Vista Ready Upgrade”, failed the test. Over and over again. Really – I tried the test several times, and in between, I tried it on the other drive, which passed over and over again.
I played the odds, and won – one of the cards was suitable for ReadyBoost, and the other was suitable for the camera.
My suggestion to you is to ask the guy in the store – “Is this disk / card compatible with ReadyBoost?” – so that you can take it back for a refund if you find it fails the test.
Ironically, SanDisk’s web site has a section on it talking about ReadyBoost – but they only describe their USB drives. I prefer my SD Card, which sticks out of my laptop only about a twentieth of an inch, rather than my USB drives, that stick an inch and a half out, and are always ready to be snapped off.
I was inspired by my “empty DACL” issue, and what I remembered of Jesper’s “Is That Application Really Secure?” talk from last June’s Microsoft Tech-Ed conference, to test whether my security issue was caused by a NULL or empty DACL.
Jesper had said in his talk that Vista changes the behaviour of NULL and empty DACLs – that NULL DACLs were changed to mean “no access”, from Windows XP’s behaviour of “full control to everyone”; and that empty DACLS are changed to mean “no access”, from XP’s “full control to owner; no access to everyone else”.
Note, however, what ICACLS, Vista’s replacement for CACLS and XCACLS says on files that I create and assign restrictions to:
empty.txt No permissions are set. All users have full control.
null.txt No permissions are set. All users have full control.
Successfully processed 2 files; Failed processing 0 files
As you can see, ICACLS says that both an empty DACL and a NULL DACL mean “everyone, full control”. Here’s what Explorer properties says about them each:
So, ICACLS disagrees with Explorer, and they both disagree with Jesper.
Although Jesper’s the most reliable source I know, he was of course talking about Beta software that was not yet tied down, so it’s entirely possible that what was true in the Beta version of Vista last June (or was planned to be true by release time) got changed before the product could actually make it to market.
The best thing to do, then, is to test.
Sure enough, I can write to the NULL DACL file from any account, and I can’t write to the empty DACL file from any account – including the owner of the file.
So, Explorer’s right, this time around. NULL DACL means “full access to anyone, including the guest”, and an empty DACL means “no access to anyone, including the owner”.
I discussed this with Jesper, who noted that he was passing on statements from other team members about functional changes that obviously didn’t make it in to the final cut for Vista – whether for time reasons, or because the changes were ruled inappropriate (maybe backwards compatibility got in the way?).
This demonstrates that you absolutely need to not only understand the documentation for the behaviour of various DACL settings, but that you also need to test, test, and test again on all the platforms you support.
Null DACLS, then, are still a phenomenally bad idea, and you just plain shouldn’t use SetNamedSecurityInfo if you don’t know what you’re doing!
In fact, it is very rarely Vista, from the problems I’ve seen.
Sure, there are some programs that rely on features and functionality that has been removed from Vista – but by and large, that functionality was already documented by Microsoft as being ‘deprecated’ or ‘obsolete’. [Some features documented as obsolete for a decade!]
In those cases, you can argue that Microsoft should have made the decision to keep the feature in Windows because it was still being used. You won’t persuade me, because the majority of features being removed are harmful to continued reliability and security (we’ll talk about GINA and WinLogon later).
So, with this attitude, you’d think I would try to spend a lot of time making sure every piece of code I used would work in Windows Vista, right?
I’m as guilty of assuming as the next guy over.
I’ve been spending months ignoring the fact that my version control software, Component Software’s CS-RCS Pro, isn’t working on Vista.
Every time I open up Visual Studio 2005, it tries to open CS-RCS to get at the version control information for the files it’s looking at. It doesn’t help that some of the solutions I’m working on have five or more projects, and each project gets a warning that I have to acknowledge.
I’d been struggling through this, hitting “Ignore” or “Cancel” over and over, with the typical developer mentality of “I’ve got to get the job done, I can’t afford to spend time trying in vain to fix the tools”.
Until, that is, this weekend, when I decided I’d download a new version from Component Software’s web site. “Surely by now,” I rationalised, “they must have fixed it to work with Vista”.
Nope – same problems.
So I went to read the help file.
Seriously? Access denied? On a help file?
Sure enough, the directory was banning me from accessing it.
NTFS permissions were doing me in.
Why? Because there was nobody listed in the DACL. The fact that I got no access indicates that this must have been an empty DACL. In Vista, an empty DACL really means “no access” – in Windows XP, an empty DACL means “owner has full control, everyone else no access”.
So, it’s possible that this was simply an inappropriate use of a poorly-documented DACL behaviour, rather than setting a DACL explicitly to restrict usage of the CS-RCS directory.
I can’t reproduce this behaviour with the current install of CS-RCS, so I can’t say whether this was my poor setup, or CS-RCS setting the DACL restrictively.