Ask.fm users being redirected to malware sites

Malicious adverts displayed on the Ask.fm website have been automatically redirecting users to malware sites, where they are prompted to install unwanted or malicious software under the pretense of Java and Flash Player updates.

This particular advert is benign and serves only as an example of the banner's placement

Ask.fm is a popular social network which allows its users to receive and answer anonymous questions, but both registered users and anonymous question askers are being put at risk by some of the adverts it displays: Merely viewing a user's profile on Ask.fm caused some users to be redirected to the following page, which claimed that an outdated Java plugin had been detected (even when Java had been disabled).

Rather than downloading a Java update, victims will instead end up installing a program which several anti-virus vendors identify as DomaIQ. This is an advertising platform used by adware and other malicious programs to display unwanted pop-up ads within Internet Explorer, Firefox and Google Chrome.

The rogue advert responsible for performing the redirection was initially served through ADTECH GmbH, which is a wholly-owned subsidiary of AOL. However, the trail does not end there – the framed content served by ADTECH subsequently requested several pages from AppNexus servers at ib.adnxs.com and ams1.ib.adnxs.com, before one of these pages initiated a request to a Java servlet on exchange.admailtiser.com. Finally, this servlet page caused the parent frame to be redirected from Ask.fm to the page on www.updriong.com, essentially taking the browser to a different website without requiring any user interaction.

After returning to the Ask.fm website, another rogue advert immediately redirected the browser to a fake Adobe Flash update site. Again, no user interaction was required – the chain of requests initiated by the third party advert automatically redirected the user's browser to the fake site hosted in Sweden.

In this case, the rogue advert on http://ask.fm/account/wall was again initially served by ADTECH, but the framed content made its next request to a Yahoo ad server (ads.yahoo.com), which in turn made a request to ad.copa-media.com, which itself made a request for content hosted on an AppNexus server at ams1.ib.adnxs.com.

Finally, a request to another AppNexus server at ib.adnxs.com resulted in the user's browser being redirected to the fake Adobe Flash update site at download.adoocobo.us. The setup.exe file is served from a domain which is known for propagating malware.

Mobile browsers have also been targeted by similar attacks on Ask.fm. The example below shows an Ask.fm webpage displaying an intrusive and unsolicited alert dialog which originates from a Yahoo ad server. If the user clicks OK, he will be taken to a site which falsely claims that his phone has severe battery issues.

Within a few minutes, another advert on Ask.fm attempted to download an Android app directly from a website in France as soon as the user clicked OK. The makers of the genuine Mobogenie Market app recommend that it should only be downloaded from reliable sources such as Google Play, mobogenie.com and other partner networks (although it does not specify who these are).

Incidentally, despite encouraging its users not to reveal their passwords to anyone, the login form on http://ask.fm transmits a user's password over an unencrypted HTTP connection:

Most high profile websites only ever transmit passwords over encrypted HTTPS connections, and many sites also ensure that the entire duration of a browser session remains encrypted, i.e. not just the login process. Sending plain text passwords over an unencrypted connection makes them vulnerable to eavesdropping, giving a correctly-positioned attacker the opportunity to gain unauthorised access to Ask.fm user accounts.

PayPal redirect exploited in Apple ID phishing attack

Fraudsters have exploited a redirection vulnerability in a PayPal website in an attempt to steal Apple IDs. Phishing emails sent by the fraudster were disguised as receipts from the iTunes Store for expensive items, enticing victims to try to cancel the fake orders.

The emails stated, "If you did not order the above products and suspect your account has been hijacked kindly visit the link below". The link was displayed with a legitimate-looking location (www.order.itunes.com/verify/cancel) but actually took victims to a URL on the PayPal communications website. The phishing email also noted, "You will be asked some specific questions about you and your financial data to prove you actually owned the account."

The page on PayPal's website at https://www.paypal-communication.com/r/4V2JION/PPPU5A/GDY6I8I/20PEVD/7ZS7MP/7M/h?a=http://192.185.##.###/~broo23yo/ immediately redirected victims to the Apple phishing site specified in its GET parameter, http://192.185.##.###/~broo23yo/. Parts of these addresses have been obfuscated, although the target of the redirect has since been suspended by its hosting company, HostGator, and the PayPal URL used in the phishing emails no longer redirects to the URL specified in the a parameter.

Fraudsters use redirection scripts on well-known and well-trusted websites in order to increase the success of their phishing campaigns. Some email clients block access to links that use IP addresses directly and, as such, would scupper the fraudster's efforts. Using a fully-qualified domain name eliminates this particular problem, and some operators of third-party blocking software might also assume that all PayPal domains can be trusted without exception, which may not always be true. Cautious users who hover over links before clicking on them will see that the disguised links in the phishing email actually go to a trusted PayPal website, which would not seem untoward.

PayPal's site at www.paypal-communication.com uses an extended validation (EV) SSL certificate, which demonstrates that an enhanced set of guidelines has been followed in order to verify the identity of the website's owner. Some browsers emphasise this additional level of verification by adding green cues to the address bar, so a visitor can be sure with reasonable certainty that this site does indeed belong to PayPal, Inc. In this case, however, the redirect was near-instantaneous, so potential victims would not have seen the additional EV browser cues.

Notably, the secondary purpose of extended validation certificates is to address problems relating to phishing, but this is not effective when a phishing attack exploits flaws on a legitimate website using an EV certificate. A somewhat-similar scenario has previously affected PayPal: a third-party website which used an EV certificate was compromised and used to host a PayPal phishing site in 2011.

Incidentally, encrypted traffic destined for www.paypal-communication.com could also be vulnerable to eavesdropping. This Apache-powered website offered the TLS heartbeat extension prior to the disclosure of the Heartbleed bug, so the private key for its SSL certificate could have been compromised. PayPal promptly reacted to this by switching to a new SSL certificate (issued on 14 April 2014), but crucially, the potentially-compromised certificate has not been revoked. PayPal's main site, www.paypal.com, is affected by the same problem: its pre-Heartbleed certificate has also not been revoked.

Failing to revoke the previous certificate means that if it has been compromised, correctly-positioned attackers could use it to impersonate the secure PayPal communication website until the certificate expires in April 2015. As the site used an EV certificate, revocation is all the more important and is often more effective than the checks made for standard certificates. Most major browsers will make OCSP requests for EV certificates and will not display the EV browser cues if the certificate has been revoked or if there is no positive verification of its current status, e.g. if the OCSP request was blocked by a man-in-the-middle attacker. Revoked EV certificates are also more likely to appear in Chrome's CRLSets, which are arguably the most effective form of revocation checking currently available.

is.gd goes down, takes a billion shortened URLs with it

The popular is.gd URL shortening service has been offline for more than two days, taking with it more than a billion shortened URLs. Shortly before the site disappeared on Sunday, the homepage reported that its links have been accessed nearly 50 billion times.

The shortened links generated are usually not more than 18 characters long, including the protocol http://. These links are commonly used in tweets, emails, and text messages where long URLs are impractical. Despite the fact the shortened links do not work, many previously-created is.gd shortened URLs are still appearing on Twitter.

is.gd is owned by and supported by UK hosting provider Memset, who planned to support it as a free service indefinitely. Notably, its sister site, v.gd, is still up and running. Other free services provided by Memset include TweetDownload, TweetDelete and the statistics calculator Tweetails.

For security reasons, both is.gd and v.gd disallow the shortening of URLs which use the data: and javascript: protocols. Nevertheless, the service is still abused by fraudsters who use the shortened URLs to direct victims to phishing sites. Some fraudsters have appended a query string to the shortened URL in an attempt to make it look similar to those used by the phishing target. For example, the following is.gd URL was used to redirect victims to a Taobao phishing site:

http://is.gd/Tb###U?2.taobao.com/item.htm?spm=2007.1000337

Throughout April, is.gd was the fifth phishiest URL shortening service. By far the phishiest was tinyurl.com, which pointed to 17 times as many phishing sites, making it account for 60% of all phishing activity amongst the top five URL shortening services. Privately-held bit.ly, Google's goo.gl and GoDaddy's x.co also pointed to more phishing sites than is.gd.

Three years ago, the is.gd service suffered a shorter outage of a few hours. This was caused by the failure of some of the virtual machines in its frontend cloud, which were responsible for accepting HTTP requests from a load balancer.

Update 21/05/2014: is.gd is now back online. An explanation for the outage can be found at http://is.gd/news.php

POP! goes the phisher

Fraudsters are impersonating online banking websites in order to gain unauthorised access to customers' emails. Most online banking phishing sites simply try to steal whatever credentials are required to gain access to a victim's bank account, but by also gaining access to the victim's email account, the fraudster can prevent the victim from receiving any email alerts regarding account activity.

With access to the victim's emails, the fraudster could also potentially net a much larger haul. These emails will indicate to the fraudster which other banks, shops, social networks and other online services the victim uses. The fraudster can then attempt to compromise the victim's accounts on these services by initiating password resets, which will be sent to the email address he now has access to. In some cases, the fraudster will also be able to change the password of the victim's own email account, thus locking him out and making him unaware that further compromises are taking place.

The following phishing site targeted customers of Chase Bank earlier this month. Like many other phishing sites, it did a good job of looking like the real Chase Bank, although the address bar revealed that it was actually served from a hacked gift store.

Clicking on the Log In to Accounts button takes the victim to the following page, where he is told that a POP email service is required in order to continue. This is purportedly part of a verification measure, and the victim is prompted to enter his email address and email password so the site can log in to the victim's email account automatically.

POP (Post Office Protocol) is one of the most widely supported mail retrieval protocols, which lets an email client download email from a mail server. Many webmail providers (including Gmail, Outlook.com and Yahoo Mail) also allow mail to be retrieved via this protocol.

As soon as the victim clicks the Login button, he is taken to the real Chase Bank homepage which, unsurprisingly, looks rather similar to the original phishing site, albeit with the correct URL in the address bar.

At this point, the victim may simply assume he has to log in again after completing the previous verification step. If he does, he will be taken to his online banking account as expected. Meanwhile, the fraudster could well be helping himself to the victim's emails, starting the process of compromising each of the victim's other accounts one by one.

Chase Bank customers who have enrolled to receive Account Alerts can be notified of account activity via email. By deleting these emails, the fraudster might be able to prevent the victim from becoming aware of any fraudulent transactions until it is too late.

The phishing site used in this particular attack was one of the 8.5 million sites blocked by Netcraft's phishing site feed and has since been taken offline.

Keys left unchanged in many Heartbleed replacement certificates!

Although many secure websites reacted promptly to the Heartbleed bug by patching OpenSSL, replacing their SSL certificates, and revoking the old certificates, some have made the critical mistake of reusing the potentially-compromised private key in the new certificate. Since the Heartbleed bug was announced on 7 April, more than 30,000 affected certificates have been revoked and reissued without changing the private key.

Internet users rely on public key cryptography to verify the identity of secure websites: SSL certificates contain a public key that is generated from its associated private key. At the start of the secure connection, the server proves that it has the private key by decrypting messages encrypted with the public key, or by cryptographically signing its own messages. Keeping the private key secret is critical — if an attacker steals the private key, he can impersonate the secure website, decrypt sensitive information, or perform a man-in-the-middle attack.

Although we typically refer to "potentially-compromised" certificates when discussing the Heartbleed bug, the CA/Browser Forum adopts a much more cautious approach to its terminology. This group lays out the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, and they consider a private key to be "compromised" if there exists a practical technique by which an unauthorised person may discover its value — even if there is no evidence of such a technique having been exploited.

By reusing the same private key, a site that was affected by the Heartbleed bug still faces exactly the same risks as the those that have not yet replaced their SSL certificates — if the previous certificate had been compromised, then the stolen private key can still be used to impersonate the website's new SSL certificate, even if the old certificate has been revoked. Certificates that have been reissued with the same private key are easy to identify, as the new public key will also be identical to the old one.

Only 14% of affected websites (Zone A in the above Euler diagram) have done all three required steps after patching the Heartbleed bug – they have replaced their SSL certificates, revoked the old ones, and made sure to use a different private key. This zone also includes sites with certificates that expired shortly after the bug was disclosed.

Zone B represents the 5% of sites that have made the fundamental mistake of reissuing their certificates without changing the private key. This is the most dangerous zone, as not only could these websites still be vulnerable to impersonation attacks, but the website administrators will probably believe that they have done everything necessary to fix the problem. An additional 2% have reused the same private key and not revoked the old SSL certificate.

The white outer zone represents nearly 57% of the affected sites which have taken no action whatsoever — they have neither reissued nor revoked their certificates. A further 21% have reissued their certificates with a new private key, but failed to revoke the old ones.

The Canadian government ought to appreciate the risks posed by the Heartbleed bug more than others, particularly after the bug was exploited to steal social insurance numbers from the Canadian Revenue Agency. However, some parts of the Canadian government have made the mistake of reusing private keys while trying to mitigate the risks.

The Quebec Automobile Insurance Corporation is a crown corporation responsible for licensing drivers and providing personal injury insurance to the public. One of its websites at secure.saaq.gouv.qc.ca was issued a new SSL certificate in response to the Heartbleed bug, and the previous certificate was revoked on 29 April. The CRL revocation status listed the reason as "keyCompromise", but the issuing certificate authority nonetheless allowed the new certificate to be signed with the same private key. This means the new certificate can also be impersonated by anyone who is in possession of the compromised key.

This type of mistake could be prevented by certificate authorities: if public keys from revoked certificates were blacklisted, new requests with the same public key would be rejected. This type of automated check does not seem to be in use by most CAs; however, Netcraft's Site Reports and browser extensions can be used to determine whether a website has signed its replacement certificate with the same private key:

May 2014 Web Server Survey

In the May 2014 survey we received responses from 975,262,468 sites — 16 million more than last month.

Microsoft threatening Apache's market lead

Microsoft gained nine million additional sites this month, increasing its market share by a further 0.37 percentage points. Meanwhile, despite gaining 4.3 million sites, Apache's market share fell by 0.18 points. Although Apache still leads with 37.6% of all sites, Microsoft is now just 4.1 percentage points behind. Apache has been the most commonly used web server for more than 18 years, but this is the closest Microsoft has ever been to threatening this position.

Apache's position is much stronger when considering only Active Sites — it retains an absolute majority of 52.3%, and second place is held by nginx (14.4%), rather than Microsoft (11.3%). By excluding much of the automatically-generated content present on the internet, the Active Sites metric better reflects web server market share amongst human-maintained web sites.

New releases of nginx

The total number of websites using nginx fell by 3.7 million this month; however, the losses were mostly isolated to just a few hosting companies. Nearly two million nginx sites disappeared at cloud hosting company Enzu, followed by 1.2 million at BurstNet. Within the top million sites, however, nginx was the only web server to grow — Microsoft, Apache, and Google all lost market share.

A new stable version of nginx was released on April 24. nginx 1.6.0 features SPDY 3.1 support and various SSL improvements that were originally implemented in the 1.5.x mainline branch of releases. The previous mainline branch has also been superseded by nginx 1.7.0, which added support for backend SSL certificate verification and support for SNI while working with SSL backends.

Seven million new sites using Microsoft IIS

Nearly seven million of this month's new websites are using Microsoft IIS. Around 11 thousand of these new sites are hosted on the Microsoft Azure platform (including a few phishing sites), helping to maintain Microsoft's position as the largest Windows hosting company in terms on web-facing computers. Most of the new IIS sites at Azure are hosted in the US, with more than a third of the total being hosted in the North Central US Azure region alone.

Notably, www.apachelounge.com is one of this month's websites which appears to have switched to Microsoft IIS. The Apache Lounge is a web forum primarily focused on running Apache in Windows environments, and has provided Windows Apache binaries for more than 10 years. The site understandably has a long history of being hosted from an Apache web server, most recently on a Windows Server 2008 platform, but is now using Microsoft IIS 8.5 on Windows Server 2012.

All may not be as it seems, however, as the web server is still sending an X-Powered-By: Apache/2.4.9 (Win64) header. The web server is also reporting X-Powered-By: ARR/2.5, indicating the use of IIS's load-balancing features. It is likely that Apache Lounge is powered by multiple Apache instances which are hidden behind a Microsoft IIS load balancer.

New gTLDs showing promising growth

Several more new generic top-level domains have shown rapid growth in this month's survey. The .berlin gTLD, which was used by only two websites in last month's survey, is now used by 40,000 websites. The domain started its sunrise registration period on February 14, when trademark owners were able to register .berlin domains ahead of the March 16 deadline.

German news magazine Der Spiegel – one of Europe's largest publications of its kind – criticised the availability of .berlin and other new top-level domains, likening them to a housing bubble and suggesting that such domain names are a waste of money. The company behind the .berlin domain, dotBERLIN GmbH & Co. KG, was quick to reply pointing out that not only had Der Spiegel applied for its own gTLD (.spiegel) two years ago, but it had also already registered the domain name spiegel.berlin before its own article was published.

The .email gTLD is another one that has been thriving since the closure of its sunrise period: More than 12 thousand websites are now using .email, compared with only two last month. This gTLD is one of many operated by Donuts Inc, and became generally available on March 19.  Donuts applied to ICANN for more than 300 TLDs in 2012, 65 of which are already generally available for registration, including .support, .domains, .photos, .estate, .guru and .plumbing. A further 66 TLDs are scheduled for general availability between now and September, including .expert, .parts, .media, .toys, .wtf and .fail.





DeveloperApril 2014PercentMay 2014PercentChange
Apache361,853,00337.74%366,262,34637.56%-0.18
Microsoft316,843,69533.04%325,854,05433.41%0.37
nginx146,204,06715.25%142,426,53814.60%-0.64
Google20,983,3102.19%20,685,1652.12%-0.07
Continue reading