A new attack technique: The "In-Session Phishing"

Date : February 04, 2009

On 29 December 2008, the Trusteer company issued a security advisory concerning a new method of attack, which exists in most JavaScript engine implementations used in major browsers such as Internet Explorer, Firefox, Safari, Chrome, etc... A design bug in JavaScript allows hackers to steal session information (cookies, credentials, etc..), and can be used to abuse online services such as online banking (see our media bulletin on 14/01/2009), online gaming, social networks or to simply bypass applications requiring authentication. This new type of attack is now known as the "In-Session Phishing". Some experts say that this new technique is the end of the Phishing attack through email. But why?

"Phishing" versus "In-Session Phishing"

The "Phishing" attack is now a well-known and classic attack of its kind, as we know it today. An email is sent to some victims, which entices them thanks to varied reasons to click a malicious link. The success rate of this attack is mainly based on the level of persuasion of the mail content and on the credulity of the victim. These factors are difficult to measure by hackers and such attacks often require complementary techniques such as "social engineering" and knowledge of victims to succeed. Moreover, malicious links are now "well" detected by anti-phishing mechanisms embedded in browsers, and the awareness of users makes classic Phishing attacks difficult to succeed.

The "In-session Phishing" attack however, does not require sending emails encouraging a victim to click a malicious link. Hackers no longer have to copy the targeted sites (e.g. banking) and to host them from complacent or unscrupulous ISPs. This new technique only requires a simultaneous navigation (aka tabbed browsing) on an online banking site and on a vulnerable site (e.g. forum) which is hosting a malicious code.

Scenario of an "In-session Phishing" attack

An "In-session Phishing" attack may occur when a victim is connected (with authentication) to an online banking web site for example and is simultaneously browsing in another tab, a compromised web site hosting malicious codes, without closing the session to the banking site. Suddenly, during the navigation, a “session expired” popup asks the user to re-enter its credential (username and password) for connecting to the bank site. Other reasons than session expiration may be used, such as responding to an online survey or participating in a promotional contest.

Since the user has already logged on and has probably already done some transactions, there is a good chance that he does not suspect the popup to be fraudulent, and he will probably re-enter the requested information in order not to lose the current session.

Several conditions are necessary for the attack to succeed:

  • A website must have been compromised (that is to be used to launch the attack) and must be simultaneously visited by the user.
  • The malicious code injected into the compromised website must be able to identify what web sites the user is browsing and if it is connected to one of the targeted sites (online banking, etc.).
  • The website to which the attacker tries to obtain the login of a potential victim must use a specific JavaScript function.

Although these conditions are required, they are easily met on the Internet.

In fact the first condition is "easily" satisfied because there are thousands of web sites which are likely to be compromised on the Internet (forums, etc.). The second one too, since the injected code can be technically advanced and able to detect the visited targeted sites. The third one is also met because online banking, financing, or gaming web sites, and many applications requiring authentication and of interest for hackers, use the vulnerable JavaScript function.

The code injected into the compromised web site does not alter the appearance of the latter. It is then difficult to detect it. The malicious code must be able to detect the online sites (banking for example) to which a victim could be connected to. Then it must be able to provide a popup that appears to come from the online banking site and prompting the victim to provide its identity.

The bug!

The most difficult part for the attacker is to make the malicious code determine whether the victim is connected or not to the targeted web site from which he wants to get login information. A vulnerability in the JavaScript implementation, recently discovered by the Trusteer company, allows using a specific function to determine if the victim is connected to the site of online banking for example. The call to this function leaves in memory a sort of "fingerprint" describing the temporary Internet connection to the targeted site. The use of this fingerprint allows the attacker to know if the user is connected and to send him a popup if so. If the user can be fooled, he provides its credentials to the popup (in fact to the malicious code) thinking to provide them to his banking web site.

How to protect from this attack?

The first two recommendations that could be given are best practices. The first one is simply to remember to log out when you no longer need access to an online site (banking, finance, game, etc.), and not to wait until the session expires. The second one is to be extremely vigilant when a popup window appears during a browsing session, especially if no link from the browsed web site was clicked. In fact, such an expiration window should only pop up when a link is clicked from the browsed web site (e.g. banking), or when a page from this site is refreshed, but rarely during inactivity regarding the session.

Finally, another recommendation is to use a program such as NoScript (see the Cert-IST article entitled “NoScript, a must have Firefox security extension”, although it is valid only for Firefox. The primary function of NoScript is blocking any JavaScript code, it is thereby likely that a vulnerable site compromised to exploit such an attack, will be blocked (except if the user has knowingly allowed the use of JavaScript on this vulnerable site).

For more information:

Trusteer security advisory: In Session Phishing Attacks

Previous Previous Next Next Print Print