SaaSHub helps you find the best software and product alternatives Learn more →
Ysoserial Alternatives
Similar projects and alternatives to ysoserial
-
Apache Log4j 2
Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.
-
log4shell-ldap
A tool for checking log4shell vulnerability mitigations
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
jsoniter
jsoniter (json-iterator) is fast and flexible JSON parser available in Java and Go (by json-iterator)
-
log4shell-tools
Tool that runs a test to check whether one of your applications is affected by the recent vulnerabilities in log4j: CVE-2021-44228 and CVE-2021-45046
-
PHP Serializer
A Java library for serializing objects as PHP serialization format.
-
-
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/
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
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
-
-
-
coq
Coq is a formal proof management system. It provides a formal language to write mathematical definitions, executable algorithms and theorems together with an environment for semi-interactive development of machine-checked proofs.
-
-
Logout4Shell
Use Log4Shell vulnerability to vaccinate a victim server against Log4Shell
-
log4j-affected-db
Discontinued A community sourced list of log4j-affected software
-
JNDI-Exploit-Kit
JNDI-Exploitation-Kit(A modified version of the great JNDI-Injection-Exploit created by @welk1n. This tool can be used to start an HTTP Server, RMI Server and LDAP Server to exploit java web apps vulnerable to JNDI Injection)
-
wg-best-practices-os-developers
The Best Practices for OSS Developers working group is dedicated to raising awareness and education of secure code best practices for open source developers.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
ysoserial reviews and mentions
-
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.
-
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.
-
Why JEP 411 Will Have a Negative Impact on Java Security
I think a mistake many people make, is they assume it's for untrusted code or applets or something along those lines, but this completely ignores access controls, besides signed applets were given AllPermission, which was just nuts in my opinion. If you read Li Gong's book "Inside Java 2 Platform Security, Second Edition", he informs the reader that remote data which has the capability to modify state, should be treated the same as code, when you take that perspective, it means that Java Serialization and XML parsers should have had an unprivileged domain placed onto the call stack, to represent untrusted data. Java Serialization was designed a long time ago, I noticed even tonight a new gadget attack was posted against Java Serialization. https://github.com/frohoff/ysoserial/commit/d367e379d961c18bff28fd2c888a2c8fe0dc6e63#commitcomment-51212711
-
A note from our sponsor - SaaSHub
www.saashub.com | 29 Mar 2024
Stats
frohoff/ysoserial is an open source project licensed under MIT License which is an OSI approved license.
The primary programming language of ysoserial is Java.