High severity Log4J2 vulnerability disclosed...

Sinbad

Sinbad

Honorary Master
Joined
Jun 5, 2006
Messages
88,633
Reaction score
41,151
www.randori.com

QRadar SaaS | IBM

Palo Alto Networks recently completed the acquisition of IBM's QRadar Software as a Service (SaaS) assets. IBM continue to sale QRadar on-premises.
www.randori.com www.randori.com

Get patching....

Impact​

The Log4j 2 library is very frequently used in enterprise Java software. Due to this deployment methodology, the impact is difficult to quantify. Similarly to other high-profile vulnerabilities such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come. Due to the ease of exploitation and the breadth of applicability, we suspect ransomware actors to begin leveraging this vulnerability immediately.

Recommendation​

If you believe you may be impacted by CVE-2021-44228, Randori encourages all organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity. If anomalies are found, we encourage you to assume this is an active incident, that you have been compromised and respond accordingly.
 
Give the widespread impact, it would help if anyone could share things they've done to defend/mitigate against this vulnerability.

On my side, we've been finding where the vulnerable versions of LOG4J is running (v2.0-2.14.1) as well as assessing our perimeter for anything web-facing that could be susceptible to the exploits. This is done to possibly narrow the remediation scope.
IPS signatures have been updated and enabled.

Here's a useful GITHUB link with details on check to do to find if you're compromised: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Useful article from Tenable: https://www.tenable.com/blog/cve-20...che-log4j-remote-code-execution-vulnerability

The biggest challenge is that LOG4J 2.15.0 needs Java 8 before you can upgrade...
 
Last edited:
After spending most of my morning working on this I saw that AWS WAF covers this in one of their managed rule groups. Switched it on and boom, problem gone for the more common points of vulnerability.
 
SAguy said:
After spending most of my morning working on this I saw that AWS WAF covers this in one of their managed rule groups. Switched it on and boom, problem gone for the more common points of vulnerability.
Click to expand...

The AWS WAF is pretty awesome, I luckily didn’t have to do anything as I’ve been using the managed rules mentioned for mitigation.
 
SAguy said:
After spending most of my morning working on this I saw that AWS WAF covers this in one of their managed rule groups. Switched it on and boom, problem gone for the more common points of vulnerability.
Click to expand...
I wish it were that easy for me.

Some of their other rules in this group are causing issues with certain apps we use.
Also have many clients with their own infrastructure that we just host and support ESRI software on and that software uses log4j.
 
Patched in hours of the vulnerability been disclosed. Thankfully I only had one package that used log4j2.
 
PsYTraNc3 said:
I wish it were that easy for me.

Some of their other rules in this group are causing issues with certain apps we use.
Also have many clients with their own infrastructure that we just host and support ESRI software on and that software uses log4j.
Click to expand...
I actually found that their core rule groups were messing with SSO on one of our apps, gonna have to investigate that before rolling it out everywhere too.
 
w1z4rd said:
Patched in hours of the vulnerability been disclosed. Thankfully I only had one package that used log4j2.
Click to expand...
One of our apps was scary - you could literally throw a one liner into the username field on the login page and boom - you were lekker running remote commands.
 
SAguy said:
I actually found that their core rule groups were messing with SSO on one of our apps, gonna have to investigate that before rolling it out everywhere too.
Click to expand...
I also had an issue with on of our apps using Azure SSO.

We were using custom WAF rules, decided to switch to the core rule groups instead of updating the custom ones and then reverted and rather stuck to updating the custom rules after SSO and other issues popped up.
 
SAguy said:
One of our apps was scary - you could literally throw a one liner into the username field on the login page and boom - you were lekker running remote commands.
Click to expand...
${jndi:ldap://127.0.0.1/a} :D
 
And an interesting response to the above meme....


How is this a terrifying challenge? This is a trivial task for an application/build engineer.

"grep -r log4j" in a full enlistment of your source code.

Do you let your devs test and release their own code? What about monkeys?

How is this *routine release engineering practice* suddenly some horror of darkness and despair?

Because *you* allowed *your org* to violate IEEE SDLC standards and segregation of roles in development. Because *you* allowed *your org* to release a single char of code without aggressive, independent quality assurance.

Don't start whining now about the disaster *you* allowed to happen because *you* don't know how to find a string in a million lines of code.

Every single engineer you passed over because they were "overqualified" or "too old to be a good team fit" is laughing at this absolutely avoidable disaster.
 
AWS WAF is a "compliance WAF", totally kak. Roll your own,
 
Sinbad said:
And an interesting response to the above meme....


How is this a terrifying challenge? This is a trivial task for an application/build engineer.

"grep -r log4j" in a full enlistment of your source code.

Do you let your devs test and release their own code? What about monkeys?

How is this *routine release engineering practice* suddenly some horror of darkness and despair?

Because *you* allowed *your org* to violate IEEE SDLC standards and segregation of roles in development. Because *you* allowed *your org* to release a single char of code without aggressive, independent quality assurance.

Don't start whining now about the disaster *you* allowed to happen because *you* don't know how to find a string in a million lines of code.

Every single engineer you passed over because they were "overqualified" or "too old to be a good team fit" is laughing at this absolutely avoidable disaster.
Click to expand...
The reality is that nobody owns the code for every application in their environment.
How are you going to search through the source code for SAP, CRM, Tableau, etc?
 
RonSwanson said:
AWS WAF is a "compliance WAF", totally kak. Roll your own,
Click to expand...
AWS WAF with custom rule groups ticks most boxes. If you're just just using managed rule groups then yes, you're just doing it to tick the compliance box.
 
SAguy said:
The reality is that nobody owns the code for every application in their environment.
How are you going to search through the source code for SAP, CRM, Tableau, etc?
Click to expand...
Yup, there is this as well.

However, it should be easy enough to find for those apps. The way I audited our stuff was to search disks for the log4j2 libraries, and if they were present in an app (regardless of whether they were used), implement the no-formatting mitigation.
 
Sinbad said:
Yup, there is this as well.

However, it should be easy enough to find for those apps. The way I audited our stuff was to search disks for the log4j2 libraries, and if they were present in an app (regardless of whether they were used), implement the no-formatting mitigation.
Click to expand...
Yip, and then add to that other 3rd party hosted solutions that have integrations into your environment - and the provider hasn't mitigated.

Definitely agree that in house code should be a non event, but that is just the tip of the iceberg in terms of the witch hunt required for this vulnerability.
 
Yussis, now 2.17.0 is also found with an RCE vulnerability.
www.bleepingcomputer.com

Log4j 2.17.1 out now, fixes new remote code execution bug

Apache has released another Log4j version, 2.17.1 fixing a newly discovered remote code execution (RCE) vulnerability in 2.17.0, tracked as CVE-2021-44832. Prior to today, 2.17.0 was the most recent version of Log4j and deemed the safest release to upgrade to, but that advice has now evolved.
www.bleepingcomputer.com www.bleepingcomputer.com
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X