ICANN hit by successful spear phishing attack

The Internet Corporation for Assigned Names and Numbers (ICANN) has fallen victim to a phishing attack which resulted in the attackers gaining administrative access to some of ICANN's systems, including its Centralized Zone Data Service (CZDS).

In an email alert sent this morning, ICANN said it believes a spear phishing attack in November resulted in several ICANN staff members' email credentials being compromised. The stolen passwords were then used to gain unauthorised access to multiple ICANN systems, which could have resulted in other usernames and passwords being compromised.

Although CZDS passwords are stored as salted hashes, ICANN has taken the precaution of deactivating passwords and API keys used on the compromised CZDS service. ICANN implemented some security enhancements earlier this year, which it believes limited the extent of the unauthorised access, and has implemented further measures since this attack.

The spear phishing emails involved in this attack were crafted to appear to originate from ICANN's own domain, which is a common tactic for phishers as it lends a fair amount of credibility to the emails. This domain spoofing could well have played an important part in the successfulness of the attack, but icann.org still does not feature any Sender Policy Framework records to specify who can send mail on its behalf.

Organisations concerned about these types of attack can use Netcraft's Fraud Detection service, which processes DMARC (Domain-based Message Authentication, Reporting and Conformance) reports on your behalf. These reports are sent by ISPs and e-mail receivers when they see any emails which claim to be from one of your own domains. A web interface shows the status of all of your own domains, any configuration changes required, and highlights unprotected domains being used by fraudsters attacking your customers.

Banks allow phishers to log in using Tor

The Financial Crimes Enforcement Network (FinCEN), a department of the US Treasury that combats financial crimes such as fraud and money laundering, recently released a report stating that "nearly $24 million in likely fraudulent activity" involved known Tor network nodes. The proportion of fraud that involves Tor is increasing rapidly: according to the report, October 2007 to March 2013 saw an increase of 50% in Tor-related fraud reports, whereas the most recent and much shorter period of March 2013 to July 2014 saw an increase of 100%. The report, which is not public, was obtained by computer security journalist Brian Krebs.

Tor is a piece of open-source software that attempts to provide online anonymity using a technique known as "onion routing". Messages sent by the user, such as HTTP requests from the user's web browser, are sent across the Tor network, instead of being sent directly to the destination server. Before a user sends a message, it is encrypted several times, along with information describing how the message should be routed through a virtual circuit across the Tor network. Circuits consist of a series of three randomly-selected Tor nodes: an entry node, a middle node and an exit node. The user's traffic enters the Tor network at the entry node. Each successive node is able to remove a single layer of encryption, which also reveals the next node to send the message to – akin to peeling the layers of an onion. When the message reaches the exit node, the final layer of encryption is removed and it is sent out across the Internet to its final destination. A similar procedure applies to messages travelling in the opposite direction back to the user, such as HTTP responses.

A diagram showing the nodes and the links between them in a Tor circuit. Although Tor does not encrypt the communication between the exit node and destination itself, it can be encrypted by the applications using Tor – for example, the user's web browser could use HTTPS instead of HTTP.

At no single point in the circuit are the source IP address, destination IP address and contents of the message all known to an eavesdropper simultaneously. To reduce the chance that users can be de-anonymized, Tor attempts to avoid picking nodes that share the same operator when creating circuits. This makes it difficult, but perhaps not impossible, for the identity of a particular user to be discovered. For example, an attacker who can observe a user's traffic as it both enters and leaves the Tor network can carry out a traffic confirmation attack, in which they correlate characteristics such as the timing or volume of the user's traffic, to link the user to the destination server.

Unsurprisingly, the anonymity provided by Tor makes it an attractive tool for fraudsters. For example, a phisher who has tricked users into handing over their online banking credentials might use Tor to log in to the bank's website with the compromised credentials. The bank's log files will show the IP address of the Tor exit node, rather than the phisher's own IP address, making it more difficult for the bank and law enforcement agencies to trace the fraud back to the phisher.

The report from FinCEN examined 6,048 suspicious activity reports (SARs) filed by banks and other financial companies between 2001 and 2014. Of those, 975 involved Tor, totalling $24 million of "likely fraudulent activity". The report goes on to state that "in the majority of the SAR filings, the underlying suspicious activity – most frequently account takeovers – might have been prevented if the filing institution had been aware that their network was being accessed via Tor IP addresses." Even if blocking Tor does not deter phishers from committing fraud entirely, it may cause them to switch to using services that are easier for the authorities to trace, such as open proxy servers or anonymous VPN services.

According to FinCEN's report, banks were only aware that Tor was involved in 3% of cases. Netcraft has visited the websites of the ten financial companies most targeted by phishing in the last six months, using a variety of Tor exit nodes located around the world, to check if any of the companies block Tor.

Position Company Blocks Tor traffic
1 PayPal No, but Tor users must solve a CAPTCHA
2 USAA No
3 AXA Banque No
4 SFR No
5 Wells Fargo No
6 Bank of America No
7 Chase No, but Tor users must use two-factor authentication
8 Lloyds Bank No
9 Banco do Brasil No
10 Cielo No

As shown in the table above, none of the login pages we visited blocked Tor traffic outright. For example, the following screenshot shows the appearance of PayPal's login page fetched from a variety of Tor exit nodes:

Screenshots of PayPal's login page fetched from several Tor exit nodes located across the world.

However, some of the websites we tested do treat Tor users differently during or after the login process – instead of blocking Tor users outright, they use Tor as an indicator for performing more stringent anti-fraud checks. (It is also possible that some companies perform additional checks that are not visible to end users.)

For example, Chase forces the use of two-factor authentication – by either email, text message or phone call – over Tor. PayPal requires Tor users to solve a CAPTCHA during the login process, which protects against automated attacks such as brute force login attempts, but would not prevent a phisher from manually logging into a victim's account. On the other hand, Lloyds Bank does not appear to visibly treat Tor users any differently to normal users.

A screenshot of the CAPTCHA that PayPal displays to users who attempt to log in over the Tor network.

The Tor Project considers services blanket blocking Tor traffic due to abusive and illegal behaviour by a proportion of its users to be a "threat to Tor's success". It advocates a range of other measures for sites to tackle abusive Tor traffic, including CAPTCHAs, two-factor authentication and establishing trust on a per-user rather than a per-IP basis. However, with the exception of two-factor authentication, most of these measures are targeted at abusive behaviour such as spam and are unlikely to prevent fraudsters from logging into compromised accounts.

Netcraft provides a wide range of countermeasures against phishing to many customers, including two of the world's top ten banks, as well as some smaller institutions at the sharp end of Internet crime – such as three of the largest Bitcoin exchanges and four Nigerian banks. For more information, please contact sales@netcraft.com.

Typosquatters cashing in on .uk domains

Typosquatters are cashing in by registering new .uk domains which look similar to those used by existing high-traffic .co.uk websites. By simply registering a .uk domain that ends in "co", the squatters have obtained dangerously deceptive domains such as paypalco.uk and americanexpressco.uk in an attempt to steal traffic from the real domains, paypal.co.uk and americanexpress.co.uk.

Many of these typosquatting domains are being monetized by displaying ads related to the legitimate domains they are impersonating, or by using referral schemes to redirect visitors to the corresponding legitimate site — or even driving visitors towards competing services.

The typosquatting site at paypalco.uk features monetized adverts for both PayPal and its competitors.

The typosquatting site at paypalco.uk features monetized adverts for both PayPal and its competitors.

However, the potential for abuse is not limited to making money through advertising and referral schemes. With the only difference being a single additional dot in the real domain name, this form of typosquatting could be exploited to make extremely potent phishing attacks.

First introduced in 1985, the .uk country code top-level domain (ccTLD) has only recently allowed ordinary consumers to register domains directly under .uk (such as stephenfry.uk). Before 10 June 2014, practically all UK domains had to be registered under second-level domains, which categorised the activity of the site. By far the most popular of these second-level domains is .co.uk, which is intended for commercial and general use.

Even the BBC has been targeted: www.bbcco.uk  redirects browsers to a sponsored listings page at bringthenews.co.uk

Even the BBC has been targeted: www.bbcco.uk
redirects browsers to a sponsored listings page at bringthenews.co.uk

To limit the most obvious potential for domain squatting, existing owners of .co.uk domains were given automatic rights to the corresponding .uk domain (for example nationalrail.uk) on 10 June 2014, providing there was no other equivalent .org.uk, .me.uk, .net.uk, .ltd.uk and .plc.uk domain in existence. The reservation period runs for a period of five years, during which time no other party can register the domain, even if the rightful party chooses not to.

However, these measures are inconsequential to the typosquatters, who seem to have found no barriers in registering deceptive domains such as nationalrailco.uk, barclaysco.uk and hsbcco.uk. The latter two deceptive domains are registered to a corporation in Sweden, and currently display a set of sponsored listings with titles such as "Need a New Bank Account?". Other registered domains which target high-traffic financial institutions include nationwideco.uk, lloydsbankco.uk, bankofscotlandco.uk, halifax-onlineco.uk, natwestco.uk, and westernunionco.uk.

The potential for financial fraud is immense, particularly as many online banking transactions are now carried out using mobile devices, on which typographical errors are naturally more common.

Some of the .uk typosquatting sites are clearly optimised for use on mobile devices, such as nationalrailco.uk, which displays a small form to search for train tickets. However, rather than taking users to the real National Rail website at nationalrail.co.uk, the search form uses the TradeDoubler affiliate scheme to monetize the typo-traffic by directing users to a train ticket sales website at thetrainline.com.

Some co.uk typosquatting sites are optimised to be viewed on mobile devices.

Some co.uk typosquatting sites are optimised to be viewed on mobile devices.

Flagrant typosquatting of popular sites amongst the .uk top-level domain is rife. Another brazen example is mbnaco.uk, which is clearly trying to scoop up typo-traffic from credit card provider MBNA, which uses mbna.co.uk for its main website. The typo domain presents adverts which invite visitors to apply for credit cards at various competitors, including American Express and Capital One.

Sponsored listings for competing credit card providers on mbnaco.uk

Sponsored listings for competing credit card providers on mbnaco.uk

Companies concerned about typosquatting attacks against their customers can use Netcraft's Fraud Detection service to pre-emptively identify fraudulent domain name registrations. Domain name registrars can use Netcraft's Domain Registration Risk service to analyse the likelihood of a new domain being used for fraudulent activity.

Google’s POODLE affects oodles

97% of SSL web servers are likely to be vulnerable to POODLE, a vulnerability that can be exploited in version 3 of the SSL protocol. POODLE, in common with BEAST, allows a man-in-the-middle attacker to extract secrets from SSL sessions by forcing the victim's browser into making many thousands of similar requests. As a result of the fallback behaviour in all major browsers, connections to web servers that support both SSL 3 and more modern versions of the protocol are also at risk.

The Secure Sockets Layer (SSL) protocol is used by millions of websites to protect confidential data in transit across the internet using strong cryptography. The protocol was designed by Netscape in the mid 1990s and was first released to the public as SSL 2 in February 1995. It was quickly replaced by SSL 3 in 1996 after serious security flaws were discovered. SSL 3 was replaced by the IETF-defined Transport Layer Security (TLS) version 1.0 in January 1999 with relatively few changes. Since TLS 1's release, TLS 1.1 and TLS 1.2 have succeeded it and should be used in its place wherever possible.

sslv3-vulnerable6

POODLE's bark may be worse than its bite

Unlike Heartbleed, POODLE can be used to attack client-server connections and is inherent to the protocol itself, rather than any one implementation such as OpenSSL or Microsoft's SChannel. In order to exploit it, an attacker must modify the victim's network traffic, know how the targeted secret information is structured (such as where a session cookie appears) and be able to force the victim into making a large number of requests.

Each SSL connection is split up into a number of chunks, known as SSL records. When using a block cipher, such as Triple DES in CBC mode, each block is mixed in with the next block and the record then padded to be a whole number of blocks long (8-bytes in the case of Triple DES). An attacker with network access can carefully manipulate the ordering of the cipher-blocks within a record to influence the decryption and exploit the padding oracle. If the attacker has been lucky (there's a 1 in 256 chance), she will have matched the correct value for the padding length in her manipulated record and correctly guessed the value of a single byte of the secret. This can be repeated to reveal the entire targeted secret.

SSL 3's padding is particularly easy to exploit as it relies on a single byte at the end of the padding, the padding length. Consequently an attacker must force the victim to make only 256×n requests for n bytes of secret to be revealed. TLS 1.0 changed this padding mechanism, requiring the padding bytes themselves to have a specific value making the attack far less likely to succeed.

The POODLE vulnerability makes session hijacking attacks against web applications reasonably feasible for a correctly-positioned attacker. For example, a typical 32-byte session cookie could be retrieved after eavesdropping just over 8,000 HTTPS requests using SSL 3. This could be achieved by tricking the victim into visiting a specially crafted web page which uses JavaScript to send the necessary requests.

Use of SSL v3

Within the top 1,000 SSL sites, SSL 3 remained very widely supported yesterday, with 97% of SSL sites accepting an SSL 3 handshake. CitiBank and Bank of America both support SSL 3 exclusively and presumably are vulnerable.

move-to-tls1

A number of SSL sites have already reacted to this vulnerability by disabling support for SSL 3, including CloudFlare and LinkedIn. On Tuesday 14th, the most common configuration within the top 1,000 SSL sites was to support SSL 3.0 all the way through to TLS 1.2, with almost two-thirds of popular sites taking this approach. One day later, this remains the most popular configuration; however, TLS 1.0 is now the minimum version for 11%.

Microsoft Internet Explorer 6 does not support TLS 1.0 or greater by default and may be the most notable victim of disabling SSL 3 internet-wide. Now 13 years old, IE6 was the default browser released with Windows Server 2003 and Windows XP in 2001 and will remain supported in Windows Server 2003 until July 2015. Despite its age and the end of Microsoft's support for Windows XP, IE6 remains popular, accounting for more 3.8% of web visits worldwide, and 12.5% in China. This vulnerability may ring the death knell for IE6 and Windows XP.

However, unless SSL 3 is completely disabled on the server side, a client supporting SSL 3 may still be vulnerable even if the server supports more recent versions of TLS. An attacker can take advantage of browser fallback behaviour to force otherwise secure connections to use SSL 3 in place of TLS version 1 or above.

SSL version negotiation

At the start of an SSL connection, servers and clients mutually agree upon a version of SSL/TLS to use for the remainder of the connection. The client's first message to the server includes its maximum supported version of the protocol, the server then compares the client's maximum version against its own maximum version to pick the highest mutually supported version.

While this mechanism protects against version downgrade attacks in theory, most browsers have an additional fallback mechanism that retries a connection attempt with successively lower version numbers until it succeeds in negotiating a connection or it reaches the lowest acceptable version. This additional fallback mechanism has proven necessary for practical interoperability with some TLS servers and corporate man-in-the-middle devices which, rather than gracefully downgrading when presented with a non-supported version of TLS, they instead terminate the connection prematurely.

An attacker with appropriate network access can exploit this behaviour to force a TLS connection to be downgraded by forging Handshake Alert messages. The browser will take the Handshake Alert message as a signal that the remote server (or some intermediate device) has version negotiation bugs and the browser will retry the connection with a lower maximum version in the initial Client Hello message.

handshake-alert

Operation of a forced downgrade to SSL 3 against a modern browser.

The fallback mechanism was previously not a security issue as it never results in the use of a protocol version that neither the client nor server will accept. However, those with clients that have not yet been updated to disable support for SSL 3 are relying on the server to have disabled SSL 3. What remains is a chicken and egg problem, where modern clients support SSL 3 in order to retain support for legacy servers, and modern servers retain support for SSL 3 for legacy clients.

There is, however, a proposed solution in the form of an indicator (an SCSV) in the fallback connection to inform compatible servers that this connection is a fallback and to reject the connection unless the fallback was expected. Google Chrome and Google's web sites already support this SCSV indicator.


Firefox 32

Chrome 40

IE 11

Opera 25

Safari 7.1
TLS 1.2 TLS 1.2 x 3 TLS 1.2 TLS 1.2 x 3 TLS 1.2
TLS 1.1 TLS 1.1 TLS 1.1
TLS 1.0 TLS 1.0 TLS 1.0 TLS 1.0 TLS 1.0
SSL 3.0 SSL 3.0 SSL 3.0 SSL 3.0 SSL 3.0

Comparison of browser fallback behaviour

We tested five major browsers with an attack based on the forged Handshake Alert method outlined above, and found that each browser has a variant of this fallback behaviour. Both Chrome and Opera try TLS 1.2 three times before trying to downgrade the maximum supported version, whereas the remainder immediately started downgrading. Curiously, Internet Explorer and Safari both skip TLS 1.1 and jump straight from TLS 1.2 to TLS 1.0.

Mitigation

Mitigation can take many forms: the fallback SCSV, disabling SSL 3 fallback, disabling SSL 3 in the client side, disabling SSL 3 in the server side, and disabling CBC cipher suites in SSL version 3. Each solution has its own problems, but the current trend is to disable SSL 3 entirely.

Disabling only the CBC cipher suites in SSL 3 leaves system administrators with a dilemma: RC4 is the only other practical choice and it has its fair share of problems making it an undesirable alternative. The SCSV requires support from both clients and servers, so may take some time before it is widely deployed enough to mitigate this vulnerability; it will also likely not be applied to legacy browsers such as IE 6.

Apache httpd can be configured to disable SSL 3 as follows:

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 -SSLv2 -SSLv3
Microsoft IIS and nginx can also be configured to avoid negotiating SSL version 3.

Firefox can be configured to disable support for SSL 3 by altering security.tls.version.min from 0 (SSL 3) to 1 (TLS 1) in about:config.

firefox-disable

Internet Explorer can also be configured to disable support using the Advanced tab in the Internet Options dialogue (found in the Control Panel). In a similar way, IE 6 users can also enable support for TLS 1.0.

internet-options-disable

Chrome can be configured to not use SSL 3 using a command line flag, --ssl-version-min=tls1.

Site Report

You can check which SSL sites are still using SSL 3 using the Netcraft Site Report:

Netcraft site report
URL:

Phishing with data: URIs

A recent spate of phishing attacks has taken to using the data URI scheme for evil. Supported in most browsers, these special URIs allow the content of a phishing page to be contained entirely within the URI itself, effectively eliminating the need to host the page on a remote web server and adding an additional layer of indirection.

One of these attacks is demonstrated below, where a phishing campaign was used to herd victims to a compromised site in the US, which then redirected them to a Base64-encoded data URI. This particular example impersonates Google Docs in an attempt to steal email addresses and passwords from Yahoo, Gmail, Hotmail, and AOL customers.

Google Docs phishing site using data: URI

All of the attacks use Base64-encoded data URIs, rather than human-readable plain text, making it harder for people, simple firewalls and other content filters to detect the malicious content.

Most phishing sites are hosted on compromised websites, but can also be seen using purpose-bought domain names and bulletproof hosting packages that have been paid for fraudulently. However, fraudsters can take advantage of open redirect vulnerabilities to "host" these malicious data URIs without the need for conventional web hosting.

This situation is ideal for scenarios such as malware delivery and social engineering attacks where no subsequent client-server interaction is required, but phishing sites still need some way of transmitting their victim's credentials to the fraudster. Most phishing attacks that use data URIs resort to the traditional method of transmitting stolen credentials, i.e. POSTing them to a script on a remote web server. However, with no obvious phishing content being hosted on the remote web server, such scripts could be more difficult for third parties to take down; and as long as they remain functional, each one can continue to be used by any number of data URI attacks.

Another interesting example which impersonated an eBay login page is shown below. If a victim is unfortunate enough to fall for this particular phishing attack, his credentials will be transmitted to a PHP script hosted on a compromised web server in Germany.

eBay phishing site using a data: URI

This demonstrates an interesting deficiency in Google Chrome: If the data URI is longer than 100,000 characters, then none of the Base64-encoded data within the URI will be displayed in the address bar. Rather than truncating the URI, Chrome's address bar will only display the string "data:".

This behaviour could make it more difficult for wary victims to report such attacks. Although the victim is viewing an eBay phishing page, if he tries to copy the URI from the address bar in Chrome, the clipboard will still only contain the string "data:".

The Netcraft Extension provides protection against the redirects used in the phishing attacks above, and Netcraft's open redirect detection service can be used to identify website vulnerabilities which would allow fraudsters to easily redirect victims to similar phishing content.

Bitcoin phishers get desperate with search engine ads

More than a week after we reported deceptive search engine ads being used in Bitcoin wallet attacks, fraudsters are still using Bing ads to trick Blockchain users into visiting phishing sites — but this time, the ads are using some crude social engineering ploys.

Searching for "blockchain" on bing.com currently displays the following pair of phishing ads at the top of the search results:

"Other ads are all phishing site" – click this one!
(Page requested at 12:15 BST, 2nd July 2014)

The first ad begs the user to "click this one" and warns that all other ads are phishing sites, but clicking on the ad actually sends the victim to a Blockchain phishing site, where he is prompted to enter his identifier and password. This phishing site is hosted in a subdirectory on a compromised website, which belongs to a web development outsourcing company in India.

Similarly, the second phishing ad warns that the other one is a phishing site; however, the fraudster behind this ad has made a mistake. When a victim clicks on this ad, it will try to send him to blockchain.lnfo (.LNFO). This link won't work because the .lnfo top-level domain does not exist, and probably never will, because as the fraudster has so perfectly demonstrated, it could easily be confused with .info.

As we saw in previous attacks, the green display URLs shown in these ads are carefully chosen by the fraudster to look similar to the real Blockchain website, which uses the blockchain.info domain. Neither of the display URLs accurately reflect the actual location reached after clicking on the ads. Also, the blue link text on the second ad uses an i-acute character in place of the "i" in Blockchain, presumably to make it harder to detect misuse of the Blockchain brand.

The fact that these phishing ads are trying to discredit each other suggests that there are multiple Bitcoin fraudsters competing for click-through traffic on sites which display Bing ads. These phishing ads also appear on other search engines which use the Yahoo Bing ad network, such as Yahoo and DuckDuckGo.

A phishing ad displayed on the privacy-conscious DuckDuckGo search engine.