As part of a challenge, I would like to use reflections to get information about the code running on a tomcat server as *.jsp. (Assuming that the server is not configured very secure and allows this).
Google shows absolutely no answer regarding tomcat and reflections from the outside.
I guess I might have to combine it with Remote Procedure Calls or sth like that. Any ideas?
You don't get free exploits just because Java has reflection.
Reflection (as in java.lang.reflect.*) works only from the inside. Code executing in a JVM process can reason about other code running in the same context, IOW, the program can reflect about itself.
You would need to be able to inject your spying code into the server's java process.
Luckily, servers generally don't allow you to do that, not even badly configured ones - unless there is a remote code execution vulnerability like CVE-2013-4444 for example.
You also can't abuse Remote Procedure Calls that easy. First of all, a remotely callable procedure must be placed there by the programmer. And there are none by default. But assuming you find something that is for some reason unprotected, you'd still only be allowed to call that procedure, not arbitrary code of your choice. If you can, you've probably found a vulnerability.
Related
Is there a way to configure the JVM to block instances of a class being created?
I'd like to do this to ensure no service running in the JVM is allowed to create instances of a class that has been identified as a security risk in a CVE, lets call that class BadClass.
NOTE: I'm looking for a general solution, so the following is purely additional information. I would normally address this by switching the library out, or upgrading it to a version that doesn't have the exploit, but it's part of a larger library that wont be addressing the issue for some time. So I'm not even using BadClass anywhere, but want to completely block it.
I do not know a JVM parameter, but here's some alternatives that might pout you in a position that solve your requirements:
You can write a CustomClassLoader that gives you fine control on what to do. Normal use cases would be plugin loading etc. In your case this is more security governance on devops level.
If you have a CICD pipeline with integration tests you could also start the JVM with -verbose:class parameter and see which classes are loaded when running your tests. Seem a bit hacky, but maybe suits your use case. Just throwing everything into the game, it's up to you judging about the best fit.
Depending on your build system (Maven?) you could restrict building applications just on your private cached libs. So you should have full control on it and put a library - review layer in between. This would also share responsibility between devs and the repository admins.
A distinct non-answer: Do not even try!
What if that larger library that has this dependency wants to call that method? What should happen then?
In other words, what is your blocking supposed to do?
Throw some Error instance, that leads to a teardown of the JVM?
Return null, so that (maybe much later) other code runs into a NPE?
Remember: that class doesn't exist in a void. There is other code invoking it. That code isn't prepared for you coming in, and well, doing what again?!
I think there are no good answers to these questions.
So, if you really want to "manipulate" things:
Try sneaking in a different version of that specific class into your classpath instead. Either an official one, that doesn't have the security issue, or something that complies to the required interface and that does something less harmful. Or, if you dare going down that path, do as the other answer suggests and get into "my own classloader" business.
In any case, your first objective: get clean on your requirements here. What does blocking mean?!
Have you considered using Java Agent?
It can intercept class loading in any classloader, and manipulate it's content before the class is actually loaded. Then, you may either modify the class to remove/fix it's bugs, or return dummy class that would throw error in static initializer.
My application code will run on one box. I have a tool that will be executed on a different box. Here I want to access my application code specific class method in the tool where it will executed on different box. How can I do this?
I don't want to change any existing code on the application side, I only want to add code on tool side to access the application class method. The class that I want to access is a regular java bean class.
We used to have a somehow similar issue.
We end up creating a simple library that allow us to distribute classes over several JVMs and to call methods in remote JVM.
You can have a look on https://github.com/plantuml/remotejvm to see if it can help you.
May be you need to have a look at Remote Method Invocation. Also take care of which version you are using, versions before Java 5.0 required the RMI stubs to be compiled separately.
Java RMI Tutorial
RMI online training
You would want to take a look at remote method invocation(RMI). It is not possible without adding code on the application side since you need to register the application with the RMI registry. The RMI registry is sort of a directory lookup to allow remote applications to access the application.
You could also use RMI-IIOP but it has the same constraints. You need to register the application with tnameserv
Link: https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/index.html
We have a web application which sometimes (quite rarely, several times a day) gives an
error in production. It is deployed on Tomcat, uses Spring+Hibernate, the error is caused
by a Hibernate exception which is hard to understand without actually logging the
parameters passed to the method of the Hibernate class. It is not possible to replace
the Hibernate library with a modified version which logs the parameters, and spring-aop
cannot be used since the "beans" are not managed. I have seen an example of byte code
instrumentation using javassist, on http://today.java.net/pub/a/today/2008/04/24/add-logging-at-class-load-time-with-instrumentation.html, however trying to run it under
tomcat, the instrumented code does not seem to run, probably due to classloader problems
which I currently don't understand.
What I am asking then, is this: does anyone know of a more or less simple way to instrument
the byte code under tomcat for such a task as logging the parameters of methods in
external libraries? is there some further insight you may give on this problem?
Have a look at BTrace.
It will allow you to log calls to other classes/functions without slowing down the main application.
You could (temporarily) enable JDWP on the production Tomcat, attach a debugger, and place a breakpoint on the offending code. But I'd recommend avoiding doing that on the actual production machine -- better to clone the production environment to another machine that you can tinker with.
At work, I use a Java application (I have located compiled/executable jars on the C-drive). I want to be able to grab some information from this application through code. The application itself probably does not store information, so it must communicate with legacy systems some way, I am not sure how, I have seen traces of a Servlet(?) Hence, I suspect the application also has built-in "encryption"(?)
I do not want to get involved in encryption and login procedures etc., so I am thinking I could just build a Java project around the current executable jars, and launch the application as I usually do (through the "main" entry point, "Start.jar", but then after execution call the functions that I want to (i.e. the application just runs as usual in the background)...
Would that be possible? Is there another way? Can one, for example, hook up to an already executed Java application and issue commands?
What I have tried so far
Downloaded Eclipse, and created a new project
Made Eclipse "reference" external jars (there was a wizard in Eclipse)
Created a new class in my new project, in which I launch the "main" entry point of the "main" executable jar (the structure of all the jars pops up with "IntelliSense"). I have also found out which argument I need to supply to the main procedure using JD-GUI (Java Decompiler)...
It seems that from inside the main procedure a call is made to another procedure, which resides in a different jar, in the debug window of Eclipse I just see an error, which made me doubt that my current approach is viable... Maybe the problem arises because the command is issued from a compiled jar? Could there be an issue with the "class path"? Does this at all seem like a solution? But then again, I have no experience with Java (mostly VBA and some C#).
You can start your JVM for the application with options, which enable remote debugging. Then you can connect the eclipse debugger to this JVM.
http://www.eclipsezone.com/eclipse/forums/t53459.html
Based on your question, I am going to guess that your application does not have a Java API you can code against. That would, of course, be the easiest way. So, if you have not checked, do that first.
Assuming you don't have an API to code against, I think your approach is correct. But it could be hard to do, since you are basically flying blind trying to figure out what the application is doing. Remote debugging might solve part of that problem.
There might be a slightly easier solution, if you are sure it is sending requests across the network. You can use a tool like Wireshark to see what it is creating. Then, you can have your application create requests that look like that and send them to that destination. This assumes of course that the requests aren't encrypted. In that case you are probably out of luck.
What I want to do is implement some basic security by checking not only what class has called a particular method, but also, which instance of that class.
I tried
StackTraceElement[] stackTraceElements = Thread.currentThread().getStackTrace();
but that obviously only gives me the class name. The problem with allowing/requiring the callers to send self, or personal IDs is that all the callers are required to have access to the details of all the others. Can anyone help?
EDIT: More information:
So we have a server which makes connections with several agents. The agents send packets of information which include the name they CLAIM to have. There is a special agent which decides whether or not people should be able to lie about this in each particular case.
The agents make connections to instances of an Agent class on the server, but there is also a possibility that some agents will run natively. The reason I'm interested in this approach is that I will need that technique later (extract the specific instance that called a given method)
I hope this is better, and sorry for not putting enough info before :/
This whole line of attack can't possible secure anything. If users can control the code that runs, they can just run a codegen library and edit your code. If users can't control the code, then this is all unnecessary.
If you can't resist this urge, one approach is to wrap everything in Proxies that communicate the information you need.
By Proxy, I mean java.lang.reflect.Proxy. That is, wrap every one of these objects in a proxy. The proxy's job would be to store away this on a stack of your own that the callees could consult.
This is essentially AOP (aspect oriented programming) reinvented, so you might want to read about that. Look at the Spring framework.
You are not securing anything like this.
I think for such problems just check that all contributing code comes from signed jars.
Look up Capability-based security. Instead of knowing which client is doing what, you should give each client separate capability objects (essentially proxy objects with different privileges).