Stuff I'm Up To

Technical Ramblings

Rant by a Complete Java Noob — February 1, 2017

Rant by a Complete Java Noob

I confess, I’m a complete Java noob. In fact slightly worse than that, I’m a Java hater. In principle it’s a great idea, cross platform and all that jazz, but in execution it leaves me frustrated. Seems most vendors I encounter may use Java, but use libraries specific to Windows making it as mobile as Jabba the Hutt. Also vendor installations that require Java seem to only be able to support last years version of Java, not the newest stable, and therefore it has so many vulnerabilities it makes it impossible to pass any kind of security audit.

This month I’ve been trying to buckle down and get stuck in to understand things more. Try to figure out how all of this is strung together and see if anything can be done to satisfy the needs of the application and security.

Continue reading

Tomcat and HTTPS — January 31, 2017

Tomcat and HTTPS

By default Tomcat gets installed with HTTP only and a number of default applications. Previously I linked documents on how to secure Tomcat. But put simply just delete the folders under webapps that you don’t need for your application. So you pretty much get left with host-manager and manager in there.

My next step was to try to figure out how to get the connection changed from HTTP to HTTPS and apply a valid certificate to the connection.

Continue reading

Securing Tomcat —

Securing Tomcat

Following a penetration test a large security weakness was exploited that allowed an attacker to gain local admin rights on a server running Tomcat. This in turn allowed the capture of session passwords from memory which in turn resulted in domain admin level access.

All because of a 3rd party application installed by a vendor who left the underlying Tomcat installation as a vanilla box product with all the softwares default settings.

Lesson: NEVER trust a vendor installation to be secure. Carry out a vulnerability scan whilst they’re still onsite and don’t sign off any installation until all security concerns have been resolved.

References:

http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

https://www.owasp.org/index.php/Securing_tomcat

https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html

https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html

https://www.upguard.com/articles/15-ways-to-secure-apache-tomcat-8

Java SSL/TLS Ciphers — January 30, 2017

Java SSL/TLS Ciphers

You can specify what cipher suites Java uses by editing the file:

%JAVA_HOME%\lib\security\java.security

This file must also be used by the Java application. So if the application overrides this by using a -Djava.security.properties=<URL> setting then you should modify the file specified by <URL>.

The ciphers to disable are listed in the following keys:

jdk.certpath.disabledAlgorithms

jdk.tls.disabledAlgorithms

The file is documented, so you should be able to figure out the required settings from the examples.

The jdk.tls.disabledAlgorithms property in the policy file controls TLS cipher selection. The jdk.certpath.disabledAlgorithms controls the algorithms you will come across in SSL certificates.

Oracle has more information about this here.

Continue reading

Java Certificates —

Java Certificates

Certificates are the bane of my existence! After applying some updated certificates to Windows servers some of the systems are now failing to connect to database servers. This is due to the underlying Java program not knowing about the Windows certificate stores and using their own.

Now if life weren’t difficult enough the default keystores used by Java reside in their %JAVA_HOME%\lib\security folder, but we’ve got applications that have many flavours of Java installed. ie. java_jre_32bit, java_jre_64bit, java_jdk_32bit and java_jdk_64bit. I know, I didn’t install it like this, it’s a vendor install and they insist on it being this way and it must remain as a very specific version of Java.

So now we have to add the CA certificate into he cacerts file, which is where Java keeps its CA certs. So I’ve had to do this for each flavour of Java by using:

c:\> %JAVA_HOME%\bin\keytool -v -import -alias MyCA -file MyCA.pem -keystore %JAVA_HOME%\lib\security\cacert

Where MyCA is the name of the certificate and the .pem is a .cer file you must export from your CA’s mmc computer certificate snap in (management console).

Keytool will ask you for a password. What could it be? Well after a major trawl of the internet I found the default Java cacert password is ‘changeit‘.

I’m sure you can change it to whatever you’d like, but then you’re going to have to ensure that you update your Java configs to give it the new password. Which for me could be problematic as the vendors configs could be anywhere!

References: https://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html