95% of HTTPS servers vulnerable to trivial MITM attacks

Only 1 in 20 HTTPS servers correctly implements HTTP Strict Transport Security, a widely-supported security feature that prevents visitors making unencrypted HTTP connections to a server.

The remaining 95% are therefore vulnerable to trivial connection hijacking attacks, which can be exploited to carry out effective phishing, pharming and man-in-the-middle attacks. An attacker can exploit these vulnerabilities whenever a user inadvertently tries to access a secure site via HTTP, and so the attacker does not even need to spoof a valid TLS certificate. Because no crypto-wizardry is required to hijack an HTTP connection, these attacks are far easier to carry out than those that target TLS, such as the recently announced DROWN attack.

Background

The growth of HTTPS has been a mostly positive step in the evolution of the internet, enabling encrypted communications between more users and websites than ever before. Many high profile sites now use HTTPS by default, and millions of TLS certificates are currently in use on the web. With companies like Let's Encrypt offering free certificates and automated management tools, it is also easier than ever to deploy an HTTPS website that will be trusted by all modern browsers.

The primary purpose of a TLS certificate is to allow a browser to verify that it is communicating with the correct website. For example, if https://www.example.com uses a valid TLS certificate, then a man-in-the-middle attacker would not be able to hijack a browser's connection to this site unless he is also able to obtain a valid certificate for that domain.

A man-in-the-middle attack like this is generally not possible if the customer uses HTTPS.

A man-in-the-middle attack like this is generally not possible if the initial request from the customer uses HTTPS.

It would be extremely difficult for the attacker to obtain a valid certificate for a domain he does not control, and using an invalid certificate would cause the victim's browser to display an appropriate warning message. Consequently, man-in-the-middle attacks against HTTPS services are hard to pull off, and often not very successful. However, there are plenty of realistic opportunities to use the unencrypted HTTP protocol to attack most HTTPS websites.

HTTP Strict Transport Security (HSTS)

Encrypted communications are an essential requirement for banks and other financial websites, but HTTPS alone is not sufficient to defend these sites against man-in-the-middle attacks. Astonishingly, many banking websites lurk amongst the 95% of HTTPS servers that lack a simple feature that renders them still vulnerable to pharming and man-in-the-middle attacks. This missing feature is HTTP Strict Transport Security (HSTS), and only 1 in 20 secure servers currently make use of it, even though it is supported by practically all modern browsers.

Each secure website that does not implement an HSTS policy can be attacked simply by hijacking an HTTP connection that is destined for it. This is a surprisingly feasible attack vector, as there are many ways in which a user can inadvertently end up connecting via HTTP instead of HTTPS.

Manually typed URLs often result in an initial insecure request, as most users do not explicitly type in the protocol string (http:// or https://). When no protocol is given, the browser will default to HTTP – unless there is an appropriate HSTS policy in force.

To improve accessibility, most secure websites also run an HTTP service to redirect users to the corresponding HTTPS site – but this makes them particularly prone to man-in-the-middle attacks if there is no HSTS policy in force. Not only would many users be accustomed to visiting the HTTP site first, but anyone else who visits the site via an old bookmark or search engine result might also initially access the site via an insecure HTTP address. Whenever this happens, the attacker can hijack the initial HTTP request and prevent the customer being redirected to the secure HTTPS website.

This type of attack can be automated with the sslstrip tool, which transparently hijacks HTTP traffic on a network and converts HTTPS links and redirects into HTTP. This type of exploit is sometimes regarded as a protocol downgrade attack, but strictly speaking, it is not: rather than downgrading the protocol, it simply prevents the HTTP protocol being upgraded to HTTPS.

NatWest's online banking website at www.nwolb.com lacks an HSTS policy and also offers an HTTP service to redirect its customers to the HTTPS site. This setup is vulnerable to the type of man-in-the-middle attack described above.

NatWest's online banking website at www.nwolb.com lacks an HSTS policy and also offers an HTTP service to redirect its customers to the HTTPS site. This setup is vulnerable to the type of man-in-the-middle attack described above.

Vulnerable sites can be attacked on a massive scale by compromising home routers or DNS servers to point the target hostname at a server that is controlled by the attacker (a so-called "pharming" attack). Some smaller scale attacks can be carried out very easily – for example, if an attacker sets up a rogue Wi-Fi access point to provide internet access to nearby victims, he can easily influence the results of their DNS lookups.

Even if a secure website uses HTTPS exclusively (i.e. with no HTTP service at all), then man-in-the-middle attacks are still possible. For example, if a victim manually types www.examplebank.com into his browser's address bar—without prefixing it with https://—the browser will attempt to make an unencrypted HTTP connection to http://www.examplebank.com, even if the genuine site does not run an HTTP service. If this hostname has been pharmed, or is otherwise subjected to a man-in-the-middle attack, the attacker can hijack the request nonetheless and eavesdrop the connection as it is relayed to the genuine secure site, or serve phishing content directly to the victim.

In short, failing to implement an HSTS policy on a secure website means attackers can carry out man-in-the-middle attacks without having to obtain a valid TLS certificate. Many victims would fall for these attacks, as they can be executed over an unencrypted HTTP connection, thus avoiding any of the browser's tell-tale warnings about invalid certificates.

Implementing HSTS: A simple one-liner

The trivial man-in-the-middle attacks described above can be thwarted by implementing an appropriate HSTS policy. A secure website can do this simply by setting a single HTTP header in its responses:

    Strict-Transport-Security: max-age=31536000;

This header can only be set over an HTTPS connection, and instructs compatible browsers to only access the site over HTTPS for the next year (31,536,000 seconds = 1 year). This is the most common max-age value, used by nearly half of all HTTPS servers. After this HSTS policy has been applied, even if a user manually prefixes the site's hostname with http://, the browser will ignore this and access the site over HTTPS instead.

The combination of HSTS and HTTPS therefore provides a good defence against pharming attacks, as the attacker will not be able to redirect and intercept plaintext HTTP traffic when a client obeys the HSTS policy, nor will he be able to present a valid TLS certificate for the site he is impersonating.

The attacker cannot even rely on a small proportion his victims unwisely ignoring the use of an invalid certificate, as browsers must regard this situation as a hard fail when an HSTS policy is in force. The browser will simply not let the victim access the site if it finds an invalid certificate, nor will it allow an exception to be added.

When Google Chrome encounters an invalid certificate for a site that has an effective HSTS policy, the victim is not allowed to bypass the browser's warning message or add an exception.

When Google Chrome encounters an invalid certificate for a site that has an effective HSTS policy, the victim is not allowed to bypass the browser's warning message or add an exception.

To prevent other types of attack, it is also wise to add the includeSubDomains directive to ensure that every possible subdomain of a site is protected by HSTS. This mitigates cookie injection and session fixation attacks that could be executed by impersonating an HTTP site on a non-existent subdomain such as foo.www.example.com, and using it to set a cookie which would be sent to the secure site at https://www.example.com. This directive can be enabled like so:

    Strict-Transport-Security: max-age=31536000; includeSubDomains

However, some thought is required before taking the carte blanche approach of including all subdomains in an HSTS policy. The website's administrators must ensure that every single one of its subdomains supports HTTPS for at least the duration specified by the max-age parameter, otherwise users of these subdomains risk being locked out.

Setting an HSTS policy will also protect first time visitors who habitually use search bars or search engines to reach their destination. For example, typing "paypal" into Google's HTTPS search engine will yield a link to https://www.paypal.com, because Google will always link to the HTTPS version of a website if an appropriate HSTS policy exists.

HSTS preloading

HSTS is clearly an important security feature, but there are several circumstances under which its benefits will not work. Because HSTS directives are delivered via an HTTP header (over an HTTPS connection), HSTS can only instruct a browser to only use HTTPS after the browser's first visit to a secure website.

Men-in-the-middle can therefore still carry out attacks against users who have:

  • Never before visited the site.
  • Recently reinstalled their operating system.
  • Recently reinstalled their browser.
  • Switched to a new browser.
  • Switched to a new device (e.g. mobile phone).
  • Deleted their browser's cache.
  • Not visited the site within the past year (or however long the max-age period lasts).

These vulnerabilities can be eliminated by using HSTS Preloading, which ensures that the site's HSTS policy is distributed to supported browsers before the customer's first visit.

Website administrators can use the form at https://hstspreload.appspot.com/ to request for domains to be included in the HSTS Preload list maintained by Google. Each site must have a valid certificate, redirect all HTTP traffic to HTTPS, and serve all subdomains over HTTPS. The HSTS header served from each site must specify a max-age of at least 18 weeks (10,886,400 seconds) and include the preload and includeSubdomains directives.

It can take several months for domains to be reviewed and propagated to the latest stable versions of Firefox, Safari, Internet Explorer, Edge and Chrome. When domains are added to the preload list, all users of these browsers will benefit from the security offered by HSTS, even if they have never visited the sites before.

Conclusions

HSTS is widely supported, but not widely implemented. Nearly all modern browsers obey HSTS policies, including Internet Explorer 11, Microsoft Edge, Firefox, Chrome, Safari and Opera – yet less than 5% of secure websites enable this important security feature.

Secure websites that do not use HSTS are trivial to attack if the attacker can hijack a victim's web traffic, but it is even easier to defeat such attacks by implementing an HSTS policy. This begs the question of why so few websites are using HSTS.

The HSTS specification (RFC 6797) was published in 2012, and so it can hardly be considered a new technology any more. Nonetheless, many website administrators might still be unaware of its existence, or may not yet feel ready to commit to running an HTTPS-only website. These are probably the most significant reasons for its low uptake.

Some website administrators have even disabled HSTS by explicitly setting a max-age of 0 seconds. This has the effect of switching off any previously established HSTS policies, but this backpedalling can only take proper effect if every client revisits the secure site after the max-age has been set to zero. When a site implements an HSTS policy, it is effectively committed to maintaining its HTTPS service for as long as the largest max-age it has ever specified, otherwise it risks denying access to infrequent visitors. Nearly 4% of all HTTPS servers that use the Strict-Transport-Security header currently set a max-age of zero, including Twitter's t.co URL-shortener.

Browser support for HSTS can also introduce some privacy concerns. By initiating requests to several distinct hostnames (some of which enable HSTS), a hostile webpage can establish a "supercookie" to uniquely identify the client browser during subsequent visits, even if the user deletes the browser's conventional cookies. The browser will remember which pattern of hostnames had HSTS enabled, thus allowing the supercookie to persist. However, this privacy concern only affects clients and does not serve as an excuse for websites to avoid implementing their own HSTS policies.

Implementing an HSTS policy is very simple and there are no practical downsides when a site already operates entirely over HTTPS. This makes it even more surprising to see many banks failing to use HSTS, especially on their online banking platforms. This demonstrates poor security practices where it matters the most, as these are likely to be primary targets of pharming attacks.

Netcraft offers a range of services that can be used to detect and defeat large-scale pharming attacks, and security testing services that identify man-in-the-middle vulnerabilities in web application and mobile apps. Contact security-sales@netcraft.com for more information.

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:

July 2019 Web Server Survey

In the July 2019 survey we received responses from 1,395,897,118 sites across 238,145,990 unique domain names and 8,938,144 web-facing computers. This reflects gains of 62.5 million sites, 1.15 million domains, and 98,000 computers.

nginx continues to extend its lead at the top of the list of web server vendors by total number of sites: it has gained 43.3 million sites since the June 2019 survey, bringing its total to 483 million. It now leads second-place Apache by 6.84 percentage points.

nginx has achieved the milestone of serving more than a third of sites in the survey. It becomes the fourth web server to achieve this in the 24 years since Netcraft's Web Server Survey began in August 1995. At that time NCSA [archive.org] - one of the very earliest web servers - served 53% of all sites. NCSA was quickly replaced by Apache, which passed the one-third milestone in June 1996 and continued to serve more than a third of sites until February 2016. Microsoft have served more than a third of sites for four separate periods most recently falling below a third in January 2019.

Unusually, nginx did not fare as well in any of the other metrics this month, losing out in both absolute numbers and market share in terms of domains (-4.0 million, -1.81pp), active sites (-1.2 million, -1.00pp) and in the top million busiest sites (-9,300, -0.93pp). The drops in domains and active sites are accounted for by large changes at two hosting providers; 2.8 million domains hosted by Endurance International Group moved from using nginx to Apache, and 1.5 million domains and 1.4 million active sites hosted by ecommerce provider Shopify now identify as using cloudflare. nginx also lost a small amount of market share of web-facing computers (-0.10pp) despite gaining 21,300 in absolute terms. These losses buck the trend of recent months that has seen nginx gaining market share from Apache and Microsoft.

Apache gained both the largest number of domains and the largest number of active sites since the June survey with increases of 2.2 million and 2.1 million respectively. Microsoft gained the largest number of web-facing computers with an increase of 43,200.

Cloudflare's web server moves up another place into fourth this month after gaining 4.7 million sites to bring its total to 39.9 million. It serves 9.5 million more sites than fifth placed openresty, but stands well behind the 190 million sites served by Microsoft's IIS. The 39.9 million sites served using Cloudflare are spread across 15.2 million unique domains, 2.6 sites per domain, a significantly smaller number of sites per domain than the top three placed web servers. Nginx has 8.2 sites per domain, Apache has 5.3, and Microsoft IIS has 9.3; the total for all sites in the survey is 5.8 sites per domain.

Envoy - the open source edge and service proxy for cloud-native applications, which leapt up to the tenth largest web server by sites in the May survey - has dropped over 200 places and is only seen hosting 13,000 sites in the July survey. This comes as a result of Squarespace sites no longer identifying themselves as using Envoy, but rather announcing "Squarespace" as the web server. Squarespace is the eleventh largest web server by number of sites with 5.2 million sites on 2.8 million unique domains; the seventh largest number of domains.

Total number of websites

Web server market share

DeveloperJune 2019PercentJuly 2019PercentChange
nginx439,626,71332.97%482,877,27534.59%1.62
Apache374,360,94928.08%387,366,82627.75%-0.32
Microsoft205,235,29115.39%203,673,34414.59%-0.80
Google28,181,7442.11%29,385,0652.11%-0.01
Continue reading

June 2019 Web Server Survey

In the June 2019 survey we received responses from 1,333,421,275 sites across 236,991,999 unique domain names and 8,840,331 web-facing computers. This reflects gains of 6.76 million sites, 1.98 million domains, and 113,000 computers.

nginx has further extended its lead in the hostnames metric, with 52.2 million additional sites pushing its total up to 440 million. Since overtaking Apache in April, nginx has already built up a 4.89 percentage point lead over Apache's market share and is not far off accounting for more than one third of all sites.

Apache retains the lead in all other metrics, but for how long? The proportion of unique domains that are served by Apache has fallen to 30.1%, while nginx snapped up the majority of this month's net domain growth, bringing its share to within 3.4 percentage points of Apache's. There has been a clear trend of Apache's domain market share decreasing, while nginx's increases and looks likely to overtake Apache within a year. A similar trend is evident in web-facing computers and among the top million sites, so it may not be long before nginx steals more of the limelight.

Reports of a remote code execution vulnerability in most recent versions of nginx were downplayed by its developers, who claimed that neither of the two overflow vulnerabilities appeared to be generally exploitable. Both bugs affected the njs scripting language implementation that allows nginx's functionality to be extended; one bug was fixed in njs 0.3.2, which was released on 21 May along with nginx 1.17.0, while the other bug is expected to be fixed in the future release of njs 0.3.3.

Several other product updates were also released during May, including NGINX Unit 1.9.0, lighttpd 1.4.54, LiteSpeed Web Server 5.3.8 (Stable), OpenLiteSpeed 1.5.1, and cPanel & WHM 80. The latest version of cPanel & WHM adds the ability to run Node.js applications, manage API tokens to allow resellers and third-party developers to run API functions, and ensure visitors are redirected to the secure HTTPS versions of sites.

Envoy – the open source edge and service proxy for cloud-native applications, which leapt to prominence in last month's survey – remains in tenth place with around 5 million sites, which are spread across 2.7 million unique domain names.

Cloudflare's web server has moved up into fifth place after gaining more than 5 million websites, giving it a total of 35.1 million sites across 12.9 million domains. The Cloudflare server is used by the edge nodes of Cloudflare's content delivery network, which now serves 2.6% of all sites in this month's survey.

Microsoft saw losses in every metric this month, apart from web-facing computers, where it made a gain of 13,600; however, this was not enough to stop its market share falling slightly, while Apache gained 17,300 computers and nginx gained 64,000.

Total number of websites

Web server market share

DeveloperMay 2019PercentJune 2019PercentChange
nginx387,416,88929.20%439,626,71332.97%3.77
Apache385,685,25229.07%374,360,94928.08%-1.00
Microsoft250,440,88718.88%205,235,29115.39%-3.49
Google27,711,3752.09%28,181,7442.11%0.02
Continue reading

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.

August 2019 Web Server Survey

In the August 2019 survey we received responses from 1,271,920,923 sites across 239,441,736 unique domain names and 8,948,887 web-facing computers. This reflects a large loss of 124 million sites, but a gain of 1.30 million domains and 10,700 computers.

All major vendors lost active sites this month, and of those, only Google made a gain in sites (+1.58 million). Microsoft lost the largest number of active sites (-2.03 million), while nginx lost the most sites (-81.4 million, -16.9%) but remains in the lead with a 31.6% share of all sites.

Despite losing so many sites, nginx showed the strongest growth in unique domains, web-facing computers, and among the top million sites. This bears more significance than the more unpredictable changes in the site counts, which are prone to fluctuations month-on-month as link farms, spam networks and other low-value web content comes and goes.

With a gain of 58,500 web-facing computers, nginx now has more than 31% of the computer market share – just 5.39 percentage points behind Apache – while Microsoft has lost 65,000 computers. As is evident in the graphs, counting web-facing computers provides the most stable metric and makes long term trends easy to spot. In particular, the clear and consistent rise in nginx's market share and the steady decline of Apache makes it hard not to imagine nginx taking the market lead from Apache by early next year.

The number of top-million websites powered by nginx has increased by 1,292, while Apache's count fell by 3,101. Apache maintains the lead in this market, but is now only 5.92 percentage points ahead of nginx. Apache also continues to lead in terms of unique domains, despite losing 784,000 this month. It has a similar lead over nginx, which is now only 5.32 percentage points behind Apache after gaining 753,000 domains.

Microsoft lost counts in almost all metrics this month, apart from where it gained 166,000 domains, although this still resulted in a small drop in its domain market share. The sites market is the only one where its share did not fall, despite losing 16.6 million sites.

Netflix finds nginx vulnerabilities

nginx 1.61.1 stable and nginx 1.17.3 mainline were released on 13th August, in order to address three HTTP/2 security issues that could cause excessive memory consumption and CPU usage. All versions between 1.9.5 – 1.17.2 are affected, but only if HTTP/2 is enabled. These security issues were discovered by Jonathan Looney at Netflix, which chose to use nginx when developing its own globally distributed content delivery network, known as Netflix Open Connect.

The content delivery network consists of Open Connect Appliances, which run the FreeBSD operating system and use nginx to stream audio and video directly to Netflix customers. Most of this content is served from appliances hosted by ISPs, rather than across the internet, which leads to better performance whilst vastly reducing the amount of peered traffic when huge numbers of customers worldwide stream a popular show at the same time. Thousands of ISPs have enthusiastically participated in this program because it is free to connect to the Open Connect network, and it prevents Netflix traffic from taking up a significant amount of an ISP's internet capacity.

FreeBSD is dying?!

Netflix chose FreeBSD for its balance of stability and features (as did Netcraft once upon a time), but it is becoming an increasingly less common frontend operating system on the web as a whole. Only 60,200 (0.67%) web-facing computers are running FreeBSD today. To put this into perspective, more than twice as many servers are still running Windows Server 2003, even though it has not been supported for several years.

Linux is by far the most commonly used operating system for web-facing computers. It is installed on 6.64 million (74.2%) servers, and at least 1.05 million of these can be positively identified as running the Ubuntu distribution.

Naturally, the choice of operating system depends to some extent on what type of web server will be running on it, and vice versa. For example, it is no surprise that most instances of Microsoft IIS can be found running on Windows Server, and most instances of Windows Server are used to run Microsoft IIS; but it is clear that the Linux operating system is especially favoured for some web servers. Between 92% and 96% of all web-facing computers that use each of nginx, Apache, Litespeed and lighttpd can be found running Linux.

AWS ELB overtakes Beaver

The awselb (Amazon Web Services Elastic Load Balancing) web server was found on 69,800 web-facing computers this month, overtaking Beaver to become the fourth most commonly used frontend server by computers. Practically all of these machines appear to be running Linux, and are responsible for hosting 464,000 sites across 48,500 unique domains.

ELB achieves fault tolerance and scalability by automatically distributing incoming application traffic across multiple targets – and can even spread it across multiple AWS Availability Zones – so the 69,800 AWS ELB servers exposed to the internet are likely to be only the tip of the iceberg in terms of the AWS infrastructure used by each website.

Total number of websites

Web server market share

DeveloperJuly 2019PercentAugust 2019PercentChange
nginx482,877,27534.59%401,454,02931.56%-3.03
Apache387,366,82627.75%374,277,24329.43%1.68
Microsoft203,673,34414.59%187,109,42314.71%0.12
Google29,385,0652.11%30,969,2592.43%0.33
Continue reading