MUMBLE "couldn't create video" -- моя регрессия из 576baa3/753d21c. В логах
у части загрузок есть Stream mapping и "Press [q]", но нет "Output #0":
ffmpeg не доработал, его снял дедлайн.
Две причины:
- "-threads 1" душил многопоточное декодирование vp9. 12-секундное 640x360
в 2 секунды одним потоком не влезает.
- checkGeometry вызывал ffprobe ВНУТРИ того же 2-секундного контекста, что
и кодек, отбирая у него время.
- убран -threads 1, -max_alloc оставлен (на скорость не влияет);
- probe получил свой бюджет ProbeDeadline=1s, ffmpeg -- полные
ProcessingDeadline=2.5s. Сумма с GetDuration укладывается в 7с
контекста handleCreate с запасом;
- семафор 16 -> 48: под флудом 16 слотов создавали очередь, и чекер
выпадал по таймауту ещё до обработки. Бомбы теперь отсекаются дёшево,
слоты освобождаются быстро.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
handleAccess выдаёт доступ, не проверяя существование видео, а запись в
access привязана к аккаунту и переживает ротацию токенов. Значит можно
занять строки под будущие id постоянным аккаунтом, и забирать флаги даже
после того, как цель запатчит keygen.
- tiktak_preauth.py: логинится постоянным PERSIST_LOGIN, меряет скорость
роста id (у команд разброс 7..900/мин), занимает окно вперёд на N минут.
Не для фермы, запускать раз в 10-20 мин, пока цель не запатчила.
- tiktak_keygen_forge.py: тот же постоянный аккаунт вместо одноразового;
watch=200 без форжа = сработала закладка, собираем флаг и оттуда.
Проверено на 10.10.10.5: занял 184 будущих id, через минуту watch/60524 и
60527 отдали свежие флаги без токена в запросе.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
handleAccess вызывал AddAccess не проверяя, что видео существует. Значит
можно было пре-авторизоваться на ещё не созданные id (и на отрицательные):
POST /access videoID=<top+3000> с форженным токеном возвращает 302, строка
в access создаётся, и когда чекер создаст видео с этим id -- доступ уже
есть.
Главное: такая строка ПЕРЕЖИВАЕТ ротацию токенов. haveAccess() смотрит в
таблицу access, а не на токен, поэтому переход на HMAC от заранее набитых
записей не защищает.
Проверено на 10.10.10.5: /access для id=top+3000 -> 302 /watch/63481.
Чистка уже накопленного мусора (легитимных записей на несуществующие видео
быть не может):
DELETE a FROM access a LEFT JOIN video v ON v.id = a.video_id
WHERE v.id IS NULL;
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Фиксированная глубина 3000 не работала на быстрых боксах: на 10.10.10.1
id растут >1000/мин, приватные ролики чекера ушли на 12000 вниз от top и
сплойт возвращался пустым.
Теперь сканируем блоками по 2000 сверху вниз до 14000 и выходим, как только
набрали 6 целей -- на медленных боксах это по-прежнему один блок.
Проверено: 4 флага с 10.10.10.1 (глубина 12042), 3 с 10.10.10.5
(глубина 1653), на 10.10.10.2 корректно определился патч.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Единственный рабочий вектор на данный момент: LFI закрыли уже все команды
(проверил .1/.4/.5 -- везде 404), а keygen разобрали далеко не все.
Токен считается только от video id: seed=(seed*17+42)%62 по алфавиту base62,
30 символов, ключа нет. Форжим -> POST /access пишет строку в access ->
haveAccess() пропускает легально -> /watch отдаёт description, /vtt субтитры.
Поиск целей: приватное видео выдаёт себя размытым превью. /feed показывает
лишь 50 последних, а id растут ~500/мин из-за чужого флуда, поэтому
чекерские ролики лежат на глубине в сотни-тысячи id. Сканируем 3000 id в
50 потоков; echo отдаёт статику только на GET (HEAD => 405), так что
пробуем GET с Range: bytes=0-0 -- один байт вместо всего PNG.
6 отказов /access подряд => команда запатчена, выходим рано.
Проверено вживую: 3 флага с 10.10.10.5, 1 с 10.10.10.1, на 10.10.10.4
корректно определился патч.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
На vulnbox сервис лежит в ./tiktak, в репе -- в ./services/tiktak, и скрипт
падал на поиске тестового видео ещё до первой проверки.
- каталог сервиса ищется сам (./tiktak, ./services/tiktak, ., рядом со
скриптом), либо задаётся через TIKTAK_DIR
- тестовый webm: с диска -> скачать с живого сервиса (/feed -> /watch/N ->
ссылка на .webm, публичное видео отдаёт её без авторизации) -> ffmpeg на
хосте -> ffmpeg в контейнере
- бомба для проверки DoS-защиты тоже генерится в контейнере, если на хосте
нет ffmpeg
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MUMBLE "failed to get access using private key": чекер держит share-токен,
выданный ещё старым keygen, а после перехода на HMAC ValidateKey его
отвергал.
- keygen/legacy.go: восстановленный из keygen.a алгоритм
seed=(seed*17+42)%62 принимается ТОЛЬКО для video.id <= cutoff, то есть
для видео, существовавших на момент перехода. Выше cutoff -- лишь HMAC.
- cutoff берётся из max(video.id) при первом старте и пишется в
public/.legacy_cutoff на volume: рестарт не должен расширять окно.
Не смогли прочитать -- fail closed, legacy выключен.
- Когда старые флаги протухнут: echo 0 > public/.legacy_cutoff + рестарт,
и legacy отключается полностью.
Ещё MUMBLE "cannot create video" -- он же DoS, у NOP-команды то же самое:
- checkGeometry сделан FAIL-OPEN. Неразобранный ffprobe больше не отклоняет
загрузку, режем только успешно прочитанную и абсурдную геометрию.
- ffmpeg -max_alloc 128M: 1080p кадру нужно ~8 МБ, бомбе ~1 ГБ. Работает
даже когда probe промолчал.
check_tiktak.sh: smoke-тест для vulnbox, гоняет сценарий чекера целиком
и отдельно проверяет, что патчи реально в задеплоенном билде.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Приходят 100 КБ webm с VP8-кадром гигантского разрешения (boundary у них
буквально ----bomb*). Проверку f.Size > 5MB он проходит, validateWebm смотрит
только первые 512 байт, а ffmpeg разворачивает такой кадр в ~1 ГБ сырых
пикселей. При семафоре на 75 параллельных это укладывает box, чекер не
укладывается в свои 7 секунд => MUMBLE.
- video/probe.go: ffprobe читает geometry из заголовка (кадр не декодируется),
режем > 4096 по стороне и > 8 Mpx.
- Blur: image.DecodeConfig до image.Decode, тот же лимит по пикселям.
imaging.Blur держит несколько копий битмапа, без лимита это OOM сам по себе.
Заодно f.Close(), которого не было.
- ffmpeg -threads 1, семафор 75 -> 16.
- BodyLimit 8M: размер видео проверялся, а форма нет. Огромные субтитры
превращались в слайс на миллионы строк в GenerateVtt. Плюс явный
MaxSubtitlesSize 64K.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Share-токен приватного видео считался в legacy/keygen.a только от video id,
без ключа: seed=(seed*17+42)%62, out[i]=alpha[seed]. После первой итерации
состояние схлопывалось в id%62, то есть на весь сервис приходилось 62
различных токена. Разбирать бинарь не требовалось: 62 своих приватных видео
дают таблицу токенов ко всем чужим.
Форж токена => POST /access => строка в таблице access => haveAccess() отдаёт
и description, и субтитры, и .webm совершенно легально, мимо патча /vtt/.
Теперь HMAC-SHA256(secret, vid), те же сигнатуры и тот же 30-символьный
base62, cgo и keygen.a из сборки выпали (образ собирается под любую
архитектуру). Сверка constant-time через hmac.Equal.
Совместимость со старыми токенами намеренно не сохранена: раунды ещё не
начинались, приватных видео нет.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- tiktak_vtt_path_traversal.py: ../ в ?id=, подбирает рабочий шаблон
один раз и переиспользует на остальных ID.
- tiktak_vtt_auth_bypass.py: рассинхрон SQL/FS ('./7' => MySQL 0, файл
public/vtt/7.vtt), работает даже если запатчат только traversal.
- tiktak_private_preview_leak.py: резкое превью приватного видео,
OCR опционален, без pytesseract молча не печатает мусор в stdout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- handleVtt: id валидируется как положительное целое, ошибка GetVideo
больше не игнорируется. Закрывает сразу два вектора: обход ACL через
нулевой db.Video (Private=false => haveAccess пропускал анонима) и
path traversal в path.Join(VttFolder, vid+".vtt").
- handleCreate: резкое превью приватного видео удаляется после блюра,
иначе оно оставалось доступным в public/static через echo.Static.
- main.go: DSN приведён к паролю из compose (5935004 поменял только
compose, из-за чего сервис не достучался бы до базы).
- db: пароли хешируются sha256 с pepper, сверка в Go constant-time,
плейнтекст принимается как legacy => старые юзеры не теряют доступ.
- cookies: HttpOnly + Path=/ + SameSite=Lax.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
V4/V5: docker-compose публиковал наружу все пять узлов. database на :38002 —
это key-value store вообще без аутентификации: GET /users/<кто угодно>/msg
отдаёт флаг, GET .../password отдаёт пароль, POST перезаписывает любое поле.
content на :38004 рендерит файл юзера уже без требования .html в пути.
Имена жертв берутся из комментариев к картинкам там же.
38001-38004 привязаны к 127.0.0.1: наружу торчит только proxy на 38000.
Между собой контейнеры ходят по docker-сети (database:5002), публикация портов
на это не влияет — функциональность сохраняется полностью. Проверено с внешнего
IP: весь флоу чекера проходит через один 38000, сплойт собирает 0 флагов и не
может даже перечислить пользователей.
ДОПУЩЕНИЕ: чекер ходит только в proxy. Из исходников это не доказать —
свериться с Pacmate/Firegex на vulnbox и последить за первым раундом проверок.
Коммит отдельный именно поэтому: откат этого изменения не тронет патчи кода,
которые безопасны наверняка. Откат — вернуть "38002:5002" нужному узлу.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NN8sHQuGbTBLGGkJyfxzXr
Разбор сервиса и все PoC — в services/rusgram/WRITEUP.md и VULNS.md.
Каждая находка воспроизведена на живом стенде до патча и перепроверена после.
content.py — V1 (RCE, крит) и V5:
template_folder='files' совпадает с каталогом БД, поэтому render_template(path)
с путём из URL рендерил файл пользователя как исходник Jinja-шаблона. Имя юзера
выбирает атакующий: регистрируем `pwn.html`, кладём payload себе в first_name,
дёргаем /db/users/pwn.html через публичный :38000 — RCE от root в контейнере,
где смонтирован весь website/. Теперь рендерим только 4 реальные страницы.
logic.py — V2 (захват аккаунта) и V3/V6 (SSRF/открытый редирект):
register не проверял существование юзера, а database делал read-modify-write,
так что повторная регистрация ПЕРЕЗАПИСЫВАЛА пароль, сохраняя msg и профиль:
чужой аккаунт вместе с флагом и сломанный логин у чекера. Теперь 409.
Location строился из заголовка Origin, а proxy ходил по нему серверсайд —
чтение внутренней сети. Редирект стал фиксированным /login.html.
database.py — снижает ущерб от V4:
валидация имени юзера как имени файла, белый список полей, пароль можно только
создать, но не перезаписать (смены пароля в сервисе нет), 400/404 вместо 500.
proxy.py — defense in depth к V3: allow_redirects=False на ветке api/.
V8: единая безопасная проверка сессии вместо 4 копий — кривая кука, отсутствие
куки, несуществующий юзер и нечисловой img больше не роняют воркер в 500.
Формат куки login||password и плейнтекстовые пароли осознанно НЕ трогали:
чекер почти наверняка на них завязан.
Тесты: services/rusgram/test_rusgram.py — SLA 16/16, SEC 21/21 на патче;
на services_vulnerable та же секция SEC падает 12 раз. Сплойт собирает 0 флагов.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NN8sHQuGbTBLGGkJyfxzXr
Комбинированный сплойт: V1 SSTI->RCE через имя юзера *.html, V3 SSRF через
Origin, V4 прямой database :38002, V5 прямой content :38004, V2 захват
аккаунта перерегистрацией. Векторы независимы — патч одного не глушит остальные.
Энумерация жертв: комментарии к картинкам + `ls` через RCE.
V1 использует свежее имя юзера на каждый раунд: Flask вне debug не перечитывает
шаблоны, и после первого рендера Jinja отдаёт закэшированную версию.
Проверено на стенде: собирает все посаженные флаги.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NN8sHQuGbTBLGGkJyfxzXr
bobiqqandClaude Opus 5
frogolonso
h1z3
dmeetrogonandClaude Opus 5
