RCE in log4j, Log4Shell, or how things can get bad quickly

Published: 2021-12-10
Last Updated: 2021-12-10 17:08:13 UTC
by Bojan Zdrnja (Version: 1)
4 comment(s)

If you have been following developments on Twitter and various other security sources, by now you have undoubtedly heard about the latest vulnerability in the very popular Apache log4j library.

log4j is a very popular logging package for Java. It is very powerful and flexible and, even from my own experience, is used in almost every Java application that I have ever encountered. No wonder, it allows you to just create an instance of the log4j class and then easily use it for logging, based on provided configuration parameters (typically set in the log4j.properties file).

Yesterday a PoC for a Remote Code Execution vulnerability in log4j was published. The exploit is actually unbelievably simple – which makes it very, very scary at the same time.

The vulnerability is in the JNDI lookup feature of the log4j library. While the background around this is very complex, exploitation actually is not (as you will see below in couple redacted screenshots).

The JNDI lookup feature of log4j allows variables to be retrieved via JNDI - Java Naming and Directory Interface. This is an API that that provides naming and directory functionality to Java applications. While there are many possibilities, the log4j one supports (AFAIK) LDAP and RMI (Remote Method Invocation).

In other words, when a new log entry is being created, and log4j encounters a JNDI reference, it will actually literally go to the supplied resource and fetch whatever it needs to fetch in order to resolve the required variable. And in this process, it might even download remote classes and execute them!

Below is a simple initial PoC that demonstrates how the vulnerability can be exploited:

Vulnerable code

As you can see above, in order to initially exploit the vulnerability, an attacker just needs to literally supply the JNDI reference (the text you can see in the source code). When that input gets logged by log4j, it will parse the text, see the reference and try to resolve it. And this is where the problem really is.

Depending on the JNDI reference, the log4j library will now either perform an LDAP query or an RMI query to the target URL. This is where an attacker can use the marshalsec package by Moritz Bechler, available at https://github.com/mbechler/marshalsec

This package supports, among other things JNDI reference indirection – it allows an attacker to setup a server that will accept the incoming JNDI lookup (either LDAP or RMI) and then automatically create a redirection that will point the client (in our case the log4j library) to the target codebase. The library will then follow the redirection and visit the codebase server (which is accessed over the HTTP protocol), fetch a class that is served there and execute it! Scary.

The figure below shows the marshalsec package created a JNDI reference indirection server using the RMI protocol (to use a different one than the PoC). You can see that a client accessed the server and was redirected to a remote classloading stub where the final class is waiting to be executed.

marshalsec RMI

This final class is just a simple Java class that can execute anything that an attacker wishes to execute – here’s an example for the LDAP reference that will execute netcat to send a shell back to the attacker:

And really it is that simple (provided you can juggle your way around Java).

Now, you might wonder what is the impact of this? The one important thing to be aware of here is that *any application* that uses a vulnerable log4j version is affected. It does not matter if this is a server side application, or a client side application (!!!) – as long as it reads some input from an attacker, and passes that to the log4 library, there is an exploitation path, which means that even client side applications are potentially affected (and fixing might take months :/).

Since the cat is out of the bag, and due to exploitation being relatively simple, we would suggest that you try to apply one of the workarounds as soon as possible:

  1. A new log4j library has been released, version 2.15.0 that fixes the vulnerability. This is, of course, the best fix, but it might require recompilation and redistribution of packages
  2. If you are using version 2.10.0 you can set a property called formatMsgNoLookups to true to prevent lookups. This can be passed as a parameter too.
  3. For older versions you will need to modify logging patterns as specified here: https://issues.apache.org/jira/browse/LOG4J2-2109

Since the exploit requires the affected server/client to reach out to another server (that will supply the JNDI reference) on the Internet, the following actions can be performed:

  • As always, block any outgoing traffic that is not required. If you have a server running a Java application that only needs to accept incoming traffic, prevent everything outgoing.
  • If you do any traffic inspection, check for LDAP and RMI protocols.

Finally, as my fellow handler @xme noticed – this is already being exploited as part of a User Agent header:

I presume that these (simple) attackers are observing posted PoC exploits where one demo used the User Agent field, but we should stress out that *absolutely any input field* that is controlled by an attacker, and passed to the log4j library can lead to remote code execution.


[Update #1]

Based on the activity already captured by our honeypots and the amount of information about the vulnerability, we discussed and reviewed the InfoCon rubrik[1]. We decided to switch to the "Yellow" level until the situation will be clearer. Many vendors still have to investigate and fix the problem in their applications/systems.


[1] https://isc.sans.edu/infocon.html

Keywords: log4shell log4j
4 comment(s)

Python Shellcode Injection From JSON Data

Published: 2021-12-10
Last Updated: 2021-12-10 08:33:00 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

My hunting rules detected a niece piece of Python code. It's interesting to see how the code is simple, not deeply obfuscated, and with a very low VT score: 2/56![1]. I see more and more malicious Python code targeting the Windows environments. Thanks to the library ctypes[2], Python is able to use any native API calls provided by DLLs.

The script is very simple, so here is the full code:

import ctypes,urllib3,base64,json
  y={'Content-Type':'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) ',"Origin":'hxxps://txtpad[.]cn',}
except Exception as e:

Note the strange HTTP header "Content-Type" that contains a User-Agent!?

If you're familiar with code injection in Windows, you can quickly spot the magic combination of classic API calls:

  • kernel32.VirtualAlloc (with the "0x40")
  • kernel32.RtlMoveMemory
  • kernel32.CreateThread
  • kernel32.WaitForSingleObject

The shellcode is downloaded from a website and, based on the references to "json.loads" and "b64decode", we can guess that it's hidden in a JSON structure. When you visit the URL, you get this data back (beautified):

        \"content\":\"YiJceGZjXHg0OFx4 ... Content Removed ... NFx4NTNceGU1XHhmZlx4ZDVceDQ4XHg5M

The "content" variable contains the shellcode. It is extracted and injected.

Note that the shellcode is Base64-encoded but also hex-encoded. The shellcode phones home to http://150[.]158[.]39[.]215/x9Ic (a classic Cobalt Strike[3]).

[1] https://www.virustotal.com/gui/file/a848d43eae6518569edb17158a9a127167051266dd406acbb963d1330a9ffefc/detection
[2] https://docs.python.org/3/library/ctypes.html
[3] https://isc.sans.edu/forums/diary/Finding+Metasploit+Cobalt+Strike+URLs/27204/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant

0 comment(s)
ISC Stormcast For Friday, December 10th, 2021 https://isc.sans.edu/podcastdetail.html?id=7790


eweew<a href="https://www.seocheckin.com/edu-sites-list/">mashood</a>
dwqqqwqwq mashood
[https://isc.sans.edu/diary.html | https://isc.sans.edu/diary.html]
What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission

Diary Archives