Archive for 2014

Zero days and cyber-warfare

Thursday, December 18th, 2014

The ongoing saga of the Sony hack is quite interesting. Some notable developments:

  • It is quite clear that the attack on Sony was at least ordered and funded by a state actor (North Korea). They may have hired out the actual work to a criminal gang (in case they did not have adequate domestic talent to carry this off) but they certainly are behind it.
  • Sony has decided to pull the release of their movie about assasination of North Korea’s dictator. In effect, the aggressor in this case has won, the victim has capitulated. This is really unprecedented.
  • If you define cyber-warfare as aggressive action by a nation state, causing economic or physical harm, through disruption of digital systems, then this is clearly cyber-war. The only comparable case I can think of is the Stuxnet worm used by Americans and Israelis to disrupt Iranian centrifuges.

So how did the attack succeed so spectacularly? Presumably there was some combination of zero-day vulnerabilities and perhaps spear-phishing attacks against Sony’s network and people. This would get the attacker into the Sony network, but not compromise the entire house of cards.

From there, one assumes some combination of packet sniffing, DNS spoofing and/or keylogging was used to allow the attackers to expand their scope of influence. This is where a privileged access management system would have come in handy – to slow down the advance of the hackers. At the same time, there appears to have been a total failure to detect the ongoing attack. A SIEM system would presumably have helped to detect that something was amiss, as would a Data Loss Prevention (DLP) system.

Why all of these systems either were not in place to protect Sony, or did not function, is anybody’s guess. If nothing else, this incident should be a wake-up call to other organizations, reminding them that:

  • You are a target, whether you like it or not.
  • Zero day exploits and spearphishing attacks can be used to get inside your perimeter. Only an air gap will keep your perimeter 100% secure, and that’s not compatible with an ongonig business.
  • Security infrastructure, including patch management, perimeter defense, privileged access management, SIEM and DLP is not an option. You need all these components, and vigilance, to mitigate the risk inherent in attackers getting into your network.

Stay safe everyone!

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.

Do you still limit daily password changes?

Wednesday, July 30th, 2014

Once upon a time, password history enforcement used code that stored hashes of the “last N” passwords for each user.  N was typically a small integer – often less than 10.  Some users would figure out what N was and, when the time came to change their password, made N+1 password changes, where the last password reverted to their original password.

Such users are both smart and stupid.  Smart, because they figured out how the underlying security system worked and how to circumvent it.  Stupid, because they opted for static passwords and thus weakened the security of their own accounts.

Some organizations figured out that they had users using the “N+1 trick,” and found a low-tech way to make it painful for the offending users.  They limited the number of times a user could change his own password in the course of a single day, typically to just 1.  A user who wanted to use the “N+1 trick” would be obliged to do so over N+1 days, which pretty much eliminated the attractiveness of the scheme.

Unfortunately, limiting the number of password changes per day is unfriendly to users.  Say I change my password, then decide that the new password is not so nice after all, and want to change it again, to a better value?  What about if I change my password, forget it and need to reset it.  These are legitimate use cases and users should be able to change their password as often as needed.

Fast forward to the present, where N can either be very large (say 100) or simply open-ended (Password Manager supports  this).  In either case, we get the same benefit of the old “max once daily” rule, but without annoying users who just want to change their password again.

In this context, “max once daily” loses any conceivable benefit. There is no security advantage to preventing an authenticated user from changing his own password as often as he likes.  There is no benefit in the sense of stronger measures against password reuse, if the password history data is large or open ended.  There is only down-side.

I raise this because we still, occasionally, meet organizations that insist on enforcing this rule.  Get over it – open ended history is a better solution.  This rule should be abandoned to a curiosity of history, removed from enforced password security policies.  Use a product like Password Manager to enforce open-ended history or just set N to a large number.

Default passwords strike again!

Wednesday, June 11th, 2014

Amusing article in the
Winnipeg Sun. A couple of “computer whiz” grade 9 kids used a search engine to find an operators manual for the ATM at their local grocery store. In the manual, there are instructions for signing into the ATM as an admin, along with a default password.

Lo and behold, the BMO bank machine still used the default admin password, so the kids got it. Now these are nice kids, so they visited the local branch, explained the problem and made sure that the problem was fixed. No harm done, and instead rather a good deed.

What’s interesting here is that in this day and age, a *bank* was so lax about security as to leave a *cash machine*, which is protected by exactly *zero* physical security and is installed in a public place, with a *default administrator password*.

I can’t think of a more clear cut use case for deploying a Privileged Access Management solution. This password should have been a long, pseudo-random, daily string — not a factory default.

eBay compromise – the largest incident yet?

Thursday, May 22nd, 2014

It seems that compromised password databases are getting bigger and bigger.

The latest one is a report that 145 million user account records (i.e., username, hashed password, some profile information such as date of birth) were exfiltrated from eBay.

(Gotta love that word … exfiltrated.)

I don’t know what attack vector was used to compromise this data, other than that the attack was carried out from inside the eBay corporate network, so discussing that will have to wait for another day.

As the scale of these incidents gets larger, new problems arise. For example, eBay (the corporation) has reacted very responsibly here – disclosing what they know and advising users to change their passwords. Users are getting used to these kinds of incidents and are trying to change their passwords. So far, so good.

But there are 145,000,000 users trying to change their passwords, more or less all at the same time. The eBay web site clearly cannot keep up. I tried to change my password, but failed:

  • First, it was hard to find the password change screen (but I did find it in the end…)
  • Once I found it, I learned that the eBay site requires confirmation that it’s a legitimate user (me) making the password change, by sending a code to my personal e-mail or phone.
  • But … the system is under such high load that I never got the confirmation e-mail. I tried asking for a text message but the site just refused, complaining about load.
  • What about users who registered an e-mail account with eBay years ago, and no longer have that account? I suppose they cannot change their password – at least not without human assistance, which also won’t scale to 145,000,000 accounts…

In short, at this scale, remediation is a problem. Maybe I’ll try to change my password tonight or tomorrow. Hopefully the storm of password changes will have slowed down by then.

What about users that employ the same password on multiple web sites (i.e., almost everybody)? This incident implies that 100,000,000 or more users are now trying to change their passwords on facebook, reddit, flickr, google,, etc. I bet those sites are slammed too, and perhaps also unable to respond.

All this sounds like a strong argument for federating identity and authentication — but federating to a few large providers (like Google or Microsoft) will concentrate risk. Imagine if Google or Microsoft get compromised, and everybody was using those platforms as federated identity/authentication providers for web sites such as eBay. That would be even worse than the current eBay incident! Moreover, federation creates linkages between accounts on different services, so has the (unintended) effect of diluting privacy.

Ultimately, I think federating to a large number of small providers would be best, because compromise of any one provider would have only modest impact. Unfortunately, we are still very far from such an architecture.

Another day, another rogue admin

Wednesday, May 21st, 2014

Some people never learn, I guess.

This guy: (link to IT World article) will spend some quality time in jail for sabotaging work systems before he learned about his own imminent termination.

Getting fired sucks. Going to jail for these shenanigans is definitely worse.

Clearly, a privileged access management system could have mitigated the harm.

Real security: the new SOX

Monday, May 5th, 2014

In the past few years, the looming threat of non-compliance with Sarbanes-Oxley (SOX) has driven much spending on IT security. This, despite that the “security” bits in the SOX legislation are laughably vague. In section 404 of the SOX legislation, there are requirements for public-listed companies to implement, assess and certify the quality of the internal controls that impact financial systems and data. That’s about it. Weak.

Despite being totally ambiguous, fear of SOX non-compliance has led corporations to spend billions on IT security. I imagine much of that money was spent on useless technology and process – things that *look* like they work, but may not actually be effective.

That was then. This is now.

I just read that the CEO of Target was removed, in large part because of the huge security incident they had, with tens of millions of credit card records compromised. Now that’s a serious threat, with a material impact on the corporation, both in terms of liability (to the card companies) and brand (shoppers going elsewhere because they are afraid of the nuisance of identity theft). It seems that the impact on management is actually more serious than SOX. I can’t recall any CEO of a major corporation being terminated before, due to an IT security breach. But now we have one, and I bet all the other CEOs will take note.

It will be interesting if the response to this will be any different than it had been to SOX. i.e., if the focus this time will be on actual security, rather than merely passing audits.

Of course, we have a vested stake in this game. Organizations seeking real security need to worry about all kinds of things — control over privileged accounts, prompt/reliable/complete access deactivation when users leave, assigning needs-appropriate access rights, strong user passwords and much more. We make software that addresses these problems.