LDAP Injection

Introduction

Lightweight Directory Access Protocol (LDAP) is a widely used protocol for accessing information directories. LDAP injection is the technique of exploiting web applications that use client-supplied data in LDAP statements without first stripping potentially harmful characters from the request. The objective of this paper is to inform developers, system administrators and security professionals about various techniques that could be used to attack their applications. It also describes preventive measures for protecting applications from these intrusions.

The example used in this white paper was written using Active Server Page (ASP) under Microsoft Information Server (IIS) and making use of the LDAP control written by nSoftware. The back-end LDAP server used is SunOne Directory Server 5.0.

LDAP Query Introduction
Before discussing how to attack web applications using LDAP, let’s review some of the basics of how LDAP search queries are constructed and what to expect in return. Let’s look at how the example application used in this paper construct its queries and how it deals with the data returned.
The example application simply takes a query argument called "user" and searches the LDAP directory for the user’s cn (common name), mail, and telephone number attributes. Once the data is returned, the application displays the information to the user, as illustrated in Figure 1.

Figure 1: Normal application processing.

To examine how the application constructs the query, let’s use the debug switch in the query string. Figure 2 displays the underlying LDAP query construction based on the user information.

Figure 2: Normal search operation with debug information.

According to the displayed debug information, the application searches the ou=people,dc=spilab,dc=com tree of the directory for the attributes cn, mail and telephoneNumber. The filter part is a bit more complicated and provides the mechanism for LDAP injections. The filter used in the application is uid = user_supplied_value, where the value is sfaust.

Attacking LDAP Search Queries
The most widely use of LDAP in web applications is to enable users to easily search for specific data on the Internet. For example, a college or university might electronically publish white pages that allow users to find information about students and teachers. As illustrated in Figure 3, the example LDAP-enabled Web application displays specific information about a user by accepting the user name in a query argument.

Figure 3: Normal search operation.

Understanding the Query Construction
Now that we have a basic understand of what the application does, let’s examine how the application is constructing the LDAP query to get the information.

The first step should be to determine if the application is attempting any type of validation on the data sent by the user. To test for this, we can send a few requests with unusual characters and see how the application reacts to them. Figures 4 and 5 illustrate these simple requests.

Figure 4: First test for user input validation.

Figure 5: Second test for user input validation.

In the first validation test, the probe sends data that even the least sophisticated data validation routine would reject (as seen in Figure 4). In the second test, the probe sends a request that might look like a valid character in an LDAP query string (as seen in Figure 5). The returned data illustrated in Figures 4 and 5 indicate that the application is not validating the data passed in the query and is storing the value directly into the LDAP object. Since the data is injected in the query, the application returns an error because of the invalid LDAP query created. This test application also sends a closing parenthesis, but it could use any valid filter character such as the following: ( &.

Having identified the type of validation performed by the target application, the attacker can reverse-engineer the structure of the LDAP query to determine how the user-supplied data is used to perform the search. The LDAP search filters are always enclosed between parentheses. To locate the data in the filter string, try to generate valid LDAP filters by adding a few valid characters to the beginning and end of the argument value, and then examine the response.

If the application reports an error, the probe is generating an invalid request. If the application returns without errors or with new data, the probe has created a valid query. This process can be time-consuming depending on the size of the query and the number of arguments sent. Figures 6 and 7 present a few examples.

Figure 6: Sending " " returns no errors and no data.

Figure 7: Sending ampersand (%26) returns no errors and no data.

As illustrated in Figures 6 and 7, we can see how the query is structured by sending logical operators such as OR and AND. The actual query substitutes the symbols " " for OR and "&" (URL-encoded as %26, to prevent the target application from interpreting the operator as query name/value separator) for AND. Because the target application does not return an error, the injected values must have created a valid query. With that information in mind and by looking at the LDAP query syntax, the attacker can conclude that the application generates a query in the following format: (some attribute=user input). The injected value in Figure 6 would generate (some attribute=user input). In Figure 7, the injected value would generate (some attribute=user input&). Both are valid queries that return no values.

To verify these assumptions, try to get the cn value of the user sfaust. This requires injecting data to generate a query that looks like (some attribute=user input)((cn=*)), which instructs the server to return any cn values. Since the assumption is that the query looks like (some attribute = user input), to get (some attribute=user input)((cn=*)), we will need to inject sfaust)((cn=*). Figure 8 illustrates the actual string and the results of the query.

Figure 8: Getting the cn value of the user.

In this example, the injection works, confirming the assumptions about the structure of the query.

Generating Attacks
Having determined the structure of the query, we can generate additional attacks to access more information. First, we need to discover what attributes are available by querying the LDAP server to obtain an objectclass listing. Then, simply refer to http://docs.sun.com/source/816-6699-10/objclass.html to see the attributes included in each objectclass. If the objectclass listed is not on the above site, you can usually find the information by searching the Internet with your favorite search engine. Figure 9 shows the list of available objectclasses for our user.

Figure 9: Getting a list of available objectclasses.

Now that we have a list of objectclasses, we can pick one and see if we have rights to view the data. This example uses the posixAccount objectclass, but any could contain interesting information. By looking at the class definition in RFC 2307, we see that the following attributes are required and should be available.
• cn
• uid
• uidNumber
• gidNumber
• homeDirectory

In theory, we should be allowed to see any of these attributes. Figure 10 illustrates the attempt to get the home directory of the user sfaust.

Figure 10: Getting the home directory for user sfaust.

Bingo! We now know that we can view the attributes of the posixAccount objectclass. We can apply the same techniques to all the objectclasses and obtain the data.

To obtain a listing of all the users on the system (and view their settings), simply use a wildcard character as the user value. Figure 11 illustrates this request and the subsequent response.

Figure 11: Getting a listing of all users.

Prevention
Protecting LDAP-enabled web applications demands the effort of developers as well as the LDAP administrators. Though effective at reducing the risk of such an attack, the approaches discussed in the next section are not complete solutions. It is best to remember that web application security, by its own definition, must be a continually evolving process. As hackers change their methodologies, so must those who want to implement a secure Web application.

Incoming Data Validation
All client-supplied data needs to be cleaned of any characters or strings that could possibly be used maliciously. This should be done for all applications, not just those that use LDAP queries. Stripping quotes or putting backslashes in front of them is nowhere near enough. The best way to filter data is with a default-deny regular expression that includes only the type of characters that you want. For instance, the following regular expression will return only letters and numbers:

s/[^0-9a-zA-Z]//g

Make your filter as specific as possible. Whenever possible use only numbers. After that, numbers and letters only. If you need to include symbols or punctuation of any kind, make absolutely sure to convert them to HTML substitutes (such as " "e; " or " > "). For instance, if the user is submitting an email address, allow only the "at" sign, underscore, period, and hyphen in addition to numbers and letters, and only after those characters have been converted to their HTML substitutes.

Outgoing Data Validation
All data returned to the user should be validated and the amount of data returned by the queries should be restricted as an added layer of security.

LDAP Configuration
Implementing tight access control on the data in the LDAP directory is imperative, especially when configuring the permissions on user objects, and even more importantly if the directory is used for single sign-on solution. You must fully understand how each objectclass is used and decide if the user should be allowed to modify it. Allowing users to modify their uidNumber

attribute, for example, may let the user change access levels when accessing systems. The access level used by the Web application to connect to the LDAP server should be restricted to the absolute minimum required. That way, even if an attacker manages to find a way to break the application, the damage would be limited. In addition, the LDAP server should not be directly accessible on the Internet, thereby eliminating direct attacks to the server itself.


Appendix A: LDAP References

For more information on LDAP, refer to these additional resources.
RFC 1960 - A String Representation of LDAP Search Filters http://www.ietf.org/rfc/rfc1960.txt

LDAP Overview
by Bruce Greenblatt, http://www.directory-applications.com/ldap3_files/frame.htm

Understanding LDAP
by IBM, http://www.redbooks.ibm.com/redbooks/SG244986.html

LDAPMAN web site
http://ldapman.org/

PA-DSS secures payment applications

A new standard under development by the PCI Security Standards Council aims to shore up a gaping hole in the payments process: vulnerable payment applications.

The Payment Application Data Security Standard (PA-DSS) is based largely on Visa's Payment Application Best Practices (PABP) program, which was introduced in 2005 to help software vendors create secure payment applications. Bob Russo, general manager of the PCI Security Standards Council -- which manages the Payment Card Industry Data Security Standard (PCI DSS) -- said vulnerable applications are often the weak link exploited by thieves.
Visa said its research showed that vulnerable payment applications are the leading cause of compromise, especially among small merchants.

"Criminals are targeting certain versions of software because of their known security gaps," Michael E. Smith, senior vice president of payment system risk at Visa, said in a statement. "Some versions of software in use today are known to store the full content of the magnetic stripe, PIN data or security codes, contrary to Visa rules and the PCI Data Security Standard."

The PA-DSS, which is endorsed by the five major payment card brands (American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa Inc.), will ensure payment applications don't store sensitive card data and aren't rife with flaws that can lead to cross-site scripting and SQL injection attacks. Russo said a lot applications are hastily written with little heed paid to security; the standard will make sure developers account for security.

Applications developed internally by merchants and others are subject to PCI DSS, not PA-DSS.
Russo said the council sent out Visa's PABP as the draft PA-DSS standard to its advisors, participating organizations, Qualified Security Assessors (QSAa), and Approved Scanning Vendors for feedback. The council plans to publish a final version of the standard by the end of the first quarter of this year, and then roll out training for QSAs and a list of validated payment applications.

Requiring merchants to use the validated applications is up to the payment card brands, Russo said. In November, Visa announced a series of requirements for U.S. merchants to use secure payment system software. An American Express spokeswoman said in an email that the company doesn't currently have any specific rules regarding what payment applications its merchants use, but "will look to make appropriate adjustments to our merchant agreements to ensure the security of all of our customers." MasterCard did not immediately respond to a request for comment.

Visa's phased-in mandates began Jan. 1 and require U.S. banks that service merchants to ensure they only use versions of payment applications that don't store sensitive card data and that adhere to PABP (Visa said its mandates will be modified to reflect the final PA-DSS). As of Jan. 1, service merchants cannot sign new merchants that use known vulnerable payment software. By July 1, 2010, service merchants must ensure their merchants use only PABP-compliant applications.

Approximately 200 applications have been validated against PABP, according to the council. That represents less than half of the payment applications used by merchants, said Roger Nebel, an independent PCI DSS auditor and director of strategic security at FTI Consulting.
"The majority of payment applications have never been audited and likely don't pass PABP," he said.

Common weaknesses in payment applications include SQL injection flaws and use of default user IDs and passwords for remote software management, Nebel said. The PA-DSS sets a relatively low bar but if followed can dramatically increase security, he added.
While merchants will be forced under Visa's requirement to absorb the cost of obtaining validated applications, acquiring banks will be the primary enforcers of the new mandate, Nebel said.

Diana Kelley, a vice president and service director at research firm Burton Group, said Visa's PABP focused on point-of-sale systems. Now under management of the PCI Security Standards Council, the PA-DSS establishes an industry-wide bar for securing POS systems, and will help raise awareness of application security.
"It's a good baseline," she said.

For ACI Worldwide, a New York-based payment software developer, the PA-DSS is good news. "We're happy that the industry is consolidating around a standard," said Douglas Grote, senior product manager at the company.
ACI Worldwide has been participating in Visa's PABP program and has three products validated as PABP-compliant with about 10 more in the process of being validated. Although PABP validation was not a requirement, the company aimed to be proactive.
"First, we want to make sure we are developing secure software. We consider ourselves a premier supplier in the industry and we want to assure our customers that we take this seriously," Grote said. "Second, we want to make sure our customers can pass their PCI audits. We don't want anything in our product to prevent them from being successful."

Validation is comprehensive process that includes requirements such as monitoring for threats that might affect the application, he said. "Many of the objectives are outside of the actual code that we ship to customers."
With the new PA-DSS, ACI will need to revalidate its applications but Visa already required annual revalidation under PABP, Grote said.

DNS Redirection

This attack is exactly the same as the default gateway redirection, but instead of sending back a bogus default gateway the rouge DHCP sends back a bogus DNS server. This then allows the attacker to quietly redirect just certain requests. For example, you think your accessing your bank WWW site, but the attacker is using their own DNS server to redirect you to a fake WWW site that they have set to capture your details.

Mitigation

The mitigation strategy is exactly the same as for the default gateway redirect. Stop rogue DHCP responses getting onto your network, and you won't get your details stolen by this attack.

Man in the Middle Attacks by defualt Gateway Redirect

This is also a simple attack. The attacker either disables the primary DHCP server using a denial of service attack then operates their own DHCP server, or they simply setup a faster DHCP than the one already on the network. When a client sends out a DHCP request it accepts the response from whichever DHCP responds first.

If the attacker wants to see all the traffic you are sending out of your local subnet, then they simply respond to your DHCP request, and specify there own machine as the default gateway. The attacker's machine then forwards on any traffic to the real default gateway. Now the attacker can see everything your sending (perfect for username and password theft, identify theft, or capturing other sensitive information).

Mitigation
Cisco have a technology to overcome this called DHCP snooping. What happens is you tell the switch which port(s) have a DHCP server plugged in. The switch then only allows that port to respond to DHCP queries. Simple. This feature is available on layer 3 switches such as the Cisco 3560, but note that the EMI feature set is often required. A limited form of DHCP snooping is available on layer 2 switches, but it can only limit the rate at which DHCP packets are sent.

First, enable the feature globally.
ip dhcp snooping vlan 1
no ip dhcp snooping information optionip
dhcp snooping

Then tell the switch to trust ports that have a DHCP server plugged into them.
interface FastEthernet x/y
ip dhcp snooping trust

That's the basic config done

DHCP Address Starvation with MAC flooding

This is perhaps the simplest and fastest attack. DHCP servers have a limited number of addresses that they can give out. DHCP scopes commonly have less than 200 addresses that they give out to hosts (the rest of the space is often reserved for static IP devices, such as servers, printers, etc). So to stop the DHCP server from working all an attacker has to do is send DHCP requests using random MAC addresses. It keeps sending requests until the DHCP server stops responding. Of course, the DHCP has no idea what's going on, so it keeps responding to all the requests it sees coming in. It has no idea it is being attacked. This attack usually take less than 10s to complete, and uses a very small amount of bandwidth. As long as the attack uses forged MAC addresses (and the common tools for doing this attack do this) it is very difficult for the Windows administrator to track down, since all of the information they have available to them is forged.

Mitigation
Mitigation of this attack is very simple with a Cisco switch, using a feature called port security. What port security does is limit the number of MAC addresses a client machine can use. So if you enable the feature on every port that can connect to a workstation, and a workstation tries to send a packet with a MAC address different to that of a packet it has sent in the same session, the switch will shut the port down stopping the attack dead. Port security is supported on Cisco 2950's and above. The switch clears the MAC address associated with a port when the link goes down (such as the workstation being turned off, or unplugged). So it works happily with ports shared by different machines (as long as only one machine at a time is plugged into the port).

interface FastEthernet x/y
switchport port-security

8 steps to protect your Cisco router

In this article I will give you 8 steps, easy to follow, to minimize your Cisco router exposure by turning off some unused services, applying some access control and applying some security options available on that.
1- Control Access to your router;
2- Restrict telnet access to it;
3- Block Spoof/Malicious packets;
4- Restrict SNMP;
5- Encrypt all passwords;
6- Disable all unused services;
7- Add some security options;
8- Log everything;


1- Control Access to your router
The first thing to do is apply some rules to restrict all external access to some ports of the router. You can block all ports, but it is not always necessary. These commands bellow will protect your router against some reconnaissance attacks and, obviously, will restrict access to these ports:

access-list 110 deny tcp any host $yourRouterIP eq 7
access-list 110 deny tcp any host $yourRouterIP eq 9
access-list 110 deny tcp any host $yourRouterIP eq 13
access-list 110 deny tcp any host $yourRouterIP eq 19
access-list 110 deny tcp any host $yourRouterIP eq 23
access-list 110 deny tcp any host $yourRouterIP eq 79

int x0/0
access-group in 110

Where $yourRouterIP is your router IP and x0/0 is your external interface. We Will always use this convention in this article.


2- Restrict telnet access to it
Telnet is not a very safe protocol to use, but if you really need to use it (you should always use ssh) you might want to restrict all access to it (remember that all your traffic will be unencrypted). The best way to accomplish that is using a standard access-list and the access-class command.

access-list 50 permit 192.168.1.1
access-list 50 deny any log

line vty 0 4
access-class 50 in
exec-timeout 5 0

Where 192.168.1.1 is the IP address allowed to telnet the router


3- Block Spoof/Malicious packets
You must never allow loopback/reserved IP address from the Internet reach your external
interface and you can reject broadcast and multicast addresses too.

access-list 111 deny ip 127.0.0.0 0.255.255.255 any
access-list 111 deny ip 192.168.0.0 0.0.0.255 any
access-list 111 deny ip 172.16.0.0 0.0.255.255 any
access-list 111 deny ip 10.0.0.0 0.255.255.255 any
access-list 111 deny ip host 0.0.0.0 any
access-list 111 deny ip 224.0.0.0 31.255.255.255 any
access-list 111 deny icmp any any redirect

int x0/0
access-group in 111


4- Restrict SNMP
SNMP must always be restrict, unless you want some malicious person getting a lot of information from your network.

access-list 112 deny udp any any eq snmp
access-list 112 permit ip any any

interface x0/0
access-group 112 in

And if you are not going to use SNMP at all, disable it:

no snmp-server


5- Encrypt all passwords
A very important thing to do is protect all your passwords using the powerful algorithm as possible.The password from exec mode, that grants privileged access to the IOS system,
Can be set using a MD5 hash, which is the strongest option available on the Cisco IOS.

enable secret $yourpassword

All other passwords, you can encrypt using the Vigenere cipher that is not Very strong, but can help. To do that, you can use the service password-encryption Command that encrypts all passwords present in you system.

service password-encryption


6- Disable all unused services

6.1 - Disable Echo, Chargen and discard
no service tcp-small-servers
no service udp-small-servers

6.2 - Disable finger
no service finger

6.3 - Disable the httpd interface
no ip http server

6.4 - Disable ntp (if you are not using it)
ntp disable


7- Add some security options

7.1 - Disable source routing
no ip source-route

7.2 - Disable Proxy Arp
no ip proxy-arp

7.3 - Disable ICMP redirects
interface s0/0 (your external interface)
no ip redirects

7.4 - Disable Multicast route Caching
interface s0/0 (your external interface)
no ip mroute-cache

7.5 - Disable CDP
no cdp run

7.6 - Disable direct broadcast (protect against Smurf attacks)
no ip directed-broadcast


8- Log everythingTo finish

you must log everything on an outside Log Server. You must log everything from all your ystems and always analyze the logs.
logging trap debugging
logging 192.168.1.10

where 192.168.1.10 is the ip of your log server (configured as a Syslog server)

Phishing Countermeasures

Just as successful phishers have turned to a distributed, multi-tiered system of attacks, so must institutions and consumers rely on a distributed, multi-tiered and layered defense in order to protect themselves. There is no silver bullet solution to defeat phishing; instead, a variety of technical and social techniques must be employed.

User Education
One key element of the war on phishing, and of information security in general, is consumer education. After all, if potential victims could be convinced to inspect email headers, to verify URLS, and not to reveal their personal and financial information to phishers, then the problem would just go away. However, education is not a sufficient answer in itself; con men have been running the same scams via Internet, telephone, and postal mail for ages. Yet many consumers are eager to learn how to protect themselves from online fraud. Savvy ones will learn if they are taught how to protect themselves. User education can be an inexpensive yet high-profile way to decrease fraud while convincing customers that their trust is important to a business.

Email Authentication
An important technical countermeasure to phishing is for businesses to implement an email authentication technology like SenderID or Domain Keys Identified Mail (DKIM) on their email systems. Since no authentication is supported by Simple Mail Transfer Protocol (SMTP), the dominant standard for email transmission, it is very easy for attackers to send spoofed email messages that appear to have originated from a legitimate domain. Designed to combat this, DKIM is an email authentication system that can verify the domain of an email sender and the message integrity. SenderID is an extension to SMTP that allows email servers to identify and reject forged addresses based on entries in DNS records. In essence, using DKIM and SenderID discourages phishing because they make it difficult for a spammer’s email server to masquerade as a legitimate email server, such as that of a bank or other financial institution. Since DKIM and SenderID are complementary technologies, it is ideal for businesses to implement both if possible.

Consumer Reporting
Phishing threatens every company and consumer who uses the Internet, and because of this, many users are eager to help by reporting suspected hoaxes. This is often the most successful method of identifying phishing sites. Potentially targeted companies should make it easy for consumers to report phishing and other methods of Internet scams: every company should have a link on its home page to a web form where anyone can easily report suspected fraud. In addition, every company should have a publicized email account that allows users to easily forward possible phish emails.

Anti-phishing Solution Deployment
Institutions must be proactive in order to defend their brand, reputation and customers from the threat of phishing. There are many components to an anti-phishing solution, including preventing the establishment of cousin or mock domains, detection and analysis of attacks, and technical and physical shutdown of phishing sites. Some solutions try to prevent phishing from occurring by authenticating and filtering email. Others filter web content through consumer products such as browser toolbars. Most anti-phishing solutions rely on an Internet data center that collects, analyzes, and responds to threats. Many rely on consumers to report phishing email and phishing web sites, and then target those email and web servers for shutdown. Anti-phishing solutions must offer this full range of services in order to defeat a phishing attack in a timely manner.

Phishing

Phishing is an online scam in which people are lured to fraudulent web sites, mostly by authentic-looking emails, and asked to divulge personal information such as their user names, passwords, account numbers, addresses, personal identification numbers (PINs), and so on. The phisher, or modern con artist, then uses this information to appropriate the victim’s identity and withdraw money from his or her bank account, run fraudulent online auctions, apply for credit cards, obtain loans, launder money, and engage in a variety of illegal online activities. While these schemes are focused on individual consumers, the institutions that phishers are impersonating are also victims: their brand and hard-earned reputation is impugned. Banks are the most common targets of phishing attacks, but more and more, such attacks are being carried out against auction sites, payment sites, social networking sites, online brokerages, gambling web sites, and online merchants.

This form of fraud has become an unfortunate and thriving economic reality. Online phishing can be traced back as far as 19961 and has escalated swiftly: the number of unique phishing web sites detected by the Anti-Phishing Working Group rose to 55,643 in April 2007, a massive jump from March’s 20,8712. Similarly, PhishTank (a collaborative clearinghouse for data and information about phishing) received 53,263 submissions of suspected phishing sites in May 2007, of which 43,789 were verified.3 A more accurate measurement of phishers’ activities is the number of corporate brands attacked. According to the MarkMonitor Brandjacking Index™, a quarterly report that measures the effect of online threats to brands, the number of brands phished each month reached an all-time high of 229 in March 2007.

Phishing is a serious threat not only to consumers and companies but also to the general perception of the Internet’s suitability for business transactions. A recent poll of 2,120 American adults conducted by the Wall Street Journal and Harris Interactive confirmed online businesses’ worst fears: 30 percent of those polled said they limit online transactions, and 24 percent limit online banking transactions.

Of particular cause for alarm is the growing threat presented by the Phish Gang, a formidable twist on the standard phishing scheme that has garnered tremendous amounts of money for its perpetrators. They are clearly not an average group of thieves, but rather a sophisticated international crime syndicate that has a talented IT staff. By exploiting high-availability practices to achieve system redundancy and horizontal scaling, and relying on a geographically dispersed system, the Phish Gang has developed a methodology that makes them very difficult to defeat using standard anti-phishing measures. Ironically, their success relies on many of the information technology best practices that legitimate companies use to ensure business continuity.


The Typical Phish

In a typical phishing attack, the perpetrator sends out enormous amounts of spam (unsolicited commercial email) including links to fraudulent web sites that are under the control of the attackers. This means that the first step of a successful phishing attack is to evade recipients’ spam filters. Anyone with an email account has been inundated by spam in recent years, and phishers rely on the fact that as spam filters analyze billions of emails a day, dangerous ones can slip by. The phishing email must look legitimate enough that the victim believes it is a genuine communication from a legitimate business. In addition, the phishing email has to entice the victim to act on it (and hand over personal information), perhaps by reporting a fake transaction that needs to be cancelled or requesting account maintenance. Thus, phishing is not purely a technology problem: it is a combination of social engineering and technology prowess. Though phishers rely on technology to carry out their attacks, consumers must take the bait
and then voluntarily provide sensitive information for attacks to succeed.
When a victim is persuaded to act by a phishing email, he connects to a fake web site by clicking on a link in the email. A web browser window opens and takes him either directly or through a series of redirects to the spoofed (fraudulent) web site. Once the victim arrives at the web site, he is presented with a web page that looks like a legitimate company page; usually these pages contain mock corporate logos, privacy policies, and links to report fraud. The victim then fills in his personal information, which is transmitted to the attackers or stored in a text file on the server. Typically, the attacker sells the information to other criminals who then engage in fraudulent transactions.

The fake web site is normally hosted on a compromised web server, one which has been exploited by the phishing attacker for this purpose. The attacker may also use rapidly provisioned free web space, such as that provided by a social networking site, which is usually untraceable; although that is becoming less common. The URL pointing to the fake web site usually contains some wording that impersonates the organization being attacked. For example, if the attacker has compromised the server at http://www.site.com, he may then send victims to http://www.site.com/bankname.com where "bankname" represents the institution being impersonated. This fools naive users, who quickly scan the URL for "bankname" and when they see it, decide that the link is legitimate.

There are a number of variations on this theme. Phishers may use the IP address of the server to further confuse victims. They may also go so far as to register fake domain names, which are typically a variation of the legitimate institution’s domain name, such as securesite.com, and then create a sub-domain that typically includes a variation of the legitimate institution’s domain name, such as: http://www.bankname.securesite.com/.


Recently study shows that Phish Gang has employed several techniques that make them more difficult to defeat than other phishers. In an elaborate, multi-tiered scheme, they use the stolen credentials of their victims to register multiple domain names at multiple registrars. These domain names are usually short and meaningless, such as "342egt.info". The gang then hosts their own authoritative DNS servers using wildcard "A" records to provide name-to-IP service for each of the fraudulently registered domain names. The IP addresses used (and there may be upwards of 100 at a time) point to multiple compromised PCs. These PCs are part of a botnet, which act as proxy connections to a handful of servers that host phish pages of up to 20 fake web sites at a time.


Challenges Presented by Phishing

The difficulty of preventing this technique is that each layer of the phisher’s infrastructure (DNS, proxy server, back-end server) contains redundancies and variations. The advantage to phishers of implementing a distributed architecture is that attacks can continue unfettered when any one element of the system is shut down: a traditional phishing site can be defeated by removing the hosting web site or domain, but Latest Phish sites share hosts and domains; if one is removed, the site automatically switches to another.

It is extremely difficult to track Phish attacks all the way through to the back-end server. The rapid cycling through domain names and IP addresses makes them appear to be always on the move and leaves much of the international security community in a quandary; the Phish Gang seems to be able to bring up countless combinations of multiple tiers in their attacks. This matrix of sites provides a robust system with many levels of failover. If a domain server is taken down, then name-to-IP services failover to another domain server. If a proxy server running on a compromised host is taken down, then the proxy services failover to another compromised host. Although they will typically only be using 10 to 20 such hosts at a time, the Phish Gang is known to be in control of a multitude of compromised web servers, which are commissioned as needed.


To defeat site-blacklisting techniques such as those employed by PhishTank, Google, and many other anti-spam and anti-phishing services, the Phish Gang uses large numbers of slightly varied URLs to draw victims to their fraudulent web site, such as these:
http://welcome23.bank.com.cbibsweb168st.342egt.info/confirm/submit.do/
http://welcome24.bank.com.cbibsweb59121j.342egt.info/confirm/submit.do/
http://welcome22.bank.com.cbibsweb146121k.342egt.info/confirm/submit.do/
http://welcome24.bank.com.cbibsweb574721a.342egt.info/confirm/submit.do/

MarkMonitor has seen as many as 5,000 unique URLs targeting a single organization within a one-month period. This high number indicates that approximately 50 percent of all active phishing URLs during a given period can be attributed to the Phish Gang. As long as a single URL can still be resolved to a single IP address the attack is still fully functioning and dangerously harvesting information. Many combinations of URLs, domains, DNS servers, compromised hosts providing proxy services, and back-end servers can exist.

The Phish Gang has evolved—now, the initial spam email they send to their victims is likely to contain random text followed by a GIF image containing the actual phishing message. Spam filters currently lack an effective means to analyze this GIF image and thus are ineffective. Many analysts estimate that between one third and one half of all phishing email can be traced back to the Phish Gang.

Unfortunately, the successful sophisticated techniques employed by the Phish Gang have motivated other phishers to emulate their methods. These copycats use similar tactics, such as registering bogus domains and using large numbers of variations of URLs. These attacks are much more difficult to defeat and represent an increased threat to consumers and institutions doing business on the Web.

It is difficult, if not impossible to distinguish between the Phish Gang’s attack on a bank and a copycat’s attack on an online payment service, as shown by the URLS each used:

Bank
http://session-05856.bankname.com.kitrt.cn/corporate/onlineservices/TreasuryMgmt/
http://session-101101156.bankname.com.dllet.bz/corporate/onlineservices/TreasuryMgmt/
http://session-101101186.bankname.com.dllet.bz/corporate/onlineservices/TreasuryMgmt/

Online Payment Service:
http://www.onlinepaymentservicename.com.156254.oagty79a.com/cmd-confirm/login.php
http://www.onlinepaymentservicename.com.177461.aaasjpa0.com/cmd-confirm/login.php
http://www.onlinepaymentservicename.com.306716.oagty79a.com/cmd-confirm/login.php