Fairly new pentester here, having issues executing a metasploit payload uploaded by the IIS guest account. All payloads seem to fail, or do not have adequate permissions to execute.

Background on target:IIS 6 running on Win2kSP2 with ASP. The IIS guest account has read/write/execute. I can upload a file through a vulnerability I discovered, however I cannot execute. If for example I upload and ASP shell, I receive an error saying access denied on line etc (which is at the end of the payload). I have verified ASP scripts can run by uploading something simple like document.write("hello"). Maybe I can use a different payload?

Any ideas here or suggested reading you can point me to?

Last edited by Bluecifer on Wed Dec 05, 2012 12:24 am, edited 1 time in total.

Thank you for the reply. I am able to upload via writing a small perl script. The application fails to validate the location of the configuration file, and an attacker can specify an extra "\" and the server will read the config file via smb or webdav. The configuration file specifies the location of the logfile. For example:

Once uploaded though I cannot take advantage of exec() or system() with perl, (you can run logfile script multiple times) as the IIS account appears to not have the proper permissions to execute cmd.exe. When I tested in a lab environment, and changed permissions of cmd.exe to 'everyone', I was able to get a shell. This also appears to be the same problem with the metasploit payloads as well (cmd.exe).

I guess what I am asking is what do you do when pentesting an app running on IIS since it uses the guest account? Maybe I need some other creativity (look for other files containing passwords, etc). Any ideas? Just looking for other opinions or ideas.

Thanks!

Last edited by Bluecifer on Wed Dec 05, 2012 1:18 am, edited 1 time in total.

I'm really not familiar with running Perl on IIS. I'd setup a test system locally in a VM and see what you can work out there. That's usually a better plan than trial-and-error on a remote system. That'll allow you to see the log files, event logs, etc. and determine where the problem lies.

However, the restricted guest account should be able to run commands, especially as far back as Win2k. There may be Perl configuration settings that prevent this, but that account can certainly get a shell; I've done so numerous times via ASP. You're not going to be able to perform privileged operations (i.e. adding users), but that's not going to prevent you from running general commands.

Thanks again for the reply. I hit the 'Googles' and was able to find an interesting article giving an example of uploading your own "cmd.exe" to overcome the issue I was having. Rewrote the ASP script to point to my cmd.exe and was able to get "network service" level privileges.