Dec 21 2021

Apacheā€™s other product: Critical bugs in ā€˜httpdā€™ web server, patch now!

Category: Web Security — DISC @ 11:37 am
Apache’s other product: Critical bugs in ‘httpd’ web server, patch now!

Pick a random person, and ask them these two questions:

Q1. Have you heard of Apache?
Q2. If so, can you name an Apache product?

Weā€™re willing to wager that you will get one of two replies:

A1. No. A2. (Not applicable.)
A1. Yes. A2. Log4j.

Two weeks ago, however, weā€™d suggest that very few people had heard of Log4j, and even amongst those cognoscenti, few would have been particularly interested in it.

Until a cluster of potentially catastrophic bugs ā€“ originally implemented as features, on the grounds that less is never more ā€“ were revealed under the bug-brand Log4Shell, the Log4j programming library was merely one of those many components that got sucked into and used by thousands, perhaps even hundreds of thousands, of Java applications and utilities.

Log4j was just ā€œpart of the supply chainā€ that came bundled into more back-end servers and cloud-based services than anyone actually realised until now.

Many sysdamins, IT staff and cybersecurity teams have spent the past two weeksĀ eradicating this programmatic plagueĀ from their demesnes. (Yes, thatā€™s a real word. Itā€™s pronouncedĀ domains, but the archaic spelling avoids implying a Windows network.)

Donā€™t forget ā€œthe other Apacheā€

Tags: Apache HTTP Server, Apache patch, critical bug

Dec 11 2021

Cybereason released Logout4Shell, a vaccine for Log4Shell Apache Log4j RCE

Category: Cyber Threats,Cyberweapons,Web Security — DISC @ 12:48 pm
Cybereason released Logout4Shell, a vaccine for Log4Shell Apache Log4j RCE

Chinese security researcher p0rz9 publicly disclosed a Proof-of-concept exploit for a critical remote code execution zero-day vulnerability, tracked a CVE-2021-44228 (aka Log4Shell), in the Apache Log4j Java-based logging library.

The Log4j is widely used by both enterprise apps and cloud services, including Apple iCloud and Steam.

A remote, unauthenticated attacker can exploit the CVE-2021-44228 to execute arbitrary code on a vulnerable system leading to a complete system takeover.

The vulnerability was discovered by researchers from Alibaba Cloudā€™s security team that notified the Apache Foundation on November 24. According to the experts, the vulnerability is easy to exploit and does not require special configuration, for this reason, it received a CVSSv3 score of 10/10. Researchers pointed out that Apache Struts2, Apache Solr, Apache Druid, Apache Flink are all affected by this vulnerability.

Now researchers from cybersecurity firm Cybereason have released a script that works as a ā€œvaccineā€(dubbed Logout4Shell) that allows remotely mitigating the Log4Shell vulnerability by turning off the ā€œtrustURLCodebaseā€ setting in vulnerable instances of the library.

ā€œWhile the best mitigation against this vulnerability is to patch log4j to 2.15.0 and above, in Log4j version (>=2.10) this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath. Additionally, if the server has Java runtimes >= 8u121, then by default, the settings com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase are set to ā€œfalseā€, mitigating this risk. However, enabling these system property requires access to the vulnerable servers as well as a restart.ā€ reads the GitHub Page set up for the Log4Shell project.

Cyberreson experts pointed out that enabling these system property requires access to the vulnerable servers, and the servers have to be restarted. 

A zero-day exploit for Log4j Java library could have a tsunami impact on IT giants

Defensive Security Handbook: Best Practices for Securing Infrastructure

Tags: Apache patch, Defensive Security, Log4j, Log4shell

Oct 08 2021

Apache patch proves patchy ā€“ now you need to patch the patch

Category: Security vulnerabilities — DISC @ 9:21 am
Apache patch proves patchy – now you need to patch the patch

Software patches are sometimes a bit like buses.

You donā€™t get one for a while, and then three come at once.

For buses on busy urban routes, at least, the explanation of the phenomenon goes something like this.

If three buses start out travelling the same route together in a nicely spaced sequence, then the first one is most likely to be the slowest, because it will be stopping to scoop up most of the waiting passengers, while the ones behind will tend to travel faster because they need to stop less often or for shorter periods.

So buses naturally tend to scrunch up and arrive in bursts.

Burst-mode software patches

When it comes to software patches, however, the problem often works the other way around.

If the first patch arrives too quickly, then it may not have been reviewed or tested quite as much as you might like.

So itā€™s not so much that the next patch in the queue catches up because the first one is too slow, but that the next one has to be completed in a rush to keep upā€¦

ā€¦and, if you arenā€™t careful, then that second patch might itself beget a third patch, needed to patch the patch that patched the first patch.

Three Apache buses

And thus with Apache: just two days ago, we reported aĀ path validation bugĀ dubbedĀ CVE-2021-41773Ā that was introduced in Apache 2.4.49:

Apache web server zero-day bug is easy to exploit – patch now!

We advised you to update to 2.4.50, which would indeed have protected you against at least some of the known exploits already circulating on Twitter.

Tags: Apache patch