BayThreat 2011: Sharpening the Axe

I will be presenting “Sharpening the Axe – How to Chop Down a Cloud” at BayThreat 2011

…the 2nd annual information security conference in the South Bay at The Hacker Dojo, December 9th, 10th & 11th.

My title is in reference to President Abraham Lincoln who was said to have once quipped:

If I had eight hours to chop down a tree, I’d spend six hours sharpening my axe.

The runner-up quote from Lincoln was

If this is coffee, please bring me some tea; but if this is tea, please bring me some coffee

…but I couldn’t figure out how to make it into a full presentation, let alone a title. Perhaps “if this is cloud, please bring me on-premise; but if this is on-premise, please bring me cloud”?

The axe title works fine, though, and also is in reference to Theseus’ paradox, sometimes known as the Ship of Theseus or my grandfather’s axe, which seems appropriate given this year’s badge.

At BayThreat this year, we’re giving attendees circuit board badges. These badges are plain boards to start, but on Sunday we will have a soldering workshop where everyone can work on their badges. We will have kits available for the badge.

The presentation is based on some of the material you will find in my new book soon to be published by Wiley on security in virtual environments. Hope to see you there.

BayThreat

Facebook FAIL: ID mixup leads to lawsuit

An established German company named Merck in the 1880s sent one of its chemists to New York to import drugs to the American market and capitalize on the fast-growing economy. Things went so well that just ten years later they began to look for ways to avoid high import tariffs and manufacture drugs in America; by 1900 they expanded operations into the remote and open space of New Jersey.

The company then was caught up in the divisiveness of WWI. German companies on U.S. soil, including Merck, were confiscated and auctioned to American owners. German Merck became a completely separate and distinct entity from Merck operations in America due to the terms of reconciliation and the Treaty of Versailles in 1918. After the forced split the American company eventually grew to be much larger than the German Merck.

Fastforward to today’s news. Facebook staff made the extremely awkward, if not completely ignorant, decision to hand the American Merck control over a page setup by the German Merck.

Facebook Inc said on Monday that it made a mistake in letting Merck & Co take over a page on the social networking website from its German rival Merck KGaA.

The takeover prompted an unusual November 21 filing by Merck KGaA with a New York state court.

In it, Merck KGaA sought to force Facebook to explain how it lost the page, www.facebook.com/merck, and the ability to administer it to Merck & Co, a separate company.

[…]

“The transfer of the vanity URL Facebook.com/Merck from Merck KGaA to Merck & Co was due to an administrative error,” Facebook said in a statement. “We apologize for any inconvenience this may have caused.”

This issue of impersonation is one of the most difficult problems in identity management, to be fair. How many John Smiths are there on Facebook and what can Facebook really depend upon to distinguish them as unique users? I mean which Budweiser brewer is the real one?

More to the point, how can a provider tell husband access from wife, or parent from child? The courts are usually the best answer. If a divorce court rules that a wife gets the shared Facebook account, then Facebook will have some justification to act.

This case is odd because Facebook apparently made a decision without authority to favor the American company over the German one.

Users need assurance that a company like Facebook, entrusted with sensitive data, can handle this kind of situation without making an historic blunder. Merck is lucky to have the legal team and resources to file a formal complaint but it begs the question how many similar mistakes are being made at a lower profile. It also begs whether Facebook staff do even the most basic review or follow a transparent and monitored process before taking action.

DB dump rescues lost dog

Matt forwarded me this sweet story today about dumping databases when faced with an unsuitable user interface.

The authors call it “Finding a lost dog’s owner with Perl and WWW::Mechanize” because that’s the meat of their story.

It starts with a lost dog and a programmer. The programmer finds an online database of dog registrations. Unfortunately the programmer isn’t sure how to find the license number, which is needed to look up the dog owner. So he proceeds to write a perl script to automate queries and dump the entire database.

I ran wireshark captures of both a manual post in Chrome and my test script. Comparison of the captures revealed that the submit button name/value was not being sent by my script. Looking at the WWW::Mechanize docs, I found the button parameter to the submit_form() method for simulating a submit button click. It worked. I finished the script, looping over all 24996 records and soon I was pulling down all the Warren County dog registration records for 2011.

Now that he has all the information on his local system, he searches for the parameters that are more obvious to him.

After that, it was some simple calls to grep to filter the results:

cat warren_county_dogs.txt | \
grep -i springboro | \
grep -i lab | \
grep -i brown | \
grep -i female \
> brown_labs.txt

This narrowed down the 25,000 records to 39. That made it easily to visually scan the list and find the addresses that were closest to where the dog was found. That narrowed it down to three. Adam Googled the phone numbers, found that one was a cell, and texted it.

The programmer could have built a way to narrow down a license number query using the existing interface. Or he could have built an interface to query the site on his filter parameters (e.g. color, sex). Both would have left the data on the server. Instead he pounded the database to dump all its information for 2011; lucky for him (and unlucky for 24,999 other dog owners) they did not notice or block his automated queries. The only thing more questionable would have been if this story tried to justify a SQL injection to dump databases and rescue a lost dog.

This reminds me of a joke I heard many years ago. Two guys are angry that they can’t tell their horses apart. So one notches his horse’s tail. Then the other horse gets its tail caught in a fence and the notches are the same. So the other one clips his horses ear. Then the other horse gets into a patch of woods and clips its ear in the same spot. Finally the two men realize one horse might be slightly larger than the other. They measure and discover the white horse is a whole hand taller than the black horse.

If only the dog owner database had allowed a more useful query to begin with…

Case Study: Virtualization and PCI Compliance

Southwest Airlines is featured in a new video, which mentions PCI DSS compliance in virtual environments using VMware Configuration Manager (VCM).

I noticed this comment on efficiency at the start:

The airline industry is a very tough industry. Airlines weren’t built to run on 130 dollar barrel of fuel.

And then I noticed people in the data center wearing shorts. Shorts? PCI DSS obviously does not include a dress code or say anything about hardware MTBF.

Must be awful hot in those racks…or maybe Southwest also has found efficiencies in cooling.