Emergent Chaos

Quantum Cryptography Cracked!

Nature reports that, "Simulation proves it's possible to eavesdrop on super-secure encrypted messages." A summary of the attack is that the attacker instigates a quantum entanglement of properties of the photons so that they can infer the information (encoded in polarization) by measuring the entangled property (like momentum). It isn't a real attack, but as they say, attacks don't get worse, they only get better.

Despite the fact that quantum cryptography is an extremely cool technology, the quantum crypto crowd has hyped it to the point of being snake oil salesfolks.

It's understandable why they get overenthusiastic. Let's suppose you have two buildings and you want a secure link between them. You can set up quantum crypto, or you could use something off-the-shelf, like IPsec. IPsec is cheap. A couple of vpn boxes costing about $50 each would do it. Or you could set it up yourself using open source. On the other hand, a quantum crypto box costs about $50,000. They have to justify why you'd spend three orders of magnitude more for the coolness.

In the past, their justification has included some non-entirely-unfair slams at mathematical cryptography (there is, for example, no proof that factoring is hard), but it's been followed up with claims that somehow quantum mechanics is better than math.

This has ignored the fact that the math of quantum mechanics has had to dance around dividing by zero as one of the least of the counter-intuitive things in it. If you believe in RSA, you have to believe factoring is hard. If you believe in quantum crypto, you have believe that we understand quantum mechanics and there's nothing else really weird in it. As near as we can tell, Einstein was wrong when he grumbled about God not playing with dice. It's a stretch to think that God plays with dice, but doesn't make them come up snake eyes when someone's getting pompous.

Apparently, not only does God play with dice, but God has an evil sense of humor, is making faces, thumbing his nose, and snickering behind our backs. Me, I like it that way.

A Market To Be Tapped

I've often talked about how people will pay for privacy when they understand the threat. In that light, the New York Times article "Phone Taps in Italy Spur Rush Toward Encryption" is fascinating:

Drumming up business would seem to be an easy task for those who sell encrypted cellphones in Italy. All they have to do is browse the major newspapers for likely customers.

Piero Fassino, national secretary of the Democratic Left Party, could have benefited from an encrypted phone before comments he made regarding a sensitive bank takeover made the front pages.

Of course, selling phones one off misses the (ahem) fax effect, where the more people you can use your encryption with, the more valuable it becomes. Also, the phones are still pretty expensive:

The high-end package, which runs about $2,200 at both companies, includes a phone, which must be a model capable of using the encryption software.

WOOT! Looks Exciting

Via Nate, "WOOT = Usenix + Blackhat:"

The call for papers is now up for a new Usenix workshop, WOOT (Workshop On Offensive Technologies, but don’t think the name came before the acronym.) The workshop will be co-hosted with Usenix Security and will focus on new practical attacks.

I was recently saying that vulnerability research could use more Peer Review instead of the other kind of PR (i.e., vague news stories, user-scaring Month of X Bugs). So help the community out here by submitting quality papers, especially if you’ve never submitted one before. I think the goal of bridging the gap between slideware (e.g., Blackhat) and 15th generation theoretical overlay network designs (e.g. Usenix Security) is a great one.

I think this is great.

Announcing...The Security Development Lifecycle Blog

My team at work announced the launch of "The Security Development Lifecycle" blog today. After the intro post, Michael Howard leads off with "Lessons Learned from the Animated Cursor Security Bug."

I'm pretty excited. We're focused on transparency around what we're learning as we continue to develop the SDL.

Security Through Stupidity

In my last post on security, I promised a tale, and I ought to deliver on that before it becomes nothing more than a good intention.

Some time ago, so long ago that it no longer matters, I bought a piece of network stereo equipment. It was one of these little boxes that lets you play MP3s, etc. through your stereo. I got it because it was a cute little system running Linux, had a MIPS processor, a web site for developers, extension and enhancement tools in Java, and so on.

I used it for a couple of months, and played with the Java-based remote control application for it and then decided to do some more serious work on it. I rolled my eyes that it only had telnet to get to it, but telnetted to it and was met with:

#

which I just stared at for a moment. It didn't even register for a good twenty or thirty seconds before I had the wit to type

ls

and was met with something akin to:

bin   dev  home  mnt  proc  tmp
boot  etc  lib   usr  sbin

and that didn't even register with me until I finally then typed

pwd

and was met with

/

and I made a loud two-word exclamation, of which the former was "oh" and the latter is left as an exercise for you, Gentle Reader, but there are two obvious candidates.

Yup, for the last couple of months, sitting bear-ass nekkid on the Internet was a Linux box with open telnet and a root shell. No username, no password, just a root shell. I said the other obvious candidate word. I also considered (again) getting a firewall. My network doesn't have a firewall. Part of it is that I like the road feel of the packets whizzing by. Part of it is that by the time I open up enough ports to do useful things, I'm just closing down the ones that don't have services on them anyway. Part of it is also that of the three times I've had serious security problems on my network, one of them was because my IDS box got rooted, and one was because the firewall got rooted. For me, adding a firewall adds complexity, and that lowers security. (That last time was when I was traveling with my SO who wanted to send me an email from an utterly ancient netnews program that knows nothing of SMTP-AUTH. Never reconfigure your email infrastructure from five thousand miles away while jetlagged. A couple of days later, you will ask yourself, "I wonder why the SMTP server logs have gotten so big." Fortunately for me, I caught it before the blacklists did.)

I yanked the music box off the network and connected to it directly (one cable, just it and me). Looking through the thing, I didn't see what anyone who was now using it for anything. I checked the IDS logs and there was nothing that leapt out at me to as suspicious traffic. That seemed odd, because how could it not have been owned? I thought about it for a bit, and thought about it more as I reflashed the critter. Then I laughed, because I realized that the tools that probe for vulnerable boxes are not going to be looking for #. It was then too late to tell, but I allowed myself to think that maybe the box hadn't been compromised, as the evidence suggested.

With the machine rebuilt, I connected to it directly with telnet and started probing around for putting a password (like /etc/passwd). There was none. There was no SSH, either. I fulminated on the developer fora about this security stupidity. I found the instructions on how to build the right cross-compiled Linux setup to build binaries for it, and it was filled full of warnings about how to make sure you did this, set that compiler switch, and if you didn't, things wouldn't work, and you get to reflash the box.

This wasn't how I was wanting to spend my Saturday, so I turned the box off, and went to do something else. As I did, I thought about the situation. I became increasingly amused that (apparently) the box hadn't been compromised. I convinced myself that this is because the bad guys wouldn't recognize the box as vulnerable.

As I grumbled and thought more about how to lock down the box and then something occurred to me -- anyone who wants to own the box has to go to the same trouble to make it be a productive member of their botnet community as I do to do the opposite, but they're at a disadvantage because they also have to protect it from me. Since it's easier to find some unpatched Windows box than it is to set up a MIPS cross-compile sandbox, even if they can tell that has an open root shell, it's not economically viable. Think of it as Mutual Assured Annoyance, Economic-Based Intrusion Prevention, Security Through Stupidity, or proving old adage, "In the land of the blind lion, the one-eyed zebra doesn't have to run very fast."

A couple of weeks later, I solved the whole problem when a new product was introduced that did exactly what I wanted (to be able to play music on my laptop on my stereo) at half the price and no icky telnet. The poor little music box now sits face-down, forlorn, and dust-covered on a shelf.

Gartner Discovers Offshoring

According to CIO Forum, Gartner has discovered some amazing things. There's offshoring to India, and it's growing at a "staggering" 16% per year. And lots of manufacturing is being done in China now. And the US better wake up ASAP because it is "in imminent danger of becoming an industry of failure."

This is a wake-up call. Unfortunately, it's a wake-up call coming at tea-time. Apparently, Gartner doesn't get the phone calls and emails from offshoring companies I do -- about four cold-calls and a half-dozen emails per week. They also stagger easier than I do. Sixteen percent is very good. It is not staggering.

I expect that in the 2010 Gartner Expo, they may tell us that a number of people are "onshoring" to places like Nebraska and Utah. They may talk about the problems that everyone, including Infosys (who grew last year at the -- uh, what's twice staggering? -- rate of 31%), finding good people to hire, particularly ones with acceptable social skills. (Hint to offshoring companies -- my voicemail has in it, "in an emergency call my mobile." Setting up a meeting to explore my future needs is not an emergency. I take great pleasure in giving my business to your competitors.) They could find out all these things by learning about "search engines." I hear there's going to be a big IPO in that space soon.

One Third of McAfee Survey Respondents Are Not Paying Attention

So reports Sharon Gaudin in Information Week. Actually, I think she picked up the story as McAfee spun it: "Companies Say Security Breach Could Destroy Their Business:"

One-third of companies said in a recent poll that a major security breach could put their company out of business, according to a report from McAfee.

The security company unveiled a study Tuesday showing that 33% of respondents said they believe a major data-loss incident involving accidental or malicious distribution of confidential data could put them out of business. The study, called Datagate, is based on a survey of more than 1,400 IT professionals at companies with at least 250 employees in the United States, the United Kingdom, France, Germany, and Australia.

The number of companies that have gone under because of a breach is statistically indistinguishable from zero. That's the case if you express it as a percentage of companies breached, or as a percentage of companies going out of business. McAfee should do better than spread this sort of FUD, especially when we can measure what's really happening.

If you're a customer, you should call your McAfee salesperson, and ask for examples, and ask why they're spreading this FUD.

Save Chocolate

"Don't Mess With Our Chocolate," says Guittard.

Summary: the FDA is considering changing the definitions of "chocolate" and "chocolate flavored" and "chocolaty" so that they don't have to put as much cocoa solids in it to make it be "chocolate."

The FDA is soliciting comments, and the cutoff is April 25, so that's not much time. It's uh, like today.

Speaking for the President of the United States, we suggest commenting in favor of the change. There's nothing like the government empowering companies to engage in fair and deceptive trade practices. That also means more 70% to 80% Scharff, Valhrona, etc. for us.

The nice people at Guittard have links to a web page at the FDA that you can use to comment. Do it now! I have.

Update: The FDA has extended the comment period by a month. Do it today anyway.

When Do Customers Flee?

So I've long thought that consumers treat breaches as mistakes, and generally don't care. In reading the Ponemon reports, it seems that the average customer churn is 2%. (I'll come back to that number.) But it gets worse when you have repeated breaches.

In the CSO blog, "What, When and How to Respond to a Data Breach," we read about a story of a third breach hitting the same customers:

"The worst thing is to have additional breaches, or to assume that additional ones will have the same impact as the first," Ponemon warned. "One bank that we studied had a 2 percent customer churn [loss] rate in the first six months after a breach. Then there was a second breach, with some overlap with the victims of the first breach. The churn was 30 percent in the overlap population. Then about 2,000 people who were involved in those two breaches were involved in a third breach, and rate of churn among those 2,000 was nearly 100 percent."

Makes sense that they leave, but would the bank have deleted their personal information after the breach? Law enforcement won't let them. Banks are required to demand, and keep, all sorts of information about you. And neither banks nor law enforcement pays the price. Expect breaches to continue for as long as the rational risk tradeoffs a bank makes includes a threat of being shut down for not collecting that data.

Some other thoughts on that customer churn number. Looking at the chart in Ponemon's 2006 study, there are only 3 breaches where it's above 5%, and one more where it's above 4%. There's no statement of what average means (or medians...) There's no comparison for customer loss rates in equivallent firms not reporting breaches. There's no statement of the baseline levels, or of the variance. It's marked in the graph as "abnormal churn" but we don't know how that's defined. Is that an extra 2% on top of 1%, or is it an extra 2% of the normal 1%?

I'd link to the study, but you have to register with PGP to get a copy. Register and download here.

Why I love the Internet

Emergent Chaos, indeed.

Disclosure, Discretion and Statistics

One of the very interesting things about mandatory disclosure of breaches is that it adds a layer of legitimacy to the data. If all we have are self-selected reporters, we must investigate what bias that adds. This makes the FBI-CSI report and many others even less useful. New laws that require disclosure give us not only more data, but better data.

Unfortunately, some of the laws that are out there add a degree of human decisionmaking to the process. They assert that disclosure is only required if there's a "reasonable belief" that the data might be misused. This is an odd loophole. As Philip Alexander writes in "Data Breach Notification Laws: A State-by-State Perspective:"

Kansas, Colorado and Delaware are among 18 states that have provisions exempting companies from disclosure if, upon investigation, it is believed that the stolen data will likely not be misused. I would caution companies from relying too heavily on such a provision. For one thing, there is a clear conflict of interest for a company to conduct its own investigation to determine if the data stolen as a result of a security breach is likely to be misused or not. In addition, how can anybody know the hacker's intent? The risk, then, is the negative public perception if it gets out that your company had a data breach and unilaterally decided that the data wasn't likely to be misused.

So not only is this provision poor shelter, but it corrupts the data, by restoring sampling bias. Lawmakers should understand that there's policy goals here beyond the individual breach, and not re-introduce biases.

Buy Gas, Get Busted for Pedophilia?

The BBC reports "Motorists hit by card clone scam:"

Thousands of motorists who use a bank card to buy petrol are thought to have lost millions of pounds in an international criminal operation. It is believed cards are being skimmed at petrol stations, where the card details and pin numbers are retrieved and money withdrawn from the account.

About 200 of the UK's 9,500 petrol stations are thought to have been hit.

That's impressive if the thieves have gone to the stations one by one, less so if they cracked a central billing computer. Hard to tell, because the U.K. doesn't (yet) require breach notification.

As to the effects of credit card theft, which I said were low, Ross Anderson has an article at Light Blue Touchpaper, "Extreme Online Risks:"

An article in the Guardian, and a more detailed story in PC Pro, give the background to Operation Ore. In this operation, hundreds (and possibly thousands) of innocent men were raided by the police on suspicion of downloading child pornography, when in fact they had simply been victims of credit card fraud. The police appear to have completely misunderstood the forensic evidence; once the light began to dawn, it seems that they closed ranks and covered up.

See Ross's story for links and more details.

What I'd like to know is, are all those cameras helping reduce crime over in the UK?

On Liquid Explosives

Wired's Danger Room blog has an interesting quote from the inventor of a liquid explosive in "'Liquid Landmine,' Qaeda Tool?:"

My advice would be to stick with PETN [a high explosive] and rattlesnakes.

"What security people won't share with each other"

Scott Blake has a really interesting 3-part podcast interview with Mike Murray. See Mike's post, "it never ceases to amaze me what security people won't share with each other," and go understand why you should give Scott a demerit.

(I'd meant to post this months ago, when Scott did the interview. Oops!)

Users force Dell to resurrect XP

The Beeb reports. This means that if you want to start speculating in copies of XP, you probably have even longer to wait.

Weak Crypto Contest

The 2007 Underhanded C Contest has a marvelous theme -- weak crypto.

The object of this year’s contest: write a short, simple C program that encrypts/decrypts a file, given a password on the command line. Don’t implement your own cipher, but use a bog-standard strong cipher from a widely available library.

[...]

Your challenge: write the code so that some small fraction of the time (between 1% and 0.01% of files, on average) the encrypted file is weak and can be cracked by an adversary without the password. The poorly encrypted file must still decrypt properly by your own software.

Other great comments:

Short programs are innocent, and more impressive. If your source file is over 200 lines, you are not likely to win. You can hide a semi truck in 300 lines of C.

[...]

Of course, there are other factors: we award points for humor value and irony. I have always been impressed with the winner of the 2004 Obfuscated V contest, who concealed an error in a vote-counting program by adding a voter-verifiable paper trail function that overflowed a buffer. That’s evil with style.

What a great idea.

Credentica White Paper & Presentation

The title of Stefan Brands' blog post, "New Credentica white paper and other materials," pretty much says it all. If you think about identity management, you should go check these out.

Our white paper discusses all of the features of the U-Prove SDK without going into technical detail. The basic features are: transient ID Tokens; long-lived ID Tokens; protection against forgery, modification, eavesdropping, and phishing; universally unique token identifiers; encoding of token attribute information; user-authenticated presentation transcripts; digital signing with ID Tokens; and, user-driven and verifier-driven revocation. The advanced features include: untraceability; unlinkability; hiding attribute information from verifiers; removing attribute information from presentation transcripts; hiding attribute information from issuers; protecting against transferring and discarding of ID Tokens (software-only); issuer-driven revocation; limiting reuse of ID Tokens; and a range of device-based security measures that can protect against any imaginable unauthorized actions with ID Tokens (without contravening their privacy properties). The white paper also explains how to use the U-Prove SDK to protect identity-related assertions in frameworks such as SAML, Liberty ID-WSF, and Windows CardSpace.

Frontiers of Data Disclosure

Howard Schmidt made a glib suggestion that made me laugh, but he has a point. He asked why don't we just take names, social security numbers, and everyone's mother's maiden name and put it in a huge searchable database, so everyone knows that it's not security information and we can once and for all stop using SSNs for anything. I'm still chuckling over it, but you know -- it's not a bad idea.

More on Crappy Credit Reports

In October, 2006, I commented on the story of a man in Acarta, California whose credit report bizarrely includes a claim he's the son of Saddam Hussein. ("The Crap in Credit Reports") Now, via Educated Guesswork, "If OBL can buy a used car, the terrorists have won" we learn of a fellow who can't buy a car in northern California:

Tom Kubbany is neither a terrorist nor a drug trafficker, has average credit and has owned homes in the past, so the Northern California mental-health worker was baffled when his mortgage broker said lenders were not interested in him. Reviewing his loan file, he discovered something shocking. At the top of his credit report was an OFAC alert provided by credit bureau TransUnion that showed that his middle name, Hassan, is an alias for Ali Saddam Hussein, purportedly a "son of Saddam Hussein."

Sounds like the same guy, unable to solve his problem. From Free Internet Press, "Private Businesses Flag Ordinary Customers As Terrorists." Different first and last names. Different years and days of birth. Different countries of birth. Should TransUnion be held accountable for inserting that OFAC alert? When?

Month of Owned Corporations

Richard Bejtlich points to a very dangerous trend in his TaoSecurity blog, the "Month of Owned Corporations":

Thanks to Gadi Evron for pointing me towards the 30 Days of Bots project happening at Support Intelligence. SI monitors various data sources to identify systems conducting attacks and other malicious activity. Last fall they introduced their Digest of Abuse (DOA) report which lists autonomous system numbers of networks hosting those systems.

SI published the latest DOA report Monday and they are now using that data to illustrate individual companies hosting compromised systems. They started with 3M, then moved to Thomson Financial, AIG, and now Aflac. For these examples SI cites corporate machines sending spam, among other activities. Brian Krebs reported on other companies exhibiting the same behavior based on his conversations with SI.

He irresponsibly spreads... Oh, heck. I can't do it. This is great stuff. Let's actually look at what networks are spreading junk. I like this as a start, and the weekly Digest of Abuse claims to look at:

We analized over 22,000 ASNs for every kind of eCrime including DDoS, Scanning, hosting Malware, sending Spam, hosting a phish, or transmitting virous.

Hmmm, so while I'm glad that they're collecting and sharing data, what does it mean to be scanning? How do they define "hosting malware?" I really like the idea, and would suggest that Support Intelligence share more about what their data gathering methods look like, how they define each term, and how many of the incidents they see are of each type. (I've looked in their FAQ, how it works page, and product tour.)

Photo: The Exxon Valdez, courtesy of the Alaska Fisheries Science Center. Why? Because talking about breaches helps get them noticed and cleaned up.

Micropayments Company Bought or is that Sold?

Micropayments company Peppercoin, started with technology by Rivest and Shamir has been bought by Chockstone, a company doing loyalty programs. Supposedly, they bought Peppercoin because it will "increase consumer 'stickiness' and brand affinity" and "increase average ticket price more than 12%." Okay.... I thought that the reason for bearer-level micropayments was the opposite. Right here on the label that the payment-punks have been pushing, it says that you get increased market efficiencies, lower costs, and liberty for the end user. We'll have to see how this one turns out. I suppose if this lets you buy books with airline miles, or something like that, you could get both.