Last Sunday Adobe issued an extremely highly rated CVE under CVE-2022-24086 with a rating of 9.8/10 for their “Adobe Commerce” platform. The vulnerability allows anyone to execute arbitrary code execution, without any prior credentials or admin powers! The weakness found was based off input validation which is a relatively common weakness. If you’ve ever heard of SQL injection attacks, both attacks use the same general method to get code somewhere it shouldn’t be.
For quick reference, Adobe Commerce is a web platform for selling products & working through the back-end logistics. For example, an online store could use it to host their website while keeping their Amazon page up-to-date, as well as handle shipping providers. This makes it customer-facing, causing a vulnerability like this one to be even worse, since you can’t just wall it off as some internal-only application.
Thankfully, by looking into the source code of the vulnerability patch, we can get a glimmer of how this specific attack works:
$pattern = '/{{.*?}}/';
do {
$result = preg_replace($pattern, '', (string)$result);
} while (preg_match($pattern, $result));
This newly added snippet of code uses regular expressions (Regex) to look for a particular pattern in an incoming string, and remove all occurrences. The pattern is two set of curly braces, one within another, with any amount of characters (including none) between them. This specific formatting is used in YAML to embed code.
This is entirely speculation, but my guess at the mechanics behind this attack would be sending YAML queries to the Adobe Commerce backend with a carefully crafted bit of code within a set of {{}} that the backend accidentally then executed to do some further unknown function.
Unfortunately the specific attack details are still scarce due to Adobe waiting for their customers to patch before releasing how the vulnerability is acted upon. The vulnerability effects all versions up to two minor versions ago (current: 2.4.5, < 2.4.4 effected). Adobe also stated they’ve gotten reports of this vulnerability being exploited “in the wild” and have stated that there are “very limited attacks” on customers using Adobe Commerce, but gave no hard numbers.
Input Validation & RCE
How do you tell a computer what is code, and what is data? If we were trying to encode the string “print(“Hello, World!”)”, how does Python know whether or not to execute the print() function within the string? If you call print() on that string, then what happens?
A very important part of writing programs is input validation. Things as simple as checking whether a string can get parsed into a number, to complex error & RCE checking. There are other forms of input validation (such as checking for concurrent sessions for the same user) to be aware of as well. For string-based input validation, it is recommended to look for specific code-related characters & remove them from the input to ensure the string won’t get mis-read as code:
- Comment tags such as // or /* */
- Semicolons ;
- String delimiters such as ‘ or “
- Newline and null characters: \n and \0
- Braces and Bracket pairs such as <>, {} and []
When an input is mis-read as code, it allows attackers to run effectively anything they want in the worst case as shown in this CVE. It can also result in crashing or causing incorrect behaviour in a system, which I’ve seen firsthand at an internship last summer.
Examples of Similar Exploits
The classic example of improper input validation comes from XKCD:
Another recent example has been the RCE exploit in Dark Souls 3, where the game’s multiplayer has been temporarily disabled to fix the problem. Another blog post has already covered this, here:
Links:
- Adobe page regarding the CVE: https://helpx.adobe.com/security/products/magento/apsb22-12.html
- ZDNet Article regarding the CVE: https://www.zdnet.com/article/patch-now-adobe-releases-emergency-fix-for-exploited-commerce-magento-zero-day/
- Sansec Article Regarding the CVE: https://sansec.io/research/magento-2-cve-2022-24086
- Defeating Input Validation: https://www.secjuice.com/bypass-strict-input-validation-with-remove-suffix-and-prefix-pattern/
That’s a really interesting, I have heard in the past about this type of exploit but I had never looked much into possible ways to counteract them and prevent the arbitrary code from being executed. I think that sample of Adobe’s patch you included in your post really helped me to understand how you could go about solving this issue. This being a service used by hundreds of thousands of users, it’s good that Adobe found a solution before any real and serious damage could be done.
Great post, reminding the fundamental security tips that should not be ignored at all regardless of the technology being used while developing a software product. Attackers always find out the easy hole of a system to get into. When it comes to security practices, all the practices should be followed thoroughly. Following 80% of the security measures and not following security measures are both the same as attackers just need one single weak point of a system. While the input validation is an old phenomena, the content is still important and very relevant to ensuring security.
This is an interesting issue! Can you explain to me what a CVE is? And what are the consequences of this one? What can happen when “anyone can execute arbitrary code execution”? Do you know what are the potential consequences of this CVE in particular?
Good Post, it is interesting to see that a basic and introductory concept like input validation can lead to such a widespread and potentially damaging vulnerability. I remember being taught about basic string input validation in first-year CPSC courses, it was a basic concept, yet implementing it was an easy step to miss. Another commenter pointed out that this vulnerability was found in software that is used by hundreds of thousands of users. The fact that an exploitation of such a fundamental concept could lead to a potentially massive and costly security breach is rather humorous, but it also reinforces that current fundamental coding principles are just that: fundamental, that their implementation should not be taken lightly.
Really interesting topic ! And the way you presented the topic made it easy for me to follow the information stated in this blog .
Great JoB!