ysoserial
log4shell-tools
Our great sponsors
ysoserial | log4shell-tools | |
---|---|---|
13 | 8 | |
7,291 | 84 | |
- | - | |
0.0 | 4.5 | |
30 days ago | 22 days ago | |
Java | Go | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ysoserial
- anybody got ysoserial to work in kali 2022 running java v17?
-
Java deserialization payloads in log4j (Unified starting point)
So I've finished the unified box in stage 2 of the starting point and have tons of questions about the box. In the box they use veracode-research/rogue-jndi to exploit the log4j vulnerability. But when I test it with deserialize payload generated by frohoff/ysoserial it's not running. I've try to look at the java log in the challenge container but can't find anything that java complain or error out. Is it because the ysoserial payload too complex that it running but fail at some point and don't throw error or maybe the author just hard code so that only the payload from rogue-jndi work? can it's because of the java version/framework/library/weirdness? Do I need to test both kind of payload if I want to exploit log4j in the future or just stick with pimps/JNDI-Expoit-Kit or cckuailong/JNDI-Injection_Exploit-Plus (my senior recommendation when exploiting log4j).
-
An Unsafe Deserialization Vulnerability and Types of Deserialization
GitHub - Ysoserial
-
Great Time at JavaZone 2022
A gadget lets you run load a different class upon serialization. This will fail later when we downcast but during the read process we can load a different class where we can do arbitrary code execution. HashMap is a class that overrides the readObject and can be used as part of an exploit chain. ysoserial helps us create a chain of serialization to produce an exploit based on known serialization weaknesses. You can run this project and generate payload ser files that you can pass to exploit potential vulnerabilities.
- PoC tool for creating payloads that exploit unsafe Java object deserialization
-
Is Java as safe as we believe?
gadget chain attack: is a type of exploit where an attacker uses a series of "gadgets" — small pieces of code that perform a specific function — to execute a larger, more complex attack. By chaining together these gadgets, an attacker can gain control of a target system or perform other malicious actions. You can use ysoserial to create a serialize payload java -jar path/to/ysoserial.jar CommonsCollections4 'whoami'
-
Is Haskell a Good Choice for Software Security?
> A similar issue has occurred with Java (and other languages, see https://frohoff.github.io/appseccali-marshalling-pickles/). Java provided a suberbly user-friendly way of serializing any object to disk and recovering it back in its original form. The only unfortunate problem was that there was no way to say which object you are expecting! This allows attackers to send you objects that, upon deserialization in your program, become nasties that wreak havoc and steal data.
Not correct. You can certainly inspect before instantiation:
https://docs.oracle.com/javase/7/docs/platform/serialization...
-
Log4j 2.15.0 – Previously suggested mitigations may not be enough
Mmh, I don't think so. Beside logging most other libraries will already sanitize user input since it is a more commonly known attack vector for those kind of libraries. I would compare the vulnerability to https://github.com/frohoff/ysoserial.
-
Analysis of the 2nd Log4j CVE published earlier (CVE-2021-45046 / Log4Shell2)
Exactly. eg. https://github.com/frohoff/ysoserial#usage
Note the classes aren't at fault or doing anything wrong (even though you could imagine other mitigations they could use), they are just conveniently there to use if you have a vulnerability that lets you de-serialize untrusted data.
-
RCE 0-day exploit found in log4j, a popular Java logging package
This has been known for a zillion years and has caused a zillion CBEs, so at this point there are off-the-shelf tools like ysoserial that take your payload and wrap it into an object that kabooms when deserialized, with like 20 different choices of methods depending on what dangerous objects are available on the target's classpath for deserialization.
log4shell-tools
-
Log4j: The Pain Just Keeps Going and Going
I'm seeing this as well. While the amount of traffic has certainly decreased compared to the first couple of days after the CVE was announced, https://log4shell.tools is still being used by people every day.
-
How to send similar payload to different http headers?
e.g. from log4j. Taken from https://log4shell.tools/
-
Received a visit from the infamous Dejmnok420 today. Can anyone ELI5 the steps to take now?
I run tests with https://log4shell.tools, and it seems I'm vulnerable on client side, but my server is safe, which makes sense as I compiled the .jar 2 weeks ago with BuildTools as indicated here https://www.spigotmc.org/threads/spigot-security-releases-%E2%80%94-1-8-8%E2%80%931-18.537204/
-
Log4Shell Vulnerability Test Tool
You're right, but this has always been the trade off with tools like this. You put some trust in the tool's authors and gain some insight in return. Remember the services that tested for Heartbleed (e.g. https://filippo.io/Heartbleed/)? Fairly similar trade-off, but still these tools were widely used.
If you really don't trust me and have some technical know-how, you can self host the service. It's open source: https://github.com/alexbakker/log4shell-tools.
-
Log4j 2.15.0 – Previously suggested mitigations may not be enough
I can't say I'm feeling the same. Still lots of people testing over at https://log4shell.tools almost a week after this vulnerability became widely known. Plenty of people still discovering they're vulnerable as well. I think it's likely that these are just the people who know they're using log4j. If you're running a black box product from a vendor you'll have no clue you're vulnerable until it's too late.
-
Analysis of the 2nd Log4j CVE published earlier (CVE-2021-45046 / Log4Shell2)
I have a feeling this vulnerability is going to be with us for years. Shameless plug: I built a tool that assists in detecting whether you're vulnerable to this or the previous CVE: https://log4shell.tools. Just enter the JNDI URI it gives you anywhere you suspect it ends up causing a message lookup in log4j. If log4j does so much as a DNS lookup, this tool will tell you about it.
-
log4shell.tools - Check if you're vulnerable to an egregious case of log4shell
Done! https://github.com/alexbakker/log4shell-tools
What are some alternatives?
jsoniter - jsoniter (json-iterator) is fast and flexible JSON parser available in Java and Go
lunasec - LunaSec - Dependency Security Scanner that automatically notifies you about vulnerabilities like Log4Shell or node-ipc in your Pull Requests and Builds. Protect yourself in 30 seconds with the LunaTrace GitHub App: https://github.com/marketplace/lunatrace-by-lunasec/
log4shell-ldap - A tool for checking log4shell vulnerability mitigations
log4j-affected-db - A community sourced list of log4j-affected software
Apache Log4j 2 - Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.
log4j2-without-jndi - log4j2-core JAR w/o JndiLookup.class
PHP Serializer - A Java library for serializing objects as PHP serialization format.
log4j-log4shell-affected - Lists of affected components and affected apps/vendors by CVE-2021-44228 (aka Log4shell or Log4j RCE). This list is meant as a resource for security responders to be able to find and address the vulnerability
Arthas - Alibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas
aegis4j - A Java agent that disables platform features you don't use, before an attacker uses them against you.
fastjson - FASTJSON 2.0.x has been released, faster and more secure, recommend you upgrade.
log4jshell-pdf - The purpose of this project is to demonstrate the Log4Shell exploit with Log4J vulnerabilities using PDF as delivery channel