What you read in this article:
Preventing Data and Source Code Theft in Java Applications
Examining traditional methods of stealing data from Java applications and how to guard against such attacks.
Planned and Unplanned Attacks
I’m Arsalan Mirbozorgi;
This article will examine some of the different methods for infecting a Java virtual machine with malware/sniffing JVM traffic/etc. Protecting your application is the primary goal of this essay. The following attacks are planned:
- Get access to the dump’s sensitive information.
- An external dependence can be used to steal code by infecting it with a piece of malware.
Using Java Dump Data to Steal
Someone may gain access to the Java process and read passwords or database addresses. A look at the next DataSource setup is warranted.
Java
1
@Bean
2
public DataSource dataSource(){
3
MysqlDataSource mysqlDataSource = new MysqlDataSource();
4
mysqlDataSource.setUrl(“jdbc:oracle:thin:@localhost:1521:xe”);
5
mysqlDataSource.setUser(“mySqlUser”);
6
mysqlDataSource.setPassword(“secretPassword”);
7
return mysqlDataSource;
8
}
Now, if a hacker gains access to our server and the JVM process, they can use a jcmd application to obtain a dump of the JVM’s memory. As an illustration:
jcmd 20932 GC.heap_dump d:\dump\JVM_DUMP.bin
Once he has it, the VisualVM profiler can be used to query the JVM’s dump using the QOL language. For example, he can use the following query to find all strings that begin with “JDBC.”
Selected from the Java language.
In the String s.toString ().
startsWith(“jdbc”)
He can also retrieve the MysqlDataSource object by using the following command:
pick “/com.mysql.cj.jdbc.MysqlDataSource/.test(it.name)” from the heap of classes
I’ll demonstrate in the following video how to make a dump of DataSource and locate possibly sensitive data:
Tutorial
Is There a Way to Prevent Dump Data Being Read?
To avoid this, you should:
- When the JVM starts up, pass a parameter of the kind -XX:+DisableAttachMechanism.
- Disable the ptrace syscall in Linux to prevent jcmd from being called (if you use Ubuntu).
- Set hidepid=1 to prevent non-root users from seeing any processes.
- Java-side encryption of data (it requires a separate article to explain).
Using Java Dependency Malware to Steal Source Code
Malware
Dependencies are a common feature in Java programs. A logger requirement should be used in even the most basic of apps. No one is interested in re-inventing the wheel and prefers to rely on proven methods instead. However, not everyone knows that dependencies might lead to a potential source code leak or even more serious issues.
With External Dependencies, Hackers Can Inject Unwanted Code into a System
A hacker typically needs two items to carry out an attack:
Release a brand new version of your software with a malware-free 3rd party dependency in maven (or any other public repository) (or replace the existing release version).
Please pray for an external repository with a new dependent version (or, in the best scenario, the $latest version) from which your client’s application gets its code.
Malware code can be executed by an infected dependency that meets these conditions. Is there anything hackers may take advantage of? Numerous! He can now:
Infected Dependency
There are a lot of other issues that aren’t covered in the examples above. We’re able to run practically any program dynamically we can think of inside malware. I believe that stolen source code is the most costly of all the difficulties.
What’s the Best Way to Steal the Source Code?
External dependencies can access a folder containing classes as long as the JVM has access to it. To steal source code, there are two steps:
- Take *.classes files from the user’s directory or classpath and paste them into the compiled code.
- Send the hacker’s server *.classes binary data (in our example, we will print class names and their size).
Using SLF4J Logger to Recreate an Attack
Using the SLF4J logger as an example, we can replicate the attack by injecting malware into it. We assume that the SLF4J repository was hacked by the hacker (the hacker may do a Man in the Middle attack and change the jar file in the next requests from the external repository).
On the Victim’s Side, what we expect
- The remote repository has a logger reliance on him (e.g., maven central).
- He always uses the most recent version, whether it’s automatic or something he does himself (not obligatory condition, but in such a situation, the leak will be known later by the community because many of the users apply a fixed version).
Attack Scenario
Attack
Example of the Attack
Details of the victim’s Java Application
Example of the Attack
Hacker Side
Hacker
What are the results when the victim updates the version and starts the application
Results
How to Prevent Such Attacks from Happening to Your Apps
Prevent
How can you be sure that your Java program is safe from these attacks? Malware can easily be inserted into your code, but unfortunately, there are numerous ways to do it. When hackers gain control of your network, they can inject malware into the JDK and dynamically replace dependencies. As a precaution, here are a few points you should do to safeguard your application:
Using an external repository (for example, https://oss.sonatype.org/) is not recommended.
The $LATEST version of a dependent should not be used at all.
Always use official dependencies instead of homemade ones (not from official sources).
If you desire to keep your code safe, configure your network and close most ports and protocols.
Use an internal private network (although it’s not a possibility for most apps, especially for those with worldwide clients) in the event of a catastrophic situation.
Conclusion – Preventing Data and Source Code Theft in Java
It is possible to hack Java apps in a variety of ways. Here, I’ve outlined the most common and efficient method of hacking that most criminals employ. Don’t disregard the aforementioned advice, and keep your app safe.
