Asp Server Exploit

[Szafran]

I was recently writting an ASP online file editor so i could edit my site from within its pages and i stumbeled upon the ability to view every file/folder that currently exists on the servers hard-drive includeing other drives on the server. It is quite easy to view the code on any webpage including asp. it is also able to chanbe the file, delete it, download it and create/remove directorys. I would also like to point out that some folders are "Permission Denied" but as for ones that are used for FTP and so fourth give me full read acces and most give me write access. I've tested this on BRINKSTER.COM and it works. I've notified most Servers that allow ASP about this. Is there a way to actuall stop people from doing this????

Ive attached the page i created in hopes that someone can give me an idea if this is fixable or not.

I also posted this incase a viewer might know of any other ASP providing websites and would like to notify them of this. If so i would like to have, at least, my name mentioned to them. - Zach Szafran

[VicC]

I was wondering, when you open up the Management console for IIS and view the properties for this web site, is it set to allow directory viewing and read, write, execute access. If the root of the web site is improperly configured then these settings may propagate through the entire sit (run on sentence).

I'm certainly not an expert but that's the first thing that comes to mind.

[Szafran]

i wouldn't be surprised. I dind't think of that. I work at an ISP and i'll ask there.

[slarty]

There isn't really any way to stop this.

But you have to trust your ASP developers not to write scripts which break system security.

Although it should not generally be possible to write to system directories or files (if your system has appropriate filesystem permissions), an ASP script could easily mess up other users' stuff.

There isn't unfortunately (AFAIK) an ASP equivalent of PHP's safe mode.

However there might be something on ASP.NET which will work (but then you have to allow developers to use *ONLY* ASP.NET)

Slarty

[Juridian]

Erm...

You haven't stumbled on anything new. The biggest problem with this is that you are poorly implementing a solution for your website and opening up a big hole on your own server.

Most people are not going to have a problem with this unless they are silly enough to create an asp page on their server that allows such silly amounts of access to their harddrive.

Pebcak

[Szafran]

The biggest problem with this is that you are poorly implementing a solution for your website and opening up a big hole on your own server.

Actually this is a bigger problem, usually with ASP scripts like this you can only view files in the current DIR. With the one above you can view the entire drive. This is a big problem for sites such as BRINKSTER.COM who support ASP scripts. They allow users to create an ASP bases home page and with a script like this you can access all other accounts/folders/files that are on the server's HD.

[SittingDuck]

That is only the start, it also possible to write an asp page which will send commands to command line. So think carefully before you allow users to upload data to your web site!

SittingDuck

[catch]

This is not an exploit, merely improper permissions. An exploit needs cause a system to work in a manner outside of its design, your script doesn't do that. It acts exactly as it should act, with proper permissions it would no longer work as you have seen it.

The proper way for an ASP hosting site to manage this problem is to either create an anon access account for each user. From here you can either create a log in account for each user as well or you can create a single trusted editing interface that allows users to only modify files in their anon space. Another option is to create a single account for all the web space files and to apply a trusted application envionment like Pitbull Protector to keep each asp script minding its own business, then user accounts may be handled with either integrated NT accounts or a single editing account that runs outside out the trusted environment's grasp and uses it's own authentication scheme to prevent users from altering scripts beyond their own. This second solution is less finely grained as ASP scripts will now need to share common write to areas, so in an ideal world, a hybrid solution would be used.

catch

PS. Could you stop filling this forum with such garbage? Seems like not a day goes by without you posting some exploit that isn't and now you want your name spread around? Why don't you try posting these things on bugtraq/NTbugtraq I am sure they will be more than happy to tell you what is up with these "exploits."

PPS. Almost forgot, sittingduck, cmd.exe should have its ACL set to deny full control from SYSTEM, IUSR_, and IWAM. This will also prevent exploits that launch a system shell from IIS (or anywhere else for that matter)

[Szafran]

merely improper permissions

How could the permissions be improper? If you Deni Read Access then the pages in the folder cann be viewed which defies the purpose of having a website in the first place. To Deni Read access is an impossibility so the function of read the Source Code, and downloading files my "script" that i attached cannot be delt with. As for Write Permssion, there are only a few reason why that should be enabeled. Most likely it won't.

[catch]

How could the permissions be improper? If you Deni Read Access then the pages in the folder cann be viewed which defies the purpose of having a website in the first place. To Deni Read access is an impossibility so the function of read the Source Code, and downloading files my "script" that i attached cannot be delt with. As for Write Permssion, there are only a few reason why that should be enabeled. Most likely it won't.

Did you even read my post? You can either have an anon account for each user on the system (rather than a regular account for each and just use a trusted application to delegate out) This allows you to deny access from that user but allow access to the anon account. Or you can use an extended DBAC style controls with Pitbull to prevent scripts from reading other scripts.

This would force the user to read only via the web interface or as the user in question.

Again, please stop posting these "exploits" not one you have posted has actually been an exploit and the ones that were close are just bad readings of old exploits.

catch