A new phishing campaign has been targeting U.S. organizations in the military, security software, manufacturing supply chain, healthcare and pharmaceutical sectors to steal Microsoft Office 365 and Outlook credentials.
The operation is ongoing and the threat actor behind it uses fake voicemail notifications to lure victims into opening a malicious HTML attachment.
Campaign overview
According to researchers at cloud security company ZScaler, the recently discovered campaign shares tactics, techniques, and procedures (TTPs) with another operation analyzed in mid-2020.
The threat actors leverage email services in Japan to route their messages and spoof the sender’s address, making it look like the emails come from an address belonging to the targeted organization.
Email headers(Zscaler)
The email has an HTML attachment that uses a music note character in the naming to make it appear as if the file is a sound clip. In reality, the file contains obfuscated JavaScript code that takes the victim to a phishing site.
Message used in the phishing campaign(Zscaler)
The URL format follows an assembly system that considers the targeted organization’s domain to make it appear as if the site is a legitimate subdomain.
Phishing domain naming scheme(Zscaler)
The redirection process first takes the victim to a CAPTCHA check, which is designed to evade anti-phishing tools and increases the illusion of legitimacy for the victims.
Typical CAPTCHA step on phishing site(Zscaler)
The CAPTCHA check was also used in a 2020 campaign that ZScaler’s ThreatLabZ researchers analyzed and it continues to be an effective middle step that helps increase the phishing success rate.
Once the users pass this step, they are redirected to a genuine-looking phishing page that steals Microsoft Office 365 accounts.
The final destination of the redirections is a phishing page(Zscaler)
Those careful enough would notice that the domain of the login page doesn’t belong to Microsoft or their organization and is one of the following:
briccorp[.]com
bajafulfillrnent[.]com
bpirninerals[.]com
lovitafood-tw[.]com
dorrngroup[.]com
lacotechs[.]com
brenthavenhg[.]com
spasfetech[.]com
mordematx[.]com
antarnex[.]com
This is why before submitting, or even before starting to type their username and password, users should always check and confirm they are on a real login portal and not a fake one.
Typically, recipients are logged into the account, which should make suspicious a request to log in once more to listen to the voicemail.
Voicemail-themed phishing using HTML attachments has been used since at least 2019, but it is still effective, especially with careless employees.
Cybersecurity researchers have disclosed details about 15 security flaws in Siemens SINEC network management system (NMS), some of which could be chained by an attacker to achieve remote code execution on affected systems.
“The vulnerabilities, if exploited, pose a number of risks to Siemens devices on the network including denial-of-service attacks, credential leaks, and remote code execution in certain circumstances,” industrial security company Claroty said in a new report.
The shortcomings in question — tracked from CVE-2021-33722 through CVE-2021-33736 — were addressed by Siemens in version V1.0 SP2 Update 1 as part of patches shipped on October 12, 2021.
“The most severe could allow an authenticated remote attacker to execute arbitrary code on the system, with system privileges, under certain conditions,” Siemens noted in an advisory at the time.
Chief among the weaknesses is CVE-2021-33723 (CVSS score: 8.8), which allows for privilege escalation to an administrator account and could be combined with CVE-2021-33722 (CVSS score: 7.2), a path traversal flaw, to execute arbitrary code remotely.
Another notable flaw relates to a case of SQL injection (CVE-2021-33729, CVSS score: 8.8) that could be exploited by an authenticated attacker to execute arbitrary commands in the local database.
“SINEC is in a powerful central position within the network topology because it requires access to the credentials, cryptographic keys, and other secrets granting it administrator access in order to manage devices in the network,” Claroty’s Noam Moshe said.
“From an attacker’s perspective carrying out a living-off-the-land type of attack where legitimate credentials and network tools are abused to carry out malicious activity, access to, and control of, SINEC puts an attacker in prime position for: reconnaissance, lateral movement, and privilege escalation.”
A security flaw in Apple Safari that was exploited in the wild earlier this year was originally fixed in 2013 and reintroduced in December 2016, according to a new report from Google Project Zero.
The issue, tracked as CVE-2022-22620 (CVSS score: 8.8), concerns a case of a use-after-free vulnerability in the WebKit component that could be exploited by a piece of specially crafted web content to gain arbitrary code execution.
In early February 2022, Apple shipped patches for the bug across Safari, iOS, iPadOS, and macOS, while acknowledging that it “may have been actively exploited.”
“In this case, the variant was completely patched when the vulnerability was initially reported in 2013,” Maddie Stone of Google Project Zero said. “However, the variant was reintroduced three years later during large refactoring efforts. The vulnerability then continued to exist for 5 years until it was fixed as an in-the-wild zero-day in January 2022.”
While both the 2013 and 2022 bugs in the History API are essentially the same, the paths to trigger the vulnerability are different. Then subsequent code changes undertaken years later revived the zero-day flaw from the dead like a “zombie.”
Stating the incident is not unique to Safari, Stone further stressed taking adequate time to audit code and patches to avoid instances of duplicating the fixes and understanding the security impacts of the changes being carried out.
“Both the October 2016 and the December 2016 commits were very large. The commit in October changed 40 files with 900 additions and 1225 deletions. The commit in December changed 95 files with 1336 additions and 1325 deletions,” Stone noted.
“It seems untenable for any developers or reviewers to understand the security implications of each change in those commits in detail, especially since they’re related to lifetime semantics.”
The Asia-Africa-Europe-1 (AAE-1) suffered a cable cut on Tuesday 7 June causing outages and network issues around the world.
The issue with the 25,000km submarine cable occurred on land in Egypt, meaning that a fix was much faster than if it had broken at the bottom of the ocean. Most services were restored after four hours, but latency issues persisted for some providers.
The telecoms consortium-owned AAE-1 starts in Hong Kong, traveling west via Vietnam, Malaysia, Thailand, Cambodia, Myanmar, India, Pakistan, Oman, UAE, Qatar, Yemen, Djibouti, Saudi Arabia, Egypt, Greece, and Italy, before terminating in France.
It has 100Gbps transmission technology, with a minimum design capacity of 40Tbps.
Following the cut, Cloudflare Radar, the Internet trends division of Cloudflare, reported traffic dropping in Ethiopia, Somalia, and Tanzania. Network monitoring company Kentik saw issues in East Africa, Middle East and South Asia, including Pakistan, Somalia, Djibouti, and Saudi Arabia.
Curiously, Cloudflare said that it was “also seeing concurrent drops in traffic in Pakistan, Mozambique, Kenya, and Uganda, reportedly due to an issue also impacting the SeaMeWe5 submarine cable.”
The two cables are supposed to be independent.
The cable cut caused issues with Cloudflare’s own system. “Full restoration is expected to be done within 6 hours. We are working to mitigate impact to Internet users in the regions of Asia Pacific, Middle East, and Africa,” it said at the time.
Google Cloud’s said that there was “incident affecting Hybrid Connectivity, Virtual Private Cloud (VPC), Google Cloud Networking, Cloud NAT,” and reports “packet loss observed from Internet in Middle East to Google.”
OVHcloud said that “partner fiber cuts” caused network backbone degradation.
Amazon Web Services and Microsoft Azure appeared to suffer some network degradation, but made no official comment. Around the time of the cut, Microsoft’s LinkedIn service went briefly offline.
Today, a cluster of Internet standards were published that rationalize and modernize the definition of HTTP – the application protocol that underpins the web. This work includes updates to, and refactoring of, HTTP semantics, HTTP caching, HTTP/1.1, HTTP/2, and the brand-new HTTP/3. Developing these specifications has been no mean feat and today marks the culmination of efforts far and wide, in the Internet Engineering Task Force (IETF) and beyond. We thought it would be interesting to celebrate the occasion by sharing some analysis of Cloudflare’s view of HTTP traffic over the last 12 months.
However, before we get into the traffic data, for quick reference, here are the new RFCs that you should make a note of and start using:
HTTP’s overall architecture, common terminology and shared protocol aspects such as request and response messages, methods, status codes, header and trailer fields, message content, representation data, content codings and much more. Obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.
A syntax of HTTP that uses a binary framing format, which provides streams to support concurrent requests and responses. Message fields can be compressed using HPACK. Typically used over TCP and TLS. Obsoletes RFCs 7540 and 8740.
A variation of HPACK field compression that is optimized for the QUIC transport protocol.
On May 28, 2021, we enabled QUIC version 1 and HTTP/3 for all Cloudflare customers, using the final “h3” identifier that matches RFC 9114. So although today’s publication is an occasion to celebrate, for us nothing much has changed, and it’s business as usual.
A browser and web server typically automatically negotiate the highest HTTP version available. Thus, HTTP/3 takes precedence over HTTP/2. We looked back over the last year to understand HTTP/3 usage trends across the Cloudflare network, as well as analyzing HTTP versions used by traffic from leading browser families (Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari), major search engine indexing bots, and bots associated with some popular social media platforms. The graphs below are based on aggregate HTTP(S) traffic seen globally by the Cloudflare network, and include requests for website and application content across the Cloudflare customer base between May 7, 2021, and May 7, 2022. We used Cloudflare bot scores to restrict analysis to “likely human” traffic for the browsers, and to “likely automated” and “automated” for the search and social bots.
Traffic by HTTP version
Overall, HTTP/2 still comprises the majority of the request traffic for Cloudflare customer content, as clearly seen in the graph below. After remaining fairly consistent through 2021, HTTP/2 request volume increased by approximately 20% heading into 2022. HTTP/1.1 request traffic remained fairly flat over the year, aside from a slight drop in early December. And while HTTP/3 traffic initially trailed HTTP/1.1, it surpassed it in early July, growing steadily and roughly doubling in twelve months.
HTTP/3 traffic by browser
Digging into just HTTP/3 traffic, the graph below shows the trend in daily aggregate request volume over the last year for HTTP/3 requests made by the surveyed browser families. Google Chrome (orange line) is far and away the leading browser, with request volume far outpacing the others.
Below, we remove Chrome from the graph to allow us to more clearly see the trending across other browsers. Likely because it is also based on the Chromium engine, the trend for Microsoft Edge closely mirrors Chrome. As noted above, Mozilla Firefox first enabled production support in version 88 in April 2021, making it available by default by the end of May. The increased adoption of that updated version during the following month is clear in the graph as well, as HTTP/3 request volume from Firefox grew rapidly. HTTP/3 traffic from Apple Safari increased gradually through April, suggesting growth in the number of users enabling the experimental feature or running a Technology Preview version of the browser. However, Safari’s HTTP/3 traffic has subsequently dropped over the last couple of months. We are not aware of any specific reasons for this decline, but our most recent observations indicate HTTP/3 traffic is recovering.
Looking at the lines in the graph for Chrome, Edge, and Firefox, a weekly cycle is clearly visible in the graph, suggesting greater usage of these browsers during the work week. This same pattern is absent from Safari usage.
Across the surveyed browsers, Chrome ultimately accounts for approximately 80% of the HTTP/3 requests seen by Cloudflare, as illustrated in the graphs below. Edge is responsible for around another 10%, with Firefox just under 10%, and Safari responsible for the balance.
We also wanted to look at how the mix of HTTP versions has changed over the last year across each of the leading browsers. Although the percentages vary between browsers, it is interesting to note that the trends are very similar across Chrome, Firefox and Edge. (After Firefox turned on default HTTP/3 support in May 2021, of course.) These trends are largely customer-driven – that is, they are likely due to changes in Cloudflare customer configurations.
Most notably we see an increase in HTTP/3 during the last week of September, and a decrease in HTTP/1.1 at the beginning of December. For Safari, the HTTP/1.1 drop in December is also visible, but the HTTP/3 increase in September is not. We expect that over time, once Safari supports HTTP/3 by default that its trends will become more similar to those seen for the other browsers.
Traffic by search indexing bot
Back in 2014, Google announced that it would start to consider HTTPS usage as a ranking signal as it indexed websites. However, it does not appear that Google, or any of the other major search engines, currently consider support for the latest versions of HTTP as a ranking signal. (At least not directly – the performance improvements associated with newer versions of HTTP could theoretically influence rankings.) Given that, we wanted to understand which versions of HTTP the indexing bots themselves were using.
Despite leading the charge around the development of QUIC, and integrating HTTP/3 support into the Chrome browser early on, it appears that on the indexing/crawling side, Google still has quite a long way to go. The graph below shows that requests from GoogleBot are still predominantly being made over HTTP/1.1, although use of HTTP/2 has grown over the last six months, gradually approaching HTTP/1.1 request volume. (A blog post from Google provides some potential insights into this shift.) Unfortunately, the volume of requests from GoogleBot over HTTP/3 has remained extremely limited over the last year.
Microsoft’s BingBot also fails to use HTTP/3 when indexing sites, with near-zero request volume. However, in contrast to GoogleBot, BingBot prefers to use HTTP/2, with a wide margin developing in mid-May 2021 and remaining consistent across the rest of the past year.
Traffic by social media bot
Major social media platforms use custom bots to retrieve metadata for shared content, improve language models for speech recognition technology, or otherwise index website content. We also surveyed the HTTP version preferences of the bots deployed by three of the leading social media platforms.
Although Facebook supports HTTP/3 on their main website (and presumably their mobile applications as well), their back-end FacebookBot crawler does not appear to support it. Over the last year, on the order of 60% of the requests from FacebookBot have been over HTTP/1.1, with the balance over HTTP/2. Heading into 2022, it appeared that HTTP/1.1 preference was trending lower, with request volume over the 25-year-old protocol dropping from near 80% to just under 50% during the fourth quarter. However, that trend was abruptly reversed, with HTTP/1.1 growing back to over 70% in early February. The reason for the reversal is unclear.
Similar to FacebookBot, it appears TwitterBot’s use of HTTP/3 is, unfortunately, pretty much non-existent. However, TwitterBot clearly has a strong and consistent preference for HTTP/2, accounting for 75-80% of its requests, with the balance over HTTP/1.1.
In contrast, LinkedInBot has, over the last year, been firmly committed to making requests over HTTP/1.1, aside from the apparently brief anomalous usage of HTTP/2 last June. However, in mid-March, it appeared to tentatively start exploring the use of other HTTP versions, with around 5% of requests now being made over HTTP/2, and around 1% over HTTP/3, as seen in the upper right corner of the graph below.
Conclusion
We’re happy that HTTP/3 has, at long last, been published as RFC 9114. More than that, we’re super pleased to see that regardless of the wait, browsers have steadily been enabling support for the protocol by default. This allows end users to seamlessly gain the advantages of HTTP/3 whenever it is available. On Cloudflare’s global network, we’ve seen continued growth in the share of traffic speaking HTTP/3, demonstrating continued interest from customers in enabling it for their sites and services. In contrast, we are disappointed to see bots from the major search and social platforms continuing to rely on aging versions of HTTP. We’d like to build a better understanding of how these platforms chose particular HTTP versions and welcome collaboration in exploring the advantages that HTTP/3, in particular, could provide.
Current statistics on HTTP/3 and QUIC adoption at a country and autonomous system (ASN) level can be found on Cloudflare Radar.
Running HTTP/3 and QUIC on the edge for everyone has allowed us to monitor a wide range of aspects related to interoperability and performance across the Internet. Stay tuned for future blog posts that explore some of the technical developments we’ve been making.
And this certainly isn’t the end of protocol innovation, as HTTP/3 and QUIC provide many exciting new opportunities. The IETF and wider community are already underway building new capabilities on top, such as MASQUE and WebTransport. Meanwhile, in the last year, the QUIC Working Group has adopted new work such as QUIC version 2, and the Multipath Extension to QUIC.
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.
.png)
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.
