Hacker story: How to take over the computer of Java/Clojure/Scala programmers

Hacker story: How to take over the computer of Java/Clojure/Scala programmers
Sonatype has responded to this post and declared on their blog that the SSL link will be enabled for all users. This change makes the Java program ecosystem more secure and reliable, and I am very happy with this.

Nevertheless, if you see this blog and consider spending 10 dollars to assess whether your product needs this security, the answer is no. This is like a car company deciding to spend 10 dollars evaluating whether their car needs airbags. Fortunately, in real life, automobile companies must install airbags.

I am very happy with this modification to the Sonatype mechanism, hoping that they will continue to reduce security conflicts with products. For our developers, it is our responsibility to provide users with the safest and most secure products. What is the user's tolerance for handling products and security issues.

One day, I saw that my firewall was set up like this, so I began to intrude into one of my Clojure projects:

Then I downloaded clojure. jar from http // repo.maven.apache.org through port 80. This means that I will be able to download the package through an unencrypted http. I initially thought this was a leiningen issue. However, the results are completely different. Clojure. jar and many other jar packages are important in the Java, Clojure, and Scala fields. They are officially put in a public service-Maven Central provided by Sonatype. Sonatype has a mechanism: only those with identity can allow SSL connections. You need to donate ten dollars to the Apache Foundation to obtain the identity and SSL link. If you don't believe what I said, the donated webpage is here, this mechanism is stated on this blog. Man-in-the-middle attacks are even mentioned here.

Because the identity is distributed to individuals or organizations, tools like maven or leiningen cannot be bound to it. If you use these tools, downloading java programs or installing some of its Dependencies will not pass SSL. One of my employees on twitter and Sonatype argued and confirmed the issue.

The jar package you downloaded will come from man-in-the-middle, and the code you executed will be replaced by malware. To prevent such incidents from happening, you must be careful when performing each step of the operation. Otherwise, you will be able to pay another person ten dollars.

When will this happen normally? If you have linked public networks of coffee shops or wireless networks of others, the man-in-the-middle will be able to communicate with you. Your network service provider should be able to communicate with you at will. Some people do this to advertise. Or, you will also be attacked by operations from countries.

Dilettante

To prove how easy it is, I wrote a man-in-the-middle proxy dilettante which intercepts JAR packages from maven central and then injects malicious code into it.

Use dilettante to proxy http transmission, and then set a backdoor for any JAR package downloaded in maven central. The version with backdoors configured will retain the original functions, but when they use this class library, a friendly message will be prompted. You can watch this video:
Or:

The source code is here.

Implementation

When downloading the JAR package from maven central, the man-in-the-middle can be replaced as it is transmitted over HTTP. JAR packages can be identified, but based on my experience with standard tools, these identifiers will not be checked. The only other method can verify the SHA1 and which are also transmitted over HTTP. When dilettante finds that JAR comes from maven central, it will replace a version with a backdoor with the original one. The replaced version will then run malicious code on the victim's computer. Because SHA1 only transmits data over HTTP, dilettante simply replaces all the hash tables it can see with the corresponding hash tables with the following JAR packages.

I used an excellent mitproxy class library to create my tools. I first write an inline script for the proxy, and then create an independent tool with libmp Roxy.

 

package dilettante;public class Dilettante {    public static void() {        // do some evil stuff    }}

 

The JAR package is only a compressed package containing resources, classes, and metadata. I add my own classes to the JAR to set a backdoor for this JAR.

A little headache is how to call my malicious code. I know the victim will definitely download some class libraries. However, no matter which class in the class library you call, it can run my code, and it cannot affect the normal use of the previous class library.

Java has the concept of static class blocks, which can be initialized at the class level. When the class is loaded into the memory, the code in the static class is called only once. After I insert a malicious class into the Jar package, I can call the code in the static block as follows:

 

import dilettante.*;static {    Dilettante.backdoor();}

 

To insert the above code, I need to insert it directly into the Java class, instead of the source file. I used Karakatau to insert the code in Jasmin format. Karakatau is a Java decompilation/compilation class library for Python.

 

.method static <clinit> : ()V  ; method code size: 4 bytes  .limit stack 0  .limit locals 0  invokestatic dilettante/Dilettante backdoor ()V  return.end method

 

Limitations

This is just a conceptual experiment, and it still has limitations.

1. For some reason, it is not very fast:

I must decompile and compile it. If you can directly insert compiled code into the class, it will be more efficient.

I actually used the Python zipfile class library to create a copy of the class files of the compressed package. In terms of space and speed, this is not efficient. If you are more familiar with the zip function, you may find a method to insert data efficiently.

2. If you download multiple JAR packages at the same time. Then I will set backdoors one by one. Malicious code is executed only once in each JAR. However, if multiple jar files are configured with backdoors, the jar files are executed multiple times. If we replace the cat image with a high-quality, stable backdoor that can only affect the system once, then this problem will not occur again.