P0wned! Don’t make the same mistake I did

I fell victim to an interesting attack, which I am recounting here so that others may avoid it.

In a nutshell, I fell victim to a trojan, which the malefactor was able to place in a trusted location in my search path. A wrapper obscured the malicious payload. Additionally, a second line of defense did not catch the substitution. I believe the attackers were not out to harm me, but that this trojan was put in place partially for lulz, and partially to allow a more-important attack on the systems RBAC mechanisms to succeed.

Attack Details

I was attempting to purchase a six pack of New Belgium Rampant IPA, shown immediately below.

IMG_2242.JPG

I obtained the six pack from the canonical location in the system – a reach-in refrigerator in the supermarket’s liquor aisle. I proceeded to the cashier, who rang up my purchase, bagged it, and accepted payment.

I realized upon arrival home, that this was a trojan six pack, as seen below:

IMG_2243.JPG

Clearly, the attacker to care to make his payload look legitimate. What I noticed later, was the subtle difference I zoom in on below

IMG_2245.JPG

:

IMG_2244.JPG

Yes, the attacker had substituted root beer for real beer.

Needless to say, this was a devious denial of service, which the perpetrators undoubtedly laughed about. However, this was likely not just “for the lulz”. I think this was the work of juvenile attackers, whose motives were to defeat the RBAC (real beer access control) system. Knowing that a purchase of real beer would be scrutinized closely, I believe they exfiltrated the target beer by hiding it in a root beer package.

Mitigations put in place by the system did not catch this error – the cashier/reference monitor allowed the purchase (and likely, the offsetting real beer as root beer purchase).

Possible Countermeasures

The keys to this attack were that the trojan was in the right place in the search path, and that it appeared legitimate. Obviously, this location must be readable by all, since items need to be fetched from it. However, allowing items to be placed in it by untrusted users is a definite risk. Technical constraints make the obvious countermeasure — allowing only privileged stocking, while permitting “world” fetching — presents serious usability concerns, and increases system cost, since the privileged stocker must be paid.

Nonetheless, such countermeasures are in place for certain other items, notably where the cost to the system — as opposed to the user — of an illicit item substitution is quite high.

Lessons learned

Ultimately, system usability and cost tradeoffs put the onus on the end-user. Before taking a non-idempotent step, inspect the objects closely!

On Bitcoin

There’s an absolutely fascinating interview with Adam Back: “Let’s Talk Bitcoin Adam Back interview.”

For those of you who don’t know Adam, he created Hashcash, which is at the core of Bitcoin proof of work.

Two elements I’d like to call attention to in particular are:
First, there’s an interesting contrast between Adam’s opinions and Glenn Flieshman’s opinions in “On the Matter of Why Bitcoin Matters.” In particular, Glenn seems to think that transaction dispute should be in the protocol, and Adam thinks it should be layered on in some way. (Near as I can tell, Glenn is a very smart journalist, but he’s not a protocol designer.)

Secondly, Adam discusses the ways in which a really smart fellow, deeply steeped in the underlying technologies, can fail to see how all the elements of Bitcoin happened to combine into a real ecash system. Like Adam, I was focused on properties other systems have and Bitcoin does not, and so was unexcited by it. There’s an interesting lesson in humility there for me.

This is also interesting “How the Bitcoin protocol works.”

Getting Ready for a Launch

I’m getting ready for to announce a new project that I’ve been working on for quite a while.

As I get ready, I was talking to friends in PR and marketing, and they were shocked and appalled that I don’t have a mailing list. It was a little like telling people in security that you don’t fuzz your code.

Now, I don’t know a lot about marketing, but I do know that look which implies table stakes. So I’ve set up a mailing list. I’ve cleverly named it “Adam Shostack’s New Thing.” It’ll be the first place to hear about the new things I’m creating — books, games or anything else.

People who sign up will be the first to hear my news.

[Update: Some people are asking why I don’t just use Twitter or blogs? I plan to, but there are people who’d like more concentrated news in their inbox. Cool. I can help them. And much as I love Twitter, it’s easy for a tweet to be lost, and easy to fall into the trap of retweeting yourself every hour to overcome that. That’s annoying to your followers who see you repeating yourself.]

Please vote for the social security blogger awards!

Alan Shimmy has the nominations for the 2014 Social Security bloggers award!

New School has been nominated for most entertaining, while Emergent Chaos has been nominated for best representing the security industry and the hall of fame.

Now, I have no idea what it means that Emergent Chaos would represent the security industry. I’m hopeful that it’s intended as a complement.

What’s Copyright, Doc?

I blogged yesterday about all the new works that have entered the public domain as their copyright expired in the United States. If you missed it, that’s because exactly nothing entered the public domain yesterday.

Read more — but only commentary, because there’s no newly free work — at “What Could Have Entered the Public Domain on January 1, 2014?

It’s near-impossible to see how our insanely long copyright terms, or their never-ending extensions encourage Dr. Seuss, Ayn Rand, Jack Kerouac or Ian Fleming to keep producing new work. Those authors have been richly rewarded for their work. But it’s easy to see how keeping those works under copyright reduces creative re-use of our collective cultural heritage.

What to do for randomness today?

In light of recent news, such as “FreeBSD washing Intel-chip randomness” and “alleged NSA-RSA scheming,” what advice should we give engineers who want to use randomness in their designs?


My advice for software engineers building things used to be to rely on the OS to get it right. That defers the problem to a small number of smart people. Is that still the right advice, despite recent news? The right advice is pretty clearly not that a normal software engineer building in Ruby on Rails or asp.net should go and roll their own. It also cannot be that they spend days wading through debates. Experts ought to be providing guidance on what to do.

Is the right thing to hash together the OS and something else? If so, precisely what something else?

What Price Privacy, Paying For Apps edition

There’s a new study on what people would pay for privacy in apps. As reported by Techflash:

A study by two University of Colorado Boulder economists, Scott Savage and Donald Waldman, found the average user would pay varying amounts for different kinds of privacy: $4.05 to conceal contact lists, $2.28 to keep their browser history private, $2.12 to eliminate advertising on apps, $1.19 to conceal personal locations, $1.75 to conceal the phone’s ID number and $3.58 to conceal the contents of text messages.

Those numbers seem small, but they’re in the context of app pricing, which is generally a few bucks. If those numbers combine linearly, people being willing to pay up to $10 more for a private version is a very high valuation. (Of course, the numbers will combine in ways that are not strictly rational. Consumers satisfice.

A quick skim of the article leads me to think that they didn’t estimate app maker benefit from these privacy changes. How much does a consumer contact list go for? (And how does that compare to the fines for improperly revealing it?) How much does an app maker make per person whose eyeballs they sell to show ads?

A Mini-Review of “The Practice of Network Security Monitoring”

NSM book coverRecently the kind folks at No Starch Press sent me a review copy of Rich Bejtlich’s newest book The Practice of Network Security Monitoring and I can’t recommend it enough. It is well worth reading from a theory perspective, but where it really shines is digging into the nuts and bolts of building an NSM program from the ground up. He has essentially built a full end to end tutorial on a broad variety of tools (especially Open Source ones) that will help with every aspect of the program, from collection to analysis to reporting.

As someone who used to own security monitoring and incident response for various organizations, the book was a great refresher on the why and wherefores of building an NSM program and it was really interesting to see how much the tools have evolved over the last 10 years or so since I was in the trenches with the bits and bytes. This is a great resource though regardless of your level of experience and will be a great reference work for years to come. Go read it…