Jesper Johansson's Blog

Munir Kotadia, an IT Journalist in Australia, has finally managed to figure out how to blame Microsoft for the fake anti-malware epidemic. Apparently, the reason is that "Microsoft could save the world from fake security applications by introducing a whitelist for apps from legitimate security firms" and, presumably, has neglected to do so out of sheer malice.

I'm clearly not a thinker at the same level as Munir; maybe that is why I don't fully get this white list he proposes. Does he want one only of security software? How would you identify security software? I can see only two ways. The first is to detect software that behaves like security software. If you scan files for viruses, hook certain APIs, quarantine things occassionally, and throw frequent incomprehensible warnings, you must be security software. The problem is, the fake ones only do the latter of those four. If you use heuristic detection of security software it would be absolutely trivial for the fake packages to not trip the warnings. They just have to avoid behaving like security software. Of course, if they actually DID behave like security software, we would not have this problem, would we?

 The second approach I can think of is to have all security software to identify themselves as such, both the fake and the real. They could set some bit in the application manifest, the file which describes the application. I propose that it should look like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32"
                    name="RBU.FakeAntiMalware.MyCurrentVersion"
                    version="6.0.0.0"
                    processorArchitecture="x86"
                    publicKeyToken="0000000000000000"
                    securitySoftware="True"
  />
</assembly>

Note the flag in the manifest above that identifies this package as security software. Now Microsoft can just compare the name of the package against a list of known good software and if it does not match, block it. This extremely simple mechanism works just as well as the "evil bit": http://www.ietf.org/rfc/rfc3514.txt. In fact, if we simply change the manifest like this, we can avoid the whole white list altogether:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32"
                    name="RBU.FakeAntiMalware.MyCurrentVersion"
                    version="6.0.0.0"
                    processorArchitecture="x86"
                    publicKeyToken="0000000000000000"
                    malicious="True"
  />
</assembly>

There you have it! Microsoft should make it part of the logo guidelines to require all malicious software to identify itself as malicious. Problem solved! You may go back to surfing the intarwebs now.

The sharp-eyed security experts in the crowd may have spotted a minor flaw in this scheme, however. What if the malicious software refuses to identify itself? Curses to them! Maybe we need something better. Perhaps Munir's whitelist is to be a whitelist of all software? That would be simpler to be sure. In fact, using Software Restriction Policies (SRP), which has been built into Windows for years, we can restrict which software can run. Now all we need is our whitelist. Of course, as Munir points out, it is Microsoft's responsibility to produce that whitelist.

Producing the whitelist would be conceptually simple. Microsoft would simply have to create a division that ingested all third party software, tested it, and validated it as non-malicious. DOMUS (The Department of Made Up Statistics) estimate the number of third-party applications for Windows at somewhere between 5 and 10 million, including shareware, freeware, open source, commercial applications, in-house developed applications, line of business applications, the kiosk applications that drive your ATM, your gas pump, your car, and probably a space craft or two. In order to avoid becoming an impediment deployment, Microsoft would have to test all such software for malice, with an SLA of 24-48 hours, yet guarantee that software does not turn malicious after several weeks or months. It would also need to ensure that any updates do not introduce malicious functionality. In other words, to meet these requirements, Microsoft would need to do just two things: (a) develop a method of time travel, and (b) hire and train all of China to analyze software for malicicous action. I'm sure the Trustworthy Computing division is working on both problems.

I am not arguing that reputation scoring does not have some promise, which is what Symantec's Rob Pregnall was actually talking about, and which Munir turned into an indictment of Microsoft. However, reputation systems are not only fallible and can be relatively easily manipulated. Without consumers actually understanding what the reputation score means, and learning how to value it over the naked dancing pigs, it will never help. Again, it comes down to how we educate consumers on how to be safe online and why, instead of scaring them into buying more anti-malware software. I may be mistaken, but I was under the impression that the reason Freedom of the Press is a cherished human right is because the Press is there to educate the public. Why is the press, along with government and the IT Industry, not doing more to educate the public on how to tell real from fake?

One of the last areas where more tool support is needed is in monitoring the various attributes in Active Directory (AD). Recently I got curious about the delegation flags, and, more to the point, how to tell which accounts have been trusted for delegation. This could be of great import if, for instance, you have to produce reports of privileged accounts.

KB 305144 gives a certain amount of detail about how delegation rights are presented in Active Directory. However, it is unclear from that article how to discover accounts trusted for full delegation, as opposed to those trusted only for constrained delegation; and the various flags with "DELEGATION" in them are not as clearly explained as I would like. Nor was I able to glean any insight into this from the various security guides and recommendations for Windows. I asked around, and got great answers from Ken Schaefer. By spinning up a Windows Server 2003 Domain Controller in Amazon EC2 and running a few tests, I was able to verify that Ken was indeed correct.

Delegation rights are represented in the userAccountControl flag on the account object in AD, whether a user or a computer account. There are a couple of different flags involved, however. Here are the values set in various circumstances:

For a computer account, the default userAccountControl flag value is 0x1020, which is equivalent to the WORKSTATION_TRUST_ACCOUNT & PASSWD_NOTREQD values being set. A user account is set to 0x200 (NORMAL_ACCOUNT) by default.

When you enable full delegation, 0x80000, or TRUSTED_FOR_DELEGATION, gets ANDed to the userAccountControl flag. This is irrespective of domain functional level. In other words, in a Windows 2000 compatible domain, checking the "Trusted for delegation" box; and, in higher functional levels, checking "Trust this computer for delegation to any service" using the "Kerberos Only" setting, both result in the same flag being set. The same flag is set on user accounts when you check the "Account is trusted for delegation" checkbox.

In a Windows Server 2003 or higher functional level domain you gain the ability to trust an account for delegation only to specific services: constrained delegation. If you configure constrained delegation using Kerberos only, the userAccountControl value is not changed at all. The account simply gets a list of services it can delegate to in the msDS-AllowedToDelegateTo flag.

However, if you configure constrained delegation using any protocol, the userAccountControl value gets ANDed with 0x1000000, or TRUSTED_TO_AUTH_FOR_DELEGATION.

There is also a flag in userAccountControl called NOT_DELEGATED. This flag is set when you check the box "Account is sensitive and cannot be delegated."

This tie-back to the graphical user interface, as well as explanation of the various flags, should help an auditor construct a query that lists all accounts trusted for delegation in an arbitrary domain. Obviously, any account with TRUSTED_FOR_DELEGATION set should be considered extremely sensitive; as sensitive as a Domain Controller or Enterprise Admin account. An account with TRUSTED_TO_AUTH_FOR_DELEGATION set is probably less sensitive, depending on which specific services it can connect to, but still quite sensitive as it can use other protocols than Kerberos. Finally, and least sensitive of those accounts trusted for some form of delegation, are those that are only permitted to delegate to specific services using Kerberos.

It's official. I just received an e-mail from Thawte notifying me that, as of November 16, 2009, the most innovative and useful idea in PKI since its inception, the Web of Trust, will die.

Thawte was founded 14 years ago by Mark Shuttleworth. The primary purpose was to get around the then-current U.S. export restrictions on cryptography. Shuttleworth also had an idea that drew from PGP: rather than force everyone who wanted an e-mail certificate to get verified by some central entity - and pay for the privilege - why not have them verified by a distributed verification system, similar to the key signing system used by PGP, but more controlled. This was the Web of Trust. Anyone can get a free e-mail certificate, but to get your name in it instead of the default "Thawte FreeMail User" you had to get "notarized" by at least 2 people (or 1, if you managed to meet Shuttleworth himself or a few select others). The Web of Trust was a point-based system, and if you received 100 points (requiring at least three notary signatures) you became a notary yourself. The really cool idea was that it created a manageable system of trust based not so much on the six degrees of separation as on the fact that most of us are inherently trustworthy beings.

In 1999 Shuttleworth sold Thawte to Verisign for enough money for him to take a joyride into space, found the Ubuntu project, and to live without worries about money for the rest of his own life and that of several of his descendants. Verisign, of course, is in the business of printing money, only in the form of digital certificates, and certainly not in giving anything away for free. Not that there is anything inherently wrong with that, but it iscertainly at odds with Thawte's free service, so it was really just a matter of time before the latter was disbanded. WIth it goes the Web of Trust.

Finally, on November 16, 2009, the Web of Trust will be removed as a free competitor to Verisign's paid service that does the same thing. It will be a sad day indeed.

At least for the short to medium term. That is the, quite obvious, conclusion drawn in a Newsweek article entitled "Building a Better Password."  The article goes inside the CyLab at Carnegie-Mellon University to understand how passwords may one day be replaced. It is interesting reading all around.

The article is not without some "really?" moments though, such as this quote:

The idea of passphrases isn't new. But no one has ever told you about it, because over the years, complexity—mandating a mix of letters, numbers, and punctuation that AT&T researcher William Cheswick derides as "eye-of-newt, witches'-brew password fascism"—somehow became the sole determinant of password strength.

Actually, I do believe someone did tell you about it. Five years ago now, in fact.

Today I finally got wind of my first piece of true standard user malware. MS Antispyware 2008 has turned standard user. The version in question installs the binaries in c:\documents and settings\all users\application data\<something>, and makes itself resident by infecting HKCU\...\Run. Curiously, the legitimate anti-malware program (one of the top 3) failed to detect the infector.

Obviously, this version is much easier to remove than the ones that require admin privileges. However, MS Antispyware is not about being hard to remove. It just needs to run until the user pays for the privilege, and more than likely, even as a standard user, many people will fall for it.

On a somewhat unrelated note, just as I was wondering who would fall for these types of scams, I met a real person that did; a not-particularly-well-off disabled retiree who was scammed out of $5000 by an organized crime ring that claims to have won you a lottery, as long as you just pay them for the ticket first. That particular scam was run partially by phone and partially online. And, the scumbags apparently didn't think they had scammed her out of enough money so they kept calling her even after she sent them the money. I advised her to call Rob McKenna's office (Attorney General of Washington State). Mr. McKenna's office stated that they felt horrible for her. Apparently that was about all the comfort they could give. I must say that level of action was not particularly impressive, and does not really live up to Mr. McKenna's campaign promises of cracking down on scammers.

In an absolutely astonishing move Microsoft's Polish subsidiary decided to do some photoshopping on its Business Productivity Infrastructure page to tailor it to the Polish market. Here you can see the U.S. original. In one of the least sensitive moves this year, the Polish subsidiary decided that black people in Poland do not need to be empowered, so here you can see what its version of that page looked like for a few hours today. As you can see from the current version on the Polish site, someone with a bit more human sensitivity than a teaspoon, and an I.Q. that is at least room temperature (celsius), decided to fix it. This evening Microsoft empowers everyone equally - even in Poland.

Last week, an expert from Verizon, nee Cybertrust, posted a note about the Active Template Library (ATL) security vulnerability over on the Verizon Business Security Blog. For home users, the phone company now advises you to use a different browser, ostensibly because IE and ActiveX are inherently insecure. I felt that quite missed the point that (a) browsers are software, and (b) all software has vulnerabilities, and (c) extension technologies in browsers add functionality, which (d) is implemented in the form of software, and therefore (e) introduce additional vulnerabilities. Just because Internet Explorer's extension technology is called ActiveX does not mean it inherently has any more, or less, vulnerabilities than the extension technologies in other browsers. ActiveX received a, deservedly, horrible reputation when it first came out about ten years ago. Since then Microsoft has actually put a lot of effort into securing the user's browsing experience, but for some reason, people keep dragging up old vulnerabilities from many years ago as proof that Microsoft does not care about security. Doing so is unfair and denigrates what is probably most comprehensive software security program in the industry.

So, I decided to try to make that claim in the comments. That generated a response from "Nathan Anderson," who did not bother really reading what I wrote, used a flawed interpretation of data to "prove" that Firefox and Chrome are far more secure than IE, ignored Low Rights IE, and concluded by, in essence, calling me an idiot.

My comment also generated a response from Dave Kennedy, who appears to have been the original poster, and who thinks I went too far.

At this point, I'd probably do better to ignore the discussion, but Mr Kennedy posited a very interesting question, and I thought I'd like to explore it a little. Here it is:
"How many millions of dollars have been lost and thousands of individuals have become the victims of identity fraud that can be laid squarely at the feet of criminal exploitation of vulnerable ActiveX controls?"

I don't know. How many? And how does it compare with the number of millions of dollars lost because users click on things they shouldn't, while running as admins? How does it compare with the number of millions of dollars lost due to vulnerable versions of Flash and Acrobat; which are vulnerable on all browsers? All of those would be fantastic statistics to have. If anyone has them, I'd love to see them.

To the Nathans of the world: I never said Firefox and Chrome are less secure than IE. All I pointed out was that they do not benefit from a sandbox the way IE does on Vista and Win7. They could. Easily. Stripping privileges out of a token and setting an integrity level is quite simple. The difficult part is really just to build an escalation method to be able to perform tasks outside the sandbox.  It is just that their respective manufacturers have chosen not to implement this functionality. I really wish they had. It would greatly improve the difficulty of exploiting either browser.

In addition, Firefox, etc, may not have ActiveX, but they have other extension mechanisms, and a vulnerable extension is a vulnerable extension, whether it is ActiveX or not. It is correct that Chrome has fewer vulnerabilities than either Firefox or IE, but a reasonable argument can be made that it is because of how long it has been out and the amount of attention from security researchers it has received so far. Chrome is not yet a year old. In that time, Chrome 1.x and 2.x have racked up 9 advisories (12 vulnerabilities), according to Secunia. I included both versions because of how fast they were released. It provides a more accurate measure of the impact on the end user. Chrome 3.x is still considered a preview release as far as I can tell, so I excluded it. Firefox 3 (the only supported Firefox version for most of the one-year timeframe) had 9 advisories in 2009 so far, and an additional 5 in late 2008. Internet Explorer 7 in that timeframe has 6. 

Based on these figures, I would submit there is no statistically significant difference between the three browsers. I am not trying to minimize the ATL vulnerability, which was sloppy in the extreme, and I am not trying to denigrate either Firefox or Chrome, as I use and enjoy both, although mostly Firefox, which I used to write this post. I am simply saying that all software has vulnerabilities, and that the attackers will be opportunistic enough to exploit any or all of them if it is necessary to meet their needs.

Vulnerability counting misses the point entirely though. All the bad guys need is one unpatched vulnerability. Furthermore, that vulnerability can reside in the browser, or in anything else running in the browser.The common add-ins, such as Flash and Acrobat, have vulnerabilities regardless of which browser they are running in. Even if the user has a fully patched and non-vulnerable browser, all the attacker needs is one unpatched add-in. Adding a new browser requires adding new add-ins, so now you have two copies of Flash to maintain, two copies of Acrobat to maintain, and another browser.Simply adding more software to maintain does not make people more secure. Most users would probably be far better off maintaining only one browser and spending the additional effort on learning how to browse more securely.

Finally, whether a computer is fully patched or not; whether a browser or its extensions are full of holes or not; the most vulnerable part of any system is almost always the user. Humans are still at v. 1.0 and there have not been a single security patch issued for them yet. There has been no Trustworthy Computing Initiative to stamp out security vulnerabilities in people. Therefore, the easiest way to hack anything is almost always to ask a legitimate user to do it for you. Simply present the user with something he values more than an intangible and incomprehensible security benefit, and your job is done. Many of the attacks today do not even use software vulnerabilities. It is more reliable and less expensive to exploit the user directly.

This morning I talked to my dad. After a few minutes of polite small talk, I heard the 10 little words I have come to dread: “I had some problems with my computer the other day.” The video card on his laptop had died. The screen was just black. He has a Dell Vostro, so he called Dell Technical Support. They sent a contractor technician out; with a motherboard. The technician, having no real qualifications other than the need for a job; and no real training other than how to fill out the repair paperwork, installed the motherboard. Three days later he returned with the video card the computer actually needed, and the computer started again.

At this point, the following conversation ensued:

Dad: When I started the computer I got an error message

Me: What did the message say?

Dad: How should I know? It was written for “people” like you. I didn’t understand a word of it. It just said something about some software not working and it should be reinstalled

Me: Which software?

Dad: I don’t know. I told you, I didn’t understand it.

Me: So what did you do?

Dad: I figured it must have been Windows. Windows never works properly, so that made sense. I thought if I reinstalled Windows it would all work.

Me: And…?

Dad: Now Office doesn’t work.

Me: When you say “reinstalled Windows” did you do an in-place upgrade?

Dad: Can you restate that again in Human?

Me: Did you upgrade Windows?

Dad: No, the upgrade option was grayed out.

At this point, if, like me, you are a cubicle-dwelling, bespectacled nerd with the social skills of a turnip you know exactly what happened. He created a new side-by-side installation of Windows. Sure enough, in the C:\Windows.Old folder were his old Users folder, his old Windows folder, his Program Files folder, and all the other contents of his hard drive. I pointed this out to him to explain what happened.

This is when Dad drew the completely logical assumption: “OK, so if I just copy the Microsoft Office folder from there to C:\Program Files it will work?”

No. It won’t. It would if software were designed for the humans that actually use it. Unfortunately, it is not. It is designed by and for the same people: cubicle-dwelling bespectacled nerds with the social skills of turnips; people who have never spent any significant time interacting with humans, and who have never met any of the real users who will use the products they design. If we had actually met and interacted at length with real people at any point over the past 15 years, we probably would have realized already that designing a “program” that consists of 3,829 files, spread over 60 folders, is not how people expect it to work. That, by the way, is not a random figure. It is the number of files and folders in C:\Program Files\Microsoft Office on my laptop. Lest you were now to say that someone else knows better, iTunes vomits 2,718 files over 1064 folders, in two different hierarchies. Why don’t you try to move either to your cavernous external hard drive to save space and see how well that works?

Is it that my dad was being illogical? No. Moving the Office folder would indeed be incredibly logical; totally rational in fact. If you bought a new file cabinet, you could easily take the files out of the old file cabinet, put them in the new one, and they actually still remain readable! You could even take one of your old pens, scribble a note on them in the process, and a year later you can read the note! Amazing that ain’t it? If file cabinets were computers you certainly could try to remove the file from the computer. It would prompt you with a dialog asking if you really wanted to do that, once per character on the page. Once you accepted the prompts, you could insert the file into the new cabinet. When you tried to read it, however, you would find that the ink fell onto the floor between the two file cabinets. The magic fixative that keeps the ink on the paper works only as long as the paper stays in the old file cabinet.

We have a mental model consisting of physical, tangible things. There is a school of thought in Cognitive Science that believes the basic wiring of the human brain was forged in caves. Our brains were designed to address the biggest concerns of the day: evading the saber-toothed cat, spearing a wooly mammoth for dinner, and, for at least half the population, clubbing a suitable mate to drag home to the cave. (Presumably, the other half of the population lived in fear of getting clubbed and dragged away). Our brains were not exactly wired to understand the convoluted product management decisions that resulted in almost four thousand files and thousands of directories. And they certainly were not wired to understand that all those files and directories are utterly useless without the settings, which are stored elsewhere – in a place that does not really exist – and are joined to the file system manifestation of the software only in the very loosest sense of the word.

 Every time I boot Windows these days – and especially Windows 7 – I feel like the software is designed to be some kind of punishment. It’s meant to exact revenge on us for the designers being bullied in elementary school. So much of the software we software engineers design feels vindictive, counter-intuitive, and illogical. When the users finally figure out basic interaction styles, we change it all. When people finally learn that you can click on things on the quick launch menu to start them, we get the bastardized task bar in Windows 7 that only activates existing copies. When we finally figure out how to make find things on the start menu it becomes polluted with several hundred useless icons like iSCSI Initiator. Rather than features to make it easy to use, we bloat software up with new features because that’s what the computer journalists look for. I keep hoping for a release of a major piece of software that just works; that is elegant, that shows thoughtfulness in how the software was plumbed together, and that is designed from the ground up not to add new features but to be intuitive to the poor people who have to use it. Unfortunately, I never will. “Intuitive”, “elegant”, and “just works” are words you never see in computer journals, except maybe in Macworld. 

Sometimes I feel like the only piece of software ever designed to work EXACTLY the way its intended users expected it to work is Solitaire. Predictably, my sources tell me that Microsoft laid off the guy who wrote it in May.

In May, in one of the more inexplicable moves this year, Microsoft laid off my good friend Steve Riley, four days before he was to deliver half a dozen presentations at TechEd. Fortunately, it did not take Steve long to find a new gig. This Monday, he starts as the latest Evangelist & Strategist for Amazon Web Services!

I'm very very happy for Steve, and very excited about what he can do in that role. Web Services are where the future is, and Steve is extremely well suited to the role. Please join me in wishing him good luck!

For the past few days I've been following the Microsoft Video Control Vulnerability with interest. Basically, it's another vulnerable ActiveX control that needs killbitted. Last night, Microsoft posted a work-around which involves using a Group Policy ADM template (ADM is the template format that was deprecated in Vista and Windows Server 2008). Unfortunately, the template tattoos the registry, which is not really recommended.

I contemplated for a while writing a work-around for this issue, but then remembered that I actually did; almost three years ago. The workaround I wrote then, for another ActiveX vulnerability will not tattoo the registry, and will be much simpler to deploy with an Enterprise Management System. Just take the CLSIDs from the advisory (there are 45 of them) and run my script that many times with the -k switch. If you wish to revert the change, run the same script with the -r switch.

The Consumer Federation of America just published a report on identity theft services entitled "Are Identity Theft Services Worth The Cost?" The conclusion is that many are not, and that regulation is needed in that industry. It is a very interesting read.

Recently I had a very interesting incident. I wrote an article some time in 2008 and the publisher paid me a little bit of money for it. That means the publisher must send a report to the Internal Revenue Service (IRS - the U.S. tax department) reporting that they paid me, as well as send me a form called a 1099 form that I can use to report this money on my tax return.

A few days ago the comptroller for the publisher sent me an e-mail asking for my social security number (my national ID number for any non-Americans that are unfamiliar with the term). As is my custom, I responded that I really do not care to e-mail my social security number, but if he gives me a phone number I will gladly call him and let him know. This he did. I called, and within 15 minutes of the call I received a form California DE 542 in the mail. The DE 542 is required by the state of California when money is paid to a contractor, or a contract is entered into to pay money to a contractor. Its purpose is to permit the state to track payments to parents who do not pay their child support. Not only do I not need this form as I am not a resident of California; it also contains, you guessed it:

my social security number.

At this point I started wondering what part of "I do not wish to have my social security number transmitted by clear-text e-mail" was unclear. I sent a message to the sender that informed him that this could quite possibly be considered a data breach and require notification under Washington State SSB 6043, which requires formal breach notification. As of today, I am still awaiting a response. Any response.

Just because I felt like griping to someone, I forwarded the e-mail to my favorite accountant. Her response was "yeah, I know lots of CPA firms who e-mail around unencrypted 1040s." (A "1040" is the U.S. federal tax return form). I was absolutely floored. Last week credit card processor Heartland reported that they had experienced what may very well be the largest data breach in world history. Many banks are replacing every single one of their credit cards because of it. In fact, I took a call from a distressed bank manager just this morning asking whether it would be prudent to do so (the answer was "yes"). Yet, does that not pale in comparison to the number of unencrypted 1040s e-mailed around by tens of thousands of accountants every year, and the untold millions other tax-related forms that traverse unencrypted network channels?

If you steal my credit card number, I can call the bank and ask them to issue me a new number. A few days later, I have a new card. The bad guy can, at worst, incur a few hundred dollars in charges, maybe a few thousand if they are really lucky. Yet, credit card data is somehow seen as the primary piece of data that needs protection. How many news reports have you read that discuss a computer breach and include the words "no credit card numbers appear to have been compromised?" Have we completely lost sight of the fact that there may be other pieces of information that need protection?

Consider the corollary. If you steal my social security number, you can take over my house, get any number of credit cards in my name, give me a criminal record, get a driver's license in my name... And, how do I clean it up? If I call the Social Security Administration and ask for a new number because my existing number has been compromised they would simply laugh at me. Only in exceptionally rare circumstances do they issue new numbers. In some states I am permitted, if my social security number has been compromised, to put in a credit report freeze, but the burden is on me, as the victim, to prove that my information has been compromised before I can get a freeze. If I am deemed worthy of getting the barn door closed after the horses have fled, I get to pay $30-60, per freeze, per credit bureau, requested by certified mail. And each freeze may only be good for 90 days. That's only in some states. Other states prohibit credit freezes, and a few, more progressive ones, actually permit consumers to close the barn door before the horses run away. The freeze usually still costs money, and usually is still time-limited, and usually still requires that you use certified mail to each credit bureau to request it. Fortunately, you can "thaw" the freeze by making a single phone call and typing in a four-digit pin.

What is wrong with this picture? Why are accountants and comptrollers still e-mailing around the source data - social security numbers; while we as consumers only seem to care about the derived data - the credit card number? Why is there a Payment Card Industry (PCI) Data Security Standard that, while widely ignored, attempts to set data protection standards for cardholder data; but no Social Security Number security standard that establishes requirements for protection of social security numbers and liability for anyone who compromises someone else's Social Security Number?

Why do we not see any Attorney's General up in arms over that one? Who is going to help me protect the source data?

CBS News did a story a few days ago on the Transportation Security Administration (TSA). Basically it was a tit-for-tat between Bruce Schneier, security pontificator extraordinaire, and Kip Hawley, the administrator of the TSA. Mr. Hawley's maintans that the TSA provides a necessary service because we are at war, and the obvious battleground, apparently, is airplanes. Surely, we must all realize that just because the terrorists used airplanes once, they can't possibly have enough imagination to go for another target next time. Mr. Schneier, wisely, disagrees, points out all the flaws in what the TSA does, and calls the whole thing "Security Theater;" a term whose origins are not entirely undisputed, but that is beside the point.

The interesting thing with this story is that neither of Messrs. Schneier and Hawley were quoted as addressing the currently most glaring flaw in the entire air transportation security apparatus. If one of our enemies actually wanted to terrorize the populace, why take on the risk of blowing up another plane? Just for fun, head on down to your local airport this week. Walk into the terminal area and take a look at the security line. At Dulles (IAD), Los Angeles (LAX), Chicago (ORD), Denver (DEN), Atlanta (ATL), John F. Kennedy (JFK), etc, the picture is the same. There will, at any given moment, be 500 to 1,000 people in line.

It took 5 terrorists per plane (four on one plane) to blow up the planes on September 11, 2001. Together, they managed to kill 2,751 people. That's  145 victims per attacker. Take those 19 terrorists, strap them full of explosives, and position them strategically in the lines the TSA has created leading up to the security checkpoints. I guarantee you that each one of them will kill 145 people, or more. Better still, have them get in line with a bag full of explosives, then leave the bag and step out of line. They will probably have two to three minutes to make a get-away before the bag explodes before anyone even so much as looks at those bags. One might even have more if one chats up the people next to oneself in line to watch the bag while the attacker runs to the restroom. Suddenly, we have the prospect of a devastating, coordinated attack that is far more insidious, far more deadly, and far more difficult to prevent, than the attacks of September 11. This one you can't inspect away. You can't put a security checkpoint to get into the security checkpoint.

The TSA, single-handedly, created this vulnerability by making the airport security checkpoints so incredibly inefficient (and, one might add, ineffective) that the lines leading up to them back up with hundreds, or, in the case of Dulles, even thousands, of people. If the terrorists really wanted to erode confidence in our transportation infrastructure, why not make the security checkpoints the most dangerous part of it?

Mr. Hawley, in your final few weeks, how are you going to protect the public you are sworn to protect from this attack? How are you going to prioritize our safety while we are waiting in line so that your spiffily dressed officers can declare us as posing no risk to the traveling public?

Wired, always a source for amusement and interesting literature, just carried a story on a "hacker" (the magazine's use of the term equates to "criminal") who attempted to dominate the market in stolen credit cards. It's a neat story about an unsavory character who is not going to get enough prison time. 

If you are too busy to read it, here is a synopsis:

---

Once upon a time, there lived in a far away land an evil dark lord. He lived in a dark castle with all kinds of dark objects around him. His most priced possession was the Mirror of Omniscience, which let him see into the lives of everyone else in the kingdom. His highest ambition was to take over the world and become ruler over all the land.
..
Luckily, there was a handsome and strong prince who wanted to preserve the beauty and way of life in this delightful communist enclave. The prince was deeply in love with the most beautiful woman in the whole kingdom. However, the dark lord had imprisoned her soul in his dark castle. So, the handsome prince set out to rescue her and save the kingdom from the impending disaster.
...
and the handsome prince broke the Mirror of Omniscience, and they all lived happily ever after.

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-alt:"Calisto MT"; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-alt:"Times New Roman"; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

Just as an FYI, for those of you that used Microsoft's recommended mitigations for MS08-078. If you unregistered the MSXML Island object you need to manually re-create the registry entries after you install the patch to restore the functionality. The patch does not re-create the registry entries. Unfortunately, it appears Microsoft removed the actual registry entries from the bulletin and removed the work-around information from the advisory altogether, so unless you created a backup copy, you will need to look at an untouched system to find out what the registry entry was.

Or, you can just copy this into a text file called “WhyDidTheyRemoveTheInformationINeed.reg” and double-click it:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}]

@="MsxmlIsland"

[HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}\InProcServer32]

"ThreadingModel"="Apartment"

@=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,\

  00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,73,00,\

  78,00,6d,00,6c,00,33,00,2e,00,64,00,6c,00,6c,00,00,00

[HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}\TypeLib]

@="{D63E0CE2-A0A2-11D0-9C02-00C04FC99C8E}"

Recently, Lev Bolotin of Clevx gave me a production sample of a USB token with a keypad on it. It's a pretty neat idea for certain uses. My immediate thought went to BitLocker in Windows Vista. You can store the BitLocker key on a USB stick, but you cannot prevent anyone who gets their hands on the USB stick from stealing the key. Nor can you require a PIN and the USB stick to unlock your drive. With Lev's stick, however, you can put a PIN on the USB stick itself. Unless you enter the PIN on the device before sticking it into the computer the stick won't give up the BitLocker key. In other words, you finally get the option for both a USB stick and a PIN to unlock your BitLocker volumes. 

I also like IronKey as a safe and secure USB stick. IronKey also permits multiple volumes, something that Clevx' technology currently does not have. In other words, IronKey lets you have one encrypted volume and one unencrypted one, both on the same stick. However, IronKey requires software installed on your computer to access the encrypted volume. This precludes its use to provide a second factor for BitLocker because the BitLocker key has to be available prior to booting the operating system, and IronKey's software cannot run unless the operating system is running. If you put your BitLocker key on the IronKey it must be on the unencrypted partition.

Clevx's PIN technology is currently available from Corsair in the Flash Padlock product.

More on BitLocker is available in Byron Hynes excellent TechNet Magazine article. I still run BitLocker on all my Vista computers.

Shocking, yes, I know, but in only four hours this evening Microsoft has managed to alienate over 150 additional customers with its insistence on Digital Rights Management (DRM). This time it is the DRM component of the Zune store that is down, according to the 164 posts so far over on the Zune forums. OK, so realistically, that probably means that about 100 times that many customers have been alienated, including my oldest son who is unable to use the $15 worth of Zune points that his mother just purchased for him because "Error C00D12F6: Can't verify your media usage rights. A local firewall may be blocking access to the Zune service".

Rest assured, it is not a firewall problem. It is just that the DRM servers on the Zune site are horked up, again. No DRM: no buying music. No buying music: unhappy son. Perhaps the best part of this was that a few customers who called the Zune support line (1-877-438-9863) to get help were told to reset their DRM components. That turns out to not be the best move they made tonight as after doing so they can no longer play ANY of the music they have purchased on the Zune store. Ever.

I will take guesses at this point for when the industry will FINALLY get it that DRM, while completely useless in combating actually piracy, is extremely useful in combating customer satisfaction.

If you really wanted to defeat the Zune DRM it really is not that hard. For one, you could use FairUse4WM. Alternatively, my old friend Rob Hensing, in the Security Engineering group at Microsoft recommends using the old trick of burning the songs on CD and ripping them again to remove the DRM from legally purchased music. Those ideas work for music. If your fancies turn to DVD movies on your Zune, there are some suggestions for how to do it from Microsoft employees on the TechNet and MSDN blogs sites. Keith Combs apparently prefers the Xilisoft DVD Ripper Platinum. Andy Pennel appears to have figured out how to rip DVDs to play both on his Zune and his Media Center PC, but won't tell you how on his MSDN blog. Probably a wise move considering he just admitted to a Federal Crime on a company-sponsored blog. Wouldn't want to give the prosecutor too much information now, would we? Rohan Thomas, however, discusses how to leverage new Silverlight features when ripping your DVDs on his MSDN blog. Steve Makofsky, over on the MSDN blogs, apparently uses DVD Decrypter and Nero Recode to get his DVD movies into a format suitable for playing on devices. That is the same piece of software Keith Combs used.

Did I mention, by the way, that Amazon sells music without DRM? It will play for sure on any device you have now or in in the future.

I get a fair bit of blog spam - comments advertising everything from sexual enhancers to fake anti-malware. This one just came in this morning:

Sweet! I can turn off all the blog spam just by e-mailing the criminals? Or, could it possibly be that this is a clever ruse find out what my e-mail address is so they can send their junk there too? Hmm. I think I'll just forward this to abuse@gmail.com.

For a while I've been thinking about writing something about interesting times I've had at various airport security checkpoints; security theater, as they have come to be known. There is the obvious shoe removal arguments and the ill-defined rules on electronics (my camera is larger and has more electronics than most laptops, but that can stay in the bag, laptops can't), but there have been more interesting stories. Got any of your own? Share them!

Around November 2001 a colleague of mine and I flew to New York on business. On the way back we went through Kennedy airport. I was wearing a pair of boots, which the TSA (was it even TSA then?) required me to remove, even though shoes were not normally removed at the time as airport security hadn't yet figured out that you could bomb a plane with them. The lady scanned them for explosives and then handed them back saying "these are OK." I was so relieved because I had explicitly asked for the non-exploding boots when I bought them.

Not TSA related, but still: the same year I was traveling through Boston with my competition shotgun. It was broken down into three pieces and stuffed into a very solid, and quite short, aluminum case. When I went to check in I told the check in agent that it needed special screening. She asked me to open it and then asked what it was. I responded that it was a shotgun. She took two steps back from the counter, threw her hands up in the air, and exclaimed "Is it unloaded?" I felt like answering "What? It has to be unloaded? But what if I want to use it during the flight?" Fortunately for me, I didn't.

Several years later I was flying from Seattle, this time with a rifle. Firearms require special screening so after checking in they called a sky cap to carry it for me over to the TSA because I am no longer allowed to touch it at that point at Seattle Tacoma International Airport. Note that at other airports I am perfectly well allowed to touch it as they usually make me hand carry it to the checkpoint. Once I got there the Transportation Security Officer (TSO) asked me for the keys and then struggled with the case for a while before opening it. I offered to help, but he refused as I were not allowed to touch it. He poked around the foam in the case for a while, but all the while refused to lift the rifle. I informed him that the foam is removable and he was welcome to do so as it would make it far less likely I would try to sneak a bomb on the plane. He ignored me. When he was done with that I asked if he was finished and he said "not quite," which turned out to be nearly the only two words this friendly gentleman said to me the entire time. He then turned around, grabbed the explosives swab - and proceeded to swab my rifle down for explosives! I tried asking him how he thought the bullets come out of it! Unfortunately, the airline agent that was with me was laughing so hard I couldn't make myself heard. We both stopped laughing when the TSO explained that he did not find any explosives. It turns out that the Explosives Trace Detection (ETD) units used for explosives swabbing can evidently only detect ammonia-based explosives. Lesson: I wonder when the TSA will realize the giant hole in failing to detect smokeless gun powder?

This year, again with a rifle, I asked why the TSO was so careful not to touch the rifle. Apparently, they are not trained in handling firearms and are afraid they will explode if they touch them. Silly me, I thought they were federal law enforcement officers. Now I realize they are not. They're mostly just people like you and me, except they save lives; and I work in real security.

Shoes again: apparently kid shoes are no threat. I travelled with my three-year old a few years ago. As we went through the check-point they made me remove my shoes for screening, but she could keep hers on. I'm not sure if they were too small to pose a threat (presumably if they were actually bombs there may not have been enough explosives in them to blow a hole in the plane?) or whether they just figured I would be willing to blow myself up but not to sacrifice her. I asked them what size shoes must be to pose a threat, but they refused to answer, citing national security concerns.

A year or so after September 11, I went through Minneapolis airport. Going through the security checkpoint I asked the TSO if he wanted me to put my clothes and underwear in a separate bin or whether I could put them in the same bin. He went beet red and disappeared. The replacement officer told me to take this very seriously and make sure I remove even the smallest piece of metal, like my neck chain, because the scanner was so sensitive this time. I went through without incident. When I got comfortably ensconced in seat 47 E I stuck my hand in my pocket and discovered the three-inch pocket knife I had forgotten to remove. I contemplated briefly calling the TSA and asking if the machine was actually plugged in but decided that would just cause them to empty the whole airport and then arrest me so I figured I'd better let sleeping dogs lie. Amazingly, even with this incredible breach of security, I got home safely.

There are probably more stories. What's your most outrageous one? I've heard of many, like the federal marshal who was permitted to fly with a loaded hand gun but had his nail clippers confiscated, and the TSO that held a leatherman knife and failed to recognize it. If you just want to read some others, read Jeffrey Goldberg's article in the Atlantic Monthly.

Several helpful people just pointed me to some articles on XP Antivirus and its various variants. In case you do not remember, XP Antivirus was the subject of an article I wrote for The Register a few months back.

It turns out that the scammers got hacked, and the hacker posted some internal accounting details on the web. As suspected, this is a sophisticated business making millions of dollars. It even appears to have an affiliate program.

In case you have not seen the articles yet, here are a few:

http://www.iht.com/articles/2008/10/30/technology/virus.php
http://www.smh.com.au/news/technology/security/russian-scammers-cash-in-on-popup-menace/2008/11/04/1225560814202.html
http://www.scmagazineuk.com/Hacker-reveals-Russian-software-company-behind-anti-virus-scam/article/120152/

Thanks to Marc Michault, Phillippe Jan, and Jason Grubè for all pointing me to articles on this topic.