At Wordfence, we see large amounts of threat actor data, and often that data tells unexpected stories. Taking a look at just the top five attacking IP addresses over a 30 day period, you might be surprised to find out where these attacks are originating, and what they are doing. When most people hear about threat actors, they think about countries like Russia, China, and North Korea. In reality, attacks originate from all over the world, with the top five attackers we have tracked over the past 30 days coming from Australia, Germany, the United States, Ukraine, and Finland.
The purpose of these attacks is nearly as varied as their locations. Each of the top five malicious IP addresses was found to be attempting unauthorized access to websites or file systems. In sixth place was an IP address that was attempting brute force attacks, but the remaining malicious IP addresses in the top ten were all found to be attempting malicious access by other means. Several of the addresses were seen scanning for vulnerabilities, downloading or uploading files, accessing web shells, and even viewing or writing custom wp-config.php files. While one of the malicious indicators was consistent across all of the top five IP addresses, there are also some actions that were unique to a specific attack source.
IP Threat #1 Originating From Australia
The IP address found in Australia, 20.213.156.164, which is owned by Microsoft, may seem like the most surprising one to make this list, let alone first on the list. In a 30 day period, we tracked 107,569,810 requests from this single IP address out of Sydney. The threat actor using this IP was primarily attempting to open potential web shells on victims’ websites which could indicate that the attacker was looking for left-over webshells from other attackers’ successful exploits.
This is a common technique for threat actors, as it can be automated and does not require actively uploading their own shells and backdoors to a potential victim’s website. This could help the attacker save time and money instead of launching their own attack campaign to compromise servers.
The following is an example of a request the offending IP tried to make to access a known shell. It was blocked by the Wordfence firewall.
IP Threat #2 Originating From Germany
The German IP address, 217.160.145.62, may have a tracked attack quantity that is around 35% lower than the Sydney IP address, with only 70,752,527 tracked events, but its actions are much more varied. In fact, this IP address triggered four different web application firewall (WAF) rules, including attempts to upload zip files to the attacked websites. This is a common action performed as a first step to get malicious files onto the server. There were also attempts to exploit a remote code execution (RCE) vulnerability in the Tatsu Builder plugin, and access the wp-config.php file from a web-visible location.Sample of an exploit targeting the Tatsu Builder plugin vulnerability from this IP Address.
IP Threat #3 Originating From The United States
The attacks originating from the IP address 20.29.48.70 in the United States were slightly lower in quantity than those from Germany, with 54,020,587 detected events. The logged events are similar to those found coming from Australia. Searching for previously installed shells and backdoors appears to be the main purpose of these attacks as well. It’s important to note that this does not indicate that a backdoor is actually present on the site. This is just a method attackers use in hopes of landing on a webshell that had been installed previously by another attacker to save time and resources. One filename we saw the IP address attempting to access is commonly used to serve spam or redirect to potentially malicious e-commerce websites.Example of a pharma website that was the end result of a redirect chain.
IP Threat #4 Originating from Ukraine
The attacks starting in Ukraine are from the IP address 194.38.20.161, and the purpose of these attacks is different from what we see from the IP addresses in the other entries in the top five. The majority of the 51,293,613 requests appear to be checking for jQuery upload capabilities on the affected websites. This is done with a web request that uses a JPEG image file in an attempted upload. Once they know an upload is possible, the attacker can upload malicious files that range from spam to backdoors, and everything in between.
IP Threat #5 Originating From Finland
Rounding out our top five with only 44,954,492 registered events is the IP address 65.108.195.44 from Helsinki, Finland. This one also attempts to access web shells and backdoors. The majority of requests from this IP address seem to be accessing previously uploaded malicious files, rather than trying to exploit vulnerabilities or activate code that was added to otherwise legitimate files, such as the example below.The s_e.php file sample in its raw form: a file this IP was trying to access.
One Thing in Common: All IPs Made it on to the Wordfence IP Blocklist
While the threat actors behind these IP addresses may have tried a variety of methods to gain control of these WordPress sites, one thing all these IP addresses have in common is that their attempts were blocked by the Wordfence Network and made their way onto the Wordfence IP Blocklist, a Premium feature of Wordfence.
This means that due to the volume of attacks these IP addresses were initiating they ended up on the Wordfence Real-Time IP blocklist, which prevents these IP addresses from accessing your site in the first place.
Conclusion
While the top five locations may not be commonly thought of as locations that web attacks may originate from, these are areas where computers and the internet are common. Wherever you have both of these, you will have attack origins. What is not as surprising is that despite widely varied locations for attackers, the methods they use are typically common and often predictable. Hosting accounts that threat actors use to launch attacks can live anywhere in the world while a threat actor themselves may be in an entirely different location.
By knowing how an attacker thinks, and the methods they use, we can defend against their attacks. These top five offenders averaged more than 10 million access attempts per day in the reviewed period, but having a proper web application firewall with Wordfence in place meant the attackers had no chance of accomplishing their goals.
All Wordfence users with the Wordfence Web Application Firewall active, including Wordfence free customers, are protected against the types of attacks seen from these IP addresses, and the vulnerabilities they may be attempting to exploit.If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.
On June 16, 2022, the Wordfence Threat Intelligence team noticed a back-ported security update in Ninja Forms, a WordPress plugin with over one million active installations. As with all security updates in WordPress plugins and themes, our team analyzed the plugin to determine the exploitability and severity of the vulnerability that had been patched.
We uncovered a code injection vulnerability that made it possible for unauthenticated attackers to call a limited number of methods in various Ninja Forms classes, including a method that unserialized user-supplied content, resulting in Object Injection. This could allow attackers to execute arbitrary code or delete arbitrary files on sites where a separate POP chain was present.
There is evidence to suggest that this vulnerability is being actively exploited in the wild, and as such we are alerting our users immediately to the presence of this vulnerability.
This flaw has been fully patched in versions 3.0.34.2, 3.1.10, 3.2.28, 3.3.21.4, 3.4.34.2, 3.5.8.4, and 3.6.11.WordPress appears to have performed a forced automatic update for this plugin, so your site may already be using one of the patched version. Nonetheless, we strongly recommend ensuring that your site has been updated to one of the patched versions as soon as possible since automatic updates are not always successful.
Wordfence Premium, Wordfence Care, and Wordfence Response customers received a rule on June 16, 2022 to protect against active exploitation of this vulnerability. Wordfence users still using the free version will receive the same protection on July 16, 2022. Regardless of your protection status with Wordfence, you can update the plugin on your site to one of the patched versions to avoid exploitation.
Description: Code Injection Affected Plugin:Ninja Forms Contact Form – The Drag and Drop Form Builder for WordPress Plugin Slug: ninja-forms Plugin Developer: Saturday Drive Affected Versions: 3.6-3.6.10, 3.5-3.5.8.3, 3.4-3.4.34.1, 3.3-3.3.21.3, 3.2-3.2.27, 3.1-3.1.9, 3.0-3.0.34.1 CVE ID: Pending CVSS Score: 9.8 (Critical) CVSS Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Fully Patched Version: 3.0.34.2, 3.1.10, 3.2.28, 3.3.21.4, 3.4.34.2, 3.5.8.4, 3.6.11
Ninja Forms is a popular WordPress plugin designed to enhance WordPress sites with easily customizable forms. One feature of Ninja Forms is the ability to add “Merge Tags” to forms that will auto-populate values from other areas of WordPress like Post IDs and logged in user’s names. Unfortunately, this functionality had a flaw that made it possible to call various Ninja Form classes that could be used for a wide range of exploits targeting vulnerable WordPress sites.
Without providing too many details on the vulnerability, the Merge Tag functionality does an is_callable() check on a supplied Merge Tags. When a callable class and method is supplied as a Merge Tag, the function is called and the code executed. These Merge Tags can be supplied by unauthenticated users due to the way NF_MergeTags_Other class handles Merge Tags.
We determined that this could lead to a variety of exploit chains due to the various classes and functions that the Ninja Forms plugin contains. One potentially critical exploit chain in particular involves the use of the NF_Admin_Processes_ImportForm class to achieve remote code execution via deserialization, though there would need to be another plugin or theme installed on the site with a usable gadget.
As we learn more about the exploit chains attackers are using to exploit this vulnerability, we will update this post.
Conclusion
In today’s post, we detailed a critical vulnerability in Ninja Forms Contact Form which allows unauthenticated attackers to call static methods on a vulnerable site that could be used for the site. This can be used to completely take over a WordPress site. There is evidence to suggest that this vulnerability is being actively exploited.
This flaw has been fully patched in versions 3.0.34.2, 3.1.10, 3.2.28, 3.3.21.4, 3.4.34.2, 3.5.8.4, and 3.6.11. It appears as though WordPress may have performed a forced update so your site may already be on one of the patched versions. Nonetheless, we strongly recommend ensuring that your site has been updated to one of the patched versions as soon as possible.
Wordfence Premium, Wordfence Care, and Wordfence Response customers received a rule on June 16, 2022 to protect against active exploitation of this vulnerability. Wordfence users still using the free version will receive the same protection on July 16, 2022. Regardless of your protection status with Wordfence, you can update the plugin on your site to one of the patched versions to avoid exploitation.
If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.
If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected, as this is a serious vulnerability that can lead to complete site takeover.
Special thanks to Ramuel Gall, a Wordfence Threat Analyst, for his work reverse engineering the vulnerability’s patches to develop a working Proof of Concept and for his contributions to this post.
In modern processors, the time to execute a given set of instructions may vary depending on many factors. Two important factors in these variations are the number of cycles and the CPU frequency.
This document provides software guidance for mitigating timing side channels due to CPU frequency behavior. Power management algorithms in most modern processors, including Intel® processors, provide mechanisms to enforce electrical parameters (such as power and current) to remain below specified limits. CPU frequency throttling is triggered when one of these limits is reached, which results in CPU frequency changes regardless of whether Intel® Turbo Boost Technology is enabled or not. Such frequency change and derived behavior may be correlated with information being processed by the CPU and it may be possible to infer parts of the information through sophisticated analysis of the frequency change behavior. The guidance in this document is based on Intel’s information and understanding at the time of writing. However as with other security guidance, Intel’s guidance is subject to change as the threat landscape evolves or new information becomes available.
Frequency Throttling Side Channel
When CPUs process data, transistors are switched on and off depending on the data being processed. Switching transistors uses energy. Consequently, running the same workload with different data may change the CPU’s power consumption. This physical property may lead to malicious actors correlating the system’s reported power consumption with possible secret data being processed on the system. Refer to Intel’s Running Average Power Limit Energy Reporting technical article for more details on Intel’s mitigations.
The CPU power management unit routinely calculates the running averaged electrical parameters during the past time window and compares it against the power management reactive limits. If any of the limits are exceeded, the power management algorithm will trigger CPU throttling and adjust the maximal allowed frequency accordingly. As a result, there is an inverse correlation between the average throttling frequency and the power consumption1 before frequency throttling: a workload with higher power consumption before throttling tends to run at lower average throttled frequency, and vice versa. Furthermore, since the power consumption of a workload may be correlated with the data being processed, the throttling frequency may also be correlated with the data, which becomes a frequency side channel. The CPU frequency change also causes a difference in the execution time of the workload and results in a timing side channel.
Figure 1: Power management reactive limits throttling converts power differences to frequency/timing differences
Figure 1 explains the side channel using an illustrative example. Figure 1(a) shows the same program executed twice with the input data 1 (in blue) and data 2 (in orange), respectively. Assuming the program is a constant-cycle implementation, the number of cycles with data 1 and data 2 are the same (c1=c2). On the other hand, power consumption of processing data 1 and data 2 might be different. Without loss of generality, we assume processing data 1 consumes higher power (p1) compared to that of data 2 (p2). When neither p1 nor p2 exceeds the default power limit (or any other reactive limit), there is no throttling, and the frequency stays at fdefault when the program is running. As a result, the execution time of the program is the same with either data 1 or data 2.
Assuming the total power consumption exceeds the power limit due to increased system power consumption (such as when stressor code starts to run in parallel with the function) or a reduction of the power limit, frequency throttling occurs. As shown in Figure 1(c), since processing data 1 consumes more power than data 2, the averaged throttled frequency of data 1 (freq1) will become lower than that of data 2 (freq2) to ensure the power limit is satisfied. Of course, both throttling frequencies are lower than fdefault. Therefore, even if the number of execution cycles of the program is still data-invariant, the throttling frequency, and hence execution time, becomes data-variant. An attacker may utilize this side channel to extract secret data (such as cryptographic keys) from a constant-time cryptography implementation, since a typical constant-time implementation ensures only constant-cycle execution, and data-dependent variations in CPU frequency will result in data-dependent code execution time.
Power Management Reactive Limits
Intel® processors have several reactive limits related to power management, such as Running Average Power Limit (RAPL) and Voltage Regulator Thermal Design Current Limit (VR-TDC).
Running Average Power Limit (RAPL)
RAPL is a feature supported by Intel power management architecture to cap the power consumption on the system. When the configured power limit is exceeded, the CPU will be forced to run at a lower frequency to maximize performance while meeting the power limit requirement. Intel currently provides multiple power limit capabilities, including package-level power limits and platform-level power limits. Ring 0 software can configure both the running average window and the power limit of each capability through model specific registers (MSRs) such as, MSR_PKG_POWER_LIMIT for package-level power limit. Refer to Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3 Section 14.10 “Platform Specific Power Management Support” for more details.
Voltage Regulator Thermal Design Current Limit (VR-TDC)
VR-TDC is a power management feature supported by Intel power management architecture. The feature introduces a current limit, naturally specified in amperes, that is to be maintained to preserve the electrical constraints on properties of the voltage regulator (VR). Generally, the control algorithm monitors the Exponential Moving Average (EMA) current, which is also measured in amperes, by reading current measurements from the VR. As with other control algorithms, this algorithm controls the power budget based on a given time window. If the limit is hit, the processor will reduce the CPU frequency (frequency throttling) to ensure the current remains below this limit.
Related Issues
Intel released microcode updates (MCUs) in IPU 2020.2 and IPU 2021.2 responding to Running Average Power Limit energy reporting vulnerabilities (CVE-2020-8694 and CVE-2020-8695). None of the MCUs are meant to mitigate the frequency throttling side channel vulnerability. In the Software Guidance for Cryptographic Implementations section of this article, Intel provides software guidance for mitigating frequency throttling side channels against cryptographic implementations. Intel recommends cryptographic library and application developers refer to the suggested methods in this article to assess and harden their code against the frequency throttling side channel (also known as “Hertzbleed”).
This section provides cryptographic application and library developers2 with guidance to assess the risk and reduce the impact of frequency throttling side channels on cryptographic implementations. Remember that the root cause of the frequency throttling side channel is the power side channel, and the mitigation of it has been researched exhaustively. This document is not intended to provide comprehensive solutions to mitigate the frequency throttling side channel for all cryptography implementations, but instead provides recommendations to enable cryptography developers to evaluate the risks and to help harden their software implementations against this side channel. Intel recommends that cryptographic implementations follow existing guidance for developing constant-cycle code, as described in Intel’s Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations, and the Data Operand Independent Timing Instruction Set Architecture Guidance.
Cryptographic implementations may be vulnerable to frequency throttling side channels when all the following conditions are met. If one or more of these listed prerequisites is not satisfied, the cryptography implementation should not be impacted by this type of side channel.
Check the list of conditions below to assess your implementation’s risk based on the nature of the implementation and your threat model.
The Cryptographic Implementation is Vulnerable to Power Side Channel Attack
The power side channel is the fundamental root cause of the frequency throttling side channel. An implementation that is vulnerable to the frequency throttling side channel needs to satisfy all the prerequisites of physical power side channel attacks, except for the physical access capability to measure power. The prerequisites for a malicious actor to exploit the physical power side channel include, but are not limited to:
The ability to repeatedly initiate cryptographic operations with the same secret key to collect enough data.
For block ciphers, the ability to read input/output or inter-round state of the block cipher primitives. Note that the input/output is not necessarily the plaintext or ciphertext. One example is the counter (CTR) mode of block cipher, where the input to the block cipher is the concatenation of the nonce and counter.
Ability to Ensure Victim Execution hits the CPU’s Reactive Limits
For the power frequency to be correlated with secret data, a reactive limit needs to be hit while the victim workload is running. There are several techniques that an attacker may take to meet this necessary condition.
An attacker may run multiple instances of the same victim workload (using the same secret data) on multiple cores to increase power consumption of the package (to hit the limit) and increase Signal-to-Noise Ratio (SNR)3.
An attacker may run stressor workloads in parallel with the victim workload to increase package power consumption.
An attacker with ring 0 privilege can reduce the limits through reactive limit configuration interfaces (for example, MSRs) to ensure the victim workload hits the limit.
Ability to Monitor Frequency Change or Related CPU Behaviors with Sufficient Resolution
The attacker needs to be able to sample CPU frequency while the victim workload is running, or else observe the execution time of the victim workload with sufficient resolution to identify data-dependent differences in the measured information.
Software Implementation
The following guidance can help developers mitigate the frequency throttling side channel. Additionally, this guidance can be used as a defense-in-depth mechanism even when not all conditions for the frequency throttling side channel are met.
Most of the proven software-based countermeasures against power side channels on cryptographic primitives will also be effective against the frequency throttling side channel. For example, mitigations that reduce power SNR of single instructions are effective for both the physical power side channel and the frequency throttling side channel, since the SNR of averaged power consumption (and timing due to throttling) during the running average window is also reduced. Other techniques, such as software-based masking [1] [2], should be also effective against frequency throttling side channels.
Note that countermeasures that randomize the execution order of instructions, while being effective in making trace alignment and identification of point of interest harder for physical power side channel, are less effective at mitigating the frequency throttling side channel. This is because reordering instructions at the cycle granularity is less likely to impact averaged power consumption during the averaging time window of milliseconds or longer.
For cryptographic applications, an example of a generic countermeasure against power side channel is key refresh. One of the necessary conditions for power side channel is the ability to repeatedly kick off cryptographic operations with the same sensitive key. If the secret key is refreshed before enough traces can be collected, it will be harder for the attacker to fully deduce the secret. Key refresh frequency may be based on timing (for example, refresh per several hours) or data volume (for example, the volume of data being encrypted with the same key). If the implementor is uncertain of which threshold to use, the lowest threshold that meets performance/design requirements should be selected. It should be noted that the practicality of key refresh depends on the specific cryptographic use case (for example, key refresh is typically not applicable to disk encryption).
Avoiding Unnecessary Exposure of Reactive Limit Configuration Interfaces
As stated in the Conditions of the Attack section, if an adversary has access to certain hardware interfaces (for example, MSR_PKG_POWER_LIMIT), they may configure and reduce the reactive limits to make it easier for the victim workload to trigger frequency throttling. To reduce the attack surface, privileged software (for example, hypervisor or ring-0 software) that has access to these interfaces should avoid unnecessarily exposing those interfaces to untrusted entities (for example guest VMs or ring-3 software). If there is a business need to expose these interfaces, the designers of the privileged software should be aware of the potential security implication.
Restricting Correlation of Frequency Change or Related Behaviors
Another common countermeasure against side channel attacks is to jam the channel with noise to deter the attacker from deducing the secret. As the side channel in this attack is frequency change or derived behaviors, the noise can be injected into the frequency transition or timing information.
One method to do this is to leverage the inherent noise during cryptographic application calls. The cryptographic library provider or cryptographic application provider may restrict the maximum size of the plaintext/ciphertext allowed per API invocation, so that more invocations of the API are needed to process the same amount of data, which introduces more inherent noise.
Besides that, a cryptography implementor may proactively inject random noise into the cryptographic operations to increase timing variation. To implement this countermeasure, the developer may add dummy instructions that introduce sufficient power or latency variation. The dummy instructions should be independent from the secret data using cryptographic functions. For example, timing variations can be introduced using a loop of instructions with random iterations. In addition to that, any power variation induced by the dummy instructions may also increase the entropy of the frequency transition. To help ensure every frequency change is impacted by noise, Intel recommends injecting some noise during the running time window of the reactive limits that may be leveraged by an attacker. One possible way to balance the trade-offs between security and performance is to combine this scheme with the key refresh countermeasure described in Applying Effective Solutions Against Power Side Channel section to increase the time needed to perform a successful attack to a key lifetime that is acceptable for your implementation.
Steps to Take to Protect Your Code
Cryptographic library application providers are advised to take the following steps to assess and protect their code:
Assess whether the implementation is impacted based on the threat model and the necessary conditions of the attack.
If the cryptographic implementation is impacted and mitigation is needed:
Apply generic countermeasures against the power side channel on the cryptography primitive level (for example, masking) or cryptography application level (for example, key refresh).
Restrict correlation of frequency change or related behaviors. Examples include restricting maximum input data size per invocation and injecting random delay noise.
For privileged software or hypervisors, avoid unnecessary exposure of reactive limit configuration interfaces to untrusted entities.
S. Mangard, E. Oswald and T. Popp, Power Analysis Attacks: Revealing the Secrets of Smart Cards.
E. Prouff and M. Rivain, “Masking against Side-Channel Attacks: a Formal Security Proof,” in Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2013.
For simplicity, in this document, we use power to indicate any electrical parameter that exhibits similar behavior.
The definition of application is the software that utilizes cryptographic library primitives and owns/manages cryptography keys. The definition of a library is the software that provides cryptography primitives but does not own the key. Instead, the cryptographic library relies on the application to provide the cryptography key to use.
Here, signal is the secret-correlated power consumption, and noise is the secret-independent power consumption.
Hertzbleed is a new family of side-channel attacks: frequency side channels. In the worst case, these attacks can allow an attacker to extract cryptographic keys from remote servers that were previously believed to be secure.
Hertzbleed takes advantage of our experiments showing that, under certain circumstances, the dynamic frequency scaling of modern x86 processors depends on the data being processed. This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436.
Hertzbleed is a real, and practical, threat to the security of cryptographic software. We have demonstrated how a clever attacker can use a novel chosen-ciphertext attack against SIKE to perform full key extraction via remote timing, despite SIKE being implemented as “constant time”.
Research Paper
The Hertzbleed paper will appear in the 31st USENIX Security Symposium (Boston, 10–12 August 2022) with the following title:
Hertzbleed: Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86
Intel’s security advisory states that all Intel processors are affected. We experimentally confirmed that several Intel processors are affected, including desktop and laptop models from the 8th to the 11th generation Core microarchitecture.
AMD’s security advisory states that several of their desktop, mobile and server processors are affected. We experimentally confirmed that AMD Ryzen processors are affected, including desktop and laptop models from the Zen 2 and Zen 3 microarchitectures.
Other processor vendors (e.g., ARM) also implement frequency scaling in their products and were made aware of Hertzbleed. However, we have not confirmed if they are, or are not, affected by Hertzbleed.
What is the impact of Hertzbleed?
First, Hertzbleed shows that on modern x86 CPUs, power side-channel attacks can be turned into (even remote!) timing attacks—lifting the need for any power measurement interface. The cause is that, under certain circumstances, periodic CPU frequency adjustments depend on the current CPU power consumption, and these adjustments directly translate to execution time differences (as 1 hertz = 1 cycle per second).
Second, Hertzbleed shows that, even when implemented correctly as constant time, cryptographic code can still leak via remote timing analysis. The result is that current industry guidelines for how to write constant-time code (such as Intel’s one) are insufficient to guarantee constant-time execution on modern processors.
Is there an assigned CVE for Hertzbleed?
Yes. Hertzbleed is tracked under CVE-2022-23823 and CVE-2022-24436 in the Common Vulnerabilities and Exposures (CVE) system.
Is Hertzbleed a bug?
No. The root cause of Hertzbleed is dynamic frequency scaling, a feature of modern processors, used to reduce power consumption (during low CPU loads) and to ensure that the system stays below power and thermal limits (during high CPU loads).
When did you disclose Hertzbleed?
We disclosed our findings, together with proof-of-concept code, to Intel, Cloudflare and Microsoft in Q3 2021 and to AMD in Q1 2022. Intel originally requested our findings be held under embargo until May 10, 2022. Later, Intel requested a significant extension of that embargo, and we coordinated with them on publicly disclosing our findings on June 14, 2022.
Do Intel and AMD plan to release microcode patches to mitigate Hertzbleed?
No. To our knowledge, Intel and AMD do not plan to deploy any microcode patches to mitigate Hertzbleed. However, Intel provides guidance to mitigate Hertzbleed in software. Cryptographic developers may choose to follow Intel’s guidance to harden their libraries and applications against Hertzbleed. For more information, we refer to the official security advisories (Intel and AMD).
Why did Intel ask for a long embargo, considering they are not deploying patches?
Ask Intel.
Is there a workaround?
Technically, yes. However, it has a significant system-wide performance impact.
In most cases, a workload-independent workaround to mitigate Hertzbleed is to disable frequency boost. Intel calls this feature “Turbo Boost”, and AMD calls it “Turbo Core” or “Precision Boost”. Disabling frequency boost can be done either through the BIOS or at runtime via the frequency scaling driver. In our experiments, when frequency boost was disabled, the frequency stayed fixed at the base frequency during workload execution, preventing leakage via Hertzbleed. However, this is not a recommended mitigation strategy as it will significantly impact performance. Moreover, on some custom system configurations (with reduced power limits), data-dependent frequency updates may occur even when frequency boost is disabled.
What is SIKE?
SIKE (Supersingular Isogeny Key Encapsulation) is a decade old, widely studied key encapsulation mechanism. It is currently a finalist in NIST’s Post-Quantum Cryptography competition. It has multiple industrial implementations and was the subject of an in-the-wild deployment experiment. Among its claimed advantages are a “well-understood” side channel posture. You can find author names, implementations, talks, studies, articles, security analyses and more about SIKE on its official website.
What is a key encapsulation mechanism?
A key encapsulation mechanism is a protocol used to securely exchange a symmetric key using asymmetric (public-key) cryptography.
How did Cloudflare and Microsoft mitigate the attack on SIKE?
Both Cloudflare and Microsoft deployed the mitigation suggested by De Feo et al. (who, while our paper was under the long Intel embargo, independently re-discovered how to exploit anomalous 0s in SIKE for power side channels). The mitigation consists of validating, before decapsulation, that the ciphertext consists of a pair of linearly independent points of the correct order. The mitigation adds a decapsulation performance overhead of 5% for CIRCL and of 11% for PQCrypto-SIDH.
Is my constant-time cryptographic library affected?
Affected? Likely yes. Vulnerable? Maybe.
Your constant-time cryptographic library might be vulnerable if is susceptible to secret-dependent power leakage, and this leakage extends to enough operations to induce secret-dependent changes in CPU frequency. Future work is needed to systematically study what cryptosystems can be exploited via the new Hertzbleed side channel.
Can I use the logo?
Yes. The Hertzbleed logo is free to use under a CC0 license.
Last week, Cloudflare automatically detected and mitigated a 26 million request per second DDoS attack — the largest HTTPS DDoS attack on record.
The attack targeted a customer website using Cloudflare’s Free plan. Similar to the previous 15M rps attack, this attack also originated mostly from Cloud Service Providers as opposed to Residential Internet Service Providers, indicating the use of hijacked virtual machines and powerful servers to generate the attack — as opposed to much weaker Internet of Things (IoT) devices.
The 26M rps DDoS attack originated from a small but powerful botnet of 5,067 devices. On average, each node generated approximately 5,200 rps at peak. To contrast the size of this botnet, we’ve been tracking another much larger but less powerful botnet of over 730,000 devices. The latter, larger botnet wasn’t able to generate more than one million requests per second, i.e. roughly 1.3 requests per second on average per device. Putting it plainly, this botnet was, on average, 4,000 times stronger due to its use of virtual machines and servers.
Also, worth noting that this attack was over HTTPS. HTTPS DDoS attacks are more expensive in terms of required computational resources because of the higher cost of establishing a secure TLS encrypted connection. Therefore, it costs the attacker more to launch the attack, and for the victim to mitigate it. We’ve seen very large attacks in the past over (unencrypted) HTTP, but this attack stands out because of the resources it required at its scale.
Within less than 30 seconds, this botnet generated more than 212 million HTTPS requests from over 1,500 networks in 121 countries. The top countries were Indonesia, the United States, Brazil and Russia. About 3% of the attack came through Tor nodes.
The top source networks were the French-based OVH (Autonomous System Number 16276), the Indonesian Telkomnet (ASN 7713), the US-based iboss (ASN 137922) and the Libyan Ajeel (ASN 37284).
The DDoS threat landscape
It’s important to understand the attack landscape when thinking about DDoS protection. When looking at our recent DDoS Trends report, we can see that most of the attacks are small, e.g. cyber vandalism. However, even small attacks can severely impact unprotected Internet properties. On the other hand, large attacks are growing in size and frequency — but remain short and rapid. Attackers concentrate their botnet’s power to try and wreak havoc with a single quick knockout blow — trying to avoid detection.
DDoS attacks might be initiated by humans, but they are generated by machines. By the time humans can respond to the attack, it may be over. And even if the attack was quick, the network and application failure events can extend long after the attack is over — costing you revenue and reputation. For this reason, it is recommended to protect your Internet properties with an automated always-on protection service that does not rely on humans to detect and mitigate attacks.
Helping build a better Internet
At Cloudflare, everything we do is guided by our mission to help build a better Internet. The DDoS team’s vision is derived from this mission: our goal is to make the impact of DDoS attacks a thing of the past. The level of protection that we offer is unmetered and unlimited — It is not bounded by the size of the attack, the number of the attacks, or the duration of the attacks. This is especially important these days because as we’ve recently seen, attacks are getting larger and more frequent.
Not using Cloudflare yet? Start now with our Free and Pro plans to protect your websites, or contact us for comprehensive DDoS protection for your entire network using Magic Transit.
Welcome to our first DDoS report of 2022, and the ninth in total so far. This report includes new data points and insights both in the application-layer and network-layer sections — as observed across the global Cloudflare network between January and March 2022.
The first quarter of 2022 saw a massive spike in application-layer DDoS attacks, but a decrease in the total number of network-layer DDoS attacks. Despite the decrease, we’ve seen volumetric DDoS attacks surge by up to 645% QoQ, and we mitigated a new zero-day reflection attack with an amplification factor of 220 billion percent.
In the Russian and Ukrainian cyberspace, the most targeted industries were Online Media and Broadcast Media. In our Azerbaijan and Palestinian Cloudflare data centers, we’ve seen enormous spikes in DDoS activity — indicating the presence of botnets operating from within.
The Highlights
The Russian and Ukrainian cyberspace
Russian Online Media companies were the most targeted industries within Russia in Q1. The next most targeted was the Internet industry, then Cryptocurrency, and then Retail. While many attacks that targeted Russian Cryptocurrency companies originated in Ukraine or the US, another major source of attacks was from within Russia itself.
The majority of HTTP DDoS attacks that targeted Russian companies originated from Germany, the US, Singapore, Finland, India, the Netherlands, and Ukraine. It’s important to note that being able to identify where cyber attack traffic originates is not the same as being able to attribute where the attacker is located.
Attacks on Ukraine targeted Broadcast Media and Publishing websites and seem to have been more distributed, originating from more countries — which may indicate the use of global botnets. Still, most of the attack traffic originated from the US, Russia, Germany, China, the UK, and Thailand.
In January 2022, over 17% of under-attack respondents reported being targeted by ransom DDoS attacks or receiving a threat in advance.
That figure drastically dropped to 6% in February, and then to 3% in March.
When compared to previous quarters, we can see that in total, in Q1, only 10% of respondents reported a ransom DDoS attack; a 28% decrease YoY and 52% decrease QoQ.
Application-layer DDoS attacks
2022 Q1 was the busiest quarter in the past 12 months for application-layer attacks. HTTP-layer DDoS attacks increased by 164% YoY and 135% QoQ.
Diving deeper into the quarter, in March 2022 there were more HTTP DDoS attacks than in all of Q4 combined (and Q3, and Q1).
After four consecutive quarters in a row with China as the top source of HTTP DDoS attacks, the US stepped into the lead this quarter. HTTP DDoS attacks originating from the US increased by a staggering 6,777% QoQ and 2,225% YoY.
Network-layer DDoS attacks
Network-layer attacks in Q1 increased by 71% YoY but decreased 58% QoQ.
The Telecommunications industry was the most targeted by network-layer DDoS attacks, followed by Gaming and Gambling companies, and the Information Technology and Services industry.
Volumetric attacks increased in Q1. Attacks above 10 Mpps (million packets per second) grew by over 300% QoQ, and attacks over 100 Gbps grew by 645% QoQ.
This report is based on DDoS attacks that were automatically detected and mitigated by Cloudflare’s DDoS Protection systems. To learn more about how it works, check out this deep-dive blog post.
A note on how we measure DDoS attacks observed over our network To analyze attack trends, we calculate the “DDoS activity” rate, which is either the percentage of attack traffic out of the total traffic (attack + clean) observed over our global network, or in a specific location, or in a specific category (e.g., industry or billing country). Measuring the percentages allows us to normalize data points and avoid biases reflected in absolute numbers towards, for example, a Cloudflare data center that receives more total traffic and likely, also more attacks.
To view an interactive version of this report view it on Cloudflare Radar.
Ransom Attacks
Our systems constantly analyze traffic and automatically apply mitigation when DDoS attacks are detected. Each DDoS’d customer is prompted with an automated survey to help us better understand the nature of the attack and the success of the mitigation.
For over two years now, Cloudflare has been surveying attacked customers — one question on the survey being if they received a threat or a ransom note demanding payment in exchange to stop the DDoS attack. In the last quarter, 2021 Q4, we observed a record-breaking level of reported ransom DDoS attacks (one out of every five customers). This quarter, we’ve witnessed a drop in ransom DDoS attacks with only one out of 10 respondents reporting a ransom DDoS attack; a 28% decrease YoY and 52% decrease QoQ.
When we break it down by month, we can see that January 2022 saw the largest number of respondents reporting receiving a ransom letter in Q1. Almost one out of every five customers (17%).
Application-layer DDoS attacks
Application-layer DDoS attacks, specifically HTTP DDoS attacks, are attacks that usually aim to disrupt a web server by making it unable to process legitimate user requests. If a server is bombarded with more requests than it can process, the server will drop legitimate requests and — in some cases — crash, resulting in degraded performance or an outage for legitimate users.
Application-layer DDoS attacks by month
In Q1, application-layer DDoS attacks soared by 164% YoY and 135% QoQ – the busiest quarter within the past year.
Application-layer DDoS attacks increased to new heights in the first quarter of 2022. In March alone, there were more HTTP DDoS attacks than in all of 2021 Q4 combined (and Q3, and Q1).
Application-layer DDoS attacks by industry
Consumer Electronics was the most targeted industry in Q1.
Globally, the Consumer Electronics industry was the most attacked with an increase of 5,086% QoQ. Second was the Online Media industry with a 2,131% increase in attacks QoQ. Third were Computer Software companies, with an increase of 76% QoQ and 1,472 YoY.
To understand the origin of the HTTP attacks, we look at the geolocation of the source IP address belonging to the client that generated the attack HTTP requests. Unlike network-layer attacks, source IP addresses cannot be spoofed in HTTP attacks. A high percentage of DDoS activity in a given country usually indicates the presence of botnets operating from within the country’s borders.
After four consecutive quarters in a row with China as the top source of HTTP DDoS attacks, the US stepped into the lead this quarter. HTTP DDoS attacks originating from the US increased by a staggering 6,777% QoQ and 2,225% YoY. Following China in second place are India, Germany, Brazil, and Ukraine.
Application-layer DDoS attacks by target country
In order to identify which countries are targeted by the most HTTP DDoS attacks, we bucket the DDoS attacks by our customers’ billing countries and represent it as a percentage out of all DDoS attacks.
The US drops to second place, after being first for three consecutive quarters. Organizations in China were targeted the most by HTTP DDoS attacks, followed by the US, Russia, and Cyprus.
Network-layer DDoS attacks
While application-layer attacks target the application (Layer 7 of the OSI model) running the service that end users are trying to access (HTTP/S in our case), network-layer attacks aim to overwhelm network infrastructure (such as in-line routers and servers) and the Internet link itself.
Network-layer DDoS attacks by month
While HTTP DDoS attacks soared in Q1, network-layer DDoS attacks actually decreased by 58% QoQ, but still increased by 71% YoY.
Diving deeper into Q1, we can see that the amount of network-layer DDoS attacks remained mostly consistent throughout the quarter with about a third of attacks occurring every month.
Amongst these network-layer DDoS attacks are also zero-day DDoS attacks that Cloudflare automatically detected and mitigated.
In the beginning of March, Cloudflare researchers helped investigate and expose a zero-day vulnerability in Mitel business phone systems that amongst other possible exploitations, also enables attackers to launch an amplification DDoS attack. This type of attack reflects traffic off vulnerable Mitel servers to victims, amplifying the amount of traffic sent in the process by an amplification factor of 220 billion percent in this specific case. You can read more about it in our recent blog post.
We observed several of these attacks across our network. One of them targeted a North American cloud provider using the Cloudflare Magic Transit service. The attack originated from 100 source IPs mainly from the US, UK, Canada, Netherlands, Australia, and approximately 20 other countries. It peaked above 50 Mpps (~22 Gbps) and was automatically detected and mitigated by Cloudflare systems.
In this report, for the first time, we’ve begun classifying network-layer DDoS attacks according to the industries of our customers using the Spectrum and Magic products. This classification allows us to understand which industries are targeted the most by network-layer DDoS attacks.
When we look at Q1 statistics, we can see that in terms of attack packets and attack bytes launched towards Cloudflare customers, the Telecommunications industry was targeted the most. More than 8% of all attack bytes and 10% of all attack packets that Cloudflare mitigated targeted Telecommunications companies.
Following not too far behind, in second and third place were the Gaming / Gambling and Information Technology and Services industries.
Network-layer DDoS attacks by target country
Similarly to the classification by our customers’ industry, we can also bucket attacks by our customers’ billing country as we do for application-layer DDoS attacks, to identify the top attacked countries.
Looking at Q1 numbers, we can see that the US was targeted by the highest percentage of DDoS attacks traffic — over 10% of all attack packets and almost 8% of all attack bytes. Following the US is China, Canada, and Singapore.
Network-layer DDoS attacks by ingress country
When trying to understand where network-layer DDoS attacks originate, we cannot use the same method as we use for the application-layer attack analysis. To launch an application-layer DDoS attack, successful handshakes must occur between the client and the server in order to establish an HTTP/S connection. For a successful handshake to occur, the attacker cannot spoof their source IP address. While the attacker may use botnets, proxies, and other methods to obfuscate their identity, the attacking client’s source IP location does sufficiently represent the attack source of application-layer DDoS attacks.
On the other hand, to launch network-layer DDoS attacks, in most cases, no handshake is needed. Attackers can spoof the source IP address in order to obfuscate the attack source and introduce randomness into the attack properties, which can make it harder for simple DDoS protection systems to block the attack. So if we were to derive the source country based on a spoofed source IP, we would get a ‘spoofed country’.
For this reason, when analyzing network-layer DDoS attack sources, we bucket the traffic by the Cloudflare edge data center locations where the traffic was ingested, and not by the (potentially) spoofed source IP to get an understanding of where the attacks originate from. We are able to achieve geographical accuracy in our report because we have data centers in over 270 cities around the world. However, even this method is not 100% accurate, as traffic may be back hauled and routed via various Internet Service Providers and countries for reasons that vary from cost reduction to congestion and failure management.
In Q1, the percentage of attacks detected in Cloudflare’s data centers in Azerbaijan increased by 16,624% QoQ and 96,900% YoY, making it the country with the highest percentage of network-layer DDoS activity (48.5%).
Following our Azerbaijanian data center is our Palestinian data center where a staggering 41.9% of all traffic was DDoS traffic. This represents a 10,120% increase QoQ and 46,456% YoY.
To view all regions and countries, check out the interactive map.
Attack vectors
SYN Floods remain the most popular DDoS attack vector, while use of generic UDP floods drops significantly in Q1.
An attack vector is a term used to describe the method that the attacker uses to launch their DDoS attack, i.e., the IP protocol, packet attributes such as TCP flags, flooding method, and other criteria.
In Q1, SYN floods accounted for 57% of all network-layer DDoS attacks, representing a 69% increase QoQ and a 13% increase YoY. In second place, attacks over SSDP surged by over 1,100% QoQ. Following were RST floods and attacks over UDP. Last quarter, generic UDP floods took the second place, but this time, generic UDP DDoS attacks plummeted by 87% QoQ from 32% to a mere 3.9%.
Emerging threats
Identifying the top attack vectors helps organizations understand the threat landscape. In turn, this may help them improve their security posture to protect against those threats. Similarly, learning about new emerging threats that may not yet account for a significant portion of attacks, can help mitigate them before they become a significant force.
When we look at new emerging attack vectors in Q1, we can see increases in DDoS attacks reflecting off of Lantronix services (+971% QoQ) and SSDP reflection attacks (+724% QoQ). Additionally, SYN-ACK attacks increased by 437% and attacks by Mirai botnets by 321% QoQ.
Attacker reflecting traffic off of Lantronix Discovery Service
Lantronix is a US-based software and hardware company that provides solutions for Internet of Things (IoT) management amongst their vast offering. One of the tools that they provide to manage their IoT components is the Lantronix Discovery Protocol. It is a command-line tool that helps to search and find Lantronix devices. The discovery tool is UDP-based, meaning that no handshake is required. The source IP can be spoofed. So an attacker can use the tool to search for publicly exposed Lantronix devices using a 4 byte request, which will then in turn respond with a 30 byte response from port 30718. By spoofing the source IP of the victim, all Lantronix devices will target their responses to the victim — resulting in a reflection/amplification attack.
Simple Service Discovery Protocol used for reflection DDoS attacks
The Simple Service Discovery Protocol (SSDP) protocol works similarly to the Lantronix Discovery protocol, but for Universal Plug and Play (UPnP) devices such as network-connected printers. By abusing the SSDP protocol, attackers can generate a reflection-based DDoS attack overwhelming the target’s infrastructure and taking their Internet properties offline. You can read more about SSDP-based DDoS attacks here.
Network-layer DDoS attacks by attack rate
In Q1, we observed a massive uptick in volumetric DDoS attacks — both from the packet rate and bitrate perspective. Attacks over 10 Mpps grew by over 300% QoQ, and attacks over 100 Gbps grew by 645% QoQ.
There are different ways of measuring the size of an L3/4 DDoS attack. One is the volume of traffic it delivers, measured as the bit rate (specifically, terabits per second or gigabits per second). Another is the number of packets it delivers, measured as the packet rate (specifically, millions of packets per second).
Attacks with high bit rates attempt to cause a denial-of-service event by clogging the Internet link, while attacks with high packet rates attempt to overwhelm the servers, routers, or other in-line hardware appliances. These devices dedicate a certain amount of memory and computation power to process each packet. Therefore, by bombarding it with many packets, the appliance can be left with no further processing resources. In such a case, packets are “dropped,” i.e., the appliance is unable to process them. For users, this results in service disruptions and denial of service.
Distribution by packet rate
The majority of network-layer DDoS attacks remain below 50,000 packets per second. While 50 kpps is on the lower side of the spectrum at Cloudflare scale, it can still easily take down unprotected Internet properties and congest even a standard Gigabit Ethernet connection.
When we look at the changes in the attack sizes, we can see that attacks of over 10 Mpps grew by over 300% QoQ. Similarly, attacks of 1-10 Mpps grew by almost 40% QoQ.
Distribution by bitrate
In Q1, most of the network-layer DDoS attacks remain below 500 Mbps. This too is a tiny drop in the water at Cloudflare scale, but can very quickly shut down unprotected Internet properties with less capacity or at the very least congest, even a standard Gigabit Ethernet connection.
Graph of the distribution of network-layer DDoS attacks by bit rate in 2022 Q1
Similarly to the trends observed in the packet-per-second realm, here we can also see large increases. The amount of DDoS attacks that peaked over 100 Gbps increased by 645% QoQ; attacks peaking between 10 Gbps to 100 Gbps increased by 407%; attacks peaking between 1 Gbps to 10 Gbps increased by 88%; and even attacks peaking between 500 Mbps to 1 Gbps increased by almost 20% QoQ.
Network-layer DDoS attacks by duration
Most attacks remain under one hour in duration, reiterating the need for automated always-on DDoS mitigation solutions.
We measure the duration of an attack by recording the difference between when it is first detected by our systems as an attack and the last packet we see with that attack signature towards that specific target.
In previous reports, we provided a breakdown of ‘attacks under an hour’, and larger time ranges. However, in most cases over 90 percent of attacks last less than an hour. So starting from this report, we broke down the short attacks and grouped them by shorter time ranges to provide better granularity.
One important thing to keep in mind is that even if an attack lasts only a few minutes, if it is successful, the repercussions could last well beyond the initial attack duration. IT personnel responding to a successful attack may spend hours and even days restoring their services.
In the first quarter of 2022, more than half of the attacks lasted 10-20 minutes, approximately 40% ended within 10 minutes, another ~5% lasted 20-40 minutes, and the remaining lasted longer than 40 minutes.
Short attacks can easily go undetected, especially burst attacks that, within seconds, bombard a target with a significant number of packets, bytes, or requests. In this case, DDoS protection services that rely on manual mitigation by security analysis have no chance in mitigating the attack in time. They can only learn from it in their post-attack analysis, then deploy a new rule that filters the attack fingerprint and hope to catch it next time. Similarly, using an “on-demand” service, where the security team will redirect traffic to a DDoS provider during the attack, is also inefficient because the attack will already be over before the traffic routes to the on-demand DDoS provider.
It’s recommended that companies use automated, always-on DDoS protection services that analyze traffic and apply real-time fingerprinting fast enough to block short-lived attacks.
Summary
Cloudflare’s mission is to help build a better Internet. A better Internet is one that is more secure, faster, and reliable for everyone — even in the face of DDoS attacks. As part of our mission, since 2017, we’ve been providing unmetered and unlimited DDoS protection for free to all of our customers. Over the years, it has become increasingly easier for attackers to launch DDoS attacks. But as easy as it has become, we want to make sure that it is even easier — and free — for organizations of all sizes to protect themselves against DDoS attacks of all types.
Not using Cloudflare yet? Start now with our Free and Pro plans to protect your websites, or contact us for comprehensive DDoS protection for your entire network using Magic Transit.
CUPERTINO, CALIFORNIA Apple today previewed macOS Ventura, the latest version of the world’s most advanced desktop operating system, which takes the Mac experience to a whole new level. Stage Manager gives Mac users an all-new way to stay focused on the task in front of them while seamlessly switching between apps and windows. Continuity Camera uses iPhone as the webcam on Mac to do things that were never possible before,1 and with Handoff coming to FaceTime, users can start a FaceTime call on their iPhone or iPad and fluidly pass it over to their Mac. Mail and Messages come with great new features that make the apps better than ever, while Safari — the world’s fastest browser on Mac2 — ushers in a passwordless future with passkeys. And with the power and popularity of Apple silicon, and new developer tools in Metal 3, gaming on Mac has never been better.
“macOS Ventura includes powerful features and new innovations that help make the Mac experience even better. New tools like Stage Manager make focusing on tasks and moving between apps and windows easier and faster than ever, and Continuity Camera brings new videoconferencing features to any Mac, including Desk View, Studio Light, and more,” said Craig Federighi, Apple’s senior vice president of Software Engineering. “With helpful new features in Messages, state-of-the-art search technologies in Mail, and an updated design for Spotlight, Ventura has so much to offer and enriches many of the ways customers use their Macs.”
Stage Manager automatically organises open apps and windows so users can concentrate on their work and still see everything in a single glance. The current window users are working in is displayed prominently in the center, and other open windows appear on the left-hand side so they can quickly and easily switch between tasks. Users can also group windows together when working on specific tasks or projects that require different apps. Stage Manager works in concert with other macOS windowing tools — including Mission Control and Spaces — and users can now easily get to their desktop with a single click.
Pause playback of video: Stage Manager in macOS Ventura
Stage Manager automatically arranges open windows and puts the app the user is currently working with front and center.
Apple Devices Working Together with Continuity
Continuity Cameranow gives Mac customers the ability to use their iPhone as a webcam, and unlocks new capabilities that were never possible before on a webcam. With the power of Continuity, Mac can automatically recognise and use the camera on iPhone when it is nearby — without the need to wake or select it — and iPhone can even connect to Mac wirelessly for greater flexibility.3 Continuity Camera delivers innovative features to all Mac computers including Center Stage, Portrait mode, and the new Studio Light — an effect that beautifully illuminates a user’s face while dimming the background. Plus, Continuity Camera taps into the Ultra Wide camera on iPhone to enable Desk View, which simultaneously shows the user’s face and an overhead view of their desk — great for creating DIY videos, showing off sketches over FaceTime, and so much more.4
Handoff now comes to FaceTime, allowing users to start a FaceTime call on one Apple device and seamlessly transfer it to another Apple device nearby. Users can be on a FaceTime call on iPhone or iPad, then move the call to their Mac with just a click, or start a call on their Mac and shift to iPhone or iPad when they need to continue on the go.
Powerful Updates to Key macOS Apps and Features
Safari offers the fastest and most power-efficient browsing experience on the Mac, along with trailblazing privacy features. In macOS Ventura, Safari introduces a powerful new way for users to browse together: With shared Tab Groups, friends, family, and colleagues can share their favorite sites in Safari and see what tabs others are looking at live. Users can also build a list of bookmarks on a shared Start Page, and even start a Messages conversation or FaceTime call right from Safari — great for planning a trip or researching a project together.
In the biggest overhaul to search in years, Mail now uses state-of-the-art techniques to deliver more relevant, accurate, and complete results. Users can quickly find what they are looking for as soon as they click into search, including recent emails, contacts, documents, photos, and more, all before they even start typing. Users can also schedule emails and even cancel delivery after hitting send,5 and Mail now intelligently detects if items such as an attachment or cc’d recipient is missing from their message. In Mail, users can set reminders to come back to a message at a particular date and time, and receive automatic suggestions to follow up on an email if there has been no response.
Messages on the Mac now includes the ability to edit or undo a recently sent message, mark a message as unread, or even recover accidentally deleted messages.6 New collaboration features make working with others quick and seamless. Now, when a user shares a file via Messages using the share sheet or drag and drop, they can choose to share a copy or collaborate. When they choose to collaborate, everyone on a Messages thread is automatically added. And when someone makes an edit to the shared document, activity updates appear at the top of the thread. Users can also join SharePlay sessions from their Mac right in Messages, so they can chat and participate in synchronised experiences.
Spotlight includes an updated design that makes navigation easier, new features that provide a more consistent experience across Apple devices, and Quick Look for quickly previewing files. Users can now find images in their photo library, across the system, and on the web. They can even search for their photos by location, people, scenes, or objects, and Live Text lets them search by text inside images. To be even more productive, users can now take actions from Spotlight, like starting a timer, creating a new document, or running a shortcut. And Spotlight now includes rich results for artists, movies, actors, and TV shows, as well as businesses and sports.
With iCloud Shared Photo Library, users can now create and share a separate photo library among up to six family members, so everyone can enjoy all of their family photos. Users can choose to share all of their existing photos from their personal libraries, or share based on a start date or people in the photos. To help keep their Shared Library up to date, users will receive intelligent suggestions to share relevant photo moments that include participants in the library and any other people they choose. Every user in the Shared Photo Library can add, delete, edit, or favorite the shared photos and videos, which will appear in each user’s Memories and Featured Photos so that everyone can relive more complete family moments.
More Secure Browsing in Safari
Browsing in Safari is even safer with passkeys, next-generation credentials that are more secure, easy to use, and designed to replace passwords. Passkeys are unique digital keys that stay on device and are never stored on a web server, so hackers can’t leak them or trick users into sharing them. Passkeys make it simple to sign in securely, using Touch ID or Face ID for biometric verification, and iCloud Keychain to sync across Mac, iPhone, iPad, and Apple TV with end-to-end encryption. They will also work across apps and the web, and users can even sign in to websites or apps on non-Apple devices using their iPhone.
Immersive Gaming Experiences
The power of Apple silicon enables every new Mac to run AAA games with ease, including upcoming titles such as EA’s GRID Legends and Capcom’s Resident Evil Village. And since Apple silicon also powers iPad, game developers can bring their AAA games to even more users, like No Man’s Sky from Hello Games, which is coming to both Mac and iPad later this year.
Metal 3, the latest version of the software that powers the gaming experience across Apple platforms, introduces new features that take the gaming experience on Mac to new heights and unleash the full potential of Apple silicon for years to come. MetalFX Upscaling enables developers to quickly render complex scenes by using less compute-intensive frames, and then apply resolution scaling and temporal anti-aliasing. The result is accelerated performance that provides gamers with a more responsive feel and graphics that look stunning. Game developers also benefit from a new Fast Resource Loading API that minimizes wait time by providing a more direct path from storage to the GPU, so games can easily access high-quality textures and geometry needed to create expansive worlds for realistic and immersive gameplay.
Pause playback of video: Gaming with Metal 3
Metal 3 brings new features that unleash the full potential of Apple silicon for even greater gaming experiences.
More Great Experiences Coming with macOS Ventura
Live Text uses on-device intelligence to recognise text in images across the system, and now adds support for paused video frames, as well as Japanese and Korean text. Users can also now lift the subject away from an image and drop it into another app. And Visual Look Up expands its recognition capabilities to now include animals, birds, insects, statues, and even more landmarks.
The Weather and Clock apps, with all the features users know and love from iPhone, have been optimized for Mac.
New accessibility tools include Live Captions for all audio content, Type to Speak on calls, Text Checker to support proofreading for VoiceOver users, and more.7
System Settings is the new name for System Preferences, and comes with a refreshed and streamlined design that is easier to navigate and instantly familiar to iPhone and iPad users.
macOS security gets even stronger with new tools that make the Mac more resistant to attack, including Rapid Security Response that works in between normal updates to easily keep security up to date without a reboot.
Availability
The developer beta of macOS Ventura is available to Apple Developer Program members at developer.apple.com starting today. A public beta will be available to Mac users next month at beta.apple.com. macOS Ventura will be available this fall as a free software update. For more information, including compatible Mac models, visit apple.com/in/macos/macos-ventura-preview. Features are subject to change. Some features may not be available in all regions or languages.
A webmail application enables organizations to host a centralized, browser-based email client for their members. Typically, users log into the webmail server with their email credentials, then the webmail server acts as a proxy to the organization’s email server and allows authenticated users to view and send emails.
With so much trust being placed into webmail servers, they naturally become a highly interesting target for attackers. If a sophisticated adversary could compromise a webmail server, they can intercept every sent and received email, access password-reset links, and sensitive documents, impersonate personnel and steal all credentials of users logging into the webmail service.
This blog post discusses a vulnerability that the Sonar R&D team discovered in Horde Webmail. The vulnerability allows an attacker to fully take over an instance as soon as a victim opens an email the attacker sent. At the time of writing, no official patch is available.
Impact
The discovered code vulnerability (CVE-2022-30287) allows an authenticated user of a Horde instance to execute arbitrary code on the underlying server.
The vulnerability can be exploited with a single GET request which can be triggered via Cross-Site-Request-Forgery. For this, an attacker can craft a malicious email and include an external image that when rendered exploits the vulnerability without further interaction of a victim: the only requirement is to have a victim open the malicious email.
The vulnerability exists in the default configuration and can be exploited with no knowledge of a targeted Horde instance. We confirmed that it exists in the latest version. The vendor has not released a patch at the time of writing.
Another side-effect of this vulnerability is that the clear-text credentials of the victim triggering the exploit are leaked to the attacker. The adversary could then use them to gain access to even more services of an organization. This is demonstrated in our video:
In the following sections, we go into detail about the root cause of this vulnerability and how attackers could exploit it.
Background – Horde Address Book configuration
Horde Webmail allows users to manage contacts. From the web interface, they can add, delete and search contacts. Administrators can configure where these contacts should be stored and create multiple address books, each backed by a different backend server and protocol.
The following snippet is an excerpt from the default address book configuration file and shows the default configuration for an LDAP backend:
As can be seen, this LDAP configuration is added to an array of available address book backends stored in the $cfgSources array. The configuration itself is a key/value array containing entries used to configure the LDAP driver.
CVE-2022-30287 – Lack of type checking in Factory class
When a user interacts with an endpoint related to contacts, they are expected to send a string identifying the address book they want to use. Horde then fetches the corresponding configuration from the $cfgSources array and manages the connection to the address book backend.
The following code snippet demonstrates typical usage of this pattern:
The code snippet above shows how the parameter $source is received and passed to the create() method of the Turba_Factory_Driver. Turba is the name of the address book component of Horde.
Things start to become interesting when looking at the create() method:
turba/lib/Factory/Driver.php
51 public function create($name, $name2 = '', $cfgSources = array())
52 {
53 // …
57 if (is_array($name)) {
58 ksort($name);
59 $key = md5(serialize($name));
60 $srcName = $name2;
61 $srcConfig = $name;
62 } else {
63 $key = $name;
64 $srcName = $name;
65 if (empty($cfgSources[$name])) {
66 throw new Turba_Exception(sprintf(_("The address book \"%s\" does not exist."), $name));
67 }
68 $srcConfig = $cfgSources[$name];
69 }
On line 57, the type of the $name parameter is checked. This parameter corresponds to the previously shown $source parameter. If it is an array, it is used directly as a config by setting it to $srcConfig variable. If it is a string, the global $cfgSources is accessed with it and the corresponding configuration is fetched.
This behavior is interesting to an attacker as Horde expects a well-behaved user to send a string, which then leads to a trusted configuration being used. However, there is no type checking in place which could stop an attacker from sending an array as a parameter and supplying an entirely controlled configuration.
Some lines of code later, the create() method dynamically instantiates a driver class using values from the attacker-controlled array:
With this level of control, an attacker can choose to instantiate an arbitrary address book driver and has full control over the parameters passed to it, such as for example the host, username, password, file paths etc.
Instantiating a driver that enables an attacker to execute arbitrary code
The next step for an attacker would be to inject a driver configuration that enables them to execute arbitrary code on the Horde instance they are targeting.
We discovered that Horde supports connecting to an IMSP server, which uses a protocol that was drafted in 1995 but never finalized as it was superseded by the ACAP protocol. When connecting to this server, Horde fetches various entries. Some of these entries are interpreted as PHP serialized objects and are then unserialized.
The following code excerpt from the _read() method of the IMSP driver class shows how the existence of a __members entry is checked. If it exists, it is deserialized:
turba/lib/Driver/Imsp.php
223 if (!empty($temp['__members'])) {
224 $tmembers = @unserialize($temp['__members']);
225 }
By default, Horde blocks any images in HTML emails that don’t have a data: URI. An attacker can bypass this restriction by using the HTML tags <picture> and <source>. A <picture> tag allows developers to specify multiple image sources that are loaded depending on the dimensions of the user visiting the site. The following example bypasses the blocking of external images:
At the time of writing, no official patch is available. As Horde seems to be no longer actively maintained, we recommend considering alternative webmail solutions.
Timeline
Date
Action
2022-02-02
We report the issue to the vendor and inform about our 90 disclosure policy
2022-02-17
We ask for a status update.
2022-03-02
Horde releases a fix for a different issue we reported previously and acknowledge this report.
2022-05-03
We inform the vendor that the 90-day disclosure deadline has passed
Summary
In this blog post, we described a vulnerability that allows an attacker to take over a Horde webmail instance simply by sending an email to a victim and having the victim read the email.
The vulnerability occurs in PHP code, which is typically using dynamic types. In this case, a security-sensitive branch was entered if a user-controlled variable was of the type array. We highly discourage developers from making security decisions based on the type of a variable, as it is often easy to miss language-specific quirks.
Atlassian has released security updates to address a critical zero-day vulnerability in Confluence Server and Data Center actively exploited in the wild to backdoor Internet-exposed servers.
The zero-day (CVE-2022-26134) affects all supported versions of Confluence Server and Data Center and allows unauthenticated attackers to gain remote code execution on unpatched servers.
The company has now released patches and advises all customers to upgrade their appliances to versions 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4, and 7.18.1, which contain a fix for this flaw.
“We strongly recommend upgrading to a fixed version of Confluence as there are several other security fixes included in the fixed versions of Confluence,” Atlassian said.
Admins who cannot immediately upgrade their Confluence installs can also use a temporary workaround to mitigate the CVE-2022-26134 security bug by updating some JAR files on their Confluence servers by following the detailed instructions available here.
Widely exploited in ongoing attacks
The security vulnerability was discovered by cybersecurity firm Volexity over the Memorial Day weekend during an incident response.
While analyzing the incident, Volexity discovered that the zero-day was used to install a BEHINDER JSP web shell allowing the threat actors to execute commands on the compromised server remotely.
They also deployed a China Chopper web shell and a simple file upload tool as backups to maintain access to the hacked server.
Volexity threat analysts added that they believe multiple threat actors from China are using CVE-2022-26134 exploits to hack into Internet-exposed and unpatched Confluence servers.
The company also released a list of IP addresses used in the attacks and some Yara rules to identify web shell activity on potentially breached Confluence servers.
“The targeted industries/verticals are quite widespread. This is a free-for-all where the exploitation seems coordinated,” Volexity President Steven Adair revealed today.
“It is clear that multiple threat groups and individual actors have the exploit and have been using it in different ways.
“Some are quite sloppy and others are a bit more stealth. Loading class files into memory and writing JSP shells are the most popular we have seen so far.”
A similar Atlassian Confluence remote code execution vulnerability was exploited in the wild in September 2021 to install cryptomining malware after a PoC exploit was publicly shared online.
Pharmaceutical giant Novartis says no sensitive data was compromised in a recent cyberattack by the Industrial Spy data-extortion gang.
Industrial Spy is a hacking group that runs an extortion marketplace where they sell data stolen from compromised organizations.
Yesterday, the hacking group began selling data allegedly stolen from Novartis on their Tor extortion marketplace for $500,000 in bitcoins.
The threat actors claim that the data is related to RNA and DNA-based drug technology and tests from Novartis and were stolen “directly from the laboratory environment of the manufacturing plant.”
Novartis data sold on the Industrial Spy extortion marketplace Source: BleepingComputer
The data being sold consists of 7.7 MB of PDF files, which all have a timestamp of 2/25/2022 04:26, likely when the data was stolen.
As the amount of data for sale is minimal, it is not clear if this is all the threat actors stole or if they have further data to sell later.
BleepingComputer emailed Novartis to confirm the attack and theft of data and received the following statement.
“Novartis is aware of this matter. We have thoroughly investigated it and we can confirm that no sensitive data has been compromised. We take data privacy and security very seriously and have implemented industry standard measures in response to these kind of threats to ensure the safety of our data.” – Novartis.
Novartis declined to answer any further questions about the breach, when it occurred, and how the threat actors gained access to their data.
Industrial Spy is also known to use ransomware in attacks, but there is no evidence that devices were encrypted during the Novartis incident.
Sample of an exploit targeting the Tatsu Builder plugin vulnerability from this IP Address.
Example of a pharma website that was the end result of a redirect chain.
The s_e.php file sample in its raw form: a file this IP was trying to access.
![Graph of the yearly distribution of network-layer DDoS attacks by month in the past 12 months]](https://blog.cloudflare.com/content/images/2022/04/image28.png)
