[Learning] Inside Different Generations of WebShells (Part 2: CGI WebShells)
Last Update:
Word Count:
Read Time:
Introduction
This article is part of the Inside Different Generations of WebShells series.
In the previous article, Inside Different Generations of WebShells (Part 1: Understanding WebShells), I introduced the concept and design philosophy of OneShells.
In this article, I will discuss how CGI webshells can be implemented using Perl and Ruby. These techniques can be applied when targeting Microsoft IIS servers as well as embedded devices that expose CGI-based web interfaces.
What Is CGI?
CGI stands for Common Gateway Interface. It is a standard that allows a web server to execute external programs or scripts in response to an HTTP request. Instead of serving only static files, a CGI-enabled web server can run applications written in languages such as Perl, Ruby, C, or shell scripts to process user input, interact with databases or hardware, and generate dynamic web content.
Applications of CGI
On a Microsoft Internet Information Services (IIS) server, CGI enables IIS to launch external executables or scripts to handle web requests.
Although CGI is considered a legacy technology in many modern enterprise environments, it is still widely used in embedded systems and network-connected devices. Many routers, industrial controllers, NAS devices, IP cameras, printers, and IoT products still rely on CGI programs to implement their web management interfaces.
CGI OneShells
As I mentioned in the previous article, the essential philosophy of OneShells is arbitrary code execution. Once arbitrary code execution is achieved, the entire server can be compromised.
Fortunately (or unfortunately), both Perl and Ruby provide the powerful eval() function.
Perl OneShells
Nowadays, Perl is far less popular than Python. In addition, Perl also predates Python by several years. (Many security researchers probably have not written Perl code since analyzing the leaked NSA toolset.)
In a CGI environment, a Perl script generates the response, beginning with HTTP headers (such as Content-Type) followed by the response body (HTML, JSON, plain text, or another supported format).
In other words, Content-Type has to be printed first.
1 | |
After reading the Perl CGI documentation (PerlDoc), implementing an HTTP POST handler is actually straightforward:
1 | |
HTTP POST request:
1 | |
Using the same approach, a Perl OneShell can be implemented as follows:
1 | |
The POST data below demonstrates how this webshell can be exploited:
1 | |
Of course, if we want to minimize the OneShell even further, we can remove the print "Content-Type: text/html\n\n";, but you have to append it at the beginning of the payload. Otherwise, the server returns an HTTP 500 response.
1 | |
1 | |
Note: Alien v5.0.0 currently adopts this approach. However, I plan to make the implementation more customizable in future versions.
At this point, the simplest Perl OneShell can be implemented as follows:
1 | |
Ruby OneShells
Like Perl, Ruby is not as popular as Python. Most security researchers are probably familiar with Ruby because Metasploit is primarily written in Ruby. (If you have worked in penetration testing, chances are that you have already used it.)
In a CGI environment, Ruby scripts work similarly to Perl scripts, beginning with HTTP headers (such as Content-Type) followed by the response body:
1 | |
However, the HTTP POST handler is slightly more complicated than Perl. It seems that Ruby’s CGI library does not provide an interface as convenient as Perl or PHP.
After some experimentation, I discovered an approach for better compatibility:
1 | |
Eventually, a Ruby OneShell can be implemented as follows:
1 | |
Note: Alien v5.0.0 currently adopts this implementation. By introducing the global
$_POSTvariable, the development experience becomes very similar to PHP. However, I still plan to make this behavior configurable in future versions.
Conclusion
Although Perl and Ruby are very different languages from PHP or ASP.NET, the overall design philosophy remains unchanged. As long as arbitrary code execution can be achieved, the webshell becomes merely a lightweight execution layer, while the actual functionality can be implemented entirely by Alien.
So far, this series has covered OneShell implementations in PHP, ASP, ASP.NET, Perl and Ruby.
Although CGI webshells are no longer common in modern enterprise environments, they are still highly relevant when targeting embedded systems, network appliances, and legacy web applications.
One of the primary goals of Alien is to provide a unified management framework across as many web technologies as possible. Therefore, supporting CGI-based languages such as Perl and Ruby remains worthwhile.
In the next article, I will introduce the design philosophy behind NebulaPulsar, discuss how it integrates with Alien, and explain the engineering challenges involved. Finally, I will introduce Event Horizon, the component responsible for obfuscating HTTP traffic generated by OneShells.
If you have any comments or suggestions, please feel free to leave them below!
THANKS FOR READING