How to discover Java agents, JVMTIs, etc.

How can you protect your Java environment while running on a computer that you do not control? What could prevent someone from building a java agent or custom JVMTI agent and dumping bytecode or rewriting classes to bypass licensing and / or other security checks? Is there a way to determine if any agents are running from Java code? From JNI? From a JVMTI agent?

+2


a source to share


7 replies


If you are not in control of the environment, then I'm sorry - you are really stuck. Yes, you could be looking for trivial JVMTI agents through some cmdline sniffing, but that worries you the least. Consider compromising java / lang / Classloader.defineClass (). This is easy to do if you own the box - just replace the .class file in rt.jar. In fact, until JVMTI came along, this was the typical way in which profiling and monitoring tools instrumented Java code.

Coming back to JVMTI - the "Late attach" function also allows you to load JVMTI agents on the fly. This may not have happened the first time you scanned.



Bottom line - if someone can change the JRE bytes on disk they can do whatever they want. It's ethical, no? Can they be caught? Perhaps, but you will never win the war.

+2


a source


It looks like I can go with a combination of checks inside some native JNI code.



1.) snd-string for searching agents. 2.) Make sure the cmd-line -XX: + DisableAttachMechanism parameter exists. (this will prevent people from connecting to my work VM)

+1


a source


I remember once making an almost silent Java agent. I think you better look for port scanners or something.

0


a source


Java 2 security, banner signing, etc. gives you some level of control over what is loaded into your application.

In the end, however, if a malicious person has access to the machine so that they can write to disk, then in all likelihood they have a lot of room for harm without resorting to clever Java hacks.

Include this round in any language, what can you do to detect Trojans?

Closely controlling access to the machines you care about is non-trivial, but essential if you are serious about such issues. Security professionals can seem paranoid, but that often means they really understand the risks.

0


a source


If you cannot control the platform, you cannot control this software.

Even if you can turn off all the checks you listed, Java is open source. They could simply take the source code and recompile it with the necessary changes.

Also, try to remember that while this is your code, this is their machine. They have the right to review your code to make sure that running it on their computer does what it expects it to do and does not perform "unnecessary" actions that might not be desirable. Less reliable companies have scanned junk files in the past, copied sensitive information to their home servers, and more.

0


a source


I would look at the command line and see if there are any "-agent" options. All profilers, debuggers, and other code modifiers use this for introspection. You can also check for unusual jars in the bootclass path as they can be a threat as well (but keep in mind that you must also deliver a custom JVM as some software like Quicktime adds itself to the bootclasspath from all java applications running ... (I couldn't believe my eyes when I saw this ...))

0


a source


This is mainly a battle.

See how visualvm works in the Sun JDK and how it can attach to a running process and override whatever it likes. It is very difficult to detect this in a portable way, and if you cannot do it, you can abandon this approach.

The question is, what do you want to avoid?

0


a source







All Articles