Evil Merge: как малварь пряталась в git merge-коммите 3,5 месяца

Несколько месяцев назад я делал плановую проверку кодовой базы на одном из проектов и нашёл обфусцированный код в файле vite.config.js. Вредонос был добавлен не в коммитах, видимых в PR, а во время разрешения конфликта прямо в merge-коммите. GitHub показывает в PR только diff ветки, но не diff самого merge-коммита, поэтому добавленный код остался невидим.

Я пошёл смотреть через git log — какой коммит это принёс. Оказался merge-коммит. Не обычный коммит в ветке — именно merge. И вот тут началось интересное.

Merge, который не должен был ничего менять

У merge-коммита было два родителя. Я проверил файл в обоих — идентичный. Одинаковое содержимое, одинаковый MD5:

Родитель 1: aa82acb0c335430d8300b6cb306dc824  ? чистый Родитель 2: aa82acb0c335430d8300b6cb306dc824  ? чистый, идентичный Merge:      2a54754defae4d13aab39f256738dbbf  ? ДРУГОЙ 

Если вы понимаете как работает трёхстороннее слияние в git — вы уже видите проблему. Когда оба родителя содержат одинаковый файл, git просто берёт его как есть. Ему нечего мержить. Единственный способ получить другой результат — вручную отредактировать файл в процессе merge до коммита.

Именно это и произошло. Контрибьютор, нажавший кнопку merge в PR, добавил код которого не было ни в одной из веток. Git записал это как обычный merge-коммит, и никто не обратил внимания.

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

Что делал этот код

Я потратил день на деобфускацию. Коротко:

Первый слой восстанавливает строки require, module, constructor через алгоритм перемешивания с числовым сидом. Это позволяет обойти любой статический анализ, который ищет подозрительные ключевые слова. Вместо eval() используется Function constructor — делает то же самое, но grep не поймает.

Второй слой — кастомный декодер на таблице замены символов. Декодирует большой зашифрованный блок в настоящий пейлоад.

Дальше — самое интересное. Пейлоад не содержит ни одного URL и ни одного IP-адреса. Вместо этого он запрашивает TRON-кошелёк на последнюю транзакцию, берёт из неё BSC-хеш транзакции, делает eth_getTransactionByHash JSON-RPC запрос к BSC-ноде и вытаскивает из поля input зашифрованный XOR-ом код. Этот код и выполняется.

Канал управления — блокчейн. Его нельзя заблокировать по домену, нельзя вынуть сервер. В исходниках нет никаких очевидных индикаторов компрометации.

Есть резервный путь через Aptos на случай если TRON недоступен. Вся инфраструктура — кошельки, транзакции — была подготовлена до внедрения кода.

Финальный этап запускает отдельный фоновый процесс (child_process.spawn с stdio: 'ignore' и detached: true) — он живёт после завершения Vite. Таймер на 30 секунд не даёт коду выполниться повторно в watch-режиме.

Всё это запускалось при каждом npm run dev и npm run build примерно 3,5 месяца.

Почему никто не заметил

GitHub не показывает diff merge-коммитов в PR. Ревью PR показывало изменения ветки — всё чисто. Сама инъекция произошла на шаге merge, который никто не ревьюит. Ну а зачем? Это же просто слияние.

git log показывает merge-коммит, но не то что в нём изменилось. Чтобы увидеть это, нужно запустить git diff <parent1>..<merge> — а так никто в рутинной работе не делает.

Файл в любом редакторе выглядел нормально. Вредоносный код был на той же строке что и легитимный, просто сдвинут вправо пробелами. Его не увидеть, если специально не скроллить за колонку 200.

SAST не поднял тревогу, потому что явных сигнатур не было — ни eval, ни URL, ни base64 в открытом виде. Всё за кастомным энкодером.

Что такое evil merge

После этого инцидента я начал копать — есть ли для этого название и известна ли такая техника. Оказалось, термин есть, и он официальный. Из документации git (gitglossary(7)):

An evil merge is a merge that introduces changes that do not appear in any parent.

Термин закреплён в официальном глоссарии git. В 2013 году Junio C Hamano — нынешний мейнтейнер git — написал единственный серьёзный пост на эту тему, объясняя как evil merge может возникнуть случайно при семантических конфликтах. То что я нашёл — не случайность.

На Хабре по этой теме нет ни одной публикации. На dev.to — одно упоминание в комментарии. На HN — пара реплик в чужих тредах. Тема, которую мейнтейнер git описывал ещё в 2013-м, в 2024-м году практически неизвестна разработчикам.

С инструментами ещё хуже. Есть evilmergediff — Python 2 скрипт, последний коммит в 2013 году, нет exit-кода, нет CI-интеграции. Есть пара bash-гистов на GitHub. Встроенный git show --remerge-diff может показать проблему, но только если вы вручную запустите его на конкретный коммит. Инструмента который сканирует всю историю репозитория автоматически — не было.

Детектор

После того как паника улеглась и мы поменяли все секреты которые смогли найти, я начал думать — а можно ли это было поймать автоматически?

Логика простая: для каждого merge-коммита восстановить то что git должен был сгенерировать — чистое трёхстороннее слияние деревьев родителей через общего предка — и сравнить с тем что merge-коммит реально содержит. Любое расхождение означает что файл редактировался вручную в процессе merge.

Из этого получился Evil Merge Detector — CLI на Go:

evilmerge scan /path/to/repo 

Он проходит по всем merge-коммитам, сравнивает ожидаемое дерево с реальным и выводит расхождения. Есть --format=sarif для интеграции с GitHub Code Scanning и уровни severity (конфликтные разрешения которые были ручными — ожидаемы, инструмент их отличает от правок файлов без конфликта).

Есть GitHub Action для добавления в CI:

- uses: fimskiy/Evil-merge-detector@v1   with:     fail-on: warning 

И GitHub App — устанавливается на репозиторий и автоматически проверяет каждый PR через Checks API. При первой установке он сканирует всю историю репозитория — на случай если инцидент уже произошёл.

Для GitLab, Bitbucket или self-hosted git-серверов — готовые шаблоны в директории examples/, включая pre-receive хук, который блокирует push с evil merge прямо на уровне сервера.

Шире

Атаки на supply chain через зависимости open source получают много внимания. Атаки через contributor-доступ к приватным репозиториям — почти никакого.

Паттерн простой: получить доступ контрибьютора, несколько месяцев делать легитимные коммиты, потом внедрить код во время merge. PR чистый. Merge-коммит выглядит как рутинная интеграция.

Стандартный совет — требовать линейную историю (squash/rebase only) или поставить pre-receive хук на своём git-сервере. Оба варианта меняют workflow или требуют self-hosted инфраструктуру. На GitHub это не так просто.

Я отправил репорт в GitHub Security. Полный ответ:

«This is an intentional design decision and is working as expected. We may make this functionality more strict in the future, but don’t have anything to announce right now.»

В качестве существующей митигации указали “Dismiss stale reviews” — правило защиты ветки, которое требует повторного ревью при каждом новом коммите в PR-ветку.

“Dismiss stale reviews” действительно усложняет атаку. Но это prevention, не detection. Он не сканирует существующую историю на предмет прошлых инъекций. Требует ручной настройки на каждый репозиторий. И может быть отключён любым администратором. Если правило не было включено до инцидента — или он произошёл в репозитории без активного мониторинга — вы об этом не узнаете.

GitHub оставил дверь открытой для будущих изменений, но ничего конкретного не анонсировал. Пока — merge workflow работает так же.

Я не знаю насколько это распространено. Может наш случай редкий. Но то что это работало 3,5 месяца в репозитории с CI, code review и несколькими разработчиками которые работали с ним каждый день — говорит о том что мы, возможно, проверяем не то.