Guest account with write and script execute access - how dangerous

Dear IIS Users:

I would like to know is if the following configuration is secure from
hackers.


Assume that my application is at MyDomain/myPerlApp/cgi-bin/app.pl and that
this is my IIS configuration:

1) Removed anonymous authentication from myPerlApp and enabled Windows
Authentication. This was only done to achieve a layer of privacy to keep
anonymous browsers off my application. Data is not sensitive, therefore a
secure transmission is not required in this case.

2) Using IIS Manager, I enabled 'Windows Authentication' for the myPerlApp
and cgi-bin directories. The cgi-bin directory is set to 'Execute scripts
only'.

3) Created a user account called 'myaccount' and limited this account to
'Guests' group.

4) I assigned 'myaccount' Read access (and nothing else) to
C:\WINDOWS\system32\LogFiles\W3SVC2471873669 which is the directory where my
IIS log files are stored.


At this point, I do not see any security flaws, but please correct me if I
am wrong.


5) If I grant 'myaccount' modify access to MyDomain/myPerlApp/cgi-bin


After step 5, I am thinking that damage can occur if a hacker were to upload
a malicious script to the cgi-bin directory since the settings are 'Execute
scripts only'. Would it somehow be possible to upload a script here due to
the fact that 'myaccount' has modify access to this directory? And even if
an upload did occur, 'myaccount' belongs to the guest group and write
permissions has only been granted to the cgi-bin directory and no other, so
how dangerous could this be?

These are questions that I've had for a while now, any comments would be
greatly appreciated.


Thank you,

Jeff

Re: Guest account with write and script execute access - how dangerous

Question - why does the MyAccount user account even exist?

Cheers
Ken

"Jeff Dunlap" wrote in message
news:5642E624-14C3-4C22-9CD4-2D3518A582A4@microsoft.com...
> Dear IIS Users:
>
> I would like to know is if the following configuration is secure from
> hackers.
>
>
> Assume that my application is at MyDomain/myPerlApp/cgi-bin/app.pl and
> that
> this is my IIS configuration:
>
> 1) Removed anonymous authentication from myPerlApp and enabled Windows
> Authentication. This was only done to achieve a layer of privacy to keep
> anonymous browsers off my application. Data is not sensitive, therefore a
> secure transmission is not required in this case.
>
> 2) Using IIS Manager, I enabled 'Windows Authentication' for the myPerlApp
> and cgi-bin directories. The cgi-bin directory is set to 'Execute scripts
> only'.
>
> 3) Created a user account called 'myaccount' and limited this account to
> 'Guests' group.
>
> 4) I assigned 'myaccount' Read access (and nothing else) to
> C:\WINDOWS\system32\LogFiles\W3SVC2471873669 which is the directory where
> my
> IIS log files are stored.
>
>
> At this point, I do not see any security flaws, but please correct me if I
> am wrong.
>
>
> 5) If I grant 'myaccount' modify access to MyDomain/myPerlApp/cgi-bin
>
>
> After step 5, I am thinking that damage can occur if a hacker were to
> upload
> a malicious script to the cgi-bin directory since the settings are
> 'Execute
> scripts only'. Would it somehow be possible to upload a script here due
> to
> the fact that 'myaccount' has modify access to this directory? And even
> if
> an upload did occur, 'myaccount' belongs to the guest group and write
> permissions has only been granted to the cgi-bin directory and no other,
> so
> how dangerous could this be?
>
> These are questions that I've had for a while now, any comments would be
> greatly appreciated.
>
>
> Thank you,
>
> Jeff
>
>

Re: Guest account with write and script execute access - how dange

Ken,

The reason that I created myaccount was to set Windows authentication to my
application, app.pl. I don't want just anyone off the web accessing app.pl.

I definately did not want to use an existing user account that has more
rights, so I created myaccount and granted the minimum rights mentioned in
the original post. If there is something wrong with what I did, please let
me know.

Best Regards,

Jeff

> Question - why does the MyAccount user account even exist?

Re: Guest account with write and script execute access - how dange

So your users are all using this same account when accessing the CGI
application?

Cheers
Ken

"Jeff Dunlap" wrote in message
news:4EF2AFD9-F90A-4D41-9277-6965A8C30698@microsoft.com...
> Ken,
>
> The reason that I created myaccount was to set Windows authentication to
> my
> application, app.pl. I don't want just anyone off the web accessing
> app.pl.
>
> I definately did not want to use an existing user account that has more
> rights, so I created myaccount and granted the minimum rights mentioned in
> the original post. If there is something wrong with what I did, please
> let
> me know.
>
> Best Regards,
>
> Jeff
>
>> Question - why does the MyAccount user account even exist?
>

Re: Guest account with write and script execute access - how

It's really your call, but let me just say that you have a definite
vulnerability. You have to identify your level of threat and value of
the server resource (and anything it can potentially access) to
determine how dangerous/devastating your configuration is.

With both Write permissions and Execute Script permissions, any user
that can authenticate can put a script of their choosing, which can
RevertToSelf() or otherwise obtain privileges, and run code of the
user's choosing. You might as well hand people the admin user/password
if you do this and pray through "security through obscurity" that that
no user is sophisticated enough to do this.

For example, if you were on IIS5 and /cgi-bin is in "Low Isolation",
you just gave the user access to "LocalSystem" to do as they wish.
This is why IIS6/7 Application Pools are useful for this scenario to
properly limit the exposure to the minimum necessary.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



On Jan 14, 6:46=A0pm, Jeff Dunlap
wrote:
> Dear IIS Users:
>
> I would like to know is if the following configuration is secure from
> hackers. =A0
>
> Assume that my application is at MyDomain/myPerlApp/cgi-bin/app.pl and tha=
t
> this is my IIS configuration:
>
> 1) Removed anonymous authentication from myPerlApp and enabled Windows
> Authentication. =A0This was only done to achieve a layer of privacy to kee=
p
> anonymous browsers off my application. =A0Data is not sensitive, therefore=
a
> secure transmission is not required in this case.
>
> 2) Using IIS Manager, I enabled 'Windows Authentication' for the myPerlApp=

> and cgi-bin directories. =A0The cgi-bin directory is set to 'Execute scrip=
ts
> only'.
>
> 3) Created a user account called 'myaccount' and limited this account to
> 'Guests' group.
>
> 4) I assigned 'myaccount' Read access (and nothing else) to
> C:\WINDOWS\system32\LogFiles\W3SVC2471873669 which is the directory where =
my
> IIS log files are stored.
>
> At this point, I do not see any security flaws, but please correct me if I=

> am wrong. =A0
>
> 5) If I grant 'myaccount' modify access to MyDomain/myPerlApp/cgi-bin
>
> After step 5, I am thinking that damage can occur if a hacker were to uplo=
ad
> a malicious script to the cgi-bin directory since the settings are 'Execut=
e
> scripts only'. =A0Would it somehow be possible to upload a script here due=
to
> the fact that 'myaccount' has modify access to this directory? =A0And even=
if
> an upload did occur, 'myaccount' belongs to the guest group and write
> permissions has only been granted to the cgi-bin directory and no other, s=
o
> how dangerous could this be?
>
> These are questions that I've had for a while now, any comments would be
> greatly appreciated.
>
> Thank you,
>
> Jeff

Re: Guest account with write and script execute access - how dange

> So your users are all using this same account when accessing the CGI
> application?

Hi Ken,

That is correct, all users access the cgi using the same user name and
password.

Re: Guest account with write and script execute access - how dange

On Jan 16, 5:03=A0pm, Jeff Dunlap
wrote:
> > So your users are all using this same account when accessing the CGI
> > application?
>
> Hi Ken,
>
> That is correct, all users access the cgi using the same user name and
> password.



The user token used to execute ISAPI/CGI is only impersonated by IIS.
User code can RevertToSelf() (which you cannot control) to gain access
to other, potentially more powerful identities. See my other response.

The username/password and authentication really doesn't help -- from a
security analysis perspective, you assume the hacker can compromise a
single user account (through a variety of clever means), so you need
to stay a step ahead by asking "what can they do as this user" and
"what exploit can they attempt as this user."

If you did not give modify/write permissions to this user, then you
just need to worry about ACLs on the system to constrain the user.
However, with modify/write permission, you also have to assume the
user can run any code which they upload to the server, at which point
you start thinking about dangerous codepaths -- and RevertToSelf()
would be one of the potential risks.

So you see, giving write permissions is a much more complicated
scenario than just read -- hence IIS warns about Execute/Script +
Write.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: Guest account with write and script execute access - how dange

Hi David,

> It's really your call, but let me just say that you have a definite
> vulnerability. You have to identify your level of threat and value of
> the server resource (and anything it can potentially access) to
> determine how dangerous/devastating your configuration is.

Thanks very much for responding, and for pointing out my vulnerability. I
am using IIS6 and the account I created for the particular script has access
only to a single directory where the scripts data files are created and
written to. I figured that damage would be limited only to that directory if
it did occur and due to the account's limited guest status, not much damage
could be done.

> With both Write permissions and Execute Script permissions, any user
> that can authenticate can put a script of their choosing, which can
> RevertToSelf() or otherwise obtain privileges, and run code of the
> user's choosing. You might as well hand people the admin user/password
> if you do this and pray through "security through obscurity" that that
> no user is sophisticated enough to do this.

I got these questions still nagging me and I cannot find info about them
anywhere. Hopefully you can provide some insight.

1) Is it possible to configure an anonymously accessible executable (exe)
that creates and modifies it's own data files on a specific directory? I
have some other exe's that do just that at the moment.

2) How would it be possible for a hacker to upload a script or another
executable without ftp or webdav access? Before reading your response, I had
assumed I was safe, because I figured that nobody would be able to upload
stuff without ftp or webdav access.

I've been running IIS6 for a few years now, and I had Anonymous access to a
particular EXE (execute and write access to IUSR_xxx). I don't know if
anyone ever took advantage of that vulnerability, but after about 2 or 3
years or so on the server, I ended up with an intruder who began serving tons
of content off my server. I cannot say that was the cause because I did some
stupid things like install other software packages on that server, etc...
Anyway, I formatted it and now I am looking for ways to secure my server even
more to prevent this from happening again.

Thanks Again,

Jeff

Re: Guest account with write and script execute access - how dange

David,

I was pretty unclear with question number 1), but then I read another reply
you posted and it is becoming clear to me that it is just plain dangerous to
have an executable with write access.

I would assume that I'm not the only one doing this. In fact, I've read
articles and have seen samples where people do this. It would be greatly
apprecated and helpful if you could write a blog on this at some point.

Kindest Regards,

Jeff