Working Remotely – Not the Good Kind

No, this is not a blog about remote working, working from home, or telecommuting. This is not a blog that will discuss the work/life balance benefits of working from home, though there are many, and this will not talk about how building out our internet infrastructure benefits businesses and employees. No. This blog is about lines of code working remotely to cause problems in web applications and servers. The latest example of which being the Adobe Magento CVE-2022-24086 vulnerability patched in an out of band, emergency release a bit more than a week ago. As an aside, if you didn’t see it, another vulnerability with the same 9.8 CVSS severity (CVE-2022-24087) was announced last week. 

Remote Code Execution

So just what is remote code execution or RCE? It’s the ability for an attacker to execute code on a remote system or device. When used on a website it can allow visitors to delete or read files and even connect to a database. Remote code execution may begin by an attacker entering information into a field, let’s say, during user registration/sign-up on a website.

If you wanted to keep a userID stored along with the IP address of the user during registration, it may look something like this:

eval(“\$$userid = ‘$ipaddr’);

Now since the visitor to your site can create their own user ID an attacker could use this opportunity to create a name that will allow exploitation of the eval string above. The user ID, for instance, may look like this:

x = ‘y’;phpinfo();//

Now, in our stored code we have:

eval($x = ‘y’;phpinfo();// = ‘128.0.0.1’);

If this user ID is accepted by the webapp, it will allow an attacker to run commands while commenting out the ‘$ipaddr’ value. This will allow the attacker to see the output of phpinfo on the page. The use of php here is just an example and RCE is and can be used with other programming languages as well.

Input Validation

Most consumers are familiar with the concept of input validation even if they don’t know specifically what it does. The process of validating that an input into a field matches the desired pattern or format is very common during account registrations and checkout pages. Input validation is used innocently to make sure passwords meet certain criteria, dates are formatted correctly, coupon codes are valid, or payment cards have the correct number of characters.

Again, the most recent (as of Feb 2022) RCE news to make headlines was around Adobe’s Magento platform. Specifically Magento 2.4.3-p1 (and earlier) and 2.3.7-p2 (and earlier) versions. This allowed RCE on webapps running these Magento versions; the extent of which we do not know (as of this writing). Patches released by Adobe mention CWE category 20 (CWE-20) and after analyzing the patches for these versions we can see Adobe has added pattern matching to aid input validation (Image 1 below).

With the rise in RCE (log4j, Magento) the responsibility no longer solely falls onto the website developers to validate input; validation must also be done by software developers and web security personnel.

The Inevitable

The use of RCE on Magento platforms leads us to believe that Magecart groups have found another technique to implant skimmers onto websites. Even with software developers and security personnel having the tools readily available to combat RCE and input validation, exploits and vulnerabilities will still be found. These exploits may allow webapp client-side attacks to take place on your site even after patching occurs. 

What do you do, then, when the inevitable skimming attack occurs?

Easy. You use Source Defense.

Watch me WiPP – and say, “Nay, Nay!” to the Adversary

Source Defense offers existing and future customers the ability to block first-party JavaScript from monitoring keystrokes and field inputs. Meaning if input validation has failed and RCE is used to deploy JS based skimming attacks on your website, Source Defense can prevent that action in real time. No need to worry about how quickly a patch is released, what specific platforms or integrations you’re using, or how you’re going to explain to management that you simply don’t know if you’ve been compromised. 

Our Website In-Page Protection (WiPP) module gives full block capabilities to first-party JavaScript running on your site. Simply choose to allow or block JS from reading keystrokes and field inputs with one click. The image below (Image 2 below) shows a first-party script accessing field inputs. An “Allow” and “Block” option is in the upper right of the image. Simply choosing to block this script from reading these inputs means skimming attacks piggybacking onto the selected script will be unsuccessful. Period.

RCE and Input Validation attacks are going to happen, especially as legacy systems, old code, and unpatched software exist in the market today. Source Defense helps protect your website from attacks that originate from RCE and input validation.

So, get back to working remotely knowing the only issue may be your choice to wear pajamas on camera.

The post Working Remotely – Not the Good Kind appeared first on Source Defense.

*** This is a Security Bloggers Network syndicated blog from Blog – Source Defense authored by Randy Paszek. Read the original post at: https://sourcedefense.com/resources/working-remotely-not-the-good-kind/