AcyMailing Securité

[cavo789]

Bonjour

Je viens de vérifier (cela fait un moment que je n'avais plus mis les mains dans aeSecure QuickScan) : le scanner va détecter l'utilisation des "$_COOKIES" qui est à la base de l'attaque des virus déposés via l'exploitation du trou de sécurité dans acyMailing.

Cela veut donc dire que si vous téléchargez le script aeSecure QuickScan https://github.com/cavo789/aesecure_quickscan que vous le sauvez à la racine de votre site web (le mieux étant de le faire depuis une copie en local; bien plus rapide), vous pourrez identifier les scripts php qui font appel à $_COOKIES et d'en recevoir une liste.

Pour chaque fichier trouvé, vous aurez non seulement sa localisation sur votre site (chemin d'accès) mais aussi une portion du code où le "pattern" a été trouvé (exemple : https://github.com/cavo789/aesecure_...us_of_mine.png). Cela vous permettra, sur base du nom (si c'est dans le dossier /media ou /images; déjà, c'est hyper suspect) ainsi que de la portion de code de comprendre si c'est un virus ou pas.

L'interface vous permettra alors de le supprimer si tel est votre choix. Attention toutefois aux faux positifs. Ne supprimez que si vous êtes sûr.
Le scanner est dit "QuickScan" car il se base sur des signatures (réelles de virus) mais aussi sur des patterns (comme "$_COOKIES"). La présence de "$_COOKIES" dans un code php n'est pas synonyme de virus; c'est une instruction, la plupart du temps, légitime.

Comment cela fonctionne ? Télécharger le fichier aesecure_quickscan.php et sauvez-le sur votre disque dur (localhost) ou sur votre serveur; cela à la racine de votre site web. Accédez au script aesecure_quickscan.php depuis une URL (http // votre_site/aesecure_quickscan.php). La première chose qu'il fera sera de télécharger certains fichiers de configuration depuis GitHub puis vous permettra de lancer le scan.

Bonne chasse aux morpions.

[herve]

Bonjour

...

Comment cela fonctionne ? Télécharger le fichier aesecure_quickscan.php et sauvez-le sur votre disque dur (localhost) ou sur votre serveur; cela à la racine de votre site web. Accédez au script aesecure_quickscan.php depuis une URL (http // votre_site/aesecure_quickscan.php). La première chose qu'il fera sera de télécharger certains fichiers de configuration depuis GitHub puis vous permettra de lancer le scan.

Bonne chasse aux morpions.

C'est ce que j'ai fais sur 2 sites en ligne. A chaque fois, rien ne se passe ni d'invitation à télécharger des fichiers complémentaires.
Est-ce possible que cela soit bloqué par l'hébergeur (PH et Gandi) ?

[cavo789]

Le téléchargement se fait automatiquement, zéro invitation à faire quoi que ce soit. As-tu reçu l'interface de l'application pour démarrer le scan ? Si oui, alors tout est bien là.

(Note: de mémoire, le téléchargement se fait dans un dossier qui est créé à l'occasion, nommé "aesecure". De mémoire car cela fait un bon moment que je ne l'ai plus utilisé moi-même)

[alatak]

Bonjour

Pour info, ils sont au courant depuis avant le 5 mai

https://forum.acymailing.com/d/4296-mysterious-new-thumbnails

[bisoox]

Bonjour,
Merci d'abord a tous pour votre veille active, cela nous donne des pistes de travail.
J'ai moi même 10 sites avec licence acymailing, et apparemment 4 sont infecté, dont 1 site ecommerce... youpi...

Je suis heureux de lire que l'utilisation d'akeeba admin tool limite la casse.

Suite à vos posts, j'ai nettoyé les fichiers infecté xxxx.php.png, mais je n'ai pas compris comment localisé et supprimé les fichier infecté par $_COOKIES.
J'ai essayé de mettre en place ton script @avo789, mais d'abord le lien que tu as mis vers github est en erreur 404, j'ai ensuite trouvé cette page : https://github.com/cavo789/aesecure_quickscan
J'ai essayer de le mettre en place, mais quand j'exécute le script aesecure_quickscan.php, j'ai une erreur 403 : Forbidden : You don't have permission to access this resource.

En tout cas merci à tous, en espérant que cela n'aura pas trop d'impact.
Assez déçu de la reactivité d'acymailing, et vu le temps passé a nettoyer et rechanger tous les mots de passe... ils pourraient nous offrir une année gratuite..

[woluweb]

Bonjour

Pour info, ils sont au courant depuis avant le 5 mai

https://forum.acymailing.com/d/4296-...new-thumbnails

Oh, c'est même depuis le 1er février.
Plus d'infos sur https://joomla.digital-peak.com/blog/we-got-hacked et tous les liens qu'Allon mentionne.

[jfque]

Comme j'aime bien comprendre comment fonctionne les choses, j'ai creusé un peu plus l'histoire de l'activation des fichiers "php.png" avec Nicholas Dionysopoulos d'où il ressort (à boudins... non, je m'égare) qu'à moins que votre hébergeur n'a pas tenu compte d'avertissements datant de 2001 sur le paramétrage d'Apache, l'interpréteur PHP n'exécute les fichiers se trouvant sur le serveur et se terminant par .php. Donc un fichier se terminant par .php.png ne sera jamais exécuté, sauf configuration erronée du serveur.

Pour vous assurer que votre serveur est bien configuré (et que vous ne devez donc pas fuir votre hébergeur incompétent), vous pouvez faire le test simple suivant :

• créer un fichier "test.php.txt" contenant juste la ligne suivante : <?php phpinfo();
• uploader ce fichier dans le dossier "images" de votre site Joomla!
• appeler ensuite l'URL https://www.mondomaine.tld/images/test.php.txt : si vous voyez la chaîne littérale "<?php phpinfo();", c'est bon, le serveur est bien configuré. Par contre, si vous voyez le PHP info de votre site, votre serveur présente un très grave problème de configuration et votre hébergeur n'est certainement pas digne de confiance.

Donc si vous n'avez trouvé que des fichiers "xxx.php.png" sur votre site, oui le pirate a pu profiter de la faille d'Acymailing pour uploader ses fichiers mais il n'a pas pu les exploiter. Par contre, si en plus (comme mentionné dans certains posts plus haut), vous avez en plus des fichiers xxx.php, il est plus que probable que le piratage a été effectué. Si votre site contient des données d'utilisateurs, vous devez les avertir, ainsi que l'organisme en charge de la protection des données personnelles (la CNIL en France, l'APD en Belgique).

Pour ceux que ça intéresse, mon échange complet avec Nicholas (beaucoup de détails techniques) se trouve ici : https://www.akeeba.com/support/admin...ng-hack-1.html

[Helloo]

[*]appeler ensuite l'URL https://www.mondomaine.tld/images/test.php.txt : si vous voyez la chaîne littérale "<?php phpinfo();", c'est bon, le serveur est bien configuré. Par contre, si vous voyez le PHP info de votre site, votre serveur présente un très grave problème de configuration et votre hébergeur n'est certainement pas digne de confiance.

Moi je reçois: "Access denied"

[cavo789]

Avec pmleconte (merci!), nous avons upgradé le code source de QuickScan vers PHP 8.2.9 et fait quelques modifs (uniquement concernant le code source; pas les fonctionnalités).
aeSecure Quickscan est passé en v2.0

J'ai donc relancé l'interface en local et la récupération des fichiers se fait bien immédiatement à l'ouverture de l'interface. Les fichiers sont téléchargés dans le dossier racine (là où se trouve le script aesecure_quickscan.php et se nomment p.ex. aesecure_quickscan_lang_fr_FR.json (ils commencent tous par "aesecure_quickscan_").

J'ai essayer de le mettre en place, mais quand j'exécute le script aesecure_quickscan.php, j'ai une erreur 403 : Forbidden : You don't have permission to access this resource.

Une telle erreur concerne ton serveur web. As-tu mis le script à la racine de ton site web ? Si oui, je présume que tu as une sécurité en place qui bloque l'interdiction du script; peut-être Akeeba Admintools ? (je ne sais pas). Il faudrait que tu trouves "qui" interdit l'exécution du script.

[RobertG]

Merci jfque !

Je viens de faire le test chez PlanetHoster avec les noms test.php.txt et test.php.png et dans le premier cas je vois bien <?php phpinfo(); et dans le second, un message d'erreur concernant un fichier image incorrect.
Idem sur mon serveur PHPNET/NUXIT Performance 1 (l'offre n'existe plus )
En revanche, sur un serveur mutualisé OVH, j'ai bien les infos PHP.

[jfque]

Oui, j'ai fait le test sur mes différents serveurs (Apache et Lightspeed, chez différents hébergeurs) et j'ai toujours l'affichage du texte, sauf une fois une erreur 406 pour un MIME type incorrect.
Pour Helloo , une erreur 403 est une sécurité encore plus rigide, ce qui n'est pas plus mal. A priori, il n'est pas nécessaire d'avoir de fichier .txt dans le dossier image, quoiqu'il me semble que certains composants de galerie utilisent (ou utilisaient) ce type de fichier pour ajouter des meta données aux images.

[bisoox]

Alors oui, effectivement, j'ai quasiment sur tous mes sites en production akeeba tool.
ça doit être ça qui bloque, et j'ai également fait le test de jfque, et c'est tout bon pour moi. Donc ça laisse a supposé que les requêtes script n'ont pas pu être exécuté.
J'ai aussi SH404SEF qui bloque les attaques par injection base64 et par injection de script, ça doit aussi aider un peu.
Comme quoi, toujours multiplié les outils de sécurité, les failles arrive souvent là ou on ne les attends pas.

[Lyr!C]

Merci jfque !

Je viens de faire le test chez PlanetHoster avec les noms test.php.txt et test.php.png et dans le premier cas je vois bien <?php phpinfo(); et dans le second, un message d'erreur concernant un fichier image incorrect.
Idem sur mon serveur PHPNET/NUXIT Performance 1 (l'offre n'existe plus )
En revanche, sur un serveur mutualisé OVH, j'ai bien les infos PHP.

Bigre... OVH a 20 ans de retard...

C'est limite grave, non?

[RobertG]

Peut-être n'est-ce pas sur tous ses serveurs, mais en tout cas cet ancien, je confirme.
Il faudrait vérifier sur d'autres serveurs chez eux.

[Lyr!C]

Peut-être n'est-ce pas sur tous ses serveurs, mais en tout cas cet ancien, je confirme.
Il faudrait vérifier sur d'autres serveurs chez eux.

Je viens de vérifier sur différents sites clients, et tous sont concernés (hébergement ancien ou plus récent, perso, pro, performance...).

Là je ne comprends pas comment c'est possible en 2023, et me demande comment corriger cela sur un hébergement OVH.