an anti-spoofing tool: spoofguard++studentnet.cs.manchester.ac.uk/resources/library/...an...

AN ANTI-SPOOFING TOOL:

SPOOFGUARD++

A dissertation submitted to The University of Manchester for the degree of MSc in Advance Computer Science in the Faculty of Engineering and Physical Sciences

2011

MOHAMMED S BAIHAN

SCHOOL OF COMPUTER SCIENCE

An Anti-Spoofing Tool: SpoofGuard++ By Mohammed S Baihan

2

Table of Contents

Table of Contents ...................................................................................................... 2

List of Figures .......................................................................................................... 5

List of Tables ............................................................................................................. 7

List of Equations ....................................................................................................... 8

Abstract ..................................................................................................................... 9

Declaration .............................................................................................................. 11

Intellectual Property Statement ............................................................................. 12

Acknowledgment .................................................................................................... 14

Chapter 1. Introduction........................................................................................ 15

1.1. Project Context ..............................................................................................................15

1.1.1. Phishing Attacks ............................................................................................................15

1.1.2. The Consequence of Phishing Attacks ........................................................................16

1.1.3. How to Counter Phishing Attacks ...............................................................................17

1.2. Research Motivations and Challenges .......................................................................17

1.3. Aim and Objectives .......................................................................................................18

1.4. Project Scope .................................................................................................................18

1.5. Dissertation Structure ...................................................................................................19

Chapter 2. Literature Review (countermeasures) ............................................ 20

2.1. Chapter Introduction ....................................................................................................20

2.2. Type 1: Server-Side Solutions .......................................................................................20

2.2.1. Email-Content Analysis Method ................................................................................21

2.2.2. Notice-and-Take-Down Method ................................................................................27

2.2.3. Authentication Protocol Method ...............................................................................28

2.3. Type 2: Client-Side Solutions .......................................................................................32

2.3.1. Blacklist-Based Method ..............................................................................................32

2.3.2. Visual-Clue-Based Method .........................................................................................36

2.3.3. Webpage-Feature-Based Method ..............................................................................40

2.3.4. Information-Flow-Based Method ..............................................................................45

2.4. The Best Way Forward ..................................................................................................47

2.5. Chapter Summary ..........................................................................................................47


3

Chapter 3. SpoofGuard++ Design ....................................................................... 48


3.2. SpoofGuard++ Overview ..............................................................................................48

3.3. Requirement Specifications ..........................................................................................49

3.4. SpoofGuard++ Architectural Design ..........................................................................51

3.4.1. Architecture Overview ...............................................................................................52

3.4.2. Architectural Components .........................................................................................53

3.4.2.1. SpoofGuard_Toolbar Component ..........................................................................54

3.4.2.1.1 Blacklist-Based Versus Webpage-Feature-Based Method ................................54

3.4.2.1.2 Webpage-Feature-Based Method .........................................................................55

3.4.2.1.2.1. First-Round Checks ..........................................................................................57

3.4.2.1.2.2. Second-Round Checks ......................................................................................61

3.4.2.2. User_Setting Component ........................................................................................64

3.4.2.3. Page_Status Component .........................................................................................65

3.4.3. User Interface .............................................................................................................65

3.5. Chapter Summary ..........................................................................................................68

Chapter 4. SpoofGuard++ Implementation ........................................................ 69


4.2. Implementation Platforms ............................................................................................69

4.3. Programming Languages .............................................................................................70

4.4. SpoofGuard++' Low Level Design................................................................................70

4.4.1. BeforeNavigate2 .........................................................................................................73

4.4.2. DocumentComplete ....................................................................................................79

4.5. Difficulties Faced During Implementation .................................................................84

4.6. Chapter Summary ..........................................................................................................86

Chapter 5. SpoofGuard++ Evaluation and Testing ........................................... 87


5.2. Testing and Results .......................................................................................................87

5.2.1. Testing Against Phishing Attacks ..............................................................................88

5.2.1.1. Testing Against Phish Sites .....................................................................................88

5.2.1.2. Domain Check Testing and Results ........................................................................90

5.2.1.3. URL Check Testing and Results .............................................................................91

5.2.1.4. Email Check Testing and Results ...........................................................................92

5.2.1.5. Outgoing Post Data Check Testing and Results ....................................................93

5.2.1.6. Password Check Testing and Results .....................................................................95


4

5.2.1.7. Links Check Testing and Results ...........................................................................96

5.2.1.8. Image Check Testing and Results ...........................................................................98

5.2.1.9. Tabnabbing Check Testing and Results ................................................................99

5.2.2. False Positive Rate Testing and Results ..................................................................101

5.2.3. SpoofGuard++ Performance Evaluating and Result .............................................102

5.3. SpoofGuard++ Limitations .........................................................................................103

5.4. Chapter Summary ........................................................................................................104

Chapter 6. Conclusion and Future Works ....................................................... 105

6.1. Conclusions ...................................................................................................................105

6.2. Recommendations for Furute Works .........................................................................106

References ............................................................................................................ 107

The final word count:

Body of the dissertation - 15972

Complete dissertation - 18342


5

List of Figures

Figure 1.1 - Typical phishing attack steps ....................................................................... 16

Figure 2.1 - The machine learning approach ................................................................... 22

Figure 2.2 - SenderID technique processes ..................................................................... 29

Figure 2.3 - DKIM technique processes ........................................................................... 31

Figure 2.4 - NetCraft Toolbar ............................................................................................. 36

Figure 3.1 - SpoofGuard++ architecture ........................................................................... 53

Figure 3.2 - SpoofGuard++ toolbar ................................................................................... 66

Figure 3.3 - SpoofGuard++ page status pop up ............................................................... 66

Figure 3.4 - SpoofGuard++ setting pop-up ...................................................................... 67

Figure 4.1 - A warning message at BeforeNavigate2 event ............................................ 74

Figure 4.2 - Pseudocode for domain check ..................................................................... 75

Figure 4.3 - Pseudocode for URL check........................................................................... 76

Figure 4.4 - Pseudocode for email check ......................................................................... 77

Figure 4.5 - Pseudocode for outgoing post data check .................................................. 78

Figure 4.6 - A warning message at DocumentComplete event ....................................... 80

Figure 4.7 - Pseudocode for password check ................................................................. 81

Figure 4.8 - Pseudocode for links check .......................................................................... 82

Figure 4.9 - Pseudocode for image check ........................................................................ 83

Figure 4.10 - Pseudocode for tabnabbing check ............................................................. 84

Figure 5.1 - A comparison between each tool response against phish URLs ............... 89

Figure 5.2 - Testing domain check ................................................................................... 90

Figure 5.3 - Testing URL check ......................................................................................... 91

Figure 5.4 - Testing email check ....................................................................................... 92

Figure 5.5 - Testing outgoing post data check ................................................................ 94

Figure 5.6 - Testing password check ............................................................................... 95

Figure 5.7 - Testing links check ........................................................................................ 96


6

Figure 5.8 - Testing image check ...................................................................................... 98

Figure 5.9 - Testing tabnabbing check ............................................................................. 99

Figure 5.10 - A comparison between each tool response against clean URLs ........... 101


7

List of Tables

Table 2.1 - Features used in model-based machine learning technique ........................ 22

Table 2.2 - Features used in Chandrasekaran et al. proposal ........................................ 25

Table 2.3 - A summary of SpoofGuard’s evaluations functions ..................................... 41

Table 2.4 - The 18 URL features and their coefficients ................................................... 44

Table 5.1 - Phish tested URLs and each tool response .................................................. 89

Table 5.2 - Clean tested URLs and each tool response .................................................. 22


8

List of Equations

Equation 3.1 - Total spoof score (TSS) calculation ......................................................... 56


9

Abstract

Phishing is an online identity theft that makes use of social engineering and

technical subterfuge. Using these techniques attackers can gain individuals‘

confidential data in order to illegally access their bank accounts, for example.

The number of victims of phishing attacks has been increasing dramatically in

the last decade. This is because attackers constantly develop new phishing

techniques and the majority of Internet users do not follow security advice. The

aim of this project is to provide an anti-spoofing solution, SpoofGuard++, to

address the phishing problem. The proposed solution tries to counter existing

as well as new phishing techniques, such as URL shortening and tabnabbing.

In this project, a comprehensive literature review of the related works has been

conducted identifying strengthens and limitations in existing solutions. In

addition, an investigation of new sophisticated phishing techniques has also

been conducted. Based on the literature research, a novel solution,

SpoofGuard++, has been designed, implemented and evaluated. The solution

uses two round checks to detect phishing attacks. The first round of checks

cover the domain, URL, email, and outgoing post data checks, which are fired

before the Internet Explorer navigates. The second round of checks cover the

password, links, image, and tabnabbing checks, which are fired after the

Internet Explorer has uploaded a page. An Internet Explorer toolbar has been

developed to implement the proposed design using C# programming language.

The evaluations of SpoofGuard++ and the original solution, SpoofGuard,

demonstrate that the proposed solution can reduce the false positive rate by as

high as 60%.


10

Protecting users‘ sensitive information in the Internet environment requires the

projection of new attacks and the understanding of the nature of the new

attacks. The future work includes adding new features to stop Cross Site

Scripting (XSS) and JavaScript-based attacks, and extending the solution to

Firefox browser.


11

Declaration

No portion of the work referred to in the dissertation has been submitted in

support of an application for another degree or qualification of this or any other

university or other institute of learning.


12

Intellectual Property Statement

i. The author of this dissertation (including any appendices and/or

schedules to this dissertation) owns certain copyright or related rights

in it (the ―Copyright‖) and s/he has given The University of

Manchester certain rights to use such Copyright, including for

administrative purposes.

ii. Copies of this dissertation, either in full or in extracts and whether in

hard or electronic copy, may be made only in accordance with the

Copyright, Designs and Patents Act 1988 (as amended) and

regulations issued under it or, where appropriate, in accordance with

licensing agreements which the University has entered into. This

page must form part of any such copies made.

iii. The ownership of certain Copyright, patents, designs, trade marks

and other intellectual property (the ―Intellectual Property‖) and any

reproductions of copyright works in the dissertation, for example

graphs and tables (―Reproductions‖), which may be described in this

dissertation, may not be owned by the author and may be owned by

third parties. Such Intellectual Property and Reproductions cannot

and must not be made available for use without the prior written

permission of the owner(s) of the relevant Intellectual Property and/or

Reproductions.

iv. Further information on the conditions under which disclosure,

publication and commercialisation of this dissertation, the Copyright

and any Intellectual Property and/or Reproductions described in it

may take place is available in the University IP Policy (see


13

http://documents.manchester.ac.uk/display.aspx?DocID=487), in any

relevant Dissertation restriction declarations deposited in the

University Library, The University Library‘s regulations (see

http://www.manchester.ac.uk/library/aboutus/regulations) and in The

University‘s Guidance for the Presentation of Dissertations.


14

Acknowledgment

I would like to show my great gratitude to my project supervisor Dr. Ning Zhang

for her guidance and feedback on the project

I also want to thank my parents who gave me the moral support I required

My wife Jawza was so patient with my busy days and nights, and I want to

thank her for her faithful support in writing this dissertation.


15

Chapter 1. Introduction

Phishing, a term coined in 1996, is an online identity theft that makes use of

social engineering and technical subterfuge. Attackers use these techniques to

steal users‘ confidential data, for example, bank account ID and password, and

then consequently cause harm to Internet users by transferring money from

their accounts to the attacker‘s accounts. The first use of this type of online

attacks was on AOL accounts [2].

1.1. Project Context

In order to understand the phishing problem better, a reader may need to know

about phishing attacks, the consequences of such attacks, and how to counter

these attacks.

1.1.1. Phishing Attacks

As Huang et al. [1] describe in their paper, a typical phishing attack involves five

steps (figure 1.1) which can be described as follows:

1- A fraudulent website is developed by an attacker.

2- The attacker sends fake emails to a large number of users. These emails

include a link to the attacker‘s website.

3- A number of unsuspecting users will be lured to visit the attacker‘s website.

On this website the confidential data of these users are exposed to be

compromised.


16

4- The attacker can gain users‘ confidential data from his fraudulent website.

5- The attacker impersonates the users on the target website using their

confidential data. Then the attacker can access the victims‘ financial accounts.

1.1.2. The Consequences of Phishing Attacks

Phishing attacks mainly affect individuals. These affects are financially related

and legally related [35]. The financial impact of phishing on individuals is the

most important issue. Typically, the main target of phishers is gaining access to

the individuals‘ bank accounts. If their attacks are successful, the individuals are

likely to lose money from their bank accounts. In addition, an individual may

face real legal issues because of phishing. Phishing attacks focus on gathering

individual confidential data, such as name and social security number. If these

data are used to break the law, the individual will not be able to deny this and

hence may face formal penalties.

Figure 1.1: Typical phishing attack steps [1]


17

1.1.3. How to Counter Phishing Attacks

In order to reduce the risk of phishing attacks, a variety of techniques have

been proposed. Some of these techniques are designed to work at server side

(server website), while other techniques are developed to work at client site (the

browser client). In addition, educating users may contribute in mitigating

phishing risks and can be served as a compliment solution to both server and

client side techniques. A dissection of these techniques can be found in

Chapter.

1.2. Research Motivations and Challenges

The motivations and challenges of this project are:

1- There are shortcomings in the current anti-phishing techniques and solutions

which allow some sophisticated attackers to achieve their targets, for example,

blacklist-based solutions are not effective if these lists are not updated [36].

2- The number of victims, both organizations and individuals, has increased

over the last ten years. For instance, in 2008, more than 5 million US Internet

users lost major amounts of their money [37].

3- Phishing attackers mainly try to gather users‘ confidential data [38].

4- Most of Internet users do not follow security advice due to extra effort that

security requires [41].


18

1.3. Aim and Objectives

The aim of this project is to provide the anti-phishing industry with a solution

that can detect more sophisticated phishing attacks as well as detecting simple

phishing attacks. To achieve this aim, there are some detailed objectives and

tasks that are required to be performed:

1- To survey and examine the current techniques and solutions of anti-phishing

and gain further knowledge through the understanding of these techniques.

2- To conduct an investigation of new phishing attacks and their potential

threats.

3- To collect the proposed system requirements.

4- To design the proposed system‘s architecture.

5- To implement the designed architecture into a working programme.

6- To evaluate the resulting system.

1.4. Project Scope

In order to achieve the project‘s objectives this project‘s scope should be

specified:

1- The development of an Internet Explorer (version 4 and later) toolbar

(SpoofGuard++).

2- The Microsoft .NET framework will be used to implement SpoofGuard++

using C# programming language.

3- SpoofGuard++ is an enhanced version of the origin SpoofGuard [3].

4- SpoofGuard++ is intended to mitigate risks of new and sophisticated phishing

techniques.


19

1.5. Dissertation Structure

The following chapters of this dissertation are organized as follows. Chapter 2

provides a survey of solutions that have been proposed in literature and

industry to mitigate the phishing problem. The server-side and client-side

solutions are described and each solution of them is critically analyzed. Chapter

3 describes the high-level design of an anti-spoofing solution, SpoofGuard++. It

also provides an overview of the proposed solution and a basic set of

requirements that the solution should achieve in order to make this solution

acceptable by Internet Explorer users. Chapter 4 focuses on the implementation

issues of the SpoofGuard++ development and discusses the implementation

platform that the anti-spoofing toolbar integrates to. In chapter 5, the proposed

solution and its individual checks are tested and evaluated and a number of

phish and safe sites are used to test true and false positive rates of

SpoofGuard++. Finally, chapter 6 provides a summary of what this project has

achieved. It also concludes main findings, and suggests some suggestions for

future work.


20

Chapter 2. Literature Review (countermeasures)

2.1. Chapter Introduction

This chapter provides a survey of solutions that have been proposed in

literature and industry to mitigate the phishing problem. The server-side and

client-side solutions are described and each solution of them is critically

analyzed. In this chapter, potential missing features in the previous works are

discussed.

In details, this chapter is structured as follows. Section 2.2 provides a detailed

description of the existing server-side solutions and their limitations. Section 2.3

describes the existing client-side solutions and their limitations. Section 2.4

discusses the potential missing features in the previous works. Finally, section

2.5 summaries this chapter.

2.2. Type 1: Server-Side Solutions

Server-side solutions are server-based applications that attempt to mitigate the

phishing problem. The idea behind server-side anti-phishing solutions is to

protect a user from being a victim of a phishing attack by filtering incoming

emails, taking action against fraudulent websites, or applying authentication

protocols at the recipient‘s mail server. These solutions make use of email-

content analysis, notice-and-take-down, or protocol-based authentication

methods.


21

2.2.1. Email-Content Analysis Method

The email-content analysis method focuses on examining incoming emails to

find specific features of fake emails to prevent such emails from reaching the

user‘s inbox. To determine these features, a number of known fake emails are

analyzed. These features can be grouped into seven categories: structural, link,

element, spam filter-based, style markers-based, structural attributes-based and

word-based features. There are a number of techniques which are associated

with this method. For example, model-based machine learning [14] and

property-structure based techniques [18].

Bergholz et al. (2008) [14] proposed a model-based machine learning

technique. In this technique new email‘s features are compared to features of

known phishing emails. Then a judgment on the new email is made as to

whether this email is fake or normal. This technique uses 27 basic features and

different advanced features. The basic features can be grouped into five

groups: structural, link, element, spam filter-based and word-based features.

Features of each group are listed in tables 2.1.

The advanced features are proposed by the authors. They adaptively trained

Dynamic Markov Chains and novel latent Class-Topic Models to generate these

features. To compare the new email‘s features to the proposed features, the

technique uses a classifier. This classifier has two inputs: the values of the

phishing emails‘ features (the training set of the classifier), and the values of the

new emails‘ features (the test set of the classifier). Figure 2.1 gives a general

view of the proposed technique.


22

Table 2.1: the features used in model-based machine learning technique

Feature category Feature

Structural

total number of body parts

number of discrete and composite body parts

number of alternative body parts

Link

total number of links

number of internal and external links

number of links with IP-numbers

number of deceptive links

number of links behind an image

maximum number of dots in a link

Boolean value, indicating whether there is a

link whose text contains one of the following

words: click, here, login, update

Element

Boolean value, indicating whether HTML is

used.

Boolean value, indicating whether scripting is

used.

Boolean value, indicating whether JavaScript is

used.

Boolean value, indicating whether form is used.

spam filter-based filter test score

Boolean value, indicating whether an email is


23

considered to be spam

word-based features

Boolean value, indicating whether ―account‖

word exists in the email

Boolean value, indicating whether ―update‖


Boolean value, indicating whether ―confirm‖


Boolean value, indicating whether ―verify‖ word

exists in the email

Boolean value, indicating whether ―secur‖ word

exists in the email

Boolean value, indicating whether ―notif‖ word

exists in the email

Boolean value, indicating whether ―log‖ word

exists in the email

Boolean value, indicating whether ―click‖ word

exists in the email

Boolean value, indicating whether

―inconvenien‖ word exists in the email

Figure 2.1: The machine learning approach [14]


24

This technique has one advantage and two limitations:

Advantage

1- The classifier used in the proposed technique may minimize the amount

of normal emails that may be classified as phishing emails. The authors

[14] claim that the classifier reduces this amount by two thirds in

comparison with the work of Cormack et al. [15].

Limitations

1- This technique provides less accurate results in comparison with

previous solutions – that of Fette et al. [16] for example. This is because

this technique does not use extrinsic-based features such as the age of

linked-to domains [14].

2- Since the proposed solution is a statistically-based technique, attackers

may bypass it, for example by using HTML layout tricks [17][18].

Another technique is proposed by Chandrasekaran et al. (2006) [18]. This

technique makes use of the structural properties of phishing emails to

distinguish between legitimate and fake emails. To achieve their target the

authors have identified 25 features. These features can be grouped into two

groups: style markers-based and structural attributes-based features. The

complete list of these features is provided in table 2.2. The authors used 100

phishing and 100 legitimate emails as input to the simulated annealing

algorithm, to identify the useful features. From the relevance between such

features, information gain (IG) has been used to rank these features. Based on


25

the candidate features, the authors used the Support Vector Machine (SVM)

classifier to classify phishing emails.

Table 2.2: the features used in Chandrasekaran et al. proposal

Feature category Feature

style markers-based

Total number of characters

Total number of unique words

Word count

Total number of function words

Function word frequency distribution:

Account

Log

Access

Bank

Credit

Click

Identity

Inconvenience

Information

Limited

Minutes

Password

Recently

Risk


26

Social

Security

Service

Suspended

Total number of words

structural attributes-based

Structure of email subject line

Structure of the greeting provided in the email

body

This technique has one advantage and two limitations.

Advantage

1- The selection of function words features increases the accuracy of this

technique as the authors have proved in their experiment [18].

Limitations

1- This technique may not identify some browser vulnerabilities-based

attacks [18], such as International Domain Name (IDN) spoofing and

pop-up hijacking attacks. This is because the proposed technique

focuses only on email-based attacks.

2- This limited number of emails involved in the experiment is not large

enough to draw a broader conclusion [18].


27

2.2.2. Notice-and-Take-Down Method

Another method to combat phishers is to attack their websites before they can

start harming any individuals. This can be done by finding these websites‘ URLs

from reported phishing emails, for example, then try to remove these websites

from the Internet. Typically, specialist companies play this role as a service to

financial organizations. There are a few techniques that follow this method, two

of which will be discussed here.

Shah et al. (2009) [19] proposed a technique called Pshark. Essentially, through

four stages, Pshark waits for any suspicious emails and, upon detecting a phish

website, it starts to remove such a website. In the first stage, the system

identifies the suspicious email which is currently judged manually. In the second

stage, the URL of a phish page will be extracted and a WHOIS query is used to

find the host server‘s IP address and location, and the Server Administrator‘s

details. In the last stage, Pshark sends a message to the host Server

Administrator to notify him/her that a phishing website is being hosted on its

server. Then the Server Administrator should remove the phishing pages. After

that, Phshark periodically checks whether or not the phishing pages have been

removed. If such a page still exists, Pshark will act aggressively in one of two

ways. Firstly, it will inform the legal authorities that the Server Administrator is

responsible for this attack. Secondly, Pshark will apply attacks against the

phishing page, for example by flooding the phishing page using false data to

reduce the probability of determining correct and false data.

Another notice-and-take-down technique is provided by BrandProtect

International Company [20]. This technique tries indirectly to remove phishing


28

pages upon the receipt of an abuse notification from victims. Using the

suspected website‘s URL, the website is checked and considered as to whether

or not it is active, if it still exists, or if it is never-active. If the site is active, the

Incident Response Analyst collects information about the ISP and the domain

owner and afterwards ensures that the phishing site is removed. In addition, the

URLs of such fraudulent websites will be sent to Microsoft, Google and Firefox

asking them to add these URLs to their blacklist.

These two techniques have one advantage and three limitations as follows:

Advantage

1- These solutions are used to attack phish sites, proactive action, rather

than waiting for real phishing incidents, reactive actions. Therefore

protect more innocent users from phishing attacks.

Limitations

1- Both of the proposed methods require Server Administrator interaction to

remove phishing pages. This dependence on an external body may

affect the performance of the solution [19].

2- As these solutions act upon receiving user messages, confidential

information of some victims may already have been compromised [21].

3- The Pshark design still lacks an effective email filtering technique [19].

2.2.3. Authentication Protocol Method

This method tries to solve the phishing problem by adopting authentication

schemas. These schemas can be applied on the email protocol (STMP), which

is designed without security requirements [6]. Using this method, sender‘s


29

identity can be examined. This can mitigate phishing risks. A number of

techniques, that adopt this method, have been proposed such as senderID [4]

and DomainKeys Identified Mail (DKIM) [5].

Microsoft proposes an email authentication technique called SenderID which

provides sender authentication based on its path. Typically, before sending an

email, a sender can publish a DNS text record which contains allowed IP

addresses that can be associated with the sender‘s domain. Then, before the

sender‘s email reaches its destination, the recipient‘s mail server can intercept

this email and extract the sender‘s IP Address and the sender‘s domain by

finding the address in the ―From:‖ header. Then, it queries the sender‘s DNS to

retrieve the associated IP address. After that, the recipient‘s mail server can

check the real sender‘s IP against the associated IP addresses. The email is

authentic if it passes this check or is considered to be deceptive otherwise.

Figure 2.2 summarizes the senderID technique process.

Figure 2.2: SenderID technique processes [4]


30

This technique has one advantage and one limitation.

Advantage

1- SenderID is easy to implement since it performs a simple IP address

check.

Limitation

1- In a normal email, the ―From:‖ header indicates the sender‘s domain, and

the IP address that appears in the email is the sender‘s IP. However, if

the email is redirected using mail forwarding services or mailing lists, the

―From:‖ header still indicates the original sender‘s domain, but the IP in

that email will be the service provider‘s IP. Thus, the sender needs to

publish all mail forwarding services and mailing list IP addresses that it

may use. Obviously this task is not easy [6].

Yahoo also proposes another email authentication technique called DKIM. It is

a cryptographic-based protocol which is used to authenticate the sender‘s

(server) domain. To do this, a sender can digitally sign an email for

authentication purposes. Typically, the sender produces a hash value of each

message and encrypts the hash value using the sender‘s private key. The

corresponding public key is published in a DNS text record. When the

recipient‘s mail server receives the email, it extracts the sender‘s domain that

can be found in the ―From:‖ header. Then, it finds the sender‘s public key from

the DNS text record, and finally checks the signature against the email context.

If the signature is valid, the sender is then authenticated. Figure 2.3

summarizes the DKIM protocol processes.


31

This technique has two advantages and one limitation.

Advantages

1- DKIM is a solution for mail forwarding problems. Because this protocol

does not check the IP address in an email, this may confuse the

senderID protocol. However, instead of an IP address, it verifies a digital

signature, which does not change in the case of mail forwarding [6]

2- Before the email reaches its destination, the email contents can be

modified. However, using DKIM protocol, the recipient can verify the

original message content. First, the original message‘s hash value can

be produced by decrypting the digital signature using the sender‘s public

key. Then, using the identical hash algorithm on the current message,

the recipient can get the current message‘s hash value. Finally, if it is not

identical to the original message‘s hash value, the authentication will fail

[6].

Figure 2.3: DKIM technique processes [5]


32

Limitation

1- Sometimes the forwarding services need to modify a message‘s content.

However, as shown above, this modification will result in authentication

fail [6].

2.3. Type 2: Client-Side Solutions

While the previous category of solutions can be applied on the server side,

client-based solutions are designed to work on the Internet users‘ machines.

That is, using plug-ins or browser helper objects (BHOs) which a user can

install to monitor visited web pages, and to warn the users if they have entered

a fraudulent page. These solutions are different in terms of how to determine if

a visited page is fraudulent or not. They can be classified into four groups:

blacklist-based, visual-clue-based, webpage-feature-based and information-

flow-based solutions.

2.3.1. Blacklist-Based Method

The majority of anti-phishing methods rely on a blacklist, a list of known

phishing domains [1]. This method combats the phishing attempts by preventing

user from accessing web pages that appear in the blacklist. To build this list, the

method requires retrieving recent uniform resource locators (URLs) of phishing

pages from specialist websites such as Anti-phishing Working Group (APWG)

and PhishTank, or alternatively may receive these URLs from the users directly.

The techniques of Microsoft SmartScreen Filter [22] and NetCraft Toolbar [23]

make use of blacklists method.


33

Microsoft SmartScreen Filter is integrated with Microsoft Internet Explorer

(version 7 or later). This tool uses two methods to determine the nature of a

page: blacklist checking and heuristics analyses. Basically, when a user visits a

site using Internet Explorer, the SmartScreen Filter will compare a page‘s

contents against heuristics characteristics, which are updated periodically using

machine learning techniques developed by Microsoft. If suspicious properties

are found, the tool will warn the user to avoid providing any confidential data by

causing a yellow shield to appear. However, if the page passes the heuristics

test, the tool will check its URL against a frequently updated online blacklist. If

the URL is found in the blacklist, the page‘s contents will be blocked, and a red

shield will appear in the address bar. The user then has the choice whether to

proceed or to close the page. The tool also checks downloaded files against the

same blacklist, and the later processes will be applied. SmartScreen Filter

provides its user with a reporting feature to notify Microsoft about new

fraudulent URLs. In addition, to decrease the false positive detection rate, this

tool depends only on verified unsafe URLs provided by reviewers at Microsoft or

by employees from third parties. In a network environment, the domain

administrator can use a Group Policy feature to prevent users from overriding

the SmartScreen Filter. This means that users in this network cannot bypass

the warning if it appears, because the option of ignoring such a warning is

disabled, thus the users are more secured [24].

This technique has two advantages and one limitation.


34

Advantages

1- Unlike blacklist-based tools, SmartScreen Filter can protect users from

downloadable malicious files that may be used by phishers to collect

users‘ confidential data, for example keyloggers.

2- By preventing users from overriding SmartScreen Filter, an organization

network administrator may decrease the possibility for users becoming

phishing victims, and hence may protect the organization‘s

confidentiality.

Limitation

1- As with any blacklist-based solution, users are still exposed to new

phishing attacks [1]. That is, the URLs of newly established phishing

sites may not yet be included in the blacklist.

NetCraft Toolbar is another blacklist-based technique provided to Mozilla

Firefox and Internet Explorer users by NetCraft. This tool warns the users

through five labels: ―since‖, ―rank‖, ―country‖, ―host name‖ and ―risk rating‖ (see

Figure 2.4). Each time a user enters a website, the tool will query the NetCraft

Web Server Survey using the website‘s URL to retrieve critical information

about such a website. The tool then shows the website‘s foundation date in the

―since‖ label or prompts ―new site‖ if this website is not found in the Web Server

Survey. New sites are given a high risk rating as most phishing sites have this

property. The ―rank‖ label indicates how many times a website has been visited,

and most visited web pages are considered safe by the method. The ―country‖

label displays the place of a website‘s host server. For example, if a user enters

a barclays.co.uk site, and the country label value is ―China‖, then the user can


35

identify this site as being fraudulent. In the ―host name‖ label, the website

hosting company can be displayed. If the hosting company has a history of

hosting phishing sites, the NetCraft Toolbar will increase the risk rating. The

―risk rating‖ label gives an indication of the danger the users face. The tool

calculates the rating based on several factors including:

1- The age of the website domain, which NetCraft‘s designers consider as

the most important factor.

2- Known phishing sites hosted in the same domain as the current website.

3- The appearance of the legal website‘s hostname, an IP address or a port

number in the current website‘s URL.

4- The history of the current website‘s hosting company regarding hosting

any phishing pages.

5- The history of the current website‘s hosting country with respect to

phishing websites.

6- The top level domain‘s history, for example .biz, regarding hosting any

phishing pages in the past.

7- The current site‘s rank score.

In addition, NetCraft Toolbar enforces the browser to show its address bar in

every window to combat some of the advances in terms of phishing attacks, in

which the address bar is disabled in order to deceive the user. This technique

has one advantage and one limitation.


36

Advantage

1- NetCraft Toolbar copes with DNS poisoning. That is if the local DNS

have been altered. For example, if www.facebook.com, which is

supposed to be hosted in the USA, is assigned to an IP address from

Turkey, the NetCraft Toolbar will display Turkey in the ―country‖ label and

the user can identify the problem.

Limitation

1- Some phishing sites are hosted on compromised servers in which the

domain names of such servers have a clean history in NetCraft Web

Server Survey regarding phishing sites and these domain names have

been registered on the Internet since 2001, for example. As NetCraft

depends heavily on the age property of websites‘ domain names, the tool

will consider these fraudulent sites as trusted sites.

2.3.2. Visual-Clue-Based Method

Visual-clue-based method applies the idea of using images as a base for the

solution to combating phishing attacks. This method relies on the fact that

phishing attackers try to lure users by imitating visual features of target

websites. This method tends to use images as authentication evidences that the

Figure 2.4: NetCraft Toolbar [23]

http://www.facebook.com/


37

server should present. Dynamic security skin [25] and Visible Watermarking [26]

are two visual-clue-based techniques.

Dhamija and Tygar proposed a technique called dynamic security skin [25]. In

their design, a user needs to remember only one simple password throughout

the whole session, and performs two image matches in order to authenticate a

remote server. Basically, for the first time, the user selects one image from a list

as a background to the login window. The authors call this the trust password

window. This image proves to the user that the window knows the shared

secret. The authors adopted the Secure Remote Password protocol (SRP) to

achieve a mutual authentication between the user and the remote server, in

which the two parties do not have to share a secret password. To do this, the

user first chooses a password, a random salt and performs a one-way function

to generate the verifier. This verifier and the salt should be sent to the server,

which will store this information and consider the verifier as the user‘s

password. To access the server, the user provides his or her username, and the

server finds the corresponding verifier and salt. Then the user‘s browser and the

server separately generate two random values and exchange them. Then, using

the random values and the verifier, each party separately computes an identical

session key and generates a hash value of this session key. After that, each

party sends each other the hash value of this session key and the random

values exchanged earlier. At this stage every party has proved to each other

that it knows the shared secret. However, the user needs to identify an

authenticated web page. The authors propose the idea of automated custom

security indicators in which random generated images are used. In the last

stage of the authentication, the server generates the hash value of the session


38

key. The server can use a visual hash algorithm, Random Art, which takes this

hash value and generates a random mathematical formula that determines a

color value for every pixel in an abstract image. Using the same hash value, the

user‘s browser can generate the same abstract image. Then, the browser

presents this image, for example as a window‘s border, on the trusted password

window. Similarly, the server presents the same image on its webpage. The

user then compares the two images on the trusted password window and the

server‘s webpage. If there is a match, then he can trust the server‘s webpage.


Advantage

1- The proposed technique provides the server with a way to prove its

identity which is easy for a user to recognize, as he or she only needs to

perform two image matches, and it is hard for an attacker to spoof since

the attacker has neither the verifier nor the random values [1].

Limitations

1- This technique requires the user to have some knowledge of phishing

attacks and how to identify spoofed pages in order to distinguish

between an authentic and a spoof webpage. As a result of the leak

knowledge, more than 20% of users ignore webpage‘s visual clues and

even professional users may be victims of visual-based attacks [27].

2- This solution is vulnerable to the visual man-in-the-middle-attack [25].

That is, an attacker may be able to create a pop up fraudulent window on

the front of an authenticated window and the trust password window.


39

Topkara et al. [26] proposed another technique called visible watermarking

(ViWiD). It is an integrity check technique in which the user needs to verify a

watermark within the company webpage‘s logo to authenticate this webpage.

This watermark consists of two parts: a shared secret, which the user selects at

the registration stage in a secure manner, between the user and the company‘s

sever, and the current date and time of the user‘s time zone determined by the

IP address of the user‘s machine. This watermark is designed to be unique for

every user in order to combat a ―one size fits all‖ attack. The company‘s logo

can appear to the user in two ways: after the user login into his or her account,

or by using a cookie. The last choice is preferred since the user need not to

enter his or her confidential data on the login webpage to avoid revealing this

data on a forged webpage. The user can trust the server‘s webpage since its

logo includes the shared secret. The process of adding the watermark to the

company‘s logo is done on the company web server, and the user need not

install any tool or store any data on his or her local machine. This technique has

two advantages and two limitations.

Advantages

1- If the user prefers to use cookies to access sensitive web pages through

ViWiD, the chance of attackers stealing his or her confidential data is

significantly reduced.

2- Since the watermark is different for each user at a specific time, and

includes a shared secret between the user and the company, it is hard to

design a fraudulent webpage that displays the correct watermark for

each user.


40

Limitations

1- This technique requires the user to be involved in the verification

process.

2- The users have to be trained to expect what information should appear in

the company‘s logo in order to distinguish between real and fake

webpages.

2.3.3. Webpage-Feature-Based Method

Another method depends on analyzing the webpage‘s contents to find fraud

symptoms, and then warning the user of a potential phishing attack. A number

of techniques adopt this method have been proposed, for example SpoofGuard

[6] and a framework for the detection and measurement of phishing attacks [8].

Chou et al. [6] proposed and implemented a technique called SpoofGuard to

mitigating simple phishing attacks. Typically, when a user visits a webpage,

several evaluations on this webpage and a check on outgoing post data will be

applied to compute a webpage‘s spoof index or a total spoof score (TSS). If this

spoof index is greater than a threshold which has previously been specified by

the user, it indicates that such a webpage is a spoof and the user will be

warned. Some of these evaluations are done after downloading the webpage:

URL, link, image and domain checks. In addition, some evaluations are

conducted when the user interacts with such a page: password, outgoing

password, referring page, outgoing post data checks. Table 2.3 summarizes

these evaluation functions.


41

Table 2.3: A summary of SpoofGuard‘s evaluations functions

Check type Function

URL If a webpage‘s URL includes ―@‖ or an IP

address, then increase the spoof index

Link If 25% of a webpage‘s links fail an URL check

then increase the spoof index

Image If an image on a webpage is in imageDataBase,

then check if the two images are associated with

different domains, then increase the spoof index

Domain If a webpage‘s host domain is similar to a host

domain in the history file or in commonly spoofed

sites file, then increase the spoof index

Password If a function of a webpage requests the user‘s

password and this webpage does not use

HTTPS, then increase the spoof index

Outgoing password When the user enters a password on a webpage,

a hash value of this password and the webpage‘s

host domain will be compared against a

database. This includes hash values of previous

entered passwords and their corresponding

webpage‘s host domain. If there is a password

match with a different host domain, then increase

the spoof index and warn the user

Referring page If the user is redirected to a webpage, then check


42

if the referring page is an email provider, then

increase the spoof index

Post data If a webpage‘s function requests any data, then a

hash value of the data and the webpage‘s host

domain will be compared against a database.

This includes hash values of previous entered

passwords and their corresponding webpage‘s

host domain. If there is a password match with a

different host domain, then run password check

This technique has three advantages and two limitations.

Advantages

1- If this method is adopted by the majority of Internet users, the phishing

attackers will need to develop more sophisticated attacks [25].

2- Such a method presents high accuracy rates (90%) when it comes to

identifying phishing pages [9].

3- This method provides a user with a monitoring system without requiring

user involvement.

Limitations

1- As this method is developed to address simple phishing attacks, it can be

fooled using sophisticated phishing attacks such as Cross-Site Scripting

(XSS) [10]. That is, using a script code, an attacker can construct input

forms in order to gain user confidential data.


43

2- SpoofGuard has a relatively high false alarm rate [9][11]. That is,

identifying a number of genuine websites as fraudulent.

Garera et al. [8] proposed a technique for the detection and measurement of

phishing attacks which depends heavily on analyzing URLs to distinguish

between benign and phishing web pages. In this solution, a logistic regression

filter takes a URL as its input, and applies 18 URL feature tests to determine the

webpage‘s nature, whether it is benign or phishing. The authors collected most

of these features from some Google infrastructures such as the White Domain

Table and Google‘s index infrastructure. The URL feature tests can be

classified into four types: page-based features, domain-based features, type-

based features and word-based features. Then, they use the Weka data mining

library to analyze 2,508 URLs (1,245 phishing and 1,263 non-phishing) using

the logistic regression algorithm. From this experiment they obtained the

coefficients of the 18 URL features (see Table 2.4). From these results, the

authors found that ―host obfuscated with IP‖ and ―White Domain Table‖ are the

most useful features to identify phishing ULRs. The authors claim that their

method has an accuracy rate of 97.31% with a true positive rate of 95.8% and a

false positive rate of 1.2%.


44

Table 2.4: The 18 URL features and their coefficients

Feature Logistic

coefficient

Odd Ratio

ecoefficient

Is URL in White Domain Table? -3.82 0.0219

Quality Score II -1.9543 0.1417

PageRank of Host -1.8812 0.1524

PageRank of URL -1.2606 0.2835

PageRank in Crawl Database -0.536 0.5851

Quality Score I 0.0443 1.0453

Number of characters after organization in host 0.2306 1.2594

Word secure presence 0.3328 1.3949

Word account presence 0.8589 2.3605

Is Page in Index? 0.8738 2.3961

Word webscr presence 0.9969 2.7099

Word login presence 1.8587 6.4155

Word ebayisapi presence 2.1659 8.7221

Word signin presence 2.5404 12.685

Word banking presence 2.6361 13.9593

Word confirm presence 2.7586 15.777

Is target organization in path but not in host? 2.9464 19.0378

Is host obfuscated with IP? 6.3933 597.8151

Constant -0.5881


45


Advantage

1- Like SpoofGaurd, this method provides a user with a phishing

detection solution without requiring user involvement.

Limitations

1- As this method tries to identify phishing pages based on heuristics

texts, it could not stop Man-in-the-Middle Attacks [12]. For example,

an attacker may use a Man-in-the-Middle Phishing Kit to serve as a

proxy between the user and the provider site [13].

2- For sophisticated attackers it is easy to bypass this detection method

[11].

2.3.4. Information-Flow-Based Method

Information-flow-based method tries to protect users from being victims of phish

attacks by tracking their sensitive information to make sure that they provide

this information on trusted websites. A user will be warned, if she is about giving

away her confidential data on fake websites. One technique that follows this

method is AntiPhish [42]. This technique detects phishing by examining the

current webpage‘s domain when a user starts to enter sensitive data.

The AntiPhish technique‘s main purpose is to protect users‘ confidential data.

This can be done by monitoring where the users‘ confidential data is been

entered and warning the user in the case of a phishing attack. Typically, when a

user enters confidential data in a web page‘s form for the first time, she may ask

AntiPhish to capture this data and stores it in an encrypted form. AntiPhish uses


46

the DES encryption algorithm to encrypt users‘ confidential data by a master

password. AntiPhish also stores a web page‘s domain to be mapped with the

user data. AntiPhish uses a domain rather than a web page‘ address because

some websites are hosted in more than one server. However, if AntiPhish uses

the address, false attack detection may be triggered. The user needs to provide

the master password the next time in order to automatically fill in the previous

web page‘s form. To monitor the users‘ confidential data, AntiPhish examines

text field elements of any form in a web page and interrupts any user event. If

the user interacts with a text element, AntiPhish will compare the element value

against a list of previous stored user‘s confidential data. If it finds a match,

domains comparison will started. If there is no match, AntiPhish will consider

the current webpage as phishing. AntiPhish runs same test if the user

generates events on text elements: press a key, load new page, click or focus.

JavaScript gives an attacker the ability of accessing form‘s text elements before

a user submits inputs. To combat this problem, AntiPhish deactivates

JavaScript if the focus is on a text element and reactivates it when the focus is

lost. AntiPhish has two advantages and two limitations.

Advantages

1- AntiPhish may reduce the false positive rate by using the web page‘s

domain rather than the address in mapping user‘s confidential data.

2- AntiPhish provides an effective method to combat event-based

JavaScript attacks and permits legitimate event-based JavaScript

functions in the same time.

Limitations

1- The user needs to inform AntiPhish to capture her confidential data.


47

2- Key-press JavaScript functions are not allowed by AntiPhish, since it

prevents such functions.

2.4. The Best Way Forward

In order to mitigating the identity theft problem in the future it is important to

address new security threats. These threats may result from vulnerabilities in

new development technologies, for example URL shortening, or from new

phishing techniques. These techniques are: page load attack, HTML

attachment, Tabnabbing. Unfortunately, there is no solution have been

proposed in literature or industry to address these threats. For this reason, the

focus of this work will be on these security threats and on proposing a

framework to mitigate the expected resulting problems.

2.5. Chapter Summary

In this chapter a verity of proposed anti-phishing solutions both in literature and

in industry have been discussed and critically analyzed in order to show their

advantages and limitations. Most of these solutions are leading in the anti-

phishing field. From the discussion, it was clear that all of these solutions can

stop some phishing attacks but not all attacks. In addition, attackers have

developed new phishing techniques, for example tabnabbing. This project tries

to address some of these techniques‘ threats.


48

Chapter 3. SpoofGuard++ Design


This chapter describes the high-level design of an anti-spoofing solution,

SpoofGuard++. An overview of the proposed solution is provided. A basic set of

requirements are introduced such that the solution should achieve them in order

to make this solution acceptable by Internet Explorer users. A description of the

architectural design of the solution, its architectural components and the user

interface are provided.

In details, this chapter is structured as follows. Section 3.2 provides an overview

of SpoofGuard++. Section 3.3 presents requirement specifications of the

proposed solution. Section 3.4 describes the architectural design of this

solution. Finally, section 3.5 summarizes the SpoofGuard++ design.

3.2. SpoofGuard++ Overview

SpoofGuard++ is a solution developed to help Internet Explorer users identify

phish web pages that they may visit. The proposed solution is transparent to the

users, i.e. it does not require the user to be involved in the process of detecting

phish pages. Thus, this solution can be used by expert and non-expert Internet

users. To use this solution, the user is required to install the solution‘s toolbar to

Internet Explorer (version 4 and later). Then, while surfing the Internet, the user

only needs to check the color that appears on the SpoofGuard++ toolbar. The


49

purpose of this color is to indicate the danger level of the current page, i.e. red

(danger), yellow (suspicious) or green (safe).

The name of the proposed solution, SpoofGuard++, is adopted from the original

SpoofGuard, which is a well-known solution in the literature. This solution

proves its ability to combat simple phishing attacks [9]. As a result, checks

proposed by SpoofGuard will be adopted in the proposed solution. The

proposed solution applies a variety of checks on the current page in order to

distinguish between a phish and a normal page. Some of these checks are

modified versions of the adopted checks. These modifications are made to

provide better resistance against simple phishing attacks. In addition to these

checks, a variety of proposed checks have been added to address the concern

of sophisticated and new phishing attacks. A combination of these checks is

used to form the proposed solution.

3.3. Requirement Specifications

In order to obtain good design system requirements, a collection step is

needed. These requirements can be collected by performing two activities:

previous work analysis and new phishing threats investigation. The previous

work analysis, or literature review activity, is important to gain thorough

understanding of the phishing problem. An investigation into the activity of new

phishing threats is needed to obtain good knowledge of the recent phishing

attacks that need to be addressed. After obtaining the system requirements, the

design step can commence. The main purpose of the design step is to convert


50

the system requirements into a conceptual form that can be implemented using

a programming language.

In light of the literature review and new phishing threats investigation activities,

the main requirements of the proposed system are functionality, small false

detection rates, and performance.

Functionality requirements: The proposed system should be able to detect

simple and sophisticated phishing attacks through its functions. These functions

should include:

1- Enhanced checks of SpoofGuard: Attackers can fool some of SpoofGuard‘s

checks [6]. These functions are URL, image and links checks.

2- The ability to detect URL-shortening threat: The URL-shortening service is

developed to avoid using long URLs. This service enables Twitter and Identi.ca

users to exchange messages in which the usage of URLs is limited to 140

characters per message. However, this service provides attackers and

spammers with an ability to bypass protection techniques, such as URL blacklist

check [30]. Using this service the attackers are able to redirect unsuspecting

users to malicious sites in order to gain users‘ confidential data. The proposed

solution should be able to effectively detect such a threat.

3- The ability to detect HTML attachment attack: Attackers have found a new

way to bypass blacklist-based anti-phishing tools in modern browsers by using

HTML attachments rather than URLs in their fake emails [31]. The proposed

http://en.wikipedia.org/wiki/Identi.ca


51

solution should be able to check such attachments in order to address this

threat.

4- The ability to detect tabnabbing attack: Tabnabbing is a new phishing attack

in which the contents of a web page can be changed after the user has left it

open for a while [32]. This attack can be performed using a simple JavaScript

code. The proposed solution should be able to detect such as attack.

Small false detection rate requirement: In order to provide Internet users with

a useful phishing monitoring system, SpoofGuard++ should produce false

attack detection as little as possible.

Performance requirement: The proposed solution is an Internet Explorer

extension. The functionalities of this solution should not degrade the

performance of Internet Explorer, i.e. web-page access time.

3.4. SpoofGuard++ Architectural Design

This section gives the reader a thorough understanding of how SpoofGuard++

works. It consists of three subsections: an overview of SpoofGuard++‘s

architecture, architectural components, and user interface.


52

3.4.1. Architecture Overview

In order to perform checks, SpoofGuard++ needs to deal with the Internet

Explorer history file and two other files, i.e. hashed password history and

hashed image history, which this solution creates and maintains on the user‘s

machine. Domains list in the Internet Explorer history file and commonly

spoofed sites list are used to create a domain white list. Domains in the browser

history file have been visited by the user; thus, users are assumed to have a

reason to trust these domains. In order to reduce the number of false alarms,

warning messages will not be raised when the user is visiting such domains.

There are two reasons why commonly spoofed sites are added to the domain

white list. First, most phish attackers target specific sites [44], e.g. PayPal and

HSBC. Second, legitimate sites are sometimes wrongfully considered as

spoofed sites when the user visits a legitimate site after visiting a similar

spoofed one; this is one problem with the original version SpoofGuard [9].

The hashed password history file maintains a record of each password entered

by the user. Each record consists of three fields: domain, username and

password hashed value. All passwords in the hashed password history file are

hashed using the SHA-1 algorithm to stop sensitive information from leaking.

The hashed image history file keeps records of logos and images of commonly

spoofed sites (e.g. PayPal) because most phish attackers target specific sites

(e.g. PayPal and HSBC) and construct pages that include images taken from

them [3]. Each record consists of two fields: domain and image. The hashed

image history file maintains hashed values of the images, using the MD5

algorithm, rather than keeping actual images to minimize the total file size. In


53

addition, the proposed solution performs a reverse DNS lookup to gain domain

names for numeric IP addresses; however, it never forwards the user‘s

sensitive information (e.g. password) to any external site. Hashed password

history and hashed image history files can be reset using a button on the

toolbar.

3.4.2. Architectural Components

SpoofGuard++ consists of three main components: SpoofGuard_Toolbar,

User_Setting and Page_Status. The first component performs most of the

proposed solution work, while the other components are used for user

interaction purposes. Figure 3.1 shows SpoofGuard++ architecture.

Figure 3.1: SpoofGuard++ architecture

SpoofGuard_Toolbar

Page_Status User_Setting

Requests to pop up

‘current page’ status

Requests to pop up ‘user

setting’ window


54

3.4.2.1. SpoofGuard_Toolbar Component

This is the main COM component of the SpoofGuard++ solution which

implements the main functions and checks of the solution. This component is

also responsible for showing the solution toolbar and maintains user settings at

runtime. These settings are used as inputs of the processes of warning the user

such as setting the color of the traffic light on the toolbar and producing warning

messages, which can be seen on page status dialog. In order to implement

SpoofGuard_Toolbar, there are two methods that can be adopted: Blacklist-

Based and Web-Page-Feature-Based methods.

3.4.2.1.1 Blacklist-Based Method versus Web-Page-Feature-

Based Method

Since detection of spoof attacks is the main factor of judging anti-spoofing

methods, both methods need to be investigated. The Blacklist-Based method

tries to combat phishing attacks by preventing the user from accessing web

pages that appear in a blacklist (refer to section 2.3.1 to read more). The Web-

Page-Feature-Based method depends on analyzing a web page‘s contents to

find fraud symptoms and then warning the user of potential phishing attacks

(refer to section 2.3.3 to read more).

Y. Zhang et al. [9] conducted a study on a number of existing anti-spoofing tools

that are a combination of Blacklist-Based and Web-Page-Feature-Based

solutions. In their study, half of the Blacklist-Based solutions could detect a

number of phish pages, whereas most of the Web-Page-Feature-Based


55

solutions could detect a significant number of phish pages. Their study suggests

that Blacklist-Based solutions require massive amounts of information to be

gathered periodically in order to provide accurate results. On the other hand,

Web-Page-Feature-Based solutions just apply a number of checks without the

need to update any information. The study also found that some Blacklist-Based

solutions forward URLs, entered by the user, to central blacklist servers. This

action may be considered as a user privacy breach. In contrast, most of the

Web-Page-Feature-Based solutions do not need to send the user‘s sensitive

information (e.g. password or URL) to any external site. In addition, attackers

have recently developed new techniques to fool Blacklist-Based solutions, such

as Cross-Site Scripting (XSS) [29], URL shortening [30], HTML attachment [31]

and tabnabbing [32]. However, most of these techniques may not be able to fool

most of the Web-Page-Feature-Based solutions because these solutions

examine pages‘ contents and then are able to detect such phish tricks.

Therefore, the Web-Page-Feature-Based method is selected to implement the

SpoofGuard_Toolbar component.

3.4.2.1.2 Web-Page-Feature-Based Method

In order to determine the current page status—spoof or normal—several checks

need to be applied. Any visited page will be examined using these checks. The

results of these checks are used to calculate the page‘s total spoof score (TSS),

which is a measurement used to decide whether a visited page is part of a

phish attack. Most SpoofGuard++ warning messages are passive. This means

in crucial situations, when the traffic light color is red, the toolbar will pop up a


56

warning message to the user. In less dangerous situations, when the traffic light

color is yellow or green, the user is enabled to press on the traffic light button to

pop up a page status window. The toolbar uses passive indication to avoid

bothering the user.

The proposed solution conducts different checks (C1, C2, .., C10). Each check

(Ci) results in a number (Ri) in the range [0, 1]. Ri=1 means the current page

may be a spoof, whereas Ri=0 means it is a normal page. The majority of these

checks provide a value of 0 or 1, and some checks provide a value between 0

and 1. The resulted values are added to provide a TSS using the equation 3.1

below:

………………

… …

…

(Equation 3.1: Total spoof score (TSS) calculation)


57

Each indicates a single check‘s weight, which is predefined and used to

reduce the false alarm rate. The calculation equation is adopted from intrusion

detection systems and spam filters [43]. This equation aggregates a number of

sums. Each one can be a sum of individual results ( ), sum of products of pairs

( ) or triples ( ) or a larger number of results ( … ). The

product operation is used because when a certain set of events happens, the

probability of a visited page being a spoof raises significantly. For instance, if an

organization‘s logo is found on a suspicious page, and if the password and

credit card fields are found on the same page, this page should be considered

as a spoof and its weight should be large. SpoofGuard++ carries out two rounds

of checks. Checks at the first round are triggered before the browser navigates

to the attempted URL, and checks at the second round are triggered after the

browser successfully loads the attempted page or after the default time-out has

occurred. In addition, if the Internet Explorer tries to load a local HTML

document, second-round checks will be applied on such a document to protect

the user from the HTML attachment attack.

3.4.2.1.2.1. First-Round Checks

In the first-round checks, domain, URL, email and outgoing post data checks

are done. These checks will not be performed if the current domain is founded

in the domain white list. Otherwise, If the sum of results of these checks is equal

to or greater than the Total Alert Level, a threshold level which distinguishes

between a spoof and normal page, the user will be warned not to navigate to

the attempted URL and the traffic light color will be set to red. In addition, if the


58

current page requests a password and the sum of results of the first-round

checks is less than the Total Alert Level, the user password information, i.e.

domain, username and password hashed value, will be added to the hashed

password file. The following are descriptions of first-round checks.

Domain Check

In this check, the domain name of the attempting URL is examined to determine

whether the current page is part of a spoof attack. This check makes use of the

domain white list. The domain name of the entered URL is compared with

domains in the domain white list. If the entered domain name is similar to one in

the list, the entered domain will be identified as spoof and the TSS of this page

will be increased. For example, if the entered domain (www.netwest.com) is

compared with the history (www.natwest.com), the entered domain will be

considered as spoof—notice the difference at the second letter ‗e‘ and ‗a‘,

respectively. The previous check is important because attackers often construct

fake URLs with spelling mistakes [50]. SpoofGuard++ calculates the similarity

between domains using the Hamming (edit) distance [45]. The Hamming (edit)

distance between two domains is the number of substitutions required to

change one domain into the other, as seen in the previous example.

URL Check

The rest of the attempting URL is examined by the URL check. In this check,

five different tests are performed. The first, second and third tests are adopted


59

from SpoofGuard [3], whereas the fourth and fifth tests are proposed by Garera

et al. [8]. The first test is used to combat an embedded username attack. In this

attack, the attacker forms a URL that has a username and hostname using the

‗@‘ symbol, e.g. ([email protected]). In this URL, the

username (www.ebay.com) contains ‗www‘ and ‗com‘, which are used to

persuade the user that he is visiting the eBay web site. The TSS of the

attempting page will be increased if the username contains ‗www‘, ‗com‘ or any

top level domain keyword. The previous URL has another trick: The hostname

(999.888.222.111) of the attempted URL does not include ‗www‘, ‗com‘ or any

top level domain keyword. This is used by attackers to hide the real hostname.

The second test is used to reveal such a trick, i.e. the TSS of the attempting

page will be increased if the hostname does not contain ‗www‘, ‗com‘ or any

similar keyword. The third test is used to check whether the attempted URL is

using a non-standard web port number (e.g. http, https, ftp, gopher, socks). A

non-standard web port number in a URL means the spoof page may be hosted

on a third-party machine that is already compromised [46]. For instance, the

URL (www.ebaw.com:123) is considered as misleading. The fourth test is used

to address obfuscating the host with another domain attack. In this attack, the

URL is formed so that it has a normal domain name and the name of the

organization being imitated appears in the rest of the URL, e.g.

(www.mybank.com/HSBC.co.uk/index.html) [8]. This test checks the attempted

URL against the commonly spoofed sites list. The previous URL will be

considered as misleading because the keyword ―HSBC‖ appears in the URL

path but not in the domain name. The last test is used to recognize obfuscating

the URL with a large-hostname attack. In this attack, the name of the


60

organization being imitated appears in the URL‘s hostname and a large number

of characters appear after the domain name, e.g.

(www.paypal.com.redirector.webservices.aktuell.lasord.info/) [8]. This test

compares the attempted URL with the commonly spoofed sites list. If one

domain name is found in the hostname of the attempted URL and the number of

characters after the domain name is greater than zero, the URL will be

considered as misleading. In the previous example, there are 43 characters

after (www.paypal.com).

Email Check

The email check examines the attempting URL to find out whether the

attempting page is launching from a web-based email site, since the majority of

phishing attacks start by sending fake emails to a large number of Internet

users [47]. This check simply retrieves the value of the referring page field of

the Internet Explorer browser. If this value indicates a web-based email site,

e.g. Hotmail, Yahoo or Gmail, the TSS of the attempting page will be increased.

Regarding the Hotmail site, the value of the referring page field may be a

numeric IP address instead of a hostname. In this case, the email check will

perform a reverse DNS query to retrieve the corresponding hostname.

Outgoing Post Data Check

The outgoing post data check is used to intercept HTML post requests and

prevent sending the user‘s sensitive information to a non-trusted destination.


61

This check may stop a smart phishing attack. That is, an attacker is able to set

the name attribute of an image tag to be the user password and send that

attribute value via an HTML post [3]. To prevent such an attack, each outgoing

data in an HTML post can be hashed, using the SHA-1 algorithm, and

compared with passwords in the hashed password history file. If there is a

match, the domain name of the current page will be compared with the

password-associated domain name. If they are different, it means the user is on

a suspicious page and the HTML post request will be cancelled. Using this

check, SpoofGuard++ is able to recognize password leakage even if the

suspicious page does not use the term ‗password‘.

3.4.2.1.2.2. Second-Round Checks

In the second-round checks, password, links, image, and tabnabbing checks

are done. These checks will be applied if the current page is not found in the

browser history file; otherwise, none of these checks is needed. These checks

are applied after the browser loads the attempted page or after the default time-

out has occurred. The default time-out is used to address the page load attack

[9]. In this attack, the attempted page takes an extremely long time to load.

During this period, the user may enter his or her sensitive information. The

following are descriptions of second-round checks.


62

Password Check

Password check is used to examine the current web page, which is parsed by

the browser, to find HTML input fields of a type password. Web pages that deal

with password or sensitive information should be encrypted, i.e. an authenticate

web protocol should be used such as SSL, in order to protect user-supplied

credentials [48]. The appearance of one or more password-type fields does not

mean the page is suspicious; instead, SpoofGuard++ will be more concerned

about this page and will reduce its Total Alert Level and will check whether the

SSL protocol is used. If the SSL protocol is not used, the TSS of the attempting

page will be increased. Likewise, if there is a password-type field on an

unencrypted frame, the same action will be performed.

Links Check

This check tests links on an attempting web page. Typically, phish attackers

construct fake pages or emails that contain at least one bad link. The visible

address in this link is valid; however, if a user clicks on such a link, it would take

him or her to a different address, which is suspicious [49]. For example, an

attacker may send an email message that includes a link such as

(www.adwords.google.com/select/login), which is a correct login address for

Google AdWords. This link, in fact, would redirect the user to

(www.adwords.google.com.zxcffdg.cn/select/login), which is suspicious—notice

the number of characters (.zxcffdg.cn) after the valid domain

(adwords.google.com). Another issue about links is the usage of URL

shortening, which helps attackers to obfuscate phish links [30]. The links check


63

can examine the attempting web page to find links. For each link, the links

check will perform a URL check on the actual address. In addition, the visible

address of each link will be checked against a list of URL-shortening provider

names [28]. If at least one-fourth of these links fail the links check, the TSS of

the attempting page will be increased.

Image Check

The image check contributes in identifying phish pages by comparing each

image on the current page with each image in the hashed image history file to

detect fake images and logos on web pages that request users‘ passwords, e.g.

login pages. This comparison is done using hash values of the images using the

MD5 algorithm. If the comparison result is positive, both images‘ domain names

will be compared; if they are different, the TSS of the attempting page will be

increased. SpoofGuard++ associates the image check with the outgoing

password check in calculating a page‘s TSS. That is, when a user types a

username and password of a PayPal account, for example, on a spoof page,

this page‘s TSS will be increased by a specific amount, i.e. the outgoing post

data check weight. The page‘s TSS will be increased multiplicatively higher if

the spoof page also includes a PayPal logo.

Tabnabbing Check

The tabnabbing check is used to warn the user of the tabnabbing attack. In this

attack, an attacker creates a normal page and attaches a few JavaScript lines


64

to an HTML code [32]. The JavaScript code is used to change the current

page‘s contents, title and favicon (i.e. the page icon) to different contents that

are similar to a trusted site (e.g. Hotmail) [29]. This code is triggered when a

user leaves the Internet Explorer tab that contains the malicious page. To stop

such a clever attack, all JavaScript lines associated with a visiting page are

tested to detect any possible tabnabbing attack. This is done by searching the

JavaScript code to find certain keywords that are used for this attack, namely

‗SETTIMEOUT‘ and ‗ONBLUR‘. If these keywords are found, the TSS of

attempting page will be increased.

3.4.2.2. User_Setting Component

This component handles the user settings dialog. This component maintains a

variable value for every field of the user settings dialog (e.g. URL check weight).

Each time the user presses on the setting button on the toolbar, the

SpoofGuard_Toolbar component initialises a new instance of user settings

dialog and assigns the dialog variables to the current user settings, which are

retrieved from the registry. Any event fired by the user settings dialog at runtime

(e.g. changing textbox contents) is controlled by the User_Setting component,

which maintains the latest values of the dialog fields. Any change that happens

at the user settings dialog forces SpoofGuard++ to recalculate the attempting

page‘s TSS, and then warning messages on the page status dialog will be

updated. The new values of the setting dialog fields will be sent to the

SpoofGuard_Toolbar component when the user closes this dialog.


65

3.4.2.3. Page_Status Component

This component handles the page status dialog. The page status dialog is a

simple dialog that merely shows the user the complete warning message

regarding the currently visited page. Each time the user presses on the current

domain status button (i.e. traffic light) on the toolbar, the SpoofGuard_Toolbar

component initialises a new instance of page status dialog. The Page_Status

component controls the page status dialog to set the warning message to the

dialog when the dialog is created.

3.4.3. User Interface

After the SpoofGuard_Toolbar component is initialized, three buttons are

established and registered: current domain status, i.e. traffic light, setting and

reset history information (see Figure 3.2). The traffic light reflects the danger

level of the current page, i.e. red (danger), yellow (suspicious) or green (safe).

When the user presses the traffic light, the page status dialog will be triggered

(see Figure 3.3). This dialog shows the user detailed information about the

current page. The setting button triggers user settings dialog. The last button is

used to delete records in the hashed password history and the hashed image

history files.

The user settings dialog, shown in Figure 3.4, enables the user to change the

default setting of the toolbar, i.e. Total Alert Level and the weights and

sensitivity of hostname, URL, password, links, image, email referral, and


66

tabnabbing checks. The user can stop warning messages, set history cache,

stop image hash caching and disable password protection.

Figure 3.3: SpoofGuard++ page status pop up

Figure 3.2: SpoofGuard++ toolbar


67

Figure 3.4: SpoofGuard++ setting pop-up


68


This chapter has shown the high-level design of SpoofGuard++ and has

provided proposed solution requirements. In addition, the three main

components of the solution—SpoofGuard_Toolbar, User_Setting and

Page_Status—have been demonstrated. Two rounds of checks have been

introduced to mitigate the spoof problem. The first-round check applies several

checks to every URL of the attempting page before navigation and gives an

initial judgment on that page. The second-round check conducts additional

checks on HTML contents of the attempting page and provides a final judgment

on that page. The proposed solution provides three new features, tabnabbing

detection, domain white list, and page default timeout in which they may help in

reducing false positive rate. In the next chapter, code-generation issues of

these two rounds of checks will be discussed.


69

Chapter 4. SpoofGuard++ Implementation


This chapter focuses on the implementation issues of SpoofGuard++

development. It discusses the implementation platform to which the anti-

spoofing toolbar integrates. A comparison among alternative programming

languages that are used to translate system design into a working system is

given in this chapter. The implementation and code generation of the proposed

solution will be discussed, along with development difficulties and challenges.

This chapter is structured as follows. Section 4.2 discusses the implementation

platform. Section 4.3 gives a comparison between alternative programming

languages. Section 4.4 provides a low level design of the proposed solution.

Section 4.5 describes the implementation difficulties and Section 4.6 summaries

the chapter.

4.2. Implementation Platforms

Since the majority of users surf the Internet using Microsoft Internet Explorer

(version 4 and later) [33], this platform was selected to host the proposed anti-

phishing toolbar. To integrate this toolbar into the Internet Explorer, the

development of a Browser Help Object (BHO) was needed. A BHO has two

advantages: its flexibility and its continuity [33]. Native Windows codes can be

involved within a BHO, since a BHO is an independent Windows thread. This


70

provides developers with direct ways to create processes, files, and network

connections, in addition to the ability to invoke an existing code. A BHO also

benefits from Internet Explorer support. That is, a BHO can work perfectly in the

current Internet Explorer version, and also in the later versions.

4.3. Programming Languages

Microsoft has proposed the .NET framework for any high level code (for

example C#, VB.NET, C++) compiled into a Common Intermediate Language

(CIL) [33]. The resulting code is called a managed code. This managed code is

executed inside a sandbox component, which prevents the code inside it from

calling any code outside of the .NET framework. This technology provides a

safe implementing environment. To implement the proposed toolbar, C# or C++

programming languages can be used. Writing a code using C# is easier than

using C++, because, for example, one statement in C# may represent several

statements in C++ [39]. For these reasons the .NET framework and the C#

programming language have been selected to implement SpoofGuard++.

4.4. SpoofGuard++ Low Level Design (SpoofGuard_Toolbar)

SpoofGuard++ is an Internet Explorer (version 4 and later) toolbar or Browser

Helper Object (BHO). A BHO is a COM component that can be integrated with

Internet Explorer, and is triggered when the browser starts. That means a BHO

can use the same memory as the browser. In addition, a BHO has the ability to

control Internet Explorer components. That is, a BHO may edit menus and


71

toolbar settings in the browser, detect and respond to browser events, and open

new browser windows. The main class of the proposed toolbar is

SpoofGuard_Toolbar. Following are implementation details of this class.

This class performs two tasks: showing the toolbar, and applying all checks, as

described in section 3.4.2.1. To show the toolbar on Internet Explorer, two

variables, pvaClsid, and pvarShow, should be set and used in the following

statement:

InternetExplorer.ShowBrowserBar(pvaClsid, pvarShow)

pvaClsid is a string value of the globally unique identifier (GUID), for the toolbar,

while pvarShow is a Boolean value that indicates whether or not to show the

toolbar. The method ShowBrowserBar is responsible for sending these values to

the Internet Explorer COM component to establish a browser bar. This class

initiates a user setting dialog using the following statements:

User_Setting setting_Dialog = new User_Setting(setList);

setting_Dialog.ShowDialog();

The setList is an integer list of user setting. This class also initiates a status

page dialog using the following statements:

Page_Status status_Dialog = new Page_Status(warningMessage);

status_Dialog.ShowDialog();

In order to perform the checks, the SpoofGuard_Toolbar class needs to retrieve

current user settings (checks, weights, etc) from the registry upon initiating the

toolbar, using the method readUserSetting(). When the toolbar is terminated,


72

the user setting is sent to the registry using the method writeUserSetting().

This class implements two main COM interfaces: IObjectWithSite and

IDeskBand as following:

public class SpoofGuard_Toolbar : IObjectWithSite, IDeskBand {...}

The IObjectWithSite interface provides a simple way to support

communication between the toolbar and Internet Explorer, while the interface

IDeskBand is used to get information about the toolbar, such as the view mode.

The main method in the IobjectWithSite interface is SetSite. The SetSite

method triggers SpoofGuard_Toolbar and registers Internet Explorer with the

toolbar. The SetSite method is invoked by Internet Explorer upon starting and

passes SpoofGuard_Toolbar a pointer to Internet Explorer. At this point the

toolbar should invoke its methods readUserSetting() to get user settings, and

createWhiteList() to create the domain white list. Internet Explorer unregisters

the toolbar by invoking the SetSite method again before it terminates the

toolbar. The SetSite method also adds the handlers of two events,

BeforeNavigate2 and DocumentComplete, to the SpoofGuard_Toolbar class

using the WebBrowserEvents2 interface as follows:

webBrowserEvents = webBrowser as DWebBrowserEvents2_Event;

webBrowserEvents.DocumentComplete += new

DWebBrowserEvents2_DocumentCompleteEventHandler(webBrowserEvents_Docum

entComplete);

webBrowserEvents.BeforeNavigate2 += new

DWebBrowserEvents2_BeforeNavigate2EventHandler(webBrowserEvents_Before

Navigate2);


73

4.4.1. BeforeNavigate2

This event is fired before Internet Explorer starts to load a page. It receives the

navigation object (ob1), the attempted URL (URL), HTML post data (da), and

extra information. The SpoofGuard_Toolbar class is also enabled to cancel the

navigation by setting the value of the parameter (Cancel) to true. This event is

declared as following:

BeforeNavigate2(object ob1,ref object URL,...,ref object da,ref bool

Cancel)

This event is used to perform the first round checks, i.e. checkDomain(URL),

checkURL(URL), checkEmail(URL), and checkPostData(URL, da). These checks

are only triggered if the received object, (ob1) is the outermost frame, the

attempted URL is correct, and its domain is not found in the domain white list. If

any check detects a spoof symptom, it will add a text string to the

warningMessage variable describing this symptom, and will return an integer

value. The returned values of these checks, i.e. DomainCheckRes, UrlCheckRes,

EmailCheckRes, and PostDataCheckRes, and their weights are used to

calculate the total spoof score (TSS) of the attempted URL, as described by the

equation in 3.1. A warning message will be shown and the traffic light will

become red if the TSS of the attempting URL is equal or greater than the total

alert level (TAL) (see Figure 4.1). At the end of this event, the

pageDownloadTimeOut timer is enabled and its interval value is set to two

seconds.


74

Following are implementation details of the domain, URL, email, and outgoing

post data checks.

.

Domain Check

This check uses two loops. The first one reads one domain from the domain

white list at a time. The second loop reads one character at a time from the

domain white list and one character from the current domain. A warning text will

be added to the warning message if the difference between the two domains is

an integer between one and the value of the hostNameCheckSensitivity result,

a number indicating the maximum difference between safe and spoof domains.

Figure 4.2 shows a Pseudocode for the domain check.

Figure 4.1: A warning message at BeforeNavigate2 event


75

Figure 4.2: Pseudocode for domain check

URL Check

This check performs five sub-checks and adds a warning text to the warning

message if any sub-check finds a spoof symptom, as described in section

3.4.2.1.2.1. The first check reads one keyword at a time from the

topLevelDomainList, and searches for this keyword in the URL‘s username. The

second check searches for the IP address in the URL‘s hostname. The third

check searches for a suspicious port in the URL‘s port. The forth check reads

one domain at a time from the commonSpoofSiteList and searches for this

domain in the URL‘s path. The fifth check is similar to the forth check, but it

searches for the domain in the URL‘s hostname and compares their length.

Figure 4.3 shows a Pseudocode for the URL check.


76

Figure 4.3: Pseudocode for URL check


77

Email Check

This check reads one host from the emailHostNameList at a time and adds a

warning text to warning message if URL‘s hostname is in the list. Figure 4.4

shows a Pseudocode for the email check.

Figure 4.4: Pseudocode for email check

Outgoing Post Data Check

This check extracts the postUserName and the postPassword from the post

data (da), and hashes the postPassword. Then it reads one record at a time

from the passwordFile and extracts the domain from the first field, the

userName from the second field, and the hash value of the password,

passwordHash, from the third field. If the postUserName and the hash value of

the post password, postPasswordHash, are identical to the userName and hash

value of the password, passwordHash, in the record, and the current domain is

not the domain in the record, a warning message will be shown. Otherwise, the


78

post information and the current domain will be added to the passwordFile. This

check will return a relatively large integer if the image check result is positive.

The hash algorithm used for password hashing is SHA-1 from the library

System.Security.Cryptography. SHA-1 has been adopted since it is the most

resistant hash algorithm against brute force attacks [40]. Figure 4.5 shows a

Pseudocode for the outgoing post data check.

Figure 4.5: Pseudocode for outgoing post data check


79

4.4.2. DocumentComplete

This event is fired after all the contents (images, links, scripts, frames, etc.) of

the attempting object (the page) in Internet Explorer have been completely

loaded. Two parameters are passed to this event: the navigation object (pDisp)

and the attempted URL (URL). This event is declared as follows:

DocumentComplete(object pDisp, ref object URL)

This event is used to perform the second round checks, i.e.

checkPassword(pDisp, URL), checkLinks(pDisp), checkImage(pDisp, URL),

and checkTababbing(pDisp). These checks are only triggered if the received

object, (pDisp), is the outermost frame. If any check detects a spoof symptom, it

will add a text string that describes the symptom to the warningMessage variable

and will return an integer value. The returned values of these checks, i.e.

PasswordCheckRes, LinksCheckRes, TababbingCheckRes, and ImageCheckRes,

and their weights are used to calculate the total spoof score (TSS) of the

attempting page as described by equation 3.1. The TSS of the page is added to

the TSS of the URL, which is calculated in the BeforeNavigate2 event, to

compute the final TSS. A warning message will be shown and the traffic light

will become red if the final TSS is equal or greater than the total alert level

(TAL) (see Figure 4.6). The second round checks are also applied in the

pageDownloadTimeOut timer. The timer event is fired if two seconds are left after

the BeforeNavigate2 event finishes and the DocumentComplete event does not

finish. This timer is used to address page load attacks as described in section

3.4.2.1.2.2. Following are implementation details of the password, links, image,

and tabnabbing checks.


80

Figure 4.6: A warning message at DocumentComplete event

Password Check

This check uses one loop to read one page element at a time. If there is an

element with a name input or textarea, which has a password type, two tasks

will be performed. First, the Total Alert Level value will be reduced by two digits.

Second, a warning text will be added to warning message, as described in

section 3.4.2.1.2.2. Figure 4.7 shows a Pseudocode for the password check.


81

Figure 4.7: Pseudocode for password check

Links Check

This check reads one page element at a time to find a link element, i.e. element

with a tag name link or a. Then it extracts values of href and innertext attributes

from each link. An individual link is a bad in one of two cases. First, if innertext

attribute value contains any item of the URL shortener list. Second, if href

attribute value fails URL check. Then, if the result of dividing the number of bad

links by the number of page links is equal to or greater than 0.25, a warning text

will be added to warning message. Figure 4.8 shows a Pseudocode for the links

check.


82

Figure 4.8: Pseudocode for links check

Image Check

This check reads one page element at a time to find an image element. It

rejects any image size larger than 300 kilobytes. The image data is retrieved

and hashed using the MD5 hash algorithm, since MD5 is much faster than

SHA-1 and since this check does not deal with passwords [40]. Then, the image

file is opened and one record at a time will be read. Two values will be

extracted: the domain from the first field, and the hash value of the image,


83

imagHash, from the second field. If the page image hash value, pageimagHash,

is identical to the image hash value, imagHash, in the record, and the current

domain is not the domain in the record, a warning text will be added to the

warning message. Otherwise, the hash value of the image on the page,

pageimagHash, and the current domain will be added to the imageFile. Figure

4.9 shows a Pseudocode for the image check.

Figure 4.9: Pseudocode for image check


84

Tabnabbing check

This check reads one page element at a time to find a script element. Then it

retrieves the script string and searches the string for ―settimeout‖ and ―onblur‖

keywords. If both keywords are found, a warning text will be added to the

warning message. Figure 4.10 shows a Pseudocode for the tabnabbing check.

Figure 4.10: Pseudocode for tabnabbing check

4.5. Difficulties Faced During Implementation

The development of the anti-spoofing solution, SpoofGuard++, involves solving

some challenges to provide an acceptable solution. These challenges are:

finding phishing pages, large image sizes, and reducing false-positive rates.


85

Finding Phishing Pages

In order to provide solid phishing detection methods, analysis of recent phishing

pages may be important. However, most phishing pages are removed from the

Internet by the attackers themselves after a short time [51]. To cope with this

challenge, an investigation of different resources, including academic articles on

security and security specialists‘ blogs, e.g. ―www.esecurityplanet.com‖, has

been conducted in order to identify some of the symptoms of new phishing

techniques.

Large size Image

The image check reads and hashes every image on a visited page (as

described in section 3.4.2.1.2.2.). However, processing and hashing a large

image has a detrimental effect on Internet Explorer‘s performance. To deal with

this challenge, only image sizes of 300 kilobytes or less can be processed and

hashed.

Reduce False Positive Rates

The original version, SpoofGuard, suffers from a relatively high false alarm rate

[9][11]. The proposed solution should reduce the false alarm rate. To address

this problem, several changes have been made. First, a list of commonly

spoofed sites has been added to Internet Explorer‘s history to create a domain

white list (see section 3.4.1.). Second, a page default timeout has been added


86

to avoid page load attack (see section 3.4.2.1.2.2.). Third, a new check method

has been added, i.e. tabnabbing and HTML attachment, and two check

methods have been enhanced, i.e. URL, link.


This chapter has presented SpoofGuard++ development and implementation

issues. Internet Explorer has been chosen as the container platform for the

proposed anti-phishing solution. The Microsoft .NET framework and the C#

programming language have been selected to implement the proposed system

design. The Pseudocode of domain, email, URL, outgoing post data, password,

links, image, and tabnabbing checks have been shown. Three implementation

challenges have been discussed: finding phish pages, large image sizes, and

reducing false positive rates.


87

Chapter 5. SpoofGuard++ Evaluation and Testing


In this chapter, the proposed solution and its individual checks are tested and

evaluated to draw a solid conclusion about this solution. A number of phish and

clean sites are used to test true and false positive rates of SpoofGuard++. For

each check of the solution, a specific webpage is created to test its functionality.

The effective of the proposed solution and the origin, SpoofGuard, are tested

with respect to true and false positive rates. The performance of the proposed

anti-spoofing solution is evaluated using a simple measurement. Two main

limitations are discussed in this chapter.

In details, this chapter is organized as follows. Section 5.2 discusses a number

of functionality tests applied on the proposed solution. Section 5.3 provides

SpoofGuard++ limitations. While section 5.4 summaries the chapter.

5.2. Testing and Results

After implementing SpoofGuard++ design, it is necessary to test it against the

system‘s requirements. Three main criteria can be used to test the anti-spoofing

solution: testing against phishing attacks, testing false positive rate and

evaluate the performance of the solution.


88

5.2.1. Testing Against Phishing Attacks

Since the main aim of the proposed anti-spoofing solution is to identify and

detect phishing attacks, this solution should be tested against existing phish

websites. The proposed solution has been tested against a limited number of

phish sites, since the possibility of accessing such websites is limited (as

described in section 4.5). In addition to this test, a number of websites has been

created to simulate different type of attacks. These websites are hosting in the

domain ―freehostingcloud.com‖ as sub-domains. For security reason, each

website contains the declaration ―Attention! This website is created for testing

SpoofGuard++ tool‖. As an exception, email and tabnabbing checks can be

tested without creating simulation websites. All of the tests are performed using

the tool default settings.

5.2.1.1. Testing against phish sites

The proposed toolbar, SpoofGuad++, and the original, SpoofGuard, have been

tested against only ten phish sites taken from PhishTank.com [52]. For each

site, the URL is entered into the Explorer address bar and the responses of

each tool are noted. Both tools have identified seven sites out of ten as phish,

70%, and three sites as clean, 30%. The test sites‘ URLs are listed in table 5.1,

while in figure 5.1 there is a comparison between each tool response.


89

Table 5.1: Phish tested URLs and each tool response

URL SpoofGuard SpoofGuard ++

http://flex-hotel.com/ Spoof Clean

http://www.webbohotel.net/ Spoof Spoof

http://rrcs-74-218-221-

98.central.biz.rr.com/www.paypal.com/ukw

ebscr/

Spoof Spoof

http://turgutu.tu.ohost.de/MSN%20SMS/ Spoof Spoof

http://suraj123kabaap1.hdfree.in/1.html Clean Spoof

http://zoolandarad.ro/pib/index.html Clean Clean

http://ir-l.com/irl/login.htm Spoof Spoof

http://votacaoeletronica.inf.br/components/

com_media/assets/timp/paypal.fr/cgi-

bin/update/webscr.php?cmd=_login-

run&dispatch=https://www.paypal.com/fr/c

gi-bin/webscr?cmd=_login-

run&dispatch=5885d80a13c0db1f8e26366

3d3faee8d9384d85353843a61960628281

8e091d0

Spoof Spoof

http://eu.battle.net-support-wow-

blizzard.in/p/login.html

Spoof Spoof

http://nicebenifit.cz.cc/tbp/TargetPro.htm Clean Clean

http://flex-hotel.com/

http://www.webbohotel.net/

http://rrcs-74-218-221-98.central.biz.rr.com/www.paypal.com/ukwebscr/



http://turgutu.tu.ohost.de/MSN%20SMS/

http://suraj123kabaap1.hdfree.in/1.html

http://zoolandarad.ro/pib/index.html

http://ir-l.com/irl/login.htm

http://votacaoeletronica.inf.br/components/com_media/assets/timp/paypal.fr/cgi-bin/update/webscr.php?cmd=_login-run&dispatch=https://www.paypal.com/fr/cgi-bin/webscr?cmd=_login-run&dispatch=5885d80a13c0db1f8e263663d3faee8d9384d85353843a619606282818e091d0








http://eu.battle.net-support-wow-blizzard.in/p/login.html

http://eu.battle.net-support-wow-blizzard.in/p/login.html

http://nicebenifit.cz.cc/tbp/TargetPro.htm


90

Figure 5.1: A comparison between each tool response against phish URLs

5.2.1.2. Domain Check Testing and Results

This test examines the ability of the domain check to detect minor differences

between a trust domain name in the white list and a fake domain name. To do

this, a trust domain ―www.dnnchktst.freehostingcloud.com‖ has been added to

the white list and a fake page has been created and hosted in a fake domain

―www.dmnchktst.freehostingcloud.com‖, which starts with ―dm‖ rather than ―dn‖.

After entering the above URL in the Explorer address bar, domain check has

correctly recognized this URL and has constructed a message describes the

problem. Figure 5.2 shows a snapshot of testing the domain check.

0

2

4

6

8

10

12

SpoofGuard++ SpoofGuard

Spoof

Clean

http://www.dnnchktst.freehostingcloud.com/

http://www.dmnchktst.freehostingcloud.com/


91

Figure 5.2: Testing domain check

5.2.1.3. URL Check Testing and Results

This test examines the ability of the URL check to detect any URL-based trick,

as described in section 3.4.2.1.2.1.2. To do this, a simple page has been

created and hosted in the domain ―www.urlchktst.freehostingcloud.com:5051‖.

No problem with this URL except the port number ―5051‖, which is not a

standard web port.

www.urlchktst.freehostingcloud.com:5051


92

As a result of using the suspicious URL, URL check has correctly identified the

un-standard web port in the fake URL and has constructed a message

describes the problem. Figure 5.3 shows a snapshot of testing the URL check.

Figure 5.3: Testing URL check

5.2.1.4. Email Check Testing and Results

In this test the email check is expected to detect whether a new opened window

has been lunched from an email message. As mentioned in section 5.2.1, the

email check should be tested on a real email provider, e.g. ―mail.live.com‖. To

http://www.mail.live.com/


93

do this, a message contains one bad link has been constructed and sent to a

hotmail account, i.e. email. From that message a new Internet Explorer window

has been opened by clicking on the provided link.

As a result of the previous test, email check has popped up a message that

warns the user of a potential attack. The user is also given the ability to cancel

the navigation. Figure 5.4 shows a snapshot of testing the email check.

Figure 5.4: Testing email check

5.2.1.5. Outgoing Post Data Check Testing and Results

This test examines the outgoing post data check to ensure that this check can

intercept any HTML post request and stop it in the case of suspicious request.

Before testing this check, a simple login page has been created and hosted in

the domain ―www.pstdatachktst.freehostingcloud.com‖. This page consists of

www.pstdatachktst.freehostingcloud.com


94

one form contains two input areas for username and password and a submit

button. The ―method‖ attribute of the form is set to ―post‖ while the attribute

―action‖ is set to ―http://spoofguardpp.freehostingcloud.com‖, which is

considered as spoof. To perform the test, an email address and password have

been submitted to a trust domain, i.e. ―www.yahoo.com‖, and the same email

address and password have been submitted on the fake page.

After conducting this experiment, the outgoing post data check has effectively

intercepted the HTML post request and has recognized the difference between

the legal and fake domains. The user is warned by a message describes the

potential attack. The user is also given the ability to cancel the navigation.

Figure 5.5 shows a snapshot of testing the outgoing post data check.

http://spoofguardpp.freehostingcloud.com/

http://www.yahoo.com/


95

Figure 5.5: Testing outgoing post data check

5.2.1.6. Password Check Testing and Results

In this test the password check is expected to detect HTML text elements of

type password. To do this, a simple login page has been created and hosted in

the domain ―www.psschktst.freehostingcloud.com‖. This page is similar to the

page used in the previous test, i.e. test outgoing post data check, but does not

send any data. This page also does not use the SSL protocol. Figure 5.5 shows

a snapshot of testing the password check.

http://www.psschktst.freehostingcloud.com/


96

After the Explorer complete downloading the attempting page, password check

has successfully recognized that there is a password field on an encrypted

page. A warning message of this problem has been added to the page status.

Figure 5.6 shows a snapshot of testing the password check.

Figure 5.6: Testing password check

5.2.1.7. Links Check Testing and Results

This test examines the links check to ensure that each link on a visited

webpage is checked against URL check and a list of URL shorteners. To


97

achieve this, a single page has been created and hosted in the domain

―www.lnkchktst.freehostingcloud.com‖. This page consists of five links, two are

bad links and the rest are normal.

As a result of loading the previous page, the links check has identified both bad

links and calculated the percentage of bad links, which is 40%. In addition,

detailed information about each bad link has been added to the page status.

Figure 5.7 shows a snapshot of testing the links check.

Figure 5.7: Testing links check

http://www.lnkchktst.freehostingcloud.com/


98

5.2.1.8. Image Check Testing and Results

This test examines the ability of the image check to recognize fake and imitated

images on a visited page. To achieve this first, a fake page has been created

and hosted in the domain ―www.imgchktst.freehostingcloud.com‖. This page is

similar to the page used in the testing password check. In addition, two images,

retrieved from gmail login page, have been added to this page. After that, a

trusted domain ―www.gmail.com‖ has been visited to add its images‘ hash

values to hash image file. Finally, the fake page has been visited.

After navigate to such a page, image check has compared between hash

values of each page and has concluded that the last visited page is fake. In

addition, the user is warned by a message describes the recognized problem.

Figure 5.8 shows a snapshot of testing the image check.

http://www.imgchktst.freehostingcloud.com/

http://www.gmail.com/


99

Figure 5.8: Testing image check

5.2.1.9. Tabnabbing Check Testing and Results

This test examines the tabnabbing check to ensure that each script associated

with a visited page is checked. The tabnabbing check will be tested against the

page ―http://www.azarask.in/blog/post/a-new-type-of-phishing-attack‖, which is

created by A. Raskin [32] (as described in section 3.4.2.1.2.2.4). Since this

attack has not been used by attackers yet, testing this check against such a

page may be enough.

http://www.azarask.in/blog/post/a-new-type-of-phishing-attack


100

Loading such a page on the Explorer gave the tabnabbing check the

opportunity to intercept all script related to the page and detect the potential

attack. In addition, a warning message of this problem has been added to the

page status. Figure 5.9 shows a snapshot of testing the tabnabbing check.

Figure 5.9: Testing tabnabbing check


101

5.2.2. False Positive Rate Testing and Results

This test is used to identify the false positive rate of SpoofGuard++ in

comparison with SpoofGuard. To do this, both tools have been tested against

ten known clean sites. For each site, the URL is entered into the Explorer

address bar and the responses of each tool are noted. SpoofGuard++ has

identified nine sites out of ten as clean, 90%, and one site as phish, 10%. While,

SpoofGuard has identified four sites out of ten as clean, 40%, and six sites as

phish, 60%. From this comparison, it is clear that the proposed solution reduces

the false positive rate from 60% to 10%. This enhancement may be a result of

using the new features in SpoofGuard++, i.e. domain white list, HTML

attachment aware, page default timeout, and the modified versions of URL and

domain checks. The test sites‘ URLs are listed in table 5.2, while in figure 5.10

there is a comparison between each tool response.

Table 5.2: Clean tested URLs and each tool response

URL SpoofGuard SpoofGuard ++

http://www.plusnetwork.com/ Spoof Clean

http://www.hotmail.com/ Clean Clean

http://www.gmail.com/ Spoof Clean

http://www.google.co.uk/ Clean Clean

http://www.direct.gov.uk/ Clean Clean

http://www.facebook.com/ Spoof Clean

http://www.hsbc.com/1/2/ Spoof Clean

http://www.bradesco.com.br/ Spoof Clean

https://signin.ebay.co.uk/ Spoof Spoof

http://www.plusnetwork.com/

http://www.hotmail.com/

http://www.gmail.com/

http://www.google.co.uk/

http://www.direct.gov.uk/

http://www.facebook.com/

http://www.hsbc.com/1/2/

http://www.bradesco.com.br/

https://signin.ebay.co.uk/


102

http://www.halifax.co.uk/ Clean Clean

Figure 5.10: A comparison between each tool response against clean URLs

5.2.3. SpoofGuard++ Performance Evaluating and Result

The evaluation of the proposed tool performance has been conducted in order

to identify the impact of the tool on its container, Internet Explorer. To do this, a

simple BHO has been developed using C#. In this BHO, two timers have been

added to a simple toolbar to be triggered at BeforeNavigate2 and

DecumentComplete events. One timer is used to record page navigation

starting time while another is used to record the page load finishing time. This

measurement method is adopted from the work of N. Chou et al. [3]. Ten sites

have been surfed with SpoofGaurd++ and without it and the developed BHO,

i.e. the measure, has been used in both cases. This evaluation has been

conducted using a 2.30 GHz AMD Dual-Core Mobile with 2GB of RAM PC

connected through a 10 Mbps Ethernet card. After doing the evaluation, the

result of retrieving a page at average was 337 milliseconds without using the

0

2

4

6

8

10

12

SpoofGuard++ SpoofGuard

Spoof

Clean

http://www.halifax.co.uk/


103

tool and 529 milliseconds with the tool. Overall, this evaluation suggests that

SpoofGuard++ functions and checks do not degrade Internet explorer and user

machine performance.

5.3. SpoofGuard++ Limitations

Phish attackers develop new techniques constantly to illegally gather

unsuspecting users‘ sensitive data. These techniques may be designed to fool

existing anti-phishing solutions. However, it is hard to produce an anti-phishing

solution to stop all types of phish attacks. As the proposed solution,

SpoofGuard++, is one of these solutions, it is unable to detect all JavaScript-

based and malware-based attacks. In addition, the proposed toolbar work only

on Internet Explorer browser.

Although the proposed check tabnabbing is design to detect tabnabbing attack,

in which JavaScript code is used, JavaScript can be used to fool and bypass

SpoofGuard++. For example, a JavaScript code can be used capture system

clipboard. This code is easy to develop and it is effective since the user may not

detect it easily.

None of the proposed solution check is enabled to recognize malware-based

attack. An example of such attacks is key logger. A key logger is developed to

record user keyboard inputs before she sends it.

Since the proposed solution is developed to work only on Internet Explorer

browser, Firefox users, for example, are not able to use the toolbar on such a

browser.


104


This chapter has presented how the proposed anti-phishing solution may be

tested and evaluated. Each of the proposed solution‘s checks has correctly

identified phish tricks used in the designed pages. Comparing the effectiveness

of the proposed solution and the original has clearly shown that SpoofGuard++

has less false positive rate. The performance evaluation has concluded that the

proposed solution is unlikely to cause a noticeable page access delay while

using Internet Explorer and is expected to be accepted by the user. The threats

of JavaScript-based and malware-based attacks have been considered as the

main limitations of the proposed solution.


105

Chapter 6. Conclusion and Future Works

This chapter provides a summary of what this project has achieved, its main

findings, and some suggestions for future work.

6.1. Conclusions

This project has achieved its main aim of providing an anti-phishing solution that

can detect a number of new and sophisticated phishing techniques, e.g.

tabbnabing and HTML attachment techniques. This has been done by

examining the limitations of a number of anti-phishing solutions and by

analyzing recent phishing attacks.

In this project, two round checks have been proposed to detect phishing

attacks. The first round checks are domain, URL, email, and outgoing post data.

These checks are fired before Internet Explorer starts navigating to a given URL

and provides an initial conclusion about the attempt page. In addition, the

second round checks are password, links, image, and tabnabbing. These

checks are fired after Internet Explorer completes loading a given page and

provides the final conclusion about the attempt page.

The proposed solution has added a number of significant features to the original

solution, SpoofGaurd. These new features enable the proposed solution to

dramatically reduce false positive rate (see section 5.2.2 for more details) and

to protect the user from some new types of attacks. The main added features


106

are: domain white list, HTML attachment aware, page default timeout, URL

shortening aware, and sophisticated misleading URL aware.

6.2. Recommendations for Furute Works

Due to the time restriction only five new anti-phishing features have been

proposed. Although these features may added values to the anti-phishing field,

a lot of work are still needed to be done in order to provide the Internet user with

a safer environment. This may be done by adding features to stop Cross Site

Scripting (XSS) and JavaScript-based attacks. In addition, the Firefox browser

may be enabled to use the proposed toolbar.

Since JavaScript–based phish attacks have been increased, any JavaScript

code associates with a HTML page should be intercepted and analyzed to find

attacks attempts. New features may be added to implement such a suggestion.

A Cross Site Scripting attack occurs when an attacker supplies malicious inputs

to a web application. A feature may be developed to be able to receive and filter

the attacker malicious input and only passes the safe part of the input to the

targeted web application.

A new version of SpoofGuard++ may be developed to work on Firefox browser.

This may increase the number of the proposed solution users and then protect

them from a number of phishing attacks.


107

References

[1] H. Huang, J. Tan, L. Liu, "Countermeasure Techniques for Deceptive Phishing Attack", International Conference on New Trends in Information and Service Science, 2009, pp. 636-641. [2] Anti-Phishing Working Group, "http://www.antiphishing.org/", 2011, retrieved on 20/03/2011.

[3] N. Chou, R. Ledesma, and Y. Teraguchi, et al, "Client-side Defense against Web-based Identify Theft", In: Proc. of 11th Annual Network and Distributed System Security Symposium, 2004, pp.1-16. [4] Microsoft, "Sender ID Home Page", "http://www.microsoft.com/mscorp/safety/tehnologies/senderid/default.aspx", 2009, retrieved on 23/03/2011. [5] Yahoo, "Yahoo! AntiSpam Resource Center", "http://antispam.yahoo.com/domainkeys", 2009, retrieved on 23/03/2011. [6] Cisco Corporation, "IronPort Email Authentication", 2008, pp. 1-14. [7] R. Dhamija, and J. D. Tygar, "The Battle against phishing: Dynamic Security Skins", In: Proc. of ACM Symposium on Usable Security and Privacy, 2005, pp.77-88. [8] S. Garera, N. Provos, and M. Chew, et al, "A Framework for Detection and Measurement of Phishing Attacks", In: Proc. of the 5th ACM Workshop on Recurring Malcode, 2007, pp.1-8. [9] Y. Zhang, S. Egelman, L. Cranor, and J. Hong, "Phinding Phish: Evaluating Anti-Phishing Tools", 2010, pp. 1-16. [10] H. Shahriar and M. Zulkernine, "PhishTester: Automatic Testing of Phishing Attacks", Fourth International Conference on Secure Software Integration and Reliability Improvement, 2010, pp. 198-207. [11] S. Bin, W. Qiaoyan, L. Xiaoying, "A DNS based Anti-Phishing Approach", Second International Conference on Networks Security, Wireless Communications and Trusted Computing, 2010, pp. 262-265. [12] Y. Joshi, D. Das, S. Saha, "Mitigating Man in the Middle Attack over Secure Sockets Layer", IEEE, 2009, pp. 1-5. [13] J. Milletary, "Technical Trends in Phishing Attacks", US-CERT, 2006, pp. 1-17. [14] A. Bergholz, J.-H. Chang, G. Paaß, F. Reichartz, and S. Strobel, "Improved phishing detection using model-based features". In Proceedings of the Conference on Email and Anti-Spam (CEAS), 2008, pp. 1-10.


108

[15] G. V. Cormack and R. N. Horspool, "Data compression using dynamic markov modelling", The Computer Journal, 30(6), 1987, pp.541–550. [16] I. Fette, N. Sadeh, and A. Tomasic. "Learning to detect phishing emails", In Proceedings of the International World Wide Web Conference (WWW), 2007, pp. 649–656. [17] Gregory L. Wittel and S. Felix Wu, "On Attacking Statistical Spam Filters", first conference on E-mail and Anti-spam, 2004, pp. 1-7. [18] M. Chandrasekaran, K. Narayanan and S. Upadhyaya, "Phishing E-mail detection based on structural properties", NYS Cyber Security Conference, 2006, pp. 1-7. [19] R. Shah, J. Trevathan, W. Read and H. Ghodosi, "A Proactive Approach to Preventing Phishing Attacks Using a Pshark", Sixth International Conference on Information Technology, 2009, pp. 1-7. [20] BrandProtect International, "BrandProtect‘s Phishing takedown process", "http://www.brandprotect.com/phishing-take-down-process.html", 2010, retrieved on 25/04/2011. [21] T. Moore and R. Clayton, "Examining the impact of website take-down on phishing", Anti-Phishing Working Group eCrime Researcher's Summit (APWG eCrime), 2007, pp. 1-13. [22] Microsoft, SmartScreen Filter, "http://windows.microsoft.com/en-US/internet-explorer/products/ie-9/features/smartscreen-filter", 2011, retrieved on 24/03/2011. [23] NetCraft, Netcraft Tolbar, "http://toolbar.netcraft.com", 2011, retrieved on 21/03/2011. [24] Microsoft, SmartScreen Filter and Resulting Internet Communication in Windows 7 and Windows Server 2008 R2, "http://msdn.microsoft.com/en-us/library/ee126149(v=ws.10).aspx", 2009, retrieved on 24/03/2011. [25] R. Dhamija, and J. D. Tygar, "The Battle against phishing: Dynamic Security Skins", In: Proc. of ACM Symposium on Usable Security and Privacy, 2005, pp.77-88. [26] M. Topkara, A. Kamra, and M. J. Atallah, et al, "ViWiD: Visible Watermarking Based Defense against Phishing", Lecture Notes in Computer Science, Vol.3710, 2005, pp.470-483. [27] R. Dhamija, J. D. Tygar, and M. Hearst, "Why Phishing Works? ", In: Proc. of the SIGCHI conference on Human Factors in computing systems, 2006, pp.581-590.

http://www.brandprotect.com/phishing-take-down-process.html

http://windows.microsoft.com/en-US/internet-explorer/products/ie-9/features/smartscreen-filter

http://windows.microsoft.com/en-US/internet-explorer/products/ie-9/features/smartscreen-filter

http://msdn.microsoft.com/en-us/library/ee126149(v=ws.10).aspx

http://msdn.microsoft.com/en-us/library/ee126149(v=ws.10).aspx


109

[28] D. Betonio, "10 Best URL Shorteners and why they are good",

"http://www.tripwiremagazine.com/2010/06/10-best-url-shorteners-and-why-

they-are-good.html", 2010, retrieved on 14/03/2011. [29] A. Engst, "Beware Tabnabbing, a New Type of Phishing Attack", "http://tidbits.com/article/11314", 2010, retrieved on 13/03/2011. [30] M. Kassner, "URL shortening: Yet another security risk", "http://www.techrepublic.com/blog/security/url-shortening-yet-another-security-risk/1044", 2009, retrieved on 05/05/2011. [31] E. Mills, "Phishers use HTML attachments to evade browser blacklists", "http://news.cnet.com/8301-27080_3-20043960-245.html", 2011, retrieved on 06/05/2011. [32] A. Raskin, "Tabnabbing: A New Type of Phishing Attack", "http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/", 2010, retrieved on 03/05/2011. [33] T. Raffetseder, E. Kirda, and C. Kruegel, "Building Anti-Phishing Browser Plug-Ins: An Experience Report", ICSE Workshop on Software Engineering for Secure Systems (SESS), IEEE Computer Society Press, 2007, pp. 1-7. [34] NetCraft, "Most Visited Web sites", "http://toolbar.netcraft.com/stats/topsites", 2011, retrieved on 06/05/2011. [35] AgainstPhishing, "The Dangers of a Phishing Attack", "http://www.againstphishing.com/dangers-of-phishing.html", 2010, retrieved on 01/05/2011. [36] Internet Technologies Workshop: Tel-Aviv University, "Current Anti Phishing Methods", "http://tau-itw.wikidot.com/deleted:saphe-current-anti-phishing-methods", 2009, retrieved on 14/02/2011. [37] Gartner, "Number of Phishing Attacks on U.S. Consumers Increased 40 Percent in 2008", "http://www.gartner.com/it/page.jsp?id=936913", 2009, retrieved on Sunday 13/02/2011. [38] L. Phifer: E-Security planet, "top ten phishing facts", "http://www.esecurityplanet.com/views/article.php/3875866/Top-Ten-Phishing-Facts.htm", 2010, retrieved on 13/02/2011. [39] M. Suess , "C++ vs. C# - a Checklist from a C++ Programmers Point of View", ―http://www.thinkingparallel.com/2007/03/06/c-vs-c-a-checklist-from-a-c-programmers-point-of-view/‖, 2007, retrieved on 13/03/2011.

http://www.tripwiremagazine.com/2010/06/10-best-url-shorteners-and-why-they-are-good.html

http://www.tripwiremagazine.com/2010/06/10-best-url-shorteners-and-why-they-are-good.html

http://tidbits.com/author/Adam%20C.%20Engst

http://tidbits.com/article/11314

http://www.cnet.com/profile/elinormills/

http://news.cnet.com/8301-27080_3-20043960-245.html

http://en.wikipedia.org/wiki/Aza_Raskin

http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/

http://toolbar.netcraft.com/stats/topsites

http://www.againstphishing.com/dangers-of-phishing.html

http://tau-itw.wikidot.com/

http://tau-itw.wikidot.com/deleted:saphe-current-anti-phishing-methods

http://tau-itw.wikidot.com/deleted:saphe-current-anti-phishing-methods

http://www.gartner.com/it/page.jsp?id=936913

http://www.esecurityplanet.com/author.php/16233/Lisa-Phifer.htm

http://www.esecurityplanet.com/views/article.php/3875866/Top-Ten-Phishing-Facts.htm

http://www.esecurityplanet.com/views/article.php/3875866/Top-Ten-Phishing-Facts.htm

http://www.thinkingparallel.com/2007/03/06/c-vs-c-a-checklist-from-a-c-programmers-point-of-view/





110

[40] Microsoft Developer Network, "Performance Comparison: Security Design Choices",‖http://msdn.microsoft.com/en-us/library/ms978415.aspx‖, 2002, retrieved on 16/06/2011.

[41] C. Herley, "So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users", Association for Computing Machinery, Inc., 2009, pp. 1-12. [42] E. Kirda, and C. Kruegel, "Protecting Users against Phishing Attacks with AntiPhish", In: Proc. of the 29th Annual International Computer Software and Applications Conference, 2005, pp.521-534. [43] T. Dinter, "The Apache SpamAssassin Project", "http://spamassassin.apache.org/", 2003, retrieved on 18/04/2011. [44] Kaspersky Lab, "Spam Report: May 2010", "http://www.securelist.com/en/analysis/204792124/Spam_Report_May_2010", 2010, retrieved on 23/06/2011. [45] B. Manthey and R. Reischuk, "The Intractability of Computing the Hamming Distance", 2002, pp. 1-15. [46] Next Generation Security Software (NGS), "The Phishing Guide: Understanding and Preventing Phishing Attacks", 2006, pp. 1-50. [47] Anti Phishing Scams, "Defending Against Phishing Attacks – What Is Phishing", "http://www.antiphishingscams.com/defending-against-phishing-attacks.html", 2011, retrieved on 21/04/2011. [48] Microsoft patterns & practices, "Security Guidelines: ASP.NET 2.0", "http://msdn.microsoft.com/en-us/library/ff649487.aspx", 2005, retrieved on 21/04/2011. [49] E. Graudins, "Email Phishing Links – How To Identify Them", "http://theinternetbloke.com/identify-phishing-links", 2009, retrieved on 12/05/2011. [50] ICICI Bank, "Beware of Frauds", "http://www.icicibank.com/online-safe-banking/beware-of-fraud/phishing.html", 2011, retrieved on 18/07/2011. [51] Anti-Phishing Working Group, ―Phishing Activity Trends Report", 2006, pp 1-7. [52] PhishTank team, ―Recent Phish List", "http://www.phishtank.com", 2011, retrieved on 06/09/2011.

http://msdn.microsoft.com/en-us/library/ms978415.aspx

http://spamassassin.apache.org/

http://www.kaspersky.com/

http://www.securelist.com/en/analysis/204792124/Spam_Report_May_2010

http://www.kaspersky.com/

http://www.antiphishingscams.com/defending-against-phishing-attacks.html

http://www.antiphishingscams.com/defending-against-phishing-attacks.html

http://msdn.microsoft.com/en-us/library/ff649487.aspx

http://theinternetbloke.com/author/ericg

http://theinternetbloke.com/identify-phishing-links

http://theinternetbloke.com/identify-phishing-links

http://www.icicibank.com/online-safe-banking/beware-of-fraud/index.html

http://www.icicibank.com/online-safe-banking/beware-of-fraud/phishing.html

http://www.icicibank.com/online-safe-banking/beware-of-fraud/phishing.html

an anti-spoofing tool: spoofguard++studentnet.cs.manchester.ac.uk/resources/library/...an...

Documents