In the previous article "Ghost King in Shell - JAVAWEB Memory shell [Cognitive]", I introduced a lot of things about memory shell from a philosophical perspective and gave my judgment: "In the trend, memory shell technology will be like SQL injection, file upload, etc., and it is a security technology that every security researcher must master in the future."
Memory shell technology is great, everyone loves it, but in fact, an unavoidable problem is that the technical threshold for proficiently modifying, debugging, and using memory shells is relatively high. In addition to the security knowledge required for vulnerability exploitation, it also requires a considerable understanding of the design patterns and source code implementation of frameworks and middleware. Facing different versions, environments, and JDKs, etc., multiple compatibility is required. Targeted attacks may require a lot of research, debugging, and code writing. For most vulnerability exploiters who are usually short of time for projects, this is not the most cost-effective way. Imagine that if you encounter a deserialization vulnerability, you need to test the gadget, generate a deserialization payload, and the payload provided by the original ysoserial generally only executes commands, and you cannot see the results after executing the commands. It is even more difficult to know how to continue to exploit in the environment without the Internet. If conditions permit, attackers can inject memory shells, but facing different versions of middleware and different technologies used by the kernel, it is difficult to exploit successfully without preparing in advance or debugging related code according to specified environments.
So, how to solve this problem? I believe that for a certain type of vulnerability, providing a universal exploitation framework that can cover the vast majority of situations and allow white hats to directly use it regardless of intermediate technologies is the best way. If the best practices can also be provided for each vulnerability, allowing users to simply click, wouldn't that be great?
So, please watch the following video:
Next, briefly introduce the use of the Ysoserial extension integrated by Goby.
What is a deserialization vulnerability? The ysoserial project is not described here, and the focus is on the usage of the extension integrated in Goby this time.
When it comes to deserialization vulnerabilities, the most important thing is Gadget. In the target environment, there must be dependencies with exploit chains, but even with dependencies, exploitation may fail due to various reasons such as incomplete dependencies or different versions. Goby provides a total of 65 deserialization Gadgets, covering most exploitation scenarios, through dynamic modification of class bytecode, deserialization streams, and other means. Users can choose the Gadget they want to use according to their needs.
The highlight of this extension, and what this article wants to introduce to everyone, is the one-click injection and utilization of memory shells.
In deserialization exploits, a considerable portion of the exploitation chain ultimately uses TemplatesImpl instantiation bytecode for exploitation. In the original ysoserial, only Runtime.getRuntime().exec() was used to execute system commands, which is too limited in functionality. In actual exploits, we can also use it to execute many functions, such as command execution feedback, tunnel classes, and execution of arbitrary custom code.
Of course, we can also inject memory shells. Goby currently supports a total of 20 different types of memory shells, including Spring, Tomcat, Resin, Jetty, JBoss, and WebSphere, which can cover most environments.
The types of memory shells currently supported by default include Behinder, Godzilla raw, Godzilla, and cmd command feedback.
After selecting the type of memory shell, you can set the address, password, and Referrer used for verification.
In addition to TemplatesImpl, the most common gadget used in Goby is the Transformer[] array in CC, which is a chain-like reflection call that is generally used to call Runtime.getRuntime().exec(). Can memory shells be injected in this type of exploitation as well?
The answer is yes. In addition to using remote class loading, bcel, and other methods to inject memory shells, Goby also supports the injection of memory shells by default by using ScriptEngineManager to execute class-loading JS scripts. In fact, memory shells can also be injected through the DefiningClassLoader of org.mozilla.javascript for class loading and many other methods, but considering that the specified dependencies may not exist in actual environments, these techniques still need further refinement.
In addition, this project provides some additional options for configuration.
- Inherit: Whether malicious classes need to inherit AbstractTranslet for deserialization exploits triggered by the TemplatesImpl method;
- Obscure: Provides some obfuscation and bypass methods for reflective calls to native methods, unsafe, etc.;
- Jboss: Outputs in JBossObjectOutputStream format;
- Dirty-type: Provides three ways to obfuscate deserialization payload at the traffic level;
- Dirty-length: The length of the obfuscated data;
Users can use these configurations as needed. By default, no configuration is required.
After all configurations are completed, click Generate to save the generated deserialization payload.
For more information on gadgets, exploitation methods, etc., please refer to the ReadMe or source code of my open source project.
Project address: https://github.com/su18/ysoserial
Using it is very simple. For example, if I want to use the CC6 deserialization chain to generate a Tomcat Filter type of Cobalt Strike memory shell with the shell address "/bg.jpg", the password is "test", and the shell Referer verification address is https://google.com/, then I can configure it as follows:
Click Generate to generate it.
After talking about so much, just using the extension to generate deserialization data seems meaningless? Can't I use a command-line tool? The reason why it is packaged as a extension is mainly for the following two reasons:
- The command-line parameters are too cumbersome, and the user experience is poor. It is more comfortable to use a graphical page.
- Considering that the actual vulnerability exploitation environment may not have a Java environment, it is too cumbersome to generate deserialization payload. Here, we put the dynamic generation of payload on the GodServer side, and there is no need for a Java environment on the Goby side.
The second question is, how to use the deserialization payload?
Of course, you can copy and paste the generated payload data into the vulnerability exploitation tool or script for exploitation, or use curl to directly send a packet to the target. However, since it is in Goby, why not integrate it with PoC?
Therefore, the previous three chapters were all nonsense. A good product should allow users to use it without knowing the details. However, if the user wants to configure it, it can also provide refined and advanced configuration functions.
So here, Goby and I have connected all the details in between and written a batch of PoC that can be used in conjunction with Goby extensions. Some representative deserialization vulnerabilities, Shiro series vulnerabilities, etc. are written, which can be directly embedded in the memory shell. In these PoCs, I have built-in several parameters that ensure that they can be used, and Goby users can inject memory shells with one click without any configuration.
It is the video at the beginning of the article. The video is linked with Goby's ShellHub extension, which can directly manage memory shells in Goby and provide functions such as command execution, file management, and basic information acquisition. If you just want to obtain some information and execute some commands, you don't need to open other webshell management software at all. From asset detection, vulnerability scanning, injection of memory shells to management of webshells, they can all be directly completed by Goby.
Of course, if you are familiar with the relevant technology, you can modify the parameters and carry out customized exploitation.
Due to time constraints, I have prepared 25 PoCs in this batch, including the Shiro framework, products such as Apache OFBiz, Apereo CAS, FineReport, Liferay Portal, ZOHO ManageEngine OpManager, ForgeRock AM, etc. Generally, two exploitation methods are provided, one is command execution echo (various echo technologies are used here), and the other is the injection of memory shells. This batch of PoCs will be used as a pilot to experience the functions of the extension. However, it is not limited. As the most discussed type of vulnerability exploitation in Java security
The above is basically the content of this article. Because this article mainly introduces the Goby extension, many technical details are not completely covered. Interested teachers can communicate privately.
In addition to the deserialization vulnerability, Java has many types of vulnerabilities that can be directly injected into the memory shell, such as JNDI, Fastjson, and so on. These capabilities may gradually be integrated into Goby (I guess). In addition to Java, php/. NET also has the use of the memory shell, which may also be gradually supported in the future. You can look forward to it.
At present, if you want to use the PoC generated by this plug-in to enter the memory shell and link with the ShellHub for management, you need to write the PoC according to the specified format. For this format, you will update it in detail in the Goby input manual later, and you can write and use it according to the manual.
The capabilities provided by the Goby extension this time are only those provided by the open source project. There are some interesting precipitates and achievements that have not been fully provided. They will be gradually shared in the future to help you use the memory shell more smoothly and lower the threshold.
All technologies and effects involved in this article will be released in the next version of Goby. Please look forward to it.
- GitHub issue: https://github.com/gobysec/Goby/issues
- Telegram Group: http://t.me/gobies (Group benefits: enjoy the version update 1 month in advance)
- Telegram Channel: https://t.me/joinchat/ENkApMqOonRhZjFl (Channel benefits: enjoy the version update 1 month in advance)
- WeChat Group: First add my personal WeChat: gobyteam, I will add everyone to the official WeChat group of Goby. (Group benefits: enjoy the version update 1 month in advance)