Facebook Apps hosted by Heroku used for viral Twitter phishing attack

Netcraft blocked a Twitter phishing site being served from multiple Facebook Applications on 6th June. Visitors to the Facebook applications were requested to enter their Twitter credentials in order to view a "Twitter Video" application. On submission of the fake Twitter login form, the user is redirected to YouTube.

Links to the phishing attack were spread via both public tweets and direct messages. A Twitter direct message can only be sent to and from users who are following each other which lends credence to the message and the link it contains. The message entices the recipient to visit the fraudulent Facebook application: "I'm turning off my page if no one comes farward [sic] regarding this. https://apps.facebook.com/165922313586222".

Facebook — a trusted website which is served over HTTPS — is a useful medium for a fraudster; a Facebook user may be accustomed to seeing legitimate third-party authorisation forms on the social network making a fake login form all the more convincing. Netcraft has also observed similar attacks targeting Facebook itself which are being spread via Facebook statuses.

Twitter phishing via Facebook Apps and Twitter Direct messages

Twitter phishing via Facebook Apps and Twitter direct messages

Facebook Apps are not hosted on Facebook servers, instead they are hosted by a third party provider. The Facebook Apps involved in this phishing attack were hosted on Heroku and included on facebook.com via an iframe. In September 2011 Facebook partnered with Heroku, simplifying the process of setting up a new Heroku hosting account and Facebook App down to a few clicks. Heroku provides free accounts which are attractive for fraudsters wishing to host phishing attacks on Facebook.

The Facebook App at Heroku has a further iframe showing the actual fake login form, which is hosted at another hosting provider Joe's Datacenter. Both Facebook and the Facebook App hosted at Heroku are served using HTTPS but the final iframe is not, causing some browsers to display an insecure content warning.

Facebook iframe visualisation

Structure of the phishing attack: the fake twitter login form is included in an iframe within the Heroku-hosted Facebook App. The Facebook App is then included on facebook.com within another iframe.

Internet Explorer 9+ blocks HTTP iframes on HTTPS pages by default as it considers them as Mixed Active Content. Firefox currently hides the padlock when viewing mixed content, but does not block it. Firefox 23, due for release later this month, will automatically block iframes when it introduces Mixed Active Content blocking. In Google Chrome, iframes are currently considered passive rather than active, so the padlock icon displays a warning but the content is not blocked. Chrome 29 will switch to treating iframes as Mixed Active Content and block them by default.

Mixed Active Content Blocking in IE10, Pre-release Firefox Nightly, Pre-release Chromium

Mixed Active Content Blocking in IE10, Pre-release Firefox Nightly, Pre-release Chromium

On 6th June, Netcraft observed the following events (times are GMT). Netcraft had access to both a compromised Twitter account and a second Twitter account which was targeted by the first.

12:00
A Twitter direct message with a link to the phishing attack is received from the compromised account. Netcraft blocks the phishing attack in its Phishing Feed.
19:00
Twitter resets the password on the compromised account: "Twitter believes that your account may have been compromised by a website or service not associated with Twitter. We've reset your password to prevent others from accessing your account". The direct message containing the link to the phishing attack is removed. This is the same email that Twitter sent to 250,000 users in February when it discovered an attack which may have accessed user information.
20:00
Facebook removes the phishing applications Netcraft discovered, but the content is still accessible directly.

Social network credentials are particularly appealing to fraudsters as they have a built-in method to spread the attack without further involvement from the fraudster. Some features, such as attached third-party applications, can make a compromised account even more valuable to a fraudster. Authentication forms of the type imitated in this attack are common and train users to expect to see social media login forms triggered from websites other than that of the social network itself. Despite this attack asking for Twitter credentials within a Facebook App, the fraudster was still able to gather twitter account credentials and use them to further spread the attack using twitter direct messages and tweets.

You can protect yourself against phishing attacks by installing Netcraft's Anti-Phishing Extension. You can help protect the internet community by reporting potential phishing sites to Netcraft by email to scam@netcraft.com or at http://toolbar.netcraft.com/report_url. Netcraft can also help protect both brand owners and hosting companies.

Phishing attack hosted on police site with an SSL certificate

The Malaysian government's Police Portal (Johor Contingent) is currently hosting a phishing attack against PayPal on its secure website https://www.polisjohor.gov.my (Site Report). Phishing sites using SSL certificates can piggyback on the trust instilled by browser indicators, such as the padlock icon, to trick potential victims into revealing sensitive information such as their username and password. The SSL certificate used for this phishing attack is irrevocable in some major browsers including Firefox (due to the lack of an OCSP URL in the certificate) and Safari (which doesn't check revocation by default).

A phishing site targeting PayPal hosted on the Malaysian Police's web site which is available over HTTPS.

Fraudsters often use a compromised third party website to host their phishing attack rather than obtaining web hosting directly. By compromising an existing trusted website the fraudster can avoid paying for a potentially suspicious domain name or SSL certificate himself. For example, registering or obtaining an SSL certificate for paypaal.com could draw unwanted attention if the registrar or SSL certificate authority is already conscious of the risk posed by this type of domain name.

The presence of an SSL certificate on a website hosting a phishing site is far from unusual. In May 2013, Netcraft identified 234 trusted SSL certificates on websites with at least one known phishing site. Of these, 67 were issued by Symantec (including the polisjohor.gov.my certificate) which may not be surprising given its leading position in the SSL certificate market. Comodo and Go Daddy had a similar number of such certificates discovered by Netcraft, 42 and 46 respectively. Extended Validation (EV) certificates could be especially valuable to a fraudster as they are designed explicitly to increase the perceived trustworthiness of websites which have passed the validation process by displaying additional indicators such as green bar. During May 2013, Netcraft identified five EV certificates being used on potentially compromised websites: two signed by Symantec and one each signed by Comodo, DigiCert, and Go Daddy.

The SSL certificate for polisjohor.gov.my was issued by GeoTrust (a Symantec brand) back in 2011 and is valid for several more months. If Symantec wished to revoke the certificate to make the site inaccessible over HTTPS it could do so by updating its Certificate Revocation List or by providing on-demand OCSP responses noting its revocation. As examined by Netcraft recently, the current treatment of revocation in many major browsers leaves some room for improvement: this certificate does not contain an OCSP URL so is irrevocable in Firefox. Even if the CA wanted to, it could not directly prevent further use of the certificate in Firefox. Safari users are left unprotected by default as the revocation checking has to be explicitly enabled.

Netcraft offers Phishing alerts to CAs to provide timely alerts to the CA about potential misuse of a certificate. Having access to timely, professionally validated alerts when phishing attacks occur can allow the CA to provide the first alert of a compromise to the webmaster. Both the CA and the webmaster are then able to respond appropriately to the potential compromise, safeguarding the reputation of both parties.

June 2013 Web Server Survey

In the June 2013 survey we received responses from 672,985,183 sites, 148k more than last month.

Both Microsoft and Google grew slightly this month, gaining 0.5 percentage points of market share. Microsoft's web server, IIS, now serves 17.22% of the world's websites, down from a historic high of 37% which it reached in October 2007. Microsoft IIS's market share amongst secure websites (HTTPS) is significantly higher: it serves 39% of the secure websites found by Netcraft and is in 2nd place behind Apache. Apache's lead over Microsoft in the secure website market is only slight: it is ahead by just two percentage points and doesn't hold an absolute majority as it does for non-secure websites (HTTP).

Despite its market share dipping slightly, Apache is still significantly ahead of its position just two months ago due to Go Daddy's switch last month to Apache Traffic Server. Within the Million Busiest Sites, Apache bucked its recent downward trend this month: 7,300 more websites than last month are using Apache, including DigiCert's website which switched from nginx to Apache 2.4.5 (2.4.4 is the latest stable release).

nginx's growth within the Million Busiest Sites remains strong, 5,400 more busy websites now use the web server since last month's survey including The Verge which switched from Apache. Across all web sites, however, nginx lost almost 1% of market share and 6.4M websites caused by a large network of websites at namecheap.com failing to respond during the survey.

In early May 2013, nginx released a patch for a high severity security vulnerability which could allow an attacker to execute arbitrary code. Several attacks exploiting the vulnerability in the chunked transfer size calculation have been demonstrated including a proof of concept and an automated metasploit module. Almost 2M websites — or around 2% of all websites using nginx — presented a server banner corresponding to a vulnerable version (1.3.9+ and 1.4.0). The vast majority of nginx websites do not report the version in the server banner; however, the two most popular versions reported are 1.2.1 (released in June 2012) and 1.0.15 (released in April 2012) which do not have this vulnerability but may have others if left unpatched.

nginx is the most commonly used web server at Amazon: it is used on 41% of the 12M websites hosted using EC2 or S3. Last month Netcraft reported Amazon had 158k web-facing computers and has been the largest hosting provider by the number of web-facing computers since September 2012. After nginx, Apache is the next most common web server, 24.7% of websites use it, followed by Microsoft with 14%. Only 1% presented the AmazonS3 server banner, which can be used to host entire static websites in addition to simply static files.





DeveloperMay 2013PercentJune 2013PercentChange
Apache359,441,46853.42%358,974,04553.34%-0.08
Microsoft112,303,41216.69%115,920,68117.22%0.53
nginx104,411,08715.52%97,991,19114.56%-0.96
Google23,029,2603.42%26,036,6163.87%0.45
Continue reading

Most Reliable Hosting Company Sites in May 2013

Rank Performance Graph OS Outage
hh:mm:ss
Failed
Req%
DNS Connect First
byte
Total
1 Qube Managed Services Linux 0:00:00 0.006 0.099 0.045 0.091 0.091
2 Datapipe FreeBSD 0:00:00 0.009 0.073 0.016 0.033 0.051
3 ServerStack Linux 0:00:00 0.009 0.077 0.066 0.134 0.134
4 Bigstep Linux 0:00:00 0.009 0.269 0.071 0.143 0.143
5 iWeb Linux 0:00:00 0.009 0.121 0.073 0.144 0.144
6 www.dinahosting.com Linux 0:00:00 0.012 0.178 0.098 0.198 0.198
7 XILO Communications Ltd. Linux 0:00:00 0.015 0.218 0.076 0.361 0.517
8 Swishmail FreeBSD 0:00:00 0.018 0.110 0.062 0.124 0.226
9 INetU Windows Server 2008 0:00:00 0.018 0.130 0.072 0.236 0.456
10 Virtual Internet Linux 0:00:00 0.018 0.165 0.074 0.324 0.453

See full table

Qube Managed Services had the most reliable hosting company site in May, with only 2 failed requests. Qube specialises in providing managed hosting from three data centres in London, New York and Zurich. Qube was founded in 2001 and provides services to a number of notable clients, including Betfair (a large betting exchange) and blinkbox (a video streaming service from Tesco in the UK). Qube has appeared in the top 10 over twenty times since Netcraft began monitoring it in March 2010 and has now ranked in 1st place four times.

Datapipe and ServerStack placed 2nd and 3rd, both narrowly missing the top spot by a single failed request. Datapipe had the lowest average connection time out of all the top 10 sites, which breaks the tie with ServerStack in its favour. Datapipe has continued to maintain its 100% uptime record having recently passed the 100% uptime over 7 years milestone despite some of its nine data centres being in the path of hurricanes, typhoons, and a snowstorm. Serverstack has now been monitored by Netcraft for seven months and has already appeared in the top 10 four times. The company's 100% uptime SLA offers 5% credit for every half hour of sustained unscheduled downtime.

All but three of May's top 10 most reliable hosting companies hosted their own sites on Linux, including Qube in 1st place, ServerStack in 3rd place and Bigstep in 4th place, which made its debut entry in the table last month. FreeBSD is used by 2nd place Datapipe and last month's winner Swishmail (this month in 8th place). INetU was the only hosting company in the top 10 to host its site on Windows Server 2008.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.

OCSP Server Performance in April 2013

Rank Performance Graph OS Outage
hh:mm:ss
Failed
Req%
DNS Connect First
byte
Total
1 ocsp.starfieldtech.com Linux  0:00:00  0.013  0.111 0.023 0.043 0.043
2 ocsp.trendmicro.com/tmca Citrix Netscaler  0:00:00  0.019  0.043 0.099 0.200 0.200
3 ocsp.entrust.net Linux  0:00:00  0.022  0.251 0.014 0.249 0.249
4 ocsp.godaddy.com Linux  0:00:00  0.022  0.164 0.021 0.041 0.041
5 ocsp.digicert.com Linux  0:00:00  0.022  0.027 0.026 0.051 0.051
6 ocsp.quovadisglobal.com Windows Server 2003  0:00:00  0.032  0.021 0.116 0.222 0.222
7 ocsp.verisign.com Citrix Netscaler  0:00:00  0.038  0.050 0.084 0.168 0.168
8 evsecure-ocsp.verisign.com Citrix Netscaler  0:00:00  0.041  0.239 0.085 0.168 0.168
9 ocsp.thawte.com Citrix Netscaler  0:00:00  0.044  0.041 0.083 0.165 0.165
10 ocsp.startssl.com/sub/class4/server/ca Linux  0:00:00  0.047  0.086 0.011 0.041 0.041

See full table

Starfield Technologies had the most reliable OCSP responder during April, failing to respond to only 4 of Netcraft's OCSP requests. Starfield also had the most reliable responder in March, but showed a slight improvement to its average connection times in April. Starfield was founded as the technology and research branch of Go Daddy in 2003, and Go Daddy customers can choose to have their SSL certificates issued by either Starfield or Go Daddy.

Trend Micro had the second most reliable OCSP responder, which failed to respond to only 6 requests. However, this could be one of the survey's least busy responders: Netcraft's April 2013 SSL Survey discovered only 113 valid SSL certificates issued by Trend Micro, all of which are organisation validated. 29 of these certificates are used by a single organisation, Florida Hospital.

StartCom (which operates StartSSL) once again exhibited the fastest connection times, taking only a hundredth of a second to establish a TCP connection for one of its OCSP URLs.  However, its reliability was only just good enough to make it into the top ten — in total, 15 requests to http://ocsp.startssl.com/sub/class4/server/ca failed during April.

Linux is the most popular choice of operating system on which to run an OCSP responder, and it certainly seems to perform well with regard to connection times: all of the top 25 fastest OCSP responders used Linux in April. In terms of failed requests, though, the distribution of Citrix Netscaler appliances is skewed towards the more reliable end of the spectrum — of the five responders that were using Netscaler, four of them feature in the top ten. QuoVadis's OCSP responder, which was sixth most reliable in April, is one of only two responders that ran on Windows.

On April 24, nginx 1.4.0 stable was released, incorporating several new features that had previously only been released in development branches of the web server. One of the most important performance features is that nginx now support OCSP stapling. This feature is designed to improve performance by allowing secure websites to "staple" a cached OCSP response to the TLS handshake, removing the need for the client browser to make a second, separate connection to the certificate authority's OCSP responder.

The Online Certificate Status Protocol (OCSP) is an alternative method to Certificate Revocation Lists (CRLs) for obtaining the revocation status of an individual SSL certificate. Fast and reliable OCSP responders are essential for both Certificate Authorities (CAs) and their customers — a slow OCSP response will introduce an additional delay before many browsers can start sending and receiving encrypted traffic over an HTTPS connection.

Would you knowingly trust an irrevocable SSL certificate?

Despite the inconsistent treatment of certificate revocation by browsers, providing reliable revocation information is an integral part of operating a trustworthy certificate authority (CA) and a well-accepted requirement of Mozilla's CA root program. However, there are presently thousands of certificates in use which are irrevocable in some major browsers, and hundreds in those browsers which do everything right.

Without the ability to revoke a certificate, a CA has no control over whether a certificate is accepted by browsers or relied upon for secure communication after its issuance and before its expiry. A compromised private key and certificate in the hands of an attacker could be devastating: he would be able to use the private key to decrypt some intercepted SSL-secured traffic and the certificate to impersonate the targeted site. Even if the CA becomes aware of the problem, they can do nothing about it directly without having to rely on the browser vendor's support. CAs use two main technologies for browsers to check whether a particular certificate has been revoked: using the Online Certificate Status Protocol (OCSP) or looking up the certificate in a Certificate Revocation List (CRL). OCSP provides revocation information about an individual certificate from an issuing CA, whereas CRLs provide a list of revoked certificates and may be received by clients less frequently.

Assessing browser support for the two forms of revocation is complicated by Google Chrome's varying behaviour, depending on the platform, browser settings, and its use of pre-aggregated crlsets which contain revocation information for a limited selection of certificate authorities. Firefox does not automatically download CRLs for non-EV certificates so, by default, must rely on OCSP alone. Both Internet Explorer and Opera are more secure in this context: they support OCSP and CRLs and make suitable checks for all types of certificate. Safari does not make revocation checks at all by default for non-EV certificates and the mobile version does not provide the option to do so. For most Safari users, whether or not a certificate is irrevocable is immaterial — Safari does not check for revocation by default.

Excerpt from Netcraft's site report for https://www.bancagenerali.it showing the lack of any revocation method available.

Netcraft has found hundreds of certificates trusted by major browsers which are effectively irrevocable; that is they do not contain valid entries in the crlDistributionPoints X509 extension or OCSP URLs in the AuthorityInformationAccess extension. There may be appropriate CRLs or OCSP responders available, but there is no standard automated means to discover them. Without these two extensions, there is some chance a browser will use a cached CRL (downloaded after visiting another site using the same intermediate certificate) and have access to revocation information not otherwise available. It is easy, however, to envision many scenarios where this fortunate event hasn't occurred before a person visits a site with a revoked certificate.

The CA/B forum — an organisation of both CAs and browsers — publishes a set of Baseline Requirements (BR), which allow a CA to rely on OCSP stapling for "high-traffic" FQDNs and omit OCSP URLs from the certificate. However, currently there is not a widely supported method for enforcing the use of OCSP stapling. The draft TLS Security Policy extension can contain a must-staple directive, which, if present, will indicate to clients to reject any connection without a stapled OCSP response.

In Netcraft's May 2013 SSL survey, more than 300,000 certificates did not contain an OCSP responder URL and are thus irrevocable in Firefox (except for a handful of hard-coded OCSP responder URLs); of these, almost 9,000 were issued this year. Around 800 did not contain URLs for either revocation method, making them effectively irrevocable.

The table below shows some example certificates which are missing some or all of the URLs pointing to revocation methods.

Example certificateSite rankCertificate AuthorityOCSP serversCertificate Revocation ListsOCSP Stapling enabledSelf-declared BR compliance according to responses to Mozilla
fsgateway.aexp.comAmerican Express (Verizon Business)NoNoNoNot yet compliant
www.bancagenerali.it28,225I.T. Telecom (Verizon Business)NoNoNoNot yet compliant
*.malaga.esFNMTNoNoNoN/A
accounts.google.com7Google Internet Authority (Symantec)NoYesNoCompliant
login.skype.com1,804Microsoft (Verizon Business)NoYesNoNot yet compliant
query.rapidssl.com1,280,616SymantecNoYesNoCompliant
www.faa.gov498,030Verizon BusinessNoYesNoNot yet compliant
www.creditmutuel.deKEYNECTISNoYesNoCompliant
*.mygrants.gov.myAlphaSSL (GlobalSign)NoYesNoPartially compliant

There are a number of certificate authorities which have issued such certificates, including the following:

  • An American Express certificate, issued by their own certificate authority, does not contain URLs for either revocation method nor does it staple an OCSP response, making it totally irrevocable. American Express's certificate authority eventually chains up to GTE CyberTrust (now Verizon Business). This certificate was issued before the effective date of the CA/B forum's Baseline Requirements.
  • Google Internet Authority, a subordinate CA of Equifax (now Symantec), does not include OCSP responder URLs in any of its certificates making the certificates effectively irrevocable in Firefox except by action by the browser vendor. Even if Google were to use OCSP stapling (which it does not appear to do — at least on some popular sites) people using Firefox would be no better off as support by default is still in the pipeline. The lack of OCSP URLs may be a conscious decision by Google to reduce the performance penalty of using SSL. The risk posed by not performing this check is not theoretical as one of Google's CRLs contains 7 serial numbers for certificates which were revoked for 'Key Compromise', an event which can't be dealt with directly by Google for users of Firefox.
  • A number of other certificate authorities have issued certificates without OCSP responder URLs this year, including Symantec, Verizon Business, GlobalSign, Microsoft, and KEYNECTIS. The original Baseline Requirements document — effective from 1 July 2012 — stated that there MUST be at least one OCSP URL in the AuthorityInformationAccess extension.
  • Several recently-issued irrevocable certificates violate other Baseline Requirements. For example many certificates also have RSA keys shorter than 2048-bits expiring beyond the end of this year — the CA will not be able to revoke them effectively on 1st January 2014 as is required. I.T. Telecom (which is a subordinate CA of Verizon Business) and FMNT (the Spanish Royal Mint) are the worst offenders, having issued totally irrevocable certificates with short public keys. Some major CAs have also signed certificates with short public keys and only CRL revocation available including Symantec and Verizon Business.

None of the example certificates mentioned above responded with a valid OCSP response stapled, so the limited exception allowed in the Baseline Requirements for high-traffic FQDNs isn't applicable.

Whilst the majority of certificates issued by major CAs are revocable in line with the Baseline Requirements, browser vendors could consider enforcing the most security-critical requirements in the browser itself, raising the bar for all certificate authorities. Browser vendors are somewhat limited in the available methods to sanction or remove their trust in widely used CAs: straightforward revocation of intermediates or root certificates runs the risk of disabling a large proportion of secure websites leading users to question not the CAs, but the browser software and the web site they are visiting.

23/05/2013: Edited to correct attribution of Microsoft's CA to Verizon Business.