Je viens de regarder ma page de suivi des agents utilisateurs sur mon site (archivée sur Yandex ) et j'ai remarqué ces agents utilisateurs. Je pense que c'est une tentative d'exploiter mon serveur (Nginx avec PHP). Le 1 devant est juste le nombre de fois où l'agent utilisateur a été vu dans le journal Nginx. Ce sont également des agents utilisateurs raccourcis et non longs comme Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
. Je n'ai plus accès aux journaux car je suppose que cela s'est produit en janvier ou février (mes plus anciens journaux sont en mars et j'ai créé le site en janvier).
1 Mozilla/5.9}print(238947899389478923-34567343546345);{
1 Mozilla/5.9{${print(238947899389478923-34567343546345)}}
1 Mozilla/5.9\x22{${print(238947899389478923-34567343546345)}}\x22
1 Mozilla/5.9\x22];print(238947899389478923-34567343546345);//
1 Mozilla/5.9\x22
Quel exploit a été tenté et comment puis-je tester pour m'assurer que ces exploits ne sont pas utilisables?
Il semble essayer d'exploiter une certaine forme d'injection de commande. Comme DarkMatter l'a mentionné dans sa réponse, il s'agissait probablement d'une vaste tentative de trouver des serveurs vulnérables, plutôt que de vous cibler spécifiquement. La charge utile elle-même semble simplement être en train de tester pour voir si le serveur est vulnérable à l'injection de commandes. Il ne semble pas avoir de but supplémentaire.
Afin de tester si vous seriez affecté par ces charges utiles spécifiques, le moyen le plus simple serait de les envoyer à votre propre serveur et de voir comment elles réagissent. Notez que je ne dis cela que parce que les charges utiles elles-mêmes sont bénignes; Je ne recommande pas de le faire avec toutes les charges utiles.
Je parie que votre serveur n'est pas vulnérable, car je m'attendais à voir une demande de suivi pour exploiter réellement votre serveur.
Ce n'est probablement rien. Cela ressemble au large spam d'un scanner qui recherche sur le Web tout site Web qui évalue et renvoie cette soustraction alors qu'il ne devrait pas. C'est une chose assez courante à voir.
L'utilisation de noms de fonction réels (par exemple print
) suggère qu'ils recherchent des sites Web qui utilisent eval
d'une certaine manière (notez que cela pourrait être PHP eval(string $code)
, JavaScript eval(string)
et équivalents d'autres langages de script).
Je note que le code exécutable apparaît immédiatement après le premier paramètre version
après Mozilla/
. Cela signifie que les auteurs de cette attaque pensent qu'un nombre suffisant de sites Web à l'état sauvage utilisent en fait eval
comme moyen (horrible) d'analyser un composant à deux composants (major.minor
) numéro de version.
J'imagine donc que des sites Web vulnérables faisaient quelque chose comme ceci (pseudo-code):
var userAgent = request.headers["User-Agent"];
var indexOfVersion = userAgent.indexof( '/' );
var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );
var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
var versionNumber = eval( versionText ); // <------- this is the vulnerability!
il semble qu'ils essaient d'injecter PHP dans les fichiers journaux. L'idée étant que si l'administrateur système utilise une application PHP pour analyser les journaux, certains peut voir le fichier journal comme fiable (après tout, l'utilisateur ne peut normalement pas modifier directement le fichier journal) et donc renoncer à tout processus de désinfection.
Si vous consultez vos fichiers journaux via un bureau ou un éditeur de texte CLI, vous ne serez jamais vulnérable à cette attaque. Si vous utilisez une application PHP, assurez-vous qu'elle traite les journaux comme non fiables et désinfectez-les comme vous le feriez pour un champ de saisie utilisateur normal.
C'est simple; ils essaient PHP injection de commande. Le processus consiste à remplacer un en-tête (dans ce cas le champ de l'agent utilisateur) par une expression mathématique, puis de déterminer si le code est en cours d'exécution voir le retour Si le code est exécuté, la valeur de retour sera le résultat de l'expression, plutôt que de l'expression d'origine. Vous remarquerez l'utilisation légèrement spammeuse des crochets ouverts et fermés, des points-virgules et d'autres caractères souvent utilisés pour tromper les langues interprétées dans en interprétant les données sous forme de code exécutable. Rien à craindre, les analyses de vulnérabilité automatisées comme celle-ci font aujourd'hui partie du cours.