search

neykov / extract-tls-secrets

Decrypt HTTPS/TLS connections on the fly with Wireshark
Apache License 2.0
392 stars 70 forks source link

Error: Could not find or load main class name.neykov.secrets.AgentAttach #15

Closed nephewtom closed 1 year ago

nephewtom commented 1 year ago

Hi, nice tool, by the way! I am trying to attach to a Java process on a CentOS machine that is currently being executed by user runner. When logging with my user tomas, java -jar extract-tls-secrets-4.0.0.jar list runs fine and shows:

[tomas@myhost tls-decrypt]
$ java -jar extract-tls-secrets-4.0.0.jar list
  3259833 extract-tls-secrets-4.0.0.jar list

Then, after becoming root, it also let me do a list, which shows the process I want to attach to (the one with pid=3109):

[tomas@myhost tls-decrypt]
$ sudo su
[root@myhost tls-decrypt]
# java -jar extract-tls-secrets-4.0.0.jar list
  3109 com.example.containers.pretty.Pretty -mybatis.environment rac -configuration /etc/core/configuration.xml -connections 1
  3259908 extract-tls-secrets-4.0.0.jar list
  2551 com.example.workers.demux.Demux -mybatis.environment rac -configuration /etc/core/configuration.xml
  2935 com.example.containers.restzly.Restzly -mybatis.environment rac -configuration /etc/core/configuration.xml -connections 2

If I try to attach to it, it fails with:

[root@myhost tls-decrypt]
# java -jar extract-tls-secrets-4.0.0.jar 3109 /tmp/secrets.log
Failed to attach to java process 3109. Cause: Unable to open socket file: target process not responding or HotSpot VM not loaded

So I try to attach sudoing to user runner:

[root@myhost tls-decrypt]
# su runner

[runner@myhost tls-decrypt]
$ java -jar extract-tls-secrets-4.0.0.jar list
Error: Could not find or load main class name.neykov.secrets.AgentAttach

which returns this basic error of not finding or loading main class... I don't really get why is returning that... it must be something basic I am not aware of...

Could you please suggest what else can I try? Thanks in advance!

nephewtom commented 1 year ago

Tried with the latest version (4.1.0) to attach to pid=3109 as root and got this:

[root@myhost tls-decrypt]
# java -jar extract-tls-secrets-4.1.0-SNAPSHOT.jar 3109 /tmp/secrets.log
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at name.neykov.secrets.AgentAttach.attach(AgentAttach.java:64)
        at name.neykov.secrets.AgentAttach.main(AgentAttach.java:42)
Caused by: name.neykov.secrets.MessageException
        at name.neykov.secrets.AttachHelper.handle(AttachHelper.java:27)
        ... 6 more

Just in case it helps.

neykov commented 1 year ago

@tomasorti running as the target process user (runner) is what you need in this case. I can't figure out why it would fail though, especially if it's running with other users in the system. Perhaps it's an environment issue. Can you try comparing the java executable used to execute the command when you are logged in as tomas vs runner

nephewtom commented 1 year ago

@tomasorti running as the target process user (runner) is what you need in this case.

Yes, I was assuming that

Can you try comparing the java executable used to execute the command when you are logged in as tomas vs runner

The only difference I found is that tomas user is using the java executable via /usr/bin/java symbolic link whereas runner is using the java executable via /bin/java symbolic link, but both links point to the same executable.

java used by tomas user:

[tomas@myhost tls-decrypt]
$ echo $JAVA_HOME
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-2.el8_6.x86_64/
[tomas@myhost tls-decrypt]
$ which java
/usr/bin/java
[tomas@myhost tls-decrypt]
$ ls -ltr /usr/bin/java
lrwxrwxrwx. 1 root root 22 Aug  4 12:11 /usr/bin/java -> /etc/alternatives/java

java used by runner user:

[runner@myhost tls-decrypt]
$ echo $JAVA_HOME
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-2.el8_6.x86_64/
[runner@myhost tls-decrypt]
$ which java
/bin/java
[runner@myhost tls-decrypt]
$ ls -ltr /bin/java
lrwxrwxrwx. 1 root root 22 Aug  4 12:11 /bin/java -> /etc/alternatives/java

java used by root user with file type information:

[root@myhost tls-decrypt]
# echo $JAVA_HOME
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-2.el8_6.x86_64/
[root@myhost tls-decrypt]
# which java
/bin/java
[root@myhost tls-decrypt]
# ls -ltr /bin/java
lrwxrwxrwx. 1 root root 22 Aug  4 12:11 /bin/java -> /etc/alternatives/java
[root@myhost tls-decrypt]
# ls -ltr /etc/alternatives/java
lrwxrwxrwx. 1 root root 73 Aug  4 12:11 /etc/alternatives/java -> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-2.el8_6.x86_64/jre/bin/java
[root@myhost tls-decrypt]
# ls -ltr  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-2.el8_6.x86_64/jre/bin/java
-rwxr-xr-x. 1 root root 11544 Jul 25 16:46 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-2.el8_6.x86_64/jre/bin/java
[root@myhost tls-decrypt]
# file  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-2.el8_6.x86_64/jre/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-2.el8_6.x86_64/jre/bin/java: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=b3881802d778965c1989f0fc8b6589cac8c9c782, not stripped

So all users seem to be using the same java executable...

Honestly, I still do not get why I am getting this message:

[m2m@myhost tls-decrypt]
$ java -jar extract-tls-secrets-4.0.0.jar list
Error: Could not find or load main class name.neykov.secrets.AgentAttach
$ java -jar extract-tls-secrets-4.1.0-SNAPSHOT.jar list
Error: Could not find or load main class name.neykov.secrets.AgentAttach

This seem a very trivial error... I think I am missing something else...

neykov commented 1 year ago

Could the OS be restricting access to the jar file in some way (e.x. selinux)? What would happen if you were to download the file as the runner user? You could also try an alternative way of starting it. In case you get a different error message to guide you to the root cause:

java -cp extract-tls-secrets-4.0.0.jar name.neykov.secrets.AgentAttach list

or even extracting the jar file:

mkdir test
cd test
jar xf ../extract-tls-secrets-4.0.0.jar
java -cp . name.neykov.secrets.AgentAttach list
nephewtom commented 1 year ago

You could also try an alternative way of starting it. In case you get a different error message to guide you to the root cause:

java -cp extract-tls-secrets-4.0.0.jar name.neykov.secrets.AgentAttach list

or even extracting the jar file:

mkdir test
cd test
jar xf ../extract-tls-secrets-4.0.0.jar
java -cp . name.neykov.secrets.AgentAttach list

In fact, I already tested these two suggestions you are giving. But I am getting exactly the same result as running with java -jar .

Could the OS be restricting access to the jar file in some way (e.x. selinux)?

I am not familiar with selinux... so I will have to google a bit how that can be restricting the access to the jar file and how to check it in my host.

What would happen if you were to download the file as the runner user?

Sorry, what do you mean by this?

neykov commented 1 year ago

Sorry, what do you mean by this?

Switch to runner and then

wget https://repo1.maven.org/maven2/name/neykov/extract-tls-secrets/4.0.0/extract-tls-secrets-4.0.0.jar
java -jar extract-tls-secrets-4.0.0.jar

i.e. download the file as the runner user, so it takes the users's permissions.

neykov commented 1 year ago

You could also try attaching to the process at startup as described here.

nephewtom commented 1 year ago

Sorry, what do you mean by this?

Switch to runner and then

wget https://repo1.maven.org/maven2/name/neykov/extract-tls-secrets/4.0.0/extract-tls-secrets-4.0.0.jar
java -jar extract-tls-secrets-4.0.0.jar

i.e. download the file as the runner user, so it takes the users's permissions.

I tried this and same result

nephewtom commented 1 year ago

You could also try attaching to the process at startup as described here.

Yes, I did this a couple of days ago and it worked. But I am interested in attaching to a running process. The process is also used by other users and if I have to stop and restart it to capture traffic, this is affecting the other users.

nephewtom commented 1 year ago

By the way:

[root@myhost tls-decrypt]
# sestatus
SELinux status:                 disabled
nephewtom commented 1 year ago

Honestly, I am kind of intrigued why is returning this error:

[runner@myhost tls-decrypt]
$ java -jar extract-tls-secrets-4.0.0.jar list
Error: Could not find or load main class name.neykov.secrets.AgentAttach
$ java -jar extract-tls-secrets-4.1.0-SNAPSHOT.jar list
Error: Could not find or load main class name.neykov.secrets.AgentAttach

Having looked at all the possible reasons/problems that can cause that in this post, neither of them apply: https://stackoverflow.com/questions/18093928/what-does-could-not-find-or-load-main-class-mean

nephewtom commented 1 year ago

Ok, I finally found it... and it was kind of silly... As you mentioned and I was also suspecting, it was an environment issue.

I downloaded the jar file in a directory owned by tomas user. I had already changed that directory permissions to rwxrwxrwx, but... my home directory has rwxr-x--- permissions. So the execution from runner user was not really able to access the jar file and showed that error. The execution from root worked because root can access everywhere.

Moving the jar file to /tmp or a directory owned by runner makes it work. In fact, I am reading what you said before:

Switch to runner and then

wget https://repo1.maven.org/maven2/name/neykov/extract-tls-secrets/4.0.0/extract-tls-secrets-4.0.0.jar
java -jar extract-tls-secrets-4.0.0.jar

i.e. download the file as the runner user, so it takes the users's permissions.

And I did that, but did it from a tomas directory... and executed: su runner not su - runner

I used the former, so I got involved in this nonsense. If I had used the second, it would have worked.

Anyway, puzzle solved! Thanks for your replies and keep up the good work @neykov ! Best Regards!