Re: Tomcat Configuration Hardening

[Christopher Schultz <ch...@christopherschultz.net>]

Dylan,

This might be a better discussion for the users' list, but I'll keep it
on dev for the time being.

On 2/28/16 2:28 PM, Dylan Ayrey wrote:
> I'm a security analyst at a company named Praetorian. When doing internal
> network pentesting it is extremely common to find tomcat instances with
> manager portals, and users added to the manager role with the credentials
> on line 35 of this file
> *http://svn.apache.org/repos/asf/tomcat/trunk/conf/tomcat-users.xml
> <http://svn.apache.org/repos/asf/tomcat/trunk/conf/tomcat-users.xml>*
> 
> This would suggest to me users are simply uncommenting that line and adding
> the manager role to it.

:(

> Typically during network assessments that first compromise is the hardest
> part, and then after the first machine is compromised it is quite easy to
> move horizontally through out the network (this can be done through SSH
> keys in a linux environment or pass the hash in a windows environment).

If you had an SSH key for the target machine, why bother attacking it
through the manager application?

> As you may be aware, one popular way we compromise that first machine, is
> to scan the entire network for tomcat servers, and attempt to login with
> "tomcat/tomcat" credentials. There's even Metasploit modules designed to do
> just this
> https://www.rapid7.com/db/modules/auxiliary/scanner/http/tomcat_mgr_login
> 
> I was wondering if it might be possible to modify the comment on line 35 to
> no longer have a hard coded password, but instead have a dynamically
> generated password or passphrase.

While not a bad idea, it's pretty tough to do this. Why? A few reasons:

1. Many people use the tarball or ZIP distribution of Tomcat. Since
there's no installer, there's no opportunity to change the password for
each installation. We could randomize the password for each release we
do, but that just makes the attacker's job a tiny bit harder because
they need to try 1 password for each release-version of Tomcat instead
of just 1 for all of them.

2. Many people use OS-package-managed versions of Tomcat, and we have no
control over what goes on, there. Whatever we may do may be undone by
the package manager(s).

I'd be in favor of adding this kind of thing to the Windows Installer
packaging provided by the ASF, but I myself don't know how to actually
do that.

> Then, when a user installs or first runs tomcat, 3 or 4 random 
> dynamic concatenated words get placed in the password section of the
> comment block on line 35. This would make it much harder for 
> attackers, because it would prevent users from simply uncommenting 
> the line and adding the manager role to that user.

This is a change-control issue that might be a problem. Setting a
password on installation is the best way to do this. There are too many
ways that Tomcat could overwrite the legitimate configuration an admin
had set-up, so I don't think a "first-run" strategy is appropriate.

> I know it sounds silly to put a random password in a comment block like
> that, but I think it would go a long way in hardening this common issue. It
> would also make networks as a whole more secure, because as I mentioned
> before, the first compromise is often a door to horizontally compromising
> more machines.

I'll have to check, but I believe a blank password will cause the
MemoryRealm to refuse a login. Perhaps simply setting the password to ""
will fix this: admins will have to set-up their own passwords. Maybe
they'll all choose "tomcat" as the password, but that's their own dumb
fault (as is using default passwords any time, of course).

The current code for MemoryRealm[1] will reject any login attempts for
users with null stored credentials. MemoryRuleSet (the component that
marshals the configuration data into the MemoryRealm) uses
org.xml.sax.Attributes.getValue("password") to get the user's password.
So setting the password attribute to the empty-string will likely do
nothing except remove the password requirement. Completely removing the
"password" attribute should cause the stored-credentials to be null.

So it seems like completely removing the "password" attribute might
help, here. We could add comments in the XML file instructing the user
to set their own password, and not to use something stupid. Also,
perhaps, suggest that they might want to lock-down the manager account
to a certain IP range, etc. A link to the appropriate documentation for
lock-downs should help with that.

I welcome comments on a proposal to completely remove the "password"
attribute from the stock tomcat-users.xml that ships with Tomcat.

> Thank you for all of your contributions to the open source community, I
> apologize if this email is not formatted correctly, I am new to the Apache
> Way. I would be interested to see what you guys think

Your post was just fine. Welcome to the community.

-chris

[1]
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/realm/MemoryRealm.java?revision=1706746&view=markup

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat Configuration Hardening

[Emmanuel Bourg <eb...@apache.org>]

Le 3/03/2016 16:36, Christopher Schultz a écrit :

> 2. Many people use OS-package-managed versions of Tomcat, and we have no
> control over what goes on, there. Whatever we may do may be undone by
> the package manager(s).

FWIW I'm in a position to change the packaging of Tomcat in Debian (and
indirectly in Ubuntu and its derivatives) if necessary. So if there is
anything wrong just ping me and I'll modify the package.

For now the Debian package deploys tomcat-users.xml unchanged with the
examples commented.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat Configuration Hardening

[Rémy Maucherat <re...@apache.org>]

2016-03-07 17:52 GMT+01:00 Mark Thomas <ma...@apache.org>:

> On 05/03/2016 18:36, Mark Thomas wrote:
> > On 05/03/2016 17:08, Christopher Schultz wrote:
> >
> >>> First of all we could add the remote address valve and limit access to
> >>> localhost by default. That will limit some remote attacks but possibly
> >>> not all depending on reverse proxy configurations
> >>
> >> I was thinking about this as well. It would definitely make a stock
> >> Tomcat more secure.
> >>
> >>> I'd also be in favour of hard-coding a check into the MemoryRealm and
> >>> the MemoryUserDatabase that rejects [1] any of those three users if
> they
> >>> have the default password and anything other than the roles defined in
> >>> the comments.
> >>
> >> Why not ignore the roles and just refuse to use "tomcat" as passwords?
> >> Then, of course, we'll have millions of servers running with "tomcat1"
> >> as the password. :(
> >
> > Indeed. Having thought about this some more, I'm going off this idea.
> >
> > I still quite like my original idea which was:
> > "Fire the idiot that did this."
> >
> >> If we completely remove the "password" attribute, I believe the code
> >> will currently reject all logins. That would force admins to make-up
> >> their own, since there would be no default.
> >
> > That is my reading of the code as well but we should double check that
> > is what actually happens.
>
> I started to work on this. If we remove the password attribute entirely
> we'll need to add something to the file that explains how to add it
> back. That probably needs an example which brings us right back to the
> copy/paste problem.
>
> I think I have a better idea. If we change it to something that will
> break if simply uncommented then that solves the problem without making
> it too much harder for inexperienced users. Something like:
>
> password="<change-this-to-something-secure>"
>
> Now they could just edit this to remove '<' and '>' but at that point
> they really do deserve to be fired.
>

Great trick actually.

>
> The comments above could also make clear that the passwords need to be
> set if that block is uncommented.
>
> WDYT?
>
> Rémy

Re: Tomcat Configuration Hardening

[Mark Thomas <ma...@apache.org>]

On 05/03/2016 18:36, Mark Thomas wrote:
> On 05/03/2016 17:08, Christopher Schultz wrote:
> 
>>> First of all we could add the remote address valve and limit access to
>>> localhost by default. That will limit some remote attacks but possibly
>>> not all depending on reverse proxy configurations
>>
>> I was thinking about this as well. It would definitely make a stock
>> Tomcat more secure.
>>
>>> I'd also be in favour of hard-coding a check into the MemoryRealm and
>>> the MemoryUserDatabase that rejects [1] any of those three users if they
>>> have the default password and anything other than the roles defined in
>>> the comments.
>>
>> Why not ignore the roles and just refuse to use "tomcat" as passwords?
>> Then, of course, we'll have millions of servers running with "tomcat1"
>> as the password. :(
> 
> Indeed. Having thought about this some more, I'm going off this idea.
> 
> I still quite like my original idea which was:
> "Fire the idiot that did this."
> 
>> If we completely remove the "password" attribute, I believe the code
>> will currently reject all logins. That would force admins to make-up
>> their own, since there would be no default.
> 
> That is my reading of the code as well but we should double check that
> is what actually happens.

I started to work on this. If we remove the password attribute entirely
we'll need to add something to the file that explains how to add it
back. That probably needs an example which brings us right back to the
copy/paste problem.

I think I have a better idea. If we change it to something that will
break if simply uncommented then that solves the problem without making
it too much harder for inexperienced users. Something like:

password="<change-this-to-something-secure>"

Now they could just edit this to remove '<' and '>' but at that point
they really do deserve to be fired.

The comments above could also make clear that the passwords need to be
set if that block is uncommented.

WDYT?

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat Configuration Hardening

[Mark Thomas <ma...@apache.org>]

On 05/03/2016 17:08, Christopher Schultz wrote:

>> First of all we could add the remote address valve and limit access to
>> localhost by default. That will limit some remote attacks but possibly
>> not all depending on reverse proxy configurations
> 
> I was thinking about this as well. It would definitely make a stock
> Tomcat more secure.
> 
>> I'd also be in favour of hard-coding a check into the MemoryRealm and
>> the MemoryUserDatabase that rejects [1] any of those three users if they
>> have the default password and anything other than the roles defined in
>> the comments.
> 
> Why not ignore the roles and just refuse to use "tomcat" as passwords?
> Then, of course, we'll have millions of servers running with "tomcat1"
> as the password. :(

Indeed. Having thought about this some more, I'm going off this idea.

I still quite like my original idea which was:
"Fire the idiot that did this."

> If we completely remove the "password" attribute, I believe the code
> will currently reject all logins. That would force admins to make-up
> their own, since there would be no default.

That is my reading of the code as well but we should double check that
is what actually happens.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Tomcat Configuration Hardening

[Christopher Schultz <ch...@christopherschultz.net>]

Mark,

On 3/3/16 3:35 PM, Mark Thomas wrote:
> On 03/03/2016 15:36, Christopher Schultz wrote:
>> Dylan,
>>
>> This might be a better discussion for the users' list, but I'll keep it
>> on dev for the time being.
>>
>> On 2/28/16 2:28 PM, Dylan Ayrey wrote:
>>> I'm a security analyst at a company named Praetorian. When doing internal
>>> network pentesting it is extremely common to find tomcat instances with
>>> manager portals, and users added to the manager role with the credentials
>>> on line 35 of this file
>>> *http://svn.apache.org/repos/asf/tomcat/trunk/conf/tomcat-users.xml
>>> <http://svn.apache.org/repos/asf/tomcat/trunk/conf/tomcat-users.xml>*
>>>
>>> This would suggest to me users are simply uncommenting that line and adding
>>> the manager role to it.
>>
>> :(
> 
> We should make sure none of the distros are doing this when installing
> the Manager package. I don't think any of that would be that stupid but...
> 
>>> As you may be aware, one popular way we compromise that first machine, is
>>> to scan the entire network for tomcat servers, and attempt to login with
>>> "tomcat/tomcat" credentials. There's even Metasploit modules designed to do
>>> just this
>>> https://www.rapid7.com/db/modules/auxiliary/scanner/http/tomcat_mgr_login
>>>
>>> I was wondering if it might be possible to modify the comment on line 35 to
>>> no longer have a hard coded password, but instead have a dynamically
>>> generated password or passphrase.
>>
>> While not a bad idea, it's pretty tough to do this. Why? A few reasons:
> 
> <snip/>
> 
> I think there might be a simpler approach.
> 
> First of all we could add the remote address valve and limit access to
> localhost by default. That will limit some remote attacks but possibly
> not all depending on reverse proxy configurations

I was thinking about this as well. It would definitely make a stock
Tomcat more secure.

> I'd also be in favour of hard-coding a check into the MemoryRealm and
> the MemoryUserDatabase that rejects [1] any of those three users if they
> have the default password and anything other than the roles defined in
> the comments.

Why not ignore the roles and just refuse to use "tomcat" as passwords?
Then, of course, we'll have millions of servers running with "tomcat1"
as the password. :(

If we completely remove the "password" attribute, I believe the code
will currently reject all logins. That would force admins to make-up
their own, since there would be no default.

-chris

Re: Tomcat Configuration Hardening

[Mark Thomas <ma...@apache.org>]

On 03/03/2016 15:36, Christopher Schultz wrote:
> Dylan,
> 
> This might be a better discussion for the users' list, but I'll keep it
> on dev for the time being.
> 
> On 2/28/16 2:28 PM, Dylan Ayrey wrote:
>> I'm a security analyst at a company named Praetorian. When doing internal
>> network pentesting it is extremely common to find tomcat instances with
>> manager portals, and users added to the manager role with the credentials
>> on line 35 of this file
>> *http://svn.apache.org/repos/asf/tomcat/trunk/conf/tomcat-users.xml
>> <http://svn.apache.org/repos/asf/tomcat/trunk/conf/tomcat-users.xml>*
>>
>> This would suggest to me users are simply uncommenting that line and adding
>> the manager role to it.
> 
> :(

We should make sure none of the distros are doing this when installing
the Manager package. I don't think any of that would be that stupid but...

>> As you may be aware, one popular way we compromise that first machine, is
>> to scan the entire network for tomcat servers, and attempt to login with
>> "tomcat/tomcat" credentials. There's even Metasploit modules designed to do
>> just this
>> https://www.rapid7.com/db/modules/auxiliary/scanner/http/tomcat_mgr_login
>>
>> I was wondering if it might be possible to modify the comment on line 35 to
>> no longer have a hard coded password, but instead have a dynamically
>> generated password or passphrase.
> 
> While not a bad idea, it's pretty tough to do this. Why? A few reasons:

<snip/>

I think there might be a simpler approach.

First of all we could add the remote address valve and limit access to
localhost by default. That will limit some remote attacks but possibly
not all depending on reverse proxy configurations

I'd also be in favour of hard-coding a check into the MemoryRealm and
the MemoryUserDatabase that rejects [1] any of those three users if they
have the default password and anything other than the roles defined in
the comments.

Mark

[1] I am sorely tempted to add "with a call to System.exit()" here

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org