Am Sonntagabend wurde in einer bestimmten Gruppe plötzlich eine Notfallwarnung zu Sicherheitslücken in phpmyadmin des Pagoda-Panels gepostet und eine große Anzahl von URLs mit Sicherheitslücken angegeben:
Just Klicken Sie darauf. Eine davon ist eine große phpmyadmin-Hintergrundverwaltungsseite ohne Authentifizierung und Anmeldung. Natürlich wurden später in den sozialen Netzwerken alle möglichen magischen Bilder und Mythen populär. Als ruhiger Sicherheitsforscher habe ich natürlich darüber gelacht, aber ich interessiere mich immer noch sehr für die Ursache dieser Sicherheitslücke, deshalb werden wir in diesem Artikel darauf eingehen Der gesamte Prozess.
1. Was ist unser Problem?
Lassen Sie mich zunächst ein Fazit ziehen: Es handelt sich definitiv nicht einfach um ein PMA-Verzeichnis, das ich vergessen habe zu löschen, oder um das Pagodenpanel, das fahrlässig falsch konfiguriert wurde, und es handelt sich auch nicht, wie manche in Verschwörungstheorien behaupten, um die offizielle Hintertür wurde bewusst offen gelassen.
Warum sage ich das? Zunächst einmal betrifft diese Schwachstelle laut offizieller Aussage nur die folgenden Versionen:
Linux offizielle Version 7.4.2
Linux Beta-Version 7.5.13
Windows offizielle Version 6.8
Diese Version ist die neueste Version (Bugfix-Version). Mit anderen Worten: Das Versionsfenster vor dieser bestimmten Nebenversion ist nicht betroffen. Denken wir einmal darüber nach: Wenn es sich um eine „Hintertür“ oder ein Verzeichnis handelt, das der Beamte vergessen hat zu löschen, warum betrifft es dann nur diese Version? Darüber hinaus wurde Pagoda Panel schon so lange entwickelt und hat 4 Millionen Benutzer, und die Systemsicherheit ist relativ ausgereift. Wenn es solche minderwertigen Fehler oder „Hintertüren“ gab, hätten sie schon vor langer Zeit entdeckt werden müssen.
Nachdem ich tatsächlich die Fälle im Internet überprüft und Freunde gefragt habe, die das Pagoden-Panel verwenden, habe ich festgestellt, dass es in Versionen vor 7.4.2 kein PMA-Verzeichnis gibt und die Authentifizierungsmethode von phpmyadmin standardmäßig die Eingabe des Kontokennworts erfordert. Wenn diese Schwachstelle in der Pagode auftritt, müssen daher die folgenden zwei Dinge getan worden sein:
Unsere Frage lautet also: Warum hat der Beamte diese beiden Änderungen vorgenommen und was ist der Zweck?
Um dieses Problem zu untersuchen, müssen wir zuerst eine Pagoda 7.4.2-Version installieren. Die Installation von Pagoda ist jedoch ein narrensicheres Ein-Klick-Skript:
yum install -y wget && wget -O install.sh http://download.bt.cn/install/install_6.0.sh && sh install.sh
Nach dem Login kopieren
bietet Benutzern keine Möglichkeit, eine Versionsnummer auszuwählen. Das offizielle Git wurde möglicherweise schon lange nicht mehr aktualisiert Version ( 7.4.2)?
Zweitens: Installiere eine passende Version
Natürlich ist das für mich kein Problem. Zuerst habe ich die neueste Version von Pagoda Panel mit dem oben erwähnten Ein-Klick-Skript installiert.
Der Installationsprozess ist natürlich kein Problem. Nach Abschluss der Installation zeigt das System die neueste Version 7.4.3 an, da der Beamte sie nach Aufdecken der Sicherheitslücke schnell repariert und aktualisiert hat. Aber das macht nichts, wir können immer noch das Offline-Upgrade-Paket finden:
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
Nach dem Login kopieren
Es handelt sich um die Versionen 7.4.0/7.4.2/7.4.3. Wir haben sie jeweils heruntergeladen und dekomprimiert und versucht, unsere Serverversion wiederherzustellen die anfällige Version 7.4.2.
Bevor wir den Code wiederherstellen, trennen wir zunächst den Server vom Internet oder versetzen die Pagode in den Offline-Modus:
Der Zweck besteht darin, zu verhindern, dass die Pagode die Version automatisch aktualisiert, und das automatische Upgrade zu vermeiden des Codes, der schließlich wiederhergestellt wurde.
Der Pagoda-Systemcode wird standardmäßig in /www/server/panel installiert, und dann laden wir das Panel-Verzeichnis im komprimierten Paket hier direkt hoch und überschreiben dabei die vorhandenen Dateien. Starten Sie die Pagode neu und Sie werden feststellen, dass die Systemversionsnummer auf 7.4.2 wiederhergestellt wurde:
Es ist noch nicht vorbei. Wir verwenden Beyond Compare, um den komprimierten Paketcode von 7.4.2 und 7.4.3 zu öffnen Wie der Beamte die Sicherheitslücke zuerst behebt:
ist relativ grob. Bestimmen Sie direkt, ob das Verzeichnis /www/server/phpmyadmin/pma existiert, und löschen Sie es direkt, wenn es existiert. Obwohl wir den Systemversionscode wiederhergestellt haben, ist das gelöschte PMA daher nicht mehr vorhanden und wir müssen dieses Verzeichnis noch wiederherstellen.
Die Methode ist auch sehr einfach. Wir können dieses Verzeichnis direkt kopieren: /www/server/phpmyadmin
Mit der Umgebung müssen wir noch umgehen ein Look-Code.
Da 7.4.2 die Version ist, die Schwachstellen mit sich bringt, werfen wir zunächst einen Blick auf das offizielle Update-Protokoll für 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
'''
...
#如果是PHP文件
if puri[-4:] == '.php':
if request.path.find('/phpmyadmin/') != -1:
...
if request.method == 'POST':
#登录phpmyadmin
if puri in ['index.php','/index.php']:
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('pma_username')
if username:
password = request.form.get('pma_password')
if not self.write_pma_passwd(username,password):
return Resp('未安装phpmyadmin')
if puri in ['logout.php','/logout.php']:
self.write_pma_passwd(None,None)
else:
...
#如果是静态文件
return send_file(filename)Nach dem Login kopieren
代码太长，我们不展开分析，只我写出来的部分。在请求的路径是/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
'''
self.check_phpmyadmin_phpversion()
pconfig = 'cookie'
if username:
pconfig = 'config'
pma_path = '/www/server/phpmyadmin/'
pma_config_file = os.path.join(pma_path,'pma/config.inc.php')
conf = public.readFile(pma_config_file)
if not conf: return False
rep = r"/\* Authentication type \*/(.|\n)+/\* Server parameters \*/"
rstr = '''/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = '{}';
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['port'] = '{}';
$cfg['Servers'][$i]['user'] = '{}';
$cfg['Servers'][$i]['password'] = '{}';
/* Server parameters */'''.format(pconfig,self.get_mysql_port(),username,password)
conf = re.sub(rep,rstr,conf)
public.writeFile(pma_config_file,conf)
return TrueNach dem Login kopieren
这个代码也很好理解了，如果传入了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。这样有三个好处：
这就是为什么宝塔要在7.4.2增加phpmyadmin有关的视图的原因，这个视图就是一个phpmyadmin的代理，做的事情就是转发用户的请求给php-fpm。
用户在第一次使用这种方式登录时，系统会自动发送包含了Mysql账号密码的数据包，宝塔后端会捕捉到此时的账号密码，填入phpmyadmin的配置文件，并将认证方式改成config。对于用户来说，感受到的体验就是，不再需要输入任何Mysql密码即可使用phpmyadmin了。
这的确给用户的使用带来了更好的体验。
五、漏洞复现
此时我们应该还有个疑问：既然官方目的是“直接在python层面做用户认证，和宝塔的用户认证进行统一”，那么仍然是有认证的呀？为什么会出现未授权访问漏洞呢？
我们可以来复现一下这个漏洞。首先，我们以系统管理员的身份登录宝塔后台，来到数据库页面，点击“phpMyAdmin”按钮，会弹出如下模态框：
Dabei gibt es zwei Zugriffsmodi. „Zugriff über Nginx/Apache/OIs“ ist die Zugriffsmethode der alten Version und „Sicherer Zugriff über das Panel“ ist der neu hinzugefügte Proxy-Modus in 7.4.2.
Wir klicken auf „Sicherer Zugriff über das Panel“ und erfassen das Paket. Wir erfassen ein solches Datenpaket:
Das Pagoda-Frontend trägt das Passwort unseres MySQL-Kontos ein und sendet es direkt an phpmyadmin. Und aufgrund des Codes, den wir zuvor analysiert haben, werden das Konto und das Passwort im Hintergrund direkt in die phpmyadmin-Konfigurationsdatei geschrieben, um eine authentifizierungsfreie Logik zu erreichen.
Was passiert, wenn ein nicht authentifizierter Benutzer direkt auf http://ip:8888/phpmyadmin/index.php zugreift? Sie werden direkt zur Anmeldeseite weitergeleitet:
Wenn das alles ist, gibt es in diesem Prozess keine Lücke. Allerdings machte der offizielle Entwickler einen Fehler: Er platzierte die PMA-Anwendung im /www/server/phpmyadmin-Verzeichnis, das ursprünglich das Web-Stammverzeichnis war, das von der alten phpmyadmin-Zugriffsmethode verwendet wurde.
Das bedeutet, dass ich über den alten 888-Port + das PMA-Verzeichnis auf den neuen phpmyadmin zugreifen kann und der neue phpmyadmin die Konfigurationsdatei offiziell geändert hat, was letztendlich zu einer Sicherheitslücke bei unbefugtem Zugriff führt:
Also, wie man es löst dieses Problem? Es ist auch ganz einfach: Verschieben Sie einfach die PMA in ein anderes Verzeichnis.
6. Zusammenfassung
Lassen Sie uns eine Zusammenfassung erstellen.
Zuallererst ist das Pagoda-Panel definitiv nicht geistig zurückgeblieben. Diese Sicherheitslücke beruht nicht einfach darauf, dass man einen nicht autorisierten PMA draußen lässt und vergisst, ihn zu löschen. Dies wird tatsächlich vielen Leuten ins Gesicht schlagen, weil die meisten Leute denken, dass dies nur eine einfache Schwachstelle für unbefugten Zugriff von phpmyadmin ist, und sie diskreditieren die Pagode, haben aber nicht erwartet, dass dahinter tatsächlich ein komplexer Logikfehler steckt.
Zweitens stehen Benutzererfahrung und Sicherheit überhaupt nicht im Widerspruch dazu. Ich mag die Praxis, die Benutzererfahrung zu kastrieren, um die Sicherheit zu gewährleisten, wirklich nicht. Daher hoffen wir, dass der Pagoda-Beamte den Code aufgrund dieses Sicherheitslückenvorfalls nicht vollständig zurücksetzen wird (das Update 7.4.3 soll nur eine vorübergehende Lösung sein) und die Bereiche mit Verbesserungsbedarf noch verbessert werden müssen.
Ich habe das Linux-Panel einige Jahre lang nicht verwendet. Dieses Mal habe ich das Linux-Panel im Jahr 2020 erneut erlebt. Ich persönlich habe das Gefühl, dass Pagoda wie ein System aussieht, das mehr Wert auf Sicherheit legt, beispielsweise auf automatisch generierte Benutzer Passwörter, Benutzernamen und Passwortrichtlinien, standardmäßige PHP-Sicherheitskonfiguration, automatische Versionsaktualisierungen usw. sind definitiv besser als viele andere inländische kommerzielle Systeme. Aber wenn ich mir den Code ansehe, gibt es noch viele Bereiche, die verbessert werden müssen. Darauf werde ich später näher eingehen, wenn ich die Gelegenheit dazu habe.
Dieser Artikel stammt aus dem öffentlichen Konto: https://mp.weixin.qq.com/s/3ZjwFo5gWlJACSkeYWQLXA
Das obige ist der detaillierte Inhalt vonIst die Sicherheitslücke bei unbefugtem Zugriff von phpMyAdmin im Pagoda Panel ein geringfügiger Fehler?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
