Viruses, iOS, and Apple

About twenty years ago I used to do a presentation, based upon an early paper, in which I identified four conditions necessary and sufficient for the successful spread of a computer virus.
" A population of similar systems, capable of executing and replicating the virus;
" Sharing of vectors to carry the virus across the population;
" A way for the virus to replicate, i.e., to get itself executed, and
" And storage to hold the copy.
By restricting any one of these things, we could resist the spread of a virus. Of course, these things are all otherwise desirable. There is resistance to restricting them.

In the early nineties I attended a meeting at IBM Research. Fred Cohen, the godfather of all viruses, gave a presentation in which he observed that, in a world of application-only computers, we might still enjoy most, but not all, of the advantages of the modern computer.

I thought about this for a while. This was a way of looking at the third condition, the ability of the virus to get itself executed. The Windows operating system had a dozen ways for a program to be executed automatically. Even if we restricted all of these, the virus might still get itself executed by duping the user into "clicking on it."

We have had application-only computers for a long time. My favorite example is the ATM, the automated teller machine. I also like the arcade machines like Pac-Man.

One thing that distinguishes the application-only machine from the general purpose computer is programmability. The virus exploits the ability of the user to execute an arbitrary program of his own choice or even writing. After listening to Fred, I concluded that even if we could stamp out programming, it is so valuable that some SOB would just re-invent it.

Then, along came Apple with the iPhone and what we now know as iOS. At first Apple said "no user programs." Of course, they did not say that explicitly, They just did not provide any capability for creating one, importing it, or executing it. It did not offer an application programming interface, API, or a software development kit, SDK. Voila, an application-only virus-resistant computer.

Only a few geeks understood. Apple was offering a closed system while the geeks preferred, not to say demanded, open. Most of us did not realize that we were buying a "crippled" computer; we thought that we were buying a "smart" phone.

Gradually Apple has rehabilitated iOS. They have provided an API and SDK, both carefully crafted to maintain security. Applications run in an isolated compartment that Apple calls a "sandbox." Each application looks like an application machine to the user and hides the operating system, file system, and network from the user.

However, all four of the necessary conditions for the success of a virus are still restricted in some way or another. iPhones and iPads can be viewed as application-only computers.

Just as Fred Cohen promised, the tens of millions of users of iOS enjoy most, but not all, of the advantages of the general purpose computer. On the other hand, just as Fred predicted, they are pretty much virus free.

On the other hand, I was right too. The geeks are still trying to liberate, to "jailbreak," iOS, to restore to it all of the generality, flexibility, and capability, that Apple has "arbitrarily" denied to them, along with the inherent vulnerability from which Apple has protected them.

On July 15 Apple released an update to iOS, Version 4.3.4, to close a vulnerability exploited by the jail-breakers, one that could have been exploited by others. German authorities assert that this vulnerability had, in some form or another, existed for four years. Less than 12 hours later, a new jail-break was available. On July 5, 2011 Apple released Version 4.3.5 with a fix for that and 3 other vulnerabilities in other parsers

So far, Apple has patched the PDF parser half a dozen times. Each time the geeks have found another vulnerability. We call this strategy of late vulnerability detection and patching, the Microsoft strategy. It is likely to be about as successful for Apple as it has been for Microsoft.

All that is necessary to use this vulnerability to jail-break is to click on a crafted PDF on a web-page. How can it be that easy? It exploits an implementation-induced vulnerability, an unchecked input in the pdf parser within the Safari browser. While the jail-break PDF is overt, chosen by the user, and only Apple considers it malicious, the same vulnerability could be used to make more covert and malicious changes to an iOS device.

As we have noted here before, checking inputs is difficult. It is particularly difficult for a browser, where most inputs are legal and illegal ones difficult to enumerate. Therefore including a browser, Safari, in the operating system is inherently dangerous. Trying to parse PDFs in the OS is insane.

We have talked here before about how difficult it is to check inputs in modern systems. That is why we recommend the use of the OWASP Enterprise Security API Library for web servers. No such library exists for browsers or PDF parsers. Parsing PDF input appears to be so difficult that even adobe must issue frequent, not to say weekly, patches.

Eventually Apple is going to have to resort to a more fundamental strategy, like removing Safari from the OS. In the meantime, there are six alternative browsers for iOS. Unlike Safari, they all run as applications. Using one of these, running in its sandbox, a user could parse a rogue PDF safely.

Users who like the relatively sanitary environment of their idevices should care about a fundamental fix. Enterprises should care. Android is too open to ever be trusted. RIMM is struggling just to stay in business. On July 24, 2011 they laid off ten percent of their workforce.

The geeks will whine and complain about any fundamental fix. Steve will tell them that if they want an open system to buy a Mac, hell, even buy an Android. iOS is about as open as it is going to get. I am glad that there are more open alternatives to iOS but not nearly so glad as I am that iOS is closed.

So far this vulnerability has been used by geeks to jail-break. While it might have been used in a few narrowly targeted attacks, it has not been exploited by rogue hackers for widespread attacks.. It is a vulnerability without a threat, not a risk, not a problem. So far.

Until Apple does something more effective than patch, professionals that rely upon iOS to protect the applications and data of their principals must be on the alert for any emergent threat. While we are not happy about it, that is why we are called professionals and are paid the big bucks.

Phone Hacking?

Hey, guys! It's not "phone" hacking. It is "voice-mail" hacking."

How many, besides me, have been hooked this weekend by a headline about "phone hacking" only to say, "Oh, that's what they mean. That's not what I thought they were talking about." I am still doing it. I have done it twice since I got up. Even when I understand that they are simply talking voice-mail, my brain wants to interpret "hacking" as some sophisticated access to the mailbox from the computer side. This does not even involve brute force attacks against the password from the public switched telephone network.

Now you say that I only make this mistake because I am a geek. Perhaps. On the other hand, the average consumer of news may have even less of an idea what the term "phone hacking" means, much less what they ought to do about it. Parsing the words ought to get them closer to an understanding instead of further away.

The popular press does not serve us well when they do this. What language will they use when someone really hacks a phone, like "remote code execution," over the network?

We owe it to the innocent public to identify these attacks in a manner that informs them as to how to address the vulnerability.

"There is no such corrupting lie as a problem poorly named." Using the wrong words to describe something is counter-productive, not to say, destructive. Take, for example, calling cross-site scripting and buffer over-flows "vulnerabilities" rather than "attacks." The real vulnerability is "unchecked inputs." Perhaps one reason that these vulnerabilities are not only persistent, but growing, is that by naming them wrong we obscure the remedy.

Note that the voice-mail boxes are not being hacked via the application programming interface, API, but via the user interface, the UI. Our colleague, Brian Honan, reports from across the pond, that most of these "hacks" are simply using either the default password, or an easily guessed password. Can you say 1111?

We need to describe the vulnerability in a way that helps people protect themselves. I do not use 0416 because that is my birthday. I do not use your birthday either. I do not use any date because a "dictionary" of four digit passwords is going to contain those 365 numbers and will try them right after 1111, 2222,......1234, etc.

I do not do this because I think that a four-digit password is too short; for most people it is probably just fine. However, there are only ten thousand numbers in a four digit-lock-code; on average 5000 (automated) trials should be sufficient to find yours. For most of us, that is probably adequate. It helps if your carrier limits the number of trial.

For celebrities, four digits may not be adequate. As recent events demonstrate, any of us might become a celebrity at any time. Some of us may not want to use standard voice mail and some of us should not. There are viable alternatives.

While I an not a celebrity, I do not use my phone company voice mailbox at all. All of my phone numbers are forwarded to Skype-in. Access to that voice mail box requires a Skype client, my e-mail address, and my 9 character Skype password. Blackberry users can use longer lock-codes chosen from the full character set of the alpha-numeric keyboard. Longer lock-codes do not raise our work factor very much but they raise the cost of attack dramatically.

Four thousand victims of News of the World is a problem, a few of the victims even tragic. There are probably three or four times that many victims of less organized attacks. Good practice can eliminate a large percentage of these. For the rest, there are alternatives. However, the problem is likely to persist until we name and describe the problem in a constructive manner.

FFIEC Authentication Guidance

The Federal Financial Institution Examination Council, the FFIEC, has finally passed its long-awaited "new" Authentication Guidance. It was hoped that this guidance would address the account take-over attacks that have resulted in both losses to, and disputes between, the banks and their customers. Those security professionals that had hoped that the guidance would address the credential re-play that is at the heart of this problem can only be disappointed. Indeed, almost everyone is disappointed with the exception of the banks and the regulators themselves.

The language is someplace between "wishy-washy" and largely "content free." For example, it says that "institutions should use effective methods to authenticate the identity of customers and that the techniques employed should be commensurate with the risks associated with the products and services offered and the protection of sensitive customer information."

On the other hand, it is silent on the relative effectiveness of measures and makes no recommendation among them.

It dismisses token-based strong-authentication on the basis that it might be vulnerable to man-in-the-middle attacks. While that may be true, we are not seeing any such attacks. On the other hand it is resistant to the re-play attacks that we are seeing.

The Guidance suggests that we need better questions in challenge-response systems. Of course, the problem is not the resistance of the questions to guessing but how many questions there are and how quickly they leak to a key-logger. Again, it is as if the authors do not really understand the attacks.

If there is anything in the Guidance that I agree with, it is the idea of layered security. The idea is that we should not rely exclusively on the authentication, regardless of how good we think that it is. We should have policy, application controls, monitoring, timely confirmations and reconciliation, Patco and Experi-Metals both could have been a lot worse without these controls. That said, these controls mitigate the fundamental problem of credential re-play, they do not compensate for it. Moreover, the document is labeled "Authentication Guidance;" we have a right to expect that it will speak to that.

Part of the problem is that the agencies do not want to preempt the responsibility of bank management. Thus, they emphasize "risk management." They even acknowledge that the risk has changed since they published their original guidance. Banks have the fundamental responsibility to protect the customer.

Part of the problem is that the FFIEC is made up of the five Federal agencies, Office of the Comptroller of the Currency (OCC), the Federal Deposit Insurance Corporation (FDIC), The Federal Reserve Bank (FRB), The National Credit Union Administration (NCUA), and the new, Consumer Financial Protection Bureau. Each has different constituents and interests. The purpose of the council is to promote uniformity in regulation and limit institutional shopping among the regulators. Perhaps it is a little much to expect that five government agencies would ever arrive at strong guidance on anything.

However, the result is to set the bar at the lowest of all the agencies. As one of the authors put it, "The Guidance provided minimum (emphasis mine) supervisory expectations for effective authentication controls applicable to high-risk online transactions involving access to customer information or the movement of funds to other parties."

As I read the Guidance and the commentary on it, I kept coming back to the same question: "What part of 're-play' do they not understand?" Finally I scanned the document. The word does not appear. They do not understand any of it.

When they are criticized for not addressing re-play, their response is, "placing so much emphasis on what's 'missing' from the guidance detracts from regulators' intent." Perhaps. Perhaps they simply do not get it. Perhaps it is not even their job. Perhaps we expect too much of them. Perhaps it is our job.

Our job is not to debate whether or not guidance from the regulators is correct or complete. In fact, we have known since shortly after Sarbanes-Oxley that "security by compliance" encourages minimalist, not to say weak, security. No bank is going to have to change what it is doing to meet this "new" Guidance. Hopefully they will meet the requirement in spite of the Guidance, if not because of it. The Guidance sets a low bar but does not forbid high clearance.

Indeed, our job, without regard to the guidance, is to keep our principals out of the debate and to be sure that bad regulatory guidance is not used to justify weak security.

The good news is that we did not really need the Guidance to tell us what to do and now we can stop waiting for its magic. The bad news is that some management might decide to use it to justify continuing whatever they are already doing. It is our job to see that our principals do the right thing, whatever the Guidance says. It is for that that we are called professionals and are paid the big bucks.

Business as Usual........

......no longer cuts it.

The cost of attack against targets of choice has fallen close to that of targets of opportunity. Patience helps and may even be necessary but not much work or access is required; the necessary special knowledge is available as a toolkit for tens of dollars. Attackers are in different legal jurisdictions and may even be agents of foreign nation states; they do not, and need not, fear detection or identification, much less prosecution.

The value of a successful attack is too high and rising. Compromised credentials may result in losses of hundreds of thousands of dollars, expensive to the banks, but a threat to the health and continuity of a small business customer. Compromised systems may result in the loss of intellectual property that threatens the health, competitiveness, and continuity of the enterprise. Can you say Google? RSA? Can you say Sony?

Too many web facing applications have unchecked inputs making them vulnerable to SQL injection and buffer overflow attacks. These attacks are resulting in the compromise of personally identifiable information (PII) and payment card information (PCI). They have become so common that many no longer make news.

While we still see bait on web sites and some spam, the most efficient bait is crafted to appeal to identified individuals and is delivered by e-mail. For many enterprises a crafted bait message may be sufficient to compromise their whole network. The bait messages that used to appeal to fear, greed, or lust now appeal to curiosity. One report had it that the bait messages addressed to RSA were labeled "2011 Hiring plan."

Accepting the bait may compromise the user's credentials, as we saw in Patco and Experi-Metals, facilitating re-play attacks. Alternatively, it may compromise a system, providing a tunnel through the perimeter and an agent on the network, as we saw in RSA.

The net of all of this is that "Business as usual" will not cut it. We must raise the state of the practice closer to the state of the art. We must raise the cost of attack and lower the value of success. We must raise the bar across the board.

Since e-mail is proving to be such an efficient attack vector and involved in so many compromises, it is a good place to start.

Awareness training is necessary but not sufficient. With a sufficiently large population of users, it is inevitable that one or more will take the bait. It is not stupidity or even carelessness. Rather it is simply human nature.

Upgrade or outsource your e-mail. Use a restrictive e-mail policy; that is, accept messages only from known sources. Ninety percent of all your traffic comes from such sources and they are limited in number. Quarantine or "red-flag" everything else. Be sure that the "from address" agrees with the origin address.

Encourage users to have personal e-mail addresses that they can access from their own mobile devices or kiosk machines provided for the purpose. Yes, it is a change in culture but not as expensive we pretend that it is.

Since unchecked inputs is obviously part of the problem, address them. Checking inputs is much harder than it looks, beyond the training, knowledge, skills, and abilities of most application programmers. That is why this problem, identified forty years ago, still persists. Therefore, application programmers should all be trained and required to use the OWASP Enterprise Security API.

Most of us still use M&M security, crisp on the outside, soft and mushy on the inside.

Assume that there is no perimeter or that there is an agent on the inside. The NSA behaves accordingly. If one has, or assumes that one has, untrusted machines on one's network, one must place place firewalls between all systems and their networks. These must implement a restrictive policy; only that traffic explicitly permitted must pass.

We must have strong authentication, credentials that cannot be re-played raise the cost of attack and reduce the value of success. More on this next week when we talk about the "new" authentication guidance from the Federal Financilaal Institutions Examination Council.

Servers must talk only in secret codes, VPNs to clients, VLANs to one another. Terminate VPNs on the applications, not on the perimeter, not on operating systems. Applications should talk only in secret codes, only to those who have the key.

Lock down every system that you can. Restrict "write" access to programs. Part of our problem is that the population of systems that can be compromised is ten times the size it needs to be. Most users do not require the discretion to execute arbitrary programs or even to install applications. Most users could get along with thin clients to apps running on servers. If a user takes bait but his system resists compromise, then no permanent harm done may be done.

Configure access control on database servers. We are relying on application servers to protect the database servers; they are not up to the task. Use a restrictive policy; even these will leak but they will raise the cost of attack over permissive one's. Most application data, personally identifiable information, payment card data, and intellectual property must be stored on object-oriented, database servers, not in flat files, not on personal systems.

We must have stronger application controls. It is absurd, for example, for an application to permit 92 transactions in a day, for hundreds of thousands of dollars, using credentials that have never been used for that purpose before, against an account that normally had a zero balance, and against which no more than one or two transactions had ever been made in a day. In addition to checked inputs and database controls, we need controls specific to the application. Application controls raise the cost of attack and reduce the value of success.

Do you really believe that your security is that much better than Sony's, that you could resist the same kind of attack? If compromised in the same way, do you have a plan to return your network to a known and trusted state? Note that this requires rigorous separation of data and programs so that you can restore programs without the loss of data.

Let me not forget monitoring, measurement, and reporting. Turning on logs is necessary but not sufficient. If one waits until after something goes wrong and looks at them only for forensic purposes, it is too late. There is software for integrating logs and for using them pro-actively to identify and resist attacks before, rather than after, they succeed.

Restrictive policies, even for e-mail, least privilege, even for users, strong authentication, stronger applications, encryption by default, and better monitoring, measurement, and reporting all round. It is time to get serious.

Many of these measures are counter-cultural. They will have some influence on the way people do their jobs. They will generate some resistance and even some resentment. We will have to change attitudes. Notice that they do not require new tools so much as changes to how we use our tools.

These are just tactics but a change of this magnitude is strategic. It is ambitious. It will require leadership, commitment, and planning. It will take time, of which we have little enough. If we are to continue to be called professionals and to be paid the big bucks, we must be able to look back two years from now and measure a marked improvement in our security posture. If you are not up to the challenge, perhaps you should update your resume. On second thought, perhaps you should consider a change in career.

RSA SecurID Update

I continue to believe that the public relations surrounding the recent breach of RSA's systems is the worst since Watergate. In any case, it is far worse than the breach. Every pronouncement on their part to make it better has only raised more fear, uncertainty and doubt.

I would like to try to distill some signal from all this noise.

Let me say from the start that the sky is not falling. Fear is not justified. Strong authentication is not falling apart. SecurID is not broken. While the cost of attack for one adversary, perhaps a nation state, against some targets of choice has fallen marginally, for most SecurID users, their risk is approximately the same today as it would be had their been no breach.

As I noted in my first report on this subject, I am glad that RSA is not my client. They are truly between a rock and a hard place and the water is rising.

So there are all sorts of good reasons why RSA is less than forthcoming about their breach. First, they probably have limited knowledge about what actually happened. They do not want to compromise the investigation. They do not want to leak any information that might be useful to the perpetrator in exploiting the product of the breach. They do not want to do anything that might make a bad situation worse.

However, their lack of candor has done just exactly that.

[Of course the perpetrator of the breach probably knows what he got and how to use it. After all, RSA was a target of choice, not opportunity; if the attacker had not known what he was looking for and what he would do with it if he got it, he would not have bothered.]

The lack of candor of their customer, Lockheed-Martin, only added to the FUD. What evidence did Lockheed have that it was under attack? What evidence that it was related to the RSA breach? What was the method of attack? To what extent was the attack successful? Security professionals would like to know. Instead, after all of this, the only thing that we know with confidence is that RSA was breached by a resourceful and patient adversary. Almost all else is speculation, not to say hype.

Given the little we know, what should we do? Which among us should do it?

If you are not already using strong authentication, start. Can you say "replay attack?" Account takeover? Identity fraud? Zeus? SpyEye? Start with privileged users. Start with users at systems that you do not control. Can you say customers? Trading partners? Home workers?

While I still have a high regard for EMC and RSA security, needless to say, it is diminished. So, if you want to use token-based, you may want to consider a different vendor. I am increasingly a fan of out-of-band. I like the use of mobile devices, devices that people carry anyway, for both token-based and out-of-band. I use my iPhone for token-based with PayPal.

If you are the average SecurID user, do nothing. Your risk has not changed enough to justify the cost of any changes, let alone the cost of distributing new tokens, even free ones.

Any attack exploiting the leak and that does not involve the use of a known token ID, or at least a user ID and PIN, will be noisy. Therefore, risk averse organizations may wish to:

1. Listen. Monitor your ACE server for failed logon attempts.

2. Resist bait attacks and other "social engineering attacks seeking token IDs, user IDs and PINs. (See rule 1.)

3. Resist exhaustive attacks against PINs, for example by increasing the content. However, since the most efficient attacks against PINs will involve "social engineering," see rule 2.

The Canadian Cyber Incident Response Center published "advice," this week, further muddying the water. Their advice included a target list in the context of the RSA breach.

· high-profile international events participants (e.g., Olympics, FIFA)

· legal organizations, namely those involved in international contracts, mergers and acquisitions (e.g., Clifford Chance)

· organizations involved in international affairs, economics and finance (e.g., IMF, World Bank)

· security and defense organizations (e.g., Lockheed-Martin, Northrop-Grumman)

· natural resources and energy sector organizations (e.g., FMC, Exxon-Mobil, AramCo)

· research and development organizations (e.g.,

· information management / information technology organizations (e.g., Intel, Apple, IBM, EMC, Verisign,

· political activist groups (e.g., ACLU, the RNC)

While these are all high value targets, taken collectively, their risk did not change as a result of the RSA Breach. The list is too long and embraces far more enterprises than even a resourceful adversary is capable of getting to. For most on this list, there is safety in numbers. Having drawn the list and thereby suggesting that all on it are peer targets, the CCIRC stopped short of recommending that they all issue new tokens. Government, in an abundance of caution, has cast its net so broadly that no recommendation is possible.

You should issue new tokens if, and only if, you might be a target of choice for those who breached RSA and attacked Lockheed-Martin. You should know who you are. You do not need the CCIRC to tell you. Your risk may have changed enough to justify issuing new tokens. Expect RSA to pay for them. Still in doubt? Call me.

Whoever you decide that you are and whatever you decide to do, write it down. Professionals document their decisions and communicate them to their principals. Be prepared to be second-guessed; it goes with the job.

We need to watch for any evidence that those who breached RSA have been successful in exploiting it. One way this will show up is as evidence of efficient attacks; we should watch for this. Another way that it will show up is in sale of RSA intellectual property to others; these transactions will probably take place on the Internet and we should watch for them.

Discerning intelligence, information that we can act on, from all this noise is difficult. That is why we are called professionals and are paid the big bucks. Fortunately, for most of us, the default, doing nothing, is the right choice. Write it down.