мы ждали этого джва года

if __name__ == "__main__":
    print("Hello, world!")

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

Мои решения можно трекать тут: https://github.com/hacker-volodya/adventofcode2023

Запилил дэшборд для отслеживания блэкаута в сети TON

На этой неделе у валидаторов в очередях скопилось 2.5 млн сообщений, из-за чего всё стало работать невероятно медленно.

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

https://tonqueues.vladimirlebe.dev/

Написал 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

Тут подкинули на работе ооооочень классную задачу. До её решения можно дойти эврестически, можно аналитически

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

Настраиваем виртуалки локально с помощью 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 с аутентификацией по ключу.

Оргаю 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

Подкладываем файлы в докер в 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/