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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
