Hardening win32 Apache by theossom


									|=-------------------------------------------------------------------------------------------------=| |=---------------------------=[ 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</transportguarantee> </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/shad0w/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 don't want anyone to build of this options. So if you're please and create your own i'll only explain a concept. This because a trojan. My goal is making people aware going to build a trojan stop reading here 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 # milw0rm.com [2009-08-27]

To top