The Browser Threat Model

Introduction

This document describes in overview form the threat model facing the browser. For a fast reading, skip to the 3rd section.

What is a Threat Model?

The construction of the threat model is an essential, critical, phase in the construction of the overall security model for a system [Modelling]; the threat model is one of the factors that feeds into the security model, which latter takes and analyses the costs and benefits of defending against each listed threat [Modelling];

Note. Defences against particular threats are more part of the security model than the threat model. To complete and link the discussion, defences are shown in the sideboxes. They are, however, not part of the formal threat model, and this document thus includes more than the threat model per se.

Attack Trees

An attack tree is "a systematic method to characterize system security based on varying attacks. Each attack tree enumerates and elaborates the ways that an attacker could cause the event to occur. Each path through an attack tree represents a unique attack on the enterprise [Hollingworth]." I've found relatively little in the literature on threat models, but there is some literature on Attack Trees [AT]. Attack trees differ from the approach of this document. Attack trees document all potential and plausible attacks, and then leave it up to the security model to identify and deal with each attack. In contrast, this document is currently structured to start from the known, validated threats to Internet users in general and browsing in particular. In this sense, it considers theoretical attacks as less important, a priori.

An attack tree formatted as a mindmap is presented at http://iang.org/maps/browser_attack_tree.html [Maps]. The attack tree is not as structured nor complete as the above literature suggests. For one, it does not develop the attacks in its full process, rather, each attack is simply listed and left to the reader for full development.

User Base

What are the users doing?

What sort of threat model / security model can we construct in the face of an uncertain user base for the Mozilla certificate and browsing architecture?

Why now?

Evolution of the Threats

Criticism of the secure browsing security model has been ever-present, but lacked momentum until recently due to no serious threats to browsing. Most criticism has centered on the key exchange part of the protocol, grounded as it is in a public key infrastructure ("PKI") known as the Certificate Authority model [PKI].

During recent years, serious attempts at revisionism of security architecture policy have been attemtped. The cornerstone of these efforts has been to move from the deductive, no-risk school representative in SSL to the inductive, opportunistic school representative of SSH. These efforts at re-aligning security architecture to economic risks have gained momentum from the market success of the SSH model, and the arisal of phishing as a serious breach of the secure browsing security model.

Original Models

The original security model for browsing never developed and validated a proper threat model [WYTM?]. Instead, the model used was variously assumed, guessed at, and labelled, ex poste, the Internet Threat Model ("ITM"). This has been known as weak for some time, yet only recently has it been recognised as wrong and also one of the root cause of weaknesses in secure browsing.

Without a viable threat model, the construction of a security model is unfounded. That is, it's a building of concrete and steel, of some significant height and weight, yet laid on sand dunes. Will it sink, will it roll over, or will it collapse?

The weakness of a laid-out threat model for browsing has been recognised for some time. Since then, unaddressed threats have grown worse, but there has been relatively little momentum to address these threats.

Mozilla Foundation

In 2004, the Mozilla Foundation, a publisher of open source browser software, embarked on the selection of a policy for the addition of new Certificate Authorities. This new policy project has recognised and called for a remedy to the lack of a threat model; this present document is this author's informal attempt to fill that gap.

TBD

What's Missing

Frank Hecker wrote:
> Note that for a full treatment we
> really need to consider email and
> downloading executable code as well,
> since those are the other two major
> uses for certificates in the context
> of Mozilla and related software.

Things to consider

Frank Hecker wrote:
> Some things I've found so far include
> Nelson's posting "On a crypto security
> threat model for mozilla users":
> 
> http://www.google.com/groups?selm=c0mp01%24cip1%40ripley.netscape.com&output=gplain
> 
> and John Meyers' posting in a thread
> Nelson started about "On criteria
> for trusting public root CAs":
> 
> http://www.google.com/groups?selm=9dadnUFVDPKtVbTdXTWc-g%40speakeasy.net&output=gplain
> 
> There are more useful comments in these
> threads and others.

Layout

Firstly, the general major Internet threats that are clear and present today are laid out. As a Threat Model strives to be complete, it necessarily should start out broad, and then narrow down (fast readers can skip this section).

Then, the Internet threats are taken as the context and background for the next section, being those threats that are relevant to the browser.

General Threats to Users of the Internet

Follows is a list of the major threats to Internet users. These are major because they are frequent, and costly. In other words, these are validated threats.

However, not all of them relate to browser security, (and some are not specific even to the Internet). For threats against browsing, see the next section.

Threat #I1 - Phishing

Phishing is defined as the sending of emails to victims in a spam-like broadcast, attempting to elicit account information. In general, the email purports to come from a targeted institution, and includes a URL which the victim is tricked into following.

Threat #I2 - Viruses

Viruses that pass from one mailer to another.

Viruses can pass from any active agent to another; the essence is a service that accepts connections and performs some processing.

Threat #I3 - Spam

Spam email is an economic problem. As email is free, and presumes that any person can send any other person an email without prior relationship, it creates the environment for costless advertising (in approximate marginal terms).

Threat #I4 - DOS

Denials of Service are generally launched at upstream elements and stop users reaching assets.

Threat #I5 - Cracking

The major issues with Cracking into boxes on the net (a.k.a., hacking) are that:

1. The box itself suffers, due to the cost of cleaning out any damage or changes made;

2. The box can be used as a staging point for a further attack against other assets; and

3. Information on the box such as card or personal details can be stolen.

Cracking is frequent. Last August, in one month, 12,892 Linux servers were breached, and 4,626 Windows servers also were cracked [Linux].

Other Threats

The following threats are not considered to be Internet threats, per se, but are relevant (tenuously or directly) to the browsing environment, as they effect browser users.

Financial Fraud

Identity Theft

This threat is more asymmetric to the net, but for reasons of its relationship and classification to other threats, and its increase in prevalence to (mostly) american commerce, it needs to be recognised [Identity].

Ponzis and Pyramids

In the online payments world, many scams of the Ponzi and Pyramid nature are conducted. These generally involve a game or investment, with some promise of fortunes to be made [P+P].

Threats to Browser Users

This section refines the above from a broad Internet list to a specific browser list.

Threat #B1 - Phishing

Phishing is primarily a browser threat. The browser is the tool of choice for accessing financial accounts.

How it is done

The attack has many phases. It has a very good filtering characteristic, as spam techniques allow a broadcast invitation, and the victims self-filter themselves through the website. [Semantic Attacks].

Presentation

Normally a mail is sent, and a URL is presented. There are several aspects.

The mail can be plaintext or it can be in HTML. If in HTML, the URL can be bogus by means of hiding the real URL in the HTML. For example,

    <a href="http://dodgy.free.com/scam.php"> www.bankofamerica.com </a>

If the email is in plaintext, the URL is normally one that relates to a "like" name. E.g., www.boa-fraud-control.com.

Elements of both can be used. Often, there are many valid URLs mixed with a few invalid ones.

Click-thru

The essence of the email is to convince the user to click on the URL, as presented by the email. Once clicked through, the browser launches directly, and presents the site.

Note. The click through feature is only partially to blame here, as even if the user were forced to copy the URL by hand, there would be ways to encourage the user to continue along that path. It is also worth bearing in mind that consumers are unlikely to give up their click through feature.

The Spoof Site

On the site itself, a series of more or less convincing claims, or a convincing copy of the original targeted site, entice the user to enter account number/name and password. Once these details are captured by the spoof site, some form of closure is attempted.

The Crime

Once the account details are obtained, the account can be raided. The theft can either be done immediately, or delayed to another time when there is more money in the account (or a coordinated sweep can be attempted across many accounts).

The Launder

The money is transferred directly to another account. This will often be a way-station account, from there, the funds are transferred again, and potentially again and again [Wash].

Validation

Attempts at phishing happen daily, in bulk mailings. Often, the same attempt is tried with multiple variations. Actual statistics of frequency of victims and losses are hard to come by [aphwg]. [mi2g] [Crowne] [Texas]. But, the evidence of frequent attempts indicates some success is occurring.

Threat #B2 - Eavesdropping

Passive listening to browsing activity in general is a possible attack. The attacker is sometimes known as Eve.

How it is done

For Eve to listen to web traffic, there needs to be access to either an open broadcast network (unswitched ethernet or 802.11b), or access to a router node. Having access to a router node of some form implies either an insider attack or a cracking attack.

Validation

It is very hard to validate eavesdropping attacks. For the most part, the frequency seems to be below the noise level, i.e., unmeasurable. This is in direct opposition to the public perception of the Internet as a wild and lawless place where all of the user's traffic can be read.

There have been isolated incidents of eavesdropping. Here are some examples, of anecdotal strength:

• System administrators have occasionally been caught reading email of clients. This has generally come to light when they have been reportedly fired for this activity. No monetary losses are known.

• Eavesdropping was prevalent in the earlier days of remote system administration, when rsh(1) was used to hack into boxes. The advent of ssh(1) (in short, Secure Rsh) put a stop to that.

• One reported incident of credit cards (multiple) being allegedly sniffed off a student (open) network.

Incentives

The attack is hard to monetarise due to its poor filtering characteristics. Browsing involves a huge amount of traffic, and searching for the key parts of a form submission, or scanning downloads for key information requires a lot of work. Further, as access to larger amounts of data is needed, security gets tougher, either at the node level, or due to side-effects.

For this reason, eavesdropping is normally conducted as a privacy breach - the search for some specific privacy information against some stated target, rather than a monetary breach such as scanning for cards.

In practice, little evidence leads to this as a serious monetary threat, but it may be more of a privacy threat due to its difficulty in detection.

Threat #B3 - MITM

In contrast to the above, the the man in the middle attack ("MITM") is an active attack, requiring the attacker (known as Mallory) to send and/or block packets.

How it is done

Opportunistic crypto leaves open the weakness of the MITM. This is because opportunistic crypto does not authenticate the other party, so a third party can sit in the middle and complete the protocol both ways.

Incentives

MITM is an expensive attack as it leaves tracks. It's also an active attack, and thus presents evidence of wrong doing, in the act. Unlike eavesdropping, which is a passive attack, MITM potentially provides the victims with sufficient evidence without needing to capture the sessions of the attacker "in the act" as it were.

Therefore, we can presume that Mallory will generally only use the technique of MITM where he is unconcerned about being caught. For example, one of the following scenarios:

1. It is a "demonstration," not a crime. This happens for example at hacker conferences, and on university campuses.

2. The criminal is out of reach: sufficiently remote and untouchable so as not to care (so, not on an open ethernet, but rather, hacked into a router box, or if wardriving, too far away to be seen).

3. The attacker is unpunishable even if caught. This would generally imply that the attacker has many other resources, and only chooses this method so as to be surreptitious [HRC].

Of the above, the only serious threat is the remote attack. This limits the attack to the hacked routers, or potentially the wardriver.

The unpunishable attacker can generally attack other ways as well, so the essence is on limiting and detecting that avenue if possible. The demonstration attacker is a nuisance, but not a serious input into a security model.

Because of their poor filtering characteristics, and their high riskiness deriving from active tracks (evidence), they remain the tools of only a select few fringe attackers with obscure interests.

Validation

There are extraordinarily few reports of MITMs.

Some reports come from demonstrations and from demonstration kits that are available for MITMing the popular protocols. Others come from conferences of hackers and the like, and are akin to "mucking around in a safe environment."

There are no known reports of MITMs over the SSH network, which is arguably the highest prized network to attack, as it could create the pool of hacked machines to further deploy attacks. Likewise, OpenPGP and SSL have not experienced any successful MITMs that have been reported.

DNS has been "poisoned" several times, resulting in email and web sites being diverted. The former was for a privacy attack (salacious emails being revealed in political campaign) and the latter was a demonstration of the weakness of DNS.

In essence, MITMs remain the stuff of legend.

Threat #B4 - DOS

Denial of service is conducted by causing many controlled boxes to flood a website with requests. These boxes are controlled via one of two methods, being cracking, or viruses.

As the DOS is conducted by copying the activities of normal users, in the act of browsing, it is a hard attack to address. For this reason, it is often considered to be the last threat to be dealt with, if at all.

References