Is it safe to expose java remote debugger port to the internet?

Question

I was going to expose a port for remote debugging of Java-based web service over the internet, but thinking twice I realised that it has no any authentification.

Theoretically, it seems to be possible to write a tool, that attaches to remote debugger port, and executes arbitrary system commands via Java API. Or modifies/dumps database, and so on. At least this exploit seems to be the case http://securityaffairs.co/wordpress/36394/hacking/paypal-remote-code-execution.html

I don't remember being strongly warned about exposing remote debugger port ever. But nowadays, when hundreds of botnets scan ports looking for vulnerabilities, it should be better advertised.

Can please anybody comment whether it is safe and/or how to do that in a secure manner on an arbitrary java-based web-service? My goal is to be able to perform remote debug on production server.

Answer 1

You can configure remote debugging to use SSL and authentication, this works for both Windows and Linux but is a bit cumbersome. And the port is open all the time.

I am sure you have good reason to debug your live / productive application and know that when you really debug it and not only use the connection to gain access to JMX data for example your application will stop running when you connect the debugger.

Oracle documents some risks, some higher or lower, depending on how you configure the agent:

Caution - A potential security issue has been identified with password authentication for remote connectors when the client obtains the remote connector from an insecure RMI registry (the default). If an attacker starts a bogus RMI registry on the target server before the legitimate registry is started, then the attacker can steal clients' passwords. This scenario includes the case where you launch a Java VM with remote management enabled, using the system property com.sun.management.jmxremote.port=portNum, even when SSL is enabled. Although such attacks are likely to be noticed, it is nevertheless a vulnerability.

Caution - This configuration is insecure. Any remote user who knows (or guesses) your JMX port number and host name will be able to monitor and control your Java application and platform. While it may be acceptable for development, it is not recommended for production systems.

Caution - This configuration is insecure: any remote user who knows (or guesses) your port number and host name will be able to monitor and control your Java applications and platform. Furthermore, possible harm is not limited to the operations you define in your MBeans. A remote client could create a javax.management.loading.MLet MBean and use it to create new MBeans from arbitrary URLs, at least if there is no security manager. In other words, a rogue remote client could make your Java application execute arbitrary code.

Consequently, while disabling security might be acceptable for development, it is strongly recommended that you do not disable security for production systems.

Even the configuration with the highest security involved (port moved, ssl enabled, authentication by ssl client certificate) still bears risks. If you still need the debug connection I suggest you use the presumably already existing ssh connection to the server and use this one to create a ssh tunnel to the debugger port. You can read more about this here: Cannot remotely debug JVM via SSH tunnel (because it is already on SO I don't copy the details)

Opening the port without encryption and authentication will enable anyone to connect to your jvm. This will allow for reading and writing JMX values, halting the execution of your code, modifying values, creating heapdumps, overwriting code and all the other bad stuff.