Как сделать научную работу?

Наступил сентябрь. За последние пару недель пришла куча запросов по теме "Вова, какую мне тему взять на курсач?". Грустно, что нигде об этом не рассказывают (по крайней мере у нас), так что делюсь самым простым, универсальным и рабочим вариантом.

1. Определяемся, в каком направлении хотим двигаться (реверс малвари / криптография с публичным ключом / etc — чем область более узкая, тем лучше, иначе можно потеряться в изобилии материала).

2. Гуглим научные статьи по этому направлению, перечитываем десяток-другой статей (когда у вас спрашивают тему, времени на выбор обычно прям очень мало, поэтому лучше делать это заранее).

3. В статьях обычно пишут, какие есть ограничения, проблемы, варианты развития данной темы. Любая такая штука — это готовая тема для новой работы, если выглядит посильно — берём.

4. Также можно попытаться самостоятельно найти, как развить чужую тему. Например, автор написал тулзу и протестировал её на некотором классе программ. Что если протестировать её на другом (но не менее интересном с исследовательской точки зрения) классе программ?

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

^ последние несколько недель делал вот это

(CircuitPython это страшная вещь: вроде всё просто, но как только возникают какие-то проблемы, приходится продираться через тонну абстракций и всё равно разбираться, как там что работает. на мой взгляд, пока что сыровато немножк)

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

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

Делаем свой 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, где вам нужно ввести <​noscript>alert()<​/noscript> в поле формы, или 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