In recent days, the programmer friends of Shichao in various Internet factories have been tortured by an epic vulnerability called Log4Shell!
This vulnerability stems from a Java open source logging framework called Log4J2 (Log For Java 2), which can be said to be unknown to everyone in the code farmer group who use Java to knock code.
It's like the Bigfoot plugin that must be installed in World of Warcraft in the early years, it belongs to the real sense of "coffee companion", and few Java programs do not use this component.
It is such a terrible underlying log framework, which was found to penetrate a hole...
The first to discover the vulnerability was a big guy named Chen Zhaojun in the Alibaba Cloud security team.
According to him, this vulnerability was swept out by foreign security code scanning platforms very early, and the programmers in the circle are also waiting for the official fix, and there is no sound.
"The security architecture of millions of knives is worthless in the face of the Log4J2 vulnerability... ” ▼
Soon, including Ali, Tencent, Baidu, NetEase, Sina and other domestic Internet manufacturers have been shot, have been circled within the scope of the impact.
Some bloggers also received protection text messages from Tencent Cloud. ▼
Not only the service systems of large factories, but also hardware systems such as headphones, computers, and car machines are not spared...
It is no exaggeration to say that if this vulnerability is not patched in time, the end will be stabbed by hungry hackers, further threatening network security.
They will effectively exploit "zero-day vulnerabilities" (referring to security vulnerabilities that are maliciously exploited immediately after discovery) to launch zero-day attacks to kill servers before security patches come out.
Even the mobile phone and computer software we use every day (most of which is written in Java) will be exposed to the attack range of hackers, and it is not impossible to poke where you want to poke and take your computer hostage to mine.
It's like playing a game and stealing a house, so easy...
However, it is interesting that some people have taken advantage of this loophole to find that Tesla uploaded domestic data to the U.S. server.
I don't know if this data contains user data, but I suggest that Lung Ma Ge don't rush to explain this stubble, or quickly fix this loophole, otherwise it may be really bad when the time comes.
Cough, pull away...
Speaking of this vulnerability, the most terrible thing is that there is no threshold for implementation, as long as a simple string of characters is used, you can easily break the server and run all kinds of code on it...
This is not to mention stealing personal information, hackers want to remotely hijack and paralyze enterprise-level servers, that is also no obstacle.
So how did hackers exploit vulnerabilities and easily break through servers with a few strings of characters?
To understand this problem, we must first figure out what a log is.
As we all know, programmers can not use it immediately after typing a piece of code, but through repeated testing to verify the feasibility of the code.
But the code itself is in a black box state when it is running, and if it is allowed to run blindly, it will get stuck in the middle of the run, and it does not know which step is wrong.
It's like if you don't have scratch paper when doing math problems, you always have no bottom in your mind.
At this time, the role of the log is reflected, it is like a large piece of scratch paper, on which you can do any of your own understanding steps and marks, convenient for anytime, anywhere.
In essence, the log is a tool often used by programmers, which records every step of the code in the testing process, and when it is finished and then debugged, it is very targeted and efficient.
Log4J2 is such an open source logging framework, which integrates many common functions that will be used when modifying code, such as log management, output variables and other practical functions.
This high-risk vulnerability stems from a feature called Lookups in Log4J2.
Literally, this function is an interface for searching for content, and if you want to search for something, you have to rely on the code to achieve it.
Log4J2 also provides a lot of implementation paths under the function of Lookups, and the problem lies in this way called JNDI.
JNDI is allowed by Java to load files by connecting remotely, either to the developer's own server or to an outside server.
Bad is bad on this remote download...
As long as the hackers connect to their own malicious servers through JNDI methods, they can enter from this interface and then break through the entire impregnable building.
Here Shi Chao explained this loophole in the simplest possible terms, if the messengers are interested in the specific implementation method, you can see the article written by the big guy who knows the wind of the upper Xuanyuan, which is introduced in detail.
https : //zhuanlan.zhihu.com/p/444103520
So the question is, why did it take so long after this vulnerability was discovered before it was taken seriously?
Laymen look at the bustle, insiders look at the doorway, and some things really have to ask the industry insiders.
So Shichao consulted the well-known domestic white hat website - The little fire student of the Firewire security platform, and after a chat, he roughly understood the views of professionals on this matter.
In fact, the Log4J2 vulnerability was caused by some programmers wanting developers to keep the old functionality of the JNDI implementation in Lookups.
According to Volkan Yaz c, the maintainer of Log4J2, they had long wanted to give this risky feature, but in order to ensure backward compatibility, they took care of programmers who wanted to use the feature, so they kept it.
Well, the small hole is not filled, the big hole is suffering, after this high-risk vulnerability was discovered, the actual management agency of Log4J2, the Apache Software Foundation, did not attract enough attention, and the process of disclosing the vulnerability did not follow the process.
They posted the problem directly into the issue of the open source platform Github, expecting that someone with good intentions would give a solution to the problem.
But this is an open platform, there are programmers and hackers...
This wave of operations is equivalent to telling hackers around the world: "Our software has high-risk vulnerabilities Ha, welcome to poke!" ”
Even before the vulnerability broke out in full swing, white customers had already publicly discussed the specific fix details in the issue.
Unfortunately, it has been a long time since all business systems that use Log4J2 react to this vulnerability.
Because there is so much software that uses Log4J2 components, the security department of the Internet company needs to repair and upgrade the software one by one, and the workload here can be imagined.
At present, the fastest temporary processing solution is to do a trigger interceptor in Log4J2, similar to vaccinating the system first, blocking the content related to the vulnerability in advance, and the principle of the firewall is similar.
Having said that, Shichao feels that the pot that caused this vulnerability problem should not be all carried by the maintainers of Log4J2.
You may not believe it, such an open source project as Log4J2, in fact, only rely on a few programmers in the amateur event to manage and maintain, they themselves are also with love to generate electricity, without any compensation.
Comments from Volkan Yaz c twitter▼
On the contrary, including these large companies like Apple, Google, Amazon, Tesla, etc., are to a certain extent in the happy "white prostitute" Log4J2, after all, open source, can save a little manpower maintenance to save a little, anyway, there will always be someone to maintain...
For the developers of large factories, this tool from more than a decade ago, only a few people maintained, as long as the product can be completed, it will be used in order, and it will never be repeated to build wheels.
And strive to successfully jump ship before there is a problem...
It is conceivable that everyone has always "encountered a problem" for such a program security vulnerability, who knows that the entire industry has turned over.
Although the matter is over, such a large-scale loophole overturning incident is not the first time, nor will it be the last, and such "black swan events" are often unpredictable and accidental.
And this fire in the online world can only be extinguished by relying on the programmers' night battle to pick up the lights...
Special thanks: Firewire Security
Author: Ji Hao Editor: Xiao Xinxin, Jie Jie
Images, sources:
Weibo: @Programmers those things
Weibo: @Flanker_017
Weibo: @ Active Dry Rice Cat
Know: Nuclear bomb-level vulnerabilities! I'll show you log4j!
Xin Zhiyuan: Chinese programmers preemptively warned of "epic" bugs, sweeping Apple Tesla
Open Source China: Log4j Maintainer: Did not remove old features that caused vulnerabilities for backward compatibility
Twitter：@yazicivo
Mitigating the log4j Vulnerability (CVE-2021-44228) with NGINX