WordPress Core 6.0.2 Security & Maintenance Release – What You Need to Know

On August 30, 2022, the WordPress core team released WordPress version 6.0.2, which contains patches for 3 vulnerabilities, including a High Severity SQLi vulnerability in the Links functionality as well as two Medium Severity Cross-Site Scripting vulnerabilities.

These patches have been backported to every version of WordPress since 3.7. WordPress has supported automatic core updates for security releases since WordPress 3.7, and the vast majority of WordPress sites should receive a patch for their major version of WordPress automatically over the next 24 hours. We recommend verifying that your site has been automatically updated to one of the patched versions. Patched versions are available for every major version of WordPress since 3.7, so you can update without risking compatibility issues. If your site has not been updated automatically we recommend updating manually.

Vulnerability Analysis

As with every WordPress core release containing security fixes, the Wordfence Threat Intelligence team analyzed the code changes in detail to evaluate the impact of these vulnerabilities on our customers, and to ensure our customers remain protected.

They have determined that these vulnerabilities are unlikely to be targeted for exploitation due to the special cases needed to exploit. In most circumstances these vulnerabilities require either elevated privileges, such as those of an administrator, or the presence of a separate vulnerable or malicious plugin. Nonetheless, the Wordfence firewall should protect against any exploits that do not require administrative privileges. In nearly all cases administrators already have the maximum level of access and attackers with that level of access are unlikely to use convoluted and difficult exploits when simpler paths to making configuration changes or obtaining sensitive information are readily available.

Source and more details at: https://www.wordfence.com/blog/2022/08/wordpress-core-6-0-2-security-maintenance-release-what-you-need-to-know

Scan This: There’s Danger in QR Codes

QR codes have become embedded in daily life for many adults. Their spread was highlighted on Super Bowl Sunday, when a bouncing QR code on a brightly colored field occupied 30 seconds of very expensive air time. Capturing that particular QR code led viewers to information on cryptocurrency. Codes that have popped up on restaurant tables across the country lead to menus and apps for paying meal charges. Other codes could lead to much less benign destinations. 

The same qualities that make QR codes so valuable make them a legitimate threat to enterprise (and personal) cybersecurity. A type of bar code introduced in 1994 by automotive supplier Denso Wave, QR codes were first used to track components and subassemblies through an automobile assembly process. There are now 40 versions of the QR code, each carrying a different amount of information. Depending on the error correction employed, QR code capacity can range from 72 to 16,568 bits — more than enough to carry significant information about a part, or a malicious instruction for your mobile device or enterprise network.

And the opportunities to deliver those malicious instructions exploded shortly after the beginning of the pandemic when countless restaurants, eager to avoid the appearance of delivering viruses along with menus, moved customers to a menu viewed on their mobile phones. How did those menus get to the customers’ mobile phones? Through a scanned QR code. Convenient, hygienic, and ubiquitous, QR codes have revolutionized menu delivery and customer feedback. They have also revolutionized delivery methods for malware and social engineering attacks.

Take a Closer Look
The problem isn’t really with the capability of QR codes — those capabilities make the codes very useful for any number of legitimate business and consumer purposes. The problem is that so many people have stopped thinking about the codes that they scan. How many times have you seen people walk into a restaurant and scan the QR code from a sticker attached to the table, often scanning the code before they’re fully settled in their seats? That kind of reflexive scanning is the human component of the vulnerability that the code introduces to the enterprise.

So, what is an enterprise security staff to do about it? Given the square code’s ubiquity, a blanket prohibition on scanning is unlikely to work. The best approach, as in so many things cyber, is solid education on the threat and best practices for minimizing its impact.

The first thing employees must learn is that scanning a QR code should never be automatic. Want to see a menu on your smartphone? Great — ask the server to bring you a sheet with the QR code printed on it. Want to leave a review? Great — scan the code on the bottom of your receipt. QR codes on random stickers stuck to tables and doors should be treated with suspicion since they’re in far too public a set of locations to trust.

Next up is learning to consider context when scanning a QR code. On an official sign with a logo in your bank’s lobby? Perhaps. On a crooked sticker at the front of a gas pump? Hard no. Treating QR codes as you would any other bit of electronic kit is important because that’s exactly what they are: mechanisms for carrying and delivering code to a device. Just because they’re made of ink and paper rather than silicon and gallium arsenide doesn’t mean they’re any less effective — or dangerous.

Consider Training
The potential danger of QR codes is actually a good excuse to introduce training about dangers beyond the obvious phishing email message and dodgy website. Criminals and threat actors are eager to take advantage of actions taken without thought — times when employees are on “auto pilot” regarding their actions. Train employees to stop and think about codes, images, and stickers before they launch the attached URL and you may well cut down on the number of malware packages that come attached to orders for gooey cookies.

Source: https://www.darkreading.com/omdia/scan-this-there-s-danger-in-qr-codes

Ukrainian Website Threat Landscape Throughout 2022

The Russian invasion of Ukraine began on February 20, 2022. By mid-March it was clear the cyber-war had begun, and the attacks have been consistent ever since. Prior to this, on March 1, 2022, Wordfence reported on an attack campaign on Ukrainian university websites. In response, we deployed our real-time threat intelligence to all sites running Wordfence with a .ua top-level domain (TLD). In the following months, we have continued to monitor the situation, and to block attack attempts aimed at Ukrainian websites.

Based on the data we have tracked, it has become clear that most of the attacks being levied against Ukrainian entities since the initial campaign are fairly routine, though regularly increasing in quantity. While there are some more sophisticated attacks, the vast majority of what we are seeing is routine spam content and defacements. These types of attacks are often perpetrated by lesser-skilled actors probing for easily exploitable random web targets with simple scripts. What we are seeing does not indicate the highly skilled and coordinated attacks that would be seen from larger criminal organizations or nation-state attackers.

Today’s post will focus on the quantitative threat landscape targeting Ukrainian websites that we’ve monitored in 2022, while next week we will follow-up with an article diving deeper into the attack data and exploits we are seeing targeting Ukrainian domains.

Broader Attacks Increasing in Volume

As we approach the six-month mark since the initial invasion, the cyber-front remains a volatile but constant battleground. Just after the invasion officially began, there was a spike in attacks against Ukrainian websites, then things were quiet for almost a week. At that point, on March 3, 2022, a barrage of attack attempts were brought against Ukrainian websites, with these attacks not only continuing, but generally increasing as the war continued. At first, the attack attempts were close to normal levels, but quickly increased to more than 50,000 attempts per day.

In the six months leading up to February 20, 2022 there were an average of just over 52,480 attack attempts against .ua websites blocked by the Wordfence firewall per day. The average during the conflict has increased almost 50% to nearly 75,000 attack attempts blocked per day, excluding any exploits coming from blocklisted IP Addresses.

blocked attacks by date

The largest spike we have seen at this point began on June 24th, and subsided on the 28th. During this spike, we blocked 1,875,045 total attack attempts. In this time, most of the attack attempts were coming from known malicious IP addresses, with a substantial number of the attempts being brute force attacks. Directory traversal, file uploads, and information disclosure rounded out the most common attack types. There are no indicators in our data that these attacks were connected, meaning it is likely that this was not a large attacking organization, but rather a concerted effort from many smaller groups and individuals.

Wordfence deployed its real-time threat intelligence, which includes an IP Blocklist, to all .ua domains on March 1, 2022. The IP blocklist is updated in real-time to block the latest active known threats and is very effective at doing so. It provides a drastic increase in protection on any sites running the Wordfence firewall due to the simple fact that an IP that targets several sites will end up on the blocklist before they can target many more. As such, we excluded this data from our attack data trends to demonstrate the general threat landscape, without the added benefit of Wordfence real-time Threat Intelligence, a feature of Wordfence PremiumWordfence Care, and Wordfence Response, to be comparative with the attack data we saw before we made that deployment. Astonishingly, once we added the real-time IP blocklist attack data to our analysis, the percentage of attacks the Wordfence firewall blocked on all .ua domains jumped nearly 450% demonstrating the effectiveness of deploying our real-time Threat Intelligence to those domains.

Attack types in June spike

The spike at the beginning of the invasion largely consisted of attacks against Ukrainian educational institutions as part of a defacement campaign. While these institutions have continued to experience attack attempts, they have not been as directly targeted since the initial attack on Universities in February. At the same time, the rate of attacks brought against educational institutions has remained higher than pre-invasion levels, with (comparatively small) spikes primarily in March, April, and July. The trend continues upward, with the average number of daily attack attempts per day nearing the 100,000 mark. Since the invasion began, we have logged 46,698,709 attack attempts against .ua domains. Of those attempts, 2,903,923 were against .edu.ua domains, and 1,903,806 were against .gov.ua domains.

Ukrainian universities attack rates

A Shift In The Threat Landscape

When we first wrote about the attack on Ukrainian universities, there was one IP address, 185.193.127.179, that stood out as the primary attacking IP. The IP address was registered through Njalla, a hosting company that is run by the co-founder of Pirate Bay. After the initial attack against the universities subsided, there is no indication that this IP address has been reused in further attacks against Ukraine.

The top attacking IP currently is 62.233.50.223, which is assigned to Chang Way Technologies. The company is based in Hong Kong, but the IP address is assigned to a server located in Russia and registered to the Russian organization Sierra LLC. The IP block this address is a part of was registered to Sierra LLC on October 13, 2021. In contrast to the 104,098 attack attempts in a single day by the Njalla IP address that attacked universities in February, the Sierra LLC. IP address is only responsible for 205,223 attack attempts in 30 days, and those attempts were not targeted against a specific type of potential victim.

Despite the fact that this IP address does not appear to be targeting victims in any particular industry, the attacks coming from this address are relatively consistent. The majority of what we are seeing from this IP address is SQL injection attacks, sending a GET request to the site with the payload in a URL encoded string, as seen here.

SQL injection payload

With this string decoded, it begins to look more like a normal SQL query, though portions are using character encoding which we see here as CHR encoded strings.

character encoding

When we convert this and combine the string as is the purpose of the || operator, we end with this final payload string.

SQL injection decoded

This is essentially using the SQL CASE statement to iterate through options to determine if specific content exists within the database, and uses the CAST statement to convert content to a specific data type. As with many attacks, this does not mean that a SQL injection vulnerability is present, or that the desired content is in the database. This is the malicious actor fishing for information, and hoping they get something in return.

Similar to the lack of focus we are seeing with the types of attacks, there does not appear to be any primary attacker in recent attempts. While the top nine attacking IP addresses are responsible for more than 50,000 attack attempts each, there is a long tail of IP addresses responsible for just under 50,000 attacks each and slowly working down to sub-100 volumes. This is a fairly typical pattern in attack data, rather than having one attacking organization stand out above the others.

Top attacking IPs

Conclusion

In this post, we reviewed the data collected from attack attempts against Ukrainian domains with a .ua TLD since the beginning of the Russian invasion of Ukraine on February 20, 2022. The initial attacks we saw were very targeted around educational institutions, however the attacks we have been blocking since the initial campaign have been much more varied. Attack attempts are coming from a variety of malicious actors, in varying locations. The volume of attack attempts has remained high compared to pre-invasion levels, but with our continued protection these attempts are blocked, preventing damage to Ukrainian websites.

If you want to know more about the types of attacks we are blocking on Ukrainian websites, keep an eye on the Wordfence blog. A post next week will discuss these attacks, the vulnerabilities they are attempting to exploit, and how malicious actors can use them to damage an affected website.

Wordfence deployed Real-Time Threat Intelligence, an exclusive feature of Wordfence Premium, Wordfence Care, and Wordfence Response, to all .ua domain names regardless of their product tier. This means that all .ua domains, including those running Wordfence Free, have the latest protection against the newest threats, including vulnerabilities, IP addresses, and malware.

Source: https://www.wordfence.com/blog/2022/08/ukrainian-website-threat-landscape-throughout-2022

Cross-Site Request Forgery Vulnerability Patched in Ecwid Ecommerce Shopping Cart Plugin

On June 24, 2022, the Wordfence Threat Intelligence team initiated the responsible disclosure process for a Cross-Site Request Forgery vulnerability we discovered in Ecwid Ecommerce Shopping Cart, a WordPress plugin installed on over 30,000 sites. This vulnerability made it possible for attackers to modify some of the plugin’s more advanced settings via a forged request.

We attempted to reach out to the developer on June, 24, 2022 via their ticketing system. After several plugin updates did not address the issue and we received no response from the developer, we disclosed this vulnerability to the plugins team on July 11, 2022. The vulnerabilities were fixed a few days later in version 6.10.24 on July 13, 2022.

Due to the nature of Cross-Site Request Forgery vulnerabilities, which involve tricking administrators into performing actions they are allowed to perform, it is not possible to provide adequate protection for these vulnerabilities without blocking legitimate requests. As such, we highly recommend updating to version 6.10.24 or higher of Ecwid Ecommerce Shopping Cart to ensure that your site is protected against any exploits targeting this vulnerability.

Source and more details: https://www.wordfence.com/blog/2022/08/cross-site-request-forgery-vulnerability-patched-in-ecwid-ecommerce-shopping-cart-plugin