Protecting Java Application From Stealing Data and Source Code

Attack Scenarios

In this article, we review possible ways how to inject malware code in JVM/to sniff JVMs traffic/etc. The key objective of this article is to explain how to protect your application. The plan is to perform the next attacks:

• Read sensitive data from the dump.
• Steal source code by injecting malware in an external dependency.

Stealing Data From Java Dump

If someone got access to the Java process he might be able to read sensitive information like passwords or database addresses. Let's take a look into the next DataSource configuration:

@Bean
public DataSource dataSource(){
  MysqlDataSource mysqlDataSource = new MysqlDataSource();
  mysqlDataSource.setUrl("jdbc:oracle:thin:@localhost:1521:xe");
  mysqlDataSource.setUser("mySqlUser");
  mysqlDataSource.setPassword("secretPassword");
  return mysqlDataSource;
}

Now if the hacker attacks our server and gets access to the JVM process then he can make the dump of JVM's memory by using a jcmd program. For instance:

jcmd 20932 GC.heap_dump d:\dump\JVM_DUMP.bin

When he gets JVM's dump he can query it with VisualVM profiler using QOL language. For example, to fetch all strings starting with "JDBC" he can make the next query:

select s from java.lang.String s where s.toString().startsWith("jdbc")

Or as an alternative he can fetch the MysqlDataSource object:

select filter(heap.classes(), "/com.mysql.cj.jdbc.MysqlDataSource/.test(it.name)")

In the next video I'll show how we can make dump and find potentially sensitive data from DataSource:

How To Prevent Reading Data From the Dump? 

In order to prevent it you need to:

•  Add parameter -XX:+DisableAttachMechanism on JVM startup.
• Disable jcmd call in Linux by disabling the ptrace syscall (if you use ubuntu).
• For non-root users disable access to processes by set hidepid=1.
• Encrypt data on the Java side (it requires a separate article to explain).

Stealing Source Code by Injecting Malware in Java Dependency

The vast majority of Java applications use dependencies. Even hello world applications should use logger dependency. No one wants to reinvent the wheel and would rather use existent solutions. But not everyone knows that dependencies can be the source for potential source code leak or even worse problems.

How Hacker Can Inject Unwanted Code Using External Dependency

In order to perform an attack, a hacker usually needs 2 things:

• Get control over 3rd party dependency in maven (or any other public repo) and release a new version with malware (or replace the existent release version).
• Hope that client's application uses an external repository with a new dependency version (or perfect case with $latest version).

If these requirements are met, an infected dependency can execute malware code. What opportunity does it give to hackers?  Numerous! Now he can:

The above-shown examples don't describe all the potential problems. Inside malware, we are able to dynamically execute almost every thinkable application. But among all problems, I think the most expensive one is stolen source code.

How to Steal the Source Code?

As far as JVM has access to a folder with classes, we can expect that external dependency also has the right to read it. In practice, stealing the source code has 2 steps:

• Copy *.classes files from user directory / classpath.
• Send *.classes binary data to the hacker's server (in our example we will just print class names and their size).

Reproducing Attack With SLF4J Logger

In this example, we will reproduce the attack by injecting malware into the SLF4J logger. We assume that the hacker got access to the SLF4J repository (as an option, the hacker might perform Man in the Middle attack and replace jar file incoming requests from the external repository).

What We Expect To Have On Victim Side

• He has logger dependency from the external repository (e.g., maven central).
• He uses the latest version or manually updates it to the most recent (not mandatory condition but in such case, the leak will be detected later by the community because most of the users use fixed version).

The Attack Scenario 

Example of Attack

Victim's Java Application Details

Hacker Side

Results When Victim Updates Version and Start Application

How to Protect Your Applications From Such Attacks 

Is there any ultimate way to protect your Java application from such attacks? Unfortunately no, there are many ways to inject malware into your code. Hackers can inject malware during the build or by injecting malware in JDK as well as replace dependencies dynamically by getting control over your network. However, the following are some precautionary measures that you should implement in order to protect your application:

• Never use an external repository but your private one (for example https://oss.sonatype.org/).
• Use stable dependency version and never use $LATEST one.
• Never use custom, not official dependencies (not from official sources).
• Configure network and close most ports/protocols to avoid source code transfer.
• In the critical case - deploy your application in an internal private network (although, it's not an option for most applications, especially with worldwide clients).

Conclusion

There are many more ways to hack Java applications. In this post, I described the most known and efficient way that most hackers use. Don't ignore the mentioned recommendation and keep your application secure. 

It was my first article with GIF. Do let me know if you like it so I can keep this practice for future articles. Thanks for reading!