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