District Court Holds that Running Hash Values on Computer Is A Search: The case is United States v. Crist, 2008 WL 4682806 (M.D.Pa. October 22 2008) (Kane, C.J.). It's a child pornography case involving a warrantless search that raises a very interesting and important question of first impression: Is running a hash a Fourth Amendment search? (For background on what a "hash" is and why it matters, see here).

First, the facts. Crist is behind on his rent payments, and his landlord starts to evict him by hiring Sell to remove Crist's belongings and throw them away. Sell comes a cross Crist's computer, and he hands over the computer to his friend Hipple who he knows is looking for a computer. Hipple starts to look through the files, and he comes across child pornography: Hipple freaks out and calls the police. The police then conduct a warrantless forensic examination of the computer:

In the forensic examination, Agent Buckwash used the following procedure. First, Agent Buckwash created an "MD5 hash value" of Crist's hard drive. An MD5 hash value is a unique alphanumeric representation of the data, a sort of "fingerprint" or "digital DNA." When creating the hash value, Agent Buckwash used a "software write protect" in order to ensure that "nothing can be written to that hard drive." Supp. Tr. 88. Next, he ran a virus scan, during which he identified three relatively innocuous viruses. After that, he created an "image," or exact copy, of all the data on Crist's hard drive.

Agent Buckwash then opened up the image (not the actual hard drive) in a software program called EnCase, which is the principal tool in the analysis. He explained that EnCase does not access the hard drive in the traditional manner, i.e., through the computer's operating system. Rather, EnCase "reads the hard drive itself." Supp. Tr. 102. In other words, it reads every file-bit by bit, cluster by cluster-and creates a index of the files contained on the hard drive. EnCase can, therefore, bypass user-defined passwords, "break down complex file structures for examination," and recover "deleted" files as long as those files have not been written over. Supp. Tr. 102-03.

Once in EnCase, Agent Buckwash ran a "hash value and signature analysis on all of the files on the hard drive." Supp. Tr. 89. In doing so, he was able to "ingerprint" each file in the computer. Once he generated hash values of the files, he compared those hash values to the hash values of files that are known or suspected to contain child pornography. Agent Buckwash discovered five videos containing known child pornography. Attachment 5. He discovered 171 videos containing suspected child pornography.

One of the interesting questions here is whether the search that resulted was within the scope of Hipple's private search; different courts have approached this question differently. But for now the most interesting question is whether running the hash was a Fourth Amendment search. The Court concluded that it was, and that the evidence of child pornography discovered had to be suppressed:

The Government argues that no search occurred in running the EnCase program because the agents "didn't look at any files, they simply accessed the computer." 2d Supp. Tr. 16. The Court rejects this view and finds that the "running of hash values" is a search protected by the Fourth Amendment.

Computers are composed of many compartments, among them a "hard drive," which in turn is composed of many "platters," or disks. To derive the hash values of Crist's computer, the Government physically removed the hard drive from the computer, created a duplicate image of the hard drive without physically invading it, and applied the EnCase program to each compartment, disk, file, folder, and bit.2d Supp. Tr. 18-19. By subjecting the entire computer to a hash value analysis-every file, internet history, picture, and "buddy list" became available for Government review. Such examination constitutes a search.

I think this is generally a correct result: See my article Searches and Seizures in a Digital World, 119 Harv. L. Rev. 531 (2005), for the details. Still, given the lack of analysis here it's somewhat hard to know what to make of the decision. Which stage was the search — the creating the duplicate? The running of the hash? It's not really clear. I don't think it matters very much to this case, because the agent who got the positive hit on the hashes didn't then get a warrant. Instead, he immediately switched over to the EnCase "gallery view" function to see the images, which seems to be to be undoudtedly a search. Still, it's a really interesting question.

Setting the context for this post, it is a tough economic situation all over the world. IT spending has reduced and will reduce significantly. In one of earlier posts, I had referred to information security as an overhead of an overhead (IT). What is a good approach for security practice in this type of economy?

I don't have a magic wand to pull a rabbit out of a hat. I have always been told that: tough economy is the time for real smart people to make money. Coming back to information security topic, with a bit of common sense, it is wise for information security professionals to offer services in those areas that does not involve capital expenditure. As a Security Manager, you may be already aware that your people are willing to go an extra mile in the current economic times.

- No budget or lack of budget, means no new capital expenditure. Spend time wisely in building a future technology strategy and keep it in the back pocket when the economy turns around.

- This is a good time to create roles/responsibilities and ownership for various areas. Create operating procedures. Make your team to automate tasks. This will help your operations become more efficient.

- This is time for security awareness  education. Create pamphlets/brochures/presentations for an online or classroom training. Engage your and your team's time to impart training.

- Leverage already invested technology platforms. Leverage utilized features that reduce costs. If you have already invested in technology such as VMware, this is the time to get the best out of it. You can use VMware's toolkit to build your lab and staging environment and optimize on hardware cost.

- Off shoring has been the mantra of senior executives, this is the time to revisit those services and measure their performance closely and assess your satisfaction level. This is a good time to build a case for not off shoring if it makes sense.

- Companies are more vulnerable in bad economic times. You are in a better position to influence senior management about information security risks under these circumstances and drive home the value of protecting your intellectual property under these kinds of circumstances. management will be all ears for such a pitch.

- Time to engage your architect to optimize your security architecture, revisit standards and optimize design for cost efficiency.

- Revisit various controls and see if there are some risks that you could optimize spending on.

- Training budget is an unfortunate victim of this type of economy. Encourage employees to take free webinars offered by various security vendors and encourage them to share the summary across the team. This will put your employees in touch with latest happenings in security at the same time there is some learning that is imparted despite zero training budget.

- Since there are very few projects in action, this is a good time to have conversations with cross functional teams and educate them about your services and solicit feedback on how to do better.

- Revisit your vendor logistics and identify whether you can renegotiate some of your already existing contracts.

The above are some good ways by which you can optimize costs, this will also enhance your team's competence level in the long run. And this approach is better than letting people go, if you can pull this.

Luckily we do have some technologies to warn users who still haven’t learned to stop opening spammy attachments, click pop up ads and so on…but I don’t think they’d help with the snarky attitude problems. I’m not sure I’d want my computer network to try doing that anyway.

Steps are now being taken, rather faster since Dan Kaminsky came up with a really effective DNS poisoning attack, to secure DNS by using DNSSEC.

The basic idea of DNSSEC is that when you get an answer from the DNS it will be signed by someone you trust. At some point the “trust anchor” for the system will be “.” the DNS root, but for the moment there’s just a handful of “trust anchors” one level down from that. One such anchor is the “.se” country code domain for Sweden. Additionally, Brazil (.br), Puerto Rico (.pr), and Bulgaria (.bg) have signed their zones, but that’s about it for today.

So, wishing to get some experience with the brave new world of DNSSEC, I decided that Sweden was the “in” place to be, and to purchase “cloudba.se” and roll out my first DNSSEC signed domain.

The purchase wasn’t as easy as it might have been — when you buy a domain, Sweden insists that people provide their identity numbers (albeit they have absolutely no way of checking if you’re telling the truth) — or if a company they want a VAT or registration number (which are checkable, albeit I suspect they didn’t bother). I also found that they don’t like spaces in the VAT number — which held things up for a while!

However, eventually they sent me a PGP signed email to tell me I was now the proud owner of “cloudba.se”. Unfortunately, this email wasn’t in RFC3156 PGP/MIME format (or any other format that my usually pretty capable email client understood).

The email was signed with key 0xF440EE9B which was reassuring because the .se registry gives the fingerprint for this key on their website here. Rather less reassuringly footnote (*) next to the fingerprint says “.SE signature for outgoing e-mail. (**) June 1 through August 31.” (the (**) is for a second level of footnote, which is absent — and of course it is now September).

They also enable you to fetch the key through a link on this page to their “PGP nyckel-ID” at http://subkeys.pgp.net.

Unfortunately, fetching the key shows that the signature on the email is invalid.

Since the email seems to have originated in the Windows world, but was signed on a Linux box (giving it a mixture of 0D 0A and 0A line endings), then pushed through a three year old copy of MIME-tools I suppose the failure isn’t too surprising. But strictly the invalid signature means that I shouldn’t trust the email’s contents at all — because the contents have definitely been tampered with since the signature was applied.

Since the point of the email was to get me to login for the first time to the registry website and set my password to control the domain, this is a little unfortunate.

Even if the signature had been correct, then should I trust the PGP key?

Well it is pointed to from the registry website which is a Good Thing. However, they do themselves no favours by referencing a version on the public key servers. I checked who had signed the key (which is an alternative way of trusting its provenance — since the email had arrived to a non-DNSSEC secured domain). Turned out there was no-one I knew, and of 4 individual signatures, 2 were from expired keys. The other signature was the IIS root key — which sounds promising. That has 8 signatures, once again not people I know — but only 1 from a non-expired key, so perhaps I can get to know some of the other 7?

Of course, anyone can sign a key on a public key server, so perhaps it makes sense for .se to suggest that people fetch a key with as many signatures as possible — there’s more chance of it being signed by someone they know. Anyway, I have now added my own signature, using an email address at my nice shiny new domain. However, it is possible that I may not have increased the level of trust

In any case, if you do pentests, think about all the RECENT cases where you break in to a major corporation through:

• a Solaris system with Internet-exposed telnet with a guessable password OR a telnet vulnerability (circa 1994!)
• an exposed VPN appliance with a manufacturer's administrator password
• a router with default "enable" password
• or, something else entirely - but something that rivals the above example in its unparalleled, unbelievable, abysmal, deep idiocy.

Indeed, many of my pentesting friends still report plenty of such cases (one was also featured in the presentation mentioned above). Whenever I hear about it from a pentester, I always ask:

Do you think "somebody bad" had already passed through the hole you just discovered?

Maybe an hour ago, a day ago - or a year ago?!

I cannot see how the answer can be "no."

Even though pentesters usually don't focus on forensics (no time for this), it is not uncommon to notice "your predecessor's" intrusion traces while you break through systems, "plant flags", change screen backgrounds [for the admins to notice that you've been there...], etc.

Let's think what this situation really means? Here are the choices I see:

1. Nobody discovered the hole - a law of large  numbers (aka "dumb luck") have "shielded" the company from an incident. Yes, Virginia, dumb luck IS a security strategy for some companies... AND it works for them.
2. It was discovered, but not used/abused by the attacker - maybe he was busy hacking other systems, or saved this for later and never came back due to his ADD. Congratulation, you win! The immense power of dumb luck wrapped you in a protective "security" blanket ... again :-)
3. It was discovered; the attacker went in, looked around and compromised a few others systems, but found nothing of interest (no low hanging fruits)  - and he was not a bot herder. Again, you win. Next time you are in Vegas, bet on "00."
4. It was discovered; the attacker went in and deployed a bot on "your" system - given how many botnets are there, this situation is clearly acceptable to many organizations. In this case, dumb luck strategy, apparently, still work: so they use your box to spam and phish somebody else ... big deal!
5. It was discovered; the attacker went in and stole all your credit card information (it is now for sale) - even in this case, the user of "the dumb luck strategy" still "wins" (in some perverse sense)! Unless and until the stolen information IS tracked back to you OR a friendly neighborhood PCI auditor come and jams a broomstick up your ..., you can still continue to be stupid at your leisure and ignore basic security practices.
6. It was discovered; the attacker went in and stole your CEO's Inbox, including the email related to his affair (it is now on CNN) - now, in this case, you lose AND it is time to stop being stupid! Welcome to the "0wned world." Time to launch (relaunch?) your security program and get serious.

What does this teach us about RISK? The lesson here is important:

• For a security professional, an Internet-exposed system with "root/root" is an obvious HUGE risk!
• For your boss's boss's boss, it is NOT!

This is exactly why I think that the most critical problem in security today is METRICS. Metrics that a) work AND mean something to decision makers and b) can be clearly communicated to said decision makers [BTW, a) and b) are two separate problems.] Metrics that cover not only threats and vulnerabilities we face, but also the effectiveness of security countermeasures we deploy. Metrics you can act on - and ones your boss (and his boss) will act on. Metrics that lead to correct decisions about which risks to accept, which to  mitigate (all while knowing with what efficiency such mitigation occurs) and which to transfer.

Until that time, the dreaded "C-word" (compliance) will trump "the other C-word" (common sense) as a driver for security ... and we will continue to live in the "0wned world."

Possibly related posts:

• Risk vs Risk 

1. The Sun-Sentinel newspaper in Fort Lauderdale accidentally republishes a six-year-old news story about the bankruptcy of UAL. It wasn't on the home page, but instead buried somewhere inside the web site.
2. Google's news crawler (an automated thing, remember) finds the story and incorporates it as part of its news feed.
3. Investors see the story, and immediately react. When UAL's stock plunged 76% to a low of $3, Nasdaq shut down trading. Eventually trading resumed, and the stock closed at just under $11, losing about 11%.
4. United blamed Tribune Company (the owner of the Sun-Sentinel) for "irresponsibly" changing the date on the story and demanded a retraction.
5. Tribune Company blamed Google, claiming they've had issues with Google's crawler "for months."

Who will blame be shifted to next?

Look -- if people haven't realized by now that the Internet pretty much lacks a delete function, then (IMNSHO) it becomes the requirement of each and every one of us to pay close attention to what we're reading, to use our own big brains and fine-tuned bullshit detectors to suss out whether something makes sense.

Since this is my blog, I'm going to parcel out blame the way I see it:

• United: 0%. If the concept of "negative blame" made any sense, then I'd actually write −∞ (that's a negative infinity, in case your character set is different than mine).
• Google: 5%. How can an automated crawler know that a newly-dated story isn't really new? Well, those folks over there at Google are smart. Certainly it shouldn't be that difficult to compare a "new" article against existing ones. Content hashes won't work as a comparison tool, because the date would be included in the hash computation, thus making the hashes different anyway. Full-text comparisons? Sure, it would take a lot of horsepower. Perhaps not every "new" story needs comparison, but at least the crawler could submit to the comparator any stories that ought to be verified (say those with the word "bankruptcy" in them).
• Tribune Company: 30%. Hey guys, you changed the date on the article. Don't go blaming someone else for your screw-up.
• Investors: 65%. If you're using an automated news aggregator (remember, an aggregator is not a source of news) to make major financial decisions -- decisions that affect the livelihoods of thousands (maybe millions) of people -- well, you're a moron. You should know that incorrect information can be just as instantly available as correct information. Verify potentially damaging claims before engaging in reckless behavior.

What's this got to do with security? I don't know, maybe nothing directly related. But it certainly raises the question -- what if someone intentionally wanted to cause nearly permanent damage to a person or a corporation? Malicious content, disguised as "news," certainly seems to have become a potentially successful attack vector this week.

Worried about a social engineering attack on a massive scale? I suspect that what happened Monday (8 September) was the largest social engineering attack in history -- although I wouldn't classify it as intentionally malicious. Just you wait until the idea spreads.