Оргаю Tinkoff CTF

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

Зарегаться и создать команду нужно сегодня вот здесь: https://ctf.tinkoff.ru/
(мои таски будут в лиге опытных)

Если вы из Томска — можно будет зарулить своей командой в наш замечательный хакспейс, уже заявило о своём участии 5 команд.

Написал райтапы на свои таски:

https://vladimirlebe.dev/Tinkoff-CTF-2024-b633657d0e0f41b68d75948b4b17055e

RUN --mount в Dockerfile

Практически drop-in способ ускорить сборку докера, который помог оптимизировать мне сборку с 15 минут до 20 секунд.

FROM rust:1.77.2-buster AS builder
COPY . .
RUN --mount=type=cache,target=/var/cache/buildkit \
    CARGO_HOME=/var/cache/buildkit/cargo \
    CARGO_TARGET_DIR=/var/cache/buildkit/target \
    cargo build --release --locked && \
    cp /var/cache/buildkit/target/release/hello-world /

FROM debian:bookworm-slim AS runtime
COPY --from=builder /hello-world /usr/local/bin
ENTRYPOINT ["/usr/local/bin/hello-world"]

Как работает: докер монтирует папку, в которую вы складываете кэш, при следующих сборках этот кэш подкладывается.

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

Рекомендую почитать доку по buildkit, в последнее время там добавили дофига всего, о чём мало кто знает.

Один из участников записал видеоразбор моего таска с багом в nginx (включая подробный разбор функции ngx_http_validate_host).

https://youtu.be/uq-UX36UwCE

Делаем свой e-zine

У нас в хакспейсе возникла идея попробовать накидать свой собственный хакерский журнальчик.

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

📝 вы написали крутую тулзу или собрали DIY-проект, и хотите рассказать об этом?
🤯 разобрались в подводных камнях в какой-нибудь теме — от ядерной эксплуатации WinXP до SDR и премудростей ИИ?
👨‍💻 наткнулись на необычный CTF-таск и считаете, что о нём должно узнать больше людей?
🤖 любите ASCII-art и поразмышлять о киберпанке?
💃 считаете, что сцена уже не та и хотите поныть об этом?

Есть желающие присоединиться? Пишите мне или @g1inko.

[оригинальный анонс]

Подкладываем файлы в докер в remote context

Допустим, есть вот такая структура папок:

my-cool-project-dev
|— docker-compose.yml
|— config.yml
|— my-cool-project
   |— Dockerfile

Есть основная репа my-cool-project, где всё чисто и красиво, а есть dev-окружение в отдельной репе, где мы тестим продукт в нужном нам окружении.

Как подложить конфиг в контейнер my-cool-project?

Самое популярное решение: добавить в компоуз маунт ./config.yml:/config.yml:ro. Загвоздка в том, что моё тестовое окружение подразумевает запуск не в локальном докере, а на выделенной тачке, к которой клиентский докер подключён через remote context (рекомендую изучить, невероятно полезная фича). Из-за него все маунты будут происходить не с локальной тачки, а с тачки, где крутится докер демон, т.е. с ремоут контекста.

Поэтому, если вы хотите запустить в компоузе какой-то готовый образ, например, traefik, то конфиг можно подложить в новый слой образа: делаем папку traefik, кладём в неё конфиги и Dockerfile с директивами FROM traefik и COPY config.yml /config.yml, а в компоузе прописываем build: traefik.

Однако, в рассмотренном примере уже есть Dockerfile, который мы не хотим менять, но от которого не можем как-то органично отпочковаться, чтобы подложить конфиг. Не, можно конечно каких-нибудь build.sh скриптов понаписать, но мы ж хакеры, да?

Предлагаю вашему вниманию вот такой компоуз:

services:
  app:
    build:
      context: my-cool-project
      additional_contexts:
        config: ./config
      dockerfile_inline: |
        # syntax = devthefuture/dockerfile-x
        FROM ./Dockerfile
        COPY --from=config /config.yml /config.yml

В папку my-cool-project-dev/config мы кладём наши отладочные конфиги, добавляем их как дополнительный контекст для buildkit, и наконец, с помощью кастомного докерфайл-синтаксиса dockerfile-x, создаём инлайн враппер для докерфайла, в котором инклудим оригинальный докерфайл и добавляем копирование конфига в образ.

Кстати, через механизмы configs и secrets сейчас тоже нельзя с локальной тачки прокинуть ничего в ремоут контекст, но совсем недавно появился пулл-реквест с капибарой, который это фиксит (очень надеюсь, что его примут).

No, LLM Agents can not Autonomously Exploit Zero-day Vulnerabilities (yet)

Недавно стала распространяться новая работа про LLM-хакеров — "Teams of LLM Agents can Exploit Zero-Day Vulnerabilities". Например, на них ссылается Jason Haddix в своем видео, ещё это репостилось во многих каналах.

Почему эта некачественная работа, на которую не стоит ссылаться:

1) Это авторы, которые постоянно публикуют некачественные работы про автономных LLM-хакеров. Большие разборы их прошлых ресерчей можно прочитать тут:
- No, LLM Agents can not Autonomously Exploit One-day Vulnerabilities
- No, LLM Agents Cannot Autonomously "Hack" Websites

2) Это работа с некачественной методологией, о чем можно прочитать тут:
- https://www.linkedin.com/posts/activity-7206265412932567041-D9SY — автору двух разборов выше надоело разбирать их ресерчи и он просто сделал TLDR нового.

3) Датасет
Используемый датасет смещён в сторону простейших уязвимостей (т.е. нерепрезентативен).
Например, первая уязвимость в их списке — это XSS, где вам нужно ввести <​script>alert()<​/script> в поле формы, или SQLi-уязвимость, где вам просто нужно вставить полезную нагрузку в логин (что-то вроде 'or 1=1 -- -)

Если объяснять с языка кибербезопасности, то это уязвимости минимальной сложности примерно уровня джуна/стажера. Они редко встречаются в реальности, особенно в zero-day ресерче. Частично это можно отследить по "Attack Complexity" метрике в CVSS их уязвимостей - почти все они Low.

4) Сравнения
Авторы пишут "it outperforms open-source vulnerability scanners (which achieved 0% on our benchmark)."

Это неправда, потому что даже быстрый гуглинг показывает, что их SQLi уязвимости ломаются опенсурсной утилитой sqlmap: CVE-2024-33247, CVE-2024-31678. В реальности я ожидал бы >50% решаемости, если понимать чем/как пользоваться.

5) Невоспроизводимость
Авторы не оставили никаких данных для воспроизведения работы. Если в ресерчах принято показывать хоть что-то (часть промптов, псевдокод, подробный алгоритм), то тут почти всё скрыто или описано без пояснений, поэтому невозможно проверить.

В целом, LLM-агенты действительно могут быть эффективны в разных задачах кибербезопасности, просто конкретно это некачественные ресерчи, результаты которых ничего не показывают (кроме закона Гудхарта)

samply — невероятно простой профайлер

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

cargo install samply
samply record ./my-application

(вам понадобится Rust, чтобы его поставить, хотя профайлить можно не только растовые приложения)

После того как приложение отработало, результат автоматически откроется в браузере через Firefox Profiler, можно тыкать, фильтровать и даже зашерить результат, например: https://share.firefox.dev/3j3PJoK

Dreamhack Invitational

Обратил внимание на развивающуюся корейскую платформу для CTF-тренировок Dreamhack. Недавно они проводили большой CTF со сложными тасками, решил парочку и написал райтап.

В программе:
— случайно затесавшийся 10-минутный новичковый таск
— атака на кастомный ГПСЧ, автоматизируем решение с помощью фреймворка angr
— атака на RC4-like шифр с известным открытым текстом, автоматизируем решение с помощью Z3
— лёгкий CVE на fastjson, но внутри очень сложная слепая OGNL-инъекция, на которую ушло 90% всего времени

https://vladimirlebe.dev/19b2efeb42648010a017d664dec2f2df

Вышел разбор моего демо-таска на T-CTF 2025. Ещё несколько моих тасков можно будет заценить на самом соревновании 19-20 апреля.

https://habr.com/ru/companies/tbank/articles/891944/