Author: Andrew Mikhaliuk, CEO of CoreWin
Last Friday seemed to end quietly, but only at first glance. Some people experienced glitches with LinkedIn, while others faced issues with their email client disconnecting frequently. However, most of us dismissed these as minor inconveniences and headed into the weekend without concern. Log4Shell is the biggest vulnerability of the year. At the end of the article, I will share my own developments for checking the service for vulnerabilities.
On Saturday, dear colleagues, some of us greeted the day with heavy hearts. News of a new vulnerability, Log4Shell, began to spread worldwide. Some rushed to the office on Saturday for emergency response. Others started addressing the issue as early as Friday. It quickly became clear to everyone in the IT world: cybercriminals had left us an unpleasant gift under the Christmas tree. That gift included sleepless nights and a dire need for strong doses of tranquilizers.
To understand why the news about the log4j library vulnerability has made so much noise, it’s worth diving a little deeper into the essence of this library, or even the framework.
The first factor:
The library is distributed under the Apache license, which means it is free.
The second factor:
It is a solution for Java development.
The third factor:
This library is essential for logging, in other words, recording system and other program actions.
Let’s break down why each of these factors led to a big BOOM!
1. Apache License
This license allows the library to be freely used for any purpose, with no restrictions on the number of copies distributed. Additionally, the license does not require maintaining the original licensing terms for redistributed software, nor does it insist on keeping the software free and open-source. The only condition imposed by the Apache License is to inform recipients that the source code they are using is licensed under the Apache License. Simply put, you can take this library, use it in your solution, apply a proprietary license to the final product, and legitimately earn revenue from it.
2. It is a Java development tool
Java is the unofficial leader in the large enterprise market. Here are a few reasons:
- It is an old language, and plenty of corporate systems are written in it because it happened so (the so-called legacy systems), which means that solutions written in Java have an advantage over others
- Java has numerous open-source libraries, and not only ready-to-use libraries (yes, such as log4j), which means that you do not have to reinvent the wheel and can focus on innovation
- After all, Java has proven itself very well on a large scale, which is, in fact, the definition of a corporate client
3. Logging
No matter what your developers write, no matter what the application is, there will be logs. Without logs, it’s almost impossible to debug, software without a log is a car without headlights on a country road at night. It seems to be driving, but everyone realizes that sooner or later, it will crash into a tree.
We don’t have any statistics on how many corporate services have this library as part of their structure. However, rest assured that we are saying that almost every large organization faced this problem this weekend.
For example, one study found 10,000 servers to be vulnerable. Most of them are in the United States, which has historically used many legacy technologies.
A little bit of memes
In addition, this library was used in very popular components such as Apache Struts or ElasticSearch, so the attack surface was and still is incredible. This situation is best illustrated by a meme from the past.
Now let’s dive into the technology a bit
For obvious reasons, in this article, I will not describe in detail the technology and the causes of the vulnerability, nor how it can be exploited for malicious purposes. But let’s look at some of the features of this vulnerability.
1. This vulnerability is easy to exploit
In fact, to exploit it, you need nothing more than a laptop with any OS, Internet access, and basic console skills (whether cmd or shell, it doesn’t matter). By the time Saturday rolled around, you didn’t even need any knowledge. YouTube already had videos on how to exploit the vulnerability (already blocked at the time of publication), and GitHub had ready-made jar packages for use in one command (already deleted at the time of publication).
2. This vulnerability provides VERY deep access to the server
Objectively, with skillful use, you can send any command to the operating system level, and it will be executed.
3. This vulnerability is very flexible
In fact, it can be used to do anything with a server. You can infect it, join it to a botnet, quietly plant spyware, encrypt data, use it as an intermediate link to gain further access or whatever.
We know that this vulnerability has been known to hackers since at least December 1st. But in my research, I’ve come across attack-ready packages with a note that they were downloaded 2 years ago. I can’t judge how “working” they are, but the fact remains.
So, on Friday, a successful attack on the Minecraft server took place, and the global community of both professional hackers and amateurs rushed to test their skills in the new tool. On Sunday, we already received reports that organized criminals have added this vulnerability to both their scanners and viruses. So, from being secret knowledge for a select few, these attacks have been added to the gray noise of constant mass attacks. BANG! Because a significant number of corporations were simply not ready for this attack, and that’s why we still receive information about new incidents.
Therefore, what to do?
- You need to promptly (if not already) conduct a detailed audit of not only the company’s services, but also analyze all their components. Make a list of which ones have log4j.
- Conduct a quick manual check of the most critical services and a black-box scan of all web services that have access to the Internet.
- Update or otherwise close this vulnerability (fortunately, all common solutions or components already have a hotfix and are preparing a bugfix).
- Review and clean up all services where the library was installed. You may already be under attack and not know it.
- Develop or use a platform that analyzes libraries and components of corporate solutions for vulnerabilities, at least existing ones, and ideally have a team that analyzes vulnerabilities at least on GitHub. For example, in this case, you would have known about the vulnerability since December and could have taken action before the massive attack.
Additional materials
To help my colleagues, I’m also sharing an open source, free vulnerability checker (посилання більше не дійсне) and instructions for reproducing the vulnerability in a test environment. Tested by myself as working.
