AN ANTI-SPOOFING TOOL: SPOOFGUARD++

Transcription

1 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

2 Table of Contents Table of Contents... 2 List of Figures... 5 List of Tables... 7 List of Equations... 8 Abstract... 9 Declaration Intellectual Property Statement Acknowledgment Chapter 1. Introduction Project Context Phishing Attacks The Consequence of Phishing Attacks How to Counter Phishing Attacks Research Motivations and Challenges Aim and Objectives Project Scope Dissertation Structure...19 Chapter 2. Literature Review (countermeasures) Chapter Introduction Type 1: Server-Side Solutions Content Analysis Method Notice-and-Take-Down Method Authentication Protocol Method Type 2: Client-Side Solutions Blacklist-Based Method Visual-Clue-Based Method Webpage-Feature-Based Method Information-Flow-Based Method The Best Way Forward Chapter Summary

3 Chapter 3. SpoofGuard++ Design Chapter Introduction SpoofGuard++ Overview Requirement Specifications SpoofGuard++ Architectural Design Architecture Overview Architectural Components SpoofGuard_Toolbar Component Blacklist-Based Versus Webpage-Feature-Based Method Webpage-Feature-Based Method First-Round Checks Second-Round Checks User_Setting Component Page_Status Component User Interface Chapter Summary...68 Chapter 4. SpoofGuard++ Implementation Chapter Introduction Implementation Platforms Programming Languages SpoofGuard++' Low Level Design BeforeNavigate DocumentComplete Difficulties Faced During Implementation Chapter Summary...86 Chapter 5. SpoofGuard++ Evaluation and Testing Chapter Introduction Testing and Results Testing Against Phishing Attacks Testing Against Phish Sites Domain Check Testing and Results URL Check Testing and Results Check Testing and Results Outgoing Post Data Check Testing and Results Password Check Testing and Results

4 Links Check Testing and Results Image Check Testing and Results Tabnabbing Check Testing and Results False Positive Rate Testing and Results SpoofGuard++ Performance Evaluating and Result SpoofGuard++ Limitations Chapter Summary Chapter 6. Conclusion and Future Works Conclusions Recommendations for Furute Works References The final word count: Body of the dissertation Complete dissertation

5 List of Figures Figure Typical phishing attack steps Figure The machine learning approach Figure SenderID technique processes Figure DKIM technique processes Figure NetCraft Toolbar Figure SpoofGuard++ architecture Figure SpoofGuard++ toolbar Figure SpoofGuard++ page status pop up Figure SpoofGuard++ setting pop-up Figure A warning message at BeforeNavigate2 event Figure Pseudocode for domain check Figure Pseudocode for URL check Figure Pseudocode for check Figure Pseudocode for outgoing post data check Figure A warning message at DocumentComplete event Figure Pseudocode for password check Figure Pseudocode for links check Figure Pseudocode for image check Figure Pseudocode for tabnabbing check Figure A comparison between each tool response against phish URLs Figure Testing domain check Figure Testing URL check Figure Testing check Figure Testing outgoing post data check Figure Testing password check Figure Testing links check

6 Figure Testing image check Figure Testing tabnabbing check Figure A comparison between each tool response against clean URLs

7 List of Tables Table Features used in model-based machine learning technique Table Features used in Chandrasekaran et al. proposal Table A summary of SpoofGuard s evaluations functions Table The 18 URL features and their coefficients Table Phish tested URLs and each tool response Table Clean tested URLs and each tool response

8 List of Equations Equation Total spoof score (TSS) calculation

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, , 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%. 9

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. 10

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. 11

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 12

13 in any relevant Dissertation restriction declarations deposited in the University Library, The University Library s regulations (see and in The University s Guidance for the Presentation of Dissertations. 13

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. 14

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] 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 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 s to a large number of users. These s 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. 15

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. Figure 1.1: Typical phishing attack steps [1] 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. 16

17 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 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]. 17

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 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. 18

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. 19

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 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 s, taking action against fraudulent websites, or applying authentication protocols at the recipient s mail server. These solutions make use of content analysis, notice-and-take-down, or protocol-based authentication methods. 20

21 Content Analysis Method The -content analysis method focuses on examining incoming s to find specific features of fake s to prevent such s from reaching the user s inbox. To determine these features, a number of known fake s 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 s features are compared to features of known phishing s. Then a judgment on the new is made as to whether this 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 s features to the proposed features, the technique uses a classifier. This classifier has two inputs: the values of the phishing s features (the training set of the classifier), and the values of the new s features (the test set of the classifier). Figure 2.1 gives a general view of the proposed technique. 21

22 Table 2.1: the features used in model-based machine learning technique Feature category Feature total number of body parts Structural number of discrete and composite body parts number of alternative body parts total number of links number of internal and external links number of links with IP-numbers number of deceptive links Link 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 Boolean value, indicating whether HTML is used. Boolean value, indicating whether scripting is Element 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 is 22

23 considered to be spam Boolean value, indicating whether account word exists in the Boolean value, indicating whether update word exists in the Boolean value, indicating whether confirm word exists in the Boolean value, indicating whether verify word exists in the word-based features Boolean value, indicating whether secur word exists in the Boolean value, indicating whether notif word exists in the Boolean value, indicating whether log word exists in the Boolean value, indicating whether click word exists in the Boolean value, indicating whether inconvenien word exists in the Figure 2.1: The machine learning approach [14] 23

24 This technique has one advantage and two limitations: Advantage 1- The classifier used in the proposed technique may minimize the amount of normal s that may be classified as phishing s. 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 s to distinguish between legitimate and fake s. 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 s 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 24

25 the candidate features, the authors used the Support Vector Machine (SVM) classifier to classify phishing s. Table 2.2: the features used in Chandrasekaran et al. proposal Feature category Feature Total number of characters Total number of unique words Word count Total number of function words Function word frequency distribution: Account Log Access Bank style markers-based Credit Click Identity Inconvenience Information Limited Minutes Password Recently Risk 25

26 Social Security Service Suspended Total number of words Structure of subject line structural attributes-based Structure of the greeting provided in the 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 -based attacks. 2- This limited number of s involved in the experiment is not large enough to draw a broader conclusion [18]. 26

27 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 s, 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 s and, upon detecting a phish website, it starts to remove such a website. In the first stage, the system identifies the suspicious 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 27

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 filtering technique [19] Authentication Protocol Method This method tries to solve the phishing problem by adopting authentication schemas. These schemas can be applied on the protocol (STMP), which is designed without security requirements [6]. Using this method, sender s 28

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 authentication technique called SenderID which provides sender authentication based on its path. Typically, before sending an , 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 reaches its destination, the recipient s mail server can intercept this 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 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] 29

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 , the From: header indicates the sender s domain, and the IP address that appears in the is the sender s IP. However, if the is redirected using mail forwarding services or mailing lists, the From: header still indicates the original sender s domain, but the IP in that 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 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 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 , 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 context. If the signature is valid, the sender is then authenticated. Figure 2.3 summarizes the DKIM protocol processes. 30

31 Figure 2.3: DKIM technique processes [5] 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 , 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 reaches its destination, the 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]. 31

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] 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 informationflow-based solutions 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. 32

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. 33

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 34

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. 35

36 Figure 2.4: NetCraft Toolbar [23] Advantage 1- NetCraft Toolbar copes with DNS poisoning. That is if the local DNS have been altered. For example, if 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 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 36

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 37

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. This technique has one advantage and two limitations. 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. 38

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. 39

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 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. 40

41 Table 2.3: A summary of SpoofGuard s evaluations functions Check type URL Function If a webpage s URL 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 41

42 if the referring page is an 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. 42

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, typebased 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%. 43

44 Table 2.4: The 18 URL features and their coefficients Feature Logistic coefficient Odd ecoefficient Ratio Is URL in White Domain Table? Quality Score II PageRank of Host PageRank of URL PageRank in Crawl Database Quality Score I Number of characters after organization in host Word secure presence Word account presence Is Page in Index? Word webscr presence Word login presence Word ebayisapi presence Word signin presence Word banking presence Word confirm presence Is target organization in path but not in host? Is host obfuscated with IP? Constant

45 This technique has one advantage and two limitations. 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] 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 45

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. 46

47 2- Key-press JavaScript functions are not allowed by AntiPhish, since it prevents such functions 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 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 antiphishing 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. 47

48 Chapter 3. SpoofGuard++ Design 3.1. Chapter Introduction 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 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 48

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 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 49

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 s [31]. The proposed 50

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 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. 51

52 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 52

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 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. Requests to pop up current page status SpoofGuard_Toolbar Requests to pop up user setting window Page_Status User_Setting Figure 3.1: SpoofGuard++ architecture 53

54 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 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 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 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 54

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 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 55

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 (C 1, C 2,.., C 10 ). Each check (C i ) results in a number (R i ) in the range [0, 1]. R i =1 means the current page may be a spoof, whereas R i =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) 56

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 First-Round Checks In the first-round checks, domain, URL, 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 57

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 ( is compared with the history ( 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 58

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 symbol, e.g. ( In this URL, the username ( 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 ( ) 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 ( 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. ( [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 59

60 organization being imitated appears in the URL s hostname and a large number of characters appear after the domain name, e.g. ( [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 ( Check The check examines the attempting URL to find out whether the attempting page is launching from a web-based site, since the majority of phishing attacks start by sending fake s 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 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 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. 60

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 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 timeout 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. 61

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 s 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 message that includes a link such as ( which is a correct login address for Google AdWords. This link, in fact, would redirect the user to ( 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 62

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 63

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 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. 64

65 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 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, referral, and 65

66 tabnabbing checks. The user can stop warning messages, set history cache, stop image hash caching and disable password protection. Figure 3.2: SpoofGuard++ toolbar Figure 3.3: SpoofGuard++ page status pop up 66

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

68 3.5. Chapter Summary 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. 68

69 Chapter 4. SpoofGuard++ Implementation 4.1. Chapter Introduction This chapter focuses on the implementation issues of SpoofGuard++ development. It discusses the implementation platform to which the antispoofing 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 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 antiphishing 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 69

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 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 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 70

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 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, 71

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); 72

73 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), check (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, CheckRes, 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. 73

74 Figure 4.1: A warning message at BeforeNavigate2 event Following are implementation details of the domain, URL, , 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. 74

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 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. 75

76 Figure 4.3: Pseudocode for URL check 76

77 Check This check reads one host from the hostnamelist 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 check. Figure 4.4: Pseudocode for 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 77

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 78

79 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 Following are implementation details of the password, links, image, and tabnabbing checks. 79

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 Figure 4.7 shows a Pseudocode for the password check. 80

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. 81

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, 82

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 83

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. 84

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. 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 ). 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 ). Second, a page default timeout has been added 85

86 to avoid page load attack (see section ). 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 Chapter Summary 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, , 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. 86

87 Chapter 5. SpoofGuard++ Evaluation and Testing 5.1. Chapter Introduction 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 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. 87

88 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, and tabnabbing checks can be tested without creating simulation websites. All of the tests are performed using the tool default settings 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. 88

89 Table 5.1: Phish tested URLs and each tool response URL SpoofGuard SpoofGuard ++ Spoof Clean Spoof Spoof 98.central.biz.rr.com/ ebscr/ Spoof Spoof Spoof Spoof Clean Spoof Clean Clean Spoof Spoof com_media/assets/timp/paypal.fr/cgibin/update/webscr.php?cmd=_loginrun&dispatch= gi-bin/webscr?cmd=_loginrun&dispatch=5885d80a13c0db1f8e d3faee8d9384d a e091d0 Spoof Spoof Spoof Spoof Clean Clean 89

90 SpoofGuard++ SpoofGuard Spoof Clean Figure 5.1: A comparison between each tool response against phish URLs 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 has been added to the white list and a fake page has been created and hosted in a fake domain 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. 90

91 Figure 5.2: Testing domain check URL Check Testing and Results This test examines the ability of the URL check to detect any URL-based trick, as described in section To do this, a simple page has been created and hosted in the domain No problem with this URL except the port number 5051, which is not a standard web port. 91

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 Check Testing and Results In this test the check is expected to detect whether a new opened window has been lunched from an message. As mentioned in section 5.2.1, the check should be tested on a real provider, e.g. mail.live.com. To 92

93 do this, a message contains one bad link has been constructed and sent to a hotmail account, i.e. . From that message a new Internet Explorer window has been opened by clicking on the provided link. As a result of the previous test, 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 check. Figure 5.4: Testing check 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 This page consists of 93

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 which is considered as spoof. To perform the test, an address and password have been submitted to a trust domain, i.e. and the same 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. 94

95 Figure 5.5: Testing outgoing post data check 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 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. 95

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 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 96

97 achieve this, a single page has been created and hosted in the domain 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 97

98 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 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 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. 98

99 Figure 5.8: Testing image check 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 which is created by A. Raskin [32] (as described in section ). Since this attack has not been used by attackers yet, testing this check against such a page may be enough. 99

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 100

101 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 ++ Spoof Clean Clean Clean Spoof Clean Clean Clean Clean Clean Spoof Clean Spoof Clean Spoof Clean Spoof Spoof 101

102 Clean Clean SpoofGuard++ SpoofGuard Spoof Clean Figure 5.10: A comparison between each tool response against clean URLs 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 102