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!

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…

A flame about flame

CNET ran a truly ridiculous article last week titled
“Flame can sabotage computers by deleting files, says Symantec”. And if that’s not goofy enough, the post opens with

The virus can not only steal data but disrupt computers by removing critical files, says a Symantec researcher.

ZOMG! A virus that deletes files! Now that is cutting edge technology! It’s shit articles like this that reifies the belief that the security industry in general and the AV industry in specific is filled with people who are completely out of touch with the rest of the world.

“These guys have the capability to delete everything on the computer,” Thakur said, according to Reuters. “This is not something that is theoretical. It is absolutely there.”

ProTip to Symantec and Reuters, viruses have been doing this since at least the 80s. Are you really that desperate for yet another story that this is the level that this is the sort of thing you feel is worthy of a press release and news article. How about you save that time and effort and instead focus on making a product that works better.

Shocking News of the Day: Social Security Numbers Suck

The firm’s annual Banking Identity Safety Scorecard looked at the consumer-security practices of 25 large banks and credit unions. It found that far too many still rely on customers’ Social Security numbers for authentication purposes — for instance, to verify a customer’s identity when he or she wants to speak to a bank representative over the telephone or re-set a password.

All banks in the report used some version of the Social Security number as a means of authenticating the customer, Javelin found. The pervasive use of Social Security numbers was surprising, given the importance of Social Security numbers as a tool for identity theft, said Phil Blank, managing director of security, risk and fraud at Javelin. (“Banks Rely Too Heavily On Social Security Numbers, Report Finds“, Ann Carrns, New York Times)

Previously here: “Social Security Numbers are Worthless as Authenticators” (2009), or “Bad advice on SSNs” (2005).

Emergent Chaos endorses Wim Remes for ISC(2) Board

Today, we are sticking our noses in a place about which we know fairly little: the ISC(2) elections. We’re endorsing a guy we don’t know, Wim Remes, to shake stuff up. Because, really, we ought to care about the biggest and oldest certification in security, but hey, we don’t. And really, that’s a bit of a problem. And it seems that Wim wants to make things better. And so we’re encouraging all four of our CISSP-holding readers to go vote for him, because we think that a whole lotta shaking going on would be, at worst, a not-bad thing.

How’s that for a heartfelt endorsement?

Ok, more seriously. ISC(2) offers up a certification in information security. There’s a big infosec community that doesn’t take that certification very seriously. That’s a problem that I’ve never had a motivation to try to solve, but Wim does, and I wish him the very best of luck. I think that that CISSP could do substantially better, and the first phase of that is to elect some outsiders to communicate a message that change is needed. What’s more, Wim is not a joke candidate, and he’s campaigned effectively for the role, getting lots of endorsements from people who are both worth listening to and who take this seriously enough that they wouldn’t open with a jokey lead.

And so Emergent Chaos is endorsing Wim, and hoping that some chaos and other worthwhile things start to emerge. You can read his statement on Jimmy Blake’s blog, and vote here.

Emergent Map: Streets of the US

This is really cool. All Streets is a map of the United States made of nothing but roads. A surprisingly accurate map of the country emerges from the chaos of our roads:

Allstreets poster

All Streets consists of 240 million individual road segments. No other features — no outlines, cities, or types of terrain — are marked, yet canyons and mountains emerge as the roads course around them, and sparser webs of road mark less populated areas. More details can be found here, with additional discussion of the previous version here.

In the discussion page, “Fry” writes:

The result is a map made of 240 million segments of road. It’s very difficult to say exactly how many individual streets are involved — since a winding road might consist of dozens or even hundreds of segments — but I’m sure there’s someone deep inside the Census Bureau who knows the exact number.

Which raises a fascinating question: is there a Platonic definition of “a road”? Is the question answerable in the sort of concrete way that I can say “there are 2 pens in my hand”? We tend to believe that things are countable, but as you try to count them in larger scales, the question of what is a discrete thing grows in importance. We see this when map software tells us to “continue on Foo Street.” Most drivers don’t care about such instructions; the road is the same road, insofar as you can drive in a straight line and be on what seems the same “stretch of pavement.” All that differs is the signs (if there are signs). There’s a story that when Bostonians named Washington Street after our first President, they changed the names of all the streets as they cross Washington Street, to draw attention to the great man. Are those different streets? They are likely different segments, but I think that for someone to know the number of streets in the US requires not an ontological analysis of the nature of street, but rather a purpose-driven one. Who needs to know how many individual streets are in the US? What would they do with that knowledge? Will they count gravel roads? What about new roads, under construction, or roads in the process of being torn up? This weekend of “carmageddeon” closing of 405 in LA, does 405 count as a road?

Only with these questions answered could someone answer the question of “how many streets are there?” People often steam-roller over such issues to get to answers when they need them, and that may be ok, depending on what details are flattened. Me, I’ll stick with “a great many,” since it is accurate enough for all my purposes.

So the takeaway for you? Well, there’s two. First, even with the seemingly most concrete of questions, definitions matter a lot. When someone gives you big numbers and the influence behavior, be sure to understand what they measured and how, and what decisions they made along the way. In information security, a great many people announce seemingly precise and often scary-sounding numbers that, on investigation, mean far different things than they seem to. (Or, more often, far less.)

And second, despite what I wrote above, it’s not the whole country that emerges. It’s the contiguous 48. Again, watch those definitions, especially for what’s not there.

Previously on Emergent Chaos: Steve Coast’s “Map of London” and “Map of Where Tourists Take Pictures.”

Is iTunes 10.3.1 a security update?

Dear Apple,

In the software update, you tell us that we should see http://support.apple.com/kb/HT1222 for the security content of this update:

Itunes10 3 1

However, on visiting http://support.apple.com/kb/HT1222, and searching for “10.3″, the phrase doesn’t appear. Does that imply that there’s no security content? Does it mean there is security content but you’re not telling us about it?

Really, I don’t feel like thinking about the latest terms of service today if I don’t have to. I’d prefer not to get your latest features which let you sell more and bundle in your latest ideas about what a music player ought to do. But I’m scared. And so I’d like to ask: Is there security content in iTunes 10.3.1?

Elevation of Privilege (Web Edition) Question

Someone wrote to me to ask:

A few cards are not straightforward to apply to a webapp situation (some seem assume a proprietary client) – do you recommend discarding them or perhaps you thought of a way to rephrase them somehow?

For example:

“An attacker can make a client unavailable or unusable but the problem goes away when the attacker stops”

I don’t have a great answer, but I’m thinking someone else might have taken it on.

For Denial of Service attacks in the Microsoft SDL bug bar, we roughly to break things down to a matrix of (server, client, persistent/temporary). That doesn’t seem right for web apps. Is there a better approach, and perhaps even one that can translate into some good threat cards?

AT&T, Voice Encryption and Trust

Yesterday, AT&T announced an Encrypted Mobile Voice. As CNet summarizes:

AT&T is using One Vault Voice to provide users with an application to control their security. The app integrates into a device’s address book and “standard operation” to give users the option to encrypt any call. AT&T said that when encryption is used, the call is protected from end to end.

AT&T Encrypted Mobile Voice is designed specifically for major companies, government agencies, and law enforcement organizations. An AT&T spokesperson said it is not available to consumers. The technology is available to users running BlackBerry devices or Windows Mobile smartphones, and it works in 190 countries.

Organizations interested in deploying Encrypted Mobile Voice will need to pay an additional fee to do so. AT&T said that cost depends on the size of the deployment. (“AT&T improves service security with encryption

Jake Appelbaum and Chris Soghoian expressed skepticism. (“From the company that brought you NSA wire tapping, they thought you’d also like….” and “If you trust AT&T’s new voice encryption service, you are a fool.“)

What’s funny (sad) about this is that there are a number of software encrypted voice systems available. They include RedPhone, CryptoPhone and zFone. Some of these even work on pocket sized computers with integrated radios. But Apple and AT&T won’t let you install alternate voice applications.

A lot of people claim that these restrictions on what you can do with your device just don’t matter very much. That you can really get everything you need. But here’s a clear example of why that isn’t so. Voice encryption is a special app that you have to get permission to run.

Now, maybe you don’t care. You’re “not doing anything wrong.” Well, Hoder wasn’t doing anything wrong when he went to Israel and blogged about it in Farsi. But he’s serving 20 years in jail in Iran.

Now is the time we should be building security in. Systems that prevent you from doing so, or systems that reset themselves to some manufacturer designated default are simply untrustworthy. We should demand better, more trustworthy products or build them ourselves.

[Added: I'd meant to include a comment about Adam Thierer's comment "The more interesting question here is how “closed” is the iPhone really?" I think the answer is, in part, here. There's a function, voice privacy, for which AT&T and three other companies think is marketable. And it doesn't exist on the iPhone OS, which is the 2nd most prevalent phone platform out there.]

[Update 2: Robert and Rob rob me of some of my argument by pointing out that AT&T now allows you to install voice apps, but none of the encrypted voice apps that I'd consider trustworthy are available. (I exlude Skype and their proprietary & secret designs from trustworthy; it's probably better than no crypto until you trust it, then it's probably not good enough to really protect you.) Maybe this is a result of the arbitrary rejections by the Apple app store, but when I look for zfone, redphone or cryptophone, I see a fast dial app and some games. When I search for crypto, it's all password managers. So while I'm no longer sure of the reason, the result remains. The iPhone is missing trustworthy voice crypto, despite the market.]

Use crypto. Not too confusing. Mostly asymmetric.

A little ways back, Gunnar Peterson said “passwords are like hamburgers, taste great but kill us in long run wean off password now or colonoscopy later.” I responded: “Use crypto. Not too confusing. Mostly asymmetric.” I’d like to expand on that a little. Not quite so much as Michael Pollan, but a little.

The first sentence, “use crypto” is a simple one. It means more security requires getting away from sending strings as a way to authenticate people at a distance. This applies (obviously) to passwords, but also to SSNs, mother’s “maiden” names, your first car, and will apply to biometrics. Sending a string which represents an image of a fingerprint is no harder to fake than sending a password. Stronger authenticators will need to involve an algorithm and a key.

The second, “not too confusing” is a little more subtle, because there are layers of confusing. There’s developer confusion as the system is implemented, adding pieces, like captchas, without a threat model. There’s user confusion as to what program popped that demand for credentials, what site they’re connecting to, or what password they’re supposed to use. There’s also confusion about what makes a good password when one site demands no fewer than 10 characters and another insists on no more. But regardless, it’s essential that a a strong authentication system be understood by at least 99% of its users, and that the authentication is either mutual or resistant to replay, reflection and man-in-the-middle attacks. In this, “TOFU” is better than PKI. I prefer to call TOFO “persistence” or “key persistence” This is in keeping with Pollan’s belief that things with names are better than things with acronyms.

Finally, “mostly asymmetric.” There are three main building blocks in crypto. They are one way functions, symmetric and asymmetric ciphers. Asymmetric systems are those with two mathematically related keys, only one of which is kept secret. These are better because forgery attacks are harder; because only one party holds a given key. (Systems that use one way functions can also deliver this property.) There are a few reasons to avoid asymmetric ciphers, mostly having to do with the compute capabilities of really small devices like a smartcard or very power limited devices like pacemakers.

So there you have it: Use crypto. Not too confusing. Mostly asymmetric.