Asp Server Exploit

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

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.

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

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

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

Quote:

---

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.

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

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)

Quote:

---

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.

Quote:

---

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

Quote:

---

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)

---

That makes perfect sence. What about just replacing a file on their harddrive with another one. Such as spools.exe with a trojan? Or editing a batch file already on the computer?

Again bad permissions, the user should not have write ability to anything outside of their home dir. Replacing spools.exe (which my system doesn't even have, winspool.exe is the closest and only admins/system have the ability to replace it... even sever operators don't, not only that IUSR/IWAM are denied full) would require some serious problems with the system.

I wonder, do you even have NTFS on your test system? It really doesn't seem like it.

Please just stop, I and I suspect anyone else in the knows respect you less and less with each passing post.

catch

Quote:

---

Again bad permissions, the user should not have write ability to anything outside of their home dir

---

And again it is not "bad permissions". I would like for you to explain to me how you think a web site works. You cannot set read permissions on all folders even though you might think so. Iin this "exploit" you are viewing the ROOTDIRs of peoples webpages. And a read permission on one of those folders will result in the inability to view that web page. There would be no point in trying to fix this "exploit" by changing the "bad permissions" for you will be doing more harm then the "exploit" it self.

*grumble*
*deleted a rude, unproductive comment*

\webroot (this funnels all access through IUSR_systemname)
\webroot\bill (this funnels all anon access through IUSR_bill)
\webroot\sally (this funnels all anon acces through IUSR_sally)
etc

Now from here you have two choices, choice 1 is to create a normal account for these as well now web_bill, web_sally that have write perms and read and write perms over their respective directories. Their IUSR accounts only have read/exe perms over their respective directories. Or if you want fewer users you create a single trusted application interface that manages an admin account to write in all the user dirs. This solution is bad for obvious reasons. You are better of going with dual accounts or using a trsuted application environment like pitbull which will allow IUSR_bill to have write perms over bill's dir as well, but will not allow the IIS process to propigate these rights, so you would need to access via something else (telnet, alternate instance of IIS etc.)

Understand?

catch

Ok.....this thread is going to retardville in a hurry.

There is no exploit other than your poor solution. You are using the file system objects which are a com library put there for dealing with directories, files, etc. They give access to everything on the drive because of the account you're using to run the scripts. If you want to do a custom solution for writing pages to your server then for god's sake write your own file access component that uses com+, the proper group/account based security, and a real authentication method.

As I said before...the problem is pebcak.