Log4j 2.15.0 – Previously suggested mitigations may not be enough

• log4shell-tools

  8 84 4.5 Go

  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

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.

• log4j-affected-db

  30 1,117 7.1 Shell

  Discontinued A community sourced list of log4j-affected software

  

The major risk here probably isn't in-house developed code but versions of log4j used in a vast array of packaged software and systems.

https://github.com/cisagov/log4j-affected-db <-- that's a (probably incomplete) list of affected vendors and applications, and in many cases the vendor can't even say yet whether they're vulnerable.

• InfluxDB

  www.influxdata.com sponsored

  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.

  

• ysoserial

  13 7,291 0.0 Java

  A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization.

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.

• Apache Log4j 2

  108 3,266 9.9 Java

  Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.

  

> I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}

In 2.16.0 message lookups have been completely ripped out: https://github.com/apache/logging-log4j2/pull/623

Lookups now only work in the configured patterns. Thats IMHO the way it should have been in the first place.

• lunasec

  36 1,406 5.5 TypeScript

  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/

  

log4j-api isn't actually a problem (directly). It's the usage of log4j-core that has the JndiManager class that's the injection point for RCE.

In the case of the transient dependency, it's further complicated because we've seen that some packages repackage the JARs they depend on... that means that statically analyzing for log4j is very difficult because you can't use hashes (even if you unzip the jar and hash class files directly).

I've been working on a scanner for this stuff on GitHub[0], and it's a real pain in the neck lol. Especially for Vendor software that you don't control.

0: https://github.com/lunasec-io/lunasec/tree/master/tools/log4...

• logstash-patterns-core

  3 2,160 0.0 Ruby
  

Logstash is a hugely popular service for collecting/processing/shipping logs, mainly associated with elasticsearch ("ELK") but has lots of output plugins. It uses log4j, so if one of the log events it was processing contained an exploit string, and also caused logstash to encounter an error processing or shipping the message, that message would get logged to logstash's own log, thus triggering the exploit deep in someone's infrastructure.

probably not too hard to come up with a way to break one of the many "grok" pattern regexes https://github.com/logstash-plugins/logstash-patterns-core/b...

• aegis4j

  8 14 4.5 Java

  A Java agent that disables platform features you don't use, before an attacker uses them against you.

The recent log4j vulnerability really piqued my interest, and I've spent the last few evenings working on a proof of concept Java agent that could mitigate similar vulnerabilities in the future, for applications that are able to completely forego platform features like JNDI, serialization or native process execution.

Link to the project: https://github.com/gredler/aegis4j

It's not a lot of code, but it uses parts of the platform that I think are a bit unusual for most devs, so it was quite interesting to implement. Happy to discuss details, ideas, and concerns.

One idea for a possible improvement is to make the feature block list adaptive, i.e. watch what the application uses in the first few minutes of execution, and then shut down all unused "dangerous" features for the remaining lifetime of the VM. Not sure how reliable this would be though, especially for services which have background jobs that might only run once a day.

• WorkOS

  workos.com sponsored

  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.

  

Suggest a related project