lunasec-io/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/

lunasec's Issues

RCE in CVE-2021-45046

In the recent blog post, https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/, you say that a RCE is still possible with log4j 2.15.0. I am not sure about this finding, so I hope you can elaborate on this:
In the CVE, it says that JNDI LDAP lookups are now limited to localhost. This part is not mentioned in the blog post.
You show a RCE with the 2.15.0 version, but I cannot see if the LDAP server is running on localhost or on a remote server. If the LDAP server is running on localhost, I don't see how this would work in a real world scenario, as the attacker cannot run their LDAP server on the victims machine.
So, can you please validate your findings by specifying if your RCE PoC uses a localhost JNDI LDAP lookup?

Virustotal Detected Trojan Malware for log4shell_1.3.0-log4shell_Windows_x86_64.exe

Hi,
I ran this scanner through Virustotal which detects it as malicisous by 2 vendors. I realize it might be a false positive (as I seen before for MaxSecure eg) but anyway this might freak people out.

As I looked throught the details, however not sure what can done to fix this from developer point of view, but maybe at least some statement to the Community tab or README.md entry to address this would be beneficial.

Multi-domain SEO

2.16 vulnerable, expect 2.17

Hi it seems that news vulns have been found on 2.16
Not clear yet from what I read...

https://issues.apache.org/jira/plugins/servlet/mobile#issue/LOG4J2-3230

“Log4Shell Update: Second log4j Vulnerability Published” blog post uses incorrect property name which is confusing

The property/flag name should be formatMsgNoLookups​ but in several places throughout the post it’s slightly different:

You may still be vulnerable to Log4Shell (RCE) if you only enabled the noMsgFormatLookups flag

Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.

Issues when using log4j2.noFormatMsgLookup (>=2.10.0)

The server is still vulnerable even with log4j2.noFormatMsgLookup enabled because

log4j-api not impacted

The quoted statement below from https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/ is not correct. The log4j-api library is not affected by this vulnerability on it's own.

"This vulnerability affects anybody who's using the log4j packages (log4j-core, log4j-api, etc). That means it's primarily Java, but other languages like Scala, Groovy, or Clojure are also impacted."

See https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot for more information.

Integrate frontend styling feedback

Gonna leave these recommendations here for both of us to reference in the future:

Global

• Sidebar headings should be more distinct (uppercase? larger?)
• Breadcrumbs should be smaller
• Active vs inactive link colors should be consistent (sidebar active color is the same as the main content's inactive color)
• Dark mode slider needs to be overhauled
• Indentation in sidebar can be decreased to save space
• Adjust text sizing to use "clamp()" (font-size: clamp(3.5rem 6.5vw 6rem);, works better on ultrawide monitors)
• Icons are not aligned with text's horizontal axis

Project View

• Tab navigation in main content is inconsistent with the overall style of the UI
• "Click here" icon and text need better spacing

Vulnerabilities View

• Fields and dropdowns should be consistently sized
• Move user settings and dark mode slider to bottom of sidebar for space conservation
  • (We need to stick with a somewhat similar UX for what users expect, but maybe moving the dark mode slider to the Footer makes sense?)
• Move breadcrumbs to bottom of canvas for further space conservation
• Consider adding placeholder after "Project Access Tokens" for when no content is available to be displayed (likely out of date with the new pane)
• Typo: "drop-and-drop" instead of "drag-and-drop"
• User settings dropdown animation is probably too slow

CSS Changes to reference

// I'd recommend creating these variables for consistency
$color-link-active: #e9ecef;
$color-link-inactive: #adb5bd;
$color-background-active: #3F80EA;
$color-background-hover: $gray-100;

// Apply inactive color to sidebar links by default

a.sidebar-link {
color: $color-link-inactive;

  // Align icon with text baseline instead of descender, reduce space between icon and link text
  svg {
    margin-right: 0.5rem;
    margin-bottom: 0.075rem;
  }
}

// Apply link active color and changes active background color
a.sidebar-link-active {
font-weight: 500;
color: $color-link-active;
background-color: $color-background-active;

  // Applies background color to sidebar link hover
  &:hover {
    background-color: $color-background-hover;
  }
}

// Changes sidebar header styling to better differentiate from links
li.sidebar-header {
  font-size: 0.75rem;
  text-transform: uppercase;
  letter-spacing: 0.5rem;
  font-weight: 500;
}

// Aligns chevron when expanded
.sidebar [aria-expanded=true]:before, .sidebar [data-bs-toggle=collapse]:not(.collapsed):before {
  top:50%;
}

windows scanner returns invalid json format

lunasec version: log4shell_1.6.0-log4shell_Windows_x86_64.exe

I'm using the lunasec scanner in a Powershell script where I first find all .jar files with robocopy, and then scan each .jar file in a foreach loop with the scanner. I'm using the --json parameter to get the result in json so I can use Powershell's ConvertFrom-Json to get a Powershell object to work with.

The issue is that the json result I get back is not valid and ConvertFrom-Json throws a invalid json primitive error

I think the issue is that the data return are two json objects, but they are not in an array.
eg.

{"level":"info","searchDirs":["D:\\blah\\blah\\blah\\lib\\log4j-core-2.11.1.jar"],"excludeDirs":[],"time":1641992600,"message":"Scanning directories for vulnerable Log4j libraries."} {"severity":"10.0","path":"D:\\blah\\blah\\blah\\lib\\log4j-core-2.11.1.jar","versionIndicatorFileName":"org/apache/logging/log4j/core/net/JndiManager.class","versionIndicatorHash":"293d7e83d4197f0496855f40a7745cfcdd10026dc057dfc1816de57295be88a6","jndiLookupFileName":"org/apache/logging/log4j/core/lookup/JndiLookup.class","jndiLookupHash":"0f038a1e0aa0aff76d66d1440c88a2b35a3d023ad8b2e3bac8e25a3208499f7e","versionInfo":"2.10.0, 2.11.0, 2.11.1, 2.11.2, 2.9.0, 2.9.1","cve":"CVE-2021-44228","time":1641992600,"message":"Identified vulnerable path"}

Would be nice if there was a way to exclude the "Scanning directories for vulnerable Log4j libraries." info message object in the json result. Makes it easier to use in a script and parse.

False positive between 2.14.1 and 2.15.0/2.16.0

It looks like we're hashing a file that's the same between these versions, and that's creating a false positive for people.

This was introduced when we started generating the hashes ourselves from files off of Maven vs using hashes from this repo.

Fix is to find files that hash to different values for each of these versions, which I'm going to do manually now and then cut a release. Opening this issue to track it in case somebody runs into this.

Twitter link not working anymore

Hi, I noticed the Twitter link provided in the Lunasec article is not working anymore https://www.lunasec.io/docs/blog/log4j-zero-day/#:~:text=The%200%2Dday%20was%20tweeted%20along.

v 1.3 does not detect CVE-2019-17571 anymore.

v 1.2 finds correctly (1.1.2)
cve: CVE-2019-17571
fileName: org/apache/log4j/net/SocketNode.class
path: "c:\Users\Public\IBM\ClientSolutions\acsbundle.jar::lib/log4j-1.2.17.jar"
severity: 9.8
versionInfo: "log4j 1.2.17"

Where v1.3 does not find anything.?

VirusTotal shows 4 security vendors flagged this file as malicious

4/67 scanners report a Trojan.
Cylance
Unsafe
MaxSecure
Trojan.Malware.300983.susgen
Rising
[email protected] (RDML:fGe6bRIqDvA/1X3XGGuFkg)
SecureAge APEX
Malicious

Please review.

Query regarding vulnerable class file in log4j2

Hi,

I was using latest release of log4shell tool to scan hive metastore. It shows that there is one log4j-core-2.8.2.jar.

I referred mitigations published on apache log4j website. There its mentioned:

Implement one of the following mitigation techniques:

- Java 8 (or later) users should upgrade to release 2.16.0.
- Java 7 users should upgrade to release 2.12.2.
- Otherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: 
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

I removed JndiLookup.class but tool still gives / rather shows vulnerable file. Only after removing JndiManager.class does the vulnerability goes away. Can someone please clarify do we have to remove both classes or just JndiManager.class ?

sh-4.4# ./log4shell_1.4.1-log4shell_Linux_x86_64 scan --ignore-warnings /opt/apache-hive-metastore-3.0.0-bin/lib/
2:12PM Scan Result: Identified vulnerable path
	cve: CVE-2021-44228
	fileName: org/apache/logging/log4j/core/net/JndiManager.class
	hash: 764b06686dbe06e3d5f6d15891250ab04073a0d1c357d114b7365c70fa8a7407
	path: /opt/apache-hive-metastore-3.0.0-bin/lib/log4j-core-2.8.2.jar
	severity: 10.0
	versionInfo: 2.8.2
sh-4.4#

sh-4.4# jar tvf /opt/apache-hive-metastore-3.0.0-bin/lib/log4j-core-2.8.2.jar | grep -i jndi
  2974 Sun Apr 02 15:24:22 UTC 2017 org/apache/logging/log4j/core/lookup/JndiLookup.class
  4197 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/net/JndiManager.class
  1890 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/net/JndiManager$JndiManagerFactory.class
  4948 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/selector/JndiContextSelector.class
   249 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/net/JndiManager$1.class
   800 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/util/JndiCloser.class

sh-4.4# zip -q -d /opt/apache-hive-metastore-3.0.0-bin/lib/log4j-core-2.8.2.jar \*/JndiLookup.class

sh-4.4# jar tvf /opt/apache-hive-metastore-3.0.0-bin/lib/log4j-core-2.8.2.jar | grep -i jndi
  4197 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/net/JndiManager.class
  1890 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/net/JndiManager$JndiManagerFactory.class
  4948 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/selector/JndiContextSelector.class
   249 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/net/JndiManager$1.class
   800 Sun Apr 02 15:24:24 UTC 2017 org/apache/logging/log4j/core/util/JndiCloser.class

sh-4.4# ./log4shell_1.4.1-log4shell_Linux_x86_64 scan --ignore-warnings /opt/apache-hive-metastore-3.0.0-bin/lib/
2:17PM Scan Result: Identified vulnerable path
	cve: CVE-2021-44228
	fileName: org/apache/logging/log4j/core/net/JndiManager.class
	hash: 764b06686dbe06e3d5f6d15891250ab04073a0d1c357d114b7365c70fa8a7407
	path: /opt/apache-hive-metastore-3.0.0-bin/lib/log4j-core-2.8.2.jar
	severity: 10.0
	versionInfo: 2.8.2
sh-4.4#

sh-4.4# zip -q -d /opt/apache-hive-metastore-3.0.0-bin/lib/log4j-core-2.8.2.jar \*/JndiManager.class
sh-4.4# ./log4shell_1.4.1-log4shell_Linux_x86_64 scan --ignore-warnings /opt/apache-hive-metastore-3.0.0-bin/lib/
sh-4.4#

CVE-2021-45046 advise vs. scanner results

Hi

In https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046, it is advised to remove org/apache/logging/log4j/core/lookup/JndiLookup.class however, I do not see this file in your scanner.
Also, I see a lot of other files present, is this an alternative way to fix the problem or is the advise in CVE-2021-45046 incorrect?

All ouput is sent to STDERR instead of STDOUT

As of version 1.3.0 on Linux (log4shell_1.3.0-log4shell_Linux_x86_64), the entire output is always sent to STDERR instead of STDOUT, so it's not possible to ignore warnings and errors to get a clean output of the results.

Example:

[root@7810801a658a tmp]# ./log4shell --json scan /usr/share/elasticsearch/lib 2> /dev/null
[root@7810801a658a tmp]# ./log4shell --json scan /usr/share/elasticsearch/lib 1> /dev/null
1:54PM ??? Identified vulnerable path
cve: CVE-2021-44228
fileName: org/apache/logging/log4j/core/lookup/JndiLookup.class
hash: 0f038a1e0aa0aff76d66d1440c88a2b35a3d023ad8b2e3bac8e25a3208499f7e
path: /usr/share/elasticsearch/lib/log4j-core-2.9.1.jar
severity: 10.0
versionInfo: "2.10.0, 2.11.0, 2.11.1, 2.11.2, 2.9.0, 2.9.1"

I would be expecting that the line with 2>/dev/null would return me the result, but it's the opposite.

Frontend Analytics

start with simple analytics and then choose a session replay thing as well, free is narrowing down the choices

how to uncompress the file

Good day,
once I download the file log4shell_1.4.1-log4shell_Linux_x86_64
for linux,
how do I uncompress it? it comes with no extension,
thank you very much

Clarification please : Vulnerable path in example from Section 3

Hi,

Need a clarification regarding the vulnerable log4j detected example under the section 3 "Determine if you are impacted by log4shell"

Please can you clarify if the MessagePatternConverter class is also to be removed in addition to JndiLookup.

Thanks in advance!

Confusing inclusion of log4j 1.2.x file hashes

Thanks for the work on the log4shell tool 👍

Currently the log4shell tool here appears to flag hashes of SocketNode from 1.2.x alongside all of the vulnerable log4j 2.x classes.

lunasec/tools/log4shell/constants/vulnerablehashes.go

Lines 64 to 73 in 5252c62

	"6adb3617902180bdf9cbcfc08b5a11f3fac2b44ef1828131296ac41397435e3d": "log4j 1.2.4", // SocketNode.class
	"3ef93e9cb937295175b75182e42ba9a0aa94f9f8e295236c9eef914348efeef0": "log4j 1.2.6-1.2.9", // SocketNode.class
	"bee4a5a70843a981e47207b476f1e705c21fc90cb70e95c3b40d04a2191f33e9": "log4j 1.2.8", // SocketNode.class
	"7b996623c05f1a25a57fb5b43c519c2ec02ec2e647c2b97b3407965af928c9a4": "log4j 1.2.15", // SocketNode.class
	"688a3dadfb1c0a08fb2a2885a356200eb74e7f0f26a197d358d74f2faf6e8f46": "log4j 1.2.16", // SocketNode.class
	"8ef0ebdfbf28ec14b2267e6004a8eea947b4411d3c30d228a7b48fae36431d74": "log4j 1.2.17", // SocketNode.class
	"d778227b779f8f3a2850987e3cfe6020ca26c299037fdfa7e0ac8f81385963e6": "log4j 1.2.11", // SocketNode.class
	"ed5d53deb29f737808521dd6284c2d7a873a59140e702295a80bd0f26988f53a": "log4j 1.2.5", // SocketNode.class
	"f3b815a2b3c74851ff1b94e414c36f576fbcdf52b82b805b2e18322b3f5fc27c": "log4j 1.2.12", // SocketNode.class
	"fbda3cfc5853ab4744b853398f2b3580505f5a7d67bfb200716ef6ae5be3c8b7": "log4j 1.2.13-1.2.14", // SocketNode.class

Personally, I don't think it's wise to mix these together and is likely to cause confusion - and confusion is probably not what we need as a community to get the right effort into the highest risk places.

As noted in hillu/local-log4j-vuln-scanner#11 (seems to be the upstream source of the hashes, based on the comment) while Log4j 1.x is vulnerable to an RCE in CVE-2019-17571 and is EOL (should be replaced/upgraded on that basis as well as the CVE), that specific CVE does require usage of log4j 1.x in a particular way that is very different and not common (use of the SocketServer) and thus rather different to the 2.0 >= log4j <= 2.14 CVE-2021-44228 risk of "log a message with a particular formatted string and you're at high risk of RCE".

I would suggest either highlighting the specific vulnerability each hash might correspond to, or separate the v1 flagging as they seem to have done in the upstream project (recently).

How to run log4shell_1.4.2-log4shell_Linux_x86_64

Hi,
can you please advice on how to run this file?
It has non extention, i should be .tar.gz.
Thank you.

Organization home page

zerolog dependency

Hi.

The log4shell scanner tool is easily auditable, except for this odd dependency on zerolog:

https://github.com/lunasec-io/lunasec/blob/master/tools/log4shell/scan/scan.go#L23

I'm torn between laughter and sadness. Popularity of that logging library is definitely not an indicator of safety. After all, that's why this tool exists in the first place.

Is this really needed? Couldn't the standard library log be used instead?

Confusing statements about log4j 2.15.0 still being vulnerable to RCE

In the article https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/, it is written

In this case, you must upgrade to 2.16.0 or else you will still be vulnerable to RCE.

The mention of possible RCE is unfortunately missing from the published CVE. In the CVE it only mentions a possible "Denial-of-Service" attack for versions prior to 2.15.0.

However, the remainder of the article only calls out versions up until 2.14.1 to be vulnerable for RCE.
Please mention in the article for which scenario 2.15.0 is still vulnerable for RCE, or correct the above statements.

Thanks!

add "--exclude" to ignore paths like /proc

is it possible to add an "--exclude" parameter to exclude paths like /proc on unix machines

Project home dashboard

Show information about the project, including info like GitHub URL, Repo Name, metrics, etc.

log4j scanner quits when it hits the first CVE

I ran log4j scan against my lab where I ran old log4j v1.2.9.
This old log4j was vulnerable to CVE-2019-17571 and the tool correclty detected it.

However, I was hoping it will flag the new CVE-2021-44228, but it did not.
I presume the tools was programmed to exit as soon as it finds the first CVE?

It would be great if it continued to run and list all CVEs that are applicable.
Or did I missed something?
Thanks

Log4j RCE isn't real

https://github.com/lunasec-io/lunasec/blob/ef796b71cdcd20bb403c82bc2db4d3d685105616/docs/blog/2021-12-09-log4j-zero-day.md
This doesn't actually do anything useful. The file is never actually downloaded and would not be executed in any sane setup.

Main logged-in homepage dashboard/splash page

Chris is working on github app stuff that will go here.

Title card, docs links, getting started buttons

Idea: show most recently viewed projects, write them to localstorage

WRN unable to open archive

Many jar make this error
WRN unable to open archive error="zip: not a valid zip file"
It's possible to know why ? Manual unzip it and launch the tool on unzipped dir can be a workaround ?

Dedicated tutorial/ docs

This should be in the existing docusaurus under a new tab just for lunatrace.

Do this once MVP is finished so that UX doesnt change and need to be redocumented

• Add LunaTrace docs folder
• Migrate existing LunaDefend docs
• Fix broken links to old docs with 301 redirects
• Put both LunaDefend and LunaTrace on top nav bar

.ear package files

I see a reference to the scanning of war, jar and zip files. Does the scan also reads the contents of Ear files?

Log4j fix with %m{nolookups} works only after version 2.7

According to our research feature "{nolookups}" appeared in log4j only after version 2.7. Here is part of confirmation https://stackoverflow.com/questions/27103400/log4j2-how-to-disable-date-lookup-log4j-throws-exception

Also we have tested on own application and found that fix with %m{nolookups} does NOT work on log4j version 2-2.6* and start to work only after 2.7. Please post this on your blog page.

Thanks,
Dmytriy

Panic created when executing lstat on a file/directory which doesn't exist.

Issue found on 1.4.0 release

Allow Log4Shell to patch Log4j1

The patch option is a convenient way to remediate our vulnerabilities without having to change a bunch of versions etc. However, it would be nice to patch Log4j 1 vulnerabilities as well so everything can be patched easily all at once.

I propose adding the --include-log4j1 flag to the patch command that does the same thing it does for scan, adds log4j1 to the recognized vulnerabilities so they can be patched also.

Log4Shell scanner memory utilization

Log4Shell scanner consumes a lot of memory. I saw it as high as 18Gb of resident use.
It appears to depend on a number of .jar's it processes. Does it not release memory after each archive?

Measured by /usr/bin/time -v ./log4shell s /
Maximum resident set size (kbytes): 17572356

Some systems just don't have that much memory available which leads to OOM.

linux, v1.4.1-log4shell

No detection of log4j repackaged inside shaded jar

The efficiency of checksum comparison has one downside: it does not find tools that repackage log4j.

For instance Elastic java agent version 1.28.0 is vulnerable (See announcement here) but not detected.
From what I found out the 1.28.0 agent repackages log4j and changes the packages which results in a new class.

Do you think this class and similar ones should be added to the checksum list? IMO it serves the purpose of the tool (great job BTW)

Make Oathkeeper frontend routes less fragile

Oathkeeper routes can break in certain situations because the regex could colide with a legit route

Json output on windows - path issues

On Windows the path contains double \ instead of a single one. c:\folder\lib instead or c:\folder\lib.

 {
                        "path": "c:\\Users\\oli\\Downloads\\test.war::WEB-INF/lib/log4j-core-2.13.3.jar",
                        "file_name": "org/apache/logging/log4j/core/net/JndiManager.class",
                        "hash": "c3e95da6542945c1a096b308bf65bbd7fcb96e3d201e5a2257d85d4dedc6a078",
                        "version": "2.13.0, 2.13.1, 2.13.2, 2.13.3",
                        "cve": "CVE-2021-44228",
                        "severity": "10.0"
},

False positive Log4J Checks - JndiLookup.class

Hi,

The constants for Log4J vulnerability are looking at the hash of the JndiLookup.class which was actually not modified between versions 2.15 and 2.16. This results in a false positive saying that the version 2.16 (up to date) of the class is still at 2.15 and stating that this is a vulnerability which is wrong.

Files

• constant fill to remove JndiLookup.class verification

When checking the hash on both 2.15 and 2.16 you can see the JndiLookup.class files are identical:

md5 JndiLookup16.class 
MD5 (JndiLookup16.class) = 737b430fac6caef7c485c9c47f0f9104

bash-3.2$ md5 JndiLookup15.class 
MD5 (JndiLookup15.class) = 737b430fac6caef7c485c9c47f0f9104

Files for checks:

• 2.15
• 2.16

Let me know if you have any question!

Integrated tutorialization and tooltips

Critical path should all be hand-holded in a non-obtrusive way.

Returning from github app install, users may be lost.

Follow along tutorial page:

• example project that people can OPTIONALLY import and use for testing
  • Java - Using CLI
  • Node

SBOM Generator Web Tool

A separate page accessible from both logged in/not logged in views. Needs to be accessible to people landing on the site but also not distract/confuse users investigating and signing up for the full product

Windows version of tool is outputing to sterr and not possible to change

I'm trying to pack this tool together with a PowerShell script to run on multiple computers.
However the output is sent to the sterr output stream and so i cannot capture it properly.

Right now i have to redirect the error stream to the success stream (using 2>&1) to handle it.
But this really should be unnecessary.

The --json flag does not seem to change anything (or the instruction for use is unclear).
Both of these will just output the "pretty print" (which is a pain to parse...)
.\log4shell_1.1.2-log4shell_Windows_x86_64.exe --json scan "C:\"
.\log4shell_1.1.2-log4shell_Windows_x86_64.exe scan "C:\" --json

POM project 12:00PM | warn | Unable to parse semver version

Describe the bug
Lot's of lines like

12:00PM | warn | Unable to parse semver version
        fileName: spring-web-5.2.14.RELEASE
        semverVersion:

when analyzing spring-boot project root with pom.xml

Expected behavior
Clean log.

Desktop (please complete the following information):

• Win 10 + WSL Ubuntu 20.04
• N/A
• 1.4.2

hashes are not correct

mubix/CVE-2021-44228-Log4Shell-Hashes#3

I can personally tell you I found the same thing - downloaded jars from maven did not match the hashes.

Attached the ones I downloaded from search.maven.central before I brutally ripped the jndi lookup class out.

test thing by forrest

--json option doesn't do anything

As of version 1.3.0 on Linux (log4shell_1.3.0-log4shell_Linux_x86_64), the --json option doesn't change anything in the output. It's not displayed as json at all.

Example:

[root@7810801a658a tmp]# ./log4shell --json scan /usr/share/elasticsearch/lib
1:45PM ??? Identified vulnerable path
cve: CVE-2021-44228
fileName: org/apache/logging/log4j/core/lookup/JndiLookup.class
hash: 0f038a1e0aa0aff76d66d1440c88a2b35a3d023ad8b2e3bac8e25a3208499f7e
path: /usr/share/elasticsearch/lib/log4j-core-2.9.1.jar
severity: 10.0
versionInfo: "2.10.0, 2.11.0, 2.11.1, 2.11.2, 2.9.0, 2.9.1"

Banner suggestion for the third Log4Shell blog post

I propose that you make Log4Shell logo worse with each time a new vulnerability in it

This is the supposed third Log4Shell logo

Test end-to-end deployment flow in Production

• Deploy new changes
• Add new env vars + secrets to Secrets Manager
• Verify no local dev constants are hardcoded
• Test GitHub App Webhooks and Callbacks
• Migrate to newest Kratos DB schema
• Migrate Hasura database

Ignoring files with error "not a valid zip file"

Is it possible to suppress all loglines with loglevel "WRN" and the logmessage "WRN unable to open archive error="zip: not a valid zip file" ?

Integrated tutorialization and tooltips