|=--------------------------------------------------------------------------------------------------=|
|=---------------------------=[ Hardening & messing with win32 Apache Tomcat ]=---------------------=|
|=------------------------------------=[ 15 July 2009 ]=--------------------------------------------=|
|=--------------------------------=[  By shad0w_crash  ]=-------------------------------------------=|
|=--------------------------------------------------------------------------------------------------=|

---------------------------------------------------------------------------------------------------------
Index

1) Introduction
2) hash default userDatabase passwords
3) Disable manager
4) Change service account
5) SSL
6) Change shutdown
7) Information hiding
8) Signing jar files
9) Policies
10) Creating backdoors for tomcat
11) Weakening tomcat
12) Contact
---------------------------------------------------------------------------------------------------------
1. Introduction

This is my first tutorial on something so feel free to send me feedback.
The aim of this tutorial is putting a lot of information about securing
win32 apache tomcat in one whitepaper. The examples are tested on
version 6.0.20. Not all security measures are usefull but i wanted to
mention them because every small thing is also a thing.

---------------------------------------------------------------------------------------------------------
2. hash default userDatabase passwords

Default tomcat uses plaintext passwords in the configuration files
(tomcat/conf/user-conf.xml). When you share a server someone could gain
higher privileges by reading te file. Or if you are updating it by
shoulder surfing. To provide this you should hash the passwords. This
can be done in 2 ease steps.

  1) append to the rule about the userdatabase digest="sha". The line will now look like this:
        <Real className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" digest="sha" />

  2) Change the password in user-conf.xml to sha(password). 

Don't forget to reboot tomcat ;)
---------------------------------------------------------------------------------------------------------
3. Disable manager

Unless you use the tomcat manager(for deployment), the best thing to do
is removing the tomcat manger from server.xml. If it's neceseary to
exists (for remote administration) you should create an ip-filter. The
easyst way to do this is appending the following line to
tomcat/conf/server.xml:

  <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="xxx.xxx.xxx.xxx" />

Of course you could also use this setting to secure other webapplications on ip.
---------------------------------------------------------------------------------------------------------

4. Change service account

By a default instalations apache tomcat is installed under the local
system administrator account. You should prevent this.

	First add a user and a group. 
	Grant the right to run services to this group (local security policy). 
	Grand the rights to use java, tomcat and webapp directory

If all this is been done go to services.msc and find the apache tomcat
service. Get the properties and go to log on. Here you should click this
account (and choise your account).
---------------------------------------------------------------------------------------------------------
 
5. SSL

Enabeling ssl, importing the right and strong signed certificateds is
not enough to make ssl work. Many website's redirect the website to
https and of course this'll work. But you're not forced to use https. If
you check out the request and repost it, most time it'll be processed.
This is a security risk because a man in the middle attack could be
realised.

In the web.xml of a context you could specify the transport-guarantee
and the allowed methods. By only allowing post and ssl you'll be more
secure.  This is an example:

<security-constraint>
	<web-resource-collection>
		<web-resource-name>something</web-resource-name>
		<url-pattern>/payingservlet/*</url-pattern>
		<http-method>POST</http-method>
	<web-resource-collection>
	<user-data-constraint>
		<description>description</description>
		<transport-guarantee>CONFIDENTIAL</transport-guarantee>
	</user-data-constraint>
</security-constraint>
---------------------------------------------------------------------------------------------------------

6. Change shutdown

You could shutdown apache tomcat by connecting to TCP 8005 and type
shutdown. This connection is only allowed from localhost, but why take a
change? Change the rule '<server port="8005" shutdown="SHUTDOWN" in
conf/server.xml. You could use an other port and you could use an other
shutdown (sort off shutdown password).

My first tought was to use the number 100000 to disable it. But with
this number tomcat doesn't start anymore. However if you use an integer
so big that it'll overflow the java integer. Tomcat wil startup and
connecting to 8005 is impossible. I used '500000000000000' for example.
---------------------------------------------------------------------------------------------------------

7. Information hiding

To distract scriptkiddy's you should hide version numbers and webserver
type. If you append server="Apache" to <Connector port = "80"> the
server wi'll only show Apache as name. You can view this change by using
LiveHTTPHeader (firefox plugin).

  An other place to hide information is as follows.
  Extract lib/catalina.jar and open the extracted org/apache/cataline/util/ServerInfo.properties.
  Change the
      server.info=Apache
      server.number=x.x
      server.built=x

 You could degrate the data to apache and version 1.0. Also you could a
little bit of distraction by naming it to IIS (ore somelike).            
---------------------------------------------------------------------------------------------------------

8. Signing jar files

Why should you sign a jar? First of you can claim your code with it.
Also it's faster to traceback if someone messed with it. If an
authorised certificate is used the chance of having a virus free jar is
much bigger :).

How to sign a jar file. First of all you need to create a keystore.
Second you need to use the jarsigner to (self)sign the jar.

keytool -genkey -alias shad0w_crash -keypass <goodpassword> -keystore /home/shad0w/keystore
jarsigner -keystore /home/jeroen/keystore -storepass <goodpassword> -keypass <goodpassword> -signedjar <output>.jar <org>.jar shad0w_crash

Now you could verify the .jar file by using:

jarsigner -verify a.jar

Also if you open the .jar file you'll see in the /META-inf directory 3
files wich contains the hashes of your .class files. Of course it's
faster for webservers to sum the jar with a strong hashing algoritem
(shasum -a 512 <filename> ).
---------------------------------------------------------------------------------------------------------

9.policies

Default apache tomcat runs with all permisions of the java security
manager. The first thing to do is using the catalina policie file. Open
your tomcat configuration gui (\bin\tomcat6w.exe) and go to the java
tab. Exstend java options with this line:

-Djava.security.policy=<direcotyr>\catalina.policy

After this you should go to a prompt and execute /bin/catalina start -security

Now go to your policy file and decide what your applications really
need. For example if your application doesn't need sql or remote
connections you should disable this.

---------------------------------------------------------------------------------------------------------


10. Creating backdoors for tomcat

Appending
In this part of this paper i'll only explain a concept. This because I
don't want anyone to build a trojan. My goal is making people aware of
this options. So if you're going to build a trojan stop reading here
please and create your own way.

the most usefull way for tomcat to create an backdoor is creating a
webapplication wich allows you to upload, download, browse execute
connect, connectback etc. But this is realy obvious. If you're in a
position to analyse code before inserting a trojan the best way is
looking for an peace of code that calls a class or action dynamicly. For
example this piece:

exec = (Action)Class.forName(input).newInstance();

Output = exec.run(args);

Creating a new class that implements the interface should be enough to
have a nice hidden action. If the module is open-source you should
integrate the code in an excisting class and replace the old one.

Replacing
Also you could check out the source from tomcat
(http://svn.apache.org/repost/asf/tomcat/trunk). As example i picked the
org.apache.catalina.servlets.DefaultServlet.java code and added:

ostream.println("<!-- secret message -->");

to the protected void serveResource(.....).

After that i removed the classes

org.apache.catalina.servlets.DefaultServlet.class
org.apache.catalina.servlets.DefaultServlet$Range.class

from catalina.jar. Now when i start apache tomcat and view the source i'll see <!-- secret message -->
Other options i tested by using the defaultServlet(of course normal java code works like always!):

1) filewriting (create a nice .java file in the root directory)
2) Compiling (Create a .classfile) 
	String command = "javac.exe c:" + File.separator + "Test.java";
	Process p = Runtime.getRuntime().exec(command);
3) Updating a jar file 
	jar -uf a.jar Test.class 
	note: you can't update catalina.jar when tomcat is running but you can ofcourse extend it ;).
4) Using sockets to connect to an remote host 

11) Weakening tomcat

When you want to less secure tomcat you should enable the invoker
servlet. Simple reconfigure web.xml and allow the invoker servlet and
make sure the webapplications runs as privileged. An other option is to
reconfigure the web.xml from the manager. Remove the deploy servlet from
the security-constraint.

12) Contact 

If you have any thing to attach, just copy the tekst and repost it to
the site you got it from. Only thing I ask is to not remove my allias
but just add yours. For contact http://twitter.com/shad0w_crash.
Grtz