Printable View
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?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)
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
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.Quote:
Again bad permissions, the user should not have write ability to anything outside of their home dir
*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.