CODEWITHSUNDEEP
javajavaagents
Abby
Abby

Reputation: 395

Securing Java Agent

I am currently working on a legacy application where database calls are kind of scattered all over. I need to execute some logic linked to security (business) every time some sort of DML is executed. For this, I am thinking of using a java agent and intercepting the calls and subsequently executing the business logic. The issue is that this agent needs to be secured and I need to ensure that there is no way that a different agent developed with a similar but different logic is loaded. Is there any kind of mutual authentication possible between the application and the java agent which would ensure that a wrong agent is in no way able to be loaded

Upvotes: 0

Views: 349

Answers (2)

Rafael Winterhalter
Rafael Winterhalter

Reputation: 44032

The Java attach API is already secured in the way that an agent must either:

  • be specified on the command line.
  • be attached from a JVM running by the same OS user.

To establish both cases, you must own privileges that can already escalate beyond the privileges of the agent running within the JVM process. For these reasons, it should not be necessary to validate your agent from within the JVM.

In theory you could write a Java agent that instruments the instrumentation API and make sure this agent is attached first. The instrumentation API's instrumentation could then check the jar file of the attached agent prior to its attachment and compare it to some known seed, for example. If this seed does not match, you could fail the agent's initialization.

Upvotes: 0

Stephen C
Stephen C

Reputation: 719159

Is there any kind of mutual authentication possible between the application and the java agent which would ensure that a wrong agent is in no way able to be loaded.

No. The application has (almost) no knowledge of the agent. Certainly there is no way to for the application to properly validate the agent.

I guess, you could design a "protocol" where the application only works if an agent calls a particular application method in a particular way. However that could be circumvented by reverse engineering the application or a real agent, and using that knowledge to write a bad agent that imitates the required behavior.

But I think that you are going about this the wrong way. There are many better (simpler, cleaner, more efficient) ways to inject behavior into a Java application. And I think I can detect that part of your motivation is that you want to modify the legacy application as little as possible. And that is the primary motivation for your complicated agent-based approach.

(My reaction to that is that you are likely to spend more effort on the agent stuff than you would save by not modifying the legacy app. And the result will be much harder to maintain.)

I also suspect that your requirement for mutual authentication of the application and the interceptors (however they are implemented) is not really necessary. A consequence of using agents rather than a fundamental requirement.

If I was doing this and I was this concerned about protecting against (insider) attempts to subvert the business rules, I would:

  1. Choose an alternative mechanism
  2. Implement the new code and modifications to the legacy app as required.
  3. Audit the main application and interceptor logic
  4. Join the two parts together (depending on how the mechanism work)
  5. Put the combined system onto a secured machine or container.

Upvotes: 1

Related Questions