Вова Лебедев

Вышел разбор моего демо-таска на T-CTF 2025. Ещё несколько моих тасков можно будет заценить на самом соревновании 19-20 апреля. https://habr.com/ru/companies/tbank/articles/891944/

Dreamhack Invitational Обратил внимание на развивающуюся корейскую платформу для CTF-тренировок Dreamhack. Недавно они проводили большой CTF со сложными тасками, решил парочку и написал райтап. В программе: — случайно затесавшийся 10-минутный новичковый таск — атака на кастомный ГПСЧ, автоматизируем решение с помощью фреймворка angr — атака на RC4-like шифр с известным открытым текстом, автоматизируем решение с помощью Z3 — лёгкий CVE на fastjson, но внутри очень сложная слепая OGNL-инъекция, на которую ушло 90% всего времени https://vladimirlebe.dev/19b2efeb42648010a017d664dec2f2df

https://psi3.ru/blog/swl01u/

Потестировал новую модель Антропика, где агенты могут управлять компьютером, используя экран Инъекции с ней работают точно также и позволяют менять поведение агента на новое (например, отправить команды в терминал)

samply — невероятно простой профайлер Иногда бывает нужно разобраться в причинах, почему код работает слишком долго, но сетапить окружение или разбираться чем смотреть результат профайлинга слишком лень. cargo install samply samply record ./my-application (вам понадобится Rust, чтобы его поставить, хотя профайлить можно не только растовые приложения) После того как приложение отработало, результат автоматически откроется в браузере через Firefox Profiler, можно тыкать, фильтровать и даже зашерить результат, например: https://share.firefox.dev/3j3PJoK

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-агенты действительно могут быть эффективны в разных задачах кибербезопасности, просто конкретно это некачественные ресерчи, результаты которых ничего не показывают (кроме закона Гудхарта)

Подкладываем файлы в докер в 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 сейчас тоже нельзя с локальной тачки прокинуть ничего в ремоут контекст, но совсем недавно появился пулл-реквест с капибарой, который это фиксит (очень надеюсь, что его примут).

Делаем свой e-zine У нас в хакспейсе возникла идея попробовать накидать свой собственный хакерский журнальчик. Мы ищем авторов, готовых поделиться с миром своими исследованиями, проектами и интересными находками: 📝 вы написали крутую тулзу или собрали DIY-проект, и хотите рассказать об этом? 🤯 разобрались в подводных камнях в какой-нибудь теме — от ядерной эксплуатации WinXP до SDR и премудростей ИИ? 👨‍💻 наткнулись на необычный CTF-таск и считаете, что о нём должно узнать больше людей? 🤖 любите ASCII-art и поразмышлять о киберпанке? 💃 считаете, что сцена уже не та и хотите поныть об этом? Есть желающие присоединиться? Пишите мне или @g1inko. [оригинальный анонс]

Один из участников записал видеоразбор моего таска с багом в nginx (включая подробный разбор функции ngx_http_validate_host). https://youtu.be/uq-UX36UwCE

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, в последнее время там добавили дофига всего, о чём мало кто знает.

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

Оргаю Tinkoff CTF В прошлом году мы прям плотно поиграли Tinkoff CTF, а теперь я в числе организаторов и могу затизерить, что на этих выходных можно будет порешать пару интересных и сложных тасков от меня. Зарегаться и создать команду нужно сегодня вот здесь: https://ctf.tinkoff.ru/ (мои таски будут в лиге опытных) Если вы из Томска — можно будет зарулить своей командой в наш замечательный хакспейс, уже заявило о своём участии 5 команд.

Настраиваем виртуалки локально с помощью cloud-init Понадобилась недавно локальная виртуалка, но стало как-то лениво протыкивать в очередной раз инсталлятор Ubuntu Server. Облачные провайдеры уже давно используют cloud-init, мы можем использовать тот же подход. 1. Создаём cloud-init.yml: #cloud-config autoinstall: version: 1 user-data: users: - name: user lock_passwd: true ssh_import_id: - gh:hacker-volodya # импортируем свой ssh-ключ из гитхаба sudo: ALL=(ALL) NOPASSWD:ALL ssh: install-server: true В cloud-init есть миллион параметров на любой вкус: автоматическая установка софта, конфигурация сети и т.д., поэтому гуглим и кастомизируем под свои нужды. 2. Запускаем cloud-localds ./seed.iso ./cloud-init.yml (предварительно ставим тулзу через apt install cloud-image-utils). 3. Создаём виртуалку, подключаем туда iso с убунтой и рядом подключаем seed.iso (может понадобиться создать ещё один дисковод в виртуалке). 4. Запускаем виртуалку, установщик предложит всё поставить автоматически, подтверждаем. Через параметры загрузки ядра можно сделать, чтобы подтверждать не нужно было, но это слишком запарно для полу-домашнего использования. Теперь для раскатки каждой новой виртуалки нужно просто монтировать образ системы и seed.iso. После установки системы cloud-init принтит полученный айпишник в консоль, к которому можно коннектиться по ssh с аутентификацией по ключу.

Тут подкинули на работе ооооочень классную задачу. До её решения можно дойти эврестически, можно аналитически Надзиратель в концлагере решил освободить его и отдал приказ "расстрелять всех через одного, кто останется - тоже через одного и так далее, пока не останется один". Куда нужно встать, чтобы выжить?

Написал Email -> Telegram форвардер Надоело обновлять страничку в ожидании, когда в проектах отработает CI/CD, пошарился по фичам гитлаба и гитхаба для уведомлений. Можно отправлять уведомления на емэйл, но забивать почту мусором не очень хочется, поэтому открыл для себя Email Workers в Cloudflare. Как работает: 1. Имеем домен example.com, включаем для него в клаудфлейре Email Routing. 2. Деплоим с гитхаба воркер, который будет обрабатывать емэйлы, прописываем ему креды для бота в телеге. 3. Настраиваем правило, чтобы емэйлы для notifications@example.com направлялись в наш воркер. https://github.com/hacker-volodya/email-telegram-forwarder

Запилил дэшборд для отслеживания блэкаута в сети TON На этой неделе у валидаторов в очередях скопилось 2.5 млн сообщений, из-за чего всё стало работать невероятно медленно. Запилил графану, чтобы юзеры блокчейна могли наглядно в реальном времени отслеживать разбор очередей валидаторами: https://tonqueues.vladimirlebe.dev/

Го адвент, я создал

Го адвент, я создал

мы ждали этого джва года if __name__ == "__main__": print("Hello, world!")