Attackers are smart and they have realized that even in 2018, the human is still the weakest link in the chain. The 2017 Verizon breach report identified that 81% of hacking related breaches occurred as a result of weak credentials or credential theft, an increase from the 63% reported in 2016’s breach report.

Source: Verizon 2017 data breach report

Your credentials are as important as your house or car keys. If someone copies or steals them, the repercussions can be catastrophic. If you suspect someone has access to your house keys you change your locks. If you aren’t fast enough, someone might break in.

Likewise if you realize that someone might have access to your password, the remedy is to change it. Too often, as with house keys, we are slow to change our passwords. This is why we see so many account compromises happen after a big public breach like Yahoo. As soon as the attacker gets their hands on a cache of credentials from a breach they immediately try them against every other account the user has. They know that a very high percentage of users still reuse the same credentials across multiple sites. So their chances of success are high - sometimes years after a breach has happened.

This is especially problematic with API keys because they often leak without anyone ever knowing it’s happened. Common examples include attackers who steal API keys by reversing client software, or using malicious code inside the browser to navigate and steal secrets - often long after the user has logged out. Some banking trojans such as the infamous Zeus even continue to browse after you have logged out, and display fake balance information to hide withdrawals it makes. This is why many banks now force you to re-authenticate often with 2FA when you log in and again when you perform any kind of financial transaction.

The Trojan Horse. (It’s not a new attack)

Attackers realize this too and they have been steadily upping their game to catch unsuspecting users. Not content to just sit and wait, attackers constantly try to grab credentials through a combination of trickery and sophisticated software attacks. The one thing that links all of this? It’s you that they are attacking, not some server sitting in a datacenter.

Phishing emails remain the most popular method but they have now evolved and range from the mundane badly spelled email asking for your password or offering you a link to some unknown site...

Common Cloudflare phishing email

A more sophisticated Cloudflare phishing email

Stepping up from phishing emails, we now have to face malicious software hidden inside innocuous everyday packages from browser extensions to free games. The most popular and difficult to detect of these by far are the malicious browser extensions. Often these start out as legitimate browser tools, then either they get hacked, or an attacker simply buys a forgotten extension project and injects malicious code into it. Now, anything your browser can see, the malicious extension can also see.

The most sophisticated of these are often targeted at a particular institution and know how to silently navigate to the credentials they wish to steal. Over the past couple of years we have seen several of these targeted specifically at Cloudflare customers. Below is an example of one such campaign from late last year involving a very popular Chrome extension called “Web Developer”.

Web Developer for Chrome breach alert

The malicious code injected into the extension was designed to be as stealthy and as resilient to attempts to stop it as possible.

• First it checks to make sure its been installed for at least 10 minutes.

• If it determines the coast is clear, it connects to a machine generated domain name, also called a DGA or “Domain Generation Algorithm” domain. These are random seeming domain names that are actually made by an algorithm so that they are harder to find and the attacker can automatically change to a new domain if the old one gets shut down, without changing any code. On August 2nd 2017 the DGA domain for this malicious extension was “wd7bdb20e4d622f6569f3e8503138c859d[.]win”. By August 3rd it had changed to “wd8a2b7d68f1c7c7f34381dc1a198465b4[.]win” as you can imagine this makes predicting new domains very hard unless you break the code behind the DGA algorithm.

• If the connection is successful it downloads a fresh payload, ga.js over HTTPS which is meant to fool anyone that sees it into thinking that it is downloading Google analytics.

Example code downloaded by the malicious version of Web Developer

The Cloudflare API Key stealing payload downloaded by the malicious extension.

Web Developer for Chrome wasn’t the only extension compromised in that particular campaign. Other extensions compromised included

• Chrometana – Version 1.1.3

• Infinity New Tab – Version 3.12.3

• CopyFish – Version 2.8.5

• Web Paint – Version 1.2.1

• Social Fixer 20.1.1 affected

• TouchVPN

• Betternet VPN

All these extensions have since been updated, but anyone with an older version should consider themselves at risk. How did this happen? Phishing of course:

Phishing email sent to Chrome developer a9t9.com

If you want to read more about this, our friends over at proofpoint have an in depth teardown of all the other aspects of this particular campaign.

We have built our systems to be secure by design. In some cases, this is as simple as ensuring that sensitive data is restricted, or made completely unobtainable. In other cases this has meant building systems in a way that makes them secure against a wide range of common attacks.

Passwords We store user passwords in a secure database using a complex, salted hash that uses the blowfish based bcrypt() hashing algorithm.

API Keys We ensure that API keys are unique by generating them using a combination of AES (Rijndael 256), SHA256 and plenty of entropy. Once generated through these hashing algorithms, API Keys are also stored in a secure database that only a handful of people have access to.

All calls to these sensitive databases are audited, and stored in logs that go back to the very beginning of Cloudflare. In one recent audit exercise we were able to review, and determine the exact time an API Key was generated for a customer in 2013. Access to both the audit logs and critical systems, like our databases, is restricted to a handful of senior production engineers and security staff. All staff access is also logged, and stored securely for audit purposes.

Finally, all programmatic calls to these databases are made through stored procedures linked to dedicated accounts. Dynamic SQL is not permitted.

All connections are made over HTTPS and sensitive tokens or credentials are never exposed in transit.

In the User InterfaceTo access your dashboard you need your account email, your password, and assuming you enabled it, (you really should if you haven’t) your 2FA code. If all of this is correct, and the IP you are using is one you are known to use, you are logged in. If the IP address isn’t known we send an email alert to your registered email address alerting you to the event.

Screenshot of an IP alert generated by accessing the dashboard

If your account is Pro, Business or Enterprise, that email also contains a “Multi Factor Authentication” or MFA code. Until this code is typed in, attempts to log-in are blocked.

MFA Alert generated by accessing the dashboard

Make sure the email registered to your Cloudflare account is correct and that it is one whose emails you can quickly see for maximum benefit. The faster you react to an alert the better!

API Keys are very sensitive things. They have as much power as your password but benefit from relatively few of the protections built into a modern browser. This is why we are deepening our investment to make our API even more secure.

Our first improvement, released last week, was to protect the API key against malicious software - such as a malicious browser extension - by adding a CAPTCHA to the “View API Key” feature. Below is a screenshot of the challenge you will now see when attempting to access your API Key. This change means that even if malicious software manages to steal your password, it cannot easily request and harvest your API Key.

Updated “View API Key” user experience

Next, we are looking at looked at scoped API keys. These are keys which can either be restricted to authorized IP addresses or limited in terms of what they can do. At the same time we will be adding the ability to turn the API off completely for your account. Finally, looking to the future, we are exploring options like other technical frameworks and token types, so that you have even better tools to build an API architecture that that is secure by design.

• Turn on 2FA and ensure your email address is correct The sooner you see an alert, the faster you can take action to lock your account down.Handle your credentials with care, NEVER enter them into a site other than Cloudflare.com if in doubt check the website certificate fingerprints:

SHA 256 - 12 C4 A5 74 7E D5 6E 37 2C 87 89 02 25 E4 CD 51 89 6D 8E AD 7D 55 CF 76 BF D1 9B 6B 74 6C 70 D0

SHA1 - D4 AD AB 1B 95 72 8D 3D 6E 26 4A 70 70 B1 1E 88 2F CA 71 67

• Check your browser extensions regularly. If you see any you don’t recognize remove them immediately. Remember that like all software, regular updates to browser extensions are important too.

• Design your client or application to protect your API credentials. If your API design is weak - for example it doesn’t do proper certificate validation, or even worse transmit any of the data in plaintext at any point in the connection - then you are risking disaster.

• Change your API key regularly, especially if you have any concern that it may have been exposed.

• Do not store your API key (or any credentials for that matter) in public repositories. One way to ensure this is by making sure you don’t store your API key in your application source tree. A significant number of accidental leaks to GitHub happen because this gets overlooked.

• Be very careful when embedding keys or credentials in clients that you will expose publically. Do not expose your account API key this way. Reverse engineering is not hard and many organizations have learnt this the hard way.

• Review your code before you release it. Use a tool that’s part of your CI or Build processes to automatically check for accidental key leakage. How many times have we seen API Keys for major institutions leak because they were accidentally checked into GitHub? Don’t be that person.

• IBM has some great additional security guidance for organizations building with APIs here,

• Finally, it may seem obvious but take care when clicking on links in emails. Even experienced Chrome developers get tricked sometimes!

The Payment Card Industry Data Security Standard (PCI DSS) is a global financial information security standard that keeps credit card holders safe. It ensures that any company processing credit card transactions adheres to the highest technical standards.

PCI certification has several levels. Level one (the highest level) is reserved for those companies that handle the greatest numbers of credit cards. Companies at level one PCI compliance are subject to the most stringent checks.

CloudFlare’s mission leads it to provide security for some of the most important companies in the world. This is why CloudFlare chose to be audited as a level one service provider. By adhering to PCI’s rigorous financial security controls, CloudFlare ensures that security is held to the highest standard and that those controls are validated independently by a recognised body.

If you are interested in learning more, see these details about the Payment Card Industry Data Security Standard.

This year’s update from PCI 2.0 to 3.1 was long overdue. PCI DSS 2.0 was issued in October 2010, and the information security threat landscape does not stand still—especially when it comes to industries that deal with financial payments or credit cards. New attacks are almost a daily occurrence, which means that an out-of-date security standard is often worse than no standard at all.

In PCI 3.1, the PCI council attempted to address this issue by both covering known attacks that have come out since the last version of the standard and beefing up financial security controls in anticipation of future attacks.

Here is a summary of the changes between PCI versions 2.0 and 3.1:

The PCI council has realized that the first lines of defense in any organization are the information security practitioners, developers, and engineers. With this in mind, the council has removed much of the "legal-speak" in the PCI DSS documentation, making it readable for the average person. Each section has an explanation, and each requirement has a justification with examples when possible.

Version 2.0 of the PCI standard was reliant on the annual audits each organization must go through to demonstrate compliance. This was leading to a culture of "tickbox security" where organizations would do the bare minimum during the year, then rush to make the necessary changes to meet compliance requirements in time for their audit. This is a bad way to do security.

Security should be holistic and ongoing. A company should ensure that security is built into every level of the organization. Security features should be incorporated into products from the ground up. Not only is this the least expensive way to do security, but it is also the most secure way.

To this end, PCI 3.1 was designed to integrate into the everyday operations of a compliant organization. This integration ranges from installing itself in critical operational processes, to ensuring that PCI compliance is an integral part of the Software Development Lifecycle (SDLC) that the company uses to build its products. PCI is present at every level of the operation.

Furthermore, PCI now requires that the processes which support these critical business functions are robust. This means that things like the patch management process or vulnerability testing process have a clearly defined owner, a clearly defined review process, and a clear timetable.

Another aspect of the "tickbox security" culture that developed around PCI 2.0 was the fact that it was possible to use documentation to fool the audit process. This lead companies toward a “smoke and mirrors” strategy for covering up substantial security flaws or implying compensating controls that did not exist.

To address this, PCI 3.1 became much more rigorous about evidence. It is no longer sufficient to say, "here is some paperwork about this control." The control itself has to be tested and evaluated by the auditor before the organization can be passed as compliant. Furthermore, PCI 3.1 also insists on vulnerability testing on a regular basis at every stage of the development lifecycle. This requirement is designed to catch weaknesses that might have slipped through the cracks and to detect software vulnerabilities that somehow missed getting patched.

It has become clear to many information security practitioners that security is a complex, multi-actor deliverable. This means the weak link in the chain can, and often does, undermine other substantially more secure organizations. PCI 3.1 now recognizes this with a definition of responsibilities for all stakeholders in the payment process. Whether you’re a merchant, service provider, or card issuer, it is no longer possible to completely outsource accountability. This forces the whole chain into the light of the day and ensures that good security practices are followed every step of the way.

TLS 1.0 and 1.1 have been around for a long time—SSL 3.0 even longer. The problem is that encryption has a shelf-life. As time passes, flaws are found in these systems, and computing performance reaches a level where it can break widespread encryption algorithms. Eventually, the encryption technology of yesterday no longer offers the same amount of protection as when it was first released.

With PCI 3.1, the payment card industry recognises this by setting a "sunset date" for old encryption standards. In order to remain compliant after June 30 2016, companies must switch off SSL 3.0, TLS 1.0, and TLS 1.1. This is a step in the right direction, and it affects CloudFlare as much as it affects our customers.

However, a significant amount of the world still uses TLS 1.0 (14% of traffic last time we looked). We recognise that not everyone wants, or needs, to do this. As a result, we will be offering our customers who wish to be PCI compliant a feature that will allow them to ensure their CloudFlare configuration meets PCI DSS guidelines.

The changes between PCI 2.0 and 3.1 made re-certification a lengthy, but highly illuminating, process for CloudFlare. We achieved full compliance as a level one service provider while substantially improving our security along the way. We also learned a lot about the compliance needs of our customers through this process, and you can expect a lot more compliance-related features to surface further down the road.

One attack that is particularly interesting because it appears to be using a brand new WordPress 0day.

The first sign we typically see that indicate a new phishing campaign is underway are the phishing emails themselves. Generally, there's a constant background noise from a few of these emails targeting individual customers every day. However, when a larger campaign starts up that trickle typically turns into a flood of similar messages.

Here's an example we've recently received:

Note — CloudFlare will never send you an email like this. If you see one like it, it is fake and should be reported to our abuse team by forwarding it to support@cloudflare.com.

In terms of the phishing campaign timeline, these emails aren’t the first event. Much like a spider looking to trap flies, a phisher first has to build a web to trap his or her victims. One way is through landing pages.

Looking like the legitimate login page of a target domain, these landing pages have one goal - to collect your credentials. Since these landing pages are quickly identified, the phisher will often go to great lengths to ensure that he or she can put up tens or even hundreds of pages during the lifetime of a campaign, all while being extra careful that these pages can't be traced back to him or her. Generally, this means compromising a large number of vulnerable websites in order to inject a phishing toolkit.

It's no surprise that first step in most phishing campaigns will usually be the mass compromise of a large number of vulnerable websites. This is why you will often see a notable uptick in the volume of phishing emails whenever a major vulnerability comes out for one of the popular CMS platforms. This is also why protecting the Internet’s back-office is a critical step in building a better Internet. If vulnerable CMS sites are protected, not only can they flourish, but the thousands of potential victims that could get abused when their infrastructure gets hijacked for malicious purposes are also protected.

This is why, at CloudFlare, we feel that providing free, basic security to every website is such important thing and why ultimately it could be such a game changer in building a better Internet.

Returning to our phishing attack, we see that it's no different. Analyzing the “load.cloudflare.com” hyperlink on the message, we see that it's actually a link pointing to a compromised WordPress site hosted by Bluehost.

Note: This is not a reflection on Bluehost, every hosting provider gets targeted at some point. What's more important is how those hosting providers subsequently respond to reports of compromised sites. In fact, Bluehost should be commended for the speed with which they responded to our requests and the way they handled the affected sites we reported.

Every other email in this particular campaign followed the same pattern. Here is the source for another one of those links that uses “activate.cloudflare.com”:

As you can see, while the message will display that you are going to “activate.cloudflare.com”, in reality, anyone that clicks on the link will be diverted to the victim website. Which, unsurprisingly, is running an old, vulnerable version of WordPress.

Every phishing email from this campaign has followed exactly the same pattern: a basic email template addressed to $customer informing them that their site has been locked, and inviting them to click on a link that takes them to a compromised WordPress site on Bluehost.

It looks like is this attacker harvested a large number of target domains using public DNS and email records identifying administrative email addresses. This became the victim list. The attacker then targeted a convenient, vulnerable CMS platform and injected his or her phishing kit into every innocent domain that's been compromised. Finally, once that is complete the attacker will send out the phishing emails to the victim list.

As phishing attacks go, this one is remarkably unsophisticated. All a savvy user had to do to reveal the true nature of this link is a quick mouse over. As soon as you do mouse over, the link you will see -- “activate.cloudflare.com” -- does not match the true destination.

A clever phisher could have used one of the many well known tricks to obfuscate the URL. Below are some of those techniques possible so you will know them if you see them.

• Image Maps. Instead of using a traditional hyperlink as above, phishers have been known to put an image map in their emails. The image, of course, is of a link to a trusted site such as “www.safesite.com”. When an unsuspecting user clicks within the coordinates of the image map, they are diverted to the phishing site.

Here's an example of this technique taken from an old eBay phishing email:

In order to fool Bayesian filters looking for phishing spam like this, the phisher also added some legitimate sounding words in white font to keep them from appearing. The user experience, however, is the same as the earlier phishing email. As soon as you mouse over the image map, you will see the true destination.

• Misspelled domain names and homoglyphs. Misspelled domains can look very similar to their legitimate counterparts and by using a homoglyph -- or look-a-like character -- an attacker can make a misspelling look even less obvious. Examples include “microsft.com” or “g00gle.com” These domains look so similar to the advertised link in the phishing email that many people will miss the discrepancy when they mouse over the link.

• Reflection, Redirection, and javascript. Many websites -- even sites like answers.usa.gov -- have search features, offsite links, or vulnerable pages that have historically been abused by phishers. If the offsite link can be manipulated, typically with a cross site scripting vulnerability, it's possible for the phisher to present a link from the target domain that takes the victim to a page under the Phisher’s control. Below is an example of a historic flaw of this nature that existed on the answers.usa.gov site

In this case, the URL looks like a legitimate “answers.usa.gov” ur,l but if you clicked on it, you would activate a cross-site scripting flaw that executes the javascript in your browser. The attacker could easily turn a page with this sort of flaw into a malicious credential harvester, all while continuing to use a link to the legitimate site.

Note - All those extra %20’s are encoded spaces to push the javascript far enough away that it won’t be visible on mouse over.

A slightly different flaw, also on the USA.gov site, involved its URL shortening service. Open to anyone, Phishers quickly discovered that they could use this service to create shortened URLs that looked important because of the .gov prefix. A victim that might be reluctant to click on an unsolicited bit.ly link might be less reluctant if faced with a .gov link. Here's an example of an email from a campaign abusing that service:

• URL obfuscation. Historically, this has been one of the most popular and varied techniques. The concept is simple: use any of the available URL encoding methods to disguise the true nature of the destination URL. I'll describe a couple of historic techniques below.

Note: many modern browsers now warn against some of these techniques.

First is username:password@url abuse. This notation, now deprecated because only an idiot would pass credentials in the HTTP query string these days, was designed to allow seamless access to password protected areas. Abuse is easy, for example:

www.safesite.com@www.evilsite.com

Next is IP address obfuscation. You are probably familiar with the IP address as a dotted quad? 123.123.123.123 Well, IP addresses can also be expressed in a number of other formats which browsers will accept. By combining this with the “username:password@” trick above, an attacker can effectively hide his true destination. Below are four different methods for presenting one of Google’s IP addresses -- 74.125.131.105

• http://www.safesite.com@74.125.131.105

• http://www.safesite.com@1249739625/

• http://www.safesite.com@0x4a.0x7d.0x83.0x69/

• http://www.safesite.com@0112.0175.0203.0151/

All of these URLs go to 74.125.131.150.

Finally we have Punycode and Homoglyph based obfuscation. Punycode was created as a way for international characters to map to valid characters for DNS, e.g., “café.com”. Using punycode this would be represented as xn--caf-dma.com. As mentioned at the start, homoglyphs are symbols which closely resemble other symbols, like 0 and O, or I and l.

By combining these two methods we can create URLs like:

www.safesite.com⁄login.html.evilsite.com

The secret to this obfuscated URL is to use a non-standard character which happens to be a homoglyph for /. The result? Instead of a page on safesite.com, you are actually taken to a subdomain of the following punycode domain:

www.safesite.xn--comlogin-g03d.html.evilsite.com

New obfuscation techniques like these appear all the time. Phishing is both the most common and arguably the most effective method of attack for medium to low skill attackers. Staying up to date with these techniques can be extremely useful when it comes to spotting potential phishing attempts.

After further analysis, it quickly became clear that all of the endpoints in this campaign were compromised WordPress sites running WordPress 4.0 - 4.1.1.

The most likely scenario is that a new critical vulnerability has surfaced in WordPress 4.1.1 and earlier. Given that 4.1.1 was, at the time of writing, the most current version of WordPress, this can only mean one thing -- a WordPress 0day in the wild.

Checking the WordPress site confirms that that a few hours ago they announced a new critical cross-site scripting vulnerability:

While we can’t confirm for certain that this is the vulnerability our phisher was using, it seems highly likely given the version numbers compromised.

Over the last few hours, we've worked closely with our friends at Bluehost to identify the remaining affected sites compromised by this phisher so they could take them offline. A quick response like this essentially renders all remaining phishing emails in this current campaign harmless. The need to quickly neutralize Phishing sites is why CloudFlare engineers developed our own process for rapidly identifying and tagging suspected compromised sites. When a site on our network is flagged as phishing site, we impose an interstitial page that serves to both to warn potential visitors and give the site owner time to fix the issue.

You can read more about our own process in this blog post.

By enabling the CloudFlare's WAF, CloudFlare customers have some protection against the sort of cross-site scripting vulnerability involved in this attack. However, anyone can still fall victim to a phishing email. Below are 7 tips to help you stay safe:

• NEVER click on links in unsolicited emails or advertisements.

• Be vigilant, poor spelling and strange URLs are dead giveaways.

• Mouse over the URL and see if it matches the what’s presented in the email.

• Type URLs in manually where possible.

• Stay up to date on your software and make sure you are running a current up-to-date antivirus client — yes, even if you're using Mac.

• It’s possible to set traps for phishers: use unique, specific email addresses for each account you set up. That way if you get an email to you Bank of America email address asking for your Capital One password, you immediately know it's a phishing attack.

• Finally, where possible enable two-factor authentication. While not foolproof, it makes it much harder for attackers.