Last week, Harsh Jaiswal and Rahul Maini from ProjectDiscovery released some impressive security research on multiple vulnerabilities in Lucee (and Mura CMS and Masa CMS). Their blog post is a must-read, and I'm not going to rehash their steps from research to discovery to exploitation. Instead, I'm going to look at these vulnerabilities through a defensive lens.
I will say upfront -- I prefer offense over defense. When staring at a screen, I'd rather be breaking software than building software. But defense is an important component of any overall security plan and sometimes I have to think defensively and break exploits instead of breaking applications. Patching and keeping software up-to-date is always recommended, but there are also often proactive choices and configurations that can protect potentially-vulnerable components and prevent successful exploitation. Stringent access control rules, egress network filtering, and endpoint detection tools can often help to minimize impact and turn the exploitable into the unexploitable.
I. CVE-2023-38693 - This is a Java deserialization vulnerability in Lucee's REST mappings that can lead to remote code execution. It was fixed by the Lucee team in August 2023.
Some thoughts on defensive recommendations - If you have any Lucee REST mappings, you'll want to ensure that you're running on a patched version of Lucee. (And if you do not have any REST mappings, you should not be vulnerable to exploitation.) Some web application firewalls may also include rules that that detect Java deserialization payloads.
II. The CFMLExpressionInterpreter class and Client Cookies - The second vulnerability involves a vulnerable codepath in which the contents of Client Cookies (with a CF_CLIENT_YOURAPPNAME name) will be evaluated as CFML code, which can be triggered on pages that call functions including sessionInvalidate() and sessionRotate().
Some thoughts on defensive recommendations - Ideally, ensure that Client Management is disabled in Lucee Admin and Client Storage is set to "Memory". If you need you need these settings configured differently, ensure that you're running a patched version of Lucee (which I believe is Lucee 6.0.1.59 or later).
Proof-of-concept exploit code for this vulnerability is available in a Nuclei template, which could also be used to come up with detection and prevention rules, such as in a WAF. While the exploit could certainly be modified to bypass some of these specific detection rules, WAF rules could look for things such as a cookie name starting with CF_CLIENT or cookie values that contain a render() call or <cfscript> tags.
III. Evaluation of CFML Code in Tags and Functions - The third vulnerability pertains to how three Lucee CFML functions -- specifically empty(), isDefined(), and structGet() -- will evaluate CFML code passed as arguments.
Now while it may be new or surprising information that these specific functions are vulnerable, it is already well-documented that functions such as evaluate() , iif() and maybe a few others are vulnerable sinks that can lead to remote code execution if they process user-controlled data.
Multiple versions of Masa CMS and Mura CMS include vulnerable instances of isDefined() calls, which can be exploited on Lucee by an unauthenticated attacker. This is a critical vulnerability, and if you're running Masa CMS or Mura CMS on Lucee, you'll want to ensure that you're running a patched version or otherwise protected.
Some thoughts on defensive recommendations - Unvalidated user input is the root cause of many classes of application security vulnerabilities, and these examples are no exception. Avoid passing unvalidated, user-controlled input into these functions -- and add them to your list of "dangerous" functions during code reviews, CI/CD guardrails, and other security controls. Use structKeyExists() instead of isDefined() where possible.
This has been fixed in Lucee 5.4.5.8 and 6.0.1.59, and which added a lucee.security.limitEvaluation environment variable to limit the evaluation of variables in certain tags and functions. Later versions of Lucee 6.x include a Lucee Admin setting to "Limit variable evaluation in functions/tags", which you should enable if you can. Note that this will disable variable evaluation in these functions -- which some applications (such as Mura CMS and Masa CMS) -- may be intentionally using.
And if you're running Masa CMS or Mura CMS on Lucee, you'll want to upgraded to a patched version. This vulnerability was patched in Masa CMS 7.4.5 / 7.3.12 / 7.2.7 and (I believe) Mura CMS 10.0.687.
In closing - patching and keeping everything up-to-date is an important part to staying secure. But if there are ever reasons that you can't immediately patch or upgrade, you can often buy yourself a little extra time and protect against the inevitable automated attacks by understanding the root causes of the vulnerabilities, how to the exploits work, and where compensating controls for detection and prevention can be added. And a big thanks to Harsh and Rahul for responsibly disclosing these bugs, to Pete Freitag for some further vulnerability analysis reflected in this post, and to the Lucee team for fixing them quickly.
[ NB: Adobe ColdFusion is not affected by these vulnerabilities. ]
No comments:
Post a Comment