Tweet
Hi, this post will be in English and french for a better communication of the information.
Bonjour, ce post va être fait en Anglais et en Français pour une meilleure communication de l'information
English version
1. What is the CVE-2017-17672 on vBulletin 5.3.X (Especially in 5.3.4) ?
As presented by the researchers in their article LINK this 0day vulnerability comes from an:
"Unsafe usage of PHP’s unserialize() on user-supplied input allows an unauthenticated attacker to delete arbitrary files and, under certain circumstances, execute arbitrary code on a vBulletin installation."
Researcher's article also contains detailed explanations about the source code function to blame as well as the proof of concept of an exploitation.
The vulnerability is unpatched and it's even more important as vBulletin seems to ignore researchers alerts about the 0day vulnerability
At the time this article is written there is no official mitigation solution, so we've make our own waiting for the official Vbulletin fix...
https://blogs.securiteam.com/index.php/archives/3573
2. How to mitigate the CVE-2017-17672 ?
When this 0day have been disclosed, a group of bots began to scan the internet to find vulnerable servers.
So, the first thing we can do to avoid being indexed as vulnerable to this vulnerability is to remove the vBulletin version number from it's footer.
(The name of the buttons may be approximate.)
- Go to the Admin control panel
- "Langages & Expressions"
- "Search in the expressions"
- Then search the expression "powered_by_vbulletin" via the dedicated search engine
- Then edit all the expression to remove the variable "Version {1}"
With that, we won't being indexed as vulnerable by simple scanners, however, the version number is exposed on others sections, in this way smarter scanners will still identified you as vulnerable.
Moreover, this first mitigation is not enough to avoid blind exploitation tentative.
As the origin of this vulnerability is an insecure handling of this vBulletin resource : /ajax/api/template/cacheTemplates
The temporary solution that we find is to not expose this resource at a server level:
For NGINX, blocking this can be done by adding this configuration in the website configuration file :
Same configuration can be added in Apache with these lines:
With this configuration, each request to this resource result in an HTTP 403 code, avoiding the vulnerability to be exploited.
This mitigation seem to have no apparent impact on the usage of the forum system by users. And even if it had, we suppose that it would only impact the front cache system, so nothing very serious compared to the risks of this vulnerability.
Version française
1. Qu'est-ce que la CVE-2017-17672 sur vBulletin 5.3.x (et plus spécifiquement 5.3.4) ?
Comme présenté dans l' article des chercheurs, cette vulnérabilité 0day vient de :
"Un usage non-sûr de la fonction PHP unserialize() sur des données fournies par l'utilisateur permet à un attaquant non connecté de supprimer des fichiers arbitraires sur le serveur et de, en certaines circonstances, permettre d'exécuter du code arbitraire sur l'installation vBulletin."
L'article des chercheurs contient également des détails sur le code source vBulletin à incrimier ainsi qu'un exemple d'exploitation.
Cette vulnérabilité non patchée est d'autant plus importante que vBulletin fait la sourde oreille à cette alerte de sécurité présentée par les chercheurs.
À l'heure d'écriture de cet article, cette vulnérabilité reste non patchée. Nous avons donc créé notre propre solution en attendant la correction officielle de vBulletin.
2. Comment mitiger CVE-2017-17671 ?
Quand cette vulnérabilité a été rendue publique, un groupe de bot a commencer à scanner internet afin de trouver des serveurs vulnérables.
De ce fait, la première mitigation qui peut être mise en place est d'empêcher son installation d'être marquée comme vulnérable en supprimant le numéro de version de vBulletin de son pied de page.
(Remarque : le nom du bouton pourrait être un peu différent)
- Rendez-vous dans le panneau de contrôle de l'administration
- "Langages et Expressions"
- "Chercher dans les expressions"
- Cherchez alors l'expression "powered_by_vbulletin" via le moteur de recherche proposé
- Éditez alors toutes les expressions pour supprimer la variable "Version {1}"
Avec cette première mitigation, nous ne serons pas indexé par les scanners les plus simples. Cependant, la version de vBulletin se retrouve dans d'autres endroits de la page et pourrait donc encore être trouvée par des scanners plus complexes. Elle n'est de plus pas suffisante pour éviter l'exploitation à l'aveugle.
Comme l'origine de cette vulnérabilité se trouve dans une gestion non sécurisée de la ressource vBulletin suivante : /ajax/api/template/cacheTemplates, une solution temporaire est de bloquer cette dernière au niveau du serveur.
Pour NGINX, cela peut être fait en ajoutant les lignes suivantes dans le fichier de configuration du site web en question :
La même configuration peut être mise en place dans Apache2 via le code suivant :
Ces configurations entrainent que chaque requête envoyée à cette ressource résulte en un code HTTP 403. Ce qui empêche la vulnérabilité d'être exploitée.
De plus, cette mitigation semble ne pas avoir d'impact apparent sur l'usage du système par les utilsateurs. De plus, si un léger impact venait à exister, ce dernier est à comparer avec l'impact possible et très important de l'exploitation possible de cette vulnérabilité.
Bonjour, ce post va être fait en Anglais et en Français pour une meilleure communication de l'information
English version
1. What is the CVE-2017-17672 on vBulletin 5.3.X (Especially in 5.3.4) ?
As presented by the researchers in their article LINK this 0day vulnerability comes from an:
"Unsafe usage of PHP’s unserialize() on user-supplied input allows an unauthenticated attacker to delete arbitrary files and, under certain circumstances, execute arbitrary code on a vBulletin installation."
Researcher's article also contains detailed explanations about the source code function to blame as well as the proof of concept of an exploitation.
The vulnerability is unpatched and it's even more important as vBulletin seems to ignore researchers alerts about the 0day vulnerability
At the time this article is written there is no official mitigation solution, so we've make our own waiting for the official Vbulletin fix...
https://blogs.securiteam.com/index.php/archives/3573
2. How to mitigate the CVE-2017-17672 ?
When this 0day have been disclosed, a group of bots began to scan the internet to find vulnerable servers.
So, the first thing we can do to avoid being indexed as vulnerable to this vulnerability is to remove the vBulletin version number from it's footer.
(The name of the buttons may be approximate.)
- Go to the Admin control panel
- "Langages & Expressions"
- "Search in the expressions"
- Then search the expression "powered_by_vbulletin" via the dedicated search engine
- Then edit all the expression to remove the variable "Version {1}"
With that, we won't being indexed as vulnerable by simple scanners, however, the version number is exposed on others sections, in this way smarter scanners will still identified you as vulnerable.
Moreover, this first mitigation is not enough to avoid blind exploitation tentative.
As the origin of this vulnerability is an insecure handling of this vBulletin resource : /ajax/api/template/cacheTemplates
The temporary solution that we find is to not expose this resource at a server level:
For NGINX, blocking this can be done by adding this configuration in the website configuration file :
Code:
location /ajax/api/template/cacheTemplates {
deny all;
}
Code:
<Files "/ajax/api/template/cacheTemplates"> Order deny, allow Deny from all </Files>
With this configuration, each request to this resource result in an HTTP 403 code, avoiding the vulnerability to be exploited.
This mitigation seem to have no apparent impact on the usage of the forum system by users. And even if it had, we suppose that it would only impact the front cache system, so nothing very serious compared to the risks of this vulnerability.
Version française
1. Qu'est-ce que la CVE-2017-17672 sur vBulletin 5.3.x (et plus spécifiquement 5.3.4) ?
Comme présenté dans l' article des chercheurs, cette vulnérabilité 0day vient de :
"Un usage non-sûr de la fonction PHP unserialize() sur des données fournies par l'utilisateur permet à un attaquant non connecté de supprimer des fichiers arbitraires sur le serveur et de, en certaines circonstances, permettre d'exécuter du code arbitraire sur l'installation vBulletin."
L'article des chercheurs contient également des détails sur le code source vBulletin à incrimier ainsi qu'un exemple d'exploitation.
Cette vulnérabilité non patchée est d'autant plus importante que vBulletin fait la sourde oreille à cette alerte de sécurité présentée par les chercheurs.
À l'heure d'écriture de cet article, cette vulnérabilité reste non patchée. Nous avons donc créé notre propre solution en attendant la correction officielle de vBulletin.
2. Comment mitiger CVE-2017-17671 ?
Quand cette vulnérabilité a été rendue publique, un groupe de bot a commencer à scanner internet afin de trouver des serveurs vulnérables.
De ce fait, la première mitigation qui peut être mise en place est d'empêcher son installation d'être marquée comme vulnérable en supprimant le numéro de version de vBulletin de son pied de page.
(Remarque : le nom du bouton pourrait être un peu différent)
- Rendez-vous dans le panneau de contrôle de l'administration
- "Langages et Expressions"
- "Chercher dans les expressions"
- Cherchez alors l'expression "powered_by_vbulletin" via le moteur de recherche proposé
- Éditez alors toutes les expressions pour supprimer la variable "Version {1}"
Avec cette première mitigation, nous ne serons pas indexé par les scanners les plus simples. Cependant, la version de vBulletin se retrouve dans d'autres endroits de la page et pourrait donc encore être trouvée par des scanners plus complexes. Elle n'est de plus pas suffisante pour éviter l'exploitation à l'aveugle.
Comme l'origine de cette vulnérabilité se trouve dans une gestion non sécurisée de la ressource vBulletin suivante : /ajax/api/template/cacheTemplates, une solution temporaire est de bloquer cette dernière au niveau du serveur.
Pour NGINX, cela peut être fait en ajoutant les lignes suivantes dans le fichier de configuration du site web en question :
Code:
location /ajax/api/template/cacheTemplates {
deny all;
}
Code:
<Files "/ajax/api/template/cacheTemplates"> Order deny, allow Deny from all </Files>
Ces configurations entrainent que chaque requête envoyée à cette ressource résulte en un code HTTP 403. Ce qui empêche la vulnérabilité d'être exploitée.
De plus, cette mitigation semble ne pas avoir d'impact apparent sur l'usage du système par les utilsateurs. De plus, si un léger impact venait à exister, ce dernier est à comparer avec l'impact possible et très important de l'exploitation possible de cette vulnérabilité.
