La vulnérabilité de sécurité des accès non autorisés de phpMyAdmin dans Pagoda Panel est-elle une erreur de bas niveau ?

Dimanche soir, un message a été soudainement publié dans un certain groupe. Il y a eu un avertissement de vulnérabilité d'urgence concernant des vulnérabilités d'accès non autorisé dans phpmyadmin du Pagoda Panel, et un grand nombre d'URL présentant des vulnérabilités ont été fournies :

Cliquez simplement sur l'un d'eux, et ce sera une grande page de gestion en arrière-plan de phpmyadmin, sans aucune authentification ni connexion. Bien sûr, toutes sortes d'images et de mythes magiques sont ensuite devenus populaires sur les réseaux sociaux. En tant que chercheur en sécurité calme, j'en ai bien sûr ri, mais je suis toujours très intéressé par la cause de cette vulnérabilité, c'est pourquoi nous allons examiner dans cet article. tout le processus. La raison de l’incident.

1. Quel est notre problème ?

Tout d'abord, permettez-moi de conclure : cette affaire n'est certainement pas simplement un répertoire pma que j'ai oublié de supprimer, ou le panneau de la pagode a été configuré de manière négligente et incorrecte, encore moins quelque chose comme quelqu'un. L'officiel La porte dérobée mentionnée dans les théories du complot de certaines personnes est délibérée.

Pourquoi je dis ça ? Tout d'abord, selon le communiqué officiel, cette vulnérabilité n'affecte que les versions suivantes :

• Linux version officielle 7.4.2

• Linux bêta version 7.5.13

• Version officielle de Windows 6.8

Cette version est la version précédente de la dernière version (version de correction de bug). En d’autres termes, le panneau de version précédant cette certaine version mineure n’est pas affecté. Réfléchissons-y, s'il s'agit d'une « porte dérobée » ou d'un répertoire que le responsable a oublié de supprimer, pourquoi cela n'affecte-t-il que cette version ? De plus, Pagoda Panel a été développé depuis si longtemps et a accumulé 4 millions d'utilisateurs, et la sécurité du système est relativement mature s'il y avait eu des erreurs ou des « portes dérobées » aussi inférieures, elles auraient dû être découvertes depuis longtemps.

Après avoir effectivement vérifié les cas sur Internet et interrogé des amis qui ont utilisé le panneau pagode, j'ai découvert qu'il n'y avait pas de répertoire pma dans les versions antérieures à 7.4.2, et la méthode d'authentification de phpmyadmin nécessite de saisir le mot de passe du compte par défaut. Par conséquent, lorsque cette vulnérabilité apparaît dans la pagode, les deux choses suivantes doivent avoir été faites :

• Ajout d'un nouveau répertoire pma avec le contenu phpmyadmin

• Le fichier de configuration de phpmyadmin a été modifié pour changer la méthode d'authentification

Ensuite, notre question devient, pourquoi le responsable a-t-il effectué ces deux modifications, et quel est le but ?

Afin d'étudier ce problème, nous devons d'abord installer une version Pagoda 7.4.2. Cependant, l'installation de Pagoda est un script infaillible en un clic :

yum install -y wget && wget -O install.sh http://download.bt.cn/install/install_6.0.sh && sh install.sh

ne donne pas aux utilisateurs la possibilité de choisir un numéro de version. Le Git officiel n'a peut-être pas été mis à jour depuis longtemps. on l'installe ? Qu'en est-il de la version appropriée (7.4.2) ?

2. Installez une version adaptée

Bien sûr, cela ne me pose pas de problème. Tout d’abord, j’ai installé la dernière version de Pagoda Panel, en utilisant le script en un clic mentionné ci-dessus.

Le processus d'installation s'est naturellement déroulé sans problème. Une fois l'installation terminée, le numéro de version affiché par le système était la dernière version 7.4.3, car une fois la vulnérabilité révélée, le responsable l'a rapidement réparé et mis à niveau. . Mais ce n'est pas grave, nous pouvons toujours trouver le package de mise à niveau hors ligne :

http://download.bt.cn/install/update/LinuxPanel-7.4.0.zip
http://download.bt.cn/install/update/LinuxPanel-7.4.2.zip
http://download.bt.cn/install/update/LinuxPanel-7.4.3.zip

sont respectivement les versions 7.4.0/7.4.2/7.4.3. Nous les téléchargeons et les décompressons respectivement, et essayons de restaurer notre. propre version du serveur à la vulnérabilité version 7.4.2.

Avant de restaurer le code, on déconnecte d'abord le serveur ou on met la pagode en mode hors ligne :

Le but de ceci est d'empêcher la pagode de démarrer automatiquement La version est mise à jour pour éviter que le code finalement récupéré ne soit automatiquement mis à jour.

Le code système de la pagode est installé dans /www/server/panel par défaut. Ensuite, nous téléchargerons directement le répertoire du panneau dans le package compressé ici, en écrasant les fichiers existants. Redémarrez la pagode et vous constaterez que le numéro de version du système a été restauré à 7.4.2 :

Ce n'est pas encore fini. Nous utilisons Beyond Compare pour ouvrir la compression de 7.4. .2 et 7.4.3 Pour empaqueter le code, regardez d'abord comment le responsable corrige la vulnérabilité :

est plus grossier, déterminez directement si le répertoire /www/server/phpmyadmin/pma existe et supprimez-le directement s'il existe. Par conséquent, bien que nous ayons restauré le code de la version du système, le pma supprimé n'est plus là et nous devons toujours restaurer ce répertoire.

La méthode est également très simple. Il y a un répertoire phpmyadmin sous /www/server/phpmyadmin On peut directement copier ce répertoire :

3. Quelle est exactement la vulnérabilité

Avec l'environnement en place, nous devons encore examiner le code.

Tout d’abord, puisque la version 7.4.2 est la version qui a introduit la vulnérabilité, jetons un coup d’œil au journal de mise à jour officiel de la 7.4.2 :

用beyond compare打开7.4.0和7.4.2的压缩包代码，看看具体增加了哪些代码：

可见，在7.4.2版本中增加了两个视图，分别对应着phpmyadmin和adminer。视图中用到了panelPHP#start方法，这个方法其实也是新加的：

    def start(self,puri,document_root,last_path = ''):
        '''
            @name 开始处理PHP请求
            @author hwliang<2020-07-11>
            @param puri string(URI地址)
            @return socket or Response
        &#39;&#39;&#39;
        ...
        #如果是PHP文件
        if puri[-4:] == &#39;.php&#39;:
            if  request.path.find(&#39;/phpmyadmin/&#39;) != -1:
                ...
                if request.method == &#39;POST&#39;:
                    #登录phpmyadmin
                    if puri in [&#39;index.php&#39;,&#39;/index.php&#39;]:
                        content = public.url_encode(request.form.to_dict())
                        if not isinstance(content,bytes):
                            content = content.encode()
                        self.re_io = StringIO(content)
                        username = request.form.get(&#39;pma_username&#39;)
                        if username:
                            password = request.form.get(&#39;pma_password&#39;)
                            if not self.write_pma_passwd(username,password):
                                return Resp(&#39;未安装phpmyadmin&#39;)
                if puri in [&#39;logout.php&#39;,&#39;/logout.php&#39;]:
                    self.write_pma_passwd(None,None)
            else:
                ...
      #如果是静态文件
        return send_file(filename)

代码太长，我们不展开分析，只我写出来的部分。在请求的路径是/phpmyadmin/index.php且存在pma_username、pma_password时，则执行self.write_pma_passwd(username,password)。

跟进self.write_pma_passwd：

    def write_pma_passwd(self,username,password):
        '''
            @name 写入mysql帐号密码到配置文件
            @author hwliang<2020-07-13>
            @param username string(用户名)
            @param password string(密码)
            @return bool
        &#39;&#39;&#39;
        self.check_phpmyadmin_phpversion()
        pconfig = &#39;cookie&#39;
        if username:
            pconfig = &#39;config&#39;
        pma_path = &#39;/www/server/phpmyadmin/&#39;
        pma_config_file = os.path.join(pma_path,&#39;pma/config.inc.php&#39;)
        conf = public.readFile(pma_config_file)
        if not conf: return False
        rep = r"/\* Authentication type \*/(.|\n)+/\* Server parameters \*/"
        rstr = &#39;&#39;&#39;/* Authentication type */
$cfg[&#39;Servers&#39;][$i][&#39;auth_type&#39;] = &#39;{}&#39;;
$cfg[&#39;Servers&#39;][$i][&#39;host&#39;] = &#39;localhost&#39;; 
$cfg[&#39;Servers&#39;][$i][&#39;port&#39;] = &#39;{}&#39;;
$cfg[&#39;Servers&#39;][$i][&#39;user&#39;] = &#39;{}&#39;; 
$cfg[&#39;Servers&#39;][$i][&#39;password&#39;] = &#39;{}&#39;; 
/* Server parameters */&#39;&#39;&#39;.format(pconfig,self.get_mysql_port(),username,password)
        conf = re.sub(rep,rstr,conf)
        public.writeFile(pma_config_file,conf)
        return True

这个代码也很好理解了，如果传入了username和password的情况下，宝塔会改写phpmyadmin的配置文件config.inc.php，将认证方式改成config，并写死账号密码。

这就是为什么7.4.2版本中pma可以直接访问的原因。

补个课：

phpmyadmin支持数种认证方法，默认情况下是Cookie认证，此时需要输入账号密码；用户也可以将认证方式修改成Config认证，此时phpmyadmin会使用配置文件中的账号密码来连接mysql数据库，即不用再输入账号密码。

四、官方做这些动作的原因

其实各位看官看到这里肯定脑子里还是一团浆糊，这些代码究竟意味着什么呢？为什么官方要将认证模式改成config模式？

是很多漏洞分析文章的通病，这些文章在出现漏洞后跟一遍漏洞代码，找到漏洞发生点和利用方法就结束了，并没有深入研究开发为什么会这么写，那么下次你还是挖不出漏洞。

所以，这里思考一下，我们现在起码还有下列疑问：

• 在7.4.2版本以前，用户是如何使用phpmyadmin的？

• 宝塔为什么要在7.4.2版本增加phpmyadmin有关的视图？

• 宝塔为什么要将phpmyadmin认证模式改成config？

我们如何复现这个漏洞？

第一个问题，我们其实可以简单找到答案。在正常安装宝塔最新版7.4.3时，我们点击宝塔后台的phpmyadmin链接，会访问到这样一个路径：

7.4.3版本为了修复这个漏洞，回滚了部分代码，所以这种方式其实就是7.4.2以前版本的phpmyadmin的访问方式：通过888端口下的一个以phpmyadmin_开头的文件夹直接访问phpmyadmin。

这种老的访问方法中，888端口是一个单独的Nginx或Apache服务器，整个东西是安全的，访问也需要输入账号密码。

但是这种访问方法有些麻烦，需要额外开放888端口，而且每次登陆都要重新输入密码。所以，官方开发人员提出了一种新的做法，在宝塔后端的python层面转发用户对phpmyadmin的请求给php-fpm。这样有三个好处：

• 直接在python层面做用户认证，和宝塔的用户认证进行统一，不需要多次输入mysql密码

• 也不需要再对外开放888端口了

• 使用phpmyadmin也不再依赖于Nginx/Apache等服务器中间件了

这就是为什么宝塔要在7.4.2增加phpmyadmin有关的视图的原因，这个视图就是一个phpmyadmin的代理，做的事情就是转发用户的请求给php-fpm。

用户在第一次使用这种方式登录时，系统会自动发送包含了Mysql账号密码的数据包，宝塔后端会捕捉到此时的账号密码，填入phpmyadmin的配置文件，并将认证方式改成config。对于用户来说，感受到的体验就是，不再需要输入任何Mysql密码即可使用phpmyadmin了。

这的确给用户的使用带来了更好的体验。

五、漏洞复现

此时我们应该还有个疑问：既然官方目的是“直接在python层面做用户认证，和宝塔的用户认证进行统一”，那么仍然是有认证的呀？为什么会出现未授权访问漏洞呢？

我们可以来复现一下这个漏洞。首先，我们以系统管理员的身份登录宝塔后台，来到数据库页面，点击“phpMyAdmin”按钮，会弹出如下模态框：

Il existe deux modes d'accès. "Accès via Nginx/Apache/OIs" est la méthode d'accès de l'ancienne version, et "Accès sécurisé via le panneau" est le mode proxy nouvellement ajouté dans la version 7.4.2.

Nous cliquons sur "Accès sécurisé via le panneau" et capturons le paquet. Nous capturerons un tel paquet de données :

Le front-end de la pagode stockera. le mot de passe de notre compte Mysql Remplissez-le et envoyez-le directement à phpmyadmin. Et grâce au code que nous avons analysé précédemment, le compte et le mot de passe sont directement écrits dans le fichier de configuration phpmyadmin en arrière-plan pour obtenir une logique sans authentification.

Que se passe-t-il si un utilisateur non authentifié accède directement à http://ip:8888/phpmyadmin/index.php ? Vous serez redirigé directement vers la page de connexion :

Si tel est le cas, il n'y a aucune faille dans cette démarche. Cependant, le développeur officiel a commis une erreur. Il a placé l'application pma dans le répertoire /www/server/phpmyadmin, qui était à l'origine le répertoire racine Web utilisé par l'ancienne méthode d'accès phpmyadmin.

Cela signifie que je peux accéder au nouveau phpmyadmin via l'ancien répertoire port 888 + pma, et que le nouveau phpmyadmin a officiellement modifié le fichier de configuration, ce qui conduit finalement à une vulnérabilité d'accès non autorisé :

Alors, comment résoudre ce problème ? C'est aussi très simple, il suffit de déplacer le pma vers un autre répertoire.

6.Résumé

Faisons un résumé.

Tout d'abord, le panneau Pagoda n'est certainement pas mentalement retardé. Cette vulnérabilité ne consiste pas simplement à laisser un pma non autorisé à l'extérieur et à oublier de le supprimer. Cela va en fait gifler beaucoup de gens, car la plupart des gens pensent qu'il s'agit simplement d'une simple vulnérabilité d'accès non autorisé de phpmyadmin, et ils critiquent la pagode, mais ils ne s'attendaient pas à ce qu'il y ait en réalité une erreur logique complexe derrière cela.

Deuxièmement, l'expérience utilisateur et la sécurité ne sont absolument pas en conflit. Je n'aime vraiment pas la pratique consistant à émasculer l'expérience utilisateur afin d'assurer la sécurité. Par conséquent, nous espérons que le responsable de Pagoda n'annulera pas complètement le code en raison de cet incident de vulnérabilité (on dit que la mise à jour 7.4.3 n'est qu'une solution temporaire), et les domaines à améliorer doivent encore être améliorés.

Je n'ai pas utilisé le panel Linux depuis quelques années. Cette fois, j'ai revu le panel Linux en 2020. Personnellement, j'ai l'impression que Pagoda ressemble à un système qui accorde plus d'attention à la sécurité, par exemple. en tant qu'utilisateurs générés automatiquement, les politiques de nom d'utilisateur et de mot de passe, la configuration de sécurité Php par défaut, les mises à jour automatiques de version, etc. sont nettement meilleures que de nombreux autres systèmes commerciaux nationaux. Mais en regardant le code, il y a encore de nombreux domaines qui doivent être améliorés, j'y reviendrai plus tard lorsque j'en aurai l'occasion.

Cet article provient du compte public : https://mp.weixin.qq.com/s/3ZjwFo5gWlJACSkeYWQLXA

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!