This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
We all have our little secrets and we want to keep them safe and secure. But most of the time we fail. Knowingly or unknowingly we tend to give away those secrets to others, resulting in a huge loss or embarrassment. One such secret is our username and password, that we often give away to attackers on internet by becoming victims of what is known as phishing. Phishing is an attack where the attackers masquerade as a trustworthy entity and trick us into submitting our credentials, mostly our usernames, passwords and credit card details. In this paper we shall take you around various techniques and methodologies available, to prevent such theft. And also discuss why we still fail to prevent phishing.
A phishing technique was described in detail in 1987. It was in a paper and presentation delivered to the International HP Users Group, Interex. But the use of this term was first recorded in the year 1996. The early use of this technique was first seen in AOL. But AOL soon came up with security measures in 1995. This resulted in targeting specific users on the internet, which later was coined with the term spear phishing and in some cases where the targets were big shots of huge organizations; it came to be known as whaling.
Initially the attackers sent emails with a link, asking the users to follow it to change their usernames, etc, in the name of "Account Verification", "Verify Billing Information", and so on. This slowly spread from emails to targeting users on IMs. This led to the advertisement of various messages by AOL and IM services telling "no one working at AOL will ask for your password or billing information", etc.
The first known attack over a payment system was recorded in 2001. It was against a payment system known as E-gold. By 2004 phishing was recognized as a fully industrialized part of the economy of crime. The most recent data tells us that there were 55, 698 attacks on the first half of 2009. The figure here shows the statistics of the year 2009 based on the reports received by them.
Figure-1: The number of unique phishing websites detected by the APWG
during the third quarter of 2009
3.6 million adults lost US $3.2 billion in the year 2007 . Phishing has seen a transition from AOL to IMs, IMs to financial institutions, social networking sites, file sharing websites and to almost everything on the internet. Apart from the attacks on the web, phishing exists in various other forms as vishing (voice phishing, which is also known as phone phishing), SMSishing (phishing through SMS), etc.
We shall go through some techniques on how the attackers trick us into this whole web.
SOME PHISHING TECHNIQUES
Link manipulation : it is a technique where an email is sent by the attacker with a link in it. The anchor text of the link appears to be legitimate but upon clicking, it takes us to a site that looks exactly similar to the original one. For example the link http://www.abccorporation.com may appear to be the original website address of ABC Corporation but it doesn't take us to the legitimate site.
Another old technique is to use the '@' symbol to spoof the sites. For example http:[email protected] takes us to a site which is www.notmycollege.com rather than what it claims to be i.e., www.mycollege.com. This is called spoofing the website.
A further problem of link manipulation is with respect to the visually similar sites. For example, the website www.paypal.com looks similar to www.PayPal.com or www.Paypal.com. Attackers take such mistakes from the user side to their advantage to steal information.
Filter Evasion : many security firms have designed to filter out phishing sites based on the content, links, etc in the web pages. But such filters are evaded by the attackers by using images, instead of text.
Website Forgery : many websites that support online payments and secure transaction have unique address bar. They come with either the company's symbol or with a color or a lock symbol, etc, to show those sites belong to the original company. Attackers use Java Script commands to change the address bar and deceive the users. It basically dealt with forging the website's scripts to their advantage. These came to known as Cross-site scripting.
Phone phishing : it is not necessary that phishing can be done only through websites. People receive phone calls saying that they are from the bank where they hold accounts, claiming that they have problems with the users' account. This way, they get all the personal information regarding the user's account through the phone.
Pop-up windows : the attackers successfully forward the client to the bank's legitimate website. But when they use a pop-up window requesting the username and password, as if it were being asked by the bank itself. Very tricky one.
Many tools, strategies and solutions are proposed and put in use to overcome phishing. Let us look at various solutions that come and went till now and those that are still in use.
Anti-phishing measures have been implemented in various ways. Some are just design solutions for strong authentication; some are used as plug-ins in browsers, toolbars and few others as part of login procedures. Here we divide these anti-phishing strategies into various categories such as: user training, security solutions and tools (toolbars and plug-ins). We shall take a look at each of them one by one.
As users tend to ignore the warnings given by the tools, an initiative to train the users on the aspects of phishing was taken. Users were given information on how could they be tricked into phishing attacks. The most basic approach was to post articles and materials on websites that taught the users, hoe to detect and prevent phishing. And most interactive way was to let users assess their knowledge on phishing through some web-based tests. Few sites put up some flash based games where the user had to indentify which site was a phish and whish isn't based on some rules. It made the whole training more fun and productive.
Phishing education was also conducted in a classroom setting, as has been done by Robila and Ragucci. The idea of sending fake phishing emails to test users' vulnerability has been explored by several groups. Typically, at the end of such studies, all users were given additional materials to teach them about phishing attacks. This approach has been used with Indiana University students and West Point cadets, as well as with employees at a New York state office. This study was conducted in two phases. In the first phase the participants were tried to detect phishing sites without any training and were tested for their ability. In the second phase, they were given materials on phishing and then tested again. On comparison the studies showed significant improvement.
Security solutions can be further classified into two groups such as third party certifications and authentication mechanisms. Most of these solutions can be implemented independent of the browsers we use and their versions. We shall now look at various security solutions in detail.
Silently eliminating the threat
The strategy of this is to provide protection without the giving any work to the user. The phishing sites are detected and removed from the web silently. Also the fraud emails and messages are detected and deleted . But the problem here is that we cannot achieve hundred percent accuracy every time. By the time we detect a phishing site, it would have been online for long enough to snare unsuspecting victims. According to the Anti-Phishing Working Group (APWG), phishing sites manage stay online on average for 4.8 days .
A number of tools were developed to warn users that the website they are visiting is likely fraudulent or legitimate. They either provided explicit warnings or provided interfaces that helped people notice that they may be on a phishing website. Ye and Sean and Dhamija and Tygar developed prototype "trusted paths" for the Mozilla web browser that was designed to assist users in verifying that their browser has made a secure connection to a trusted site. More common were few toolbars which provided indication of overall safety of the website by flashing red or green lights on the browsers . But they had their share of weaknesses:
First, it required people to install special software (although newer versions of web browsers have such software included).
Second, user studies showed that users often do not understand or act on the indications or warnings provided by toolbars.
Third, a recent study shows that some anti-phishing toolbars are not very accurate, and even the best toolbars may miss over 20% of phishing websites.
Even though there were many techniques already existing to prevent phishing the rapid growth in the attacks called for more better and strong solutions. Since then many solutions were proposed ranging from quick fixes to substantial redesigns. All these proposals were evaluated based on four security properties: the limited human skills property, general purpose graphics property, the golden arches property, the unmotivated user property and the barn door property. Few proposals addressed most of these properties whereas few failed to do so. Attempts to solve the phishing problem were again divided into three approaches: going for Third party certifications, designing Direct authentication mechanisms, and Anti-Phishing tools.
Third Party certifications
Hierarchical and Distributed trust models
Third party certification includes hierarchical trust models, like Public Key Infrastructure (PKI), which were proposed long ago as a solution for users to authenticate servers and vice-versa. In PKI, chains of Certificate Authorities (CAs) vouch for identity by binding a public key to a entity in a digital certificate. The Secure Sockets Layer (SSL), now known as Transport Layer Security (TLS), both rely on PKI. The problem here is that, in the typical use of SSL today only the server is authenticated. Even with the wide use of one-sided SSL (in the form of server digital certificates signed by a trusted CA), there were problems. As examined in their task analysis, certificates have been falsely issued, and most users do not have the knowledge or skill to understand digital certificates and the delegation of trust.
Other third party approaches included "web of trust" distributed trust models (e.g., Pretty Good Privacy) and the use of third party seals to indicate trusted websites (e.g. Verisign Seal Program and TRUSTe ). By displaying seals as graphics that can be easily copied, trusted seal programs ignored the "general purpose graphics" property.
The "Trustbar" proposal was again a third party certification solution, where websites logos were certified. A "trusted credentials area" was created as a fixed part of the browser window. This area was used to present credentials from the website, such as logos, icons and seals of the brand, that have been certified by trusted certificate authorities or by peers using a PGP "web of trust". Strength of this solution was that it did not rely on complex security indicators. However, careful consideration had to be given to the "general purpose graphics" and "golden arches" properties. Because, since the logos do not change, they could be easily copied and the credentials area of the browser could be spoofed (e.g., an attacker can draw an image of the credentials area into the top portion of an un-trusted webpage to make it appear trusted). Therefore, careful consideration had to be given to the design of an indicator for insecure windows so that spoofed credentials could be easily detected. But there remained an ambiguity in the cases where two sites used similar logos and they were supposed to certified uniquely.
This approach included user authentication and server authentication schemes.
Multi-Factor User Authentication
These schemes used a combination of factors to authenticate the user. The factors can be something you know (for example, a password or ATM PIN), something you have (for example, a token or key) or something you are (for example, biometrics).
America Online's Passcode was proposed as a phishing defense. This program distributed RSA SecurID  devices to members of AOL. The device generated a unique six-digit numeric code and displayed it, every 60 seconds. This could be used as a secondary password while logging into AOL website. This scheme reduced the value of collecting passwords because the passwords were of no use for another transaction. But however, they failed to prevent a man-in-the-middle (MITM) attack where the attacker could lure a user to a spoofed AOL website so that he/she can collect both the primary and secondary passwords. These passwords can immediately be presented by the attacker to AOL in order to masquerade as the user. The Passcode program did however raise the bar for phishing attacks today, but it has its own issues; phishers will soon turn to this type of "live" MITM attack, if the bar is raised everywhere. This again had a problem. This scheme ignored the "limited human skills" property, by not providing the user with any means whatsoever to verify the correct identity of the server.
Secondary SMS Passwords
One of the other two factor user-authentication schemes was issuing secondary passwords to users through Short Message Service (SMS) as text messages on their cell phones. This was again susceptible to MITM attacks. Originally these two factor user authentication schemes were used to protect the server from fraud rather than protecting the users from phishing. This again ignored the "limited human skills property".
Server Authentication using Shared Secrets
Passmark and verified by Visa
Shared secret schemes were one of the simplest ways to authenticate web servers. In this technique, the user had to share a secret such as an image and/or a pass phrase. This secret will be later revealed by the server to the user to authenticate itself. The most obvious drawback of this method was that the server had to display this secret in order to authenticate itself. So this gave a chance to the attacker to capture and replay it. But this technique used the concept of cookies. The server placed a cookie on the user machine thus preventing MITM attacks. However, this did not prevent the attack in which a rouge server instructed the browser two identical windows, where one was legitimate and the other one is a phish. By careful placement of the rouge window, the attacker could make the user enter the username and password into the phish rather than the original one. This was done by spoofing the passmark "re-registration" process.
The passmark had to be re-registered in case the user wished to user a computer in which the cookie is already not set or the cookie had been deleted. Hence, the attacker was able to redirect the user to a page where it claims that the page has been deleted, in order to make the user re-register again. The legitimate page that showed the error always asked the user to ensure that he/she has reached this page by manually typing the URL by hand. The spoofed page however did not include this error.
A number of attacks that required more difficulty were possible (e.g., breaking the secure cookie, physical observation of the secret image, discovering the potential range of images and then guessing the image). However, spoofing required the least amount of effort to defeat the most people, and was expected that this type of spoofing attack would become common if systems like Passmark were widely deployed. Evidence suggested that users were able to correctly recognize a large number of images. However, the problem was that if a user is required to remember different images or passphrases for a number of different servers, any difficulty in recognizing an image could be exploited by an attacker. This scheme ignores the "limited human skills", "general purpose graphics" and "golden arches" properties.
Server authentication using self-shared secrets
This authentication scheme required the user to share a secret with his/her own device (for example web browser) rather than the web server.
SRD (Synchronized Random Dynamic) Boundaries
Ye and Smith proposed "Synchronized Random Dynamic Boundaries" to secure the path from users to their browser. This scheme used a random number generator to set a bit that determined whether the browser border is inset or outset. The browser border alternates between inset and outset at a certain frequency in concert with a reference window. The strength of this solution was that it was good in recognizing the "general purpose graphics" problem. In this technique, rogue servers could not predict the random number which is chosen by the browser, and therefore it was difficult to create spoof windows that blink at the correct frequency. But a weakness of this approach was that it ignores the "limited human skills" property; dynamically "blinking" borders may be easy to distinguish for the users, and frequent border changes were likely to prove to be distracting. The security depended on how many border frequency options are available and how many users can differentiate.
In the YURL proposal, the user's browser maintained a mapping of a public key hash to petname. When a user visited a page that is identified by a YURL, the browser displayed the petname that the user previously associated with the public key hash. This helped in recognizing an un-trusted site if the corresponding petname was not present. This was a very simple scheme that required a small degree of personalization for each website. But scheme ignored the "unmotivated user property" because security relies on users to be motivated to customize petnames for trusted sites. One advantage of this technique was that the secret (the petname) was shared with the user's browser, rather than with the trusted server. Careful consideration had to be given to the design of the un-trusted state i.e., un-trusted windows had to be clearly marked as having no petname. Otherwise, attackers could spoof the petname display area in the browser and fool many users.
The "limited human skills" property is also important. Petnames relied on user's memory to recognize, and to associate the secret phrase with the correct website. It is expected that users would choose predictable petnames. For example, many users would choose "Google" for google.com. The designers can encourage users to select unique petnames to improve spoof resistance.
The eBay Toolbar is a browser plug-in that eBay offered to its customers. It helped keep track of auction sites for them. The toolbar has a feature, known as AccountGuard, which monitors web pages that users visit and provided a warning in the form of a colored tab on the toolbar. The tab is usually appears grey, but turns green if the user is on an eBay or PayPal site or red if the user is visiting a site that is known to be a spoof by eBay . The toolbar also allowed users to submit suspected spoof sites to eBay. One big drawback to this particular approach was that it only worked for eBay and PayPal websites. Users would not want to maintain too many toolbars that each and every site offers to detect phish. However, it is not difficult to develop a generalized program or tool for this. The main weakness was that there will always be a period of time between the time a spoof is detected and when the toolbar can begin detecting spoofs for users. If spoofs are not carefully confirmed, denial of service attacks is possible. This indicates that some percentage of users will still be vulnerable to spoofing. For these users, "the barn door" property means that their personal data will not be protected.
SpoofGuard is an Internet Explorer browser plug-in that examines web pages and warns users when a certain page has a high probability of being a spoof. This calculation is performed by carefully examining the domain name, links and images and comparing them to the stored history and also by detecting common characteristics of spoofed websites. It would make phishers to work harder to create spoof pages, if used. However, SpoofGuard always had to stay one step ahead of phishers, who could test their web pages against it. New detection tests were continuously needed to be deployed as phishers become more sophisticated.
SpoofGuard made use of what is called PwdHash. It is an Internet Explorer plug-in that replaced a user's password with a one way hash of the password and the domain name. So, the web server only received a domain-specific hash of the password instead of the password itself. This is a simple but useful technique in addressing the "barn door property" and preventing phishers from collecting user passwords. Both SpoofGuard and PwdHash ignore the "general purpose graphics" property by using a security indicator (a traffic light) that can be easily copied.
Spoofstick is again a toolbar extension for Internet Explorer and Mozilla Firefox that provides basic information about the website's domain name. That is, if the user is visiting Amazon, the toolbar will display "You're on amazon.com". If the user is at a website site that is spoofed, the toolbar instead displays "You're on 18.104.22.168". This toolbar helped users to detect attacks where the rogue website has a domain name that is syntactically or semantically similar to a legitimate site. Unfortunately, the current implementation of Spoofstick could easily be fooled by clever use of frames when different websites are opened in multiple frames in the browser window. This ignored the "limited human skills" property, because, users had to be aware of the use of hidden frames on a webpage. Spoofstick does address the "general purpose graphics" property by allowing users to customize the appearance of the toolbar.
However, most of the above tools relied on primarily on blacklists, lists of URLs that have been observed hosting phishing attacks. Blacklists provide no protection from attacks that are not already flagged as phishing. There are considerable numbers of such missed attacks. Researchers have proposed supplementing blacklists with Information Retrieval (IR)-based tools. However, an IR-based approach was assumed to have generating false positives; legitimate websites were being incorrectly flagged as phishing. False positives undermined user's trust in a tool and pose questions of legal liability. This basically added more to the phishing ability of the attackers.
BayeShield: Conversational Anti-Phishing Interface
To overcome the above problem, Peter Likarish et al, came up with an idea of BayeShield user interface which acted as a front-end to IR-based tools to identify phishing attacks with high probability but still with a few false positives. This required one pre-requisite, to educate users through a series of questions that lead to a conclusion whether the website was legitimate or an attack. This was a lengthy process to be followed every time a site was to be opened. Also, this worked only 65% of the time providing correct solutions. Its tendency to flag legitimate websites as an attack sometimes, pose to be source of confusion to the users.
iTrustPage is an anti-phishing tool that avoided full fledged automation and instead went for user assistance to detect phishing. iTrustPage, also relied on external repositories of information in order to prevent users from filling phishing Web forms. With iTrustPage, users helped to decide whether or not a Web page is legitimate. Since iTrustPage is user-assisted, it avoids the false positives as well as the false negatives associated with automatic detection of phish, to a large extent. It was implemented as a downloadable extension to FireFox. This itself proves to be a disadvantage as it limits the range of browsers this tool can be used. Also, its use becomes difficult in organizational networks where downloading is prohibited, for example universities, etc.
TruWallet, is a wallet-based authentication tool. It improves the previously proposed or used solutions for protecting web-based authentication. In contrast to other wallet-based solutions, TruWallet provides (i) strong protection for users' credentials and sensitive data by cryptographically binding them to the user's platform configuration based on Trusted Computing technology, (ii) an automated login procedure where the server is authenticated independently from (SSL) certificates, thus limiting the possibility of attacks based on hijacked certificates and allowing less dependency on the SSL PKI model, and (iii) a secure migration protocol for transferring wallet data to other platforms. This tool used a small virtualization-based security kernel with trusted computing support and works with standard SSL-based authentication solutions for the web, where only minor modifications and extensions were required. It was made interoperable so that existing operating systems and applications like web browsers could be re-used.
SpamAssasin is an open source spam filter. SpamAssasin identifies spam signatures using a wide variety of local and network tests. Using this made it very hard for spammers to identify even a single aspect which they can craft their messages to work. A well designed, abstract API was used to encapsulate its logic, so it could be integrated anywhere in the email stream. It requires very little configuration. It was not required that the users should continually update it with their mailing list memberships, mail accounts, etc. Once classification was done, site and user-specific policies could be applied against spam. Policies can be applied on both mail servers. Later it could be done using the user's own mail user-agent application. This tool helped in filtering a large extent of the spam emails sent by the attackers targeting the users.
Apart from the tools and security solutions shown above there are organizations like Anti-Phishing Work Group (APWG), TRUSTe and NetCraft that provide anti-fraud and anti-phishng services, online privacy seals, etc, to further safeguard our websites and personal information from being stolen by the attackers.
Anti-Phishing Working Group (APWG), is the global pan-industrial and law enforcement association focused on eliminating the fraud and identity theft that result from phishing, pharming and email spoofing of all types.
Netcraft is an Internet services company based in Bath, England. It provides services like internet security, which includes anti-fraud and anti-phishing services, application testing, automated penetration testing and code reviews.
Most of the anti-phishing tools here seem to have usability problems. Anti-phishing tools were able to identify all fraudulent web sites without any false positives, but because of usability problems, users could still fall victim to fraud. User testing is needed to better understand how users react to each different style of warning, for example, in eBay tool bar when it flashes different colors. Future studies on anti-phishing tools should also take into consideration, usability testing. A technically sound tool is of little or no use if users are unsure of what it is trying to communicate to them. Previous research has examined the effectiveness of several techniques for informing users about phishing . However, it did not evaluate the effectiveness of pop-up warnings, or the difference in user reaction upon seeing a warning versus having a web site blocked. Usability problems plague all varieties of software - particularly security software. Poor usability, for an anti-phishing tool, means the difference between correctly taking someone away from a phishing site and then have them ignore the warnings only to become a victim of identity theft.