Back
Adding PowerShell to Web Shells to get Database Access
File upload vulnerabilities and web shells are not a novelty when talking about web application security. It’s not rare to see a web shell result in a full compromise of the web server. For example, Metasploit can generate uploadable web payloads that can initiate Metasploit shells. It’s also not that rare that the same web server hosts multiple web applications, all with their own back-end database connectivity.
I thought it would be nice to know how much data we can gain access to by simply uploading a web shell to a web server if we decided to take a step back and chose not to completely compromise it. This really becomes more practical when you’re testing an application in a QA environment and you want to show the client that access to a random QA application may grant you direct access to databases used by other applications, even critical production databases.
To simplify the process I rewrote an existing .aspx web shell and included PowerShell functionality to allow for database connectivity to create a new CmdSql.aspx web shell. Keep in mind that the shell only works on IIS servers that allow .aspx execution, PowerShell has to be available on the web server, and the current PowerShell code only allows connectivity to MSSQL servers. Not perfect, but nice enough for me.
It’s worth noting that the CmdSql shell can help in escalating an attack in tightly configured environments. If ingress and egress filtering are properly configured, normal Metasploit bind or reverse shells may not work. And if ingress filtering from the web server limits traffic to database communication, attacking databases may provide the means to escalate the attack into the internal network.
CmdSQL.aspx Script Overiew
The CmdSql.aspx web shell supports three different functions: OS command execution, web.config parsing, and SQL query execution. Below is an overview of the functionality and a basic screen shot.
OS Command Execution
This is really the core definition of a web shell I guess. Apart from the obvious, the command execution can be used to locate the web directories (such as C:inetpub) and thus make locating web.configs faster for the next step. Below is a basic example screen shot.
Web.config Parsing
For the sake of CmdSql.aspx, the main function of web.config is to store the database connection strings. There can be multiple connection strings for an application, and there can be multiple web.configs per server. The connection strings can be either clear text or they can be encrypted. Nevertheless, they are needed for arbitrary SQL query execution.
CmdSql.aspx looks for all web.config files in the provided directory and extracts all the connection strings. If the connection string is encrypted, aspnet_regiis is first used to decrypt the configuration file (in a temp folder). Aspnet_regiis is a .NET tool that is typically used to encrypt web.configs; CmdSql attempts to find to newest version of the tools to decrypt the web.config. No key or any other decryption information has to be provided to aspnet_regiis, just the file location. I haven’t done comprehensive testing / research to determine what permissions are needed to run the program, but it seems to always work on my test systems. I decided to use aspnet_regiis even though WebAdminstration snapin could probably be used and it would be “cleaner”; I just wasn’t sure if it’s installed with IIS by default or if it’s otherwise common. Below is a basic example screenshot.
SQL Query Execution
Now that web.configs are successfully parsed (hopefully), and the connection strings are extracted, they can be popped into a text box in the web shell and arbitrary SQL queries can be executed on targeted database server. Below is a basic screen shot example.
The Code
Feel free to download the CmdSql.aspx web shell and give it a shot.
