Archive for September, 2014

ShellShock: the big security scare over nothing

Monday, September 29th, 2014

The security advisory business must be getting desperate.

Evidence: this latest Shell Shock bug. Security vendors and the media are making it out to be a serious threat to every organization. Organizations are in a panic, asking every software and services vendor to confirm that their solutions are either unaffected or patched.

Lets break down this bug, shall we?

  • Bash is a command shell. It is the Unix/Linux equivalent to cmd.exe
    on Windows.
  • There is a bug in Bash – it has likely been there for years. With
    this bug, the contents of an environment variable are executed, though
    they should not be.

As a user, I use Bash daily. With this exploit, I can get Bash to run programs as me. Hmm. I do that anyways. Not much of an exploit. I can’t gain new privileges – just cause it to do stuff that it would do anyways.

So what’s the problem? Well, what if I can get another program, which normally does run bash, to run it with my commands. OK, that’s more interesting. It would then get that other program to run things on my behalf – a legitimate exploit.

But what programs run bash?

Mostly sshd. SSH is the program I use to connect to another computer on the network. Usually, I sign into sshd with my own account (ID/password or public/private key). The ssh daemon (sshd) then runs bash and lets me type commands to run on the remote computer. Great. With this Bash bug I can … get bash to do illicitly what it already does for me. So what? So nothing.

What else? Well, in rather unusual circumstances, you can configure sshd to run just a few, limited commands on behalf of many people. For example, I might setup an account on a firewall called ‘monitor’, set a password on the account, configure it to only show firewall log records and nothing else, and share that account with many people. In this context, people who do have legitimate access to the ‘monitor’ account would be able to break out of the ‘command jail’ and run more commands on the firewall. This is an actual vulnerability, but not a major one — after all, ‘monitor’ is likely not all that privileged an account, and these are people I gave a password to in the first place, so hopefully they won’t do anything naughty.

The big fear is that there are web exploits. The idea here is that someone writes a web application in Bash. Now that’s just bizarre – using a command shell to provide content to a web site. In this case, anyone who can connect to the web site could cause the command shell to run arbitrary commands. Again, these commands would run as the web server’s designated user ID (usually a very unprivileged account), but in this case, a more serious exploit, because the set of possible attackers is large and they could come from anywhere. OK – now we’re talking about a real security problem, but wait – who writes web applications in Bash anyways? It turns out, almost nobody. It’s just not the right tool for the job. That’s like asking: “who hammers nails with a screw driver?” I’m sure it happens, not it’s not exactly easy to do and is therefore unusual.

Bottom line: this ‘Shell Shock’ security bug is a legitimate security bug, but with near-zero impact in the wild.

So why all the panic?

It must have been a slow news week last week.

Advanced search in an IAM system: a privacy threat

Monday, September 15th, 2014

XKCD posted an amusing comic about the intersection of SQL and data privacy a while ago, here –

This is interesting in that it highlights the threat to privacy by an innocuous seeming search feature. Never mind the SQL syntax in the comic – imagine that you can search for users whose ‘scheduled term date’ is in the next 30 days, or whose ‘most recent performance review’ was a low grade. Even if the IAM system refuses to show you the values of those fields, the presence or absence of a user in a search result set would compromise privacy and possibly corporate security.

What to do?

You have two options:

  • Eliminate search on sensitive attributes entirely; or
  • Ensure that the IAM system filters out search results which were included on the basis of the values of sensitive attributes.

I imagine that most IAM products and deployments out there opt for the former. You can’t search on ‘scheduled term date’ and the like. That’s fine – it’s safe, I guess, but it’s also extremely limiting. What if, as a manager, I want to run that query and see which of my subordinates, some of which are contractors, are about to reach the end of their work term? I might then wish to request extensions for some of them, because their projects are still active. Alternately, I might request to turn some contractors into employees.

In other words, simply refusing to search on these things is not a satisfactory solution – it leaves out too much useful functionality.

That brings us to the second option — build a search engine smart enough to figure that a given record should not be included in the result set because this particular requester should not be able to see the sensitive attribute value for this particular user. That’s hard, but creates much more value for the end user.

This is the approach we opted for at Hitachi ID. Hopefully our customers like it. 😉

My CC was hacked – but where?

Thursday, September 4th, 2014

We recently got a call from the bank, asking to verify that a series of transactions were valid. As it turned out, nothing was amiss and no action (e.g., new CC) had to be taken.

But this kind of call gets you thinking: why did the bank call? Presumably because there was a bulk compromise of some or all transactions at some retailer that the bank deals with. Recent news releases (Target, Home Depot, etc.) make this seem likely.

As a consumer, I really want to know. Which vendor got hacked? At all locations or just one (physical or virtual) retail outlet? I want to know because, frankly, I might be more careful doing business with that retailer or outlet in the future.

The banks don’t release this information today. There is a hack, they know about it, but they don’t tell me who was hacked, or when, or where? This is presumably because they don’t want to anger (embarass?) their merchant customer. I get that, but I’m their customer too, and so are millions of other consumers. I think the banks should disclose what they know to the consumers, as this will reduce the total cost of the impact of the hack. It will also provide a much stronger incentive to merchants to lock things down, and over time may reduce the cost of attacks.

At the end of the day, the bank did nothing wrong, the merchant had an error of omission, not commission (inadequate protection) and the consumer did nothing wrong. Can’t we just all be open and transparent about the event, to help work together to keep out the bad guys?

Another day, another hack

Tuesday, September 2nd, 2014

This time, it’s the “Fappening” – titillating name, that. A bunch of young starlets had compromising photos lifted from their iCloud accounts and posted online.

Apple claims innocence, and they are likely telling the truth. Why would only a few dozens (or hundreds? thousands?) of iCloud accounts have been hacked? That’s not consistent with a systemic security failure at Apple.

So how did these “hackers” get in? Likely they found a stash of e-mail addresses and passwords from some other breach, on-line somewhere. There have been plenty of large scale breaches in the past year or two. They would then have looked for persons of interest in the stash of IDs/passwords and, having found some, tried some of these same login credentials on the Apple site.

Simple enough – no technical skills required – just persistence.

Are there lessons to be learned here? Sure!

  • If your account on one system has been hacked, change your passwords everywhere, not just on that one site.
  • Heck, change all your passwords once in a while, on the theory that some of them may have been hacked and you were not notified.
  • Keep different passwords on different systems, or at least on systems that have different security profiles, both in terms of how securely you suspect they are managed and in terms of how much you would care if they were compromised. Don’t use the same password on Facebook and your bank, for example.
  • Don’t store sensitive, personal data in plaintext on systems or media you don’t physically control. Putting nude pictures of yourself on the cloud? Not so smart.

Mind you, nobody ever seems to learn. I’m sure this sort of thing will happen again, soon.