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
signature.asc
Description: OpenPGP digital signature
