<- All Blogs
Vulnerabilities

When Less Isn't More: A Deep Dive into Exploiting the Less.js RCE

Written by
Evander Pierre
Published on
July 15, 2021

A remote code execution (RCE) vulnerability was discovered in multiple applications using the Less.js CSS preprocessor. When a service transpiles (compiles from one language to another) user-controlled Less.js files to CSS files, it is possible to achieve remote code execution by using Less.js plugins. This vulnerability affected CodePen, allowing researchers to leak AWS credentials and execute arbitrary code inside their Lambdas.

What are CSS preprocessors?

CSS preprocessors aim to simplify the creation of CSS files by using plugins and directives that are executed to generate the final CSS files. They are typically used by developers or build servers to generate the final CSS files for web applications. However, some sites and services take user-generated CSS preprocessor files and transpile them server-side to create and render CSS.

Less.js is one of the most popular CSS preprocessors, with over 14 million downloads per month and 1.4 million dependent repositories on GitHub. It is a superset of CSS that provides many more features to assist with writing CSS, such as custom variables, mixins, nesting, functions, and scoping.

The vulnerability

As part of its extended functionality, Less.js allows users to define custom directives through plugins and imports. While these features can be powerful tools for development, they can also bring a security risk when exposed to users. The impact of this can range from arbitrary file read and SSRF through the use of the import directive, all the way to full RCE on the server transpiling the Less.js code by using custom remote JavaScript plugins.

Screenshot showing remote code execution on a web application by submitting malicious CSS.

This isn’t the first time Less.js has had issues with remote code execution. Previously, commands could be executed via the use of backticks; however, these were removed in version 3 as it was trivial for attackers to abuse them.

In addition, due to the open-source nature of Github as a platform and its dependency graph, it is easy to identify other tools and products that may be vulnerable to this kind of exploitation.

Real-world example

CodePen is a popular website used to create code snippets in HTML, CSS and JavaScript, with over 330,000 registered accounts and 14 million monthly users. As part of its CSS functionality, CodePen supports the use of CSS preprocessors, including Less.js. The user provides Less.js code which is then transpiled by the server to raw CSS.

Screenshot showing an example Less.js CSS running on CodePen.

This vulnerability was caused by CodePen transpiling user-defined Less.js code server-side, which allowed for plugins to be defined with custom JavaScript. When these Less.js files were transpiled server-side to CSS, the plugins ran within a Node.js environment, and arbitrary commands could be executed on the server.

As a result of this vulnerability, the researchers could leak the AWS secret keys used by CodePen and run arbitrary commands inside their Lambdas. This could have resulted in further compromise or an attacker using large amounts of resources at CodePen’s expense.

It’s a feature, not a bug

As frustrating as it can be, some vulnerabilities are caused by features rather than bugs and, as such, are unlikely to be fixed. At the time of writing this, there is no way to disable remote plugins when using Less.js. This means that the security of an application using Less.js is dependent on the specific use case.

Mitigations

Where user-controlled CSS preprocessor files are used, they should first be sanitized to remove any unexpected plugins using an ‘allow-listing’ technique. You should also test these lists and any associated plugins and code to ensure that the filtering or sanitization in place cannot be bypassed.

So what now?

The vulnerability was quickly patched by CodePen following responsible disclosure. Even so, there are likely many more instances where Less.js is being used in a vulnerable configuration.

We’ve published two new labs to help you get to grips with this vulnerability. In our Less.js RCE offensive lab, try your hand at writing malicious CSS code to exploit a target web server. If you prefer the defensive side of things, have a go at the first lab in our new Real-world playground series and secure a web application that uses the Less.js preprocessor.

Log in to your Immersive Labs account to try these labs or book a demo for a tour of our platform today.

Mat Rollings
Senior Application Security Engineer
Immersive Labs
@stealthcopter

Will Roberts
Junior Application Security Engineer
Immersive Labs
@rushisec

Share this post